Redirection完全ガイド！使い方、初期・詳細設定、トラブル対応など徹底解説！【WordPress】

2025年9月2日

Webサイト運営をしていると、URLの変更やリンク切れ、ドメイン移行などで突然リダイレクト対応が必要になる場面が出てきます。

そんなとき、次のような悩みや疑問を抱えていませんか？

「記事のURLを変えたらアクセスが減った。正しくリダイレクトすれば元に戻るの？」
「301と302の違いって結局どう使い分ければいいの？」
「404がたくさん出ているけど、どれから直せばいいかわからない……」
「プラグインで設定したはずが動かない。サーバー側の設定とどう住み分けすれば良い？」
「大量のルールを一括で移行したいが、失敗してサイトを壊すのが怖い」

本記事は、こうした現場でよくある疑問に答えつつ、Redirectionプラグインを使った基本操作から正規表現やCSVによる一括運用、ログ・404監視、トラブルシューティングにいたるまで、初心者でも再現可能な手順で丁寧に解説します。

まずは「何を・いつ・どう設定すればいいか」がサッとわかるように構成していますので、必要な箇所をピンポイントで読み進めてください。

この記事を読むと、次のことができるようになります：適切なHTTPステータスの選び方（301/302/410）、転送ルールの作り方とテスト方法、404の優先対応、CSVでの一括インポート・バックアップ、そして問題発生時の切り分け手順。

初心者の方はまず「導入と初期設定」→「ルールの作成とテスト」→「運用・監視」の順で読み進めるのがおすすめです。

概要と基本概念

Redirection プラグインは、WordPressサイト上でURLの転送（リダイレクト）を簡単に作成・管理できるツールです。

本セクションではまずリダイレクトそのものの役割と仕組みを整理し、そのうえで代表的なHTTPステータスである 301（永続） と 302（一時） の違いとSEOへの影響をわかりやすく説明します。

リダイレクトとは何か（役割と仕組み）

リダイレクト は「あるURLに来たリクエストを別のURLへ自動的に転送する仕組み」です。

Webサイト運用でよく出てくる用途は次のとおりです。

ページURLを変更したとき（古いURL → 新しいURL）
コンテンツを別ページへ統合したとき（複数の古い記事を1つにまとめる）
ドメイン移行をしたとき（旧ドメイン → 新ドメイン）
期間限定のキャンペーンなどで一時的に別ページへ誘導するとき

仕組み

ユーザー（または検索エンジン）が古いURLへアクセスする。
サーバーが「このリクエストは別の場所へ行ってください」と返す（HTTPレスポンスで転送先と転送の種類を通知）。
ブラウザは転送先に自動で移動する。

補足（Redirectionプラグインでの役割）

ブラウザとサーバー間の「どのURLをどこへ渡すか」を管理画面から簡単に設定できる。
404エラーの監視や転送のログ記録、一括インポート/エクスポートなど運用に便利な機能を備えていることが多いです。

ポイント：リダイレクトは単なる「訪問者の誘導」だけでなく、検索エンジンの評価（インデックスやリンク評価）にも影響するため、用途に応じた正しい種類を使うことが重要です。

永続（301）と一時（302）の違いとSEOへの影響

リダイレクトには主に 301（Moved Permanently） と 302（Found / Moved Temporarily） の2種類があり、意味合いとSEOへの影響が異なります。

下の表で違いを整理します。

スクロールできます

種類	意味（HTTP）	主な用途	検索エンジン（SEO）への主な扱い
`301`	永続的に移動した	URLを恒久的に変更するとき（例：記事URL変更、ドメイン移行）	一般に評価（被リンクの価値など）を新URLへ引き継ぐことが期待される。検索エンジンは旧URLをインデックスから置き換える傾向がある。
`302`	一時的に移動した	一時的なキャンペーン、メンテナンス、A/Bテストなど	一時的な措置として扱われ、検索エンジンは旧URLを残す可能性がある。評価を恒久的に移さない挙動が想定される。

こんなときにリダイレクトが必要か（活用ケース）

Redirectionプラグインを使うべき典型的な場面を、目的・設定のポイント・注意点を中心に初心者向けに整理します。

各ケースごとに「設定で何を選ぶか」「運用時のチェック項目」を具体例とともに示します。

ページURLを変更する場合

目的
既存ページのパーマリンクを変えるとき（記事名の変更や分類の見直しなど）、古いURLへ来たユーザーや検索エンジンを新しいURLへ送りたいときに使います。

設定のポイント

推奨ステータス：301（恒久移転） — 検索評価を新URLへ移したい場合。
Redirectionでの手順：新規追加 → ソースURL（旧）を入力 → ターゲットURL（新）を入力 → ステータスを301にして保存。

運用チェック

サイト内の内部リンクとサイトマップを新URLに更新する。
リダイレクト後に404が増えていないかログを確認する。
実際にブラウザで古いURLにアクセスして転送されるかをテストする。 ✅

実例

ソース：/old-article → ターゲット：/new-article-title（301）

ドメインを移転する場合

目的
サイト全体を別ドメインに移す（例：example-old.com → example-new.com）ときのトラフィック維持・SEO保全。

設定のポイント

推奨ステータス：301（恒久移転） をサイト全体に対して設定する（A → B の全ページが1対1で移行するのが理想）。
Redirectionでは個別ルールを大量に作るか、サーバー側でドメイン単位のリダイレクト（可能なら.htaccessやサーバー設定）を併用する。
パス構成が同じなら ^/(.*) → https://new.example.com/$1 のような正規表現ルールが便利。

運用チェック

SSL（https）とDNSが新ドメインで正しく設定されているか。
Search Consoleや類似ツールでドメイン移転通知やインデックス状況を監視する。
旧ドメインの重要ページが正しく新ドメインへ飛ぶかランダムにチェック。 🔁

注意点

ドメイン移行は影響が大きいので、短期的にトラフィックや順位が変動する可能性があることを認識する。

一時的な転送が必要なケース（キャンペーン等）

目的
期間限定のキャンペーンやメンテナンス時に、訪問者を一時的に別ページへ誘導したいとき。

設定のポイント

推奨ステータス：302（一時転送） — 元のURLの評価を維持したい場合に適する。
Redirectionでルールを作成したら、いつ戻すか（終了日） を運用上で決めておく。プラグイン自体に期限機能が無ければカレンダーで管理する。 📅

運用チェック

キャンペーン終了後にリダイレクトを削除または停止する。
SEOの誤解を避けるため、キャンペーン用のページは内部リンクやメタ情報で明確に一時性を示す。

実例

期間：7/1〜7/10 → /sale を一時的に /coming-soon に302で転送

注意点

長期間にわたる「一時的」設定は検索エンジンに誤解されることがあるため、運用は短期向けに限定するのが無難です。

コンテンツを大幅に差し替えたとき・削除したとき

目的
記事の内容を完全に差し替えた、あるいはページを削除したが訪問者に近い代替情報を提供したい場合。

設定のポイント

差し替え（別ページへ誘導）：関連性の高いページがあれば 301 またはコンテキストに応じて 302 を検討。
完全削除（恒久的に存在しない場合）：単に別ページへ無理にリダイレクトするより、HTTP 410（Gone） を検討する（RedirectionではHTTPコードの選択で対応可）。410は「恒久的に削除」を明示するため、検索エンジン側でインデックスの削除が早まることがある。

運用チェック

関連ページへリダイレクトする場合は、ユーザーの期待に沿うか（関連性が低いと離脱率が上がる）。
大量削除する際は、404/410ログをチェックし、不要なリダイレクトが発生していないか確認する。
削除理由を社内で記録しておき、将来の復帰時に対応しやすくする。

実例

記事を統合した場合：旧記事群 → 新まとめ記事（301）
明確に削除する場合：旧URLに410を返してインデックス削除を促す

ケース別の簡単早見表

スクロールできます

