A launch happens and the organic traffic chart bends downwards. The release gets the blame, and sometimes it deserves it, but a launch is also when other things can change at once. This article sets out what Google’s documentation says to expect after a move, the mistakes it lists, and how to separate the move from other causes. Where we go beyond the sources, we say so.
For the wider picture of causes, see diagnosing a traffic drop before acting on it.
What Google says to expect after URL changes
Google’s guide to debugging drops in Search traffic is direct: if you change the URLs of existing pages, you may experience ranking fluctuations while Google recrawls and reindexes your site. As a general rule, a medium-sized website can take a few weeks for Google to notice the change, and larger sites can take longer.
Its guidance on site moves with URL changes repeats the point and adds detail: for medium-sized sites it can take a few weeks or more before the new URLs gradually replace the old ones in results, and longer for larger sites. The speed depends largely on the number of URLs and on server speed, and Google describes the temporary fluctuation as normal.
Neither page gives a number of days after which a drop counts as a failure. The condition is that a drop is not recovering. Our reading is that this needs a baseline recorded before launch.
The mistakes Google lists when a move stalls
The troubleshooting section of the site move page lists common mistakes that can prevent the new site being indexed completely. As the page stands, there are five:
- noindex or robots.txt blocks that were only needed for the migration and were not removed.
- Incorrect redirects. Google says it frequently sees redirects to the wrong, non-existent URLs on the new site, and suggests checking Search Console for unusual numbers of “Not found” errors or crawling your own site.
- Other crawl errors, as a spike in errors on the new site during migration events.
- Insufficient server capacity. Google crawls the new site more heavily than usual after a move, because crawls of old URLs are redirected to it on top of normal crawling.
- Sitemaps not updated with the new URLs.
The same page covers other items earlier, as preparation rather than troubleshooting: self-referencing canonicals on new URLs, hreflang annotations updated to the new URLs, internal links changed to the new URLs, and a 404 or 410 for content that is not moving. They are sensible checks when a move stalls, though Google does not list them as troubleshooting.
Google’s move pages do not discuss rendering or performance regressions. In our reading they belong in the review anyway, because a redesign can change how content reaches the page even when every URL is mapped correctly. Our article on technical causes of a traffic drop covers that category of problem.
Moves that change no URLs, and ordinary releases
Not every launch moves URLs. Google’s page on changing your web hosting covers moves that leave URLs alone, such as switching hosting providers or moving to a CDN. No redirects are involved, but the page still raises matters such as whether a firewall blocks Googlebot.
An ordinary release that changes templates is not described as a site move. Google’s traffic-drop guide classes technical issues as errors that can prevent crawling, indexing or serving, and gives a misplaced noindex tag as an example, noting that because it depends on Google recrawling the page, the loss of traffic would be slower. Our reading: the shape of the loss, gradual or a sudden step, hints at the mechanism.
Separating the move from other causes
Two questions do most of the work: what changed and when, and which URLs lost traffic.
On timing, Google’s guide suggests a 16-month view and comparing the last three months with the previous period or the same period a year earlier, which shows whether the dip repeats each year. Check the data anomalies and reporting side first, too. For a launch that coincides with a Google update, see what to check after a Google update.
On scope, the guide says to use the Pages table to see whether the loss is across the whole site, a group of pages or one important page, sorting by clicks difference. For a group of pages it suggests the URL Inspection tool on a few of them. Our reading: loss concentrated in redirected, rebuilt or re-templated URLs points to the launch; loss across untouched URLs points elsewhere. Test that inference; it is not a rule.
What to compare before and after
Google’s tools show the state after launch, so the comparison needs a record from before it. These are the comparisons we would want (our reading, built on the mistakes Google lists):
- URL inventory. Which old URLs had traffic or links, and where each now goes. Google suggests starting with URLs in sitemaps, those with the most traffic, and those with links in Search Console.
- Status codes. What each important old URL returns now, and what the destination returns. This is where “redirects to non-existent URLs” shows up.
- Indexability. Whether the new URLs carry noindex or are blocked by robots.txt, and whether the canonical is what you expect.
- Templates. Whether titles, headings, main content and internal links on a changed template still match.
For individual URLs, Google’s URL Inspection tool reports the indexed version of a page, and its live test checks the current version. It can show the rendered page and the Google-selected canonical; the indexed result may differ from the live page. The Crawl Stats report gives the site-level view: its host status shows whether Google met availability problems, and its crawl responses table groups the responses Google received, so a rise in errors after launch is visible there.
Telling a normal transition from a problem
From the sources, a normal transition has three features: it follows a change to URLs, it is temporary, and the new URLs gradually replace the old ones in results. A problem is signalled by the drop persisting, which is Google’s own trigger for the troubleshooting list, or by evidence of a fault in that list.
Our reading, which Google does not state: evidence matters more than elapsed time. A redirect returning 404 or a noindex on a key template is a fault on day two, and waiting will not fix it. Equally, clean redirects, indexable pages and healthy crawl responses, with traffic still settling inside Google’s window, are a reason to keep monitoring.
Where this fits at Cultured Digital: launches and what follows
Migrations are part of our technical SEO work: planning and redirect mapping, pre-launch testing, launch-day monitoring and post-launch recovery, for single sites and multi-market structures. The migrations guide sets out the stages, and rebuilds and migrations covers moves that are part of a build, with redirects mapped before launch and tested after. Our SEO QA checks releases before and after launch, so regressions are caught early.
When traffic has already fallen and the cause is unclear, an SEO audit finds the cause and then says what to do first. We do not promise rankings or traffic numbers. For launch checks, see WordPress launch checks that protect rankings, and for the redirect detail, redirect chains and site moves. If a security or spam problem is a possibility, read that article too.