WordPress＋Astroのヘッドレス構成が中小企業サイトに向いている理由｜制作会社の実測と判断基準

「ヘッドレスCMSに興味はあるが、うちみたいな規模のサイトで本当に意味があるのか」。美容室や店舗ビジネスの経営者、中小企業のWEB担当者からよく受ける質問です。

結論から書きます。**中小企業サイトのヘッドレス構成は「WordPress＋Astro（静的生成＝SSG）」が現実解**です。理由は次の5つに集約されます。

1. ビルド時にHTMLを焼き上げるため、検索エンジンに確実に本文が届く

2. 更新頻度が低く動的機能が薄い中小サイトには、SSGで十分・最速・最安

3. 既存のレンタルサーバー＋FTPという運用をそのまま使える（サーバー移転が不要）

4. 記事の更新はこれまで通りWordPressの管理画面。現場の運用は何も変わらない

5. 学習コストが低く、内製・外注どちらでも保守を引き継ぎやすい

逆に言うと、**レンダリング方式を誤ったヘッドレス構成は、検索にまったく評価されないサイトを生みます**。これは理屈の話ではなく、弊社が自社サイトで実測して確認した事実です。本記事では、その検証データと、Astroを選んだ判断基準、導入時に必ず押さえるべきチェックリストまでを制作会社の実務目線で解説します。

ヘッドレス構成の落とし穴：CSRでは記事がGoogleに届かない

ヘッドレスCMSとは、WordPressなどのCMSを「記事管理の裏方」に徹させ、表側（フロントエンド）を別の技術で作る構成です。表示速度やデザイン自由度が上がる一方で、**フロント側のレンダリング方式を間違えると致命傷になります**。

方式は大きく3つあります。

| 方式 | HTMLが作られるタイミング | 検索エンジンへの影響 |

|—|—|—|

| CSR（クライアントサイドレンダリング） | 閲覧者のブラウザ上でJavaScriptが描画 | 生HTMLに本文がなく、評価されないリスク大 |

| SSR（サーバーサイドレンダリング） | アクセスのたびにサーバーが生成 | 問題ないが常駐サーバーが必要 |

| SSG（静的サイト生成） | ビルド時にあらかじめ生成 | 生HTMLに本文が焼き込まれ確実に届く |

このうちCSR、つまりReactなどのSPA（シングルページアプリケーション）でヘッドレスを組むと、何が起きるか。弊社が自社コーポレートサイト（当時はVite＋ReactのSPA構成）で実際にHTMLソースとインデックス状況を検証したところ、次の状態になっていました。

ブログ記事ページの生HTMLに**本文が1文字も存在しない**（JavaScriptが後から描画するため）
canonicalタグ（検索エンジンに「正式なURLはこれ」と伝えるタグ）が全記事で**トップページを指していた**
sitemapにブログ記事の個別URLが**1件も載っていなかった**

つまり、十数本の記事を公開していたのに、Googleから見れば「本文のない、正式URLがトップページの、地図にも載っていないページ」だったわけです。記事を書けば書くほど手間だけが積み上がる状態でした。

これは特殊な失敗ではありません。**「ヘッドレス＝モダンで速い」というイメージだけでSPA構成を選ぶと、どの会社でも同じことが起こりえます**。だからこそ、中小企業サイトのヘッドレスは最初からSSGで設計するのが正解です。SSGならビルド時点で本文・canonical・OGP・構造化データがすべてHTMLに焼き込まれるため、この問題は設計レベルで消えます。

なぜNext.jsではなくAstroなのか

SSGができるフレームワークは複数あります。有名どころはNext.jsですが、弊社は中小企業サイトの標準構成として**Astroを採用**しました。判断のポイントは4つです。

1. 既存のレンタルサーバー運用をそのまま使える

Astroのビルド成果物は純粋な静的HTMLです。エックスサーバーなどの一般的なレンタルサーバーに、これまで通りFTPでアップロードするだけで公開できます。

一方、Next.jsの強みであるISRやSSRは常駐するNode.jsサーバーが前提で、実質的にVercelなどのホスティングサービスへの移行がセットになります。月額コストが増え、契約先も増える。**「今のサーバー契約のまま、フロントだけ差し替える」ができるかどうか**は、中小企業にとって大きな分かれ目です。

2. サイトの性質がSSGと合っている

美容室や店舗のサイト、中小企業のコーポレートサイトは、更新はブログとお知らせが中心で、リアルタイムに変わる動的機能はほぼありません。この性質なら、アクセスのたびにページを組み立てるSSRはオーバースペックで、あらかじめ全ページを生成しておくSSGが最速かつ最安です。予約システムや会員機能のような動的要件が中心の案件なら話は別で、そのときはNext.jsを選びます。**「更新頻度が低く、動的機能が薄いならAstro、動的機能が主役ならNext.js」**というのが弊社の使い分けです。

