WordPress から Next.js への移行 Vercel 2026

Q: 移行中に Google ランキングを失いますか？

いいえ、リダイレクト を正しく処理すれば。URL が変更される可能性があるすべてのの 301 リダイレクトを実装し、メタ タイトルとメタ説明を保持し、新しいサイトマップを Google Search Console に送信し、ドメインが変更される場合は [住所の変更] ツール を使用します。Google がより優れた Core Web Vitals を認識するため、2～4 週間の小さなランキング変動を期待し、その後回復または改善します。

Q: フォームと動的機能はどうですか？

Next.js API ルート（または App Router 内のサーバー アクション）は、フォーム送信、検索、認証、およびすべてのサーバー側ロジックを処理します。コンタクト フォームの場合、Resend などのサービスで Server Actions を使用できます。検索の場合、Algolia または Meilisearch を検討してください。認証の場合、NextAuth.js（現在 Auth.js v5）はほとんどのユースケースをカバーしています。

Q: WooCommerce ストアを移行する必要がある場合はどうなりますか？

これはより大きなプロジェクトです。ほとんどのチームは、ストア フロントを Next.js に移行し、コマース バックエンドを Shopify（Storefront API を使用）、Medusa.js、または Saleor に移動します。Shopify の Hydrogen フレームワークは別のオプションですが、フロントエンドに対する完全な制御が必要な場合は、Shopify の API を使用した Next.js が最も実績のあるパスです。e-コマース移行がタイムラインに 4～8 週間追加されることを期待します。

WordPress のインストールはページロードのたびに 487 キロバイトを送信しています — テーマアセット、プラグインスクリプト、3 層深くスタックされた jQuery 依存関係。Lighthouse パフォーマンススコアが 40 台で停滞する一方で、競合他社の Next.js サイトは同じコンテンツでより上位にランクされています。Next.js と Vercel への移行は理論的にはシンプルに聞こえます：コンテンツをエクスポートし、ヘッドレス CMS をセットアップし、デプロイするだけです。ですが、3 年間で 12 の移行プロジェクトを見てきた経験から、実際にはそうではありません。4 つのプロジェクトは 2 週間以内に完了しました。8 つのプロジェクトは数か月間停滞してしまいました。チームが WordPress が静かに処理していたもの（リダイレクト、画像最適化、XML サイトマップ、メタ注入）を見落としていたからです。アンインストールする前に、それを理解していませんでした。スムーズな切り替えと午前 2 時のロールバックの違いは、ほぼ常に 1 つのことに帰着します：WordPress が実際にあなたのサイトのために何をしているのかを監査してから、インストールを削除することです。

このガイドは、最初の移行の前に誰かが渡してくれればよかったと思うすべてのものです。完全な流れをカバーします：移行すべきかどうかの評価、ヘッドレス CMS の選択、コンテンツの移動、テンプレートの再構築、ランキングを失わずに SEO を処理すること、そしてトラフィックスパイクで落ちないセットアップで Vercel にデプロイすることです。

では、始めましょう。

WordPress to Next.js Migration on Vercel: A 2026 Guide

2026 年に WordPress から Next.js に移行する理由
移行前の監査：WordPress が実際に何をしているのか
ヘッドレス CMS バックエンドの選択
コンテンツ移行戦略
Next.js 15 でのフロントエンド再構築
URL 構造と SEO の保全
Vercel へのデプロイ：実際に機能する設定
パフォーマンスベンチマーク：移行前後
よくある移行のピットフォール
FAQ

2026 年に WordPress から Next.js に移行する理由

正直に言いましょう — WordPress は 2026 年の時点でも依然としてウェブの約 40% を動かしています。それはどこにも行きません。しかし、去る理由はより説得力をもつようになりました：

パフォーマンスの天井。 積極的なキャッシングプラグイン（WP Rocket、W3 Total Cache）を使っても、ほとんどの WordPress サイトは Lighthouse パフォーマンススコアで 70～80 の周辺で壁に当たります。プラグインの肥大化、レンダーブロッキングの PHP、そしてページロードのたびに発生するデータベースクエリは、いかなる最適化によっても完全には排除できないオーバーヘッドを生み出します。

