買収後のSEO統合とサイト統合

TL;DR — 企業を買収したからといって、すぐにそのウェブサイトを自社のサイトに統合すべきというわけではありません。両方のサイトを維持することも、統合することも、ハイブリッドにすることもできます。顧客が何を検索しているか、ブランドが同じオーディエンスにサービスを提供しているか、コンテンツの重複度、チームが結果を安全に運用できるかどうかに基づいて選択してください。ページを移動する場合は、古いURLそれぞれを実際の移行先にリダイレクトしてください。単一ドメインのトラフィックグラフが上昇したかどうかだけでなく、統合後のビジネスが顧客とコンバージョンを維持しているかを測定してください。

買収後のSEO統合とは

買収後のSEO統合とは、買収した検索資産（ドメイン、ブランド、ページ、コンテンツ、リンク、プラットフォーム、アナリティクス、国際サイト、ベンダーアカウント、それらを運営する人材）に何が起こるかを決定し、実装する作業です。

基本的な選択肢は3つあります。

どれが自動的に最良というわけではありません。統合は重複作業を減らし、権威を集中させることができますが、URL、ブランディング、コンテンツ、内部リンク、ユーザーの期待を同時に変更します。サイトを分離したままにすると、その移行は回避できますが、継続的なプラットフォーム、ガバナンス、コンテンツのコストがかかります。

リダイレクトを構築する前に決定を下す

5つの質問をしてください。

1. 人々は買収したブランドを求めているか？ ブランド検索、ダイレクトトラフィック、レビュー、 コミュニティ、顧客の言葉は、名前を保存する価値があるものにする可能性があります。
2. サイトは同じ検索を満たしているか？ 重複は類似キーワードだけではありません。 意図、オーディエンス、製品、地理、ジャーニーステージを比較してください。
3. コンテンツは本当に交換可能か？ 買収先の優れたガイドは、買い手がすでに似たタイトルの短いページを 持っているという理由だけで破棄すべきではありません。
4. 移行先はビジネスをサポートできるか？ テンプレート、ローカライゼーション、 製品データ、コマース、サポート、アクセシビリティ、セキュリティ、測定を確認してください。
5. 誰が運用するのか？ 価値を生み出した人材とシステムが知識移転の前に離れてしまうと、計画は失敗します。

統合する場合

買収したサイトの完全なURLインベントリを使用してください。古いページごとに、以下を決定します。

• コンテンツを新しい同等のURLに移行する。
• より強力な統合ページにマージする。
• 依然として分離されたプロパティに保持する。
• 置き換えがないため、404/410で廃止する。

次に、移動した各URLから最終的な同等のURLへのサーバーサイドの恒久リダイレクトを使用します。 買収したサイト全体を買い手のホームページに送信しないでください。Googleは、 無関係な一括リダイレクトはソフト404として扱われる可能性があると警告しています。Googleのサイト移転ガイド では、マッピングとリダイレクトのプロセスについて説明しています。

成功の意味

成功とは「買い手ドメインのトラフィックが40%増加した」ということではありません。その増加の一部は、単に 買収したドメインから消えたトラフィックである可能性があります。

統合された資産を測定します。

• 維持されたインプレッション、クリック、質の高いセッション、リード、収益、顧客。
• レガシーブランドごとのブランドおよび非ブランド需要。
• コホートごとの旧URLから新URLへの移行。
• コンバージョン、リテンション、サポートの成果。
• 運用コスト、移行インシデント、未解決の依存関係。

目標は、ビジネス統合を通じて有用な需要を維持し、改善することです。 ドメインのチャートは証拠の一部にすぎません。

TL;DR — 実装する前にアーキテクチャを審査する。ブランド需要、クエリとオーディエンスの重複、ページレベルのパフォーマンス、コンテンツの優位性、リンクの来歴、技術プラットフォーム、国際アーキテクチャ、セキュリティ、測定、運用コストを用いて、分離、統合、ハイブリッドの各状態を比較する。証拠が変更を支持するまで、取得した資産を維持する。統合の場合は、すべてのURLに対して正規のコンテンツ勝者と処分方法を定義し、可逆的なコホートで移行し、すべての検索シグナルを更新し、固定されたクローズ前のベースラインに対して統合後の保持を測定する。旧状態が無傷で、ロールバックが総害を減らす場合にのみロールバックする。それ以外の場合は、既知の欠陥を前方修正する。

統合のテーゼから始める

バックログの前に1ページのテーゼを書く：

