Website Migration SEO Checklist: 32 Checks Before, During, and After Launch

A website migration usually starts with an optimistic sentence: we are only changing the domain, the CMS, the design, or the URL structure.

Then launch day arrives. The homepage works, everyone likes the new navigation, and the team celebrates. A week later, traffic is down. Old links lead through three redirects. Google is still finding staging canonicals. Product pages disappeared from the sitemap. A few important articles now return 404s because nobody remembered an old URL format from five years ago.

This is why migration SEO is not a final check performed after development. It is part of the migration itself.

The good news is that most migration problems are predictable. You do not need to guess what might go wrong. You need a record of the old site, a clear map to the new one, and enough time to test both sides of the move.

This checklist covers 32 practical checks before, during, and after launch. It is written for SEOs, developers, marketers, founders, and anyone who has suddenly become responsible for making sure a new website does not erase years of search visibility.

What counts as a website migration?

A migration is any substantial website change that can affect how users or search engines reach, crawl, understand, or index your pages.

Common examples include:

• Moving to a new domain or subdomain.
• Changing from HTTP to HTTPS.
• Replacing a CMS or ecommerce platform.
• Redesigning the site and changing templates or navigation.
• Changing URL folders, slugs, or language structure.
• Merging two websites.
• Splitting one website into several properties.
• Moving from client-side rendering to server rendering, or the other way around.
• Removing, combining, or reorganizing a large amount of content.

Not every migration needs the same level of work. A hosting change with identical URLs is different from a domain move plus a redesign plus a new CMS. The larger the change, the more important it becomes to separate the work into understandable pieces.

If possible, avoid changing the domain, platform, design, information architecture, and content strategy in one release. When everything changes at once, even a good team can struggle to explain why traffic moved.

Before migration: decide what is actually changing

The first four checks sound basic. They are also where many migrations quietly lose control.

• Define the exact scope. Write down what will change and what must remain stable.
• Choose one owner for the URL map, even if several people contribute to it.
• Separate required changes from nice-to-have redesign ideas.
• Create a rollback plan with a clear decision point for using it.

The rollback plan does not need to be dramatic. It needs to answer practical questions. Can the previous deployment be restored? Will the old redirect configuration still be available? Who can make that call? How long will analytics, logs, and the old crawl remain accessible?

A migration without a rollback plan forces the team to improvise while traffic is already affected.

Record the site before you touch it

You cannot compare the old site with the new site if the old site has already disappeared.

Before development or launch, save a useful baseline:

• Crawl the current website and export every discovered indexable URL.
• Export the current XML sitemaps.
• Save top landing pages, clicks, impressions, and queries from Search Console.
• Save traffic, conversions, and revenue by landing page from analytics.
• Record important backlinks and the old URLs receiving them.
• Capture current titles, descriptions, canonicals, headings, status codes, hreflang, and structured data.
• Benchmark representative templates for LCP, INP, CLS, and general page weight.

Do not save only the top ten pages. High-traffic pages deserve special attention, but long-tail pages often carry years of links, topical coverage, and conversions that are easy to miss in a short report.

Use more than one source when building the inventory. The sitemap shows URLs the site wants search engines to find. Analytics shows URLs people actually visit. Search Console shows URLs Google has used in search. Server logs can reveal old paths that still receive crawler or user traffic. A site crawl shows what the current internal architecture exposes.

None of those lists is complete on its own.

Build the old-to-new URL map

The URL map is the heart of a migration. It is not just a developer spreadsheet full of redirect rules. It is the written decision about what happens to every existing page.

At minimum, the map should contain:

• The old URL.
• The planned new URL.
• The action: keep, redirect, consolidate, or remove.
• The expected final status code.
• The page type or template.
• Organic traffic or business priority.
• Notes about canonicals, hreflang, backlinks, or special behavior.
• The person responsible for approving the decision.

Map pages to their closest useful equivalent. An old product page should go to the corresponding new product page, not automatically to the homepage. An article that has been merged into a stronger guide can redirect to that guide. A page with no replacement and no useful value may correctly return 404 or 410.

