WordPressの引っ越しは、思っていたほど大工事ではなかった

WordPressからCloudflareへ。移行を機に、サイトそのものを作り直した話

WordPress のサイトを別の仕組みに移す。そう聞くと、かなりの大工事を想像すると思います。私もそうでした。

ところが、以前に個人サイト（chiakidokai.com）を Cloudflare に移したとき、拍子抜けするほどあっさり終わりました。たまたまかもしれない、と思っていたので、今回は会社のサイト（onmitsu.co.jp）でも試してみました。

結論から書くと、今回も「思っていたほど大工事ではなかった」です。ただし、引っ越しのついでにサイトの中身もかなり作り直しました。この記事は、その記録です。

なぜ WordPress を離れようと思ったのか

先に書いておくと、WordPress が悪いという話ではありません。これまで会社サイトを運用するうえで、十分に役立ってきました。

それでも移行を考えた一番の理由は、表示速度でした。

WordPress のときから、ページの構造や画像、SEO、表示速度にはかなり気を使ってきました。決して何もしていなかったわけではありません。それなりに改善してきたつもりです。

ただ、だんだん頭打ちも感じていました。

ここから先を大きく変えるなら、PHP でページを生成する WordPress のまま細かな調整を重ねるより、最初から静的な HTML を配信する構成へ移した方がいいのではないか。そんなことを考えるようになりました。

もうひとつ期待していたのは、運用とセキュリティです。

WordPress では、本体、PHP、テーマ、プラグインを継続的に更新していく必要があります。静的サイトにすれば、そうした動的な仕組みを大きく減らせます。もちろん、静的サイトなら何もしなくても安全、という意味ではありません。ただ、会社案内を中心としたサイトに、これだけの実行環境を持ち続ける必要があるのか、とは感じていました。

WordPress 時代も、更新作業そのものはかなり自動化していました。テーマは GitHub で管理し、GitHub Actions からサーバーへ反映していたので、私自身が FTP を開いてファイルを入れ替えるような運用ではありませんでした。AI にテーマを修正してもらうこともできていました。

それでも、WordPress、レンタルサーバー、PHP、プラグイン、GitHub Actions と、いくつもの仕組みをまたいで動いています。

Astro でサイトを作り、GitHub から Cloudflare Pages へデプロイする構成にすると、その距離がかなり短くなります。

AI との作業の仕方も少し変わります。

以前は、あとで人間が保守できるように、CSS やページ部品をできるだけ共通化し、変更箇所を減らすことを強く意識する必要がありました。もちろん今でも、共通化されたコードの方が健全です。

ただ、生成 AI がコード全体を見ながら更新できるようになると、「どこを共通化するか」「同じ修正が必要な場所はどこか」を、人間がすべて覚えて管理する必要はなくなってきました。

ページごとに少し違う表現を試しても、あとから AI に重複を見つけてもらい、共通部分をまとめ直すことができます。

共通化が不要になったのではなく、共通化を維持するための負担を、人間だけで抱えなくてよくなった。これは、今回サイトを作り直していて感じた大きな変化でした。

そしてもうひとつ、レンタルサーバー代の使い方です。

会社サイトを公開するためだけにサーバーを維持するより、その費用を VPS など、実験や業務システムを動かす環境へ回した方が、いまの自分たちには意味がある。そんな判断もありました。

どうせ引っ越すなら、サイトそのものを見直そう

移行の方法として、いまのサイトをそっくり再現する、という選択肢もありました。デザインも構成も同じで、置き場所だけ変える方法です。

今回はそうしませんでした。会社の軸を「意味の監査」に置き直したところだったので、サイトの見せ方もそれに合わせたかったからです。

見直したのは、たとえば次のようなところです。

トップページの最初の一文と、全体のデザイン
サービスの探し方（「課題から探す」と「実務から探す」の 2 つの入口）
「意味の監査」の説明ページ
会社概要と代表メッセージ
プライバシーポリシーと特定商取引法に基づく表記

一方で、変えないと決めたものもあります。それが次の話です。

一番心配だったのは「古い資産を壊すこと」だった

新しいサイトをきれいに作ることより、心配していたのはこちらでした。

旧サイトには、これまでに積み上がったものがあります。検索から読まれている記事、採用ページ、海外企業向けの英語サイト（Japan Desk）、AI 研修の料金ページ。採用ページには、ChatGPT から紹介されて来る人が少なくありませんでした。

ここで URL を変えたりページを消したりすると、検索や AI からの流れが切れてしまうおそれがあります。

そこで最初に「 既存の URL は原則そのまま残す 」と決めました。新しいデザインに合わないページがあっても、捨てずに同じ住所で表示する。整理したいページは、理由があるものだけ個別に判断する。この方針を先に置いたことで、後の作業で迷うことが減りました。

旧 WordPress の資産をそのまま運ぶ仕組みを作った

