Redirect Rule Generator — Export Server Rules

Most migration post-mortems mention content or design. The quiet killer is redirects: a missing 301, a chain left over from three platform changes, or two conflicting rules fighting for the same old path. This guide is about planning the URL map and writing rules for the stack you run — Apache, Nginx, Cloudflare, Vercel, Next.js, or Netlify. When you already have a spreadsheet of old and new URLs and need deployable syntax with chain checks, use the Redirect Rule Generator . It runs in the browser and flags loops before you paste into production. Start with the URL map, not the config file A redirect map is two columns: every old URL that still matters, and exactly one destination that should replace it. "Matters" means organic traffic, backlinks, ads, email links, or internal links from pages you are keeping. Build the list from more than one source. Export Search Console landing pages, crawl your old sitemap, pull top paths from analytics, and ask client stakeholders for printed URLs. Merge and dedupe. Sort by importance so you fix high-value rows first when something is wrong. Each row should be one hop in the final world: old path → new path. If your spreadsheet already has A→B and B→C because teams added rules incrementally, compose those mentally to A→C before you write server config. Chains add latency and dilute the signal passed to the destination. Google’s site-move documentation assumes you consolidate to direct redirects where possible. Avoid the homepage dump. Sending thousands of product URLs to the homepage path looks like a soft 404 to users and a weak relevance signal to search engines. Map like for like when content survives; use a sensible category hub when a section merges; use 410 or removal when content is truly gone. Choose the status…