WordPress to Next.js 移行

私は 1 ダースを超える WordPress サイトを本番環境で Next.js に移行してきましたが、皆さんを驚かせるかもしれませんが、実際のコード移行は難しい部分ではありません。難しいのは切り替え (cutover) です。スイッチを入れて何も壊れないことを祈る、その恐ろしい瞬間です。良いニュースは？正しいプレイブックがあれば、その瞬間を退屈なものにできます。そして、運用では、退屈こそまさに求められることです。

これが Social Animal で本番環境の切り替えに使用するプレイブックです。理論的ではなく、実際の移行から構築されたものです。実際の収益が関わっていました。1 日 $50K のe コマースサイト、月間数百万ページビューのコンテンツパブリッシャー、5 分のダウンタイムが CEO の携帯電話に電話が来ることを意味する SaaS マーケティングサイトについて話しています。

ゼロダウンタイムが思っているより重要な理由
移行アーキテクチャの概要
フェーズ 1: コンテンツ移行と API レイヤー
フェーズ 2: Next.js アプリケーションの構築
フェーズ 3: 並行デプロイメント設定
フェーズ 4: ブルーグリーンデプロイメント設定
フェーズ 5: DNS 切り替え戦略
フェーズ 6: 切り替えチェックリスト
フェーズ 7: 切り替え後の監視とロールバック
一般的な障害モードとその防止方法
よくある質問

Zero Downtime CMS Migration: WordPress to Next.js Cutover Playbook

ゼロダウンタイムが思っているより重要な理由

数字で示しましょう。Google の 2024 年の調査では、ページ読み込み時間が 1 秒遅れると、およそ 7% のコンバージョンが失われます。今、あなたのサイトが単に...消えていると想像してください。たった 5 分間でも。

実際の危険にさらされているのは以下の通りです:

ダウンタイム期間	収益への影響 (1 日 $10K のサイト)	SEO への影響	ユーザー信頼への影響
5 分	~$35 の損失	隔離されていれば最小限	低
30 分	~$208 の損失	Googlebot が気づくかもしれない	中程度
2 時間	~$833 の損失	GSC でクロールエラー	高
24 時間	$10,000+ の損失	インデックス削除のリスク	深刻

しかし、それは収益だけではありません。検索エンジンは常にクロールしています。移行中に Googlebot があなたのサイトにアクセスして 500 エラーを取得した場合、それらの URL は数時間以内にインデックスから削除される可能性があります。「昼食時に簡単な移行を行った」ために、有機トラフィックの 40% を失ったサイトを見てきました。

目標はゼロダウンタイムだけではありません。遷移中にユーザーと検索エンジンに見えないゼロの変更です。

移行アーキテクチャの概要

フェーズに入る前に、対象としているアーキテクチャを見てみましょう。基本的なパターンは両方のシステムを並行して実行し、トラフィックをアトミックにシフトさせることです。

                    ┌─────────────────┐
                    │   Cloudflare /   │
                    │   Load Balancer  │
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    │  Traffic Router  │
                    │  (weight-based)  │
                    └────┬───────┬────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  WordPress  │ │   Next.js   │
              │  (Blue)     │ │   (Green)   │
              │  Origin     │ │   on Vercel │
              └──────────┬──┘ └──┬──────────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  MySQL DB   │ │ Headless CMS │
              │             │ │ (Sanity/etc) │
              └─────────────┘ └─────────────┘

重要な洞察: フロントエンドだけを移行しているのではありません。コンテンツレイヤー、レンダリングレイヤー、配信レイヤーを移行しており、それぞれを独立して移行できます。

フェーズ 1: コンテンツ移行と API レイヤー

ここが多くのチームが間違える場所です。彼らは最初に Next.js フロントエンドを構築しようとし、その後コンテンツを後で把握します。これをしないでください。コンテンツから始めてください。

ヘッドレス CMS の選択

WordPress コンテンツには新しい場所が必要です。選択肢は移行の複雑さに大きく影響します:

