WordPressをHeadless CMS化してNext.jsで運用する具体手順｜記事資産を活かす移行ガイド

WordPressをHeadless CMSとして使うとは、WordPressを「記事を管理するための管理画面」として残し、実際のサイト表示はNext.jsで行う構成のことです。

通常のWordPressサイトでは、記事の管理も、ページの表示も、テーマによるデザインも、すべてWordPress側で行います。

一方、Headless構成では、WordPressは記事データを管理するだけの役割になります。

サイトの見た目、トップページ、サービスページ、問い合わせページ、記事一覧ページ、記事詳細ページなどは、Next.js側で作ります。

つまり、役割分担は以下のようになります。

WordPress側で管理するもの

• 投稿記事
• 固定ページの一部
• カテゴリ
• タグ
• アイキャッチ画像
• 著者情報
• SEO用の説明文
• 記事の公開・下書き・更新

Next.js側で管理するもの

• サイトデザイン
• トップページ
• サービスページ
• 会社紹介ページ
• LP
• 記事一覧ページ
• 記事詳細ページ
• グローバルナビ
• フッター
• CTA
• 表示速度の最適化
• SEO構造
• ルーティング

この構成にすると、WordPressの使いやすい管理画面を残しながら、Next.jsの高速表示・自由なデザイン・モダンな開発環境を活用できます。

WordPress公式のREST APIでは、投稿、固定ページ、タクソノミーなどのWordPressデータをエンドポイント経由で取得できます。そのため、Next.js側からWordPressの記事データをJSONとして取得し、フロントエンドで表示することができます。

Headless WordPress構成では、サイト全体を以下のように分けて考えます。

WordPress

• 管理画面
• 記事作成
• 記事編集
• 画像アップロード
• カテゴリ管理
• タグ管理
• REST APIまたはGraphQL APIで記事データを提供

Next.js

• フロントエンド表示
• 記事一覧
• 記事詳細
• 静的ページ
• LP
• SEO設定
• OGP設定
• サイトマップ生成
• キャッシュ制御
• デザイン実装

ユーザーが見るサイトはNext.jsです。

WordPressのテーマは、実質的には使いません。WordPressは裏側のCMSとして残します。

例えば、ユーザーが以下のURLにアクセスしたとします。

https://example.com/blog/wordpress-headless-nextjs/

このページ自体はNext.jsで表示されます。

Next.jsはWordPress REST APIから該当記事のデータを取得し、タイトル、本文、アイキャッチ画像、カテゴリ、公開日などを画面に表示します。

WordPressをHeadless化してNext.jsで運用する構成は、以下のようなサイトに向いています。

• 記事更新はWordPress管理画面で続けたい
• 既存のWordPress記事を活かしたい
• デザインを大きくリニューアルしたい
• 表示速度を改善したい
• サービスページやLPを自由に作りたい
• WordPressテーマの制約から離れたい
• 記事以外のページをNext.jsで柔軟に作りたい
• SEOを強化したい
• 将来的に複数サイト・複数言語展開をしたい

特に、既存のWordPressサイトに記事資産がある場合、この方法は現実的です。

記事管理を完全にNext.js側へ移すと、Markdown管理やCMS導入が必要になります。しかし、WordPressをHeadless CMSとして残せば、これまで通りWordPress管理画面から記事を投稿できます。

そのため、編集者やライターがWordPressに慣れている場合でも、運用を大きく変えずにNext.js化できます。

この構成で一番大事なのは、役割を明確に分けることです。

おすすめの基本方針は、以下です。

記事データ

WordPressで管理します。

デザインと表示

Next.jsで管理します。

トップページやLP

Next.jsで直接作ります。

ブログ記事ページ

WordPress APIから取得してNext.jsで表示します。

問い合わせフォーム

Next.js側で作り、必要に応じて外部フォームやAPIに送信します。

画像

最初はWordPressのメディアURLを使ってもよいですが、長期的にはNext.js側または外部ストレージに整理する方が安全です。

このように分けることで、WordPressとNext.jsの責任範囲が明確になります。