• 統合のビジネス上の理由；
• 意図するブランドとドメインのアーキテクチャ；
• 影響を受けるオーディエンス、製品、市場、ジャーニー；
• 分離、統合、またはハイブリッド処理から期待される価値；
• 選択を支持する証拠；
• 決定を変える条件；
• オーナー、予算、順序、決定日。

「買ったから、自社ドメインに移す」はテーゼではない。それは仮定である。

3つの目標状態を比較する

各目標状態を好みではなく証拠で評価する。

重み付き決定記録を使用するが、1つのスコアの中に不確実性を隠さない。ブランド、重複、技術、法的、セキュリティ、財務、運用の入力の背後にある証拠と信頼度を示す。専門家は自分の領域の結論を所有する。

統合変更の前にベースラインを確立する

利用可能な場合は、少なくとも1つの比較可能な季節サイクルを維持する。エクスポート：

• ページ、クエリ、国、デバイス、検索表示別のSearch Console；
• アナリティクスのランディングセッション、イベント、コンバージョン、アトリビューション設定、同意状態；
• CRM/ECの成果、返金、更新、認定パイプラインの定義；
• ランキング、クロール、ログ、サイトマップ、バックリンク、リダイレクト、インデックス済みページのパターン；
• 両方の名前と一般的な誤字を含むブランド需要；
• プラットフォームコスト、公開スループット、インシデント、スタッフ依存関係。

URLを変更する前にコホートを作成する：購入者変更なし、取得変更なし、移動、統合、廃止、国際、トランザクション、編集、サポート、コントロール。リリース、キャンペーン、障害、季節性、確認された検索アップデートを記録し、統合が無関係な変動の功績や責任を負わないようにする。

ブランドと検索需要を分析する

ブランドと非ブランドを分離し、ナビゲーション意図とカテゴリ発見を区別する。以下を含むクエリをレビューする：

• 買い手ブランド、買収したブランド、および組み合わせた名前；
• 製品名、レガシー名、モデル番号、およびサポート条件；
• 代替品、比較、レビュー、ログイン、価格、および苦情；
• 国と言語の修飾子。

ブランド需要は、URLシグナルと同じようにリダイレクトを通じて移転するわけではありません。 顧客が引き続き買収した名前を検索する場合は、有用な宛先と明確な説明を維持してください。 リブランドの日付がユーザーの行動を変えると想定するのではなく、需要が移行するか、持続するか、減衰するかを追跡してください。

ページレベルでコンテンツの勝者を決定する

キーワードの重複は出発点であり、統合の指示ではありません。各候補ペアを以下で比較してください：

• 意図とオーディエンス；
• 完全性、独自性、正確性、新しさ、および実証された専門性；
• トラフィック、リンク、コンバージョン、支援されたジャーニー、およびサポート価値；
• 形式、メディア、コメント/レビュー、ローカライゼーション、および構造化データ；
• メンテナンス負担、権利、承認、および製品依存関係。

可能な決定は、買い手の勝利、買収したページの勝利、結合ページ、異なる意図のための別個のページ、または廃止です。どちらの会社が書いたかに関係なく、最良の素材を保存してください。何が移動され、何が書き直され、何がライセンスされ、誰がそれを維持するかを文書化してください。

すべてのリンクを資産として扱わずにリンク価値をレビューする

外部リンクされたURLと、それぞれがリンクを獲得した理由をマッピングしてください。同等の結合リソースへのリダイレクトは、ユーザージャーニーを保存できます。古い調査レポートから無関係な製品ページへのリダイレクトは、その理由を再現できません。

手動による対策、スパム行為、有料または管理されたリンク、期限切れドメインの使用、サイト評判の露出、およびハッキング履歴をレビューしてください。クリーンな手動による対策レポートは、現在人間が発行したアクションが表示されていないことを意味するだけであり、リンクプロファイルやアルゴリズムによる扱いを保証するものではありません。Googleは手動による対策レポートの範囲を 説明しており、別のスパムポリシーを維持しています。

技術的な宛先を検証する

買収した資産を、それが機能する仕組みを再現できないプラットフォームに移動しないでください。テストしてください：

• クロール可能性、レンダリング、インデックス可能性、正規化、ページネーション、およびURLコントロール；
• テンプレート、メタデータ、見出し、構造化データ、画像、ビデオ、およびダウンロード；
• ナビゲーション、内部リンク、関連コンテンツ、サイト検索、および孤立ページの処理；
• パフォーマンス、容量、CDN動作、キャッシュ、WAF、ボットアクセス、およびエラー処理；
• 製品在庫、レビュー、価格、在庫状況、場所、およびフィード；
• 同意、分析、実験、広告、CRM/EC結合、およびサーバーログ；
• アクセシビリティ、セキュリティ、プライバシー、保持、および専門家によるインシデント対応。

