Website redesign without losing rankings.

Here is the call we get most often, and it always arrives about three weeks too late. A business launched a new site last month. It looks considerably better than the old one. Organic traffic has halved, the enquiry form has gone quiet, and nobody can say precisely when it started, because analytics was reinstalled on launch day and the comparison no longer exists.

Nothing was done maliciously. Usually nothing was even done carelessly. The agency built a good site, the client approved it, and the part that protects search traffic was simply never anybody's job.

This guide is the sequence we run on a migration. It is dull, and that is the point.

What actually breaks, and it is never the design

Google does not rank you lower for having a new stylesheet. It ranks you lower because the signals it had been using quietly stopped existing. There are four ways that happens, and in our experience almost every damaged migration is one or more of them.

The URLs changed and nothing was told where they went

Your old URLs are not addresses. They are the thing other sites link to, the thing Google has associated with a set of queries, and the thing sitting in somebody's bookmarks. Move /web-design-services to /services/website-design without telling anyone, and to a search engine you have not moved a page. You have deleted one and published a different one with no history.

The redirects exist but point somewhere useless

This is more common than missing redirects, and harder to spot because the site technically works. Every old URL resolves, nothing 404s, and the report looks clean. The problem is that four hundred of them resolve to the homepage.

The staging site got indexed

Development usually happens on a subdomain. If that subdomain has no password, no noindex, and a robots file nobody checked, Google will find it and index an unfinished copy of your site. You then have two versions competing, and Google picking the wrong one.

Content was removed because it looked untidy

Covered properly below, because it is the one nobody expects and the hardest to reverse.

The inventory almost nobody takes

You cannot protect assets you have not written down. Before a wireframe exists, you want three exports sitting in one spreadsheet.

A full crawl of the current site. Screaming Frog, Sitebulb, or the site audit in Ahrefs or Semrush, any of them will do. What you need out of it is every URL that returns a 200, plus its title, meta description, H1, word count and internal links pointing at it.

Search Console performance data, exported by page, over the longest range available. This tells you which URLs actually earn clicks rather than which ones somebody assumes are important.

Analytics landing page and conversion data. Traffic alone is misleading. A page with modest traffic that produces enquiries matters more than a popular article that produces none.

Put them together and sort by whatever your business actually counts. What comes out is a short list of pages that are doing real work, and it is routinely not the list the marketing team would have guessed. We have yet to run this exercise without at least one page surprising the client.

The redirect map, and the one rule that matters

A redirect map is a spreadsheet with two columns: every old URL, and the single most equivalent new URL. It is built while the new site is being designed, not after it is finished, because it will change the sitemap you build.

One page to one relevant page. That is the rule, and nearly every migration failure we are called in to fix broke it.

Redirecting everything to the homepage is the usual shortcut, and it fails on both counts that matter. The visitor who searched for a specific service lands somewhere general and leaves. And Google, seeing a large number of unrelated pages all claiming to have become the homepage, treats the redirects as a soft 404 rather than as a transfer.

Three details that get missed:

• Use 301, not 302. A 302 says temporary. If the move is permanent and you said temporary, you have told Google to keep the old URL.
• Avoid chains. Old → newer → newest is a chain. They waste crawl budget, they compound when the next redesign happens, and we regularly find sites five redirects deep because nobody flattened the previous migration. Point every old URL at its final destination directly.
• Decide deliberately about pages with no equivalent. If a page is genuinely gone and nothing replaces it, let it 404 or return 410 rather than redirecting it somewhere irrelevant. An honest 404 is better than a misleading redirect.

Check the canonical tags on the new site at the same time. A canonical pointing at the old URL, or at a staging domain, is a quiet way to undo the entire redirect map. It is worth one pass with a crawler specifically looking at nothing else.

The content a designer will call clutter

This is the failure nobody plans for, because it does not feel like a technical decision. It feels like good taste.

A designer looks at a service page with eleven hundred words on it, and the page is visually heavier than the clean layout in the mockup. The text gets cut to three short sections. The page now looks far better, and it answers four fewer questions than it used to.

Google was ranking that page partly because it covered things competitors did not. Removing them does not make the page cleaner in search. It makes it thinner.

Before anything is cut from a page that currently ranks:

• FAQ blocks. Often the only part of a page answering the long-tail queries that bring in qualified visitors.
• Supporting explanation. Process descriptions, comparisons, pricing context. The sections a visitor reads when they are close to deciding.
• Internal links. Navigation redesigns frequently drop contextual in-content links. Those links are how Google understands which of your pages matter and how topics relate. Losing them weakens pages that were not touched at all.
• Headings. Replacing descriptive headings with short decorative ones removes the structure that both readers and search engines use to scan the page.

None of this means a redesign cannot improve content. It means cutting is a content decision made with the performance data open, not a layout decision made in a design review.

Launch day, in the right order

Most of launch day is deployment. Six things are yours.

1. Check robots.txt on production. The staging file says Disallow: /. If it ships, your entire site is invisible, and we have seen it survive for weeks before anyone noticed.
2. Remove every noindex tag. Development templates carry them. Crawl the live site immediately after launch and confirm not one page still has one.
3. Deploy the redirects before the DNS switch, not after. There should be no window in which old URLs 404.
4. Generate and submit the new sitemap in Search Console. Keep the old sitemap available for a few weeks so Google recrawls the old URLs and finds the redirects.
5. Verify tracking before you need it. Analytics, conversion tracking and tag manager, tested with a real submission. A redesign that creates a two-week hole in your data makes every question afterwards unanswerable.
6. Spot-check your top twenty pages from the inventory. Load each one, submit the forms, confirm the content survived.

The first thirty days, and what normal looks like

Rankings move after a migration. Google has to recrawl every URL, process every redirect and reassess pages whose content changed, and it does not do this in a day. Some fluctuation is expected and means nothing.

What separates normal from broken is shape, not size.

Normal looks like movement in both directions across different pages, settling over two to six weeks depending on how large the site is and how often it gets crawled. Individual keywords wobble. The overall trend flattens and recovers.

Broken looks like a step change. Traffic drops sharply on a single day, stays down, and the drop is concentrated in pages that previously performed well. That is not Google reassessing you. That is something no longer reachable.

Check these weekly for the first month:

• Search Console coverage. A rising count of excluded or not-indexed pages is the earliest reliable warning.
• 404s in Search Console and your server logs. Old URLs still being requested and returning 404 are redirects you missed.
• Index count against your inventory. If you had 180 indexable pages and Google now knows about 60, stop and find out why.
• Your top twenty pages by previous clicks. Specifically those, not the sitewide average, which hides a lot.

If you are reading this too late

Most migration damage is recoverable, and the order matters more than the speed.

Start by diffing the old and new sites. If you took the inventory, this takes an afternoon. If you did not, use the Wayback Machine and Search Console's historical data to reconstruct what used to exist, which is slower and less complete but usually sufficient.

Then work through, in this sequence: confirm the site is crawlable at all, check for stray noindex tags, find old URLs returning 404 and redirect them properly, flatten any chains, then compare the content on your previously strongest pages against what they used to contain and restore what was cut.

On timing, we will be straight with you. A missed redirect fixed in week two usually recovers within a few weeks of the fix. Content cut from a dozen important pages and restored three months later takes longer, because by then competitors have moved and Google has had time to reassess. Recovery is normally a matter of weeks to a few months rather than days, and anyone offering you a date is guessing.

If a redesign is on your roadmap, this is work that has to start before the design does. Our SEO services include migration planning, and our process sets out how we sequence it against a build.