セキュリティの攻撃面。 WordPress は 2025 年にコアとよく使われるプラグイン全体で 149 の文書化されている脆弱性がありました。すべてのプラグインは攻撃ベクトルです。すべてのテーマ更新は潜在的なブレークです。WooCommerce を実行している場合、攻撃面は倍になります。

開発者体験。 チームが React を知っているのであれば、PHP テンプレートで構築することは利き手ではない手で書くような感覚です。Next.js 15 の App Router、Server Components、および組み込みキャッシングは、WordPress が一致できない最新の開発ワークフローを提供します。

規模での費用。 マネージド WordPress ホスティング（WP Engine、Kinsta）は、まともなパフォーマンスで月 30～300 ドルです。Vercel の Pro プラン（月 20 ドル/ユーザー）エッジ関数と自動スケーリングを備えたもは、より良いパフォーマンスを発揮しながら、多くの場合コストが低くなります。

そうは言っても — トレンドだからというだけで移行しないでください。50 つの投稿を持つ簡単なブログでクライアントが週に 1 回 WordPress 管理画面経由でそれを更新している場合、移行は解決するより多くの問題を生じる可能性があります。移行の最良の候補は：

パフォーマンスを向上させる必要がある 500+ ページを持つサイト
コンポーネントベースの開発を望むチーム
プラグインの競合がメンテナンスの悪夢を引き起こしているサイト
WooCommerce パフォーマンスの制限に当たっている e-コマースサイト
エッジでの A/B テストとパーソナライゼーションが必要なマーケティングサイト

移行前の監査：WordPress が実際に何をしているのか

これはほとんどの移行が失敗する場所です。人々は単にブログを移行していると思っていますが、WordPress は実際にはコンタクトフォーム、リダイレクト、画像最適化、検索、コメント、認証、cron ジョブ、および 15 の他のもの（プラグイン構成に埋め込まれている）を処理しています。

単一行の Next.js コードを書く前に、すべてを文書化します：

プラグインインベントリ

プラグインリストをエクスポートして、各プラグインを分類します：

wp plugin list --status=active --format=csv > active-plugins.csv

各プラグインについて、答えてください：これは何をしていますか、そして Next.js エコシステムでそれを何が置き換えますか？

WordPress プラグイン	機能	Next.js での置き換え
Yoast SEO	メタタグ、サイトマップ、スキーマ	next-seo + カスタム sitemap.xml ルート
WP Rocket	キャッシング、圧縮	Vercel Edge Cache + Next.js 組み込み
Contact Form 7	フォーム処理	React Hook Form + API ルートまたは Formspree
Wordfence	セキュリティ	不要（管理画面サーフェスがない）
WPML	多言語対応	next-intl またはビルトイン i18n ルーティング
WooCommerce	e-コマース	Shopify Storefront API または Saleor
Advanced Custom Fields	カスタムコンテンツモデル	ヘッドレス CMS のコンテンツモデリング
Redirection	URL リダイレクト	next.config.js リダイレクトまたは Vercel 設定
WP Cron	スケジュールタスク	Vercel Cron Jobs または別のサービス
Imagify	画像最適化	next/image と Vercel Image Optimization

コンテンツインベントリ

コンテンツをカウントして分類します：

SELECT post_type, post_status, COUNT(*) 
FROM wp_posts 
GROUP BY post_type, post_status;

カスタム投稿タイプ、タクソノミー用語、ユーザープロフィール、メニュー構造、ウィジェット設定、およびオプション値を忘れないでください。その「シンプルな」WordPress サイトはおそらくあなたが思っているより多くのコンテンツタイプを持っています。

URL マッピング

すべての URL をエクスポートします。本当に、すべてです。Screaming Frog またはシンプルなサイトマップクロールを使用します：

curl -s https://yoursite.com/sitemap_index.xml | \
grep -oP '<loc>\K[^<]+' | \
xargs -I {} curl -s {} | \
grep -oP '<loc>\K[^<]+' > all-urls.txt

このファイルは金です。リダイレクトマッピング、SEO 保全、移行後の QA テストに使用します。

WordPress to Next.js Migration on Vercel: A 2026 Guide - architecture

ヘッドレス CMS バックエンドの選択

コンテンツを保存および管理する場所が必要です。2026 年の最も一般的な 3 つのパス：