CMS	WP からの移行の容易さ	リアルタイム同期が可能	価格 (2025)	最適な用途
Sanity	高 (構造化コンテンツがうまくマップされる)	はい、ウェブフック経由	無料枠、その後 $99/月	複雑なコンテンツモデル
Contentful	中程度 (フィールドマッピングが必要)	はい	$300/月チーム向け	エンタープライズチーム
Strapi	高 (DB バックアップモデルに類似)	はい	自家ホスト無料、クラウド $29/月から	完全なコントロール
WordPress REST API	N/A (ヘッドレスとして保持)	既に同期済み	既存ホスティングコスト	迅速な勝利
Payload CMS	高	はい	自家ホスト無料	デベロッパーファーストチーム

私たちはヘッドレス CMS 開発機能ページでヘッドレス CMS の選択を詳しくカバーしていますが、簡潔に言うと、ほとんどの WordPress 移行では、Sanity または Payload CMS が最良の移行パスを提供します。

コンテンツ同期の設定

重要な部分はこれです。並行実行フェーズでは、両方のシステムにコンテンツが存在する必要があります。戦略が 2 つあります:

戦略 A: ワンタイム移行 + フリーズ すべてのコンテンツを新しい CMS に移行してから、WordPress 編集をフリーズします。小規模サイトの場合は機能しますが、エディターが引き続き公開する必要がある場合は機能しません。

戦略 B: 継続的な同期 (推奨) WordPress の変更を新しい CMS にほぼリアルタイムで複製する同期パイプラインを設定します。

// 例: WordPress ウェブフック ハンドラー で Sanity に同期
// これはサーバーレス関数 (Vercel/AWS Lambda) として実行されます

import { createClient } from '@sanity/client';

const sanity = createClient({
  projectId: process.env.SANITY_PROJECT_ID,
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2025-01-01',
  useCdn: false,
});

export async function POST(request) {
  const payload = await request.json();
  const { post_id, post_title, post_content, post_status } = payload;

  if (post_status !== 'publish') return new Response('Skipped', { status: 200 });

  try {
    await sanity.createOrReplace({
      _id: `wp-${post_id}`,
      _type: 'post',
      title: post_title,
      body: convertGutenbergToPortableText(post_content),
      migratedFrom: 'wordpress',
      wpId: post_id,
      _updatedAt: new Date().toISOString(),
    });

    return new Response('Synced', { status: 200 });
  } catch (error) {
    console.error('Sync failed:', error);
    return new Response('Sync error', { status: 500 });
  }
}

WordPress 側も必要です。save_post で実行されるシンプルなプラグインを使用します:

// wp-content/plugins/headless-sync/headless-sync.php
add_action('save_post', function($post_id, $post) {
    if (wp_is_post_revision($post_id)) return;
    
    wp_remote_post(SYNC_ENDPOINT_URL, [
        'body' => json_encode([
            'post_id' => $post_id,
            'post_title' => $post->post_title,
            'post_content' => $post->post_content,
            'post_status' => $post->post_status,
        ]),
        'headers' => [
            'Content-Type' => 'application/json',
            'X-Sync-Secret' => SYNC_SECRET,
        ],
    ]);
}, 10, 2);

切り替え前に少なくとも 2 週間この同期を実行してください。エッジケースをキャッチしたいのです - 奇妙なショートコード、カスタム投稿タイプ、うまくマップされていない ACF フィールド。

Zero Downtime CMS Migration: WordPress to Next.js Cutover Playbook - architecture

フェーズ 2: Next.js アプリケーションの構築

ここで Next.js ビルドプロセス全体をカバーするつもりはありません - それは独自の記事に値します (そして私たちは Next.js 開発で深い専門知識を持っています)。しかし、ゼロダウンタイムに関連する移行固有の懸念があります。

URL パリティは交渉の余地がありません

WordPress サイトに存在するすべての URL が、Next.js サイトで同じコンテンツに解決される必要があります。すべて、です。

つまり:

