はじめに：移転と同時に順位低下するサイトが後を絶たない理由

サイトを移転した直後にアクセスが半減──。これは単なる巡り合わせではなく、検索エンジンが「別サイト」と認識して評価を一時的にリセットしてしまうためです。リダイレクトは“住所変更届”とまったく同じ役割を果たしますが、届け出の仕方を誤れば旧住所の郵便物が新居に届かないのと同様、検索順位が戻らなくなります。旅館サイトや歯科医院のように地域ビジネスであっても、IT ブログのように検索流入が生命線であっても、影響度は同じです。ここでは「評価の損失ゼロ」を目標に、手順を体系立てて解説します。

リダイレクトが必要になる 3 つの典型シナリオ

1. サイト移転（ドメイン変更・サブディレクトリ化）

• 例：ryokan-example.com → stay.example.jp へ移行
• 影響：TOP ページだけでなくプラン紹介やアクセス案内など下層 URL がすべて変わる

2. SSL 化による http→https 変更

• 医療機関で義務化が進む常時 SSL 化
• 混在コンテンツ（http の画像・CSS）が残ると警告が出て順位にも悪影響

3. コンテンツ統合・記事整理

• 古い記事を削除せず統合記事へ 301 で橋渡し
• 重複コンテンツ評価の分散を防ぎ、サイト全体の E‑E‑A‑T を高める

リダイレクトの種類と SEO への影響

リダイレクトには複数の方式がありますが、実務で使うのは大きく 3 種類です。

種類	意図	検索エンジンの扱い	主な使用シーン
301（Moved Permanently）	恒久的転送	ページ評価を 90〜99 % 引き継ぐ	ドメイン移転、記事統合
302（Found）	一時的転送	PageRank はほぼ渡さない	キャンペーン用 LP、A/B テスト
meta refresh（5 秒リダイレクト等）	HTML 内転送	評価をほぼ渡さないうえ UX も低下	緊急時のみ推奨

※ JavaScript リダイレクトはクロール待ち時間が長くなるうえ、画像オブジェクトや CSS からの参照 URL が検出されにくいため原則非推奨です。

301 と 302 の選択基準：検索評価を譲渡するか否か

恒久的変更なら 301 一択

301 は「今後も変わらない」ことを示すため、ページ評価や被リンク資産を引き継ぎます。「旅館名を変える」「クリニックが移転する」など、旧 URL に戻る見込みがない場合は 301 を必ず選びます。

一時キャンペーンなら 302

シーズンごとのプラン紹介ページなど、終了後に元ページへ戻す前提なら 302 が安全です。302 を誤って恒久変更に使うと、Google が「仮置き」と判断し旧ページをインデックスし続け、評価が分散する原因になります。

準備フェーズ：現状 URL と内部リンクの棚卸し

リダイレクト設定の前に、まずは「何を、どこから、どこへ」転送するかを洗い出します。

1. URL 全量を抽出
   • Screaming Frog などのクローラーでサイト全体をクロールし、CSV でエクスポート
   • CMS が WordPress なら、データベースから wp_posts テーブルを SQL 抽出すると漏れが少ない
2. 内部リンク・画像・JS の参照を紐付け
   • 画像や PDF など静的ファイルは Google Analytics の「行動 › サイトコンテンツ › すべてのページ」で PV を確認し、遷移先の優先度を決める
3. 優先順位のスコアリング
   • PV × 滞在時間 × 外部被リンク数を「3 軸合計」で数値化すると重要 URL が可視化できる
4. マッピング表を作成
   • 旧 URL / 新 URL / 転送方式 / 優先度 / 備考（担当メモ）の 5 列構成でスプレッドシート化

サイト移転・SSL 化での実践ステップ

ステップ 1：DNS とサーバー環境の同時準備

• 新ドメインの DNS A レコードを TTL 300 秒程度に短縮
• 旧サイトと同一サーバーに仮設置して疎通テストを行う（移転直前まで noindex）

ステップ 2：リダイレクトルールを記述

Apache なら .htaccess、Nginx なら server ブロックで設定。大量転送時は RewriteMap で外部ファイル化するとメンテナンス性が上がります。

ステップ 3：カノニカル＆内部リンク一括置換

• CMS 側テーマファイルで rel="canonical" を新 URL に固定
• データベースの一括置換前には必ず全バックアップ

ステップ 4：Search Console でアドレス変更ツールを実行

• HTTP→HTTPS はプロパティ追加を忘れやすいので注意
• サイトマップは旧 URL と新 URL の双方を 180 日は併用

ステップ 5：監視とチューニング

• 404 発生回数をサーバーログで監視し、週次でリダイレクト表を更新
• 検索パフォーマンスが安定しない場合、301 チェーン（リダイレクト多段階）をログ解析して最適化

コラム：サーバー負荷と表示速度は本当に悪化するのか