オプション 1：ヘッドレス CMS としての WordPress

はい、WordPress をバックエンドとして保持し、Next.js をフロントエンドとして使用できます。WPGraphQL（現在 v2.1）はこれを驚くほど実行可能にします。エディタは使い慣れた管理インターフェイスを保持します。最新のフロントエンドを取得します。

// lib/wordpress.js
const API_URL = process.env.WORDPRESS_GRAPHQL_URL;

export async function getPostBySlug(slug) {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `
        query PostBySlug($slug: ID!) {
          post(id: $slug, idType: SLUG) {
            title
            content
            date
            featuredImage {
              node {
                sourceUrl
                altText
              }
            }
            seo {
              title
              metaDesc
              opengraphImage {
                sourceUrl
              }
            }
          }
        }
      `,
      variables: { slug },
    }),
    next: { revalidate: 60 },
  });
  const json = await res.json();
  return json.data.post;
}

欠点？あなたは依然として WordPress インストールを保守する必要があります。セキュリティ更新、PHP バージョン管理、データベースバックアップ — それはすべてあなたのプレートに留まります。そして、あなたは依然として WordPress ホスティング用に支払っています。

オプション 2：目的別ビルド型ヘッドレス CMS

これは、ほとんどの移行に対して推奨するものです。コンテンツを API ファーストの配信のために一から構築された CMS に移動します。

CMS	2026 年の料金	最適な用途	コンテンツモデリング	API タイプ
Sanity	フリーティア、$15/ユーザー/月 Pro	複雑なコンテンツ、リアルタイムコラボレーション	優秀、コード定義	GROQ + GraphQL
Contentful	フリーティア、$300/月 Team	エンタープライズ、大規模チーム	良好、UI 定義	REST + GraphQL
Storyblok	フリーティア、€106/月 Business	ビジュアル編集、コンポーネント	素晴らしい、ビジュアル	REST + GraphQL
Strapi v5	フリー（セルフホスト）、クラウド $29/月から	完全なコントロール、オープンソース	柔軟、UI 定義	REST + GraphQL
Payload CMS 3.0	フリー（セルフホスト）	コードファースト希望の開発者	優秀、コード定義	REST + GraphQL

あなたのチームが Social Animal で移行を処理している場合、通常は Sanity または Payload を推奨します — 開発者にコンテンツモデリングに対する最大の制御を与えながら、エディタを満足させます。

オプション 3：リポジトリ内の Markdown/MDX

開発者ブログとドキュメンテーションサイトの場合、コンテンツを Git リポジトリ内の MDX ファイルとして保存することが最も簡単なアプローチです。管理する CMS がなく、API 呼び出しがなく、コンテンツはコードと一緒にバージョン管理されます。ただし、これはコンテンツエディタが Git ワークフローに快適である場合にのみ機能します。

コンテンツ移行戦略

WordPress からのエクスポート

ビルトイン WordPress エクスポート（ツール → エクスポート）は XML ファイルを提供します。それは始まりですが、乱雑です。構造化された移行のために、カスタム WP-CLI スクリプトを使用します：

// export-content.php
<?php
$posts = get_posts([
    'post_type' => ['post', 'page', 'your_custom_type'],
    'posts_per_page' => -1,
    'post_status' => 'publish',
]);

$export = [];
foreach ($posts as $post) {
    $export[] = [
        'id' => $post->ID,
        'title' => $post->post_title,
        'slug' => $post->post_name,
        'content' => apply_filters('the_content', $post->post_content),
        'excerpt' => $post->post_excerpt,
        'date' => $post->post_date,
        'modified' => $post->post_modified,
        'author' => get_the_author_meta('display_name', $post->post_author),
        'categories' => wp_get_post_categories($post->ID, ['fields' => 'names']),
        'tags' => wp_get_post_tags($post->ID, ['fields' => 'names']),
        'featured_image' => get_the_post_thumbnail_url($post->ID, 'full'),
        'acf' => function_exists('get_fields') ? get_fields($post->ID) : [],
        'yoast' => [
            'title' => get_post_meta($post->ID, '_yoast_wpseo_title', true),
            'description' => get_post_meta($post->ID, '_yoast_wpseo_metadesc', true),
        ],
    ];
}

