Search traffic fell after the replatform: working back through the map

Bucket the loss by URL class before you form any theory about it. Take 30 days of server logs from before the cutover, keep every URL that received at least one organic entry, and classify each into a class: article, section index, tag or topic archive, author page, paginated list, on-site search results, feed endpoints, image and media paths, legacy subdomains, and the sediment left by whatever migration happened before this one. Then run that URL list through a checker that records the final status code, the number of hops and the final URL. Join the two. The resulting table is the diagnosis, and it usually takes under an hour to build.

Work from logs, not from a rankings tool

The reason to work from logs rather than from a rankings tool is that rankings tools report the classes they were told to track, which are almost always articles and section pages. The classes that break in a migration are the ones nobody was tracking, because nobody thought of them as pages — an author archive with a decade of bylines on it, a tag page that a Wikipedia citation points at, page 7 of a paginated list that still holds a link.

The classes that break, and why each one is missed

That last row costs twice. Re-deriving renditions changes the address, and the transform step is also where embedded provenance and rights metadata is quietly stripped — the loss traced in keeping provenance metadata alive from camera to CDN. A migration is the single most likely moment for a publisher to lose both at once.

Five causes, and the fingerprint each one leaves

1. A whole class was never in the map. The most common cause by a wide margin. The fingerprint is a step rather than a curve: traffic for URLs sharing one path segment goes to near zero on the cutover date while everything else holds. Group your 404 log by path segment and the answer is the first row.
2. Redirects land somewhere that is not the equivalent. Everything technically resolves, so nobody flags it. Search engines treat a redirect to an unrelated page as a soft 404 rather than as a redirect, and Google Search Console labels them as such in its page indexing report — check that report before assuming a 301 did its job.
3. Chains and loops. Old to interim to new, where the interim path came from a migration two platforms ago, and every hop crossing http to https or www to apex adds another. Any hop count above 1 is worth collapsing; the fingerprint is in the checker output, not in any traffic graph.
4. Canonical relationships between duplicate copy were lost. Publishers run agency copy, and the old platform expressed which copy was canonical. After the move every duplicate is self-canonical, the versions compete, and which one ranks becomes arbitrary. The fingerprint is a large set of URLs indexed but receiving nothing, with identical opening paragraphs across mastheads.
5. The origin is slow on redirect. If the map is evaluated by the application rather than at the edge, a crawler working through hundreds of thousands of old URLs hits your origin on every one of them. Response times rise, crawl rate falls, and recovery stalls for reasons that have nothing to do with the map's contents. The fingerprint is a high time to first byte specifically on 301 responses in the logs.

Repair order: inbound links first, volume second

1. Export referring domains per URL from a backlink tool and rank the broken classes by external links, not by lost sessions. Rankings recover once the mapping is right; links, once someone gives up on a dead URL, do not come back.
2. Fix whole classes with a rule, not URL by URL. A class that broke because a path pattern changed is repaired by one pattern; a class that broke because identifiers changed needs a lookup table generated from the migration's own mapping records.
3. Collapse every chain to one hop, including the ones that were fine before the migration and gained a hop during it.
4. Replace generic-destination redirects with item-level ones. This is the slowest step and the one that most needs the migration's field mapping, which is exactly the artefact produced by mapping legacy stories into a model that did not exist.
5. Move the map to the edge before re-submitting anything, so the recrawl does not land on your origin.
6. Re-submit sitemaps class by class, and watch the classes separately. An aggregate curve will not show you that authors recovered and tags did not.

Deriving item-level destinations for a large archive is a matching problem — old title, old date, old byline against the new record set — and it is one of the few places in a migration where automation genuinely pays for itself rather than adding a layer to debug. It is the sort of bounded, verifiable work we build as AI agents and automation: a candidate match with a confidence score, a human confirming the low-confidence tail, and a mapping table as the output.

A redirect map is not a launch task. It is a permanent index of every address the outside world still believes in.

How to know it worked

• Track entries and impressions per URL class weekly, on one chart with one line per class. The aggregate line is the one that will mislead you for a quarter.
• Track hop counts and non-200 finals on the full old URL set, not a sample. This is a cheap nightly job and it catches the redirect somebody removed in a cleanup six months from now.
• Watch crawl statistics for response time on redirect responses specifically, because that is the number that decides how fast the archive gets re-processed.
• Keep an eye on the classes that produce no traffic signal — feeds, image paths, embeds in third-party pages. They break silently and are usually discovered by a partner rather than by you.
• If stories are also appearing late or twice on the new platform, that is a separate defect in the publish path and is diagnosed in scheduled stories that go live late or twice.

The uncomfortable finding, most of the time, is that the redirect map was nobody's deliverable. It sat between the outgoing platform's knowledge and the incoming platform's schema, and both parties assumed the other owned it. That is a scoping failure rather than a technical one, and it is worth settling in writing before a migration starts — the kind of question covered in choosing an AI development partner and in the sequencing work of cutover week for a publishing replatform.

The rest of this silo sits under CMS and publishing platform engineering, and the platform work we do for newsrooms is described in our media and publishing practice.

• migration
• redirects
• technical SEO
• publishing platform