Answers

Did a redirect or URL change lose us rankings?

Get the before list, whatever it takes#

You cannot audit redirects without knowing which URLs existed before the change. If nobody exported them, reconstruct from these in order of reliability:

Search Console performance data for the period before the change, your old XML sitemap if it's in version control, server logs, an archived crawl, or Wayback Machine as a last resort.

Reconstruct it even if it's incomplete. A partial before-list finds most of the problem, and no list finds none of it.

Crawl the old URLs and classify what you find#

Run every pre-change URL through a crawler and record the final destination and status code. Then sort into these buckets:

The second row is the most common and the most damaging. Bulk-redirecting everything to the homepage is a decision that feels tidy and destroys the specific relevance every one of those pages had earned.

Match the failures against what you actually lost#

An audit that lists 400 broken redirects is overwhelming and unprioritised. Cross-reference against traffic to make it tractable.

Pull clicks per URL for the 90 days before the change, join to your redirect audit, and sort the failures by clicks lost. The pages that mattered surface immediately, and they're usually a small fraction of the broken list.

This also tells you whether redirects are the cause at all. If your highest-traffic old URLs all redirect correctly and traffic still fell, look elsewhere. See Did a site deployment cause our search drop?.

Fix in this order#

1. Redirect loops. The page is completely unreachable. Fix first.

2. High-traffic 404s. Every day these stay broken is compounding loss.

3. Redirects to the wrong destination. Point each to its genuine equivalent, not to a parent category.

4. Chains. Collapse to a single hop from original to final.

5. Wrong status codes. Convert 302 and 307 to 301 where the move is permanent.

Then update your internal links to point at the final URLs directly. Redirects should exist for external links and crawler memory, not as permanent internal plumbing.

Finally, submit the new sitemap and request indexing on the highest-value pages to accelerate re-processing.

How long recovery takes, and when it isn't coming#

Correctly implemented 301s usually restore most of the ranking within two to eight weeks once recrawled, faster on frequently crawled sites.

Two situations don't recover. If the new page's content differs substantially from the old one, you're not restoring a ranking, you're asking for a new one on different content. And if a competitor filled the position during the outage and improved their page while you were down, you're competing again rather than reclaiming.

Set expectations on that before anyone promises a recovery date. See How long should I wait before deciding an SEO change failed?.

The signal you'll lose without noticing#

URL changes also break AI-surface citations, and that loss is invisible in Search Console.

Our own state of AI search research, covering more than 22,000 answers and 115,000 citation events, found presence is path-dependent: once a brand is mentioned for a prompt, next-observation mention probability is 83.2% on ChatGPT, 83.3% on Perplexity, and 84.2% on Google AI Mode, against roughly 10% after a miss.

A cited URL that starts returning a 404 or redirecting to a category page can drop out of that citation set, and re-earning the position takes considerably longer than restoring a ranking. Google's documentation on AI features notes the same crawlability requirements govern AI surfaces, so a broken redirect removes you from both at once. Check your most-cited URLs specifically during any migration, because they may not overlap with your highest-traffic ones.

Audit it as a workflow#

The manual version is a crawl, an export, a join, and a prioritisation pass. Doing it once during a migration is normal. Doing it again three weeks later to verify the fixes is where it usually gets dropped.

Fetch URL handles the crawl of the old list. GSC Page Performance Summary and Indexing Status supply the traffic join and the crawler's own view. Citation Watched Pages covers the layer Search Console can't see.

A migration-audit agent, re-runnable after each fix round:

Start (manual, or webhook on deploy) → Loop / For Each over the pre-change URL list → Fetch URL per URL (record final destination, status code, hop count) → GSC Page Performance Summary (clicks per old URL, 90 days pre-change) → GSC Indexing Status → Citation Watched Pages (which old URLs were cited by AI surfaces) → Code (classify each URL into the seven buckets, sort failures by clicks lost, flag any cited URL that now 404s) → Prompt LLM (produce a prioritised fix list with the failure type named per URL) → Excel export → Send Email to engineering and SEO.

The cited-URL flag is the part most migration audits lack entirely. A URL with modest search traffic that AI surfaces cite regularly is worth more than its click count suggests, and it would sit near the bottom of a traffic-sorted fix list without it.

Re-run the same agent after each fix round and the Excel export gives you a dated record of what was broken and what got resolved.

FAQ#

Related answers#

• Did a site deployment cause our search drop?
• My traffic dropped 40% overnight — how do I figure out what caused it?
• Is this page underperforming because of content or because it isn't indexed?
• When should I rewrite, merge, redirect, or retire an underperforming page?