Redirect remediation — high-level pointers (local fallback)

abra’s validation tells you what is wrong with a redirect — the loop, the extra hop, the wrong code, the dead end. The detailed, current fix procedures — server/CDN config, .htaccess vs Nginx vs _redirects syntax, migration mapping conventions — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• Redirect loop — two rules (or a rule + a canonical/trailing-slash normaliser) send URLs back at each other. Find the pair and make one authoritative; test the exact URL before re-deploying.
• Over-long chain — collapse the intermediate hops so each old URL 301s once, straight to the final destination (each hop costs latency and bleeds link equity).
• 302/307 where a 301 belongs — switch temporary codes to a permanent 301/308 when the move is permanent, so search engines pass ranking and stop re-checking the old URL.
• https→http downgrade — a redirect drops the request to plain http; force the target to https and make HSTS/upgrade rules consistent across the chain.
• Dead end (4xx/5xx) — the old URL lands on an error; point it at the correct live page, or 410 it deliberately if the content is gone for good.
• Meta-refresh / JS redirect — replace client-side redirects with a real server 301; they’re slow and largely invisible to crawlers.

Full playbook → the team wiki’s redirect & migration reference (server config, mapping conventions, agent-safety notes, per-finding procedures). Configure the wiki to have abra surface the live versions in its report.