SEO Migration Checklist: URLs, Redirects and Verification

An SEO migration checklist should connect each important old URL to an intentional outcome and verify the new site after an authorized release. A successful local build does not prove the public move worked. Keep preparation, deployment and public verification as separate stages with their own evidence.

• Inventory old URLs from more than one available source.
• Map each retained or retired page to a justified outcome.
• Test redirects, canonicals, links and indexing controls together.
• Define release and rollback responsibilities before launch.
• Verify the public site instead of relying on deployment status.

For named providers and links to their published service scopes, see Best Ecommerce SEO Companies: Catalog and Revenue Fit; Best Shopify SEO Agencies: Store Implementation Compared. Use those shortlists alongside this guide’s evaluation questions; published scope alone does not establish delivery quality or suitability for your project.

For named providers and published service models, compare Technical SEO Agencies: Compare Diagnostics and Engineering; International SEO Agencies: Compare Country and Language Scope. The shortlists distinguish advertised capabilities from the questions to confirm for your actual project.

What kind of migration are you planning?

Identify whether the change affects URLs, domain, platform, content or several of those at once. A visual redesign with stable URLs differs from a domain move. The checklist should match the actual change rather than applying a generic launch sequence blindly.

Read Google’s site move guidance when URLs will change. Use it alongside an inventory of the current site and the proposed implementation. A migration can involve temporary search fluctuations; do not promise that a technical checklist guarantees unchanged rankings.

Record the scope, target environment, decision makers and release responsibilities. Assign the hosting, DNS and indexing configuration to their actual owners. A content handoff and a deployment approval are different milestones; the release plan should make both visible.

How should the old URL inventory be built?

Combine available sources and preserve their origin. A crawl finds reachable pages, while a sitemap, analytics export or search performance export may reveal other URLs. No single source should be assumed complete without checking its limitations.

For each URL, record status, content role, canonical, internal links and any available first-party evidence of use. Keep query parameters and alternate forms visible long enough to understand their behavior. Do not discard them before deciding how the new site will handle them.

Add important assets and external destinations where relevant. A menu PDF, downloadable resource or profile landing page can break even when the main navigation works. Inventory what customers and external links actually use, not just the pages the design team plans to keep.

What belongs in the old-to-new URL map?

Give every important old URL an explicit destination or retirement decision. A destination should satisfy the same or a closely relevant need. Sending unrelated pages to the home page may preserve an HTTP response while failing the visitor’s task.

Store the reason for each mapping. A future editor should understand why a page was consolidated or retired. The map also prevents a later content expansion from recreating an old duplicate without realizing it.

Which staging checks should happen before release?

Check the staged site’s content, navigation and technical signals while maintaining the intended staging restrictions. Confirm that the new site contains the approved pages, not just the right number of routes. A count cannot establish that the correct content survived.

Inspect Titles, H1s, descriptions, canonicals, internal links and structured data. Check representative templates and the important individual URLs from the map. Confirm that assets load and that contact behavior matches the approved workflow.

The landing page development guide covers page-level acceptance. A migration adds a relationship to the old site: old URLs, external destinations and release controls must also be accounted for. Keep those checks in the migration record rather than assuming the redesign team handled them.

How should redirects be tested?

Test each mapped old URL against the intended final destination. Record the response behavior and check that the final page represents the correct content. A redirect that ends on the wrong service is not a successful mapping simply because it avoids an error page.

Look for chains, loops and inconsistent alternate URL behavior. Check internal links so the new site points directly to the intended URLs instead of depending on redirects for ordinary navigation. Confirm canonical signals agree with the final destinations.

Where deployment architecture prevents testing real old-host behavior locally, state that limitation. You can validate the map and configuration in preparation, but the public redirect still needs verification after an authorized release. Do not report a simulated test as a live result.

What response should each mapped URL return?

Use explicit response criteria in the mapping sheet. For a permanent move, Google recommends server-side permanent redirects, including HTTP 301 or 308. For genuinely removed content without a relevant replacement, use an intentional 404 or 410 response rather than an unrelated home-page redirect; see Google’s HTTP status guidance.

