Traffic Dropped After a Replatform: The Technical Checks I Run First

A traffic drop after a replatform has a special ability to make everyone nervous at once.

Marketing sees rankings slip. Product sees fewer users. Engineering sees a release that technically shipped. Leadership sees a graph moving the wrong way and wants to know whether to roll back, patch forward, or wait for Google to "catch up".

Waiting might be right. It often is not. The first job is to separate normal post‑launch noise from technical damage.

This is not about blaming the redesign or the new platform. It is about checking whether the new site still gives search engines the same or better ability to discover, render, understand, and trust the important pages.

First, Prove the Drop is Real

Before crawling the site, confirm the shape of the problem.

Look at Search Console, analytics, rank tracking if it exists, server logs where available, and the release timeline. The question is not just "did traffic drop?" It is "which traffic dropped, when, and where?"

Segment by:

• page type
• query group
• device
• country
• branded versus non‑branded traffic
• organic landing pages
• index coverage
• crawl activity
• old URLs versus new URLs

A site‑wide drop immediately after launch suggests a different problem from a slow decline in one route family. A mobile‑only drop points somewhere different from a content parity issue. A drop in impressions is not the same as a drop in click‑through rate. A drop in branded traffic is not the same as a lost long‑tail article cluster.

Good diagnosis starts with the affected surface.

Compare the Old and New Route Set

Most migration problems become visible when the old URL estate is compared with the new one.

I want to know:

• Which old URLs still exist?
• Which old URLs redirect?
• Which old URLs now return 404 or soft 404 content?
• Which important new URLs are missing from the sitemap?
• Which URLs changed trailing slash, case, locale, query, or canonical behaviour?
• Which parameterised or filtered URLs are now crawlable by accident?

Redirects are a common source of quiet damage. A redirect map can be incomplete, chained, temporary when it should be permanent, or pointed at a page that is only roughly equivalent. 301 and 307 redirects are not interchangeable signals. Search engines and users need to land on the best replacement, not the nearest homepage.

The worst redirect maps are the ones that look tidy in a spreadsheet but collapse intent. If a detailed service page, category page, or article redirects to a generic page, the migration may preserve status codes while losing relevance.

Check the Rendered HTML, Not Just the React Tree

Modern front ends can look right in the browser while shipping weaker HTML than the previous site.

Search engines can render JavaScript, but that does not make rendered output irrelevant. Important titles, headings, body copy, canonical links, meta descriptions, structured data, internal links, and image alt text should be present and stable in the rendered page. If the old site exposed clear HTML and the new one delays meaning behind fragile client‑side behaviour, the migration has changed more than the design.

HTML markup for SEO still matters after a migration. The page needs a coherent document structure. It needs a single sensible primary heading. It needs links that crawlers and users can follow. It needs metadata that matches the visible content.

For each affected template, inspect:

• title and meta description
• canonical URL
• robots directives
• h1 and heading hierarchy
• primary body copy
• internal links
• pagination links
• structured data
• image alt text and dimensions
• status code
• rendered text after hydration

Do this on the built or live page. Source code only explains the root cause after the rendered problem is visible.

Look for Content Parity Failures

Redesigns often remove content accidentally.

The new page may be cleaner, but it has lost the copy that matched long‑tail queries. The old page may have had supporting FAQs, comparison sections, technical details, reviews, opening hours, location copy, product attributes, or category descriptions. The new page keeps the hero and cards, but removes the paragraphs that made the page understandable.

This is especially common when teams treat content as decoration instead of evidence. A beautiful page can be thinner than the page it replaced.

Content parity does not mean copying every old paragraph. It means preserving the useful information, intent, and internal links that helped the page earn visibility. If something was removed deliberately, the team should know why.

Compare the old and new versions of the affected pages. Check word count only as a rough signal. More important is whether the new page still explains the topic, answers the user's query, and supports the internal linking graph.

Audit Canonicals and Index Directives

Canonical mistakes can flatten a site quickly.

The new platform might point every page at the homepage. It might canonicalise filtered pages incorrectly. It might preserve staging canonical URLs. It might generate absolute URLs with the wrong host. It might render a canonical that disagrees with redirects, sitemap entries, and internal links.

