サイト移行後のトラフィック減少：診断と回復

要点 — サイト移行後に検索エンジンが新旧URLをクロールする間、順位が多少動くのは正常です。ただし、大幅または長期的な減少は不具合を示すことがあります。まず、レポートからトラフィックが欠落しているだけではないことを確認します。次に、減少したページと検索を正確に特定します。旧URLが適切な新ページへ転送され、新ページをクロール・インデックスでき、コンテンツと内部リンクが引き継がれているかを調べます。証明できた原因を直し、推測のまま別の10項目まで変更しないでください。

サイト移行後のトラフィック減少とは

サイト移行後のトラフィック減少とは、Webサイトがドメイン、URL、プラットフォーム、プロトコル、ホスト、テンプレート、コンテンツを変更した後に、オーガニック検索での可視性や事業成果が低下することです。

Googleが移転済みURLを再クロールして再インデックスする間、トラフィックは変動します。Googleによると、中規模サイトの大半のページがインデックス内で移転するには数週間かかる場合があり、大規模サイトではさらに長くかかることがあります。処理はURLごとに行われ、サイト規模とサーバー容量にも左右されるため、一定の回復期限はありません。Googleはサイト移転ドキュメントで、この見込みを説明しています。

だからといって、すべての減少が正常とは限りません。実装の破損、想定外に深刻な事業影響、または進展の停止を示す証拠があれば、移行障害です。

最初にデータの移行を確認する

順位を調べる前に、レポートが新しいサイトを引き続き測定していることを確認します。

• Search Consoleで新しいhttps、ホスト、ドメインのプロパティを見ていますか。
• アナリティクスとタグマネージャーのコードは、すべての本番テンプレートに届いていますか。
• 同意動作、参照元処理、チャネルルール、イベント名は変わっていませんか。
• 日付、タイムゾーン、フィルタ、比較期間は同等ですか。
• 注文、リード、電話、サーバーログにも同じ減少が現れていますか。

Googleは、プロパティの取り違えをSearch Consoleトラフィックが見つからない最も一般的な説明の1つとしています。Googleのトラフィック減少ガイドも、この確認から始まります。

損失の形を捉える

サイト全体の合計値から始めないでください。移行前後を次の単位で比較します。

• 旧URLと新URLの組み合わせ
• ディレクトリ、テンプレート、コンテンツ種別
• クエリとページ
• ブランド検索と非ブランド検索
• 国、言語、デバイス、検索での見え方
• 表示回数、クリック数、掲載順位、セッション、コンバージョン、売上

損失の形によって原因を絞れます。表示回数が維持されてクリックが減ったなら、検索結果の見え方、タイトル、スニペット、ブランド、順位を調べます。ページがインデックスから消えたなら、クロール、インデックス可能性、正規化、リダイレクトから始めます。検索クリックが維持され、アナリティクスのセッションだけが消えたなら、測定を修正します。

最初に確認する5項目

1. 可用性： 重要な新URLは高速で安定した200レスポンスを返しますか。
2. リダイレクト： 重要な旧URLはすべて、対応する新URLへ直接移動しますか。
3. インデックス可能性： ステージング環境のnoindex、robotsルール、認証、canonicalタグが本番に入っていませんか。
4. コンテンツ： レンダリング後のページに、有用なメインコンテンツ、タイトル、見出し、メディア、構造化データ、内部リンクが残っていますか。
5. 測定： テスト訪問とコンバージョンを、想定したシステム全体で追跡できますか。

SEO Migration Planner & Validatorを使い、マッピング、配備済みリダイレクト、旧URLの結果、サイトマップ差分を確認します。代表URLではSearch ConsoleのURL検査ツールを使い、Googleのインデックス情報とライブテストを比較します。ライブテストは現在アクセスできるかを示しますが、インデックス登録や順位を保証しません。Googleもこの違いを説明しています。

検証済みの原因を1つずつ直す

時刻、証拠、担当者、措置、リリース、結果を障害ログに残します。停止、5xxレスポンス、意図しない認証、robotsブロック、noindex、壊れたリダイレクト、誤った正規URLなど、確度が高く広範な阻害要因を先に修正します。

