The short answer
Website relaunch SEO depends on preserving useful destinations and making each URL change explicit. Inventory the current site, map every valuable URL to the closest relevant destination, implement direct permanent redirects, align internal links and canonical signals, then validate and monitor the production site.
- Make a URL-level decision before launch for every page with users, links, rankings or business value.
- Use direct server-side permanent redirects for genuine permanent moves and avoid irrelevant homepage redirects.
- Update internal links, canonicals, hreflang and the sitemap so they point directly to final URLs.
- Expect temporary search fluctuation and monitor page groups against the migration map instead of promising stability.
On this page
The direct answer
Successful website relaunch SEO is a controlled transfer of destinations, content and search signals. The central deliverable is not a generic launch checklist. It is a reviewed map showing what happens to every old URL, why that decision is appropriate, how it will be implemented and how it will be tested on production.
Keep a URL unchanged when it still represents the same useful page. When a page moves, send it directly to the closest relevant replacement with a permanent server-side redirect. When content is genuinely gone and has no suitable replacement, return a real 404 or 410 instead of pushing the visitor to an unrelated homepage.
Google advises planning a URL mapping, using permanent server-side redirects for permanent moves, updating internal and external references, submitting the new sitemap and monitoring through Search Console. It also warns that rankings may fluctuate while the site is recrawled and reindexed. A migration can reduce avoidable loss, but nobody can guarantee unchanged rankings or traffic.
- Inventory current URLs and collect evidence before changing the site.
- Assign each old URL one reviewed outcome.
- Implement redirects directly to final destinations.
- Align internal links and search annotations with the new URLs.
- Validate on production and monitor by page group.
Build an evidence-backed URL inventory
Start before designers or developers rename sections. Crawl the public site and combine that list with XML sitemaps, analytics landing pages, Search Console performance and indexing reports, important backlinks, campaign destinations, downloadable files and known offline links. No single source is complete.
Record business evidence as well as search evidence. A low-traffic technical support page may prevent calls, support a sales conversation or receive links from a product manual. A high-traffic article may attract the wrong audience and contribute little to the business. The decision should reflect purpose, not traffic alone.
Give every URL a content owner and status. Typical outcomes are keep, improve in place, move, consolidate, retire with a relevant replacement, or remove without replacement. Freeze the reviewed inventory before launch so late content decisions do not silently bypass the redirect plan.
- Current URL, status code, canonical and indexability
- Page type, topic, language and owner
- Organic landing activity and representative queries
- Inbound links, campaign use and offline references
- Business role, conversion path and proposed outcome
| Evidence | What it reveals | Decision it informs | Limitation |
|---|---|---|---|
| Site crawl | Reachable URLs, status codes, links and annotations | Technical inventory and internal-link changes | May miss orphaned or blocked URLs |
| Search Console | Queries, pages, indexing and search clicks | Search demand and pages needing preservation | Does not describe all visitors or business value |
| Analytics | Landing journeys and measured outcomes | Commercial priority and post-launch comparison | Depends on correct consent and tracking |
| Backlink and business records | External references, campaigns and operational use | Redirect retention and outreach priority | Lists are rarely complete |
Decide the destination for every old URL
The destination should satisfy the reason someone used the old page. Match topic, intent, language and business function. A discontinued service page may map to a successor service if that replacement answers the same need. An expired event with no enduring information should normally return an error response rather than redirect to the events index merely because it exists.
Consolidation needs editorial judgment. Several thin pages can point to one new comprehensive page when that page genuinely contains their useful material. Record the relevant section or content requirement in the map, then verify it exists before enabling the redirect. Otherwise a technically valid redirect can still disappoint the visitor.
For a hypothetical Lausanne B2B firm, imagine that /en/audit-old/ and /en/risk-review/ become one new risk assessment service. Both may map to the consolidated page after their distinct questions are incorporated. A deleted staff vacancy should not map there. It should return 404 or 410 unless an appropriate careers destination exists.
- Keep the URL when the page purpose and language remain stable.
- Map a moved page to its closest equivalent, not merely its parent section.
- Consolidate only when the destination carries forward the useful content.
- Return 404 or 410 when nothing relevant replaces the page.
- Keep language variants within the correct language journey.
| Old-page situation | Recommended outcome | Required evidence | Validation |
|---|---|---|---|
| Same purpose and content | Keep the existing URL | The URL remains suitable in the new structure | Returns 200 and retains intended canonical |
| Same purpose, new URL | Permanent redirect to the equivalent page | Destination answers the same need | One hop to a 200 response |
| Several pages become one | Redirect each to the consolidated page | Relevant material is present | Content and anchors are manually reviewed |
| No replacement | Return 404 or 410 with a useful error page | Owner confirms retirement | Correct HTTP status, helpful navigation |
| Temporary campaign change | Use a temporary response only when the original will return | Documented temporary condition | Original remains the intended search URL |
Specify redirects and search signals
Google recommends permanent server-side redirects, such as 301 or 308, when a move will not be reversed. Redirect directly to the final URL. Google can follow redirect chains, but chains add latency and increase failure points. The practical acceptance condition is one hop wherever the team controls both URLs.
Do not redirect many unrelated URLs to the homepage. Google says irrelevant bulk redirects can confuse users and may be treated as soft 404 responses. A useful custom error page can offer navigation and popular resources, but a removed URL must still return the correct 404 status.
Redirects are only one signal. Update internal links so visitors and crawlers do not pass through redirects. Change canonical annotations, hreflang references, structured-data URLs, navigation, campaign links and profiles to the final URLs. List canonical new URLs in the sitemap. Google describes redirects and rel=canonical as strong canonicalization signals and sitemap inclusion as a weaker signal, so consistency matters.
- Use 301 or 308 for a genuine permanent move.
- Point directly to a live final destination.
- Remove chains, loops and irrelevant bulk rules.
- Update internal links and annotations rather than relying on redirects forever.
- Keep the redirect map under change control.
| Signal | Expected production state | Failure example |
|---|---|---|
| Redirect | Old URL reaches the closest final URL in one hop | Old URL passes through two former structures |
| Canonical | New page names its final indexable URL | Canonical still names staging or the old domain |
| Internal links | Navigation and body links use final URLs | Every click triggers a redirect |
| Sitemap | Contains canonical, indexable new URLs | Includes redirected or blocked URLs |
| Hreflang | Language alternates are reciprocal and final | Alternates point to old or redirected pages |
Prepare the new website before launch
Test the new site while it is still private, but prepare production index controls before the release window. Google specifically cautions teams that block all crawling or add noindex during development to prepare the correct production robots file and a list of pages from which noindex must be removed.
Crawl the staging site with production-like URLs or a reliable mapping. Check that every planned destination exists, key content migrated, titles and headings are intentional, canonicals do not point to staging, and multilingual alternates form complete reciprocal sets. Validate structured data against visible content and inspect templates on mobile.
Verify Search Console access for the relevant old and new properties before launch and preserve the verification method. Prepare the sitemap, redirect rules, DNS or deployment plan, monitoring and rollback criteria. If the redesign also changes domain, URL structure, CMS and content at once, document the combined risk and make responsibilities unambiguous.
- Remove accidental production noindex and crawl blocks.
- Confirm old and new Search Console ownership where applicable.
- Validate every destination named in the approved URL map.
- Test canonicals, hreflang and structured data on representative templates.
- Prepare the production crawl and critical redirect sample in advance.
Validate the production migration
Production is a new test environment. As soon as the release is live, crawl the final site and sample redirects from each rule type and page group. Confirm status codes, destination content, one-hop behavior, canonical host, indexability, internal links, sitemap reachability and real form delivery.
Prioritize tests by risk. Check the homepage, high-value service pages, leading organic landing pages, pages with important backlinks, language variants and campaign destinations first. Use URL Inspection for representative URLs to see the response and rendered content Google receives. Submit the sitemap through Search Console and review processing errors, while remembering that submission is a hint rather than an indexing guarantee.
Google recommends keeping migration redirects as long as possible, generally at least one year, so signals and old links have time to transfer. Consider retaining them indefinitely when people may continue to use old bookmarks, documents or external links. Keep the map available to prevent a future deployment from removing active rules.
- Run a complete production crawl and compare it with the approved inventory.
- Test representative old URLs from logs or a fixed migration test set.
- Inspect rendered content and selected canonicals in Search Console.
- Submit the new sitemap and review its processing status.
- Archive redirect rules, decisions and test evidence for maintenance.
Monitor decisions, not only traffic
Search visibility can fluctuate during a substantial move while Google recrawls and reindexes URLs. Google says a medium-sized site may take a few weeks or more to start showing new URLs, while larger sites can take longer. Treat this as context, not a recovery deadline.
Monitor whether the migration behaves as designed. Track old URLs still receiving requests, redirect errors, new 404s, sitemap processing, indexed page groups, canonical selection, representative queries and business outcomes. Compare equivalent page groups rather than a single site-wide total because seasonality, campaigns and demand can move independently of the relaunch.
Investigate exceptions against the map. If an old service page loses visibility, first confirm its redirect, destination relevance, content, canonical, internal links and rendered response. A dashboard cannot replace that URL-level diagnosis. Record the correction and retest it.
- Daily immediately after launch: errors, critical redirects, forms and server health.
- Regularly during reprocessing: indexing, sitemap status, canonical exceptions and key page groups.
- At an agreed review point: search demand, landing-page outcomes and unresolved old URL requests.
- After later releases: confirm redirect rules and annotations remain intact.
Turn the migration into an accountable brief
Your brief should assign ownership for the inventory, content decisions, redirect implementation, technical annotations, Search Console, production validation and monitoring. Ask who signs off the URL map and who can change it. Migration tasks divided vaguely between an agency, marketing team and IT team often disappear at the boundaries.
Make evidence part of completion. The supplier should deliver the final URL map, redirect configuration or export, crawl results, exception list and monitoring handover. Acceptance should depend on observed production responses, not a statement that an SEO plugin was installed.
A new homepage concept can help clarify the revised information hierarchy before URLs and templates are finalized. It should remain separate from the migration promise: the concept covers a homepage direction and priorities, while implementation, hosting and ongoing work require their own scope and quote.
- Named owner for each migration deliverable
- Approved URL map with rationale and change history
- Technical acceptance criteria and production evidence
- Escalation and rollback conditions for critical failures
- Monitoring period, handover format and redirect-retention responsibility
YOUR QUESTIONS, ANSWERED
Frequently asked questions
What is website relaunch SEO?
It is the planning and validation needed to preserve useful search destinations when a website changes. It covers URL inventory, content decisions, redirects, internal links, canonical signals, sitemaps, index controls and post-launch monitoring.
Should every old URL redirect to the new homepage?
No. Each moved URL should point to the closest relevant replacement. Google warns that redirecting many unrelated URLs to one irrelevant destination can confuse users and may be treated as a soft 404.
Which redirect should a permanent website migration use?
Google recommends a server-side permanent redirect such as 301 or 308 when the move will not be reversed. Direct each old URL to the final destination and avoid chains where possible.
How long should migration redirects remain active?
Google recommends keeping them as long as possible, generally at least one year. Keeping useful redirects longer can continue helping people who use old bookmarks, documents and external links.
Will a correct migration prevent all ranking changes?
No. Google says fluctuations can occur while a changed site is recrawled and reindexed. Good planning reduces avoidable errors but cannot guarantee unchanged rankings, traffic or leads.
What should an agency deliver after the migration?
Request the approved URL map, implemented redirect record, production crawl evidence, unresolved exception list, Search Console and sitemap checks, monitoring plan and a clear handover owner.
CHECK THE DETAIL