• ほとんどの場合、301 1 段階なら遅延は 20 ms 前後で体感差はありません
• ただし画像 CDN・AMP キャッシュを含む場合、リダイレクト先で再キャッシュが走るため初回表示が遅く見えることがあります
• GTmetrix などのテストで「Redirect chains」の項目が黄色以上なら、URL 正規化を見直すサイン

古い記事統合時のベストプラクティス

複数の記事を一本化する理由は「重複コンテンツ解消」と「評価集中」の二つに集約されます。特に IT ブログでは、似た内容のアップデート記事が並存しやすく、検索順位が分散しやすい状態が放置されがちです。統合のステップは次のとおりです。

ステップ 1：統合対象候補の洗い出し

• 同一キーワードで順位が 20 位以内に複数表示される記事
• 更新日が古く、被リンクはあるもののアクセスが頭打ちの記事
• 新情報を追加しても URL を変えたくない強い一本柱記事（ハブ記事）がある場合、そのハブ記事を残して他を統合

ステップ 2：評価指標で優先度を順位付け

Google Search Console の「検索結果」レポートからクリック数・表示回数・掲載順位を CSV 出力し、月平均 PV と被リンク数を掛け合わせスコアリングします。数値化することで「残すべき主⾳記事」が可視化され、統合漏れを防げます。

統合前記事タイトル	公開日	月間 PV	被リンク数	統合先 URL	コメント
Apache リダイレクト設定完全ガイド	2019/08/10	5,200	14	/redirect-manual/	用語解説が重複
301 と 302 の違いを徹底比較	2020/03/18	4,100	27	/redirect-manual/	被リンク優秀
.htaccess で 301 転送を一括管理する方法	2021/02/05	3,450	9	/redirect-manual/htaccess/	技術詳細をサブ記事化

ステップ 3：コンテンツ統合の実装

1. 情報を加筆・最新化
   ‑ 統合先記事に旧記事の高評価部分をコピーし、重複箇所は削除して 1.5 倍程度の情報量に増量。
2. 旧記事に 301 を設定
   ‑ URL 構造が類似していれば正規表現でワイルドカード転送すると設定漏れが減る。
3. パーマリンク内部リンクの張り替え
   ‑ WordPress を例にすると、UPDATE wp_posts SET post_content = REPLACE(post_content, '旧URL', '新URL') で一括置換。本番反映前に必ず WP‑CLI でエクスポートバックアップを取得。
4. Search Console でクロールリクエスト
   ‑ 統合先 URL を手動検査し「インデックス登録をリクエスト」を押下。平均 1〜3 日で影響が反映される。

統合後 30 日間で見るべき 3 指標

• 平均掲載順位：旧記事単独時より 3 位以内に収束すれば成功ライン
• クリック率（CTR）：タイトル変更を伴う場合は 15 % 以上を目標
• 流入クエリの分散度：Search Console の「クエリ数」が 1.3 倍以上ならロングテール獲得につながっている

リダイレクト設定後の検証とモニタリング

設定が完了した時点では“スタートライン”に立っただけです。検索評価を損なわないかどうかは、最低でも 90 日間の観測が不可欠となります。

1. サーバーログで 404／500 を検出

• 旧 URL がブックマークされている場合、リダイレクト漏れで 404 が急増します。grep " 404 " コマンドで日次抽出し、発生ランキング上位 20 件を毎朝レビュー。
• 500 系エラーは RewriteRule のタイプミスが原因のことが多く、同タイミングで CPU 使用率も跳ね上がるため、監視ツール側の閾値を一時的に下げて早期検知。

2. Search Console「カバレッジ」レポート

• エラー → 除外 → 有効 のステータス推移をグラフで見ると、リダイレクトチェーンが残っていないかを把握しやすい。
• 「ページの取得」速度が 100 ms 以上悪化した場合、CDN 側のキャッシュ TTL が正しくない可能性があるため要再設定。

3. GA4 でランディングページ比較

GA4 の「トラフィック獲得」→「ランディングページ」レポートを使い、移転前後 30 日間でセッション数変化を比較。以下のようなチャートを作成すると、影響度をチームで共有しやすくなります。

チャート作成手順（GA4→Google スプレッドシート）

1. GA4 から CSV エクスポート
2. スプレッドシートで「旧 URL セッション数」「新 URL セッション数」を縦棒グラフ化
3. 棒グラフ上で差分をラベル表示すると、非エンジニアでも理解しやすい

トラブルシューティング：よくある失敗と解決策

症状 1：検索結果に旧 URL が残り続ける

原因：301 ではなく 302 を設定したか、noindex 指定を解除していない
対策：301 に修正し、Search Console で「削除ツール」を併用

症状 2：混在コンテンツ警告が消えない

原因：テーマファイル内のスクリプトが http のままハードコード
対策：<script src="//example.com/js/app.js"> のスキームレス記述を推奨

