Is the Redesigned Site Ready to Replace the Current One?

Create a current-state relationship map before wireframes are approved. The map should identify priority pages, their purpose, parent and child pages, inbound internal links, outbound evidence links, authors, reviewers, organisation references, breadcrumbs, navigation labels, and conversion paths. Store crawl exports and screenshots so the redesigned version can be compared against reproducible evidence.

A priority page passes when its redesigned version keeps or improves the relationships needed for the same user task. It fails when the page becomes harder to reach, loses supporting links, hides material evidence, changes the responsible author without review, or moves into a template that removes important content from rendered HTML.

Severity is critical for pages tied to revenue, eligibility, safety, regulated claims, or essential support information. The information architect owns navigation and hierarchy; the content owner owns page purpose and evidence; development owns rendered output; SEO owns crawl and indexation validation.

Review relative click depth and internal link context, but do not treat a specific depth as a universal ranking threshold. A page can remain several steps from the homepage when that structure is logical and the page is discoverable through relevant paths.

The corrective action should address the actual failure: restore a navigation path, add a contextual link, expose hidden copy, retain an author block, or redesign the template.

For high-trust content, compare biographies, credentials, citations, publication and review dates, policies, and organisation details. Tabs and accordions can be usable when the content remains accessible and rendered, but critical evidence should not be hidden behind a control that fails on mobile or without scripts.

The final validation compares the top 50 priority pages on the current and staging sites. Record click depth, inbound links, visible purpose, author and reviewer information, evidence access, and action path. Any material loss requires correction or an explicit signed exception before launch.

A redesign is an opportunity to reduce duplication and outdated information, but deletion can remove useful history, links, demand, or required disclosures. Build a page inventory and classify each URL into three working outcomes: retain, improve, or consolidate and remove. The final decision should be documented at URL level.

The source uses an 18 months inactivity screen and reports a prior project in which nearly 40 percent of legacy posts were removed. No supporting source URL exists in this JSON, so those figures must be treated as historical internal examples rather than universal thresholds or verified outcomes.

Use a longer data window when seasonality, infrequent buying cycles, policy history, or evergreen references make recent clicks an incomplete measure.

Evidence should include at least the last available search impressions, clicks, analytics sessions, conversions, external links, internal links, query purpose, publication and review dates, content accuracy, legal or records requirements, and overlap with other pages.

A page passes retention when it serves a distinct current need, supports another important journey, holds relevant links, or must remain available. It fails retention when it has no distinct purpose, duplicates stronger content, contains unsupported or obsolete claims, and has no obligation to remain.

Severity is critical when outdated advice could cause harm, when removed content has strong links or conversions, or when a required page is omitted. Content owners decide editorial disposition; SEO assesses search demand and links; legal or compliance reviews retention duties; analytics verifies outcomes; development implements redirects or removal responses.

Corrective actions include updating the page, merging useful material into a better destination, redirecting when the replacement satisfies the same intent, or returning an appropriate removal status when no replacement exists.

Validation requires checking the live response, destination relevance, internal links, sitemap, canonical, and archived decision record.

A page with zero visits and zero links is not automatically worthless. It may be new, seasonal, required, inaccessible because of a technical defect, or useful to a small but important audience. Diagnose the reason before acting.

Structured data can disappear, duplicate, or become inaccurate when a theme, CMS, plugin, template, or content model changes. Export the current JSON-LD and microdata by template before development. Record which fields come from the CMS, which are hard-coded, and which depend on author, product, review, location, or organisation records.

The redesigned implementation passes when each supported type matches visible page content, uses accurate identifiers, connects the appropriate organisation and person records, and remains consistent across canonical URLs.

It fails when markup claims a service, review, award, author, location, or relationship that the visible page does not support. Misleading structured data is critical; missing optional markup is usually lower severity.

Do not promise that continuity will preserve rich results. Search features are selected by Google and can change. Do not add FAQPage schema under this contract or claim that FAQ content can earn a Google FAQ rich result.

Google no longer shows that feature. Use current official documentation to determine whether LegalService, FinancialService, MedicalBusiness, Product, Review, LocalBusiness, HowTo, or other types are appropriate for a specific page.

Schema owners should map current properties to the redesigned content model, not copy old output blindly. If a field no longer exists, either restore the visible fact and data source or remove the property.

SameAs, memberOf, awards, area served, and credentials require factual validation and should not be used simply to strengthen an entity narrative.

Validate every unique staging template with syntax tools and a visible-content comparison. A passing validator confirms structure, not truth or search eligibility. After launch, inspect live canonical pages and monitor supported Search Console enhancement reports where available.

The corrective action belongs to development when templates or data binding fail, to content when visible facts are missing, and to SEO or legal when eligibility or policy is unclear. Validation requires the final rendered page, not only source code in a component library.

