サイト移行

TL;DR — サイト移行とは、URLの移動や Google の読み取り方に影響する大きな変更です。新ドメイン、HTTPS 化、プラットフォーム交換、フォルダ再編、リデザインが該当します。トラフィックを守る方法は共通で、各旧ページを最も近い新ページへ 301 リダイレクトし、長期間維持します。一時的な流入減は普通ですが、回復しない場合は何かが壊れています。

サイト移行とは

「移行」は大げさに聞こえ、実際にそうなることもあります。しかし意味は、検索エンジンによるページの発見、読み取り、ランキングに影響し得る重要なサイト変更です。新ドメインへの移動、http:// から https:// への切り替え、blog.example.com から example.com/blog/ への移動が該当します。URL が同じリデザインも、Google が評価するコンテンツとテンプレートが変わるため移行です。

これらがひとまとめにされるのは、共通のリスクと共通の実行手順を持つからです。

最も重要なたった1つの原則

URL が変わるときは、ページの移動先をブラウザと検索エンジンに伝える必要があります。その手段が リダイレクト、特に「このページは永久にここへ移動した」と示す 301（永久）リダイレクトです。ランキングを旧 URL から新 URL へ実際に運ぶのはリダイレクトです。Google は 301 その他の永久リダイレクトで PageRank は失われないと説明しています。

最重要なのは、各旧ページを、最も関連性の高い新ページ1枚に対応付けることです。すべてをホームページへ送ってはいけません。古い商品ページに完全な対応先がなければ、ホームではなく最も近いカテゴリへ送ります。Google は多数の旧ページからホームへのリダイレクトを 404 と同様に扱うため、利点はありません。

よくある誤解

• 「リダイレクトでリンク評価が失われる」 いいえ。永久リダイレクトは PageRank を失わせません。この通説はとっくに否定されています。
• 「住所変更ツールがサイトを移動する」 いいえ。Google Search Console のこのツールは新ドメインへ移ったと Google に伝えるだけで、実際の作業はリダイレクトです。ドメイン全体の移動にのみ使え、HTTPS 化やフォルダ再編には使えません。
• 「トラフィックが減ったから移行は失敗」 通常は違います。Google が再処理する間の数週間の揺れは普通です。 この主張の根拠 Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. 対象範囲： Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. 信頼度： 高 · 検証日： 2026-07-14 Google Search Central: Site move with URL changes
• 「数か月後にリダイレクトを外せる」 さらに長く、できれば数年、実質的には永久に維持します。

一度に変えるのは1つ

移行の最大リスクは、一度に変えすぎることです。新ドメイン、新プラットフォーム、新 URL 構造を同日に導入すれば3つの移行が重なり、リスクが増幅します。大きな変更を段階に分けられるなら、分けて実施します。

7つのフェーズ、リダイレクト戦略、移行タイプ別チェックリストを含む全手順は、Advanced タブに切り替えてください。

TL;DR — 移行リスクは 変更量 × 同時に行う変更量 です。ランキングを運び PageRank を失わない 301/308 が中核で、住所変更ツール、サイトマップ、内部リンク、カノニカルは補助シグナルです。旧→新を1:1で対応させ、ホームへ一括リダイレクト（ソフト 404）せず、チェーンを避け、「12か月」よりはるかに長く維持します。一時的な揺れと回復は想定内です。回復しない場合は、ステージングのブロック、hreflang/カノニカルの消失、誤った noindex、間違ったリダイレクトなどが壊れています。以下で共通の7フェーズと、7種の移行別の注意点を説明します。

このハブが扱うのは 分類、原則、リスクモデル、移行種別の判断、回復診断 です。実行可能なタスク順、担当者、リリースゲート、受け入れ基準は ウェブサイト移行チェックリスト を使ってください。

移行の実体（7つのタイプ）

サイト移行とは、検索エンジンのクロール、インデックス登録、ランキングに影響し得る URL 構造、ドメイン、プラットフォーム、プロトコル、ホスティングの重要な変更です。1行の HTTPS 切り替えから、新 CMS で数十万 URL を新ドメインへ移す完全なリブランドまで含みます。

リダイレクトを1本も書く前に最も役立つのは、移行を分類することと、現実の移行は複数種が同時に重なると理解することです。おおむねリスク順の7種は次のとおりです。

番号は後述のタイプ別セクション順で、表はリスク順です。リスク = 変更量 × 同時の変更量。URL を変えないリデザインは低リスクですが、ドメイン変更＋URL 再編＋再プラットフォーム化は3つの高リスク変更が複合します。Google も一度に1つずつ変えることを推奨しています。

すべての移行に共通するプロセス

以下は、後述のタイプ固有手順を追加する前に、あらゆる移行に適用するプロセスです。多数の移行で一貫している成功条件は、移行の成功にはチェックリスト以上のものが必要だということです。チェックリスは手順の忘れを防ぎますが、成功を決めるのはプロセスと全段階での SEO 参画です。

フェーズ1 — 計画

• 関係する移行タイプをすべて分類する。 URL 再編とドメイン移動を伴う再プラットフォーム化は3つの移行です。実際のリスクを見積もれるよう、最初にすべて名前を付けます。
• ローンチ前に経営層と期待値を合わせる。 トラフィックはほぼ確実に変動します。一時的な減少は正常と関係者に事前説明し、通常の揺れで恐慌的なロールバックを起こさないようにします。
• 常にロールバック計画を持つ。 極端な状況でしか使わないとしても、元の状態へ戻す手段を用意します。
• 低トラフィック時にローンチする。 Google も可能なら低トラフィック時の移動を勧めています。実務では金曜日や繁忙期でなく月～木曜日にし、問題対応要員を確保し、安定化中の売上リスクを抑えます。
• SEO プロジェクトマネージャーを置き、管理システムを使う。 開発、コンテンツ、解析、SEO に跨る依存関係を担当者が管理します。

フェーズ2 — 旧サイトのベンチマークとクロール

「変更前」の記録なしに移行 QA はできません。旧サイトの稼働中に次を保存します。

