A redesign is the single most dangerous thing you can do to a website that already works. The design is rarely what breaks it. What breaks it is a handful of technical decisions made quietly during the build, which nobody notices until the enquiries stop six weeks after launch and the agency has moved on.
These are the failures we find most often when auditing a redesign that lost traffic — ordered roughly by how much damage they do.
1. Nobody mapped the old URLs
This is the big one. Your old site had URLs. Other websites link to them, Google has them indexed, your Google Business Profile points at some of them, and your old directory citations reference others. If the new site uses different URLs and nothing redirects the old ones, every one of those links now lands on a 404 and every ranking attached to them evaporates.
The fix is unglamorous: crawl the old site before launch, export every URL, and map each one to its closest equivalent on the new site with a 301 redirect. Not to the homepage — to the equivalent page. A blanket redirect of everything to the homepage is treated by Google as a soft 404 and preserves almost nothing.
Do this before launch, not after. Once the old site is gone you cannot crawl it, and you are reduced to reconstructing the URL list from Search Console and archive.org.
2. A redirect rule that quietly shadows real pages
This one is genuinely nasty because everything looks fine. Catch-all redirect patterns written to kill off legacy URLs will happily match your new site's own routes too.
A real example: a site migrating off WordPress added a rule sending /category/* to the blog index, because the old WordPress category archives no longer existed. Reasonable. Except the new site had its own /category/[slug] pages — and the rule redirected every one of them to the blog index before the application ever saw the request. The pages existed, rendered perfectly in development, and were completely unreachable in production. Every internal link into them was silently dead for months.
Redirect rules are evaluated before your routing. Any pattern with a wildcard needs checking against the list of routes your new site actually serves.
3. Redirect loops from legacy query strings
WordPress sites serve posts at /?p=123. A migration rule that strips query parameters and sends the request to / can produce a request that matches its own rule again — and Google reports the URL as a redirect loop and drops it entirely.
Test redirects with the query string attached, not just the clean path. curl -I "https://yoursite.com/?p=123" should terminate somewhere sensible within one or two hops.
4. The content Google needs is rendered in the browser
Modern frameworks make it easy to build a page that fetches its own content after loading. Visually it is fine. To a crawler it can be an empty shell.
The trap that catches people: the page fetches from your own /api/ endpoint, and robots.txt disallows /api/. Googlebot renders the page, declines to fetch the disallowed endpoint, and indexes a blank grid with zero links. We have seen a blog index page serve no links to any blog post at all for this exact reason, which meant not one of the site's articles had a single internal link pointing at it.
Check it the simple way: view source — actual source, not the inspector — and search for a link you expect to be there. If it is not in the HTML, Google may not be counting it.
5. The sitemap lists URLs that redirect or are noindexed
A sitemap is a list of pages you are asking Google to index. Every URL in it should return 200 and be indexable. If it 301s, 404s, or carries a noindex tag, you are sending contradictory instructions and burning crawl budget.
This happens constantly after a redesign, because the sitemap is generated from the database while the redirects are configured separately, and nobody reconciles them. After launch, fetch your own sitemap and check the status code of every URL in it. Anything that is not a 200 does not belong there.
6. "We simplified the copy"
Designers dislike walls of text and clients often agree. So the 1,400-word service page that ranked on page one becomes 300 words of elegant, airy, generic marketing language — and drops to page four.
Depth is not decoration. If a page currently ranks, the content on it is the asset. You can restructure it, add headings, break it up, make it scannable. What you cannot do is delete two-thirds of it and expect the ranking to survive. Identify your top twenty pages by organic traffic before the redesign and treat their content as protected.
7. Changing URL structure for no reason
Tidiness is not a business case. If /services/web-design ranks, moving it to /what-we-do/web-design costs you a redirect hop, a period of instability and some accumulated authority — in exchange for nothing a visitor will ever notice. Change URLs when there is a genuine reason. Otherwise leave them exactly where they are, even if the new site's internal structure would prefer otherwise.
8. Losing the title tags and H1s that were working
Titles are frequently rewritten during a redesign for brand consistency. But the existing title is what Google has associated with that page's rankings, and often what earns the click. Rewriting every title at the same moment you change everything else means that if performance drops you have no idea which change caused it. Export your current titles and meta descriptions first, and change them deliberately and separately from the redesign itself.
9. Launching with the staging noindex still in place
Staging sites are blocked from search engines, correctly. The tag then ships to production. The site sits there quietly deindexing for however long it takes someone to notice — usually a fortnight, sometimes much longer.
First action after any launch: request the live homepage and confirm there is no noindex in the response, and that robots.txt is not disallowing everything. It takes thirty seconds and it is the most valuable thirty seconds in the entire project.
10. No baseline, so nobody can prove what happened
If traffic drops after launch and you have no record of what the old site ranked for, you cannot diagnose it and you cannot argue about it. Before you launch, export from Search Console: your queries, your pages, and your average positions for the last twelve months. Export a full crawl of the site. Screenshot your analytics. It costs an hour and it is the difference between fixing a problem and guessing at one.
The pre-launch checklist
- Full crawl of the old site exported and stored
- Search Console query, page and position data exported for the last 12 months
- Every old URL mapped to a new one, page to equivalent page
- Redirects tested — including with query strings — and confirmed to resolve in one hop
- Wildcard redirect rules checked against the new site's own routes
- Top 20 organic pages confirmed to retain their content depth
- Existing title tags preserved unless deliberately changed
- View-source check that key content and links appear in the raw HTML
noindexremoved androbots.txtverified on the live domain- Sitemap regenerated, and every URL in it returning 200
- Analytics and conversion tracking firing on the new templates
- Search Console updated with the new sitemap on launch day
What to do if you have already launched and traffic fell
Do not panic and do not roll back immediately — a second migration compounds the damage. Work in this order: confirm the site is indexable at all, check Search Console's coverage report for a spike in 404s or redirect errors, compare your current top pages against the pre-launch export to find what lost position, and check whether those specific pages lost content or changed URL. In most cases the cause is one of the ten items above, and most of them are still fixable weeks later.
FAQs
How long after a redesign should rankings recover?
Expect a dip of two to six weeks even on a clean migration, as Google recrawls and reassigns signals to the new URLs. If you are still down significantly after eight weeks, something is broken rather than settling.
Should I use 301 or 302 redirects for a redesign?
301, permanent. A 302 tells Google the move is temporary and it may keep the old URL indexed. Note that some frameworks emit 308 rather than 301 for permanent redirects — Google treats them identically, so that is fine.
Can I redirect everything to the homepage to avoid 404s?
No. Google treats mass redirects to an irrelevant page as soft 404s, and you lose the ranking value entirely. A genuine 404 is better than a misleading redirect. Redirect to the closest equivalent page, or let it 404 honestly if no equivalent exists.
Do I need to resubmit my sitemap after a redesign?
Yes. Submit the new sitemap in Search Console on launch day and monitor the Index Coverage report for the following month. That report is where migration problems surface first.
Is it safer to redesign in stages?
Often, yes. Rebuilding templates while keeping URLs and content intact, then improving content separately, means that if something breaks you know which change caused it. Changing design, structure, URLs and copy simultaneously is how projects become undiagnosable.
Planning a redesign?
Blend Designs treats URL mapping, redirect testing and ranking preservation as part of the build rather than an optional extra. If you have a site that currently earns enquiries, that is the part of the project worth paying attention to.
Request a redesign quote, or read what actually drives website redesign cost in Australia before you brief an agency.