file_put_contents('export.json', json_encode($export, JSON_PRETTY_PRINT));

コンテンツの変換

WordPress コンテンツは Gutenberg ブロックマークアップを含む HTML として保存されます。決定する必要があります：HTML を保持してレンダリングするか、CMS の構造化形式に変換するか？

Sanity の場合、@sanity/block-tools を使用して HTML を Portable Text に変換します。Contentful の場合、それらの移行 CLI は豊富なテキスト変換を処理します。どちらにしても、コンテンツのクリーンアップに時間をかけてください — WordPress コンテンツは [shortcodes]、インラインスタイル、および修正が必要な破損した HTML でいっぱいです。

// migrate-to-sanity.js
import { htmlToBlocks } from '@sanity/block-tools';
import { JSDOM } from 'jsdom';
import { Schema } from '@sanity/schema';

const schema = Schema.compile({ /* your schema */ });
const blockContentType = schema.get('post')
  .fields.find(f => f.name === 'body').type;

function convertPost(wpPost) {
  return {
    _type: 'post',
    title: wpPost.title,
    slug: { current: wpPost.slug },
    publishedAt: wpPost.date,
    body: htmlToBlocks(
      wpPost.content,
      blockContentType,
      { parseHtml: (html) => new JSDOM(html).window.document }
    ),
  };
}

画像移行

これをスキップしないでください。WordPress から wp-content/uploads のすべての画像をダウンロードし、CMS または CDN（Cloudinary、Vercel Blob Storage、S3）に再度アップロードし、すべてのコンテンツ参照を更新します。通常、私は以下を行うスクリプトを書きます：

エクスポート JSON で画像 URL をクロール
各画像をダウンロード
新しいストレージにアップロード
URL マッピングファイルを作成
すべてのコンテンツで検索と置換を実行

Next.js 15 でのフロントエンド再構築

Next.js 15（2024 年後半に安定化、2026 年現在 15.2）はデフォルトで App Router を使用します。以下は、コンテンツが豊富なサイトに使用する構造です：

app/
├── layout.tsx          # フォント、分析を含むルートレイアウト
├── page.tsx            # ホームページ
├── blog/
│   ├── page.tsx        # ページネーションを備えたブログリスト
│   └── [slug]/
│       └── page.tsx    # 個別ブログポスト
├── [slug]/
│   └── page.tsx        # ジェネリックページ
├── sitemap.ts          # 動的サイトマップ生成
├── robots.ts           # robots.txt
└── not-found.tsx       # カスタム 404

ISR を使用した静的生成

ほとんどのコンテンツページでは、段階的静的再生成は甘い場所です — 動的な新鮮さを持つ静的パフォーマンス：

// app/blog/[slug]/page.tsx
import { getPostBySlug, getAllPostSlugs } from '@/lib/cms';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const slugs = await getAllPostSlugs();
  return slugs.map((slug) => ({ slug }));
}

export async function generateMetadata({ params }) {
  const post = await getPostBySlug(params.slug);
  if (!post) return {};
  return {
    title: post.seo?.title || post.title,
    description: post.seo?.description || post.excerpt,
    openGraph: {
      images: [post.featuredImage?.url],
    },
  };
}

export const revalidate = 3600; // 1 時間ごとに再検証

export default async function BlogPost({ params }) {
  const post = await getPostBySlug(params.slug);
  if (!post) notFound();

  return (
    <article className="prose lg:prose-xl">
      <h1>{post.title}</h1>
      <time dateTime={post.date}>{formatDate(post.date)}</time>
      <PostBody content={post.body} />
    </article>
  );
}

リアルタイム更新が必要なサイト（ニュース、ライブコンテンツ）の場合、CMS からのウェブフックトリガー経由でオンデマンド再検証を使用します。ほとんどのヘッドレス CMS プラットフォームはコンテンツ公開時のウェブフックトリガーをサポートしています。

URL 構造と SEO の保全

これは非交渉です。URL 構造を失うと、検索ランキングを失います。ピリオド。

リダイレクトマップ

WordPress は /2024/03/post-slug/ または /category/term/ などの URL パターンを使用します。Next.js サイトは /blog/post-slug を使用する可能性があります。リダイレクトマップを作成します：