• 旧サイト全体をクロール（Screaming Frog、Ahrefs Site Audit など）し、ローンチ後の差分基準として保存する。
• URL ごとにすべて記録: ステータスコード、title、meta description、canonical、hreflang、見出し構造、内部リンク構造、Core Web Vitals。
• 主要ページの ランキングをスナップショットする。
• トラフィック基準をエクスポート: Search Console の過去3/6/12か月の性能データと、ページ/セッション単位の GA4。
• バックリンク上位ページをエクスポート（Ahrefs＋GSC リンクレポート）する。リンク評価を運ぶこれらの URL は必ず正しくリダイレクトする。
• CMS、CDN、.htaccess/サーバー設定、Search Console の リダイレクトがあるページ レポート、解析など すべてのソースから既存リダイレクトを収集する。1つでも落とすとローンチ後にチェーンができる。
• 古いカノニカルエラー、インデックス肥大化、クロールブロックを新ドメイン/CMS へ持ち込まないよう、移行前に レガシー問題を監査する。

フェーズ3 — URL マッピング

1対1のスプレッドシートを作ります。すべての旧 URL → 最も関連性の高い新 URL 1つ。 例外はなく、各 URL の処理先を決めます。

• 近い対応ページがある削除ページ: 最も関連性の高い現存ページへリダイレクトする。Google も、多数の旧 URL をホームなど無関係な1か所へ送らないよう明示しています。 この主張の根拠 Google advises against redirecting many old URLs to one irrelevant destination such as the home page and says that can be treated as a soft 404. 対象範囲： Google Search guidance for site moves with changed URLs; relevant replacements remain appropriate. 信頼度： 高 · 検証日： 2026-07-14 Google Search Central: Site move with URL changes
• 同等ページが全くない: 正式な 410（削除済み）または 404 を返す。ソフト 404 と見なされるためホームへはリダイレクトしない。
• 各 URL の元と移行先を明確に追跡することが最重要です。このマップ自体が移行です。

フェーズ4 — リダイレクト戦略

ここがプロジェクト全体の背骨です。

• 永久移動には 301（Moved Permanently）または 308 を使う。 Google はサーバー側の 301/308 を推奨します。
• 301 は PageRank を渡す。 Google は永久リダイレクトで PageRank は失われないと説明し、Gary Illyes も 30x で失われなくなったと確認しています。漏れるという解説は古いものです。 この主張の根拠 Google says 301 and other permanent redirects do not cause a loss in PageRank. 対象範囲： Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. 信頼度： 高 · 検証日： 2026-07-14 Google Search Central: Site move with URL changes
• リダイレクトチェーンを避ける。 旧→新へ直接対応させます。Google は理想は3以下、5未満とし、Googlebot は約10ホップ追跡しますが、各ホップは故障とシグナル統合遅延の機会です。末尾スラッシュ（/page と /page/）の不統一もよくある原因なので、1つのカノニカル形式に統一する。
• ページだけでなく、画像、PDF、その他の非 HTML ファイルもリダイレクトする。
• サーバー側で実装する。 JavaScript リダイレクトは最終手段であり、レンダリングに失敗すれば Google は処理しない可能性がある。
• 一時と永久を混同しない。 302/307 は移行先をカノニカルとするシグナルではなく、旧 URL がインデックスに残りシグナルもほぼ残る。本当に一時的な場合のみ使う。
• 「1年」よりはるかに長く保つ。 Google の下限は「少なくとも1年」ですが、Illyes は約12か月は Google のためであり、ユーザーのために実質永久に保つとよいと補足しています。Bing は最低1～2年寄りです。旧 URL に流入またはリンクがある限り、実務上は無期限に維持します。 この主張の根拠 Google recommends keeping site-move redirects as long as possible, generally for at least one year. 対象範囲： Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. 信頼度： 高 · 検証日： 2026-07-14 Google Search Central: Site move with URL changes

フェーズ5 — ステージングとローンチ前テスト

• ステージングサイトのインデックス登録をブロックする。ステージングホストに noindex や robots.txt の Disallow を使い、dev へのアクセスも制限する。このブロックはフェーズ6で必ず解除すると記録する。
• 公開テストには beta.example.com などの 一時ホスト名を使う。
• 全リダイレクトを旧→新でテストし、旧 URL 全リストをステージングに対してクロールし、各1ホップで意図した本番ページに到達することを確認する。
• ステージングクロールをフェーズ2基準と比較し、title、meta description、canonical、hreflang、構造化データ、meta robots、内部リンク、ページ速度を差分化する。
• カノニカルがステージング URL でなく本番を指すことを確認する。
• GA4、GSC 確認、タグマネージャーが動作することを確認し、フォーム、決済などのコンバージョン経路をテストする。
• ファイアウォールや DoS 保護が Googlebot をブロックせず、DNS とホストへ到達できることを確認する。

フェーズ6 — ローンチ

• クロールブロックを直ちにすべて解除する。構築用の noindex とステージング robots.txt ルールを除去する。最も多い移行事故はこのブロックを残したまま本番化すること。
• 301 リダイレクトをすべて同時に有効化する。
• 現在の本番 XML サイトマップを新カノニカル URL のみに更新し、再送信する。旧 URL サイトマップがリダイレクト発見や監視に役立つ場合は、明確に一時的な別サイトマップとして送信し、旧と新を混ぜず、役目を終えたら削除する。Google の サイト移動ガイダンス を参照。
• GSC URL 検査ツールでリダイレクトを抜き取り確認する。
• 住所変更ツールを送信するのはドメインレベル移動のみ。
• Bing には現行方式の IndexNow で送信する。旧 Site Move ツールは 2021 年頃に廃止され、IndexNow なら移行後の URL を一括送信できる。
• サーバー容量を確保する。 移行直後は Google が通常より多くクロールする。

フェーズ7 — ローンチ後の監視

