Post-migration SEO checklist: verify the URLs people actually reach
Check deployed redirects, destination pages, canonicals, internal links, and search evidence after a URL migration. Includes a sample release log and worksheet.
The paths and observations below are fictional examples. A passing redirect map or HTTP check does not prove Google has indexed a destination or that search traffic will recover on a fixed schedule.
Start with the deployed journey
Before launch, a redirect map describes what should happen. After launch, verify what a request actually receives. Keep the approved map, old and new URL inventories, release time, and a record of important entry pages. A correct spreadsheet cannot detect a rule that was omitted from the production configuration.
For a small migration, check every mapped URL. For a larger one, automate the inventory checks and manually review representative templates, high-value pages, unusual rules, and failures. A sample that passes is evidence about that sample, so record what remains untested.
A fictional release with four different outcomes
This example changes paths on one domain. The response chain, final-page inspection, and intended outcome are recorded separately.
| Old path and intent | Observed release behavior | Decision |
|---|---|---|
| /services/search-audit → /services/seo-audit | 301 directly to a 200 page with the expected content and self-canonical | Technical sample passes; check links and later search evidence |
| /blog/move-site → /guides/site-migration | 301 to a 200 page carrying noindex | Remove the unintended destination noindex and verify again |
| /downloads/audit.pdf → /downloads/site-audit.pdf | Old URL returns 404; new PDF exists | Restore the approved redirect for the download |
| /events/2019-workshop; no equivalent replacement | 301 to an unrelated homepage | Review removal intent; use an appropriate 404 or 410 when no replacement exists |
Check responses and page signals together
Follow the chain from each old URL and record the status, Location target, final URL, and final response. For a permanent move, use the intended permanent redirect and point directly to the relevant destination. A 200 response by itself does not establish that the right content arrived: inspect the page heading, main content, and important resources.
For destinations meant to appear in search, check robots accessibility, meta robots and X-Robots-Tag directives, and the canonical in the delivered page. Compare rendered output when scripts can change metadata. A page can return 200 and still carry an accidental noindex or identify an old URL as canonical.
Google advises against redirecting unrelated old pages to the homepage and recommends direct redirects to the final destination. Keep deliberate removals distinct from migration failures. An expected 404 is not the same finding as a valuable moved page whose redirect was forgotten.
Update discovery paths, then inspect Google's view
Update navigation and contextual internal links to the chosen destinations. Check the sitemap and canonical signals for consistency. Keep redirect rules working for old links that you cannot update, including bookmarks and external references. Google recommends retaining redirects for at least a year, and longer where useful for people following old URLs.
Search Console URL Inspection separates the indexed version from a live test. Use the live test to investigate current accessibility and potential indexability, then record the indexed result and selected canonical separately. A successful live test is not proof that the URL is currently indexed or will be shown in search.
If the move changes domains, review Google's property-verification and Change of Address guidance where applicable. A path change on the same domain, like this example, should not be described as a domain transfer.
Monitor mapped page groups instead of one sitewide number
Keep old and new URLs associated in the review. Follow clicks, impressions, indexed-URL evidence, and relevant conversion tracking for the affected page group. Compare the same date windows and filters, and annotate unrelated changes such as a redesign or tracking update. A falling old-URL count can be expected as a replacement takes over; an unchanged property total can also hide a broken important page.
Use checks immediately after release and follow-up reviews appropriate to the site's size and observed issues. Do not promise that Google will process every URL within seven or thirty days. Escalate concrete failures such as looping redirects, unavailable destinations, or unintended indexing blocks instead of waiting for a traffic chart to confirm them.
Close each finding with evidence
For the missing PDF redirect, the release log should identify the old URL, intended destination, observed 404, owner, fix, and a later successful request. For the noindex finding, preserve both the original directive and the corrected response. Mark the technical issue verified while leaving search processing as a separate follow-up.
RankCrab's redirect-map validator checks the files you provide; it does not fetch the deployed URLs. Use it to review the map, then record actual response checks in this worksheet. The downloadable HTML file saves local notes and does not crawl a site or monitor future changes.