WordPressを静的サイト化する3つの方法｜プラグインで書き出す・Astroで作り直す・ヘッドレスで残す

はじめに

WordPressで作ったホームページを静的なHTMLにしたい、と考える理由はおもに3つあります。PHPやプラグインの更新に追われていること、表示が遅いこと、2026年に入ってからWordPress本体とPHPの深刻な脆弱性が続いたことです。

「WordPress 静的サイト化」で検索すると、上位にはプラグインでHTMLを書き出す手順が並びます。ただ、やり方は1つではありません。この記事では、静的サイト化の方法を3つに分け、同じ項目で比べます。

1. WordPressを残し、プラグインでHTMLを書き出す
2. Astroなどのフレームワークで作り直し、WordPressを外す
3. WordPressを記事を書く場所として残し、表示だけAstroなどで作る

後半では、どの方法を選んでも決めることになる、URLの対応表と301リダイレクト、お問い合わせフォームの代わり、サイト内検索、画像、更新担当者の手順、公開後の確認をまとめます。プラグインの機能と料金は、2026年10月23日に公式ページで確認した内容だけを書いています。

静的サイト化で変わること

WordPressは、ページが見られるたびに、サーバーの中でPHPが動き、データベースに問い合わせてHTMLを組み立てます。静的サイト化は、このHTMLをあらかじめ作っておき、公開サーバーにはHTMLと画像だけを置く構成に変えることです。

変わるのは次の2点です。

• 公開サーバーでPHPとデータベースが動かなくなる。PHP、WordPress本体、テーマ、プラグインの更新と、そのたびの動作確認が公開ページから消える。ログイン画面（wp-login.php）も公開サーバーから消える
• フォームの送信、サイト内検索、コメントなど、サーバー側で何かを処理する機能は、そのままでは動かなくなる。別の仕組みに置き換える

2点目が、静的サイト化の計画で手間がかかる部分です。3つの方法の違いも、おもにここの扱いに出ます。

方法1：WordPressを残してプラグインでHTMLを書き出す

WordPressの管理画面はそのまま使い、公開用のHTMLをプラグインで書き出して、別の場所（静的ホスティングやCDN）に置く方法です。管理画面のあるWordPressは、社内ネットワークや別のサーバーで動かし続けます。

代表的なプラグイン

2026年10月23日にwordpress.orgと各公式サイトで確認した内容です。料金は変わるので、申し込む前に公式ページを見てください。

wordpress.orgのSimply Staticのページでは、Pro版の配置先にNetlifyとCloudflare Pagesも挙がっていますが、料金ページにはその記載がありませんでした。使いたい配置先がある場合は、購入前に問い合わせるのが確実です。

更新のしかた

担当者はこれまでどおりWordPressの管理画面で記事を書き、公開ボタンの代わりに、プラグインの書き出しを実行します。無料版ではZIPを手でホスティングへ上げる手間が残り、有料版では配置先へ自動で送れます。

フォームと検索

静的なHTMLからは、WordPressのフォームプラグインの送信処理が動きません。両プラグインの有料版はフォーム連携を持ち、Simply Static Proは送信内容をWordPress側に保存すると説明しています。つまり、フォームを受け取るためのWordPressは、公開ページとは別の場所で動き続けます。検索も同じで、有料版の検索連携か、後述する静的サイト向けの検索ライブラリに置き換えます。

向くサイト

WordPressの管理画面を手放したくない、担当者が複数いて投稿が多い、テーマやプラグインで作った表示をそのまま残したい、というサイトに向きます。ただし、WordPressそのものの更新作業はなくなりません。公開サーバーからPHPが消えるだけで、管理画面のあるWordPressは、今までどおり本体、テーマ、プラグイン、PHPの更新が必要です。

方法2：Astroなどで作り直してWordPressを外す

WordPressから投稿と固定ページを取り出し、AstroやNext.jsのような、ページをあらかじめHTMLに生成するフレームワークで作り直す方法です。当社がサービスとして提供しているのはこの方法です。

記事の取り出し方

WordPressの管理画面の「ツール」→「エクスポート」で、投稿、固定ページ、カスタム投稿、コメント、カスタムフィールド、カテゴリ、タグがXML（WXR形式）で書き出せます。画像ファイルは含まれないので、wp-content/uploads を別にコピーします（WordPress公式の説明）。

Astro公式にはWordPressからの移行ガイド（日本語）があり、WordPressの投稿をMarkdownに変換するツールと、移行した人の体験記が並んでいます。ガイドにも、大きなサイトでは変換結果の手直しが要る、と書かれています。ショートコードやテーマ独自のブロックは、変換ツールにかけても文字列のまま残りやすいので、人が見て直す前提で予定を組みます。

更新のしかた

WordPressの管理画面はなくなります。記事はMarkdownのファイルとしてGitリポジトリに置き、変更するとホスティング側でビルドが走り、HTMLが公開されます。担当者の慣れに合わせて、次のどれかを選ぶことになります。