WordPressをHeadless CMSとして使う場合、Next.jsから記事データを取得する方法は主に2つあります。

1つ目は、WordPress REST APIを使う方法です。

WordPressには標準でREST APIが用意されています。追加プラグインなしでも、投稿や固定ページのデータを取得できます。

例えば、投稿一覧は以下のようなURLで取得できます。

https://example.com/wp-json/wp/v2/posts

固定ページは以下です。

https://example.com/wp-json/wp/v2/pages

カテゴリは以下です。

https://example.com/wp-json/wp/v2/categories

2つ目は、WPGraphQLなどのプラグインを使ってGraphQL APIで取得する方法です。

GraphQLを使うと、必要なデータだけを指定して取得しやすくなります。ただし、追加プラグインが必要になるため、まずはREST APIで始める方がシンプルです。

小規模から中規模サイトであれば、最初はREST APIで十分です。

記事数が多い、取得データを細かく制御したい、フロントエンド側の型管理をしっかりしたい場合は、GraphQLを検討してもよいでしょう。

まず、WordPress側でHeadless化の準備をします。

最低限確認する項目は以下です。

• REST APIが有効か
• パーマリンク設定が正しいか
• 記事のスラッグが整理されているか
• カテゴリとタグが整理されているか
• アイキャッチ画像が設定されているか
• SEO用のタイトル・説明文をどこで管理するか
• 不要なプラグインを削除できるか
• セキュリティ対策ができているか

REST APIが有効であれば、以下のURLにアクセスするとJSONデータが表示されます。

https://example.com/wp-json/wp/v2/posts

ここで記事データが返ってくれば、Next.js側から取得できます。

もし表示されない場合は、セキュリティ系プラグインやサーバー設定でREST APIが制限されている可能性があります。

Headless構成では、WordPressテーマでサイト表示を作る必要はありません。

ユーザーが見る画面はNext.js側で作るため、WordPressテーマは管理画面とAPIが動けば十分です。

ただし、WordPress本体を完全に削除するわけではありません。

WordPressは以下の用途で使います。

• 管理画面にログインする
• 記事を書く
• 画像をアップロードする
• カテゴリを設定する
• タグを設定する
• 公開・下書きを管理する
• APIで記事データを提供する

そのため、WordPress側には軽量なテーマを入れておけば十分です。

重要なのは、WordPressを「表示のためのシステム」ではなく、「記事管理のためのCMS」として扱うことです。

Next.js側では、以下のようなページ構成を作ります。

app/
  page.jsx
  blog/
    page.jsx
    [slug]/
      page.jsx
  about/
    page.jsx
  contact/
    page.jsx

この場合、役割は以下です。

app/page.jsx

トップページです。Next.jsで直接作ります。

app/blog/page.jsx

WordPress APIから投稿一覧を取得し、ブログ一覧を表示します。

app/blog/[slug]/page.jsx

WordPress APIから該当スラッグの記事を取得し、記事詳細を表示します。

app/about/page.jsx

会社紹介やブランドページなど、記事ではないページをNext.jsで直接作ります。

app/contact/page.jsx

問い合わせページをNext.jsで作ります。

この構成にすると、記事だけWordPressから取得し、それ以外はNext.jsで完全に自由に作れます。

Next.js側では、fetchを使ってWordPress REST APIから記事一覧を取得できます。

基本的な考え方は以下です。

const res = await fetch("https://example.com/wp-json/wp/v2/posts?_embed");
const posts = await res.json();

_embed を付けると、アイキャッチ画像などの関連データも一緒に取得しやすくなります。

Next.js App Routerでは、サーバー側で fetch して、その結果をページに表示できます。

Next.js の fetch は、通常の fetch を拡張しており、キャッシュや再検証の設定ができます。例えば、一定時間ごとにWordPressの記事データを再取得するように設定できます。

記事サイトでは、毎回リアルタイムでWordPressにアクセスするより、一定時間キャッシュする方が表示速度と安定性の面で有利です。

