Our organic search traffic fell after the redesign — how do we find out why and what do we fix first?

Rankings attach to pages, not to sites. A redesign quietly changes which pages exist. Old URLs disappear, copy gets tightened to fit a new layout, navigation gets simplified and deep pages lose their inbound links. Google sees fewer pages, thinner pages, or pages it cannot reach.

This matters because the instinct after a traffic drop is to blame the new design or chase Core Web Vitals. In the migrations we run, the design is almost never the cause. Speed is almost never the cause either. A faster, better-looking page that lives at a new URL with no redirect is worth nothing in search.

So the first question is not “is the new site good?” It is “which pages used to exist, and where did each one go?”

A two to six week wobble after launch is normal. Google has to recrawl every changed URL, and it does not do that in a day. Rankings reshuffle, some pages come back higher than before, and total traffic sags in the middle.

Tell the two apart before you act. Open Search Console, set the comparison to the four weeks after launch against the four weeks before, and look at the page-level report rather than the site total.

Signs it is a normal dip: impressions hold roughly steady while average position moves around, and the losses are spread thinly across many pages. Signs it is a real loss: impressions for specific URLs go to zero and stay there, or a whole group of pages built from the same template vanishes at once.

The second pattern is not patience territory. Zero impressions on a page that had thousands means Google either cannot find it or has been told to ignore it.

The order matters because the checks get more expensive as you go down, and because fixing the wrong one first burns the recovery window while the drop compounds. A rewrite takes weeks. A missing redirect takes an afternoon.

Work down the list and stop when the numbers explain the shortfall.

Export the list of URLs that got traffic in the six months before launch. Analytics or Search Console will both give you this. Request each one and record what happens.

You are looking for three faults. A 404, which means the page is gone with nothing in its place. A redirect to the homepage, which Google often treats as a soft 404 and drops. And a chain, where the old URL goes to a second URL that goes to a third, which leaks signal at every hop.

The homepage redirect is the one that catches most teams, because the site looks fine. Nothing is broken. Every link works. But a guide that ranked for a specific query now resolves to a page about the company, and the ranking goes.

The fix is a one-to-one map: /guides/onboarding-checklist goes to /resources/onboarding-checklist, not to /resources. If a page genuinely has no successor, point it at the nearest parent page that answers a similar question, and accept you will lose some of it.

Do this check before anything else, and do not let anyone sell you a content rewrite until it is verified. We have seen teams commission new copy for pages whose only problem was a 404.

New layouts want shorter text. A designer trims a 1,400-word service page to 500 words so it sits well in a three-column grid, and half the phrases that page ranked for go with the cut.

Check the pages that lost traffic against the old version in the Wayback Machine. Two things to compare: total word count, and the H1 and H2 text. Headings carry a lot of what a page is understood to be about, and “Built for teams” replacing “Invoice approval software for finance teams” is a real change in meaning even though it reads better.

If a page dropped from 1,400 words to 500 and lost the queries its old subheadings named, that is your cause. Put the substance back. You do not have to restore the old layout, only the content the layout displaced.

A noindex tag or a blocked path in robots.txt survives the move from staging to live more often than anyone expects. The tell is a sudden and total loss across one group of pages, usually every page built from the same template, while the rest of the site is fine.

Check three things. The robots.txt file at your domain root, for Disallow lines covering directories that should be public. The page source of a lost page, for a robots meta tag containing noindex. And Search Console’s Pages report, which names the reason each excluded URL is excluded.

This is the cheapest fix on the list and the fastest to recover from. Remove the block, request indexing for a handful of the affected URLs, and the group usually returns within a couple of weeks.

Simplified navigation is usually good for people and sometimes bad for search. A menu that dropped from 40 links to 8 removed the only route to 32 pages. If nothing else on the site links to them, Google has no reason to keep crawling them and no signal that they matter.

Run a crawler over the new site, Screaming Frog will do it free up to 500 URLs, and look for pages with zero inbound internal links. Compare that list against the pages that lost traffic.

The fix is not to put everything back in the menu. That trades a search problem for a usability one. Instead add hub pages and in-body links: a resources index that lists every guide, related links at the foot of each article, and links from the pages people do reach to the ones they no longer can.

Before you spend anything, look at what the lost pages were actually doing. In our projects, a meaningful share of a traffic drop sits on pages that never converted anyone: old blog posts on topics you no longer sell, job listings, event pages from three years ago.

If a page brought 800 visits a month and zero enquiries, restoring it buys you a nicer chart. That is not the same as buying revenue. Judge the loss by page value, not by session count.

Rebuilding pages you deliberately retired is usually the wrong instinct. You removed them for a reason, and the reason has not changed because a graph went down. Redirect them to the closest live page and move on.

The lines worth defending are the ones that earn: product and service pages, pricing, comparison pages, and the two or three guides that bring people who become customers.

Freeze three things through launch: the URL set, the page titles, and the body copy on your top traffic pages. Redesign around them. This is what we do on Glasspage migrations, and it works because it separates two variables. If traffic changes and the pages did not, the cause is technical and findable.

Concretely, that means your top 20 pages by organic traffic keep their existing paths, their title tags and their text. Everything else changes freely. The new design system handles the layout, spacing and components around content that stays put.

Once traffic is stable again, usually four to six weeks after launch, revisit those pages one at a time. Change the copy on one, watch it for a fortnight, then do the next. You get the improvements without ever losing the ability to tell what caused what.

A redesign should change how your pages look. It should not change which pages exist, unless you decided that on purpose.

If you have one afternoon, spend it on the redirect map. Export the URLs that had organic traffic before launch, request each one, and list every 404 and every redirect that lands on the homepage. That list is either your answer or it rules out the most common cause, and both outcomes are worth the afternoon.

If you would rather someone else ran the check, that is the kind of work we do at the start of a migration.