Redirecting hundreds of unrelated URLs to the homepage does not preserve their meaning. It creates a confusing experience for users and may be treated as a soft 404 by search engines.

Protect the pages that already work

Migration planning often focuses on removing old clutter. That is useful, but it can make teams underestimate ordinary pages that quietly perform well.

Mark the pages that must receive an individual review:

• Pages with organic clicks or impressions.
• Pages with conversions, leads, or revenue.
• Pages with valuable external links.
• Pages that rank for important branded or non-branded queries.
• Product, pricing, contact, support, and location pages.
• Evergreen guides that support a larger topic cluster.
• Images, PDFs, videos, or other assets that receive search traffic or links.

For each priority page, confirm that the new version still answers the same intent. A technically perfect redirect cannot compensate for replacing a detailed guide with a thin marketing paragraph.

Preserve useful content, not merely the old keyword. Keep the proof, examples, product details, author information, comparison points, and supporting sections that made the page valuable in the first place.

Prepare the new site without exposing the wrong version

Staging needs to be testable by the team without becoming a public duplicate of the current website.

Use proper access control when possible. A password-protected staging environment is safer than relying only on `noindex`, because links and configuration mistakes can expose preview URLs unexpectedly.

At the same time, do not let staging protection hide production problems. Before launch, create a specific removal checklist for anything that must not survive deployment:

• Staging `noindex` directives.
• Site-wide `Disallow` rules.
• Preview-domain canonicals.
• Test hreflang URLs.
• Placeholder analytics IDs.
• Development API endpoints or asset hosts.
• Temporary redirects used during QA.

One person should own this list on launch day. "Everyone knows about it" is how a production site ends up blocked for a weekend.

Test the new site as a website, not a collection of screenshots

A migration review needs more than visual approval. The page can look correct while the signals behind it point somewhere else.

Test representative URLs from every important template: homepage, category, product, article, author, location, pagination, search, filtered pages, account areas, and error pages.

For each template, check:

• The final URL and HTTP status.
• Title, description, H1, and heading structure.
• Self-referencing canonical on the preferred new URL.
• Robots meta and X-Robots-Tag headers.
• Rendered content, links, and structured data.
• Mobile viewport and main interactions.
• Images, alt text, and asset URLs.
• Open Graph and social preview data.
• PageSpeed and browser-observed performance.

If the new site uses more JavaScript than the old one, inspect the rendered page, not only the initial source. Make sure important copy, internal links, canonicals, metadata, and schema exist when the page is actually processed.

Update internal links before redirects do the work

Redirects protect old paths. They should not become the new internal linking system.

Update navigation, breadcrumbs, footer links, related content, product recommendations, image links, language selectors, pagination, and links inside the main content so they point directly to final URLs.

This matters for three reasons:

• Users avoid unnecessary delay.
• Crawlers reach the final page with less work.
• The site sends one consistent signal about which URLs are preferred.

Check links hidden in templates and reusable components. A manual review of five pages may miss an old domain embedded in every footer, canonical helper, email template, or structured data block.

After updating the obvious links, run a same-site crawl and search specifically for the old hostname and old path patterns.

Align canonicals, hreflang, schema, and sitemaps

Redirects are only one part of the move. The new site should agree with itself everywhere.

Every indexable new page should normally use a self-referencing canonical on its final preferred URL. Update canonical helpers at the template level and inspect the rendered result. Watch for old domains, preview hosts, HTTP URLs, incorrect trailing slashes, and canonicals that point through another redirect.

For multilingual sites, update every hreflang reference to the new URLs. Confirm that reciprocal annotations still connect equivalent pages and that `x-default` still points to the intended fallback.

Structured data should describe the new visible page and use current entity URLs. Check `url`, `@id`, breadcrumbs, images, authors, products, offers, organizations, and WebSite references. A migration can leave schema perfectly valid but connected to the old domain.