調査中にすべてのコンテンツを書き直し、タイトルを変え、リンクを購入し、全URLのインデックス登録を申請してはいけません。同時変更が増えるほど原因の特定が難しくなり、新たな損害も招きます。

要点 — 減少を障害として扱い、測定の妥当性、損失の分割、技術検証という3トラックを並行して進めます。固定した新旧URLコホートを比較し、順位低下と推定する前にクリックを表示回数、CTR、順位へ分解します。可用性、リダイレクト、インデックス可能性、レンダリングの同等性、正規URL選択、内部リンク、サイトマップ、hreflang、構造化データ、パフォーマンス、botログ、セキュリティ、手動による対策、無関係な変更を検証します。広範で確度の高い欠陥を優先してください。より安全な既知の正常状態へ戻せる場合だけロールバックし、それ以外は前進修正します。一定の回復日を約束せず、クロール、リダイレクト、正規URL・インデックス移行、表示回数、クリック、事業成果の順に監視します。

障害を正確に定義する

症状を測定可能な言葉で記述します。次は相対的な時系列を使った仮想の障害記述です。

公開から48時間後、米国プロパティにある移行済み商品URLへの非ブランド・モバイルクリックが、季節性を考慮した比較基準より42%減少し始めた。Search Consoleの表示回数は38%、アナリティクスのオーガニック・ランディングセッションは40%、売上は35%減少した。移行していないサポートURLには変化がない。

これは診断可能ですが、「SEOが落ちた」だけでは診断できません。

次を記録します。

• 移行種別、公開時刻、影響を受けるプロパティとコホート、リリース版
• 基準期間と既知の季節性
• 観測した指標と事業影響
• 確信度、重大度、障害指揮者、技術担当者、次のチェックポイント
• 無関係な配備、キャンペーン、停止、同意変更、確認済みの検索更新

変動と実装障害を分ける

想定される移行パターンでは、旧URLが減少する一方、対応する新URLのクロール、インデックス登録、表示回数、クリックが増えます。順位は変動する場合があります。次の状況では障害の可能性が高まります。

• 壊れたテンプレート、ステータス、マッピングのコホートだけで深刻に減少する
• 新URLがブロック、noindex、非正規、利用不能、または内部リンクから孤立している
• 旧URLがエラーを返す、または無関係な移転先へ転送される
• 5xx、ソフト404、重複、除外、レンダリング失敗が増える
• 公開時刻から測定の同等性が崩れる
• クロール機会があるのに移行の先行指標が動かない
• 検索処理時間とは無関係に、事業上重要な導線が失敗する

任意の割合や日数だけをトリガーにしないでください。サイト通常時の変動、売上への影響、URL数、サーバー容量、確認済みの技術状態に対して重大度を設定します。

トラック1：測定を検証する

Search Console

ドメインプロパティとURLプレフィックスプロパティの範囲、プロトコル、ホスト名、サブドメイン、国別表示を確認します。片方だけを見るのではなく、新旧プロパティを比較します。パフォーマンスレポートの検索タイプ、フィルタ、日付、ディメンションが一致するかを確認し、匿名化クエリとエクスポートの行数制限も考慮します。

アナリティクスと事業データ

生HTMLとレンダリング済みHTMLでのタグ、同意動作、ネットワークリクエスト、デバッグ表示、リアルタイムレポート、クロスドメイン設定、参照元除外、チャネル定義、EC・リードイベント、通貨、タイムゾーン、データフィルタを調べます。移転先でテスト取引を実行し、事業システムと照合します。

ログ

サーバーとCDNのログでは、GooglebotがURLをリクエストしたか、どのレスポンスを受けたか、サーバーが失敗したかを確認できます。必要に応じ、User-Agent文字列を信頼せずGooglebotを検証します。ログは順位や人間のコンバージョンを証明しません。

Search Consoleのクリックが安定し、公開時からアナリティクスのセッションだけが減ったなら、測定が第一仮説です。検索クリック、セッション、事業成果が同じコホートでそろって減ったなら、発見性と検索シグナルの移行を調べます。

トラック2：損失を分割する

基準値と現在値を持つ新旧URLの結合表を作ります。

クリック損失を分解します。