• 一時的な変動を想定する。 Google は移動中のランキング変動を想定するよう説明しています。低下だけで失敗とは言えません。Martin Splitt は URL 構造と内容をそのまま新ドメインへ複製するなら、低下しないこともあると指摘します。
• 期間を理解する。 Google では中規模サイトの大半がインデックス内で移動するのに数週間、大規模サイトはさらに長くかかります。完全安定化は通常数か月。
• 回復しない低下を診断する。 Gary Illyes によれば、移動後の低下は移動自体ではなく、新サイトで欠落・誤設定されたタグ/ディレクティブ（hreflang の消失、余分な noindex、壊れた canonical）が主因です。最初にこれらを調べる。
• リダイレクトを一括 QA し、旧 URL 一覧を再クロールし、各ページが正しい本番ページへ 301 を返し、チェーンや末尾 404 がないことを確認する。
• カノニカル選択を監視する。 外部および古い内部リンクが旧 URL を指し続けると Google が新でなく旧 URL を登録し続ける可能性がある。内部リンク更新はリダイレクトと同じく重要で、主要リンク元に直接リンクへの変更を依頼する価値もある。
• GSC のページのインデックス登録、ページ別クリック/表示回数、クロール統計、新しい手動対策を監視する。最初の1か月は毎週ランキングを保存。Bing は移行後少なくとも3か月のサーバーログ監視を勧める。

リダイレクトは効いたか：誤判定せずに影響を測る

ローンチ当日のスクリーンショットだけで移行を評価しないでください。ローンチ前に旧 URL、新 URL、クエリ/ページグループ、指標を固定し、同じコホートを4つの時点で読み取ります。

各時点で、変更後と同等の変更前期間を比較し、変更当日を除外します。当日は旧新状態、部分デプロイ、キャッシュ変更、QA トラフィック、計測断絶が混ざるため、どちらに入れても比較が汚染されます。コホートと指標定義を固定し、ブランド/非ブランド、デバイス、国、テンプレート、移行種別の分割は測定計画にある場合のみ行います。

増減の原因を移行とする前に、期間内のリリース、コンテンツ更新、計測変更、季節性、キャンペーン、Google の 確認済みランキング更新履歴 を注記します。アルゴリズム更新と重なっても移行の無罪・有罪は決まりません。帰属が交絡するため不確実性を報告し、レスポンステスト、インデックス範囲、カノニカル選択、サーバーログなどの直接実装証拠を重視します。

「変化なし」も有効な結果です。 URL 移動中にアクセス、シグナル、コンバージョンを保つことがリダイレクトの仕事です。正しい1ホップ応答でパフォーマンスが横ばいなら成功し得ます。データの裏付けのない成長話を探さず、そう記録します。

計画中の Before/After Impact Checker はこの段階に入ります。公開後は変更当日の除外と 7/14/30/90 日比較を標準化できます。それまではスプレッドシートやレポート層を使い、各時点の正確な日付範囲、フィルター、コホート、注記を保存します。

7種の移行

作業の大半は上記の共通プロセスです。以下は各タイプに固有の、見落としやすい注意点と必須事項です。

タイプ1 — ドメイン変更 / リブランド

内容: oldbrand.com の全ページを newbrand.com へ移すこと。新ドメイン、新 GSC プロパティを使い、理想的には URL 構造は同時に変えません。

リスク: 最高。 全 URL が変わり、外部リンクの更新が必要で、GSC 履歴も2プロパティに分かれます。

注意点と必須事項:

• ドメイン変更とリデザイン、URL 再編を同時に行わない。 Google も、ドメイン移動とコンテンツ/URL 構造のリデザインを組み合わせるとトラフィック損失の可能性があると警告する。まずドメインを移し、再編は後にする。
• 登録前に新ドメインの履歴を調べる。 archive.org で確認し、手動対策履歴のある中古ドメインから不利なスタートを切らない。
• 旧ドメインを失効させない。 更新とリダイレクトを継続する。他者に取得されるとリダイレクトとリンク評価が失われる。
• ドメイン移動をチェーン化しない（A → B の直後に B → C）。住所変更ツールは連鎖できない。

住所変更ツールがすること・しないこと。 ここに誤解が集中します。このツールは Google に新サイトのクロール/インデックスを優先させ、シグナルを転送し、新サイトのカノニカルを 180日間 優先させます。重要な制約は次のとおりです。

• パス範囲のないドメインまたはサブドメイン移動に使い、個別ページやフォルダの移動には使えない。
• 対象となる旧新 Search Console プロパティの確認済み所有者である必要がある。ドメインプロパティと ルート URL プレフィックスプロパティは対象になり得るが、パス限定 URL プレフィックスは不可。Google の 住所変更要件 と プロパティ適格性 を参照。
• 厳密な1対1移動専用で、統合や部分移動には使えない。
• 任意であり必須ではない。 追加シグナルにすぎず、リダイレクトが正しければ使わなくても問題ない。実作業は 301 で、ツールは伝達を速く明確にするだけ。（検索エンジンツールクラスターに専門解説があります。）

180日の期間はリダイレクトの期限ではありません。 180日後、Google はツールを通じた旧新サイトの関係を認識せず、旧サイトを無関係と扱います。だからリダイレクトはツールより長く保ちます。Google の下限は1年、実務ではさらに長く維持します。

タイプ2 — HTTP → HTTPS

内容: 暗号化されていない HTTP から HTTPS（TLS/SSL）への移動。全 URL が http:// から https:// へ変わります。HTTPS は 2014 年から弱いランキングシグナルで、現在 HTTP は明確な不利です。

正しく行えば リスク: 低～中。証明書や混合コンテンツの問題が出ると 高。

注意点と必須事項:

• 住所変更ツールは使わない。 Google は HTTP → HTTPS にはサイト移動ガイドを使うよう明示する。
• すべてを HTTPS ホームへ送るルールではなく、URL ごとの 301 を使う。単なるプロトコル移動と明確に示すほどスムーズに切り替わる。
• 混合コンテンツを修正する。 HTTPS 化後も HTTP で読み込む画像、スクリプト、CSS は警告と矛盾シグナルを生む。プロトコル相対/相対 URL を使い、CSP upgrade-insecure-requests で取りこぼしを早く処理できる。
• Google は HTTPS を自動的にカノニカルとして優先するが、証明書が無効、依存リソースが非安全、HTTP へ戻すリダイレクト、その他の矛盾シグナルがある場合は例外。証明書不備は HTTP がカノニカルのままになる原因にもなる。
• HSTS は慎重に。 一定期間 HTTPS のみに接続させるため、TLS が確実に安定する前に有効化すると、証明書エラーで再訪問者が完全にアクセスできなくなる。確信後に低い max-age から始め、段階的に上げる。
• 強い証明書（2048-bit RSA または EC、Qualys SSL テスト A/A+）を使い、Cookie に Secure フラグを設定する。