Generate a clean sitemap containing the canonical new URLs you want indexed. Do not fill it with redirects, blocked pages, old hostnames, non-canonical variants, or URLs returning errors.

Plan redirects before launch day

For a permanent move, use server-side permanent redirects such as 301 or 308 when technically possible. They are clear to browsers, users, and search engines.

Generate redirect rules from the approved URL map, then test them before they receive real traffic.

A good redirect test checks more than whether the browser eventually loads something:

• The old URL returns the intended permanent redirect.
• The redirect goes directly to the final destination.
• The destination returns 200.
• The destination is indexable.
• The destination canonical points to itself.
• Query parameters are preserved or removed intentionally.
• HTTP, HTTPS, www, non-www, uppercase, and trailing-slash variants behave consistently.
• There are no loops or chains through historical URL versions.

Avoid routing an old URL through the last two redesigns before it reaches the current page. Update the original rule so it points directly to the final destination.

Keep permanent redirects for at least a year. For URLs that still receive meaningful links or visits, keeping them indefinitely can be better for users. Meanwhile, update internal links and important external profiles so they no longer depend on the redirect.

Launch day: change carefully and verify immediately

Choose a lower-traffic period when possible, but make sure the people who can fix the deployment are available. A quiet Sunday launch is not safer if the developer, SEO, and infrastructure owner are all offline.

During deployment, verify these launch-critical checks first:

• Redirects are active for old URLs.
• Production is not blocked by robots.txt or `noindex`.
• New pages return the intended status codes.
• Canonicals and hreflang use production URLs.
• The new sitemap is live and references only new canonical URLs.
• robots.txt is accessible and references the correct sitemap.
• Analytics, conversion tracking, consent, and Search Console verification still work.
• Critical user journeys work on desktop and mobile.
• The server can handle users plus increased crawler activity.

Do not spend the first hour polishing minor metadata while all product URLs redirect to the homepage. Work in priority order: access, status, redirects, indexability, canonicalization, discovery, content, then refinements.

For a domain move, verify both old and new properties in Search Console and use the Change of Address tool where appropriate. An HTTP-to-HTTPS move does not use the Change of Address tool, but both versions should still be verified and monitored.

Run a post-migration crawl

As soon as the new site is stable, crawl it again. This crawl answers a different question from the staging audit: what did the real deployment actually produce?

Compare the post-launch crawl with the saved baseline and URL map. Look for:

• Old URLs that do not redirect.
• New URLs returning 4xx or 5xx responses.
• Redirect chains and loops.
• Pages that lost their title, H1, description, canonical, or schema.
• Internal links still pointing to old URLs.
• Orphan pages and unexpected crawl-depth changes.
• Blocked or non-indexable priority pages.
• Duplicate titles, descriptions, and canonicals created by the new templates.
• Sitemap URLs that redirect or return errors.
• Assets still loading from staging or the old domain.

Do not review only the error count. Compare patterns by template. Twenty broken URLs caused by one shared component are usually one fix. One broken pricing page may be a more urgent business problem than all twenty.

Monitor what search engines and users are doing

A migration is processed URL by URL. Search visibility can fluctuate while search engines recrawl the old pages, follow redirects, discover the new URLs, and update their indexes.

Monitor both the old and new properties. You want to see activity move in the right direction: old URLs receive less search traffic while the corresponding new URLs begin receiving impressions and clicks.

Watch for:

• Unexpected drops by page group, country, device, or query type.
• A rise in not found, server, redirect, or blocked errors.
• New URLs discovered but not indexed.
• Google-selected canonicals that differ from your declared canonicals.
• Important old URLs still appearing without the intended replacement.
• Large differences between analytics traffic and Search Console clicks.
• Conversion or revenue changes even when organic traffic looks stable.

Inspect a sample of the most important pages in Search Console rather than requesting indexing for every URL repeatedly. For a large set of URLs, submit the new sitemap and let the normal crawl process work.

Small and medium sites may take a few weeks for most URLs to settle. Larger migrations can take longer. Patience is reasonable only when the technical signals are correct. If a key section is blocked, returning errors, or canonicalized elsewhere, waiting is not a strategy.