• 表示回数が減少： 需要、インデックス、正規URL、順位、表示資格の問題
• 表示回数は安定し順位が低下： 関連性、コンテンツ、内部リンク、シグナル、競争、処理の問題
• 順位は安定しCTRが低下： タイトル・スニペット、リッチリザルト消失、ブランド、SERP構成、意図の不一致
• GSCクリックは安定しセッションが減少： アナリティクス、同意、リダイレクト、読み込み、アトリビューションの問題
• セッションは安定しコンバージョンが減少： ユーザー導線、オファー、フォーム、決済、オーディエンス、測定、事業の問題

Googleのトラフィック減少ガイドは、パフォーマンスレポートで減少期間を比較し、クリックを失ったページを調べるよう勧めています。また、サイト全体とページ単位の影響を区別します。公式の手順はこちらです。

トラック3：技術的な障害ツリーを実行する

可用性とステータスコード

必要に応じて複数ネットワークから、代表コホートと全コホートをテストします。DNS障害、証明書問題、認証、WAFチャレンジ、5xx、429、タイムアウト、地域限定障害、壊れたキャッシュキー、断続的エラーを探します。robots.txt自体が想定したレスポンスを返すかも確認します。

旧URLへのリクエストが通常のクロールに加えて移転先へ転送されるため、新サーバーのクロール量は増える場合があります。Googleは移転後に十分な容量を確保するよう勧めています。サイト移転ガイドはこの負荷パターンを明記しています。

リダイレクトとURLマッピング

旧URLごとに、最初のレスポンス、ホップ、最終URL、最終ステータス、関連性、パラメータ、意味のあるフラグメント、デバイス・言語地域による差を記録します。

よくある失敗は次のとおりです。

• 恒久移転で誤って302または307を使う
• サーバー側リダイレクトが使えるのにJavaScriptやmeta refreshを使う
• 旧URLから中間URLを経て最終URLへ至るチェーン
• ループ、大文字小文字や末尾スラッシュの不一致、クエリ削除、エンコードエラー
• 多数のURLをホームまたは無関係なカテゴリへ送る
• 画像、PDF、動画、フィードのURLを漏らす
• ブラウザーでは動くが、bot、国、モバイルのリクエストで失敗する

Googleは、通常301または308を使う直接のサーバー側恒久リダイレクトを推奨し、無関係な一括転送を警告しています。また、恒久リダイレクトを少なくとも1年間維持するよう勧めています。現在のリダイレクト指針はこちらです。

robots、meta robots、アクセス制御

生ヘッダーとレンダリング済みHTMLを比較し、本番環境で次を確認します。

• ステージング環境からコピーされたDisallow
• HTML内のnoindexまたはX-Robots-Tagヘッダー
• 認証、VPN、IP許可リスト、プレビューCookie、botチャレンジ
• 意味のあるレンダリングを妨げるリソースブロック
• Search Consoleで送信された削除

インデックス済みページを削除しようとして、Googleがnoindexを確認できないようrobots.txtでも遮断してはいけません。まず実際の状態を診断します。

レンダリングとコンテンツの同等性

保存した移行前のHTML・スクリーンショットを、移転先の生出力・レンダリング済み出力と比較します。メインコンテンツ、タイトル、メタディスクリプション、見出し、画像、動画、リンク、ページネーション、商品データ、レビュー、著者情報、構造化データを検証します。

JavaScriptエラー、API認証、ハイドレーション、パーソナライズ、地域ルーティング、Cookie状態、遅延読み込みにより、テスト状態でコンテンツが隠れていないかを調べます。URL検査、レンダリング対応クローラー、ブラウザートレースを使います。URL検査のライブテストはページへのアクセスとレンダリング状態を示しますが、Googleはインデックス登録を保証しないと説明しています。公式ドキュメントに制限があります。

正規URLと重複の統合

指定した正規URL、リダイレクト、サイトマップ、内部リンク、Googleが選択した正規URLを確認します。よくある移行不具合は次のとおりです。

• canonicalがステージング環境または旧URLを指したまま
• 新しいバリエーションが一般カテゴリや別の言語地域を正規URLにする
• プロトコル、ホスト名、末尾スラッシュ、パラメータ、大文字小文字がシグナル間で一致しない
• 移転済みページの内容が旧ページより大幅に薄い
• 重複する新旧ページが整合した正規化方針なしに両方200を返す