ブログ一覧ページでは、WordPressから投稿一覧を取得し、タイトルや抜粋を表示します。

実装イメージは以下です。

async function getPosts() {
  const res = await fetch(
    "https://example.com/wp-json/wp/v2/posts?_embed&per_page=10",
    {
      next: { revalidate: 300 }
    }
  );

  if (!res.ok) {
    throw new Error("Failed to fetch posts");
  }

  return res.json();
}

export default async function BlogPage() {
  const posts = await getPosts();

  return (
    <main>
      <h1>Blog</h1>

      <div>
        {posts.map((post) => (
          <article key={post.id}>
            <h2>{post.title.rendered}</h2>
            <div
              dangerouslySetInnerHTML={{
                __html: post.excerpt.rendered
              }}
            />
          </article>
        ))}
      </div>
    </main>
  );
}

ここでは、WordPressの記事タイトルと抜粋を取得して表示しています。

WordPress REST APIの本文やタイトルはHTMLとして返るため、表示時にはHTMLの扱いに注意が必要です。

記事詳細ページでは、URLのslugを使ってWordPressから該当記事を取得します。

例えば、Next.js側のURLを以下のようにします。

/blog/wordpress-headless-nextjs/

このslugを使って、WordPress APIに問い合わせます。

https://example.com/wp-json/wp/v2/posts?slug=wordpress-headless-nextjs&_embed

実装イメージは以下です。

async function getPost(slug) {
  const res = await fetch(
    `https://example.com/wp-json/wp/v2/posts?slug=${slug}&_embed`,
    {
      next: { revalidate: 300 }
    }
  );

  if (!res.ok) {
    throw new Error("Failed to fetch post");
  }

  const posts = await res.json();

  return posts[0];
}

export default async function BlogPostPage({ params }) {
  const post = await getPost(params.slug);

  if (!post) {
    return <div>記事が見つかりませんでした。</div>;
  }

  return (
    <main>
      <article>
        <h1>{post.title.rendered}</h1>

        <div
          dangerouslySetInnerHTML={{
            __html: post.content.rendered
          }}
        />
      </article>
    </main>
  );
}

このようにすれば、WordPressで作成した記事をNext.js側のデザインで表示できます。

記事数がある程度決まっている場合は、Next.js の generateStaticParams を使って、記事ページを静的生成できます。

これにより、記事詳細ページを高速に表示しやすくなります。

実装イメージは以下です。

export async function generateStaticParams() {
  const res = await fetch(
    "https://example.com/wp-json/wp/v2/posts?per_page=100"
  );

  const posts = await res.json();

  return posts.map((post) => ({
    slug: post.slug
  }));
}

この設定により、WordPressから取得した記事スラッグに基づいて、Next.js側で記事ページを生成できます。

ただし、記事数が非常に多い場合は、すべてをビルド時に生成すると時間がかかります。

その場合は、ISR を使って必要に応じてページを再生成する方法が現実的です。

Headless WordPress構成で重要なのが、WordPressで記事を更新したときに、Next.js側へどう反映するかです。

Next.js では、revalidate を使って一定時間ごとにデータを再取得できます。

例えば、以下のように設定します。

fetch(url, {
  next: { revalidate: 300 }
});

この場合、最大で約5分ごとにデータが再検証されます。

記事更新頻度が低いサイトなら、300秒から3600秒程度でも問題ありません。

頻繁に更新するニュースサイトなら、短めに設定します。

一方、公開直後にすぐ反映したい場合は、WordPressの更新時に Next.js 側の再検証APIを叩く仕組みを作るとよいです。

より本格的に運用するなら、WordPress で記事を公開・更新したタイミングで、Next.js 側のキャッシュを再検証する仕組みを作ります。

考え方は以下です。

1. WordPressで記事を更新する
2. WordPressのフックが動く
3. Next.jsのAPI Routeにリクエストを送る
4. Next.js側で該当ページのキャッシュを再検証する
5. 最新の記事内容が反映される

これにより、「WordPressで更新したのにNext.js側にまだ反映されない」という問題を減らせます。

