ウェブサイト移行ツール完全ガイド（2026年版）

サイト移行は、SEOチームが実行できる施策の中でも最もリスクの高いものの1つです。MagentoからShopifyへの移行、20の地域サイトを1つのドメインに統合する場合、あるいは何千ものURLを再構成する場合でも、ミスできる余地はごくわずかです。うまくいけばトラフィックは安定します。失敗すれば、順位の回復に何か月もかかることがあります。

きれいな移行と損害を招く移行の差は、しばしばツールにあります。適切なツールは公開前にエラーを検出し、大規模にリダイレクトを展開し、公開後もリンクの健全性を継続的に監視します。間違ったツール、あるいはさらに悪いことに手作業のみのプロセスは、Googleが見つけるのを得意とする抜け穴を生み出します。

このガイドでは、あらゆるチームに必要な移行ツールの5つのカテゴリ、それぞれのカテゴリでの最適な選択肢、そして混乱しがちな移行を管理されたプロセスへと変える段階別ワークフローを解説します。

サイト移行とは何か？#

Googleはサイト移行を広く定義しています。移行はいくつかのカテゴリに分かれ、それぞれに異なるリダイレクト要件があります：

サイト移転：ドメイン全体を変更する（example.com → newdomain.com）。すべてのURLに1対1のリダイレクトが必要です。URLの再構成：同じドメインで、新しいURLパターンに変更する（/blog/post-title → /resources/post-title）。一括マッピングが重要です。プラットフォーム移行：Magento → Shopify、WordPress → Webflow。URLはそのままの場合もあれば変更される場合もあります。まずクロールし、その後判断します。プロトコル変更：HTTP → HTTPS。しばしば「移行」として見落とされますが、HTTPSリダイレクトの設定不備は重複コンテンツを生みます。サブドメイン統合：blog.example.com → example.com/blog。サブドメイン全体にわたってパターンベースのリダイレクトが必要です。

不適切に実施された移行のコストは検索結果に表れます。Googleのサイト移転ガイドによると、中小規模のサイトでは大半のページの移行に数週間かかる場合があり、大規模サイトではさらに時間がかかり、その間に可視性が変動することがあります。その期間中に壊れたリダイレクト、404、チェーンが発生するたびに、状況は悪化します。適切なツール群は、その期間をできるだけ短く、静かなものに保ちます。

すべての移行に必要な5つのツールカテゴリ#

移行は5つの明確な段階を経て進みます。各段階には、プロセスの特定部分を担う専用ツールがあります。段階を飛ばしたり、間違ったツールを使ったりすると、下流でリスクが積み重なります。

1. クロールツールと監査ツール#

何かを移動する前に、現在のサイト上にあるすべてのURLについて完全なインベントリが必要です。ステータスコード、canonicalタグ、インデックス可能性、そしてサイト構造内での位置です。クローラーがこのインベントリを生成します。

主要ツール: Screaming Frog SEO Spider は業界標準です。500 URLまでは無料で、年間279ドルの有料ライセンス（2026年10月確認）で無制限クロール、JavaScriptレンダリング、カスタム抽出が利用できます。Sitebulb は強力なビジュアルレポートを追加し、SEO以外の関係者にもクロールデータを読みやすくします。Lumar（旧 Deepcrawl）は、URL数が非常に多いエンタープライズサイト向けに構築されています。Botify はクロールデータとログファイル分析を組み合わせるため、存在するものだけでなく、Google が実際にクロールしているものも確認できます。

プロのヒント: クロールは2回実行しましょう。1回は移行計画の前に、もう1回は公開直前に行います。サイトの内容はすぐに変わるため、3週間前のクロールでは、その後 Google がインデックスしたURLを見逃してしまいます。

2. リダイレクトマッパー#

クロール後に直面する中心的な作業は、すべての旧URLを新しい移動先に対応付けることです。100 URL未満のサイトなら、スプレッドシートで対応できます。それより大きい場合は、専用のマッピングツールを使うことで時間を節約し、人為的ミスを防げます。無料の Migration Redirect Mapper は、サイトマップ、貼り付けたリスト、CSV から旧 URL を新 URL に照合し、各照合の根拠となるルールを表示します。

