How to Redesign Your Website Without Losing Your Rankings

The most expensive thing a business can do to its own website is redesign it without a migration plan. I have seen organic traffic fall by more than half overnight, and the cause is almost never the design. It is that thousands of URLs changed and nobody told Google where they went.

The work that protects you is unglamorous and it happens before launch, not after. Here is the sequence.

1. Crawl and record the old site first

Before anything is touched, capture the current state: every URL, its title, its meta description, its H1, and its inbound links. Export your Search Console query and page data too, covering at least the last twelve months.

If you skip this, you lose the ability to know what you had, and therefore the ability to prove what broke. This is the step that gets skipped and the one that costs most.

2. Identify the pages that actually earn

Sort your pages by clicks and by inbound links. Usually a small minority of pages produce most of the organic value.

Those pages get protected absolutely: same URL wherever possible, same core content, same headings. A redesign is not the moment to rewrite the page that generates a third of your enquiries.

3. Keep the URLs if you possibly can

The safest migration changes no URLs at all. Every URL you change is a redirect you have to get right, and redirects lose a little in translation even when executed perfectly.

If a new URL structure is genuinely necessary, change it once, deliberately, with a full map — not incrementally over the following months.

4. Map every old URL to a new one

Build a spreadsheet with two columns: old URL, new URL. Every single old URL needs a row. Rules to follow:

• Use 301 permanent redirects, not 302 temporary ones.
• Redirect to the closest equivalent page. Never mass-redirect everything to the homepage — Google treats that as a soft 404 and you lose the value anyway.
• Avoid chains. Old A should point straight to new C, not to B which points to C.
• If a page has no equivalent and no value, letting it 404 is acceptable and honest. Redirecting it somewhere irrelevant is worse.

5. Check the pre-launch essentials

On a staging site, confirm: the staging environment is blocked from indexing, and that the block is removed at launch. That single oversight — shipping a live site with noindex still set — is the most catastrophic and most common migration failure there is.

Also confirm titles and meta descriptions carried over, headings survived, images kept their alt text, internal links point at new URLs rather than through redirects, and structured data still validates.

6. Launch, then watch closely

Submit the new sitemap in Search Console immediately. Then, for the first fortnight, check daily: crawl errors, indexed page count, and the Pages report.

Expect a modest dip and some ranking fluctuation for two to four weeks while Google re-crawls and re-evaluates. That is normal. What is not normal is a sustained drop past week four, or indexed pages falling and staying down — investigate immediately rather than waiting to see whether it recovers.

Keep the old site accessible for a while

Do not delete the previous build the day you launch. Keep a copy for at least a month. If something is missing and you did not capture it in step one, it is the only way to recover the content.

Page speed on the new build matters as much as the migration itself — a technically clean launch onto a slow template trades one problem for another, which is covered in Core Web Vitals explained.

If you are still deciding whether to rebuild at all, how much a website costs in the Philippines breaks down the price bands first. More on how I handle builds and migrations is on my web development service page.