3年前、あるクライアントが通話に参加する際、カオスとしか言いようのないスプレッドシートを持ってきました。7つのブランド。4つのターゲット市場。2つの言語。それぞれ独立したWordPressインストール上で運営され、それぞれがホスティング代、プラグインライセンス、放置されたブログを持っていました。彼女は「統合したい」と言いました。私は40分間をかけて、彼女の場合において間違った判断——つまりWordPress Multisiteは選ぶべきではないという判断に彼女を説得しました。
重要なポイント：サブフォルダは権限を集約し、サブドメインはそれを分散させ、Multisiteは SEO の観点よりも運用面での判断です。ガバナンスが必要でない限り、デフォルトではサブフォルダを選択してください。
それは彼女を驚かせました。多くの人々を驚かせます。複数のブランドをやり繰りする際には、マルチサイトは明白な答えのように聞こえます。しかし、マルチブランド WordPress プロパティを SEO 向けにどのように構成するかという問題は、実際には最も重大な影響を与えるアーキテクチャ上の決定の 1 つであり、ほぼ間違いなく、それが値する微妙さを得ることはありません。
では、それを改善しましょう。
---
3つの構成、簡潔に
意見を述べる前に、まず基本を確認しておきましょう。
- WordPress Multisite。共有コードベースで複数のサイトを実行する単一のWordPressインストール。各サイトはサブドメイン（
brand2.yourdomain.com）またはサブフォルダ（yourdomain.com/brand2/）、あるいはMercatorのようなプラグイン経由でマップされたドメイン（brand2.com）にすることができます。 - 別のサブフォルダ。1つのWordPressインストール。
yourdomain.com/brand2/のようなパスからコンテンツを配信。技術的にはMultisiteではありません。ツールで模擬することもできますし、特定のページビルダー設定で適切に実装することもできますが、通常は分割されたコンテンツを持つ1つのサイトを意味します。 - サブドメイン。
brand2.yourdomain.com。Multisite内か、別のサブドメインを指す完全に独立したWordPressインストールのいずれか。
混乱が生じる理由は通常、Multisiteがサブドメインまたはサブフォルダーのいずれかを使用できるからです。そのため人々はホスティングアーキテクチャをURL構造と混同します。これらは独立した決定です。頭の中でも分けておきましょう。
---
Googleが実際にこれらを扱う方法（神話なし）
多くのエージェンシーオーナーをつまずかせる点は次の通りです。GoogleはSEOコミュニティが18ヶ月ごとに再び議論し続けているにもかかわらず、この点について非常に一貫性を保っています。
Googleの公式ドキュメンテーションでは、サブフォルダーとサブドメインを異なるエンティティとして扱っています。サブドメインはドメインオーソリティを継承できますが、Googleは明示的にサブドメインをクローリングとインデックス目的で別のサイトとして扱うと述べています。John Muellerは2019年のSearch Central office hoursで確認しました。コンテンツがトピック関連のとき、サブフォルダーは一般的にサブドメインより信号をよりよく統合します。
これは実際には何を意味するのでしょうか？2つのブランドが本当に別のビジネスであり、異なるオーディエンス、異なるニッチ、異なるインテントを持つ場合、サブドメインまたは別のドメインが理にかなっています。親としてのアイデンティティを共有するか、トピックが重なっている場合、サブフォルダ構造またはMultisiteサブフォルダネットワークはリンク資産をより速く蓄積します。
Seahawkは、1つの親会社傘下で4つのホテルブランドを運営していたホスピタリティクライアントを担当していました。私たちは彼らを4つの独立したドメインから親ドメイン下のMultisiteサブフォルダネットワークに移行させました。12ヶ月後、4つのブランドのうち3つのオーガニックトラフィックが倍になっていました。4つ目のブランドはコンテンツの問題を抱えていました。構造的な問題ではなく、構造は薄いページを救うことはできません。
---
WordPress Multisite：優れている場面と悪夢のような場面
本当の利点
Multisiteは、予測可能で反復可能なブランド構造がある場合、本当に優れています。フランチャイズネットワーク、地域版を持つニュース組織、またはローカライズされたマーケティングサイトを立ち上げているSaaS企業を想像してください。1つのコードベース。一元管理されたプラグイン管理。必要に応じて共有ユーザー。
管理効率は実在します。私たちは1つのクライアントのための40以上のサイトのネットワークを管理しています。1つのテーマアップデート。1つのセキュリティパッチ。すべてのサイトで完了。Multisiteなしでは、月曜日の朝はそれ自体が1つのタスクになります。
失敗する場所
ブランドが分岐するとMultisiteはあなたを厳しく罰します。ブランドAが、ブランドBが必要とするものと矛盾するプラグインを必要とする瞬間、あなたは問題を抱えています。そしてWordPressプラグインは常にMultisiteと互換性があるわけではありません。2024年でもそれは本当のことです。WP EngineのMultisiteガイドはプラグイン互換性をトップの摩擦ポイントとしてリストしており、私は実務経験からそれに同意します。
パフォーマンス分離も弱いです。1つのサイトのトラフィックスパイクが同じインストール上の別のサイトに影響を与える可能性があります。あるサブサイトでのプロダクトローンチが、共有wp-cronキューがハンマーで叩かれたために3つの他のサイトを遅くする場面を見たことがあります。夜11時にクライアントに説明するのは楽しくありません。
正直なところの経験則
ブランドがチームを共有していて、コードベースの意図を共有していて、プラグインのニーズが分岐しないなら、Multisiteは価値がある。本当に別々のビジネスユニットで技術要件も異なるなら、管理のオーバーヘッドが高くても別々のインストールの方が手間が少ない。
---
サブフォルダー構造：SEOでは過小評価、エージェンシーでは過度に未活用
私はサブフォルダーについてやや熱心です。すべての状況に適しているわけではありませんが、エージェンシーはそれらを見落としがちです。
マルチブランドまたはマルチカテゴリーのプレゼンスをparentbrand.com/subbrand/として構造化すると、そのパスの下のあらゆるコンテンツがルートドメインの権威性に貢献します。/subbrand/の下の投稿への強力なバックリンクは、ドメイン全体を押し上げます。この数学は時間とともに複利で増殖する方法で、個別ドメインが迅速に複製することができません。
2020年、私は3つのプロダクトラインに対して3つの別々のドメインを立ち上げた英国のフィンテック企業に携わった。3つのドメイン全体のバックリンクプロファイルは約1,400の参照ドメイン。8ヶ月かけて彼らの最強ドメイン上のサブフォルダ構造に統合した。14ヶ月以内に、それらのシグナルを効果的にプールして、弱いプロダクトラインが以前は触れたこともないキーワードでランク付けされるようになった。純粋にドメインオーソリティがそのドメイン全体で上昇したからだ。
トレードオフ
サブフォルダー構造には規律が必要です。URLタクソノミーは最初から整理する必要があります。6か月後に/brand-a/を/brand-a-uk/に変更することはリダイレクトの手間です。構築後ではなく、構築前にタクソノミーを計画してください。
また、2つの異なるブランドで異なるオーディエンスを本当に運営している場合、1つのブランドのドメイン直下のサブフォルダは、ユーザーにとって奇妙に見える。ブランドの認識は重要だ。誰かがfashionlabel.com/industrial-tools/にランディングした場合、ポジショニングの会話で何かが失敗している。
---
サブドメイン：その根拠が存在する
サブドメイン反対派に見られたくない。実際に正しい選択肢となるシナリオは存在する。
- 真に異なるオーディエンス。B2Cのニュースサイトとb2Bのデータプロダクトを持つメディア企業。ユーザーが異なり、意図が異なり、すべてが異なる。1つのドメインの下で混在させると、両方に悪影響を与える。
- 規制上の分離。Seahawk Mediaは、コンプライアンスで特定のコンテンツが明らかに分離された環境に存在する必要があった金融クライアントと協働してきた。サブドメインは明確な境界線を提供した。
- 異なるTLDが利用できない国際展開。
brand.frが利用できないがfr.brand.comは利用できる場合、適切なhreflangセットアップを備えたサブドメインは何もないよりはましだ。 - 大規模なコミュニティやアプリセクション。
app.yourdomain.comやcommunity.yourdomain.comで、コンテンツタイプと技術要件が異なりすぎて分離する方が統合するより得るものが多い場合。
サブドメインのSEOコストは実在するが、ルートドメインが既に強力であれば破滅的ではない。DA 60以上のルートドメインがサブドメインを立ち上げると、そのサブドメインは比較的早期に信頼の一部を継承する。DA 15のスタートアップなら、サブドメインはほぼゼロから始まる。その区別が重要だ。
---
監査と計画に実際に使用するツール
クライアントがマルチブランド構造の質問を持ってくるとき、最初のスタックは次のようなものだ：
- [Screaming Frog SEO Spider](https://www.screamingfrog.co.uk/seo-spider/)で、すべての候補ドメインをクロールして現在のオーソリティ分布をマップする。何かを移動することを推奨する前に、バックリンクが実際どこに存在しているのかを見たい。
- Ahrefs、具体的にはSite Explorerでドメインを並べて比較する。参照ドメイン数、DRスコア、トピカルオーソリティの広がりを取得する。
- Google Search Console、クライアントがデータを持っている場合、実際にインプレッションを生み出しているプロパティと休止中のプロパティを見たい。50,000の参照ドメインを持つが、GSCインプレッションがゼロのドメインは、構造の問題ではなくコンテンツの問題がある。
- WP CLI、Multisiteの移行作業に関しては、私はWP CLIの中に生きている。Multisiteの手動データベース移行は特別な種類の苦痛だ。
- RaygunまたはDatadog、移行後のモニタリング。4つのプロパティをマージした場合、最初の6週間はリアルタイムのエラー追跡が必要だ。
監査は通常、中規模のマルチブランドセットアップで4～6時間かかります。スキップして推測するだけなら、アーキテクチャを2回構築し直すはめになります。
---
移行：誰もが過小評価する部分
ここは直言しましょう。移行こそがSEOの実際の仕事が起こる場所です。新しい構造を決定するのはたぶん仕事の20%です。
統合サブフォルダまたはMultisite構造への移行のおおよその順序は以下の通りです：
- すべてのプロパティ全体の既存URLをすべて監査、Screaming Frogで、すべてをエクスポートする。
- すべての旧URLを新しい宛先にマッピングする。すべてだ。「後でリダイレクトを処理する」なんて言い訳は禁止。
- ステージング環境で新しい構造を構築する。Redirect Path（Chrome拡張機能）のようなツールでリダイレクトをテストする。
- コンテンツの移行を最初に行い、静かな日（私の場合は火曜日の朝、トラフィックが低く、監視のために丸一週間ある）にライブにする。
- 影響を受けるすべてのプロパティのサイトマップを24時間以内にGSCに送信する。
- 少なくとも30日間、GSCのクロールエラーを毎日監視する。
- すべての内部リンクを更新する。このステップは常にスキップされている。スキップするな。
ステップ2のリダイレクトマッピングは、ほとんどの代理店がコーナーを切るポイントだ。3段階で移行を実施して後片付けをしなかったせいで、6ホップの301リダイレクトチェーンになっているのを見たことがある。Googleはチェーンを許容するが、それは雑で、各ホップでリンクエクイティが失われる。
「リダイレクトマップは新しいアーキテクチャよりも重要だ。ここで失敗すると、失う必要のなかったランキングを取り戻すのに何か月もかかることになる」。これは移行前に全クライアントに伝えることだ。
---
では、実際どれを選ぶべきか？
正直なところ、あなたの状況次第ですが、こう考えます：
同じような複数のサイト（フランチャイズ、地域版、テンプレート化されたブランド）を管理していて、チームにWordPressの深い知見があるなら、Multisiteを選択すること。WP EngineやKinstaなどのマルチサイト対応ホスティングに投資しろ。共有cPanelプランなんかじゃなく。
ブランドがトピック的に関連していて、ブランド独立性よりもSEOパフォーマンスを優先する場合はサブフォルダ統合を選びましょう。これはサービス業やコンテンツ主導の企業に最も推奨できるアプローチです。
ブランドが本当に異なるオーディエンスに対応している場合、異なる規制環境で運営している場合、または1つのインストール下ではプラグインやパフォーマンスの競合を引き起こすような技術要件がある場合は、サブドメインまたは別ドメインを選びましょう。権威構築の速度低下は受け入れつつ、各プロパティのリンク獲得に投資してください。
そして正直に言うと、あなた固有のバックリンクプロファイル、コンテンツの深さ、チームの技術的能力を監査もせずに、一律の答えを売ろうとする人間がいたら、懐疑的になるべきだ。答えは常にデータの中にあり、教義の中にはない。
---
よくある質問
WordPress Multisiteは SEO に悪影響を与えますか？
本質的には与えません。Multisite自体はクローリングの観点からニュートラルです。SEOへの影響はURLの構造（サブドメイン対サブフォルダ）と、ネットワーク全体でcanonicalタグ、hreflang、XMLサイトマップをどれだけうまく管理できるかから生じます。正規化が重複したMultisiteの設定が悪いと悪影響が出ます。適切に設定されたものなら出ません。
Googleはサブドメインを別々のウェブサイトとして扱いますか？
機能的にはそうだ。Googleは確認済みで、サブドメインをクローリングと評価の際に個別サイトとして扱っている。これはサブドメインがルートからゼロの権威を継承しないという意味ではなく、強力なルートドメインは多少の信頼は渡すが、新しいサブドメインが親ドメインが権威あるからといって自動的にランクインするとは思うな。しない。独自のバックリンクとコンテンツシグナルがなければ。
WordPress Multisiteのドメインマッピングを異なるブランドに使用できますか？
そうだ。Mercator（Human Madeがメンテナンス）やより新しいWordPressバージョンの組み込みドメインマッピングのようなプラグインを使えば、brand2.comをマルチサイトネットワークのサブサイトにマップできる。ポートフォリオブランドを管理するエージェンシーにとって強力だ。SEOの意味では、各マップされたドメインは検索目的では独立したドメインとして動作する。ブランド分離が必要だが共有インフラを使いたい場合に便利だ。
マルチドメインSEO統合で結果が出るまでどのくらいかかりますか？
クライアントが聞きたいよりも長いです。私の経験では、統合移行後にリダイレクトがクリーンで、コンテンツが保持されていれば、ランク付けの意味のある変動が見られるまで3～6か月を計画すべきです。完全な複利効果を見るまでに12か月。もっと早い結果を約束している人は、通常より強いドメインで作業しているか、タイムラインを過小評価しています。
多言語ブランド向けのWordPress Multisiteでhreflangを使用すべきですか？
そうだ、絶対に。異なる言語や地域別コンテンツを配信しているなら。Googleのhreflang文書は実装について詳細だ。WPMLとPolylangの両方がマルチサイト対応モードを持っているが、私の経験ではWPMLのマルチサイトサポートがより実戦的だ。ローンチ後は常にSearch Consoleの国際ターゲティングレポートでhreflangを検証しろ。
---
アーキテクチャの会話は退屈だ。クライアントはコンテンツとランキングについて話したがる。だが同じ統合判断が、良く行われたか悪く行われたかで、2年間で有機成長に90%の差をもたらすのを見てきた。構造を最初に正しく作れ。その後は全て簡単になる。