Website Redesign Without Losing SEO: A Complete Checklist

A website redesign without losing SEO is entirely possible if three things survive the launch: every old URL either stays the same or 301-redirects to its closest new match, the content and internal links that earned your rankings come across intact, and nothing from staging (a noindex tag, a robots.txt block, a password) leaks onto the live site. Benchmark first, map every URL, launch clean, then watch Search Console for at least 4 weeks.

That’s the whole answer in one paragraph. The rest of this post is the checklist I actually work from, split into before, during and after, plus the handful of decisions that change it.

Will a Website Redesign Affect SEO?

Yes, almost always a little, and sometimes a lot. A redesign that keeps every URL, every heading and every paragraph is mostly a visual change, and Google barely notices. A redesign that changes URLs, cuts pages, rewrites copy and swaps the theme in one go is a different animal.

Google’s own site move guide says to “expect temporary fluctuation in site ranking during the move.” It also notes that for a medium-sized site, it can take a few weeks or more for Google to start showing the new URLs instead of the old ones. So a short wobble is normal. A slide that keeps going after 30 days is not.

When I look at a redesign that went wrong, the cause is rarely the design itself. It’s a missing redirect, a deleted page that had backlinks, or a staging noindex tag nobody removed.

The Four Variables That Change Your Redesign Plan

Before I write a single redirect rule, I answer four questions. Each one changes how much of the checklist applies to you.

1. Are URLs changing? If no, you skip most of the redirect work. If yes, the redirect map becomes the most important file in the project.
2. Is content changing? Keeping the copy and swapping the theme is low risk. Rewriting or merging pages is where rankings move.
3. Is the domain changing? A new domain is a full site move and adds the Change of Address tool. Same domain means it isn’t.
4. Is the platform changing? Moving from Wix or Squarespace to WordPress, or from WordPress to Shopify, usually forces URL changes even if you didn’t plan any.

Is a Redesign a Site Move in Google’s Eyes?

Not exactly, and this distinction confuses a lot of people. Google’s site move documentation covers moves where URLs change: HTTP to HTTPS, a new domain, or path changes like example.com/page.php?id=1 to example.com/widget. A redesign on the same domain with the same URLs isn’t on that list at all.

My take is simple. If your redesign changes even some URL paths, treat those pages as a site move and follow Google’s URL-change guidance: permanent redirects, updated internal links, self-referencing canonicals and a fresh sitemap. If no URL changes, you only need the content, staging and launch checks below.

The Change of Address tool in Search Console is only for domain or subdomain changes. Don’t go looking for it on a same-domain redesign.

Before the Redesign: Crawl, Benchmark and Map

This phase does most of the work. If you skip it, you have nothing to compare against when traffic dips, and you can’t tell a normal wobble from a real loss.

Crawl the Old Site and Export Search Console Data

Crawl the live site with a tool like Screaming Frog or Sitebulb and save the full list of URLs, titles, H1s, canonicals and status codes. Then export Search Console performance data with the date range set to the last 16 months, which is the longest Search Console keeps. Google’s own traffic drop debugging guide recommends that same 16-month view so you can separate real drops from seasonal ones.

Export by page and by query. Honestly, the page export matters more, because it tells you which URLs actually earn clicks. Those are the pages you protect at any cost.

Also pull your top linked pages from your backlink tool. A page with zero traffic but strong backlinks still deserves a redirect.

Build the URL Inventory and Redirect Map

Put every old URL in one column and its new destination in the next. Each old URL gets one of three outcomes: kept as is, redirected one-to-one to the closest matching new page, or retired with a 404 or 410 when there’s genuinely no equivalent.

Use permanent redirects. Google recommends server-side 301 or 308 redirects for moves, and if you’re unsure which code fits which case, my 301 vs 302 redirects guide walks through it. Never redirect everything to the homepage. That’s the single fastest way I know to throw away the relevance a page built up.

Decide What Content Stays

Redesign teams love to trim. Before you cut a page, check whether it has clicks, impressions or links in your exports. If it does, keep it, merge it into a stronger page with a redirect, or rewrite it on the new design. Don’t just delete it because it “looks old.”

During the Build: Staging and On-Page Signals

The build phase is where the quiet mistakes happen. Nothing breaks visibly, so nobody notices until the launch.

Lock Down the Staging Site the Right Way

Keep staging out of Google with password protection (HTTP authentication) first, and a noindex tag as a backup. Google’s robots.txt documentation says robots.txt “is not a mechanism for keeping a web page out of Google.” It also says a noindex only works if the page isn’t blocked by robots.txt, because Googlebot has to crawl the page to see the tag.

So a staging site with only Disallow: / in robots.txt can still get URLs indexed if someone links to it. Password protection is the clean answer. I prefer it because it also stops clients from sharing a half-finished site.

Keep Content, Headings and Internal Links

Copy the ranking content across word for word unless you have a reason to change it. Keep the title tags, H1s and the main internal links that point to your money pages. A new mega menu often drops links to pages that used to sit in the old sidebar, and those pages lose internal link signals overnight.

Update internal links to point straight at the new URLs. Google’s site move guide says to change internal links from the old URLs to the new ones, and relying on redirects inside your own navigation just adds hops.

Carry Over Canonicals and Structured Data