/blog/my-post-slug/ が機能する必要があります (WordPress が使用した場合は末尾のスラッシュを含む)
/category/technology/ が機能またはリダイレクトする必要があります
/wp-content/uploads/2024/03/image.jpg は新しい画像 CDN にリダイレクトされる必要があります
/feed/ は有効な RSS/Atom を引き続き返す必要があります
/blog/page/2/ のようなページネーション URL が機能する必要があります

早期に URL 監査スクリプトを構築してください:

# WP-CLI を使用して WordPress URL をすべてエクスポート
wp post list --post_type=post,page --post_status=publish \
  --fields=ID,post_name,post_type,guid --format=csv > urls.csv

# SEO プラグインからリダイレクトも取得
wp db query "SELECT * FROM wp_redirection_items" --format=csv > redirects.csv

その後、それらを Next.js ビルドに対して検証してください:

// validate-urls.mjs
import { readFileSync } from 'fs';
import { parse } from 'csv-parse/sync';

const urls = parse(readFileSync('./urls.csv'), { columns: true });
const NEXT_BASE = 'https://staging.yoursite.com';

for (const row of urls) {
  const res = await fetch(`${NEXT_BASE}/${row.post_name}/`, {
    redirect: 'manual'
  });
  
  if (res.status >= 400) {
    console.error(`BROKEN: /${row.post_name}/ → ${res.status}`);
  }
}

パフォーマンスベースライン

切り替え前に、Next.js サイトは少なくとも WordPress と同じくらい高速である必要があります。明白に聞こえますが、新しいスタックに興奮したチームがベンチマークを忘れるのを見てきました。

CrUX データまたは Lighthouse CI を使用して WordPress サイトから Core Web Vitals をキャプチャし、それらに一致するか上回ってください。WordPress サイトの LCP が 2.1s で Next.js サイトが 3.4s の場合、準備ができていません。

フェーズ 3: 並行デプロイメント設定

ここでゼロダウンタイムを可能にするインフラストラクチャに到達します。

並行実行

両方のシステムが同時に実行され、実トラフィックを提供します。しかし、いずれかの時点では、1 つだけが「プライマリ」です。

Vercel 上の Next.js (私たちの最も一般的なセットアップ) の場合、next.yoursite.com のようなカスタムドメインに Next.js アプリをデプロイするか、Vercel のプレビュー URL を使用します。WordPress サイトは yoursite.com で実行され続けます。

# Nginx をリバース プロキシとして使用している場合
# これは並行実行設定です

upstream wordpress {
    server wordpress-origin.internal:80;
}

upstream nextjs {
    server next-yoursite.vercel.app:443;
}

server {
    listen 443 ssl;
    server_name yoursite.com;

    # 並行実行中: トラフィックを両方にミラーしますが、
    # WordPress からの応答を提供
    location / {
        mirror /mirror;
        proxy_pass http://wordpress;
    }

    location = /mirror {
        internal;
        proxy_pass https://nextjs$request_uri;
    }
}

このミラー設定は、すべてのリクエストを両方のバックエンドに送信しますが、WordPress レスポンスのみを返します。ユーザーに見られることなく、実トラフィックが Next.js アプリにアクセスします。Next.js ログでエラー、404、遅いレスポンスをチェックしてください。

合成監視

両方のシステムが同等のコンテンツを返すことを継続的に検証する監視を設定します:

// canary-check.mjs — 5 分ごとに実行 (cron 経由)
const CRITICAL_URLS = [
  '/',
  '/blog/',
  '/about/',
  '/contact/',
  '/blog/most-popular-post/',
];

for (const path of CRITICAL_URLS) {
  const [wpRes, nextRes] = await Promise.all([
    fetch(`https://yoursite.com${path}`),
    fetch(`https://next.yoursite.com${path}`),
  ]);

  if (wpRes.status !== nextRes.status) {
    alert(`Status mismatch on ${path}: WP=${wpRes.status} Next=${nextRes.status}`);
  }

  // コンテンツパリティチェックとしてタイトルタグを比較
  const wpTitle = (await wpRes.text()).match(/<title>(.*?)<\/title>/)?.[1];
  const nextTitle = (await nextRes.text()).match(/<title>(.*?)<\/title>/)?.[1];

  if (wpTitle !== nextTitle) {
    alert(`Title mismatch on ${path}`);
  }
}

