Services

Traffic Dropped After a Redesign or Replatform

Traffic drops after a redesign, rebuild, or platform change usually need a technical explanation of what changed, not a generic SEO audit detached from the launch.

Recover organic traffic after a redesign or replatform by isolating what changed in URLs, templates, rendering, metadata, or crawl signals before the drop compounds.

Short Answer

A redesign or replatform can look fine in the browser while search traffic drops because URLs, templates, internal links, or rendered signals changed underneath the visual layer. Recovery starts by comparing the old and live estates, including URL and canonical mapping, rendered HTML, metadata parity, structured data, sitemap and robots behaviour, then prioritising fixes by commercial route value rather than running a generic SEO audit.

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

  • Compare high‑value pre‑launch URLs with the live versions for redirects, canonicals, rendered HTML, and internal‑link changes.
  • Which route families lost the most traffic first and whether the drop lines up with one template or one change type.
  • What changed in the release across metadata, URL policy, rendering, and crawl discovery.

How I Help Fix This

  • Trace the traffic drop back to the technical changes most likely to have commercial impact.
  • Fix the route families and templates most likely to recover visibility first.
  • Validate the recovery work so the team stops guessing.

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.

What Gets Resolved

  • Traffic loss is tied back to changed routes, templates, redirects, metadata, crawl signals, or content rendering.
  • Lost or underperforming URLs are mapped against rendered HTML and crawl or indexing signals.
  • Redirect, canonical, sitemap, robots, metadata, and schema faults are separated.
  • Fixes are prioritised by commercial search exposure and implementation risk.
  • The team knows which evidence to re‑check after release.

How This Usually Works

  1. Technical Diagnostic

    A focused review of affected routes, templates, deployment behaviour, crawl signals, CMS behaviour, performance bottlenecks, or code paths, followed by a prioritised fix plan the team can take into delivery.

  2. Recovery Sprint

    A short, concentrated engagement for a defined technical SEO, performance, CMS, Vercel, migration, or production issue where the business needs the cause isolated and the first fixes moved quickly.

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, as long as there is enough evidence from redirects, launch artefacts, cached pages, sitemaps, analytics, or deployment history to compare what important routes used to do with what they do now.

Talk to me about your recovery

A short description of the affected route, Search Console signal, or production symptom is enough. I'll read it and suggest the next step.

Get in touch

Related Case Studies and Project Work

  1. Screenshot of the John Lewis website; part of John Kavanagh's selected project work.

    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 while the brand changed.

    View case study
  2. Screenshot of the Nando’s website; part of John Kavanagh's selected 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

More Specific Service Pages

Related Services

All Services

Related Technical Articles