マッピングの方法: スプレッドシートベース（Google Sheets、Excel） — 小規模サイト（100 URL未満）に適しています。VLOOKUP または INDEX/MATCH を使って旧URLと新URLを対応付けます。大規模になると限界があります — 5,000行のシートに1つ টাইपोがあるだけで、リダイレクト切れが発生します。自動パターンマッチング — Screaming Frog のようなツールは、正規表現やパターンベースのルールを適用して、リダイレクトマップを自動生成できます。たとえば /blog/* → /resources/* なら、1つのルールで数百URLを一括処理できます。CMS移行プラグイン — Shopify や WordPress などのプラットフォームには、一般的な移行元プラットフォーム（Magento、WooCommerce）向けの移行コネクタがあります。これらはURLマッピングを自動処理しますが、絞り込み済みURL、ページネーション、UTMパラメータ付きページなどの例外を見落とすことがよくあります。CSV一括インポート対応のリダイレクトプラットフォーム — 最も速い方法は、マッピング済みCSVを書き出し、リダイレクト管理プラットフォームにインポートして、すべてのURLに一度で展開することです。これにより、URLごとの手動設定が不要になり、移行マップ全体を一元的に管理できるダッシュボードが手に入ります。

3. リダイレクト展開プラットフォーム#

移行の成否はここで決まります。完璧にマッピングされたリダイレクト計画も、展開が遅い、ミスが起きやすい、あるいは開発者の対応に依存していては意味がありません。リダイレクト展開プラットフォームは、構成ファイル不要、ステージングへのデプロイ不要、待機不要で、直接制御できるべきです。

.htaccess / サーバー設定ファイル — 従来の方法です。Apache/Nginx 上の小規模サイトで機能します。問題点: サーバーアクセス、手動編集、デプロイ手順が必要です。1つの構文エラーでサイト全体が停止します。標準の検証、監視、分析機能はありません。

CDNレベルのリダイレクト（Cloudflare、Akamai）はエッジで実行されるため高速で、サイトがすでにそのCDNの背後にある場合は理にかなっています。ルール数の上限、一括オプション、どの機能に有料プランが必要かはプロバイダーごとに異なるため、導入を決める前に、リダイレクトマップの規模と照らし合わせて確認してください。

専用のリダイレクトプラットフォームは、この用途のために作られています。RedirHub を使えば、旧ドメインのルートと www レコードをプラットフォームに向け、移行用 URL マッピングを CSV でアップロードするだけで、各旧 URL をそれぞれの新しいページへ転送できます。リダイレクトは世界 130 か所のエッジロケーションから配信され、接続されたすべてのドメインに対して HTTPS が自動で発行されます。また、クリック分析により、どの旧 URL にまだトラフィックがあるかを確認できます。サーバーへのアクセスやデプロイ作業は不要なため、非技術系のメンバーでもエンジニアの支援なしでリダイレクトを管理できます。

判断フレームワーク: URL が 50 未満でサーバーアクセスがあるなら、.htaccess で対応できます。100 を超える URL、複数ドメイン、または開発者への依存を避けたいチームなら、専用のリダイレクトプラットフォームを使いましょう。

4. 公開前テストツール#

リダイレクトのデプロイから DNS 切り替えまでの間は、エラーを見つけられる最後のチャンスです。検索エンジンに検出される前に、すべてのリダイレクトをテストしましょう。

必須のテスト項目: リダイレクトチェーンを検証する — 1 つのリダイレクトは別のリダイレクトではなく、最終 URL を指す必要があります。チェーンはページ読み込みを遅くし、クローラーを混乱させ、リンク評価を薄めます。httpstatus.io や Screaming Frog の redirect chain checker のようなツールで検出できます。ステータスコードをテストする — 旧 URL が 302（temporary）ではなく 301（permanent）を返すことを確認します。移行中に 302 が返ると、そのリダイレクトは一時的だと Google に伝わり、ランキングシグナルの移行が遅れます。HTTPS 対応を確認する — すべてのリダイレクトは HTTPS で解決される必要があります。Mixed content の警告や HTTP のみのリダイレクトは、移行後によくあるエラーです。特殊ケースをテストする — クエリパラメータ、UTM タグ、末尾スラッシュ、非 ASCII 文字を含む URL です。これらは移行時に最も壊れやすい URL です。ステージングで検証する — 可能であれば、まずステージング環境にリダイレクトをデプロイします。旧 URL → リダイレクト → 新 URL の完全な経路をテストし、新 URL がソフト 404 ではなく 200 を返すことを確認します。

5. 公開後の監視ツール#

公開日はゴールではありません。移行後の最初の 72 時間は極めて重要です。Google がサイトを再クロールし、新しい URL を発見し、リダイレクトの再処理を始めるのがこの時期だからです。この期間に見つかったエラーは SEO への影響が最小限で済みます。数週間後に見つかったエラーは、すでに被害を引き起こしています。

監視スタック: Google Search Console: 最初の1週間はページのインデックス登録レポートを毎日確認し、404やリダイレクトエラーの急増を監視します。重要な古いURLにはURL検査を使って、Googleがリダイレクトを認識していることを確認します。リダイレクト分析: リダイレクトプラットフォームでは、どのリダイレクトにトラフィックがあるか、どれがまったくないか（未使用または設定ミスの可能性あり）、そして訪問者がどこに着地しているかを確認できるはずです。稼働監視: リダイレクトのインフラは基盤そのものなので、リダイレクトエンドポイントにアラートを設定します。ログファイル: Googlebot が新しいURLをクロールしており、行き止まりで時間を無駄にしていないことを確認します。

移行ツール一覧#

移行ワークフロー：どのツールをいつ使うか#

以下に、各フェーズごとの完全なワークフローと、各手順で推奨されるツールを示します。

フェーズ1: 移行前監査 — サイト全体をクロールします。すべてのURLをHTTPステータスコード、canonicalタグ、meta robotsディレクティブ、インデックス可能性ステータス付きで書き出します。ツール: サイト規模に応じて Screaming Frog、Sitebulb、または Lumar を使用します。出力: 既存の全URLを網羅した完全なCSV。Google Search Console と分析プラットフォームで、現在のオーガニックトラフィック、キーワード順位、Core Web Vitals をベンチマークします。

フェーズ2: リダイレクトマッピング — 旧URLと新しい移動先を1対1で対応付けます。予測可能なURL構造にはパターンマッチングを使用します（例: /blog/* → /resources/*）。大規模サイトでは、一括CSVインポートに対応したリダイレクトプラットフォームを使います。1回マッピングすれば、どこへでもデプロイできます。出力: インポート用に検証済みのマッピングファイル（CSV）。

フェーズ3: リダイレクトのデプロイ。マッピングをリダイレクトツール（リダイレクトプラットフォーム、CDNルール、またはサーバー設定での一括リダイレクトインポート）に読み込み、各ソースが正しい移動先へ301で返すことを確認します。次に、旧ドメインが変更される場合はDNSを切り替え、切り替えを素早く行えるよう1日前にTTLを下げておきます。ドメイン変更の場合は、旧ドメインの検証済みバリアントごとに Google Search Console で住所変更を送信します。

フェーズ4: ローンチ前テスト — リダイレクトの10%を手動でスポットチェックします。残り90%には自動チェックを実行します。クエリパラメータ、末尾スラッシュ、大文字小文字の区別、HTTPS などのエッジケースをテストします。リダイレクトのチェーンが一切発生していないことを確認します（A → B → C は不適切、A → C が正しい）。ツール: httpstatus.io、Screaming Frog のリストモード、またはお使いのリダイレクトプラットフォームに内蔵された検証機能。

フェーズ5: 移行後の監視 — 最初の1週間は毎日、その後の1か月は毎週監視します。Search Console のページ インデックス レポート、リダイレクト トラフィック分析、および稼働監視を確認してください。404急増とリダイレクト失敗のアラートを設定します。ツール: Google Search Console、リダイレクト プラットフォームの分析、稼働監視ツール。

危険信号: 移行トラブルを示すツール#

一部のツール選定は、解決する以上のリスクを生みます。避けるべきものは以下のとおりです:

大規模運用での手動のみのリダイレクト管理 — .htaccess ファイルを1つずつ編集してリダイレクトを作成するやり方では、移行は失敗します。100件以上のURLでは、手動入力のエラー率が無視できなくなります。1,000件を超えると、ほぼ確実です。

HTTPSを回避するリダイレクト — リダイレクトツールがすべてのドメインに対してSSL証明書を自動的にプロビジョニングしない場合、それは移行上の脆弱性を生みます。HTTPのみのリダイレクトはブラウザ警告を引き起こし、分析トラッキングを壊し、サイトが完全に सुरक्षितではないことをGoogleに示します。

移行後のヘルス監視なし — デプロイ方法で、公開後のリダイレクト トラフィックや健全性が見えないなら、完全に手探りで進めているのと同じです。移行の2週間後に静かに壊れたリダイレクトは、気づく前に数百のランキング順位を失わせる可能性があります。

ワイルドカードや一括対応なし — プラットフォームがワイルドカード ドメイン（*.example.com）やCSVの一括インポートに対応していないなら、移行向けではありません。すべてのURLに対して個別にリダイレクトを手作業で作成することになり、本来エンタープライズ向け移行ツールが解消すべきボトルネックそのものになります。

正しい構成: クロール、マッピング、デプロイ、テスト、監視#

成功する移行は、常に同じ5つのフェーズをたどります。ツールは規模と予算によって変わりますが、順序は変わりません:

クロール → マッピング → デプロイ → テスト → 監視。

このうち、リダイレクトのデプロイは、ほとんどのチームでツールが最も弱い段階です。サーバー設定、CDNルール、あるいは移行規模のリダイレクト管理向けに設計されていない手動プロセスに依存しています。

専用のリダイレクトプラットフォームがそのギャップを埋めます。エッジ配信により、世界中の訪問者に対してリダイレクトを高速に保ち、1つのCSVアップロードで何千ものマッピングを読み込み、クリック分析で公開前後に何が機能しているかを把握できます。

まずは、現在のリダイレクト基盤を監査することから始めましょう。移行ツールの構成がクローラーとスプレッドシートで止まっているなら、次の移行にはギャップがあります。そしてGoogleはそれを見つけます。