国際的なアーキテクチャを意図的に選択する

買収はしばしば、重複する国別サイト、言語、ccTLD、サブドメイン、およびディストリビューターを生み出します。各市場を誰が所有し、ページが言語、国、またはその両方をターゲットにするかを決定してください。ユーザーやクローラーが代替手段に到達するのを防ぐ自動IPリダイレクトを避けてください。

代替URLが残っている場合は、hreflangを正規の最終URLに更新し、注釈を相互に保ってください。Googleはドメイン間でhreflangをサポートしています。各言語バージョンは、それ自体と他のバリアントをリストする必要があります。Googleはこれらの 要件を文書化しています。

移行前にガバナンスを設計する

以下の責任者を指名してください：

• ドメイン、DNS、証明書、CDN、リダイレクト、および更新；
• CMS、テンプレート、リポジトリ、リリース、およびインシデント対応；
• コンテンツ基準、承認、ローカライゼーション、およびアーカイブ；
• 分析、同意、データアクセス、レポート、およびビジネス定義；
• Search Console、ビジネスプロフィール、フィード、ベンダーツール、およびシークレット；
• クロージング後のSEOロードマップと移行の決定権。

主要な従業員や代理店が退職する前に知識を獲得してください。アクセスは知識ではありません。 移行されたCMSログインでは、システムに組み込まれた例外は説明されません。

段階的に統合する

優れた段階は一貫性があり、測定可能です：

1. 基盤： アクセス、セキュリティ、アナリティクス、ドメイン、モニタリング、ガバナンス。
2. 低リスクの重複： 明確な同等物を持つ限定されたコンテンツ群。
3. 高価値のテンプレート： 製品、カテゴリ、ソリューション、または編集セクション。
4. 国際およびプラットフォームの境界： 市場、ヘルプセンター、アプリ、フィード、ファイル。
5. レガシーのクリーンアップ： 古いドメイン、チェーン、マイクロサイト、プロフィール、ベンダーの退場。

Googleは、一度に一つの大きな変更を行うこと、必要に応じて大きな移動をセクションでテストすること、URLが再クロールされ再インデックスされる間に一時的なランキング変動を予想することを推奨しています。また、パイロットが完全な移動を代表するとは限らないとも述べています。 現在のサイト移動ガイダンスはそれらの制限を述べています。

リダイレクトとコンテンツマップを構築する

すべての古いURLには、明確な処分と証拠の記録が与えられます。恒久的な移動にはサーバーサイドの301/308リダイレクトを使用します。レガシーチェーンを経由せず、最終的な同等のURLに直接ポイントします。内部リンク、正規化、hreflang、構造化データのIDとURL、サイトマップ、フィード、プロフィール、広告、高価値の外部リンクを更新します。

複数のページが本当に一つのより良いページに統合される場合、多対一が正しいことがあります。置き換えが存在しない場合は、404/410を返します。Googleは無関係な一括リダイレクトに対して警告し、恒久的なリダイレクトを少なくとも1年間、可能であればユーザーにとってより長く維持することを推奨しています。実装ガイダンスを 参照してください。

ロールバックと前方修正を計画する

ロールバックは自動的には安全ではありません。次の場合に使用します：

• 以前の状態が無傷で安全なままである場合；
• 起動後に作成されたデータを調整できる場合；
• 障害が広範囲で深刻であり、迅速に隔離できない場合；
• ロールバックが契約、取引、アクセス、または後の移行段階を壊さない場合。

欠陥が既知で限定されている場合、以前の状態がもはや有効でない場合、またはロールバックが2回目の移行を追加する場合は、前方修正を行います。起動前にしきい値を決定します。例：重要なジャーニーが利用できない、広範囲にわたる意図しないnoindex、重大なリダイレクト障害、深刻な測定損失、またはセキュリティの露出。予想される再クロールウィンドウ内でのランキングのみのトリガーは、技術的証拠が欠陥を特定しない限り避けてください。

最終的な考察

統合は選択肢であり、統合の定義ではありません。買収した資産を、その価値を生み出すものを理解するのに十分な期間保持してください。その後、明確な宛先、運用責任者、測定計画があるものだけを移動します。

