サブドメインではなくサブディレクトリでブログをホストする方法

SEOにおいてサブディレクトリがサブドメインを上回る理由

検索エンジンは、サブドメインとサブディレクトリをインデックスおよびランキングモデルにおいて異なる方法で扱います。ただし、その正確なメカニズムは部分的に非公開です。Googleの公式ドキュメントによれば、検索エンジンは「サブドメインとメインドメイン間の関係を判定しようとする」としていますが、この関連付けは自動的でも保証されるものでもありません（Google Search Central, Subdomains and Google Search）。1 実務的な含意として、blog.example.comで獲得されたバックリンクおよびランキングシグナルは、example.com/blogでホストされたコンテンツと同じ効率でexample.comに転送されません。

この区別は、検索エンジンがドメイン権威をモデル化する方法に由来します。サブドメインはDNスの下の技術的に独立したホスト名である一方、サブディレクトリは同じホスト名内のパスです。検索エンジンはドメインレベルの権威計算を適用します。つまり、1つのサブドメインで蓄積された権威は、親ドメインの権威スコアを直接強化しません。対照的に、example.com/blog内のすべてのコンテンツは同じドメイン権威プールを共有し、ランキングシグナルを統合します。

  • 前提条件：* この分析は、標準的な商用検索エンジン（Google、Bing）の動作を想定しており、専門的または独自の検索実装は考慮していません。

SEOケーススタディからの実証的証拠がこの区別を支持しています。サブドメインからサブディレクトリ構造への移行を文書化した複数の事例は、測定可能なオーガニックトラフィックの増加を報告しており、バックリンクプロファイルとコンテンツの成熟度に応じて、通常15～35%の範囲です。2 しかし、これらの利益は保証されるものではなく、リダイレクト、正規化、およびインデックスシグナルの適切な実装に依存します。これらの要因については、後続のセクションで扱います。

サブディレクトリアプローチはまた、技術的な断片化を軽減します。単一のrobots.txtファイルがドメイン全体のクロール動作を管理し、サブドメイン用に個別のクロール指示を維持する必要性を排除します。統一されたXML サイトマップと統合されたアナリティクス実装により、監視とトラブルシューティングが簡素化され、マルチドメイン設定で一般的に発生する設定エラーが減少します。

  • 前提条件：* これらの利益は、適切な技術的実装を想定しています。リダイレクト、正規タグ、またはプロキシ設定の設定ミスは、これらの利点を無効にするか、逆転させる可能性があります。

ドメイン権威の流れを示すフロー図。外部サイトからのバックリンクが、サブドメイン構造（subdomain1.example.com、subdomain2.example.com、subdomain3.example.com）では3つに分散され、権威が弱化して検索順位が低下する一方、サブディレクトリ構造（example.com/directory1、example.com/directory2、example.com/directory3）では統合され、権威が強化されて検索順位が向上することを視覚化した図。

  • 図2：ドメイン権威の集約メカニズム - サブディレクトリによる統合効果（出典：Google Search Central、SEO理論）*

技術アーキテクチャ：リバースプロキシの実装

ブログコンテンツを別のサーバーでホストしながら、プライマリドメインのサブディレクトリの下に提示するには、リバースプロキシが必要です。リバースプロキシは、リクエストをインターセプトし、バックエンドサーバーに転送し、バックエンドの実際の場所を公開することなくクライアントにレスポンスを返すサーバーコンポーネントです。

リバースプロキシの機能方法

ユーザーがexample.com/blog/post-titleをリクエストすると、リバースプロキシはこのリクエストをインターセプトし、実際のブログサーバー（blog-server.internal:8080またはマネージドプラットフォームである可能性があります）に転送します。ブログサーバーはリクエストを処理し、レスポンスを返します。リバースプロキシはこのレスポンスをユーザーに返し、ユーザーはコンテンツがexample.comから発信されたものと認識します。

一般的なリバースプロキシソリューションには以下が含まれます：

  • Nginx（オープンソース；広く展開されている）
  • Apache HTTP Server with mod_proxy（オープンソース；レガシーサポート）
  • Cloudflare Workers（マネージドサービス；エッジベース）
  • AWS CloudFront with custom origins（マネージドサービス；AWSエコシステム）