// next.config.js
module.exports = {
  async redirects() {
    return [
      // 日付ベースの URL をクリーンなスラッグに
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      // カテゴリー アーカイブ
      {
        source: '/category/:slug',
        destination: '/blog?category=:slug',
        permanent: true,
      },
      // ページネーション
      {
        source: '/page/:num',
        destination: '/blog?page=:num',
        permanent: true,
      },
      // フィード URL
      {
        source: '/feed',
        destination: '/rss.xml',
        permanent: true,
      },
    ];
  },
};

大規模なサイト（1000+ リダイレクト）の場合、Vercel の vercel.json 設定またはミドルウェアの代わりに使用します — next.config.js リダイレクトには、ビルド時間が低下し始める前に約 1024 エントリのソフト制限があります。

構造化データ

Yoast などの WordPress プラグインは JSON-LD を自動生成します。これを複製する必要があります：

// components/structured-data.tsx
export function ArticleSchema({ post }) {
  const schema = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    datePublished: post.date,
    dateModified: post.modified,
    author: {
      '@type': 'Person',
      name: post.author,
    },
    image: post.featuredImage?.url,
    publisher: {
      '@type': 'Organization',
      name: 'Your Site Name',
      logo: { '@type': 'ImageObject', url: '/logo.png' },
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

XML サイトマップ

Next.js 15 はダイナミックサイトマップを簡単にします：

// app/sitemap.ts
import { getAllPosts, getAllPages } from '@/lib/cms';

export default async function sitemap() {
  const posts = await getAllPosts();
  const pages = await getAllPages();

  return [
    { url: 'https://yoursite.com', lastModified: new Date() },
    ...pages.map((page) => ({
      url: `https://yoursite.com/${page.slug}`,
      lastModified: page.modified,
    })),
    ...posts.map((post) => ({
      url: `https://yoursite.com/blog/${post.slug}`,
      lastModified: post.modified,
    })),
  ];
}

Vercel へのデプロイ：実際に機能する設定

プロジェクトセットアップ

npx create-next-app@latest my-migrated-site --typescript --tailwind --app
cd my-migrated-site
vercel link

環境変数

これらを Vercel のダッシュボードで設定します。.env ファイルに Git にコミットしないでください：

CMS_API_URL=https://your-cms-api-endpoint
CMS_API_TOKEN=your-read-only-token
REVALIDATION_SECRET=a-random-string-for-webhook-auth
SITE_URL=https://yoursite.com

Vercel 設定

// vercel.json
{
  "crons": [
    {
      "path": "/api/revalidate-sitemap",
      "schedule": "0 */6 * * *"
    }
  ],
  "headers": [
    {
      "source": "/fonts/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
      ]
    }
  ]
}

オンデマンド再検証ウェブフック

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');
  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ error: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const { slug, type } = body;

  if (type === 'post') {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // リスティングも再検証
  } else {
    revalidatePath(`/${slug}`);
  }

  return NextResponse.json({ revalidated: true });
}

CMS ウェブフックを https://yoursite.com/api/revalidate にポイントし、シークレットヘッダーを追加します。これで、コンテンツ更新は完全な再構築なしで数秒以内に表示されます。

パフォーマンスベンチマーク：移行前後

これらは 2025～2026 年に Social Animal で完了した移行からの実数です：

メトリック	WordPress（WP Engine）	Next.js（Vercel）	改善
Lighthouse パフォーマンス	62～78	95～100	+30～40%
最大コンテンツフルペイント	2.8～4.2 秒	0.8～1.4 秒	60～70% 高速化
最初のバイトまでの時間	800ms～1.5s	50～120ms	90%+ 高速化
累積レイアウトシフト	0.12～0.25	0.01～0.05	~80% 削減
月額ホスティング費用	平均 $115/月	$20～40/月	60～80% 削減
ビルド時間（500 ページ）	N/A（動的）	45～90 秒	N/A
ページ/秒（ISR）	15～30 req/s	エッジから 10,000+	数桁大きい

TTFB の改善だけで移行の価値があります。WordPress はすべてのページを PHP と MySQL を通じて生成します。Vercel は事前にレンダリングされたページを世界中 300 以上の場所のエッジノードから提供します。

よくある移行のピットフォール

