3年前、あるクライアントが通話に参加する際、カオスとしか言いようのないスプレッドシートを持ってきました。7つのブランド。4つのターゲット市場。2つの言語。それぞれ独立したWordPressインストール上で運営され、それぞれがホスティング代、プラグインライセンス、放置されたブログを持っていました。彼女は「統合したい」と言いました。私は40分間をかけて、彼女の場合において間違った判断——つまりWordPress Multisiteは選ぶべきではないという判断に彼女を説得しました。WordPress installs, each with its own hosting bill, its own plugin licences, its own abandoned blog. She wanted to "consolidate." I spent forty minutes talking her out of the wrong decision, and the wrong decision, in her case, was WordPress Multisite.
重要なポイント：サブフォルダは権限を集約し、サブドメインはそれを分散させ、Multisiteは SEO の観点よりも運用面での判断です。ガバナンスが必要でない限り、デフォルトではサブフォルダを選択してください。Subfolders consolidate authority, subdomains split it, and Multisite is an ops decision rather than an SEO one; default to subfolders unless governance forces otherwise.
それは彼女を驚かせました。多くの人々を驚かせます。複数のブランドをやり繰りする際には、マルチサイトは明白な答えのように聞こえます。しかし、マルチブランド WordPress プロパティを SEO 向けにどのように構成するかという問題は、実際には最も重大な影響を与えるアーキテクチャ上の決定の 1 つであり、ほぼ間違いなく、それが値する微妙さを得ることはありません。
では、それを改善しましょう。
---
3つの構成、簡潔に
意見を述べる前に、まず基本を確認しておきましょう。
- WordPress Multisite。共有コードベースで複数のサイトを実行する単一のWordPressインストール。各サイトはサブドメイン（brand2.yourdomain.com）またはサブフォルダ（yourdomain.com/brand2/）、あるいはMercatorのようなプラグイン経由でマップされたドメイン（brand2.com）にすることができます。, a single WordPress installation running multiple sites under a shared codebase. Each site can be a subdomain (
brand2.yourdomain.com) or a subfolder (yourdomain.com/brand2), or even a mapped domain (brand2.com) via a plugin like Mercator. - 別のサブフォルダ。1つのWordPressインストール。yourdomain.com/brand2/のようなパスからコンテンツを配信。技術的にはMultisiteではありません。ツールで模擬することもできますし、特定のページビルダー設定で適切に実装することもできますが、通常は分割されたコンテンツを持つ1つのサイトを意味します。, one WordPress install, content served from paths like
yourdomain.com/brand2/. Not technically Multisite. Can be faked with tools, or done properly with certain page-builder setups, but usually it means one site with segmented content. - サブドメイン。brand2.yourdomain.com。Multisite内か、別のサブドメインを指す完全に独立したWordPressインストールのいずれか。,
brand2.yourdomain.com. Either within Multisite or as a fully separate WordPress install pointing to a different subdomain.
混乱が生じる理由は通常、Multisiteがサブドメインまたはサブフォルダーのいずれかを使用できるからです。そのため人々はホスティングアーキテクチャをURL構造と混同します。これらは独立した決定です。頭の中でも分けておきましょう。can use subdomains or subfolders. So people conflate the hosting architecture with the URL structure. They're separate decisions. Keep them separate in your head.
---
Googleが実際にこれらを扱う方法（神話なし）
多くのエージェンシーオーナーをつまずかせる点は次の通りです。GoogleはSEOコミュニティが18ヶ月ごとに再び議論し続けているにもかかわらず、この点について非常に一貫性を保っています。
Googleの公式ドキュメンテーションでは、サブフォルダーとサブドメインを異なるエンティティとして扱っています。サブドメインはドメインオーソリティを継承できますが、Googleは明示的にサブドメインをクローリングとインデックス目的で別のサイトとして扱うと述べています。John Muellerは2019年のSearch Central office hoursで確認しました。コンテンツがトピック関連のとき、サブフォルダーは一般的にサブドメインより信号をよりよく統合します。 treats subfolders and subdomains as distinct entities. Subdomains can inherit domain authority, but Google has said explicitly that it treats subdomains as separate sites for crawling and indexing purposes. John Mueller confirmed this in a 2019 Search Central office hours: subfolders generally consolidate signals better than subdomains when the content is topically related.
これは実際には何を意味するのでしょうか？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ガイドはプラグイン互換性をトップの摩擦ポイントとしてリストしており、私は実務経験からそれに同意します。WP Engine's Multisite guide lists plugin compatibility as the number-one friction point, and I'd agree from experience.
パフォーマンス分離も弱いです。1つのサイトのトラフィックスパイクが同じインストール上の別のサイトに影響を与える可能性があります。あるサブサイトでのプロダクトローンチが、共有wp-cronキューがハンマーで叩かれたために3つの他のサイトを遅くする場面を見たことがあります。夜11時にクライアントに説明するのは楽しくありません。wp-cron queue got hammered. Not fun to explain to a client at 11pm.
正直なところの経験則
ブランドがチームを共有していて、コードベースの意図が同じで、プラグイン要件で分岐しないなら――Multisiteの価値がある。本当に別のビジネスユニットで技術要件が異なるなら、別インストールのほうが管理負荷は高くても頭痛の種は少ない。
---
サブフォルダー構造：SEOでは過小評価、エージェンシーでは過度に未活用
私はサブフォルダーについてやや熱心です。すべての状況に適しているわけではありませんが、エージェンシーはそれらを見落としがちです。
マルチブランドまたはマルチカテゴリーのプレゼンスをparentbrand.com/subbrand/として構造化すると、そのパスの下のあらゆるコンテンツがルートドメインの権威性に貢献します。/subbrand/の下の投稿への強力なバックリンクは、ドメイン全体を押し上げます。この数学は時間とともに複利で増殖する方法で、個別ドメインが迅速に複製することができません。parentbrand.com/subbrand/, every piece of content under that path contributes to the root domain's authority. A strong backlink to a post under /subbrand/ lifts the whole domain. The maths on this compounds over time in a way that separate domains simply don't replicate quickly.
2020年、私はイギリスのフィンテック企業で、3つの製品ラインに対して3つの別々のドメインを立ち上げていた案件に携わった。3つのドメイン全体の被リンクプロファイルを合算すると、約1,400の参照ドメインがあった。8ヶ月かけて、彼らの最強ドメイン配下のサブフォルダ構造に統合した。14ヶ月後には、那些シグナルが実質的にプールされ――弱かった製品ラインが、それまで手も付けていなかったキーワードでランキングしているのが見えるようになった。ドメインオーソリティが周囲で上昇していたからだ。
トレードオフ
サブフォルダー構造には規律が必要です。URLタクソノミーは最初から整理する必要があります。6か月後に/brand-a/を/brand-a-uk/に変更することはリダイレクトの手間です。構築後ではなく、構築前にタクソノミーを計画してください。/brand-a/ to /brand-a-uk/ six months later is a redirect headache. Plan the taxonomy before you build, not after.
また――本当に異なるオーディエンスを持つ2つの別々のブランドを展開しているなら、1つのブランドドメイン配下のサブフォルダは利用者には奇妙に見える。ブランド認識が大事だ。fashionlabel.com/industrial-tools/ にランディングしたら、ポジショニングの会話で何か上手くいってない。different brands with different audiences, a subfolder under one brand's domain looks odd to users. Brand perception matters. If someone lands on fashionlabel.com/industrial-tools/, something has gone wrong in the positioning conversation.
---
サブドメイン：その根拠が存在する
サブドメイン反対派に見られたくない。実際に正しい選択肢となるシナリオは存在する。
- 真に異なるオーディエンス。B2Cのニュースサイトとb2Bのデータプロダクトを持つメディア企業。ユーザーが異なり、意図が異なり、すべてが異なる。1つのドメインの下で混在させると、両方に悪影響を与える。 A media company with a B2C news site and a B2B data product. Different users, different intent, different everything. Mixing them under one domain would hurt both.
- 規制上の分離。Seahawk Mediaは、コンプライアンスで特定のコンテンツが明らかに分離された環境に存在する必要があった金融クライアントと協働してきた。サブドメインは明確な境界線を提供した。 Seahawk has worked with financial clients where compliance required certain content to live in a demonstrably separate environment. Subdomains gave a clean boundary.
- 異なるTLDが利用できない国際展開の場合。brand.frが利用できないが fr.brand.com が利用できるなら――適切なhreflangセットアップを持つサブドメインは何もないよりはマシだ。 When
brand.frisn't available butfr.brand.comis, a subdomain with a properhreflangsetup is better than nothing. - 大規模なコミュニティやアプリセクション。app.yourdomain.comやcommunity.yourdomain.comで、コンテンツタイプと技術要件が異なりすぎて分離する方が統合するより得るものが多い場合。
app.yourdomain.comorcommunity.yourdomain.comwhere the content type and technical requirements are so different that separation saves more than consolidation gains.
サブドメインのSEOコストは実在するが、ルートドメインが既に強力であれば破滅的ではない。DA 60以上のルートドメインがサブドメインを立ち上げると、そのサブドメインは比較的早期に信頼の一部を継承する。DA 15のスタートアップなら、サブドメインはほぼゼロから始まる。その区別が重要だ。
---
監査と計画に実際に使用するツール
クライアントがマルチブランド構造の質問を持ってくるとき、最初のスタックは次のようなものだ：
- [Screaming Frog SEO Spider](https://www.screamingfrog.co.uk/seo-spider/) ――候補ドメイン全体をクロールして、現在のオーソリティ分布をマッピングする。何かを移動することを勧める前に、被リンクが実際どこに存在しているかを見たい。, crawl all candidate domains and map the current authority distribution. I want to see where the backlinks actually live before I recommend moving anything.
- Ahrefs――特にSite Explorerでドメイン同士を並べて比較する。参照ドメイン数、DRスコア、トピカルオーソリティの展開を抽出する。, specifically the Site Explorer comparing domains side by side. I'll pull referring domain counts, DR scores, and topical authority spread.
- Google Search Console――クライアントがデータを持っていたら、どのプロパティが実際にインプレッションを生んでいるか、どれが死んでいるか見たい。50,000の参照ドメインがあるのにGoogle Search Consoleのインプレッションがゼロなドメインは、構造の問題じゃなくてコンテンツの問題を抱えている。, if the client has data, I want to see which properties are actually driving impressions versus sitting dead. A domain with 50,000 referring domains but zero GSC impressions has a content problem, not a structure problem.
- WP CLI――Multisite移行作業なら、私はWP CLIに住みついてる。Multisiteの手動データベース移行は特別な種類の苦しみだ。, for any Multisite migration work, I live in WP CLI. Manual database migrations for Multisite are a special kind of painful.
- RaygunまたはDatadog――移行後のモニタリング。4つのプロパティをマージしたなら、最初の6週間は本当の意味でのエラー追跡が欲しい。, post-migration monitoring. If I've merged four properties, I want real-time error tracking for the first six weeks.
監査は通常、中規模のマルチブランドセットアップで4～6時間かかります。スキップして推測するだけなら、アーキテクチャを2回構築し直すはめになります。
---
移行：誰もが過小評価する部分
ここは直言しましょう。移行こそがSEOの実際の仕事が起こる場所です。新しい構造を決定するのはたぶん仕事の20%です。
統合サブフォルダまたはMultisite構造への移行のおおよその順序は以下の通りです：
- 全プロパティの既存URL全てを監査する――Screaming Frog、全てエクスポートする。
- すべての旧URLを新しい宛先にマッピングする。すべてだ。「後でリダイレクトを処理する」なんて言い訳は禁止。
- ステージング環境で新しい構造を構築する。Redirect Path（Chrome拡張機能）のようなツールでリダイレクトをテストする。
- コンテンツを最初に移行し、静かな日（火曜日の朝は私にとって効果的です——トラフィックが少なく、監視する1週間が完全に残っています）にライブにします。
- 影響を受けるすべてのプロパティのサイトマップを24時間以内にGSCに送信する。
- 少なくとも30日間、GSCのクロールエラーを毎日監視する。
- すべての内部リンクを更新する。このステップは常にスキップされている。スキップするな。
ステップ2のリダイレクトマッピングは、ほとんどの代理店がコーナーを切るポイントだ。3段階で移行を実施して後片付けをしなかったせいで、6ホップの301リダイレクトチェーンになっているのを見たことがある。Googleはチェーンを許容するが、それは雑で、各ホップでリンクエクイティが失われる。
「リダイレクトマップは新しいアーキテクチャよりも重要です。これを間違えると、失う必要がなかったランキングを取り戻すのに何ヶ月も費やすことになります。」——移行前に私がすべてのクライアントに伝えることです。
---
では、実際どれを選ぶべきか？
正直なところ、あなたの状況次第ですが、こう考えます：
同様のサイトのネットワーク（フランチャイズ、地域版、テンプレート化されたブランド）を管理していて、チームがそれを処理するためのWordPressの深い知識を持っている場合は、Multisiteを選択してください。WP EngineまたはKinstaなどの高品質なMultisite互換ホスティングに投資してください——共有cPlanではなく。 if you're managing a network of similar sites (franchises, regional editions, templated brands) and your team has the WordPress depth to handle it. Invest in quality Multisite-compatible hosting, WP Engine or Kinsta, not a shared cPanel plan.
ブランドがトピック的に関連していて、ブランド独立性よりもSEOパフォーマンスを優先する場合はサブフォルダ統合を選びましょう。これはサービス業やコンテンツ主導の企業に最も推奨できるアプローチです。 if your brands are topically related and SEO performance is the priority over brand independence. This is my most-recommended path for service businesses and content-led companies.
ブランドが本当に異なるオーディエンスに対応している場合、異なる規制環境で運営している場合、または1つのインストール下ではプラグインやパフォーマンスの競合を引き起こすような技術要件がある場合は、サブドメインまたは別ドメインを選びましょう。権威構築の速度低下は受け入れつつ、各プロパティのリンク獲得に投資してください。 if your brands genuinely serve different audiences, operate in different regulatory environments, or have technical requirements that would create plugin or performance conflicts under one install. Accept the slower authority build and invest in link acquisition for each property.
そして正直なところ、誰かがあなたの特定のバックリンク・プロフィール、コンテンツの深さ、およびチームの技術的能力を監査せずに一律の答えを販売しようとしている場合は、懐疑的になってください。答えは常にデータの中にあり、教義の中にはありません。
---
よくある質問
WordPress Multisiteは SEO に悪影響を与えますか？
本質的には与えません。Multisite自体はクローリングの観点からニュートラルです。SEOへの影響はURLの構造（サブドメイン対サブフォルダ）と、ネットワーク全体でcanonicalタグ、hreflang、XMLサイトマップをどれだけうまく管理できるかから生じます。正規化が重複したMultisiteの設定が悪いと悪影響が出ます。適切に設定されたものなら出ません。how you structure the URLs (subdomains vs. subfolders) and how well you manage canonical tags, hreflang, and XML sitemaps across the network. A badly configured Multisite with duplicate canonicals will hurt. A properly set-up one won't.
Googleはサブドメインを別々のウェブサイトとして扱いますか？
はい、機能的には。Googleはサブドメインをクローリングおよび評価のための別個のサイトとして扱うことを確認しています。それはルートからゼロの権限を相続しないという意味ではありません——強いルートドメインはいくつかの信頼を渡します——しかし、新しいサブドメインが親ドメインが権威的であるため自動的にランク付けされると仮定しないでください。独自のバックリンクおよびコンテンツシグナルなしではそうなりません。
WordPress Multisiteのドメインマッピングを異なるブランドに使用できますか？
はい。Mercator（Human Madeによってメンテナンスされています）またはより新しいWordPressバージョンの組み込みドメインマッピングのようなプラグインを使用すれば、brand2.comをMultisiteネットワーク内のサブサイトにマッピングできます。これはポートフォリオブランドを管理しているエージェンシーにとって強力です。SEOの意味は、各マッピングされたドメインが検索目的のための独立したドメインとして動作するということです——ブランドの分離は必要だが共有インフラストラクチャが必要な場合に有用です。brand2.com to a subsite in your Multisite network. This is powerful for agencies managing portfolio brands. The SEO implication is that each mapped domain behaves as its own independent domain for search purposes, useful if you want brand separation but shared infrastructure.
マルチドメインSEO統合で結果が出るまでどのくらいかかりますか？
クライアントが聞きたいよりも長いです。私の経験では、統合移行後にリダイレクトがクリーンで、コンテンツが保持されていれば、ランク付けの意味のある変動が見られるまで3～6か月を計画すべきです。完全な複利効果を見るまでに12か月。もっと早い結果を約束している人は、通常より強いドメインで作業しているか、タイムラインを過小評価しています。
多言語ブランド向けのWordPress Multisiteでhreflangを使用すべきですか？
はい、絶対に——異なる言語または地域コンテンツを提供している場合。Googleのhreflangドキュメンテーションは実装について徹底しています。WPMLとPolylangの両方にMultisite互換モードがありますが、WPMLのMultisiteサポートは私の経験ではより戦闘テストされています。ローンチ後、Search Consoleの国際ターゲティングレポートでhreflangsを常に検証してください。Google's hreflang documentation is thorough on implementation. WPML and Polylang both have Multisite-compatible modes, though WPML's Multisite support is more battle-tested in my experience. Always validate your hreflang with Search Console's International Targeting report after launch.
---
アーキテクチャの会話は退屈です。クライアントはコンテンツとランキングについて話したいです。しかし、同じ統合決定を目撃してきました——よく行われたか悪く行われたか——2年間で有機成長に90％の違いを生み出します。最初に構造を正しく設定します。そこからすべてが簡単になります。