AIまとめ

• 統合を買収後のデフォルトの結果として扱わないでください。
• 分離、統合、ハイブリッドの目標状態を明確な証拠と比較してください。
• ブランド変更、コンテンツ、プラットフォーム、またはURLの変更の前に、ベースラインとコホートを保持してください。
• ブランド需要、ページの意図、コンテンツの品質、リンク、技術的能力、国際的なアーキテクチャ、セキュリティ、データ、チームの依存関係を分析してください。
• 買収したすべてのURLに処分を与え、移動したすべてのURLに真の後継URLを割り当ててください。
• ガバナンス、モニタリング、ロールバック、前方修正のルールを持つ測定可能な段階で統合してください。
• 季節性や無関係な変更を考慮したうえで、統合後のトラフィックとビジネス成果から成功を判断してください。

主要な参考文献

• Google: サイト移転とURL変更
• Google: リダイレクトと検索
• Google: 正規化
• Google: ローカライズ版とhreflang
• Google: 手動による対策レポート
• Google: セキュリティ問題レポート
• Google: スパムに関するポリシー

ソースからの引用

• “If you recently bought a site that had pre-existing security issues, fix the issues listed in the Security Issues report” (翻訳) 「最近、既存のセキュリティ問題があるサイトを購入した場合は、セキュリティ問題レポートに記載されている問題を修正してください。」— Google Search Console ヘルプ。 引用元へ移動

統合チェックリスト

決定

• ビジネス目標と3つのターゲット状態の選択肢をすべて文書化する。
• ブランド、非ブランド、トラフィック、成果、URL、リンク、システム、コストのベースラインを設定する。
• オーディエンス、意図、コンテンツ、テクノロジー、国際展開、セキュリティ、チームの適合性を比較する。
• 証拠、不確実性、責任者、予算、および決定を変更する条件を記録する。

設計と提供

• すべてのURLとコンテンツアセットに処分を割り当てる。
• マッピングを承認し、最も強力で有用なコンテンツを保持する。
• 宛先テンプレート、ジャーニー、キャパシティ、測定、ガバナンスを検証する。
• リダイレクト、内部リンク、正規化、hreflang、スキーマ、サイトマップ、プロフィールを更新する。
• ウェーブゲート、ロールバック/フォワードフィックスのしきい値、コミュニケーション、モニタリングを定義する。

安定化

• すべての古いURLと宛先コホートをクロールする。
• 新旧のインデックス、クリック、ランキング、成果、ログを比較する。
• レガシーブランドの需要と顧客の混乱を追跡する。
• チェーン、見逃したアセット、アクセス、ベンダー、国際的な依存関係を解決する。
• 終了基準を満たした後にのみ、古いプラットフォームを廃止する。

VALUEアーキテクチャフレームワーク

• V — 閲覧者と顧客: オーディエンス、意図、ブランド期待、ジャーニーは互換性があるか？
• A — アセット: どのコンテンツ、リンク、ドメイン、データ、権利、機能が価値を生み出すか？
• L — 場所: 各アセットはブランド、ドメイン、市場、プラットフォームのどこに配置すべきか？
• U — ユニットエコノミクス: 移行、修復、運用、機会費用はいくらか？
• E — 実行: チームはターゲット状態を移行、測定、保護、ガバナンス、維持できるか？

フレームワークを使用してアーキテクチャを比較する。争われている法的、セキュリティ、プライバシー、財務上の入力をSEOの意見に矮小化しないこと。

ターゲットアーキテクチャを選択する

アーキテクチャ決定SOP

1. 比較可能なベースラインをエクスポートできる十分な期間、変更を凍結する。
2. 買収先と買い手の資産、権利、管理、コスト、依存関係を棚卸しする。
3. 需要、オーディエンス、コンテンツ、リンク、市場、プラットフォーム、成果をセグメント化する。
4. 分離、統合、ハイブリッドの状態を仮定を示してモデル化する。
5. 専門家のインプットと未解決の制約をレビューする。
6. テーゼ、コホート、予算、ガバナンス、順序、成功基準を承認する。
7. ソースを廃止せずに、一貫性のあるコホートをパイロットする。
8. 次のウェーブを承認する前に、結果とインシデントの証拠を比較する。

最初の100日間

0〜30日目: 安定化

• アクセス、更新、人材、ベンダー、現在のアーキテクチャを維持する。
• ベースラインをエクスポートし、手動による対策、セキュリティ問題、削除、アクセスを検査する。
• 未レビューのリダイレクト、大規模なブランド変更、削除、プラットフォームのシャットダウンを停止する。

