Website Migration SEO Checklist: A Practical Launch Plan

Agree exactly what is changing

A migration brief should name the changes individually: domain, hosting, CMS, URL structure, content, navigation and tracking. That gives everyone a shared definition of the project and makes problems easier to investigate later.

For example, moving a site to new hosting while keeping its addresses and content is different from replacing the CMS, rewriting service pages and launching a new domain together. Google documents hosting changes without URL changes separately from moves that change URLs.

Ask the project lead to complete this sentence: “At launch, these things will change; these things will stay; these changes will wait.” If everything must change together, allow time to test the combined result and record what changed.

Do not make “zero traffic loss” the acceptance criterion. Google's site-move guidance warns that rankings can fluctuate as it processes a move. Base the launch decision on checks the team can demonstrate, with a monitoring plan for what search engines do afterwards.

Save a baseline you can compare after launch

Before the old site is replaced, save a dated view of its performance and content. A workable starting point is the latest complete 28 days, the preceding 28 days, and a comparable seasonal period when the business has strong seasonal demand. Those windows are a planning recommendation, not a Google requirement.

Keep three views separate:

• •Search visibility: Search Console clicks, impressions, click-through rate and average position, including the queries and landing pages that matter to the business. Use the same search type and filters when comparing periods. Google explains these measures in its Performance report documentation.
• •Website visits and actions: GA4 sessions from Organic Search, landing pages, engagement and the relevant key events already configured. Use session-scoped traffic acquisition when the question is how a visit arrived; first-user acquisition answers a different question. For a comparison with Search Console, also save a view filtered to Session source / medium = google / organic. Google's Traffic acquisition guide explains these dimensions.
• •Actual enquiries: Received forms, bookings, calls or CRM records where available. Separate a recorded event from a genuine enquiry and a genuine enquiry from a qualified opportunity.

If tracking is incomplete, write that down. An unknown baseline does not become zero, and a successful form submission does not prove that its analytics event fired correctly.

Save a content inventory alongside the numbers. Reconcile the CMS export and a crawl of the existing site with URLs receiving search traffic or external links. Include service pages, useful articles, contact routes, campaign destinations and linked files such as PDFs. Google's guidance on finding the old URLs explains why a single source may miss part of the site.

For priority pages, save the title, meta description, main heading, important copy and existing structured data. Review intentional changes with the content owner so useful material is not lost in a new template. A page can matter commercially even when its search traffic is small.

Give every important old URL a decision

Use one shared mapping sheet for the move. Its purpose is to explain what will happen to each address and why. A list of redirects without that decision trail is harder for a marketing lead to review.

The following paths are hypothetical examples, not a client case study:

Give priority pages individual review. Use pattern-based rules only where the relationship between old and new paths is consistent, then test representative exceptions.

For permanently moved pages, Google recommends server-side permanent redirects when possible; both 301 and 308 are permanent redirect status codes. Google's redirect guidance explains the distinction from temporary redirects. The implementation will depend on the platform and host.

Send people to the closest relevant replacement. When there is no suitable replacement, return an HTTP 404 (not found) or 410 (gone) response and offer useful navigation on the error page. A page that looks like an error but returns a successful response can be treated as a soft 404. Google's HTTP status guidance explains the distinction.

Ask for redirects that reach the final destination directly. Google recommends keeping redirects for as long as possible, generally at least a year. Review their use before removing them. For a domain move, assign responsibility for renewing the old domain and keeping the redirect service running; agree where redirects will live before cancelling old hosting.

If platform selection is still open, resolve that decision before the mapping becomes implementation work. Our WordPress versus Webflow comparison covers the operating questions that belong in that choice.

Ask for evidence before approving launch

“SEO has been checked” is too broad to approve. Request a short acceptance record showing what was tested, when it was tested, who tested it and what remains unresolved.

Use this as a starting point and adjust it to the site:

One person may hold several roles. The useful distinction is accountability: someone owns each check, and someone can decide whether a remaining issue blocks launch.

Confirm access to Search Console before launch and make sure its ownership verification will survive the release. For a domain move, verify both the old and new sites, as covered in Google's preparation checks. Include the domain registrar, hosting and redirect service in the access handover so the person responsible can act when a check fails.

