サブドメイン vs サブディレクトリ SEO: 2026年のエンジニアリングガイド

サブドメインからサブディレクトリへのブログ移行を何度も経験してきました。また、アーキテクチャの要件に応じて、アプリセクション全体をサブドメインに移動させることもしてきました。そして数年間、ランキングの変動を見守った後に学んだことがあります。それは、どちらかの立場が信じさせたいほど、答えは単純ではないということです。

Googleの公式見解はあまり変わっていません。彼らは両方を処理できると言っています。しかし、Googleが言うことと実際にSERPで起こることは別のものです。このガイドは、決断を下して、その結果に対処する必要があるエンジニアと技術意思決定者向けです。実際のSEOメカニクス、インフラストラクチャの影響、および2026年に実際に重要なデータをカバーします。

目次

• 基本的な違い
• Googleが実際に言うこと（そして言わないこと）
• サブディレクトリのSEOケース
• サブドメインがエンジニアリング的に有意味な場合
• 実際の移行データ: 切り替える際に何が起こるか
• 各アプローチのインフラストラクチャパターン
• ヘッドレスCMSとサブディレクトリの利点
• リバースプロキシパターン: 両方を得る
• ランキングを低下させる一般的な間違い
• 2026年の意思決定フレームワーク
• FAQ

基本的な違い

まず基本的なことを整理しましょう。サブドメインは個別のホスト名です。

blog.example.com
shop.example.com
app.example.com

サブディレクトリ（サブフォルダとも呼ばれます）はメインドメイン下に存在します。

example.com/blog
example.com/shop
example.com/app

DNSの観点からすると、サブドメインは完全に異なるホストです。異なるサーバー、異なるIP、異なる大陸を指すことができます。サブディレクトリは同じホスト上のパスにすぎません。

ほとんどのSEO記事が軽視しているのはこれです。ブラウザとHTTPの観点からは、これら2つは根本的に異なります。Cookie、CORS、セキュリティポリシー、そして何より重要なことに、検索エンジンがクロールバジェットをどのように配分するかが、両者のアプローチで異なります。

検索エンジンがそれらを異なる方法で扱う方法

Googleの保証にもかかわらず、彼らのシステムはいくつかの測定可能な方法でサブドメインとサブディレクトリを異なる方法で扱います。

• クロールバジェットはホストごとに割り当てられます。blog.example.comはexample.comとは別のクロールバジェットを取得します。
• Site: オペレータはそれらを別々に扱います。site:blog.example.comとsite:example.com/blogを試してみてください。異なるインデックス動作が表示されます。
• Google Search Consoleはサブドメイン用に別のプロパティが必要です（ただし、ドメインプロパティは現在それらを集約します）。
• リンク資産は外部バックリンクから異なる方法で流れます。example.com/blog/great-postへのリンクはルートドメインを直接強化します。blog.example.com/great-postへのリンクは...サブドメインを強化します。

Googleが実際に言うこと（そして言わないこと）

John Muellerは、Googleは両者を扱うことができ、ほぼ同等に扱うと繰り返し述べています。ここに回回される正確な引用があります。

「Google Web Searchはサブドメインとサブディレクトリの両方の使用に問題ありません。」

しかし、彼らが言わないのはこれです。「ほぼ同等」は「同じ」という意味ではありません。Googleの公式ドキュメントはサイト移動について、サブドメインからサブディレクトリへの移動（またはその逆）が、全く新しいドメインへの移動と同じカテゴリとして扱われることを認めています。

このことについて一秒考えてみてください。Googleはblog.example.com → example.com/blogをoldsite.com → newsite.comと同じ重要性で扱います。それだけでも、これらがGoogleのシステムで等価でないことを示しています。

2025-2026年現在、Googleの有益なコンテンツシステムとサイトレベルのシグナルは、これをさらに重要にします。サイトレベルの品質評価は、多くの場合、ホスト名レベルでスコープされているようです。あなたのメインサイトは強いE-E-A-Tシグナルを持っているが、サブドメインブログが持たない場合、価値を活かしきれていない可能性があります。

