Website relaunch SEO checklist: control the migration from inventory to monitoring

A website relaunch becomes an SEO risk when several systems change without a shared map. New visuals are rarely the problem by themselves. URL decisions, content removal, navigation, indexation signals, analytics and release timing are where visibility and leads can be lost. Treating migration as a controlled product release with its own SEO workstream reduces avoidable risk.

Classify the migration before planning it

A redesign within the same templates is not the same project as a CMS move or a domain change. List every layer that will change:

• brand and interface;
• CMS, framework, hosting or rendering method;
• domain, protocol, folders, slugs or language structure;
• navigation and internal linking;
• copy, media and page purpose;
• forms, ecommerce, analytics and consent controls.

The more layers that move together, the harder it is to diagnose a later change in performance. Where possible, keep stable elements stable. A new design is not a reason to rename every URL, and a CMS migration does not require rewriting content that already meets its purpose.

Create one source of truth for every old URL

Before production content is edited, collect the current site. Combine a full crawl with XML sitemaps, CMS exports, analytics landing pages, Search Console data and relevant backlink records. Each source has blind spots: a crawl can miss orphaned pages, while analytics can miss pages without recent visits.

Use a migration register with one row per old URL. Recommended fields include:

• old URL and page type;
• current status, indexability and canonical;
• organic traffic or clicks for an agreed comparison period;
• key conversions and meaningful external links, where available;
• content owner and migration decision;
• new URL or intended final response;
• redirect test result and approval status.

Preserve copies of robots.txt, XML sitemaps, redirect rules, tracking specifications and important templates. A snapshot gives the launch team a reference when a behaviour is disputed later.

Decide content before assigning redirects

Redirect mapping is the output of editorial and information-architecture decisions. It should not be a last-minute attempt to send every old address somewhere.

Keep a page

If the page still serves a distinct need and performs a useful role, keeping its address is usually the lowest-risk choice. Refreshing the layout or copy does not require a new slug.

Merge several pages

When pages genuinely compete for the same task, consolidate their useful material into one strong destination. Map each source URL directly to that page. Do not redirect valuable content to a thin category that does not answer the same need.

Remove a page

If no close replacement exists, use an honest not-found or gone response and remove internal references. A catch-all homepage redirect hides the gap from neither visitors nor search engines. Before deletion, check campaigns, support documents and external links that may still depend on the address.

No old URL should reach launch day with an undecided destination.

Design the staging environment for testing

Staging must be protected from public access and accidental indexation while remaining fully testable by the project team. Authentication is usually safer than relying on a robots.txt block alone. Make sure the production release cannot inherit staging-only noindex directives or asset paths.

Crawl staging using the approved future host or a consistent test configuration. Review every important template, not just a few showcase pages. Compare:

• titles, descriptions, headings and primary content;
• robots directives, canonical targets and language alternatives;
• navigation, breadcrumbs, pagination and contextual links;
• images, media paths and accessible alternative text;
• structured data that remains appropriate to visible content;
• forms, downloads, checkout and other critical journeys.

Manual journeys matter alongside the crawl. Walk a realistic route from a guidance page to the matching service or conversion step. A new menu can look cleaner while removing links that previously communicated site structure.

Build redirects as a test suite

Use permanent server-side redirects for permanent moves. Each old URL should reach the closest relevant destination in one hop. Eliminate chains that pass through previous migrations, and update internal links to point directly to the final address.

Pattern rules need deliberate test cases. Record examples that must match and examples that must not. Include protocol, host, trailing slash, case and parameter variants where the platform can produce them. Broad rules can quietly redirect unrelated pages if only positive examples are checked.

The migration register can drive an automated test: request the old URL, record each hop, compare the final status and destination with the expected values, and flag differences. Run it before launch against the prepared rules and immediately after deployment against production.

Keep content and metadata accountable

Content migration is often divided among several editors, which makes template defaults easy to miss. Assign an owner to each page or content group and define a completed state. The page is not finished merely because the body copy exists.

The review should include the search intent and purpose of the page, title, description, unique main heading, internal links, media, canonical and language relationships. If content has been rewritten substantially, compare it with the queries and user tasks the old page served. The new version does not need to repeat every sentence, but it should not accidentally discard the section that answered the main need.

Test measurement as part of acceptance

A relaunch can make traffic appear to change simply because tracking definitions changed. Freeze a measurement specification before release. It should identify primary and secondary conversions, event names, values, currencies, transaction or lead identifiers and the consent states in which tags may operate.

Test complete journeys rather than confirming that a tag exists. Submit forms successfully and unsuccessfully, complete test purchases, repeat the confirmation page, move between domains where relevant and check both browser diagnostics and receiving-platform reports. Look for missing events and duplicates.

Technical testing does not replace legal review of consent and data processing. The project should have a named owner for that decision.

Set a release freeze and rollback threshold

In the final week, reduce optional changes. Every late addition creates a dependency that has had less time to be tested. A release freeze should allow critical fixes, but only with an owner, review and clear description of their impact.

Before approval, confirm:

• the final staging crawl has no unresolved launch blocker;
• the URL register and redirect rules are approved;
• robots, canonicals, language annotations and sitemaps use production values;
• representative mobile and desktop journeys work;
• critical conversions pass in the intended consent states;
• backups, deployment steps and rollback ownership are ready.

Define the conditions that justify rollback before the release begins. Examples might include widespread server errors, a broken checkout or a site-wide indexation block. Without a threshold, teams lose time debating the decision during an incident.

Use a launch-day runbook

After deployment, first verify availability. Check the homepage, representative templates, robots.txt, XML sitemaps, canonical tags and critical user journeys. Confirm that production is indexable as intended and staging remains protected.

Next, run the prepared redirect test and a focused production crawl. Prioritise widespread server errors, unexpected noindex, incorrect canonical hosts, internal links to old URLs and assets still loaded from staging. Submit the final sitemap only after the live site is stable.

For a domain move, retain control of the old property and keep its redirects available. Complete the relevant search-engine ownership and address-change procedures. The old domain remains part of the migration infrastructure.

Monitor page cohorts alongside site-wide totals

Daily site-wide traffic is noisy. During the first month, compare page types, directories and query groups with the baseline. Track server errors, crawling, indexation, organic landing pages and conversions together.

Useful diagnostic patterns include:

• one template declines while the rest of the site is stable;
• old URLs continue to receive internal links or heavy crawling;
• search engines select unexpected canonical URLs;
• new pages exist but remain absent from navigation or sitemaps;
• conversion loss is limited to one device, form or checkout step;
• 404 and server-error groups grow after the first clean-up.

A pattern points to a testable hypothesis. A single total rarely tells the team what to fix.

Make ownership visible

Migration failures often sit between disciplines. SEO specifies a requirement, design changes a component, development implements the template, content populates it, and analytics checks the event. Assign one person to own the outcome and another to verify it for every launch-critical task.

If the project combines a new interface, platform work and content migration, bring web design and development into the SEO planning before templates are signed off. URL and linking constraints are cheaper to solve in the architecture than after content has been loaded.

Five gates before launch approval

1. Every previously relevant URL has a documented decision.
2. Every changed URL reaches an equivalent destination without a chain.
3. Content, internal links and indexation signals have passed staging review.
4. Conversions have been tested end to end in the intended consent states.
5. The launch team has owners, monitoring and agreed escalation paths.

A «not yet» at any gate is useful information. It identifies a specific risk that can be accepted, corrected or used to move the release date-before visitors discover it.