Review the map.
Then test the road.

A redirect spreadsheet is a plan. A successful browser request is evidence that the deployed rule works. You need both before signing off a migration.

1. Start with explicit destinations

Use a CSV with exactly two columns, source and target. Enter full HTTP(S) URLs, or use paths with the correct base origin. Keep path capitalization and query parameters intact. They can identify different resources.

source,target
/old-services,/services
/old-contact,/contact

2. Separate loops from chains

A chain such as /old → /middle → /new reaches a destination, but adds a hop. Review whether /old can point directly to /new. A loop such as /a → /b → /a never reaches a final destination in the map. Fix the cycle before deployment.

3. Resolve conflicting rules

If /contact points to both /hello and /support, a spreadsheet cannot tell which server rule will win. Choose the intended destination. Two old pages pointing to one new page can be intentional; check that the merged content answers both visitors’ needs.

4. Hand off a reviewable report

Run the checker, review blockers first, then warnings and intentional merges. Print a report or download JSON. Record numbers include the header; a quoted multiline field is still one CSV record. Recheck the final map after edits.

5. Verify after deployment

Test the actual responses, final destinations, content, canonical URLs and internal links. This tool does not make network requests to mapped URLs, crawl a site, or evaluate regex and server-rule precedence. It does not promise preserved rankings.

Follow Google’s site-move documentation for the broader migration process. A tool such as httpstatus.io can help inspect live responses. These are independent resources, not endorsements.