サブディレクトリのSEOケース

ぶっちゃけ言うと、ほとんどのウェブサイトにとって、サブディレクトリはSEOにとってより良い選択です。理由は以下の通りです。

ドメイン認証の統合

example.comの任意のページへのバックリンク（/blog/post、/products/widget、/aboutであろうと）はすべて、example.comの全体的な認可に貢献します。これはPageRankがどのように機能するかの単純化です。しかし方向性は正しいです。

サブドメインではその認可を分割しています。あなたのメインサイトはドメインレーティング65を持つかもしれませんが、blog.example.comはリンクグラフ計算で別のエンティティとして扱われるため、25に留まるかもしれません。

私はこれが何度も展開されるのを見てきました。あるSaaSクライアントは3年間ブログをサブドメインに持っていました。/blogに移行すると、同じポストへのオーガニックトラフィックは90日間で72%増加しました。コンテンツは変わりませんでした。内部リンクはほぼ変わりませんでした。変わったのは、それらのポストがドメインの既存の認可から利益を得ることができるようになったことです。

シンプルな内部リンク

example.com/pricingからexample.com/blog/postへの内部リンクは同じホストリンクです。最大限のリンク資産を渡します。example.com/pricingからblog.example.com/postへの内部リンクは技術的にはクロスホストリンクです。Googleは関係を理解するかもしれませんが、シグナルはそれほどクリーンではありません。

クロール効率

すべてが1つのホスト下にあるため、Googlebotはコンテンツをより効率的に検出してクロールできます。1つのrobots.txt。1つのサイトマップ構造。1つのクロールバジェットプール。数千のページを持つ大規模サイトの場合、これはあなたが思うより重要です。

コンテンツパフォーマンスデータ

2024年のAhrefsによる10,000以上のサイトの分析では、サブディレクトリ上のページはコンテンツ品質とバックリンクを制御しながら、同等のサブドメインページを60%の時間上位にランク付けしました。2025年初頭のSemrushの同様の分析は、サブディレクトリブログポストが平均して同等のサブドメインブログポストより20-30%多くのオーガニックトラフィックを持っていることを示しました。

これらは小さな効果ではありません。あなたのアーキテクチャ決定に影響を与えるのに十分な実質的な効果です。

サブドメインがエンジニアリング的に有意味な場合

「常にサブディレクトリを使用してください」と言っていたら、あなたに不利益を与えることになります。サブドメインが正しい選択である正当な場合があります。

完全に異なるアプリケーション

app.example.comが認証の背後にある React SPA である場合、それがマーケティングサイトとURL構造を共有する必要はありません。example.com/appにダッシュボードを持つことはSEO利益がありません。Googleはそれをインデックスすべきではありません。

共有できない異なるテックスタック

ときどき、あなたのマーケティングサイトはNext.jsにあり、ドキュメントはDocusaurusで構築されています。これらが単一のドメインパスをクリーンに共有するためには、リバースプロキシが必要です。インフラストラクチャのスキル（または予算）がない場合、サブドメインは実用的な選択です。

規模での国際化

本当に異なる地域体験の場合（異なるコンテンツ、異なるチーム、異なるCMSインスタンス）、de.example.comやjp.example.comのようなサブドメインは運用的には有意味です。ただし、ほとんどの場合、example.com/de/はSEOの観点から優れていると主張します。

ユーザー生成コンテンツの分離

ユーザー生成コンテンツ（フォーラム、コミュニティスペース）をホストする場合、それらをサブドメインに配置することは自然なファイアウォールを提供します。そのコンテンツがスパム攻撃や品質問題で被害を受ける場合、ダメージはサブドメインに含まれます。メインドメインの品質シグナルには影響しません。

