Claude CodeでWordPressからCloudflare Workersに引っ越した話。DNSを触らずに本番を切り替える
このブログを、WordPressからCloudflare Workersに引っ越しました。
結果を先に書くと、表示速度は 2.75秒 → 0.05秒、ページの転送量は 97KB → 9.3KB。本番の切り替え作業そのものは 1〜2分 で終わりました。
サイト本体をAstro（HTMLをあらかじめ全部作っておく、静的サイト用のツール）で作り直した経緯は前編に譲って、この記事は 「どこに載せるか」と「どうやって本番を切り替えるか」 の記録です。手順書というより、それぞれの場面で なぜその判断をしたか を中心に書きます。調査も設定も切り替え後の確認も、作業はClaude Codeと進めました。
この引っ越しは2本の記事に分けて書いています。 前編：サイトをAstroで作り直すまで 後編（この記事）：Cloudflare Workersに載せて、本番ドメインを切り替えるまで
Cloudflare Pagesではなく、Workersを選んだ理由
Cloudflareで静的サイトを公開する方法には、Pages と Workers の2つがあります。少し前までの定番はPagesでした。
ただ、Claude Codeに現状を調べてもらうと、Pagesはいまメンテナンスモード（機能追加が止まっていて、新規はWorkersが推奨）とのこと。それに加えて決め手になったのが、D1・KV・R2（Cloudflareが提供するデータベースやデータ置き場のサービス）は Workersからしか使えない という点です。
このブログは静的サイトなので、いまはデータベースが要りません。ただ、将来コメント欄や問い合わせの保存を付けたくなったとき、Pagesを選んでいるとそこで移行作業が発生します。Workersなら、そのとき追加するだけで済みます。
いま必要かどうかではなく、「ドアを開けたままにしておくコストがゼロなら、開けておく」 という判断です。静的な出力を置くだけならアダプタ（フレームワークとWorkersをつなぐ追加部品）も不要で、Pagesと比べて手間が増えるわけでもありませんでした。
URLから日付を抜き、旧URLは301リダイレクトで送る
WordPress時代のURLは /2026/06/06/記事名/ という 日付入り でした。新しいサイトでは /blog/記事名/ に統一しています。
日付がURLに入っていると、記事を更新しても古く見えます。技術記事は書きっぱなしにせず更新して育てるものなので、URLに日付を焼き込むのはやめました。
URLを変えるということは、検索エンジンも外部からのリンクも、全部 旧URLを見ている ということです。そこで、旧URL5本から新URLへ 301リダイレクト（「引っ越しました」という恒久的な通知。検索エンジンは評価を新URLへ引き継いでくれます）を設定しました。あわせて /feed/ → /rss.xml、/sitemap.xml → 新サイトマップも転送しています。
リダイレクトだけで済ませなかった箇所が2つあります。
- 記事内の内部リンク8本は、新URLへ直接書き換えました。 301経由でもたどり着けますが、リダイレクトを挟むとリンクの評価が目減りすると言われています。自分で書き換えられる場所は、転送に頼らず直します
/category/claude-code/は、リダイレクトではなく本物のカテゴリページとして復活させました。 同じ役割のページを新サイトにも作れるのだから、別のページへ逃がすより受け皿をそのまま用意するほうが自然だと判断しました
本番切り替え：DNSを触るのをやめた
この引っ越しで、いちばん考えたのがここです。
当初の計画は王道でした。DNS（ドメイン名とサーバーを結びつける、住所録のような仕組み）の向き先を、レンタルサーバーからWorkersへ書き換える。引っ越しの解説記事は、だいたいこの方式です。
ところが、Claude Codeに現在のDNSを調べてもらった結果、やめました。
このドメインはCloudflareのプロキシ（代理サーバー）経由で配信されていて、元のレコードの中身——種類がAレコードなのかCNAMEなのか、値が何なのか——が外から確認できません。つまり、書き換えること自体は簡単でも、戻すときに正確な復元ができない。
引っ越しで怖いのは「進めないこと」ではなく「戻れないこと」です。控えを取れないものを書き換えるのはやめて、方式を変えました。
DNSには一切触らず、Workersの「ルート」という機能で、ドメインへのリクエストをWorkersが横取りする方式 です。住所録の上では、ドメインは今までどおりレンタルサーバーを指したまま。その手前でWorkersが応答します。
この方式にした理由は、性能でも新しさでもなく、戻しやすさ です。
- 戻したくなったら、設定ファイルからルートの記述を 2行消して再デプロイするだけ。1〜2分でWordPressの表示に戻ります
- WordPress本体もレンタルサーバー上でそのまま生かしてあるので、「戻ったように見える」ではなく 本当に元の状態へ戻ります
切り替え当日は、この設定を入れて再デプロイして終わり。作業時間は1〜2分でした。あっけないですが、あっけなく済むように前段で準備した結果だと思っています。
ルート方式の落とし穴：DNSは元のサーバーを指したまま
戻しやすさを理由にルート方式を選びましたが、これは移行が落ち着くまでの一時的な措置です。最終形はカスタムドメイン方式（CloudflareがDNSレコードをWorker直結に置き換える方式）にする予定で、その理由を書いておきます。
ルート方式は、エッジ（利用者に近いCloudflareのサーバー）でリクエストを横取りしているだけで、DNSレコードは1文字も変わっていません。住所録の上では、ドメインはいまも元のレンタルサーバーを指しています。通常はWorkersが全部受けるので、元のサーバーに到達することはなく、動作に問題は出ません。
ただし、元のレンタルサーバーを解約すると話が変わります。解約すると、そのIPアドレスはいずれ別の契約者に割り当てられます。Workersが何らかの理由で処理できなかったとき、Cloudflareが「元のサーバー」へ問い合わせに行くと、見知らぬ他人のサーバーに繋がる可能性があります。確率は低いですが、放置してよい設定ではありません。
だから、解約の前にカスタムドメイン方式へ切り替えます。切り替えれば、元のサーバーのIPアドレスはDNSから消えます。解約してしまえば「WordPressに戻す」という選択肢自体がなくなるので、戻せる性質を保つ意味もなくなります。順番は ①最終バックアップ → ②カスタムドメインへ切り替え → ③動作確認 → ④そのあと解約 です。
実は一度、この切り替えを試して詰まっています。設定を書き換えてデプロイしたら、エラーで止まりました。
Hostname 'aimasakichi.com' already has externally managed DNS records
(A, CNAME, etc). Delete them first or try a different hostname.「このホスト名には既にDNSレコードがあります。先に削除してください」という趣旨です。Cloudflareが既存のDNSレコードを勝手に上書きしないよう保護している仕様で、カスタムドメインにするには、先に自分でDNSレコードを削除しておく必要がありました。なお、このとき本番は無事でした。切り替えは適用されず、元のルート方式のまま動き続けています。
この切り替えは、サーバー解約とセットでやる予定です。戻れることを優先した結果、宿題がひとつ残った——という状態です。
検索エンジンまわりで引き継いだもの
サイトの中身と同じくらい大事なのが、検索エンジンへの引き継ぎです。やったことは4つあります。
- Bing Webmaster Toolsの認証タグ（
msvalidate.01）を全ページに設置。 BingはHTMLタグでサイトの所有者を確認しているため、タグが消えると認証が外れます - Google Search ConsoleはDNS認証（DNSに確認用の記録を置く方式）だったので、影響なし。 こちらは何もしなくて大丈夫でした
- サイトマップをGoogleとBingに再送信
- Search Consoleに登録済みだった古いサイトマップURLが404になる ことに気づき、そこも新サイトマップへ301。登録済みのURLは検索エンジンが巡回し続けるので、放置すると延々と404を返すことになります
詰まったところ
すんなりいかなかった点も書いておきます。
wwwのリダイレクトが書けなかった
www 付きのURLをwwwなしへ転送する設定を _redirects ファイルに書いたところ、エラーになりました。Workersの _redirects は相対パスしか書けず、https://www.〜 のような別ホストへの転送が書けません。Cloudflare Pagesでは書ける記法なので、Pages向けの解説どおりに書くと、ここで引っかかります。
対応は「見送り」です。各ページのcanonicalタグ（「このページの正式なURLはこちら」と検索エンジンに伝えるタグ）が本体のURLを指しているため、実害はないと判断しました。
切り替え直後、「反映されてない？」と焦った
デプロイ直後にサイトを確認したら、変更前の表示のままに見えました。一瞬「失敗したか」と思いましたが、原因は キャッシュ（表示を速くするための一時保存データ）でした。キャッシュを回避して確認し直したら、正しく反映されていました。
切り替えの直後は、必ず「壊れた？」と見える瞬間が来ます。疑う順番は「まずキャッシュ、次に設定」がよさそうです。
結果：表示は2.75秒から0.05秒になった
| 項目 | WordPress | Workers |
|---|---|---|
| 表示速度 | 2.75秒 | 0.05秒 |
| 転送量 | 97KB | 9.3KB |
数字の上では55倍ですが、体感としては「待つ」という概念がなくなった感じです。
切り替え直後には、全15ページの疎通確認（ちゃんと表示されるか）と、301リダイレクト7本の転送先の全数確認 をしました。ここはClaude CodeにURLの一覧を渡して、全部アクセスして結果を表にしてもらうと数分で終わります。「たぶん大丈夫」で放置せず、その場で全部見ておくのがおすすめです。
まとめ
- PagesではなくWorkers。 いまは差がなくても、将来D1やKVを使う可能性のドアを、コストゼロで開けておけるため
- URLから日付を抜いて
/blog/記事名/に統一。 旧URLは301で転送し、内部リンクは転送に頼らず直接書き換え - 本番切り替えはDNSを触らず、Workersのルートで横取り。 正確に復元できないものは書き換えない
- 検索エンジンの引き継ぎ は、Bingの認証タグ・サイトマップ再送信・旧サイトマップURLの301まで
いちばんの学びは、「戻せる状態を作ってから切り替える」 ことです。切り替え作業が1〜2分で済んだのも、その1〜2分を不安なく進められたのも、「失敗しても1〜2分で戻れる」と分かっていたからでした。攻めの技術選定より、退路の設計のほうが引っ越しの本体だったと思います。
このブログをWordPressで開設したときの記録はこちらです。開設から3か月あまりで引っ越すことになりましたが、最初の一歩としてWordPressを選んだこと自体は、良い選択だったと思っています。