SEO Migration Planner & Validator

Free, no signup. Run the migration in order: create a redirect map, verify what deployed, check the old URLs, compare the sitemaps, then spot-check historical snapshots. Your project stays in this browser unless you export it; public verification requests use the site's bounded fetch service.

Built by Patrick Stox

Saved in this browser.

Step 1

Build the redirect map

Paste the pre-migration URL set and the intended destination set. Exact/strong matches start accepted; weak or unmatched rows stay for review.

Recommended: bring in the full version 2 project so pattern rules, manual overrides, 410 decisions, and review states stay intact. The text fields below remain a quick-start fallback.

Agency report

Migration readiness summary

Use Print / save PDF to hand off this scoped record. It declares skipped steps rather than implying they passed.

Checks run from our server; we fetch the URL you enter and don't keep the results. The URL lists, map, and report are stored only in this browser. Optional verification, status, sitemap, and Wayback steps request the public URLs you enter through their respective bounded endpoints. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Sample report Static workflow example

Spring domain migration

  • Step 1: Redirect map — complete (48 accepted, 2 review)
  • Step 2: Verify redirects — partial (one rate-limited row not evaluated)
  • Step 3: Bulk status — not run
  • Step 4: Sitemap diff — complete (3 added, 1 removed)
  • Step 5: Wayback checks — complete (5 sampled)

Follow-up signals need review; one step not run.

This demonstrates state handling and report shape, not results from a real migration.

How to use it

  1. Paste complete old and new URL inventories, build the map, and review every weak or unmatched suggestion.
  2. Deploy only accepted redirects, then verify those live old URLs.
  3. Run the separate bulk-status view to find old URLs that still error or resolve unexpectedly.
  4. Compare old/new child sitemaps and spot-check accepted old URLs in the Archive.
  5. Export the browser project and print the readiness summary with all skipped states visible.

What each step produces

  • Map tier/review — strength of the suggested URL match and the human acceptance state.
  • Verification verdict — whether an accepted row deployed as the expected direct 301 to a 2xx target.
  • Bulk status — operational resolution of every old URL through bounded batches, separate from expected target matching.
  • Sitemap diff — absolute URLs added to or removed from the supplied child sitemaps.
  • Wayback — archive capture counts for up to five accepted old URLs.

How project data is stored

Map matching, review state, project persistence, and reporting run in the browser. Verification and status use bounded redirect/status endpoints, sitemap comparison uses the protected sitemap fetcher and validator, and archive checks use cached CDX responses. Each step writes an explicit state into the exported project.

Features

  • Five ordered migration workstreams in one browser project.
  • Human review preserved alongside deterministic URL matching.
  • Live redirect/status verification with honest unavailable rows.
  • Sitemap additions/removals and bounded archive spot checks.
  • JSON import/export and printable agency summary.

Limitations

The tool does not deploy redirects, crawl every new page, authenticate, call GSC, or prove content equivalence. Large bulk-status runs are paced in bounded host-aware batches; archive checks are capped at five accepted rows and the map preview at 40 rows. Browser storage can be cleared; export important projects. A completed workflow remains a scoped QA record, not a guarantee of traffic or index preservation.

Frequently asked questions

What does the SEO Migration Planner & Validator store?

The project name, URL sets, map, review decisions, and completed-step results are stored in this browser. You can export a JSON project or print the report.

Does the redirect mapper deploy redirects?

No. It suggests matches and records review decisions. Deployment happens in your server, CDN, or platform, after which the verification step can check accepted rows.

What counts as a correct verified redirect?

The verification step requires a direct 301A 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. from the accepted old URL to its mapped destination, ending in a successful 2xx response.

Does a Wayback snapshot prove content equivalence?

No. It only establishes that an archived capture was returned for a sampled old URL. It does not verify the redirect or compare old and new content.

Can skipped steps appear as passed?

No. The report preserves not-run, partial, error, and complete states so an incomplete workflow is not presented as release-ready.