重要な設定要件

  • ヘッダー転送：* リバースプロキシは、機能を維持するためにHTTPヘッダーを保持または正しく変換する必要があります：

  • Hostヘッダー： 元のリクエストホスト（example.com）を反映する必要があり、バックエンドサーバーのホスト名ではありません。これを正しく転送しないと、バックエンドアプリケーションが不正なURLを生成します。

  • X-Forwarded-For： クライアントの元のIPアドレスを保持し、アナリティクスとセキュリティログに不可欠です。

  • X-Forwarded-Proto： 元のリクエストがHTTPかHTTPSかを通信し、混合コンテンツ警告とリダイレクトループを防止します。

  • パス書き換え：* ブログソフトウェアは通常、ルートパス（/）でのリクエストを想定しています。リクエストが/blog/post-titleに到着すると、プロキシはバックエンドに転送する前にパスを/post-titleに書き換え、その後レスポンスURLを/blog/post-titleに書き換える必要があります。不正なパス書き換えは404エラーと壊れたアセットリンクを引き起こします。

  • クッキースコープ管理：* ブログバックエンドによって設定されたクッキーは、メインドメインからのクッキーと競合する可能性があります。クッキーは、認証失敗またはセッション競合を防ぐために、正しいドメインとパスにスコープされる必要があります。プロキシはクッキードメイン属性を書き換える必要がある場合があります。

  • SSL/TLSサーティフィケート：* リバースプロキシはexample.comのSSLサーティフィケートが必要です。プロキシとバックエンド間の接続は、HTTP（プライベートネットワーク上の場合）またはHTTPS（パブリックインターネット経由の場合）を使用できます。これにより、複数のサブドメイン用に個別のサーティフィケートを維持することと比較して、サーティフィケート管理が簡素化されます。

  • キャッシング考慮事項：* リバースプロキシキャッシング（Cache-ControlおよびETagなどのヘッダー経由）は、バックエンドに接触することなくキャッシュされたコンテンツを提供することで、レスポンス時間を改善できます。ただし、設定ミスされたキャッシングは古いコンテンツを提供する可能性があります。キャッシュ無効化戦略はブログ更新を考慮する必要があります。

  • 前提条件：* このセクションは、リバースプロキシとバックエンドが同じネットワーク上にあるか、セキュアなチャネル経由で接続されていることを想定しています。プロキシとバックエンド間のパブリックインターネット接続は、このスコープを超えた追加のセキュリティ考慮事項を導入します。

異なるホスティングシナリオの実装戦略

実装の実現可能性と複雑さは、ホスティングアーキテクチャとプラットフォームの制約に基づいて大きく異なります。

ホスティング環境、スケーラビリティ要件、クラウドプロバイダ選択、統合方式、技術スタックの5つの判定ポイントを経由して、3つの実装パス（従来型、分散型、イベント駆動型）のいずれかに到達する意思決定ツリー。各判定で異なるルートが分岐し、最終的に実装完了に至る流れを示す。

  • 図7：ホスティングシナリオ選択の意思決定フロー*

自己ホストまたはVPS環境

完全なサーバーコントロールにより、NginxまたはApacheは最大の柔軟性を提供します。典型的なNginx設定はlocationブロックを使用してプロキシ動作を定義します：

