WordPressから静的サイトへ移行する前に｜それぞれのリスクと、移すと起きること

WordPressと静的サイトは「ページを組み立てるタイミング」が違う

狙われやすさも、表示の速さも、移したときに何が動かなくなるかも、元をたどるとこの1つの違いから来ています。ここを押さえておくと、このあとのリスクの話が「なぜそうなるのか」までつながるので、少しだけ付き合ってください。

WordPressは、読者が開くたびにページを組み立てる

WordPressのサイトを読者が開くと、その瞬間にサーバー（サイトを置いている場所）の中でプログラムが動きます。記事の文章をデータベース（記事や設定をしまっておく入れ物）から取り出して、見た目の部品と組み合わせ、1枚のページにしてから読者に返す。

これを、読者が開くたびに毎回やっているんです。だから、コメントを受け付ける、サイトの中を検索する、問い合わせを送る、のような「読者の操作に合わせて中身が変わること」が簡単にできる。

そのかわり、外から届いたものを受け取って動くプログラムが、置き場所でいつも待っていることになります。これが、次の章で書く狙われやすさの元です。

静的サイトは、完成したページを置いておくだけ

静的サイトは、組み立てを先に済ませておきます。記事を書いたら、公開する前に全部のページを完成した形に作って、それを置き場所に並べておく。読者が開いたら、置いてあるページをそのまま渡すだけ。

渡すだけなので、速いんですね。読者が開くたびにプログラムが動くわけではないので、外から何かを送り込まれても、受け取って動くものがありません。

そのかわり、読者の操作に合わせて中身を変えるのは苦手です。コメント、サイト内の検索、問い合わせのフォームは、そのままでは動かない。ここは4つ目の章でくわしく書きます。

ページを一気に作る「組み立て係」の道具

「静的サイトジェネレーター」という言葉もよく出てきます。記事のファイルと見た目のひな形を読み込んで、完成したページを一気に作り出す道具のこと。名前はいくつもありますが、覚えなくて大丈夫です。

記事は、Markdown（見出しの前に「#」をつけるような、簡単な記号で書く文章のファイル）で書くことが多い。WordPressの管理画面で打っていた記事が、パソコンの中のファイル1つ1つに変わるイメージですね。

WordPressは読者が開いたときに組み立て、静的サイトは公開する前に組み立てる。違いはこれだけで、速さも安全も手間も、ここから決まります。

WordPressが狙われる理由と、移さずにできる対策

「WordPressは危ない」とよく言われますけど、WordPressの本体が特別に穴だらけ、というわけではないんです。狙われる理由は、WordPressの置かれている状況のほうにあります。

使っている人が多いと、1つの穴がたくさんのサイトに効く

脆弱性というのは、プログラムの中にある、外から悪用できる穴のことです。

攻撃する側から見ると、使っている人が多い仕組みほど割がいい。1つ穴を見つければ、同じ追加機能（プラグイン。WordPressにあとから入れる機能の部品）を入れているサイトの全部に、同じ手が通るからです。なので、1つ1つのサイトを人が選んで狙うというより、プログラムが自動でネット中のサイトを回って、古い部品が入っていないかを探しています。

「うちみたいな小さいブログ、誰も狙わないでしょ」が通用しないのは、このせいなんですよね。サイトの大きさは関係なくて、古い部品が入っているかどうかで当たる。

ログイン画面の場所が、どのサイトでも同じ

WordPressの管理画面にログインするページは、何もしなければ、どのサイトでも同じ場所（URLの最後が wp-login.php）にあります。場所が分かっているので、そこへパスワードを片っ端から試す攻撃が来る。

パスワードが短い、ほかのサービスと同じものを使っている。こういうサイトは、ここで破られます。

追加機能は、作っている人がばらばら

追加機能は、世界中のいろいろな人や会社が作っています。こまめに直している作者もいれば、何年も前に更新が止まったまま、という作者もいる。