Three technical details deserve explicit attention:

Canonical addresses. A canonical tag signals which version of a page you prefer when similar versions exist. Ask the delivery team to check that canonicals, internal links and sitemap entries agree on the intended production URLs. Google's canonical guidance explains these signals. A staging-domain canonical should not be carried into the live site by accident.

Indexing controls. Keep private staging environments protected, then check the actual production response at launch, including page directives and HTTP response headers. A lingering noindex directive can prevent a page from appearing in Google. A robots.txt block is a different control; blocking crawling does not reliably remove a URL from search, and can stop Google seeing a noindex directive. Google's noindex documentation explains why these checks must be separate.

Sitemaps. Check that the production sitemap contains the intended canonical pages and can be retrieved. Submission helps discovery, but does not guarantee indexing. Use Google's sitemap guidance to confirm the implementation rather than treating a submission message as proof that the move is complete.

Where a site supports multiple languages, include language-switch links and the annotations connecting equivalent pages in the acceptance record. Where important content depends on JavaScript, inspect what the rendered page actually contains. The person approving launch should be able to see the evidence without having to interpret the entire codebase.

Set the launch blockers while there is still time to fix them

Agree the decision rules before the launch meeting. Otherwise the team has to negotiate the meaning of “ready” while a deadline is approaching.

Our recommended blockers include:

• •An important service page, resource or enquiry route is missing or broken.
• •A critical group of old URLs has no reviewed destination or fails its redirect tests.
• •The public site is still protected by staging access controls or unintended indexing restrictions.
• •Enquiries do not reach the business, or nobody can verify that they do.
• •The team cannot identify who is responsible for the release and any recovery decision.

Treat a confirmed tracking failure as a separate launch decision. It can make an otherwise functioning release difficult to evaluate. Document the impact and obtain explicit acceptance if a limited measurement gap must remain temporarily.

A minor visual adjustment may be suitable for a post-launch issue list. A broken lead path usually is not. Record exceptions with an owner and a due date, rather than quietly turning failed checks into completed tasks.

Run the live checks in a deliberate order

Once the release is live, repeat the critical checks against the public site. Passing on staging does not prove that production has the same settings.

1. •Open the priority landing pages on desktop and mobile. Check that useful content, navigation and enquiry paths work.
2. •Test a representative set of old addresses, including important service pages and resources. Confirm the destination and response, not just that a browser eventually shows something.
3. •Check production indexing settings, canonicals, internal links and the sitemap.
4. •Complete controlled enquiry and measurement tests. Label test records so they do not become reported business results.
5. •Record the release time, any remaining issues and the person handling follow-up.

For an eligible domain or subdomain move, use Search Console's Change of Address process after the site has moved and redirects are working. It does not apply to a hosting change with the same URLs, a path-only change within the same site, an HTTP-to-HTTPS move, or a switch between www and non-www on the same domain. Google lists the tool's scope and prerequisites, including ownership of both Search Console properties through the same account.

Investigate post-launch changes in the right order

Assign someone to review the site immediately after launch, during the following working days and at agreed checkpoints over the next several weeks. That is an operating recommendation; the appropriate frequency depends on the site's scale and importance.

When a report changes, start with the question it can actually answer:

These are diagnostic starting points, not conclusions about the cause. Check the evidence before making another change. Keep Search Console observations, GA4 sessions and CRM outcomes in separate columns; their definitions and collection methods differ.

When URLs change, compare an old page with its mapped replacement rather than treating the new path as unrelated. For consolidated content, review the group as well as the individual URLs. Keep notes on concurrent campaigns, content edits and reporting gaps so the migration is not credited or blamed for every change.

Leave the business with a usable handover

The migration is easier to manage when the handover contains the approved URL map, test evidence, known issues, reporting baseline and ownership of ongoing checks. Make those documents accessible to the person who will run the site after the project team moves on.

WebKroo's website project work includes planning and delivering website changes, while SEO and AI search services address how people find the site. A migration brief should connect those responsibilities early, even when different people perform them.

If ongoing ownership is still unclear, use our maintenance versus ongoing support guide to decide what should continue after the launch period. The practical next step is to put names, dates and evidence beside the checks above before agreeing the release date.