WordPressの脆弱性対応に疲れた方へ、Astro＋Cloudflareに移行する手順【2026年版】

2026.10.23

「また WordPress の脆弱性か……」。本体・テーマ・プラグインの更新通知が来るたびに、表示崩れを心配しながら対応する。多くの中小企業のWeb担当者が抱えている、地味だけれど終わらない仕事です。

スゴヨクでも同じ悩みがありました。そこで選んだのが、WordPress から Astro＋Cloudflare Workers への移行です。対象は自社サイト（固定ページ46・ブログ記事280本・フォーム8種）です。

この記事では、制作会社の自社サイトを例に、移行の手順を棚卸しからDNS切替まで6ステップで解説します。「脆弱性対応をやめたい」「でもサイトの中身や検索順位は守りたい」という方に向けた、実務ベースの手順書です。

なぜWordPressから移行するのか：更新対応が「終わらない仕事」だから

結論から言うと、サイトを更新するための仕組み（WordPress）を守るための仕事が、サイトそのものを良くする仕事より多くなっていたからです。

WordPress は世界で最も使われているCMS（サイト管理システム）で、スゴヨクでもお客様のサイトに数多く採用しています。便利な反面、常に動いているプログラムである以上、脆弱性（セキュリティ上の弱点）が見つかれば対応が必要です。

直近では、2026年7月22日に IPA（情報処理推進機構）が WordPress 本体の2件の脆弱性（CVE-2026-60137、CVE-2026-63030）について注意喚起を出しました。2件を組み合わせた攻撃は「wp2shell」と呼ばれ、標準構成では管理者権限がなくても遠隔からコードを実行される可能性があるとされています。対象は 6.9.0〜6.9.4 と 7.0.0〜7.0.1（出典：IPA 注意喚起 2026年7月22日）。

本体だけでこれです。実際の運用ではさらに次が積み重なります。

更新対象	頻度の目安	起きがちなこと
WordPress 本体	年数回＋緊急時	自動更新が止まっていて未適用のまま
テーマ（有料テーマ含む）	月1回程度	子テーマのカスタマイズと競合して崩れる
プラグイン	入れた数だけ	更新で機能が変わる・放置されて更新が止まる
PHP / MySQL	サーバー側で年1回程度	古いプラグインが動かなくなる

スゴヨクのサイトはページのほとんどが「読むだけ」のコンテンツで、サーバー側で毎回生成する必要はありません。それなのに、動的に動く仕組みを守り続けるのは割に合わない。これが移行を決めた理由です。

移行先に Astro＋Cloudflare を選んだ理由

結論：「ページは完成品のHTMLを配信し、動く部分は最小限だけ自分で書く」 という構成にすれば、守るべき面積が劇的に減るからです。

Astro（アストロ）：ページを事前に「できあがったHTML」として書き出すフレームワーク。公開後のページはただのファイルなので、ログイン画面もデータベースもありません。
Cloudflare Workers：そのファイルを世界中の拠点から配信し、フォーム受付などの小さなプログラムだけを動かすサービス。中小企業のサイトなら無料枠（1日10万リクエスト）で足ります。

ほかの選択肢と比べた整理が次の表です。

選択肢	脆弱性対応	更新のしやすさ	向いているケース
WordPress のまま運用強化	減らない（WAF等で緩和）	管理画面で誰でも	毎日大量に記事を更新する、非エンジニアだけで運用
WordPress を静的化プラグインで書き出し	減る（管理用WPは残る）	管理画面で編集→書き出し	WPの操作感を残したい
Astro＋Cloudflare（今回）	大幅に減る	ファイル編集＋push	更新頻度が週数回以下、エンジニアかAIが触れる
ノーコードSaaS（Studio等）	ほぼ不要	専用エディタ	デザイン重視、独自機能が不要

制作会社の立場から言うと、「WordPress を静的化するプラグイン」は中間解として悪くないのですが、結局 WordPress 本体の更新は続きます。根本的にやめるなら、Astro のような静的サイトジェネレーターに移すのが素直です。

移行の全体像：6ステップ

結論：順番さえ守れば、サイトを止めずに移行できます。DNSの切替は一番最後です。