更新の止まった追加機能に穴が見つかっても、直す人がいません。入れているサイトは、穴が開いたまま待つことになります。WordPressの本体をいくら最新にしても、ここは防げないわけです。

乗っ取られると、何が起きるのか

乗っ取られたサイトで起きやすいのは、こういうことです。

• 記事を開いた読者が、知らない広告のページや怪しいサイトへ飛ばされる
• 自分の知らないページ（薬や賭けごとの宣伝など）が、サイトの中に大量に作られる
• 検索結果に「このサイトはハッキングされている可能性があります」と出て、クリックされなくなる

厄介なのは、自分で管理画面を開いても気づきにくいこと。ログインしている人には普通のページを見せて、検索から来た人だけを飛ばす、という手口もあるので。

WordPressのままでも、ここまではやっておく

移さなくても、狙われにくくすることはできます。

2段階の確認というのは、パスワードのあとに、スマホのアプリに出る番号も入れないとログインできなくする仕組みです。

とくに1つ目は、知らない人が多いと思うんですよね。停止すれば無害になる、と僕もずっと思っていましたし。

これが一番効いてくるのは、サイトを買ったときです。買ったサイトにも、前の持ち主が入れた追加機能がそのまま残っていて、使っていないものがいくつも混ざっていました。サイトを買うと、記事や読者と一緒に、前の持ち主の古い部品まで引き継ぐんですよね。

バックアップは「取っている」だけでは足りません。戻そうとして初めて、画像のフォルダが入っていなかったと気づく、ということも起きるので。

静的サイトにもリスクはある。守る場所が変わるだけ

ここまで読むと、静的サイトにすれば安心に思えますよね。たしかに、置き場所で待っているプログラムがないぶん、WordPressと同じ形の攻撃はほぼ当たりません。でも、リスクが消えるわけではなくて、守る場所が別のところに移るんです。

置き場のアカウントを取られたら、全部書き換えられる

静的サイトは、完成したファイルをどこかに置いて公開します。よくあるのは、記事のファイルをGitHub（ファイルの変更を記録して保管しておけるサービス）に置いて、Cloudflare Pages（静的サイトを置いて公開できる、Cloudflareのサービス）がそれを読んでサイトにする形です。

この形だと、守るものは置き場所ではなく、GitHubやCloudflareのアカウントになります。ここにログインされたら、サイトの中身は全部書き換えられる。パスワードを長くする、2段階の確認を入れる、はWordPressのとき以上に大事になります。

外のサービスに任せた部分は、相手の都合で止まる

問い合わせのフォームやコメントのように、読者が送ってきたものを受け取る機能は、完成したページを置くだけでは動きません。

方法は2つあります。フォームを受け付ける外のサービスに任せるか、置き場所（Cloudflareなど）の「小さなプログラムを動かす機能」で受け取るか。後者は、そのプログラムをClaude Codeに書いてもらえます。

外のサービスに任せた部分は、そのサービスが仕組みを変えたり終わったりしたら、一緒に止まります。自分のサイトなのに、自分では直せない部分ができる、ということです。

無料の枠には「組み立ての回数」がある

静的サイトは、置き場所代が無料で済むことが多いのも魅力です。WordPressだと、置き場所（サーバー）に毎月お金がかかるので。

ただ、無料の枠には上限があります。たとえばCloudflareの無料プランだと、ページを組み立て直せるのは月500回まで。

ふつうに記事を足すだけなら、まず届かない数です。気をつけたいのは、AIに作業させるとき。Claude Codeが記事を1本直すたびに保存して送る、を1日30回やると、月に900回。上限を超えて、月の後半は公開できなくなります。

AIには「直したら、まとめて1回だけ送って」と頼んでおくと安心です。

1回の変更で、全部のページが一度に崩れることがある

静的サイトは、公開するたびに全部のページを作り直すことが多いです。見た目のひな形を1か所まちがえると、記事が何百本あっても、全部が同じように崩れた状態で公開されます。

