目次

なぜチームはWordPressを離れるのか

WordPressは現在もウェブ全体の約40%を支えていますが、2024年以降そのシェアは緩やかに下落しています。多くのチームが口をそろえて挙げる理由は共通しています。セキュリティ対応の疲弊、プラグインの肥大化、そしてパフォーマンスの限界です。

テーマと最低限のプラグインをインストールしただけの標準的なWordPressサイトでも、1ページの表示に30〜80件のHTTPリクエストが発生します。プラグインを追加するたびにPHPの実行時間が伸び、データベースへのクエリが増え、セキュリティの脆弱面も広がっていきます。新機能の開発よりも、プラグインのアップデートや脆弱性のパッチ対応に追われる時間のほうが長くなる——多くの開発者が経験するジレンマです。

Next.jsはこの構造をまるごと刷新します。リクエストのたびにHTMLを生成するモノリシックなPHPアプリケーションではなく、ビルド時にページを事前レンダリングし、エッジCDNから配信し、クライアント側でインタラクティブに動作するReactフレームワークです。結果として、ページ表示は1秒以下になり、訪問者へのデータベースクエリはゼロになり、自分たちが本当にコントロールできるコードベースを手に入れられます。

移行を決断させる「限界点」

ほとんどのチームは、次のいずれかのタイミングで移行を決意します。

  • Core Web Vitalsの不合格 — 特にElementorやWPBakeryといったページビルダーを使っているWordPressサイトは、LCPやCLSのスコアで慢性的に苦しんでいます
  • プラグインの競合 — プラグインを1つ更新しただけでサイトが壊れ、1個ずつ無効化して原因を探る羽目になる
  • ホスティングコストの増大 — WP EngineやKinstaといったマネージドWordPressホスティングは月額3,000〜20,000円以上かかりますが、Vercelの無料枠でも同等以上のパフォーマンスが出せます
  • 開発体験の陳腐化 — コンポーネントベースのReact開発と比べると、PHPテンプレートは古さを隠せません
  • セキュリティインシデント — WordPressの脆弱性の97%は、コア本体ではなくプラグインやテーマに起因しています

Next.js vs WordPress：徹底比較

比較項目 WordPress Next.js
レンダリング リクエストごとにサーバーサイドPHPが実行 静的生成 + ISR + サーバーコンポーネント
パフォーマンス LCP 平均2.5〜6秒 LCP 平均0.5〜1.5秒
セキュリティ プラグイン・テーマの脆弱性が絶えない 攻撃面なし（CDN上の静的ファイル）
ホスティングコスト マネージドで月額3,000〜20,000円 Vercelの無料枠でほとんどのサイトをカバー
SEOのコントロール テーマ + Yoastに依存 メタ情報・構造化データ・サイトマップを完全制御
コンテンツ編集 組み込みの管理パネル ヘッドレスCMS（Sanity、Strapi、Payload、Supabaseなど）
スケーラビリティ キャッシュ・CDN・DBチューニングが必要 エッジネイティブ、設定ゼロで数百万リクエストに対応
開発体験 PHP + フック + テンプレート階層 React + TypeScript + モダンツールチェーン
ビルド時間 なし（ランタイムレンダリング） ページ数に応じて数秒〜数分
画像の最適化 プラグイン必須（Smush、ShortPixelなど） next/imageで自動最適化（組み込み）

WordPressがまだ優位なケース

WordPressがすべてのチームにとって間違った選択というわけではありません。開発者が不在で、シンプルなブログや企業紹介サイトを素早く立ち上げたいなら、マネージドホスティングと組み合わせたWordPressは依然として最短ルートです。豊富なテーマとプラグインのエコシステムのおかげで、コードを書かなくても機能的なサイトが作れます。

ただし、カスタム機能の実装、パフォーマンスの最適化、あるいは開発スピードの向上が求められた瞬間、WordPressはボトルネックに変わります。

移行後に期待できるパフォーマンス改善

私たちはこれまで200件以上のWordPressサイトをNext.jsへ移行してきました。一貫して見られる実測値をご紹介します。

Largest Contentful Paint（LCP）： 平均3.2秒 → 0.9秒。72%の改善。静的生成によって、リクエストが届く前からHTMLが準備済みの状態になります。

Cumulative Layout Shift（CLS）： 0.18 → 0.02。Next.jsのImageコンポーネントが画像の寸法を自動で管理するため、WordPressテーマで頻発するレイアウトのズレが根本から解消されます。

First Input Delay（FID）/ Interaction to Next Paint（INP）： 180ms → 45ms。jQueryも、メインスレッドを奪い合うプラグインのJavaScriptも存在しません。

Time to First Byte（TTFB）： 600ms（キャッシュ済み）→ 50ms。エッジCDN対オリジンサーバーでは、そもそも勝負になりません。

ページサイズ： 平均2.8MB → 340KB。テーマの未使用CSSも、レンダリングをブロックするプラグインスクリプトも不要です。

これらの数値はビジネス成果に直結します。GoogleはCore Web Vitalsをランキングシグナルとして使用しています。サイトが速ければコンバージョン率も上がります。ロード時間が100ms改善するごとに、コンバージョン率は約1%向上すると言われています。