アラートがなくなるまで最小 1 週間実行してから、切り替えに進みます。

フェーズ 4: ブルーグリーンデプロイメント設定

ブルーグリーンデプロイメントとは、2 つの同一の本番環境 - ブルー (現在の WordPress) とグリーン (新しい Next.js) - を持ち、それらの間を原子的に切り替えることを意味します。

トラフィックルーティングに Cloudflare Workers を使用

これは DNS 伝播遅延なく即座でグローバルなトラフィック切り替えを提供するため、推奨されるアプローチです。

// Cloudflare Worker ブルーグリーン ルーティング用
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // KV ストアからアクティブ環境を読み取ります
    const activeEnv = await env.CONFIG.get('active_environment') || 'blue';
    
    // オプション: パーセンテージベースのカナリア ルーティング
    const canaryPercent = parseInt(await env.CONFIG.get('canary_percent') || '0');
    const useGreen = activeEnv === 'green' || 
                     (canaryPercent > 0 && Math.random() * 100 < canaryPercent);
    
    const origin = useGreen
      ? 'https://next-yoursite.vercel.app'
      : 'https://wp-origin.yoursite.com';
    
    const originUrl = new URL(url.pathname + url.search, origin);
    
    const response = await fetch(originUrl, {
      method: request.method,
      headers: {
        ...Object.fromEntries(request.headers),
        'Host': new URL(origin).hostname,
        'X-Forwarded-Host': url.hostname,
      },
      body: request.method !== 'GET' ? request.body : undefined,
    });
    
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Served-By', useGreen ? 'green-nextjs' : 'blue-wordpress');
    
    return newResponse;
  }
};

このアプローチの美しさ: WordPress から Next.js への切り替えは単一の KV ストア書き込みです。DNS の変更なし。伝播なし。即座。

# グリーン (Next.js) に切り替え
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "green"

# 何か問題が発生した場合はブルー (WordPress) にロールバック
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "blue"

カナリアルーティング

トラフィックの 100% を一度に切り替えないでください。カナリアで始めてください:

Next.js へ 1% のトラフィック — 1 時間エラーをチェック
10% トラフィック — 2 時間監視
50% トラフィック — 4 時間監視
100% トラフィック — 24 時間監視
WordPress の廃止 — 100% で 1 週間後

フェーズ 5: DNS 切り替え戦略

Cloudflare Workers (または同様のエッジルーティングソリューション) を使用できない場合、DNS レベルで切り替えを処理する必要があります。TTL 伝播のため、これはより複雑です。

切り替え前の DNS 準備

切り替え前に少なくとも 48 時間:

DNS TTL を 60 秒に下げる (典型的な 3600 または 86400 から)
古い TTL が期限切れになるまで待ちます
低い TTL がアクティブであることを確認: dig yoursite.com +short は TTL ~60 を表示する必要があります

# 現在の TTL をチェック
dig yoursite.com A +noall +answer
# 以下のようなものを表示する必要があります:
# yoursite.com.  60  IN  A  76.76.21.21

DNS スイッチ

60 秒の TTL では、DNS A/CNAME レコードを更新することは、約 5 〜 10 分でのグローバル伝播を意味します (一部のリゾルバーは低い TTL を無視しますが、ほとんどは 2025 年に尊重します)。

# Vercel に移動する場合
# CNAME を cname.vercel-dns.com を指すように更新
# または A レコードを Vercel の IP アドレスに更新: 76.76.21.21

ハマる点: SSL 証明書のタイミング