ピットフォール 1：WordPress RSS フィードを忘れる。 人々がフィードを購読している場合、/feed/ と /rss/ を新しい RSS エンドポイントにリダイレクトします。Next.js はデフォルトではフィードを生成しません — カスタムルートが必要です。

ピットフォール 2：WordPress ショートコードを見逃す。 WordPress からエクスポートされたコンテンツは [gallery]、[embed]、およびプラグイン固有のショートコードに満ちています。これらを解析および変換しない場合、プレーンテキストとしてレンダリングされます。コンテンツが使用する各ショートコードタイプのトランスフォーマーを作成します。

ピットフォール 3：WordPress コメントデータを無視する。 価値があるコメントスレッドがある場合は、Disqus などのサービスに移行するか、カスタムコメントシステムを構築します。ほとんどの人はコメントをドロップしますが、最初にステークホルダーに確認してください。

ピットフォール 4：内部リンクをテストしていない。 WordPress コンテンツは絶対 URL（https://yoursite.com/old-path/）を使用した内部リンクでいっぱいです。これらを相対パスまたはあなたの新しい URL 構造に更新する必要があります。移行中にシンプルな正規表現検索と置換がほとんどの場合を処理します。

ピットフォール 5：wp-content/uploads 参照を忘れる。 画像を移行した後でも、古いコンテンツは /wp-content/uploads/2024/03/image.jpg パスを参照する可能性があります。キャッチオールリダイレクトを設定するか、これらを新しい画像 CDN にプロキシします。

これが圧倒的に感じる場合、実際には正常です。適切な移行には、サイトの複雑さに応じて 4～12 週間かかります。経験豊かな手がプロジェクトに参加してほしい場合は、お問い合わせください。

FAQ

WordPress から Next.js への移行はどのくらい時間がかかりますか？

100～500 ページを持つサイトの場合、専任の開発者で 4～8 週間を期待してください。カスタム投稿タイプ、e-コマース、または多言語コンテンツを備えたより大規模なサイトは、8～16 週間かかる可能性があります。コンテンツ移行自体は通常、作業の 20% です — その他の 80% は、テンプレートの再構築、エッジケースの処理、およびすべての URL の QA テストです。

移行中に Google ランキングを失いますか？

いいえ、リダイレクトを正しく処理すれば。URL が変更される可能性があるすべてのの 301 リダイレクトを実装し、メタタイトルとメタ説明を保持し、新しいサイトマップを Google Search Console に送信し、ドメインが変更される場合は [住所の変更] ツールを使用します。Google がより優れた Core Web Vitals を認識するため、2～4 週間の小さなランキング変動を期待し、その後回復または改善します。

WordPress を Next.js との CMS として使用し続けることができますか？

絶対にそうです。これは「ヘッドレス WordPress」と呼ばれ、それは人気のあるアプローチです。WPGraphQL を使用してコンテンツを API として公開し、Next.js から使用します。エディタは知っている WordPress 管理を保持します。主な欠点は、あなたはまだ WordPress インストールを維持します — セキュリティ更新、ホスティング、スタック全体。

WordPress から Next.js への移行の費用はいくらかかりますか？

DIY（開発者 1 人）：100～300 時間の作業。エージェンシー移行：複雑さに応じて通常 $15,000～$75,000。継続的なホスティング費用は通常減少します — Vercel Pro（月 $20/ユーザー）対マネージド WordPress ホスティング（月 $50～$300）。ROI は削減されたホスティング費用、より優れたパフォーマンス（コンバージョンレートを改善する）、および低いメンテナンスオーバーヘッドから来ます。

Next.js 15 で Pages Router または App Router を使用する必要があります。

App Router、完全に停止します。2026 年の時点では、App Router は Server Components、ストリーミング、および並列ルートを備えた安定したデフォルトです。Pages Router はまだ機能し、廃止されていませんが、新しい機能と最適化は App Router ファースト。Social Animal で行うすべての移行は App Router のみを使用します。

フォームと動的機能はどうですか？

Next.js API ルート（または App Router 内のサーバーアクション）は、フォーム送信、検索、認証、およびすべてのサーバー側ロジックを処理します。コンタクトフォームの場合、Resend などのサービスで Server Actions を使用できます。検索の場合、Algolia または Meilisearch を検討してください。認証の場合、NextAuth.js（現在 Auth.js v5）はほとんどのユースケースをカバーしています。