Local data

Saved targets, named lists, and recent check summaries remain only in this browser.

Next stepRedirect Chain Mapper — verify it with a direct check.

Explore more
ToolSEO Incident SimulatorToolHTTP Status & Redirect CheckerToolRedirect CheckerArticlePost-Acquisition SEO Integration and Site ConsolidationArticleSite Split and Carve-Out SEO MigrationArticleTechnical SEO

Feature requests for Migration Command Center

Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.

Loading…

➕ Request a feature

New requests are reviewed before they appear here.

Feedback
Report a bug

Found something broken in Migration Command Center? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
           
 
Common issues & how to fix them
 
 
 
 
 
SEO Migration Planner & Validator · one finding
 
Legacy URL has no safe migration match
 
Recommended action: Map the legacy URL to the closest intent-equivalent live destination, or deliberately return 410 when none exists.
 
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
 
 
 
 Implementation for your setup 
 
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
 
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
 
Steps
  1. Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
  2. Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
  3. Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
  4. Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
  5. Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
  
Verify on this platform
 
  • Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
  • After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
  • Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
 
Rollback
  1. Retain the prior redirect configuration and the exact deployment revision.
  2. If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
 
Caveats
  • A similarity score is evidence for review, not permission to publish a redirect.
  • Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
  • Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
  • Verify the final public responses independently against the reviewed source-to-destination map.
  
Caveats
  • Do not treat an accepted import as proof that every rule is active or ordered as intended.
  • Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
  2. Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
  3. After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
  4. Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
 
Escalate when
 
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
 
 
 
 
 
 
 
SEO Migration Planner & Validator · one finding
 
Redirect match confidence is low
 
Recommended action: Manually verify content intent and choose a stronger destination instead of publishing the low-confidence suggestion.
 
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
 
 
 
 Implementation for your setup 
 
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
 
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
 
Steps
  1. Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
  2. Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
  3. Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
  4. Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
  5. Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
  
Verify on this platform
 
  • Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
  • After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
  • Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
 
Rollback
  1. Retain the prior redirect configuration and the exact deployment revision.
  2. If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
 
Caveats
  • A similarity score is evidence for review, not permission to publish a redirect.
  • Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
  • Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
  • Verify the final public responses independently against the reviewed source-to-destination map.
  
Caveats
  • Do not treat an accepted import as proof that every rule is active or ordered as intended.
  • Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
  2. Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
  3. After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
  4. Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
 
Escalate when
 
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
 
 
 
 
 
 
 
SEO Migration Planner & Validator · one finding
 
Many legacy URLs collapse to one destination
 
Recommended action: Keep the consolidation only when every source shares destination intent; otherwise create specific one-to-one mappings.
 
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
 
 
 
 Implementation for your setup 
 
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
 
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
 
Steps
  1. Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
  2. Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
  3. Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
  4. Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
  5. Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
  
Verify on this platform
 
  • Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
  • After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
  • Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
 
Rollback
  1. Retain the prior redirect configuration and the exact deployment revision.
  2. If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
 
Caveats
  • A similarity score is evidence for review, not permission to publish a redirect.
  • Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
  • Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
  • Verify the final public responses independently against the reviewed source-to-destination map.
  
Caveats
  • Do not treat an accepted import as proof that every rule is active or ordered as intended.
  • Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
  2. Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
  3. After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
  4. Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
 
Escalate when
 
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
 
 
 
 
 
 
 
SEO Migration Planner & Validator · one finding
 
Mapped destination introduces a redirect chain
 
Recommended action: Point the legacy URL directly to the final live destination in one server-side redirect.
 
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
 
 
 
 Implementation for your setup 
 
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
 
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
 
Steps
  1. Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
  2. Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
  3. Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
  4. Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
  5. Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
  
Verify on this platform
 
  • Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
  • After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
  • Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
 
Rollback
  1. Retain the prior redirect configuration and the exact deployment revision.
  2. If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
 
Caveats
  • A similarity score is evidence for review, not permission to publish a redirect.
  • Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
  • Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
  • Verify the final public responses independently against the reviewed source-to-destination map.
  