Every new page should have a self-referencing canonical tag pointing at its own new URL, not the old one and not the staging domain. I’ve seen staging hostnames baked into canonicals more times than I’d like.

Rebuild any structured data the old theme output: Organization, Product, Article, BreadcrumbList. A theme swap can silently remove it. If the site has hreflang annotations, update them to the new URLs as well.

Prepare the New Sitemap and Robots.txt

Generate an XML sitemap that lists only the new, indexable, 200-status URLs. My XML sitemap best practices post covers what belongs in it. Write the production robots.txt now, so launch day isn’t the first time anyone looks at it.

Launch Day: The Checks I Run in the First 60 Minutes

Launch day is short if the prep was done. Here’s the order I work in:

1. Remove the staging password and any sitewide noindex. Google’s site move guide says it plainly: remove any noindex or robots.txt blocks that were only needed for the migration.
2. Load the live robots.txt in a browser. Confirm there’s no leftover Disallow: /.
3. Deploy the redirect map and test a sample of old URLs, including your top 20 by clicks. Each should return one 301 hop to the right page.
4. Crawl the new site. Look for 404s, redirect chains, noindex tags and canonicals pointing anywhere unexpected.
5. Submit the new sitemap in Search Console.
6. Use URL Inspection on the homepage and two or three key pages to confirm Google can fetch and render them.

After Launch: What to Monitor and for How Long

The first 4 weeks tell you whether the redesign held. I check Search Console a few times in week one, then weekly.

The Page indexing report is the main dashboard. Watch “Not found (404)”, “Excluded by noindex tag”, “Blocked by robots.txt” and “Page with redirect.” The redirect count should rise as Google processes the old URLs, which is expected. A spike in 404s or noindex exclusions on pages you want ranked is not.

Compare clicks and impressions by page against your 16-month export. Look at the same weeks last year too, so a holiday dip doesn’t scare you into the wrong fix.

Keep the redirects in place. Google’s guidance is to keep them “for as long as possible, generally at least 1 year,” which means 12 months as a floor. I’d go further and keep them permanently. Old backlinks keep sending people through them for years.

Website Redesign Without Losing SEO: The Copyable Checklist

Paste this into your project tracker. It covers the full sequence above.

BEFORE
[ ] Crawl old site: URLs, titles, H1s, canonicals, status codes
[ ] Export GSC performance (last 16 months) by page and by query
[ ] Export top linked pages from backlink tool
[ ] Build URL inventory: keep / redirect 1:1 / retire (404 or 410)
[ ] Write redirect map (301 or 308, never all to homepage)
[ ] Flag pages with clicks, impressions or links as protected

DURING
[ ] Staging behind password (HTTP auth) + noindex as backup
[ ] Ranking content, titles and H1s carried over
[ ] Internal links point directly at new URLs
[ ] Self-referencing canonicals on every new page (no staging host)
[ ] Structured data rebuilt and tested
[ ] Hreflang updated (if used)
[ ] New XML sitemap: only 200, indexable, canonical URLs
[ ] Production robots.txt written

LAUNCH DAY
[ ] Password and sitewide noindex removed
[ ] Live robots.txt checked (no Disallow: /)
[ ] Redirects deployed, top 20 old URLs tested (single hop)
[ ] Full crawl of new site: 404s, chains, noindex, canonicals
[ ] New sitemap submitted in Search Console
[ ] URL Inspection on homepage + key pages

AFTER (weeks 1 to 4, then monthly)
[ ] Page indexing report: 404, noindex, robots.txt, redirect counts
[ ] Clicks and impressions by page vs 16-month benchmark
[ ] Fix new 404s that had traffic or links
[ ] Keep redirects in place (at least 1 year, ideally forever)

Redesign Decision Matrix

If you can, split a risky project into two launches: move URLs first, change content later. When both change at once and traffic drops, you can’t tell which change caused it.

Where This Checklist Stops

This post covers the redesign itself. For the broader list of crawl and index problems, see my common technical SEO issues guide and the full technical SEO checklist. For keeping the new WordPress site healthy afterwards, the WordPress maintenance checklist picks up where this one ends.

If you’d rather not run the launch alone, my team handles WordPress launches and the care that follows through our WordPress maintenance service, and we build new sites through web design and development from $159. If the redesign already went live and traffic dropped, start with SEO recovery or a free SEO audit.

Frequently Asked Questions

How Long Does It Take Rankings to Recover After a Redesign?

Google says a medium-sized site can take a few weeks or more before the new URLs replace the old ones in results. If the redirects and content are right, I expect things to settle within that window. A decline that keeps going past a month usually points to a missing redirect, lost content or an indexing block.

Should I Keep the Same URLs When Redesigning?

If you can, yes. Keeping URLs removes the biggest risk in the whole project. Change them only when the old structure is genuinely broken, such as parameter URLs or dates in blog slugs, and then map every one with a permanent redirect.

Do I Need the Change of Address Tool for a Redesign?

Only if the domain or subdomain changes. Google’s guide limits the Change of Address tool to domain and subdomain moves. A same-domain redesign, even with new URL paths, doesn’t use it.

Can I Block My Staging Site With Robots.txt Alone?

I wouldn’t. Google says robots.txt isn’t a way to keep a page out of its index, and a blocked page can’t show Googlebot its noindex tag. Use a password on staging and keep noindex as a second layer.

Last updated: October 2026 by Mizanur Rahman