How to Redesign a Website Without Losing Search Rankings

The gap between the old site and the new one

A website redesign changes URLs, templates, and often the underlying platform, all at once. Search engines don't re-evaluate a site the moment it changes — Google has to re-crawl the new pages, work out how they relate to the old ones, and update its index, and Google's own documentation on site moves with URL changes is explicit that this takes time: "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)." During that window, the same page says, "the visibility of your content in Search may fluctuate temporarily during the move. This is normal."

That single sentence is worth sitting with before anything else in this article. A careful migration is the single biggest lever a business has over how much search traffic survives a redesign — but Google itself does not promise the fluctuation will be zero, and no agency honestly can either. What follows is what a careful migration actually looks like, step by step, and what to watch once the new site is live.

Step 1: Inventory the old site before you touch it

You cannot redirect what you haven't listed. Before any design or development work starts, pull a complete list of every indexable URL on the current site — not just the pages in the main menu, but blog posts, old landing pages, category and tag archives, and anything Google has indexed that a human might have forgotten existed. Three sources are worth cross-checking against each other: your CMS's own page list, a crawl of the live site with a tool like Screaming Frog, and the Pages report in Google Search Console under Indexing, which shows what Google currently has indexed rather than what you think should be there.

Against each URL, record: the page's current title and meta description, its approximate organic traffic or impressions if you have Search Console history, and which internal pages link to it. This inventory becomes the reference document for every decision that follows, including which pages are worth keeping at all — a redesign is also a reasonable time to retire pages that never earned traffic, provided they're redirected sensibly rather than left as silent 404s.

Step 2: Build a one-to-one redirect map

The redirect map is a spreadsheet: old URL in one column, new URL in the other, for every single page from Step 1. Not a blanket rule that sends everything to the homepage — Google's guidance is specific that redirects should point to "the corresponding new page," and a homepage catch-all is treated as a weak signal, not a like-for-like replacement, because it tells Google the old page's content genuinely moved to the homepage, which usually isn't true.

Where a URL structure is changing (new folder pattern, new CMS slug rules, a new domain), this mapping exercise is where most of the actual migration risk lives. It's tedious, especially on a site with a few hundred pages, but it's also the one part of a redesign that a spreadsheet can catch mistakes in before launch, rather than after.

Step 3: Implement redirects as server-side, permanent (301/308)

Google's guidance on redirects and Search recommends permanent, server-side redirects — HTTP status 301 or 308 — over meta-refresh or JavaScript redirects, which it lists only as fallbacks when a server-side redirect genuinely isn't possible. A permanent redirect is treated as a canonicalisation signal: Googlebot follows it, and Google's indexing pipeline uses it as a signal that the destination URL should become the canonical, ranking version. That's the mechanism that carries a page's existing signals across to its replacement — it isn't automatic, and it isn't instant, but it's the documented path Google follows.

One caution from the same guidance: use permanent redirects only when you're sure the change won't be reverted. A temporary redirect (302) sends a different signal — that the move might not be permanent — so don't reach for a 301 as a default for anything you might want to undo later, such as a temporary maintenance page.

Step 4: Preserve what's already working

Titles, meta descriptions, and heading structure that are already ranking reasonably well shouldn't be rewritten just because the site has a new design. If the old page's <title> and H1 are doing their job, carry them across to the new template as-is, or change them deliberately and separately from the migration — not as a side effect of a new CMS's default formatting. The same applies to structured data: if a page had review, product, or FAQ schema validating correctly, confirm the new template still outputs it, since a new theme or platform won't preserve markup the old one had by default.

Step 5: Update internal links, don't lean on redirects for them

Every internal link on the new site should point directly to the new URL, not to the old URL via a redirect. Chained redirects add latency and dilute the signal Google follows, and Google's own move guidance calls for updating internal links directly. This includes navigation menus, footer links, in-content links, and canonical tags — all easy to overlook because they don't visibly break for a visitor the way a missing redirect would.

Step 6: Stage it properly, and keep it out of Google's index

A staging environment should be blocked from indexing — either with a site-wide noindex meta tag or an HTTP authentication wall, not a robots.txt disallow alone, since robots.txt stops crawling but doesn't reliably stop a URL from being indexed if it's linked to from elsewhere. The single most common launch-day mistake is forgetting to remove that noindex tag when the real site goes live, which quietly tells Google not to index anything on the new domain. Check this explicitly as a launch step, not an assumption.

Launch checklist

At the point of going live: turn off staging protections, confirm the redirect map is deployed and firing correctly (spot-check a sample of old URLs, don't assume), submit an updated XML sitemap containing only the new, live URLs, and — if the domain itself changed — file a Change of Address request in Search Console, which is specifically for domain migrations rather than URL-path changes on the same domain. If the site is multilingual, hreflang annotations need updating to the new URLs as part of this same step, not afterwards.

It's also worth checking Core Web Vitals on the new templates before launch. The current thresholds are Largest Contentful Paint (LCP) at or under 2.5 seconds, Interaction to Next Paint (INP) at or under 200 milliseconds, and Cumulative Layout Shift (CLS) at or under 0.1, measured at the 75th percentile of real visits — web.dev's Core Web Vitals reference sets these out in full. Time to First Byte (TTFB) is a useful diagnostic for slow LCP but isn't itself a Core Web Vital. A redesign that looks better but loads worse than the old site is trading one risk for another.

What to monitor after launch

For at least the first few weeks: watch Index Coverage in Search Console for a rise in "Not found (404)" or "Page with redirect" errors — usually a gap in the redirect map. Watch Performance for clicks and impressions against the pre-launch baseline over weeks, not days, since short-term noise is normal. Spot-check periodically that redirects are still firing; a later deployment or CDN change can silently break them. Keep old redirects live indefinitely where practical — there's no fixed expiry, and external links or bookmarks may still point at old URLs months later.

Being honest about what this achieves

Everything above reduces risk. None of it eliminates it. Google's own documentation frames the fluctuation during a move as expected and normal, not as an edge case to be engineered away, and any business planning a redesign should go in expecting some temporary movement in rankings and traffic rather than a seamless, invisible transition. What a careful migration buys you is a much smaller, much shorter dip than a careless one — not a guarantee of none.

If you're planning a redesign

Before a redesign starts is also the right time to get the current site properly inventoried — content, URLs, and what's actually earning traffic — rather than relying on memory or an outdated sitemap. JagaWeb's Essential System Review (RM1,500 fixed, excluding SST — currently RM999 until 16 September 2026, for one site up to 25 pages) produces exactly that kind of inventory as part of its report, and the fee is credited toward eligible follow-on work for 12 months if you decide to proceed. For larger sites with commerce or multiple integrations, the Complete System Review (RM5,000 fixed, excluding SST, 26–250 pages) covers the same ground at scale. Both are one option among several ways to prepare for a migration — happy to talk through whether either fits before anything is committed.