Redesigning your website without losing your rankings

The measurable risk in a redesign is organic clicks. Search Console reports them per page and per query, and after a careless relaunch the line can fall on the day the new site goes live. The cause is rarely the new design. It is whatever changed underneath it, which means URLs, content, page titles, internal links and, occasionally, a single line telling Google to go away.

What follows is the sequence I use when I move a client to a new site, in the order it happens. It applies to a restaurant with twelve pages and a firm with three hundred. The bigger the site, the more the spreadsheet matters.

What a ranking is attached to

Google has learned your site one URL at a time. Each page that ranks has an address, some content, links pointing at it from elsewhere and a history of being crawled. A redesign that changes the address without saying so throws that history away, and the new page starts from nothing.

Four things can move in a redesign. They are URLs, content, links and indexing instructions. The job is to keep each one stable, or to map the old version to the new one explicitly.

Before you touch anything, record the current site

You cannot tell afterwards what you lost unless you wrote down what you had. Do this while the old site is still live.

• Crawl the whole site. A desktop crawler such as Screaming Frog, which has a free version for small sites, will export every URL with its status code, title, meta description, H1, canonical and the number of internal links pointing to it.
• Export Search Console. Take the Performance report by page and by query. Search Console keeps sixteen months of data, so save the export. It is your baseline.
• Export analytics. Landing pages and conversions (enquiries, bookings, calls) for the same period.
• List the pages with inbound links. The Links report in Search Console shows your most linked pages. Those URLs need the most careful redirects.
• Write down the queries that matter. The twenty or thirty searches that bring you business, and where you currently appear for each.
• Keep a full copy of the old site. Along with its robots.txt, its XML sitemap and any redirects already in place.

This takes an afternoon. Skipping it can take months to put right.

How risky is your move

Not every redesign carries the same risk, and it helps to know which kind you are doing.

• Same domain, same URLs. The lowest risk. The design changes and the addresses do not, so most of the work is making sure content and indexing instructions survive.
• Same domain, new URLs. The most common case, and the one where redirect mapping earns its keep.
• New domain. Higher risk, because every signal has to transfer to a new address. It needs the redirects, the Change of Address tool and more patience.
• New platform. Moving from one content system to another often changes URL patterns without anyone intending it, so check the generated addresses early.

On a twelve-page site you can map every URL by hand. On a site with several hundred, write pattern rules for the bulk, such as every old blog post moving to the same folder, and map the pages that earn traffic or links by hand.

Decide what stays

Sort the crawl by clicks from Search Console. Pages with clicks or inbound links are assets. Keep their URL, their topic, their headings and the substance of their copy. Improve them in place. A page that already ranks for the thing your customers search is usually doing its job, so a redesign should change how it looks and leave what it says.

The best redirect is no redirect. If /services/ is the right address on the new site as well, keep it.

Redirect mapping

A 301 is a permanent redirect. It tells browsers and Google that a page has moved for good, and that the old address should be replaced by the new one. Build a spreadsheet with three columns, one each for the old URL, the new URL and the reason. Every URL in the baseline crawl needs a row.

The rules I apply to every map:

• One hop. The old URL goes straight to the final URL. Chains of redirects are slower and fragile.
• The closest equivalent. Sending every old page to the home page is a common shortcut, and Google may treat such redirects as soft 404s.
• Honest dead ends. Where nothing replaces a page, let it return a 404 or a 410 and move on.
• Every variant. The http and https versions, the www and non-www versions, trailing slashes, upper and lower case, and any old query-string URLs that were indexed. Include PDFs and images that attract links.
• Server-side only. Redirects belong at the server or the edge, not in JavaScript or a meta refresh.
• Tested in bulk. Run the whole old-URL list through the redirects and check each returns a 301 and ends at a 200 on the intended page.
• Kept for a year or more. Google's guidance for site moves is to keep redirects in place for at least a year. Where it costs nothing, keep them longer.

Build it in private

The staging site must not be indexed. In order of reliability:

1. Put it behind a password with HTTP authentication. Nothing gets in, whether it is Googlebot or a link forwarded by a well-meaning client.
2. Add a noindex instruction, as a meta robots tag or an X-Robots-Tag header.
3. Use robots.txt only as a third layer. It stops well-behaved crawlers fetching pages, but Google can still list a blocked URL if other pages link to it, and it cannot see a noindex on a page it is not allowed to fetch.

