FIRST CH TOOLS LOCAL PROCESSING — サーバー送信なし EN

FIRST CH TOOLS / SEO・AI / 48 REDIRECT GENERATOR

リダイレクトルール ジェネレーター

サイトリニューアルや移転でURLが変わるとき、旧URL→新URLの対応表を貼り付けるだけで .htaccess（Apache）・nginx・Netlify の _redirects の301リダイレクトを書き出します。www統一・https統一・末尾スラッシュはプリセットから選べ、旧URLの重複・自分自身へのループ・2段以上の連鎖もその場で指摘します。

1 — 旧URL → 新URL の対応表

2 — 定型の統一ルール

統一ルールは個別の対応表より先に評価される形で書き出します（先にホストとスキームを正しくしてから、パスの入れ替えを1回で済ませるため）。

3 — 出力

.htaccess 

    

      
      
    

  


  

    
0
対応件数

    
0
重複した旧URL

    
0
連鎖

    
0
出力行数

  


  

    
読み取りの結果

    
    
  
    

  
    対応表がブラウザの外へ出ることはありません（解析も生成もこのページの中だけで動いています）。URLパラメータで設定を渡せます: /redirect/?format=nginx&domain=example.com&www=none&https=1&slash=add ／ 対応表ごと渡すなら /redirect/?pairs=/old.html,/new/;/a.html,/b/（; で行・, で列を区切る）
    

  
    
    
    How to Use
    
    
      
      
    1. 対応表を貼る旧URLと新URLの2列を、スプレッドシートからそのままコピーして貼り付けます。クローラーの一覧やサイトマップから旧URLを書き出しておくと漏れません。
      2. 
      
    2. 統一ルールを選ぶwww の有無・HTTPS・末尾スラッシュをどちらへ寄せるかを決めます。サイト全体の移転は「ドメイン」を入れて選ぶだけで、個別の対応表より先に評価される形で書き出されます。
      3. 
      
    3. サーバーへ置くApache は .htaccess を公開ディレクトリ直下へ、nginx は nginx -t で構文を確かめてから reload、Netlify / Cloudflare Pages は _redirects を公開ディレクトリへ入れてデプロイします。
      4. 
    
    
  
    

  
    
    
    About This Tool
    
    
    リニューアルで一番損をするのは、リダイレクトの取りこぼしです。URLが変わったのに旧URLがそのまま404になると、検索結果からの流入も、他サイトに貼られたリンクの評価も、ブックマークからの再訪もその場で切れます。301（恒久的な移転）で新しいURLへ繋いでおけば、検索エンジンは索引を張り替え、リンクの評価もおおむね引き継がれます。公開の当日に効いている必要があるので、対応表は実装と並行して作るのが実務です。
    
    
    同じ対応表から3つの書式を出します。Apache（.htaccess の mod_rewrite）・nginx（location か map）・Netlify / Cloudflare Pages（_redirects）は書き方がまったく違うのに、書きたいことは同じです。どのサーバーへ載せるかが決まっていない段階でも対応表だけ作っておけば、切り替えはタブ1つで済みます。クエリ文字列（?id=42）つきの旧URLも、それぞれの書式の作法（Apache は RewriteCond %{QUERY_STRING}、nginx は $request_uri の map、Netlify はパスの後ろに条件）で書き分けます。
    
    
    貼り付けた表の事故をその場で見つけます。同じ旧URLが2回出てくる（後の行は効きません）、旧URLと新URLが同じ（無限ループになります）、A→B と B→C が両方ある（1回で着くよう A→C に直すべきです）、先頭の / が無い、空白や日本語が未エンコードのまま——このあたりは数十件を手で書いていると必ず混ざります。「読み取りの結果」に件数つきで出します。
    
    
    できたルールは、公開後に Search Console のカバレッジと「クロールの統計情報」で、旧URLが301として扱われているかを確認してください。あわせてクロールの許可設定は robots.txt ジェネレーター、AI向けの案内は llms.txt ジェネレーター、URLのパラメータ整理は URLパラメータ分解・UTMタグ編集 が使えます。
    
  
    

  
    
    
    リダイレクトの落とし穴
    
    
    
      
    
        
    トップページへまとめて飛ばさない
    
        
    RewriteRule ^(.*)$ / [R=301,L]     ← 全部トップへ（事実上の404扱い）
    
        
    対応表を作るのが面倒で、旧URLを全部トップページへ飛ばす設定を見かけます。Googleはこれを「ソフト404」として扱い、評価は引き継がれません。訪問者にとっても、読みたかった記事の代わりにトップが出るだけで用は足りません。内容の近いページへ1対1で繋ぐのが原則で、対応先が本当に無いページは素直に404（または410）にします。
    
      
    
      
    
        
    連鎖させると遅くなり、評価も目減りする
    
        
    /old.html → /new.html → /new/ → https://example.com/new/   ← 4回の往復
    
        
    「http→https」「www有→無」「旧パス→新パス」「スラッシュ付与」を別々に書くと、1回のアクセスで何度も往復が起きます。モバイル回線では往復1回ごとに体感が落ち、Googleも長い連鎖の途中で追跡をやめることがあります。このツールがホスト・スキームの統一を個別ルールより先に置いているのはこのためで、対応表側の新URLは最初から最終形（https・www有無・スラッシュまで正しい形）で書くのが理想です。
    
      
    
      
    
        
    301はブラウザに強くキャッシュされる
    
        
    301 Moved Permanently   ← ブラウザが記憶する。間違えると自分では戻せない
