Website migration SEO checklist: a testable cutover method

Choose the migration model and version the release

First classify what is changing. Google separates moves that change visible URLs—such as a domain, protocol or path change—from hosting changes that keep the public URLs unchanged. A redesign can contain both: page paths may be replaced while the canonical hostname also moves to new infrastructure. Write those changes separately so URL mapping, redirect, DNS and rollback work do not become one ambiguous launch task.[1][2]

Create a versioned release manifest before implementation. Record the current canonical host, every known URL, the intended destination or removal decision, important media, internal links, Search Console ownership, sitemap state, analytics baseline and the evidence required to accept the move. Google recommends preparing and testing the new site, mapping old URLs, retaining verification and monitoring both sides; Search Console access supplies crawl and indexing evidence but does not replace a complete business-owned inventory.[1][6]

Blancc's dated build evidence is a protected preview gate recorded on 16 August 2026. That snapshot covered exactly 42 canonical pages: 13 core, tool, trust and support routes; seven service routes; and 22 insight routes. The snapshot predates this guide, so future release manifests must use their new exact totals. The production Webflow replacement, DNS cutover and post-launch search outcome are not complete; this is build-method evidence, not a client result, ranking result or migration success claim.

• Name every change to domain, protocol, path, hosting, CMS, content, design and analytics[1][2]
• Assign a release version, freeze time, owner, source inventory and approved destination map
• Capture a pre-move crawl, Search Console exports, server or platform data and representative screenshots[1][6]
• Separate automated pass conditions from owner approval, legal review and operational acceptance
• Keep the protected preview non-indexable until an authorised production cutover passes its own gate

Build the old-to-new URL and continuity map

Start with more than the current navigation. Google recommends using submitted sitemaps, server logs or analytics, Search Console link information, the content management system and recently visited URLs to find important pages. Include images, video, JavaScript, CSS and downloadable documents where their locations or incoming links matter. Reconcile those sources into one inventory instead of assuming a crawl can discover every orphaned, parameterised or externally linked URL.[1][5][6]

Give each retained old URL one direct, relevant destination. Consolidated pages can share a destination when the new page genuinely replaces them, but unrelated URLs should not be redirected to the home page. Content that is deliberately removed without a replacement should return a real 404 or 410. Record the expected status, final URL, canonical, query treatment and content owner beside every mapping so the implementation can be tested mechanically.[1][3]

Blancc's dated map keeps the existing home URL in place, preserves `/stockr` as a dedicated privacy-and-support page, normalises `/index.html`, and sends six named legacy paths to relevant new destinations. It also requires the HTTP, apex and `www` variants to preserve path and query data when they move to the canonical HTTPS host. Query preservation and the Stockr content markers are explicit Blancc continuity controls; they are not presented as universal Google requirements.

• Merge sitemap, crawl, CMS, logs, analytics, Search Console, backlink and campaign inventories[1][5][6]
• Include media, downloads, scripts and styles when their URLs carry traffic, links or functional dependencies[1]
• Map every retained URL to its closest replacement and document intentional 404 or 410 decisions[1][3]
• Test status, Location, final response, canonical, query handling and content continuity from the frozen map
• Keep product, policy, support and conversion paths distinct from generic marketing destinations

Align canonicals, sitemaps, robots and preview policy

Each new HTML page should declare the intended absolute canonical URL, while internal links and annotations should use the new URL rather than relying on redirects. The production sitemap should contain the preferred canonical URLs only. Google treats redirects and `rel=canonical` as strong canonical signals and sitemap inclusion as a weaker signal, so those surfaces should agree instead of asking its systems to reconcile contradictory destinations.[1][4][5]

Do not use robots.txt to select a canonical, and do not list one URL in the sitemap while declaring another as canonical for the same page. Validate the exact host, protocol, path and trailing-slash policy across rendered HTML, HTTP headers, sitemap entries and internal links. A sitemap assists discovery and communicates preferred URLs, but it does not guarantee indexing or override conflicting page signals.[4][5]

A private or disposable preview needs an explicit indexing boundary. Blancc's protected preview returns response-level `noindex, nofollow, noarchive` while its staged pages, sitemap and feed can be checked against the intended production canonical origin. Google says temporary crawl or index blocks used during development must be removed when the move begins. For Blancc, production noindex removal is therefore a cutover action gated with the canonical origin and redirect configuration—not a preview milestone.[1][2]

