How is this different from a general SEO audit?

This is recovery work tied to a specific change window. The job is to compare the old and new estates route by route until the technical cause of the drop is clear, not to produce a broad list of generic SEO recommendations.

Can you still help if the old platform is no longer live?

Usually yes. Old crawls, sitemaps, repository history, saved page captures, analytics, and deployment records can help reconstruct what changed. I record gaps in that evidence so a plausible explanation is not presented as a confirmed cause.

Services

Traffic Dropped After a Redesign or Replatform

If organic traffic fell after a redesign, rebuild, or platform change, I can investigate the launch with your engineering and marketing teams. The first job is to establish which pages lost visibility and whether the release evidence explains the decline.

Get an evidence‑backed diagnosis, an affected‑URL list, and a recovery plan ordered by commercial impact, fix confidence, and release risk.

Short Answer

I compare Search Console and analytics trends with the launch timeline, then inspect affected URLs, redirects, canonicals, rendered HTML, internal links, and discovery files. The diagnostic separates confirmed release defects from measurement changes and explanations that still need evidence. You get a prioritised fix list with reproduction steps and release checks, plus a recommendation to patch, roll back, or monitor. Rankings and recovery dates cannot be guaranteed.

Typical Symptoms

Traffic, rankings, or indexed coverage dropped shortly after a redesign or replatform launched.
Some template groups or route families were hit much harder than others after release.
The site looks visually fine, but discovery, rendering, or URL behaviour no longer matches the previous estate.

Likely Causes

Redirects, canonicals, internal links, or sitemap coverage changed more than expected during the launch.
The new templates are rendering weaker metadata, thinner content, or less crawlable HTML on important routes.
The redesign or rebuild shipped without route‑by‑route parity checks against the previous platform.

What I Look at First

Start with the launch date, affected landing pages, Search Console and analytics exports or read access, and any old sitemaps, crawls, or deployment records. Compare the same page groups, countries, and devices before blaming the new platform.
Use the Traffic Drop Triage Checklist to compare commercially important pre‑launch URLs with the live versions. My guide to the first checks after a replatform explains how I separate measurement changes, route loss, and rendering faults.
Use the Rendered HTML Migration Comparison Worksheet to record differences in content, metadata, schema, and links. The rendered HTML comparison guide explains why I capture both the server response and the page after JavaScript has run.
Record which comparisons are possible and which remain uncertain if the old platform or historical data is unavailable.

How I Help Fix This

Produce an affected‑URL register grouped by template, with observed defects, supporting captures, commercial priority, and confidence in each proposed fix.
Agree the first release with your team, including the safest patch or rollback path and the checks that must pass before it ships. Implementation can be scoped after the diagnosis.
Recheck response HTML, browser output, redirects, canonicals, and discovery after each fix, then monitor the affected page groups as search engines recrawl them.
On the Nando’s replatform, I introduced reusable structured‑data factories and reworked restaurant pages around addresses, opening hours, ordering options, and amenities. That delivery experience informs the checks here; the cause of your traffic loss still needs its own evidence.

When to Look at This

As soon as the drop is visible and the launch window is still clear enough to inspect properly.
When the redesign or replatform is live but nobody has a trusted parity view of what changed technically or a Website Replatforming Risk Register to work from.

What Gets Resolved

The affected page groups and change window are documented, with tracking changes and other plausible explanations kept separate from verified release defects.
An affected‑URL register records redirects, canonicals, rendered‑content differences, discovery gaps, and the evidence available for each finding.
A recovery backlog orders confirmed fixes by commercial exposure, confidence, dependencies, and release risk.
Each agreed fix has a reproduction, an expected result, and a regression check the delivery team can run.
A monitoring baseline distinguishes the technical checks that passed from later changes in crawling, indexation, clicks, and enquiries.

How This Usually Works

Technical Diagnostic
A focused review to establish what is happening, where the risk sits, and what should happen next, ending with a prioritised plan the team can take into delivery.
Recovery Sprint
A short, concentrated engagement to isolate a defined problem, stabilise the immediate situation, and move the first fixes into delivery.

Common Questions

How is this different from a general SEO audit?: This is recovery work tied to a specific change window. The job is to compare the old and new estates route by route until the technical cause of the drop is clear, not to produce a broad list of generic SEO recommendations.
Can you still help if the old platform is no longer live?: Usually yes. Old crawls, sitemaps, repository history, saved page captures, analytics, and deployment records can help reconstruct what changed. I record gaps in that evidence so a plausible explanation is not presented as a confirmed cause.

Need help with search visibility?

Tell me which pages have been affected, what changed, and when you first noticed the problem. I'll read it and suggest the next step.

Get in touch

Related Case Studies and Project Work

A Complete Migration and Replatform for Nando’s
On Nando’s, the migration tied structured data, restaurant‑page improvements, local discovery, and measurable search uplift into one Next.js and Vercel delivery.
View case study
The Optimisation and Rebrand of johnlewis.com
On John Lewis, front‑end optimisation work on a high‑traffic retail platform had to protect search‑visible commercial pages whilst the brand changed.
View case study