Website Migration SEO Checklist: Before, During and After Launch

The short answer

A safe website migration preserves the pages, signals and user journeys that already work while improving the system underneath. The work begins before development and continues after launch.

At minimum:

1. export the current site;
2. identify important URLs and queries;
3. map old URLs to new equivalents;
4. crawl and test staging;
5. launch with redirects, canonicals, analytics and sitemaps ready;
6. monitor indexing, traffic, errors and conversions.

This checklist covers redesigns, CMS changes, framework changes, domain moves, HTTPS changes, mergers and URL restructuring. The risk is higher when several happen at once.

First: define what is changing

Document the migration type.

• Design migration: same URLs and CMS, new front end.
• CMS migration: WordPress to Webflow, Shopify, Next.js or another platform.
• Domain migration: one domain to another.
• Protocol or hostname: HTTP to HTTPS, www to non-www, or subdomain changes.
• URL migration: folders, slugs or information architecture change.
• Content migration: pages are merged, rewritten, removed or split.
• Business merger: several sites move into one.

The more layers change together, the harder it is to diagnose a loss. If possible, avoid changing domain, CMS, design, content and URL structure in one release.

Set the baseline before touching staging

A migration cannot preserve performance if nobody records the starting point.

Export:

• Search Console clicks, impressions, CTR and position by page and query;
• Analytics landing pages, conversions and revenue;
• all crawlable URLs;
• indexed URL samples;
• title, meta description, canonical, robots directives and status code;
• H1 and primary content;
• internal inlinks and anchor text;
• XML sitemap URLs;
• backlinks and their destination URLs;
• top image and file URLs;
• page templates and structured data;
• server logs where available.

Choose a comparison window that accounts for seasonality. Store the export, the date and the filters. A screenshot of the dashboard is not enough.

Build a complete URL inventory

Combine several sources because no single export is complete:

• crawler output;
• XML sitemaps;
• Search Console pages;
• Analytics landing pages;
• CMS database or route manifest;
• backlink destination report;
• server logs;
• paid campaign landing pages;
• URLs shared in email, apps, QR codes or offline materials.

Classify each URL:

• keep unchanged;
• move to equivalent;
• merge into a stronger page;
• remove with 410 or 404;
• retain temporarily;
• investigate.

Do not delete a page only because it has no recent sessions. It may hold backlinks, rank seasonally or support a conversion path.

Create the redirect map

Every moved URL gets a specific destination.

Rules:

• use server-side 301 redirects;
• keep one hop from old to final;
• avoid redirect chains and loops;
• do not send every removed page to the homepage;
• preserve query parameters only when needed;
• include protocol, hostname, case and trailing-slash variants;
• keep redirects for the long term;
• test the entire map before launch.

A redirect map is not just an SEO file. It protects bookmarks, emails, paid campaigns and customer links.

Protect staging

A staging site should be inaccessible to search engines without making it impossible to test. Prefer authentication or network restrictions. A robots.txt block alone does not prevent indexing when links expose the URL, and it can stop crawlers from seeing a noindex directive.

Check staging for:

• authentication;
• noindex as a second safeguard where appropriate;
• no production analytics contamination;
• no staging canonicals pointing to staging after launch;
• no email or payment actions firing accidentally;
• realistic production rendering and data.

Before launch, remove the staging restrictions from production. A forgotten noindex can erase the site faster than a redirect error.

Crawl staging like a search engine and like a user

Technical checks

• 200 status on intended pages;
• one canonical indexable URL per page;
• self-referencing canonicals unless consolidation is intentional;
• robots meta and X-Robots-Tag;
• crawlable internal links;
• valid XML sitemap;
• no orphan pages;
• no mixed content;
• correct language and hreflang;
• working structured data;
• sensible response and render times.

Content parity

Compare the important old and new pages for:

• title and description;
• H1 and primary headings;
• body copy and tables;
• images and alt text;
• FAQs;
• product specifications and prices;
• contact and local information;
• reviews and legal copy;
• downloadable files;
• internal links;
• CTA and conversion fields.

A new design can look cleaner while silently removing the text that made the old page useful.

User journeys

Test on desktop and mobile:

• navigation;
• forms;
• checkout;
• account flows;
• search;
• filters;
• multilingual switching;
• downloads;
• phone, email and WhatsApp links;
• error pages.

Preserve internal-link equity

Update internal links to point directly at the final URLs. Do not rely on redirects inside your own site.

Check:

