Website redesign SEO: how to redesign without losing rankings

Where redesign SEO losses come from

A search engine ranks addresses, not websites. When an address changes or disappears, the page that earned its position goes with it unless you tell the engine where it moved. That is the core risk of a redesign.

Losses usually come from a short list of errors: URLs changed with no redirect, old pages deleted with no replacement, redirects that all point to the home page, titles and headings rewritten without thought, internal links left pointing to old addresses, and a block meant for the test site left on at launch.

Google’s “Site Moves and Migrations” documentation describes the process of a site migration and notes that rankings can fluctuate for weeks or longer, depending on site size. Careful work reduces the dip. It does not guarantee there will be none.

Step one: crawl and record a baseline

Before anything changes, crawl the current site with a tool that exports every URL, its status code, title, meta description, headings, canonical tag and internal links. Save the file. It is your record of what existed.

Add the pages that matter most. Google’s documentation says to build the list of old URLs from sitemaps, top-traffic pages, server logs, your CMS and the Search Console links report. Include images, videos and files that earn traffic or links.

Record the numbers you will compare against: organic clicks and impressions by page, rankings for the main queries, enquiries from organic search and Core Web Vitals. Export them at least 90 days back so a seasonal pattern is not mistaken for a loss.

Step two: map every URL

URL mapping is a spreadsheet with one row per old URL and the new URL it should lead to. It is the most important document in the project. Google’s documentation says to map each old URL to its new destination.

Choose the destination by relevance, not convenience. A page about “boiler repair” should lead to the closest new boiler repair page. Google advises against redirecting many pages to an irrelevant one, such as the home page. If a page is truly gone with no equivalent, let it return a 404 or 410 status code.

Keep URLs the same where you can. Google’s URL structure guidance favours readable words, hyphens, one letter case and few parameters. If the old addresses already follow that and the pages remain, there is no reason to change them just because the design changed. Every address you keep is one less redirect to get wrong.

Step three: redirects done properly

A 301 redirect is a permanent, server-side instruction that tells browsers and search engines a page has moved. Google’s “Redirects and Google Search” page says permanent redirects, such as 301 and 308, signal that the target should be the canonical URL, and that server-side redirects are the most reliable kind.

Do not use temporary redirects for a permanent move. A 302 or 307 does not signal that the new URL should be canonical, so the old address may keep appearing in results.

Avoid a redirect chain, where A goes to B and then to C. Google’s site move documentation says to avoid chains and to keep them ideally under three hops. After mapping, test every old URL and confirm it reaches its final destination in one step with a 200 status.

Keep redirects for the long term. Google says at least one year, and considering indefinitely, because old links and bookmarks keep arriving. Do not remove them to “tidy up” in the first year.

Step four: keep staging out of search, then let launch in

A staging site is a private test copy of the new site. If search engines index it, you create duplicate content and a second public site. Block it with a login, or with a noindex rule, which tells search engines not to index a page.

Google’s noindex documentation has an important caveat. If robots.txt blocks a page, the crawler never sees the noindex rule, so the page can still appear in results when others link to it. Use password protection for staging where you can.

Then comes the classic launch error. The block that protected staging is copied to the live site, and the new site tells search engines to stay away. Make “remove all staging blocks” a named line on the launch checklist, and check the live robots.txt file and page source after launch.

Step five: carry over content, metadata, links and schema

Pages that rank should keep their substance. Keep the main text, headings and the questions each page answers. You can improve wording, but do not delete the sections that earned the position. Google’s helpful content guidance asks for original, accurate and useful content, so remove only what fails that test.

Carry over titles and meta descriptions, then improve them page by page rather than rewriting all at once. Add self-referencing canonical tags on the new pages, which Google’s documentation lists as part of preparing the new site. Update hreflang annotations if you have several languages.

Fix internal links so they point straight to the new URLs, not through redirects. Redirects are a safety net, not navigation. Update the XML sitemap too, and remove redirect chains from internal links. Google’s sitemap documentation says a sitemap helps discovery but does not guarantee crawling or indexing.

Re-add schema markup, such as organisation, local business, product and FAQ data, and validate it. Missing structured data is a common silent loss. Make sure the mobile and desktop versions carry the same content, because Google indexes the mobile version first.

When the domain changes: Change of Address

If the move goes from one domain or subdomain to another, such as old-name.com to new-name.com, use the Change of Address tool in Search Console after the redirects are live. Google’s help page says you must own both properties, set up redirects from the old home page and ideally other pages, and include every verified variant of the old domain.

The tool is not for every change. Google says it is not needed for HTTP to HTTPS moves, www and non-www switches, path changes within the same domain, or hosting changes where URLs stay the same.

The effects of the tool last 180 days, and Google advises keeping redirects at least that long, longer if old URLs still get search traffic. Avoid chaining moves or merging several sites into one at the same time, since both make results harder to trace.

Step six: monitor and fix after launch

In the first week, check daily. Use the Search Console Page indexing report for new errors, the Sitemaps report for submission problems, and your server or CDN logs for 404 and 5xx responses. Google notes that warnings in the Sitemaps report about old URLs redirecting are expected.

Repeat the crawl on the live site and compare it with the baseline. Check that every old URL redirects once to a 200 page, that titles and canonicals are right, and that important pages are indexable.

Compare organic clicks, impressions and enquiries with the baseline for pages and groups of pages, not only the site total. A drop concentrated in one section points to a specific mistake. Review weekly for the first couple of months, because Google says changes can take weeks or longer to settle.