Robots directives can be just as damaging. A noindex left over from staging, an overly broad robots rule, or a template‑level setting applied to the wrong content type can remove pages that looked fine in QA.

Google's documentation on robots.txt handling is a useful reminder that crawl controls apply by host, protocol, and path. Migration work regularly trips over those boundaries because staging, preview, production, and canonical hosts are all in play.

Check these signals together:

• HTTP status
• canonical
• robots meta tag
• robots.txt
• sitemap inclusion
• internal links
• hreflang if relevant
• redirect target

One good signal does not cancel out five contradictory ones.

Check Sitemap and Internal Discovery

A sitemap does not guarantee indexation, but a broken sitemap can still hurt discovery.

After a replatform, I compare the sitemap with the live route set and the priority page list. Are important URLs missing? Are retired URLs still present? Are future‑dated, preview, or staging URLs leaking? Are category and pagination routes represented correctly? Are updated dates believable? Is the sitemap submitted and fetchable?

Internal links matter more than teams admit. If important pages now only exist in a client‑side carousel, behind a search interaction, or buried under generic card links, search engines and users may have a weaker discovery path than before.

The new navigation should not just look cleaner. It should preserve the routes that matter.

Structured Data Should Still Match the Page

Structured data often breaks during migrations because it sits in template code people do not inspect visually.

The new site may drop Article schema, change BreadcrumbList output, lose Product fields, duplicate Organisation data, or keep FAQ markup for questions no longer visible. Google's structured data guidance is clear that structured data should describe visible page content and follow feature‑specific requirements. The intro to structured data is still the place to start.

Do not add schema as a panic response to a traffic drop. First check whether the schema the old site had was valid, useful, and still present. Then decide whether the new page needs better entity clarity, breadcrumbs, products, articles, services, or local business data.

Schema drift is rarely the only cause of a migration drop, but it is often part of a wider pattern: the new templates are less explicit than the old ones.

GEO Can Regress Before Anyone Names It

Replatform checks should now include generative engine optimisation, even when the immediate concern is conventional organic search.

Answer engines need retrievable evidence: clear entities, consistent names, visible expertise, structured data that matches the page, useful internal links, and pages that can be crawled and summarised without guessing. A redesign can weaken those signals without causing an obvious technical failure. The page still loads, but it no longer explains who the service is for, what problem it solves, which technologies are involved, or why the source is credible.

The article on technical GEO signals covers that retrieval layer in more detail. During a migration, I would compare old and new templates for entity clarity as well as keyword coverage. Are important people, organisations, products, services, locations, frameworks, and proof points still named in visible copy? Do breadcrumbs and schema reinforce the same relationships? Do internal links connect the new page to the right supporting evidence?

This is not about stuffing pages with entities. It is about preserving meaning. If the old site made expertise and relationships clear, and the new site reduces them to vague cards and abstract headings, visibility can soften even if the route map looks tidy.

Decide Whether to Roll Back, Patch, or Wait

Not every drop justifies a rollback. Not every drop should be patched immediately.

Rollback makes sense when the new site has a broad technical defect that cannot be fixed quickly: broken routes, widespread noindex, severe rendering failure, or major redirect collapse. Patch forward makes sense when the issue is localised and the new platform is otherwise healthy. Waiting makes sense when the signals are consistent, pages are crawlable, redirects are correct, and the movement looks like normal recrawling rather than damage.

The decision should be based on evidence, not anxiety.

Write down:

• what changed
• which pages are affected
• which technical signals are wrong
• which fixes are safe
• which fixes need more care
• what should be monitored after release

That gives leadership something better than "we're looking into SEO".

Wrapping up

A traffic drop after a replatform is not automatically a disaster, but it is never something to hand‑wave away.

The early checks are practical: route mapping, redirects, rendered HTML, content parity, canonicals, robots, sitemaps, internal links, and structured data. Those are the places where migrations quietly lose search visibility while still looking successful from a delivery standpoint.

The aim is not to prove the old site was better. It is to make sure the new site has not lost the signals that made important pages findable in the first place.

Key Takeaways

• Segment the traffic drop before diagnosing the platform.
• Compare old and new URLs, redirects, and route intent.
• Audit rendered output, not only source code.
• Content parity means preserving useful information, not copying every old paragraph.
• Canonicals, robots, sitemaps, and internal links must agree.