タイプ3 — プラットフォーム / CMS 再構築

内容: 新 CMS または技術スタックへの移動（例: WordPress → headless、Magento → Shopify）。URL、テンプレート、内部リンク、レンダリングの変更を伴うことが多い。

リスク: 高。 複数の要素が同時に変わるためです。

注意点と必須事項:

• URL 変更を想定する。 プラットフォームごとに slug 構造、カテゴリ階層、ページネーションが異なる。選定後ではなく決定前に URL マップを作る。
• リダイレクトは自動で引き継がれない。 .htaccess の古いルールが新ホストへ複製されないのは典型的な失敗。新層の構築前に CMS、CDN、サーバー設定、GSC の リダイレクトがあるページ から全ルールを収集する。
• 構造化データを再実装し、スキーマが引き継がれると決めつけずローンチ後に検証する。
• headless/SPA へ移るなら JavaScript レンダリングをテストする。レンダリングは Googlebot の処理を変え、特に JavaScript コンテンツは移行後 QA の重点項目。
• ページ速度とモバイルをベンチマークする。新テーマは重くなりがちで、Google はモバイル版を登録するため、新環境が遅くない/壊れていないことを確認する。
• プラットフォームごとに扱いが異なるため 末尾スラッシュを統一し、ひそかなチェーンを防ぐ。
• ローンチ前に新環境へ GA4、GSC、タグマネージャーを再配置する。
• URL、内部リンク、テンプレートが同時に変わる大きな再編では Google が旧サイトの理解をそのまま保てないため、同等移動より安定化に時間がかかる。

タイプ4 — URL 構造 / サイト再編

内容: 同一ドメイン内の URL パスを変えること。例: /category/post/ → /post/。ドメインは同じで、コンテンツは変わる場合も変わらない場合もあります。

リスク: 中。 ドメインの権威は保たれますが、変更 URL ごとにリダイレクトが必要で、内部リンクグラフも更新します。

注意点と必須事項:

• 忘れられがちなのは内部リンク。 URL はリダイレクトしても rel=canonical、ナビ、フッター、本文リンクを更新し忘れるパターンが多い。古いシグナルが残ると、リダイレクトがあっても Google が新 URL をカノニカルに選びにくい。
• カノニカル化は遅れ得る。 旧 URL のバックリンクが多く、内部リンクも旧 URL を指すと、301 後も Google が旧 URL を優先することがある。内部リンクを新 URL へ直接更新することが不可欠。
• 同一ドメイン内の再編に 住所変更ツールは使わない。 Google の指示はリダイレクトとサイトマップ更新のみ。
• パンくず、ナビ、サイトマップを新パスへ更新する。サイトマップには新 URL だけを載せる。

タイプ5 — ウェブサイトのリデザイン（URL は同じ）

内容: ドメインと URL は同じで、テンプレート、コピー、ナビ、画像、ページ内 SEO 要素を変えるリデザイン。最低リスクですが、ゼロではありません。

リスク: 低。 ただしページ内変更でランキングは動き得ます。

注意点と必須事項:

• ページ内要素は気付かないうちに壊れる。 リデザインで <title>、meta description、見出し構造、構造化データが削除/変更されがちなので、旧サイト基準と項目ごとに照合する。
• 内部リンクを監視する。 ナビ再設計で深いページに権威を渡す重要リンクが消えることがある。
• Core Web Vitals を前後で測る。 新 CSS、JS、フォント、画像はほぼ必ずページ速度を変える。
• コンテンツ変更を意図的に行う。 「同じ URL」のリデザインでも内容が薄く/統合されがちで、薄いページが同じ性能とは限らない。
• ここでの参照は Google の URL 変更なしのサイト移動 ガイド。URL を変えずインフラや表示を変えるときの影響を最小化する。

タイプ6 — サブドメイン ↔ サブフォルダ

内容: サブドメインとサブフォルダ間のコンテンツ移動。代表例は blog.example.com → example.com/blog/。統合により2ホストに分かれた権威を1つにまとめます。

リスク: 中～高。 Google は多くの目的でサブドメインとルートを別実体と扱うため、統合で実質的な再インデックスの変動が起きます。

注意点と必須事項:

• Google にとって両者は別実体で、クロールバジェットもシグナルも一部別です。サブフォルダへの統合はプラスになりがちですが、時間がかかり実際の移動と同じ挙動をする。
• 同一ルートのサブドメイン→サブフォルダ移動に 住所変更ツールは使わない。www/非 www と同系統で、ツールではなく canonical/リダイレクトで処理する。
• GSC プロパティ: サブドメインとルートに別プロパティがあることが多い。統合後はデータがルート側に流れるため、サブドメイン側のカバレッジ減少とルート側の増加を監視する。
• 全サブドメイン URL を対応するサブフォルダへリダイレクトし、内部リンクはリダイレクト経由でなく新 URL へ直接更新する。サブドメインのバックリンク評価は 301 でメイン側へ渡るが、主要リンク元への更新依頼も役立つ。
• 解析を調整する。サブドメインが独自/クロスドメイン計測だった場合、GA4 を再設定して連続性を保つ。

タイプ7 — ドメイン統合 / サイト合併

内容: 複数の別サイトを1つに統合すること。例えば買収した競合のコンテンツをメインドメインへ組み込む、ブランドの国/商品別サイトを合併するなど。

リスク: 非常に高い。 1対1の移動でないため標準的な移行とは言えず、Google にとって統合後の実体は多くの点で実質的に新サイトです。Martin Splitt は、2サイトの統合は移行というより、複合版から新サイトを作ることだと表現しています。