Googleはリダイレクトとcanonical指定をシグナルと説明し、リダイレクトとrel=canonicalはサイトマップ掲載より強いとしています。シグナルが一致すれば重ねて利用できます。Googleの正規化ドキュメントはこちらです。

移行後にGoogleが別の正規URLを選ぶ場合

Search Consoleの正規URLステータスに表示されるURL総数から始めないでください。その件数は多数の重複クラスタの結果をまとめたもので、単一の移行原因ではなくGoogleが最後に処理した状態を反映します。ページのインデックス登録レポート は分類の出発点として使い、次の移転先を意図的に選びます。

• 正規URLを維持すべき変更なしの対照URL
• 1対1の新旧URLマッピング
• 複数の旧URLが意図的に1つの移転先を共有する統合マッピング
• 異なる市場または同一言語の地域別同等ページ
• 親商品ページとバリエーションURL
• プロトコル、ホスト、末尾スラッシュ、大文字小文字、エンコード、パラメータ正規化の組み合わせ
• 移行中にコンテンツまたは内部リンク上の役割が変わったページ

選んだクラスタごとに、ユーザー指定とGoogle選択の正規URL、すべてのレスポンスとリダイレクトホップ、最終レンダリング内容、内部リンク先、サイトマップ掲載、hreflang参照、構造化データURL、新旧両方が今も200を返すかを記録します。Googleの選択を誤りと判断する前に、観測したクラスタを承認済み移行マップと比較します。

診断はクラスタ全体のパターンから行います。弱いまたは一時的なリダイレクト後も旧URLが選ばれるなら、移行シグナルの整合が疑われます。ほぼ同じ地域ページで別市場が複数選ばれるなら、コンテンツ、canonical、hreflangの相互作用が疑われます。全バリエーションで親が選ばれるなら、意図した商品戦略かもしれません。ホストや末尾スラッシュが混在して選ばれるなら正規化が疑われます。GSCの問題件数だけではこれらを区別できません。件数はサンプル抽出元であり、結論ではありません。Googleは、レポートラベルに診断を埋め込むのではなく、複数の正規化シグナル を組み合わせて正規URLを選ぶと説明しています。

不具合パターンを証明したら、選択した移転先についてマッピング、恒久リダイレクト、内部リンク、自己参照canonical、サイトマップ、hreflang、コンテンツを整合させます。プロパティ全体の問題件数が即時または単調に減ると期待せず、再クロール後の対象コホートを追跡します。移行以外の状況での分類は「Googleにより別のページが正規ページとして選択されました」のガイドで説明しています。

内部リンクとアーキテクチャ

ユーザー起点とサイトマップ起点の両方で移転先をクロールします。リンク数、深さ、アンカーテキスト、ナビゲーション、パンくず、ページネーション、関連記事モジュール、孤立ページを比較します。リダイレクトに頼らず、リンクを最終URLへ更新します。重要ページが、その重要性を示していたハブ、カテゴリ、文脈リンクを失っていないかを確認します。

サイトマップと発見

本番サイトマップには、正規かつインデックス可能な新URLを掲載し、管理する場合は正確なlastmod値を含めます。移転先プロパティに送信してください。移転中は旧URLのサイトマップも一時的に監視でき、その旧URLに対するリダイレクト警告は想定内です。GoogleはSearch Consoleで旧URLのインデックス数が減り、新URLが増える様子を監視するよう説明しています。監視手順はこちらです。

hreflangと国際サイトの動作

最終的な正規URL、有効な言語・国コード、自己参照、相互参照、ドメインをまたぐ完全な組を検証します。言語地域の自動転送、ヘッダー、Cookie、国別アクセスもテストします。Googleは各版が自身とすべての代替版を列挙すべきとし、クロスドメインhreflangをサポートしています。言語・地域別URLの指針はこちらです。

構造化データと検索での見え方

利用資格のあるタイプ、必須プロパティ、エンティティ識別子、URL、画像ホスト、パンくず、商品データ、レビュー、組織データ、検証エラーの差分を取ります。順位が同程度でも、リッチリザルト消失でCTRは下がり得ます。リッチリザルトテストとSearch Consoleの拡張レポートを使い、実際の検索での見え方を比較します。

Core Web Vitalsとページエクスペリエンス