URL changes create migration work and should not be approved for cosmetic preference alone. Begin with the current inventory, query data, backlinks, conversions, internal links, canonical status, and page purpose.

Keep the existing URL when it is readable, stable, indexed, linked, and aligned with the future page. Change it when the current path creates a genuine structural or maintenance problem that the new architecture resolves.

The source contrasts a flat path with `example.com/services/personal-injury/london/`. A nested structure can clarify relationships, but it does not guarantee better rankings, and a nominal city or service area does not automatically justify a page.

A location path should represent a genuine location or useful local service and contain meaningful location-specific information.

Create a master mapping file with old URL, proposed new URL, disposition, reason, current status, canonical, traffic, queries, backlinks, internal links, owner, launch status, and validation result. A one-to-one mapping is preferred when the redesigned page satisfies the same task. Do not redirect unrelated pages to the homepage merely to avoid an error response.

The redirect passes when the old URL returns a direct 301 response to a relevant live destination, the new URL returns the intended status, internal links use the new path, the new sitemap contains the destination, and no chain or loop exists.

It fails when a temporary response is used for a permanent move, the destination changes intent, or the old URL remains in navigation.

Lowercase and hyphen conventions can improve consistency, but changing an established path only to enforce them may create more risk than value. Removing legacy file extensions can be useful during a platform migration when redirects and testing are complete.

Monitor missed URLs and error logs after launch. The source recommends at least thirty days as an operating period; extend monitoring when crawl frequency, site size, seasonality, or external links require it.

A redesign can add heavier templates, duplicate scripts, unoptimised media, third-party tags, and slower server responses. Record the current baseline before selecting a new CMS, theme, hosting environment, or page builder. Measure representative templates rather than relying on the homepage alone.

Evidence should include field Core Web Vitals where available, repeatable mobile lab tests, server response timing, rendered HTML, JavaScript errors, asset weight, request count, accessibility checks, uptime, security headers, certificate configuration, cache behaviour, and performance under expected load. The source example of a page taking six seconds is a warning scenario, not a universal failure threshold.

A staging template passes when the intended content renders, important interactions work, performance is no worse without an approved reason, and accessibility or security defects do not block launch.

It fails when visual effects delay content, scripts prevent navigation, mobile layouts hide controls, or the new infrastructure cannot handle expected traffic. Critical failures require a launch stop.

Remove unused CSS or JavaScript only after verifying that the code is not needed by another state, device, language, or user journey. Optimise images with suitable formats, dimensions, responsive sources, compression, and loading behaviour. Avoid using lazy loading where it delays the primary above-the-fold image or content.

Do not claim managed hosting is inherently better. Choose infrastructure by platform needs, support, security, observability, recovery, geographic requirements, and performance evidence. Document rollback procedures, backups, deployment controls, and incident ownership.

For accessibility, assess the applicable standard and jurisdiction rather than making an unsupported blanket compliance statement. Test keyboard navigation, focus, labels, contrast, headings, media alternatives, forms, error handling, and touch targets. Security and privacy teams should review forms, consent, trackers, cookies, and data flows before launch.

SGE was a historical experimental name. Current redesign planning should refer to Google AI Overviews or Google AI features. The page should be written for users first, with a structure that also lets search systems interpret its subject, claims, sources, and responsible entity.

The source refers to being Number 1 and recommends a 1-2 sentence summary. Preserve those figures as examples rather than promises. A concise opening can help when it answers the primary question accurately, but some pages require qualification, eligibility, risk, or jurisdiction before a direct answer is safe.

Create answer-first sections only when they match a real user question. Follow each summary with evidence, scope, limitations, examples, and an appropriate next step. Avoid unsupported claims that a claim-evidence-conclusion structure is preferred by AI models. Use the structure when it makes the page clearer and more reviewable.

Headings should describe the content literally enough for users and systems to understand the section. Level-two and level-three headings can frame questions when the page genuinely answers them, but not every heading must be a question. Bullets and tables should be used for comparison or scanning, not as an AI tactic.

Citations should be crawlable, relevant, and connected to the exact claim they support. About, author, expertise, governance, and policy pages should reflect visible and verifiable facts. Do not add credentials, awards, memberships, or relationships merely to strengthen entity signals.

Robots policies for search and AI crawlers are a business and legal decision. Record which public content is allowed, which agents are affected, and what consequences are accepted. A redesign should not quietly change crawler access without approval.

Validation includes an isolation test for summaries, factual review, source-link checks, rendered HTML inspection, and consistency across canonical pages. Passing these checks improves clarity but does not guarantee citation.

The staging site is where a redesign lives or dies. Most teams use it for visual approval, but I use it for a Technical Stress Test. Before the site goes live, we perform a full crawl of the staging environment to identify any 'SEO leaks'.

This includes checking for broken links, missing meta data, and incorrect canonical tags. What I've found is that many developers accidentally leave 'noindex' tags on the staging site, which can be catastrophic if they are carried over to the live environment.