ケース	推奨HTTPステータス	Redirectionでの実装のコツ
URL恒久変更（記事移転）	301	個別に作るか、同一構造なら正規表現でまとめて設定
ドメイン移行	301（全体）	パスを保持する正規表現（`$1`）で一括設定＋サーバー設定併用
キャンペーン・メンテナンス（短期）	302	終了日を決めて運用管理、終了後に削除
ページ削除（恒久）	410 または 301（関連ページへ誘導）	410はインデックス削除を早める。誘導は関連性重視

最後に：運用のためのチェックリスト

目的を明確にする（恒久か一時か）
適切なHTTPステータスを選ぶ（301/302/410）
内部リンク・サイトマップを必要に応じて更新する
リダイレクト後にブラウザやログで動作確認を行う
リダイレクトチェーンを作らない（可能な限り直リンクにする）
一括変更はCSVや正規表現で安全に（テスト用環境で確認すると安心）

Redirectionプラグインの導入と初期準備

RedirectionはWordPressでリダイレクトを直感的に管理できるプラグインです。

ここではインストール方法→初回セットアップ→管理画面の見方を順に丁寧に説明します。

初めて使う人でも迷わないように、具体的な手順・設定上の注意点・実務で役立つチェックリストを付けています。⚙️

プラグインの導入方法（管理画面／公式サイトから）

導入前の準備（必ずやること）

バックアップを取る（ファイルとデータベース）。
使用中のWordPressバージョンとPHP要件を確認する。
可能ならステージング環境で先にテストすることを推奨。

方法A：WordPress管理画面からインストール（初心者向け）

管理画面のメニューで「プラグイン」→「新規追加」を開く。
検索ボックスに Redirection と入力して検索。
一覧から該当プラグインを見つけて「今すぐインストール」→「有効化」をクリック。
有効化後、「ツール」またはプラグインメニューに Redirection の項目が表示されます。

方法B：公式サイトからダウンロードして手動アップロード

プラグインのzipをダウンロード（公式配布ページ等）。
管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」→ zip をアップロードして有効化。
アップロード後に表示される導線に従ってセットアップを開始する。

導入時の補足ポイント

プラグインを有効化したら、まずプラグインのページで「互換性」や「最近の更新日」をチェックすると安全性がわかります。
大量ルールを入れる予定がある場合は、インポート／エクスポート機能があるか確認しておくと安心。

初回セットアップの流れ（セットアップウィザード／REST API確認など）

セットアップのゴール：ログ収集や基本ルールを問題なく動かせる状態にすること。

セットアップウィザード（一般的な流れ）

Welcome画面 — 機能の概要や注意点が表示されます。
基本設定のオン／オフ選択
- 404モニタリング（オン推奨）
- リダイレクトログの記録（必要に応じてオン）
- 自動検出（プラグインが内部リンク変更を検出する機能）
REST APIの動作確認
- ウィザード内で「REST APIが動作しているか」をチェックするテストがあることが多いです。
- REST APIはプラグインがサイト内部のイベント（投稿移動など）を検知・自動処理するために使います。不具合があると自動検出や一部の機能が動かない場合があるため、必ず通す。
初期データの移行（任意）
- 既存の.htaccessベースのリダイレクトや他プラグインからのインポートを促されることがあります。必要に応じて実施。
完了画面 — 設定結果のサマリと管理画面へのリンクが表示されます。

REST API確認の具体的チェック

管理画面で「REST APIが利用可能です」と表示されればOK。
もしエラーが出る場合は：
- セキュリティプラグインがREST APIをブロックしていないか（例：特定のエンドポイントを遮断）を確認。
- .htaccess やサーバーのリライトルールで /wp-json/ がアクセス可能か確認。
注意：REST APIを無効にしていると自動検出や一部の統合機能が制限されます。必要に応じて管理者と相談して有効化しましょう。

初回設定での推奨値（一例）

404モニター：オン（サイトのリンク切れを早期発見）
ログ保持期間：運用次第だが短〜中期間（例：30〜90日）で運用し不要なら短縮する
自動検出（URL変更検出）：オン推奨（ただし誤検知の監視は必須）

管理画面の構成（転送一覧・グループ・ログ・404・インポート／エクスポート・設定）

管理画面は主にタブ（またはサイドメニュー）に分かれています。

下表で各エリアの目的と実務での使い方をまとめます。

スクロールできます

管理画面エリア	用途	初心者が最初にやること
転送一覧（Redirects / Redirections）	設定済みの転送ルールの一覧表示・新規追加・編集・停止・削除	新規ルールを1つ作って動作確認（例：`/old-page` → `/new-page`）
グループ（Groups）	ルールのカテゴリ分け（例：ドメイン移行用／キャンペーン用）	運用に合わせて1〜2個のグループを作る（例：`default`, `campaign`）
ログ（Logs）	実際に発生したリダイレクトや404の履歴を確認	まずはログが記録されているか確認し、不要なら保存期間を設定
404（404 Errors）	サイト上で検出されたリンク切れ一覧	重要な404を優先的に確認して、代替ページへリダイレクトするか修正する
インポート／エクスポート	CSVなどで一括登録・バックアップ	小規模テストのあとCSVでエクスポートしてバックアップを取る
設定（Options）	プラグイン全体の挙動（ログ保持、パフォーマンス、正規表現の有効化等）	ログ保存期間・REST API設定を確認、必要なら調整

転送ルールの主要入力項目（画面で見るもの）

Source（ソースURL）：転送元のパス（例：/old-article）
Target（ターゲットURL）：転送先のフルURLまたはパス（例：/new-article または https://example.com/new-article）
Match（一致条件）：完全一致、URLのみ、クエリ含むなど
Action / HTTP Code：301 / 302 / 410 などを選択
Group：どのグループに属するか（管理用）
Regex（正規表現）：複数パターンをまとめるときに使用（高度者向け）

運用時のポイント

必ずテスト：作成後はブラウザでソースURLにアクセスして期待通りに転送されるか確認。
ログを活用：404や頻繁にヒットする古いURLを確認して、優先的にルール化する。
チェーン回避：A→B、B→C のようなチェーンは性能とSEOに悪影響があるため、可能な限り A→C の単一ルールに直す。
グループで管理：用途ごとにグループ分けすると、運用・削除・エクスポートが楽になる。
エクスポートは定期的に：大規模な変更を行う前にCSVでバックアップを取得する習慣をつける。

最初にやるべき3つのアクション（チェックリスト）

バックアップを取得（必須）。
管理画面からプラグインをインストール＆有効化 → ウィザードで基本設定を行う。
テスト用の転送ルールを1つ作成して、動作確認（ログとブラウザで確認）。

基本的な使い方：転送ルールの作成と操作

Redirectionプラグインで「実際にルールを作る・変える・確認する」までを、画面操作手順・設定のポイント・具体例で順を追って解説します。

各項目は重複しないように分けてあります。

新しい転送ルールの追加（転送元／転送先の指定）

手順（管理画面で）

WordPress管理画面 → ツール（またはプラグインメニュー） → Redirection を開く。
「転送の追加」「Add new」などのボタンをクリック。
Source（ソース） に転送元のパスを入力（例：/old-page）。
Target（ターゲット） に転送先のフルURLまたはサイト内パスを入力（例：/new-page または https://example.com/new-page）。
必要に応じてグループやメモを入力し、保存ボタンを押す。

実務のコツ

ソースは先頭のスラッシュ（/）から始めるパス表記が基本（フルドメインを入れると外部向けに使える）。
保存前に余計なスペースが入っていないかを確認する（誤ったマッチを生む原因）。
最初はテスト用に1件だけ作って動作確認することを推奨。✅

マッチ条件とパラメーターの設定（クエリや一致ルール）

主な一致タイプ

完全一致（Exact match）：URLが完全に一致した場合のみ転送。
URLのみ（URL only）：パス部分だけで判定（サブドメインやクエリは無視）。
Query を含む（Include query）：クエリパラメーター（?utm=xxx など）まで含めて判定。
正規表現（Regex）：パターンに合致する複数URLをまとめて扱う（高度者向け）。