移行プロセスのステップバイステップ解説

フェーズ1：コンテンツの棚卸しとエクスポート

コードに触れる前に、WordPress上のすべてのリソースを棚卸しします。

  • 固定ページと投稿 — カスタムフィールド（ACF、メタボックス）を含むすべてのコンテンツをエクスポート
  • メディアライブラリ — 画像とドキュメントをすべてダウンロード
  • URL構造 — すべてのパーマリンク、カテゴリーURL、カスタム投稿タイプのスラッグを記録
  • リダイレクト — 既存のリダイレクトルールをエクスポート
  • フォーム — すべてのフォームの設定と送信先を記録
  • サードパーティ連携 — すべてのプラグインと用途をリストアップ

エクスポートにはwp-cliか、WordPress組み込みのエクスポートツールを使いましょう。ACFフィールドとカスタム投稿タイプには、REST APIを使って構造化されたJSONを取得してください。

フェーズ2：コンテンツ管理層の選定

移行における最大の決断は、WordPress後にコンテンツをどこで管理するかです。主な選択肢は以下の通りです。

ヘッドレスWordPress — WordPressをバックエンドとして残し、REST APIまたはWPGraphQL経由でNext.jsにデータを渡す方法。段階的な移行として有効ですが、WordPress自体の保守は続きます。

ヘッドレスCMS — Sanity、Strapi、Payload CMS、Contentfulなど。ヘッドレス構成のために設計されたプラットフォームです。柔軟性の観点から、SanityとPayloadを特に推奨しています。

データベース直接管理 — SupabaseやPlanetScaleを使い、カスタム管理画面でPostgreSQLにコンテンツを保存する方法。最大限のコントロールが得られますが、初期構築に手間がかかります。

Markdown / MDX — 開発者向けブログやドキュメントサイトに最適。コンテンツをリポジトリで管理し、Gitでバージョン管理します。

フェーズ3：Next.jsサイトの構築

App Routerを使ってcreate-next-appでプロジェクトを作成します。WordPressのテンプレート階層をNext.jsのレイアウトとページに対応させましょう。

  • header.php / footer.php → app/layout.tsx
  • page.php → app/page.tsx
  • single.php → app/blog/[slug]/page.tsx
  • archive.php → app/blog/page.tsx
  • functions.php → app/api/のAPIルート

デザインをReactコンポーネントとして再構築します。長年積み重なったCSS負債を清算し、モダンなデザインシステムをゼロから始める絶好の機会です。

フェーズ4：SEO移行

移行の成否を分けるフェーズです。詳細は次のセクションで解説します。

フェーズ5：テストとローンチ

新旧サイトを並行稼働させ、Screaming Frogなどのツールで新サイトをクロールして旧サイトと比較します。確認事項は以下の通りです。

  • 旧サイトのすべてのURLにリダイレクトまたは対応するURLが存在する
  • すべてのメタタイトルとディスクリプションが引き継がれている、または改善されている
  • 構造化データ（schema.org）が正しくレンダリングされている
  • XMLサイトマップが有効で、Search Consoleに送信済みである
  • canonicalタグが正しいURLを指している
  • Open GraphおよびTwitter CardのメタタグがHTMLに含まれている
  • 内部リンクがすべて正常に機能している

移行中のSEO対策

SEOは、WordPressから移行するすべてのチームにとって最大の懸念事項です。検索順位を失えば、どれだけ速いサイトができても移行は失敗と見なされます。

URLのマッピング

旧URLと新URLの完全な対応表を作成してください。1ページも漏らさず。スプレッドシートやスクリプトを使ってリダイレクトルールを生成し、next.config.jsまたはホスティングプラットフォーム上で301リダイレクトとして実装します。

メタデータの移行

YoastやRankMathからSEOタイトル、メタディスクリプション、Open Graphデータをすべて抽出し、Next.jsの対応するページにマッピングします。自動生成のメタに頼らず、トラフィック上位50ページは手動で必ず確認してください。

構造化データ

WordPressプラグインは自動でスキーママークアップを生成しますが、Next.jsではすべて自分で制御します。JSON-LDで以下を実装してください。トップページにはOrganization、ブログ記事にはArticle、全ページにBreadcrumbList、FAQ付きページにはFAQPage、そして該当する場合はLocalBusinessも忘れずに。

XMLサイトマップ

next-sitemapまたはカスタムAPIルートを使って動的なサイトマップを生成し、ローンチ直後にGoogle Search Consoleへ送信してください。

ローンチ後のモニタリング

ローンチから4週間は、毎日Search Consoleをチェックしましょう。確認すべき項目は、クロールエラーと404の発生状況、インデックス数の変動、順位の変動（2〜4週間は正常範囲内）、そしてCore Web Vitalsのスコア改善です。

WordPress後のコンテンツ管理

WordPressを離れることへの最も多い反論が「管理パネルを失う」という点です。コンテンツ編集者にとって、使い慣れたWordPressのエディターは手放しがたいものです。