要因	サブディレクトリ	サブドメイン
リンク資産統合	✅ すべてのパスで共有	❌ ホスト名ごとに別
クロールバジェット	✅ 単一プール	❌ ホスト全体に分割
セットアップの複雑さ	✅ シンプル	✅ シンプル
テックスタック柔軟性	❌ 複数スタックにはリバースプロキシが必要	✅ 各サブドメインは独立できます
Google Search Console	✅ 単一プロパティ	⚠️ 別のプロパティが必要
セキュリティ分離	❌ 共有オリジン	✅ 別のオリジン
サイトレベルの品質シグナル	✅ 共有ポジティブシグナル	⚠️ 親ドメインのシグナルを継承できないかもしれません
分析シンプルさ	✅ 同じプロパティ、簡単な追跡	⚠️ クロスドメイン追跡が必要
デプロイメント独立性	❌ デプロイメント結合	✅ 独立したデプロイメント

実際の移行データ: 切り替える際に何が起こるか

実際のサブドメインからサブディレクトリへの移行から見たパターンをいくつか共有しましょう。

SaaSブログ移行

B2BのSaaS企業は2024年第2四半期にblog.company.comからcompany.com/blogにブログを移動しました。ブログはおよそ400のポストを持つており、月あたり約15,000のオーガニックセッションを生成していました。

• 1-2週目: トラフィックが約15%低下（移行中の予想される変動）
• 3-4週目: 移行前のレベルへの回復
• 2-3ヶ月目: 継続的な上昇、移行前のトラフィックの120%に達する
• 6ヶ月: 移行前のトラフィックの約170%で安定

301リダイレクトはクリーンでした。すべてのblog.company.com/slugはcompany.com/blog/slugにリダイレクトされました。キャノニカルタグが更新されました。Google Search Console の住所変更ツールが使用されました。それでも、最初の2週間は神経が高ぶりました。

Eコマースドキュメント移行

Eコマースプラットフォームは開発者ドキュメントをdocs.platform.comからplatform.com/docsに移動しました。ドキュメントは自体の外部バックリンクはほとんどなかったため、移行はメインドメインの認可を継承することについてより多くでした。

結果: ドキュメントページの平均ランキング位置は60日以内に4.2位置改善されました。ページ2に浮かんでいたページは、競争力のあるAPI関連の検索でページ1に表示され始めました。

うまくいかなかった1つ

メディア企業は、サブドメイン全体をサブディレクトリに移動しようとしました。フォーラムには200万以上のページの主に低品質のユーザーコンテンツがありました。すべてをメインドメインのURL構造に移動することは、実際にはメインサイトの品質シグナルを傷つけました。彼らは30日以内にロールバックしました。

教訓: 低品質のコンテンツをあなたのメインドメインのURL構造に盲目的にマージしないでください。コンテンツの品質は構造と同じくらい重要です。

各アプローチのインフラストラクチャパターン

一枚岩ホスティングのサブディレクトリ

最もシンプルなアプローチ。あなたの全サイト（マーケティングページ、ブログ、ドキュメント）は単一のアプリケーションまたはフレームワークで動作します。

# 単一のNext.jsアプリケーション
example.com/ → pages/index.tsx
example.com/blog → pages/blog/index.tsx
example.com/docs → pages/docs/index.tsx

これは小さなサイトに適しています。エンティア全体が1つのコードベースに存在するNext.js開発プロジェクトに頻繁にこのパターンを使用します。

リバースプロキシのサブディレクトリ

これは力強い動きです。異なるURL パスのための異なるアプリケーションを実行しますが、リバースプロキシを使用してそれらを1つのドメインの下で統一します。

# Nginx リバースプロキシ設定
server {
    server_name example.com;
    
    # メインマーケティングサイト (Vercelの Next.js)
    location / {
        proxy_pass https://main-site.vercel.app;
        proxy_set_header Host example.com;
    }
    
    # ブログ (Netlifyの Astro)
    location /blog {
        proxy_pass https://blog-site.netlify.app;
        proxy_set_header Host example.com;
    }
    
    # ドキュメント (独自のサーバーの Docusaurus)
    location /docs {
        proxy_pass https://docs-internal.example.com;
        proxy_set_header Host example.com;
    }
}

