An SEO Release Checklist for Website Migrations and Redesigns

A website migration or redesign can improve usability, make publishing easier and give a business room to grow. It can also change several things search engines rely on at the same time: URLs, page content, internal links, rendering, indexation rules and performance.

The safest approach is to treat SEO as part of release planning, not as a final review after the new site is live. This SEO checklist for website migration and redesign is organised around three stages: prepare, release and monitor. It applies to a new domain, a change in URL structure, a CMS rebuild, a redesign on the same URLs, or a combination of these.

Not every item carries the same risk. A small visual refresh with unchanged URLs needs a different level of redirect planning from a move to a new domain. Record what is changing, who owns each task and how you will verify it before launch.

Before the release: establish what must be preserved

1. Define the migration scope and baseline

Write down the exact changes: domain, protocol, subdomain, URL paths, CMS, templates, navigation, content, JavaScript framework or hosting. This matters because problems can overlap. For example, a redesign may retain URLs while replacing server-rendered HTML with client-side rendering, changing how quickly search engines can access page content.

Capture a baseline before development is complete. Export important landing pages and their organic clicks, impressions and average positions from Search Console, and collect sessions or conversions from your analytics platform. Record the date range and any seasonal or campaign effects. These figures are comparison points, not a promise that performance should remain identical after launch.

Also save a crawl of the current site. Include status codes, indexability, canonical URLs, title tags, headings, internal links and XML sitemap URLs. Keep a copy of the current robots.txt file and any redirects. If the site is large, prioritise pages with organic traffic, conversions, backlinks or strategic value rather than treating every URL as equally important.

2. Build and review a URL mapping

For every valuable old URL, identify the closest relevant destination on the new site. A redirect map should include the old URL, new URL, reason for the change and an owner or review status. Map at page level where possible; sending every retired product or article to the home page is usually a poor substitute for a relevant destination.

For example, if a local plumbing company replaces /services/boiler-repair/ with /heating/boiler-repairs/, the old page should normally redirect directly to the new service page. If an old page has no close equivalent, decide whether to retain it, create a suitable replacement or return a genuine 404 or 410 response. Do not redirect unrelated pages simply to avoid seeing errors.

Use permanent server-side redirects for URLs that have permanently moved, and avoid chains such as old URL to intermediate URL to final URL. Check the distinction between redirects and canonical tags with this guide to canonical tags versus redirects: they solve different problems and should not be treated as interchangeable.

3. Protect content and page-level signals

Compare the current and proposed versions of important pages. Check that the main subject, useful detail, headings, descriptive titles, image context, structured data and internal links have not disappeared accidentally. A redesign does not need to preserve every sentence or layout choice, but a page that loses the information users came for may no longer serve the same search intent.

Make a list of page types—such as product, service, category, article and location pages—and inspect at least one representative page from each. Confirm that templates produce unique titles and descriptions where appropriate, a clear primary heading, crawlable links and the correct canonical URL. Check pagination, filters and faceted navigation separately if they create multiple URL variations.

If the new site relies on JavaScript to display important content, test what a search engine can render rather than assuming the browser view tells the whole story. Ryse SEO’s guide to testing whether a JavaScript site renders SEO content outlines checks that can help identify missing text or links.

4. Make the test environment safe—and useful

Staging sites should not become accidental search results. Use access controls where practical; if that is not possible, apply an appropriate noindex directive and verify it is present. A robots.txt block alone does not guarantee that a URL will stay out of search results, because crawlers may still discover the address through links.

At the same time, make sure the staging environment is available to the people testing it. Crawl representative pages and check rendered content, response codes, canonicals, links, images and forms. Test the production configuration as closely as possible, but keep staging safeguards from being copied into the live release.

Release checklist: verify the live site, not just the deployment

5. Check redirects, status codes and canonical URLs

As soon as the release is live, test a sample of high-priority old URLs and crawl the redirect list. Each moved URL should reach the intended destination in one step where possible. Confirm that the destination returns a successful response, rather than a 404, soft 404, blocked page or redirect loop.

Then check the new pages themselves. A page intended to appear in search should generally return a successful status, be accessible to crawlers and have a canonical URL that points to the preferred version. Look for accidental canonicals pointing to staging, the old domain, a parent category or a different page. If both old and new URL versions remain accessible, ensure the chosen consolidation signals are consistent.

6. Check indexation controls and crawl access

Inspect the live robots.txt file and the page-level robots directives. Confirm that production pages have not inherited staging’s noindex setting or a broad crawl block. Conversely, make sure private account areas, internal search results or other low-value areas are handled as intended.

