A redesign can pass visual QA and still erase the pages search engines already trust.

Where the handoff breaks

Four people each hold part of the answer, and nobody owns the register that carries it through launch.

• The strategist knows why a page exists.
• The designer knows what the new experience should communicate.
• The developer knows where the new component lives.
• The search specialist knows which URLs and facts already have value.

Each is doing their job. The information that dies is the information that lives between them, and it usually dies quietly, showing up six weeks later as a traffic decline nobody can explain.

We built this register out of a pre-launch engagement with a branding agency, where the site was strong and the search layer had not been built yet.

What is actually new

Redirect maps, canonicals, staging controls and XML sitemaps are not new, and good migration guides already cover them. They remain essential. Skip none of it.

What changed in 2026 is that a page can now also own things a 2019 checklist never mentioned:

• Google AI Overviews and AI Mode impressions, which since 31 August 2026 are reported in Search Console's Generative AI performance report, assigned to canonical URLs.
• Citations in Bing's AI experiences, reported since February 2026 with page-level citation activity and sampled grounding queries.
• Facts supporting an organisation, service, location or case-study claim that an answer system currently relies on.
• Third-party corroboration pointing at the old brand name or old URL.

One row per old URL

For every indexable or historically important old URL, record:

"Unavailable" is a valid baseline value. Zero is not. If the generative report has not populated for the property, or nobody has Bing access, write unavailable. Recording a zero for data the platform never exposed creates a fake improvement the moment access is granted later.

Keep the intent, not the copy

Search preservation does not mean pasting old paragraphs into a new design. It means knowing the job a page already does before deciding what to cut.

Write one primary intent per page in plain language: understand a service, compare capability, verify relevant experience, confirm location, evaluate a case study, make contact. Then preserve the minimum evidence that fulfils it.

A visually strong case-study page often still needs a publishable client or sector name, the brief, the actual scope of work, enough context to distinguish it from decoration, a link to the relevant service, an accurate title and H1, and crawlable text around the images.

Do not invent confidential results to make a case study look weightier. Specific verifiable context beats an unsupported performance number, and it survives a prospect asking how you know.

Entity facts through a rebrand

A rebrand changes more than colours. It can change the trading name, the domain, address formatting, service labels, leadership descriptions and profile URLs. Record what must stay consistent:

• Legal and trading name.
• Location and service area.
• Primary services, in the words the business actually uses.
• Founder or leadership names where public.
• Public contact details.
• Case-study relationships, awards, memberships and directory listings.
• Same-organisation social and profile URLs.

Then assign an owner for third-party updates, because the new website cannot correct an old directory, award profile or client credit on its own. Google draws local business information from official sites, licensed third-party data, user contributions and reviews. Consistency is an evidence problem across many sources, not a schema problem on one page.

Keep, merge or remove

Keep when the purpose survives, even if design and copy change entirely.

Merge when two or more old pages are served better by one stronger final page. Record which intent, evidence and inbound links each source contributes, because that is what gets lost.

Remove only after confirming the page has no needed intent, proof, links, citations or conversion role. A page with almost no traffic can still hold evidence another page depends on.

When URLs change, use a direct permanent server-side redirect to the closest relevant page. Not the homepage. Google's site-move guidance recommends mapping old to new, updating internal links and canonicals, using permanent redirects, and monitoring afterwards. It also recommends changing one major element at a time where practical, which is the advice most often ignored when a rebrand, a redesign and a domain move ship together.

Binary acceptance criteria

"SEO checked" is not an acceptance criterion. Use tests that pass or fail:

• Final URL returns the intended status code.
• Self-canonical matches the final URL.
• Indexability matches the recorded decision.
• Title and H1 describe the page's job, with no text left over from a template.
• Required factual claims are visible and accurate.
• Structured data matches the visible content.
• Old URL redirects directly to the mapped final URL, with no chain.
• Important internal links point at the final URL.
• The analytics event fires exactly once.
• Search Console and Bing properties are verified.
• The sitemap contains final canonical URLs only.

Attach evidence to each row: a rendered URL, an export, a screenshot, a test output. A tick with nothing behind it is how a launch passes QA and fails in production.

Three monitoring windows

Within 24 hours. Deployment, robots controls, canonicals, redirect responses, analytics, sitemap availability. This is implementation QA, not a performance verdict, and treating it as one causes needless panic.

At 7 days. Crawling, indexation, canonical selection, redirect errors, whether priority landing pages are being discovered. Fix implementation failures before judging content.

At 28 days. Page-level direction across standard search, generative impressions by canonical page, Bing citation activity, and qualified conversions. Record confounders such as seasonality, campaign changes or a simultaneous domain move.

Agree the trigger before launch

A handoff without a response rule is a document, not a plan. Write the triggers while the team is calm, not at 11pm on launch night.

Hotfix triggers might include a priority page unexpectedly becoming non-indexable, a final URL canonicalising to an unrelated page, redirect loops or multi-hop chains, essential facts missing or contradicted, or conversion tracking failing.

A rollback trigger needs a threshold and a window:

Roll back the affected template if more than five priority URLs fail the canonical, indexability or conversion-event acceptance test and a safe hotfix cannot ship within the agreed window.

The exact number depends on the project. Having a number at all is the point.

The smallest useful engagement

A full retainer is not required to fix this handoff. A fixed-scope pre-launch review covers:

• Reviewing the priority URL map.
• Identifying canonical, indexation and evidence risks.
• Capturing the available Google and Bing baselines before anything changes.
• Marking the facts and proof that must survive.
• Testing redirects and rendered templates.
• Producing a launch pass or fail register.
• Reviewing the first post-launch window.

For an agency, we can do this without appearing in your client relationship. You keep the design direction, the development delivery and the account. We handle the search intelligence and the implementation checks that fall between disciplines.

The rule underneath all of it: do not wait until launch day to ask which pages mattered. If a page has search demand, generative impressions, citations, corroborating links or essential proof, put that evidence in the register while the old site is still up. Then give one person ownership of the final test.

That is the difference between a controlled migration and an accidental experiment.