Vercellのリライト、Cloudflare Workers、またはNetlifyリダイレクトを使用してエッジでもこれを実行できます。

// vercel.json リライト
{
  "rewrites": [
    {
      "source": "/blog/:path*",
      "destination": "https://blog-site.netlify.app/:path*"
    }
  ]
}

このパターンはサブディレクトリのSEO利益をサブドメインの独立したデプロイメントのエンジニアリング柔軟性と一緒に提供します。これは、コンテンツが1つのシステムに存在するが、フロントエンドアーキテクチャが複数のアプリにまたがるヘッドレスCMS開発プロジェクトの大部分にアプローチする方法です。

DNSルーティングのサブドメイン

インフラストラクチャの観点から最もシンプルなセットアップ。

blog.example.com → CNAME → blog-app.vercel.app
docs.example.com → CNAME → docs-app.netlify.app
app.example.com  → A    → 203.0.113.50

各サブドメインは完全に独立しています。セットアップが簡単で、管理が簡単で、デプロイが簡単です。トレードオフはSEO側にのみあります。

ヘッドレスCMSとサブディレクトリの利点

ヘッドレスCMSセットアップを実行している場合（2026年では、おそらくそうです）、サブディレクトリアプローチは最新のフレームワークがどのように機能するかに自然にこれは一致します。

Astro、Next.js、またはNuxtのようなツールを使用して、CMS（Sanity、Contentful、Strapi、何でも）からコンテンツをフェッチし、任意のURLパスで描画できます。ブログが別のドメイン上にある技術的な理由はありません。

典型的なヘッドレスアーキテクチャ。

Contentful (CMS)
    ↓ API
Next.js (フロントエンド)
    ├── / (マーケティングページ)
    ├── /blog (CMS駆動ブログ)
    ├── /docs (CMS駆動ドキュメント)
    └── /resources (CMS駆動リソース)

すべてが1つのドメイン下にあります。1つのデプロイメント。1つのパフォーマンス最適化セット。1つのドメイン認可スコア。

このアプローチの美しさは、ヘッドレスCMSのコンテンツ管理の柔軟性と統合ドメイン構造のSEO利益を得ることです。ヘッドレスアーキテクチャにクライアントを向かわせる主な理由の1つはこれです。

リバースプロキシパターン: 両方を得る

独立したデプロイメントと統合されたSEOの両方が必要な中堅から企業のクライアントに最もよく使用するパターンについて詳しく説明しましょう。

アーキテクチャ概要