ステップ	やること	所要時間の目安（今回）
1. 棚卸し	ページ・記事・フォーム・画像・動的機能を一覧化	1時間
2. エクスポート	WordPress の「ツール→エクスポート」でXMLを取得	10分
3. 変換	テンプレートとXMLを Astro の形式に変換	半日（AI活用）
4. 再実装	フォーム・受付APIを Workers で作り直す	半日
5. デプロイ	GitHub に push → Cloudflare が自動公開	1時間
6. DNS切替	動作確認後にネームサーバーを変更	作業30分＋反映待ち

以下、ステップごとに詳しく見ていきます。

手順1〜3：棚卸し・エクスポート・変換

手順1：何があるかを数える

まず「WordPress でしか動かないもの」を洗い出します。スゴヨクのサイトの場合は次の通りです。

特に注意したいのが 動的機能 です。今回は「お問い合わせ等のフォーム8種」「AIエージェント向けの無料診断API」の2つが該当し、これらは手順4で作り直す対象になります。逆に、一覧ページ・カテゴリページ・サイトマップ・RSS は Astro がビルド時に自動生成できるので、動的機能に数えません。

手順2：エクスポートXMLを取る

WordPress の管理画面「ツール → エクスポート → すべてのコンテンツ」でXMLをダウンロードします。スゴヨクのサイトでは 26MB・2,416アイテム（下書きや添付ファイルの情報も含む）になります。

このXMLには記事本文だけでなく、カテゴリ、アイキャッチ画像のID、Yoast SEO の title / description、Contact Form 7 のメール文面まで入っています。移行に必要な情報はほぼここにあります。

手順3：Astro の形式に変換する

変換は2系統に分かれます。

固定ページ：テーマのPHPテンプレート（page-○○.php）をHTMLに書き出して、Astro のページに変換
記事：XMLを読み込み、1記事＝1ファイルのJSONに変換

変換で守るルールは次の3つです。

URLを変えない
/blog/記事スラッグ/ も画像の /wp-content/uploads/… もそのまま。検索順位と被リンクを守るためです
本文はHTMLのまま
Markdown に変換すると表や装飾が崩れるため、HTML文字列として保存
SEOメタ情報を移す
Yoast の title / description / noindex 設定をそのまま引き継ぐ

スクリプトを書けば、280記事の変換は数秒で終わります。このスクリプト作成と固定ページの変換は、生成AI（Claude など）に任せると効率的です。人が手でやると数日かかる部分です。

手順4：フォームと受付APIを Workers で作り直す

結論：WordPress をやめて一番手がかかるのは「フォーム」です。ここだけは新しく書く必要があります。

WordPress ではプラグイン（Contact Form 7 など）がメール送信まで面倒を見てくれますが、静的サイトにはメールを送る仕組みがありません。そこで次の構成にします。

役割	WordPress時代	移行後
入力画面	Contact Form 7 のショートコード	Astro のコンポーネント（HTML）
スパム対策	Turnstile プラグイン	Cloudflare Turnstile（そのまま流用）
受付処理	PHP（プラグイン）	Cloudflare Workers（TypeScript 約150行）
メール送信	サーバーの sendmail	Resend（メール送信API、無料枠月3,000通）
受信	Google Workspace	Google Workspace（変更なし）

ポイントは メールの「受信」と「送信」を分けて考える ことです。会社のメール受信は今まで通り Google Workspace のまま。サイトのプログラムから「通知メールを送る」経路だけ、Resend のような送信サービスを使います。

スゴヨクには AI エージェントがそのまま無料診断を申し込める受付API（二段階の確認メール方式）もあり、こちらも Workers で同じ動きになるよう作り直します。保存先はデータベースの代わりに Cloudflare KV（キーと値を保存する簡易ストレージ）です。

手順5〜6：デプロイとDNS切替

結論：本番URLとは別の仮URLで全部確認してから、最後にネームサーバーを切り替えます。

手順5：GitHub と Cloudflare をつなぐ

GitHub にリポジトリを作成し、プロジェクト一式を push
Cloudflare の Workers で「リポジトリをインポート」→ ビルドコマンド npm run build、デプロイコマンド npx wrangler deploy を設定
Resend の API キーと Turnstile のシークレットキーを「シークレット」として登録
自動ビルドが完了すると ○○.workers.dev という仮URLで確認できる

以降は、記事ファイルを追加して push するだけで1〜2分後に公開されます。

