SEO & migration
If you are searching for website relaunch SEO or "new website SEO", you are usually close to a redesign, CMS change or platform shift. That is the right moment to protect what you already earned in search — and the wrong moment to treat redirects as an afterthought.
We have seen beautifully designed relaunches lose months of visibility because URL structure changed without mapping, because canonicals pointed wrong for a week, or because staging got crawled. This guide is the checklist we use when the goal is a new site — without throwing rankings away.
TL;DR
Key takeaways
- SEO loss on relaunch almost always comes from broken URLs, thin content parity or crawl mistakes — not "Google dislikes the new design".
- Build a 1:1 redirect map before cutover, and keep important paths when you can.
- Every ranking page needs a clear successor with the same intent — not a generic homepage redirect.
- Noindex staging, lock preprod, and verify canonicals before the DNS cut.
- Plan a monitoring window after launch: Search Console, sitemap, 404 logs and ranking spot-checks.
- Stack changes (WordPress to Next.js and similar) are possible without loss — if migration is treated as an SEO project.
Why relaunches lose rankings
Google follows links and redirects. It does not follow your intention. When a URL disappears without a 301 to an equivalent page, that page loses its accumulated signals. When 50 pages redirect to the homepage, you tell Google the content is gone — not moved.
Design teams optimise for visual sections. SEO needs URL stability, internal linking and content parity. Those goals are not in conflict, but they compete for time in the project. If SEO only enters in UAT, the damage is often already built into the information architecture.
Another classic failure mode is "we will clean up URLs at the same time". Changing CMS, design and URL structure on the same day is three migrations. You can do it — but then mapping, QA and rollback must be equally disciplined.
The good news: most loss is avoidable. It takes boring work before launch, not magic SEO tricks afterwards.
URL strategy before you touch the design
Start with an export of the URLs that actually matter: Search Console (pages with impressions), analytics (organic landing pages), and a crawl of the current site. Sort by value — not by what looks neat in a sitemap.
For each important URL decide: keep the path, redirect 1:1 to a new path, or consciously consolidate into a stronger page. Consolidation is legitimate when you merge thin content. It is destructive when you merge unrelated intents.
Keep paths when you can. A new design does not require new slugs. If `/services/web-development` still describes the same service, let it live. Change URLs only when the information architecture truly changes.
Language and locale prefixes need extra discipline. If you move from `/da/insights/...` to `/da/indsigter/...`, that is a mass redirect — plan it explicitly and keep it permanent.
The cutover plan that protects SEO
A practical sequence you can follow whether you are changing a theme, a CMS or the whole stack.
- 01
Build the redirect map early
A spreadsheet or a script is fine. Columns: old URL, new URL, status code, owner, note. No cutover until the most important rows are green.
- 02
Match content parity
For each important page: is the H1 intent the same? Are the decisive sections present? Are FAQ and internal links preserved or improved? Thinner pages after relaunch are a quiet ranking killer.
- 03
Lock staging from crawl
Noindex, auth or IP allowlist. Make sure staging canonicals do not point at production with the wrong content — and vice versa.
- 04
Test redirects in preprod
Crawl the old URL set against the new environment. Count 404s, redirect chains and accidental 302s. Fix chains into direct 301s.
- 05
Cut over with sitemap and Search Console
Switch DNS/deploy, submit the updated sitemap, verify new URLs return 200, and watch coverage and 404s for the first weeks.
Technical signals that must be correct on day one
Canonicals must point at the preferred live URL — not staging, not an old path, not a parameter variant. Hreflang (if you are multilingual) must mirror the real locale pairs after relaunch.
Structured data must still be valid. If you had FAQPage or Article markup, verify the new stack emits it correctly. A redesign that "forgets" JSON-LD is invisible to humans and visible to rich results.
Performance helps, but it does not save broken URLs. A faster site with 404s on your best landing pages is still an SEO loss. Get redirects and parity right first; optimise Core Web Vitals in the same sprint, not as a substitute.
robots.txt and sitemap.xml must update in the same release. A sitemap listing old paths, or a robots file that accidentally disallows important sections, are classic cutover failures.
Internal linking is the signal many redesigns forget. If the new navigation buries pages that used to be two clicks from the homepage, crawl depth drops — even when URLs are preserved. Review the most important landing pages and ensure they still have clear entry points from hub pages and related content.
Controlled relaunch vs hopeful go-live
Controlled
SEO is a workstream with an owner and acceptance criteria.
- Redirect map done before design freeze
- Important URLs preserved or mapped 1:1
- Staging not indexable
- Crawl test of old URLs in preprod
- Post-launch monitoring in Search Console
Hopeful
SEO "we will handle after launch".
- New slugs because they look nicer
- Many 301s to the homepage
- Staging open to crawl for weeks
- Redirects written in panic on launch day
- Nobody knows which pages carried the traffic
“A relaunch without a redirect map is not a redesign. It is a planned 404 campaign with better typography.”
Especially when moving WordPress to Next.js (and similar shifts)
Stack changes often scare SEO owners more than a theme change — but the mechanics are the same. Google crawls HTTP responses, not your framework. If URLs, content and internal links are preserved, you can move from WordPress to Next.js without starting over.
What changes is ownership: redirects live in the application or edge layer, metadata is built in code, and preview environments must stay out of the index. That is an advantage when disciplined — and a risk when redirects are hardcoded in panic.
Plan content parity explicitly: blocks in a headless CMS must mirror the old pages' intent, not only their look. A case page that loses its sections and FAQ is a new page in Google's eyes — even if the slug is the same.
If you still change information architecture, split the project: first a URL-stable relaunch, then deliberate consolidations. Two clear steps beat one chaotic big bang.
Keep the URL — or change it deliberately?
Use the rows to avoid "we will fix URLs while we are at it".
Keep or 1:1-redirect when…
The page ranks or earns impressions today
Change URL structure when…
You have a documented mapping and accept temporary volatility
Keep or 1:1-redirect when…
Intent and content stay the same after relaunch
Change URL structure when…
Information architecture truly changes (new sections, new products)
Keep or 1:1-redirect when…
You can keep the path without technical pain
Change URL structure when…
Old paths are inconsistent and block a clear model going forward
Keep or 1:1-redirect when…
You are already mid design/CMS change
Change URL structure when…
You have capacity for a separate SEO migration with its own QA
SEO launch checklist
If these items are not green, you are not ready — no matter how finished the design looks.
- Top URLs from Search Console are mapped 1:1 or deliberately consolidated
- No critical pages 301 to the homepage
- Staging/preprod is noindex or shielded
- Canonicals, hreflang and sitemap point at the new live URLs
- Crawl of old URLs shows 200 or correct 301s — not chains and 404s
- Someone owns the 404 log and Search Console for the first weeks after launch
Questions we hear again and again
How long until rankings stabilise after a relaunch?
It varies with crawl frequency and how large the URL changes are. With clean 301s and content parity, we typically see most recovery over weeks — not hours. If you broke the mapping, "stabilisation" can effectively be a new lower baseline.
Are temporary 302 redirects okay during cutover?
Not as the end state. Use 301 (or 308) for permanent moves. 302s can be temporary in a technical emergency plan, but they must not linger — Google is more cautious about transferring signals via temporary redirects.
Can we change the design without touching URLs?
Yes — and it is often the safest path. A new UI on the same paths is the lowest SEO risk. Save slug cleanup for a separate, planned step.
What about backlinks to old URLs?
That is exactly why redirects must be permanent and correct. A good 301 preserves value from external links. A 404 or a homepage redirect wastes them.
Should we remove old content we do not want to republish?
Yes — but do it deliberately. 404/410 on irrelevant content is fine. If the content had traffic or backlinks, consolidate to the nearest relevant page with a 301, or keep an updated version.
If you are planning a relaunch
Let us make sure SEO survives cutover.
A short review of your URL map and cutover plan is often enough to spot the mistakes that cost rankings.