The short answerA redesign keeps your rankings when the pages Google already knows keep their address, their content and their links, or when every changed address redirects once to its closest match. Freeze what ranks, build a one-to-one redirect map before the build, and test on a locked staging site. Google gives no fixed recovery time, so measure against a baseline.
Last updated 26 October 2026.
The redesign plan at a glance
| Phase | When | What you do | Pass check | Owner |
|---|---|---|---|---|
| Baseline | Before the build | Export ranking pages, links, titles and traffic. Record AI answers for your tracked questions | Every page that earns traffic or links is on one list | SEO lead |
| Freeze and map | Before design sign-off | Decide what stays, what merges, what goes. Build the redirect map | Every old URL has one target | SEO lead and developer |
| Build and staging | During the build | Test on a locked staging site. Check rendered HTML, titles, structured data | Staging cannot be reached by a crawler. Key text is in the rendered HTML | Developer |
| Launch day | The day of launch | Switch redirects and sitemaps on together. Lift every noindex rule | Old URLs return one redirect to a live page | Developer and SEO lead |
| First week | Days 1 to 7 | Read errors, indexing and crawl access daily | No unexpected errors in the Page indexing report | SEO lead |
| Watch | Weeks 2 to 12 | Read traffic, rankings and AI answers against the baseline | The trend returns toward baseline | SEO lead |
The after-launch checks are long enough to need their own page, so use our SEO migration checklist for them. What follows covers what the checklist does not: the decisions you make before the build, and the ways a redesign loses rankings in the first place.
Redesign, relaunch and migration are different jobs
People use the three words as one. They carry different risk, and the risk decides how much redirect and crawl work you owe.
| Job | What changes | SEO risk | What you must do |
|---|---|---|---|
| Visual redesign | Look and layout only. Every URL and every word stays | Lower | Check templates, titles, internal links and rendering. Keep the addresses |
| Relaunch | New structure, new copy, some new URLs | Medium to high | Map every changed URL. Redirect each one. Audit content against what ranked |
| Migration | New platform, new domain or both | Highest | Everything above, plus Search Console's Change of Address tool when the domain changes |
Google's documentation splits site moves in two: moves where URLs change, and moves that do not affect the user-visible URL. A redesign that keeps every address is covered by neither page by name, so that reading is ours and Google does not state it. Whatever you call the job, the fewer addresses and words you change, the less Google has to re-learn.
What a redesign changes that can cost you rankings
Most losses trace to a handful of causes. Check each one before design sign-off.
Navigation and copy that live in script. A new menu or footer built from scripted click handlers can hide whole sections of the site from the crawler. Google says it can only discover links that are anchor elements with an href attribute. Copy carries the same risk when a rebuild moves it into client-side script: Google says content that is not visible in the rendered HTML cannot be indexed, and it still calls server-side or pre-rendering a great idea because not all bots run JavaScript. Test the rendered page, and skip the design file.
Two template problems are quick to check:
- Titles. A single pattern stamped on every page works against Google's own advice. Google says the title it shows can differ from your title element, and it asks for titles that are descriptive, concise and unique per page.
- Structured data. When the new design drops an FAQ or a table and the markup stays, the two disagree. Google says not to mark up content that readers cannot see.
Then there is speed. Google recommends good Core Web Vitals: a Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads. On weight, Google says it always seeks to show the most relevant content, even when page experience is sub-par, and that a great page experience can help where lots of helpful content is available. Protect speed through the rebuild, but do not expect it to outweigh relevant content.
Freeze what ranks before you design
Pull the list of pages that earn clicks, links or AI citations, and mark each one before design starts. Our default is to keep every indexed URL alive in a redesign cleanup. Give each old page one of three outcomes, and treat the third as the exception.
- Rewrite in place when the topic still fits your strategy. The address stays and the page improves.
- Merge with a 301 when a stronger page already covers the same intent. The weaker address redirects to the stronger one.
- Remove with a 410 only when the topic is off strategy, no good redirect target exists and the content cannot be rescued.
Headings follow the same logic. Google says heading order is not a ranking concern. Keep your headings for a reason that serves readers: they match the questions people ask. Keep titles and descriptive text on pages that already rank, and change them on purpose rather than as a side effect of a template.
Build the redirect map before the build
Google tells owners to map old URLs to new URLs and decide where each old one should go. Build that map from the freeze list while the design is still on the table. A map made after launch is a repair job.
| Old URL | New URL | Type | Priority | Owner |
|---|---|---|---|---|
/services/old-service | /services/new-service | 301 | High, earns traffic | Developer |
/blog/old-post-a | /blog/stronger-post | 301 | Medium, merged | SEO lead |
/blog/old-post-b | /blog/old-post-b | None | High, address kept | SEO lead |
/old-landing-page | No target | 410 | Off strategy | Developer |
The rules for the map:
- Use permanent, server-side redirects. Google recommends them and names 301 and 308. It says permanent redirects do not cause a loss in PageRank. Temporary types (302, 303, 307) show the old page in results. JavaScript redirects are a last resort because Google might never see one if rendering fails.
- Send each URL to its closest match, in one hop. Google advises redirecting to the final destination directly, and says chains add latency for users and that not all user agents and browsers support long chains. Do not point everything at the homepage.
- Set a pass mark. Before launch, test every old URL in the map. Each one should return a single redirect to a live page.
- Keep the redirects. Google says to keep them as long as possible, generally at least one year. Bing's guidance says at least one to two years, preferably longer. Treat one year as the floor.
- Keep your canonical signals tidy. Google lists redirects and the canonical tag as strong signals for which URL is the main one and sitemap inclusion as a weak one. Use a self-referencing canonical tag on each page and list the new URLs in the sitemap.
Lock the staging site and test what Google will see
Google says robots.txt is not a way to keep a page out of Google, and that a robots.txt block stops Google from ever reading a noindex rule. Put staging behind a login or an IP restriction, and add noindex on top of that. For a redesign with the same URLs, Google's guide also suggests checking Googlebot access with the URL Inspection tool.
Then test the build the way a crawler reads it:
- Open the rendered HTML of ten page types and confirm that titles, headings, body text and internal links are in it.
- Compare the new pages with the old ones, page by page, for everything that ranked: the main answer, the table, the FAQ and the proof.
- Check that structured data matches what a reader sees.
- Confirm the firewall or bot protection on the new setup does not block Googlebot. Google flags this on moves.
- Write down every noindex rule used during development. You will lift each one at launch.
Launch in this order
- Switch the redirects and the new sitemap on at the same moment as the new pages.
- Lift every noindex rule on the list.
- Fetch ten old URLs and ten new URLs and confirm each response.
- Submit the sitemap in Search Console and inspect your key pages.
- Start the watch with the checklist.
According to Google, the crawl rate of Googlebot drops for a short time after a launch that changes nothing in the URLs, then rises steadily over the next few days. A drop in crawling by itself is not a fault.
Keep your AI search visibility through a redesign
Most redesign guides stop at Google. Your buyers also ask ChatGPT, Perplexity, Claude and Gemini, and a redesign can cost you answers as well as rankings. Four things matter.
Server-rendered text. Vercel and MERJ reported in December 2024 that none of the major AI crawlers they measured rendered JavaScript, apart from Gemini and AppleBot. That is one network and late-2024 data, so check current behavior before you rely on it. Whatever a fresh check shows, the safe design choice is to put your answers in the HTML the server sends.
Addresses that stay alive. The same study found ChatGPT spent 34.82% of its fetches on 404 pages, against 8.22% for Googlebot. The study did not test redesigns. The inference is ours: if you change addresses without redirects, AI crawlers hit dead ends at a higher rate than Google does. After launch, read your server logs for AI-bot 404s. They show which old addresses the engines still ask for, and the paths worth redirecting.
Bot access. OpenAI and Anthropic each document a search bot, a training bot and a fetcher that runs when a user asks a question. Anthropic says its bots honor robots.txt, while OpenAI says robots.txt rules may not apply to ChatGPT-User because a user starts those visits. Perplexity documents two: PerplexityBot, which surfaces sites in its search results and which it says is not used to crawl content for AI foundation models, and Perplexity-User, which generally ignores robots.txt because a user requested the fetch. A new firewall or robots.txt can block the search bot for an engine without you noticing. OpenAI says sites opted out of OAI-SearchBot will not be shown in ChatGPT search answers, and Anthropic says blocking Claude-SearchBot may reduce your visibility in Claude's search results.
Pages the engines already use. In our own Peec reading of 120 answers from 26 August to 1 September 2026, AI engines named LoudFace only when a loudface.co page was among the answer's sources. If a redesign breaks retrieval of the pages the engines cite, they have nothing to name. Google says AI Overviews and AI Mode need no special optimization beyond a page that is indexed and eligible for a snippet, so for Google the job is to keep the page indexed and readable.
Before the build, record how the engines answer your tracked buyer questions. After launch, run the same questions again, one engine at a time, over weekly windows, and compare each engine with its own baseline.
How long recovery takes, and what we do not know
Google says to expect temporary fluctuation in rankings during a move, and that it can take a few weeks or more for Google to start showing new URLs in place of old ones. A small or medium site can take a few weeks for most pages to move, and larger sites take longer. Google gives no number of days for rankings to return.
Our own view is that a major rewrite on an indexed address often shows a dip in Search Console for four to eight weeks before it recovers. That is our judgment from client work, and Google publishes no such figure.
For a hard number, the best public sample is a Search Engine Journal study of 892 domain migrations, published 8 January 2025. It found an average of 523 days for the new domain to match the old one's organic traffic, and 17% of the migrations had not matched it after 1,000 days. Treat that with care. It covers domain moves only, and it uses estimated traffic from third-party tools.
We found no named study that measures traffic loss from redesigns, so we do not quote a loss percentage. Figures like that, when you see them, usually trace back to agency blogs and not to a primary study.
What our redesign work looks like
When we rebuilt the site for Icypeas, we rebranded the company and built the website from scratch in 8 to 12 weeks, from brand strategy through launch. The new CMS meant the marketing team could update content in minutes where it had taken a developer hours. The case study covers the scope.
Do the after-launch work
Once the site is live, the work becomes checking. Run the crawl, redirect, tracking and AI checks in our SEO migration checklist, then keep your 30, 60 and 90 day readings against the baseline from the first row of the table above. If you want a second pair of eyes on a redesign plan before the build, our SEO and AEO team does this work, and our AI visibility audit shows where your pages stand with the engines today.