Vercel は Next.js をホストする唯一のオプションですか？

いいえ。Netlify、AWS Amplify、Cloudflare Pages、または Node.js でセルフホストで Next.js をデプロイできます。ただし、Vercel は Next.js チームによって構築されており、統合が表示されます — ISR、エッジミドルウェア、画像最適化、および分析はすべて Vercel で最適に機能します。2026 年では、Vercel と代替手段の間の DX ギャップは狭まっていますが、Vercel は依然として最も摩擦の少ないパスです。

WooCommerce ストアを移行する必要がある場合はどうなりますか？

これはより大きなプロジェクトです。ほとんどのチームは、ストアフロントを Next.js に移行し、コマースバックエンドを Shopify（Storefront API を使用）、Medusa.js、または Saleor に移動します。Shopify の Hydrogen フレームワークは別のオプションですが、フロントエンドに対する完全な制御が必要な場合は、Shopify の API を使用した Next.js が最も実績のあるパスです。e-コマース移行がタイムラインに 4～8 週間追加されることを期待します。

WordPress から Next.js への移行ガイド Vercel 2026

目次

2026 年に WordPress から Next.js に移行する理由

移行前の監査：WordPress が実際に何をしているのか

プラグインインベントリ

コンテンツインベントリ

URL マッピング

ヘッドレス CMS バックエンドの選択

オプション 1：ヘッドレス CMS としての WordPress

オプション 2：目的別ビルド型ヘッドレス CMS

オプション 3：リポジトリ内の Markdown/MDX

コンテンツ移行戦略

WordPress からのエクスポート

コンテンツの変換

画像移行

Next.js 15 でのフロントエンド再構築

ISR を使用した静的生成

URL 構造と SEO の保全

リダイレクトマップ

構造化データ

XML サイトマップ

Vercel へのデプロイ：実際に機能する設定

プロジェクトセットアップ

環境変数

Vercel 設定

オンデマンド再検証ウェブフック

パフォーマンスベンチマーク：移行前後

よくある移行のピットフォール

FAQ

WordPress から Next.js への移行はどのくらい時間がかかりますか？

移行中に Google ランキングを失いますか？

WordPress を Next.js との CMS として使用し続けることができますか？

WordPress から Next.js への移行の費用はいくらかかりますか？

Next.js 15 で Pages Router または App Router を使用する必要があります。

フォームと動的機能はどうですか？

Vercel は Next.js をホストする唯一のオプションですか？

WooCommerce ストアを移行する必要がある場合はどうなりますか？

Let's build
something together.

目次

2026 年に WordPress から Next.js に移行する理由

移行前の監査：WordPress が実際に何をしているのか

プラグイン インベントリ

コンテンツ インベントリ

URL マッピング

ヘッドレス CMS バックエンドの選択

オプション 1：ヘッドレス CMS としての WordPress

オプション 2：目的別ビルド型ヘッドレス CMS

オプション 3：リポジトリ内の Markdown/MDX

コンテンツ移行戦略

WordPress からのエクスポート

コンテンツの変換

画像移行

Next.js 15 でのフロントエンド再構築

ISR を使用した静的生成

URL 構造と SEO の保全

リダイレクト マップ

構造化データ

XML サイトマップ

Vercel へのデプロイ：実際に機能する設定

プロジェクト セットアップ

環境変数

Vercel 設定

オンデマンド再検証ウェブフック

パフォーマンスベンチマーク：移行前後

よくある移行のピットフォール

FAQ

WordPress から Next.js への移行はどのくらい時間がかかりますか？

移行中に Google ランキングを失いますか？

WordPress を Next.js との CMS として使用し続けることができますか？

WordPress から Next.js への移行の費用はいくらかかりますか？

Next.js 15 で Pages Router または App Router を使用する必要があります。

フォームと動的機能はどうですか？

Vercel は Next.js をホストする唯一のオプションですか？

WooCommerce ストアを移行する必要がある場合はどうなりますか？

Let's build something together.

プラグインインベントリ

コンテンツインベントリ

リダイレクトマップ

プロジェクトセットアップ

Let's build
something together.