WordPressをやめてAstro + Cloudflare Pagesに移行した話【実体験】

WordPressで運用しているサイトが「重い」「更新が怖い」「乗っ取られた」——こういう悩みを抱えている方に向けて書きます。

私は自社サイトを含む複数のサイトを、WordPressから Astro + Cloudflare Pages の静的構成に移行してきました。今日はその実体験を、選んだ理由・実際の手順・ハマったところ・移行して何が変わったか、そして「これは移さないほうがいい」というケースまで、正直に書きます。移行を検討している制作者の方にも、WordPressサイトの運用に困っている発注側の方にも、判断材料になればと思います。

なぜWordPressをやめたのか

きっかけは、いくつかの不満が積み重なったことでした。

まず表示速度です。WordPressはプラグインを足していくほど重くなりがちで、速度を上げようとすると今度はキャッシュ系プラグインの設定に悩まされます。

次に保守のしんどさ。プラグインに依存していると、時間が経ってから「これはどう設定したんだっけ」を思い出すのにいちいち手間がかかり、更新作業でミスも起きやすい。

そして決定的だったのがセキュリティです。私のところには、乗っ取りの相談が年に5件ほど来ていました。さらに、自社サイトでも被害に遭いました。当時 ConoHa を使っていたのですが、サーバーそのものが改ざんされ、その中に入れていた4サイトが全部やられたんです。あれはこたえました。この一件以降、私はセキュリティをかなり真剣に勉強するようになったのですが、同時に「そもそも攻撃される面を減らせないか」と考えるようになりました。

静的サイトには、WordPressのような管理画面もデータベースもPHPの実行環境もありません。攻撃される入口が、構造的にほとんどない。 これが移行を決めた一番の理由です。

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

なぜ Astro か

候補としては Next.js とも迷いました。ただ、今回のように「更新が多くない静的なサイト」であれば、Astro に分があると判断しました。

決め手は、HTML / CSS をそのまま書けることです。余計な抽象化が少なく、構造がシンプルなので、時間が経ってコードを見返したときにも理解しやすい。これは、長く保守していく前提だと地味に効いてきます。凝った仕組みより「あとで自分（や引き継いだ人）が読める」ことを優先しました。

なぜ Cloudflare Pages か

ホスティングは Cloudflare Pages を選びました。理由は単純で、無料で使えること、そして Cloudflare Turnstile（reCAPTCHA のような、フォームのスパム対策に使える認証）が一緒に使えることです。

Netlify はWebアプリ案件で使ったことがありますが、今回はなんとなく Cloudflare に。Vercel も Next.js のときに使いましたが、商用利用で有料になる点や使い勝手の面で、今は選んでいません。

GitHubと連携した自動デプロイ

Cloudflare Pages は GitHub と連携して、main に push したら自動でビルド＆公開という運用ができます。これはクライアントと仕事をするうちに「便利だな」と実感して、今はずっとこの形です。ローカルで書いて push するだけで本番に反映されるので、サーバーにFTPで上げるような手間がありません。

実際にどう移行したか

ざっくり、やることは「中身を運ぶ」「機能を作り直す」の2つです。

記事・コンテンツの移行は、WordPressの記事をエクスポートして、スクリプトやAIに通して Markdown に変換しました。自社サイトはそのまま Astro 上で Markdown でブログを書く形にしています。クライアント案件では、お客さん自身が更新できるよう管理画面を作り、データベースに保存する「WordPressライク」な仕組みを別途用意することもあります。

お問い合わせフォームは、静的サイトなのでPHPは使えません。私は Google フォーム＋GAS（Google Apps Script）を連携させて、送信後にサンキューページへ飛ばしたり、自動返信メールを送ったりする形をよく使います。前述の Turnstile と組み合わせれば、スパム対策も効きます。

ハマったところ・注意点

ここが一番、これから移行する人の役に立つ部分だと思います。正直、移行は簡単そうに見えて、意外と手間（＝費用）がかかります。

