How to redesign a website without losing SEO
Will a redesign hurt your rankings?
It can, even when every URL stays the same, because Google has to relearn pages whose HTML changed. Google’s own rule for site moves is to change one thing at a time. The breaks that cost traffic are well known, and most can be tested before launch.
What actually breaks in a redesign?
| What the thread shows | Threads | One example |
|---|---|---|
| Redirects missing, wrong, chained, unreliable or sent to the homepage | 10 | After a redesign, URLs lost their “.html” ending with no redirects, and new 404 errors showed up in Search Console every day. Google forum, February 2025 |
| The project also changed domain, moved to a subdomain or switched to HTTPS | 8 | An events site moved from .it to .me. Clicks fell from about 8,000 a month to about 300, with two-hop redirects and new language versions added in the same move. Google forum, April 2026 |
| The owner couldn’t separate the launch from a Google update | 5 | A redirect plugin was swapped early in 2026, then Google’s May 2026 core update landed. Impressions are down about 39% year on year and the owner can’t say which did it. Google forum, October 2026 |
| Robots.txt blocks, noindex, or thousands of pages left unindexed | 3 | After pages moved to a subdomain, about 190,000 of them sat as crawled but not indexed, while old redirecting URLs were indexed again. Google forum, May 2026 |
| Several big changes shipped at once | 3 | A 15-year-old finance site moved to HTTPS, changed its WordPress theme and updated its content together, and its top-3 rankings disappeared. Reddit, March 2026 |
| Main content missing from the HTML Google reads | 2 | On a replatformed site, the homepage’s main text appeared only after JavaScript ran, and Google’s Rich Results Test showed it blank. Google forum, July 2026 |
| Same URLs, new design, and no cause found | 2 | A WordPress theme change with no URL changes. Daily visitors fell from more than 4,000 to about 1,000. Reddit, December 2025 |
Google’s own list of common site-move mistakes reads much the same. In order: noindex or robots.txt blocks left over from the build, incorrect redirects, other crawl errors, a server too small for the extra crawling, and sitemaps nobody updated. On redirects, Google’s site-move guide says: “We frequently see people redirecting to the wrong (non-existent) URLs on the new site.”
In the threads, “The redirects are done” was the claim that most often turned out to be incomplete. The replies that found the real fault were the ones that opened the live site and tested it. Most replies guessed.
Which kind of change is this?
| Change | What moves | What Google asks for | Change of Address tool |
|---|---|---|---|
| Redesign, same URLs | Templates, layout, navigation, often headings and copy | No dedicated document. Asked about a redesign that kept its content and URLs, Google’s John Mueller said changing the layout “can affect your search results” (office hours, September 25, 2020). Keep the main content, titles and internal links stable. | No |
| New URLs, same domain | Paths and slugs, including HTTP to HTTPS or dropping “.html” | A map from every old URL to its new one, permanent redirects on the server, and updated canonical tags, internal links and sitemaps (site moves). | No |
| New domain | Every URL, including subdomains | Everything in the row above, plus Change of Address in Search Console for every verified version of the old domain, once the redirects are live (Change of Address). | Yes |
| New platform (CMS) | URL patterns, templates, and any redirects the old platform kept for you | Treat it as new URLs plus a redesign. Google’s guide suggests keeping the same content management system for a move where you can (site moves). | Only if the domain changes |
| New host or CDN | Servers, DNS or the CDN (content delivery network). URLs stay the same | A test environment, ideally limited to your own IP addresses, noindex on any temporary hostname, and crawl blocks removed at the switch. Googlebot’s crawl rate may dip, then rise over a few days (changing your hosting). | No |
Change one thing at a time
Google’s site-move guide gives this rule its own heading: “Change only one thing at a time.” Its example is a team that wants a new domain, a new CMS and a new layout. Google’s answer is to do them one after another: move to the new domain first, change the layout after.
On Google’s Search Off the Record podcast in February 2023, members of Google’s Search Relations team explained why. Search engines work out a page’s main content from the structure of its HTML. Change that structure and Google may pick out the wrong part of the page for a while, until it relearns it. Change the URLs at the same time and it becomes hard to tell which change cost what (listen from 18:33).
Their suggestion for a rebrand that also changes domain: restyle inside the HTML you already have (colours, logo, menu) and leave the main content where it is. That much can ship with the move. A bigger redesign waits for a second stage, perhaps months later.
If the business needs it all at once, hold whatever you can stable, in this order: URLs, the main content’s HTML, titles, internal links. Then test harder. Every change you add is another suspect if traffic falls.
Before design starts: record the baseline and every old URL
Export 16 months of Search Console data. Clicks, impressions and average position, by page and by query. Search Console shows at most 16 months. After launch you’ll compare each month with the same month a year earlier, which is how Google’s own guide to traffic drops separates a real drop from a seasonal one.
Save the pages that earn the traffic. For the pages that bring most of your clicks, often a few dozen, save the HTML as the server sends it, plus the title, H1, canonical tag and structured data. That copy is what you compare staging against.
List every old URL, not only the ones in the sitemap. Google’s site-move guide suggests your sitemaps, server logs, analytics, the Links report in Search Console and your CMS. Add a crawl of the live site and the Wayback Machine’s archive, which still holds URLs that left your sitemap years ago but keep links from other sites. The free redirect checker can pull old URLs from the archive for you.
Include files, not only pages. Images, PDFs and videos you host can rank and earn links. Google says their URLs “need to be moved in the same way as all other content”.
Collect the redirects you already have. Redirects from earlier redesigns, and the ones some platforms create automatically when an editor changes a page’s URL, vanish in a platform switch unless someone exports them. Point each one straight at its final new URL, so nothing chains.
Pick the launch date. Google suggests launching during a seasonal or weekly low, so fewer visitors meet any problems and your server has more room for Googlebot. If you can, also avoid the days a Google core update is rolling out: a launch inside an update window is hard to read afterwards. Google posts updates on its Search Status Dashboard as they start, and our update calendar lists them.
The redirect map: Google’s rules
One old URL, one matching page. Send each old URL to the new page that replaced it. If several old pages were merged into one, they can all point at the merged page.
Never the homepage as a catch-all. Google’s site-move guide warns that many old URLs redirected to one irrelevant page, such as the homepage, “might be treated as a soft 404 error”: a page that answers “OK” but that Google treats as missing. The old page’s rankings don’t carry over.
Permanent, and on the server. Use a 301 or 308 status code, which tells Google the page has moved for good. A 302 or 307 is temporary, and Google keeps showing the old URL in its results. Use a JavaScript redirect only if nothing else is possible: Google says it “might never see it” if rendering fails (Redirects and Google Search).
One hop. Point every old URL straight at its final page. Googlebot follows up to 10 redirects in a row, but where a chain can’t be avoided Google asks for “ideally no more than 3 and fewer than 5”. Chains usually come from redirects left over from earlier redesigns.
Let removed pages be gone. If a page isn’t coming to the new site and nothing replaces it, let it return 404 (not found) or 410 (gone), as Google’s guide asks. Don’t redirect it somewhere unrelated to keep it alive.
Redirects don’t cost link credit. Google: “301 and other permanent redirects don’t cause a loss in PageRank.” The losses come from redirects to the wrong page, or no redirect at all.
Point your own links at the new URLs. Update internal links, canonical tags, hreflang tags (the tags that connect language versions) and the XML sitemap, so your own site never sends Google through a redirect. Ask the sites that send you the most visitors to update their links too.
Keep them for at least a year. Google: “Keep the redirects for as long as possible, generally at least 1 year.” For visitors, it suggests keeping them indefinitely. After a domain move, keep paying for the old domain for at least a year as well, so nobody else can buy it and use it.
Change of Address is for domain moves only. Submit it in Search Console once the redirects are live, for every verified version of the old domain (www, non-www, subdomains). Google says you don’t need it for HTTP to HTTPS, for www to non-www on the same domain, or for path changes (Change of Address tool).
What “the redirects are in place” can hide
Each of these comes from a thread where the redirects were said to be done:
Old URLs sent to the homepage at launch. The owner’s IT team fixed it later; five months on, one category still hadn’t recovered (Google forum, March 2025).
A page that looked fine in a browser but sent a 503 status (“service unavailable”), and an old mobile path nobody had mapped, which went through a meta refresh and two more redirects (Google forum, March 2026).
Rules that took about a day to switch on and then answered inconsistently from outside, while the developers’ own tools said they worked (Google forum, October 2026).
Two hops where one would do, on a domain move that lost most of its clicks (Google forum, April 2026).
Google has seen a stranger one. On Search Off the Record, the Search Relations team described a site whose redirect fired for people but not for Googlebot (listen from 15:03).
How to test the map
Test from outside your own network: logged out, with no cache, the way Googlebot arrives. For every old URL, record each hop’s status code and address, and where it finally lands. A pass is one hop, a 301 or 308, landing on the mapped page, which answers 200 (OK).
For a handful of URLs, curl -sIL followed by the old URL prints every hop. For hundreds, paste the list into the free redirect checker, which flags homepage redirects, chains and errors. To see what Google itself gets for a few URLs, use URL Inspection in Search Console.
What must not change in the HTML
Put each top page from your baseline next to its staging version. Change these on purpose or not at all:
Main content. The same text, in the same place, and present in the HTML the server sends. Google queues pages for rendering (running their JavaScript), and that can take a while. If your main text only appears after JavaScript runs, check that Google’s rendered view shows it, in URL Inspection or the Rich Results Test (JavaScript SEO basics).
Titles and headings. The title tag, one H1, and the order of the headings below it. If a title has to change, change it after the launch has settled, and write down the date.
Internal links. Menus, footers, breadcrumbs and related-content links tell Google which pages matter. A slimmer menu can leave pages with no links pointing at them.
Canonical tags. The canonical tag names a page’s preferred URL. On the new site, each page’s canonical should point at itself, on the production domain, never at staging or the old domain.
Structured data. Carry over the markup behind any rich results you get today, such as product or breadcrumb markup.
Robots meta tags. No noindex on any page that should rank. Don’t plan to remove a noindex with JavaScript: Google “may skip rendering and JavaScript execution” on a page that has one.
Images. The same file URLs, or a redirect for each one, and the same alt text.
Speed. Check Core Web Vitals on the staging templates. Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024 (web.dev), so a checklist that still asks for First Input Delay is out of date.
The free noindex checker reads robots.txt, the robots meta tag, the X-Robots-Tag header and the canonical tag for any URL.
The launch checklist: pass or fail
| Check | How to test | Pass when | Google source |
|---|---|---|---|
| Old URLs covered | Compare the redirect map with your full list of old URLs | Every old URL with clicks, links or a sitemap entry has a destination, or is meant to return 404 or 410 | Site moves |
| Redirect type | Request each old URL from outside your network | A 301 or 308, sent by the server. No 302, 307 or JavaScript redirect | Redirects |
| Redirect target | Compare where each old URL lands with the map | The mapped page, answering 200. The homepage only where it really replaces the old page | Site moves |
| Hops | Count the redirects for each old URL | One. Never more than 3 | Site moves |
| Removed pages | Request the old URLs you chose not to keep | 404 or 410 | Site moves |
| Missing pages | Request a URL that never existed, such as /this-page-does-not-exist | 404. A “not found” page that answers 200 is what Google calls a soft 404 | HTTP status codes |
| Noindex | Read the robots meta tag and the X-Robots-Tag header on every template | No noindex on any page that should rank | Robots meta tag |
| robots.txt | Fetch /robots.txt on the live domain | No rule blocks pages that should rank. The file answers 200, or 404 if you don’t have one | Site moves |
| Canonical tags | Read the rel="canonical" tag on every template | Each page points at its own production URL. No staging host, old domain or HTTP version | Site moves |
| Rendering | Compare the page source with Google’s rendered view (URL Inspection or the Rich Results Test) | Main text, title and links are all in what Google renders | JavaScript SEO |
| Page content | Compare top pages with the baseline: title, H1, headings, main text, structured data | Unchanged, or changed on purpose and written down | Office hours, 2020 |
| Internal links | Crawl the new site | No links to old URLs or to redirects. Top pages have at least as many internal links as before | Site moves |
| XML sitemap | Fetch it and request every URL in it | Only full new URLs you want in Google’s results, each answering 200 and indexable | Sitemaps |
| hreflang, if you use it | Read the language alternates on each version of a page | Every alternate is a new URL that answers 200 | Site moves |
| Search Console | Check verification for the old and new sites | Every version verified (www, non-www, HTTP, HTTPS), with the verification file or tag carried over | Site moves |
| Analytics | Load each template and watch the real-time report | One page view per page load, on every template | Site moves |
| Server capacity | Ask your host, then watch the server logs after launch | The extra Googlebot crawling after the move causes no errors or slowdowns | Site moves |
| Staging access | Open staging from outside, logged out | Behind a password or an IP restriction. If it has to be public, noindex on every page | Hosting |
Launch day, in order
Lift the staging blocks. Remove the noindex rules and robots.txt blocks that were only there for the build. Google lists forgetting them first among common site-move mistakes.
Switch on the redirects, then test them from outside. Run the full old-URL list, not a sample, and fix failures the same day.
Run the checklist again on the live site. Production often differs from staging: caching, CDN rules, environment settings.
Submit the new XML sitemap in Search Console. Google also suggests submitting a sitemap of the old URLs, so you can watch them move across. Warnings that its URLs redirect are expected: Google says “this is normal and you can ignore these warnings”.
On a domain move, submit Change of Address. For every verified version of the old domain.
Spot-check with URL Inspection. Test a few old URLs and your top new pages live in Search Console: status, canonical, indexing and the rendered page.
Freeze other changes. Hold copy, title and template edits for the first weeks, so the results tell you about the launch and nothing else.
Two free tools cover part of the table. The redirect checker runs the redirect rows on a list of old URLs, and the noindex checker runs the noindex, robots.txt and canonical rows on any page. If you’d rather someone outside the project ran all of it, that’s Launch Cover.
The first 60 days: what normal looks like
Many checklists say to expect a 10–20% dip that recovers within weeks. We found no source for that figure, or for any like it. Judge by the pattern instead, page by page, against your baseline.
Expected after a move
Old URLs lose impressions while the new URLs mapped to them gain them, in the Search Console Performance report.
In the Pages report, old URLs move to “Page with redirect” as the new URLs get indexed.
The sitemap of old URLs shows redirect warnings, and its indexed count falls as the new sitemap’s rises.
Googlebot crawls more than usual, because every redirect is another request.
Rankings move around for a few weeks.
Not normal: test now
New URLs don’t pick up what their old URLs lose.
“Not found (404)”, “Soft 404”, “Excluded by ‘noindex’ tag” or “Blocked by robots.txt” climb in the Pages report.
“Duplicate, Google chose different canonical than user” appears for pages you meant to rank.
Pages you didn’t change lose traffic too. Look at Google’s updates (next section).
Positions hold but clicks fall. Look at AI answers on those queries.
When to look
Day 1. Run the whole old-URL list through a redirect check again, and inspect a sample of old and new URLs in Search Console.
Week 1. Read the Pages report, the Crawl Stats report and your server logs for Googlebot requests that get errors. After a hosting change, Google says a dip in crawling that recovers over a few days is normal (changing your hosting).
Every week to day 60. Compare clicks and impressions by page with your baseline and with the same weeks last year.
After day 60. Keep the redirects and the old domain. Google’s minimum for both is a year.
If traffic falls anyway: your redesign, Google, or AI?
The pages you changed lost the traffic.
If the loss sits on old URLs that now fail a redirect check, or on pages whose HTML changed, start with your redesign. Those causes are on your site, so they’re fixable.
Your redesignPages you didn’t touch fell too, on an update’s dates.
Compare the drop date with Google’s confirmed updates. The free Google update checker lines up a Search Console export with the update calendar, in your browser.
Google update checkerRankings held, but clicks fell.
Look for AI Overviews or AI Mode answers on the queries you lost. A fix on your site won’t bring those clicks back.
AIAnalytics fell, Search Console didn’t.
Then the tracking broke, not the traffic. A new template can drop the analytics tag or load it twice.
Is it real?
A launch and an update can even start on the same day. In July 2026 a site owner asked Google’s help forum why impressions had fallen to almost nothing from May 21, the day their replatform went live and the day Google’s May 2026 core update began. A volunteer expert opened the live site and found homepage text that appeared only after JavaScript ran, and a main menu still linking to an old path. Part of that drop was the site’s, whatever the update did (Google forum, July 2026).
If you can’t separate them, the free Cause Check names the leading suspects for your site, with dates and example URLs, by email within one business day. More on each suspect: your redesign, Google and AI.
How long does recovery take?
Google’s guide puts it at a few weeks or more for a medium-sized site, and longer for a large one. The move happens one URL at a time, and it is only complete when Googlebot has visited every old and new URL at least once.
On Search Off the Record, Google’s Search Relations team put the practical limit for waiting on a move at about a year, while noting that a business can rarely wait that long. In their view, when a move loses traffic, most of the time something in the setup is wrong (listen from 13:56).
| Days after the move | Recovered |
|---|---|
| 90 | 22.8% |
| 180 | 35.4% |
| 365 | 59.5% |
| 730 | 83.5% |
| 1,095 | 86.1% |
The median migration in that study took 304 days to recover, and 13.9% hadn’t recovered after three years. An earlier crowdsourced study by the same author covered 892 domain migrations: estimated organic traffic took 523 days on average to match the old domain, and 17% hadn’t matched it after 1,000 days (Search Engine Journal, January 8, 2025). The two samples may overlap.
Neither study measures a redesign that keeps its domain, and we found no study with a stated method that does. So don’t borrow these numbers for a same-domain redesign, in either direction.
What you control is the setup: every row of the checklist. How fast Google reprocesses the site is up to Google.
Three public cases
WooCommerce: a domain move between two core updates
On October 31, 2023, WooCommerce.com became Woo.com as part of a rebrand. On April 5, 2024, Woo announced it was moving back, saying the move “created challenges for our users to find WooCommerce in Google searches”, and that the problems got worse after Google’s March 2024 update. It moved back on April 9, 2024, about five months after the switch.
- Oct 2023 core updateOctober 5–19, 2023
- Moves to Woo.comOctober 31, 2023
- Nov 2023 core updateNovember 2–28, 2023
- Mar 2024 core updateMarch 5 – April 19, 2024
- Moves back to WooCommerce.comApril 9, 2024
| Month | Estimated monthly visits from US organic search, thousands: woocommerce.com | Estimated monthly visits from US organic search, thousands: woo.com |
|---|---|---|
| June 2023 | 721 | 0 |
| July 2023 | 607 | 0 |
| August 2023 | 619 | 0 |
| September 2023 | 1,041 | 0 |
| October 2023 | 906 | 0 |
| November 2023 | 201 | 124 |
| December 2023 | 48 | 182 |
| January 2024 | 30 | 105 |
| February 2024 | 21 | 128 |
| March 2024 | 9 | 131 |
| April 2024 | 16 | 90 |
| May 2024 | 244 | 35 |
| June 2024 | 946 | 0 |
| July 2024 | 987 | 0 |
What the estimates show. Across both domains, estimated US search traffic fell from about 906,000 in October 2023 to about 325,000 in November and about 135,000 in January 2024, all before the March update began. By June 2024, two months after the move back, woocommerce.com was at about 946,000 again. The move itself landed between Google’s October and November 2023 core updates.
What they can’t show. Real visits, traffic from outside the US, or how much of the fall was the move and how much the updates. The figures are third-party estimates calculated from rankings and search volumes, and single months can jump for no visible reason (September 2023, for one). Woo’s own account names the move and Google together, and from outside the evidence goes no further than that.
Made.com: the whole domain sent to one page
After Made.com went into administration in November 2022 and Next bought its brand and domains, the whole domain was redirected (301) to Next’s brand page for Made. SISTRIX, which measures search visibility, says this led to the domain’s rapid decline in December 2022. Once the redirects came off and categories and products returned from July 2023, Made’s UK visibility rose 178.6% in the first quarter of 2024 (SISTRIX IndexWatch, April 17, 2024).
BioMed Central: every page sent to one hub
Springer Nature redirected every biomedcentral.com page to a single BMC hub on link.springer.com. SISTRIX measured a 98.4% year-on-year fall in BioMed Central’s UK Google visibility and concluded that “little to no SEO authority” reached the new home (SISTRIX IndexWatch 2025, January 28, 2026).
Both are the catch-all redirect from the rules above, at company scale.
Who checks the agency’s map?
On most relaunches, the agency or developer who builds the new site also writes the redirect map, and signs it off against the same launch deadline. The threads above are full of maps that were “done”.
Before launch, ask whoever wrote yours:
Where did the list of old URLs come from, and how many URLs is it?
What happens to an old URL that isn’t in the map?
Which status code do the redirects return, and are they set on the server?
How will every old URL be tested from outside on launch day, and who fixes failures that day?
What changed in the HTML of our top pages?
Who removes the staging noindex and robots.txt blocks, and when?
Launch Cover is that check, from someone outside the project. We test your map against every old URL we can find and run our checklist on the new build before launch, crawl the site on launch day, and watch it afterwards. We don’t build websites, so we have no stake in the map passing.
Frequently asked questions
Does a website redesign affect SEO?
It can, in either direction, even when every URL stays the same. Google’s John Mueller said in 2020 that layout changes can affect search results, through titles, internal links and the context around the main content. Test the redesign against your baseline before launch, so any effect is one you chose.
Should we keep our old URLs?
If you can, yes. Keeping them takes the biggest risk off the table: no redirect map, no chains, no soft 404s. Change URLs only when the new structure is worth a migration of its own.
How long do 301 redirects take to work?
For visitors, at once. Google processes them one URL at a time as it recrawls each old URL, so a medium-sized site can take a few weeks or more to show the new URLs in search, and a large one longer.
How long should we keep the redirects?
At least a year, Google says, and indefinitely if you can, because links on other sites keep pointing at the old URLs. After a domain move, keep the old domain registered for at least a year too.
Should staging be blocked in robots.txt or noindexed?
Lock it first: a password or an IP allowlist keeps everyone out, Google included. If it has to be public, use noindex. Don’t also disallow it in robots.txt, because Google can’t see a noindex on a page it isn’t allowed to crawl. Write down every block you add, so you can remove them all at launch.
Can we launch the redesign and the domain move together?
Google’s advice is to change one thing at a time: the domain first, the layout later. If you must do both, keep the main content’s HTML, the titles and the internal links as they are and restyle around them, so the move is the only big change Google has to process.
What is an SEO migration?
Any change that makes Google reprocess your site’s addresses or infrastructure: new URLs, a new domain, a new platform, or new hosting. A redesign that keeps every URL isn’t a migration in that sense, but it still changes what Google reads on each page.
Our traffic already dropped after a relaunch. What now?
Test the old URLs first with the free redirect checker, check key pages with the noindex checker, then compare the drop date with Google’s updates in the update checker. Or ask for a free Cause Check: we name the leading suspects by email within one business day.
Sources
- Google Search Central, Site moves with URL changes. Updated .
- Google Search Central, Redirects and Google Search. Updated .
- Search Console Help, Change of Address tool. Checked .
- Google Search Central, Changing your web hosting and SEO. Updated .
- Google Search Central, Understand JavaScript SEO basics. Updated .
- Google Search Central, Robots meta tag specifications. Updated .
- Google Search Central, Build and submit a sitemap. Updated .
- Google for Developers, How HTTP status codes affect Google’s crawlers. Updated .
- Google Search Central, Debug Google Search traffic drops. Updated .
- Google Search Central on YouTube, English Google SEO office-hours. Published .
- Google Search Central on YouTube, Site moves: Are they getting any easier? (Search Off the Record). Published .
- Google, Google Search Status Dashboard. Checked .
- web.dev, Interaction to Next Paint is officially a Core Web Vital. Updated .
- SALT.agency (Dan Taylor), Only 27% of domain migrations recover in 90 days. Published .
- Search Engine Journal (Dan Taylor, 10 Spurs), How long should an SEO migration take? [Study updated]. Published .
- WooCommerce, Say hello to Woo.com. Published .
- WooCommerce, Woo.com migrating back to WooCommerce.com. Published .
- SISTRIX, IndexWatch Q1 2024: UK SEO visibility winners and losers. Published .
- SISTRIX, IndexWatch 2025: visibility losers in Google UK search. Published .
- DataForSEO Labs, estimated monthly organic search traffic from the US for woocommerce.com and woo.com. Pulled October 23, 2026.
- Public threads: 20 threads from Google’s Search Central help forum and Reddit, posted February 2025 to October 2026 and read October 23, 2026. The ones described on this page are linked where they appear.