A relaunch is one of the most critical routine events in a website’s life. Not because something visible breaks - but because something invisible does. The new site is faster, cleaner, more modern. And three weeks later the enquiries are gone, the rankings have slipped, the traffic has halved. Nobody understands why, because everything looks better.
That’s not bad luck and it’s not an isolated case. It’s a pattern with a clear cause: rankings don’t live in the design. They live in URLs, in structure, in content and in technical signals - and those are exactly what a relaunch changes, often without anyone noticing.
This article shows why that happens, which five silent risks are behind it, and in what order a relaunch has to run so that visibility survives the move. At the end there’s a real case where we had to do exactly this cleanup - and a self-check before you press the launch button.
Why a prettier design alone saves nothing
Google doesn’t rank design as taste. But it does rank the signals a relaunch often changes: URLs, content, internal links, load time, indexability and technical structure. A page that has held position 3 for a search like “electrician in Munich” for two years earned that ranking through signals attached to that one URL.
A relaunch touches almost all of those signals at once: the URL changes. The page structure changes. Copy gets rewritten, headings reordered, internal links relaid. Each of those changes is, on its own, an intervention in a ranking factor. All of them together, on a single day, are an abrupt change to many signals at once.
Google itself is clear: in a move with URL changes, temporary ranking fluctuations are normal, and a medium-sized move takes a few weeks for most pages to be reindexed. So the question isn’t whether it fluctuates - it’s whether you lose temporarily or permanently. The difference between the two is preparation.
The mistake that hits the most pages at once: redirects
When a relaunch costs rankings, missing or incorrect redirects are the cause that hits the most pages at once.
The mechanics are simple - and they forgive no gaps. The old URL ranks and has backlinks. In the relaunch the page gets a new address, the old one is deleted. If you don’t set up a redirect from old to new, you sever the connection: the old URL returns a 404, the ranking decays, and every external link that ever pointed to the old address now leads nowhere. The authority you built over years is lost.
A clean redirect strategy follows four rules:
- 1:1 mapping. Every old URL is pointed to its closest matching new counterpart - not everything bundled onto the homepage. Google effectively treats a mass redirect to the homepage as a soft 404; the value of the old pages is lost.
- 301, not 302. A 301 is a permanent redirect and carries the old page’s signals across. A 302 signals “temporary only” - a common, expensive configuration mistake.
- No chains. Old → new in one step. Google does follow several redirects in a row, but every hop costs crawl time and is one more place that breaks at the next rebuild. Shorten existing chains to the final target during the relaunch.
- Keep them long enough. Google recommends keeping redirects in place as long as possible - for a site move typically at least a year, and longer while relevant traffic or backlinks still flow through them.
What to do: The redirect map is built before launch, not after. Every existing URL is inventoried and assigned a target, before the old page disappears.
Template: the redirect map as a table
A table with these columns is enough, as a CSV or spreadsheet. Each row is one old address:
| Column | Content | Source |
|---|---|---|
old_url | Full old address | Crawl of the old site, old sitemap, Search Console (Performance, Pages) |
clicks_16m | Clicks over the last 16 months | Search Console, Performance, by page |
external_links | Yes or no | Search Console, Links, top linked pages |
new_url | Closest matching new target, never a blanket redirect to the home page | New site structure |
type | 301, or 410 for pages deliberately removed without replacement | Decision |
checked | Date of the check after launch | Acceptance, see below |
Sort by clicks. The rows at the top carry the most visits and deserve a manual check that the new target really answers the old query. Search Console shows performance data for the last 16 months, hence the clicks_16m column.
A redirect map built after launch isn’t prevention anymore. It’s damage control - and some damage can no longer be controlled.
The five silent risks
Redirects are the most common cause, but not the only one. These five mistakes do the damage nobody notices at launch - because the site works and looks good.
- An accidental
noindexor a carried-over block. During development the staging site is kept away from Google: with a password (nobody gets in), withnoindex(Google may fetch but not index) or withrobots.txt(Google may not fetch, but can still add the address to the index without content). If one of these blocks goes live with the new site, Google may not index the new pages (noindex) or may not even fetch them (robots.txt). The classic relaunch mistake, precisely because it’s invisible from the outside. - Removed or trimmed content. Pages or text that ranked well get trimmed, merged or “tidied up” during the relaunch. With them goes exactly the content Google judged the page relevant for. Prettier doesn’t automatically mean more visible.
- Collapsed internal linking. A new navigation buries pages that were previously easy to reach three clicks deep. Internal links govern how authority flows through the site - break that structure and even pages you didn’t technically change will sink.
- Performance regressions. The new design brings heavier images, a larger framework, more scripts. Load time rises, Core Web Vitals worsen - and with them a signal that feeds into the overall page experience.
- Lost measurement signals. Analytics tag forgotten, Search Console not migrated, structured data dropped in the redesign. The insidious part: you don’t just lose signals - you lose the ability to even see the damage.
What to do: Each of these belongs on a launch checklist that’s ticked off before go-live - not discovered in the troubleshooting afterwards.
The process that protects rankings
A relaunch without ranking loss isn’t luck, it’s a sequence. This one has proven itself:
1. Measure first: inventory and baseline
You can’t protect what you haven’t measured. Before anything is rebuilt, a complete inventory is created: every existing URL, its current rankings, the top pages by traffic, the most important backlinks. That’s the blueprint for everything else - and the only reference against which you can honestly judge later whether the move succeeded.
2. Build the redirect map - before launch
Every old URL is assigned its 1:1 target, as a 301. This map is the backbone of the entire move and is created while the old site still exists.
3. Preserve structure and ranking content
What ranks stays - in substance, not necessarily in layout. Well-performing content is carried over and strengthened, not trimmed in the name of freshness. Headings that carry relevance are kept.
4. Execute the launch in an orderly way
For small and medium sites, moving all URLs at once is usually the better choice - it helps the algorithms detect the move faster. Large sites can be migrated in sections if that keeps monitoring and troubleshooting more controllable. Either way, at go-live: remove the staging block and submit the new sitemap in Search Console. For a domain or subdomain move, also use Search Console’s Change of Address tool; for plain URL changes within the same domain, clean redirects and an updated sitemap are enough.
5. Acceptance on launch day
These checks run in the first hour after the switch. Each has a clear pass criterion:
| Check | Passed when |
|---|---|
| Fetch every old address from the redirect map, for example with Screaming Frog in list mode | Each answers with its planned status: 301 in one step to a target with 200, 410 where planned, 200 where the address stays the same |
Robots meta, X-Robots-Tag and robots.txt of the live site | No noindex on pages meant to rank; robots.txt blocks no content directories |
| Canonical tags | Point to the live domain, not the staging address |
| New sitemap | Contains only status-200 addresses and is submitted in Search Console |
| Live test in Search Console's URL Inspection for the five most important pages | Page can be fetched and indexed |
| Form and phone link on a phone | Test enquiry arrives |
6. Monitor afterwards
In the weeks after launch: watch page indexing in Search Console, check the canonical Google selected for the most important pages in URL Inspection, check for 404s and broken redirects, hold clicks and impressions per page against the baseline. Compare windows of the same length and expect a delay of two to three days in the data. Fluctuation is normal, but drops that do not recover after a few weeks are a signal to intervene.
Relaunch project plan: eight to twelve weeks in five phases
This is how we plan a relaunch or migration. The phases and weeks are the same as in every website project; the SEO tasks run alongside each phase, not at the end. The table works as a template for your own project plan, even if another agency builds the site.
| Phase | Weeks | SEO task in this phase | Result |
|---|---|---|---|
| Structure and search intent | 1 to 2 | Full crawl of the old site, Search Console baseline, URL inventory | New sitemap and first draft of the redirect map |
| Design | 3 to 5 | Check that every ranking page type has a place in the new design | Page types without lost content |
| Copy | 5 to 7 | Carry over and extend ranking content, metadata and structured data | All copy with documented cuts |
| Development | 7 to 10 | Staging behind a password and noindex, implement and test redirects | Finished site on staging, redirect map checked |
| Launch and handover | 10 to 12 | Acceptance on launch day (see above), submit the sitemap | Live site and redirect log |
| Monitoring | 30 days after launch | Page indexing, 404 errors, clicks per page against the baseline | Report with deviations and actions |
Do not schedule the redirect map for launch week. Then there is no time left to check it against the crawl. The first draft belongs in weeks 1 to 2.
What the Rucker Elektro case teaches about cleanup
Sometimes we don’t come for the relaunch, but for the cleanup afterwards. That was the case with Rucker Elektro, a Munich electrical company whose website we took over from a previous agency and relaunched on 25 July 2026. At takeover, two problem areas were apparent: technical data-protection risks and a setup that hadn’t cleanly preserved important SEO signals.
The clearest example: a page on electrical meter cabinet modernisation that had previously held a top position for Munich searches. Through the faulty setup and missing redirects it slipped further and further - until it eventually fell out of the index entirely. We retrofitted the redirect map and salvaged what could be salvaged. But this is exactly where the uncomfortable lesson sits: not everything was salvageable. A page that has already dropped out of the index doesn’t return on command, and not necessarily in full.
What could be repaired, we repaired. Google Search Console, the 28 days before go-live (27 June to 24 July 2026) against 4 to 31 August 2026:
- Clicks: +119%.
- Impressions: +26%.
- Queries in the top 10: +63% (rows returned by the API, a lower bound).
The average position stayed almost the same (9.55 to 9.84); one possible explanation is the many newly added queries that shape the average. The development in detail is on the cases page. Which page types carry the clicks, and that the service pages have hardly grown so far, is broken down on the page SEO for trades.
These numbers aren’t an argument for how well recovery works. They’re an argument that recovery is more expensive, slower and less complete than prevention. A properly prepared relaunch would never have lost the meter-cabinet page. The cleanup couldn’t bring it back.
If the relaunch has already happened and the rankings are gone, Traffic drop after a website relaunch walks through five checks to find the cause.
Pre-launch self-check
Before the new site goes live - can you answer these five questions with yes?
- Is there a complete list of all old URLs with their current rankings?
- Does a 1:1 redirect map (301) exist before the old site disappears?
- Is it guaranteed that the staging environment’s
noindexblock will be removed at go-live? - Is the content that ranks today being preserved - in substance, not just in look?
- Are analytics and Search Console set up for the first day after launch?
If even one answer is no, that’s the issue - not the design.
What to do now
A relaunch is no reason to sacrifice rankings - but it punishes anyone who treats it as a pure design project. If your relaunch is coming up, we check the critical SEO risks before go-live: URLs, redirects, indexing, internal links, ranking content, sitemap, tracking and Search Console. The goal isn’t a prettier launch. The goal is a relaunch that protects visibility.
That’s the core of our website relaunch service; how the move fits into an ongoing SEO strategy, we clarify in the same step.
Have your relaunch risk reviewed
Frequently asked questions
How long does it take for rankings to come back after a relaunch?
For a medium-sized move, Google's own documentation says it takes a few weeks for most pages to be reindexed; larger sites longer. With clean 301 redirects, the old pages' signals are preserved and the fluctuation is temporary. Without redirects, the loss can be permanent.
Is it enough to redirect all old pages to the homepage?
No. Google effectively treats a blanket redirect of many URLs to the homepage as an error (soft 404), and the ranking value of the old pages is lost. Every old URL needs its matching 1:1 target.
301 or 302 - does it really matter?
Yes, and the difference is expensive. A 301 is a permanent redirect and gives Google the clear signal that the new URL should be the canonical target. A 302 signals a temporary state and is the wrong choice for permanent relaunch redirects.
We already relaunched and lost traffic - is it too late?
Often not. If the redirects are retrofitted quickly, much of the visibility returns. Pages that have already fallen completely out of the index aren't guaranteed to come back in full. The earlier the cleanup starts, the more can be saved.
Closing thought
A relaunch is a promise to the next few years - and a risk to everything you’ve built so far. Treat the invisible signals with the same seriousness as the visible design, and the move becomes a growth step rather than a setback. Treat them carelessly, and you pay the price where nobody sees it coming: in the enquiries that don’t arrive.
Sources:
- Google Search Central - Site moves with URL changes: permanent redirects, move small/medium sites in one go, submit sitemap, keep redirects as long as possible (typically at least a year), temporary fluctuation is normal
- Google Search Central - Redirects and Google Search: permanent redirects as a canonicalization signal; 302 unsuitable for permanent moves
- Google Search Console - Change of Address Tool: correctly registering an address change for a domain or subdomain move
- Rucker Elektro field data: Google Search Console, 27 June to 24 July 2026 against 4 to 31 August 2026 (as of 31 Aug 2026)