The new site went live on a Tuesday. By the following Monday, organic sessions were down 38 percent and nobody on the call could say which of the forty things that changed was responsible.
That gap between launch and explanation is where most redesign projects lose their nerve. The design is better. The pages load faster. The traffic is gone anyway, and the people who approved the budget want an answer this week.
Here is what actually happens to search traffic in the first month after a relaunch, which five changes cause most of the damage, how to tell from your own data which one hit you, and how long the recovery genuinely takes.
Ask three agencies to price SEO for website redesign work and you will get three numbers, none of them sourced. The loss depends on how many URLs changed, whether the redirects are clean, and how much content survived the rebuild. A cosmetic refresh on identical URLs might cost nothing. A platform move with a new URL structure and a trimmed sitemap can cost half your organic sessions for a quarter.
What can be pinned down is the timing. Google’s documentation on site moves with URL changes states that “for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones”, and that visibility “may fluctuate temporarily during the move”.
Read that carefully, because it reframes the whole first month. A drop in the days after launch is Google working through a recrawl, not proof that something broke. The signal that something broke is a drop that has not started closing by week three.
The number worth putting in front of a finance team is not a percentage anyway. It is what a quarter of reduced organic sessions costs in pipeline, set against what website redesign and SEO preparation would have cost to run properly before launch. The preparation is almost always the cheaper line, and it is the only one of the two you can still choose.
| Cause | What you see in Search Console | How quickly it can be fixed |
|---|---|---|
| Missing or broken redirects | Spike in 404s, old URLs still in Pages report as Not found | Hours, once the map exists |
| New URL structure | Old URLs excluded as Redirect, impressions flat while clicks fall | Weeks, mostly waiting |
| Content removed in the rebuild | Queries disappear entirely rather than dropping position | Days to restore, weeks to recover |
| Template internal links dropped | Deep pages lose impressions while the homepage holds | One template change |
| Core Web Vitals regression | LCP or CLS fails in the Core Web Vitals report | Days to weeks, depends on the build |
The website redesign timeline that matters is not the build schedule. It is the four weeks after go-live, and each one tells you something different.
Week 1. Googlebot starts finding the new URLs and re-crawling the old ones. Impressions move erratically. Rankings for some queries hold, others vanish and reappear within days. Almost nothing you see this week is a reliable signal, and teams that panic here tend to make changes that confuse the recrawl further.
There is one thing worth doing in week one, and it is not reading rankings. Open the Crawl stats report and check that Googlebot is requesting the new URLs at all. If crawl requests have collapsed rather than spiked, the problem is access, not ranking, and it is usually a robots.txt file or a noindex tag that shipped with the staging build.
Week 2. The drop becomes visible in analytics and someone senior notices. This is usually the week the real cause is already sitting in Search Console, unread.
Compare the Pages report against your pre-launch URL export rather than against last month’s traffic. Traffic tells you something is wrong. The Pages report tells you which URLs Google now considers Not found, Redirect, or Crawled and not indexed, and those three buckets point at three different fixes.
Week 3. This is the week that separates a normal dip from a broken relaunch. If clicks have started climbing back, the move is processing as Google described. If the line is still flat on the floor, something structural is wrong and waiting longer will not fix it.
The comparison that settles it is impressions against clicks. Impressions holding while clicks fall means the pages are still in the index and the move is working through. Impressions falling with them means pages have dropped out, and that is a redirect or a deleted-content problem rather than a patience problem.
Week 4. The decision point. Either you are watching a recovery curve, or you are running a website redesign SEO audit to find what the launch broke. The audit itself is an afternoon of work when the pre-launch URL export exists, and several days when it does not. Waiting past this point without a diagnosis is how a six-week dip turns into a six-month one.
These are ordered by how much traffic they typically take, not by how often they appear on a website redesign checklist.
1. Redirects that were never mapped. Every URL that changed needs a permanent redirect to its closest equivalent. Google’s guidance on 301 redirects is that “Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical”. Without that signal, the new page starts from nothing and the old page’s history is stranded.
2. Top pages that did not survive the rebuild. The pages driving the most organic traffic are rarely the pages the redesign team cares about. A three-year-old comparison post with no visual appeal can be carrying a third of the site’s search traffic, and it gets cut for being off-brand.
One of the main reasons and causes of why websites lose traffic after a migration is because they haven’t actually taken into consideration all of their top, meaningful pages to be migrated to their new location.
3. Internal links that lived in the old template. Sidebars, footers and related-post modules pass a lot of signal, and a redesign that simplifies the layout usually deletes hundreds of internal links in one commit. The homepage holds its rankings. Everything three clicks deep quietly loses them. A well-planned design system makes this visible before launch, because link placement becomes a component decision rather than an afterthought.
4. URL structure changed for tidiness. Shortening paths and renaming sections feels like housekeeping. To Google it is a full site move, with the recrawl period that comes with it. If the structure change was not worth a month of reduced visibility, it was not worth doing during a redesign.
5. Performance regressions from the new build. Heavier hero images, client-side rendering, and third-party scripts added during the rebuild push Core Web Vitals out of range. Google’s thresholds are LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less.
This one rarely causes the initial drop by itself, and it reliably slows the recovery from everything else. The frontend development choices behind it get made weeks before anyone runs a Lighthouse test, usually in a framework decision nobody thought of as an SEO decision.
A website relaunch SEO review does not take a week. An hour in Search Console will usually name the cause, as long as you work through it by symptom rather than by checklist.
If the Pages report is filling with Not found errors on URLs that used to rank, the redirects are the problem. If old URLs are showing as Page with redirect and impressions are broadly intact while clicks fall, the move is processing and you are mostly waiting. If specific queries have disappeared rather than slipped, go and find the page that used to answer them, because it probably no longer exists.
The pattern worth learning is the shape of an internal linking problem. Homepage and top-level pages hold steady, deeper pages lose impressions together, and the drop maps to template depth rather than to topic. That is not a Google problem. That is a navigation decision.
Two things hide from a quick look. Redirect chains, where an old URL points to a second old URL before reaching the live page, resolve for a human browser and waste crawl budget at scale. And a redirect that lands everything on the homepage counts as a redirect in your spreadsheet while telling Google the old page has no equivalent. Both show up in the Pages report only if you read the Redirect group rather than the Not found group.
Read more: the importance of long-term product maintenance after launch
Post-launch monitoring is the part most teams staff for two weeks and then drop, which is exactly when the useful data arrives. Most performance and maintenance engagements start on sites that launched three or four months earlier and never got a proper diagnosis.
Fix in this order, because the first item returns traffic in days and the last returns it in months.
Repair the redirect map first. Pull every URL that had organic clicks in the twelve months before launch, check each one resolves to a live, relevant page, and fix the misses. This is the single highest-return hour of the whole recovery. Google’s own instruction is to “keep the redirects for as long as possible, generally at least 1 year”, which is worth repeating to whoever schedules the cleanup sprint.
Restore the content that was cut, at the same URL where possible. A page brought back at its original address recovers faster than the same content published at a new one, because the old signals still point there.
Template internal links come next, and this is the repair teams skip because it looks cosmetic. Put the removed modules back as components, then re-crawl and confirm that pages three clicks deep are reachable in fewer hops than before the redesign. Performance work comes last, since it changes the rate of recovery rather than whether recovery happens.
Expect the curve rather than a step change. If the redirect repair happens in week three, the first movement usually shows the following week and the line keeps climbing for a month or two after that. Where frontend development is heading matters here too, because rendering choices decide how quickly a recrawl can even see the restored content.
Be honest about the ceiling. If a redesign removed twelve thin pages that ranked for queries nobody was going to buy from, that traffic is gone and the site is better for it. The number to defend is qualified sessions, not total sessions, and a redesign is a reasonable moment to reset which one you report on.
Most website redesign SEO considerations come down to one discipline: knowing what you have before you change it. Export every URL with organic clicks and impressions, rank them by traffic, and hand that list to the design team as a constraint rather than a suggestion.
I think the most important part is really to track the individual URLs, so that you have a clear map of what previously was and what it should be in the future.
Handing over a ranked URL list changes the conversation from taste to evidence. The design team is not being asked to keep an ugly page. They are being told which pages the business cannot afford to lose, which is a different argument and a much easier one to win. Good design principles survive that constraint without much trouble, because hierarchy and clarity were never the reason those pages ranked.
Three decisions do most of the protective work. Keep URLs unchanged unless there is a reason worth a month of volatility. Map every URL that does change before a single page is built. Keep the old template’s internal links in the new component library, even when the new design is cleaner without them.
The rest is sequencing. Launch to a staging environment that a crawler can reach, run the redirect map against it, and fix the misses before go-live rather than after.
Treating SEO and website redesign as one workstream instead of a handover is what removes most of the first month of damage. It is mostly a scheduling choice. The questions worth asking about SEO when redesigning a website all need answers before the first template gets built, and UI and UX design is where those answers get locked in.
We run the URL and content inventory before the design work starts, so the pages carrying the traffic are known constraints rather than late discoveries. The redirect map gets tested against staging, not written after launch from memory.
If a relaunch has already happened and the traffic has not come back, the first job is the diagnosis, not a rebuild. Most of the sites that come to us after a bad launch need a redirect repair and a template fix, which is a fortnight of work rather than a second redesign.
Work with Brickclay
Brickclay is a digital transformation partner with multiple disciplines in one team: data and analytics, AI and automation, cloud infrastructure, product engineering, brand experience and digital marketing. 100+ specialists. 300+ projects.
Tell us what you're building. We'll tell you which of our teams you need, and which you don't.
Unified data pipelines, warehouses, and lakes built for scale.
Build Your Data Foundation
Master the 12 principles of design and learn how to apply each one to create clearer, more purposeful visual work. Examples and practical tips inside.
A design system speeds front-end delivery, keeps UI consistent, and scales product growth. See how reusable components and tokens drive real ROI.
94% of first impressions are design-driven. Here are 10 proven ways professional brand design increases revenue, from conversions to premium pricing.
Branding mistakes confuse customers and stall growth. Here are the strategy, design, and execution errors to avoid, plus how to fix each one and protect trust.
