The Website Migration Checklist: Before, During, and After Launch

In short

A safe website migration inventories every current URL and search signal, maps each page to a deliberate outcome, tests the new site and redirects before launch, verifies production controls immediately after deployment, and monitors indexing, traffic, errors, performance, and conversions until the system stabilises.

Define the migration

Record every major change: domain, protocol, URL paths, CMS, rendering, hosting, navigation, content, languages, analytics, and integrations. Where practical, avoid changing all layers at once.

Before build

[ ] Export URLs from sitemap, crawl, CMS, analytics, Search Console, backlinks, and campaigns.
[ ] Record traffic, impressions, conversions, links, status, canonical, title, and internal-link count.
[ ] Assign keep, improve, merge, redirect, or remove to every URL.
[ ] Capture current robots rules, sitemaps, structured data, hreflang, and response headers.
[ ] Benchmark Core Web Vitals and important journeys.
[ ] Document integrations, forms, analytics events, consent, and account ownership.

During content and architecture

[ ] Map one primary intent to one best page.
[ ] Preserve useful content and evidence on high-value URLs.
[ ] Identify pages with backlinks or campaign dependencies.
[ ] Build a one-to-one redirect map.
[ ] Keep stable URLs when change creates no value.
[ ] Plan navigation, breadcrumbs, and contextual internal links.
[ ] Define canonical, indexation, and localization rules.

On staging

[ ] Protect staging with authentication; do not rely on robots.txt for privacy.
[ ] Crawl the rendered site.
[ ] Confirm indexable pages return 200.
[ ] Check titles, headings, descriptions, canonicals, and robots directives.
[ ] Validate structured data against visible content.
[ ] Test hreflang and regional URLs where applicable.
[ ] Check image dimensions, alt text, formats, and lazy loading.
[ ] Verify forms, search, login, checkout, and integration failures.
[ ] Test keyboard, focus, errors, contrast, zoom, and responsive states.
[ ] Compare template performance with the baseline.
[ ] Verify analytics and consent in the production configuration.

Redirect rules

use server-side 301 or 308 redirects for permanent moves;
point old URLs directly to the closest relevant new URL;
avoid chains and loops;
do not send unrelated removed pages to the homepage;
update internal links to final destinations;
retain meaningful query parameters where required;
test every mapping and prioritise valuable URLs manually;
keep redirects long term.

Google's site-move guidance recommends preparing a URL map and permanent redirects before starting a move.

Launch preparation

[ ] Choose a period with technical, content, and decision owners available.
[ ] Back up the current system and test the recovery path.
[ ] Lower DNS TTL in advance if the migration requires it.
[ ] Prepare final redirects, sitemap, robots rules, and canonicals.
[ ] Confirm production domains in analytics, consent, forms, email, payments, and integrations.
[ ] Prepare a production smoke-test list.
[ ] Define rollback criteria and authority.
[ ] Keep the old crawl, URL map, and baseline accessible.

Immediately after deployment

[ ] Verify homepage and representative templates.
[ ] Check production robots, noindex, canonicals, and status codes.
[ ] Crawl production.
[ ] Run the redirect test set.
[ ] Test top organic landing pages and backlinks.
[ ] Submit the final XML sitemap in Search Console.
[ ] Verify analytics events and conversions.
[ ] Test forms, transactions, authentication, and email delivery.
[ ] Inspect server errors, logs, monitoring, and queues.
[ ] Confirm staging remains protected.

The first weeks

Monitor by page type and query group:

clicks and impressions;
indexed and excluded pages;
404, 410, 5xx, redirect chains, and soft 404s;
sitemap processing;
selected canonicals;
Core Web Vitals;
conversions and form delivery;
integration errors;
crawl behaviour where logs are available.

Compare season, device, country, and day of week. Site-wide averages can hide a serious loss in one valuable template.

Diagnose declines in order

Response status and redirect.
Robots and indexability.
Canonical and sitemap.
Rendered content and links.
Intent, title, and lost sections.
Internal-link changes.
Structured data and hreflang.
Performance and errors.
External demand and competition.

Do not rewrite content before confirming Google can reach and index the correct page.

Sources

Common questions

How long does a website migration take to settle?

Small changes may stabilise quickly; large domain or URL moves can take weeks or longer as search engines recrawl old and new pages. Correct signals and crawl frequency affect timing.

Should every old URL redirect?

Every valuable or used URL needs an outcome. Redirect only to a genuinely relevant replacement; intentionally removed content can return 404 or 410.

How long should redirects remain?

Keep them for at least a year and preferably indefinitely when old links, bookmarks, or campaigns may still send visitors.

Should the old sitemap stay live?

During a significant URL move, an old-URL sitemap can help monitoring and discovery temporarily, while the primary new sitemap contains canonical 200-status URLs. Follow the migration plan appropriate to the platform.

Is traffic fluctuation normal after migration?

Some fluctuation is normal. Large or persistent losses require page-level diagnosis against the baseline rather than waiting without evidence.

website migrationtechnical SEOredirectswebsite redesign