Technical SEO Migration: A Prelaunch Buyer Checklist

Classify the migration before comparing proposals

Start by naming what changes: hosting, CMS, rendering method, domain, protocol, subdomain, path structure, information architecture, content, design, analytics or several of these together. A hosting move with stable URLs has different search risk from a domain move or a complete content consolidation.

Ask the supplier to separate required change from optional improvement. Combining a domain change, CMS replacement, content rewrite and navigation redesign removes clean baselines and makes faults difficult to isolate. Google advises testing the new site thoroughly and notes that a large site may be moved in sections when that makes detection and repair easier. [1]

Define the business boundary too. Include organic landing pages, paid campaign destinations, email links, product feeds, local listings, partner links, application callbacks, downloads and customer bookmarks. Technical SEO acceptance cannot cover only pages visible in the new navigation.

The proposal should state which team owns the source inventory, redirect implementation, CMS templates, analytics, DNS, CDN, consent platform, Search Console, Bing Webmaster Tools, production logs and launch decision. Shared responsibility without a named approver is an operating gap.

Freeze a source inventory and performance baseline

Require an inventory before URLs or content start changing. Combine XML sitemaps, internal crawls, analytics landing pages, Search Console pages, Bing data, server logs, backlinks, campaign destinations, product feeds and stakeholder lists. No single source is complete.

For each old URL, retain status code, canonical, robots directive, indexability, title, heading, content type, structured data type, language or region annotations, internal-link count, organic entry activity and known external importance. The purpose is not to preserve every weak page. It is to make every keep, merge, redirect, retire or investigate decision explicit.

Capture comparable baselines for organic clicks and impressions, indexed-page patterns, valid structured-data items, crawl errors, page speed, conversions and revenue events where applicable. Search Console documents page indexing, performance, rich-result, URL inspection and Core Web Vitals reports as distinct monitoring surfaces. [8]

Acceptance evidence should be exportable and buyer-owned. A dashboard alone is not a baseline if its dimensions, filters and source data cannot be reproduced after the supplier account is removed.

Make the URL map a product decision record

The URL map should have one row per known old URL and fields for action, final destination, rationale, content owner, redirect type, query treatment, launch status and test result. New URLs should be short and stable, but changing a URL solely to make it look cleaner creates migration work without guaranteed user value.

Map to the closest equivalent page by intent and content. Do not redirect unrelated pages to the home page. Google's site-move guidance warns that irrelevant mass redirects can confuse users and may be treated as soft 404s. [1] If several old pages genuinely become one consolidated resource, document why that destination satisfies each intent.

Retire pages deliberately. Return a truthful 404 or 410 when there is no equivalent and no continuing value. Preserve useful alternatives in the error experience, but do not disguise a removed resource with a successful status code.

Require query-string rules. Tracking parameters can usually pass through or be dropped intentionally, while product, language, search and filter parameters may change the resource. Sample real query URLs from logs and analytics instead of testing only neat canonical examples.

Specify redirect behavior and HTTP evidence

For permanent URL changes, require server-side 301 or 308 responses to the final destination. Google treats permanent redirects as a canonicalization signal and recommends server-side permanent redirects when possible. [2] RFC 9110 distinguishes 301 and 308: both signal a permanent new URI, while 308 unambiguously preserves the request method. [7] The engineering team should choose based on real request behavior, especially for non-GET endpoints.

Test status, Location header, final response, hop count, method behavior, protocol, hostname, trailing slash, casing, encoded characters and representative parameters. A browser arriving at the right page is insufficient if the journey contains temporary redirects, loops, chains or an eventual error.

Update internal links to the final URLs so users and crawlers do not depend on redirects. Include navigation, body links, hreflang, canonicals, structured data, XML sitemaps, image references, CSS, JavaScript and feeds.

Keep the old host, certificates and redirect service operational. Google recommends retaining redirects for as long as possible, generally at least one year. [1] Contract renewal and DNS ownership therefore belong in the migration budget.

Prove crawlability, indexability and canonical consistency

Staging controls must not leak into production. Test robots.txt, meta robots, X-Robots-Tag headers, authentication, IP allowlists and CDN rules from an external production-like environment. The launch checklist must explicitly remove temporary noindex directives and crawler blocks.

Every indexable new page should return its intended status, render its important content and declare a self-referencing canonical unless the information architecture requires another canonical. Align redirects, canonical elements, internal links and sitemap entries. Conflicting signals force search engines to interpret intent rather than follow an acceptance decision.

Google's Change of Address tool is for a move between domains or subdomains after ownership and redirects are ready. It emphasizes crawling and indexing of the new site, but it does not replace redirects or canonicals. [3] Path-only changes on the same domain do not use that tool.

Submit a new sitemap containing only final canonical URLs. Preserve a prelaunch copy of the old sitemap for reconciliation, then monitor whether old indexed URLs decline while new URLs are discovered. For Bing, current webmaster guidance likewise calls for canonical sitemap URLs and proper permanent redirects when content moves. [6]

Validate templates, structured data and international signals

Compare representative rendered pages from every template, not just the home page. Check title, description, heading order, main content, pagination, facets, canonicals, alternate language links, image URLs, Open Graph data and mobile behavior. Include empty, error and edge states.

Structured data should describe visible content on the same page, retain required properties and reference crawlable images. Google's general guidelines recommend JSON-LD, require pages to remain accessible to Googlebot and warn that valid markup does not guarantee a rich result. [4] Test syntax and business meaning. A product price, article date or organization identity can be technically valid but wrong after migration.

For multilingual sites, retain a bidirectional hreflang matrix, correct language or region codes, self-references and final destinations. For images and documents, decide whether asset URLs remain stable, redirect or move, and check that search-relevant files are not blocked by the CDN.

