What Actually Causes the Drop
A redesign that loses traffic almost always lost it for one of six reasons, and five of them are preventable in an afternoon of preparation. The design itself is virtually never the cause.
- Old URLs were not redirected to their new equivalents
- The staging site's noindex tag went live with the new site
- Content was cut during the redesign — the pages ranking well were shortened or deleted
- Page titles and meta descriptions were regenerated to something generic
- Internal linking was simplified, orphaning pages that used to be well connected
- The new build is slower or renders content only via JavaScript
If you are reading this after a launch, work down that list in order. Number two takes five minutes to check and is responsible for a startling number of catastrophic drops.
The Single Most Common Failure: Redirects
Every page on your old site that had rankings or backlinks has accumulated value at a specific URL. Change that URL without a redirect and the value does not move — it evaporates, and the visitor gets a 404.
The failures we see repeatedly:
- No redirects at all. The developer built the new site and pointed the domain at it. Every old URL now 404s.
- Everything redirected to the homepage. Feels tidy, achieves almost nothing. Search engines treat a mass redirect to an unrelated page as a soft 404.
- 302 instead of 301. A 302 signals a temporary move and does not transfer ranking value the way a permanent 301 does.
- Redirect chains. Old URL redirects to an intermediate URL which redirects again. Each hop loses a little and slows the visitor.
- Only the main navigation was mapped. Blog posts, old landing pages, and PDFs — often the pages with the most accumulated links — were forgotten.
Doing it properly
- Before launch, export every URL from Search Console, your analytics, your XML sitemap, and a crawl of the live site. Combine and de-duplicate.
- Sort by traffic and by referring domains. Anything with either gets a redirect, no exceptions.
- Map each to its closest equivalent on the new site. Where genuinely no equivalent exists, redirect to the most relevant category page, not the homepage.
- Implement as 301s, and test the full list after launch with a crawler that follows redirects.
- Keep the redirects in place permanently. They are not temporary scaffolding.
The Five-Minute Check That Saves Everything
Staging sites are blocked from search engines with a noindex directive or a robots.txt disallow. When the site goes live, that block has to be removed. It is forgotten often enough that it deserves its own section.
Check right now: visit your homepage, view source, and search for "noindex". Then visit yourdomain.com/robots.txt and confirm it does not contain "Disallow: /". In Search Console, use the URL Inspection tool on three or four important pages and confirm they are indexable.
If a noindex went live, remove it, request reindexing on your key pages, and expect recovery within two to four weeks. This is the best possible cause of a traffic drop, because it is completely reversible.
The Cause Nobody Anticipates: Content Loss
Redesigns are an aesthetic exercise, and text is the first casualty. The page that ranked first for a valuable query had 1,800 words answering the question thoroughly. The redesigned version has a hero image, three feature cards, and 200 words, because the old page "looked cluttered".
It did look cluttered. It also ranked, because it comprehensively answered what people were searching for. The new page is better designed and materially worse at its job.
How to protect content through a redesign
- Identify your top twenty pages by organic traffic before design begins, and treat their content as a fixed requirement rather than raw material.
- If a page must be shortened, ensure the substance survives — reorganise into accordions or tabs rather than deleting, but keep the text in the HTML rather than loading it on click.
- Preserve the heading structure. Headings carry topical signal; flattening six sections into two loses it.
- Keep internal links. Redesigns love clean minimal footers, and clean minimal footers frequently orphan a hundred pages.
Titles, Metadata, and the CMS That Helpfully Overwrote Everything
Hand-written page titles built over years are a real asset. Migrations regularly replace them with a template — "Services | Company Name" applied to forty pages that previously had distinct, keyword-appropriate titles.
Export every title and meta description before migration. After launch, crawl the new site and compare. Look for duplicates, for titles that lost their differentiating terms, and for pages where the description reverted to an auto-generated excerpt. This is an hour of work that prevents a slow, hard-to-diagnose decline.
Technical Regressions To Test For
- JavaScript-only rendering. If the new site loads content client-side, verify it is server-rendered or properly pre-rendered. Content that only appears after JavaScript executes is inconsistently indexed — a large part of why we build the way we describe in our stack write-up.
- Canonical tags. A migration can leave canonicals pointing at the staging domain, which effectively tells search engines your live pages are duplicates of a site they cannot reach.
- XML sitemap. Regenerate and resubmit. An old sitemap listing dead URLs slows re-crawling of the new ones.
- Structured data. Schema markup is easy to lose in a rebuild, taking your rich results with it.
- Speed. Verify the new site is genuinely faster on mobile, not just visually lighter. Our speed diagnostic guide covers how to check.
- HTTPS and www consistency. Four versions of every URL can exist. Exactly one should resolve; the rest should redirect to it.
Pre-Launch Checklist
| When | Task |
|---|---|
| 2 weeks before | Full crawl of old site; export URLs, titles, descriptions, and traffic data |
| 2 weeks before | Benchmark current rankings and monthly organic traffic so you can measure honestly |
| 1 week before | Build and review the complete redirect map |
| 1 week before | Verify content parity on the top twenty pages |
| Launch day | Remove noindex; check robots.txt; confirm canonicals point to live URLs |
| Launch day | Submit the new XML sitemap in Search Console |
| Launch + 1 day | Crawl the live site; test every redirect; fix chains and 404s |
| Launch + 1 week | Check Search Console coverage and 404 reports daily |
| Launch + 1 month | Compare rankings and traffic against the benchmark |
If It Has Already Happened
- Confirm the drop is real. Compare like-for-like periods in Search Console, not analytics, and check whether impressions fell alongside clicks. Impressions holding steady while clicks fall is a different problem — usually titles.
- Check indexability first. Five minutes, and it is the most common single cause.
- Pull the 404 report. Search Console will show you which old URLs are now dead. That list is your missing redirect map.
- Compare content on your top pages. Old version via the Internet Archive, new version live. Look for what disappeared.
- Fix in order of traffic lost. Restore the highest-value pages first rather than working alphabetically.
- Request reindexing on the pages you fix, then wait. Recovery is not instant even once the cause is removed.
Resist the urge to make additional changes while you are diagnosing. Two simultaneous changes make it impossible to tell which one worked.
The Uncomfortable Truth About Redesign Timing
Most traffic losses from redesigns are not caused by designers or developers being careless. They are caused by nobody being assigned responsibility for search continuity, because the project brief covered how the site should look and not what it should preserve.
Put it in the brief. Name the person accountable for the redirect map. Make content parity on top-performing pages a launch requirement rather than a nice-to-have. It costs a few days and it is the difference between a redesign that grows the business and one that sets it back nine months.
Kalex Studio handles migrations with a documented redirect map and pre- and post-launch crawls as standard. If you are planning a redesign — or recovering from one — talk to us before you launch rather than after.