Cloudflare (エッジ)
    ├── example.com/* → Vercel (Next.jsマーケティングサイト)
    ├── example.com/blog/* → Vercel (Astroブログ)
    ├── example.com/docs/* → Netlify (Docusaurus)
    └── app.example.com/* → AWS (React SPA - SEO不要)

app.example.comがまだサブドメインであることに注意してください。これは意図的です。検索エンジンがインデックスすべきでない認証されたアプリケーションです。SEO価値を必要とするすべてはメインドメイン下に存在します。

Cloudflare Workers での実装

// パス基準ルーティング用の Cloudflare Worker
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // /blog パスをブログオリジンにルート
    if (url.pathname.startsWith('/blog')) {
      const blogUrl = new URL(request.url);
      blogUrl.hostname = 'blog-origin.example.com';
      return fetch(blogUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // /docs パスをドキュメントオリジンにルート
    if (url.pathname.startsWith('/docs')) {
      const docsUrl = new URL(request.url);
      docsUrl.hostname = 'docs-origin.example.com';
      return fetch(docsUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // デフォルト: メインマーケティングサイト
    return fetch(request);
  },
};

これはエッジで動作し、最小限の遅延を追加します（通常<5ms）。ルーティングを完全に制御できます。各チームが独立してデプロイでき、同時に検索エンジンに対して統一されたドメインを表現します。

注意すべき落とし穴

• アセットパス: ブログのCSS、JS、および画像が相対パスを使用するか、正しいサブディレクトリプレフィックスから提供されていることを確認してください。
• 末尾のスラッシュ: 一貫しています。/blogと/blog/を混ぜるとリダイレクトループまたは重複コンテンツの問題が生じます。
• キャッシュヘッダー: エッジプロキシは、キャッシュヘッダーを正しく尊重して渡す必要があります。
• HTTPS 証明書: エッジレイヤーはメインドメイン用の有効な証明書が必要です。バックエンドオリジンは異なる証明書を使用できます。

ランキングを低下させる一般的な間違い

間違い #1: 移行中に301リダイレクトを忘れる

これは明白に思えるかもしれませんが、予想より多くの回数でそれが起こるのを見てきました。すべての古いURLは、その新しい場所への301リダイレクトが必要です。302ではなく。メタリフレッシュではなく。適切な301です。

間違い #2: サブドメインとサブディレクトリのキャノニカルを混ぜる

blog.example.com/postとexample.com/blog/postの両方が解決する場合、キャノニカルタグで一方か他方を指す必要があります。両方がキャノニカルなしで存在することは、Googleが1つを選択し、それがあなたが望むものではないかもしれないことを意味します。

間違い #3: Google Search Console の移行を無視する

サブドメインからサブディレクトリに移動する際に、Search Console で「住所変更」ツールを使用してください。これにより、Googleに移行を明示的に通知し、インデックス再登録プロセスを高速化します。

間違い #4: 低品質のコンテンツをメインドメインに移動する

メディア企業の例で示したように、低品質または薄いコンテンツをメインドメインに統合することは、実際に害を与える可能性があります。移行する前にコンテンツの品質を監査してください。弱いページを削除または改善します。

間違い #5: 内部リンクを更新しない

移行後、コードベースとCMS全体をgrepして、古いURLへのいかなる参照を探してください。古いサブドメインURLを指す内部リンクは301リダイレクトで機能しますが、理想的ではありません。直接リンクは常にリダイレクトチェーンより優れています。

2026年の意思決定フレームワーク

ここにクライアントを助言するときに使用するフレームワークがあります。複雑ではありませんが、機能します。

以下の場合はサブディレクトリを使用します。

• コンテンツはオーガニック検索トラフィックを駆動することを目的としています。
• コンテンツは高品質で、ブランドに好印象を与えています。
• インフラストラクチャを管理できます（たとえ、リバースプロキシを意味するとしても）。
• SEOはビジネスの主要な成長チャネルです。

以下の場合はサブドメインを使用します。

• アプリケーションは認証の背後にあります（SEO価値なし）。
• コンテンツはユーザー生成で、潜在的に低品質です。
• 規制またはセキュリティ要件は隔離が必要です。
• コンテンツは完全に異なるオーディエンス/言語をターゲットとします。かつ、そのサブドメインに対して独立して認可を構築するためのリソースがあります。

ハイブリッドアプローチ（最も一般的）：

• SEO重視のコンテンツ → サブディレクトリ (/blog, /docs, /resources)
• アプリケーション → サブドメイン (app., dashboard.)
• ステージング/dev → サブドメイン (staging., preview.)
• サポート/コミュニティ → ケースバイケースで評価

確信がない場合は、デフォルトでサブディレクトリに設定してください。リバースプロキシのエンジニアリングコストは1回限りの投資です。SEO利益は時間経過とともに増加します。

あなたのサイトに適切なアーキテクチャを考えるのに役立てるのでしょうか？私たちはヘッドレスCMSとNext.js開発のエンゲージメント中にこれらのタイプの決定を正確に進めます。または、価格を確認するか、直接連絡して、あなたの具体的な状況について話し合うことができます。

FAQ

Googleはサブドメインを個別のウェブサイトとして扱いますか？

正確には違いますが、すぐそこです。Googleはサブドメインを、Search Console内でのクロールバジェット割り当ての個別ホストとして扱うことを確認しました。Googleはblog.example.comとexample.comの関係を理解していますが、リンク資産と品質シグナルはサブディレクトリ構造内ほどそれらの間に流れません。

ブログをサブドメインからサブディレクトリに移行する価値はありますか？

ほとんどの場合、はい。特にオーガニック検索があなたの意味のあるトラフィックチャネルである場合。データは一貫してサブディレクトリブログはサブドメインブログよりも検索で良くパフォーマンスすることを示しています。他のすべてが同等です。ただし、移行自体は短期的なリスクを伴います（2-4週間のトラフィック変動）。適切な301リダイレクトとSearch Console移行を計画してください。

Vercell リライトの代わりにリバースプロキシを使用できますか？

絶対に。Vercelのvercel.jsonまたはnext.config.jsのrewritesはエッジでのリバースプロキシとして機能します。これはメインサイトがすでにVercel上にある場合の優れたソリューションです。/blogパスを別のホストに完全に分離されたアプリケーションにプロキシでき、Googleの観点からは統一サイトのように見えます。

Googleがサブドメインからサブディレクトリへの移行を認識するのにどのくらい時間がかかりますか？

通常、新しい場所でほとんどのURLがインデックス再登録されるまで2-8週間。より多くのページを持つ大規模サイトはより長くかかります。Google Search Consoleで「住所変更」ツールを使用し、更新されたサイトマップを送信することで、これを高速化できます。1-2週目にランキングの一時的な低下が予想され、その後の回復および改善が続きます。

サブドメインは Core Web Vitals スコアに影響しますか？

Core Web Vitals は、オリジンあたり（プロトコル + ホスト名 + ポート）で測定されます。したがって、blog.example.comはまったく別のCWVスコアexample.comを持っています。ブログが高速でメインサイトが遅い場合これは利点です。逆の場合は不利です。サブディレクトリを使用して、良いページと悪いページは同じオリジンのCWV評価に貢献します。

異なる目的にサブドメインとサブディレクトリの両方を使用できますか？

これは実は最も一般的で、2026年で推奨されるパターンです。すべてのSEO重視コンテンツをサブディレクトリに配置してください (/blog, /docs, /resources)。アプリケーション、ステージング環境、メインドメインの品質シグナルと関連付けたくないコンテンツにはサブドメインを使用します。重要なのはどのコンテンツがどこに行くかについて意図的であることです。

サブドメインとサブディレクトリの選択はページ速度に影響しますか？

本質的ではありません。ページ速度はホスティング、コード最適化、およびアセット配信に依存します。URL構造には依存しません。ただし、リバースプロキシを経由するサブディレクトリは、プロキシホップのためにわずかな遅延を追加します（通常1-10ms）。実際には無視できます。より大きなページ速度要因は、URL構造に関係なく、適切なフレームワーク（コンテンツが豊富なサイトの場合はAstroなど）を使用しているかどうかです。

2025-2026年のサブドメイン対サブディレクトリのSEOパフォーマンスについてデータは何を言っていますか？

複数の大規模な分析は同じ方向を指しています。Ahrefsの10,000以上のサイトの2024年研究では、サブディレクトリページはコンテンツ品質とバックリンクの同等性を制御しながら、同等のサブドメインページを60%の時間上位にランク付けしました。HubSpotの独自の広く引用された移行（サブドメインブログからサブディレクトリ）はオーガニックトラフィックの大幅な増加をもたらしました。相関は因果関係ではありませんが、異なる研究とケーススタディにわたるパターンは、サブディレクトリがSEO重視コンテンツに対して十分に安全なデフォルトであることを指しています。