公開更新 CMS

WordPressとReactの連携方法：ヘッドレス化とテーマ組み込みの手順【WordPress 7.1・Next.js 16】

WordPressとReactの連携方法：ヘッドレス化とテーマ組み込みの手順【WordPress 7.1・Next.js 16】

WordPressとReactをつなぐ方法は2つあります。表示をReact側へ丸ごと移すヘッドレス化と、既存テーマの一部だけをReactで描くテーマ組み込みです。構築の手間も運用の形も違うため、先にどちらを作るかを決めないと手戻りになります。なお、ブロックエディター用の独自ブロックをReactで作る場合は、表示ではなく編集画面の拡張なので、別の手順（@wordpress/create-block）になります。この記事では選び方を示したうえで、REST APIでの取得、CORSの切り分け、テーマへの組み込み、Next.jsでのヘッドレス化を順に解説します。掲載したコードは、WordPress Playground CLI 3.1.57で起動したWordPress 7.1と、React 19.3.0、Next.js 16.4.0、@wordpress/scripts 36.1.0で実行して確認しました。

まとめ：WordPressとReactの連携で先に決めること

  • サイト全体をReactで作り替えるならヘッドレス化、部品だけならテーマ組み込み。検索フォームや料金シミュレーターを足すだけなら、ヘッドレス化は手間に見合いません。
  • データの取得はREST API。追加インストールなしで/wp-json/wp/v2/が使え、カスタム投稿タイプはshow_in_restを有効にしたときだけ出ます。
  • 公開データの取得ではCORSエラーは原則なし。本体がOriginをそのまま許可して返すので、エラーの原因は独自ヘッダー・リダイレクト・WAFなど本体の外にあります。
  • テーマ組み込みのReactはWordPress同梱の18.3.1。wp-elementに依存させれば自前で同梱せずに済みますが、React 19の機能は使えません。
  • ヘッドレス化の表示側はNext.jsが第一候補。静的生成で本文入りのHTMLを返し、title・canonical・サイトマップを表示側で出し直せば、SEOで不利になりません。App Routerを使うなら、React Server Componentsの脆弱性（CVE-2025-55182と、その後に追加公表された分）を塞いだ各系列の最新パッチへ上げておきます。
比較項目 ヘッドレス化 テーマ組み込み
Reactで描く範囲 サイト全体 ページの一部
WordPressのテーマ 表示に使わない そのまま使う
Reactの版 自由（19系も可） 同梱の18.3.1
データの受け渡し REST APIかWPGraphQL REST APIかPHPから直接
サーバー WordPressとフロントの2つ WordPressだけ
プレビュー 自前で実装する 標準のまま動く

ヘッドレス化とテーマ組み込みの選び方

判断の軸は2つです。1つはReactで描きたい範囲がサイト全体か一部か、もう1つは更新する人がWordPressの管理画面だけで作業を終えられる必要があるかです。

ヘッドレス化：表示をNext.jsなどに分離する

WordPressは管理画面とデータの保管だけを担い、表示は別に立てたReactアプリがREST APIかWPGraphQL経由で受け持ちます。画面の作りを自由に決められ、同じ記事をWebとアプリに配信できる代わりに、サーバーが2つになり、テーマや表示系プラグインは使えなくなります。ヘッドレスCMS一般の仕組みや他製品との比較はヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装【2026年10月】で扱っています。

テーマ組み込み：既存テーマの一部をReactで描く

PHPのテーマはそのまま使い、動きが必要な箇所だけにReactのコンポーネントを差し込みます。ブロックエディターがReactで作られているため、WordPressは最初からReactを同梱しており、既存サイトを壊さずに段階的に導入できます。

判断基準：ヘッドレス化を見送る条件

