Run the Redesign as a Search Migration With Evidence at Every Gate

The baseline is the control copy for every later redesign decision. Preserve dated exports rather than relying on live dashboards that will keep changing after release. The owner of each baseline artifact should be clear, and any gap in the evidence should be visible before architecture approval.

Check 1 - Search and indexability inventory Evidence required: an export of indexable URLs with principal queries, Search Console impressions and clicks for the trailing 90 days, current indexability, canonical target, and crawl depth.

Pass: the export covers the known indexable set and is stored as a dated reference. Fail: priority URLs are missing, fields cannot be tied to a URL, or the only record is a live view that will change.

Severity: high for missing priority pages and medium for incomplete supporting fields. Owner: SEO. Corrective action: complete or reconcile the inventory before the affected architecture decision is approved. Validation: compare the preserved export with a fresh crawl and resolve unexplained gaps.

Check 2 - External-link evidence Evidence required: the internal destinations that receive known external links, the linking source where available, anchor context, and the destination used by the current site.

Pass: linked internal pages are visible in the migration register and cannot be retired without review. Fail: linked pages are absent from the decision set or are mapped solely because they have little direct traffic.

Severity: high when a linked destination is being removed or moved. Owner: SEO or the person maintaining backlink data. Corrective action: add the page to the protected review set and decide whether to preserve, move, combine, or retire it based on relevance. Validation: confirm the approved URL decision still accounts for every linked destination in the baseline.

Check 3 - Internal-link graph Evidence required: a crawl export showing source URL, destination URL, anchor text, response status, and depth. Pass: important hub pages and heavily supported destinations are identified before navigation and template changes are accepted.

Fail: the team cannot tell which pages lose links in staging. Severity: high for priority destinations that depend on sitewide or hub support. Owner: SEO with development support for template-generated links.

Corrective action: preserve or redesign the necessary discovery paths intentionally. Validation: compare the staged graph with the saved baseline.

Check 4 - Structured data and template evidence Evidence required: representative rendered output for each major template and a note identifying where the markup is generated. Pass: the team can compare current and staged output for equivalent templates.

Fail: structured data is assumed to survive because page content looks the same. Severity: medium unless the missing output also signals a broader template defect. Owner: development with SEO review.

Corrective action: restore or intentionally revise the output according to the page's actual content. Validation: inspect rendered staging and production output on representative URLs.

The baseline is complete when the team can trace every protected decision back to evidence. It is not a promise that nothing will change; it is the record that allows change to be deliberate.

Turn the baseline into a URL decision register before migration implementation is considered complete. Every indexable source needs a treatment, supporting evidence, a destination when one exists, an owner, and an approver. The purpose is to stop launch-week improvisation.

Use four treatments in the working register: keep the current URL and purpose, move the page to an equivalent destination, combine overlapping pages into a stronger relevant destination, or retire a page that no longer has a useful replacement. The label matters less than the evidence and acceptance condition attached to it.

For a moved page, evidence should show that the new destination serves the same user need. Pass means the approved direct 1:1 mapping is implemented, the destination contains the expected information, and internal links point to the final address.

Fail means the route is missing, the target is unrelated, or the source is still linked internally. Severity is high for sources with meaningful search or link evidence. The SEO owner and development owner should share corrective action: fix the mapping and update direct internal links, then validate the source and destination in staging and production. Validation also confirms the approved 1:1 source-to-destination relationship.

For a combined page, evidence should show genuine intent overlap and identify useful material that must survive. Pass means the destination covers the shared need before the retiring source is removed.

Fail means distinct intents were merged for design convenience or the destination omits material users still need. Severity is high when the retiring source has independent query or link evidence. The content owner makes the content correction, SEO confirms the migration decision, and validation checks both the page content and the route.

For retirement, evidence should show that the page has no appropriate continuing destination and no remaining purpose that justifies preservation. Pass means the retirement is explicit, internal links to the source are removed, and the returned status matches the intended removal.

When no equivalent exists, a deliberate 404 can be appropriate. Fail means an unrelated destination is used only to avoid an error response. Severity depends on the source's prior importance. The owner corrects the mapping or restores a suitable page, and validation confirms the final behavior.

The register should be reviewable by someone who did not design the new information architecture. If that reviewer cannot understand why a URL is kept, moved, combined, or retired from the evidence in the row, the decision is not ready.

A redirect plan is only a specification. Production behavior is the evidence. Every moved source should be tested for destination relevance, hop count, final status, and consistency with internal links and canonicals.

