Moving your website without losing your search visibility: a practical checklist

A new website can be faster, clearer and better looking yet still lose search visibility if important URLs disappear, redirects are wrong or the new production site remains blocked. This checklist covers the common failure modes and the checks worth documenting.

Before you build

1. Inventory every URL that exists today. Not only those in the menu. Use the sitemap, a crawl, Search Console and your analytics, and the backlink data you have. Pages nobody links to internally can still earn traffic.
2. Record what each page is worth. Traffic, enquiries and inbound links. This is how you decide what must be preserved.
3. Keep URLs where you sensibly can. Every URL that changes is a redirect to maintain. Change them for a reason, not for tidiness.
4. Map old URLs to relevant successors. Usually that means an old page to its nearest new equivalent. Several old pages can point to one new page if content really has been consolidated. When nothing relevant exists, return a genuine 404 or 410 instead of sending everything to the homepage.
5. Take a baseline. Search Console queries and pages, analytics, rankings you care about, speed. You cannot judge a migration without a before.

While you build

6. Keep the build out of search, deliberately. Use a noindex instruction on staging pages, or require a login. Be careful about combining that with a robots.txt block: Google says that for a noindex to work the page must not be blocked by robots.txt, otherwise the crawler never sees the instruction. And robots.txt on its own is, in Google’s words, not a mechanism for keeping a page out of Google. Choose one approach on purpose and write down what must be removed on launch.
7. Keep canonical tags pointing at the final addresses, never at staging.
8. Recreate what matters. Titles, descriptions, headings, structured data, internal links, image alt text, forms and tracking. The visual redesign is where these most often vanish.
9. Check the redirect mapping against the staging routes using a script. Then test the actual responses from the old host once redirects are configured; a staging test alone cannot prove another provider will redirect correctly.

Launch day

10. Use permanent redirects. Google recommends permanent server-side redirects such as 301 and 308, and says it treats them as a signal that the target should be canonical.
11. One hop. Old URL straight to the final one, not through a chain.
12. Remove the protections you added. The noindex, the robots.txt block, the login or the access header. Check the live pages return 200 without authentication and without a noindex in either the HTML or the response headers.
13. Submit the new sitemap, and confirm it lists only the final canonical URLs.
14. Check hostnames and HTTPS. One preferred version of the address, with the others redirecting to it.
15. Move the tracking, forms and contact routes, and test them from outside your own network, because staging and logged-in views hide problems.
16. Where the domain or subdomain changes, check Search Console’s Change of Address eligibility. It is for qualifying moves between verified properties, not routine path changes or hosting-only moves. You cannot assume access to that tool or a redirect from an old third-party subdomain you do not control.

Afterwards

17. Watch the Search Console properties you can actually verify. Track indexed pages, errors, queries and clicks against a real baseline. If the previous URLs live on a third-party subdomain you cannot verify, acknowledge that limitation.
18. Look for 404s with inbound links. Those are redirects you missed.
19. Keep the redirects. Google’s advice is to keep them for as long as possible, generally at least a year.
20. Re-crawl yourself. Chains, loops and links still pointing at old URLs.
21. Give it time, and compare against the baseline in weeks, not days. Some movement is normal after a major change.

The failures that cause most of the damage

• noindex or a robots block left on. The new site is live and invisible.
• Canonicals pointing at staging. Google is told the real pages are elsewhere.
• Unrelated URLs all redirected to the homepage. An irrelevant catch-all may be treated as a soft 404. Map to genuine successors, or return an appropriate removal response.
• Pages with traffic or links deleted without a destination.
• URLs changed for neatness, creating hundreds of redirects that did not need to exist.
• Forms and tracking untested on the live site.

Where SMB fits

Migrations are part of SEO work at SMB, inside the agreed scope. SMB is not a general web-design business, so if a rebuild is the wrong answer we will say so. If you are comparing providers for this, you can read about SMB’s approach in How we work.

How this could be wrong

This is a general guide, not a promise that every platform supports the same redirect controls. Google distinguishes hosting-only changes from URL/hostname moves. Its primary site-move, hosting, redirects and noindex documents were checked directly for this revision; consult their current versions again for a real migration.