注意点と必須事項:

• 住所変更ツールは使えない。 1ドメインから別の1ドメインへの1対1移動が前提で、合併は該当しない。URL ごとに作業する。
• 一定のトラフィック損失を想定する。 Google は A、B、C をすべて新 D へ移すと混乱と流入減が起き得ると警告する。長い安定化期間を計画する。
• まず重複を解消する。 トピックが重なるサイトを合併すると重複コンテンツができる。リダイレクト前にトピックごとのカノニカルページを決める。
• URL ごとに最も関連性の高いページへリダイレクトする。買収ドメイン全体をホームへ一括送信すると、ホーム以外はすべてソフト 404 になる。実際の同等ページへ送るとページ単位のリンク評価が最もよく移る。
• 合併する各サイトの GSC プロパティを維持し、それぞれのカバレッジ減少とメインドメインの増加を並行監視する。

専門ガイドを選ぶ

解決したい判断または失敗モードに合うガイドを使ってください。

• ホスティング移行 SEO — URL を維持したサーバー、CDN、DNS、ホスティング変更。
• CMS 移行 SEO — テンプレート、レンダリング、データ同等性リスクを含むプラットフォーム/CMS 変更。
• URL 構造の移行 — 同一ドメイン内のパス、分類、フォルダ変更。
• サイト分割 / カーブアウト SEO 移行 — 1サイトの明確な部分を別プロパティへ移す場合。
• 買収後の SEO 統合 — 買収したサイト、ブランド、コンテンツの統合方法を決める場合。
• 移行後のトラフィック減少 — ローンチ後に回復しない検索可視性またはトラフィックの診断。

この記事の位置付け

移行は、実際に評価を運ぶ リダイレクト、Google が残す URL を決めるカノニカル化、HTTPS、国際サイトの hreflang、ドメイン移動を伝える住所変更ツールなど多くの隣接トピックにまたがります。それぞれ専門解説はありますが、すべての移行の背骨は同じです。旧→新を1対1で対応させ、永久リダイレクトを長期維持し、移行後に正しいシグナルを監視します。

AI 要約

Advanced 版の要点は次のとおりです。

• サイト移行とはクロール、登録、ランキングに影響する URL、ドメイン、プラットフォーム、プロトコル、ホストの大変更。リスク = 変更量 × 同時変更量。
• 7種のリスク順: リデザイン（低）→ HTTP→HTTPS（低～中）→ URL 再編（中）→サブドメイン↔サブフォルダ（中～高）→ CMS 再構築（高）→ドメイン変更（最高）→ドメイン統合（非常に高い）。
• 共通7フェーズ: 計画/分類→旧サイト計測/クロール→1:1 URL マップ→リダイレクト戦略→ステージング/事前テスト→ローンチ→監視。
• 301/308 が中核。 ランキングを運び PageRank を失わない。住所変更、サイトマップ、内部リンク、canonical は補助シグナル。
• 旧→新を1:1で対応。 ホームへ一括送信せず（ソフト 404）、チェーンは約3～5ホップ未満、リダイレクトは実質永久に保つ。
• 一時的な変動と回復は通常。 回復しない低下はステージングブロック、hreflang/canonical 消失、noindex、誤リダイレクトなどの故障。
• 住所変更ツール: ドメイン全体の厳密な1:1移動のみの任意シグナル。HTTPS、同ドメイン内再編、合併には不可。
• Bing: 旧 Site Move は 2021 年頃に廃止。URL 送信は IndexNow、リダイレクトは1～2年維持寄り。

公式ドキュメント

検索エンジンによる一次資料です。

Google

• URL 変更を伴うサイト移動 — リダイレクト、タイミング、期待値、約1年の維持を扱う主プレイブック。
• URL 変更のないサイト移動 — ホスティング/インフラ/リデザイン、一時ホスト、DNS、ファイアウォール/DoS。
• リダイレクトと Google 検索 — 永久と一時、JavaScript リダイレクトのリスク。
• 住所変更ツール — 対応範囲、プロパティ要件、除外、リダイレクト。
• 重複 URL の統合 — HTTPS のカノニカル優先と、301 が一時リダイレクトより強いシグナルである理由。
• カノニカル化 — Google のカノニカル選択（命令でなくヒント）。
• サーバーで HTTPS を有効化 — TLS 証明書、混合コンテンツ、HSTS。

Bing / Microsoft

• Bing でのウェブサイト移行 — Bing の移行フレームワーク、リダイレクト期間、ログ監視。
• IndexNow — 移行 URL を Bing へ送信する現行手段（旧 Site Move は廃止）。

出典からの引用

Google の公的発言です。各リンクは出典ページ内の引用箇所へ移動します。

Google — リダイレクトと PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” 訳：「301 その他の永久リダイレクトで PageRank は失われない。」 — Search Central。Jump to quote
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” 訳：「チェーン内のリダイレクト数を少なく、理想は3以下、5未満に。」 — Search Central。Jump to quote
• “Keep the redirects for as long as possible, generally at least 1 year.” 訳：「リダイレクトは可能な限り長く、通常は少なくとも1年維持する。」 — Search Central。Jump to quote
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page” 訳：「多数の旧 URL をホームなど関連のない1 URL へリダイレクトしない。」 — Search Central。Jump to quote

Google — 期待値と所要時間

• “Expect temporary fluctuation in site ranking during the move.” 訳：「移動中はサイトのランキングの一時的な変動を想定する。」 — Search Central。Jump to quote
• “a medium-sized website can take a few weeks for most pages to move in our index” 訳：「中規模サイトで大半のページがインデックス内で移動するには数週間かかる。」 — Search Central。Jump to quote
• “Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs.” 訳：「旧サイトから新サイトへのリダイレクトを確認する。間違った（存在しない）URL へ送る例をよく見る。」 — Search Central。Jump to quote

Google — 住所変更ツール（180日）