症状 3：リダイレクトループが発生

原因：サーバー側 RewriteRule と CMS プラグインの両方で転送設定を重複
対策：どちらか一方に統合し、キャッシュレイヤをバイパスして検証

症状 4：アクセスは戻ったものの CV 数が減少

原因：ランディングページが変わり導線が深くなった
対策：ヒートマップで離脱箇所を特定し、CTA ボタンを折り返し点に再配置

事例紹介：旅館サイトでの OTA 連携トラブル

• OTA（オンライン旅行代理店）に登録した旧 URL が残り、クローラー経由で 302 になっていた
• 予約導線が二重化しコンバージョン計測が割れるという問題が発生
• 対策として OTA 管理画面から一括 URL 変更し、パラメータ付与で GA4 の計測も統合

事例紹介：歯科医院の予約フォーム移行

• 旧：/contact/ → 新：/reserve/ に変更
• リライトルールは問題なく動作したが、患者がブラウザの自動補完で旧 URL を直接入力
• 検索意図で「予約」と検索したときに sitelink が旧 URL を示すケースがあり、サイトリンク削除申請と内部リンクの追加で解決

モニタリングを自動化するツールセット

プロジェクトが大規模になるほど、人手だけではリダイレクト漏れやステータス異常を見逃します。ここでは運用負荷を最小化するための代表的なツールと自動化フローを紹介します。

ツール	自動化対象	推奨設定間隔	アラート通知先
UptimeRobot	HTTP ステータス監視	5 分	Slack / メール
Google Looker Studio	Search Console・GA4 の統合可視化	1 日	共有ダッシュボード
GitHub Actions + cURL	リダイレクトチェーン定期テスト	1 日	Pull Request コメント
BigQuery Scheduled Query	サーバーログの 404 集計	1 時間	Data Portal

上記を組み合わせれば、「404 が 50 件を超えたら Slack にアラート」→「リンク修正 PR を自動生成」というワークフローも実装可能です。

GitHub Actions 例：リダイレクトチェーン検出

yamlコピーするname: Check Redirect Chain
on:
  schedule:
    - cron: '0 3 * * *'
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Curl list
        run: |
          while read url; do
            curl -sIL "$url" | grep -i location | awk '{print $2}'
          done < url_list.txt

このジョブを毎日回すだけで、誤って 302 が紛れ込んでいないか、3 段以上のチェーンが発生していないかを検知できます。

法規制とプライバシーを踏まえた設定注意点

ログの個人情報取り扱い

• 医療機関ではアクセスログに IP アドレスが含まれるため、個人情報保護法上の「個人データ」扱い。7 日以内に匿名化するなど内部規程化が必要です。
• 予約フォーム移行時に追跡パラメータを付与する場合、患者の氏名や診察内容を URL に含めないよう注意。

旅館業法・景品表示法との関係

• OTA 経由料金と公式サイト料金の差額を訴求するトラフィック分岐テストを行う場合、302 転送で A/B テストすること自体は合法。ただし過度な“囲い込み”表現は景品表示法の優良誤認に抵触する恐れがある。

プロジェクト成功の鍵：ドキュメントと人

技術的な最適化が整っても、最終的に検索順位を守るのは 「変更履歴が追える体制」 です。以下のような役割分担表を作成し、担当者を固定することで属人化を防ぎます。

フェーズ	担当部門	主要タスク	チェックリスト
計画	マーケティング	影響 URL 抽出・優先度決定	URL リストに PV/リンクスコアを付与
開発	エンジニア	RewriteRule 設計・テスト	301/302 の使い分けをレビュー
品質保証	QA	リダイレクトチェーン・404 検証	自動テスト結果と手動クロール
公開	ディレクター	DNS 切替、Search Console 更新	対外周知メール送付
保守	インフラ	ログ監視・負荷分散調整	アラート閾値と対応フロー確認

ドキュメントは Notion などの一元管理ツールで「URL マッピング表」「変更履歴」「アラート対応手順」を横串で参照できるようにしておくと、担当交代時の引き継ぎが円滑になります。

まとめ

• 301 と 302 を正しく選び、検索エンジンに「恒久か一時か」を明示することが順位維持の大前提。
• 移転前の棚卸しとマッピング表作成が、のちの 404・チェーン発生を 80 % 以上抑制する。
• 統合記事は“主⾳記事”を決めて評価を集中。Search Console データで事後検証し、30 日以内に指標が回復するか確認する。
• 自動監視ツールで 404／チェーン／速度劣化を可視化し、アラートを 5 分〜1 時間単位で受け取る体制を構築する。
• 法規制・個人情報保護にも配慮し、予約システムや OTA 連携時は URL パラメータの情報量を最小限に。

これらを徹底すれば、サイト移転や SSL 化、記事統合を行っても検索順位の下落を最小限に抑え、むしろ評価の再集中と UX 向上によるプラス効果を享受できます。