• 手順書を渡して担当者が差し替える
• 制作会社に文章と画像を送って反映してもらう
• microCMSなどの管理画面をつなぎ、記事はそこで書く（公開ページは静的なまま）

フォームと検索

フォームは、外部のフォームサービスを使うか、送信だけを処理する小さなサーバーレス関数を置きます。Astroは標準で全ページを静的に生成しますが、export const prerender = false と書いたページやエンドポイントだけをサーバーで処理する設定ができ、Netlify、Vercel、Cloudflare、Node.js向けのアダプターが用意されています（Astro公式ドキュメント）。検索は、ビルド後のHTMLから索引を作ってブラウザで検索するPagefindのようなライブラリを使います。

向くサイト

会社案内、採用、サービス紹介のように、更新が月に数回までのサイトに向きます。WordPressが完全になくなるので、PHPとプラグインの更新作業がどこにも残りません。反面、デザインを作り直すことになるため、今の見た目をどこまで再現するかで手間が変わります。

方法3：WordPressをヘッドレスCMSとして残し、表示だけAstroにする

記事を書く場所としてWordPressを残し、表示するサイトはAstroなどで別に作る方法です。Astroがビルド時にWordPressのREST API（/wp-json/wp/v2/）から記事を取り込み、HTMLを生成します。REST APIは標準で有効で、読み取りに認証は要りません。GraphQLで取りたい場合はWPGraphQLなどのプラグインを入れます（Astro公式のWordPress連携ガイド）。

更新のしかた

担当者はWordPressの管理画面で記事を書きます。公開ボタンを押したあとに、Astroのビルドを呼び出す仕組み（ホスティングのビルドフックなど）をつないでおくと、数分後に静的なHTMLが更新されます。管理画面の操作が今までと変わらないのが利点です。

フォームと検索

方法2と同じです。フォームは外部サービスかサーバーレス関数、検索はPagefindのようなライブラリで置き換えます。WordPressのフォームプラグインは表示側から切り離されるので使いません。

向くサイト

投稿の頻度が高く、複数の担当者が管理画面で書いている、オウンドメディアやニュースの多いサイトに向きます。注意点は、WordPressが動くサーバーが残ることです。公開ページからは切り離されますが、管理画面のWordPressはPHPとプラグインの更新を続け、外部からログイン画面に届かないようにIP制限などで守る必要があります。

3つの方法の比較

「公開サーバーでPHPが動かない」は3つとも同じです。違いは、WordPressの更新作業がどこかに残るかどうかと、担当者が記事をどこで書くかです。

どの方法でも決めること

URLの対応表と301リダイレクト

静的化で検索流入を減らさないために、いちばん先に作るのがURLの対応表です。今のサイトの全URL（投稿、固定ページ、カテゴリ、タグ、画像、フィード）を一覧にし、新しいサイトでのURLを横に書きます。同じURLを保てるページは「維持」、どうしても変わるページは「301リダイレクト」、残さないページは「410または404」と種別を付けます。

GoogleのURL変更を伴うサイト移転の案内では、サーバー側の恒久的なリダイレクト（301か308）を使う、リダイレクトを何段も連鎖させない、多数の旧URLをトップページ1つにまとめない、リダイレクトは1年以上保つ、と書かれています（Google検索セントラル）。

当社のサイト（hanzochang.com）もNext.jsの静的生成で作り直していて、旧サイトのURLは next.config.ts の redirects に転送先を書いています。対応表をコードに書いておくと、どのURLをどこへ送っているかがレビューと履歴に残ります。

// next.config.ts（抜粋）
async redirects() {
  return [
    ...ARTICLE_REDIRECTS.map(({ slug, destination }) => ({
      source: articleUrl(slug),
      destination,
      permanent: true,
    })),
    {
      source: "/privacy-policy",
      destination: URLS.privacy,
      permanent: true,
    },
  ];
}

// next.config.ts（抜粋）
async redirects() {
  return [
    ...ARTICLE_REDIRECTS.map(({ slug, destination }) => ({
      source: articleUrl(slug),
      destination,
      permanent: true,
    })),
    {
      source: "/privacy-policy",
      destination: URLS.privacy,
      permanent: true,
    },
  ];
}

Astroでも astro.config.mjs の redirects に同じ形で書けます。ホスティング側の設定ファイル（Netlifyの _redirects、Cloudflare Pagesの _redirects など）に書く方法もあり、どちらにするかは、リダイレクトの数とビルドの仕組みで決めます。

お問い合わせフォームの代わり

静的なHTMLは送信を受け取れないので、受け取る先を別に用意します。選択肢は2つです。

1. 外部のフォームサービス。ホスティングに付属するもの（たとえばNetlify Formsは、HTMLの <form> に data-netlify="true" を付けるとデプロイ時に検出して送信を受け付けます）や、フォーム専用のサービス
2. 送信だけを処理するサーバーレス関数。Astroなら prerender = false のエンドポイント、ほかにCloudflare WorkersやVercel Functionsなど

どちらでも、決めることは同じです。入力項目、送信先のメールアドレス、自動返信の有無、スパム対策、送信内容をどこに保存するか（個人情報の置き場所）、送信後に表示するページ。WordPressのContact Form 7で設定していた内容を、そのまま要件として書き出すのが早道です。