ここで人々が困っています。DNS を Vercel (または任意の新しいホスト) に切り替えるとき、新しいホストのドメインに対する SSL 証明書は切り替え前にプロビジョニングされる必要があります。それ以外の場合は、HTTPS が機能しない期間が発生します。

Vercel では、DNS スイッチの前にプロジェクト設定にカスタムドメインを追加します。Vercel は HTTP-01 または DNS-01 チャレンジを使用して証明書のプロビジョニングを試みます。Cloudflare プロキシ DNS を使用している場合、証明書プロビジョニングが機能するようにプロキシを一時的に無効にする必要がある場合があります (オレンジクラウド → グレークラウド)。

フェーズ 6: 切り替えチェックリスト

これが切り替え当日に使用するチェックリストです。印刷してください。すべてのボックスをチェックしてください。

切り替え前 (T-24 時間)

すべてのコンテンツが新しい CMS に同期され、確認されている
URL パリティ検証 100% パス
SSL 証明書が新しいホストでプロビジョニングされている
DNS TTL が 60 秒で確認されている
ロールバック手順が文書化されテストされている
WordPress SEO プラグインからのすべてのリダイレクトが next.config.js またはエッジミドルウェアに移行されている
robots.txt と sitemap.xml が Next.js で正しく生成されている
アナリティクス追跡が Next.js で確認されている (GA4、GTM など)
フォーム送信がエンドツーエンドでテストされている
RSS フィードが検証されている
OpenGraph タグが主要ページで確認されている
404 ページがテストされている

切り替え (T-0)

ステークホルダーに通知: 「移行開始」
カナリアを 1% に設定 → 30 分監視
10% に増加 → 1 時間監視
Google Search Console でクロールエラーをチェック
50% に増加 → 2 時間監視
100% に増加
更新されたサイトマップを Google Search Console に送信
Googlebot がすべての重要なページにアクセスできることを確認 (URL 検査ツールを使用)
すべてのフォーム、e コマースフロー、認証フローをテスト

切り替え後 (T+24 時間)

CrUX ダッシュボードで Core Web Vitals を監視
Google Search Console のカバレッジ問題をチェック
すべてのアナリティクスデータが正しく流れていることを確認
WordPress オリジンがまだ実行中 (最小 2 週間保持)
Screaming Frog で新しいサイトに対してフルサイトクロールを実行

フェーズ 7: 切り替え後の監視とロールバック

監視対象

監視ツール (Vercel Analytics、Datadog、Google Search Console の組み合わせを使用) でダッシュボードをセットアップし、以下を追跡:

エラーレート: 5xx レスポンスはありますか? 4xx に上昇はありますか?
応答時間: P50、P95、P99 レイテンシ
Core Web Vitals: LCP、FID/INP、CLS
Search Console: クロール統計、カバレッジレポート、インデックス作成ステータス
ビジネス指標: コンバージョン率、バウンス率、セッションあたりのページ数

ロールバック計画

ロールバックは単一のコマンドである必要があります。15 ステップのプロセスではありません。1 つのコマンド。

Cloudflare Worker アプローチを使用:

# 単一のコマンド ロールバック
wrangler kv:key put --namespace-id=$NS_ID "active_environment" "blue"

DNS ベースの切り替えを使用:

# Cloudflare API 経由のスクリプト化 DNS ロールバック
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"content": "old-wordpress-ip-address"}'

切り替え後、少なくとも 2 週間 WordPress を実行し続けてください。ヒーローになろうとしないでください。WordPress をシャットダウンする瞬間が、移行を忘れたページを発見する瞬間です。

一般的な障害モードとその防止方法

これを何十回も行った後、最も見られる障害は次のとおりです:

1. フロントエンドルートを持つ忘れられた WordPress プラグイン そのコンタクトフォームプラグインは /wp-json/contact-form-7/ エンドポイントを作成します。その WooCommerce インストールには /my-account/ と /cart/ があります。すべてのプラグインの URL フットプリントをマップしてください。