テンプレート別にフィールドデータとラボデータを比較します。サーバー応答、レンダリングを妨げる資産、JavaScript、フォント、画像、キャッシュ、第三者処理、レイアウトシフトを確認します。パフォーマンスはユーザーとコンバージョンに大きく影響します。ただし、壊滅的なインデックス消失を小さなCore Web Vitals変化だけで説明せず、原因の規模を症状の規模に合わせます。

手動による対策、セキュリティ、削除

新旧両方のSearch Consoleプロパティで、手動による対策、セキュリティの問題、削除リクエストを確認します。Googleは、人が発行する手動による対策と、ハッキング、マルウェア、ソーシャルエンジニアリングなどのセキュリティ問題を区別しています。レポートがクリーンでもアルゴリズム上の原因は否定できません。手動による対策 とセキュリティの問題 には別々の範囲と修復手順があります。

外部要因と交絡する変更

確認済みの検索更新、季節性、需要、競合の変更、SERP機能、法的削除、在庫、価格、販促、ブランドキャンペーン、停止、その他の配備を確認します。公開との相関は有力な切り分け材料ですが、すべての損失が移行に起因する証明ではありません。

修正の優先順位を決める

範囲 × 事業影響 × 証拠の確信度 ÷ 回復工数を優先順位の参考にします。見せかけの精密な点数にはしません。

おおむね次の順に修正します。

1. セキュリティ露出、広範な停止、DNS・TLS、深刻な5xx
2. サイト全体の認証、robots、noindex、誤った正規URL
3. 価値の高いリダイレクトまたはテンプレートコホートの破損
4. レンダリング・コンテンツの同等性、内部リンク、hreflang、サイトマップの不具合
5. 構造化データ、スニペット、パフォーマンス、影響の小さい整理

限定したサンプルで修正を検証し、公開して時刻を記録した後、先行シグナルを監視します。集計トラフィックを待たず、技術状態が正されたことを確認します。

ロールバックか前進修正か

旧状態が完全で、運用可能かつ安全で、害が小さく、障害が広範または重大で、公開後のデータを照合できる場合はロールバックが適切です。旧コンテンツやインフラが古い、取引を再現できない、DNSと所有権が変わった、ロールバック自体がもう一度の全面移行になる場合は危険です。

欠陥を特定して修復できる場合、移転先だけが有効な運用状態の場合、または逆戻りが障害を悪化させる場合は前進修正します。サイト全体に誤って付いたnoindexなら、そのタグを修正して検証します。ドメイン移転全体を逆転しても、なぜタグが配備されたかは解決せず、変動を増やすだけかもしれません。

技術的に妥当な移行で数日トラフィックが動いたという理由だけでロールバックしてはいけません。一方、顧客が取引できない、またはセキュリティ問題が進行中なのに「移行は変動する」という理由だけでロールバックを拒んでもいけません。

因果順に回復を監視する

1. 配信： 可用性、ステータス、遅延、容量、エラー率が回復する。
2. クロール： botのリクエストが新URLへ届き、旧URLのリダイレクトが正しく解決する。
3. インデックスシグナル： 正規URL、インデックス状態、サイトマップのコホートが進展する。
4. 可視性： 表示回数とクエリ・ページのカバレッジが戻る。
5. トラフィック： クリックと質の高いオーガニックセッションが回復する。
6. 事業： コンバージョン、売上、継続率、サポート成果が回復する。

7日、14日、30日、90日のチェックポイントは報告頻度として使い、回復期限として保証しません。コホートの定義を変えず、途中の変更をすべて記録します。

まとめ

ほぼすべての移行問題は修正できます。重要なのは推測を止め、影響を受けたコホートを特定し、ユーザーとクローラーが実際に受け取るものを検証し、証拠に対応する最小の変更だけを行うことです。

AI要約

• 最初にSearch Console、アナリティクス、同意、イベント、フィルタ、期間、事業データを検証する。
• 影響を受けたコホートを定義し、クリックを表示回数、CTR、順位へ分解する。
• 新旧URL、テンプレート、クエリ、ブランド、国、デバイス、検索での見え方を比較する。
• 可用性、リダイレクト、インデックス可能性、レンダリング、正規URL、内部リンク、サイトマップ、hreflang、構造化データ、パフォーマンス、ログ、セキュリティ、手動による対策、交絡要因を検証する。
• 広範で影響が大きく確信度の高い欠陥を優先する。
• 完全でより安全な状態へ戻せる場合だけロールバックし、それ以外は確認済みの原因を前進修正する。
• 配信、クロール、インデックス移行、可視性、トラフィック、事業成果の順に監視する。

