WordPressからAstro＋ヘッドレスWPに移行した手順

WordPress → Astro移行の流れ

大まかな移行の流れは以下のとおりです。

• WordPress の固定ページにあたる部分を Astro でイチから作成
• 既存の WordPress はサブドメインに移し、投稿本文を API で取得
• 投稿一覧やカテゴリーページを作成
• Cloudflare Workers にデプロイして微調整・最終確認
• DNS を切り替えて正式稼働
• サイトの状態をツールでチェックしてエラーをつぶす

なお、今回の移行はもう 1 つ「Codex 任せでどこまでできるか」という裏テーマもあり、だいたい 8 割ぐらいは Codex で処理しています。

実装計画やローカルでの Astro 環境構築も Codex です。

01. Astroでページを作成

トップページやサービスページなど、WordPress 固定ページで作成していたページはすべて Astro で作り直しました。

投稿と同じく REST API で本文を取得することもできますが、それを Astro 側で変換するのは少し手間ですし、のちのちページごとにデザインを大きく変えたかったので、この形にしています。

CSS フレームワークは Lism CSS を採用。

採用の決め手は軽量であることと、もともと使用していた WordPress テーマ「SWELL」と開発者が同じだからです（デザインの引き継ぎが何となく楽そうかな…と）。

また、どうせ作り直すなら Tailwind CSS などではなく、何か新しいものを取り入れたかった、というのもあります。

とはいえ、Codex に既存のトップページを読み込ませて HTML で作ってもらったプロトタイプはこんな仕上がりでした。

「任せたらどうなるか」を見たかったので、詳細なプロンプトや DESIGN.md を用意しておらず、よくある AI サイトになっています。

たぶん英語圏のサイトをベースに学習しているからこういうデザインになるんでしょうね。

限界までシンプルにしてからデザイン変更していくのがよさそうに思えたので、以下の指示を出して作り直してもらいました。

• 角丸禁止
• box-shadow 禁止
• バッジの廃止
• ボタンに見えるパーツの廃止
• font-family と font-size の指定

トップページがある程度完成したあと、それを基本デザインとしてサービスページやお問い合わせページを追加していきました。

プライバシーポリシーなどは、エクスポートした固定ページをマークダウンに変換したものを Codex に渡し、最低限のデザインを適用したものにしています。

WordPress投稿をマークダウンに変換してAIで分析する方法

02. 投稿はヘッドレス化したWordPressから取得

投稿ページは既存の WordPress 投稿をそのまま使うことにしました。

本番環境の WordPress をサブドメインに丸ごとコピーし、そこから REST API で必要な情報を取得・加工。meta description や構造化データは、Yoast SEO のデータを取得しています。

この方式のメリットは、何百ページも作り直す必要がなく、今後の投稿もそのまま WordPress が使える点です。

デメリットは、画像 URL がサブドメインになることと、ビルドに少し時間がかかる点でしょうか。

画像に関してはドメインが変わるだけなのでリダイレクトできますし、ビルド時間も現在のページ数（約 300）で 60 秒前後です。

頻繁に更新することがないサイトや、今後はマークダウンで書いたり AI 任せにする場合は、ヘッドレス WordPress ではなく、すべて Astro で作り直したほうがよいかもしれません。そのサイトによりけりです。

デザインは、Codex に元の投稿を分析させて、必要な CSS を移植してもらいました。もちろん Lism CSS に合うように変換させています。

テーマやプラグインの CSS をすべてインポートするのが手っ取り早そうですが、その場合は「永遠に使わない CSS」も取り込んでしまいます。

たぶん、テーマやプラグインの一部しか使っていないことがほとんどだと思いますので、自分がよく使っていたものだけ取り込んでメンテナンス性や表示速度を改善するのがおすすめです。

手作業だと気の遠くなる内容ですが、AI を使えばそれほど手間ではありません。

03. 投稿一覧などアーカイブページを作成

WordPress で自動生成される各アーカイブページは、Astro で作り直しです。

幸いにも当サイトでは著者アーカイブや日付アーカイブ、タグアーカイブは使っていなかったので、全記事一覧とカテゴリーページの作成だけで完了しました。

このあたりはサイトの構成によって異なります。

Lism CSS のパターン集と、もともとのアーカイブページデザインを参照させてほぼ一発で作れました。

