Website Relaunch SEO — Rebuild Without Losing Rankings

Pre-launch SEO checklist

Complete these tasks before switching DNS to the new site.

1. Crawl the existing site

Run a full crawl of the current live site using a crawler. Export all URLs that return 200 with their title, meta description, H1, canonical, and inbound link count. This is your "SEO inventory" — every page with rankings, backlinks, or traffic that must be accounted for in the new site.

Pay particular attention to pages with inbound links from other domains. These carry accumulated authority that will be lost if the URL changes without a redirect. Your crawl should flag these pages so they're prioritised in the URL mapping step.

2. Map old URLs to new URLs

For every URL in your SEO inventory, map it to its corresponding new URL. Three categories:

• Same URL — no redirect needed; the page survives at the same path (the best outcome)
• New URL — content exists on the new site but at a different path; needs a 301 redirect from old to new
• No equivalent — page is being deprecated; redirect to the closest parent page or the homepage as a last resort

Build this as a spreadsheet with two columns: old URL, new URL. Every row in your inventory needs an entry. Blank rows mean missing redirects.

3. Set up and test all 301 redirects

Implement every redirect from the URL map before launch. Test every redirect by visiting the old URL and confirming it reaches the correct new URL with a single hop. Test the redirect logic for URL patterns — a rule covering all blog post URLs like /posts/* → /blog/* needs to be verified across multiple actual URLs, not just one.

One redirect per URL pair. No chains. If the old site had its own redirects (A → B), and B is now being redirected to C, implement A → C directly — do not let A → B → C exist in the new site.

4. Audit the new site for indexability issues

Before launch, run a crawler against the staging environment and confirm:

• There is NO noindex meta tag or X-Robots-Tag on any page that should be indexed
• The robots.txt does not disallow Googlebot on any URLs that should be crawled
• Canonical tags point to the correct new URLs — not old URLs, not the staging domain
• The XML sitemap is updated with new URLs and does not include old deprecated paths

5. Check on-page SEO elements are preserved

Verify that title tags, meta descriptions, and H1s are present on all key pages and match (or intentionally improve on) the old site's values. Confirm heading hierarchy is intact — H1 to H2 to H3 with no skips. Check that structured data (JSON-LD) is present on pages that had it, particularly product pages, article pages, and the homepage.

URL migration — the most critical task

If the relaunch changes your URL structure, URL mapping is the highest-priority technical task. Every previously-indexed URL that now returns a 404 is a direct ranking loss. The rules:

Keep URLs identical where possible. If your new CMS can use the same URL structure as the old one, do it. Same URL means no redirect needed and no ranking signal loss. For blog posts, this often means configuring the new platform's permalink structure to match the old one exactly — worth the extra setup time.

One redirect per URL. Every old URL should redirect directly to its new destination in a single hop (301). Never create redirect chains (A → B → C). If redirects were previously set up for the old site, collapse them — old URL A should redirect directly to new URL C, not through B. Redirect chains slow crawling and dilute link equity.

Redirect to the most relevant page. Don't redirect all deprecated URLs to the homepage. A blog post that no longer has an equivalent should redirect to the closest category page. A product page that was discontinued redirects to the product category, not the home page. Homepage-mass-redirects are a known ranking signal dilution pattern that Google has commented on explicitly.

Preserve URL depth where possible. A page that was one click from the homepage and ranked well for competitive terms relies partly on its position in the site architecture. A relaunch that pushes the same content four levels deep will lose some of that positional authority even with a perfect 301 redirect.

Post-launch monitoring protocol

The first 4 weeks after launch are critical. A ranking drop caught in week 1 can often be reversed in 2–3 days with the right fix. The same drop caught in week 4 may take months to recover. Monitor daily:

GSC Coverage report

Open Google Search Console and check the Coverage report every morning for the first two weeks:

• Watch for spikes in "Not found (404)" — each new 404 is likely a missed redirect from your URL map
• Watch for drops in "Valid" pages — indicates that previously-indexed pages are no longer being found or indexed
• Check for "Redirect error" — indicates redirect chains, redirect loops, or redirects to URLs that themselves redirect
• Watch for "Crawled - currently not indexed" increases — may indicate thin content or canonical issues on the new site

GSC Performance report

Total impressions should remain within 10% of the pre-launch baseline for the first two weeks. Pull a date comparison: new site launch date vs the same period the prior month. A drop greater than 20% in the first week indicates a systemic issue — noindex directive, DNS propagation problem, or robots.txt blocking crawl.

Drill into impressions by page to identify which specific URLs have dropped. Cross-reference those URLs with your redirect map — are the old URLs correctly redirecting, or are they 404ing?

Crawl the new site

Run a crawler on the new site within 24 hours of launch. Check for broken internal links, duplicate canonicals, missing titles and descriptions, and images without alt text. Verify all redirects are resolving correctly — a redirect that works in staging may behave differently on the production server depending on how the web server is configured.

Submit updated sitemap

Submit the new sitemap.xml in GSC under Sitemaps immediately after launch. Request indexing for key pages via the URL Inspection tool — enter the new URL, check the live URL result, and click "Request Indexing" if it shows the page hasn't been crawled yet. This is not necessary for every page but is worth doing for your highest-value URLs (homepage, main category pages, top-performing blog posts).

Common relaunch mistakes

Noindex left on the new site. Developer sets <meta name="robots" content="noindex"> on staging, forgets to remove before launch. Site disappears from Google within 3–7 days as Googlebot processes the directive across all crawled pages. Fix immediately by removing noindex and requesting re-indexing via GSC URL Inspection for key pages. Recovery typically takes 1–2 weeks once the directive is removed.

Missing redirects discovered post-launch. Old high-ranking URLs returning 404. Implement 301 redirects immediately — the longer they're live as 404s, the more ranking signals are lost. The window for full recovery is roughly 2 weeks; after that, you're rebuilding rather than recovering.

Staging domain URLs in canonical tags. If the new site was developed on staging.example.com, canonical tags must point to www.example.com — not the staging subdomain. Google will not index pages whose canonical points to a different domain it doesn't recognise as the same site. Check every page type: homepage, blog posts, category pages, product pages. A find-and-replace across all canonical tags before deployment is safer than relying on template logic.

Changed title tags across the site. Title changes can cause significant ranking shifts, especially for head terms where even a word change can move you off the first page. If rankings drop post-relaunch, compare title tags between the old site crawl export and a new crawl — revert any unintentional changes. Title changes are sometimes done "for UX" or as part of a brand refresh without realising the SEO impact.

Launching with a broken XML sitemap. A sitemap that includes old URLs, points to the wrong domain, or returns a 404 itself tells Googlebot nothing useful about the new site. Validate the sitemap before and immediately after launch. Check that every URL in the sitemap returns a 200, has a self-referencing canonical, and is not marked noindex.

Not testing redirect chains. A URL that was previously redirecting A → B gets changed so B now redirects to C. Without collapsing these, you end up with A → B → C — a redirect chain. Googlebot and ranking signals follow the chain, but each hop adds latency and link equity loss. Use a redirect tracer to verify every old URL hits its destination in exactly one hop.

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.