次のどれかに当てはまるなら、ヘッドレス化は見送ってテーマ組み込みから始めるべきです。

  • 更新担当が非エンジニアで、公開前のプレビューを管理画面だけで確認したい
  • Contact Form 7やスライダーなど、表示系プラグインの機能に依存している
  • 目的が表示速度の改善だけで、キャッシュや画像の最適化をまだ試していない
  • フロントエンドのサーバー（VercelやNetlifyなど）の保守を担当する人がいない

ヘッドレス化は、Webとアプリへの同時配信や、フロントを専任エンジニアが作り込む体制があるときに初めて元が取れます。表示速度が目的でも、遅さの原因が画像やサードパーティのタグ、サーバーの応答にあるならヘッドレス化しても改善せず、ブラウザだけで描画するSPAにすると初回の表示はむしろ遅くなります。迷ったら、まずテーマ組み込みでReactの比率を上げ、運用が回ることを確かめてから分離します。既存サイトの改修とヘッドレス化のどちらで進めるか決めきれない場合は、WordPressサイト制作・CMS構築の窓口で構成から相談できます。

ローカルにWordPress 7.1を立てる

手元で試すならWordPress 7.1.3（2026年10月6日公開）をWordPress Playground CLIで起動するのが速い方法です。Node.jsだけで動き、データベースやPHPを別に入れる必要がありません。

# WordPress 7.1 をローカルで起動（Node.jsだけで動く。DBやPHPの導入は不要）
npx @wp-playground/cli@latest server --port=9400 --wp=7.1

# 自作のプラグインを読み込ませるときは mu-plugins にマウントする
npx @wp-playground/cli@latest server --port=9400 --wp=7.1 \
  --mount=./mu-plugins:/wordpress/wp-content/mu-plugins

# 起動後の確認
curl -s http://127.0.0.1:9400/wp-json/wp/v2/posts

以降のcurlの例では、REST APIのベースURLをhttp://127.0.0.1:9400/wp-json/wp/v2とします。React・Next.jsのコードは本番を想定してcms.example.comと書いているので、手元で試すときは置き換えてください。

REST APIで記事を取得する

REST APIは投稿・固定ページ・メディア・カスタム投稿タイプをJSONで返す本体の機能です。仕様はREST API Handbookにまとまっています。

一覧の取得と_fields・ページ送り

投稿の一覧は/wp/v2/postsです。グローバルパラメーターの_fieldsで返す項目を絞ると、本文を丸ごと含む既定の応答より転送量が減ります。アイキャッチや著者も一緒に欲しいときは_embedを付けます。ページ送りはper_page（1〜100）とpageで行い、総件数と総ページ数は応答ヘッダーのX-WP-Total・X-WP-TotalPagesに入ります。

# 一覧：必要な項目だけ返す（_fields）。総ページ数はレスポンスヘッダーに入る
curl -s -D - "http://127.0.0.1:9400/wp-json/wp/v2/posts?per_page=10&_fields=id,title,link"

# 応答ヘッダーの抜粋（実測）
# x-wp-total: 1
# x-wp-totalpages: 1

# per_page は 1〜100。101 にすると 400 が返る
curl -s "http://127.0.0.1:9400/wp-json/wp/v2/posts?per_page=101"
# {"code":"rest_invalid_param","message":"Invalid parameter(s): per_page", ...}

パーマリンク設定が「基本」のサイトや、/wp-json/への書き換えが効かないサーバーでは、/?rest_route=/wp/v2/postsの形でも同じ応答が返ります（実測で200）。

カスタム投稿タイプをREST APIに出す

カスタム投稿タイプは、登録時にshow_in_restをtrueにしないとAPIに出ません。指定しなかった投稿タイプにアクセスすると、404のrest_no_routeが返ります。ブロックエディターもREST APIを使うため、show_in_restが無い投稿タイプは編集画面がクラシックエディターになります。

<?php
// functions.php または独自プラグイン：カスタム投稿タイプをREST APIに公開する
add_action( 'init', function () {
  register_post_type( 'product', array(
    'label'        => '製品',
    'public'       => true,
    'show_in_rest' => true,       // これが無いと /wp/v2/products は rest_no_route（404）
    'rest_base'    => 'products', // URLの末尾。省略時は投稿タイプ名
    'supports'     => array( 'title', 'editor', 'thumbnail' ),
  ) );
} );