WordPressでも見た目を壊すことはあります。ただ静的サイトは、直した、公開した、全部のページが入れ替わった、までが一瞬なんですよ。AIに直させるときほど、ここは気をつけたいところ。AIは頼まれた1か所を直したつもりで、ほかのページにも効く部品まで変えていることがあるので。

記事を書けるのが、ファイルを触れる人だけになる

WordPressなら、管理画面にログインできれば誰でも記事を書けます。静的サイトは、記事を足すのも直すのもファイルの作業です。

自分1人で、AIに頼んで書いているなら困りません。でも、記事を外のライターさんに頼んでいる、家族と一緒に運営している、という場合は話が変わる。その人たちにもファイルを扱えるようになってもらうか、自分が毎回受け取って入れるかの、どちらかになります。

それと、記事を直す作業をAIに頼り切るなら、AIが使えない日は記事も直せない、ということでもあります。AIには使える量の上限があって、当たると時間がたつまで作業が止まるので。

» Claude Codeの制限にかかったら？AIの種類の使い分けで減り方は数倍変わる｜止まる仕組みと元が取れるかの考え方

4つのリスクが誰に当てはまるかを並べると、こうなります。

WordPressから静的サイトへ移行すると起きること

移すと決めたあとで困るのは、WordPressが黙ってやってくれていたことに、移してから気づくことです。

移し方は、大きく2つ

1つ目は、使い慣れた管理画面をそのまま使えるのがいいところです。ただ、WordPressはどこかで動かし続けることになるので、追加機能の手入れは続きます。

2つ目は、WordPressから完全に離れる形。手間は大きいですけど、Claude CodeやCodexで記事を直していくなら、記事がファイルになっている方がずっと話が早い。

書き出した記事に、画像は入っていない

WordPressの管理画面には、記事を書き出す機能があります（ツール → エクスポート）。ただ、ここで書き出されるのは、記事の文章と、画像がどこに置いてあるかの情報まで。画像のファイルそのものは入っていません。

画像は別に、置き場所の画像のフォルダ（wp-content/uploads）から持ってくる必要があります。

追加機能で出していた部品が、文字のまま並ぶ

WordPressには、記事の中に [ ] でくくった短い命令を書いておくと、その場所に部品を出してくれる仕組みがあります。ショートコードと呼ばれるものです。吹き出し、商品のリンク、目次、ボタン。追加機能やテーマで出している部品の多くは、これで動いています。

静的サイトに移すと、この命令を部品に変えてくれるプログラムがいなくなる。結果、記事の中に [ ] の文字がそのまま並びます。

僕も試しに記事を書き出してみたら、商品のリンクを出していた部分が、[ ] の命令の文字のまま出てきました。記事が数本ならあとで直せますけど、何百本もあると、どの記事のどこに残っているかを探すだけでひと仕事です。

URLが1文字でも変わると、検索の評価が引き継がれない

検索エンジンは、URLごとに記事を覚えています。移したことでURLが変わると、前のURLで積み上げた評価は、新しいURLには自動ではつながりません。

変わりやすいのは、このあたりです。

• URLの最後の「/」のあるなし
• 記事のURLの前につく、日付やカテゴリの部分
• 画像のURL

一番いいのは、URLを1つも変えないこと。どうしても変わるなら、古いURLに来た人と検索エンジンを、新しいURLへ自動で送る設定（301リダイレクト）を、変わった記事の数だけ用意します。

Cloudflareなら、この送り先の一覧を1つのファイルに書いて置くだけ。書ける数には上限（2,000件ほど）がありますが、個人のブログならまず足りる。一覧づくりも、URLの前後の表をClaude Codeに渡せば作ってくれます。

WordPressが黙ってやっていた仕事

この表の左の列を、移す前に自分のサイトで全部書き出しておくと、移したあとの「あれ、動いてない」がかなり減ります。

移す前に、今のURLの一覧を保存しておく。移したあとに照らす相手がないと、どの記事が消えたのかを確かめようがありません。

