Why Traffic Dropped After A Website Redesign

Updated September 2026 · Written and maintained by the Progression Agency strategy team

Post-redesign traffic losses have a short list of causes and most are fixable within the new design rather than by reverting it. This page covers redirects first because they account for more losses than everything else combined, then indexing directives left from staging, content trimmed for appearance, weakened internal linking, rendering dependencies that hide content from crawlers, broken analytics that make traffic look lost when it is not, and what normal recovery actually looks like.

Redirects are the first thing to check and the most common cause

If URLs changed and old addresses were not permanently redirected to their new equivalents, every accumulated signal attached to those addresses is lost. This single omission accounts for more post-redesign traffic collapses than everything else combined.

Test it directly rather than trusting the launch checklist. Take twenty of the old URLs that previously received the most traffic, request each one, and record what comes back. Each should return a permanent redirect to the page that replaced it. A page that returns not-found has lost everything, and one that redirects to the homepage has lost nearly as much, because the homepage does not answer the query the old page ranked for.

The homepage-redirect pattern is worth calling out because it looks like diligence. Somebody redirected everything rather than nothing, which prevents error pages and preserves almost no relevance. Each old URL needs its closest actual equivalent.

Check whether the new site is being blocked entirely

A staging environment carries directives that prevent search engines indexing it, and those directives are supposed to be removed at launch. Frequently they are not.

Two mechanisms cause this and they need checking separately. A robots file that disallows crawling, and a noindex directive in the page markup or headers. The second is more dangerous because it is invisible in the robots file and can sit in a template applied to every page.

This produces a total collapse rather than a decline, usually within days to a couple of weeks as pages are recrawled and dropped. If traffic did not decline so much as stop, check this before anything else — it takes two minutes and is the difference between a fixable oversight and weeks of misdirected analysis.

Check the robots file first

It is one request and rules out the simplest total blocker.

Then check for noindex in the markup and headers

It can be applied by a template or a plugin setting and is not visible in the robots file.

Check index coverage reporting

It will name the reason pages were excluded rather than leaving you to infer it.

Confirm the sitemap points at the new URLs

A sitemap still listing the old structure slows discovery of the new one considerably.

Content removed during a redesign takes its rankings with it

Redesigns almost always reduce the amount of text on a site, because long pages look cluttered in a design review and the person deciding is looking at appearance rather than at what each paragraph was earning.

The pattern is consistent: explanatory sections cut for visual balance, frequently asked questions removed as unattractive, detailed service descriptions condensed into a sentence, and blog archives dropped because they looked dated. Each of those was matching queries that the new version no longer matches.

Compare a sample of important pages before and after. If the replacement covers materially less ground, that is the explanation, and the fix is to reinstate the substance within the new design rather than to revert the design.

Internal linking usually gets quietly rebuilt and weakened

Navigation redesigns change which pages link to which, and this is rarely considered as a search consequence at the time.

A simplified menu removes links to pages that were previously one click from the homepage. Contextual links inside body content disappear when that content is rewritten. Footer link blocks get tidied away. The result is pages that are still present, still indexed, and no longer supported by anything, which is a slow decline rather than a sudden one.

Check how many internal links point to your most important pages now against before. This is among the cheapest things to fix and is almost never on a launch checklist.

Rendering changes can hide your content from crawlers

Modern rebuilds frequently move content into JavaScript that assembles the page in the browser. The page looks identical to a visitor and can return almost nothing to a crawler.

The test is to fetch the raw HTML of an important page and search it for a distinctive sentence you can see on screen. If the sentence is not in the source, the content depends on rendering, and whether it gets indexed becomes uncertain rather than assured.

This is a genuine and increasingly common cause of post-rebuild decline, and it is invisible to anyone checking the site in a browser — which is everyone reviewing a redesign.

Titles and headings rewritten for the brand rather than the query

Redesigns are usually accompanied by a copy refresh, and copy refreshes are usually judged on tone rather than on relevance.

The specific damage is titles that previously named what the page was about being replaced with something more evocative. A page titled for what people search becomes a page titled for how the brand wishes to sound, and its match to the query weakens accordingly.

This does not mean titles must be mechanical. It means the words people actually use should survive the rewrite. Where a brand voice and a search term genuinely conflict, the page can carry both — one in the title, one in the first heading.

Give it time, but know what normal looks like

Some volatility after a migration is expected, and reacting to the first fortnight causes people to change things that were about to recover on their own.

The normal pattern where a migration was done correctly is a modest dip for two to four weeks as pages are recrawled and signals reconsolidate, followed by recovery to roughly the previous level. What is not normal is a decline that deepens after a month, a complete disappearance within days, or specific important pages vanishing while the rest are unaffected.

Distinguishing the two is mostly a matter of shape. Recovery that has begun looks like recovery even when the numbers are still down; a decline that is still deepening at week six is not going to resolve itself.

Two to four weeks of dip is normal

With a correctly executed migration, and it should be visibly recovering by the end of it.

Deepening after a month is not

That is an unresolved fault rather than reconsolidation, and waiting longer will not help.

Total disappearance within days is a blocker

Check indexing directives immediately rather than attributing it to migration volatility.

Page-specific losses point at those pages

Site-wide causes produce site-wide effects. If three pages fell and the rest held, look at those three.

Rebuild the measurement before you interpret it

A redesign frequently breaks analytics, and comparing broken measurement against previous data produces conclusions about a decline that may be partly or wholly artificial.

Confirm the analytics tag is present on every template, that conversion tracking still fires, that filters and exclusions carried across, and that the new URL structure has not fragmented what were previously single pages into several reported entries. Each of these makes traffic appear lower than it is.

Where the tag was missing for a period, mark that period rather than treating it as data. Interpreting a measurement gap as a traffic loss is a common and avoidable error in exactly this situation.

A checklist for the next one

Most of this is preventable, and the prevention is short enough to fit on one page.

Before launch: export the current URL list with traffic attached, map every URL to its replacement, record current rankings and traffic for the top pages, and note the word count and internal link count of important pages so the comparison is possible afterwards.

At launch: verify indexing directives are removed, test the redirect map, submit the new sitemap, confirm analytics fires on every template, and fetch the raw HTML of three important pages to confirm the content is in the source. That list takes an afternoon and prevents almost everything described above.

Reference videos

Search and measurement fundamentals relevant to the checks above.

Frequently asked questions