Do not assume one signal fixes every unwanted URL. If the release creates duplicate parameter URLs or exposes old staging paths, investigate the causes and choose an appropriate response. This checklist for investigating indexed but unwanted URLs can help structure that review.

7. Update internal links, sitemaps and key integrations

Internal links should point directly to the new preferred URLs, not rely on redirects. Check navigation, breadcrumbs, related-content modules, footer links, image links and links embedded in key articles. Update the XML sitemap so it contains canonical, indexable URLs that return successful responses; remove old URLs that no longer belong there.

Verify analytics and conversion tracking on the live site. Test important actions such as quote requests, purchases, calls or account sign-ups, and confirm that consent settings still behave as expected. Check Search Console ownership and access, and submit the current sitemap if the property is configured. For a domain move, use Google’s official site-move guidance for URL changes and follow the applicable steps for your situation.

8. Test real user journeys and representative templates

Open the site on mobile and desktop, and follow the paths that matter to the business. A visitor arriving on an old service URL should reach a working replacement and be able to contact the company. A shopper should be able to land on a product page, select options and complete checkout. Confirm that menus, forms, search, filters and key buttons work without relying on internal testing shortcuts.

Test multiple page types, not only the home page. A homepage can work perfectly while product pages return errors or an article template omits its main content. If the release also changes loading behaviour, assess performance across representative templates and prioritise issues that affect important user journeys. See how to prioritise Core Web Vitals fixes across page templates for a practical way to organise that work.

After launch: monitor, diagnose and fix in order

9. Set a short-term monitoring routine

For the first few days, check server logs or crawl data for spikes in 404s, redirect loops, blocked requests and unexpected bot activity. Review Search Console for indexing issues, crawl errors, sitemap processing and changes to impressions or clicks. Analytics can show whether organic sessions and conversions are reaching the expected landing pages, but remember that tracking changes can create apparent drops unrelated to search visibility.

Compare like with like: similar periods, landing pages and business outcomes. A seasonal business may naturally see demand change around launch; a tracking tag may also be missing from a new template. Separate technical evidence from performance interpretation before deciding that a ranking loss has occurred.

10. Prioritise fixes by reach and business impact

Fix broad problems first. A sitewide noindex, broken redirect rule, incorrect canonical template or missing navigation link can affect many URLs. Next address high-value page failures, then smaller issues with limited reach. Keep a log of the problem, affected pages, fix date and verification method so the team can see what changed.

Do not change multiple unrelated things at once if the cause of a decline is unclear. Check whether affected URLs are crawlable, whether their content and destinations are correct, and whether the change aligns with the timing of the release. Search performance can fluctuate during a migration, and a recovery timeline depends on the site, scale of change and how quickly search engines recrawl the affected URLs. The goal is to remove avoidable obstacles and make the new site’s signals coherent—not to guarantee a particular ranking outcome.

Quick release checklist

• Before: document scope, baseline performance and crawl the current site.
• Before: map valuable old URLs to relevant destinations and review the map.
• Before: check content, titles, canonicals, internal links and representative templates.
• Before: secure staging and test rendering, forms and production-like settings.
• Release: test redirects, status codes, canonical URLs, robots directives and indexability.
• Release: update internal links, XML sitemaps, analytics and Search Console configuration.
• After: monitor crawl and indexation issues, landing-page performance and conversions.
• After: prioritise sitewide faults and high-value page failures, then verify each fix.

Frequently asked questions

How long should SEO checks continue after a migration?

Do an intensive review immediately after release, then continue monitoring crawl, indexation and performance trends over the following weeks. The appropriate duration depends on site size, crawl frequency and the scale of the changes. Keep watching until important URLs are being crawled and indexed as expected and major errors have stabilised.

Should every old URL redirect to the new homepage?

No. Redirect an old URL to the closest useful replacement when one exists. If there is no relevant destination, keep the content, create a suitable replacement or return an appropriate not-found or gone response. A homepage is rarely a meaningful substitute for an unrelated page.

Can a redesign keep the same URLs and still affect SEO?

Yes. A redesign can change page content, internal links, headings, rendering, performance, structured data or indexation settings even when URLs stay the same. That is why template-level and rendered-page checks belong in the release plan.

Should the old site stay online after launch?

Keep control of the old domain and its redirect configuration for as long as the business needs the moved URLs to resolve. Do not simply let the old domain expire. The right hosting arrangement depends on the migration, but old addresses should continue directing visitors and crawlers to the intended destinations.

What should we do if organic traffic drops after launch?

First confirm the drop is real by checking analytics implementation and comparing relevant pages and dates. Then inspect indexation, crawl access, redirects, canonical tags, content changes and server responses. Fix verified technical issues before making broad content changes based on a short-term fluctuation.