1. 全体像（アーキテクチャ）

この構成では、メインのドメイン（example.com）はCloudflareにありますが、特定のパス（/blog）へのアクセスだけをWorkerが検知し、裏側にあるXSERVER（wp.example.com）からコンテンツを引っ張ってきて表示させています。

• メインLP（/）: Cloudflare（PagesやWorkersなど）
• ブログ（/blog）: XSERVER上のWordPress

---

2. 各ステップの詳細解説

① XSERVER側の準備（箱作り）

まず、WordPressを動かすための「専用の入り口」をXSERVER側に作ります。

• サブドメインの設定: wp.example.com のようなサブドメインをXSERVER上で作成します。
• WordPressのインストール: そのサブドメインに対してWordPressをインストールします。
• ディレクトリ構造: /blog というディレクトリを作成し、そこにWordPressを配置します（またはXSERVERの転送設定などで /blog で反応するようにします）。

② WordPress内のURL設定

WordPress自身に「君のURLは /blog なんだよ」と教え込む必要があります。

• 設定変更: WordPress管理画面の「設定 > 一般」
  • WordPress アドレス (URL): https://example.com/blog
  • サイトアドレス (URL): https://example.com/blog
• ポイント: ここを wp.example.com にせず、最終的な表向きのURL（example.com/blog）にするのがコツです。

③ Cloudflare DNSの設定

CloudflareからXSERVERを見に行けるように道を作ります。

• レコード追加: wp という名前で、XSERVERのIPアドレスを指すAレコードを作成します。
• プロキシ状態: オレンジ（Proxied） に設定。
  • これにより、Cloudflareのネットワークを通ってXSERVERに通信が行くようになります。

④ Cloudflare Workersの設定

ここが一番肝心な「リバースプロキシ」のコード部分です。

Workerの役割:
「もしアクセスが example.com/blog/* だったら、ブラウザのURLはそのままで、中身だけ wp.example.com/blog/* から取ってきて表示せよ」という命令を出しています。

コードのイメージ:

addEventListener('fetch', event => {
  const url = new URL(event.request.url);

  // パスが /blog で始まる場合
  if (url.pathname.startsWith('/blog')) {
    // リクエスト先を XSERVER側のサブドメインに書き換える
    const targetUrl = 'https://wp.example.com' + url.pathname + url.search;

    const newRequest = new Request(targetUrl, event.request);
    event.respondWith(fetch(newRequest));
  } else {
    // それ以外は通常のLP（Cloudflare Pagesなど）を表示
    event.respondWith(fetch(event.request));
  }
});

⑤ 仕上げ：Routeの設定

Workerを作っただけでは動きません。
Cloudflareの管理画面「Workers & Pages > Roles」にて、
example.com/blog* というリクエストが来た時に、作成したWorkerが起動するように紐付け（ルート設定）を行います。

---

3. この構成のメリット

1. SEOに強い: /blog というサブディレクトリ形式になるため、ブログのドメインパワーがメインドメインに蓄積されます。
2. 高速・安全: CloudflareのCDNキャッシュやWAFの保護を受けながら、慣れ親しんだWordPressをバックエンドで使えます。
3. サーバーの切り分け: LPはエンジニアリングしやすいCloudflareで、ブログは記事更新しやすいWordPressで、と「いいとこ取り」ができます。