• 記事内に埋め込まれた画像の移行：投稿の本文中に大量に貼られた画像を一つずつ運ぶのが、想像以上に大変でした。ここは根気強く手作業で対応しました。
• Gutenberg（ブロックエディタ）専用ブロックの再現：WordPress独自のブロックで作られた装飾やレイアウトは、そのままでは静的側に持ってこられません。一つずつHTML/CSSで作り直す必要がありました。
• URL（パス）の変更：パーマリンクの構造が変わると、過去のURLが変わってしまいます。リダイレクトなどSEO評価を引き継ぐ手当てが要ります。

つまり「ただ移すだけ」では終わらず、動的に処理していた部分を別の形で作り直す作業が必ず発生します。見積もりのときも、ここを甘く見ないことが大事です。

移行して何が変わったか（Before / After）

• 表示速度：PageSpeed Insights のスコアが、40点→60点、80点→99点 というように、ほとんどのサイトで20点近く上がりました。
• コスト：自社サイトの例だと、かかるのはドメイン管理費だけになりました。サーバー代がまるごと不要になり、年間1万円ほどの節約です。
• 保守：基本的に手がかからなくなり、ポイント修正だけで済みます。同じくらいの規模なら、定期的な保守費用はほぼ不要になると考えています。
• セキュリティ：これが一番うれしい変化でした。乗っ取りがなくなった。 WordPress時代は、ログイン通知や不正アクセスの通知が来るたびに心臓に悪かったのですが、それがなくなって本当に気が楽になりました。

一方で、トレードオフもあります。動的にできた更新が手作業寄りになる分、部分的な更新作業の費用は上がりがちです。また、静的サイトに対応できる業者がまだ少なく、頼める相手を探しにくいという面もあります（このあたりは、作った本人が継続して見られる体制かどうかが効いてきます）。

それでもWordPressのままがいいケース

静的化は万能ではありません。無理に移さないほうがいいサイトもあります。

• コンテンツが多い／記事を量産するサイト：メディア、ポータル、ニュース系。Astroでもうまく設計すれば作れますが、コストが見合わないことが多いです。プラグインや実装が豊富なぶん、WordPress（やヘッドレスCMSのカスタム）のほうがスピーディです。
• 担当者が頻繁に更新するサイト：社内で毎日のように更新する運用なら、WordPressのままが快適です。オウンドメディアを静的化するかは、よく考えたほうがいい。
• 複雑な動的機能があるサイト：会員機能や込み入った仕組みがある場合、静的化するとかえって管理が面倒になることがあります。セキュリティリスクと天秤にかけて、WordPressを選ぶのが妥当なこともあります。

逆に、ほぼ更新のいらないサイトは、まるごと静的化したほうがいいと思います。更新頻度が低めの中規模サイトならヘッドレス化、それも不要なら素のHTML構造で静的のまま、という選び分けです。

WordPressで困っている会社へ

もし「WordPressで作ってもらったけど、重い・更新できない・放置されている・乗っ取られた」という状態なら、移行を検討する価値はあります。相談するときに、次のものが手元にあるとスムーズです。

• 現状のサーバー・ドメインの契約先と、各種ログイン情報
• なぜ移行したいのか（動機）
• 移行して何をゴールにしたいのか（目的）
• 最低限ここは残して更新したい、という部分（移行すると動的な更新箇所は減ることが多いため）

特に大事なのは、動機とゴールです。「速くしたい」のか「乗っ取りの不安をなくしたい」のか「保守費を抑えたい」のかで、最適な作り方は変わります。

まとめ

• WordPressをやめた理由は、速度・保守の手間・セキュリティ（乗っ取り）
• 移行先は Astro（HTML/CSSをそのまま書ける）＋ Cloudflare Pages（無料・Turnstile・GitHub自動デプロイ）
• 移行は「ただ運ぶ」だけでなく、画像・独自ブロック・フォームの作り直しが必要で、意外と手間がかかる
• 結果は、速度アップ・コスト減・保守ほぼ不要・乗っ取りゼロ
• ただし更新が多い／複雑なサイトはWordPressのままが向いている

静的化は、向いているサイトにとっては本当に快適です。でも、向き不向きの見極めのほうが先です。そこを正直に判断するのが、移行で失敗しないコツだと思います。

---

納品して終わりではありません。サイト公開後も相談できる制作者をお探しの方は、まずはお話をお聞かせください。