例

完全一致：/old-page → /new-page（/old-page?ref=123 はマッチしない）
クエリ含む：/search?q=apple を個別に扱いたい場合に有効
正規表現：^/category/([0-9]+)/?$ → https://example.com/new-cat/$1（カテゴリIDを引き継ぐ）

注意点

クエリを無視すると、同じパスでもパラメータで動作が変わるケースで誤判定する可能性あり。
正規表現は強力だが誤マッチのリスクも高いので、必ずステージングで検証する。🧪

転送の種類（301/302 等）の指定と保存方法

代表的なHTTPコードと用途

スクロールできます

ステータス	意味	推奨ケース
301	永続的に移動	恒久的なURL変更、ドメイン移行
302	一時的移動	キャンペーン、メンテナンス等の短期転送
410	恒久的に削除（Gone）	ページを完全に削除する場合
307 / 308	HTTP/1.1以降の一時／恒久に対応（特殊ケース）	APIや特別な用途

設定方法

ルール作成画面で「Action」または「Status」から該当のHTTPコードを選択するだけ。
保存を押してルールを有効化。保存後はログや一覧に反映される。

実務ヒント

迷ったら「恒久的なら301、一時なら302」を原則とする。
重要なページでは301にするとSEOの評価を新URLへ移しやすいが、誤用に注意。
HTTPコードは後から変更可能だが、検索エンジンの反映に時間差が出る点を覚えておく。⌛

ルールの編集・複製・削除・一時停止の手順

編集

管理画面の「転送一覧」から対象のルール行を探す。
「編集」ボタンをクリックしてソース／ターゲット／マッチ条件／ステータス等を修正。
保存して動作確認。

複製（コピー）

同じ形式のルールを複数作る場合は「複製」機能でコピー→編集が早い。
複製後は必ずソースをユニークにすること（重複ルールは予期せぬ挙動を招く）。

削除

不要になったルールは一覧で選択し「削除」。
削除前にエクスポート（バックアップ）を取るのが安全。

一時停止（Disable / Deactivate）

ルールを削除せずに無効化できる機能がある場合、一時停止を使うと復活が簡単。
期限付きのキャンペーンなどは「停止」を使い、終了後に再度有効化する運用がおすすめ。🔁

注意

同じソースに対して複数の有効ルールが存在すると競合が生じる場合があるので、どのルールが優先されるか（一覧の上にあるものが先に評価される等）を確認する。

ルールをグループで管理する方法

何のためにグループ分けするか

用途別に整理（例：migrations、campaigns、temp）。
大量ルールの検索・エクスポート・一括無効化が簡単になる。

使い方の例

新規グループを作成（例：domain-move-2025）。
移行関連のルールをすべてそのグループに割り当てる。
移行が終わったらグループ単位で無効化／削除またはエクスポートして保管。

運用ルール（ベストプラクティス）

グループ名は日付や目的を含めて分かりやすく（例：2025-07_campaign_blackfriday）。
定期的にグループを見直し、不要なグループはアーカイブしておく。📂

転送の動作確認（テスト方法）

基本的な確認手順

ブラウザで確認：ソースURLにアクセスして、期待するターゲットに遷移するかチェック。
HTTPステータスを確認：ブラウザの開発者ツール（Network タブ）でレスポンスコードを確認して、301/302などが返っているか見る。
curlで検証（コマンドライン）：

   curl -I https://example.com/old-page

→ HTTP/1.1 301 Moved Permanently のような行を確認。

プラグインのログ／404画面でヒット状況を確認：実際のアクセスがログに残っているか、404一覧から対処済みになっているかを見る。
検索エンジンのキャッシュやインデックスの状態を確認（重要ページのみ）：時間経過で反映されるため、即時変化は期待しない。⏳

テスト時のチェックリスト

正しいHTTPコードが返っているか。
ルールが意図した範囲だけをキャッチしているか（過剰マッチがないか）。
リダイレクトチェーンになっていないか（A→B→C のような中継がないか）。
クエリパラメータの扱い（含めたい／含めたくない）が正しいか。
外部サービスやSNS経由のアクセスでも期待通りか（キャッシュやリンクの仕様で違いが出ることがある）。

便利な検証ツール（簡単に）

ブラウザのNetworkタブ：視覚的で初心者向け。
curl -I：ヘッダだけ確認したいときに最速。
オンラインのHTTPステータスチェッカー：外部からの見え方を確認したい場合に有用。

最後に：実務ワンポイント集（まとめ）

まずは小さくテスト：1件作って保存→ブラウザ＋ログで確認。
チェーンは避ける：可能な限り最終URLへ直接転送する。
グループとコメントを活用：後で誰が見ても分かる運用にする。
バックアップを忘れない：大量変更の前はCSVでエクスポート。
ログを見て優先的に対処：頻出404や古い参照元は早めにルール化する。📈

詳細設定と運用機能

Redirectionプラグインを安全かつ効率的に運用するには、ログ管理・404監視・自動追跡・サイト単位の設定を適切に調整することが重要です。

ここでは各設定の意味、実務での使い方、注意点、推奨値を初心者向けに分かりやすく解説します。

ログの確認と保持設定（転送ログのオン／オフ・期間変更）

なぜログが重要か

ログはどのURLがどれだけ転送されているか、どのルールがヒットしているかを把握するための第一資料です。運用改善やトラブル対応（誤ったルールの検出など）に必須です。

主な設定項目と意味

ログの有効化 / 無効化：ログ記録をONにすると転送ごとに履歴が残る。サイトが高トラフィックでDB負荷が気になる場合はOFFにする選択肢もある。
ログ保存期間：例：30日、90日、無期限。短くするとDB肥大化を防げるが、長期分析ができなくなる。
ログのエクスポート / 一括削除：CSVでの保存や、古いログ一括削除が可能なことが多い。

実務でのおすすめ設定（目安）

ログ：ON（初期はONで運用を観察）
保存期間：30〜90日（サイト規模に応じて短縮or延長）
定期バックアップ：月次でエクスポート → 重要な期間は保存しておく

操作手順（一般的）

管理画面 → Redirection → Options / Settings を開く。
「Logging」セクションでEnable loggingをチェック（または解除）。
Retentionで日数を設定。
必要ならLogsタブで古いログをフィルタして一括削除またはCSVでエクスポート。

注意点

個人情報や機密パラメータ（例：?token=やクレジット関連）はログに残ると問題になる場合があるため、クエリの記録除外やログ無効化を検討する。
高トラフィックサイトではログがDBを肥大させるため、保存期間を短めにするかログを外部で保管するワークフローを構築する。💾

404エラーモニタリングと記録の活用方法

目的

サイト内のリンク切れや外部からの誤リンクを検出し、ユーザー体験やSEO悪化を防ぐために404を把握・対応する。

機能の使い方

404モニターを有効化すると、どのURLで404が発生したか、発生回数、リファラ（参照元）が記録されます。
管理画面の 404 Errors タブで一覧を確認し、優先度に応じて対応（修正 or リダイレクト）を行います。

優先度付けの実務ルール（例）

高優先：外部リンク元が多いURL（大量のリファラ）、又は重要ページに近いコンテンツ。
中優先：内部リンクからの404（サイト内のリンク修正が可能）。
低優先：偶発的なURLやボット由来のノイズ（頻度が1回のみ等）。

対応アクション

関連ページがある場合：301で適切な代替ページへ転送。
明らかに誤ったリクエスト：ログだけ記録して様子を見る。
意図的に削除したページ：410を返す（検索エンジンに恒久削除を示す）。
大量のスパム的404：IPブロックやセキュリティプラグインで制御。

運用ワークフローの例

週次で404タブをレビュー。
上位10の404を抽出して対応（リダイレクト or リンク修正）。
対応後にログで改善を確認。

便利なポイント

404一覧から直接「この404をリダイレクトする」機能がある場合が多く、1クリックでルールを作成できます。🔧

キャッシュや自動追跡（URLモニター等）の設定項目

