Website Migration SEO Checklist
Before replacing a website, record the URLs and content people already use. That gives you a migration checklist you can test against the new site.
If you are still deciding whether to replace the site, start with our redesign versus rebuild guide.
1. Save the old site's URLs and search data
Combine a crawl with the sitemap, Search Console landing pages, analytics and known campaign links. Include important PDFs and other downloads.
Record each URL's status, title, canonical and purpose. Save dated search and traffic reports so you can compare the same pages after launch.
Flag pages that matter even if their traffic is low, such as an application form or a resource linked by partner organisations.
In our ROH Wheels rebuild, the migration included more than 180 news articles as well as image galleries from WordPress. Those older URLs needed mapping alongside the catalogue. A list containing only the new navigation would have missed that archive.
2. Decide where each URL belongs
Give each important URL an outcome: retain, replace, combine or remove. Ask the content owner to resolve uncertain cases.
A sample map might look like this:
| Old URL | Decision | Expected result |
|---|---|---|
/services/advice |
Retain | Same URL returns the service page |
/our-training |
Rename | Permanent redirect to /training |
/resources/old-handbook.pdf |
Replace | Redirect to the current handbook, if it serves the same purpose |
/news/expired-test-page |
Remove | 404 or 410 if there is no replacement |
Avoid redirecting unrelated pages to the homepage. Send visitors to a relevant replacement, or return a proper not-found response.
When combining pages, check that the destination still answers the questions covered by the old content. Google's site-move guidance explains these decisions and the search fluctuations that can follow a move.
3. Test redirects and their destinations
For each mapped URL, check that:
- The intended permanent redirect uses 301 or 308.
- It reaches the correct page without a loop or unnecessary chain.
- The destination returns the expected status and content.
- Internal links point directly to the new URL.
- Required query parameters still work.
Test parameters by purpose. A campaign identifier and a product filter can affect the site differently.
Use the migration worksheet to record the expected destination, result and any fix required.
4. Compare important pages
Check that key headings, answers, images, downloads and links survived the move. Review titles and descriptions where the content changed.
Check canonical tags for staging addresses or incorrect destinations. Google uses canonicals to identify the preferred version of duplicate or substantially similar pages; the canonical documentation explains their use.
Include HTTP headers in the check. A PDF can return 200 OK while an X-Robots-Tag: noindex header prevents indexing. HTML pages can receive indexing instructions through headers too. Google documents both mechanisms.
If the site includes structured data, check that it still matches the page.
5. Check the production environment
Before opening the site to visitors and search engines, verify:
- Production pages have no leftover staging
noindexinstructions. - Authentication, robots rules and security tools allow the intended access.
- The sitemap lists current, indexable URLs.
- Forms and downloads work through the production CDN and hosting.
- Tracking records the intended events.
Check several page types. A working homepage can hide a blocked resource section or broken integration. Our Cloudflare Googlebot incident is one example of how a security setting can affect crawling.
6. Assign launch responsibilities
Name the people who approve release, change DNS, check the live site and restore the previous deployment if needed.
Agree how content edited during final testing will reach production. Repeat critical checks after deployment, when email, caching and integration settings may differ from staging.
Set a content cut-off and plan a final import for records created or changed since the first migration. Compare record counts, but also check a sample of titles, dates, documents and images. Matching totals can conceal one missing record and one duplicate.
Google recommends separating major changes where possible. Moving domain, replacing the CMS and rewriting the content together makes a fault harder to isolate. Plan enough server capacity for increased Google crawling after the move. See Google's migration guidance.
For a move to another domain, check whether Google's Change of Address tool applies. It is not required merely because the site has a new design.
7. Monitor after launch
Check important pages, forms and downloads immediately. Then review crawl errors, indexing, search impressions and landing-page traffic over consistent periods.
Investigate patterns: missing resource URLs may point to an incomplete import; a whole section dropping out of search may point to a canonical or indexing problem.
Google recommends keeping redirects for at least a year. Keep them longer where useful old links still exist.
Our website development service includes planning the migration alongside the new build.