ページャーは前後のページ移動に加え、ページ番号入力方式にしており、これが正解なのかは今後のデータ次第といったところですね。

WordPress 既製テーマだとちょっとした変更でも手間がかかりますが、Astro だとすぐ変更できますしコンポーネント化（パーツ化）して使いまわせます。

必要なページだけ作れる＆コンポーネント化できるのは Astro のメリットであるものの、自動生成の WordPress に慣れていると少し面倒に感じるかもしれません。

どのページが必要になるか、あらかじめ整理しておいたほうがスムーズです。

04. Cloudflare Workersにデプロイ

ローカルで一通り作ったあと、GitHub 経由で Cloudflare Workers にデプロイしました。

GitHub も Cloudflare も Codex につなげてあり、設定の 9 割ぐらいは Codex 任せ。自分で行ったのは、シークレット関連の設定と最終確認ぐらいです。

「Cloudflare を使いたい」と AI に伝えると高確率で Pages を使おうとしてくると思いますが、これから始めるなら Workers をおすすめします。

Now that Workers supports both serving static assets and server-side rendering, you should start with Workers.

Workers は静的アセットの配信とサーバーサイドレンダリングの両方をサポートするようになったため、まずは Workers から始めることをおすすめします。

Your frontend, backend, and database — now in one Cloudflare Worker

デプロイ後は以下の部分を追加実装・調整しました。

• 内部検索の実装
• パンくずリストの実装
• SEO まわりの整理（meta description や構造化データなど）
• robots.txt や XML サイトマップの実装
• Google アナリティクス等のタグ実装
• お問い合わせフォームの動作設定
• ヘッダーやフッターまわりの調整

最後に一通りチェックして、リニューアル準備完了です。

• GitHub に Push してビルドが走るか
• WordPress との通信は成功するか
• セキュリティまわりに問題はないか

05. DNSを切り換えてWorkersに接続

当サイトは、すでに AdSense 審査チェッカー を Workers で動かしていたこともあり、NS（ネームサーバー）は Cloudflare に向いていました。

メインの A レコードだけエックスサーバーに向いていた状態なので、Workers でカスタムドメインを設定して切り替えるだけで載せ替え完了です（切り替え時間は 10 秒ぐらい）。

これからネームサーバーを切り換える場合、各レコード（A / MX / TXT）を調べて設定し直すことになりますが、AI に聞けば教えてくれますし、Cloudflare 側の設定は代行してくれます。

ただし、サブドメインを別サーバーで運用していたり、メールを Google Workspace 等につなげているなら、その正確な情報をすべて伝えないとどこかで何かが止まるかもしれません。

ふんわりした質問をすると一般的な回答になるケースが多いので、スクショするなりサーバーに API 接続するなりして、正確な情報を伝えてください。

XServer API | レンタルサーバーならエックスサーバー

それでも心配な場合は、専門家に丸投げするのがよいと思います。

06. サイト公開後はツールで状態チェック

リニューアル完了後、Codex にローカルと本番公開サイトを比べてもらい、不足している点がないかチェックしてもらいました。

でもそれだけでは見落とした部分がありそうなので、以下のツールでサイトの状態を改めてチェックしています。

• Google Search Console
• Bing Webmaster Tools
• Ahrefs

このなかで最も役に立ったのは Ahrefs のサイト監査機能です。

所有権確認を行えば監査機能は無料で使え、404 や meta タグの不足等を細かくレポートしてくれます。即時クロールを依頼できますから、リニューアル直後を含め常用をおすすめします。

当サイトでは 404 と構造化データの欠陥が見つかり、すぐ修正できました。

Ahrefs Free｜サイトを成長させる無料の SEO・マーケティングツール

Astro移行時の細かなポイントと注意点

WordPress から Astro に移行するさい、あらかじめおさえておきたい細かなポイントと注意点をいくつかお伝えします。

カスタムフィールドはどうするか

カスタム投稿タイプは REST API で取得でき、カスタムフィールドもよほど複雑でなければ問題なく取得できると思います。

いったん AI に API で情報を取得してもらって中身を確認してみてください。もし取れていないものがあれば GraphQL を使えば大丈夫です（あとからでも変更可）。

なお、当サイトは SWELL の「カスタム CSS」を CSS デザイン系の記事 で使用しており、そのコードは手動でコピペして移植しました。