機能の概要

キャッシュ関連：プラグイン内部で転送結果をキャッシュしてリダイレクト処理を高速化する機能。
自動追跡 / URLモニター：投稿のスラッグ変更やパーマリンク更新を検知して自動でリダイレクトルールを作成する機能。

主要設定と効果

スクロールできます

設定項目	役割	メリット / 注意点
転送キャッシュ	よく使われる転送をキャッシュして応答を早める	メリット：レスポンス高速化。注意：変更即時反映されない場合がある（キャッシュクリア必要）
自動検出（URL monitor）	投稿やページのURL変更を検出して自動的にリダイレクトを作る	メリット：手動作業削減。注意：誤検出で不要なルールを生む可能性があるので監査必須
クエリの取り扱い	クエリを保持するか無視するかを制御	セキュリティ上の懸念（敏感パラメータ）を考慮して除外設定を入れる。

実務的な設定例（推奨）

転送キャッシュ：ON（ただしルール変更時はキャッシュクリア手順を把握）
URLモニター：ON（小〜中規模なら有効。大規模・複雑なサイトはステージングで様子を見てから本番でON）
クエリのログ記録：個人情報含むパラメータは除外設定を行う

運用上の注意

キャッシュを有効化している場合、ルールを変更するとしばらく古い応答が出ることがある。キャッシュクリア手順（プラグイン内のボタン、またはページキャッシュとの連携）を確認しておく。🧹
自動検出は便利だが「自動で作られたルール一覧」を定期的にチェックして不要なルールを削除すること。

サイト単位の設定やサポート関連オプション

マルチサイト（WordPress Network）での挙動

マルチサイト環境では、サイト単位でRedirectionの有効/無効を管理するか、ネットワーク管理者が一括導入するケースがある。
ルールは通常サイトごとに分離されるが、ネットワーク全体のポリシー（ログの保存場所やAPIの可否）は統一されることがあるため、ネットワーク管理者と連携する。

サポート・ヘルプ機能

多くのプラグインには サポートリンク、FAQ、トラブルシュートガイド が設定画面に案内されている。
エラーや不具合が出た場合は、プラグインのデバッグモードやログ出力を一時的に有効にして原因を特定するのが早い（ただしデバッグ情報に個人情報が含まれないか注意）。

バックアップ・復元

設定を変更する前に エクスポート（CSV）を取得しておくと、誤削除やミスの復元が容易。
大量のルールを移行する場合は、ステージング環境でインポート→テスト→本番投入の流れを遵守する。

セキュリティと権限管理

誰でもルールを追加・編集できると誤設定のリスクが高い。管理者権限のユーザー限定で操作する運用にする。
サイトのREST APIへのアクセス制御や、セキュリティプラグインとの相互作用（REST APIがブロックされると自動機能が動かない）を確認する。🔒

サポートを受ける際の準備（問い合わせ前チェックリスト）

プラグインのバージョンとWordPressのバージョンをメモ。
発生している具体的なURL、期待する挙動、実際の挙動（ログやスクリーンショット）を用意。
可能であれば再現手順をまとめておくと早く解決する。

まとめ（運用に役立つ短いチェックリスト）

ログは基本ON→保存期間をサイト規模に合わせて設定（30〜90日推奨）。
404は定期チェック→重要度順に対応（301/410/リンク修正）。
キャッシュと自動追跡は便利だが監査が必須（変更検知・キャッシュクリア手順を把握）。
マルチサイトや権限管理に注意→編集権限は最小限に。
バックアップ（エクスポート）を常に取る→大量変更前は必須。

正規表現・高度なルール作成

Redirectionプラグインで正規表現（regex）を使うと、同じパターンに当てはまる多数のURLを一括で扱えます。

非常に強力ですが、誤設定や過剰マッチによるトラブルも起きやすいので、段階を踏んで安全に導入する方法を丁寧に解説します。

正規表現を使う場合の有効化と基本パターン

有効化の手順（一般的な流れ）

ルール作成画面で「正規表現（Regex）」にチェックを入れる／「Use regex」を有効にする。
ソース欄に正規表現パターンを記述し、ターゲット欄でキャプチャグループ（後述）を使って置換を行う。
保存して必ずテストする。

⚠️ プラグインや環境によってサポートする正規表現機能（lookbehind等）や、パスのみをマッチするのかクエリも含めるのかが異なります。必ずステージングで検証してください。

よく使う基本パターン（例と意味）

スクロールできます

パターン	説明	補足例
`^/old-page$`	`/old-page` にだけマッチ（前後の正確一致）	`/old-page` → `/new-page`
`^/category/(.+)/?$`	`/category/〜` の任意の文字列をキャプチャ（末尾スラッシュ有無OK）	`/category/news`
`^/page/([0-9]+)/?$`	数字のみをキャプチャ（IDを引き継ぎたいとき）	`/page/123`
`^/(.*)$`	サイト全体のパスをキャプチャ（注意：非常に広い範囲にマッチ）	`/anything/here`
`^foo\|bar$`	`foo` または `bar` に一致（選択のパターン）	`/foo` or `/bar`

キャプチャと置換

パターン中の丸括弧 () は「キャプチャグループ」を作ります。
ターゲットURLでは $1、$2 のように使ってキャプチャした部分を再利用します。

例：

ソース: ^/old-category/([0-9]+)/?$
ターゲット: /new-category/$1

上記は /old-category/123 → /new-category/123 に転送します。

サイト全体を対象にする転送ルールの設計（例：ワイルドカードや置換）

サイト移転やパス構成の一括変更ではサイト全体を効率よくリダイレクトする必要があります。

代表的な設計例と注意点を示します。

ドメイン丸ごと移行（パスを保持）

ソース: ^/(.*)$
ターゲット: https://new.example.com/$1
ステータス: 301

→ 旧サイトの /a/b は https://new.example.com/a/b にそのまま飛びます。

特定ディレクトリを別のディレクトリへ移す

ソース: ^/old-dir/(.*)$
ターゲット: /new-dir/$1

末尾のスラッシュを統一（例：全て末尾なしに）

ソース: ^/(.+)/$
ターゲット: /$1
ステータス: 301

クエリパラメータを扱う場合

多くの実装ではURLパスとクエリは分けて扱うことがあるため、クエリを条件に含めたいときは「Query」の設定項目を使うか、プラグインのマッチ条件で Include query を選びます。
クエリを正規表現で扱える場合は、(.*) でキャプチャしてターゲットで使えますが、仕様依存なので要テスト。

注意点（重要）

^/(.*)$ のような広いパターンは想定外のURLまでマッチしてしまうため、十分に検証してから有効化する。
サイト全体ルールは 個別ルールよりも「下」に置く（優先順の話は次節で）。
リダイレクトチェーンが発生しないよう、最終URLを直接指定する。

実用例（パターン集）

カテゴリIDを引き継ぐ：

  ソース: ^/category/([0-9]+)/?$
  ターゲット: /topics/$1

old-page と old-page/ 両方に対応：

  ソース: ^/old-page/?$
  ターゲット: /new-page

トラッキングパラメータを取り除いて転送（クエリ無視 or 除外設定がベター）：
- 推奨：プラグインのクエリ除外機能で utm_* 等を無視する設定を行う。

上級者向け：複雑な条件分岐や優先順位の付け方

高度な運用で出てくる要点を整理します。

ここは失敗すると影響が大きいので慎重に。

ルールの優先順位（一般的な考え方）

多くのシステムは上から順に評価し、最初にマッチしたルールで処理を止めます。
そのため、具体的なルール（特定のページ）を上に、汎用ルール（ワイルドカード）は下に置くのが鉄則です。

例：優先度の付け方

/old-special-page → /new-special（個別ルール：上）
^/old-section/([0-9]+)/?$ → /new-section/$1（パターン）
^/(.*)$ → https://new.example.com/$1（最下位の全体ルール）

条件分岐（複合条件）の作り方

Negative lookahead（〜で始まらない）やPositive lookahead を使うことで除外条件を設定できますが、サポート状況に注意。