主な診断資料

• Google：検索トラフィック減少のトラブルシューティング
• Google：サイト移転のトラブルシューティング
• Google：URL検査ツール
• Google：リダイレクトとGoogle検索
• Google：正規化
• Google：言語・地域別のURL
• Google：手動による対策
• Google：セキュリティの問題

出典からの引用

• “Mixing up http and https is probably the most common reason for ‘missing’ search traffic” (翻訳) 「httpとhttpsの取り違えは、検索トラフィックが『見つからない』最も一般的な理由である可能性が高い。」 Google Search Consoleヘルプ。 引用箇所へ移動

最初の1時間のチェックリスト

• 障害指揮者を指名し、無関係な本番変更を凍結する。
• 可用性、取引、DNS、TLS、5xx、WAF、監視を確認する。
• Search Consoleプロパティの範囲とアナリティクスの収集を検証する。
• 影響を受けたコホート、開始時刻、比較対象、事業影響を記述する。
• 価値の高い新旧URL、robots、noindex、正規URL、レンダリングをテストする。
• 最近のリリース、手動による対策、セキュリティ問題、削除を確認する。
• 証拠、担当者、次の措置、次回更新時刻を記録する。

調査全体のチェックリスト

• ページ、クエリ、テンプレート、ブランド、市場、デバイス、検索での見え方を分割する。
• 旧URL一覧と移転先サイトをクロールする。
• 生出力・レンダリング済み出力の同等性を移行前の基準と比較する。
• 内部リンク、サイトマップ、hreflang、構造化データ、パフォーマンス、ログを確認する。
• 検索、アナリティクス、事業成果を照合する。
• 証拠に基づき仮説を順位付けし、最も低コストで識別できる確認を行う。
• 事前に合意した安全基準でロールバックまたは前進修正を選ぶ。
• 回復コホートを監視し、障害の時系列を保存する。

SIGNAL回復フレームワーク

• S — Scope（範囲）： どのURL、クエリ、市場、デバイス、テンプレート、成果が変わったか。
• I — Instrumentation（計測）： Search Console、アナリティクス、同意、ログ、事業データは有効か。
• G — Gateway（入口）： ユーザーとクローラーは名前解決、接続、受信、レンダリングができるか。
• N — Navigation and normalization（導線と正規化）： リダイレクト、内部リンク、正規URL、hreflang、サイトマップは一致するか。
• A — Assets and answers（資産と回答）： 有用なコンテンツ、メディア、構造化データ、速度、機能は維持されたか。
• L — Learn and limit（学習と制限）： 仮説を検証し、確認済みの最小修正を公開してコホートを監視する。

ロールバックするかを判断する

1仮説ずつ検証するSOP

1. 仮説と影響を受けたコホートを書く。
2. 仮説を支持・反証する証拠を明示する。
3. 最小の識別テストを実行する。
4. 生の出力、時刻、URLサンプル、ツール設定を保存する。
5. 仮説を採用、棄却、または限定する。
6. 修正担当者と検証担当者を割り当てる。
7. 管理された変更を1つ公開する。
8. 次の変更前に先行指標と成果指標を比較する。

症状別プレイブック

頻出する移行不具合

ステージング環境の制御が本番に入った

証拠： 広範なnoindex、robotsブロック、認証、ステージングの正規URL。 修正： 本番の阻害要因を除去し、生出力とレンダリング済み出力を検証し、サンプルを調べ、正しいサイトマップを再送信します。ページ単位のインデックス登録申請を大規模に行わないでください。

リダイレクトマップがサイト構造を平坦化した

証拠： 多様な旧URLがホームまたは1つの一般カテゴリへ着地し、ソフト404が増える。 修正： 同等の1対1マッピングまたは妥当な統合マッピングを復元します。後継がなければ404または410を返します。

CMSにはコンテンツがあるがレンダリングされない