For a permanent move, the expected behavior is a direct 301 to the approved final URL. Existing redirect history must also be considered. If an older source already points to an intermediate URL that the redesign moves again, leaving both rules in place can create a chain.

Collapse known source routes so the original entry addresses resolve directly to the final destination through a single 301.

Use this verification sequence:

1. Evidence required: a crawl of current redirects and known historical source URLs. Pass: the migration set includes original entry URLs as well as current intermediates. Fail: the map begins only from the newest paths.

Severity: high for omitted sources with search or link evidence. Owner: SEO and development. Corrective action: add the original sources to the map. Validation: request them directly.

2. Evidence required: approved source-to-destination mapping with an intent note. Pass: each target answers the same or clearly continuing user need. Fail: pattern rules send sources to broad or unrelated pages.

Severity: high. Owner: SEO. Corrective action: remap the source or retire it deliberately. Validation: review destination content against the source purpose.

3. Evidence required: staged response trace. Pass: each source reaches the final destination without an unnecessary intermediate hop. Fail: a chain, loop, wrong target, or non-success final response appears.

Severity: high. Owner: development. Corrective action: rewrite the rule to point directly at the approved destination. Validation: rerun the full source set.

4. Evidence required: production response trace and internal-link crawl. Pass: live behavior matches the approved map and internal links use the final addresses. Fail: deployment changes the target or the site still relies on redirects internally.

Severity: high for systematic routing defects and medium for isolated internal links. Owner: development with SEO verification. Corrective action: repair rules and source links. Validation: recrawl production and reconcile differences.

For permanent migration mappings, verify 301 behavior rather than 302. The status is only one part of acceptance: the destination must also be relevant, the route direct, and the live implementation identical to the approved decision.

Content simplification is not automatically an SEO improvement. During a redesign, the useful question is whether a proposed change preserves the user need, search evidence, and distinctive information carried by each page. Apply the same evidence standard to pages that stay as well as pages that merge.

Decision 1 asks whether the page has demonstrated search or link evidence. Review impressions, clicks, query coverage, external links, internal support, and current purpose across the trailing 12 months where that history is useful.

Pass: the evidence is recorded before the page is materially changed. Fail: a page is judged only from current traffic or visual fit. Severity: high when the page is being removed. Owner: SEO. Corrective action: gather the missing evidence or pause the decision. Validation: attach the evidence to the migration row.

Decision 2 asks whether the page serves a distinct user intent. If 2 pages appear similar, compare the questions they answer, the actions they support, the queries that surface them, and the information that must remain findable.

Pass: combined pages genuinely overlap and a single destination can satisfy the shared need. Fail: pages with different purposes are merged because the new sitemap looks cleaner. Severity: high. Owner: content and SEO.

Corrective action: keep separate destinations or redesign the information architecture. Validation: review the proposed destination against both original intents.

Decision 3 asks which page should survive when overlap is real. Evidence required: ranking visibility, external-link evidence, internal support, content completeness, and fit with the intended information architecture.

Pass: the surviving destination is selected by evidence and can support the combined need. Fail: the survivor is chosen only because its URL is shorter or its design is newer. Severity: high. Owner: SEO and content. Corrective action: revisit the destination. Validation: record the selection rationale.

Decision 4 asks what useful material must move before a source retires. Evidence required: unique explanations, examples, media, internal links, and query-relevant sections from the retiring page. Pass: material that users still need appears on the destination before the source is removed.

Fail: the redirect is enabled first and the destination remains incomplete. Severity: high when unique coverage would disappear. Owner: content. Corrective action: expand the destination. Validation: compare the final page with the content-transfer notes.

Do not forecast a ranking gain merely because content was combined. Treat consolidation as a controlled architecture decision whose result must be measured after release against the baseline.

A priority URL can stay unchanged and still lose support if the redesign alters navigation, breadcrumbs, hub pages, related-content modules, footers, or contextual links. Treat the link graph as part of the migration evidence rather than assuming stable URLs carry stable internal support.

Step 1 - Preserve the live graph. Evidence required: source URL, destination URL, anchor text, response status, link location where available, and crawl depth. Pass: the dated export can be compared with staging.

Fail: the team has only screenshots or a post-change crawl. Severity: high when major navigation or templates are changing. Owner: SEO. Corrective action: capture the live graph before release. Validation: confirm the export covers the current crawlable site.

Step 2 - Define support expectations for priority pages. Evidence required: the important sources, hubs, navigation paths, and contextual relationships that currently lead to each protected destination.