例：/blog 配下を除くすべてを移動（擬似例、エンジン依存）：

ソース: ^/(?!blog/)(.*)$
ターゲット: https://new.example.com/$1

（上記は「最初が blog/ でないパス」にマッチ）

複雑な置換（複数グループの活用）

複数のキャプチャグループを使ってターゲットを柔軟に組み立てる：

  ソース: ^/([^/]+)/post-([0-9]+)-(.+)$
  ターゲット: /$1/articles/$2/$3

→ /sports/post-123-title → /sports/articles/123/title

パフォーマンス面の配慮

正規表現は計算コストがかかるため、不要に複雑なパターンは避ける。
大量アクセスのあるサイトでは、広範囲の(.*)マッチを多用するとDB負荷やレスポンス低下を招くことがある。
可能なら複数の小さなルールに分ける、またはサーバー側で処理する（.htaccess や Nginx リライトルール）ことを検討。

安全対策

ルール作成前にバックアップ（エクスポート）を取る。
新しい正規表現はステージングで十分にテストし、ログでヒット状況を数日監視する。
ルールには説明コメント（メモ）を残す（何のためのルールかを明記する習慣）。

テストとデバッグの実践テクニック

基本テスト手順

ブラウザで直接URLにアクセス。
開発者ツールのNetworkタブでHTTPコードとLocationヘッダを確認。
コマンドラインでヘッダ確認：

   curl -I https://example.com/old-path

→ HTTP/1.1 301 Moved Permanently と Location: ... を確認。

プラグインのログでヒット件数・参照元をチェック。

正規表現チェック

オンラインの正規表現テスター（エンジンを選べるもの）でパターンを試す。
テスターで複数のテストケース（期待するもの／期待しないもの）を用意して検証する。

よくあるミスと対応

ミス：^/old と書いて /old-xxx までマッチしてしまう → 解決：^/old$ または ^/old(/|$) にする。
ミス：エスケープ漏れ（. や ? を文字として使いたいときは \.、\?）。
ミス：クエリを想定していたがプラグインがパスのみで判定 → 解決：プラグインのクエリ設定を確認するか別途条件を追加。

最後に：覚えておくべきチェックリスト

正規表現を使う前に必ずバックアップ（エクスポート）。
まずはステージング環境でテスト。
具体→汎用の順でルールを並べる（優先順位）。
キャプチャグループは $1, $2... で正しく参照する。
クエリの扱い（パスのみか含めるか）を事前に確認する。
過度に広いパターン（.* 等）は最小限に留め、ログでヒット状況を観察する。
必要なら正規表現のサンプルをあなたの実サイトURLで作成して差し上げます — どのパターンを変換したいか教えてください。🛠️

一括操作・バックアップ（CSV等）

大量のリダイレクトルールを扱うときは、CSVによる一括操作と定期的なエクスポート（バックアップ）が必須です。

ここでは具体的な手順、CSVフォーマット例、移行時の注意点と安全な運用フローを初心者にもわかりやすく丁寧に解説します。💾🔁

CSVでの一括インポート手順とフォーマット例

準備（重要）

必ずバックアップを取る（プラグインのエクスポート／サイト全体のDBバックアップ）。
ステージング環境でまず小さい件数（例：10行）でテストする。
大量インポート前はログ記録や転送キャッシュを一時的に無効化することを検討（DB負荷・速度のため）。

一般的なCSVのカラム例（よく使われる項目）
下表はRedirectionプラグインのUIで扱う主要フィールドに対応した一例です。実際のプラグインのバージョンによって必要な列名は若干異なることがありますが、以下を基本として用意すると運用しやすいです。

スクロールできます

カラム名	説明	例
source	転送元パス（サイト内は先頭に /）	`/old-page`
target	転送先URLまたはパス	`/new-page` または `https://example.com/new-page`
status	HTTPステータス（数値）	`301`
group	管理用グループ名（任意）	`migration-2025`
match	マッチタイプ（optional）	`exact` / `url` / `query`
regex	正規表現フラグ（true/false）	`false`
position	優先順位（小さいほど上）	`1`
comment	管理用メモ	`migrated from old site`

サンプルCSV（UTF-8、カンマ区切り、ヘッダ行あり）

source,target,status,group,match,regex,position,comment
/old-page,/new-page,301,migration-2025,exact,false,1,記事移行
/old-category/(.*),/new-category/$1,301,migration-2025,regex,true,2,カテゴリ置換
/old-domain/(.*),https://new.example.com/$1,301,migration-2025,regex,true,3,ドメイン移行

注意点（CSV作成時）

文字コードはUTF-8（BOMなし）推奨。日本語が含まれる場合は特に。
特殊文字（カンマや改行）を含む列はダブルクォートで囲む。
正規表現を使う場合、source に正規表現を書き、regex 列を true にする。ターゲットで $1 等を使ってキャプチャを参照。
クエリパラメータの扱いはプラグイン仕様に依存するので、クエリ条件を使うときは必ずテストする。

インポート手順（一般的な流れ）

管理画面 → Redirection → Import（または Import/Export タブ）を開く。
作成したCSVファイルを選択。
マッピング画面が出る場合は、CSVの列とプラグインのフィールドを正しく紐付ける（source → Source 等）。
テストインポート（オプション）を実行できるならまずそれを行う（エラー行を確認）。
小規模で実行して問題なければ本番ファイルをインポートする。
インポート完了後、ブラウザやcurlでランダムな数件をサンプリングして動作確認。

エクスポートによるバックアップと復元の流れ

エクスポート（バックアップ）の手順

管理画面 → Redirection → Export（または Import/Export タブ）を開く。
エクスポートフォーマットを選択（CSVが一般的）。
全ルールまたは特定グループのみを選んでエクスポート。
ダウンロードしたCSVは日付付きのファイル名で保存しておく（例：redirection_backup_2025-08-12.csv）。💡

復元（エクスポートファイルを用いたロールバック）の手順

単純復元：エクスポートしたCSVをインポートすれば基本的に元のルールに戻せます（既存ルールと重複する場合の挙動はプラグイン依存）。
安全フロー：
1. 本番で大規模インポートをする前に必ずエクスポートでバックアップを取る。
2. 問題が発生したら、まずはプラグインのインポートでバックアップCSVをインポートするか、必要なルールのみを復元する。
3. もしインポートが反映されない／誤って大量作成してしまった場合は、エクスポートファイルを使って不要ルールを特定し削除、あるいはサイトDBのバックアップから復元する（高度な対応）。

注意点

インポート時に「重複をどう扱うか（上書き or スキップ）」のオプションがある場合は、意図する挙動を確認してから実行する。
重大な障害が起きた場合は、サイト全体のDBバックアップからの復元が最終手段（ただし他のコンテンツも巻き戻る点に注意）。

大量ルールを安全に移行するコツ

1. ステージングでのリハーサルを必須にする

ステージング環境でCSVをインポート→動作確認→ログ観察を行い、本番に反映。これが最も安全で確実です。✅

2. バッチ処理で段階的に投入する

例えば 100〜500件ずつに分割してインポートし、各バッチ後にチェックを入れる。コマンドラインが使える環境なら split コマンド等で分割可能。
大量投入でDB負荷が高くなる場合は、夜間のアクセスが少ない時間帯に実施する。

3. グループを使って一括制御する

移行用グループ名（例：migration-2025）を付けてインポートすると、本番で問題があった際にそのグループだけ無効化／削除してロールバックしやすい。

4. 事前にCSV内でドメイン名や置換済みのURLを正規化する

ドメイン移行などでは、エクスポートしたCSVをテキストエディタやスプレッドシートで検索置換してからインポートする（例：http://old.example.com → https://new.example.com）。
置換は必ずバックアップを取り、少量でテストしてから一括置換する。🔁

5. ログと監視をすぐに有効にする

インポート直後はログをこまめにチェックして誤マッチや過剰マッチが無いか監視する。ヒット回数が急増しているルールは要調査。