最初は revalidate の時間指定だけで始めても問題ありません。

ただし、記事更新を即時反映したい場合は、Webhook または WordPress側のカスタム処理を導入するのがおすすめです。

Headless WordPress では、SEOメタ情報の扱いが重要です。

WordPress側で Yoast SEO や Rank Math などを使っている場合でも、最終的にHTMLとしてmetaタグを出力するのは Next.js 側です。

そのため、Next.js の generateMetadata を使って、記事ごとに title、description、canonical、OGP画像などを出力します。

Next.js の generateMetadata は、ページごとのデータに応じたメタ情報を生成できます。

記事詳細ページでは、WordPressから取得した記事タイトルや説明文を使って、metadata を作ります。

実装イメージは以下です。

export async function generateMetadata({ params }) {
  const post = await getPost(params.slug);

  if (!post) {
    return {
      title: "記事が見つかりません"
    };
  }

  return {
    title: post.title.rendered,
    description: post.excerpt.rendered.replace(/<[^>]+>/g, ""),
    openGraph: {
      title: post.title.rendered,
      description: post.excerpt.rendered.replace(/<[^>]+>/g, ""),
      type: "article"
    }
  };
}

このようにすれば、WordPress の記事データを使いながら、Next.js 側でSEOに必要なタグを出力できます。

WordPress 側でSEOプラグインを使っている場合、メタタイトルやメタディスクリプションをAPI経由で取得したいケースがあります。

ただし、標準の WordPress REST API だけでは、SEOプラグイン独自のメタ情報がそのまま取得できないことがあります。

対応方法は主に以下です。

• REST APIにカスタムフィールドを追加する
• SEOプラグインのREST API対応機能を使う
• ACFでSEO項目を作り、APIに出す
• Next.js側でタイトル・抜粋から自動生成する
• WPGraphQLとSEO拡張を使う

最初は、Next.js側で以下のようにシンプルに扱うのが現実的です。

title

WordPressの記事タイトルを使う。

description

WordPressの抜粋を使う。

OGP画像

WordPressのアイキャッチ画像を使う。

canonical

Next.js側のURLを使う。

この形でも、基本的なSEO運用は可能です。

WordPress REST APIでアイキャッチ画像を取得するには、_embed を付ける方法が便利です。

例えば、以下のように取得します。

https://example.com/wp-json/wp/v2/posts?_embed

レスポンス内の _embedded に、アイキャッチ画像の情報が含まれます。

Next.js 側では、以下のように画像URLを取り出せます。

const featuredImage =
  post._embedded?.["wp:featuredmedia"]?.[0]?.source_url;

この画像URLを Next.js の Image コンポーネントで使う場合は、next.config.js で WordPress の画像ドメインを許可する必要があります。

例えば、WordPressの画像が example.com にある場合、next.config.js で画像ドメインを設定します。

const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "example.com"
      }
    ]
  }
};

export default nextConfig;

これで、WordPressにアップロードした画像を Next.js 側で表示できます。

WordPress REST API から取得する本文はHTMLです。

そのため、Next.js 側で表示するときには、以下のように dangerouslySetInnerHTML を使うケースがあります。

<div
  dangerouslySetInnerHTML={{
    __html: post.content.rendered
  }}
/>

ただし、HTML をそのまま表示する場合は注意が必要です。

特に、以下の点を確認します。

• 信頼できるWordPressからのみ取得する
• 不要なscriptタグが入らないようにする
• 埋め込みコンテンツの表示を確認する
• 画像の幅や高さが崩れないようにする
• テーブルやボタンのCSSを整える
• WordPressブロックのclass名に対応する

自分たちだけが記事を投稿するWordPressであれば、リスクは比較的低いです。

ただし、複数ユーザーが投稿する場合や、外部入力が混ざる場合は、HTMLサニタイズを検討しましょう。

WordPressのブロックエディタで作成した記事は、本文HTMLに WordPress 独自のclass名が含まれます。

例えば、以下のような class です。

wp-block-image
wp-block-quote
wp-block-table
wp-block-button

