Website Relaunch Without Losing SEO: A Before-and-After Launch Checklist

A relaunch often looks harmless in a project plan: new design, new technology, better copy, switch the domain and finish.

For search engines, the same relaunch can look like a complete restructuring of the site. URLs disappear, internal links change, canonicals point somewhere else and a page that brought visitors for years suddenly returns 404.

The most important SEO rule is therefore simple: Do not wait until after launch to decide what happens to old URLs.

1. Build a URL inventory before replacing the old site

Export every relevant URL before the old website disappears.

Useful sources include:

• XML sitemap
• Google Search Console
• analytics
• crawling tools
• internal links
• important backlinks
• manually maintained landing pages

Then decide for each URL:

• does it remain?
• does it receive new content?
• does it redirect to a relevant new page?
• should it intentionally return 404 or 410?

Not every old URL needs a redirect. Every important old URL does need a conscious decision.

2. Redirect old URLs to the closest relevant destination

A common mistake is redirecting every removed page to the homepage.

It is easy to implement and often wrong.

If an old “SEO consulting Vienna” page now belongs under `/en/seo-vienna/`, redirect there rather than sending every visitor to `/en/`.

A redirect should preserve the old intent as closely as possible.

3. Avoid redirect chains

Ideal:

`old-url` → `new-url`

Unnecessary:

`old-url` → `temporary-url` → `another-url` → `new-url`

Chains increase complexity and make later maintenance harder.

A relaunch is a good opportunity to clean old redirect history.

4. Canonicals and real URLs must agree

A page should not be served under one URL while declaring a different canonical URL without a deliberate reason.

Common inconsistencies include:

• http/https
• www/non-www
• trailing slash
• upper/lowercase
• parameters
• old and new paths

Choose one URL format and use it consistently in:

• canonical tags
• sitemap
• internal links
• hreflang
• structured data
• OpenGraph URLs

5. Generate the sitemap after the final URL decisions

A sitemap is not an archive of every page that has ever existed.

It should contain current, indexable canonical URLs.

It normally should not contain:

• redirect URLs
• 404 pages
• noindex pages
• test pages
• duplicate parameter URLs

6. Link directly to final URLs internally

If every navigation link triggers a 301 before reaching the real page, the website is creating unnecessary inconsistency.

After the relaunch, internal links should point directly to the final URL.

On static or prerendered sites, this can even be validated automatically by scanning the final HTML output.

7. Return a real 404, not a pretty error page with HTTP 200

A visually perfect 404 page is technically wrong if the server returns `200 OK`.

This happens frequently with single-page applications. Every unknown URL returns `index.html`, then the client router displays a 404 component while the HTTP response remains successful.

For fully prerendered marketing sites, a cleaner model is:

• existing route → static `index.html` → 200
• missing route → server 404 → custom 404 template

Users and search engines then receive the same message.

8. Do not test only the homepage after launch

Immediately after launch, check at least:

• primary service pages
• top Search Console landing pages
• old URLs with backlinks
• contact page
• blog posts with organic traffic
• robots.txt
• sitemap.xml
• canonicals
• hreflang
• structured data
• HTTP status codes

9. Monitor Search Console

Some fluctuation after a relaunch is normal. The key question is whether Google processes the new structure cleanly.

Watch:

• indexed pages
• crawl issues
• redirect reports
• discovered but not indexed
• crawled but not indexed
• impressions
• average position
• clicks

Not every movement on day one is a problem. It becomes more concerning when important old pages disappear and their new equivalents fail to gain visibility.

10. Document the redirect map

Redirects are infrastructure.

Document:

• old URL
• new URL
• reason
• date
• whether the redirect should remain permanently

You will appreciate that documentation during the next migration.

Conclusion

A good relaunch improves design and technology without unnecessarily throwing away search visibility built over time.

Most of the important work happens before launch: URL inventory, redirect mapping, canonical strategy and proper testing.

If you are planning a relaunch, I treat this technical SEO work as part of web design planning, not as an emergency repair package two weeks after launch.