2. コンテンツ内にハードコードされた wp-content URL コンテンツ内の画像は /wp-content/uploads/ を参照しています。新しいアセット CDN を指すリダイレクトまたは書き換えルールが必要です。

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/wp-content/uploads/:path*',
        destination: 'https://cdn.yoursite.com/uploads/:path*',
        permanent: true,
      },
    ];
  },
};

3. XML サイトマップの忘却 Google Search Console は /sitemap.xml を指しています。Next.js アプリはそれを生成する必要があります。next-sitemap を使用するか、アプリのルートハンドラーで構築してください。

4. 認証とセッションの問題 WordPress サイトにログインユーザーがいる場合、彼らのクッキーは新しいスタックで機能しません。ユーザー移行を個別に計画してください。

5. 切り替え中の CDN キャッシュ中毒 Cloudflare がレスポンスをキャッシュしている場合、Next.js に切り替えた後に古い WordPress ページを提供する場合があります。切り替え直後に CDN キャッシュをパージしてください。

# 切り替え後に Cloudflare キャッシュ全体をパージ
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

移行を計画していて、専門家に重い負荷を任せたい場合は、価格ページをチェックするか、直接ご連絡ください。私たちはこれを十分に行ったので、プレイブックはすべての正しい方法で実戦で傷ついています。

他のフレームワークで構築されたサイトの場合、Astro ベースの移行も行っています。これは、多くのインタラクティビティを必要としないコンテンツの多いサイトでさらに高速です。

よくある質問

WordPress から Next.js への移行には通常どのくらいかかりますか? 中程度の複雑さのサイト (100 〜 500 ページ、カスタム投稿タイプ、動的機能) の場合、エンドツーエンドで 8 〜 12 週間を計画してください。コンテンツ移行と並行実行フェーズだけで 3 〜 4 週間かかります。正しい準備ができていれば、実際の切り替えは約 4 時間のアクティブ作業です。誰かがこれが週末にできると言うなら信じないでください。

コンテンツを移行する代わりに、WordPress をヘッドレス CMS として使用できますか? 絶対に、そしていくつかのチームにとってこれは正しい呼び出しです。WordPress を CMS として保持し、REST API または WPGraphQL を使用してコンテンツを Next.js に供給し、フロントエンドのみを移行します。コンテンツ移行フェーズをスキップするため、移行のタイムラインが大幅に削減されます。トレードオフは、すべての更新とセキュリティオーバーヘッドを含む WordPress インストールをまだ維持しているということです。

移行中に SEO ランキングはどうなりますか? 正しいゼロダウンタイム移行では、ランキングは安定した状態を保つはずです。Google の John Mueller は、コンテンツ、URL、技術的な SEO 要素が同等のままであれば、CMS を変更してもランキングに影響しないことを確認しています。最大のリスクは、壊れた URL (404 を引き起こす)、変更された内部リンク構造、低下したページ速度です。プレイブックは 3 つすべてに特に対応します。

Next.js で WordPress フォームをどのように処理しますか? いくつかのオプションがあります: Formspree または Basin のようなフォームサービスを使用、Next.js で送信を直接処理する API ルートを構築、またはヘッドレス CMS のフォーム機能を使用 (Sanity はネイティブフォームを持っていませんが、Payload CMS は持っています)。条件付きロジックのある複雑なフォームの場合、通常カスタム API ルートを構築し、フロントエンドで React Hook Form を使用します。

Next.js デプロイメントには Vercel、Netlify、または自家ホストを使用すべきですか? ほとんどのチームにとって、Vercel は Next.js の最小抵抗のパスです。同じチームによって構築され、ISR、ミドルウェア、画像最適化などの機能がそこで最適に機能します。Vercel の Pro プランは月額 $20/ユーザーで、ほとんどの本番環境のニーズに対応します。特定のコンプライアンス要件があるか AWS に留まる必要がある場合、standalone 出力モードで自家ホストできます。Netlify も機能しますが、歴史的に Next.js 機能サポートの後ろにあります。

