SEO Migration Checks: Protect Your Most Valuable Pages

A migration can launch with a working homepage and still break the pages that bring customers to your business. Old product URLs might resolve to a generic category. A resource that earns links might disappear. A staging directive might remain on the new templates.

Protecting organic search starts with identifying which URLs deserve individual checks and deciding what each one should become. You need a reviewed mapping, evidence from before and after launch, and an owner who can act when a check fails.

Claude or ChatGPT can organize that work. RankParse provides live public page checks and bounded sitemap discovery, while your exports supply the commercial context and fuller URL inventory. The result should be a migration ledger that supports release decisions, not a long list of generic warnings.

This guide uses illustrative examples throughout. It does not describe a measured migration or promise that following a checklist will eliminate ranking changes.

Build an inventory around business value

Collect URLs from more than the existing sitemap. Combine your content management system export, a crawler export, Search Console landing-page data, analytics landing pages, current redirect rules and any known campaign or customer links. Include downloadable resources and older URLs that still receive visits or links.

Keep the source of each URL. A page absent from a current sitemap may still matter because customers have bookmarked it. Conversely, a sitemap entry may describe a page that should have been retired years ago. An inventory is evidence to reconcile, not a list to preserve without review.

Use business signals to create a priority group: pages responsible for qualified conversions, important product journeys, recurring support tasks and useful external references. Keep separate columns for these reasons. A commercially important pricing page and a widely cited technical guide can both deserve close inspection for different reasons.

RankParse's get_backlinks, with domain, sort=recent and a chosen limit, can surface URL-level link examples in to_url. These are candidates from a periodic link-graph snapshot, not a complete or live backlink inventory. Keep from_url and crawled_at so reviewers can understand what was observed and when. An omitted URL is not evidence that the page has no links.

For larger inventories, use your own crawl and business exports as the backbone. RankParse is useful for targeted checks and corroboration; it does not produce a complete crawl graph through its public page tool.

Define what changes and what success means

Write a migration scope before generating a redirect map. State whether you are changing domains, URL paths, templates, the content management system, information architecture, or several of these at once. Identify the launch date, content freeze, responsible engineer and rollback decision owner.

For each important old URL, select an intended outcome:

Do not map every removed URL to the homepage for convenience. A successful response from an unrelated destination does not preserve the reader's task. When no equivalent exists, an intentional removal may be clearer than a misleading redirect.

Agree on release blockers in advance. Examples include a high-value URL reaching an unrelated page, a critical template carrying an unintended noindex directive, or a redirect mapping that has not been tested. Minor wording improvements may be follow-up work. The point is to prevent a busy launch room from improvising its standards.

Capture a baseline before the old site disappears

Connect RankParse through the Claude or ChatGPT setup guide. The OAuth connector is read-only: it can inspect public pages, but it cannot implement redirects, change a website or directly import Search Console reports. Supply the exports yourself and keep implementation in your engineering workflow.

For the selected priority URLs, use get_page_seo with the full url. Save the check time and these documented fields: status_code, final_url, title.text, canonical.url, robots.raw, headings.h1 and hreflang. Record any missing values without replacing them with assumptions.

The Page SEO documentation distinguishes the target's status_code from the API request's success. A successful tool response can contain a target status of 404 or 500. The tool follows redirects and reports final_url; it does not expose the full redirect chain or prove that the original response used a permanent redirect. Use a redirect-aware HTTP check or crawler to verify every hop and status when that matters.

Capture current content and functionality separately. RankParse parses raw HTML rather than rendering JavaScript, and its H2 list is limited to the first ten headings. Browser inspection is needed for dynamic navigation, calculators, forms and content loaded after rendering. A migration can preserve metadata while breaking the feature users came to use.

Start the assistant with an evidence assignment:

We are migrating [scope] on [date]. I have attached the old URL
inventory, business-priority signals and proposed destination map.
Review only the priority URLs listed in the packet.

Use RankParse get_page_seo for their public baseline. Preserve
status_code, final_url, canonical.url, robots.raw, title.text and
headings.h1 with check times. Identify missing mappings and mismatched
reader tasks. Separate facts, intended changes and unresolved questions.
Do not infer redirect types, Google indexing or selected canonicals.

Inspect the new site's domain and URL declarations

Run get_site_health for the public destination domain when available. Its documented checks include https.enforced, www_redirect.target, and checks entries for the homepage, robots file and sitemap. These provide useful launch clues, but each is narrower than a site-wide guarantee.

In particular, robots_txt.disallow_all is a heuristic. It can flag a file containing a wildcard user agent and a rule that disallows only a subpath. Inspect the actual robots file and relevant user-agent groups before declaring the site blocked. Failed optional probes can also return null values, and a false HTTPS result can reflect a failed probe. Mark these as needing verification rather than converting them into definite defects.

