Why we always track redirects from day one of a migration
Traffic drops after site migrations almost always trace back to the same thing: URLs that changed without proper redirects in place. The work to prevent it starts before a single URL moves.
Traffic drops after site migrations have a reputation for being mysterious. A company moves to a new domain, restructures its URL hierarchy, or switches CMS, and a few weeks later, organic traffic has dropped sharply. The explanation offered is usually “it’s a Google thing” or “there was an algorithm update.”
Most of the time, that’s not what happened.
The drops are almost always traceable to redirect gaps: URLs that changed without proper 301 redirects in place, redirect chains that dilute signal, or temporary redirects left to do a permanent job. None of that is mysterious, and all of it is preventable if the tracking work starts before the migration goes live.
What actually happens when a URL changes
Google’s index is built around URLs. When a page moves to a new address, Google treats the destination as a new URL unless it receives a 301 redirect telling it otherwise. A 301 is a permanent redirect: it signals to crawlers that the old URL has moved permanently and instructs them to transfer the accumulated signals to the new address (inbound links, crawl history, ranking context).
Without a 301, none of that transfers. Google finds the old URL returning a 404, or worse, a 200 with no content. The new URL starts with no history. If a page had inbound links pointing to the old address, those links no longer pass any authority to the new destination.
A 302 redirect behaves differently still. 302 means temporary move, so Google continues to index and rank the original URL rather than the destination, because the directive says “this is temporary, keep treating the old one as canonical.” Teams often use 302s during development or staging and forget to update them before launch. The result: the new site is live, but Google is still working from the old URL structure.
Google’s own documentation on site moves with URL changes notes that the process of fully recognising a migration can take several months. That timeline starts from when crawlers first encounter the redirects. If the redirects aren’t in place on day one, the clock doesn’t start.
Why the work has to start before anything moves
The instinct is to treat redirect mapping as a post-launch cleanup task. Fix 404s as they appear in Search Console, add redirects for the broken ones, iterate. The problem is that by the time 404s appear in Search Console, crawlers have already indexed the new state. You’re trying to correct a signal Google has already recorded.
The correct sequence starts with a complete URL inventory before the migration. Every URL in the old structure needs to be accounted for, including the homepage, top-level category pages, blog posts, product pages, paginated archives, filtered views, and author pages.
For any URL in that inventory that will change address in the new structure, a 301 redirect needs to be mapped before the first deployment. For any URL being removed entirely (consolidated content, pages that no longer serve a purpose), the team needs to decide: redirect to the closest relevant page, or remove it cleanly and let it return a 404.
The redirect map is a spreadsheet or database that pairs every old URL with its new destination or its removal decision. It gets built before any live URL changes. Building it after is like writing a map after you’ve already moved.
The pre-launch process
A pre-migration URL audit involves crawling the current site in full, then pulling the active URL list from Google Search Console and cross-referencing both. Search Console often surfaces URLs that a crawler misses because they haven’t been linked to recently but still receive organic traffic.
Once you have the full inventory, you map each URL to its destination in the new structure. For CMS migrations the URL structure changes are often more extensive than clients expect, because platforms have different URL generation defaults. Every difference needs a redirect.
After the map is built, you validate it on staging before launch. You check that every redirect in the map is actually implemented (not just planned), that redirect chains don’t exist (A redirecting to B, B redirecting to C should all be collapsed to direct A-to-C redirects), and that no redirect loops exist.
Most teams skip the staging validation under time pressure. That’s where most redirect problems originate.
What to monitor after launch
Google’s own guidance says to expect a site move to take weeks to months to fully process. Googlebot revisits pages on a schedule determined by how often they change and how authoritative they are, so lower-traffic pages may not be re-crawled for some time after the migration.
Post-launch monitoring needs to run for at least three months. The metrics to watch in Search Console: crawl errors (specifically 404s, which indicate URLs that weren’t captured in the pre-launch inventory), index coverage (how quickly the new URLs are being indexed), and organic traffic by URL group.
The traffic by URL group view is usually more informative than total traffic. If the homepage and main service pages recover quickly but blog content stays flat, that tells you something specific about where the redirect mapping broke down.
For larger migrations, sites with thousands of URLs across multiple content types, it also helps to monitor crawl rate. A sudden drop in Googlebot crawl activity sometimes indicates redirect chains are burning through crawl budget without returning useful signals.
Where the gaps typically appear
Redirect chains are the most common issue. A site that has been migrated more than once often has layered redirects: an old URL from 2019 redirects to a 2022 URL, which now redirects to a 2026 URL. Each additional hop degrades signal transfer. Google recommends resolving these to direct redirects, and redirect audits routinely surface multiple chains on sites with a history of migrations.
Pagination is almost universally overlooked. /blog/page/2, /blog/page/3, and so on are real URLs with crawl history. They’re rarely included in redirect maps, which produces a large number of 404s that didn’t need to exist.
Faceted navigation causes the same problem on product and e-commerce sites. A URL like /products?category=enterprise&type=software may have accumulated inbound links or organic traffic. If the new site generates different parameter strings or uses a different filtering architecture, those URLs need to be mapped.
Internal links in existing content also break. If post A links to post B using the old URL, and post B now lives at a new address, that internal link will follow the redirect, but updating it to the canonical new URL is still better practice. Post-migration content audits that update internal links tend to fall off the project scope, and they add to the crawl overhead over time.
What the deliverable looks like
At the end of a migration project, three things should be in place: a completed and validated redirect map covering every URL in the pre-migration inventory, a post-launch monitoring setup in Search Console with the relevant views configured, and a named owner for the monitoring work for the first three months post-launch.
The monitoring owner doesn’t need to be technical. They need to be able to read a crawl error report, notice when a metric moves outside the expected range, and know who to escalate to. Checking the dashboard once at launch and assuming the migration is clean isn’t monitoring.
Pre-migration redirect work produces nothing a user ever sees and doesn’t ship a feature. It protects years of content, inbound links, and crawl history from being reset by a technical decision that takes effect in an afternoon.
The projects where this matters most are the ones involving significant URL restructuring: large editorial archives, product catalogues with deep filtering, sites that have been iterated on for years.
If you’re planning a migration and want to understand what the tracking process looks like in practice, book a call.
Sources
We're booking content platform
engagements for 2026.
Twenty-five minutes to walk through the work and decide if we're the right team for it. Scoping and a fixed price come after.