SEO

Redirect map QA pass

Use when a redirect map has been drafted and you need it checked before it goes live.

redirect-map-qa-pass.md

Download .md

You are QA-ing a proposed redirect map before it ships. You are not building the map.

Redirect map (old URL, destination, status code): {{REDIRECT_MAP}}
Old URLs ranked by traffic, links or revenue: {{VALUABLE_URLS}}
Live URLs on the new site: {{NEW_SITE_URLS}}
Pattern rules being applied: {{RULE_SET}}

Output one table covering every row in {{REDIRECT_MAP}}: Old URL | Destination | Verdict (Correct / Loose match / Wrong intent / Chain / Loop / Destination not on new site / Wrong status code) | Evidence | Fix.

Then four sections:
- "Unmapped and valuable" - anything in {{VALUABLE_URLS}} with no row in the map, ordered by value.
- "Rules that overreach" - patterns in {{RULE_SET}} that catch URLs they were never meant to, with one example each.
- "Redirects to the homepage" - the count, and which of them deserve a real destination.
- "Cannot verify" - the checks that need the live server rather than this data.

Constraints:
- A redirect that resolves but lands on a page answering a different question is Wrong intent, not Correct.
- Treat any destination absent from {{NEW_SITE_URLS}} as unverified. Do not assume it exists.
- Flag every 302, meta refresh and JavaScript redirect on a permanent move.
- Do not add a closing summary. The table and the four sections are the whole output.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{REDIRECT_MAP}}
{{VALUABLE_URLS}}
{{NEW_SITE_URLS}}
{{RULE_SET}}

Getting a better result

Feed it the map in batches by directory so the wrong intent verdicts stay reviewable.
Sort the valuable URL list by referring domains as well as traffic, since links are what you lose permanently.
Re-run the pass on the live server after launch, because the deployed rules rarely match the spreadsheet.

Questions about this prompt

When do I use this instead of the migration checklist?

The migration plan covers the whole move; this reads one artefact, the drafted map, before it ships. Use it in the gap between the map being written and code freeze. Crawling redirects after launch finds the same faults, but by then the rankings and the links have already gone.

What do I need alongside the map?

The old URLs ranked by traffic, referring domains and revenue, the live URL list for the new site, and the pattern rules being applied. Without the new site URL list every destination is unverified, and without the valuable URL list the pass cannot tell you what nobody mapped. Feed it in batches by directory.

What comes back?

A verdict on every row, then four sections. The rows marked correct tell you nothing; the value sits in unmapped and valuable, and in rules that overreach, where a pattern quietly catches URLs it was never meant to. The homepage redirect count is the third thing worth reading closely.

What is the mistake that costs me here?

Accepting resolves with a 301 as correct. A redirect that lands on a page answering a different question is marked wrong intent here, and it passes every automated check while losing the ranking anyway. The other one is signing off the spreadsheet and never re-running the pass against the live server.