6. キャッシュ・CDN設定の整合

サイトにページキャッシュやCDNがある場合、インポート後はキャッシュのクリアを忘れず行う（古いキャッシュが残るとテストで違和感が出る）。🧹

7. 大量変更時のパフォーマンス対策

ログの一時停止、データベースの一時バックアップ、夜間作業、少量ずつの投入などでDBやサイトの負荷を分散する。
重要な注意：一時的にログを切るとトラブル時の痕跡が残らないので、作業中のログ記録方針をチームで合意しておく。

便利な実務チェックリスト

[ ] ステージングで事前テストを実行した。
[ ] 現行ルールをCSVでエクスポートして保存した（ファイル名に日付）。
[ ] 本番前にDBのフルバックアップを取得した。
[ ] インポートは小バッチで実行し、都度動作確認を行った。
[ ] グループを利用して移行ルールを分類した。
[ ] インポート後にキャッシュとCDNをクリアした。
[ ] ログを監視して異常ヒットを検出したら即対応できる体制を用意した。

トラブルシューティングとよくある質問（FAQ）

Redirectionプラグインでつまずきやすいポイントと、その原因の切り分け手順・具体的な対処法を分かりやすくまとめます。

必要なコマンド例や設定例も載せるので、順に確認して問題を解消してください。🔧

リダイレクトが機能しないときに確認すべき項目

まずは「どこで止まっているか」を確認することが重要です。

以下の順でチェックすると早く原因に辿り着けます。

ブラウザで動作確認（簡易）
- ソースURLに直接アクセスしてターゲットに遷移するか確認。
- ブラウザの開発者ツール → Network タブでレスポンスコード（301/302 等）と Location ヘッダを確認。
ヘッダーだけで確認（コマンドライン）

   curl -I https://example.com/old-page

* `HTTP/1.1 301 Moved Permanently` や `Location: /new-page` が返るかをチェック。
* `curl -I -L` でチェーン先まで追う。

Redirectionプラグイン側のチェック
- ルールが有効（enabled）か。
- ソース／ターゲットの記述ミス（余分な空白、先頭スラッシュの有無など）。
- 正規表現フラグを使っている場合は、RegexがONになっているか。
- 似たルール（上位のルール）が先にマッチして上書きされていないか（ルールの並び順）。
サーバー／他プラグインの干渉
- .htaccess（Apache）やNginxの設定で既にリダイレクトがあると競合する。
- キャッシュプラグイン（ページキャッシュ、オブジェクトキャッシュ）やCDNが古い応答を返している場合、キャッシュをクリア。
- セキュリティ系プラグインが特定のリクエストをブロックしていないか（REST API 関連で機能制限されると自動検出等が動かないことがある）。
プロトコル / ドメインの不一致
- http↔https や www の有無によりマッチしないことがある。必要ならフルURLで指定するか正規表現で統一する。
チェーンやループの有無
- A → B、B → C のチェーンや、A → B → A のループをチェック。チェーンはパフォーマンス低下、ループは無限リダイレクトを招く（ブラウザで「このページはリダイレクトを繰り返しています」等の警告）。

よくある具体的ミスと対処

ミス：ソースに余分なスペース → 修正して保存。
ミス：/old と書いたら /old-xxx までマッチ → ^/old$ 等で正確に。
ミス：キャッシュの影響 → プラグイン/CDNキャッシュをクリアして再確認。
ミス：同一ソースに複数の有効ルール → 不要なルールを無効化し優先ルールだけ残す。

リダイレクト元のページを削除していいか？（運用上の注意）

削除の判断基準

恒久的に不要なページなら、まずは 301で代替ページへリダイレクト → 後で旧URLを削除してもSEOの評価が引き継がれやすい。
恒久的に削除して検索インデックスから素早く外したいなら 410（Gone） を検討（検索エンジンは410を見てインデックス削除を進めやすい）。
一時的に非表示にする場合は 302 を使っておく（後で戻す予定があるなら）。

運用時の注意

内部リンクやサイトマップは削除前に更新する。内部リンクが旧URLのままだと無駄なリダイレクトが発生する。
削除予定がある重要ページは、Search Consoleなどでインデックス状況を監視する。
大量に削除すると404/410が増え、検索クローラの扱いに一時的な影響が出るため段階的に行う。

結論：単純に「削除して良いか？」はケースバイケース。重要なのは代替（リダイレクト）or 410の選択と内部リンクの整備です。

404ログによくわからないファイルが出る場合の対処

404ログに出る「見覚えのないパス」はほとんどの場合次のいずれかです。

原因把握の手順と対処法を示します。

主な原因と対処

ボットやスクレイパーのアクセス
- リファラやUser-Agentを見て判別。頻度が高く無害でなければ無視、悪意があるならIPブロックやファイアウォールで対処。
古い外部リンク（被リンク）やブックマーク
- リファラや発生元が外部サイトの場合、適切な代替ページへ301で誘導する。
テーマ／プラグインの参照する静的ファイル（画像やJS）が削除されている）
- テーマやプラグインの設定を見直し、正しいパスに修正。
favicon, robots.txt, sitemap.xml, wp-login.php などの自動アクセス
- 必要なファイルがあれば配置、不要なら無視。頻度が気になるならログフィルタで除外。
URLパラメータ付きのアクセス（トラッキング等）
- クエリ除外の設定や、該当パラメータを無視するルールを作る。

調査手順

404ログで上位のURLを抽出（頻度順）。
リファラとUser-Agentを確認。
該当のURLが内部リンクから発生しているかをサイト内検索で確認。
内部起因ならリンク修正／リダイレクト、外部起因なら301で代替へ誘導 or 放置。
ボット由来であればアクセスパターンに応じてブロックや無視リストを作る。

便利な運用テクニック

404ログ画面から「この404をリダイレクト」機能でスピード対応。
ノイズ（単発アクセスのボット等）はしばらく観察してから方針を決める。即対応しないことも選択肢。

プラグインを使わないリダイレクト方法（.htaccess / PHP / JavaScript）との使い分け

以下は主な選択肢の比較（用途・メリット・注意点）と、実際の設定例です。

スクロールできます

方法	長所	短所	いつ使うか
サーバー設定（.htaccess / Apache）	非常に高速でWordPress起動前に処理。大量ルールやドメイン全体移行に有効。	手作業での編集が必要、ミスでサイト壊れる可能性あり。	サイト全体のドメイン移行、大量・頻繁にヒットするルール。
サーバー設定（Nginx）	高速、.htaccessが無い環境で必須。	サーバー管理の知識が必要。	同上（Nginx環境）。
PHP（header()）	動的条件で判断可能（ログイン状態等）。	WordPress起動後に実行されるため遅め。SEO的にはOKだがパフォーマンスで劣る。	特殊な動的判定が必要な場合。
JavaScript（location.replace）	実装が簡単。	クライアント側で実行されるためSEOに不向き。検索エンジンや一部ユーザーが追従しない。	一切SEOを気にしない一時的なUI誘導のみ。
CDN / Edge（Cloudflare 等のページルール）	エッジで高速処理、サーバー負荷ゼロ。	利用中のCDNに依存、細かい管理はUI制限がある場合あり。	高トラフィックで早く処理したい場合、ドメイン単位で推奨。

設定例（抜粋）

.htaccess（Apache）簡単な 301：

  # 単純リダイレクト
  Redirect 301 /old-page /new-page

  # Regex（mod_rewrite）
  RewriteEngine On
  RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]

nginx（server ブロック内）：

  # 単純リダイレクト
  rewrite ^/old-page$ /new-page permanent;

  # ドメイン移行（パスを保持）
  rewrite ^/(.*)$ https://new.example.com/$1 permanent;

PHP（テンプレートやプラグイン内）：

  <?php
  header("HTTP/1.1 301 Moved Permanently");
  header("Location: https://example.com/new-page");
  exit;

JavaScript（クライアントサイド）：

  <script>
    location.replace("/new-page");
  </script>

