WordPressの/blogだけVercelで配信する方法｜Cloudflare Worker設定手順【AI活用検証vol.115】

「既存のWordPressサイトはそのまま残したい。でも、新しく作るブログやオウンドメディアだけはNext.jsで作ってVercelに置きたい」——このリクエストは実務で非常によく発生します。しかもサブドメイン（blog.example.com）ではなく、サブパス（example.com/blog）で配信したいというケースがほとんどです。

この記事では、Cloudflare Workerを使ってWordPress側もVercel側も設定を一切変更せずに、URLのパス単位でリクエストを振り分ける方法を、実際に構築した手順そのままで解説します。ネームサーバーの移管からWorkerのルーティングコード、つまずきやすいDNSトラブルやCSS崩れの対処までを一通りカバーします。

この検証の概要

結論：Cloudflare Worker 1つでサブパス振り分けは完結する

先に結論を書きます。example.com/blog だけをVercelに、それ以外をWordPressに振り分ける構成は、Cloudflare Workerを1つ作るだけで実現できます。踏み台としてのCloudflare Pagesも、WordPress側のリバースプロキシ設定も、Vercel側のドメイン設定変更も必要ありません。

ポイントは次の2点です。

• DNSはIPアドレスまでしか届けられない。「/blogだけ別サーバー」というパス単位の振り分けはDNSの守備範囲外で、これはCloudflare Workerの仕事になります
• Workerにはカスタムドメインを直接紐づけられる。Settings → Domains & Routes から example.com をWorkerに割り当てれば、全リクエストがWorkerを経由します

この構成は、WordPressで運用中の企業サイトに、Next.jsで作った高速なオウンドメディアを後から合流させたい場合の定番パターンです。

なぜサブドメインではなくサブパスで配信するのか

サブパス（example.com/blog）での配信が選ばれる最大の理由は、ドメインの評価を1つに集約できるからです。

検索エンジンは blog.example.com と example.com を、原則として別サイトとして扱います。せっかく本体サイトが積み上げた被リンクやドメインの評価は、サブドメインのメディアにはそのまま引き継がれません。一方サブパスであれば同一サイト内のコンテンツとして扱われるため、本体サイトの評価を土台にした状態でメディアを立ち上げられます。

サブパス構成は「やりたいけれど、技術的にどう実現するかで詰まる」典型例です。その解決策が、これから解説するCloudflare Workerによるプロキシです。

全体の構成イメージ

完成後の構成は次の図の通りです。ユーザーからのリクエストは必ずCloudflare Workerを通り、Workerがパスを見てWordPressとVercelのどちらに転送するかを決めます。

ユーザー
  ↓（DNS解決 → CloudflareのIPが返る）