「残す」と決めても、手作業で一枚ずつ作り直していたら終わりません。

そこで、旧サイトのページを取り込んで、同じ URL のまま新しいサイトで表示する仕組みを用意しました。ページの性格に合わせて、3 つの載せ方を使い分けています。

採用や Japan Desk のように、いまも問い合わせを生んでいるページは、旧デザインのまま表示する
サービスの詳しい説明などは、中身はそのままに、新しいサイトの枠の中で表示する
記事は、本文と公開日を保ったまま、新しい記事レイアウトで表示する

画像などのファイルは、Cloudflare の保存領域（R2）に旧サイトと同じパスで置きました。お問い合わせ・採用応募・資料請求など 6 つのフォームも、自動返信メールや完了ページを含めて作り直しています。

数でいうと、移したのは固定ページなど 90、記事 69、画像などのファイル 795 です。

思っていたより、ずっと早くここまで来た

着手から本番の切り替えまでは、約 1 日半でした。ただ、その間ずっと作業していたわけではありません。睡眠やほかの仕事の時間も挟んでいて、私自身が画面の前で判断や操作をしていた時間は、体感では数時間程度でした。

役割分担は、はっきり分かれていました。

AI（Claude Code）が担当したのは、旧サイトの棚卸し、ページの取り込み、画像の移し替え、フォームの作り直し、リンク切れの確認、検索向け設定の比較、表示速度の計測、切り替え後の確認です。

私が担当したのは、何を残して何を変えるか、会社をどう見せるか、法務文書の中身、そして本番に切り替えるかどうかの最終判断でした。

時間がかからなかった理由は、量の多い確認作業を AI がまとめて引き受けたことが大きかったと思います。ただ、これは小さな会社の、比較的シンプルなサイトでの一例です。どんなサイトでも同じように進むとは考えていません。

表示速度はどう変わったか

移行前の旧サイトと移行後のサイトを、同じ 6 ページ・同じ条件で 3 回ずつ計測しました。使ったのは Google の Lighthouse で、代表値は 3 回の中央値です。

先に断っておくと、これは「Cloudflare にしたらどれだけ速くなったか」の比較ではありません。置き場所だけでなく、デザインも HTML も画像の扱いも変えています。比べているのは、旧サイトと、まるごと作り直した新サイトです。

最初の計測では、スマートフォンのスコアが下がっていた

作り直したのだから当然速くなっているだろう。そう思って、切り替えの翌日に本番を計測しました。

ところが、スマートフォンでのスコアは、ほとんどのページで旧サイトと同じか、むしろ下がっていました。記事ページは 54 から 42 に落ちていました。

調べてみると、原因はサーバーの置き場所ではありませんでした。見つかったのは、移行の途中で起きていた次のようなことです。

アクセス解析のプログラムが、2 つの経路から重ねて読み込まれていた（読み込みが重なっていただけで、アクセスの記録が二重になっていたわけではありません）
旧サイトの解析設定の中に、意図せず別の解析ツールが残っていた
記事の画像を、ページを開いた時点ですべて読み込んでいた（旧サイトも同じ読み込み方で、新しい記事ページでも画像の読み込み方を決めていなかった）

前の 2 つは、旧サイトでは裏で動いていて、移行のときに気づかなかったものです。旧サイトではプラグインが解析の読み込みを「画面が操作されるか、5 秒経つまで」遅らせていましたが、その仕組みは移行で引き継がれていませんでした。3 つ目は、計測をきっかけに新しく見直したものです。解析の読み込みを 1 本にまとめ、残っていたツールを止め、記事の画像を「見えるところまで来てから読み込む」形に整理して、もう一度同じ条件で計測しました。

直したあとの結果

ページ	スマホのスコア	主要なコンテンツが表示されるまで（LCP）	スマホで読み込むデータ量	アクセシビリティ
トップ	56 → 82	10.1 秒 → 4.1 秒	約 1.1MB → 約 0.2MB	93 → 96
意味の監査	58 → 79	9.1 秒 → 4.2 秒	約 1.1MB → 約 0.2MB	94 → 96
AI 研修の料金	57 → 64	5.6 秒 → 4.8 秒	約 1.3MB → 約 0.3MB	94 → 96
記事	54 → 90	5.8 秒 → 3.3 秒	約 11.3MB → 約 0.9MB	85 → 96

作り直したページは、スマホのスコアも、表示が終わるまでの時間も、読み込むデータ量も改善しました。パソコンでのスコアも、この 4 ページは 89〜94 になっています。

ただ、これは「移行しただけで速くなった」結果ではありません。計測で、移行時に抜け落ちていた点や見直すべき点を見つけ、それを直した結果として改善したものです。