いつプラグインを使い、いつサーバー側に置くか（判断基準）

プラグイン向き：管理画面で多数の細かいルールを編集したい、非エンジニアでも運用したい、404監視やログが欲しい場合。
サーバー側向き：ドメイン全体移行、大量ルールによるパフォーマンス問題、WordPress起動前に処理したい（例えばリダイレクト前にWordPressが重くて応答が遅い場合）。
CDN（Edge）向き：グローバル配信で高速に多数ユーザーに応答させたいとき。

注意：混在はトラブルの元

Plugin と .htaccess、CDNルール等を混在させるとルールの競合・ループが発生しやすい。管理場所（どこで何を制御するか）を明確にして運用すること。

最後に：即使えるトラブルシュート・チェックリスト

[ ] ブラウザでソースURLにアクセスしNetworkでステータスを確認した。
[ ] curl -I でヘッダを確認した。
[ ] Redirection管理画面でルールが有効であることを確認した。
[ ] 正規表現フラグやマッチ条件（query含む/含まない）を確認した。
[ ] キャッシュ（プラグイン／CDN）をクリアした。
[ ] サーバー設定（.htaccess / nginx）に同様のルールが無いか確認した。
[ ] ループやチェーンが発生していないか確認した。
[ ] 404ログの発生元（リファラ/UA）を見て対応を決めた。

運用上のベストプラクティス（SEO・保守）

Redirectionプラグインを安全に・継続的に運用してSEOとUXを守るための具体的なやり方をまとめます。

ここでは「検証フロー」「命名・整理ルール」「移行時の実務チェック」を中心に、すぐ使えるテンプレートやチェックリストを提示します。

検証手順・ログ活用による品質維持

目的：ルールが期待どおりに動き、不要なサーバー負荷やSEO被害を出さないこと。

日常検証フロー（短縮版）

変更直後（即時）
- ブラウザで代表的な3件を確認。
- curl -I でレスポンスヘッダ（ステータス / Location）を確認。
curl -I https://example.com/old-page
24時間後
- プラグインのログで該当ルールのヒット数・エラーを確認。
- 404一覧に新たな高頻度項目が出ていないかチェック。
1週間スパン
- ランダムに20件ほどルールを抽出して挙動チェック（ブラウザ + curl）。
- 検索エンジンで重要ページのインデックス状況を確認（必要に応じて再クロール依頼）。

ログの活用ポイント

頻度順ソート：どの古いURLがまだ多くヒットしているかを特定する。
参照元（Referrer）確認：外部リンク由来なら301で誘導、内部リンク由来ならサイト内修正。
異常検出：短期間でヒット急増しているルールは誤爆やボットの可能性あり。優先調査。

自動化のヒント

週次でログ件数をCSV出力して、増減を自動集計する（簡易スクリプトでOK）。
重要ルールのヘルスチェックを cron + curl で実行し、異常時に通知する（Slack / メール）。

簡単な検証コマンド例

# ヘッダ確認（リダイレクト先を含める）
curl -I -L https://example.com/old-page

# 期待しているステータスを確認（301 を想定）
curl -I https://example.com/old-page | grep "HTTP/" && curl -I https://example.com/old-page | grep Location

ルール命名・グループ分け・定期メンテナンスのルール

目的：誰が見ても分かる管理、迅速なロールバック、影響範囲の限定。

命名規約（例）

<YYYYMMDD>_<目的>_<簡易説明>
- 例：20250812_migration_oldblog_to_newblog
単一ルールのメモは必ず残す（理由／担当者／期限など）。

グループ分けの設計例

スクロールできます

グループ名	用途	運用アクション
`migration-2025`	ドメイン/大量移行用	移行完了後30日でアーカイブ
`campaign-summer24`	一時キャンペーン用	期限後に無効化
`permanent-fixes`	恒久的な恒久移転	定期確認（年1回）

定期メンテナンススケジュール（推奨）

毎日（または毎営業日）：ログの簡易サマリ確認（トップ10の404）。
週次：新しい404の優先対応（上位5件を処理）。
月次：全グループのヒット数レビュー、不要ルールの確認・アーカイブ。
年次：恒久ルールの再評価（事業の変化に合わせて見直し）。

運用ルール（必須）

ルール追加は担当者の承認（2名推奨）を経て公開する。
重大な一括変更はステージング→エクスポートバックアップ→本番の順で実施。
ルール削除は即時復旧しやすいようまず無効化（Disable）し、一定期間経過後に完全削除。

ドキュメント化

ルールごとに「作成日時／作成者／目的／期間（期限）」を残す。
管理者用READMEを作り、命名規約・グループ基準・ロールバック手順を明記しておく。

移行時のチェックリスト（ドメイン移行・大量変更時）

準備フェーズ（事前）

[ ] サイト全体のフルバックアップ（DB + ファイル）。
[ ] 現行のRedirectionルールをCSVエクスポートして保管（ファイル名に日付）。
[ ] ステージング環境で移行リハーサルを完了（小バッチでテスト）。
[ ] クリティカルページの優先リストを作成（トップトラフィック・収益ページ等）。

移行フェーズ（実行時）

[ ] インポートは小バッチ（例：100件）で段階的に行う。
[ ] 各バッチ後にブラウザ + curl で代表URLをチェック。
[ ] CDN / ページキャッシュをクリア（必須）。
[ ] ログ記録を一時的に強化し、ヒット状況を細かく監視。

検証フェーズ（移行直後〜数日）

[ ] 24時間以内：高頻度404の有無を確認し即対応。
[ ] 72時間以内：検索エンジンのインデックス状況（主要ページ）を確認し必要なら再クロールを依頼。
[ ] 1週間：流入や順位の大きな落ち込みがないか確認。問題があればすばやくロールバック準備。

ロールバック手順（想定）

問題発生時は該当グループを無効化または、インポート前に保存したCSVで復元。
必要ならサイト全体をDBバックアップから復元（最終手段）。
発生原因を特定して修正 → ステージングで再テスト → 再度本番に適用。

移行時の注意点（具体）

パス構造が変わる場合、正規表現での置換は慎重に：$1 の参照先が期待どおりか必ず確認。
http / https、www の有無を統一しておく（混在が原因で余計なリダイレクト発生）。
重要ページは個別ルールを上位に置く（汎用ルールは下へ）。

まとめ：実務で忘れがちな3つのポイント

小さく・段階的に動かすこと — 全件一括で突っ込まず、バッチ検証を行う。
説明の残るルール — 名前・メモ・グループを必ず付け、誰でも意図がわかるように。
ログを運用の中心に置く — ログは単なる履歴ではなく、優先対応や品質改善のエンジンになる。

付録：具体的な入力項目（実務チェックリスト）

この付録は実際にRedirectionの管理画面やCSVでルールを作るときに目の前で使えるチェックリストです。

画面に入力するフィールドの意味・注意点・例を簡潔にまとめます。

実務ですぐに使えるよう、優先度の高い項目から順に説明します。✅

転送設定で使う主要フィールド（例：ソースURL／クエリ／ターゲットURL／グループ／HTTPステータス／除外設定／位置）

下表は各フィールドの 目的・入力例・注意点 を短くまとめたものです。

入力前にこれをチェックしてください。

スクロールできます