• “Maintain the redirects for at least 180 days—longer if you still see any traffic to them from Google Search.” 訳：「リダイレクトは少なくとも180日、Google 検索から流入が残るならさらに長く維持する。」 — Search Console Help。Read the source
• “After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site.” 訳：「180日後、Google は旧新サイトの関係を認識せず、旧サイトを無関係なサイトと扱う。」 — Search Console Help。Read the source

Google — HTTPS カノニカルとリダイレクトシグナル

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” 訳：「問題や矛盾シグナルがなければ、Google は同等の HTTP より HTTPS ページをカノニカルとして優先する。」 — Search Central。Jump to quote
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” 訳：「Googlebot は一時リダイレクトを追跡するが、登録パイプラインは移動先をカノニカルにするシグナルに使わない。」 — Search Central。Jump to quote

Google — ローンチとインフラの注意

• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” 訳：「Googlebot が DNS やホスティング事業者のサーバーに到達する能力を妨げないこと。」 — Search Central。Jump to quote
• “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” 訳：「ローンチ直後に Googlebot のクロール頻度が一時的に下がり、続く数日で着実に上がるのは正常。」 — Search Central。Jump to quote

移行のマスターチェックリスト

移行種別に関係なく毎回これを実行し、下のタイプ別リストを追加します。

ローンチ前

• 関係する全移行タイプを分類し、高リスクの同時実施を回避。
• 一時的な低下は正常と関係者に説明し、低トラフィック時にローンチ。
• ロールバック計画を文書化しテスト。
• 旧サイト全体のクロールを QA 基準として保存。
• ランキング、GSC 過去3/6/12か月、GA4、バックリンク上位ページを出力。
• CMS、CDN、サーバー設定、GSC の リダイレクトがあるページ から全リダイレクトを収集。
• 旧→新 URL の1対1マップを作成。削除ページはホームでなく 410/404。
• 301/308、1ホップ、画像/PDF も対象の計画。
• ステージングを noindex や robots.txt でブロックし、ローンチ時の解除を記録。
• ステージングと基準の title、meta、canonical、hreflang、構造化データ、meta robots、内部リンク、速度を差分化。
• ステージングの canonical は本番 URL を指す。
• 全リダイレクトが1ホップで意図したページに到達。
• 解析/確認タグ、フォーム、コンバージョン経路をテスト。
• ファイアウォール/DoS が Googlebot をブロックしない。

ローンチ当日

• 全ステージングブロック（noindex、robots.txt）を解除し本番で確認。
• 全 301 を有効化。
• 本番 XML サイトマップを新 canonical URL のみに更新し GSC に再送信。
• 必要なら旧 URL 用の一時的な別サイトマップを、担当者と削除条件付きで送信。
• GSC URL 検査でリダイレクトを抜き取り確認。
• ドメイン全体移動のみ住所変更ツールを送信。
• IndexNow で Bing に移行 URL を送信。
• 増加するクロールに対するサーバー容量を確保。

ローンチ後

• 旧 URL を一括再クロールし、正しい本番ページへ 301 を返す。
• 内部リンクを新 URL へ直接更新。
• GSC のページ登録、ページ別パフォーマンス、クロール統計、手動対策を監視。
• 最初の1か月は毎週ランキングを保存。
• 主要外部リンク元へ更新を依頼。
• リダイレクトは180日でなく数年維持。
• 低下が続くなら hreflang 消失、noindex、canonical 不備、誤リダイレクトを先に確認。

タイプ別チェックリスト

タイプ1 — ドメイン変更 / リブランド

• archive.org で新ドメインの過去利用を確認し、旧ドメインの更新を確保。
• パスのない旧新 GSC ドメイン/ルート URL プレフィックスプロパティの所有を確認。
• 旧ホーム→新ホームの 301（ツール要件）。
• canonical、内部リンク、サイトマップを全サイトで新ドメインへ更新。
• サブドメインと www/非 www ごとに住所変更を送信。
• disavow ファイルを新プロパティへ移し、リデザイン/再編と同時に行わない。

タイプ2 — HTTP → HTTPS

• 有効な証明書（2048-bit RSA/EC、Qualys A/A+）と URL ごとの http→https 301。
• 混合コンテンツを修正（相対 URL、upgrade-insecure-requests CSP）。
• canonical、sitemap、robots.txt、hreflang を HTTPS 化し、Cookie に Secure。
• TLS 安定後のみ HSTS を低い max-age から追加。
• 住所変更ツールは使わない。

タイプ3 — プラットフォーム / CMS 再構築

• プラットフォーム確定前に旧→新 URL マップ。
• CMS＋CDN＋サーバー設定＋GSC からリダイレクトを収集（.htaccess を失わない）。
• 末尾スラッシュを統一し、構造化データを再構築/検証。
• headless/SPA の JavaScript とモバイルレンダリング、速度をテスト。
• GA4/GSC/タグマネージャーを再配置。

タイプ4 — URL 構造 / 再編

• 完全な旧→新マップと URL ごとの 301。
• ナビ、パンくず、フッター、本文、関連記事を含む全内部リンクを更新。
• rel=canonical を新 URL にし、サイトマップは新 URL のみ。
• 同ドメイン内のため住所変更ツールは不使用。
• 新サイトをクロールし、古いリダイレクト URL への内部リンクがない。

タイプ5 — ウェブサイトのリデザイン（URL 同一）

• 旧サイトの title、description、H1、canonical、構造化データを保存し、ローンチ後に差分化。
• ナビ再設計で高価値内部リンクを保持。
• Core Web Vitals を前後比較。
• 意図しない内容の薄型化を防ぎ、解析が動作。

タイプ6 — サブドメイン ↔ サブフォルダ

• サブドメインをクロールし、blog.example.com/post/ → example.com/blog/post/ の全マップ。
• 全 URL を対応するサブフォルダへ 301、内部リンクも直接更新。
• 同一ルート移動に住所変更ツールは不使用。
• 両 GSC プロパティと解析を監視/再設定。

タイプ7 — ドメイン統合 / 合併

