Why did traffic fall after we launched the new site?

Google gives a timeframe, and it is longer than most people expect

This is the number to hold onto when somebody wants to panic in week two.

Google's guidance says that as a general rule, for medium-sized websites it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones, and for larger sites even longer. It adds that the speed depends on how many URLs there are and how fast your server is.

Google also describes what finished actually means. To consider a site move complete, Googlebot has to visit every URL on your old and new site at least once. That is a crawling job, and crawling takes as long as it takes.

Two practical consequences. First, judging a relaunch after ten days is judging an incomplete process. Second, there are things that genuinely speed it up: Google says submitting a sitemap can help make the discovery process quicker.

One more piece of advice worth having before the next launch rather than after this one. Google suggests that if your traffic is seasonal or dips on certain weekdays, it makes sense to move during those recurring dips, so fewer people are affected and more of the server is available for crawling.

A drop that does not recover is usually the redirects

Once you are past a few weeks and nothing has come back, stop looking at the design and start looking at the addresses.

Every page that changed address needs to tell browsers and search engines where it went. Google is explicit about the mechanism: for a permanent redirect its indexing pipeline uses the redirect as a signal that the target should be the canonical address, meaning the one it shows in results. For a temporary redirect it follows the link but does not use it as that signal.

So the single most expensive mistake in a relaunch is using a temporary redirect for a permanent move. Everything works for humans. Every link resolves. And Google keeps showing addresses that now bounce, while treating the new pages as unproven.

Google's recommendation is short: if you need to change the address of a page as it appears in search results, use a permanent server side redirect whenever possible. It also says client side redirects are a last resort where no server side option exists.

On the fear that usually accompanies this, Google is reassuring and specific: do not worry about link credit, because 301 and other permanent redirects do not cause a loss in PageRank. The damage comes from redirects that are missing, wrong, or chained, not from redirecting.

Chains and missing maps are the two specific failures

Two things go wrong often enough to check by name.

The first is chaining. Google says Googlebot can follow up to 10 hops in a chain of redirects, but advises redirecting to the final destination directly, and keeping any chain low, ideally no more than 3 and fewer than 5. Chains happen quietly when a site is relaunched twice, or when an old rule is left in place next to a new one. Mozilla is blunter about the human cost: every redirect is an extra request, so they should be kept to a minimum.

The second is the missing map. Somebody has to write down which old address becomes which new one. When that list does not exist, the shortcut is to send everything to the home page. That is worse than it sounds, because a visitor looking for a specific service lands on a generic page and leaves, and the specific page that used to rank has no successor to inherit anything.

A map is not a complicated document. One row per page: the old address on the left, the new one on the right. Twenty rows covers most small sites. Written while the old site is still live, it takes an afternoon.

There is a structural choice worth knowing too. Google recommends that small and medium sites move all URLs simultaneously rather than one section at a time, because it helps the algorithms detect the move and update the index faster. Larger sites can go in sections to make problems easier to spot.

What to check, and in what order

Work down this list. The first three cost nothing but time.

• Take a list of your top twenty pages from before the launch and open every one of those old addresses. Each should land on the matching new page, not the home page and not an error.
• Check the response code on those old addresses, not just whether they work in a browser. A 302 on a permanent move is the expensive mistake and looks identical to a visitor.
• Look for chains. If an old address redirects to something that redirects again, fix it to point straight at the final page.
• Open Search Console. Google names it directly as the tool for a site move and points at the Index Status report for a broad view and the Sitemaps report to see how many submitted URLs are indexed.
• Confirm a sitemap for the new site has been submitted, since Google says that speeds discovery.
• Compare like with like on dates. A launch that coincided with a seasonal dip will look worse than it is, and comparing to the same period last year separates the two.

How to tell a normal dip from a real problem

The shapes are different, and once you know them you can usually tell within a minute.

A normal dip falls and then climbs back gradually over several weeks as pages get recrawled. Impressions usually recover before clicks. Different pages recover at different times, because they are crawled at different times.

A redirect problem looks flat. It drops and stays down, and the pages that used to bring people in stay missing. Search Console shows the old addresses as errors or as not indexed rather than as moved.

A drop that is sharp, total, and affects the whole site at once is usually neither of those. It is more often something blocking crawling altogether, which is worth ruling out first because it is the quickest to check and the most complete in its damage.

The uncomfortable truth is that all of this is far cheaper to arrange before a launch than to repair after one. A redirect map written while the old site still exists takes an afternoon. Reconstructing one from an archive after the fact takes considerably longer and is never quite complete.

Building and moving websites is one of the things we do, so if the graph has a cliff in it and nobody can say why, that is work we take on.

Terms used on this page

• 301 redirect

Sources

• Site Moves and Migrations
• Redirects and Google Search
• Redirections in HTTP (MDN Web Docs)

Last reviewed 2026-09-11.