カスタムフィールドを使っている記事もいくつかありましたが、本文に直接書いたり Astro 側で調整したりして移植してあります。

お問い合わせフォームはどうするか

WordPress プラグイン「Contact Form 7」は REST API に対応しているので、フォーム構成をそのまま移植できるようです。

WordPressお問合せフォームをAPIで【Contact Form 7 REST API】

でも、そのまま使おうとすると設定でいろいろつまずくと思いますので、Astro 側で新規作成をおすすめします。

当サイトは Google Workspace を使用しており、Email Sending を採用しました（Workers 有料プランが必要です）。

もちろんスパム防止のために Turnstile も使っています。できるだけ Cloudflare 内で完結する方向に寄せた感じです。

投稿下書きのプレビューはどうするか

今回はもともとの WordPress をサブドメインにコピーしてヘッドレス化しており、プレビューは通常の WordPress 機能が使えます（サブドメインでプレビューが開く）。

もし本番環境と同じようにプレビューしたいなら、以下の方法が考えられます。

• WordPress テーマを本番環境に似せて作る
• Astro にプレビュー専用ルートを作る
• プレビュー専用の環境を別途構築する
• 下書き保存時にプレビュー用ビルドを走らせる（リアルタイムは不可）

たとえば新規制作案件で WordPress は Twenty 系のテーマを適用しており、本番環境ではまったく違うデザインになっているなら、プレビュー環境も用意しておかないとクライアントが戸惑うかもしれません。

もとの環境をベースにリニューアルして自分だけで使うなら、さほど気にしなくてよいかと思います。

ちなみに、下書きのプレビュー用ではなく、公開済み投稿を本番環境で確認する用のリンクだけ付けました。

フィルターフックで実装できます（各投稿編集画面にも付けられます）。

add_filter('post_row_actions', function ($actions, $post) {
    if ($post->post_type !== 'post') {
        return $actions;
    }

    if (empty($post->post_name)) {
        return $actions;
    }

    $production_url = 'https://example.com/' . ltrim($post->post_name, '/') . '/';

    $actions['seory_production_view'] = sprintf(
        '<a href="%s" target="_blank" rel="noopener noreferrer">本番環境表示</a>',
        esc_url($production_url)
    );

    return $actions;
}, 10, 2);

投稿編集・公開後のデプロイはどうするか

WordPress の既存の投稿を編集、または新規公開したあと、Astro のビルド・デプロイが必要です。

いちいち Cloudflare 管理画面で操作するのは面倒なので、WordPress から手動デプロイするよう設定しました。

最初は WP Webhooks で公開状態を検知してビルドを自動的に走らせるようにしたのですが、なぜかコンマ数秒で 2 回 POST してしまって上手くいきません。Gutenberg の仕様が関係していると思われます。

これは Durable Object alarm で対応できました。alarm を 15 秒に設定し、最後の更新通知から 15 秒経過したら Deploy Hook を叩きます。

でも、「公開」をクリックするたびにビルドを走らせるより、手動デプロイのほうが性に合っていたので、現在は自動デプロイ機能は止めてあります。

通常の WordPress のように、「公開＝即時反映」ではない点だけご注意ください。サイトの構成により、ビルドからデプロイまで数十秒～数分かかります。

逆に言えば、誤操作等で公開してしまうことはなくなるので、一長一短です。

Astro移行をAIに任せるさいのポイント

WordPress から Astro への移行計画を立て、完了するまで 14 日ほどかかりました。普段の作業と並行して進めたので、きっちり集中すれば 1 週間もかからなかったと思います。

Codex は Pro（5x）の週間リミットを 2 回使い切り、10,000 円もかかっていない計算です。

サイトの規模にもよりますが、Codex Plus でも 1 か月ほどで移行できるかもしれません。ふつうに外注すれば数十万円はかかるでしょうから、それに比べればかなり安く移行できますね。

それでも AI に任せきれない点や、手作業のほうが早い部分もあります。

細かい変更はまとめて行う

Codex 内蔵ブラウザでプレビューを表示し、そこで注釈を付けて変更指示を出せるのはものすごく便利です。

しかし、ただ変更指示を出すだけだと、毎回「変更 → check → build…」となり、ビルド完了まで数分待機しなければなりません。そのたびにトークンも消費してしまいます。

