Rankings dropped after a redesign: why it happens and how to stop it

The site launches. It looks better, it loads faster, everyone is pleased. Three weeks later someone opens Search Console and the traffic graph has fallen off a cliff. It is one of the most common failures in web work, it is almost always caused by one of seven things, and every one of them is preventable.

The seven causes, most common first

1. Addresses changed without redirects. The old site had /services/boiler-repair, the new one has /boiler-repair, and nothing connects them. Google’s copy of your site now points at pages that return “not found”. It drops them over the following weeks, and the new pages start from nothing. Search Console’s Pages report shows this as a pile of “Not found” errors with the old addresses.

2. The site is blocking indexing. The staging copy had “discourage search engines” ticked, or a noindex tag, or a robots.txt that blocks everything, and it went live that way. Google visits, is told to go away, and does. Simple to check, devastating when missed.

3. Content was removed or thinned. The old services page had eight hundred words that ranked. The new design has a headline and three bullet points. Google ranked the words, not the layout.

4. Titles and headings were rewritten. Someone made them punchier. “Boiler repair in Leeds” became “We keep you warm”. The page used to say what it was about; now it does not.

5. Internal links disappeared. The old site linked between pages in the text; the new one only links from the menu. Pages that were well connected are now isolated.

6. The new site is slower than the old one, often because of a heavier theme or page builder, so the page experience signals dropped.

7. Pages were merged or deleted without redirects to the closest surviving page, or the sitemap still lists the old ones.

Finding which one hit you

Search Console, Pages report first: “Not found” errors point to cause one or seven; “Excluded by noindex” points to two. Then Performance, comparing the four weeks before launch to the four after, by page: pages that lost everything and are still indexed point to three, four or five. Core Web Vitals for six.

The recovery order

1. Fix indexing if it is blocked. Minutes. Then request indexing on the homepage and key pages.
2. Build the redirect map. Every old address, from the old sitemap or Search Console, to its new equivalent. Permanent, one hop each, never to the homepage as a catch-all. This is the fix for most drops.
3. Restore the content. Put back the words that ranked, in the new design. The layout can stay; the substance must return.
4. Restore the titles and H1s to say what each page is about, using the search terms the old ones used. Punchy can live in the subheading.
5. Restore internal links in the page text, not only the menu.
6. Fix the speed if the new site is slower, which usually means images and scripts.
7. Resubmit the sitemap and wait. Recovery from redirect-driven drops takes two to eight weeks once redirects are in. Recovery from content and title changes is faster.

Preventing it next time

Before any launch: export every old address, write the redirect map, keep the titles and the substance of ranking pages, check that indexing is on, and compare Search Console weekly for a month after. We wrote up the migration version of this for people leaving site builders, and the checklist is the same for any redesign. It adds a day to the project and it protects years of ranking.

If the drop has already happened, the first hour of investigation is the Pages report and the redirect map. Run the site through the scanner too: it will catch indexing blocks, redirect chains and the speed signals in one pass.