A website relaunch is always an intervention in an existing search system. URLs may change, content gets merged, technology is replaced, internal links move, tracking is rebuilt and search engines need to understand the new structure.
That does not mean a relaunch has to damage organic visibility. It means that launching without an inventory, redirect plan, canonical checks, sitemap, analytics and monitoring is a risk.
Our own recent website relaunch was a useful practical lens for this: SEO was not a final pass after the design and code were done. Technical clarity had to be part of the work before, during and after launch. The checklist below is intentionally operational. It helps teams preserve existing signals and make the new website crawlable, indexable and measurable.
1. Build a content and URL inventory
Before the design, navigation and CMS migration are finalized, you need a proper inventory. Every relevant existing URL should be known before deciding what stays, what moves and what gets removed.
A relaunch inventory should include at least:
- current URLs from crawls, sitemaps, analytics and Search Console
- page titles, meta descriptions and H1 structure
- organic landing pages with traffic and conversions
- pages with backlinks or local search visibility
- status codes, canonicals and redirects
- content that will be merged, updated or removed
Do not only record the pages visible in the main navigation. Many SEO-relevant URLs sit deeper: blog posts, old landing pages, case studies, PDF files, campaign URLs or localized variants.
2. Map redirects at URL level
Redirects are the most critical part of many relaunches. If old URLs return 404 after launch or all point to the homepage, users and search engines lose context.
Every old URL needs a clear decision:
- One-to-one redirect: The page has a direct new equivalent.
- Topical redirect: The old page is covered by a new, closely related page.
- 410 or 404: The content is intentionally gone and has no useful replacement.
- No change: The URL remains live and is served as before.
For permanent URL changes, server-side 301 or 308 redirects are usually the right choice. Google describes permanent redirects as a strong signal that the target URL should become canonical. Redirects should also point directly to the final destination, not through chains such as old -> intermediate -> new.
A redirect plan is not just a spreadsheet for documentation. It needs to be tested before launch: old top URLs, URLs with backlinks, old sitemap URLs and common variants with or without trailing slash, with or without www, HTTP and HTTPS.
3. Define the canonical domain and URL variants
A relaunch is a good moment to clean up domain variants consistently. A website should answer these questions unambiguously:
- Is
https://example.comorhttps://www.example.comthe preferred host? - Do HTTP variants redirect to HTTPS?
- Are duplicate URLs created by trailing slashes, capitalization or parameters?
- Do canonical tags point to the new final URL?
- Do canonicals, internal links and the sitemap agree?
Canonical tags are not a replacement for redirects when old URLs are permanently replaced. They are important for signaling duplicates and preferred variants. On multilingual websites, hreflang, canonicals and language paths should also be checked together.
4. Update the sitemap and robots.txt
After the relaunch, the XML sitemap should contain only indexable, canonical, successful URLs. Redirected URLs, 404 pages, noindex pages and staging paths do not belong there.
Check before launch:
- Is the new sitemap reachable?
- Does it contain the final HTTPS URLs?
- Are important new pages included?
- Have deleted and redirected URLs been removed?
- Does
robots.txtpoint to the correct sitemap? - Does
robots.txtavoid blocking important CSS, JS or image resources?
After launch, submit the new sitemap in Google Search Console. With larger URL changes, it can be normal for Google to report old sitemap URLs as redirected for a while. What matters is that the new structure is consistent and crawlable.
5. Check metadata, structured data and internal links
Relaunches often change templates. That can make SEO elements disappear, duplicate them or connect them to the wrong content.
Before launch, crawl and manually spot-check at least:
- unique title tags
- useful meta descriptions
- one clear H1 per page
- correct Open Graph and social metadata
- structured data without template errors
- internal links pointing to final URLs instead of old redirect targets
- image alt text for relevant media
- indexing directives such as
index,noindex,followandnofollow
Internal links are especially important. A relaunched website should not internally link to old URLs and rely on redirects to clean things up. Redirects are for external legacy traffic. The new site itself should use its final structure directly.
6. Carry over analytics and conversion tracking
SEO loss is often recognized late because tracking was broken during the relaunch. Analytics should not be treated as something to check sometime after launch.
Before go-live, clarify:
- Which analytics properties remain in use?
- Which events, conversions and consent settings are carried over?
- Are forms, clicks, downloads and bookings still measured?
- Are internal IPs, staging domains or test traffic filtered?
- Do UTM parameters and campaign attribution still work?
- Are cookie and privacy requirements respected?
If tracking structures change, document the change. Otherwise, it becomes hard to tell later whether a reporting drop came from SEO, technical behavior, consent changes or measurement logic.
7. Prepare Google Search Console
Search Console is not just a reporting tool for after the relaunch. It is part of the preparation.
Before launch:
- verify the property for the canonical domain
- make sure responsible people have access
- export existing performance data
- review indexing and page reports
- document old top pages and search queries
- check sitemap status
After launch:
- submit the new sitemap
- test important URLs with the URL Inspection tool
- watch indexing issues, 404 errors and redirect errors
- for a true domain migration, review the Change of Address tool
- compare performance data against the previous period
Google notes for site moves that processing can take a few weeks, and larger sites can take longer. A relaunch is not finished at deployment. It is finished when crawling, indexing, rankings and conversions are stable.
8. Protect staging from indexing and still test realistically
Staging environments are a common source of relaunch problems. They must not be indexed, but they still need to be realistic enough to test SEO signals before launch.
Useful protections include:
- password protection or IP restriction
noindexonly with a clear removal step before go-live- no public links to staging URLs
- no staging URLs in sitemaps
- no production canonicals pointing to staging
Shortly before launch, use a concrete checklist: Is noindex removed? Are canonicals set to production? Is the sitemap live? Are analytics IDs correct? Do redirects work on the real domain?
9. Monitor the first weeks after launch
The first days and weeks after a relaunch decide whether issues are corrected quickly or become search problems.
Immediately after go-live:
- test old top URLs for correct redirects
- check new pages for 200 status codes
- submit the sitemap
- review robots.txt and canonicals
- inspect core templates on mobile and desktop
- test analytics real-time data and conversions
Over the following weeks:
- check 404 and 5xx errors daily at first
- fix redirect chains and wrong targets
- watch Search Console indexing reports
- evaluate ranking and click data as trends, not only day-by-day noise
- recrawl important pages
- update internal links if old targets appear
Short-term volatility can happen when URLs change. The critical problems are systematic patterns: many old URLs without a target, new pages with noindex, wrong canonicals, blocked resources, missing templates or broken tracking.
Compact relaunch checklist
- Create a complete URL and content inventory
- Mark top pages from analytics and Search Console
- Build redirect mapping for every relevant old URL
- Test 301/308 redirects directly and without chains
- Define the canonical domain and redirect variants
- Keep canonicals,
hreflang, internal links and sitemap consistent - Check metadata, structured data and Open Graph
- Protect staging from indexing
- Remove
noindexand test configuration before launch - Test analytics, consent and conversion tracking
- Submit the new sitemap in Search Console
- Inspect important URLs
- Monitor 404, 5xx, redirect errors and indexing after launch
- Compare rankings, clicks and conversions over several weeks