Review the migration after 7, 14, and 30 days

Launch day catches immediate failures. Scheduled reviews catch slow problems.

At each review, compare the same groups of pages against the pre-migration baseline. Look at traffic, clicks, impressions, conversions, indexed pages, crawl errors, server logs, and site crawl results.

Use the URL map as a working document. Mark redirects as verified, record exceptions, add missed legacy URLs, and keep owners attached to unresolved issues.

The 30-day review should answer:

• Did priority pages move to their intended URLs?
• Are old URLs losing visibility as new URLs gain it?
• Have important queries and conversions recovered or improved?
• Are redirects direct and still active?
• Is the new site easier to crawl than the old one?
• Did the migration create duplicate or orphaned content?
• Which problems belong to the migration, and which are normal product or content work?

Do not delete the redirect map or old crawl when the graph looks normal again. They are useful evidence for future debugging and the next migration.

A practical Crowra migration workflow

Crowra is most useful at the page and same-site review layer of a migration.

Before the move, scan representative pages from every important template and save the results as a local baseline. Export crawl data, links, metadata, headings, canonicals, hreflang, schema, and issues while the old site is still available.

On staging, review the same page types for technical indexability, rendered metadata, structured data, internal links, accessibility, PageSpeed, and AI-readiness signals. Export the findings as a fix plan so launch blockers have an owner.

After deployment, scan the final production pages again and compare them with the saved baseline. Use the same-site crawl to find broken links, redirects, old hostname references, duplicate metadata, orphan-page hints, and unexpected crawl paths.

Crowra does not know Google's selected canonical, the last Googlebot crawl, or the actual index status of a URL. Those values still require the verified Search Console property. It also does not replace server log analysis or a large enterprise crawler. Its role is to make the live-page inspection, evidence gathering, prioritization, and handoff faster while the migration is moving.

The complete 32-point website migration SEO checklist

Before migration:

1. Define exactly what will change.
2. Assign one owner to the URL map.
3. Separate required migration work from optional redesign work.
4. Prepare a tested rollback plan.
5. Crawl and export the current website.
6. Save current sitemaps and important legacy URL lists.
7. Export Search Console, analytics, conversion, and backlink baselines.
8. Identify priority pages, templates, and assets.
9. Build an old-to-new URL map.
10. Choose a relevant destination or intentional removal for every old URL.
11. Protect staging with access control and document temporary blocks.
12. Test every important template on staging.
13. Update internal links to final new URLs.
14. Update canonicals, hreflang, schema entity URLs, and breadcrumbs.
15. Generate a clean sitemap of new canonical URLs.
16. Build and test direct permanent redirect rules.

During launch:

1. Launch when the people who can fix problems are available.
2. Activate old-to-new redirects.
3. Confirm that redirects go directly to valid final pages.
4. Remove staging `noindex` and crawl blocks from public pages.
5. Verify production status codes and indexability.
6. Verify production canonicals and hreflang.
7. Publish the new sitemap and correct robots.txt reference.
8. Confirm analytics, conversions, consent, and Search Console verification.
9. Test critical navigation, forms, checkout, login, and mobile journeys.
10. Verify that the server can handle increased crawler and user traffic.

After launch:

1. Crawl the production site and compare it with the baseline.
2. Inspect priority URLs in Search Console.
3. Submit the new sitemap and Change of Address when appropriate.
4. Monitor errors, indexing, traffic, queries, and conversions on both sites.
5. Review the migration after 7, 14, and 30 days.
6. Keep redirects for at least one year and preserve the migration records.

A successful website migration is rarely invisible. Some ranking movement and a few unexpected URLs are normal. What matters is whether the team can explain what changed, detect a real problem quickly, and trace every important old page to a sensible new outcome.

The safest migrations are not the ones with the biggest spreadsheet or the most tools. They are the ones where the old site was recorded, the decisions were made before launch, and every signal on the new site tells the same story.