サイト内検索

WordPressの検索（?s=キーワード）はPHPがデータベースを引いていたので、静的化すると動きません。代わりは次のどれかです。

• 静的サイト向けの検索ライブラリ。Pagefindは、ビルド後のHTMLから索引を作り、ブラウザが索引の必要な部分だけを読み込んで検索します。公式サイトは、1万ページのサイトでも転送量300kB未満で全文検索できると説明しています
• 外部の検索サービス（Algoliaなど）。プラグインの有料版が連携先として挙げているのもこれです
• 検索をなくす。ページ数が50以下の会社案内なら、ナビゲーションとサイトマップで足りることが多く、当社ではまず検索窓が実際に使われているかをアクセス解析で確かめます

画像

WordPressの画像は wp-content/uploads/年/月/ に置かれ、記事の本文にそのURLが書かれています。方法1では、書き出した画像をそのパスのまま置くのが楽です。方法2と3では、画像を新しいサイトの置き場に移すか、wp-content/uploads/ のパスをそのまま残すかを決めます。URLを変えるなら、画像も対応表に載せます。画像検索からの流入があるサイトでは、画像のURLを変えるとその流入が一度切れます。

Astroは画像を表示サイズに合わせて変換して出力できます。WordPressが作っていた複数サイズのサムネイルは、移行後は不要になります。

更新担当者の手順

静的化のあとで止まりやすいのは、技術の部分より、更新の運用です。移行前に次の3つを決めて、手順書に書きます。

1. 誰が書くか。担当者が直接書くのか、制作会社に送るのか
2. どこで書くか。WordPressの管理画面（方法1と3）、Markdownのファイル（方法2）、microCMSなどの管理画面（方法2の変形）
3. 書いたあとに何をすると公開されるか。プラグインの書き出し、Gitへのコミット、管理画面の公開ボタン

公開までに数分かかるビルドが挟まる構成では、公開ボタンを押したのに変わらない、と担当者が戸惑いやすくなります。待ち時間と確認のしかたを手順書に書いておきます。

公開後にSearch Consoleで確かめること

ドメインが変わらない静的化では、Search Consoleの「アドレス変更」ツールは使いません。Googleの案内でも、アドレス変更ツールが要るのはドメインかサブドメインを変える場合だけで、パスの変更には不要とされています。

公開後の確認は次の順です。

1. 新しいサイトマップを送信する。移行中は旧サイトマップにリダイレクトの警告が出ることがあり、Googleは想定内の動作としている
2. 「ページ」（インデックス登録）レポートで、404と「リダイレクトエラー」が増えていないかを見る。増えていたら対応表の漏れ
3. 「検索パフォーマンス」で、移行前の4週間と比べて表示回数とクリック数が落ちたページを探す。落ちたページは、URLが変わっていないか、タイトルと説明文が移っているかを確かめる
4. フォームからテスト送信し、通知メールが届くことを確かめる。スパム対策が強すぎて正規の送信を落としていないかも見る

向く方法の見分け方

ここまでの内容を、判断の順に並べます。

• 公開ページの脆弱性対応だけをなくしたい、管理画面は今のまま使いたい、投稿が多い。方法1か方法3
• WordPressの更新作業そのものをなくしたい、更新は月に数回まで。方法2
• 投稿が多く、担当者が複数いて、管理画面の操作を変えたくない。方法3
• 予約、会員ログイン、ECのように、見る人ごとに内容が変わる機能が中心。静的化に向かない。その機能だけを外部サービスにできるかを先に調べる

どの方法でも、リスクはゼロにはなりません。フォームの受け口、ドメインの設定、管理画面を残す場合はそのサーバーが守る対象として残ります。静的化は、守る場所を公開ページから減らして、残った場所をはっきりさせる作業です。

まとめ

• WordPressの静的サイト化は、プラグインで書き出す、Astroなどで作り直す、ヘッドレスで残す、の3つに分かれる
• 3つとも公開サーバーでPHPは動かなくなるが、WordPressの更新作業が残るかどうかと、記事をどこで書くかが違う
• プラグインの無料版はZIPやフォルダへの書き出しまでで、フォームと検索の連携と配置先の自動化は有料版（2026年10月23日に確認）
• どの方法でも、URLの対応表と301リダイレクト、フォームの受け口、検索の代わり、更新担当者の手順を先に決める
• 公開後はSearch Consoleでサイトマップ、404、表示回数の落ちたページを確かめる

当社の移行サービスについて

当社は、方法2のAstroで作り直す移行をサービスとして行っています。今のデザインとURLを極力そのままにして、公開サーバーでPHPもデータベースも動かない構成に置き換え、フォームと更新方法は相談して決めます。調べた結果、WordPressのまま保守するほうが合っていると判断したときは、そのままお伝えします。

詳しい進め方と、向くサイトと向かないサイトの一覧は、WordPress・PHPのホームページを静的サイトへ移行するサービスのページにまとめています。