Pass: the project knows which relationships must remain useful, even if the exact link count changes. Fail: only total link counts are recorded without context. Severity: high for commercially or informationally important destinations.

Owner: SEO and content architecture. Corrective action: document required discovery paths. Validation: review each protected page against its baseline sources.

Step 3 - Crawl staging and compare. Pass: priority pages remain discoverable through appropriate hubs and contextual routes, internal links resolve directly to final URLs, and no protected page becomes orphaned.

Fail: important paths deepen without reason, support disappears, or template links point at redirected sources. Severity: high for orphaning or broad template defects. Owner: development with SEO review. Corrective action: update navigation, modules, breadcrumbs, hubs, or contextual links. Validation: recrawl staging.

Step 4 - Recheck production. Evidence required: a live post-deployment crawl using the same comparison logic. Pass: the production graph matches the approved staged intent. Fail: environment-specific rendering or deployment changes reintroduce missing or redirected links.

Severity: high for systematic issues. Owner: development. Corrective action: repair the live source of the links. Validation: rerun the production crawl and close only when the defect no longer appears.

The goal is not to reproduce every old link. It is to preserve useful discovery and topical relationships deliberately, while removing links that were redundant, broken, or no longer appropriate.

A redesign can add or change scripts, fonts, media, consent components, analytics, hydration behavior, and interactive modules. A fast homepage does not demonstrate that article, category, service, or product templates behave acceptably. Test representative templates under consistent conditions and make regressions actionable before release.

Step 1 - Save the current template evidence. Record LCP, INP, and CLS observations for representative page types, along with the device profile, test conditions, and field information available for the live site.

Pass: the baseline is tied to specific templates and test conditions. Fail: the only reference is a single homepage run. Severity: medium to high depending on affected traffic. Owner: performance or development lead. Corrective action: capture comparable baselines. Validation: review the saved inputs and results.

Step 2 - Test staging consistently. Use the same device emulation, throttling approach, browser conditions, and test location where practical. Pass: repeated tests are comparable enough to identify material regressions.

Fail: current and staged results use materially different conditions. Severity: medium. Owner: performance lead. Corrective action: rerun with aligned settings. Validation: confirm the test record includes the conditions.

Step 3 - Investigate LCP regressions by template. Evidence required: the largest above-the-fold element, image loading behavior, font and render-blocking resources, relevant script execution, and client-side rendering.

Pass: a material regression has an identified cause and accepted remediation or is resolved before release. Fail: the regression is deferred without an owner. Severity: high for major affected templates.

Owner: development. Corrective action: optimize the actual bottleneck. Validation: retest the same template under the same conditions.

Step 4 - Exercise layout shifts during delayed and interactive states. Test menus, consent notices, embeds, accordions, lazy-loaded media, and other components that can move content. Pass: unstable components are fixed or intentionally constrained before release.

Fail: visible movement remains unexplained or unowned. Severity: medium to high based on scope. Owner: front-end development. Corrective action: reserve space, define media dimensions, or adjust component behavior. Validation: repeat the interaction sequence.

Step 5 - Apply the release gate. Pass: representative templates meet the documented acceptance criteria or have an explicitly approved exception with evidence. Fail: a material regression lacks an owner, corrective action, and successful retest.

Severity: high when the affected template is important to organic entry traffic. Owner: project lead with development and SEO input. Corrective action: fix, retest, or defer release. Validation: retain the passing test evidence with the launch record.

Field information from the live site is a baseline and post-release reference; an unpublished staging environment cannot reproduce the same field history. Keep that distinction explicit when comparing evidence.

Production availability is only the start of migration validation. Keep the review open for 90 days so redirects, canonicals, indexing, internal links, structured data, performance, and search visibility can be compared with the saved baseline as search engines recrawl and process the new site.

Do not treat the first 48 or 72 hours as the end of the review. The 90-day period below separates immediate implementation checks from later search-processing and recovery analysis.

Days 1-7 - Production verification. Evidence required: a live crawl against the approved URL decisions and redirect map, plus checks for robots directives, canonicals, indexability, XML sitemap contents, status codes, structured data, internal links, and representative performance.

Pass: production matches the approved implementation and critical defects have an owner. Fail: launch-blocking or broad defects remain unexplained. Severity: critical for accidental blocking, wrong canonical patterns, or broad routing failures; high for other systemic defects.

Owner: development, SEO, and the relevant platform owner. Corrective action: repair the implementation and revalidate, prioritizing critical defects within 24 hours where feasible. Validation: rerun the failed checks on production.

