- Definition
- Crawl parity — Crawl parity means the new site presents the same indexable URLs, carrying the same signals, as the old site did — allowing for intended changes. Verifying it means crawling both environments under identical configuration and comparing field by field. Unintended differences are invisible in a browser and obvious to a crawler.
The call usually comes about five weeks after launch. Traffic is down 20%, the URLs did not change, the redirects were not needed, and nobody can point at a cause.
Six things account for nearly all of these cases. Each leaves a different fingerprint, so working out which one you have is an hour of work rather than a research project.
Start with the one that is catastrophic and instant
If a noindex directive escaped from staging to production, nothing else on this list matters until it is removed.
Check three places on the live site: robots.txt, the meta robots tag, and the X-Robots-Tag HTTP response header. The third is the one people miss, because it does not appear in page source — you have to look at the response headers.
The fingerprint is unmistakable: a sharp decline starting within a few days of launch, affecting the whole site rather than a section. If your decline is gradual and uneven, it is not this, and you can move on quickly.
Copy that got shorter
This is the most common cause and the least discussed, because it is invisible to everyone reviewing the new site.
New templates have new layouts, and new layouts frequently have less room for text. A category page that carried 600 words of descriptive copy now carries 150. Nobody made a decision to reduce topical coverage; a designer made a decision about visual density and this was the consequence.
The fingerprint: loss concentrated on one template type while other page types are flat. Confirm by diffing word counts per URL between your pre-migration crawl and a current one — which is why the pre-migration crawl is the first thing on the checklist.
Internal links that quietly disappeared
Footers get trimmed from eighty links to twelve. Sidebars are removed as clutter. Related-content modules do not make the build because they were never on the ticket.
Every one of those was a crawl path and a distribution of internal link equity to deep pages.
The fingerprint is distinctive: deep pages lose visibility while the homepage and top-level pages are completely unaffected. If your top pages are flat and your long tail has fallen, look here first.
Confirm by comparing inbound internal link counts per URL — not outbound. Outbound tells you how many links a page has; inbound tells you how much support a page receives, which is what actually changed.
Content that now needs JavaScript
Moving to a JavaScript framework can move body copy, internal links and canonical tags out of the initial HTML response.
Google renders JavaScript, so this is not automatically fatal. Rendering is queued rather than immediate, and internal links that only exist after hydration are discovered slowly. On a large site that turns a two-week settling period into a two-month one.
The test: fetch the raw HTML and look for the content. Use view-source or curl, not the browser inspector — the inspector shows the rendered DOM, which is exactly the thing you are trying to see past.
Structured data nobody rebuilt
Rich results disappear a few weeks after launch and nothing in the traffic graph explains it, because impressions and average position are roughly unchanged.
That is the fingerprint: clicks down, impressions flat. The pages still rank in the same positions; they just no longer render a review snippet, an FAQ dropdown, product pricing or a breadcrumb trail, so fewer people click them.
Check which templates emitted markup before and which do now. The fix is straightforward reimplementation.
Index bloat that arrived with the platform
New platforms generate URLs the old one did not: faceted navigation, pagination parameters, sort orders, tag archives.
Crawl budget that was spent on your money pages is now spread across thousands of near-duplicates. The site can look thinner to Google than before despite having more pages.
Compare indexable URL counts against the pre-migration baseline. A large unexplained increase is bloat rather than growth, and it wants canonicals, robots rules or routing changes rather than patience.
Working through it
The order in the checklist above is deliberate: fastest and most catastrophic first, slowest and most gradual last. Most cases resolve within the first three steps.
If none of the six fit, widen the frame. Check whether the decline predates the migration, and whether it coincides with a known algorithm update affecting competitors in the same period. Attributing an algorithmic movement to a migration produces a lot of wasted work.
The parity method that prevents all of this is on the technical scope page, and the replatform page covers what to check before launch rather than after. If you need someone else to run the diagnosis, that is what the post-launch audit is for.
| Cause | Fingerprint in the data | How to confirm | Fix |
|---|---|---|---|
| Copy reduced by new templates | Loss concentrated on one template; word counts down | Diff word counts per URL between old and new crawls | Restore the copy, or accept it with the exposure known |
| Internal links removed | Deep pages lose; top-level pages flat | Compare inbound internal link counts per URL | Rebuild the modules that carried the links |
| Content moved behind JavaScript | Broad, gradual decline across a template | Fetch raw HTML and compare against the rendered DOM | Server-render the templates that carry organic traffic |
| Structured data not rebuilt | Clicks down, impressions and positions roughly flat | Check rich result reporting and markup by template | Reimplement the markup that existed before |
| Index bloat from new URL patterns | Indexable URL count up sharply; crawl spread thin | Compare indexable URL counts against the baseline | Canonicals, robots rules or routing on the new patterns |
| A directive escaped to production | Sharp, fast, site-wide decline within days | Check robots.txt, meta robots and X-Robots-Tag in production | Remove it, then request reindexing |
When this applies
- A platform or CMS change has shipped and traffic has fallen.
- URLs were preserved, so redirects are not the obvious suspect.
- The decline started within six weeks of launch.
When to look elsewhere
- URLs changed — start with redirect coverage instead.
- The decline predates the migration.
- The drop coincides with a known algorithm update and affects competitors too.
The one-hour diagnostic
Run in this order — it moves from the fastest and most catastrophic to the slowest and most gradual.
- 01
Check production directives
robots.txt, meta robots and the X-Robots-Tag response header on the live site. Headers are invisible in page source, so check the response, not the markup.
Output Directive status, pass or fail
- 02
Compare indexable URL counts
New count against the pre-migration baseline. A large unexplained increase means the platform is generating URLs the old one did not.
Output URL count delta
- 03
Diff word counts by template
Grouped by template rather than by URL, so a systematic reduction shows as a pattern instead of scattered noise.
Output Word count comparison
- 04
Diff internal link counts
Inbound internal links per URL. This is what reveals which pages lost support when navigation or sidebar modules changed.
Output Internal link comparison
- 05
Fetch raw HTML for each template
Confirm body copy and internal links are present without JavaScript execution. View source, not inspect element — they show different things.
Output Rendering status by template
- 06
Check structured data coverage
Which templates emitted markup before and which do now. Rich result losses show as falling clicks against flat impressions.
Output Markup coverage comparison
Questions people ask before starting
If URLs did not change, how can a replatform lose traffic?
Rankings attach to what is at a URL, not to the URL itself. A replatform rebuilds every template, so copy volume, heading structure, internal links, structured data and rendering can all change while the address stays identical. That is enough to move rankings.
How quickly do these problems show up?
A directive escaping to production shows within days and is sharp. Everything else is gradual — two to six weeks — because it depends on Google recrawling and reprocessing pages at its own pace. A slow decline is not evidence that the migration was not the cause.
Can this be fixed after launch?
Usually most of it. Copy can be restored, links rebuilt, markup reimplemented, rendering changed. Recovery takes another recrawl cycle, so expect weeks rather than days. The exception is content genuinely deleted with no backup, which is why the pre-migration crawl matters.
Migration coming up?
If this raised a question about your own move, send the specifics — the launch date and what is changing is enough to start.
- Reply
- Typically within one business day.
- Hours
- Monday to Friday, 9am–6pm US Eastern.
- First call
- Scoping, not a pitch. No deck.