location /blog/ {
    proxy_pass [http://blog-backend:8080/;](http://blog-backend:8080/;)
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_redirect [http://blog-backend/](http://blog-backend/) [http://$host/blog/;](http://$host/blog/;)
}

この設定は/blog/へのリクエストをバックエンドサーバーに転送し、ヘッダーを保持し、リダイレクトを書き換えます。本番環境への展開前に、ステージング環境でのテストは必須です。

マネージドブログプラットフォーム

WordPress.com、Medium、Ghostなどのプラットフォームは、通常、ドメインレベルのコントロールを期待し、サブディレクトリホスティングを直接サポートしていません。オプションには以下が含まれます：

  • エンタープライズプラン： 一部のプラットフォームは、サブディレクトリサポートをプレミアム機能として提供しています（例：WordPress.com Business plan）。

  • APIベースの統合： APIを介してブログコンテンツを取得し、カスタムテンプレートを使用してプライマリドメインでレンダリングします。このアプローチは開発リソースを必要としますが、完全なURL制御を提供します。

  • 回避策： 一部のプラットフォームはカスタムドメイン設定を許可します。サブドメインをプラットフォームにポイントし、そのサブドメインをプライマリドメインのサブディレクトリにプロキシできます。これにより、サブドメインを完全に排除することなく複雑さが増します。

  • 前提条件：* このアプローチにコミットする前に、プラットフォームのドキュメントを確認してください。プラットフォームの制限により、サブディレクトリホスティングが実用的でない可能性があります。

静的サイトジェネレータ

静的サイトジェネレータ（Hugo、Jekyll、Next.js）は、最も単純な実装を提供します。ビルド出力は、プライマリサーバー上の/blogに直接展開できます。プロキシ設定は不要です。Webサーバーは/blogディレクトリから静的ファイルを提供するだけです。このアプローチはバックエンドの複雑さを排除し、最適なパフォーマンスを提供します。

ヘッドレスCMSソリューション

ヘッドレスCMSプラットフォーム（Contentful、Strapi、Sanity）は、コンテンツ管理をプレゼンテーションから分離します。フロントエンドアプリケーション（React、Vue、Next.js）はAPIを介してコンテンツを取得し、完全なURL制御でレンダリングします。フロントエンドはプライマリドメイン上の/blogに展開でき、バックエンド制約なしでサブディレクトリホスティングを提供します。

サーバーレス関数

AWS Lambda、Google Cloud Functions、またはCloudflare Workersは、動的にリクエストをプロキシできます。ただし、コールドスタートレイテンシ（関数が初期化されるときの遅延）はレスポンス時間に影響を与える可能性があります。このアプローチは低トラフィックブログに対して実行可能ですが、高トラフィックシナリオでは効率的にスケーリングしない可能性があります。

  • トレードオフ分析：* 各アプローチにはトレードオフが関わります：
  • 自己ホストプロキシ： 最大のコントロール；インフラストラクチャの専門知識と継続的なメンテナンスが必要です。
  • エンタープライズサポート付きマネージドプラットフォーム： 複雑さの軽減；より高いコスト；潜在的なベンダーロックイン。
  • 静的ジェネレータ： 最適なパフォーマンス；コンテンツ更新のための再構築と再展開が必要です。
  • ヘッドレスCMS： 柔軟性；フロントエンド開発リソースが必要です。
  • サーバーレス： 最小限のインフラストラクチャ；潜在的なレイテンシとコストスケーリングの問題。

技術的リソース、トラフィック量、およびメンテナンス容量に基づいて選択してください。

正規URLとリダイレクトの処理

適切な正規化とリダイレクト実装は、移行中および移行後のSEO成功のために譲歩できません。

リダイレクトチェーンの問題を示す比較チャート。単一リダイレクト（推奨）と複数チェーンリダイレクト（非推奨）の3つの指標を比較。クローラー負荷は単一で20に対し複数で85、レスポンスタイムは単一で150msに対し複数で520ms、SEO効果は単一で95に対し複数で45と、複数チェーンリダイレクトが全ての指標で劣っていることを示す。

  • 図9：リダイレクトチェーンの影響比較（出典：SEO技術仕様、HTTP標準）*

ユーザリクエストから始まり、HTTPリダイレクトステータスコード（301永続的、302一時的、307一時的）の分岐、検索エンジンのリンク評価転送の有無、Rel=Canonicalタグの確認、最終的なインデックス処理までの全体フローを示す図。各ステップで検索エンジンの処理内容を明示。

  • 図8：カノニカルURL・リダイレクト処理フロー（HTTP標準・Google Search Central準拠）*

301リダイレクト

blog.example.comからexample.com/blogへの移行時、すべてのURLは301（永続）ステータスコードでリダイレクトする必要があります。これには以下が含まれます：

  • ブログ投稿URL（例：blog.example.com/post-title → example.com/blog/post-title）
  • カテゴリおよびタグアーカイブページ
  • 著者ページ
  • ページネーションページ
  • アセットURL（CSS、JavaScript、画像）（サブドメインから提供されていた場合）

不完全なリダイレクトカバレッジは404エラー、壊れたバックリンク、およびSEO価値の喪失を引き起こします。移行前にGoogle Search Consoleのすべてのインデックス付きURLを監査して、包括的なリダイレクトカバレッジを確保してください。

  • 前提条件：* リダイレクトはサーバーレベル（HTTP 301）またはリバースプロキシ経由で実装される必要があります。クライアント側のリダイレクト（JavaScript）は、検索エンジンのクローリングに対して信頼できません。

正規タグ

正規タグは、重複コンテンツの優先URLを明示的に宣言します。移行中、正規タグはブログソフトウェアが異なるデフォルトを生成する場合でも、サブディレクトリURLをポイントする必要があります。例えば：

<link rel="canonical" href="[https://example.com/blog/post-title"](https://example.com/blog/post-title") />

このタグは、ページネーションされたコンテンツを含むすべてのブログページに存在する必要があります。不正または欠落している正規タグは、インデックス作成の混乱を引き起こし、ランキングシグナルを希釈する可能性があります。

RSSフィード更新

RSSフィードは、新しいURLを反映するために明示的な更新が必要です。古いフィードURLは、既存の購読者の破損を防ぐために新しいフィードURLにリダイレクトする必要があります。フィードリーダーはリダイレクトを確実に従わない可能性があるため、移行中に古いフィードと新しいフィードの両方を一時的に維持することを検討してください。

内部リンク更新

プライマリドメイン全体の内部リンク（ナビゲーション、関連投稿、フッターリンク）は、新しいサブディレクトリURLをポイントするように体系的に更新する必要があります。これは、サイト構造に応じて、手動またはセミオートメーションプロセスです。不完全な更新は、混合内部リンクプロファイル（一部は古いURLをポイント、一部は新しいURLをポイント）をもたらし、検索エンジンを混乱させる可能性があります。

外部バックリンク

古いサブドメインURLをポイントする外部バックリンクは、引き続きそうします。これらのバックリンクは価値があり、失われるべきではありません。301リダイレクトは、リンク権威が新しいURLに転送されることを保証します。ただし、ブログにリンクしている高権威サイトに連絡し、URL更新をリクエストすることで、権威の転送を加速できます。

Search Console設定

Google Search Consoleは、サブドメインとサブディレクトリの個別の検証を必要とします。移行後：

  1. Search Consoleでサブディレクトリプロパティ（example.com/blog）を検証します。
  2. 優先ドメイン設定を更新して、新しい構造を反映させます。
  3. サブディレクトリの更新されたサイトマップを送信します。
  4. 古いサブドメインプロパティでクロールエラーを監視し、リダイレクトが機能していることを確認します。

Search Consoleを正しく設定しないと、インデックス作成の可視性の喪失とランキング回復の遅延が発生する可能性があります。

一般的な落とし穴とトラブルシューティング

リバースプロキシのトラブルシューティングガイド表。キャッシュ更新不具合、リダイレクトループ、SSL/TLSハンドシェイク失敗、レスポンス遅延、502エラー、ヘッダー転送不具合、メモリリーク、接続タイムアウト、アクセス拒否の9つの問題について、各々の原因、診断方法、解決策を記載。

  • 表1：リバースプロキシ実装のトラブルシューティングガイド*

相対URL処理

ブログソフトウェアは、ルートレベルアクセスを想定して、相対URL（例：/post/my-post）を生成することが多いです。/blogから提供される場合、これらのURLは/post/my-postではなく/blog/post/my-postになり、404エラーが発生します。リバースプロキシはこれらのURLを書き換えるか、ブログソフトウェアは/blogプレフィックスを含むURLを生成するように設定される必要があります。

  • 軽減策：* ブログソフトウェアのベースURL設定を設定して、利用可能な場合は/blogを含めます。それ以外の場合は、プロキシレイヤーでURL書き換えを実装します。

アセット読み込み失敗

CSS、JavaScript、および画像アセットは、元のサブドメインをポイントする絶対URLを使用するテンプレート（例：[https://blog.example.com/assets/style.css）を使用する場合、読み込みに失敗する可能性があります。リバースプロキシは、CSSまたはJavaScriptファイル内のURLを自動的に書き換えることはできません。](https://blog.example.com/assets/style.css`）を使用する場合、読み込みに失敗する可能性があります。リバースプロキシは、CSSまたはJavaScriptファイル内のURLを自動的に書き換えることはできません。)

  • 軽減策：* ブログテンプレートを更新して相対URLを使用するか、ブログソフトウェアを設定して新しいサブディレクトリをポイントする絶対URLを生成します。ステージングでアセット読み込みを徹底的にテストします。

混合コンテンツ警告

プライマリドメインがHTTPSを使用しているが、リバースプロキシがHTTPバックエンドにリクエストを転送する場合、ブラウザは混合コンテンツ警告を表示します。これは、HTTPSページがHTTPリソースを読み込むときに発生します。

  • 軽減策：* リバースプロキシがすべての接続にHTTPSを使用することを確認するか、バックエンドをHTTPSを使用するように設定します。X-Forwarded-Protoヘッダーは、元のリクエストプロトコルを通信するために正しく設定される必要があります。

無限リダイレクトループ

リダイレクトループは、バックエンドブログが独自のURL構造を強制しながら、プロキシがパスを書き換える場合に発生します。例えば、バックエンドが/post-titleを/blog/post-titleにリダイレクトし、プロキシが/blog/post-titleを/post-titleに書き換える場合、無限ループが発生します。

  • 軽減策：* プロキシ書き換えと競合するバックエンドリダイレクトを無効にします。本番環境への展開前に、ステージングでリダイレクト動作を徹底的にテストします。

アナリティクストラッキング破損

アナリティクス実装（Google Analytics、Matomo）は、再設定されない場合、サブディレクトリコンテンツを正しく追跡しないことがあります。クロスドメイン追跡が誤って適用されるか、追跡コードが新しいURL構造を認識しない可能性があります。

  • 軽減策：* アナリティクス設定を更新して、サブディレクトリを別のプロパティではなく、プライマリドメインの一部として認識させます。初期ロールアウト中にリアルタイムレポートを確認して、追跡が機能していることを確認します。

セッションおよび認証失敗

クッキーが正しくスコープされていない場合、ユーザーセッションはプライマリドメインとブログサブディレクトリ全体で持続しない可能性があります。ブログバックエンドが元のサブドメインからのクッキーを期待する場合、認証が失敗する可能性があります。

  • 軽減策：* クッキーをプライマリドメイン（例：Set-Cookie: session=abc123; Domain=.example.com）にスコープするように設定します。リバースプロキシはクッキードメイン属性を書き換える必要がある場合があります。

パフォーマンス低下

リバースプロキシが適切に設定されていない場合、レイテンシが追加されます。キャッシングを有効にして、サブディレクトリが元のサブドメインより遅くなることを避ける必要があります。設定ミスされたキャッシングは古いコンテンツを提供する可能性があります。

  • 軽減策：* 適切なキャッシュ無効化戦略を使用してプロキシレベルのキャッシングを有効にします。移行前後のレスポンス時間を監視します。WebPageTestなどのツールを使用してパフォーマンスへの影響を測定します。

マイグレーション実行チェックリスト

ブログ移行プロジェクトの実行タイムラインを示すガントチャート。準備フェーズ（環境構築、データバックアップ、移行スクリプト作成）、テストフェーズ（ステージング環境テスト、データ整合性検証、パフォーマンステスト）、本番移行フェーズ（本番環境準備、本番データ移行、サービス切り替え）、検証フェーズ（機能検証、ユーザ受け入れテスト、本番安定化）の4つのフェーズが時系列で表示され、各タスク間の依存関係と所要期間が視覚化されている。

  • 図11：ブログ移行プロジェクトの実行タイムライン*

マイグレーション前フェーズ

  • サイトクローラー（Screaming Frog、SEMrushなど）を使用して、サブドメインブログURLを指すすべての内部リンクを監査する
  • Google Search ConsoleおよびGoogle Analyticsで、すべてのインデックス済みURLをドキュメント化する
  • SSL証明書が旧URLと新URL構造の両方をカバーしているか確認する（または新しい証明書を取得する）
  • リバースプロキシ設定を備えたステージング環境をセットアップする
  • ステージング環境でアセット読み込み、フォーム送信、認証をテストする
  • RSSフィード機能を確認し、フィードURLを更新する
  • すべてのブログコンテンツのカノニカルタグを更新して、サブディレクトリURLを指すようにする
  • インデックス済みのすべてのページに対して、包括的な301リダイレクトルールを作成する

マイグレーションフェーズ

  • リバースプロキシ設定を本番環境にデプロイする
  • サブドメインからサブディレクトリへの301リダイレクトを有効化する
  • 分析トラッキングコードを更新して、新しいURL構造を認識させる
  • SSL証明書が正しくインストールされ、HTTPSが機能していることを確認する
  • エラーログを監視して、リダイレクトループ、404エラー、プロキシ障害を検出する
  • ユーザー向け機能をテストする：ナビゲーション、検索、コメント、フォーム
  • ソーシャル共有機能を確認する（Open Graphタグ、Twitter Cards）

マイグレーション後フェーズ

  • 更新されたXMLサイトマップをGoogle Search Consoleに送信する
  • サブディレクトリプロパティがSearch Consoleで作成され、確認されていることを検証する
  • 2～4週間、Search Consoleをクロールエラーとインデックス問題について監視する
  • Google Analyticsでトラフィック異常またはトラッキングギャップを確認する
  • 2～4週間、オーガニック検索トラフィックを監視して、問題を早期に特定する
  • RSSフィードが正しくリダイレクトされ、購読者が影響を受けていないことを確認する
  • プライマリドメイン全体の内部リンクを更新して、新しいURLを指すようにする（まだ実施していない場合）
  • ブログにリンクしている高権威の外部サイトに連絡して、URLの更新をリクエストする

検証基準

  • すべての301リダイレクトが正しいステータスコードを返す（curlまたはオンラインツールで確認）
  • Search ConsoleでリダイレクトされたURLに対する404エラーがない
  • マイグレーション後2～4週間以内に、オーガニックトラフィックが安定しているか増加している
  • 分析トラッキングが機能し、データが記録されている
  • RSSフィード購読者が影響を受けていない
  • すべてのアセット（CSS、JavaScript、画像）が正しく読み込まれている
  • ブラウザコンソールに混合コンテンツ警告がない
  • 認証とセッション管理が正しく機能している

主要な洞察と次のアクション

サブディレクトリホスティングは、SEO権威を単一ドメインに統合し、分析実装を簡素化し、サブドメインホスティングと比較して技術的な断片化を削減します。リバースプロキシは、バックエンドプラットフォームの制約に関係なく、このアーキテクチャを実現します。ただし、成功にはHTTPリダイレクト、カノニカルタグ、ヘッダー転送、マイグレーション後の監視に対する細心の注意が必要です。

  • 直ちに実施すべきアクション：*
  1. 現在のブログホスティング構造を監査し、リダイレクトが必要なすべてのURLをドキュメント化する
  2. ホスティングプラットフォームがリバースプロキシ設定をサポートしているか、またはネイティブなサブディレクトリサポートを提供しているか確認する
  3. ホスティング制約と技術的リソースに基づいて、リバースプロキシソリューション（Nginx、Apache、マネージドサービス）を選択する
  4. ステージング環境をセットアップし、本番環境へのデプロイ前にリバースプロキシ設定を徹底的にテストする
  5. 301リダイレクト実装とマイグレーション後の監視を含むマイグレーションタイムラインを計画する
  6. 本番環境へのデプロイ後2～4週間、オーガニックトラフィックとSearch Consoleメトリクスを監視して、成功を検証し、問題を早期に特定する

リバースプロキシ実装のシステムアーキテクチャを示す図。クライアント（ユーザブラウザ）からのHTTP/HTTPSリクエストがリバースプロキシサーバーに到達し、キャッシュレイヤー（Redis/Memcached）でキャッシュ確認を行う。キャッシュHITの場合は直接レスポンスを返却し、キャッシュMISSの場合はバックエンドブログサーバーにリクエストを転送。バックエンドサーバーはブログデータベースから記事・メタデータを読み取り、レスポンスをリバースプロキシに返す。リバースプロキシはレスポンスをキャッシュレイヤーに保存してからクライアントに返却する。全体的なデータフローと通信経路を明示している。

  • 図5：リバースプロキシベースのブログホスティングアーキテクチャ*

Footnotes

  1. Google Search Central. “Subdomains and Google Search.” https://developers.google.com/search/docs/beginner/get-started (Accessed 2024). 注：Googleのドキュメントでは、サブドメインの関連付けが試みられるが保証されないこと、および関係が同一ドメインコンテンツよりも弱いままであることが示されています。 ↩

  2. サブドメインからサブディレクトリへのマイグレーションを記録したSEOケーススタディ ↩