Next.js 側では、これらの class に対してCSSを用意する必要があります。

そうしないと、WordPress管理画面ではきれいに見えていた記事が、Next.js 側では崩れて見えることがあります。

最低限、以下の要素にはスタイルを用意しましょう。

• h2
• h3
• p
• ul
• ol
• blockquote
• table
• img
• figure
• figcaption
• a
• strong
• code
• pre

記事本文用のCSSを作り、prose クラスのような形で記事本文全体に適用すると管理しやすいです。

Headless WordPress でよく問題になるのが、記事のプレビューです。

通常のWordPressでは、下書き記事を WordPressテーマ上でプレビューできます。

しかし、Headless構成では、実際の表示は Next.js 側です。

そのため、下書きや予約投稿を Next.js 側でプレビューする仕組みが必要になります。

対応方法は以下です。

• WordPressのプレビューボタンからNext.jsのプレビューURLへ飛ばす
• Next.js側でDraft Modeを使う
• 認証付きで下書き記事を取得する
• WordPress Application Passwordsを使って非公開データを取得する

最初の段階では、公開済み記事だけを Next.js で表示し、プレビューは WordPress 管理画面内で簡易確認する運用でもよいです。

本格運用では、Next.js 側にプレビューモードを用意する方が便利です。

WordPressの Application Passwords を使うと、REST API への認証付きリクエストに利用できます。ただし、認証情報は必ずサーバー側で扱い、ブラウザに出さないようにします。

Headless構成では、ユーザーが見るサイトは Next.js です。

そのため、WordPress側は管理画面とAPIだけ使えれば十分です。

セキュリティを高めるために、WordPress側を以下のように制限することもできます。

• WordPressトップページをnoindexにする
• WordPress側の通常表示を使わない
• 管理画面URLへのアクセス制限を行う
• ログイン試行回数を制限する
• 不要なREST APIエンドポイントを制限する
• XML-RPCを無効化する
• WordPress本体とプラグインを常に更新する

ただし、REST API 自体を完全に止めると Next.js から記事を取得できなくなるため注意が必要です。

公開記事を取得するAPIは使える状態にしておき、管理系APIや認証が必要なAPIは適切に保護します。

Headless化する場合、URL設計は Next.js 側で決めます。

例えば、以下のような構成にできます。

トップページ

/

ブログ一覧

/blog/

記事詳細

/blog/[slug]/

カテゴリ一覧

/blog/category/[slug]/

タグ一覧

/blog/tag/[slug]/

サービスページ

/service/

問い合わせ

/contact/

既存のWordPress記事URLがすでに検索エンジンに評価されている場合は、できるだけ同じURLを Next.js 側でも再現するのがおすすめです。

例えば、WordPress側の記事URLが以下だった場合、

/wordpress-headless-nextjs/

Next.js 側も同じURLにできます。

ただし、サイト構造を整理するために、

/blog/wordpress-headless-nextjs/

のように変更する場合は、旧URLから新URLへ301リダイレクトを設定します。

すでにWordPressサイトがある場合は、いきなり完全Headless化するのではなく、段階的に移行するのがおすすめです。

流れは以下です。

1. 既存WordPressサイトの記事URLを洗い出す
2. 重要記事をリスト化する
3. WordPress REST APIで記事が取得できるか確認する
4. Next.jsで記事一覧ページを作る
5. Next.jsで記事詳細ページを作る
6. デザインを整える
7. 画像表示を確認する
8. SEOメタ情報を設定する
9. リダイレクト計画を作る
10. 本番ドメインをNext.jsへ切り替える

この流れで進めると、既存記事を活かしながら Next.js 化できます。

特に重要なのは、既存URLと新URLの対応表です。

検索流入があるページについては、URLを維持するか、必ず301リダイレクトを設定します。

Headless WordPress では、WordPress と Next.js をどのドメインに置くかを決める必要があります。

おすすめは以下の構成です。

ユーザー向けサイト

https://example.com

WordPress管理画面

https://cms.example.com

