A redesign rarely makes a site drop because of its design. It makes it drop because URLs change without a redirect plan, and because content gets shorter along the way. The method comes in three steps: take inventory before touching anything, redirect each old URL to an equivalent new page, then monitor for several weeks. Google asks for permanent redirects, kept for at least a year, and allows a few weeks for most pages of a small to medium-sized site to migrate.
Contents
The scenario is always the same. The new site looks better, loads faster, and finally matches what the company has become. Three weeks after launch, traffic has halved and nobody understands why, since “the site is better than before”.
Maybe it is. But Google indexes addresses, one by one. A redesign that changes the addresses without telling Google where the pages went wipes out each page's history in one go. Here is how to avoid that, in order.
01What a redesign really breaks
Three mechanisms explain almost every post-redesign drop. None of them has anything to do with looks.
Addresses change, and the history stays behind
Each indexed URL carries years of signals: the links pointing to it, its age, the rankings it has earned. When /our-services/plumbing.html becomes /services/plumbing/ without a redirect, Google finds a 404 error on one side and an unknown page on the other. Nothing connects the two, and the new page starts from zero.
Content shrinks without anyone deciding it
This is the most frequent cause, and the most discreet. The new design is clean, so long texts become three-line teasers. Pages that ranked because they answered a question precisely no longer answer anything. Traffic drops on URLs that were correctly redirected, and people look for the problem in the wrong place.
The internal structure gets rebuilt at random
A new menu, new templates, and internal navigation changes completely. Pages that received ten internal links no longer receive a single one; others end up three clicks from the home page instead of one. The way internal links are distributed gets entirely redone during a redesign, and almost never on purpose.
02The inventory, before touching anything
Everything that follows becomes impossible if you did not record it while the old site is still online. It is the only moment the information exists.
| What you record | Where | What it is used for later |
|---|---|---|
| All indexed URLs | Search Console, sitemap, full crawl | Building the redirect plan |
| The pages that bring traffic | Search Console, analytics | Knowing which ones must not move at all |
| Starting rankings and queries | Search Console, 3 to 6 months | Measuring afterwards, on the same basis |
| Incoming external links | Backlink tool | Spotting the URLs you cannot afford to lose |
| The text of every page that matters | Content export | Checking it has not shrunk afterwards |
On the text, the most useful check is a simple comparison: the word count of each page before, the same after. A page that goes from 900 words to 200 has lost what made it stand out, however good the new template is. This list takes an hour to draw up, and in hindsight it explains half the drops that get blamed on redirects.
This record serves as the reference for six months. Without it, the only question that matters after launch, “did we lose something or is it the season?”, will go unanswered. It is also what separates a managed redesign from one you simply undergo, and the starting point of the audit I deliver before any project.
03The redirect plan
This is the centerpiece, and also the most botched one. Google asks for permanent server-side redirects, the 301 and 308 codes, and specifies that a permanent redirect serves as a signal that the new address should be canonical. A temporary redirect, on the other hand, keeps the old page in the results.1
One old page, one equivalent new page
The rule fits in one sentence: each old URL goes to the page that covers the same topic. Not to the home page, not to a catch-all category. A mass redirect to the home page is treated as a disguised 404 error, and loses exactly what you were trying to save.
Chains and dead ends
An old URL that redirects to a second one, which redirects to a third, ends up diluting the signal and slowing down crawling. You flatten everything: each old address points directly to its final destination. And you check that no redirect loops back on itself, which makes the page inaccessible without anything flagging it.
The case of a domain change
Changing addresses at the same time as the site combines both risks, and also requires a change of address request in Search Console.2 It can be done cleanly: on a redesign with a domain migration carrying twenty-five years of archives, the redirect plan was written before launch and the rankings held.
One last point, the one everyone forgets: Google asks you to keep redirects for as long as possible, at least a year.2 They are not taken down after two months because “it looks like it went through”.
04Launch day, and the weeks that follow
The launch day order
Google gives a sequence: set up the redirects, check the rel="canonical" tags, test the redirects, submit the change of address request if applicable, then submit the new sitemap.2 In practice, verification comes first: you test the plan on the staging environment, line by line, before the public sees anything.
How long it takes
Allow a few weeks for most pages of a small to medium-sized site to migrate, longer for a large site.2 A drop during this window is normal and proves nothing. It is afterwards that you need to look.
A recent report gives finer benchmarks. On October 2, 2026, at the Search Central Live Deep Dive Europe in Barcelona, Google's Gary Illyes presented time ranges which, according to an attendee's report, rest on an internal Google analysis.3 Google had not published the slides at the time of the Search Engine Journal article, and the report gives neither a sample size nor a definition of what “typical” covers.3 These figures therefore serve as benchmarks for knowing whether a step is still in progress or stuck.
Benchmarks, step by step
The table keeps the steps that concern a redesign. Each row gives the typical time reported, the slow case, and where in Search Console you can see whether the step has been completed.
| Step | Typical3 | Slow case | To check in Search Console |
|---|---|---|---|
| Discovery of a new URL | about 20 hours | weeks, or never | URL Inspection tool: the message “URL is unknown to Google” means it has never been detected4 |
| Recrawl of a known URL | about 30 days | weeks, or never | The same tool gives the date of the last crawl4 |
| Processing a sitemap | about 24 hours | up to 14 days, or never (quality) | Sitemaps report: status and date last read5 |
| End-to-end indexing | about 1.5 hours | months, or never (quality) | Page indexing report, which counts crawled and indexed URLs6 |
| Canonical change | 1 to 3 weeks | months (conflicting signals) | URL Inspection tool: “Google-selected canonical” field4 |
| New page title | 1 to 2 days | several weeks to several months | Last crawl date: it shows whether Google has seen the page again since the change4 |
| Site move | 1 to 3 months | 6 months to over a year | Sitemaps report with the old and new sitemaps: indexed pages in the first fall toward zero, those in the second rise2 |
These steps are linked: according to the report, Gary Illyes warned that a page must be crawled before it is indexed, so delays add up.3 The same report defines end-to-end indexing as the moment all critical processes have completed, and notes that a small site move can be done in a few weeks.3
For canonicals, Google's troubleshooting guide states that pages can stay in a duplicate cluster for up to two weeks after their content has been fixed.7
In the slow cases, several steps end with “never”. For processing a sitemap as for end-to-end indexing, the report adds quality in parentheses.3 The Search Console documentation points the same way for a sitemap that is not read: among the causes it cites low crawl demand, which rises with the quality of the site's content.5 Before concluding there is a quality problem, rule out the common causes that keep Google from reading a valid sitemap, from blocking by robots.txt to an unresolved manual action.5
A site move still incomplete after three months sits at the top of the typical range reported, whereas slow cases run from six months to over a year.3 Three months without rankings coming back justify going back to the starting inventory and the redirect plan.
The report also gives figures for cases unrelated to a redesign: 1 to 2 weeks to lift a manual action, and 3 to 6 months to recover from a core update, until the next update in slow cases.3 Google's documentation on core updates points the same way: some changes take effect within a few days, the systems may take several months to confirm that the site is consistently producing helpful content, and sometimes you have to wait for the next update.8 It also recommends waiting a full week after an update has finished rolling out before analyzing the site in Search Console.8
What to monitor
- The 404 errors that appear, in Search Console and in the server logs. Each one is a forgotten redirect.
- Index coverage, to check that new URLs come in as fast as the old ones go out.
- Rankings on the queries recorded before, page by page. A global average will tell you nothing.
- Structured data, which silently disappears nine times out of ten when templates change. The markup that feeds rich results never survives a redesign on its own.
- Impressions in AI features, which are now reported separately in Search Console. I have detailed elsewhere what this report really lets you measure, and above all what it does not say.