SEO migration: a before-and-after website checklist

A new website can look better and still make your business harder to find. The danger is rarely the colour scheme. It is a valuable page disappearing, a redirect pointing to the wrong place or a launch setting that tells Google not to index the new site.

SEO migration is the work of carrying search visibility, useful content and working customer journeys from the old website to the new one. It cannot guarantee unchanged rankings. It does give you a plan for avoiding preventable mistakes and finding problems quickly.

This guide covers the checks before and after a move. If you need someone to review the plan, explore Craig's SEO consultancy.

What kind of website migration are you making?

Start with the URLs, not the platform name. A hosting change can leave every public address unchanged. A move from WordPress to another platform may also preserve URLs, or it may change all your article and service paths. Changing the domain, moving from HTTP to HTTPS and reorganising folders create different risks.

Write down what is changing: domain, hosting, platform, navigation, content and URL structure. Where practical, avoid changing everything at once. Separating major changes makes it easier to understand a performance drop. For a very large site, a smaller test move may expose problems before the entire site is affected.

Before migration: the SEO checklist

1. Record the starting position. Export Search Console clicks and impressions by page and query. Save organic landing-page traffic and actual enquiries or sales for a comparable period. Note seasonality, brand campaigns and tracking changes so later comparisons are meaningful.
2. Build a complete URL inventory. Combine a crawl of the old site with its sitemap, analytics landing pages, Search Console exports and known linked pages. Include important images, PDFs and other downloadable resources, not just the pages in the menu.
3. Decide what happens to each URL. Mark it as staying, moving, merging or being removed. For every moved page, choose the closest relevant destination. Do not send every deleted article to the homepage: a page about a specific service needs a destination that still answers that need.
4. Keep the useful content. Check that valuable explanations, page titles, headings, internal links and image descriptions survive the redesign. Improve weak content deliberately rather than deleting it because it does not fit the new template.
5. Prepare permanent redirects. Use server-side 301 or 308 redirects for permanent moves. Aim for one hop from the old address to the final new address. Test the destination, not just whether the old page redirects.
6. Protect the test site. Restrict access to staging. Keep a separate launch checklist for removing staging-only access restrictions or noindex settings from the production site. A robots.txt block alone is not a reliable way to keep a test URL out of search.
7. Check the new pages. Review status codes, self-referencing canonicals, crawlable internal links and the new sitemap. If your site genuinely uses hreflang, check that language and regional references use the final URLs.
8. Test real customer journeys. Submit a clearly labelled enquiry, check it reaches the correct inbox and test key purchases or booking steps. Confirm analytics and consent behaviour still work without treating a tracked event as proof of a sale.
9. Assign launch responsibilities. Name who controls redirects, DNS, access settings, tracking and recovery. Back up the old site and configuration. Agree what would justify rolling back and how you would do it.

A simple URL map you can actually use

Your migration spreadsheet needs an old URL, a decision, a final URL, a redirect status and a test result. Add an owner for unresolved entries. For example, an old /seo-advice/ page might move to /consultancy/seo-consultancy if the new page genuinely replaces its offer. That is an illustration, not a rule to apply to every consultancy website.

Keep addresses unchanged when there is no good reason to alter them. A cleaner-looking URL is not automatically worth the disruption of replacing an established one. Where a page is removed without a suitable replacement, returning a genuine 404 or 410 is better than pretending unrelated content is its successor.

Launch day: check what the public can reach

Repeat the critical tests against the production domain. A staging preview is not enough. Check the homepage, important landing pages, old URLs with backlinks, images and a complete enquiry or checkout journey. Make sure the production pages are not carrying noindex tags or unintended crawler blocks.

Publish a sitemap containing the final canonical URLs you want indexed and submit it through the appropriate verified Search Console property. For a domain move, use Google's Change of Address tool where supported; it is not a tool for every hosting or path change. Verify access to both properties before launch rather than discovering an ownership problem afterwards.

After migration: the SEO checklist

1. Crawl the live site. Look for broken internal links, redirect loops, server errors and canonicals pointing to staging or old URLs. Compare the crawl with the URL map.
2. Retest priority redirects. Old addresses should reach relevant new pages, which should normally return 200. Replace internal links to old addresses so visitors and crawlers do not depend on redirects inside the new site.
3. Check search visibility by page group. Review branded and non-branded queries separately. Compare equivalent periods and look at affected sections rather than relying only on total traffic.
4. Monitor indexing and crawling. Use Search Console reports and inspect representative URLs. If a new page is excluded, investigate the reason before repeatedly requesting indexing. The indexing problems guide covers that diagnosis separately.
5. Check business outcomes. Confirm organic enquiries are still arriving and that sales or lead tracking has not broken. Use the SEO ROI guide to separate reporting changes from commercial performance.
6. Keep the redirects available. Google recommends keeping redirects for at least a year; consider keeping useful ones longer for visitors and old links. Update important external links you control, including business profiles and social accounts.
7. Keep an issue list. Record the symptom, affected URLs, evidence, owner and fix. Prioritise inaccessible or blocked revenue-generating pages before minor cosmetic issues.

What if traffic falls after the move?

Some fluctuation can happen while Google processes a move. There is no universal recovery deadline. First rule out changed measurement, seasonal demand and a simultaneous search update. Then check whether the decline is concentrated in pages that changed address, lost content or became inaccessible.

A sharp drop across the site warrants immediate checks of indexability and server responses. A drop in one section suggests a more targeted problem, such as missing content or incorrect redirects. Do not keep changing URLs in response to every daily movement; fix what the evidence supports.

Make the migration a business decision, not just a design project

The strongest migration plan preserves what customers need and makes the next step easier. Search checks and commercial checks belong together. If you are planning a platform change, domain move or substantial redesign, send Craig your current website, proposed changes and intended launch date to discuss SEO and digital marketing consultancy. No migration can promise a particular ranking, but a proper review can identify avoidable risks before launch.

Sources and further reading

• Google Search Central: site moves with URL changes
• Google Search Central: hosting changes without URL changes
• Google Search Central: redirects and Google Search