We also use the staging phase to test the site's performance under load. If the new CMS is significantly heavier than the old one, we need to know before the public sees it. We compare the 'Time to First Byte' (TTFB) and the 'Largest Contentful Paint' (LCP) between the old site and the staging site.

If the staging site is slower, we stop the launch. This is a process over slogans approach: we don't 'hope' the new site is better: we prove it with data. For our clients in regulated industries, we also perform a content parity check.

We use automated tools to compare the text content of the old URLs with the new ones. If a page has lost 50 percent of its word count or key sections have been removed, we flag it for review. We want to ensure that the 'depth' of the content: which is a major ranking factor: is maintained.

This level of rigor is what separates a successful migration from a 'redesign disaster'. It is a documented, measurable system that ensures the transition is as smooth as possible.

The first 72 hours should have named on-call owners, an issue channel, severity definitions, rollback criteria, and a live migration dashboard. The purpose is to find defects quickly, not to promise that search visibility will stabilise within the window.

Monitor Search Console, server logs, crawler results, uptime, error tracking, analytics, and conversion systems. Investigate spikes in 404 responses, server errors, blocked resources, redirect loops, unexpected canonicals, sitemap failures, or missing events.

Some search fluctuation is normal, so diagnose the affected URL and query before attributing movement to a broad entity problem.

Track whether old URLs return the approved redirect and whether new URLs are crawlable, render correctly, and appear in Search Console inspection. Old URLs can remain visible in search results while systems recrawl and consolidate; their temporary presence does not by itself prove a redirect failure.

Compare user and conversion metrics in GA4 with the pre-launch baseline, but account for seasonality, campaign changes, consent, tracking differences, and normal variance. A higher bounce or lower engagement metric can indicate a UX issue, a changed traffic mix, or altered measurement. Test the page journey before concluding that the design missed intent.

The source refers to tracking the top twenty money keywords daily for the first week. Preserve the figures as an operating example, but prioritise page and query groups that matter to the migration and avoid presenting daily movement as a reliable ranking outcome.

At the end of the 72 hours, publish a stabilisation record listing every issue, evidence, severity, owner, corrective action, validation result, unresolved risk, and next review date. Continue structured monitoring through the longer recrawl and reindexing period.

Most SEO redesign guides treat the process like a simple move to a new house. They tell you to pack your boxes (content) and change your address (301 redirects). This analogy is flawed because it ignores the semantic context of your site.

Standard advice focuses heavily on the technical 'plumbing' while ignoring the informational architecture that defines your expertise. Most guides won't tell you that changing your internal link structure can destroy your topical authority even if your URLs stay the same.

They also fail to account for AI search visibility, focusing instead on legacy ranking factors that are becoming less relevant in the era of SGE and AI Overviews. My approach prioritizes the integrity of the entity, ensuring that your brand's relationship with search engines is reinforced, not reset, during the transition.

A redesign succeeds when design decisions respect the site's information, user journeys, evidence, and technical constraints from the first wireframe. SEO cannot be added safely after a new architecture has already removed important pages, hidden source material, changed URLs without mapping, or replaced accessible navigation with interactions that do not render reliably.

The most useful governance model gives design, content, development, analytics, legal, compliance, accessibility, and SEO clear approval responsibilities. A visually attractive choice can still fail when it creates an untestable migration risk. Conversely, preserving every legacy element can fail when it keeps outdated content or an unusable structure.

The checklist should make those tradeoffs reviewable. Every exception needs an owner, rationale, affected pages, severity, corrective or mitigating action, validation method, and launch decision. That record protects the project from relying on memory or optimism.

Day 1-5

Build the current-state relationship map, priority URL inventory, internal-link baseline, author and evidence inventory, and migration acceptance criteria.

Outcome: A signed baseline showing which search, content, trust, technical, and conversion signals must be preserved or intentionally changed.

Day 6-10

Classify every current page as retain, improve, consolidate, redirect, remove, or investigate, using demand, links, accuracy, obligations, overlap, and user purpose.

Outcome: An approved content disposition register with evidence, severity, owner, corrective action, and validation for every URL.

Day 11-20

Complete the old-to-new URL map, structured data field map, template requirements, tracking plan, content parity rules, and rollback design.

Outcome: A developer-ready migration specification covering redirects, canonicals, sitemaps, schema continuity, analytics, and release controls.

Day 21-25

Run the complete staging stress test across crawl, redirects, content, rendering, performance, mobile, accessibility, security, analytics, forms, and rollback.

Outcome: A frozen launch candidate with critical defects closed, high risks approved, and validation evidence attached.

Day 26-30

Launch through the approved runbook, enter the 72-Hour monitoring window, triage defects by severity, and publish the first stabilisation record.

Outcome: A controlled migration with documented launch evidence, resolved critical issues, and continued monitoring owners.