なぜすべてのサイトに同じ技術が使えないのか
WordPressは、ブログから会員サイト、EC（電子商取引）サイトまで同じ仕組みで作れます。柔軟な代わりに、どの用途でも、閲覧のたびにデータベースへ問い合わせる作りと、本体とプラグインの更新を追い続ける必要が付いてきます。用途によっては、そのどちらも要らないことがあります。
リプレースで基盤を選ぶときは、サイトが扱うデータの性質を先に見ます。閲覧者ごとに表示が切り替わるか、更新の頻度はどれくらいか。ここを決めないまま構成を選ぶと、公開したあとで作り直すことになります。
用途に合わせた2つの移行先
当方が案内する移行先は2つです。ただし「Astroは静的だけ、Laravelは動的だけ」という分け方ではありません。AstroはCloudflare上でサーバー側の処理も動かせます。Cloudflareは公式資料で、専用のサーバーを立てずにサーバー側のコードを動かせること、その用途として認証やフォーム送信の処理を挙げています。
分かれ目は、動的処理があるかどうかではありません。会員、注文、予約のように閲覧者ごとに内容が変わる仕組みを、サイトの中で扱うかどうかです。フォームや小規模なAPI（別の仕組みとデータをやり取りする窓口）で足りる範囲なら、作り置きの構成に外部サービスを足して収まります。会員機能、EC、予約をサイトの中で扱う場合は、データと画面が結びつくため、Laravel の側で作り直す範囲になります。
- 閲覧が中心のサイト: Astro + Cloudflare：コーポレートサイト、オウンドメディア、採用サイトなど、閲覧者ごとに表示内容が変わらないサイトに向きます。静的サイトジェネレーター（ページを事前に作り置きする道具）の『Astro』で、公開の準備をするときに全ページをHTMLファイルへ書き出し、Cloudflare Pages などの配信網（CDN：利用者に近い配信拠点からファイルを返す仕組み）から配信します。閲覧のたびにサーバーでプログラムを動かさないため、公開側で更新を追う対象が減ります。表示にかかる時間は、画像や外部から読み込むスクリプトの量でも変わるため、構成しだいです。
- 会員、注文、予約をサイトの中で扱うサイト: Laravel：会員マイページ、閲覧者どうしのマッチング、予約管理、データベースと頻繁にやり取りする条件検索などがあるサイトに向きます。PHP（Webサイトを動かすプログラムの処理系）の開発フレームワーク（Webアプリを作るための部品の集まり）『Laravel』で、必要な機能だけを作ります。プラグインを組み合わせて作らないため、プラグインどうしの相性で起きる不具合はなくなります。代わりに、作った分のコードを自社で保守する対象として抱えます。
技術選定マトリクス
当方が想定する標準の構成で比べた場合の違いです。標準の構成には、フォームの受付程度の小さな処理を Pages Functions（Cloudflare上で必要なときだけ動くサーバー側の処理）や外部サービスで補う形を含めます。それより重い処理を持たせる構成で表がどう変わるかは、後の節で扱います。
| 比較項目 | Astro + Cloudflare（作り置きの構成） | Laravel（Webアプリ） |
|---|---|---|
| 向くサイトの性質 | コーポレート、メディア、採用、LP（閲覧が中心） | 会員サイト、予約システム、マイページ（閲覧者ごとに内容が変わる） |
| 標準構成の配信方式 | 作り置きしたページを配信する。動的な部分はPages Functionsや外部サービスで補う | アクセスのたびにサーバー側で処理して組み立てる |
| 公開側の保守 | 公開側にWordPress本体もデータベースも置かないため、そちらの更新追従は無くなる | フレームワークとライブラリの更新追従が続く |
| 設計の自由度 | 画面の作りは自由に組める。閲覧者ごとに出し分ける処理は、そのつど外部サービスやサーバー側の処理を足すことになる | 業務ロジックとデータ構造を要件どおりに組める |
この記事の説明が当てはまらない場合
閲覧が中心のサイトでも、更新した内容をその場で反映する必要がある場合は、事前に作り置きする構成が合いません。在庫や空き枠のように秒単位で変わる情報を出しているサイトが該当します。
会員機能やECのあるサイトを作り替える場合も、閲覧の部分は作り置きの構成で配信し、会員や注文の処理を Laravel で受け持つ形に分けられることがあります。どう分けるかは、作り替えの計画の中で決めます。
AstroをSSR（アクセスのたびにサーバー側で組み立てる方式）で動かす構成や、Pages Functionsで認証や閲覧者ごとの出し分けを持たせる構成を選ぶ場合、この記事の比較表は当てはまりません。作り置きを前提にした保守の軽さも、その分だけ変わります。
ページ数が多く、全件の作り置きに時間がかかるサイトも、この記事の前提から外れます。更新のたびに全件を作り直す構成では、公開までの待ち時間が運用の制約になります。
権限の細かい制御、監査記録、外部システムとの連携が要件にある場合も、比較表の4項目だけでは決まりません。Laravel以外のフレームワークや、既存の業務向けクラウドサービスで足りることもあります。
移行先の判断は、記事の分類ではなく、実際のデータの持ち方と更新の頻度で決まります。当方の分類は候補を絞るための出発点であり、確定ではありません。
相談相手に確認すること
見積や方針を受け取ったら、次の4点を確認してください。どれも、その場で答えられる範囲です。
1つめは、更新した内容が公開ページに反映されるまでの時間です。事前に作り置きする構成では、更新から反映までに時間差が生じます。何分・何秒まで許容できるかを先に決めます。
2つめは、いま動いている機能のうち、移行先で作り直しが要るものと、外部サービスへ預けられるものの区別です。フォームとサイト内検索は分かれやすい箇所です。会員機能をサイトの中で扱っている場合は、作り直しが要る側に入ります。
3つめは、公開先を切り替える当日の手順と、切り戻しの条件です。検証をどこまで終えてから切り替えるかを、工程として決めておきます。
4つめは、移行後に自社で更新できる範囲です。更新のたびに依頼が必要になる構成では、保守の負担が形を変えて残ります。
参考情報（外部サイト）
本文で参照した外部の公開情報です。
- Pages Functions（サーバー側の処理・認証・フォーム送信の扱い）（外部サイト）（Cloudflare）
- Deploy an Astro site（AstroのSSGとSSRの扱い）（外部サイト）（Cloudflare）