書き込みはApplication Passwordsで認証する

読み取りは認証なしで動きますが、投稿の作成や更新には認証が必要です。認証なしでPOSTすると、401のrest_cannot_createが返りました。外部のアプリからは、ユーザー画面で発行するApplication PasswordsをBasic認証で送ります（Authentication）。ブラウザのコードにパスワードを埋め込むと誰でも読めるので、書き込みはサーバー側の処理に寄せます。

CORSエラーの原因を切り分ける

「WordPress React CORS」で見つかる記事の多くは、functions.phpでCORSヘッダーを付け直す方法を紹介しています。ただ、WordPress本体はもともとCORSヘッダーを返しています。7.1.3のソース（wp-includes/rest-api.phpのrest_send_cors_headers）は、リクエストにOriginがあればその値をAccess-Control-Allow-Originにそのまま入れ、Access-Control-Allow-Credentials: trueも付けます。PlaygroundでOrigin: http://localhost:5173を付けてGETすると、実際にそのOriginが返りました。

CORSエラーが出る3つの原因：独自ヘッダー・リダイレクト・WAF

公開記事のGETでCORSエラーが出るなら、本体以外のところで止まっています。確認する順番は次のとおりです。

  • 独自のリクエストヘッダー：許可されるヘッダーの既定値はAuthorization・X-WP-Nonce・Content-Disposition・Content-MD5・Content-Typeの5つだけです。X-Customのような独自ヘッダーを送ると、プリフライト（OPTIONS）の応答に含まれず、ブラウザが本リクエストを送りません。
  • リダイレクト：httpからhttps、wwwの有無、末尾のスラッシュなどでAPIのURLがリダイレクトされると、リダイレクト応答にCORSヘッダーが付かないためブラウザがそこで止め、プリフライトがある場合はリダイレクトそのものが許されません。APIのURLは最終的なURLで書きます。
  • セキュリティプラグインとWAF：REST APIを未ログインのユーザーに閉じる設定や、海外IP・ボット判定のブロックは、エラー応答にCORSヘッダーが付かないため、ブラウザには「CORSエラー」としか表示されません。開発者ツールのネットワークタブで、応答のステータスコードを先に見ます。

独自ヘッダーを使う場合は、rest_allowed_cors_headersフィルターで許可リストに足します。追加後は、プリフライト応答のAccess-Control-Allow-HeadersにX-Customが含まれました。

<?php
// 独自のリクエストヘッダーを送るなら、許可リストに足す
add_filter( 'rest_allowed_cors_headers', function ( $headers ) {
  $headers[] = 'X-Custom';
  return $headers;
} );

許可するOriginを絞る

本体の既定はどのOriginでも許可するため、自社のフロントだけに絞りたいときは本体の処理を外して置き換えます。下のコードでは、リストにないOriginにはAccess-Control-Allow-Originが返らなくなりました。

<?php
// 許可するOriginを絞る（既定はリクエストのOriginをそのまま返す）
add_action( 'rest_api_init', function () {
  remove_filter( 'rest_pre_serve_request', 'rest_send_cors_headers' );
  add_filter( 'rest_pre_serve_request', function ( $value ) {
    $allowed = array( 'https://www.example.com', 'http://localhost:5173' );
    $origin  = get_http_origin();
    if ( $origin && in_array( $origin, $allowed, true ) ) {
      header( 'Access-Control-Allow-Origin: ' . $origin );
      header( 'Access-Control-Allow-Methods: GET, OPTIONS' );
      header( 'Vary: Origin', false );
    }
    return $value;
  } );
}, 15 );

