How to Redesign a Website Without Losing Your Rankings

A website redesign keeps its rankings when every URL that earned them either stays exactly where it is or points permanently at its replacement. Google's site move documentation splits the work into two different jobs by that single question, and most redesign checklists blur them into one undifferentiated list.

So the first thing to settle is not the colour palette or the platform. It is whether this redesign changes URLs. Everything below is sorted by that answer, and every platform fact is stamped as of October 2026 and attributed to the Google document stating it.

The one question that decides which redesign you are running

Ask whether the URLs change. A redesign that keeps every path is a template and content change, and Google needs no instruction to follow it. A redesign that moves paths is a site move with URL changes, Google's own term for it, governed by documentation written for exactly that event.

The distinction decides which failures are possible at all. A same-URL redesign cannot lose a page to a broken redirect, because there are none. A URL-changing redesign can lose every page that way, and running it on the first one's checklist is how a redesign costs search traffic.

Path one: the redesign that keeps every URL

A same-URL redesign has one serious technical risk and one editorial one. The technical risk is shipping a staging-era crawl block to production. The editorial risk is a new template that quietly deletes the text search engines were ranking: the title, the H1, and the first paragraph of every page that earned traffic.

The crawl block deserves particular care, because the two ways of hiding a staging site interact badly. Google's documentation on blocking indexing states it plainly: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file. If it is, the crawler will never see the noindex rule." A site shipping both from staging is blocked in a way that resists the obvious fix. Remove the robots.txt disallow first, then the noindex, then request a recrawl in Search Console.

The editorial risk is less dramatic and more common. Designers rewrite headings to fit a layout. If the old H1 carried the service and the city a stranger would type, and the new one carries a three-word mood, the page has changed what it is about. Keep the title, H1 and first 100 words of anything that ranks, and redesign around them.

Path two: the redesign that changes URLs

A URL-changing redesign needs a one-to-one map from every old URL to its replacement, built before launch. Google's site move guidance says to build the old list from server logs over a window accounting for seasonal traffic: "Check your server logs for URLs that were visited at least once recently." Google's list includes images and videos, not only pages.

One-to-one is the part teams skip under deadline pressure. Pointing a thousand retired URLs at the new home page is fast, and it throws away the specific relevance each of those pages had earned. Map each old URL to the new page that actually replaces it. Where no replacement exists, choose deliberately between the nearest relevant page and an honest 404, rather than defaulting to the front door.

Then update everything else naming the old paths: internal links, canonical tags, the sitemap, any hreflang annotations. A redirect still carrying every internal link is doing a job the links should do directly.

What Google says about the redirects themselves

Use server-side permanent redirects. Google's documentation recommends 301 or 308 specifically: "we recommend that you use HTTP permanent redirects if possible, such as 301 and 308." Point each one straight at its final destination, and where a chain is unavoidable, Google advises no more than three hops and fewer than five.

The duration is where most teams underinvest. Google's site move documentation is direct about it: "Keep the redirects for as long as possible, generally at least 1 year." That is a year of old server configuration kept alive after the new site feels finished, a hosting budget decision as much as a technical one, and worth raising before launch.

When the Change of Address tool applies, and when it does not

The Change of Address tool applies only to a domain or subdomain move, not to a redesign that reorganises paths on the same domain. Search Console's documentation sets the scope: the tool "can be used only on properties at the domain level". A redesign that keeps the domain never touches it, whatever the URLs do underneath.

Where it does apply, the sequence matters. Put the redirects in place first, hold both properties in the same Google account, then start the move. Google's documentation notes that signal forwarding continues for 180 days after a migration is started, shorter than the one-year redirect advice above: the redirects outlive the tool, and the longer number is the one to plan for.

How long the dip should last, and when it stops being normal

Expect a temporary dip on a URL-changing move and give it a few weeks. Google states the expectation directly: "The visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site's rankings will settle down over time."

On timing, the same documentation says a medium-sized site can take a few weeks for most pages to move in the index, and larger sites longer. Knowing that number makes the dip survivable as a business decision. Three weeks of softer traffic is the documented cost of the move. Eight weeks with no recovery is a migration error, and Google's traffic-drop guidance sends you back to the site move troubleshooting steps rather than to new content. Record which URLs earned impressions in the 90 days before launch, then check that same list after, URL by URL rather than as a site total.

What a redesign looks like when the migration runs as a built system

A migration checklist is a document somebody has to remember to open. A built system checks the same things on every deploy: the old-to-new map held in the routing layer rather than a spreadsheet, the crawl block absent from production by configuration, and index status on the same screen as bookings.

A page that dropped out of the index then shows up that week rather than at the next audit. Mirastart builds sites as server-rendered HTML, so the title, H1 and opening paragraph of every page exist before any script runs, which is also what keeps them readable to the AI crawlers that do not execute JavaScript. The booking system on this site's own discovery-call page calculates real availability and confirms automatically; the online booking and repair-status software Quick Auto NC runs its bays on is ours, and so is the Carolina Sky Painting website. A redesign hands those systems a new template, not a new set of URLs to guess at.