What a redesign does to your rankings, and how to keep them

A redesign changes your URLs, your internal links and your page templates in the same week. Here is what carries across, what quietly breaks, and the checks that decide whether traffic dips for a fortnight or for a year.

Every redesign is a controlled demolition of the thing search engines had already worked out. New URLs, new templates, new internal linking, new copy, usually all in the same week. Google has to re-learn a site it already understood.

Done properly that costs you a fortnight of noise. Done badly it costs a year. The difference is almost never the design. It is whether the old addresses still resolve, whether the new pages say what the old ones said, and whether anyone checked before the DNS changed.

This is the checklist we run on a rebuild, and the failure modes we see when it gets left until after launch. It is the same work as a platform migration, minus the part where the domain changes.

What a redesign actually changes

Redesign is one word for four separate changes, and search treats each of them differently.

You can change any one of these on its own and recover in days. Changing all four in one launch is what turns a redesign into a six-month recovery, because once traffic moves you have no way of telling which change moved it.

If you take one thing from this page: change the design or change the URLs, but try not to change both in the same week.

What carries across and what breaks

Most redesign advice is written in the optimistic tense. Here is the honest version, using the same four states we use on the migration guides, because a redesign is a migration that happens to keep the domain.

Read that table as a work list. Everything marked rebuilt is something a person has to do before launch, and everything marked replaced is a decision somebody has to make on purpose rather than discover afterwards.

Why traffic drops after a launch

Three causes account for nearly all of it, and none of them are visible in a design review.

The URL changed and nothing said so

A page that ranked at one address now lives at another, and the old address returns a 404. Every link pointing at it stops counting, and the position it held goes to whoever is second. This is entirely preventable and it is still the most common cause we see.

The new page says less than the old one

Design-led rebuilds cut copy. That is usually the right instinct for a homepage and the wrong one for the service page carrying half your organic traffic. A page that ranked on nine hundred words of detail, and now carries two hundred words and a large photograph, has stopped answering the question it ranked for.

The content moved behind JavaScript

If the new build renders your body copy on the client, a crawler may fetch a shell and come back for the content later, or not at all. Answer engines are stricter than Google here: several read the HTML they are served and nothing more. Check what your page contains with JavaScript disabled. If the copy is not there, it does not reliably exist.

Redirects do most of the work

A 301 tells Google the page moved permanently and that the new address should inherit what the old one earned. Google's own documentation on redirects is worth ten minutes of anyone's time before a launch. It is the hour of work that decides most of the outcome, and it is usually handed to whoever has a free afternoon on launch day.

Map every URL that has ever earned a visit, a link or an impression. Not the pages you remember building. The pages Search Console says exist.

The map itself is two columns, old path and new path. On Wix Studio you upload it as a CSV in the redirect manager rather than editing server files, so what you are producing looks like this:

Old URL,New URL
/webdesign,/services/wix-studio-website-design
/marketing,/services/seo-aeo-ppc
/about-us,/about
/blog/2019/07/why-we-rebranded,/blog/why-we-rebranded
/shop/product/blue-widget-2,/shop/blue-widget

Four rules decide whether that file does its job:

• Point each old URL at its closest equivalent, not at the homepage. An irrelevant redirect gets treated as a soft 404 and passes nothing.
• One hop, never three. Chains slow crawling and lose value at each step, so send the old address straight to the final one.
• Keep them permanently. A redirect you tidy away after six months is a 404 with a delay on it.
• Let genuinely dead pages die. A page with no traffic, no links and no equivalent should return a 404 and fall out of the index. That is a clean signal, not a mistake.

Redirecting every old URL to the homepage is not a redirect strategy. Google reads it as a soft 404, which means you have done the work and kept none of the benefit.

The pre-launch checklist

All of this happens before the DNS change. Afterwards, half of it turns into forensics.

1. 1.Export every URL Search Console has an impression for, plus everything in your current sitemap. That is your inventory, and it will be longer than you expect.
2. 2.Pull the top fifty pages by clicks and the top fifty by referring domains. Those are the pages the rebuild is not allowed to weaken.
3. 3.Write the redirect map. Every old URL gets a destination or an explicit decision to let it 404. No blanks.
4. 4.Check content parity on those hundred pages. If the old version answered something the new design dropped, put it back before launch, not after the ranking goes.
5. 5.Keep the title tags and H1s that already work. A rebuild is the worst possible moment to rewrite the title of your best-performing page for stylistic reasons.
6. 6.Rebuild the structured data. Organization, Breadcrumb, FAQ and Article markup do not travel with the copy, and nobody notices they are missing until the rich results stop appearing.
7. 7.Confirm the staging site is blocked and the live site is not. A noindex left on at launch is a week of nothing, and it is the easiest disaster on this list to cause.
8. 8.Generate the new sitemap, submit it, and leave the old one in place until the redirects have been crawled.

Rebuilding on Wix Studio?

We write the redirect map in week one, from Search Console data, before anyone opens a design tool. It is the difference between a fortnight of noise and a quarter of recovery.

See how we handle migrations →

The first 30 days

Launch day is the start of the measurement, not the end of the project.

Then change nothing for two weeks unless something is plainly broken. A rebuild is already a large enough variable. Stacking fixes on top of it means you will never learn which one worked.

Reading the drop

Not every dip is a problem, and the shape of the curve tells you which kind you have.

Three questions come up on every one of these calls, so they are worth answering here.

How we run a rebuild

The short version is that the search work happens before the design work, not after it.

• The URL inventory and the redirect map are written in week one, from Search Console data, before a single page is designed.
• Every page that earns traffic gets a parity check. The new version has to answer what the old version answered, in as many words as that takes.
• Titles, H1s and structured data are content the client signs off, not something the build emits while nobody is looking.
• Indexing is verified on launch day rather than assumed: staging blocked, live open, top twenty URLs resolving or redirecting.
• We watch Search Console for thirty days after launch and fix what actually moves, rather than everything at once.

It is the same process behind our platform moves, whether a site is coming off WordPress or Squarespace. A redesign is the easier version of it, because the domain stays where it is.

A redesign should make you more money, not cost you the traffic you already had. Those two things only pull against each other when the search work gets left until after the launch party.