ただし、CORSはブラウザが他サイトのJavaScriptに応答を読ませないための仕組みで、アクセス制限ではありません。curlやサーバーからは、Originを絞っても記事を取得できます（実測で200）。公開したくないデータは権限チェックで守ります。

Reactで記事一覧を表示する

単体のReactアプリはnpm create vite@latest my-app -- --template reactで作れます。create-vite 9.2.1のテンプレートはReactを^19.2.8、Viteを^8.3.0で指定しており（2026年10月時点ではReact 19.3.0とVite 8.3.4が入ります）、開発サーバーはhttp://localhost:5173で起動します。下のコンポーネントは、通信の中断と取得失敗の表示、X-WP-TotalPagesの読み取りまで入れた形です。React 19.3.0で、Playgroundの記事を取得して一覧が描画されることを確認しました。

import { useEffect, useState } from "react";

const API = "https://cms.example.com/wp-json/wp/v2";

export default function Posts() {
  const [posts, setPosts] = useState([]);
  const [totalPages, setTotalPages] = useState(0);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();
    const params = new URLSearchParams({
      per_page: "10",
      _fields: "id,link,title",
    });
    fetch(`${API}/posts?${params}`, { signal: controller.signal })
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        setTotalPages(Number(res.headers.get("X-WP-TotalPages")));
        return res.json();
      })
      .then(setPosts)
      .catch((e) => {
        if (e.name !== "AbortError") setError(e.message);
      });
    return () => controller.abort();
  }, []);

  if (error) return <p>取得に失敗しました：{error}</p>;
  return (
    <>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>
            <a href={post.link}>{post.title.rendered}</a>
          </li>
        ))}
      </ul>
      <p>全{totalPages}ページ</p>
    </>
  );
}

title.renderedはHTMLエンティティを含むことがあります。タイトルに「&」などが入るサイトでは、表示前にデコードするか、サニタイズしたうえでHTMLとして挿入します。

この構成はブラウザだけで描画するSPAで、初期HTMLに記事が入りません。検索流入を狙う公開サイトは、後述のNext.jsのようにサーバー側でHTMLを作ります。React全般のインデックス対策はReact SEO対策とは？SSR・SSG・プリレンダリングの選び方と実装手順にまとめています。

既存テーマにReactを組み込む

テーマ組み込みでは、Reactを自分で同梱するより、WordPressが持っているReactを使うほうが軽くなります。WordPress 7.1.3が登録するReactの版は18.3.1です（wordpress-developの7.1.3タグのpackage.json）。

ビルドなしでwp.elementを使う

スクリプトの依存にwp-elementを指定すると、WordPressはreact.min.jsとreact-dom.min.jsを先に読み込み、グローバルのwp.elementからReactの関数を使えるようにします。

<?php
// functions.php：WordPress同梱のReact（wp-element）に依存させて読み込む
add_action( 'wp_enqueue_scripts', function () {
  wp_enqueue_script(
    'my-react-app',
    get_theme_file_uri( 'js/app.js' ),
    array( 'wp-element' ), // react.min.js・react-dom.min.js が先に読み込まれる
    '1.0.0',
    array( 'in_footer' => true )
  );
} );
// テンプレート側にマウント先を置く：<div id="my-react-app"></div>
( function () {
  const { createElement: h, createRoot, useState } = wp.element;

  function Counter() {
    const [ count, setCount ] = useState( 0 );
    return h( 'button', { onClick: () => setCount( count + 1 ) }, 'クリック数: ' + count );
  }

  const el = document.getElementById( 'my-react-app' );
  if ( el ) {
    createRoot( el ).render( h( Counter ) );
  }
} )();

Playgroundで、フロントページにreact.min.js?ver=18.3.1.1が出力され、ボタンのクリックで表示が更新されることを確認しました。JSXが使えない点を除けば、このままで動きます。

@wordpress/scriptsでJSXをビルドする

