遅いWordPressメンバーシップサイトを修正: ヘッドレス再構築ガイド
あなたの遅いWordPressメンバーシップサイトを修正する：ヘッドレス再構築ガイド
メンバーシップサイトのオーナーから同じ話を何度も聞いてきました：「WordPressで立ち上げたのは良かったのですが、今は痛いほど遅いです」。彼らは何もかも試しました――キャッシュプラグイン、CDN、ホスティングのアップグレード、プラグインを1つずつ無効化。一部は役に立ちました。ほとんどは役に立ちませんでした。そして本当の厳しい現実は？メンバーが去っていくのです。コンテンツが悪いわけではなく、レッスンページを読み込むのに6秒待つことで、月額$49の価値があるのか疑問に思わせられるからです。
それが当てはまるなら、この記事はあなたのためのものです。WordPressのメンバーシップサイトがパフォーマンスの壁に当たる理由、再構築なしで実際に修正できることは何か、そしていつ（そしてどのように）ヘッドレスに移行するかについて、正確に説明します。WordPressをコンテンツのバックエンドとして使用し、実際に高速な最新フロントエンドを備えています。
目次
- WordPressメンバーシップサイトが遅くなる理由
- 実際のパフォーマンス数値
- 再構築なしで修正できますか？
- ヘッドレス再構築が意味を持つとき
- ヘッドレスメンバーシップサイトのアーキテクチャ
- フロントエンドフレームワークの選択
- 認証とアクセス制御
- 移行プロセス ステップバイステップ
- パフォーマンス結果：ビフォー・アフター
- コストとタイムラインの期待
- FAQ
WordPressメンバーシップサイトが遅くなる理由
正直に言いましょう。典型的なWordPressメンバーシップサイトは単なるWordPressではありません。WordPress + MemberPress（またはRestrict Content Pro、WooCommerce Memberships）+ ページビルダー + LMSプラグイン + コミュニティプラグイン + フォームプラグイン + アナリティクス + おそらく他に15～25個のプラグイン。それぞれがデータベースクエリを追加します。それぞれがCSSとJavaScriptファイルを読み込みます。そして、それらは複合的に作用します。
典型的なメンバーシップサイトでのリクエストは次のようになります：
- ユーザーがページにアクセス
- PHPがリクエストを処理（WordPressコア）
- メンバーシッププラグインがユーザーがアクセス権を持っているか確認（データベースクエリ）
- アクセスが許可されたら、コンテンツを取得（さらにデータベースクエリ）
- ページビルダーがレイアウトを組み立て（さらにクエリ）
- LMSプラグインが進捗をチェックし、完了をマーク（さらにクエリ）
- すべてのプラグインCSSやJSファイルが読み込み――このページで必要ないものでも
- レンダリングされたHTMLがようやくブラウザに到達
昨年監査したメンバーシップサイトの単一のレッスンページは、147個のデータベースクエリを作成し、43個の個別のCSS/JSファイルを読み込んでいました。ページのサイズは4.2MBでした。共有ホスティングでは、そのページを読み込むのに7.8秒かかりました。
プラグインの税金
すべてのWordPressプラグインは本質的に実行パイプラインへのフックです。適切に書かれたプラグインでも、オーバーヘッドを追加します。しかし、メンバーシッププラグインはすべてのページロードでパーミッションをチェックするために実行されるため、特に高コストです。たとえば、MemberPressはtemplate_redirect、the_content、およびいくつかの他のフィルターにフックします。それを500以上の保護されたページと数千のアクティブなメンバーを持つサイト全体で乗算すると、サーバーはすべてのリクエストで深刻な作業を行っています。
データベースの問題
WordPressはすべてをデータベースに保存します。ユーザーメタ、投稿メタ、メンバーシップレベル、コース進捗、トランザクション履歴――すべてがwp_options、wp_usermeta、wp_postmetaに存在します。これらのテーブルは、メンバーシップサイトが生成するデータの量のために設計されていません。10,000人以上のメンバーを持つコース進捗データに達すると、これらのテーブルが拡大し、クエリが遅くなります。
メンバーシップサイトのwp_usermetaテーブルに200万以上の行があるのを見かけたことがあります。適切なインデックス作成がない場合（そしてWordPressのデフォルトスキーマはmeta_valueをインデックスしません）、単純な検索でも痛いほど遅くなります。
実際のパフォーマンス数値
これに対してデータを入れましょう。WordPressメンバーシップサイトから監査したCore Web Vitalsと、ヘッドレス再構築後に見られるものの比較は次のとおりです：
| メトリック | WordPress + メンバーシップ プラグイン | ヘッドレス再構築（Next.js） | Googleのターゲット |
|---|---|---|---|
| Largest Contentful Paint（LCP） | 4.2 - 8.1s | 0.8 - 1.4s | < 2.5s |
| Interaction to Next Paint（INP） | 280 - 450ms | 40 - 90ms | < 200ms |
| Cumulative Layout Shift（CLS） | 0.15 - 0.38 | 0.01 - 0.04 | < 0.1 |
| Time to First Byte（TTFB） | 1.2 - 3.8s | 50 - 200ms | < 0.8s |
| ページ総サイズ | 2.8 - 5.2MB | 180 - 400KB | < 2MB |
| HTTPリクエスト | 45 - 90+ | 8 - 15 | < 60 |
これは理論上の数値ではありません。実際のプロジェクトからのものです。その差は驚くべきものであり、それはあなたの収益に直接影響します。
Elementorの研究によると、WordPressサイトの40.5%のみがすべての3つのCore Web Vitalsを通ります。その追加プラグイン負荷を持つメンバーシップサイトの場合？その数字は大幅に減少します。一方、Next.jsサイトは約55%の通過率をはじめから備えており――適切な最適化で、それをはるかに高く押し上げることができます。
そして最も重要なビジネスケース：モバイルでの0.1秒の速度改善により、Deloitteの調査によると小売コンバージョン率が8.4%増加します。月額$49を請求するメンバーシップサイトの場合、より高速なページロードからのチャーン削減でも、数か月以内に再構築の資金が調達されます。
再構築なしで修正できますか？
妥当な質問です。そして正直な答えは：時々、そうです。完全なヘッドレス再構築にコミットする前に、試すべきものはここにあります：
実際に役に立つクイックウィン
PHPを8.3以上にアップグレード。 これだけで、パフォーマンスを20～30%向上させることができます。ダッシュボード → ツール → サイトヘルス → 情報 → サーバーでバージョンを確認します。PHP 7.4をまだ使用している場合、無料のパフォーマンステーブルにいます。
高品質ホスティングに切り替え。 共有ホスティングを使用している場合は、マネージドWordPressホスティング（Cloudways、Kinsta、WP Engine）に移行します。月額$10ではなく$50～150を予算化します。これは、ほとんどの人ができる単一の最大の改善です。
オブジェクトキャッシュをインストール。 RedisまたはMemcached。これはデータベースクエリ結果をメモリにキャッシュし、メモリはメモリが大量のメンバーシップサイトにとって大きなため。
// wp-config.php - Redisオブジェクトキャッシュを有効にする
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
未使用のプラグインを削除し、ページごとにスクリプトを無効にします。 Asset CleanUpまたはPerfmattersを使用して、それらが不要なページでプラグインCSSやJSを無効にします。これだけでページごとに10～20個のHTTPリクエストを削除できます。
データベースを最適化します。 期限切れのトランジェントを削除し、投稿の改訂をクリアし、自動読み込みオプションを最適化します：
-- 自動読み込みデータサイズを確認（1MB未満である必要があります）
SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload = 'yes';
-- 最大の犯人を見つける
SELECT option_name, LENGTH(option_value) as size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;
これらの修正が十分でない場合
ここに問題があります：すべてのこれらの最適化は、根本的なアーキテクチャ上の問題への絆創膏です。あなたはまだすべてのリクエストでPHPを実行しています。あなたはまだパーミッションをチェックするためにMySQLデータベースにクエリを送信しています。あなたはまだWordPressコア――すべての70,000以上の行――を読み込んでいます、単一のバイトの実際のコンテンツが提供される前に。
メンバーシップサイトが1,000人未満のメンバーと200未満のコンテンツを持っている場合、上記の最適化はあなたを受け入れられるパフォーマンスに到達させるかもしれません。しかし、あなたが成長するなら――そして成長は推定されるべき目的です――あなたは同じ壁に再び当たるでしょう。
ヘッドレス再構築が意味を持つとき
ヘッドレス再構築は誰にとって正しい動きではありません。ここにそれが意味を持つ場合があります：
- 1,000人以上のアクティブメンバーを持っています、そして成長するにつれてパフォーマンスが低下しています
- コンテンツチームはWordPressに満足しています、コンテンツ管理のため（彼らはサイトがどれだけ遅いかを嫌うだけです）
- 複数のプラットフォーム全体でサイトを動作させる必要があります――web、モバイルアプリ、おそらくパートナーのためのAPI
- あなたのCore Web Vitalsが失敗しています、そしてそれはSEOとコンバージョンに影響を与えています
- 既に試した上記の最適化手順と収穫逓減に当たっています
- より多くの時間を費やしています、ビジネスの構築よりもWordPressと戦っています
そしてここが意味を持たない場合です：
- あなたは小さなサイトとは限られた予算を持つ単独の作成者です
- コンテンツチームはすべてのページに対してビジュアルページビルダーなしで動作することはできません
- 分離されたアーキテクチャを保持できる開発者（またはエージェンシー）がありません
- パフォーマンス問題は実際には悪いホスティングだけです
ヘッドレスメンバーシップサイトのアーキテクチャ
実際のアーキテクチャに入りましょう。ここはヘッドレスメンバーシップサイトのようにみえるものです：
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ WordPress │ │ Next.js │ │ CDN │
│ （バックエンド）│────▶│ （フロントエンド）│────▶│ （Vercel/CF） │
│ │ API │ │ │ │
│ - コンテンツ │ │ - SSR/SSGページ │ │ - エッジキャッシング │
│ - ユーザーデータ │ │ - 認証処理 │ │ - グローバル配布 │
│ - メンバーシップ │ │ - アクセス制御 │ │ │
│ - WP REST API │ │ - コース進捗 │ │ │
│ またはWPGraphQL │ │ │ │ │
└─────────────────┘ └──────────────────┘ └─────────────────┘
コンテンツレイヤー
WordPressはCMSとして留まります。コンテンツチームはチームが知っているエディタを使い続けます。WP REST API（組み込み）またはWPGraphQL（このユースケースでははるかに優れています）を通じてコンテンツを公開します。WPGraphQLを強くお勧めします――複数のREST呼び出しを行う代わりに、単一のリクエストで必要なデータをフェッチできます。
# そのコースとアクセス要件を持つレッスンを取得
query GetLesson($slug: String!) {
lessonBy(slug: $slug) {
title
content
lessonFields {
duration
videoUrl
requiredMembershipLevel
}
course {
node {
title
slug
lessons {
nodes {
title
slug
}
}
}
}
}
}
認証レイヤー
ここはそれが興味深い場所です。伝統的なWordPressメンバーシップサイトでは、認証はクッキーとwp_get_current_user()によって処理されます。ヘッドレスセットアップでは、適切なトークンベースの認証システムが必要です。
通常は、2つのアプローチのいずれかを使用します：
- JWT認証――WordPressはログイン時にJWTを発行し、フロントエンドはそれを保存し、APIリクエストで送信します
- **NextAuth.jsをWordPressプロバイダとして――より柔軟で、ソーシャルログインをサポート、より良いセッション管理
ほとんどのメンバーシップサイトでは、オプション2が優れています：
// app/api/auth/[...nextauth]/route.ts
import NextAuth from 'next-auth'
import CredentialsProvider from 'next-auth/providers/credentials'
export const authOptions = {
providers: [
CredentialsProvider({
name: 'WordPress',
credentials: {
username: { label: 'Email', type: 'email' },
password: { label: 'Password', type: 'password' },
},
async authorize(credentials) {
const res = await fetch(
`${process.env.WP_URL}/wp-json/jwt-auth/v1/token`,
{
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
username: credentials?.username,
password: credentials?.password,
}),
}
)
const user = await res.json()
if (res.ok && user) {
return {
id: user.user_id,
name: user.user_display_name,
email: user.user_email,
token: user.token,
}
}
return null
},
}),
],
}
アクセス制御レイヤー
ヘッドレスセットアップでのアクセス制御は、フロントエンドレイヤーで発生します。フロントエンドは、保護されたコンテンツをレンダリングする前にユーザーのメンバーシップレベルをチェックします。これは実際には、保護されたコンテンツが決してブラウザに送信されなかったため、伝統的なWordPressよりもセキュアです――SSR中にサーバーレベルでゲート化されます。
// middleware.ts - メンバーシップルートをエッジで保護
import { withAuth } from 'next-auth/middleware'
export default withAuth({
callbacks: {
authorized: ({ token, req }) => {
const path = req.nextUrl.pathname
if (path.startsWith('/courses/')) {
return token?.membershipLevel === 'premium' ||
token?.membershipLevel === 'lifetime'
}
if (path.startsWith('/community/')) {
return !!token
}
return true
},
},
})
export const config = {
matcher: ['/courses/:path*', '/community/:path*', '/dashboard/:path*'],
}
フロントエンドフレームワークの選択
特にメンバーシップサイトに対して、主なオプションがどのように積み重なるかはこちらです：
| フレームワーク | 最適な用途 | SSRサポート | 認証の話 | 学習曲線 |
|---|---|---|---|---|
| Next.js（App Router） | コンテンツ更新が頻繁な動的メンバーシップサイト | 優れている | NextAuth.jsは成熟している | 中程度 |
| Astro | 最小限の相互作用を持つコンテンツに富んだサイト | 良い（ハイブリッド） | より多くのDIYが必要 | より低い |
| Remix | 複雑なユーザー相互作用、フォーム豊富なサイト | 優れている | 組み込みパターン | 中程度 |
| SvelteKit | より小さいバンドルサイズを望むチーム | 優れている | 成長しているエコシステム | 中程度 |
ほとんどのメンバーシップサイトでは、Next.jsが正しい選択です。それは静的コンテンツ（マーケティングページ、ブログ投稿）と動的コンテンツ（ダッシュボード、コース進捗、コミュニティ機能）の組み合わせをそれ以上に処理します。App RouterとReact Server Componentsは、データフェッチコードをブラウザに出荷することなく、サーバーでデータをフェッチできます。
私たちはNext.js開発の多くを特別にこの種のプロジェクトのために行います。あなたのサイトがコンテンツに豊富で、コミュニティ機能のない相互作用動的な場合――コミュニティ機能のないコンテンツライブラリメンバーシップについて考えてください――Astroはさらに高速であり、デフォルトでゼロのJavaScriptを出荷するためです。
認証とアクセス制御
メンバーシップティアを処理
ほとんどのメンバーシップサイトは複数のティアを持っています。無料、基本、プレミアム、多分生涯ティア。ヘッドレスアーキテクチャでは、メンバーシップデータをWordPressに保存し、フロントエンドのセッションに同期します。
フローは次のようなもの：
- ユーザーがログイン → フロントエンドはWordPressに対して認証 → JWTが発行されます
- JWTにメンバーシップレベルクレームが含まれます
- フロントエンドミドルウェアはすべての保護されたルートでこれらのクレームをチェック
- コンテンツはユーザーが正しいアクセスレベルを持っている場合のみWordPress APIから取得
- セッションはメンバーシップの変更をキャッチするために定期的に更新されます（アップグレード、有効期限切れ、キャンセル）
支払い統合
Stripeが標準です。2つのオプションがあります：
- WordPressでStripe統合を保つ、MemberPressまたはWooCommerce Subscriptionsを使用して、メンバーシップステータスをフロントエンドに同期します
- Stripeをフロントエンドに移動、Stripe Checkoutとウェブフックを使用して、WordPressをデータストアとしてです
オプション2は長期的にはより清潔です。Stripe Checkoutはコンプライアンスを処理し、Next.js APIルートでウェブフックを処理できます：
// app/api/webhooks/stripe/route.ts
import Stripe from 'stripe'
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)
export async function POST(req: Request) {
const body = await req.text()
const sig = req.headers.get('stripe-signature')!
const event = stripe.webhooks.constructEvent(
body,
sig,
process.env.STRIPE_WEBHOOK_SECRET!
)
switch (event.type) {
case 'customer.subscription.created':
case 'customer.subscription.updated':
// REST APIを通じてWordPressのメンバーシップレベルを更新
await updateWordPressMembership(event.data.object)
break
case 'customer.subscription.deleted':
// 無料層にダウングレード
await revokeMembership(event.data.object)
break
}
return new Response('OK', { status: 200 })
}
移行プロセス ステップバイステップ
実際の移行プロセスです。これは理論的ではありません――それはヘッドレスCMS再構築に使用するプレイブックです。
フェーズ1：監査とアーキテクチャ（週1～2）
- 現在のサイトパフォーマンスを監査（Lighthouse、WebPageTest、実際のユーザーメトリクス）
- すべてのコンテンツタイプ、メンバーシップティア、ユーザーフローをマッピング
- あらゆる統合（支払い処理者、メールサービス、アナリティクス等）を記述
- ヘッドレスアーキテクチャを設計
- WPGraphQLと カスタムタイプを設定
フェーズ2：バックエンド準備（週2～3）
- WPGraphQLをインストールして構成
- メンバーシップデータのカスタムGraphQLフィールドを作成
- 認証用のカスタムREST エンドポイントを構築
- JWT認証をセットアップ
- すべてのAPIエンドポイントを完全にテスト
フェーズ3：フロントエンド構築（週3～6）
- App RouterでNext.jsプロジェクトをスカフォール
- 認証フローを実装
- ページテンプレートを構築（マーケティングページ、コースページ、レッスンページ、ダッシュボード）
- アクセス制御ミドルウェアを実装
- Stripe統合を構築
- メンバーダッシュボードを構築
フェーズ4：テストと移行（週6～8）
- パフォーマンステストと最適化
- クロスブラウザとデバイステスト
- 実際のメンバーとのユーザー受け入れテスト
- DNS移行と起動
- 起動後最初の2週間のパフォーマンスを監視
パフォーマンス結果：ビフォー・アフター
2026年初期に再構築したメンバーシップサイトからの実例です。サイトは約8,000人のアクティブメンバー、12のコースにまたがる400以上のレッスン、およびコミュニティフォーラムを持っていました。
| メトリック | 以前（WordPress + MemberPress + LearnDash） | 後（Next.js + WordPressヘッドレス） |
|---|---|---|
| LCP（モバイル） | 6.2s | 1.1s |
| INP | 380ms | 65ms |
| CLS | 0.24 | 0.02 |
| TTFB | 2.8s | 85ms |
| Lighthouseパフォーマンス | 28 | 96 |
| ページサイズ（レッスンページ） | 3.8MB | 290KB |
| 月間チャーン率 | 8.2% | 5.1%（再構築後3ヶ月） |
その唯一のチャーン削減――8.2%から5.1%――は、この特定のサイトに対して月額およそ$14,000の保持された収益を表していました。再構築は3ヶ月以内で自身の代金を支払いました。
コストとタイムラインの期待
コストについて透明にしましょう。ヘッドレス再構築は安くはありませんが、ROIを考慮した場合、ほとんどの人が仮定するほど高くもありません。
| プロジェクト範囲 | タイムライン | 予算範囲 |
|---|---|---|
| シンプルメンバーシップ（1～2ティア、コンテンツライブラリのみ） | 6～8週間 | $15,000 - $30,000 |
| 中程度のメンバーシップ（複数ティア、コース、進捗追跡） | 8～12週間 | $30,000 - $60,000 |
| 複雑なメンバーシップ（コース、コミュニティ、ゲーミフィケーション、モバイル） | 12～20週間 | $60,000 - $120,000+ |
比較として、伝統的なWordPressアプローチにはプレミアムプラグインを使用すると、最初は$3,000～$10,000ですが、ホスティングアップグレード、プラグインライセンス（$500～1,500/年）、およびパフォーマンス低下との絶え間ない戦いに累積する継続的なコストが発生します。
あなたの特定のサイトに対するヘッドレス再構築がどのように見えるかについて話し合いたい場合は、無料のアーキテクチャコンサルテーションを提供しています。ピッチデックなし、ただあなたの状況に対して意味があるかどうかについての正直な会話。
価格ページで一般的なエンゲージメント構造も確認できます。
FAQ
コンテンツチームは新しいCMSを学ぶ必要がありますか？
いいえ、そしてこれはヘッドレスWordPressアプローチの最大の利点の1つです。コンテンツチームは、彼らが今日しているように、まったく同じようにWordPressを使い続けます。彼らは同じ管理パネルにログイン、同じエディタを使用し、同じ方法でコンテンツを管理します。唯一の違いは、訪問者が見るフロントエンド――最新のフレームワークで構築されていることです。チームはワークフローの変化に気づくことはありません。
ヘッドレスメンバーシップサイトでSEOはどのように機能しますか？
Next.jsとサーバーサイドレンダリングを使用すると、検索エンジンは伝統的なWordPressサイトから受け取るのと同じ完全にレンダリングされたHTMLを受け取ります。実際、それはより良いです――ページはより高速に読み込まれるため、Core Web Vitalsが改善され、Googleはランキング信号としてそれらを使用します。サイトマップの生成とメタタグをNext.jsレイヤーで処理する必要がありますが、next-seoのようなフレームワークはこれを簡単にします。通常、ヘッドレス移行後4～6週間以内にサイトが検索ランキングで改善されるのを見かけます。
支払いのためにMemberPressまたはWooCommerceを使い続けることはできますか？
できますが、支払い処理をフロントエンドのStripeに直接移動することをお勧めします。それはより清潔で、より保守しやすく、チェックアウト体験をより好きにコントロールできます。あなたがMemberPressとそのビリング設定を変更したくない深く統合されている場合、WordPressside上にそれを保つことができ、メンバーシップステータスをAPIを通じてフロントエンドに同期します。それは動作し、追加のレイヤーを維持するだけです。
WordPressバックエンドがダウンする場合はどうなりますか？
これは実際には、ヘッドレスに移行することの利点の1つです。静的生成を公開ページに使用している場合、それらのページはCDNでキャッシュされ、WordPressが完全にオフラインの場合でもサービスを受け続けます。動的ページ（ダッシュボード、コース進捗）は影響を受けます、しかしあなたは、キャッシュされたコンテンツを表示するか、メンテナンスメッセージを表示する優雅なエラー処理を実装できます。伝統的なWordPressセットアップでは、WordPressがダウンする場合、すべてがダウンします。
メンバーのみコンテンツをAPIで公開されないようにするにはどうすればよいですか？
これは重大なセキュリティの懸念です。保護されたコンテンツを公開APIエンドポイントで公開しないでください。保護されたコンテンツは認証されたAPIリクエストを通じてのみアクセス可能であるべきです。WPGraphQLでは、アクセス制御ルールを使用できます。これはコンテンツを返す前に、リクエストしているユーザーのメンバーシップレベルをチェックします。その後、フロントエンドはこれらのリクエストをサーバー側で行うために認証されたユーザーのJWTを使用するため、コンテンツはユーザーが許可されていない限りブラウザにはまったく当たりません。
ヘッドレスWordPressはホストするのにより高価ですか？
WordPressバックエンドは実際により安く、完全なページをレンダリングするのではなくAPIレスポンスを提供するだけなので、ホストするのがより廉価です。フロントエンド（Vercel's Proプランは月額$20/チームメンバー、またはVPS上で自分でホストできる）のホスティングコストを追加します。総ホスティングコストは通常同じか、わずかに高いですが、パフォーマンス改善は劇的です。多くのチームは、WordPressが直接トラフィックを処理していないため、WordPressホスティングをダウングレードできることに気づいています。
完全再構築ではなく段階的に移行できますか？
はい、そしてアプローチを時々お勧めします。公開ページ（マーケティング、ブログ）をヘッドレスフロントエンドとして構築し、メンバー領域を伝統的なWordPressに保つことで開始できます。その後、メンバーダッシュボード、その後コース、その後コミュニティを移行します。これはリスクを低減し、移行に完全にコミットする前にアプローチを検証させます。Next.jsミドルウェアは、移行中に特定のパスをWordPress インストールにプロキシするのを簡単にします。
ダウンタイムなしでどのくらい移行に時間がかかりますか？
ゼロダウンタイム移行は標準的な慣行です。既存のサイトが実行を続けている間、新しいフロントエンド全体を構築します。すべてがテストされ、準備ができたら、DNSレコードを新しいフロントエンドを指すように更新します。スイッチオーバーは分かかり、問題が発生した場合、DNSを直ちにロールバックできます。通常、安全なネットとして機能する旧WordPressフロントエンドを2～4週間並行して実行しています。