Languages

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.

Workflow dashboard

Readiness at a glance

No migration steps have run yet.

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.

Migration loss analyzer

Compare user-selected pre/post windows around launch. Cohorts and overlays show correlation; they do not prove causation.

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 Map Builder — generate the corrected version.

People also explore
ToolSEO Incident SimulatorToolHTTP Status & Redirect CheckerToolGoogle Index 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. 
  
 
  
 
 
  
 
 
   
       
 
Where this tool helps
Common use cases
Build and review a redirect inventory
Match complete old and new URL sets, automatically accept only exact or strong candidates, and leave weak or unmatched rows visible for a human decision.
Verify what actually deployed
Test accepted rows after launch and distinguish a correct direct 301 to the intended live destination from a wrong target, temporary redirect, chain, error, or unavailable check.
Separate URL health from mapping correctness
Run a bounded bulk-status view across every old URL without confusing a successful final response with proof that it reached the expected mapped destination.
Reconcile old and new sitemap inventories
Compare supplied child sitemaps and keep added and removed absolute URLs visible for release QA and follow-up investigation.
Create an honest migration handoff
Combine bounded archive spot checks, explicit complete, partial, error, and not-run states, local project export, baseline comparison, and a printable scoped readiness summary.
Watch the full workflow
SEO Migration Planner & Validator walkthrough
Read the transcript

      
      

        
SEO Migration Planner & Validator

        

        
This tool helps you organize the main S-E-O checks for a website migration. We will use a fictional store moving to a new domain, build its redirect plan, check what was deployed, compare its sitemaps, and finish with a simple readiness report. All results in this video are fixed example data, not a live website audit.

      

      

        
Step 1

        

        
A website migration changes addresses, domains, or both. Search engines and visitors still need the old addresses to lead to the right new pages. This tool keeps that work in one project, so you can plan the move, check the launch, and clearly show anything that still needs attention.

      

      

        
Step 2

        

        
You can use it before launch to plan redirects, after launch to check what went live, during quality review to compare old and new sitemaps, and when handing the project to someone else. The important idea is simple: unfinished checks stay visible instead of being counted as passed.

      

      

        
Step 3

        

        
The project has five steps. First, match each old address to a new one. Second, check the redirects that were deployed. Third, check every old address. Fourth, compare the old and new sitemaps. Fifth, look for saved copies in the Wayback Machine. The dashboard shows the state of every step.

      

      

        
Step 4

        

        
Give the migration a clear name. The project is stored in this browser while you work. You can download it as a file, import it later, save a comparison point, or print the report. Download important projects because browser storage can be cleared.

      

      

        
Step 5

        

        
We paste four old page addresses on the left and three new addresses on the right, then choose “Build map.” The tool compares the paths and suggests a destination for each old page. This creates a review list; it does not change the website or install redirects.

      

      

        
Step 6

        

        
The first two products have the same path, so they are exact matches. The guide moved into a new folder but kept the same ending, so it is a strong match. These three suggestions are accepted. You should still review them before deployment, especially when pages have similar names.

      

      

        
Step 7

        

        
The retired sale page has no safe match, so its review state is “to do.” That is useful. Sending every missing page to the homepage can confuse visitors and search engines. A person should choose a genuinely related replacement or decide that the old page should stay gone.

      

      

        
Step 8

        

        
After the redirects are deployed, choose “Verify accepted map.” A three-oh-one is a permanent redirect. A correct result means the old address uses one permanent redirect to the exact destination we approved, and the final page loads successfully. Two rows pass here. One could not be checked, so it stays “not evaluated.”

      

      

        
Step 9

        

        
Next, choose “Check old URLs.” This checks all four old addresses, including the one without an approved match. Three reach working pages. The retired sale page returns four-oh-four, which means page not found. That row needs a decision before the project can be signed off.

      

      

        
Step 10

        

        
A sitemap is a file that lists important website addresses for search engines. Add the old and new sitemap files, then choose “Compare sitemaps.” This example shows one new store-locator page and one removed outlet page. The tool shows the change; your team decides whether the change was intended.

      

      

        
Step 11

        

        
The final step checks whether the Wayback Machine has saved copies of a few old pages. Two pages have archive history. One check is unavailable. An archived copy can help with research, but it does not prove that a redirect works or that the new page has the same content.

      

      

        
Step 12

        

        
All five steps were attempted, but the project is not fully complete. The dashboard shows one complete step, three partial steps, and one step that needs attention. That summary is more useful than a single pass or fail because it points directly to the remaining work.

      

      

        
Step 13

        

        
The report lists the state of every step and counts the follow-up items. You can print it or save it as a P-D-F for a simple handoff. You can also export the full project file when another person needs to continue the checks in this tool.

      

      

        
Step 14

        

        
The main features are local project storage, redirect suggestions, post-launch checks, sitemap comparison, archive spot checks, export, import, saved comparison points, and a printable report. The tool does not install redirects, crawl the entire new site, connect to Search Console, or guarantee that rankings and traffic will be preserved.

      

      

        
Fix the open items, then check again.

        

        
This example is not ready to sign off. One old page has no chosen destination, one redirect check could not run, one old address still returns a page-not-found error, and one archive check is unavailable. Fix or review those items, run the checks again, and export the project so everyone can see what is finished and what is still open.

      

    
 
         
 
Common issues & how to fix them
 
     
  •  Warning Legacy URL has no safe migration match Fix: Map the legacy URL to the closest intent-equivalent live destination, or deliberately return 410 when none exists. 
  •  Warning Redirect match confidence is low Fix: Manually verify content intent and choose a stronger destination instead of publishing the low-confidence suggestion. 
  •  Warning Many legacy URLs collapse to one destination Fix: Keep the consolidation only when every source shares destination intent; otherwise create specific one-to-one mappings. 
  •  Warning Mapped destination introduces a redirect chain Fix: Point the legacy URL directly to the final live destination in one server-side redirect. 
  •  Warning Removed sitemap URLs are not mapped Fix: Map every removed sitemap URL to an equivalent destination or document an intentional 410 response. 
    •