• 各統合サイトのクロール、ランキング、バックリンク、GSC を監査。
• 重複コンテンツを解消し、リダイレクト前にトピックごとの canonical を選定。
• ホームへの一括送信ではなく最も関連性の高いページへ URL ごとに 301。
• 1:1 でないため住所変更ツールは不使用、長期安定化を計画。
• 各サイトの GSC プロパティを保持し、メインドメインと併せてカバレッジを監視。

思考モデル

1. リスク = 変更量 × 同時に変える量。 まず関係するタイプを分類します。URL 同一のリデザインは1つの低リスク変更、ドメイン移動＋URL 再編＋再プラットフォーム化は3つの高リスク変更です。段階化できるなら、1度に1つずつ変えます。

2. 実作業はリダイレクト、他はシグナル。 ランキングを運ぶ機構は 301 です。住所変更、サイトマップ送信、内部リンク更新、canonical は処理を速く正確にする補助シグナルです。まずリダイレクトを作り、他を代替でなく促進剤と扱います。

3. ホームへ全送るより1:1対応。 各旧 URL を最も関連性の高い新 URL 1つに対応させます。ホームへの大量リダイレクトはソフト 404 と扱われ、ページ単位のリンク評価を失います。対応先がなければ 410/404 を使います。

4. ツールの期間はリダイレクトの寿命ではない。 住所変更ツールは180日間シグナルを転送しますが、リダイレクトは数年長く保ち、旧 URL に流入/リンクがある限り維持します。

5. 一時的な低下は正常、回復しない低下はバグ。 数週間～数か月の揺れと回復を想定します。戻らなければ移動自体を責めず、残留ステージングブロック、hreflang 消失、noindex、canonical 不備、誤リダイレクトを探します。

6. canonical 選択で内部リンクはリダイレクトと同じく重要。 ナビ、フッター、本文、外部リンクが旧 URL を指すと、リダイレクトが完璧でも Google は旧 URL を登録し続け得ます。内部リンクを新 URL へ直接更新し、重要な外部リンク元にも依頼します。

移行チートシート

状況別リダイレクト

移行種別のツール / シグナル

Bing の対応手段

要点

• 301 は PageRank を失わない。この通説は 2016 年頃から否定済み。
• チェーン: 約3～5ホップ未満（Googlebot は約10ホップ追跡）。
• 180日は住所変更ツールの期間で、リダイレクト期限ではない。実質永久に維持。
• 再登録: 中規模は「数週間」、大規模はさらに長い。
• 回復しない低下の第1原因: 移動ではなく新サイトの hreflang、noindex、canonical の欠落/誤設定。

どの移行タイプか、住所変更を使えるか？

最大の変更で1回たどり、同じリリースの追加変更ごとに再実行します。パスとドメインも変わる再プラットフォーム化は1つでなく3つの移行です。

プレイブック：ローンチ後にトラフィックが減り、回復しない

想定されるローンチ時の変動が収まらないときに使います。サイト全体のアクセス障害から URL 単位のシグナル衝突へ進み、実装が潔白と分かるまで「移動」のせいにしません。

ステップ1 — 低下が実在し、範囲が明確か確認。 ローンチ前と同じページ、クエリ、市場、解析定義を比較します。レポートだけが消えたなら計測を修正。旧 URL が下がり新同等 URL が上がるなら通常の交差を監視。両方下がるならステップ2へ。

ステップ2 — サイト全体のクロール/登録ブロックを確認。 クローラーとして本番を取得し、robots.txt、meta robots、X-Robots-Tag、認証、ファイアウォール、DNS、ステータスを確認。ステージングの noindex、Disallow: /、認証壁、bot ブロックが本番化されたら除去し直ちに再クロール。アクセス/登録可能なら続行。

ステップ3 — 旧→新マップ全体を再テスト。 リンク/流入上位から旧 URL 全件を調べ、404、無関係な到達先、ループ、チェーンを修正して最終同等 URL へ1ホップ化。正しいなら続行。

ステップ4 — 新ページを基準と差分化。 canonical、hreflang、title、見出し、本文、構造化データ、内部リンク、レンダリング HTML を比較。テンプレート全体のタグ消失やステージング/旧 URL への指定は個別ページより先に修正。同等なら続行。

ステップ5 — 統合シグナルを確認。 新 URL が self-canonical、内部リンク/ナビが直接指定、本番サイトマップが新 canonical のみか確認。別の旧 URL サイトマップは役立つ間だけ保持。URL 検査で Google 選択 canonical を抽出し、旧/無関係 URL が選ばれるなら衝突リンク、canonical、sitemap 項目を除去し再クロールを待つ。

ステップ6 — 容量とサーバー証拠を確認。 新ホストのクロール統計/アクセスログで Googlebot の応答と活動を読み、エラー、遅延、rate limit、ファイアウォール認証が増えれば容量/アクセスを復旧。正常なら移行タイプ/テンプレート別にエスカレート。

ステップ7 — ロールバックは本番化された不具合が証明されたときだけ。 合意済みトリガーを満たし、クロール差分が可逆なテンプレート/プラットフォーム/設定不具合と低下を結び付けた場合のみ戻す。初日の揺れだけで戻すと、検索エンジンが処理する予定外の移行をもう1つ追加する。

実際の失敗を生む移行の通説

「永久リダイレクトでリンク評価が失われる」 誤りです。Google は PageRank は失われないと説明しています。実際のリスクは間違った到達先、チェーン、ループ、行き止まりであり 301 自体ではありません。各旧 URL を最も近い同等ページへ直接対応させ、最終応答をテストします。

「住所変更がサイトを移してくれる」 誤りです。厳密なドメイン全体移動の任意補助シグナルで、リダイレクトは作らず、HTTPS、パス再編、部分移動、合併には使えません。まずリダイレクトマップを作り、範囲が合う場合だけツールを使います。

「トラフィック減は必ず移行失敗」 誤りです。検索エンジンが処理する間、ランキング、クロール、別の旧 URL サイトマップを使う場合のサイトマップ交差は想定内です。事前に基準とロールバック条件を合意し、通常ノイズでなく継続または構造的に説明できる低下を診断します。