しかし、現代のヘッドレスCMSはこのギャップをほぼ完全に埋めています。Sanity Studio、Payload CMS、Strapiはいずれも、ライブプレビュー、ドラッグ&ドロップ、メディア管理を備えたリッチな編集体験を提供します。慣れてしまえば、むしろWordPressより使いやすいと感じる編集者も少なくありません。

最もシンプルな選択肢を求めるチームには、Payload CMSを強くお勧めします。Next.jsアプリの内部で動作し、既存のデータベースをそのまま使用でき、WordPressに匹敵する管理パネルを提供します。セキュリティ上の問題もパフォーマンス上の問題も、一切ありません。

よくある移行の失敗と対策

すべてのURLをリダイレクトしない。 WordPressに存在したURLはすべてリダイレクトが必要です。ページネーションURL、添付ファイルページ、著者アーカイブ、フィードURLも含めて一つも漏らしてはいけません。これを怠るとリンクエクイティが失われます。

モニタリングなしでローンチする。 稼働監視、エラートラッキング（Sentry）、アクセス解析は、ローンチ後ではなく事前に必ず設定してください。

最初のバージョンを作り込みすぎる。 まずコンテンツとデザインの移行を完了させてください。新機能は移行が安定してから追加します。リデザインとプラットフォーム移行を同時に進めると、リスクが倍増します。

メディアライブラリを軽視する。 WordPressはアップロードごとに複数サイズの画像を生成しています。移行前に画像戦略を決め、まとめて変換処理を行いましょう。

RSSフィードを忘れる。 WordPressブログにRSS経由のフィード購読者がいる場合、フィードURLを維持するかリダイレクトを設定してください。

WordPressを使い続けるべきケース

自分たちの状況を冷静に見極めてください。以下に当てはまるなら、WordPressが今もベストな選択です。

  • 開発者がおらず、開発予算もない
  • コンテンツチームがヘッドレスに対応した代替手段のない特定のWordPressプラグインに強く依存している
  • 複雑な商品設定のあるWooCommerceショップを運営している（この場合、Next.jsよりもShopifyやMedusaへの移行を検討してください）
  • 月間訪問者数が1万人未満で、パフォーマンスがビジネス上の課題になっていない

それ以外のチーム——特にマーケティングサイト、SaaSのランディングページ、コンテンツプラットフォーム、あるいはパフォーマンスと開発体験を重視するあらゆるプロジェクトにおいては——2026年においてNext.jsが明確な勝者です。

よくある質問

WordPressからNext.jsへの移行にはどれくらい時間がかかりますか？ 一般的なブランドサイト（10〜30ページ程度）なら3〜6週間。数百件の投稿を抱えるコンテンツ量の多いサイトは6〜12週間が目安です。期間はページ数よりもコンテンツの複雑さとカスタム機能の量によって左右されます。

Googleの検索順位は落ちますか？ リダイレクトとSEO移行を適切に処理すれば、順位は維持できます。Googleが再クロール・再インデックスする間、1〜3週間程度の一時的な変動は想定内です。Core Web Vitalsの改善効果によって、多くのサイトでは4〜8週間以内に順位が向上します。

非エンジニアのメンバーでもコンテンツを編集できますか？ はい。Sanity、Payload、StrapiといったヘッドレスCMSはビジュアル編集インターフェースを提供しています。ライブプレビュー機能があるものも多く、編集者はリアルタイムで変更内容を確認できます。

Next.jsサイトのホスティングコストはどれくらいですか？ Vercelの無料枠でほとんどのサイトをカバーできます。カスタムドメインや分析機能が必要な商用プロジェクトはProプラン（月額約3,000円）で対応できます。マネージドWordPressホスティングの月額3,000〜20,000円以上と比べれば、大きなコスト削減になります。

Reactを学ぶ必要がありますか？ 開発者であれば、はい——ReactはNext.jsの土台です。コンテンツ編集者やマーケターであれば、不要です。CMSがあなたの作業を受け持ち、フレームワーク自体を意識する必要はありません。

ECサイトはどうすればいいですか？ シンプルなショップなら、Next.jsのストアフロント（Storefront API使用）と組み合わせたShopifyが優れた選択肢です。複雑なBtoB向けコマースには、Medusa.jsまたはSaleorとNext.jsの組み合わせで完全なコントロールを実現できます。WooCommerceからNext.jsへの移行は技術的には可能ですが、費用対効果が低いケースがほとんどです。コマース専用プラットフォームへの移行を先に検討してください。

WordPressをバックエンドとして使い続けることはできますか？ はい。ヘッドレスWordPress（WPGraphQLまたはREST APIを使用）を利用すれば、WordPressのエディターを維持しながら、フロントエンドをNext.jsで配信できます。段階的な移行アプローチとして有効ですが、WordPressの保守負担は引き続き残ります。

WordPressのマルチサイトはどう扱いますか？ マルチテナント構成はNext.jsのミドルウェアによるドメインルーティングで実現できます。各サイトがコンポーネントを共有しながら、コンテンツと設定を独立して管理することが可能です。WordPressマルチサイトよりも構成がシンプルで、保守もはるかに容易です。