302 Found               ← 試すときはこちら
    
        
    301を受け取ったブラウザは、次からサーバーへ問い合わせずに新URLへ行きます。設定を間違えたまま公開すると、直した後も訪問者の手元では古い転送が生き続けます（キャッシュを消してもらうしかありません）。本番で不安が残るうちは302で様子を見て、確信が持ててから301へ切り替えると安全です。
    
      
    
      
    
        
    .htaccess は1行ずつ、毎回読まれる
    
        
    RewriteRule ^a/1$ /x/ [R=301,L]
RewriteRule ^a/2$ /x/ [R=301,L]
…（数百行）
    
        
    .htaccess はリクエストのたびに読み直され、ルールは上から順に評価されます。数百件を超えると無視できない負荷になるので、件数が多いときは nginx の map（ハッシュで一発で引く）か、アプリ側のリダイレクト表に持たせることを検討してください。よく使われるURLを上の方に置くだけでも効きます。
    
      
    
      
    
        
    末尾スラッシュの有無は別のURLとして扱われる
    
        
    /about   と  /about/    ← 検索エンジンには別ページに見える
    
        
    どちらでも同じ内容が出る状態は、内容の重複として扱われます。どちらかに寄せて、もう一方は301で寄せた側へ飛ばすのが基本です。ただし /index.html のような実在ファイルへスラッシュを付けると壊れるため、このツールの「付ける」はファイル（Apache は実在判定、nginx は拡張子の有無）を除外しています。
    
      
    
      
    
        
    クエリ文字列はパスと別物
    
        
    RewriteRule ^old\.php$ /new/ [R=301,L]        ← ?id=42 の判定は入っていない
RewriteCond %{QUERY_STRING} ^id=42$           ← こう書いて初めて効く
    
        
    古いCMSの /index.php?p=123 のようなURLは、パスだけを見る書き方では区別できません。Apache は RewriteCond %{QUERY_STRING}、nginx は $request_uri（クエリを含む）を使う必要があります。また転送先に元のクエリが勝手に付いて回るため、Apache では QSD フラグで落とします——このツールは対応表にクエリが含まれていれば自動でその形にします。
    
      
    
      
    
        
    旧ドメインは1年では捨てられない
    
        
    https://old-company.co.jp/*  →  https://new-company.co.jp/:splat
    
        
    ドメイン移転では、旧ドメインの契約とSSL証明書を最低1年、できれば数年維持して301を出し続けます。名刺・印刷物・他社サイトのリンクは何年も残るためです。Search Console の「アドレス変更」ツールも忘れずに使ってください（301だけより移行が速くなります）。
    
      
    
      
    
        
    リダイレクトはサイト内のリンクを直さない言い訳にならない
    
        
    <a href="/company/about.html">   ← 自分のサイトの中から古いURLを指したまま
    
        
    301を張れば動きはしますが、内部リンクが古いままだと訪問者は毎回1往復余計にすることになります。リダイレクトは外部からの流入とブックマークのための救済措置で、自サイト内のリンク・サイトマップ・構造化データ・広告のリンク先は新URLへ書き換えるのが本筋です。
    
      
    
    
    
  
    

  
    
    
    Other Tools