WordPressをAstroで
ヘッドレス化する方法

先に結論：更新性を残して公開側を軽くしたいサイトに向く

反対に、会員機能、購入処理、複雑な絞り込みなどをWordPressプラグインに強く依存しているサイトは、機能ごとの代替設計が必要です。「速くしたい」という理由だけで全面移行すると、更新担当者の手間や開発費が増える場合があります。

WordPressをAstroでヘッドレス化する基本構成

ヘッドレス化では、WordPressをコンテンツ管理の「裏側」として残し、ページを表示する「表側」をAstroへ分離します。WordPressには標準のREST APIがあり、投稿・固定ページ・カテゴリなどをJSON形式で取得できます。Astro公式ドキュメントにも、WordPress REST APIを使う構成が案内されています。

公開方法は、更新時に全ページを生成する静的生成（SSG）が基本です。更新頻度やページ数が多い場合は、必要なページだけサーバーで生成するSSRや、キャッシュ戦略を組み合わせます。重要なのは「Astroなら必ず静的生成」と決め打ちせず、更新頻度と公開までの許容時間から選ぶことです。

// WordPress REST APIから公開済み記事を取得する最小例
const response = await fetch(
  'https://example.com/wp-json/wp/v2/posts?_embed&per_page=10'
);

if (!response.ok) {
  throw new Error('WordPressの記事取得に失敗しました');
}

const posts = await response.json();

実運用ではページネーション、タイムアウト、再試行、下書きプレビュー、カスタム投稿タイプ、画像URLの変換も設計します。

Astroの動的ルートに記事を渡す例

投稿一覧を取得できたら、AstroのgetStaticPaths()でWordPressのスラッグとページを対応させます。次は、src/pages/blog/[slug].astroに置く最小構成です。

---
// src/pages/blog/[slug].astro
import { getPosts } from '../../lib/wordpress';

export async function getStaticPaths() {
  const posts = await getPosts();

  return posts.map((post) => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
---

<article>
  <h1 set:html={post.title.rendered} />
  <div set:html={post.content.rendered} />
</article>

set:htmlはHTMLをそのまま出力します。編集権限を信頼できる運用に限定し、外部投稿や複数の寄稿者を受け付ける場合はサニタイズ処理を入れます。記事が100件を超える場合は、REST APIのページネーションにも対応します。

従来のWordPress運用から何が変わるか

表示速度は構成だけで決まりません。画像サイズ、フォント、外部タグ、JavaScript量が重ければ、Astroへ移しても遅くなります。移行前後はLCP・INP・CLSを実測し、同じURL・同じ端末条件で比較します。

WordPressからAstroへ移行する7つの手順

1. URL・テンプレート・プラグインを棚卸しする

   全URL、ページ種類、カスタム投稿、カスタムフィールド、フォーム、検索、会員機能、リダイレクトを一覧化します。見た目ではなく、現在のWordPressが担っている機能を先に分解します。

2. REST APIまたはGraphQLの取得方式を決める

   標準投稿が中心ならREST APIから始められます。関連データをまとめて取得したい、取得項目を厳密に制御したい場合はWPGraphQLも候補です。既存プラグインとの相性まで確認します。

3. Astroでページテンプレートを再構築する

   一覧、詳細、カテゴリ、固定ページをコンポーネント化します。タイトル、meta description、canonical、OGP、構造化データをテンプレート側で一元管理し、ページごとの欠落を防ぎます。

4. 下書きプレビューと公開トリガーを作る

   編集者が公開前に確認できるプレビューURLを用意します。公開・更新・削除をきっかけにビルドを開始するWebhookをつなぎ、失敗時の通知と再実行方法も決めます。

5. フォーム・検索・動的機能を置き換える

   Contact Form 7などの表示側機能は、そのまま動くとは限りません。API、サーバーレス関数、外部検索などへ置き換え、スパム対策・エラー処理・個人情報の保存先も確認します。

6. 旧URLと新URLを照合し、SEO要素を移す

   可能な限りURLを維持します。変更が必要なURLは一対一で301リダイレクトし、内部リンク、canonical、XMLサイトマップも新URLに統一します。公開前に404・リダイレクトチェーン・noindex混入を機械的に検査します。

7. 同条件で比較し、段階的に切り替える

   主要テンプレートごとに表示、計測タグ、フォーム、構造化データを確認します。検索流入が多いページと問い合わせ導線から優先し、公開後はSearch Consoleのインデックス・クロール・検索パフォーマンスを監視します。

WordPress × Astroで失敗しやすい5つのポイント

ヘッドレス化に向いているサイト・向いていないサイト

Boutique Hackの掲載事例では、WordPressで運用していた企業サイトをAstroとヘッドレスCMSへ移行し、公開フローまで再設計しました。初期導入の一例は約3週間・約70万円です。ページ数、プラグイン、動的機能、既存データの状態によって期間と費用は変わります。

ヘッドレスCMS移行の掲載事例を見る →

WordPressとAstroのヘッドレス化でよくある質問