「WordPressを静的HTMLへ書き出す」ことは簡単な部分です——すでにいくつかのプラグインがそれをやってくれます。この移行が成功するかどうかを本当に左右するのは、純粋なコンテンツページではないものすべてに何が起こるかです：コメント、サイト内検索、問い合わせフォーム、そして（ストアを運営しているなら）WooCommerceの価格とカート。対策のない静的書き出しは、これらすべてを直接壊してしまいます。

単純な静的書き出しが壊すもの

  • コメント——静的ファイル上ではPHPが動いておらず、コメントの送信を受け付けられません。
  • 検索——WordPressの検索は1回のデータベースクエリです；静的サイトには問い合わせるデータベースがありません。
  • 問い合わせフォーム——フォームプラグインは、静的出力上にはもう存在しないPHP処理エンドポイントへ送信しようとします。
  • WooCommerceの価格、在庫、カート——リクエスト時点で最新である必要のあるものは、数時間前、あるいは数日前に生成された静的ファイルには焼き込めません。

解決策：放棄するのではなくプロキシする

実行可能な方法は、WordPressのインストールを今まさに動いている通りに——同じホスト、同じデータベース、同じプラグインで——動かし続け、本当に本物のWordPressに到達する必要のある少数のリクエストを除いて、すべてをエッジから静的に提供することです。静的サイトの前段にあるルーター（Pinery StaticではCloudflare Workerを使用）が受信リクエストを検査し、コメントの送信、検索クエリ、フォームの投稿、WooCommerceの価格／カートリクエストを、本物のWordPressバックエンドへ静かに転送し、通常のページ読み込みはすべて静的書き出しから即座に提供されます。

移行手順、おおよその順序

  1. WordPressのバックエンドをそのままの場所に残す。 これをホスティング移行の一部にしないでください——バックエンドは稼働し続け、プロキシが実際に対話する相手になります。
  2. 完全な静的書き出しを実行し、公開前に出力結果に明らかな問題がないか確認します——これが欠落ページや不正な形式のURLを早期に発見するタイミングです。
  3. 静的出力を、あなた自身が管理するCloudflare Pagesプロジェクトへデプロイします。
  4. プロキシルーターを前段に配置し、動的リクエストが静的な404にぶつかるのではなくWordPressへ転送されるようにします。
  5. ドメインを新しいデプロイへ向けます——理想的にはダウンタイムなしの同一ドメイン移行パスを使います。
  6. その後は差分方式で再書き出しします。 コンテンツを公開・更新するたびに、変更されたページだけを再書き出しすればよく、サイト全体をやり直す必要はありません。

完了後に得られるもの

CDNエッジから提供される静的ページは、WordPressが直接提供できるどの方法よりも速くなります——PHP実行なし、データベースクエリなし、リクエストごとのプラグインのオーバーヘッドなし——一方でコメント、検索、フォーム、ストア機能は、ネイティブではなくプロキシ経由になるだけで、これまでどおり動作します。これがアフィリエイトのコンバージョン率にとってなぜ重要かについてはパフォーマンスガイドを、静的書き出しツールを一般的に比較検討しているならSimply StaticとWP2Staticとの比較もご覧ください。