• navigation and footer;
• breadcrumbs;
• article links;
• product recommendations;
• image links;
• canonical and hreflang URLs;
• structured-data URLs;
• sitemap;
• JavaScript route references;
• PDFs and downloads where practical.

Use descriptive anchor text and keep related pages connected.

Analytics and conversion tracking

Before launch, confirm:

• GA4 tag and property;
• consent management;
• form, call, checkout and lead events;
• advertising pixels;
• cross-domain tracking;
• referral exclusions;
• ecommerce events and values;
• Search Console property access;
• CRM or lead-source fields.

Run test transactions and enquiries. A migration that preserves rankings but breaks lead tracking creates a false performance drop. A migration that breaks checkout creates a real one.

Launch-day order

1. Freeze content and code changes.
2. Take final database and file backup.
3. Capture a final crawl and analytics baseline.
4. Deploy the production build.
5. Enable the redirect map.
6. Remove production noindex or authentication.
7. Confirm robots.txt and canonicals.
8. Test key old URLs and page templates.
9. Test forms, checkout and tracking.
10. Publish the new XML sitemap.
11. Verify the property in Search Console.
12. Inspect priority URLs and request recrawl where appropriate.
13. Watch logs and monitoring.

Do not leave DNS, redirect logic and code release ownership ambiguous. Name the person responsible for each step and the rollback decision.

First 24 hours

Check:

• homepage and priority URLs return 200;
• representative old URLs 301 once to the correct pages;
• no site-wide 404, 5xx or redirect loops;
• production is indexable;
• analytics receives real-time events;
• conversions work;
• sitemap is reachable;
• Search Console has no obvious property or robots problem;
• CDN and caches serve the correct canonical host.

Keep a launch log with issue, owner, status and resolution.

First two weeks

Review daily at first, then every few days:

• Search Console indexing and crawl issues;
• clicks and impressions by page/query group;
• server 404 and 5xx logs;
• redirect hits and missing map entries;
• Analytics sessions and conversions;
• important keyword/page trends;
• Core Web Vitals and field errors;
• structured-data errors;
• backlink destinations still hitting old URLs.

Do not panic over one day of fluctuation. Search recrawling can take days or weeks. Fix technical defects immediately; judge ranking and demand changes over a longer comparable period.

First 30 to 90 days

• compare migrated page groups with the baseline;
• check whether lost queries map to changed or missing content;
• keep redirects live;
• recover valuable 404s;
• update external links when a high-value partner is willing;
• improve weak new pages rather than restoring everything blindly;
• monitor leads, revenue and conversion rate;
• document lessons for the next migration.

If several changes launched at once, use careful language. Performance moved after the migration. That does not isolate design, metadata, redirects or content as the cause.

Platform-specific risks

WordPress to Next.js

• route and trailing-slash changes;
• server versus client rendering;
• image and media URL loss;
• plugin-generated schema, canonicals or sitemaps disappearing;
• pagination and category archives;
• form replacement;
• cache and CDN behavior.

Shopify or ecommerce replatforming

• product and collection URL changes;
• variants and Product schema;
• discontinued products;
• filters and faceted navigation;
• review migration;
• ecommerce analytics;
• checkout-domain tracking.

Domain move

• verify both domains in Search Console;
• redirect every old URL;
• update canonicals, sitemap, internal links and key profiles;
• use Google's Change of Address tool where applicable;
• keep the old domain and redirects for the long term.

Migration QA table

Sources

• Google: Site moves with URL changes
• Google: Ask Google to recrawl URLs
• Google: Debugging Search traffic changes
• Semrush website migration checklist
• Screaming Frog migration guide

Frequently asked questions

How long do rankings take to recover after a migration?

There is no fixed period. Google may take days or weeks to recrawl changed URLs, and larger moves can take longer. Monitor affected pages, queries and conversions over a comparable period.

Should every old URL redirect to the homepage?

No. Redirect to the closest useful equivalent. When no equivalent exists, a proper 404 or 410 is clearer than a misleading homepage redirect.

How long should 301 redirects stay live?

Keep important migration redirects for the long term. Old links, bookmarks and crawlers can continue using them well after launch.

Does changing metadata preserve rankings?

Metadata helps describe a page, but a safe migration also preserves content, URLs, internal links, canonicals, structured data, tracking and user journeys. Metadata alone is not a migration plan.

Can a migration improve SEO?

Yes, when it fixes architecture, speed, content and usability problems. But preserve the existing value first and avoid claiming improvement from one change when several launched together.