• Use one absolute self-canonical for each indexable production page[1][4]
• Link internally to final URLs and keep canonical, redirect and sitemap destinations consistent[1][4]
• Publish canonical URLs only in the production sitemap and use accurate modification dates[4][5]
• Keep preview noindex controls observable at the response layer and test them on non-HTML endpoints too
• Remove temporary production crawl or index blocks only inside the approved launch sequence[1][2]

Make redirects and DNS cutover testable

Use server-side permanent redirects when an old URL has permanently moved. Google recommends HTTP 301 or 308 where possible and advises sending each source directly to its final destination instead of creating chains. Test with redirects disabled and enabled, follow no redirects during the first assertion, compare the exact Location header, then request the destination separately. That exposes accidental temporary statuses, loops, extra hops and broken targets.[1][3]

Blancc's release configuration requires an explicit production-redirect opt-in. The staged preview can render production canonicals while redirects remain off; at cutover, an invalid, disposable or mismatched production canonical configuration returns a non-indexable 503 instead of serving an ambiguous release. The redirect gate also checks six named legacy routes in one hop with their test query preserved. These are Blancc engineering controls, not requirements imposed by Google.

Treat DNS authority, DNS answers and web-origin readiness as separate states. Google's hosting-move guidance recommends preparing the new infrastructure, reviewing Search Console verification, lowering DNS TTL in advance where appropriate, removing temporary crawl blocks at launch, updating DNS and monitoring old and new server logs plus public DNS propagation. Blancc additionally protects mail, verification, security records and real mailbox delivery during a zone move. Those operational checks protect the business; this guide does not describe them as ranking factors.[2]

• Prefer direct server-side 301 or 308 responses for URLs that have permanently moved[1][3]
• Assert the first response manually, then assert that the declared destination returns the intended 200 page
• Enable production redirects only with the approved canonical origin and a retained rollback target
• Compare a complete owner-approved DNS export through independent resolvers before accepting authority changes[2]
• Test website, Stockr, mailbox, verification and certificate continuity as separate operational paths

Use a fail-closed launch gate with human evidence

A migration checklist becomes a release control only when each condition has an owner, an observable pass result and a response to failure. Blancc's gate stops on missing routes, malformed discovery files, incorrect canonicals, broken redirects, DNS drift or critical continuity failures. Automation covers deterministic assertions; a human still has to approve destinations, content truth, legal disclosures, mailbox operation and the decision to replace production.

The table records the Blancc method used for the 42-route protected-preview snapshot and its planned production preflight. It is not a checklist published by Google, a certification, or proof that the production cutover has occurred. Every new release must update the expected totals and evidence rather than weakening an assertion to make an outdated manifest pass.

Monitor the move, retain redirects and state the limits

After cutover, monitor the old and new properties rather than waiting for a ranking report. Google recommends Search Console, sitemap and indexing reports, server access and error logs, crawl errors, queries, impressions, clicks and user traffic. Keep permanent redirects for as long as possible and generally at least one year. Search Console needs verified ownership and can surface discovery or indexing problems, but it cannot decide whether a form, policy or commercial hand-off works.[1][6]

Blancc's planned operating cadence is daily review during the first week and weekly review for at least eight weeks. The review set includes crawl and server errors, indexed pages, unexpected canonicals, redirect hits, old-host traffic, priority landing pages, branded queries, enquiries, Stockr continuity and mailbox delivery. That cadence is a Blancc risk-control choice, not a timeline promised by Google or evidence that every migration should use the same schedule.

Expect uncertainty. Google says ranking visibility may fluctuate temporarily and that processing speed depends on the number of URLs, server speed and recrawling; there is no fixed crawl frequency or guaranteed completion date. Blancc's protected preview proves only that the tested build satisfied its declared pre-launch assertions at that time. Production cutover, indexing, rankings, qualified enquiries and revenue remain unproven, and this guide guarantees none of them.[1]

• Verify old and new properties, submit the production sitemap and inspect representative URLs[1][6]
• Watch sitemap processing, indexing, crawl errors, server logs, redirect hits and old-versus-new traffic[1][6]
• Keep permanent redirects for at least one year and longer when they continue to serve users or external links[1]
• Review daily for the first week and weekly for eight weeks as Blancc's documented operating cadence
• Record every incident, decision, correction and rollback against the release version
• Do not treat a clean preview, a submitted sitemap or a temporary traffic movement as a ranking guarantee