フィールド	目的	入力例	注意点（実務チェック）
Source（ソースURL）	リダイレクトの出発点（マッチさせるURL）	`/old-page` または `^/old-category/(.*)$`（regex時）	サイト内は先頭に `/`。正規表現使用時はRegexフラグをONに。余分な空白に注意。
Match（一致条件）	判定方法（完全一致 / URLのみ / クエリ含む / regex）	`exact` / `url` / `query` / `regex`	クエリを含めるかで振る舞いが変わる。意図を明確に。
Target（ターゲットURL）	転送先（フルURL or パス）	`/new-page` または `https://example.com/new-page`	フルURL指定は外部向けにも有効。プロトコルやドメインの誤記に注意。
HTTP Status（ステータス）	301/302/410 等の挙動指定	`301`（恒久） / `302`（一時） / `410`（消去）	恒久はSEO評価移行を期待、誤用注意。
Group（グループ）	ルールの分類（管理用）	`migration-2025` / `campaign`	グループ分けで一括無効化/エクスポートが楽に。命名規則を統一する。
Regex（正規表現フラグ）	ソースが正規表現かどうか	`true` / `false`	正規表現は強力だが誤マッチに注意。ステージングで検証。
Position（優先度/並び）	ルールの評価順（上から評価）	`1`（上位） / `10`	具体ルールを上位、汎用ルールを下位に。
Exclude / Conditions（除外・条件）	特定のクエリやIP等を除外	`exclude_query=utm_*`	個人情報やトークンをログに残さない設定も検討。
Notes / Comment（メモ）	ルールの目的・作成者・期限	`作成: 2025-08-12 / 担当: yamamoto`	後追い運用で役立つ。必須に近い運用ルールにすること。
Enabled（有効/無効）	ルールのON/OFF	`true` / `false`	本番前はテスト有効化、不要なら無効化してから削除。

重要ポイント

必ずソースとターゲットを目で確認：余分なスペースや全角文字が混じるミスが多い。
正規表現使用時は $1 等のキャプチャ参照をターゲットで正しく使う。
グループ管理を有効活用：移行時のロールバックや期限付きルールの管理が楽になります。📂

CSVサンプル（列の並びとサンプル行）

CSVで一括登録／エクスポートする際の実用的な列並び（ヘッダ）例と、実際のサンプル行を示します。

CSVは UTF-8（BOMなし） で保存するのが安定です。

日本語が含まれる場合でもUTF-8がベスト。📝

推奨ヘッダ（順序はプラグインに合わせる必要あり）

source,target,status,group,match,regex,position,comment,enabled

サンプルCSV（小さなサンプル、ヘッダ行あり）

source,target,status,group,match,regex,position,comment,enabled
/old-page,/new-page,301,migration-2025,exact,false,1,"記事移行 - 重要ページ",true
^/old-category/([0-9]+)/?$,/new-category/$1,301,migration-2025,regex,true,2,"カテゴリID引継ぎ",true
/temporary-sale,/promo-sale,302,campaign-summer24,exact,false,1,"キャンペーン（7/1-7/10）",true
/obsolete-page,,410,permanent-fixes,exact,false,5,"恒久削除（410）",true

サンプルの説明

1行目：単純なページ移行（301、同一サイトパス）。
2行目：正規表現でカテゴリIDをキャプチャして新URLに埋め込む例（$1 使用）。regex=true を忘れずに。
3行目：キャンペーンの一時転送（302）。終了後に enabled=false にする運用が楽。
4行目：恒久削除（410）。ターゲットURLは空欄でOK（プラグイン仕様により挙動確認）。

CSV作成の実務チェックリスト

[ ] 文字コード：UTF-8 (BOMなし) で保存したか？
[ ] 改行コード（LF/CRLF）は環境に合わせて統一したか？（多くはLFでOK）
[ ] 正規表現（regex=true）の行はプラグインがサポートする形式か確認したか？
[ ] カンマや改行を含む列は ダブルクォートで囲んでいるか？（例：コメントにカンマがあるとき）
[ ] エクスポートしたCSVを**もう一度読み込み（プレビュー）**してマッピングが正しいか確認したか？
[ ] 小バッチ（例：最初は10行）でテストインポートを行ったか？

実務ワンポイント

最初は小さなテストを必ず行う：CSVインポートで一気に大量反映すると戻しが大変。
「グループ」と「コメント」は手間でも必ず埋める：運用負荷を劇的に下げます。
正規表現は強力だが危険：^/(.*)$ のような広いパターンは本番投入前に必ず検証。
エクスポートは日付付きで保管：redirection_backup_YYYYMMDD.csv の命名で管理しましょう。📦

まとめ

本記事の要点を短くまとめます。

作業前にこのチェックリストを確認してから進めると安全です。

重要ポイント（チェックリスト）

目的を決める：恒久的移動は301、一時的なら302、完全削除は410。まず目的を明確に。
バックアップを取る：設定変更前は必ずエクスポート（CSV）とDBバックアップを。
小さく試す：最初は1件〜少数でテスト、問題なければバッチで拡大。
ログと404を監視する：頻出の404や誤マッチを優先的に対応する。
チェーンとループを避ける：A→B→C のチェーンは避け、可能な限り A→最終にする。
命名・グループで管理する：誰が見ても分かる名前とグループを付け、運用負荷を下げる。

最後に一言：Redirectionプラグインは「正しく使えば」非常に強力で、SEOやユーザー体験を守る強い味方になります。一方で誤設定はトラフィックを失うリスクにもなるため、まずはテストとバックアップを徹底してください。

Redirection完全ガイド！使い方、初期・詳細設定、トラブル対応など徹底解説！【WordPress】

概要と基本概念

リダイレクトとは何か（役割と仕組み）

永続（301）と一時（302）の違いとSEOへの影響

こんなときにリダイレクトが必要か（活用ケース）

ページURLを変更する場合

ドメインを移転する場合

一時的な転送が必要なケース（キャンペーン等）

コンテンツを大幅に差し替えたとき・削除したとき

ケース別の簡単早見表

最後に：運用のためのチェックリスト

Redirectionプラグインの導入と初期準備

プラグインの導入方法（管理画面／公式サイトから）

初回セットアップの流れ（セットアップウィザード／REST API確認など）

管理画面の構成（転送一覧・グループ・ログ・404・インポート／エクスポート・設定）

最初にやるべき3つのアクション（チェックリスト）

基本的な使い方：転送ルールの作成と操作

新しい転送ルールの追加（転送元／転送先の指定）

マッチ条件とパラメーターの設定（クエリや一致ルール）

転送の種類（301/302 等）の指定と保存方法

ルールの編集・複製・削除・一時停止の手順

ルールをグループで管理する方法

転送の動作確認（テスト方法）

最後に：実務ワンポイント集（まとめ）

詳細設定と運用機能

ログの確認と保持設定（転送ログのオン／オフ・期間変更）

404エラーモニタリングと記録の活用方法

キャッシュや自動追跡（URLモニター等）の設定項目

サイト単位の設定やサポート関連オプション

まとめ（運用に役立つ短いチェックリスト）

正規表現・高度なルール作成

正規表現を使う場合の有効化と基本パターン

サイト全体を対象にする転送ルールの設計（例：ワイルドカードや置換）

実用例（パターン集）

上級者向け：複雑な条件分岐や優先順位の付け方

テストとデバッグの実践テクニック

最後に：覚えておくべきチェックリスト

一括操作・バックアップ（CSV等）

CSVでの一括インポート手順とフォーマット例

エクスポートによるバックアップと復元の流れ

大量ルールを安全に移行するコツ

便利な実務チェックリスト

トラブルシューティングとよくある質問（FAQ）

リダイレクトが機能しないときに確認すべき項目

リダイレクト元のページを削除していいか？（運用上の注意）

404ログによくわからないファイルが出る場合の対処

プラグインを使わないリダイレクト方法（.htaccess / PHP / JavaScript）との使い分け

最後に：即使えるトラブルシュート・チェックリスト

運用上のベストプラクティス（SEO・保守）

検証手順・ログ活用による品質維持

ルール命名・グループ分け・定期メンテナンスのルール

移行時のチェックリスト（ドメイン移行・大量変更時）

まとめ：実務で忘れがちな3つのポイント

付録：具体的な入力項目（実務チェックリスト）

転送設定で使う主要フィールド（例：ソースURL／クエリ／ターゲットURL／グループ／HTTPステータス／除外設定／位置）

CSVサンプル（列の並びとサンプル行）

推奨ヘッダ（順序はプラグインに合わせる必要あり）

サンプルCSV（小さなサンプル、ヘッダ行あり）

CSV作成の実務チェックリスト

実務ワンポイント

まとめ

関連記事