How to redesign a website without losing SEO

Work out which kind of redesign you are doing before anything else, because the risk is very different for each:

Google's own guide to site moves says that "a small to medium-sized website can take a few weeks for most pages to move", that larger sites take longer, and that visibility "may fluctuate temporarily during the move. This is normal." (Google Search Central: site moves with URL changes)

The risk scale and the protections in the table are our own summary of that guidance, not Google's wording.

Everything you record now is your baseline. After launch you compare against it, page by page.

• Crawl the live site with a crawler such as Screaming Frog or Sitebulb. Export every URL with its status code, title, meta description, H1, canonical and word count.
• Export Search Console's Performance report by page, over the longest date range it offers: clicks, impressions and average position for each URL.
• Export your most-linked pages from Search Console's Links report, which lists your top-linked pages and exports to CSV or Google Sheets (Google: Links report), or from a backlink tool if you have one.
• Save today's XML sitemap and robots.txt.
• Record the structured data on each template (Organization, LocalBusiness, Product, FAQ, Breadcrumb).
• Take a speed baseline in PageSpeed Insights for the homepage and your top pages. Google counts LCP within 2.5 seconds, INP under 200 milliseconds and CLS under 0.1 as good (Google: Core Web Vitals).
• Confirm analytics and conversion tracking work, so a broken tag is not mistaken for an SEO loss later.
• Flag the do-not-touch pages: any URL that gets clicks, has backlinks or brings in enquiries.

Not sure what your current baseline looks like? Our free website audit checks the site you have now before anything changes.

Every old URL needs a decision. Use one row per URL:

These rows only illustrate the format. They are not client data.

Rules, with Google's guidance behind each one (site moves, redirects):

• Keep a URL unless you have a reason to change it. Every row that needs no redirect is one less thing that can break.
• Go straight to the final address. Google advises "redirecting to the final destination directly". Avoid chains (old, then interim, then final).
• Use a permanent server-side redirect (301 or 308). Google says a server-side redirect "has the highest chance of being interpreted correctly". Meta refresh is a fallback, and JavaScript redirects are only for when you can't do either.
• Redirect to the closest match, not the homepage. Google warns against sending many old URLs "to one irrelevant single URL destination, such as the home page". Those might be treated as soft 404s.
• Keep redirects "for as long as possible", which Google puts at "generally at least 1 year", and consider keeping them indefinitely for people who arrive from old links and bookmarks.
• Update your own internal links to the new URLs. Do not lean on redirects for your menu and body links.

The design can change completely. These things should not change unless you mean them to:

• Body text on pages that rank. Rewriting a ranking page is a content change, not a redesign. Do it later, one page at a time, and measure each one.
• Title tags and meta descriptions. New themes and platforms often replace them with template defaults.
• One H1 per page, with the same wording. Designs often turn headings into styled boxes that are no longer headings.
• Internal links. Tucking links into a mobile menu is fine. Deleting whole link groups, such as a footer list of services or related posts, is not. Google can only discover links that are <a> HTML elements with an href attribute (Google: JavaScript SEO basics).
• Image alt text and filenames on images that bring in Google Images traffic.
• Structured data. Compare each template with the baseline you recorded.
• Canonicals. Google asks for each new URL to have a self-referencing canonical, using the new URLs, never the staging host or the old domain.
• hreflang on multi-language sites. Google says to "update the annotations to use the new URLs".
• Speed. The new site should match or beat the old LCP, INP and CLS. Hero videos, sliders and heavy font files are the usual culprits.
• Rendering on JavaScript frameworks. Google says "server-side or pre-rendering is still a great idea". Check the rendered HTML in the URL Inspection tool and confirm the main text and links are there.

On staging

• Put staging behind a password. Google's guidance is that password protection keeps content out of search, while noindexed content "can still be linked to and visited through other web pages" (Google: control what you share). A password also cannot be copied to production by mistake, the way a noindex tag can.
• Crawl staging and compare it with your baseline: titles, H1s, canonicals, word count and internal links.
• Run the whole redirect map against staging. Every row should return one 301 to a page that answers 200.

Launch hour

• Remove the staging password, and confirm production has no noindex meta tag or X-Robots-Tag header. Google lists this explicitly: "Don't forget to remove any noindex or robots.txt blocks that were only needed for the migration."
• Check that robots.txt does not contain Disallow: /.
• Spot-test your top redirects, plus http to https and www to non-www (or the reverse).
• Submit your sitemaps in Search Console. Google's move guide has you submit both sitemaps saved from your mapping (old URLs and new URLs), then remove the old one once Google is using the new one.
• Moving to a new domain? Use Search Console's Change of Address tool. Google says you only need it when moving from one domain or subdomain to another, not for an http to https move.
• Send a test enquiry (form, call click or booking) and confirm analytics records it.

The SEJ figures come mostly from Ahrefs estimates and cover domain changes only, not redesigns on the same domain.

What to watch: in Search Console, check the Pages report (the "Not found (404)" and "Excluded by noindex" counts), Performance compared with the same period before launch, and Crawl stats. Check daily in the first weeks, then weekly.

1. Is it tracking or traffic? If Search Console clicks are steady but analytics is down, the problem is the tag, not SEO.
2. Which pages lost clicks? Compare Performance by page, before and after. Losses are usually concentrated on a handful of URLs.
3. Do those old URLs redirect properly? Look for 404s, temporary 302s, chains and redirects to the homepage.
4. Did their content, title or H1 change? Restore the old wording on the pages that lost ground.
5. Is anything noindexed, canonicalised elsewhere or blocked? Run URL Inspection on each page that lost traffic.
6. Did internal links disappear? Compare the links pointing to those pages in your old crawl and your new one.
7. Is the new site slower, or is the text only there after JavaScript runs?

Fix it quickly. Glenn Gabe of GSQi, who audits failed migrations, writes: "If you do fix the problem quickly, those urls can regain their previous rankings." But "if you wait too long, and then try to fix those redirects, you often will not recover the lost rankings" (GSQi).

We are a remote studio that redesigns and rebuilds WordPress, Astro, Next.js and React sites. The checklist on this page is the one we work through on a rebuild. You can see two live sites we built: Cali Taxes & Notary, built on Astro, and Pest Control of India, built on WordPress.

For costs, see our pricing page, which is shown in your currency. To get your baseline before anything changes, start with a free website audit of the site you have now, or tell us about your project.