Staging is also where the comparison happens. Crawl it and set the result against the baseline crawl. Check every page that ranks for its title, H1, canonical and internal links, then run the redirect list against it before launch.

The most expensive line in web design is Disallow: /, copied from staging to live.

What to carry across

Put the baseline crawl and the staging crawl side by side and look for differences you did not choose.

• Titles and meta descriptions on pages that rank. Change them deliberately.
• Headings and body copy. Keep the substance of any page that earns traffic.
• Internal links. Every page you keep should be reachable from the navigation or from related pages. A page with no internal links pointing at it is orphaned, and Google has a harder time finding and valuing it.
• Canonical tags. They must point at the final live address, never at staging.
• Structured data. Opening hours, address, articles and any FAQs you mark up. Keep them and validate them.
• Images. Alt text, and file names where your images bring in search visits.
• Content in the HTML. Use the URL Inspection tool to view the page as Google fetched it. If the words only appear after JavaScript runs, make sure Google can still see them.
• Speed. Google's thresholds for a good experience are a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of real visits. A heavy hero video can undo a lot of speed work, as covered in page speed for small business websites.

Launch day

Work down the list in order and tick each item off.

• Remove the password and every noindex tag, then open /robots.txt and confirm it does not contain Disallow: /.
• Switch on the redirects and run the full old-URL list through them.
• Confirm the canonical tags and the XML sitemap list live URLs only.
• Submit the new sitemap in Search Console.
• Inspect the home page and your five most important pages with the URL Inspection tool, and request indexing.
• Check HTTPS on every page, and that the http and www versions redirect to the one you chose.
• Submit each form once and confirm the email arrives.
• Check analytics and conversion events are recording.
• Check the 404 page returns a real 404 status and not a 200.
• Check the website, menu and booking links on your Google Business Profile still land on the right pages.
• If the domain is changing, use the Change of Address tool in Search Console. A redesign that keeps the same domain does not need it.

Launch on a Tuesday morning. A Friday launch finds its problems on Saturday, when nobody is at their desk.

The first week

Look every day for seven days. Ten minutes is enough if the baseline is ready.

• Page indexing report. Watch for rises in Not found (404), Excluded by noindex tag, Blocked by robots.txt and Page with redirect, for any URL that should be a live page.
• Performance report. Compare clicks and impressions by page and by query against the baseline, like for like by day of the week.
• A fresh crawl. Run it once more on the live site to catch broken internal links, redirect chains and missing titles.
• Analytics landing pages. Look for any that now return a 404, and for pages whose sessions fell off sharply.
• Server logs. If you can read them, look for Googlebot requests that return 404.
• Your own searches. Search the queries that matter in a private window and note where you appear against the baseline.

Google warns that a move which changes URLs can cause temporary fluctuations while it reprocesses the site. A small dip that recovers sits inside that. A cliff on day one points to a fault you can find, and it is usually in the indexing instructions or the redirects.

Weeks two to eight

Review against the baseline at two, four and eight weeks. Fix the 404s that matter by adding redirects for them. Update the links you control to the new URLs directly, starting with your Google Business Profile and moving on to social profiles, email signatures, directory listings and newsletters. That reduces your reliance on redirects. If another site links to a page whose address changed, ask for the link to be updated where it is worth the effort.

Settling can take weeks. Do not rewrite pages in the middle of that window unless the data shows a real fault.

What to tell the owner before launch

Whoever pays for the site should know what to expect before the switch. Share the baseline numbers. Say which days you will check and what you will report. Explain that some movement in the first weeks is normal and that you will flag anything outside that. It turns an alarming graph on day three into a conversation you have already had.

If it goes wrong

Work through the causes from cheapest to most expensive to fix.

1. Indexing instructions. A noindex tag, a robots.txt block or a password still switched on.
2. Redirects. Pages that used to rank returning a 404, or redirecting somewhere unrelated.
3. Canonicals and sitemaps pointing at the wrong host, or at staging.
4. Rendering. Content missing from the HTML Google receives.
5. Content and structure. Rewritten titles, merged pages, lost internal links.
6. Speed regressions.

The first three can usually be fixed within an hour of finding them. Evidence first, opinions second.

Done this way a redesign is a dull project, which is the intention. We run migrations like this as part of our web design work, with the local SEO checks alongside. The anonymised engineering firm example describes a rebuild that kept every page that already ranked, with redirects for the rest.