Cloudflare Worker（example.com に直接紐づけ）
  ├── /blog, /blog/*, /_next/* → Vercel（静的サイト）
  └── それ以外                → WordPressサーバー（さくら / Xサーバー等）

設定は次の4ステップに整理できます。

1. レジストラのネームサーバーをCloudflareに変更する
2. Cloudflare DNSでA / MX / TXTレコードを確認・整備する
3. Workerを作成し、Custom Domainで example.com を直接紐づける
4. Workerにルーティングコードを書いてデプロイする

Step1｜Cloudflareにドメインを追加する

アカウントを作成する

Cloudflare公式サイトから「Sign Up」でメールアドレスとパスワードを登録します。プランはFreeで問題ありません。今回の構成に必要な機能はすべて無料枠で使えます。

ドメインを追加する

1. ダッシュボードから「Add a Site」を選択
2. ドメイン名（例：example.com）を入力
3. プランはFreeのまま続行
4. CloudflareがDNSレコードを自動スキャンして取り込む

この自動スキャンで既存のレコードが引き継がれますが、完全ではありません。次のStepで必ず中身を確認します。

Step2｜ネームサーバーをCloudflareに変更する

ドメイン追加後の画面に、Cloudflareが指定する2つのネームサーバーが表示されます。

xxx.ns.cloudflare.com
yyy.ns.cloudflare.com

この値を、ドメインを取得したサービス側の管理画面で設定します。

反映には最大48時間かかります。Cloudflareのダッシュボードに「有効化されました」と表示されれば完了です。作業は余裕を持ったスケジュールで進めてください。

Step3｜DNSレコードを確認・整備する

この記事で最も事故が起きやすいのがこのStepです。ネームサーバーの移管が完了したら、Cloudflareのdns管理画面でレコードを1つずつ確認します。

特に注意すべき2つのレコード

• MXレコード：自動スキャンで取り込まれているか必ず確認してください。ここが消えているとメールが一切届かなくなります。またMXレコードはプロキシをオフにする必要があります
• TXTレコード：Google Search Consoleの所有権確認やSPF・DKIMの設定が引き継がれているか確認します。消えるとメールの到達率低下やSearch Consoleの計測断につながります

移管前に、現在のDNSレコード一覧のスクリーンショットを必ず撮っておいてください。何かが消えたときに、元の値がわからないと復旧できません。

WordPressサーバーのIPアドレスの調べ方

さくらインターネットやXサーバーなどのサーバー管理画面で、「サーバー情報」または「IPアドレス」の項目に記載されています。

Step4｜Workerを作成しカスタムドメインを紐づける

Cloudflare Workerとは、Cloudflareのエッジ（世界中の拠点）でリクエストを受け取り、任意のJavaScriptを実行できる仕組みです。今回はこれを「リクエストの交通整理役」として使います。

Workerを新規作成する

1. Cloudflareダッシュボード → Workers & Pages
2. 「Create」→「Create Worker」
3. 名前をつける（例：blog-proxy）
4. デフォルトのコードのまま、いったん「Deploy」

カスタムドメインを直接紐づける

1. 作成したWorkerを開き、「Settings」タブへ
2. 「Domains & Routes」セクションの「+ Add」をクリック
3. モーダルで 「Custom Domain」 を選択
4. example.com を入力して追加

RouteとCustom Domainの2択が表示されますが、今回はCustom Domainを選んでください。違いは次の通りです。

追加後、CloudflareのDNS管理画面にWorker向けのレコードが自動で追加されているか確認しておきます。

Step5｜振り分けロジックを実装する

Workerの「Edit Code」を開き、以下のコードを貼り付けます。

const BLOG_ORIGIN = 'https://your-app.vercel.app'; // ← VercelのURLに変更

function isVercelPath(path) {
  return path === '/blog'
    || path.startsWith('/blog/')
    || path.startsWith('/_next/')   // Next.jsのCSS・JS
    || path.startsWith('/favicon'); // ファビコン
}

export default {
  async fetch(request) {
    const url  = new URL(request.url);
    const path = url.pathname;

    if (isVercelPath(path)) {
      // /blog プレフィックスを除いてVercelに渡す
      const stripped = path.startsWith('/blog')
        ? (path.replace(/^\/blog/, '') || '/')
        : path;

      const target = new Request(
        BLOG_ORIGIN + stripped + url.search,
        request
      );
      target.headers.set('Host', 'your-app.vercel.app');      // ← Vercelのホスト名
      target.headers.set('X-Forwarded-Host', 'example.com');  // ← 自分のドメイン
      return fetch(target);
    }

    // /blog 以外はWordPressへ通常どおり転送
    return fetch(request);
  }
};

自分の環境に合わせて変更するのは、次の3か所だけです。

1. BLOG_ORIGIN にVercelのデプロイURL
2. Host ヘッダーにVercelのホスト名
3. X-Forwarded-Host に自分のドメイン

/_next/ の条件が入っている点が重要です。Next.jsはCSSやJavaScriptを /_next/static/... という/blogを含まないパスから読み込むため、この条件がないとアセットがWordPress側に流れて404になります。

書き換えたら「Deploy」して完了です。

Step6｜動作確認とCSS崩れのチェック

デプロイ後、次の3つのURLを開いて期待どおりに表示されるか確認します。

ページは表示されるのにデザインが崩れている場合、原因はほぼNext.jsの静的アセットが404になっていることです。ブラウザの開発者ツールのNetworkタブで /_next/static/... のリクエストを確認し、404になっていれば isVercelPath に /_next/ の条件が入っているかを見直して再デプロイしてください。

つまずきやすい5つのポイントと対処法

DNSレコード用語チートシート

DNS移管の作業中に迷わないよう、登場するレコードの役割を整理しておきます。

よくある質問

WordPress側の設定変更は必要ですか？

不要です。WordPressはこれまでどおり動き続けます。Cloudflare Workerがリクエストを受け取ってWordPressサーバーへ転送するだけなので、WordPress側からは通常のアクセスと同じに見えます。

Vercel側でドメインを追加する必要はありますか？

必須ではありません。WorkerからVercelの *.vercel.app のURLへ転送する構成のため、Vercel側のドメイン設定は変更せずに動作します。

Cloudflareの無料プランで足りますか？

足ります。Workersの無料枠は1日10万リクエストまで利用でき、通常のコーポレートサイトやオウンドメディアであれば十分な範囲です。

Cloudflare Pagesを踏み台にする必要はありますか？

不要です。以前はWorkerにカスタムドメインを割り当てるためにPagesを経由する手法が紹介されることもありましたが、現在はWorkerのSettings → Domains & RoutesからCustom Domainを直接紐づけられます。

ダウンタイムは発生しますか？

ネームサーバーの切り替えは段階的に反映されるため、Aレコードなど既存のレコードが正しく移行できていれば、原則としてサイトが落ちることはありません。ただしレコードの設定漏れがあるとその機能だけが停止します（MXレコードならメール）。移管前のスクリーンショットが最大の保険になります。

まとめ

Cloudflare Workerを使えば、WordPressとVercelを1つのドメイン上でパス単位に共存させる構成が、無料枠かつ既存環境の変更なしで実現できます。要点を振り返ります。

• パス単位の振り分けはDNSではできない。Cloudflare Workerの役割
• WorkerにはCustom Domainを直接紐づけられる（Pagesの踏み台は不要）
• 最大のリスクはDNS移管時のMX・TXTレコードの消失。移管前のスクリーンショットが必須
• CSS崩れの原因はほぼ /_next/ パスの振り分け漏れ

サブパス構成は、既存サイトのドメイン評価を活かしたままモダンな技術スタックへ移行していくための、現実的な選択肢です。「WordPressは残したいが、新しいメディアは高速に作りたい」という状況であれば、まずこの構成を検討してみてください。

株式会社AI棒では、こうしたAI・Web技術の検証を日々行い、企業のAI活用と開発の内製化を支援しています。技術選定や構築についてのご相談はお問い合わせフォームから、AI活用の伴走支援についてはAI参謀をご覧ください。