手順6：DNS を Cloudflare に切り替える

ここで一番多い事故が「メールが止まる」です。Cloudflare にドメインを追加すると既存のDNSレコードが読み込まれますが、Google Workspace の MX・SPF・DKIM レコードがすべて揃っているかを 切替前に必ず目で確認 してください。確認が済んでから、ドメイン管理会社側でネームサーバーを Cloudflare 指定のものに変更します。

切替後は、メール送受信、サブドメイン、Google Search Console へのサイトマップ再送信（sitemap_index.xml → sitemap-index.xml のようにURLが変わる場合はリダイレクトも用意）を確認します。

移行で気をつける5つのこと

結論：技術よりも「変えないこと」を決めるほうが大事です。

URLは1本も変えない
記事・画像・カテゴリのURLを維持。変わるものは _redirects ファイルで301リダイレクト
構造化データとllms.txtを引き継ぐ
Organization・LocalBusiness・FAQ・パンくずの JSON-LD、AI検索向けの llms.txt は移行後も同じ内容で出力
有料テーマのCSS/JSはコピーしない
テーマのライセンス上、静的サイトに流用できない部分はヘッダーやメニューを自前で書き直します
「中身が空のまま公開されていたページ」が見つかる
棚卸しで初めて気づくことがあります。移行は不要ページを整理するチャンスです
見た目は変えない
デザインリニューアルを同時にやると、順位変動の原因が切り分けられなくなります。見た目はそのまま、中身だけを入れ替えます。

移行後の運用：記事更新はどうする？

結論：記事は「JSONファイルを1つ追加して push」で公開されます。管理画面はありません。

管理画面がないことを不安に感じる方もいると思いますが、記事の下書き作成から入稿までを生成AIに任せる運用にすれば、むしろ手順は減ります。

やりたいこと	方法
ブログを書く	`src/content/blog/○○.json` を追加 → push
固定ページの文言修正	該当ページのファイルを編集 → push
会社情報・電話番号の変更	設定ファイル1箇所を修正
通知先メールの変更	Cloudflare の環境変数を変更

社内に触れる人がいない場合は、記事更新だけ制作会社に依頼する形でも運用できます。

どんな会社に向くか／向かないか

向いている	向いていない
更新は週数回以下	毎日複数人が管理画面で記事を書く
脆弱性対応・保守費を減らしたい	会員機能・EC・予約などの動的機能が多い
表示速度・安定性を重視	WordPress プラグインの機能に強く依存している
エンジニアかAIが更新に関われる	非エンジニアだけで、AIも使わない運用

EC や会員サイトなど「ログインして使うもの」は、素直に WordPress（または専用システム）を使い続けるほうが合理的です。コーポレートサイトやオウンドメディアのように「読むのが中心」のサイトほど、静的化の効果が大きくなります。

よくある質問

Q. 移行で検索順位は下がりませんか？
A. URL・title・description・構造化データを維持すれば、移行そのものが順位を下げる要因にはなりにくいです。むしろ表示速度の改善はプラスに働くことが期待できます。切替後は Search Console でクロールエラーがないか2〜4週間は確認してください。

Q. 費用はどれくらいかかりますか？
A. 運用費は、Cloudflare Workers・GitHub・Resend ともに今回の規模なら無料枠に収まります。レンタルサーバー代が不要になる分、月額コストは下がります。初期の移行作業費はサイトの規模（ページ数・動的機能の数）で変わるため、無料診断で見積もります。

Q. WordPress の管理画面がなくなると、社内で更新できなくなりませんか？
A. 更新方法が「ファイルを追加して push」に変わります。GitHub の画面上でもファイル編集はできますし、生成AIに記事ファイルを作らせる運用も可能です。不安があれば更新だけ外注する形も選べます。

Q. 旧サーバーはいつ解約すればいいですか？
A. 切替後2〜4週間は残すことをおすすめします。画像の取りこぼしや、移行時に見落とした機能に気づいたときの参照先になります。

Q. 静的サイトなら、もうセキュリティ対策は不要ですか？
A. 不要にはなりません。依存パッケージの更新、フォーム処理の入力チェック、送信回数の制限などは引き続き必要です。ただし「常時公開されている攻撃面」が大幅に減るため、対応の頻度と緊急度は下がります。