31〜60日目: 決定

• 完全なオーディエンス、ブランド、コンテンツ、リンク、技術、国際、およびコスト分析。
• 目標状態を選択し、リバーシブルなパイロットコホートを特定する。
• ガバナンス、測定定義、セキュリティ、およびデータ管理を確立する。

61〜100日目: 証明する

• 移行先とマッピングを構築し、QAを実施する。
• ロールバックとインシデント対応体制を備えたパイロットを開始する。
• カレンダーではなく、コホートの証拠に基づいて次の波を決定する。

統合の失敗

• 買収したドメイン全体を買い手のホームページにリダイレクトする。
• ドメインレベルの権威メトリクスのみでターゲットサイトを選択する。
• 買い手がすでにURLを持っているため、優れた買収コンテンツを削除する。
• リブランディング、プラットフォーム移行、URL再構成、統合を同時に行う。
• レガシーブランドのナビゲーションおよびサポート需要を無視する。
• 買い手ドメインの成長のみを測定し、統合エステートの維持を測定しない。
• 検証前に旧CMS、ログ、ドメイン、または人材を廃止する。
• クリーンなManual Actionsレポートを検索リスクがないことの保証として扱う。
• 無期限で管理されていない2サイト状態を一時的なハイブリッドと呼ぶ。

便利なツール

• SEO移行プランナー＆バリデータ: マップのレビュー、 デプロイされたリダイレクト、旧URLの結果、サイトマップ、アーカイブページ。
• リダイレクトマップビルダー: マッピングの提案、信頼度の スコアリング、未マッチURLの可視化、チェーンの平坦化、リダイレクトルールのエクスポート。
• Search Console、アナリティクス、CRM/eコマース、サーバーログによるベースライン照合。
• クローラー、レンダリングクロール、ページテンプレート差分によるパリティおよび回帰テスト。
• バックリンクおよびランキングツールによる発見と優先順位付け（単独の証明ではない）。
• 意思決定記録、依存関係マップ、インシデントログによるガバナンス。

受け入れテスト

統合エステートを評価する

固定された統合前コホートを使用し、季節的に適切な期間を比較する。

• 検索維持: レガシークエリ/ページコホートの合計クリックとインプレッション。
• ビジネス維持: 認定コンバージョン、顧客、収益、更新、サポート成功。
• 移行進捗: 旧URLのクロール減少と新URLのクロール/インデックス成長。
• ブランド継続性: 買収ブランドと買い手ブランドの需要、ナビゲーション、コンバージョン。
• 実装品質: リダイレクトエラー、チェーン、正規化の不一致、5xx、noindex、 hreflangの欠陥、スキーマの欠落、壊れた内部リンク。
• 運用結果: プラットフォームコスト、公開時間、インシデント数、ベンダー退出、 未解決の依存関係。

観察された結果をモデル化されたシナジーとは別に報告する。合計は、商業的に重要なセグメントでの損失を隠す可能性がある。

リソース

パトリックの検証済みの作業

• M&AにおけるSEOの役割: Patrickのデューデリジェンス、合併選択、段階的統合、モニタリング、トレーニングのガイダンス。
• ウェブサイト移転はチェックリストだけでは不十分: 計画、ベースライン、統合の仕組み、失敗モード、継続的なモニタリング。

公式ドキュメント

• Googleのサイト移転ガイド: ドメインとホスト名の統合の仕組み。
• Googleのスパムポリシー: リスクレビューのためのポリシー定義であり、買収評価モデルではない。
• Googleの手動による対策およびセキュリティ問題のドキュメント: 個別の限定されたレポート範囲。
• Bingウェブマスターガイドライン: 現在のリダイレクトと削除に関するガイダンス。

業界からの情報

• Search Engine Landのサイト移転ガイド: 現在の統合、移転、復旧に関する情報。
• RDL DigitalのM&Aリダイレクトマッピングガイド: 関連する宛先とコンテンツギャップに焦点を当てた実務者の視点。
• 9thCOのM&Aウェブサイト移転ケーススタディ: 複数ドメイン統合におけるベンダー報告の範囲。
• Koozaiの合併と移転の事例: 業界の例。商業的な結果はケース固有として扱うこと。

このサイトの関連記事: M&AのためのSEOデューデリジェンス 、サイト 移転、ウェブサイト移転 チェックリスト。

自分で試す

変更履歴