WordPress＋Next.js（REST API連携）のヘッドレス環境で、記事修正が反映されないときの対応メモ

課題

弊社では、WordPress＋Next.js（App Router）を組み合わせたヘッドレスCMS構成で、ニーテンゴギーク（2.5dgeek.jp）というオウンドメディアサイトを運営しています。

WordPress＋Next.js（App Router）でヘッドレスCMS環境を構築しているとき、WordPress側で記事を更新・修正しても、Next.js側にすぐ反映されない問題に遭遇しました。

Next.jsのApp Routerでは、データフェッチ時に自動的にキャッシュ（Full Route Cache）が効く仕組みになっています。

このため、fetch関数を使ってWordPressのREST APIから記事データを取得すると、初回取得時のデータがキャッシュされ以降も更新されないという状況が発生します。

とくにnext: { revalidate: } を設定していない場合、Next.js側が「一度取得したデータはしばらく変わらないだろう」と判断して、キャッシュを維持する仕様になっています。

next: {
  revalidate: 0,
}

を追加して、キャッシュを無効化（常に新しいデータを取得）するように設定しました。

const res = await fetch(`${process.env.WORDPRESS_API_URL}/wp-json/wp/v2/posts`, {
  next: { revalidate: 0 },
});
const posts = await res.json();

これによって、WordPress側で記事を編集・公開したあとも、Next.jsアプリで即時に変更が反映されるようになりました。

revalidate: 0は、毎回リクエストが飛ぶためアクセスが増えるとWordPress側に負荷がかかる可能性があります
サイト規模やアクセス頻度によっては、ISR（Incremental Static Regeneration）などを使って適切なキャッシュ戦略を設計するほうがよい場合もあります
「本番環境はキャッシュするけど、プレビューや管理画面用だけ revalidate: 0 にする」といった切り分けも検討できます

Next.jsのキャッシュシステム（Full Route Cacheなど）をうまく活かしたかったこと、最近の記事など更新頻度が高くシンプルなデータ構造のものはREST API経由に移行しました。
一方で、検索ページなど複雑なクエリが必要な箇所ではGraphQLを使ってfetchしています。

また、弊社プロダクトであるニーテンゴギーク（2.5dgeek.jp）では、記事の修正がすぐに反映される必要があるため、本番境でもrevalidate: 0を設定して運用しています。

用途に応じてAPIの使い分けとキャッシュ制御を工夫することで、パフォーマンスと柔軟性のバランスを取るようにしています。

WordPress＋Next.jsのヘッドレス構成では、キャッシュの扱いに注意が必要です。
今回のケースではシンプルに revalidate: 0 で対応できましたが、プロジェクトの規模や要件に応じてキャッシュポリシーは慎重に設計する必要があると感じました。