Traffic drop after a website redesign: find the cause and recover

Before you take the new site apart, make sure the drop belongs to it. Three checks take ten minutes:

• the date. In the Search Console performance report, set a date range that spans the launch and look at the clicks line. A drop that starts within days of go-live points at the relaunch; one that started a month earlier does not.
• the shape. Compare the four weeks after launch with the four weeks before, on the pages tab. If the loss is concentrated on a set of urls that now return nothing, it is a redirect problem. If every page lost a little, look at seasonality, a core update, or a sitewide technical change.
• the season. Compare with the same weeks last year. A shop that relaunched in January is comparing itself with December.

Some movement is expected. Google’s site move documentation says to “expect temporary fluctuation in site ranking during the move” and that rankings settle down over time. Fluctuation is general and recovers. A drop that sits on specific urls, or keeps getting worse after a few weeks, is something broken.

Work from the cause that loses the most and is cheapest to confirm, to the ones that take longer to diagnose. Each step rules out one explanation before you spend time on the next.

Take the list of urls the old site ranked with and request each one on the live site. Every url that answers 404 is a page whose rankings and links are being thrown away — Google removes urls that return a 4xx from the index once it recrawls them, and the links pointing at them now point at an error page.

Search Console shows the same thing from Google’s side: the Page indexing report lists urls under Not found (404), with up to 1 000 examples per reason. A count there that jumps after the launch date is the relaunch’s missing redirects showing up as Google recrawls them.

The difficulty is the list itself. If nobody built a redirect map, nobody kept a full list of old urls either — and a crawl of the new site cannot produce one. Where to get it when the old site is gone is covered below.

A relaunch with redirects can still lose traffic if they are the wrong kind. Follow each redirect on the same list and look for four patterns:

everything to the homepage — Google’s move documentation says not to redirect many old urls to one irrelevant destination such as the homepage, because it can be treated as a soft 404. The redirect exists, but nothing is passed on.

302 instead of 301 — per Google’s redirect documentation, a permanent redirect is a signal that the target should be canonical; a temporary one is not. Some platforms create 302s by default.

chains — /old → /old/ → /new → /new/. Each hop is another request; flatten them so every old url points at its final target.

javascript redirects — a client-side redirect only works once the page is rendered. A server-side 301 is always the safer choice.

A redesign often comes with a copy rewrite, and a page can lose rankings even with a perfect redirect if it no longer says what it ranked for. Open the old version (from a backup or the Wayback Machine) next to the new one for your top pages and compare:

• the title and the h1 — a clever new headline in place of the term people searched for.
• the body text — long pages cut down to a hero and three cards.
• merged pages — five service pages folded into one, each old url redirected to it, none of the five topics covered in depth any more.
• content moved behind tabs or into javascript that renders late.

This is the one cause a redirect map cannot fix, and the one that takes longest to recover from, because Google has to re-evaluate the page rather than just follow a redirect.

A new navigation usually links fewer pages than the old one. Pages that used to be one click from the homepage are now four clicks deep, or linked from nowhere at all. Crawl the new site from the homepage and compare the list against the pages that matter: any important page the crawl does not reach is an orphan now. Link it again from the navigation, a hub page or related content.

Also check the links inside the content: body text full of links to old urls means every internal link goes through a redirect, which works but wastes a hop. Update them to the new urls.

Staging sites are blocked from search on purpose, and the block sometimes survives go-live: a noindex in a template, a Disallow: / in robots.txt, or a cms setting that discourages search engines. Google’s move guide lists removing these as a step of its own. Check robots.txt by hand and run your top pages through URL Inspection, which shows whether indexing is allowed.

One detail matters here: Google’s noindex documentation says a page blocked by robots.txt is never fetched, so the crawler never sees a noindex on it either. Fix the robots.txt first, then the meta tags.

A canonical tag tells Google which url to index. After a relaunch it can point at the staging domain, at the old domain, at the http version, or — when a template sets one fixed value — at the homepage for every page. URL Inspection shows both the user-declared canonical and the Google-selected canonical; if they differ, or the declared one is a url you do not want indexed, fix the template so every page carries a canonical to its own final url.

If step one found 404s, the fix is the redirect map that was not built before launch. Building it afterwards works the same way, except that the old site usually cannot be crawled any more. The old urls come from records instead:

the Search Console performance export — set the date range to the months before the launch and export. The download contains a pages file with each url’s clicks and impressions — a url list and a priority list at once (see Google’s note on the export format). The interface export caps at 1 000 rows.

Page indexing → Not found (404) — the urls Google has already tried and failed, up to 1 000 examples. These are confirmed losses.

the old sitemap.xml — from a backup, the old cms, or a capture in the Wayback Machine.

server logs — every request that now gets a 404, including pdfs and campaign urls no other source lists.

In Silentfrog, old site already offline? takes those files as the old side and crawls only the new site (when the old site is gone). Each old url is matched against the new site’s pages; because a url list carries no titles, matching runs on the url alone, so more rows land in needs review. Then import the same Search Console export as traffic data: the table gains a clicks column, and you work through the urls that carried traffic first (traffic data). The first 50 old pages are free.

Export the redirects file for your platform, import it, and request a sample of the old urls again: each should answer 301 and land on a 200 in one hop. The orphan sources are covered in more depth in finding the urls nothing links to.

There is no fixed number. A late redirect only takes effect when Google recrawls the old url, which happens sooner for popular pages and later for rarely visited ones. Google’s move guide says that for medium-sized sites it can take a few weeks or more for Google to start showing new urls in place of old ones, and longer for large sites — and that is for a move done right from the start.

What you can watch: in Search Console, the old urls should move from Not found (404) to Page with redirect, and the new urls should start collecting the impressions the old ones lost. If a page stays down long after its redirect is recrawled, the cause is probably content (step three), not the redirect.

• Confirm the drop starts at the launch and sits on specific urls before blaming the redesign.
• Check missing redirects first: old urls that answer 404 lose their rankings and their links.
• Then wrong redirects (homepage, 302, chains), content, internal links, staging noindex and canonicals — in that order.
• Without the old site, rebuild the url list from the pre-launch Search Console export, the 404 report, the old sitemap and the logs.
• Prioritise by clicks, redirect one-to-one, and check each one resolves in a single hop.
• Recovery happens as Google recrawls the old urls — the sooner the redirects are live, the less is lost.