FIRST CH TOOLS LOCAL PROCESSING — NOTHING LEAVES YOUR DEVICE 日本語

FIRST CH TOOLS / SEO & AI / 48 REDIRECT GENERATOR

Redirect Rule Generator

When a redesign or a move changes your URLs, paste the old → new table and get 301 redirects for .htaccess (Apache), nginx and the Netlify _redirects file. Canonical www, HTTPS and trailing slashes come from presets, and duplicated source URLs, self-referencing loops and two-hop chains are flagged as you paste.

1 — Old URL → new URL

2 — Site-wide presets

The presets are written above the per-URL rules, so the host and scheme are corrected first and the path swap costs a single hop.

3 — Output

.htaccess 

    

      
      
    

  


  

    
0
Rules

    
0
Duplicate sources

    
0
Chains

    
0
Output lines

  


  

    
What was read

    
    
  
    

  
    The table never leaves your browser — parsing and generation both run on this page. Settings can be passed in the URL: /en/redirect/?format=nginx&domain=example.com&www=none&https=1&slash=add  /  with the table itself: /en/redirect/?pairs=/old.html,/new/;/a.html,/b/ (; separates rows, , separates columns).
    

  
    
    
    How to Use
    
    
      
      
    1. Paste the tableCopy the two columns of old and new URLs from your spreadsheet. Exporting the old URLs from a crawl or the old sitemap first is the reliable way to avoid gaps.
      2. 
      
    2. Pick the presetsDecide where www, HTTPS and trailing slashes should land. For a whole-site move, fill in the domain and the host rules are written above the per-URL rules.
      3. 
      
    3. Put it on the serverApache: drop .htaccess in the document root. nginx: check with nginx -t, then reload. Netlify / Cloudflare Pages: put _redirects in the publish directory and deploy.
      4. 
    
    
  
    

  
    
    
    About This Tool
    
    
    The most expensive part of a relaunch is the redirects nobody wrote. If the URLs change and the old ones start returning 404, search traffic, the value of links other sites have pointed at you, and everybody's bookmarks stop working on the same day. A 301 tells search engines the page moved for good: the index is rewritten and most of the link equity follows. Because it has to be live on launch day, the mapping table is built alongside the build, not after it.
    
    
    One table, three syntaxes. Apache (mod_rewrite in .htaccess), nginx (location or a map) and Netlify / Cloudflare Pages (_redirects) say the same thing in entirely different ways. Build the table before the hosting decision is final and switching is one tab. Old URLs with a query string (?id=42) are handled in each syntax's own idiom: RewriteCond %{QUERY_STRING} for Apache, a $request_uri map for nginx, and conditions after the path for Netlify.
    
    
    The mistakes in a hand-written table are caught as you paste. The same source URL twice (only the first rule runs), a URL pointing at itself (an infinite loop), A→B and B→C both present (it should be A→C), a missing leading /, spaces or non-ASCII characters left unencoded — all of them appear, with counts, under “What was read”.
    
    
    After launch, check in Search Console that the old URLs are reported as 301. For crawl permissions see the robots.txt generator, for AI guidance the llms.txt generator, and for tidying query strings the URL parameter editor.
    
  
    

  
    
    
    Redirect pitfalls
    
    
    
      
    
        
    Do not send everything to the home page
    
        
    RewriteRule ^(.*)$ / [R=301,L]     ← everything to the top (treated as a 404)
    
        
    Pointing every old URL at the home page to avoid writing a table is treated by Google as a soft 404, and no ranking is carried over. It does not help visitors either: they wanted an article and got the front door. Map one old URL to the closest matching new page, and let the pages with no successor return an honest 404 (or 410).
    
      
    
      
    
        
    Chains cost speed and equity
    
        
    /old.html → /new.html → /new/ → https://example.com/new/   ← four round trips
    
        
    Writing “http to https”, “www to no-www”, “old path to new path” and “add the slash” as separate rules makes one request bounce several times. On mobile every hop is felt, and Google may stop following a long chain. That is why the host and scheme rules are placed above the per-URL rules here — and why the new URLs in your table should already be in their final form (right scheme, right host, right slash).
    
      
    
      
    
        
    Browsers cache a 301 hard
    
        
    301 Moved Permanently   ← remembered by the browser; you cannot undo it remotely
302 Found               ← use this while testing
    
        
    Once a browser has seen a 301 it goes straight to the new URL without asking the server. Ship a wrong rule and it keeps running on your visitors' machines after you fix it (only clearing their cache helps). While you are unsure, test with a 302 and switch to 301 once the mapping is confirmed.
    
      
    
      
    
        
    .htaccess is read line by line, on every request
    
        
    RewriteRule ^a/1$ /x/ [R=301,L]
RewriteRule ^a/2$ /x/ [R=301,L]
… (hundreds of lines)
    
        
    .htaccess is re-read on every request and the rules are evaluated top to bottom. Past a few hundred entries that becomes real load: use an nginx map (a single hash lookup) or a redirect table inside the application. Even just moving the busiest URLs to the top helps.
    
      
    
      
    
        
    With and without the trailing slash are different URLs
    
        
    /about   and  /about/    ← two pages as far as a crawler is concerned
    
        
    Serving the same content at both looks like duplication. Pick one and 301 the other to it. Adding a slash to a real file such as /index.html breaks it, so the “add” preset excludes files (Apache tests whether the file exists; nginx checks for an extension).
    
      
    
      
    
        
    A query string is not part of the path
    
        
    RewriteRule ^old\.php$ /new/ [R=301,L]        ← nothing here looks at ?id=42
RewriteCond %{QUERY_STRING} ^id=42$           ← this is what makes it work
    
        
    Legacy CMS URLs like /index.php?p=123 cannot be told apart by a path-only rule. Apache needs RewriteCond %{QUERY_STRING}; nginx needs $request_uri, which includes the query. The original query is also appended to the target unless you drop it — Apache does that with the QSD flag, which this tool adds automatically whenever a row carries a query.
    
      
    
      
    
        
    You cannot drop the old domain after a year
    
        
    https://old-company.com/*  →  https://new-company.com/:splat
    
        
    After a domain move, keep the old registration and its TLS certificate alive for at least a year, preferably several, and keep serving the 301s: business cards, print and other people's links outlive any migration plan. Use the Change of Address tool in Search Console as well — it moves things along faster than the 301s alone.
    
      
    
      
    
        
    Redirects are not an excuse to leave internal links broken
    
        
    <a href="/company/about.html">   ← your own site still points at the old URL
    
        
    It works, but every visitor pays an extra round trip. Redirects are a safety net for inbound links and bookmarks; your own navigation, sitemap, structured data and ad destinations should be rewritten to the new URLs.
    
      
    
    
    
  
    

  
    
    
    Other Tools