Acceptance should include a text export of detected schema types, errors and key property comparisons by template. A clean home-page test cannot approve hundreds of product, article or location pages generated by different code paths.

Protect analytics, consent and conversion evidence

Write a measurement map before launch: tags, container IDs, consent states, page views, events, ecommerce payloads, form conversions, call tracking, ad pixels, referral exclusions, internal traffic filters and reporting destinations. Decide which identifiers must remain continuous and which intentionally change.

If journeys cross domains, configure and test cross-domain measurement. Google Analytics documents that the linker parameter can be lost when a destination redirect strips arbitrary query parameters. [5] Test actual links and forms, including consent choices and downloads, rather than merely confirming that a tag script loads.

Run an illustrative order or lead journey in staging and production with test identifiers. Confirm the event name, parameters, source attribution, consent behavior, destination system and report visibility. Remove test data or mark it according to the buyer's governance rules.

Retain a tag and event comparison between old and new templates. Launch-day real-time traffic is a useful signal, but acceptance also needs delayed checks for processed events, conversions and downstream CRM or commerce records.

Use an eight-gate prelaunch acceptance matrix

Convert the migration plan into pass or fail evidence. The matrix below is the text equivalent of the infographic.

Define sample sizes by risk and template diversity, not a convenient percentage. Critical revenue, sign-in, checkout and high-demand landing paths deserve direct tests even on a very large site.

Worked example: migrate a B2B software site

Consider an invented B2B software company moving from a legacy CMS to a headless build while changing its product taxonomy. This is an educational example, not a client result. The combined inventory contains 1,200 distinct old URLs after normalizing fragments and obvious tracking parameters.

The team keeps 620 paths, maps 310 to close equivalents, consolidates 90 into stronger resources, retires 140 with no suitable replacement and sends 40 ambiguous rows back to content owners. These numbers are created only to demonstrate reconciliation. The acceptance condition is that all 1,200 rows have an approved action before launch.

Prelaunch testing finds three material issues: a wildcard redirect sends retired documentation to the home page, article canonicals still point to staging and a region selector strips the Analytics linker parameter. The team replaces the wildcard with explicit mappings and truthful 404 responses, updates the template canonical helper and preserves the linker parameter through the region redirect.

At launch, operations monitor old-to-new status results, unexpected 4xx and 5xx responses, sitemap fetches, Googlebot activity, indexability, organic landing sessions and test conversions. The rollback rule covers a defective application release, but not a blind reversal of the URL map after search engines have started processing permanent moves.

Define launch monitoring and a safe rollback boundary

Name one launch commander, technical owner, SEO owner, analytics owner, content owner and communication owner. Record the decision channel, checkpoints, severity levels and authority to pause or reverse a release.

Monitor synthetic requests for critical old and new URLs, external crawls, server and CDN errors, redirect mismatches, robots and canonical changes, sitemap availability, search-console signals, analytics events and business transactions. Google notes that post-migration crawling can increase, so capacity and logs should be ready before redirects turn on. [1]

Set thresholds and actions in advance. A broken checkout or site-wide noindex may require immediate rollback. A small set of mapping errors may be safer to repair forward. DNS, CMS, database, content and redirect changes have different reversibility, so one generic rollback button is not an adequate plan.

Keep a launch decision log with timestamp, observation, owner, action and result. Continue monitoring after the launch room closes because indexing, link processing and analytics reporting do not complete at the same time.

Compare proposals by retained evidence and ownership

Ask suppliers to price discovery, inventory, mapping, development, testing, launch coverage, monitoring, reporting and handover separately. Clarify crawl limits, environments, templates, languages, domains, analytics properties and post-launch support. A low quote may exclude the inventory work that makes redirect testing possible.

An SEO and LLM search optimization scope should define the search controls and acceptance evidence. A website development scope should define implementation, environments and release ownership. Apply the same criteria to TechLithic or any other provider.

Require buyer-owned access to Search Console, Bing Webmaster Tools, analytics, tag management, DNS, CDN, hosting, repositories and monitoring. Supplier accounts can assist operations, but the buyer should be able to inspect, export and revoke access without losing evidence.

Do not buy a migration guarantee framed as a ranking promise. Search visibility can fluctuate while systems recrawl and process a move. Buy a controlled implementation, accurate signals, prompt repair and transparent reporting.

Use this checklist before approving launch

• Is the exact migration type and change boundary documented?
• Are redesign, content and platform changes separated where practical?
• Does the frozen inventory combine crawl, search, analytics, logs, links and feeds?
• Does every old URL have an approved action and rationale?
• Are important query-string and encoded URL variants represented?
• Do permanent moves return direct 301 or 308 responses to relevant final pages?
• Are loops, chains, wildcard errors and irrelevant home-page redirects absent?
• Are internal links, canonicals, hreflang, schema and sitemaps updated to final URLs?
• Are production robots, noindex and access controls tested externally?
• Does every indexable template render useful content and a consistent canonical?
• Are structured-data values visible, accurate and valid by template?
• Are image, document, feed and campaign URLs covered?
• Are analytics, consent, events, conversions and cross-domain journeys tested?
• Are both old and new domains verified in webmaster tools where required?
• Are DNS, certificates, old-host capacity and redirect retention funded?
• Are launch owners, thresholds, incident channels and rollback boundaries named?
• Will server, CDN, crawl, search, analytics and transaction signals be retained?
• Can the buyer operate the controls and revoke supplier access after handover?

For a broader redesign decision, use the website redesign scope guide. For baseline deliverables, compare the SEO audit buyer guide. A migration is ready when failures are observable, responsibilities are named and every important old path has an intentional outcome.

Frequently asked questions