Claude Code・Codexで移行するなら（Cloudflare Pagesに置くまで）

移行の作業は、量が多くて単純なものがほとんどです。AIが一番効くところですね。ただ、どのAIでも同じようにできるわけではありません。

記事が少ないうちは、チャットのAIでも移せる

• 自分のサイトの事情を書いて、WordPressのままか静的サイトかを相談する
• 組み立て係の道具の選び方や、移す流れを説明してもらう
• 記事を1本貼りつけて、Markdownに変えてもらう

1本ずつなら、チャットのAIでも移せます。しんどくなるのは、記事が何十本、何百本とあるときです。

記事が何百本もあるなら、手元のフォルダごと任せる

移行は「同じ作業を、全部の記事に」の繰り返しなんですよね。手元のフォルダにある記事を1本ずつ開いて書き換えられるClaude CodeやCodexだと、ここで差がはっきり出ます。

• 書き出した記事を全部Markdownのファイルに変えて、フォルダに並べる
• 全部の記事から [ ] の命令を探して、部品に置き換える
• 手元でサイトを組み立てて、ページがちゃんと表示されるか確かめる
• 移す前と後のURLの一覧を突き合わせて、抜けを探す
• GitHubに保存して、Cloudflare Pagesで公開できる形まで整える

僕が試しているときも、使い分けはふだんと同じです。記事を変える作業と、変えた記事の中身の確かめはClaude Code。見た目のひな形や、記事を変換するプログラムを直す作業はCodex。Claude Codeが変えた記事の点検もCodexに回しています。

見比べる相手は、頼む前に人が用意する

移行の点検は、照らす相手がはっきりしているぶん、決めやすいほうです。

この表を先に作ってから頼むと、AIは1つずつ突き合わせて、合わないところだけを出してくれます。照らす相手がないまま「うまく移せたか見て」と頼んでも、AIには確かめる材料がありません。

Cloudflare Pagesは、保存した時点で公開される

なお、Cloudflareは、これから新しく作るサイトにはPagesではなく「Workers」という別の仕組みを勧めるようになっています。Pagesも使い続けられますが、新しい機能はWorkers側に入っていく流れです。どちらにするかは、Claude Codeに「今のCloudflareのおすすめの形で」と頼めば、合わせてくれます。

Cloudflare Pagesは、GitHubに置いたファイルが更新されると、自動でサイトを組み立てて公開してくれます。便利ですけど、裏を返すと、AIがファイルを保存して送った時点で、それがそのまま公開されるということ。

なので、作業は本番とは別の枝（ブランチ。ファイルの変更を、本番と分けて置いておける場所）でやらせる方が安全です。本番以外の枝に送ると、Cloudflare Pagesは確認用のURLを別に作ってくれるので、そこで見てから本番に混ぜられます。

サイトの住所の切り替えは、自分の手でやる

移行の最後は、サイトの住所（ドメイン）の向き先（そのURLを開いたとき、どの置き場所を見に行くか）を、WordPressの置き場所から新しい置き場へ切り替える作業です。ここは自分でやった方がいいです。

切り替えた瞬間から、読者も検索エンジンも新しいサイトを見に来ます。抜けがあれば、そのまま読者の目に入る。照らし合わせの結果を自分で見て、納得してから自分の手で切り替える。

切り替えたあとも、WordPressのサイトはしばらく消さないでおきます。何かあったときに戻れる場所があるかどうかで、切り替えの怖さがまるで違うので。

WordPressのままか、静的サイトか：決め方

ここまでを、判断の分かれ目にまとめるとこうなります。

迷っているなら、移す前に、WordPressを固めるほうから手をつけるのがいいと思います。2つ目の章の「WordPressのままでも、ここまではやっておく」は、移すかどうかに関係なく効くので。

移すかどうかを決めるのは、そのあとで遅くありません。僕もまだ試している途中で、移すとは決めていないです。