Use get_sitemap with domain and limit to inspect the site's current declared URLs. Preserve sitemap_url, source, truncated and child_sitemaps_fetched. The sitemap endpoint walks a bounded set of documents; it is not a full crawl. If truncated is true, absence from the returned rows tells you little about the rest of the sitemap.

Compare returned URLs against your intended canonical destinations. Unexpected old hosts, staging hosts or retired paths are useful findings to investigate. A lastmod value comes from the site's file, not independent proof of when useful content changed. Use the content management system or deployment record for that question.

Private or authenticated staging environments cannot be checked through public RankParse fetches. Perform prelaunch checks using your team's staging access and crawler, then repeat the public checks after deployment. Do not expose a private staging site just to make a research tool reach it.

Worked example: a technically reachable but wrong destination

The following fictional example shows why checking only successful responses is insufficient.

The key finding is the mismatch between the approved mapping and observed destination. Neither a 200 response nor a self-referential canonical on the resource listing makes that mapping correct.

This also explains why the assistant needs your intended outcomes. Without them, it might describe the page as healthy. With them, it can flag a precise discrepancy that an engineer can reproduce.

Turn the mapping into a launch ledger

Use one row per old URL, even when several old URLs share a destination. Preserve the original string before normalizing anything. Case, trailing slashes, query parameters and protocol variants can behave differently on the actual platform.

The core ledger can use this template:

Old URL:
Inventory sources:
Business priority and reason:
Approved outcome:
Expected destination:
Content-equivalence reviewer:
Baseline check time and evidence:
Prelaunch implementation evidence:
Postlaunch observed final URL and target status:
Redirect-chain verification source:
Declared canonical and robots meta:
Rendered-page and conversion checks:
Result: pass / fail / unknown / intentionally retired
Issue owner and ticket:
Retest time and evidence:

These are worksheet columns, not RankParse response fields. Keep that distinction clear when asking an assistant to populate them. A generated “pass” is your team's assessment against agreed criteria, not a tool-provided certification.

For query parameters, distinguish tracking tags from parameters that select meaningful content. Blindly dropping every query string can break filters, language choices or document versions. Decide the expected behavior with the platform owner and test representative examples. Also check links embedded in transactional emails and downloadable PDFs if they point to changed routes.

The second prompt creates the actual verification queue:

Compare the approved mapping with the baseline and available launch
checks. Create a verification queue ordered by business consequence.
For each row, show expected destination, observed evidence, missing
check, owner and pass condition. Treat unknown as distinct from pass.

Flag generic destinations, unexplained content loss, unintended robots
meta and declared canonical mismatches. Redirect chains and Google
selected canonicals require separate evidence. Do not infer them.

Recheck the implementation at launch

After the release, run get_page_seo against both the old URL and intended destination for critical mappings. Check the old request's final_url against the approved destination, then verify the destination's status, title, canonical and robots meta directly. This helps distinguish a routing problem from a destination-template problem.

Check redirect chains with the separate tool or crawl established earlier. Confirm the intended permanent response and look for unnecessary intermediate hops, loops and unexpected host changes. RankParse follows up to five redirects; a fetch failure after excessive redirects is an investigation lead, not a complete description of the chain.

Inspect representative pages from every changed template, plus individually important exceptions. Product pages, localized pages, articles, filtered categories and downloadable files can use different routing or metadata logic. Sampling one article cannot validate all of them.

The third prompt helps summarize a release decision without delegating it:

Summarize the launch ledger for the release owner. List unresolved
blockers first, each with affected URLs, direct evidence and required
retest. Separate verified passes, intentional removals and unknowns.
Do not declare the migration safe based on homepage or sitemap checks.
End with the exact decisions the release owner still needs to make.

Your team decides whether to fix forward or roll back. That choice depends on the severity, scope, operational risk and available recovery path. Define rollback mechanics before launch, because an SEO report cannot reconstruct an overwritten platform configuration.

Monitor coverage and user outcomes after release

Continue targeted public checks after fixes, especially when several templates share a component. A corrected canonical template may solve many pages, but verify representative URLs and the original failed examples before closing the issue.

Use Search Console and your analytics outside the OAuth connector to monitor landing-page trends, indexing information and conversions. Google's selected canonical requires appropriate Google evidence; the HTML canonical returned by RankParse is only the site's declaration. For a domain move, review Google's site move guidance alongside the operational plan.

Keep prelaunch and postlaunch periods comparable, annotate the release and allow for search systems to process changes. Aggregate traffic can hide a problem when one section grows while another loses visibility. Review the priority URL groups and business outcomes that justified the mapping in the first place.

Do not retire the ledger immediately after the homepage looks right. Assign a monitoring owner and a date for reviewing unresolved observations, stale internal links and unexpected old-URL activity. The technical SEO checklist provides broader follow-up checks once the migration-specific risks are under control.

Begin with the pages you would be least willing to lose. Give each one an approved destination, a named owner and direct verification evidence. That small, disciplined record is more useful at launch than a large checklist whose boxes nobody can substantiate.