証拠： ソースまたはAPIにコンテンツがあるのに、レンダリング対応クローラーやURL検査では見えない。 修正： レンダリング、APIアクセス、ハイドレーション、条件付き状態を修正し、ユーザー操作に頼らずメインコンテンツを検証します。

新旧シグナルが一致しない

証拠： 旧正規URL、新サイトマップ、転送を経由する内部リンク、混在するhreflang。 修正： 最終的な移転先についてリダイレクト、自己参照canonical、内部リンク、サイトマップ、hreflang、構造化データURLを整合させます。

レポートから新ホストが欠落する

証拠： GSCの旧プロパティは低下するが、サーバーログには新ホストへの検索流入がある。 修正： 正しい確認済みプロパティを使い、移転中は新旧レポートを統合します。

診断を悪化させる対応

• 「移行では必ず減少する」と考え、期限なく待つ。
• 技術状態を検証せず、集計順位だけを見てロールバックする。
• リダイレクト、コンテンツ、タイトル、内部リンク、プラットフォームを同時に変える。
• 新旧を合わせたコホートではなく、移転先ドメインだけを見る。
• site:検索の件数を正確なインデックスKPIとして扱う。
• 発見経路を直さず、数千件の手動インデックス登録申請を送る。
• サイト全体のnoindex級の減少をCore Web Vitalsのせいにする。
• 手動による対策がクリーンなら、ほかの原因もないと決めつける。
• 安定する前に旧環境、ログ、クロール、マッピングを廃止する。

問い別のツール

• SEO Migration Planner & Validator：マップ、配備済みリダイレクト、旧URLの状態、サイトマップ、保存済みページは一致するか。
• Redirect Map Builder：どのマッピングが不確実、未対応、チェーン化、またはエクスポート可能か。
• Search ConsoleのパフォーマンスとURL検査：どのページ・クエリが変わり、Googleのインデックス済み表示とライブ表示は何を報告するか。
• クローラーとレンダリング対応クローラー：実際にどのステータス、指示、リンク、コンテンツ、シグナルが配信されるか。
• サーバー・CDNログと可観測性：検証済みbotがURLを要求し、インフラは何を返したか。
• アナリティクスのデバッグツールと事業システム：収集とコンバージョンは正常か。
• リッチリザルトテストとパフォーマンスツール：検索での見え方または体験が悪化したか。

回復の受け入れテスト

回復ダッシュボード

修正したコホートごとに、一定のチェックポイントで次を報告します。

• 可用性、遅延、4xx・5xx、リダイレクト成功率
• 新旧URLに対する検証済みbotのリクエスト
• インデックス済み・正規の移転先カバレッジとサイトマップの進展
• 表示回数、平均順位の分布、CTR、クリック
• オーガニック・ランディングセッション、質の高いコンバージョン、売上、継続率
• 移転元・旧URLの減少対移転先・新URLの増加
• 未解決仮説、欠陥数、修正リリース、検証状態

絶対値、変化率、想定範囲、確信度、注釈を示します。測定が壊れた箇所へ点推定値を補完しないでください。

資料

Patrickが検証した記事

• A Website Migration Takes More Than a Checklist：基準値、ロールバック計画、比較クロール、想定される失敗、監視に関するPatrickの指針。

公式ドキュメント

• Googleのトラフィック減少ガイド：レポート範囲、分割、インデックス、検索での見え方、需要、検索システム変更の確認。
• Googleの移行トラブルシューティング：リダイレクト、クロールエラー、容量、サイトマップの確認。
• GoogleのURL検査ドキュメント：インデックス済みURLの証拠とライブテストの境界。
• Bing Webmaster Guidelines：別の検索エンジンによるリダイレクト、クロール・レンダリング、適切な削除の指針。

業界の資料

• Search Engine Landの2026年版移行確認：公開前、公開当日、公開後の検証。
• Search Engine Landのサイト移行ガイド：計画、公開、問題、回復の包括的な範囲。
• Search Engine Journalの回復手順：測定、リダイレクト、技術、コンテンツの切り分け。例示された割合は基準ではありません。
• Screaming Frogのリダイレクト監査チュートリアル：旧URL集合とリダイレクト経路全体の大規模検証。

関連ページ：サイト移行、Webサイト移行チェックリスト。

理解度を確認する

変更履歴