ブルーグリーンデプロイメントとカナリアデプロイメントの違いは何ですか? ブルーグリーンはバイナリです: すべてのトラフィックが古いシステム (ブルー) または新しいシステム (グリーン) のいずれかに流れます。カナリアデプロイメントは、古いシステムから新しいシステムへのトラフィックをゆっくりシフトさせます。実際には、両方を組み合わせます。ブルーグリーンインフラストラクチャ (2 つの完全な環境) をセットアップしますが、実際の切り替え時にカナリア風のパーセンテージベースのルーティングを使用します。これにより、段階的なロールアウトの安全性と、2 つの環境のみを管理する単純さが得られます。

WordPress リダイレクトを Next.js に移行するにはどうすればよいですか? WordPress プラグイン (Redirection、Yoast、RankMath) からリダイレクトをエクスポートします。それらを next.config.js の Next.js リダイレクト形式に変換します。数百のリダイレクトを持つサイトの場合は、代わりにミドルウェアを使用してください - より高いパフォーマンスであり、パターンマッチングを処理できます。next.config.js リダイレクトは Vercel でビルド時間が苦しむ前に約 1,000 エントリの実用的な制限があることに注意してください。

切り替え後に WordPress にロールバックできますか? はい、これは交渉の余地がありません。切り替え後、少なくとも 2 週間 WordPress インスタンスを実行し続けてください。Cloudflare Worker アプローチを使用すると、ロールバックは数秒でグローバルに有効になる単一の API 呼び出しです。DNS ベースの切り替えを使用すると、ロールバックには TTL 伝播に応じて 1 〜 10 分かかります。新しいシステムが安定している確認されるまで、古いシステムを廃止しないでください。

ゼロダウンタイムCMS移行: WordPress to Next.js カットオーバープレイブック

目次

ゼロダウンタイムが思っているより重要な理由

移行アーキテクチャの概要

フェーズ 1: コンテンツ移行と API レイヤー

ヘッドレス CMS の選択

コンテンツ同期の設定

フェーズ 2: Next.js アプリケーションの構築

URL パリティは交渉の余地がありません

パフォーマンスベースライン

フェーズ 3: 並行デプロイメント設定

並行実行

合成監視

フェーズ 4: ブルーグリーンデプロイメント設定

トラフィックルーティングに Cloudflare Workers を使用

カナリアルーティング

フェーズ 5: DNS 切り替え戦略

切り替え前の DNS 準備

DNS スイッチ

ハマる点: SSL 証明書のタイミング

フェーズ 6: 切り替えチェックリスト

切り替え前 (T-24 時間)

切り替え (T-0)

切り替え後 (T+24 時間)

フェーズ 7: 切り替え後の監視とロールバック

監視対象

ロールバック計画

一般的な障害モードとその防止方法

よくある質問

Let's build
something together.

目次

ゼロダウンタイムが思っているより重要な理由

移行アーキテクチャの概要

フェーズ 1: コンテンツ移行と API レイヤー

ヘッドレス CMS の選択

コンテンツ同期の設定

フェーズ 2: Next.js アプリケーションの構築

URL パリティは交渉の余地がありません

パフォーマンス ベースライン

フェーズ 3: 並行デプロイメント設定

並行実行

合成監視

フェーズ 4: ブルーグリーン デプロイメント設定

トラフィック ルーティングに Cloudflare Workers を使用

カナリア ルーティング

フェーズ 5: DNS 切り替え戦略

切り替え前の DNS 準備

DNS スイッチ

ハマる点: SSL 証明書のタイミング

フェーズ 6: 切り替えチェックリスト

切り替え前 (T-24 時間)

切り替え (T-0)

切り替え後 (T+24 時間)

フェーズ 7: 切り替え後の監視とロールバック

監視対象

ロールバック計画

一般的な障害モードとその防止方法

よくある質問

Let's build something together.

パフォーマンスベースライン

フェーズ 4: ブルーグリーンデプロイメント設定

トラフィックルーティングに Cloudflare Workers を使用

カナリアルーティング

Let's build
something together.