Content migration forensics: how to find what a platform move left behind

When a site changes platform, the articles usually survive. The search signals attached to them frequently do not. Here is the three-layer audit that finds the difference, and what it surfaced on a legal site that had just moved from a website builder to a custom framework.

The problem

A developer rebuilt a law firm’s site on a modern framework. The brief had been to keep the content. By every visible measure the brief was met: the articles were there, the design was better, the new site had canonical tags, hreflang and structured data that the old one lacked.

The question the client could not answer was narrower. Did the search signals move with the content, or only the content? Those are different things. A page can be present, readable and beautifully marked up, and still have lost every ranking it held, because the address it earned those rankings at no longer resolves to it.

Nobody had the answer because nobody had compared the before and the after as data. The conversation was running on impressions — the developer’s, the client’s, mine — and impressions are exactly what a migration audit exists to replace.

The method

Three layers, run in this order. The order matters: layer A is the only one that becomes unavailable over time, because Search Console’s window is finite.

1. Layer A — export what the site earned before the move

   Full Search Console performance export for the longest available pre-migration period: pages, queries, clicks, impressions, average position. Export it first, before touching anything else. Data that has aged out of the window cannot be recovered later.

2. Layer B — read the new site as a machine reads it

   Pull the current sitemap. Then open every URL that appeared in layer A and record what it returns now: status, final address after any redirect, canonical, H1, byline, dates. Not what the CMS says is published — what the URL actually serves.

3. Layer C — map old to new, ranked by impressions

   One row per pre-migration URL, sorted by impressions descending, never alphabetically. Classify each as retained, redirected, replaced or gone. The rows at the top are the only ones worth an argument.

Everything below came out of running those three layers on one site. Each finding is stated as what the audit observed, not as what anyone intended.

What the audit found

1. Only part of the content moved to the new URL structure

The new blog listed 13 articles. Eight sat on the new address pattern. Five were still on the old platform’s pattern, linked from the new blog index but never migrated. Those five carried the majority of the site’s article impressions — which is to say the articles that mattered most were the ones that had not been moved.

2. Translations migrated; their English originals did not

This is the finding a purely technical crawl would miss. The Russian and Lithuanian versions of four articles had been rebuilt on the new URL structure. Their English originals stayed on the legacy pattern. The result is that the language versions of a single article now live in two different structures, which makes a clean hreflang cluster between them difficult to express and easy to get wrong.

3. One article was gone, and its address had been reused

An article on employer immigration compliance was absent from the blog index and from the sitemap. Its old address had not been redirected and did not 404 — it now served an unrelated service page. On the firm’s other live domain, the same slug returned 404. The only surviving copy of the text was in a search engine’s cached version, which is signed, short-lived and about to expire.

That combination — address alive, content replaced, no redirect, no archive — is the worst of the four outcomes, because monitoring tools report the URL as healthy. Nothing is broken. The article has simply stopped existing while its address carries on.

4. A quarter of the site’s clicks were landing on leftover default pages

Twenty URLs were indexed under the old builder’s default page names — the equivalent of /blank, /blank-1, /blank-2 and so on. Between them they drew 30 clicks against the site’s total of 122: a quarter of everything the site earned, arriving on pages nobody had named, let alone written a title for.

These are not junk to be deleted. They were real landing pages under meaningless addresses, and they need to be matched to their new equivalents by what they contained, not by what they were called.

A redirect map built from URL similarity will get the leftover pages wrong every time, because their names never described their contents.

The checklist this produces

• Export Search Console before the migration, not after. This is the only irreversible step.
• Check every pre-migration URL that earned impressions, not a sample, and sort the list by impressions.
• Classify outcomes into four states — retained, redirected, replaced, gone — and treat “replaced with no redirect” as the most serious, because it looks healthy.
• Verify language-cluster integrity per topic: all language versions of one article should sit in one URL structure.
• Match default-named pages to new equivalents by content, never by slug similarity.
• Confirm the sitemap contains only canonical, 200-returning URLs, and that legacy addresses are not sitting in it alongside their replacements.
• Archive anything that has genuinely gone before the cached copy expires. A cache is not a backup and has a deadline.