ページ内の複数箇所を変更するなら、「ほかにも変更箇所があるから、指示するまでビルドしないで」と伝えておいたほうがよいです。

または、check や build を自分で行えば時間短縮＆トークン節約につながります。コミットやプッシュも、AI 任せより手作業のほうが楽なこともあるでしょう。

Astro や Git の知識がなくてもすべて AI に丸投げできると思いますが、すべての作業を自分でもできるようにしておかないと、どこかで詰まるかもしれません。

文章やclass変更は手作業のほうが早い

実のところ、数文字の修正やちょっとしたデザイン変更は、Codex に依頼するより自分で直したほうが早いです。

VS Code などでファイルを開き、修正・保存。そのままビルドからプッシュまで行えば、内容によっては数分は短縮できます。

VS Code の Codex 拡張機能は単独で動作しているわけではなく、デスクトップアプリのトークがそのまま反映されます。ちょっとした修正は自分で行いつつ、時間がかかりそうな修正は並行して修正させるのが最速かもしれません。

それか、最初から Cursor で開発するのもありですね。個人的には Claude Opus に計画を立ててもらい、Composer や Codex にコードを書かせるのが好きです。

SEO関連は任せきれない

「SEO まわりの設定を整えて」というあいまいな指示だと、まず一発で成功しません。

SEO 関連の情報を一通り検索するさい、推奨されないような情報まで拾ってしまうからだと思います。

また、「この h1 要素を削除して」と伝えたら、<h1> を残したまま CSS で強引に削除するような動きも見られました。これは指示側にも問題はあるものの、何もチェックせず通していたらあまり好ましくないサイトになってしまいます。

見出しの順番がぐちゃぐちゃでも検索評価に直接的な影響はありませんが、可能なかぎりセマンティックな構造を保っておくに越したことはありません。

なお、Codex が一通り実装したあとに Claude に全体チェックをしてもらったら、SEO 関連の不備はほぼ指摘してくれました。複数ファイルを横断してのチェックは Claude のほうが得意なように感じます。

それでも、すべて AI 任せにするのは多少の不安があり、人間の最終チェックは必要だと思います。

完璧な資料を渡すのも、細かい指示を出すのも、それが正しいものだと判断できるのは人間です。

WordPressよりAstroのほうが速い？

WordPress から Astro に変更し、体感できるレベルで表示は速くなりました。とくにスマホ表示は明らかに速くなっています。

とは言うものの、もともとの WordPress も表示速度に不満はなく、検索評価や売り上げに影響するようなレベルではありません。差は 1 秒未満の自己満足の世界です。

サーバーや WordPress の知識がなくても、SWELL ＋ エックスサーバーを使っていれば十分高速です。もしそれで遅いと感じるなら、たぶん不要な施策をしてしまっているか、プラグインの干渉が原因でしょう。

参考までに PageSpeed Insights のパフォーマンススコアはこのような感じでした。

ただし、このスコアは表示速度ではありません。表示速度を指しているのは上部の「実際のユーザーの環境で評価する」のグラフのほうです。

スコア 80 のサイトが、実際は 60 のサイトより遅いことも多々ありますので、スコアだけを目安に考えないでください。

さらに言えば、表示に数十秒かかるレベルでなければ検索順位には影響しません。

できるだけプラグインに頼らず WordPress を高速化する 9 つの方法

当サイトは投稿内の画像を別サーバー（WordPress）から読み込んでおり、そのあたりが少しネックになってはいますが、しばらくこのまま様子を見てみようと思います。

まとめ

WordPress にも Astro にもそれぞれのよさがあり、どちらかが絶対的におすすめということはありません。

毎日のように投稿したり手軽に機能を追加したいなら WordPress が向いていますし、ほとんど更新しないサイトなら Astro のほうが向いています（Cloudflare ならサーバー代 0 円も可能）。

個人的に感じた移行のメリットは、管理面や表示速度の改善以外に、「移行により強制的にサイトを修正しなければならない」という点です。

サイト運営が少しマンネリになってきた or つまらなくなってきたら、何か 1 つでも新しい要素を取り入れてみるとやる気が出てきますよ。

もし Astro 移行を検討しており、代行やサポートが必要であればお気軽にご相談ください。