Before replacing your restaurant website, make a list of the pages people already use and decide where each old address should lead. After launch, check those addresses, the new pages, and the links that send guests to them. Pay particular attention to menus, locations, hours, and ordering.
A good-looking replacement is not enough if a saved menu link stops working or a search result sends guests to the wrong location. This restaurant website redesign SEO migration checklist gives you a practical way to protect useful paths without promising a particular search ranking.
1. Inventory the pages and links you have
Start the inventory before the old site comes down. Open the site on a computer and a phone, follow the navigation, and record the full address of each useful page. Include pages that may not appear in the main menu, such as catering information, private dining, gift cards, accessibility information, and individual location pages.
For each address, note what a guest expects to find there. A page called Menu may contain a downloadable file, while another location has its own menu page. Those are separate destinations if they have separate URLs.
Use several sources to find pages you might otherwise miss:
- Check the current navigation, footer, sitemap, and links within the site.
- Review website analytics, if available, for pages that receive visits or lead to useful actions. Look at a reasonable period rather than just the last few days; seasonal pages can matter.
- Review Google Search Console, if it is already set up, for pages receiving search impressions or clicks and for indexed URLs.
- Check public links you control, including business profiles, social accounts, email templates, digital ads, and QR codes on printed material.
- Ask staff which links they send to guests and which pages answer common questions.
Record the exact URL, including its domain and path. If the same page can be reached with different address forms, record those too. Keep a copy of important page content and menu files so the person building the replacement can check that essential information makes it across.
Also identify who controls the domain, DNS settings, hosting, and existing website. Confirm that the right people can make launch-day changes and that access will remain available long enough to handle corrections. If you are still deciding how to build the replacement, the restaurant website creation guide covers the broader setup decisions.
2. Map every useful address to a destination
For each old URL, choose one of three actions: keep the address and serve the equivalent page there, redirect it to a relevant replacement, or intentionally retire it. A redirect is an instruction that sends a visitor and search engines from one address to another. Ask the person managing the old address to use a permanent redirect, commonly a 301, when a page has moved permanently.
Match the destination to the guest's original intent. An old catering page should lead to the new catering page, not automatically to the homepage. If a location has closed, a page explaining the closure and directing guests to nearby options may be more helpful than silently sending them to a different restaurant.
The following worksheet is a hypothetical example for a restaurant replacing its site. The launch-check column describes what to verify, not a completed test.
| Old URL | Decision and destination | Launch check |
|---|---|---|
| /menu | Keep /menu with the current menu | Page loads and menu is readable on a phone |
| /catering-old | 301 redirect to /catering | Old address reaches the relevant catering page |
| /downtown-menu.pdf | 301 redirect to /locations/downtown/menu | Old file link reaches the downtown menu |
| /summer-2024 | Retire the expired promotion; no equivalent offer exists | Old address returns a clear not-found response |
In your own sheet, add an owner and a status for each row. Include full URLs rather than only the paths shown above, especially if the domain is changing. Mark high-priority rows for pages with useful visits, important outside links, or printed QR codes.
Do not force every retired page to the homepage. If there is no useful replacement, an intentional not-found response, such as a 404 or 410, can be clearer. Provide a helpful not-found page with navigation so a guest can continue browsing. Ask your provider how it handles these responses and where redirects are configured.
Check for redirect chains, too. Ideally, an old address should lead directly to its final destination, rather than passing through several intermediate addresses. Update links you control to point to the final URL, even when the redirect works. You cannot update every outside link, so keep necessary redirects in place and agree who will maintain them.
3. Set launch responsibilities before the switch
Share the mapping sheet with whoever controls the old site and whoever is building the new one. One person should own the final list, but the technical work may involve more than one provider. Confirm who will configure redirects, change DNS if needed, check the secure version of the domain, and resolve problems after launch.
Ask these questions before approving the switch:
- Can the new site use the addresses we intend to keep? If not, where will redirects be set up?
- Will the old hosting or domain configuration need to remain active for redirects to work?
- Who can edit page titles, descriptions, menu content, and location details after launch?
- How will we check that search engines are allowed to access the pages intended for discovery?
- What is the rollback or correction plan if the domain, menu, or ordering link fails?
If there is a preview site, review it before launch, but do not treat a working preview as proof that the public domain and old redirects will work. Also confirm that any settings used to keep a preview out of search results are reviewed when the public site goes live.
Protect the ordering route separately from the page design. Fleksa describes options to keep an existing site with an ordering button or link, as well as branded websites connected to ordering. Whichever setup you choose, ask who controls the destination and what happens if it changes. The online ordering page provides context for that product decision; the migration sheet should still record the actual link guests use.
4. Verify the public site and guest paths
As soon as the replacement is live, work through the priority rows in your sheet. Enter each old URL directly, then record the final address and whether the expected content appears. Check the homepage, every location, current menus, contact details, and key calls to action on both a phone and a computer.
For redirects, check the response with a browser or a redirect-checking tool. Confirm that permanent moves use the agreed response and end at the right page. A page that loads is not necessarily the right page: an old downtown menu link that opens the uptown menu still needs fixing.
Follow links as a guest would. Open a business profile, a social link, and a digital copy of an email. Scan representative printed QR codes. Check that telephone links open the phone action and that addresses and hours match the appropriate location. Review menu files for legibility and current content.
For ordering, use a simulated check that stops before any real transaction. Confirm that the button opens the intended ordering destination and that a guest can find the correct location and menu. Do not submit a real card payment, send a guest message, or dispatch a courier as part of practice. If the restaurant later chooses a live service pilot, plan and authorize that separately with the people handling orders and any delivery arrangements.
Record failures with the starting URL, device, observed destination, and responsible person. Recheck after a fix. If a critical path is broken, such as the main menu or ordering button, use the agreed correction or rollback plan rather than waiting for search reports to catch up.
5. Monitor discovery and fix what matters
Once the basic guest paths work, check search visibility over the following days and weeks. Google Search Console can help you inspect important URLs, review indexing information, submit a sitemap, and see search performance for the site. Make sure the appropriate property is accessible to the person responsible for monitoring, especially if the domain has changed.
Start with the pages that matter most: homepage, locations, menus, and other pages with useful search activity before launch. Compare what you see with your inventory. If a replacement page is missing from the index, inspect its URL and check whether it loads publicly, is blocked from crawling, carries an instruction not to index, or identifies a different canonical URL. Ask the site provider to explain and correct any setting that does not match your plan.
A sitemap can help communicate the new site's URLs, but submitting one does not guarantee indexing or a ranking. Likewise, a search for your restaurant name can be a useful spot check, but it is not a complete index report. Search results can take time to reflect changes and may vary. Investigate persistent problems rather than assuming every movement means the migration failed.
Keep the mapping sheet active after launch. Assign a date to review unresolved issues, update public links you control, and retain a record of retired addresses and their decisions. For a wider review of editing controls and mobile usability before choosing a builder, see the related buying guide.
Next step: List your ten most important existing URLs, assign a destination and an owner to each, and ask your website provider how those addresses will be handled. Then review Fleksa's restaurant website page and request a demonstration if it fits your restaurant.
Frequently asked questions
Do I need a redirect if the URL stays the same?
Usually the key check is that the same public address loads the intended replacement content. Test any alternate address forms too, and redirect those that should resolve to the chosen URL.
Should every old page redirect to the homepage?
No. Send a moved page to the closest useful equivalent. If an expired page has no meaningful replacement, an intentional not-found response may be more useful than an unrelated redirect.
Will redirects preserve my search rankings?
Redirects help visitors and search engines find moved content, but they do not guarantee rankings. Check important URLs and search reports after launch, and investigate access or indexing problems.
