wordpress-multisite-subfolder-subdomain-seo.html
< BACK 木製のデスクに広げられた設計図が、アンバー色の単一デスクランプに照らされ、深夜の計画決定を想起させるイメージ

WordPress マルチサイト vs サブフォルダ vs サブドメイン:マルチブランド SEO

3年前、あるクライアントがコールに参加した際、いわば混乱したスプレッドシートを持ってきました。7つのブランド。4つのターゲット市場。2つの言語。すべてが別々の WordPress インストールで稼働しており、それぞれが独自のホスティング料金、プラグインライセンス、放置されたブログを抱えていました。彼女は「統合したい」と望んでいました。私は 40 分間かけて、彼女の間違った決定を思いとどまらせました。そしてその間違った決定は、彼女の場合、WordPress マルチサイトでした。out of the wrong decision — and the wrong decision, in her case, was WordPress Multisite.

それは彼女を驚かせました。多くの人々を驚かせます。複数のブランドをやり繰りする際には、マルチサイトは明白な答えのように聞こえます。しかし、マルチブランド 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つの独立したドメインから、親ドメイン配下のマルチサイト サブフォルダネットワークに移行しました。12ヶ月後、4つのブランド中3つのオーガニックトラフィックが倍増しました。4つ目は構造的な問題ではなくコンテンツの問題がありました。構造では薄いページを救うことはできません。

---

WordPress Multisite:優れている場面と悪夢のような場面

本当の利点

Multisiteは、予測可能で反復可能なブランド構造がある場合、本当に優れています。フランチャイズネットワーク、地域版を持つニュース組織、またはローカライズされたマーケティングサイトを立ち上げているSaaS企業を想像してください。1つのコードベース。一元管理されたプラグイン管理。必要に応じて共有ユーザー。

管理効率は実在します。あるクライアント向けに40以上のサイトのネットワークを管理しています。1つのテーマ更新、1つのセキュリティパッチ。すべてで完了です。Multisiteなしなら、月曜日の朝の作業になります。

失敗する場所

Multisiteはブランドが分岐すると厳しい結果をもたらします。ブランドAがブランドBが必要とするものと競合するプラグインが必要になった瞬間、問題が生じます。そしてWordPressプラグインは常にMultisite互換というわけではありません。2024年でも本当にそうです。WP EngineのMultisiteガイドではプラグイン互換性が第1の課題として挙げられていますし、経験からもそれに同意します。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つの異なるオーディエンスを持つ2つの異なるブランドを実行している場合、一方のブランドのドメインの下のサブフォルダーはユーザーにとって奇妙に見えます。ブランド認識は重要です。誰かが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.

---

サブドメイン:その根拠が存在する

サブドメイン反対派に見られたくない。実際に正しい選択肢となるシナリオは存在する。

  1. 真に異なるオーディエンス。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.
  2. 規制上の分離。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.
  3. 異なるTLDが利用不可の国際対応。brand.frが利用不可だがfr.brand.comは利用可能な場合、適切なhreflangセットアップを備えたサブドメインは無いよりマシだ。 When brand.fr isn't available but fr.brand.com is — a subdomain with a proper hreflang setup is better than nothing.
  4. 大規模なコミュニティやアプリセクション。app.yourdomain.comやcommunity.yourdomain.comで、コンテンツタイプと技術要件が異なりすぎて分離する方が統合するより得るものが多い場合。 app.yourdomain.com or community.yourdomain.com where 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個あるのにGSCインプレッションがゼロのドメインは、構造の問題ではなくコンテンツの問題です。 — 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構造への移行のおおよその順序は以下の通りです:

  1. Screaming Frogを使ってすべてのプロパティ全体の既存URLを監査し、すべてをエクスポートする。
  2. すべての旧URLを新しい宛先にマッピングする。すべてだ。「後でリダイレクトを処理する」なんて言い訳は禁止。
  3. ステージング環境で新しい構造を構築する。Redirect Path(Chrome拡張機能)のようなツールでリダイレクトをテストする。
  4. コンテンツを最初に移行し、アクセスの少ない日(火曜日の朝が私は好き——トラフィックが少なく、その後1週間全体を監視できる)に本番化する。
  5. 影響を受けるすべてのプロパティのサイトマップを24時間以内にGSCに送信する。
  6. 少なくとも30日間、GSCのクロールエラーを毎日監視する。
  7. すべての内部リンクを更新する。このステップは常にスキップされている。スキップするな。

ステップ2のリダイレクトマッピングは、ほとんどの代理店がコーナーを切るポイントだ。3段階で移行を実施して後片付けをしなかったせいで、6ホップの301リダイレクトチェーンになっているのを見たことがある。Googleはチェーンを許容するが、それは雑で、各ホップでリンクエクイティが失われる。

「リダイレクトマップは新しいアーキテクチャより重要だ。誤ると、失う必要のなかったランキングを数ヶ月かけて回復させることになる」——移行前にすべてのクライアントに言うことだ。

---

では、実際どれを選ぶべきか?

正直なところ、あなたの状況次第ですが、こう考えます:

複数のサイトネットワークを管理している場合(フランチャイズ、地域版、テンプレート化されたブランド)で、チームがWordPressを深く理解していればMultisiteを選びましょう。WP EngineやKinstaなど、質の高いMultisite対応のホスティングに投資してください。共有cPanelプランは避けます。 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ドキュメントはImplementationについて詳細です。WPMLとPolylangはどちらもMultisiteに対応したモードを持っていますが、私の経験ではWPMLのMultisiteサポートのほうがより実戦的です。ローンチ後は、必ずSearch ConsoleのInternational Targetingレポートでhreflangを検証してください。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%の差をもたらすのを見てきました。まず構造を正しく作ってください。その後は、すべてが簡単になります。

< BACK