「数か月後にリダイレクトを外せる」 誤りです。Google の1年は処理の下限であり、ブックマーク、バックリンク、利用者の有効期限ではありません。旧 URL に流入/リンクがある限り、通常は無期限に維持し、旧ドメインも所有し続けます。

移行のマッピングと検証用ツール

• Redirect Map Builder — 旧新 URL 集合から信頼度、未対応行、410 リスト、チェーン平坦化、手動上書き、プラットフォーム出力付きの 301 案を作成。公開前に全提案の編集的同等性を確認。
• Redirect Chain Mapper — 全ホップ、ステータス、ホスト/パス変更、meta refresh、整理ルールを追跡。ステージング抽出とスラッシュ/プロトコル/ドメインルールの積み重なりに使用。
• Redirect Checker — 1 URL または小バッチの最終ステータス、ホップ、到達先を迅速確認。全旧 URL の証明にはフルクローラーが必要。
• フルサイトクローラー — 事前基準の保存、全リダイレクトテスト、title、canonical、hreflang、ディレクティブ、リンク、schema、レンダリングの差分化。
• Google Search Console — ページ登録、パフォーマンス、サイトマップ、クロール統計、URL 検査、対象ドメイン全体移動のみ住所変更。
• サーバーアクセスログ — bot が新ホストに到達するか、応答は何か、インフラ撤去前も旧 URL が要求されるかを証明。

移行がマップどおり本番化されたことを証明する

旧 URL 全件のリダイレクトテスト

• テスト: フェーズ2の旧 URL 全件を本番に対してクロールし、Redirect Chain Mapper または Redirect Checker で失敗を調査。
• 期待結果: 全移動 URL が意図した同等先へサーバー側 301/308 の1ホップ、意図的削除は 404/410。
• 失敗の意味: 旧 URL の 200、チェーン、ループ、無関係な到達先、予定外 404 はマップ/ルール順が承認どおり本番化されていない。
• 監視: ローンチ直後、修正デプロイごと、旧 URL のクロールが多い初期。
• ロールバック: 系統的なマッピングルールで重要な保護セクションが誤到達/到達不能になり、現地修正できない。

新ページの登録可能性と canonical テスト

• テスト: 新 URL のステータス、robots ディレクティブ、canonical をクロールし、代表的な重要ページに URL 検査を使用。
• 期待結果: 200、ブロック/noindex なし、意図した新 canonical。再クロール後は Google も抜き取りで意図した canonical を報告。
• 失敗の意味: サイト全体のステージング指定、旧/ステージング canonical、認証、異なる Google 選択 canonical はローンチ設定の衝突。
• 監視: 技術シグナルは即時。Google 選択 canonical/インデックス移動は再クロールが必要で、中規模で数週間、大規模ではより長い。
• ロールバック: 保護対象に影響する本番全体のクロール/登録ブロックまたはテンプレート canonical 不具合を迅速に除去できない。

リンクとサイトマップの到達先テスト

• テスト: 内部リンクをクロールし、送信 sitemap を解析し、全到達先を承認済み新 canonical URL 集合と比較。
• 期待結果: ナビ/内部リンクは新 URL を直接指し、本番 sitemap は正常応答の canonical 新 URL のみ。任意の旧 URL sitemap は別、一時的、削除条件付き。
• 失敗の意味: 古い内部リンク、旧新が混ざる sitemap、役目後も残る旧 URL sitemap は交差を遅らせ/見えにくくする。
• 監視: レンダリング済みサイト/sitemap で即時。移行後に送信 sitemap の処理を確認。
• ロールバック: ナビまたは sitemap ジェネレーター全体の不具合でクローラーを旧、ステージング、非 canonical URL へ送り、安全に即時修正できない。

読む価値のあるリソース

私の関連記事

• ウェブサイト移行の成功にはチェックリスト以上のものが必要 — よくある失敗とローンチ後監視リスト付きの移行ガイド。
• SEO のためのリダイレクト：初心者ガイド — 種類、チェーン、維持期間。
• 1年後に 301 を削除してよいか？検証結果 — 長期維持を支える独自実験。
• カノニカル化：初心者ガイド — 移動後に旧新 URL が競合するときの Google の選択。
• テクニカル SEO 初心者ガイド — 移行の全体像での位置付け。

公式

• URL 変更を伴うサイト移動 — Google の主プレイブック。
• 住所変更ツール — Google の対応範囲、プロパティ要件、リダイレクト指針。
• Bing でのウェブサイト移行 — Bing のフレームワークとリダイレクト期間。

他の著者による資料

• r/TechSEO — 移行の端点ケースとローンチ後の低下を切り分ける場。
• Google の Mueller が語る成功するサイト移行の要点 — URL マッピング、内部リンク、リダイレクトだけでは不十分な理由。
• Google：整然とした移行には時間がかかり、雑な移行にはさらにかかる — 合併と手抜きのコスト。
• HTTP から HTTPS の移行は 301 — 一括でなく URL ごとの 301 推奨。
• Bing でのウェブサイト移行 — 8ステップ、1～2年のリダイレクト、ログ監視。
• ドメイン移動：落とし穴の回避 — 新ドメイン履歴と canonical でリダイレクトを代替しないこと。
• サーバーで HTTPS を有効化 — TLS 証明書、混合コンテンツ、HSTS。

Google はサイト移動リダイレクトを可能な限り長く、通常は少なくとも1年保つよう推奨しています。 この主張の根拠 Google recommends keeping site-move redirects as long as possible, generally for at least one year. 対象範囲： Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. 信頼度： 高 · 検証日： 2026-07-14 Google Search Central: Site move with URL changes 一時的なランキング変動を想定し、中規模サイトの大半のページがインデックス内で移動するには数週間かかると説明しています。 この主張の根拠 Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. 対象範囲： Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. 信頼度： 高 · 検証日： 2026-07-14 Google Search Central: Site move with URL changes 可能な場合、Google は大きな変更を1度に1つずつ行うことを推奨します。

理解度テスト：サイト移行

移行タイプ、リダイレクト、ローンチ後診断に関する5問です。各問の答えを選び、その後に確認してください。

変更履歴