Website Relaunch SEO Checklist for Domain Migrations

1. Why a Relaunch Becomes an SEO Risk

A website relaunch or domain migration changes URLs, page structures and often content all at once. Google has to reassess the entire new structure from scratch, and during that transition period rankings, visibility and organic traffic commonly drop. Teams that treat a relaunch purely as a design or engineering project, leaving SEO as an afterthought for after launch, risk organic traffic drops of thirty to fifty percent that can drag on for months.

The root cause is rarely one single mistake but rather the sum of small oversights: missing redirects, restructured URLs without a mapping plan, forgotten canonical tags, or a freshly submitted sitemap that no longer matches the actual site structure. A structured checklist, worked through before, during and after launch, cuts this risk significantly and, in the best case, makes ranking losses entirely avoidable.

2. A Complete URL Inventory Before the Relaunch

The first and most important step before any relaunch is a full inventory of every currently indexed and crawlable URL. That includes not just the obvious category and product pages, but also filtered listing pages, paginated series, old campaign landing pages, PDF documents, and even seemingly minor pages such as terms of service or an imprint page if they still hold rankings or backlinks. This inventory should draw on at least three independent data sources: a full crawl of the live site, the URL export from Google Search Console, and server logs covering the last six to twelve months.

These three sources are merged and enriched with metrics such as organic traffic, referring domain count and ranking positions, so the team can later prioritize which URLs need the most protection. In practice, this exercise almost always surfaces URLs that are no longer linked from the current menu but still generate traffic, and it is exactly these forgotten pages that most often fall through the cracks during a relaunch.

3. Building a Redirect Mapping Strategy

Based on the URL inventory, a mapping table is created that assigns exactly one new destination URL to each old URL. Content relevance matters here: an old product page should point to the matching new product page rather than defaulting to the homepage, since such catch all redirects are increasingly penalized by Google and provide little value to users. For categories that no longer exist in the new shop, redirecting to the next closest, topically related category level is preferable to an arbitrary destination.

The mapping table should be reviewed in parallel by several people (SEO, development, content), since individual mismatches often only surface weeks later as ranking losses. For very large catalogs with several thousand URLs, an automated mapping based on product attributes such as SKU or category ID, combined with a manual spot check of the highest traffic pages, is the most reliable approach.

4. Implementing Redirects Correctly

For the actual implementation, the rule is simple: always use server side 301 redirects, never meta refresh or client side JavaScript redirects, since search engines interpret those far less reliably. Redirect rules should sit as close to the domain or web server level as possible, so they work independently of application code and survive even a future CMS change.

For very large mappings, a redirect database or lookup table is preferable to hundreds of individual rules hardcoded into a configuration file, since it is far easier to maintain and performs better at scale. Before the final launch, every redirect should be spot checked, including a check for redirect chains, since more than one hop per URL slows crawling unnecessarily and should be consolidated.

# 301 redirect from old category URL to new equivalent
location = /old-category-shoes.html {
    return 301 https://www.example-shop.com/new-category-shoes/;
}

# Bulk redirect via map for large catalogs
map $uri $redirect_target {
    /old-product-page-1.html  /new-product-page-1/;
    /old-product-page-2.html  /new-product-page-2/;
}

server {
    if ($redirect_target) {
        return 301 https://www.example-shop.com$redirect_target;
    }
}

5. Handling the Search Console Property Change

For a domain migration, Search Console offers an explicit change of address tool that should be triggered once both domains are verified. This signals to Google that a full domain move is taking place and noticeably speeds up the transfer of historical ranking signals to the new domain compared with simply waiting passively.

If the domain stays the same and only the URL structure changes, this step is skipped, but the existing sitemap in that property still needs close monitoring. In both scenarios it makes sense to keep the old and new properties running in parallel for at least six months, to compare click, impression and indexing data and catch problems early.

6. Resubmitting the Sitemap and Checking robots.txt

After launch, a new XML sitemap containing only the current URLs is generated and submitted through Search Console. The sitemap should not include any URLs that redirect, return a 404, or carry a canonical tag pointing elsewhere, since such entries confuse Google unnecessarily and dilute crawl prioritization.

At the same time, the robots.txt file needs to be checked carefully, because one of the most common relaunch mistakes is accidentally carrying over a staging environment's robots.txt that disallows all crawlers, which blocks the entire new site from search engines. This single error is one of the most frequent causes of dramatic, sudden visibility loss right after a relaunch and deserves its own double checked line item on the launch checklist.

7. Checking Internal Linking and Content Migration

Even the best redirect strategy cannot replace correct internal linking in the new system, since Google weighs links within the current site structure more heavily than legacy redirect chains. All key navigation elements, breadcrumbs, footer links and related product or article links should be linked just as carefully in the new system as they were in the old one.

For the content migration itself, it is worth checking whether heading structure, metadata, structured data and image alt text were carried over completely and unchanged, since these elements are the ones most commonly lost during automated migration scripts. A spot check comparing the ten to twenty most important pages before and after migration reliably catches these gaps before they go live.

8. The Monitoring Period After Launch

The first two to four weeks after a relaunch are critical and should be accompanied by daily monitoring. That includes a daily check of index coverage in Search Console, watching crawl behavior in server logs, and daily rank tracking for the most important keywords, so deviations are caught immediately rather than weeks later.

After this intensive phase, an extended monitoring period of at least three months follows, comparing traffic, rankings and conversions against the same period the previous year on a weekly basis. This longer observation window matters because some relaunch effects, such as a gradual reassessment by Google, only show up with a delay of several weeks.

9. Troubleshooting Ranking Drops

If rankings drop despite careful preparation, a structured troubleshooting process helps: first check whether the affected pages are actually indexed correctly, then verify redirects for chains or wrong destinations, and finally compare whether content, structure or internal linking have meaningfully declined compared with the old version.

In most cases, drops trace back to one of three causes: broken or missing redirects, accidental deindexing through robots.txt or meta robots tags, or a noticeable drop in content quality introduced during migration. Systematically ruling out these three causes usually reveals the actual source of the problem within a few days, allowing for a targeted fix instead of an open ended wait.

10. Summary

11. FAQ: Relaunch Checklist