Days 7-30 - Search baseline comparison. Evidence required: weekly comparison of rankings, impressions, clicks, indexed pages, and landing-page performance for the top 50 priority keywords and their associated URLs.

Pass: material movement has a documented interpretation or investigation. Fail: declines are noted without tracing them back to URL decisions, content changes, redirects, canonicals, or internal support.

Severity: high for sustained priority-page losses. Owner: SEO. Corrective action: diagnose the affected cluster and open targeted remediation. Validation: recheck after the corrective change is processed.

Days 30-60 - Crawl and discovery review. Evidence required: crawl statistics, sitemap coverage, orphan candidates, duplicate paths, redirected internal links, parameter behavior, and discovery depth.

Pass: important pages remain reachable and unintended crawl paths are understood. Fail: new architecture makes priority content harder to discover or creates avoidable duplicates. Severity: high for priority orphaning and medium for narrower inefficiencies.

Owner: SEO and development. Corrective action: repair discovery paths, internal links, canonical handling, or route rules. Validation: recrawl and compare the affected section.

Days 60-90 - Persistent-change assessment. Evidence required: page-group and query-set comparison with the pre-launch record. Pass: persistent declines have a documented evidence chain covering destination accuracy, indexability, canonical status, content changes, internal support, external-link preservation, structured data output, and template performance.

Fail: the team jumps to unrelated tactics without reconciling migration evidence. Severity: high for priority clusters with unresolved losses. Owner: SEO with the relevant content or development owner.

Corrective action: create a targeted remediation record. Validation: measure the repaired cluster against the same baseline and log the result.

Keep one dated migration log containing observations, evidence, changes, owners, and validation results. It prevents multiple teams from making overlapping fixes without a shared record.

Launch timing should be chosen around response capacity, not superstition. The practical requirement is a staffed window in which the owners of routing, templates, content, analytics, and SEO can verify production and act if a critical defect appears, including a site-wide 500 response pattern.

Use the following final checks and treat each as a pass or fail control.

1. Robots verification - Evidence required: the production robots.txt and representative page-level indexing directives. Pass: intended crawlable pages are not blocked and production does not inherit staging restrictions.

Fail: a required section is disallowed or a directive contradicts the approved indexability decision. Severity: critical when broad. Owner: development or platform owner. Corrective action: restore the intended directive. Validation: fetch the live file and representative pages again.

2. Sitemap readiness - Evidence required: the production XML sitemap at /sitemap.xml and a crawl comparison with canonical, indexable URLs. Pass: intended URLs are represented and the file does not include known redirect sources or 404 pages.

Fail: required pages are missing, retired pages remain, or the file reflects staging. Severity: high when broad. Owner: development with SEO review. Corrective action: correct generation or inclusion rules. Validation: refetch and reconcile the file with the approved URL set.

3. Canonical verification - Evidence required: rendered canonicals across major templates. Pass: canonicals reflect the approved production destinations. Fail: templates point to staging, an unrelated URL, or an unintended variant.

Severity: critical for sitewide patterns and high for priority sections. Owner: development. Corrective action: fix template or data logic. Validation: inspect representative production pages again.

4. Noindex verification - Evidence required: rendered meta robots directives and relevant response headers on representative production pages. Pass: indexability matches the approved URL decision.

Fail: a production page inherits an unintended noindex or conflicting directive. Severity: critical when broad. Owner: development. Corrective action: remove the unintended restriction. Validation: repeat the live check within 24 hours and after cache or deployment changes.

5. Redirect verification - Evidence required: production requests for the approved source set. Pass: each source reaches the expected relevant final destination directly. Fail: chains, loops, wrong targets, or failed responses appear.

Severity: high. Owner: development with SEO verification. Corrective action: repair the rule and update internal links. Validation: rerun the source set.

6. Structured data check - Evidence required: rendered markup on representative pages from each main template and validation output where useful. Pass: markup reflects visible page content and the intended template output.

Fail: expected output disappears or contains template-level errors introduced by the redesign. Severity: medium to high by scope. Owner: development. Corrective action: correct generation. Validation: inspect rendered production output again.

7. Rollback decision record - Evidence required: named rollback authority, trigger conditions, restoration procedure, and post-rollback validation steps. Pass: the team can make and verify a rollback decision without inventing the process during an incident.

Fail: authority or acceptance criteria are unclear. Severity: critical for a high-risk release. Owner: project and platform leads. Corrective action: document the decision path before release. Validation: review the record with the people who would execute it.

After release, begin the 90-day verification period with the launch evidence already stored in the migration log.