If two public URLs show the same restaurant menu, choose one as the preferred address and make the other point to it. A permanent redirect is usually the clearest option when the duplicate no longer needs to serve visitors. If both addresses must remain accessible, ask your website provider to add a canonical annotation on the duplicate that names the preferred URL.
Start with the address you want guests to share, update, and use in the future. Then check whether the two pages really are duplicates and who can change each one. A canonical annotation is a suggestion to search engines, not a guarantee that they will index or rank the address you select.
Inventory every public menu address
Make a short list of the URLs where a guest can see the menu. Include the address linked from your home page, the one on your ordering button, and any older address still printed on signs or shared on social profiles. Search your restaurant name and menu, then add any other public addresses you find.
Look for small differences that make addresses distinct: a trailing slash, a different subdomain, or extra text after a question mark. A campaign link may contain tracking parameters even though it opens the same page. Record the full address before deciding whether it needs its own treatment.
For each URL, note what it displays, whether it works on a phone, where guests encounter it, and who controls it. The website provider may control the main site, while an ordering provider or former agency controls another address. Your domain registrar, web host, and site builder may be different companies; access to one does not necessarily give you access to all three.
Ask each provider who can change redirects, canonical annotations, and menu links. If the answer is unclear, use the domain ownership guide to sort out the accounts and permissions before requesting changes.
Do not treat every menu-related page as a duplicate. A lunch menu and a dinner menu with different items can each deserve their own address. An ordering page may also offer choices or checkout functions that a display menu does not. Compare the actual content and guest task, not just the page titles.
Choose the intended public version
The preferred URL should be the one you can maintain and want customers to use. Favor an address that works on mobile, shows accurate items and prices, and sits on a domain your business controls. Consider whether guests need to browse only or move directly into ordering. The best address is not automatically the oldest one or the one with the shortest path.
Suppose two pages look the same today, but one is edited by your current staff and the other belongs to a former provider. If you can verify that the current page is complete and reliable, it is generally the more practical destination. Before retiring the older page, check whether it carries useful ordering or accessibility functions that would be lost.
Also consider the cost of the change. A provider may charge to configure a redirect, update a template, or transfer access. Ask for a written scope and quote that separates one-time setup from recurring charges. The decision should account for the work needed to keep the chosen menu current, not just the technical change.
Use one consistent address in your website navigation, business profiles, social bios, email signatures, and newly printed QR codes. Existing printed materials may take longer to replace, which makes a working redirect especially useful. If you are reviewing your broader site setup, the restaurant website builder comparison offers questions to ask about control and editing.
Map duplicates to redirects or canonical annotations
For a true duplicate that no longer needs a separate public address, request a permanent server-side redirect to the preferred page. A visitor opening the old address should arrive at the corresponding menu, not an unrelated home page. Confirm who can create the redirect and whether it will remain in place if you change providers.
If both pages must remain accessible, ask whether the duplicate can include a canonical link annotation in its HTML that points to the preferred URL. The preferred page can also identify itself as canonical. This tells search engines which address you prefer while allowing visitors to open either page. It does not automatically send a guest from one page to the other, and a search engine may choose a different canonical URL.
Here is a hypothetical example for a restaurant with one current menu and two older ways to reach it. The addresses are examples, not live pages. The table records the intended action and the check needed after the change.
| Current address | Intended destination | Action | Validation |
|---|---|---|---|
| example.com/menu | example.com/menu | Keep as preferred menu; use a self-referencing canonical annotation. | Page loads with the current menu and its canonical points to itself. |
| example.com/food | example.com/menu | Use a permanent redirect if the old page can be retired. | Opening the old address reaches the preferred menu. |
| example.com/menu?source=flyer | example.com/menu | If tracking requires this URL to stay accessible, use a canonical annotation pointing to the preferred menu. | Tracking works as intended and the page names the preferred URL. |
The parameterized address in this example stays accessible because the restaurant wants to preserve its tracking. If tracking is no longer needed, a redirect may be simpler. Ask the provider to check that the chosen method does not break reporting or ordering. Do not copy the example paths into your own configuration without checking what your pages do.
Keep the signals consistent. A redirect should lead to the selected destination, and a canonical annotation should name that same destination. Avoid chains in which an old menu redirects through several other addresses. Also check that the preferred page is accessible to search engines and is not marked to stay out of their indexes. Blocking a duplicate from crawling can prevent a search engine from seeing its canonical annotation.
Some platforms limit redirect or page-header controls. If a provider cannot make the requested change, ask what it can configure, who owns the address, and whether the restaurant can move the page or update the links that send guests there. Do not remove a working menu until a replacement is ready and tested.
Validate links and indexing after the change
Keep the mapping as a working checklist. Record the person responsible for each change and the date it was made. Then check the guest experience separately from the search-engine signals:
- Open every listed URL. Use a phone and a desktop browser. Confirm that the preferred page loads and that redirected addresses reach the intended menu without an error or loop.
- Check the menu itself. Confirm that items, prices, hours where shown, and ordering links are current. If the old page had a useful function, make sure guests still have a sensible way to complete that task.
- Inspect the canonical annotation. Ask your provider to show you the page HTML or use an inspection tool. Confirm that any accessible duplicate names the exact preferred address, including the correct domain and path.
- Update links you control. Change navigation, buttons, profiles, and digital campaigns to point directly to the preferred page. Test existing QR codes; plan replacements for printed codes that cannot be edited.
- Review search visibility. If you have access to a search-engine webmaster tool, inspect the preferred and duplicate URLs. Compare your declared canonical with the one the search engine reports selecting. Recheck later; processing is not immediate.
A browser check tells you what a guest encounters. It does not prove that a search engine has indexed the preferred URL. Likewise, a canonical tag in the HTML does not prove that the search engine accepted it. If the reported selection differs, look for conflicting redirects, internal links, access restrictions, or content that is not actually equivalent, then ask your provider to investigate.
For the next step, complete the mapping for your current menu and send it to whoever controls each address. If you are considering a new restaurant website, ask Fleksa about verified US availability and how its setup would handle your existing menu URLs before you change providers.
Frequently asked questions
Should both menu URLs stay live?
Only if there is a reason to keep both accessible, such as a working tracking setup or a necessary guest function. Otherwise, a permanent redirect to the preferred menu is often easier to maintain.
Does a canonical tag redirect guests?
No. It identifies a preferred URL for search engines; visitors can still view the page they opened. Use a redirect when visitors should be sent to the other address.
Should an ordering page use the menu page as its canonical?
Not automatically. If the online ordering page has a different purpose or meaningful functionality, assess it as a separate page rather than treating it as a duplicate solely because it shows menu items.
