Website relaunch without SEO loss: The checklist.
A relaunch can cost your rankings, but it does not have to. The complete SEO-safe process: from inventory and redirect mapping through 301 redirects and staging to monitoring and checklist. Plus: why the relaunch is even an opportunity.
It is the nightmare after every relaunch: the new site is live, looks great - and three weeks later organic traffic has collapsed. Rankings gone, inquiries gone, and nobody knows why.
This happens more often than you would think, and almost always for the same reason: SEO is treated as an afterthought during the relaunch. Yet the loss can be avoided entirely if you get a few things right beforehand.
This checklist walks you through the most important steps - before, during, and after the relaunch. It is written so you can hand it straight to your team or agency.
Key takeaways
- A relaunch only costs rankings when SEO comes on board too late. If you plan URLs, redirects, and content cleanly, a relaunch can even turn into a visibility gain.
- The costliest mistake: changed URLs without a 301 redirect. Google can no longer find your ranking pages and traffic collapses. 301 (permanent) passes ranking signals, 302 and 307 (temporary) do not.
- Every old URL needs a 301 redirect to its new equivalent. A platform change (Wix, WordPress or Webflow to Next.js/Astro) adds 8 checks on top, above all slugs, image URLs and rendering.
- A redirect mapping (old URL to new URL) is the core. Its basis: a full crawl of the old site plus your top-traffic and top-backlink pages from GSC and an SEO tool.
- Plan for patience. After a larger relaunch, Google often needs several weeks up to around three months to re-crawl, re-index, and stabilize rankings. Do not panic, monitor instead.
Why does a relaunch often cost rankings?
A website relaunch is more than a new design. Usually content, navigation, URL structure, and the underlying technology change at the same time. The risk lies precisely in this simultaneity: search engines have to reassess the site, re-crawl every URL, re-index and re-rank it. If this move is poorly prepared, you lose visibility you built over years.
The classic causes are almost always the same. URLs change without anyone setting up redirects, so Google can no longer find the old, ranking pages. Well-ranking pages get deleted during content cleanup. Technical mistakes like an accidental noindex or a wrongly set robots.txt lock the new site out of the index. The bitter part: none of these mistakes are necessary. They happen because SEO is not thought of from the start, only once traffic has already collapsed.
The good news is the actual core message of this article: a relaunch does not have to cost rankings. Planned cleanly, you transfer your authority fully to the new site while fixing legacy issues that held you back. The dreaded risk then becomes one of the best opportunities to grow your visibility.
When is a relaunch actually worth it?
Before you take this risk, an honest question pays off: do you really need a full relaunch, or does a renovation suffice? A relaunch is like tearing down and rebuilding a house. In many cases, incrementally optimizing the existing site is the smarter, cheaper, and for SEO far safer path. The most successful websites in the world effectively never do a big relaunch, they are continuously developed.
A real relaunch makes sense when deep structural reasons exist: an outdated CMS with security holes or no updates, missing mobile optimization, structures grown unmanageable over years, a rebranding, or a strategic repositioning. It is overkill when only small adjustments are due, the budget is tight, or the goal stays unclear. A relaunch just because a competitor did one often causes more harm than good.
The four relaunch types and their risk
Not every relaunch carries the same SEO risk. Depending on what changes, the danger to your rankings is smaller or larger. This breakdown helps you gauge how much caution your project needs:
Relaunch types and their ranking risk
| Type | What changes | Risk |
|---|---|---|
| Design relaunch | New design or theme, URLs stay | Low to medium |
| CMS relaunch | System change, e.g. WordPress to Webflow | Medium |
| URL relaunch | Rebuild of the URL structure | High |
| Domain change | New domain for the whole site | Very high |
How does an SEO-safe relaunch work?
A relaunch is a project with clear phases. Whoever runs through them in the right order and thinks about SEO in every phase avoids the typical drops. The following five phases are the scaffold. The most important principle first, and all experts agree here: take your time. Almost every catastrophic relaunch was triggered by time pressure and impatience, not by missing knowledge.
Phase 1: inventory and snapshot
Before anything changes, secure the status quo. Crawl the entire old site (with a tool like Screaming Frog) and save the URL list. Create a snapshot of your current keyword rankings, your most important backlinks with their target pages, and your top-traffic pages from Google Search Console and Analytics. This data is later your only reliable reference to spot drops and prioritize which pages to redirect.
Phase 2: planning, content audit, and structure
Now you decide which content stays, which gets merged, and which gets removed. Pages with traffic, rankings, or backlinks you keep or migrate cleanly. Legacy pages with no value at all you can remove. In parallel you plan the new URL structure. Important: only change URLs when there is a real reason. Every unnecessary URL change is an avoidable risk.
Phase 3: staging and redirect mapping
The new site is built in a password-protected staging environment that blocks Googlebot via robots.txt or noindex, so no test version gets indexed. Here you build the core: the redirect mapping, a list of every changing old URL and its new target. Its basis is your crawl from phase 1. Every redirected page should point topically to the most fitting new page, not blanket to the homepage.
Phase 4: launch with correct 301 redirects
At go-live, all changed URLs are pointed to their new target via a 301 redirect (permanent), including images and PDFs. Never use 302 or 307 (temporary), they do not reliably pass ranking signals. Submit a fresh XML sitemap in Google Search Console. For a domain change, additionally use the change of address tool there. Check that tracking code, canonicals, and hreflang are correctly in place.
Phase 5: post-launch monitoring
Right after go-live, crawl the new site again and check all status codes: do the redirects work, are there 404 errors, redirect chains, or 500s? In Google Search Console you watch indexing, coverage, and crawl errors. New 404 pages get a fitting 301 redirect immediately. Then you monitor rankings, traffic, and visibility over weeks. Patience: it often takes several weeks to months for everything to settle.
Why are 301 redirects so decisive?
If a single technical point decides success or failure of your relaunch, it is the redirects. A URL is like your address. Change it without a forwarding order and Google and your visitors land in the void. The forwarding order on the web is the 301 redirect.
The 301 status code signals a permanent change. Google transfers the ranking signals of the old URL to the new one and consolidates them there. According to Google’s own documentation, a correctly implemented permanent redirect (301 or 308) to a topically fitting target page loses no ranking signals. That is exactly why 302 and 307 are off-limits here: they signal a temporary change, and Google then passes the signals only hesitantly or not at all.
A few rules from practice. Redirect as relevantly as possible, to the closest new page in content, not blanket to the homepage. Avoid redirect chains where A points to B and B only then to C. For permanently deleted pages without a replacement, a clean 410 (Gone) is often more honest than a forced redirect. And for especially valuable backlinks, it pays to ask the linking operator directly to update to the new URL instead of relying only on the redirect.
The technical relaunch check: the checklist
This checklist bundles the points to check before launch in the staging environment and right after in the live environment. Every relaunch is individual, so extend it with your project-specific points. But no relaunch goes safely live without this baseline. If you are touching everything anyway, accessibility under the BFSG belongs on the list too.
Relaunch checklist: what to check before and after launch
| Area | Check |
|---|---|
| Redirects | All changed URLs via 301 to a fitting target? No 302/307, no chains? |
| Indexing | No accidental noindex, no ranking-relevant pages blocked in robots.txt? |
| Status codes | Crawl shows no unexpected 404 or 500? Internal links point directly to the target? |
| Sitemap | Fresh XML sitemap created and submitted in Google Search Console? |
| Canonicals & hreflang | Canonical tags correct, hreflang complete for multilingual sites? |
| Meta data & H1 | Every page with title, description, and exactly one H1? |
| Performance | Core Web Vitals and load time at least as good as before, ideally better? |
| Tracking | Analytics and tracking code active on the new site? |
| Images & PDFs | Important images and PDFs kept 1:1 or redirected? |
Switching platforms without losing rankings: from Wix, WordPress or Webflow to Next.js or Astro
A relaunch that switches platforms only loses rankings when Google can no longer find the old pages. Moving from Wix, WordPress or Webflow to Next.js or Astro changes URL patterns, image addresses, rendering and the CMS at the same time, and each of those layers needs its own mapping from old to new. If you only redirect the page URLs, you have done half the job.
Why is the risk higher than a redesign on the same platform? Four reasons.
URL structure and CMS slugs. Every platform builds its addresses differently. Wix puts blog posts under `/post/`, Webflow under the collection name, WordPress with a date or category in the path depending on settings. Add trailing slashes, upper and lower case and special characters, which every CMS resolves its own way. In the new system, slugs come from your content model in Sanity. Without a mapping, not a single address matches.
Rendering. Rendering means: where is the HTML created that Google reads? Site builders ship platform HTML with a lot of their own script, Next.js renders on the server, Astro builds static pages. That is an advantage, but only if every piece of text is in the delivered HTML and not loaded later in the browser.
Image URLs. Your images currently sit on the platform's CDN (Wix, Webflow or under `/wp-content/uploads/`). Cancel the platform and those addresses are dead. Image rankings and external links to images go with them.
Interactions. Tabs, accordions, sliders and Webflow interactions contain text that Google indexes today. If the new system builds them with JavaScript that only creates the content on click, that text drops out of the index.
The standard checklist above still applies. These eight points come on top when you switch systems:
Eight points that come on top when the system changes
| Check | Why | What we do |
|---|---|---|
| 1. Slug mapping from the CMS export | Old slugs do not live in the sitemap alone but in the CMS with category, date or collection path | We export every entry (Webflow CSV, WordPress WXR, Wix export), generate the redirect map from the export instead of by hand and fix the trailing slash rule in code |
| 2. Image and file URLs | Assets sit on the platform CDN and disappear after cancellation | Download all assets, re-upload to Sanity, carry over alt texts, 301 any images with impressions in Search Console |
| 3. Rendering check | Google judges the HTML the server delivers, not what the browser assembles afterwards | Check every template in the raw source (server response without JavaScript) and compare with the "crawled HTML" view in Search Console's URL inspection |
| 4. Text inside interactions | Accordions, tabs and sliders often lose their text from the index when rebuilt | Ship the content in the HTML, use the interaction only to control visibility, add FAQ accordions as FAQPage schema too |
| 5. Meta data, canonicals, hreflang | The platform generated title, description, canonical and Open Graph automatically; in a code system every field has to exist in the content model | Field by field mapping from the export into Sanity, carry over existing titles 1:1, reciprocal hreflang including x-default generated in code |
| 6. Sitemap, robots.txt, 404 status | Platforms deliver sitemap and redirects through their UI; in code you build both yourself | Generate the sitemap from Sanity, store redirects in the hosting configuration, serve 404 pages with a real 404 status (no soft 404 with status 200) |
| 7. Replacing plugin features | WordPress SEO plugins produced schema and breadcrumbs, forms and search depended on the platform | Rebuild schema in code and verify with the Rich Results Test, move forms to the new endpoint, reconnect search |
| 8. DNS and hosting cutover | The domain changes nameservers or DNS records; a wrong TTL or missing SSL costs hours of error pages | Lower the DNS TTL before launch, redirect www/non-www and HTTP to HTTPS consistently, cancel the old platform only once every redirect is verified |
The order matters. Points 1, 2 and 5 happen before the first build, because the content model in Sanity depends on them. Points 3, 4, 6 and 7 run during development, template by template. Point 8 belongs on launch day, with the redirect map as the test list: every old URL gets opened once after the DNS switch before anyone cancels the old platform.
Our own website shows what this looks like in practice. in-sync.io ran on Wix until 2026 and has run on Next.js, Sanity and Vercel since June 2026. We had little to lose, the old Wix site ranked for practically nothing. We still went through the full list: pre-launch crawl, redirect map for every old Wix URL, every image re-uploaded to Sanity, DE and EN with hreflang, full server rendering, sitemap and llms.txt generated from code, submission to Search Console and Bing plus IndexNow. Today 49 knowledge articles, 10 service pages and 17 city pages come out of one content model. Rankings have been building since June. On Wix we would not have built the same content model with the same control over rendering, schema and sitemap.
If you are facing the same decision: we describe the path from Webflow to Next.js step by step in migrating from Webflow to Next.js, and the decision before it in Webflow vs. Next.js. What a headless CMS is and why your content belongs in a structured content database when you switch is covered in its own article. For the overview of all three tiers, site builder, Webflow and code system, see Builder, Webflow or Next.js. And if you would rather not own the move yourself: as a website relaunch agency we handle crawl, redirect map, migration and monitoring as one package.
Which tools do you need for a relaunch?
You do not need an expensive setup, but a few tools are indispensable. The crawler is the most important: Screaming Frog is the standard for reading out all URLs, redirects, status codes, canonicals, and meta data of the old and the new site. Google Search Console is free and mandatory to watch indexing, coverage, crawl errors, and traffic changes and to submit the new sitemap. For a domain change, the address change also runs through GSC.
For the rankings and backlink snapshots before the relaunch, you use an SEO tool like Ahrefs, Sistrix, or Semrush. With it you see which pages actually carry traffic and backlinks and therefore get top priority in the redirect mapping. This combination of crawler, Search Console, and a visibility tool covers the whole process from inventory to monitoring.
How long does recovery after the relaunch take?
Even with a perfectly executed relaunch, short-term fluctuations are normal. Google has to fully re-crawl, re-index, and re-assess the new site. So do not panic if rankings wobble in the first days. That is part of the re-evaluation.
As orientation: for smaller relaunches with the same URL structure, visibility often settles within two to four weeks. For larger rebuilds with changed URLs or a domain change, the full re-assessment by Google can take several weeks up to around three months. The more that changed, the longer the algorithm needs. What matters is the direction: if your relaunch truly improved the user experience, load time, and relevance, the re-evaluation can in the end even lead to better rankings than before. That is exactly the goal.
Relaunch as an opportunity: SEO, performance, and AI visibility
The best relaunch does not just defend the status quo, it lifts it. Because everything is on the table anyway, the relaunch is the ideal moment to fix legacy issues: a cleaner site structure, better internal linking, faster load times and strong Core Web Vitals, consistent mobile optimization. All things that were often hard to retrofit on the old site.
In 2026, one point is added that most relaunch guides still skip: visibility in AI answers. Whoever switches during the relaunch to a modern CMS or framework that only assembles content via JavaScript in the browser risks that AI crawlers like GPTBot or ClaudeBot see an empty page, because many do not render JavaScript. Server-side rendering (SSR) is therefore no longer a nice-to-have, it belongs in the technical requirements for the new site. A relaunch that thinks about this makes your content readable for Google and for the generative engines at once. More on this in our article on Generative Engine Optimization.
That is exactly how we approach website relaunches: we first secure your existing visibility through clean redirect mapping and monitoring, and at the same time build the new site technically so that it is faster, more crawlable, and more AI-readable than the old one. The relaunch then becomes not a risk but a lever. What can come out of it in the end is shown by the Silencio relaunch, which we describe in our press piece on the Silencio funding round.
Frequently asked questions
Not necessarily. Rankings are only lost when SEO is planned too late, for example changed URLs without a 301 redirect, deleted ranking pages, or an accidental noindex. With clean redirect mapping, staging, and monitoring, you transfer your visibility fully to the new site and can even improve it.
The redirect mapping with 301 redirects. Every changing or dropped URL must point via a permanent 301 redirect to the most topically fitting new URL. That way Google finds your content again and transfers the ranking signals. Its basis is a full crawl of the old site before launch.
Always 301. A 301 redirect is permanent and passes the ranking signals to the new URL. A 302 or 307 is temporary, Google then assumes the change will not last and passes the signals only hesitantly or not at all. In a relaunch, 302 and 307 have no place.
For smaller relaunches with the same URL structure, often two to four weeks. For larger rebuilds with changed URLs or a domain change, the full re-assessment by Google can take several weeks up to around three months. The more that changed, the longer. Panic in the first days is normal but unfounded.
A staging environment is a password-protected test version of your new site that blocks Googlebot. There you build and test in peace without an unfinished version getting indexed or visitors landing on it. Never tinker live on the active site, that is one of the most common and costliest relaunch mistakes.
Only if there is a real reason. Every URL change raises the risk and requires redirects. If your existing URLs are clean and readable, leave them as they are. If you must change them, plan the 301 redirects especially carefully and redirect in a topically fitting way.
No, provided the mapping is right on all four layers: page URLs, image URLs, rendering and text inside interactions. Webflow slugs go into the redirect map via CSV or API export, images move from the Webflow CDN to Sanity, and every template is checked in the server HTML. One client with a five-language website (Yarowa) ported its Webflow export 1:1 to Astro with the design left identical.
For a marketing website with 10-30 pages, typically 3-6 weeks. Four things drive the timeline: page count, the volume of CMS content (blog, cases, languages), the number of interactions to rebuild, and whether the design comes from Figma or from the old export. Redirect map and pre-launch crawl are produced before the first build and maintained alongside development after that. The DNS switch itself is a matter of hours if the TTL (how long caches keep a DNS record) was lowered beforehand.
Technical SEO
The technical foundation every relaunch builds on.
Improve your Google ranking
What really moves rankings, step by step.
On-page SEO
Setting titles, structure, and internal links right.
Core Web Vitals
Why performance co-decides in a relaunch.
Migrating WordPress to Next.js
Six phases, costs and how rankings hold up along the way.
Getting 301 redirects right
Status codes, redirect map and the mistakes that cost rankings.
CMS migration: process and cost
The overview of any system change, whatever you run today.
