プラグインを更新したら、ブログが「メンテナンス中」の画面のまま戻らなくなりました。
2026年10月21日のことです。
その同じ日に、PHPの重大な脆弱性の修正版が出ました。
共用サーバーでは、修正がいつ入るかをサーバー会社に任せるしかありません。
ここでWordPressをやめると決め、ブログ2つをAstroとCloudflare Pagesの静的サイトへ移しました。
かかったのは3日で、記事の更新や分析の自動化もそのまま動いています。
移行で実際に踏んだ落とし穴と、向くブログ・向かないブログの線引きを、実録でまとめます。
この記事でわかること
- WordPressからAstro＋Cloudflare Pagesへ移した結果（期間・費用・変わったこと）
- AFFINGERの装飾だらけの記事を、MarkdownとMDXに変換できた理由
- Claude Codeで進めた移行の4ステップと、自動化を作り直した方法
- 転送・404・メール・画像・ドメインで実際にハマった5つの落とし穴
PARTS LIST ／目次
WordPressからAstroへ移行した結果（費用・期間・変わったこと）
WordPressからAstroへの移行は、記事数が数百本あるブログでも3日で終わりました。
対象は、このブログ（コードで人生リビルド）と、ポイ活のブログ（トムのポイ活攻略ログ）の2つです。
公開ページは2つ合わせて約400あり、移行後の確認ではすべて同じURLで表示されました。
結論
配信はCloudflare Pagesの無料プランで足り、PHPとプラグインの更新から解放されました。代わりに、管理画面での記事の編集はなくなりました。
Astro＋Cloudflare Pagesとはどんな構成か
Astro＋Cloudflare Pagesとは、記事をMarkdownで書き、Astroでビルドした静的なHTMLをCloudflareの配信網から届ける構成です。
訪問者のアクセスでPHPやデータベースは一切動きません。
今回の構成では、Astroは7.3.6、記事は部品を埋め込めるMDX形式にしました。
Cloudflare Pagesの無料プランでも、個人ブログには十分な枠があります。
2026年9月5日更新の公式ドキュメント（[Cloudflare Pages Limits](https://developers.cloudflare.com/pages/platform/limits/)）では、次の上限です。
- ビルドは月500回まで
- 1サイトのファイルは20,000個まで
- 1ファイルは25MiBまで
- 転送ルール（
_redirects）は固定2,000件と動的100件まで
移行して変わったこと・変わらなかったこと
一番大きく変わったのは、記事がファイルになったことです。
Claude Codeに「この記事のこの段落を直して」と頼むと、差分をGitで確かめてから反映できます。
変わらなかったのは、自動化のほうです。
記事のリライト、内部リンクの追加、メタディスクリプションの更新など、30本以上の自作スキルは、手順をほぼ変えずに動いています。
この仕組みは後半で説明します。
WordPressをやめると決めた2つのきっかけ
WordPressをやめた理由は、表示速度でも流行でもありません。
自分の手で直せない時間が、2日続けて起きたからです。
1つめはPHPの脆弱性、2つめはプラグイン更新の事故でした。
どちらも「待つしかない」状態になった点が共通しています。
PHPの重大な脆弱性（CVSS 9.2）の修正をサーバー会社任せにするしかなかった
2026年10月20日、PHPの公式サイトに「重大なセキュリティリリース」の予告が出ました（[PHP News Archive 2026](https://www.php.net/archive/2026.php)）。
CVSS v4.0で9.2と評価された脆弱性が2件あり、翌21日に8.5.12などの修正版が公開されています。
Webのリクエストを受けているPHPは、すべて影響を受けるという内容でした。
共用サーバーでは、PHPの更新はサーバー会社が行います。
修正版が出たあとも、自分のサイトにいつ入るかは選べません。
「PHPの脆弱性が出ているのに？ 現状回避策ないんだよ？」
このときClaude Codeに送ったメッセージそのままです。
プラグイン更新後に「メンテナンス中」が消えなかった
同じ10月21日、ポイ活のブログでプラグインを更新しました。
すると「予定されたメンテナンスを実行中です」の画面が出たまま、元に戻りません。
原因は、更新の途中でWordPressが作る .maintenance というファイルが消えずに残ったことでした。
FTPでこのファイルを消せば直るとわかっても、最初はパスを間違えて550エラーが出ました。WordPressの本体が public_html の直下ではなく、その下のドメイン名のフォルダにあったからです。
ファイルを消すと元に戻りました。プラグインを1つ更新しただけで、サイトが止まる仕組みの上に乗っていたことになります。
EmDashやGhostではなくAstroを選んだ理由
移行先の候補は3つありました。
決め手は「記事をファイルとして持てるか」と「訪問者側にサーバーの処理が残らないか」の2点です。
管理画面がなくなるのは、普通なら大きな欠点です。
ただ私の場合、記事の作成もリライトもClaude Codeのスキルで回していて、管理画面を開くのは公開ボタンを押すときくらいでした。
移行前に確かめた「記事をMarkdownにできるか」
移行を決める前に、一番不安だったのは記事の変換です。
私のブログはWordPressのテーマAFFINGERの装飾をたくさん使っていて、ボックスや吹き出しが1記事あたり中央値で16個入っています。
これをMarkdownにしたら、見た目が崩れるのではないか。
手元にある全記事のHTMLを数えて、確かめることにしました。
本文の9割はそのまま変換できた
全記事のブロックを種類ごとに集計すると、段落・見出し・リスト・表・コードなど、Markdownにそのまま置き換えられる部分が約9割でした。
残りの1割も、種類は限られていました。
同じ形の部品が繰り返し出てくるだけなので、部品ごとに変換のルールを1つ作れば、一括で変換できます。
AFFINGERの装飾は「部品」に置き換える
変換先はMDXにしました。
決め手は、Markdownのまま装飾だけを部品として残せることです。
メモ
MDXとは、Markdownの中にコンポーネント（部品）を書ける形式です。Astroは公式の拡張（@astrojs/mdx）で読み込めます。
- AFFINGERのボックス →
<Box>部品 - 会話の吹き出し →
<Talk>部品 - 内部リンクのブログカード →
<LinkCard>部品（タイトルとアイキャッチはビルド時にリンク先から自動で入る） - 自作の図解や表 → 中身のHTMLをそのまま残す
部品の見た目は、本番と同じクラス名のHTMLで出力するようにしました。
こうしておくと、WordPressのときに書いたCSSがそのまま効きます。
Claude Codeで進めた移行の4ステップ
移行の作業は、ほとんどをClaude Codeに任せました。
私がやったのは、方針を決めること、Cloudflareのアカウント作成とログイン、ネームサーバーの変更、最終確認です。
進め方は次の4ステップで、ポイ活のブログを先に移し、うまくいってからこのブログを移しました。
flowchart TD
A["1. パイロット<br>全ページを変換して本番と見比べる"] --> B["2. デザインの移植<br>本番と同じクラス名で組む"]
B --> C["3. 自動化の作り直し<br>REST API互換の仕組みに差し替える"]
C --> D["4. 本番の切り替え<br>ネームサーバーをCloudflareへ"]
D -->|"問題があれば"| E["DNSを旧サーバーに戻す"]
パイロット：全ページを本番と見比べる
最初に、全記事を変換して、本番のWordPressと本文を突き合わせました。
比べるのは見た目ではなく、各ページの本文のテキストです。
このブログでは、公開中の277ページすべてが同じURLで出力されました。
途中で、壊れた形のブロックがあると、その後ろの本文が変換で消える不具合が見つかりました。
16記事で起きていて、変換スクリプトを直してから全件を変換し直しています。
デザインは本番と同じクラス名で組み直す
デザインは「今の見た目を再現する」と決めました。
Astroのレイアウトを、AFFINGERと同じIDとクラス名（ヘッダー・本文・サイドバー・目次など）で組み、本番の追加CSSをそのまま読み込んでいます。
CSSを一から書き直すと、記事ごとの細かい調整まで合わせきれません。
同じ名前にしておけば、10月に作り直したばかりの設計図ノートのデザインが、ほぼそのまま効きます。
自動化はWordPress REST API互換の仕組みで作り直す
自動化の作り直しが、この移行で一番効いた判断でした。
私の自動化スクリプトは、すべてWordPressのREST APIを通して記事を読み書きしています。
そこで、REST APIと同じ形で答える小さな仕組み（記事の台帳）を作り、サイトの設定ファイルに1行足すと、そちらへ切り替わるようにしました。
- 記事の更新・下書き・削除のスクリプトは、台帳を書き換えたあと、変換・ビルド・デプロイまで自動で行う
- 分析系のスクリプトは、WordPressの代わりに台帳を読む
- スクリプトの呼び出し方は変わらないので、スキルの手順書もほぼそのまま使える
テストは510件すべて通りました。
記事の公開は、管理画面のボタンの代わりに static_publish.py publish <記事ID> の1コマンドです。
ネームサーバーを切り替えて本番公開
最後に、ドメインのネームサーバーをCloudflareへ切り替えました。
先にCloudflareに今のDNSの設定を読み込ませ、すべて「DNS only」（今と同じ動き）にしてから変更しています。
こうすると、ネームサーバーを変えた瞬間はサイトもメールも旧サーバーのままで、何も起きません。
そのうえで、サイト本体のレコードだけをCloudflare Pagesに向けました。
問題があれば、このレコードを旧サーバーのIPに戻すだけで元に戻せます。
WordPressからの移行でハマった落とし穴5つ
移行そのものより時間を使ったのは、WordPressが黙ってやってくれていたことの洗い出しです。
WordPressでは何も考えなくて済んでいた部分が、静的サイトでは1つずつ自分の仕事になります。
実際に踏んだものを5つ、症状と対処の組でまとめます。
_redirectsが日本語URLの小文字エンコードに一致しない
Cloudflare Pagesの転送ルール（_redirects）は、日本語を含むURLを大文字のパーセントエンコード（%E3）でしか照合しません。
WordPressは小文字（%e3）でリンクを出していたので、古いカテゴリのURLが404になりました。
# 大文字の形は _redirects で転送できる
/%E7%B5%B5%E6%9C%AC/ /category/%E7%B5%B5%E6%9C%AC/ 301
# 小文字の形（%e7%b5%b5...）は一致しない → 移動用のページを置いて対応した小文字の形には、すぐに正しいURLへ移動する小さなページを置いて対応しました。
404ページが無いとソフト404になる
Cloudflare Pagesは、404ページが無いと、存在しないURLにトップページを200で返します。
Googleから見ると「中身のないページが大量にある」状態です。
404.astro を1枚作るだけで、正しく404を返すようになりました。
MXがサイト本体を向いているとメールが止まる
このブログのメールの宛先（MXレコード）は、サイト本体のドメインを向いていました。
そのままサイト本体をCloudflare Pagesに向けると、メールの行き先までPagesになってしまいます。
メール用に mail.ドメイン を旧サーバーのIPで立て、MXをそちらへ向けてから、サイト本体を切り替えます。FTP用のレコードがサイト本体を指している場合も同じです。順番を逆にすると、気づかないうちに問い合わせのメールが届かなくなります。
画像が.pngのままWebPにすり替わっていた
画像をダウンロードして静的サイトに入れたら、295個がWebP形式でした。
ファイル名は .png や .jpg のままです。
WordPressの画像最適化プラグインが、WebPを受け付けるブラウザには中身をWebPに差し替えて返していました。
ダウンロードのときに「WebPは受け付けない」と伝え直して、元の形式で取り直しています。
ドメインの登録先が思っていた会社と違った
最後に止まったのは、ネームサーバーを変える場所でした。
whoisで見ると、登録先は「お名前.com」です。
ところが、お名前.comのアカウントもパスワードも覚えていません。
ドメインの更新日は1年ごとにそろっていて、サーバー会社の契約に付いてきたドメインの可能性もありました。
最終的に管理画面を見つけて変更できましたが、ここで手が止まりました。
ドメインの管理画面がどこにあるかは、切り替えの前日までに確かめておくと安心です。
Astroへの移行が向くブログ・向かないブログ
ここまでの話で、Astroへの移行が誰にでも良いとは言えません。
向き不向きを分けるのは、ブログの規模や技術力より「誰が記事を書き、誰がサイトを直すか」です。
私のブログが向いていた理由と、向かないブログの特徴を並べます。
向いているブログ
書く人とサイトを直す人が同じ。記事をファイルで管理したい。会員機能や決済がない。
向かないブログ
管理画面で書く人が別にいる。プラグインの機能に頼っている。コメントや予約を受け付けている。
向いているのは「書く人＝作る人」のブログ
記事を書く人とサイトを直す人が同じなら、管理画面がなくても困りません。
私はもともとClaude Codeで記事を作り、HTMLをファイルで持っていたので、移行後の書き方はほとんど変わっていません。
- 記事をGitで管理したい
- エディタやClaude Codeで記事を直している
- 表示速度やセキュリティの手間を減らしたい
管理画面で更新したい人には向かない
ブラウザの管理画面で記事を書く人が別にいるブログには、向きません。
記事の更新が、ファイルの編集・ビルド・デプロイの流れになるからです。
お問い合わせフォームのような機能も、自分で用意し直す必要があります。
私は2つのブログとも、Contact Form 7の代わりにGoogleフォームを埋め込みました。
回答はGmailに通知が届くので、サーバーのメールを使わずに済んでいます。
よくある質問
WordPressからAstroへの移行について、気になりやすい質問をまとめました。
費用・期間・SEO・自動化の4点が中心で、どれも今回の2つのブログの移行で実際に確かめた内容です。
細かい手順は各見出しの本文もあわせて確認してください。
Q1. WordPressからAstroへの移行にはどれくらいかかりますか？
A1. 私の場合は、記事数約400ページのブログ2つで3日でした。作業の大半はClaude Codeに任せ、私は方針の判断・アカウントの作成・ネームサーバーの変更をしました。記事の装飾や自動化の量によって、期間は大きく変わります。
Q2. Cloudflare Pagesは本当に無料で使えますか？
A2. 個人ブログなら無料プランで足ります。2026年9月時点の公式ドキュメントでは、ビルドは月500回、1サイトのファイルは20,000個、1ファイルは25MiBまでです。
Q3. 移行でSEOの評価は落ちませんか？
A3. URLを変えなければ、評価を引き継げます。私は記事のURLを同じにし、カテゴリ変更などで変わった旧URLは301で転送しました。404ページを作ってソフト404を防ぐことも欠かせません。
Q4. AFFINGERの装飾はAstroで再現できますか？
A4. できます。AFFINGERと同じクラス名でHTMLを出す部品を作り、本番の追加CSSを読み込めば、見た目はほぼそのまま残ります。
Q5. WordPressの自動化スクリプトは使えなくなりますか？
A5. 作り直しは必要ですが、全部を書き直す必要はありません。REST APIと同じ形で答える仕組みを用意すれば、スクリプトの呼び出し方を変えずに静的サイトへ反映できます。
Q6. 移行後もWordPressのサーバーは残しておくべきですか？
A6. 切り替えから数週間は残しておくのがおすすめです。問題があればDNSを旧サーバーに向け直すだけで戻せます。解約の前に、ドメインとメールがどこで管理されているかを確かめてください。
移行して3日目に思うこと（まとめ）
この記事は、移行したあとの新しい仕組みで書いた最初の記事です。
書く手順は、移行前とほとんど変わりませんでした。
違うのは、公開ボタンの代わりにコマンドを1つ打つことと、サーバーの更新を待つ時間がなくなったことです。
- 本文の9割はMarkdownにそのまま変換でき、残りは部品に置き換えられた
- デザインは本番と同じクラス名で組めば、追加CSSがそのまま使える
- 自動化はREST APIと同じ形で答える仕組みに差し替えると、スクリプトを書き直さずに済む
- 落とし穴は、WordPressが黙ってやってくれていた転送・404・メール・画像・ドメインに集まる
まだ旧サーバーは解約していません。
ドメインとメールの行き先を片付け、数週間様子を見てからにします。
WordPressをやめた判断が正しかったかは、その解約ボタンを押す日にもう一度考えます。
サイト本体と同じ場所を向いていたら、移行の前にメール用のレコードを分けておく必要があります。dig コマンドか、DNSの確認サイトで1分で調べられます。
続きを追う：X（@Tom_Java_Tech） ／ RSS
途中経過は、また書きます。