These hypothetical paths illustrate decisions, not a real site’s migration configuration:

Inspect the first response headers without following redirects, then follow the route and save the final status and destination. A browser reaching the correct-looking page does not reveal the original response code. For each redirected row, compare the Location header with the approved map, check that the final canonical matches the intended destination and confirm that internal links point directly there. If the old path loops, chains through an unnecessary intermediate page or lands on unrelated content, keep the row open. Repeat the check on the public host after release because staging behavior may differ.

How should indexing controls and canonicals be handled?

Treat environment-specific controls as explicit release items. A local preview may intentionally use noindex and local canonicals. The public environment needs its own reviewed configuration. Do not remove protections merely because the staged site looks finished.

Document which settings should differ between environments and who approves the change. Check robots directives, page-level robots metadata, canonicals and sitemap destinations together. Conflicting signals can be missed when each team checks only its own file.

Maintain a written environment comparison showing staging restrictions and intended production values. During release verification, inspect the actual public response and HTML. A copied configuration file is not evidence that the public site now uses the intended settings.

What should the release and rollback plan contain?

Name the target, authorized change, backup and verification owner. Define what evidence would justify reverting and who can make that decision. A rollback plan that says only “restore the old site” is difficult to use under pressure.

1. Approve the final content and old-to-new map.
2. Save the required source, configuration and target backup.
3. Confirm deployment access and the exact release authorization.
4. Apply the scoped change during the agreed window.
5. Verify important public URLs, redirects, controls and forms.
6. Record failures and decide whether to fix or revert.
7. Continue the agreed monitoring using consistent evidence.

The commercial SEO migration service owns the engagement scope. Keep hosting and DNS responsibilities explicit; not every content or SEO provider controls those systems. Missing access is a dependency to resolve before release, not an excuse to declare the move complete.

How do backlinks and external records fit the migration?

Include important external destinations in the inventory when evidence is available. The backlink audit checklist explains how to distinguish a broken linked destination from a speculative link-risk concern. Those tasks can inform the map without turning the migration into a broad link cleanup.

Review profiles, citations and other owner-controlled links after the new destination is publicly verified. Updating them is an external write and requires appropriate authorization. Keep a record of requested and observed changes.

Do not assume a redirect alone completes every external update. It may preserve a route while the public record remains stale. Conversely, changing an external link before the new site is ready can send customers to an unfinished destination.

What should post-launch verification report?

Report what was independently observed on the public target: page access, final URLs, canonicals, robots signals, assets and contact behavior. A deployment log or HTTP success on the home page does not establish that all important migration paths work.

Separate technical verification from indexing and performance observations. Search engines may not process changes immediately, and an indexing submission is not proof of inclusion or rankings. State the date, method and remaining limitations.

Use the original map as the verification checklist. Mark unresolved URLs and their impact rather than summarizing every issue as a generic launch defect. That gives the business a concrete basis for prioritizing fixes and judging whether the migration has actually met its acceptance criteria.

How should a migration defect be prioritized?

Describe the affected URL, observed behavior and customer or search-facing consequence. A broken contact route, an incorrect redirect and a cosmetic spacing issue require different responses. Use the approved map and acceptance criteria to decide the next action rather than treating every discrepancy equally. Save enough evidence to repeat the check after the fix. If the defect affects public release controls or a broad set of important destinations, bring it to the authorized release owner promptly. Do not silently expand the deployment scope while attempting a local correction. A clear defect record supports a deliberate fix or rollback decision.

Frequently asked questions

Is a redesign always an SEO migration?

Not every redesign changes URLs, but it can still affect content and technical signals. Define the actual changes before choosing the checklist.

Can every removed URL redirect to the home page?

Do not use that as a blanket rule. Choose relevant destinations where they exist and document intentional retirement where they do not.

Does a local build prove public redirects work?

No. Local checks can validate preparation, but public behavior needs independent verification after an authorized release.

Should staging noindex be removed now?

Change it as part of the reviewed production release configuration. Keep staging protected and verify the public page-level robots signal and crawl access after deployment.

Can a migration guarantee unchanged traffic?

No. Record the technical work and monitor appropriate evidence without promising a fixed search outcome.