一方、旧デザインのまま残した採用ページと英語サイト（Japan Desk）は、スマホで主な表示が終わるまでの時間がむしろ長くなり、課題が残りました。旧サイトでは解析の仕組みを「訪問者が画面を操作するか、5 秒経つまで読み込まない」設定にしていたので、計測上は解析の分が含まれていませんでした。新サイトでは、操作しないまま離れた訪問も計測から落とさないよう、ページを開いた時点から計測しています。その分も数字に入っています。旧デザインのページは、これから個別に見直していきます。

移行したあとに測ったから、見つかった

今回いちばん大事だと思ったのは、数字が良くなったことより、移行後にきちんと測ったからこそ「移行で失われた機能」や「見直すべき点」に気づけたことです。

旧サイトでプラグインが黙ってやっていた仕事は、移行するときに見落としやすい。速さの数字は、その見落としを見つける手がかりにもなります。

数字では見つからない不具合もあった

一方で、計測だけでは見つからなかった問題もありました。

本番切り替え前にページを見ていて、「いくつかのページだけ、左右の余白がなくなっている」と気づきました。

AI に調べてもらうと、旧サイト用の CSS と新しいレイアウトの CSS がぶつかっていて、同じ仕組みを使う 44 ページに影響していることが分かりました。ページごとに直すのではなく、共通する原因を 1 か所修正して解消しました。

ここは、AI が自動で見つけたわけではありません。人が「なんか変だ」と気づき、AI が原因と影響範囲を調べて直した。

今回の移行では、この組み合わせが何度もありました。

見た目を刷新しても、重くする必要はなかった

サイトを作り直すとき、見た目を良くしようとすると、大きな画像や動きのある演出を足したくなります。それで重くなってしまうことは珍しくありません。

今回は、トップページの背景や説明用の図を、写真ではなく線と点の図（SVG）で描きました。新しく追加した写真はありません。

図を追加する前と後で、公開前の確認用サイトのトップページを 3 回ずつ計測しました。表示速度のスコアは追加前後とも、スマートフォンで 99、パソコンで 100。読み込むデータ量は 15KB から 18KB への増加にとどまり、画面のずれ（CLS）も 0 のままでした。

見た目を刷新しても、作り方次第で重くする必要はない。今回の実務で確かめられたことのひとつです。

速くなったこと以外に変わったこと

表示速度より、運用面での変化のほうが大きいかもしれません。

テーマだけでなく、ページの中身まで含めて Git で管理され、いつ何を変えたかが残る
変更はまず確認用のサイトに出して、問題なければ本番に出す流れになった
どの URL があり、どこへ転送しているかが一覧になった
フォームの送信先や設定が、文書として整理された

切り替えから 24 時間の様子も書いておきます。あらかじめ決めておいた「元に戻す条件」（ページが表示されない、フォームが届かない、画像が欠ける、など）には、ひとつも当てはまりませんでした。旧サイトの URL を含む 204 の URL を確認し、200（正常表示）が 167、301/302（転送）が 37、それ以外は 0。エラー画面（404 / 5xx）は出ておらず、画像の配信、フォーム、SSL も正常でした。

旧 WordPress は、まだ止めていません。何かあればすぐに戻せるよう、しばらくそのまま残しておきます。

WordPress から Cloudflare へ移せばいい、という話ではない

ここまで読むと、「WordPress はやめたほうがいい」という話に見えるかもしれません。そうではありません。

今回のやり方が向いているのは、たとえば次のようなサイトです。

ページ数が数百程度までで、内容がそれほど頻繁に変わらない
動きのある機能は、お問い合わせフォームとお知らせくらい
Git で変更を管理できる担当者がいる（または AI と一緒に管理できる）

逆に、ネットショップ（WooCommerce など）、会員サイト、たくさんのプラグインに頼った仕組み、複数人が管理画面から毎日記事を書く運用などは、WordPress のままのほうが合っていることが多いと思います。

引っ越すなら、同じ家具を同じ場所に戻さなくていい

今回いちばん大きかったのは、移行を「サーバーの引っ越し」ではなく「サイトの作り直し」として考えたことでした。

引っ越しのとき、前の家と同じ家具を同じ場所に並べる必要はありません。新しい家に合わせて、置き方を変えてもいい。

ただ、思い出のある家具（これまでの URL や記事、画像）は捨てずに持っていく。今回の移行は、その両方をやったものだったと思います。

今回分かったこと

WordPress からの移行は、思っていたほど大工事ではなかった。2 回目でも同じ印象だった
移行を機に、サイトの見せ方と構造を見直せた
古い URL と資産は、仕組みを用意すれば捨てずに運べる
量の多い確認作業は AI に任せ、判断は人が持つ、という分担がうまく働いた
見た目を刷新しても、作り方次第でサイトは重くならない

2026年10月11日追記： 旧サイトの HTML を再確認し、画像の遅延読み込みに関する記述を訂正しました。旧サイトでプラグインが遅らせて読み込んでいたのは主に解析タグで、記事の画像は遅延読み込みされていませんでした。