Website migration SEO checklist for developers

Protect discoverability during a website migration with URL mapping, redirects, canonicals, language alternatives, sitemap checks and post-launch monitoring.

A solid dark structure transitioning into lighter modules beneath a silver ring.

A website migration changes the signals that help search engines and users find content. The development task is to preserve useful destinations and make the new structure internally consistent. Start with an inventory of existing URLs and identify which content moves, merges or disappears. Treat the migration as a controlled change with a measurable baseline, not a final redirect task added after the new design is complete.

Build an explicit destination map

Collect URLs from the current sitemap, internal crawl and available search or analytics data. Map each important page to the closest relevant new destination. Keep meaningful content relationships rather than redirecting unrelated pages to the homepage. Record pages that are intentionally removed and their expected response. Review the map with content owners, because engineering cannot infer whether two superficially similar services answer the same user need.

Check the new site before release

Verify response status, titles, descriptions, headings, canonical URLs, indexability and internal links. For multilingual sites, confirm each language page and its alternate references point to real, appropriate versions. Remove accidental staging restrictions from the intended public pages while keeping private environments protected. Generate a sitemap containing canonical destinations. Test redirects for loops and unnecessary chains, including common variants of old URLs.

Prepare the cut-over checklist

Keep the URL map and configuration versioned so the released behaviour can be traced.
Test important old URLs against the deployed redirect rules, not only a spreadsheet.
Confirm analytics and search-verification arrangements continue to identify the correct property.
Assign owners for server errors, missing content, incorrect redirects and indexing observations after launch.

Monitor and repair with evidence

After release, inspect crawling and indexing signals, important landing pages and actual errors. Search visibility can fluctuate during processing; do not change several unrelated signals in panic. Investigate specific lost destinations, blocked pages or incorrect canonicals first. Keep redirects available for an appropriate long-term period according to current search guidance and user needs. A migration report should distinguish confirmed technical defects from expected processing uncertainty. Success means that valuable content remains accessible through consistent destinations, with the team able to explain and repair exceptions.

Frequently asked questions

Should every old page redirect to the homepage?

No. Use the closest relevant destination where one exists and handle genuinely removed content deliberately.

Can rankings be guaranteed after migration?

No. Technical preparation reduces avoidable problems but cannot guarantee search outcomes.

Do translated pages need separate checks?

Yes. Their canonicals, indexability, internal links and language alternatives must resolve consistently.

When should redirects be tested?

Before release with the intended rules and again against the deployed environment immediately after cut-over.

What should we investigate first after launch?

Broken important destinations, server errors, accidental noindex or blocking, incorrect canonicals and redirect failures.

Bring the scope. We will help make it buildable.

Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.

Explore the delivery scope →