JSXで書きたい場合は、公式のビルドツール@wordpress/scriptsを使います。@wordpress/elementから読み込んだReactはバンドルに含まれず、実行時に同梱のReactを参照します。下のコードをsrc/index.jsに置き、npx wp-scripts buildを実行すると、build/index.jsと、依存関係を書いたbuild/index.asset.phpが出力されます。下のコンポーネントをビルドしたbuild/index.jsは292バイトで、依存にはreact-jsx-runtimeとwp-elementが入りました。

import { createRoot, useState } from '@wordpress/element';

function Counter() {
  const [ count, setCount ] = useState( 0 );
  return (
    <button onClick={ () => setCount( count + 1 ) }>
      クリック数: { count }
    </button>
  );
}

const el = document.getElementById( 'my-react-app' );
if ( el ) {
  createRoot( el ).render( <Counter /> );
}
<?php return array(
  'dependencies' => array(
    'react-jsx-runtime',
    'wp-element'
  ),
  'version' => '213730b56779e1432497'
);
<?php
// functions.php：wp-scripts の出力した依存関係ファイルをそのまま渡す
add_action( 'wp_enqueue_scripts', function () {
  $asset = include get_theme_file_path( 'build/index.asset.php' );
  wp_enqueue_script(
    'my-react-app',
    get_theme_file_uri( 'build/index.js' ),
    $asset['dependencies'],
    $asset['version'],
    array( 'in_footer' => true )
  );
} );

このビルド結果をPlaygroundのフロントページで読み込み、同梱のreact-jsx-runtime.min.js?ver=18.3.1と組み合わせてボタンが動くことを確認しました。この方式ではReactの版をWordPressが決めます。React 19で加わったuseやActionsは使えないので、React 19の機能が必要ならヘッドレス化を選びます。

Interactivity APIで足りる場面

ボタンの開閉や絞り込みなど、ブロック単位の小さな動きであれば、WordPress 6.5で本体に入ったInteractivity APIでも作れます。HTML属性（data-wp-*）で状態と表示を結び付ける方式で、サーバーで描画したHTMLをそのまま動かすため既存のブロックと混ぜやすくなります。画面全体の状態管理が要るアプリ的なUIはReactのほうが向いています。

Next.jsでヘッドレス化する

ヘッドレス化の表示側には、レンダリング方式をページごとに選べるNext.jsを使うのが一般的です。2026年10月時点の最新安定版は16.4.0です。Next.jsそのものの導入はNext.jsとは？16系App Routerで最小アプリを動かす手順と採用判断で解説しています。

App Routerで記事ページを静的生成する

下の3ファイル（lib/wp.js・app/page.jsx・app/posts/[slug]/page.jsx）で、記事の一覧ページと記事ページを静的に生成し、5分ごとに再生成する構成になります。WP_API_URLにWordPressのREST APIのURLを入れてnext buildを実行すると、記事ページはgenerateStaticParamsでビルド時にHTML化され、ビルド結果の一覧には「Revalidate 5m」と表示されました。生成されたHTMLには記事の見出しと本文が入っていました。

// lib/wp.js：WordPress REST APIの取得処理
const WP_API = process.env.WP_API_URL; // 例: https://cms.example.com/wp-json/wp/v2

export async function getPosts() {
  const res = await fetch(`${WP_API}/posts?per_page=20&_fields=id,slug,title`, {
    next: { revalidate: 300 },
  });
  if (!res.ok) throw new Error(`WordPress API: ${res.status}`);
  return res.json();
}

export async function getPostBySlug(slug) {
  const res = await fetch(`${WP_API}/posts?slug=${encodeURIComponent(slug)}`, {
    next: { revalidate: 300 },
  });
  if (!res.ok) throw new Error(`WordPress API: ${res.status}`);
  const [post] = await res.json();
  return post ?? null;
}
// app/page.jsx
import Link from "next/link";
import { getPosts } from "../lib/wp";

