鉄道ブログ「鉄分補給」をリニューアル。WordPress を残したまま、表側を Cloudflare Workers に移しました

何を変えたか

• WordPress：書く場所として残す。管理画面・予約投稿・画像の置き場所は今までどおり
• Worker（Cron）：10分おきに WordPress の REST API から記事を取り込み、本文から会社・路線・車両形式・駅を抜き出して D1 に入れる
• Worker（表示）：D1 からページを組み立てて返す

書く人の使い方は一切変えずに、読む側だけを作り直せるのがこの形のいいところです。

新サイトの狙いは、「記事＋カテゴリ」の並びではなく、鉄道ファンが情報を探す軸（会社・路線・形式・駅）でページを自動で作ること。たとえば「内房線」「115系」「長浦駅」のページが、記事が増えるたびに勝手に育っていきます。

切替は「ルートを1本足すだけ」にした

いちばん気を使ったのが切替のやり方です。

ドメインを Cloudflare に載せたうえで、DNS は元のレンタルサーバーを向けたまま、Workers の「ルート」でパスごとに行き先を分けました。

WordPress 側に流すパスは、Worker を割り当てない「Worker なし」のルートとして先に作っておきます。こうすると、

• 切替＝ドメイン/* のルートを1本足す
• 戻し＝そのルートを消す

だけで済みます。DNS を書き換えないので TTL を待たず、数十秒で切り替わります。WordPress のサイト URL や画像 URL の設定も触らずに済みました。

ポイントはカスタムドメインではなくルートを使うことです。カスタムドメインにすると Worker が終点になってしまい、WordPress に流す先がなくなります。

また、ネームサーバーの変更は反映や戻しに時間がかかるので、切替日より前の別の日に済ませ、数日様子を見てから切り替えました。大きな変更を同じ日に重ねない、というのは地味ですが効きます。

守るべきものを先に決めた

作り始める前に、アクセス解析と Search Console の数字を確認しました。分かったのは、

• 読者の多くが RSS リーダー経由で来ている
• 検索は Google より Bing からの流入のほうが多い

ということ。なので「リニューアルで一番守るべきは RSS 読者と検索からの流入」と決めて、そこに手間をかけました。

RSS：既読が新着に戻らないように

フィードの URL を変えたり、記事の識別子（guid）が変わったりすると、リーダー側で全記事が「新着」に戻ってしまいます。

• 記事の guid は旧 WordPress と同じ形式のまま出す
• 旧フィードの URL は転送せず、その場で同じ中身を返す

として、実際にリーダーで購読して、新サイトに切り替えても既読が崩れないことを確かめてから切り替えました。

旧 URL：全部ちゃんと転送されるか機械的に確かめる

旧サイトの ?p=記事ID のような URL は、新サイトの URL へ 301 で転送します。

ここは目視では無理なので、Search Console に出ている URL の一覧を CSV で落とし、全件を新サイトに投げて、転送を最後までたどって 200 に着くかを確かめるスクリプトを作りました。404 やループが0件になるまで直してから切り替えています。

戻したときのことも考えておく

見落としがちなのが「戻したあと」です。新サイトが返した 301 はブラウザや検索エンジンに残るので、戻した瞬間に新しい URL で来た人が 404 に当たります。

そこで、新 URL → 旧 URL の逆向きの転送ルールを、無効のまま事前に作っておきました。戻すときはルートを消して、このルールを ON にするだけです。結果的に使わずに済みましたが、これがあるだけで切替当日の気持ちがだいぶ楽になります。

切替当日

準備をしきっていたので、当日の作業は30分ほどでした。

1. 本番の設定を切替用に（検索エンジン向けの noindex を外す、正規 URL を本番ドメインに、など）してデプロイ
2. Workers のルートを1本足す
3. Cloudflare のキャッシュを削除
4. 転送・フィード・管理画面・画像・同期を確認

確認項目はコマンドと一緒にチェックリストにしておき、上から順に流すだけにしました。「何をもって戻すか」（全体が開けない状態が30分続く、RSS 経由が半分以下になる、など）も前もって決めておくと、当日迷いません。

おまけ：記事作成ツールも作った

表示側とは別の Worker で、記事を書くための小さなツールも作りました。

ニュースを集め、気になったものを Gemini で下書きにし、筆者への質問に答えて仕上げ、WordPress に「下書き」として送る流れです。

決めていたのは、筆者の意見や体験は、本人の回答にあることだけを書くこと。AI が意見をこしらえないようにして、ほかのニュースサイトとの差になる部分は人が書く、という分担にしています。公開は今までどおり WordPress の画面で人が行います。

まとめ

• WordPress は書く場所として残し、表側だけ Workers + D1 にすると、書く人の負担を増やさずに作り直せる
• ルートで振り分けると、切替も戻しも「ルート1本」で済む
• ネームサーバーの変更は別の日に
• 何を守るか（今回は RSS と検索流入）を数字で決めて、転送は全件をスクリプトで確かめる
• 戻したときの転送ルールまで用意しておく

既存の WordPress サイトを「全部作り直す」のではなく「表側だけ差し替える」やり方は、記事が多いサイトほど効果があると思います。同じようなリニューアルを考えている方の参考になればうれしいです。