この場合、ユーザーは example.com の Next.js サイトを見るだけです。

編集者は cms.example.com にログインして記事を書きます。

Next.js は cms.example.com の REST API から記事データを取得します。

この構成にすると、ユーザー向けサイトとWordPress管理画面を明確に分けられます。

別案として、WordPress を以下のように置くこともできます。

https://example.com/wp

ただし、将来的な管理やセキュリティを考えると、cms.example.com のようなサブドメイン運用の方が分かりやすいです。

Next.js と WordPress を別ドメインまたは別サブドメインで運用する場合、CORSの確認が必要になることがあります。

ただし、Next.js のサーバー側で WordPress API を fetch する場合は、ブラウザから直接APIを叩くわけではないため、CORS問題は起きにくいです。

一方、クライアントコンポーネントから直接 WordPress API を叩く場合は、CORS設定が問題になることがあります。

基本方針としては、WordPress API の取得は Next.js のサーバー側で行うのがおすすめです。

その方が、以下のメリットがあります。

• API URLを隠しやすい
• 認証情報を安全に扱える
• キャッシュを使いやすい
• SEOに強い
• 初期表示が速い
• CORS問題を避けやすい

記事データは、なるべく Server Component または Route Handler 経由で取得しましょう。

すべてのコンテンツを WordPress で管理する必要はありません。

おすすめは、以下のように分けることです。

WordPressで管理するページ

• ブログ記事
• ニュース
• お知らせ
• コラム
• 更新頻度の高い記事コンテンツ

Next.jsで管理するページ

• トップページ
• サービスページ
• 料金ページ
• 会社紹介
• LP
• 問い合わせページ
• 申し込みページ
• 固定の導線ページ
• デザイン性が重要なページ

この分け方にすると、記事更新は WordPress で簡単に行い、ブランドページや LP は Next.js で自由に設計できます。

特に、サービスサイトや留学サイトのように、記事SEOとブランド訴求の両方が必要なサイトでは、この構成が非常に相性が良いです。

実際の運用フローは以下のようになります。

記事を書く人

• WordPressにログインする
• 記事を作成する
• カテゴリやタグを設定する
• アイキャッチ画像を設定する
• 公開する

Next.js側

• WordPress REST APIから記事を取得する
• 記事一覧ページに表示する
• 記事詳細ページに表示する
• 一定時間ごとに再検証する
• 必要に応じて即時再検証する

ユーザー

Next.js で作られた高速なページを見る。

このように、運用者は WordPress を使い続けながら、ユーザーには Next.js の高速で洗練されたサイトを見せることができます。

WordPress を Headless CMS として使い、Next.js で表示するメリットは大きいです。

主なメリットは以下です。

• WordPressの管理画面をそのまま使える
• 記事投稿の運用を大きく変えなくてよい
• Next.jsで高速な表示を実現できる
• デザインの自由度が高い
• WordPressテーマに依存しなくなる
• フロントエンドを自由に改善できる
• LPやサービスページを作り込みやすい
• セキュリティ面でWordPressの露出を減らせる
• 将来的な多言語化や複数サイト展開がしやすい

特に、記事数が多いサイトでは、WordPress を完全に捨てるよりも、Headless CMS として再利用する方が現実的です。

一方で、デメリットもあります。

• 開発難易度が上がる
• WordPressテーマだけでは完結しない
• プレビュー機能を別途作る必要がある
• SEOメタ情報の扱いを設計する必要がある
• 画像管理が複雑になることがある
• WordPressとNext.jsの両方を保守する必要がある
• API障害時の対応を考える必要がある
• フォームや検索機能を別途実装する必要がある

特に注意すべきなのは、WordPress で記事を更新しても、Next.js 側に即時反映されるとは限らない点です。

キャッシュや ISR を使う場合、反映までに少し時間がかかることがあります。

そのため、更新頻度や運用体制に合わせて、revalidate の時間や Webhook 再検証を設計する必要があります。

Headless WordPress 移行でよくある失敗は以下です。