export default async function Home() {
  const posts = await getPosts();
  return (
    <ul>
      {posts.map((p) => (
        <li key={p.id}>
          <Link href={`/posts/${p.slug}`}>
            <span dangerouslySetInnerHTML={{ __html: p.title.rendered }} />
          </Link>
        </li>
      ))}
    </ul>
  );
}
// app/posts/[slug]/page.jsx
import { notFound } from "next/navigation";
import { getPosts, getPostBySlug } from "../../../lib/wp";

export async function generateStaticParams() {
  const posts = await getPosts();
  return posts.map((p) => ({ slug: p.slug }));
}

export default async function PostPage({ params }) {
  const { slug } = await params;
  const post = await getPostBySlug(slug);
  if (!post) notFound();
  return (
    <article>
      <h1 dangerouslySetInnerHTML={{ __html: post.title.rendered }} />
      <div dangerouslySetInnerHTML={{ __html: post.content.rendered }} />
    </article>
  );
}

content.renderedはWordPressが整形したHTMLです。投稿者を信頼できない運用（寄稿を受け付けるなど）では、挿入前にサニタイズします。SSG・ISR・SSRの使い分けはNext.jsのレンダリング方式｜SSG・ISR・SSR・CSRの違いとApp Routerでの選び方で詳しく比べています。

プレビューはDraft Modeで作る

ヘッドレス化すると、WordPressの「プレビュー」ボタンは表示側に届きません。Next.jsではDraft Modeを使い、プレビュー用のルートでトークンを確かめてからdraftMode()を有効にし、下書きを認証付きで取得して表示します。draftModeはApp Routerでは非同期関数なので、await draftMode()で呼びます。この実装を省くと、更新担当は公開してからでないと見た目を確認できません。

React Server Componentsの脆弱性への対応

2025年12月3日、React Server Componentsに認証なしで遠隔からコードを実行される脆弱性（CVE-2025-55182、CVSS 10.0）がReact公式から公表されました。影響を受けるのはreact-server-dom-webpackなどの19.0、19.1.0、19.1.1、19.2.0で、当初の修正版は19.0.1、19.1.2、19.2.1でした。その後、同じパッケージにサービス拒否（CVE-2025-55184・CVE-2025-67779・CVE-2026-23864）とソースコード露出（CVE-2025-55183）の脆弱性が追加で公表され、19.0.3・19.1.4・19.2.3までの修正も不完全とされたため、現在は19.0.4・19.1.5・19.2.4以降が必要です。Next.jsの告知によると、App Routerを使う15.x・16.xが影響を受け、13.x、14.xの安定版、Pages Router、Edge RuntimeはこのRCEの対象外です。ただし、追加された脆弱性については、React公式の更新手順が13.3.x〜14.xにも14.2.35への更新を求めています。

WordPress本体が同梱するのはブラウザで動くReact 18.3.1で、React Server Componentsのサーバー実装は入っていません。React公式も「サーバーを使わないReactのコードは影響を受けない」としており、本体とテーマ組み込みは対象外です。影響を受けるのはNext.jsで作ったヘッドレス化のフロントなので、nextを各系列の最新パッチへ上げてください。

Faust.js・Frontityを選ぶ前に確認すること

WP EngineのFaust.jsは、Next.jsでヘッドレスWordPressを作るためのツール群で、プレビューや認証を肩代わりします。@faustwp/coreは2026年10月9日に3.5.1が出ており、開発は続いています。ただし前提はWPGraphQLとNext.jsで、REST APIだけで組む構成には向きません。

一方、かつて「WordPressのためのReactフレームワーク」と呼ばれたFrontityは、READMEで「not under active development anymore」と明記され、GitHubのリポジトリはアーカイブされています。開発チームは2021年8月にAutomatticへ合流し、現在はWordPress本体のInteractivity APIを開発しています。新しい案件で採用する理由はありません。

REST APIとWPGraphQLの選び方