Caveats
  • Do not treat an accepted import as proof that every rule is active or ordered as intended.
  • Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
  2. Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
  3. After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
  4. Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
 
Escalate when
 
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.
 
 
 
 
 
 
 
SEO Migration Planner & Validator · one finding
 
Removed sitemap URLs are not mapped
 
Recommended action: Map every removed sitemap URL to an equivalent destination or document an intentional 410 response.
 
Fix principle: A migration map is an explicit, reviewable contract between the complete old inventory and the intended new inventory. Prefer the closest equivalent destination, retain unmatched and ambiguous rows for human decisions, and remove loops, chains, collisions, and content mismatches before generating deployment rules.
 
 
 
 Implementation for your setup 
 
Confirm first: An old URL is unmatched, weakly matched, ambiguously matched, or collapsed with unrelated URLs onto one destination. The proposed map creates a loop, redirect chain, destination collision, or a destination whose content intent does not match the old page. A URL removed from the old sitemap has no reviewed redirect or deliberate 404/410 decision.
 
Do not apply when: Every material old URL has one reviewed equivalent destination or an explicit retirement decision, with provenance for how the row entered the inventory. The flattened map contains no loops, chains, ambiguous matches, accidental many-to-one collapses, or destinations outside the approved migration scope.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Version-controlled migration inventory and the single server, edge, or application layer that will own redirects
 
Steps
  1. Assemble the old inventory from sitemaps, crawls, analytics, logs, backlinks, and archives; retain each URL's provenance and business importance.
  2. Assemble the complete intended destination inventory, normalize only equivalences that are actually safe for this site, and score candidate matches by path, content intent, and known relationships.
  3. Require human review for unmatched, weak, ambiguous, many-to-one, or materially content-mismatched rows; do not silently redirect them to the homepage or a broad category.
  4. Flatten approved targets to their final destination, then reject loops, chains, duplicate source rules, conflicting patterns, and destinations outside the approved new scope.
  5. Generate deployment rules only from approved rows and preserve the reviewed map as the immutable verification input.
  
Verify on this platform
 
  • Run structural validation over the complete map and confirm zero loops, chains, duplicate sources, conflicting rules, or unreviewed deployable rows.
  • After deployment, request every approved old URL and require one permanent redirect directly to its reviewed destination, followed by a successful final response.
  • Compare the deployed result with the frozen reviewed map rather than accepting any successful destination.
 
Rollback
  1. Retain the prior redirect configuration and the exact deployment revision.
  2. If the new rules create loops, widespread wrong destinations, or availability failures, restore the prior configuration as one atomic change and re-run the verification inventory.
 
Caveats
  • A similarity score is evidence for review, not permission to publish a redirect.
  • Many-to-one redirects can be correct for genuine consolidation, but they require an explicit decision because they can also hide lost content.
  • Deleted content with no equivalent may correctly return 404 or 410; a redirect is not mandatory merely because a URL existed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor migration, routing, or redirect-import system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor for its maximum rule count, ordering and wildcard semantics, duplicate handling, export/rollback path, and whether it rewrites chains automatically.
  • Verify the final public responses independently against the reviewed source-to-destination map.
  
Caveats
  • Do not treat an accepted import as proof that every rule is active or ordered as intended.
  • Escalate if the platform cannot export the active rules or restore the prior configuration atomically.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Freeze the reviewed old inventory, destination inventory, mapping decisions, and generated deployment revision.
  2. Validate zero loops, chains, duplicate sources, conflicting patterns, or unreviewed deployable rows.
  3. After cutover, verify every approved old URL against its expected destination and preserve failures as evidence.
  4. Monitor old and new URL traffic, crawl activity, indexing, and server errors through the migration window.
 
Escalate when
 
Escalate when the old inventory is materially incomplete, destination intent cannot be established, many-to-one decisions affect valuable pages, or the deployment layer cannot provide an exportable rollback.