3. 既存のReact資産を捨てずに済む

AstroはReactコンポーネントを部分的に埋め込めます（アイランドアーキテクチャ）。すでにReactで作った問い合わせフォームやUIパーツがあれば流用できるため、作り直しのコストを抑えられます。

4. 学習コストが低く、量産と引き継ぎに向く

AstroはHTMLに近い書き味で、習得の敷居が低い。制作会社の立場で言えば外注メンバーへの引き継ぎがしやすく、企業のWEB担当者の立場で言えば内製保守の現実味が出ます。弊社の見積もりでは、初回のパイロット構築こそ9〜12.5人日かかりますが、設定ファイル（サイト情報・配色・機能のON/OFF）に差し替え点を集約したテンプレートを一度作れば、**2件目以降は1サイトあたり2〜4人日**まで圧縮できます。仕組み化して量産できるかどうかも、技術選定の重要な基準です。

導入時に必ず押さえるチェックリスト

WordPress＋Astroの構成は、次の項目を最初から設計に組み込めば安定します。逆に、後回しにすると公開後に「検索に出ない」「記事が反映されない」という形で返ってきます。

SEOまわり

**本文HTMLの出力確認**：公開後、ページのソース表示で本文テキストが生HTMLに含まれているかを必ず目視する
**自己参照canonical**：各ページのcanonicalがそのページ自身を指していること
**旧URLからの301リダイレクト**：既存サイトからの移行時は、旧URL→新URLの301設定とcanonical統一を移行と同時に行う。後回しにすると新旧URLが検索上で共食い（カニバリゼーション）を起こす
**sitemapに記事個別URLを全件掲載**し、robots.txtでsitemapの場所を宣言する
title・meta description・OGP・構造化データ（JSON-LD）を記事データから動的に生成する

なお、sitemapとrobots.txtの整備は即効性があります。弊社の検証でも、robots.txtにWordPress側sitemapの宣言を追加してSearch Consoleに登録し直しただけで、それまで検出されていなかった120ページがGoogleに検出される状態になりました。

更新反映の仕組み

SSGには「WordPressで記事を保存しても、ビルドが走るまでサイトに反映されない」という性質があります。ここを設計しないと、更新した本人からは「記事が出ない」という不具合にしか見えません。予防策は二重化です。

WordPressの記事保存をトリガーに自動ビルドを起動する（Webhook連携）
保険として1日1回の定時ビルドも仕込んでおく（Webhookが失敗した日も翌朝には反映される）

また、ビルド時にWordPressのAPIへアクセスする構成上、WordPress側が一時的に落ちているとビルドが失敗します。**前回の成功ビルドを保持し、失敗時はそれを配信し続ける**設計にしておけば、サイトが消えるという最悪の事態は防げます。

規模の見極め

記事数が数百本規模になるとビルド時間が無視できなくなります。中小企業サイトの記事数（数十〜百数十本）なら実用上問題ありませんが、大規模メディアを想定するなら差分ビルドやホスティング側の仕組みも含めて検討が必要です。

ヘッドレス化を「見送るべき」ケース

すべてのサイトにヘッドレスを勧めるわけではありません。次に当てはまるなら、通常のWordPressのままテーマと高速化を整えるほうが合理的です。

サイトの表示速度や検索流入に現状大きな不満がない
更新担当者がテーマ編集やプラグインを日常的に使い、管理画面で完結する運用が定着している
フロント側を保守できる体制（社内担当者または制作会社との継続契約）が用意できない

ヘッドレスはフロントとCMSの2階建てになるぶん、保守する対象も2つになります。**「速さとSEOの伸びしろ」と「保守体制」を天秤にかけて、体制が用意できる場合にだけ踏み込む**。これが制作会社としての正直な判断基準です。

まとめ：正しく作れば、中小企業こそ恩恵が大きい

中小企業サイトのヘッドレスは**WordPress＋Astro（SSG）**が現実解。生HTMLに本文が焼き込まれ、検索に確実に届く
SPA（CSR）でのヘッドレスは「本文のないページ」を量産するリスクがある。実測でも本文ゼロ・canonical誤り・sitemap未掲載という状態を確認済み
Astroを選ぶ決め手は、**既存レンタルサーバー＋FTP運用の継続・SSGとの相性・React資産の流用・低い学習コスト**
移行時は301とcanonical統一を同時に。更新反映はWebhook＋定時ビルドの二重化で設計する
テンプレート化すれば2件目以降は2〜4人日まで圧縮でき、制作費を抑えた横展開が可能になる

WordPressの使い勝手はそのままに、表側だけを速く・検索に強く作り替える。この構成は、大企業よりむしろ「サーバー費用を増やせない、でも検索流入は伸ばしたい」中小企業にこそ向いています。導入を検討する際は、本記事のチェックリストを設計段階で潰せる体制かどうかを、まず確認してみてください。