記事一覧と記事ページが中心のサイトなら、REST APIで足ります。1画面で投稿・カテゴリ・メニュー・カスタムフィールドをまとめて取りたいなど、取得の組み合わせが複雑になったらWPGraphQLを検討します。必要な項目だけを1回のリクエストで問い合わせられます。

# エンドポイントは /graphql（パーマリンク設定が「基本」のときは /?graphql）
query {
  posts(first: 10) {
    nodes {
      databaseId
      title
      slug
      date
      featuredImage { node { sourceUrl altText } }
    }
  }
}

WPGraphQLの最新版は2.23.1（2026年9月22日）です。WordPress.orgは2024年10月にWPGraphQLを公式に推奨する「canonical plugin」にすると発表しましたが、2026年10月12日時点のプラグインページは「Community plugin」の表示のままです。本体の機能ではなく、追加のプラグインとして保守する前提で選びます。上のクエリはWPGraphQL 2.23.1を入れたPlaygroundで記事のIDとタイトルを返しました。

ヘッドレス化したWordPressのSEO：メタ情報・サイトマップ・canonical

ヘッドレス化そのものはSEOに有利でも不利でもありません。結果を分けるのは、初期HTMLに本文が入っているかと、従来はプラグインが出していたタグを表示側で出し直したかです。

従来のテーマでは、Yoast SEOやAll in One SEOがtitle・meta description・OGP・構造化データ・サイトマップを出力しますが、ヘッドレス化するとこれらは表示側に自動では出力されません（Yoast SEOはREST APIの応答にyoast_head_jsonを付けるので、表示側で読み出して出力できます）。Next.jsではgenerateMetadataでtitleやdescriptionを、app/sitemap.jsでサイトマップを生成します。WordPressが出すサイトマップをそのまま使うと、URLがWordPress側のドメインのままになり、表示側のURLと食い違います。canonicalも表示側のURLで出すこと、WordPress側のURL（cms.example.comなど）はnoindexにするか、ログインが必要な場所に置くことを、移行の作業項目に入れてください。

よくある質問

WordPressでSSRはできますか？

WordPressのテーマはもともとサーバー側でHTMLを作って返すので、従来の構成もサーバー描画です。Reactの表示をサーバー側で描画したい場合は、ヘッドレス化してNext.jsのSSRやSSGを使います。

WordPressをSPAにできますか？

できます。REST APIで記事を取得してReactで描けばSPAになりますが、初期HTMLに本文が入らないため、検索から集客するサイトでは静的生成かサーバー描画を組み合わせます。

ヘッドレス化するとプラグインは使えなくなりますか？

管理画面で動くプラグイン（カスタムフィールドの入力、権限管理など）は使えます。テーマの表示に何かを出力するプラグイン（フォーム、スライダー、SEOタグの出力など）は表示側に反映されないため、同じ機能をフロントで作り直すか、APIでデータを渡す拡張を使います。

テーマに組み込むReactのバージョンは選べますか？

wp-elementに依存させる方式では、WordPressが同梱する版（7.1.3では18.3.1）に固定されます。Reactを自前でバンドルすれば別の版も使えますが、同梱のReactに依存するブロックやプラグインと同じページに載ると、2つのReactが読み込まれて容量が増えます。

Frontityは今も使えますか？

READMEで開発終了が明記され、リポジトリもアーカイブされているため、新しい案件での採用は勧めません。Next.jsとREST API（またはWPGraphQL）で組むのが現在の標準的な構成です。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.15　テックブログ リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  2. 2026.10.16　テックブログ ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検
  3. 2026.10.16　テックブログ バーガーキング不正アクセスで約1,118万件の情報漏洩｜対象確認・案内メールの真偽と運営側のログ点検
  4. 2026.10.15　テックブログ 銀のさら不正アクセス：最大650万件の対象確認と窓口、パスワード変更の手順
  5. 2026.10.16　テックブログ ワラウ不正アクセスで連携トークン流出｜Yahoo! JAPAN ID再連携と対象確認

RELATED POSTS 関連記事

一覧へ戻る

目次