1つ目は、WordPressの本文HTMLをそのまま表示して、デザインが崩れることです。

WordPressブロックのclassに対応したCSSを用意していないと、画像、表、引用、ボタンなどが崩れます。

2つ目は、SEOメタ情報を移行しないことです。

記事タイトルだけ表示して、meta description、canonical、OGPを設定していないと、SEO上もSNSシェア上も弱くなります。

3つ目は、旧URLからのリダイレクトを忘れることです。

既存WordPressサイトから移行する場合、リダイレクトを設定しないと、検索評価を失う可能性があります。

4つ目は、WordPress管理画面のプレビューが使えなくなることを想定していないことです。

Headless化すると、実際の表示は Next.js 側になるため、プレビュー導線を別途考える必要があります。

5つ目は、WordPress API をブラウザ側から直接叩きすぎることです。

記事データは Next.js のサーバー側で取得し、キャッシュを使う方が安定します。

最初から完璧な Headless 構成を作る必要はありません。

最小構成なら、以下で始められます。

WordPress側

• 投稿記事を管理
• カテゴリを管理
• アイキャッチ画像を設定
• REST APIを有効にする

Next.js側

• トップページを作る
• ブログ一覧ページを作る
• ブログ詳細ページを作る
• WordPress REST APIから記事を取得する
• revalidateを設定する
• 基本的なSEO metadataを設定する

最初はこれで十分です。

その後、必要に応じて以下を追加します。

• プレビュー機能
• Webhook再検証
• カテゴリページ
• タグページ
• 検索機能
• 人気記事
• 関連記事
• サイトマップ
• RSS
• OGP画像自動生成

段階的に拡張することで、開発負担を抑えながら Headless 化できます。

実装は以下の順番がおすすめです。

1. WordPress REST APIで記事が取れるか確認する
2. Next.jsで記事一覧ページを作る
3. Next.jsで記事詳細ページを作る
4. アイキャッチ画像を表示する
5. 本文用CSSを整える
6. SEO metadataを設定する
7. カテゴリページを作る
8. 旧URLからのリダイレクトを設定する
9. サイトマップを作る
10. revalidateを設定する
11. WordPress更新時のWebhook再検証を作る
12. プレビュー機能を作る

この順番なら、まず公開に必要な最低限の機能を作り、その後で運用改善機能を追加できます。

例えば、サービスサイトと記事メディアを組み合わせる場合、以下のような構成にできます。

Next.jsで直接管理

• /
• /concept/
• /service/
• /pricing/
• /about/
• /contact/
• /consultation/

WordPressから取得

• /blog/
• /blog/[slug]/
• /blog/category/[slug]/
• /blog/tag/[slug]/

この構成では、ブランドやサービス訴求に関わる重要ページは Next.js で作り込みます。

一方、SEO記事やお知らせは WordPress で投稿します。

これにより、サイト全体のデザイン品質を高めながら、記事更新のしやすさも維持できます。

WordPress を Headless CMS として使い、Next.js でサイトを表示する方法は、既存のWordPress運用とNext.jsのメリットを両立できる現実的な構成です。

記事の作成・編集・公開は WordPress で行い、実際の表示、デザイン、SEO構造、トップページ、サービスページ、LP などは Next.js で管理します。

この方法なら、ライターや編集者はこれまで通り WordPress 管理画面を使えます。

一方、ユーザーが見るサイトは Next.js で高速・自由に作れます。

実装の基本は、WordPress REST API から記事データを取得し、Next.js のブログ一覧ページや記事詳細ページで表示することです。

最初は REST API と revalidate を使ったシンプルな構成で始め、必要に応じて Webhook 再検証、プレビュー機能、SEOプラグイン連携、カテゴリページ、サイトマップなどを追加していくのがおすすめです。

注意点は、本文HTMLのスタイル、SEOメタ情報、画像表示、旧URLからの301リダイレクト、プレビュー機能です。

これらを丁寧に設計すれば、WordPressの記事資産を活かしながら、Next.jsによる高速で洗練されたサイト運用が可能になります。