2026.09.25

WordPressを静的サイトへ移行した全手順【CMS廃止の実録】

groove

2026.09.25

このブログを含む自社サイトは、現在WordPress非依存の静的サイト（純正PHP）で動いています。移行したのは先日。この記事は、その作業の全記録です。「WordPressをやめる」という判断から、ページの保存・テンプレート化・フォームの再実装・検証・本番切替まで、実際の手順と実際に起きたトラブルをそのまま書きました。

冒頭に結論を整理すると、次の4つがこの記事の要点です。

更新が月1回未満の小規模サイトなら、WordPressは「過剰装備」。やめることで運用リスクとランニングコストが下がる
定番の静的化プラグイン（Simply Static等）はWordPressを残すため、更新・セキュリティ対応がなくならない。この記事はCMS自体を廃止する方式
移行は「本番のHTMLを丸ごと保存 → 部品化 → 動く部分だけ再実装 → 差分で検証」の順で進めると失敗しづらい
移行の成否は技術ではなく、「本当に使っている機能の棚卸し」で決まる

前回の記事で「更新頻度が少ないサイトはCMSを省略した方が有利」と書きましたが、あれは机上の話ではありません。自分のサイトで実際にやったので、その手順を公開します。進め方の相談はお問い合わせフォームからどうぞ。

移行後の自社サイトのフロントページ。あなたが今見ているこのブログも、この純正PHPで動いています

なぜWordPressをやめるのか: 判断の基準

まず前提として、WordPress自体が悪いわけではありません。判断の基準は更新頻度と機能の量です。

WordPressの運用には、次の定型作業が付きまといます。

コア・プラグイン・テーマのセキュリティ更新（放置は乗っ取りリスクの直結）
DBの保守とバックアップ
プラグインの相性問題と、更新前の動作確認
表示速度を稼ぐためのキャッシュ系プラグインの調整

これらは更新頻度が高く・機能が多いサイトでは初期投資より安くつくので、払う価値があります。逆に、私のサイトのような条件ではほぼ全部が死蔵になります。

公開ページは12ページ。中身は実質「フロント1枚」のfullPage構成
問い合わせフォームはどこにも表示されていなかった（Contact Form 7がインストールされているだけ。しかも送信先はダミーアドレスのまま）
ブログも表層には存在しない（/news/ への導線なし）
更新頻度: 数カ月に1回あれば良い

つまりデータベースで管理するコンテンツがほぼ存在しないのに、CMS一式（PHP+MySQL+プラグイン群）を保守し続けていたことになります。この「CMSを使っていないのにCMSを運用している」状態こそが、移行の対象です。

目安を数字にすると、次のどれかに当てはまるサイトは移行候補です。

更新が月1回未満で、更新する人が社内にいない
公開ページが20ページ以下で、会員機能・決済・検索のようなDB型機能がない
「 WordPressの更新をやめたまま数カ月経っている」状態が過去に一度でもある

移行先の比較と「純正PHP」を選んだ理由

「WordPressをやめる」と言っても、移行先は複数あります。比較はこうなります。

移行先	自由度	運用の負担	必要な環境	向いているサイト
純静的HTML	高（作り込み次第）	ほぼゼロ	サーバーのみ	更新が一切ないLP・作品集
純正PHP（今回）	高	ほぼゼロ	PHP 8.x のみ	フォームや一覧など「少し動く」部分がある
静的化プラグイン(WPは残す)	中	WPの更新作業が残る	PHP+MySQL	WordPressで記事を書き続けたいサイト
ヘッドレスCMS + SSG	中	ビルド運用が発生	Node等のビルド環境	記事が多く複数人で更新する
サイトビルダー	低	ほぼゼロ	なし	これから作り直す小規模サイト

純静的HTMLではなく純正PHPを選んだ理由は2つです。

共通部分をincludeしたかった。head・フッタ・work一覧は全ページ共通なので、部品として1箇所だけ修正すれば全ページに反映される形にしたかった
フォームとブログを動かしたかった。お問い合わせフォームの送信処理と、このブログの記事一覧・検索・リアクションはサーバー側の処理が必要です。DBは不要でも「PHPが動く」ことは必要

結果として、サーバー要件は「PHP 8.xが動くこと」だけになり、MySQLは不要になりました。ビルドツールもNodeも不要で、エディタとFTPがあれば更新できる状態です。

静的化プラグイン(Simply Static等)ではなく「CMS廃止」を選んだ理由

WordPressを静的化する方法として世の中で定番なのは、Simply Staticのような静的化プラグインでHTMLを書き出す方式です。私も最初に検討しました。結論から言うと、プラグイン方式は「WordPressを残す」ので、私が困っていた問題が半分以上残ります。

プラグイン方式とCMS廃止方式の違いを整理すると次の通りです。

	静的化プラグイン	CMS廃止（今回の方式）
表示速度・セキュリティ	改善する	改善する
WordPress本体・プラグインの更新	続けなければならない	不要
DBの保守・バックアップ	残る	不要
記事の執筆環境	WordPressのまま	Markdownファイル（このブログの方式）
導入の手間	小さい（プラグイン設定のみ）	大きい（移行作業が必要）
事後の改修	テーマ側の作業	PHPを直接編集

つまりプラグイン方式は「表示速度とセキュリティ」の目的には有効ですが、「WordPressの更新をやめたまま放置している」という状態そのものは解決しません。更新作業が残る限り、更新する人も必要です。

逆に、次のどちらかに当てはまるならプラグイン方式が正解です。

これからもWordPressで記事を書き続けたい（執筆環境を手放したくない）
サイトの改修をまだ続ける予定で、テーマの資産を活かしたい

私は「サイト自体はほぼ完成している」「更新は数カ月に1回」「どうせならサーバーからWordPressを一掃したい」という条件だったので、思い切ってCMS廃止を選びました。手間は大きいですが、サーバー上からWordPressが消えるという結果は、プラグイン方式では絶対に得られません。以下、その全手順です。

手順0: 本番サイトの棚卸し（ここが最重要）

作業の最初にやったのはコーディングではなく、本番サイトの機能の棚卸しです。WordPressのDBとテーマを読み、次のことを確認しました。

全ページがどうレンダリングされているか → 12ページすべてが「フロントと同じ構成」で、work単一ページは中身がフロントと同一だった（titleとcanonicalだけが違う）
フロントのアンカー構成 → hero / Technology / Service / Portfolio / Contact の5セクション（fullPage.jsの1ページ構成）
使われているURL一覧 → /work/{slug}/ ×8、その他WP初期ページ2つ
公開中のwork → 8件（DBには非公開が6件も残っていた）
フォームの実態 → CF7のフォームは存在するがどこにも表示されておらず、送信先は dev-email@flywheel.local というダミー

この棚卸しで「移行しなくていいもの」が確定しました。使われていないプラグイン、表示されていないフォームのWP側処理、/news/ の残骸などは、移行対象から除外します。移行作業の失敗の多くは「全部を等しく移そうとして複雑化する」ことに起因するので、この段階の切り捨てが一番の勝負どころです。ここで要件が固まれば、あとは機械的な作業です。

手順1: 本番の全ページをキャプチャする

次に、本番のレンダリング済みHTMLを全ページ保存しました。後の検証で「移行前と同じHTMLが出せるか」を比べるための正（ほん）です。

対象は公開ページ12ページ分
テーマ（936KB）、アップロード画像一式（6.5MB）、DBの内容（work一覧など）もJSONとして書き出し
保存した一式は _reference/ として作業ディレクトリに置き、以後の比較はすべてここに対して行う

ここで1つ、実録ならではの事故を紹介します。キャプチャ取得の際、クエリ文字列つきのGETリクエストを送ったところ、WP-Cacheのキャッシュファイルが24個も新規生成されてしまいました。 読み取りだけのつもりが、サイト側に痕跡を残してしまった形です。取得後に生成されたキャッシュファイルだけを特定して削除し、元の5ファイル状態に戻して内容一致を確認しました。教訓は2つです。

本番サイトへの調査は書き込みが発生しない方法を選ぶ（できればメンテナンス時間に）
取得前後でサーバー内のファイル状態を確認し、差分を必ず元に戻す

手順2: HTMLを「バイト単位」で部品化する

保存したHTMLを、そのままサイトの部品にします。ここでの方針は「自分で書き直さない」です。

head・body冒頭・フッタなどの静的部分は、本番HTMLからバイト単位でそのまま切り出して部品化（inc/generated/ 以下に断片として保存）
独自に書くのは、work一覧（8件を配列で持ってループする部分）だけ。workのデータは config.php の配列に移しました:

$GRV_WORKS = array (
  array (
    'slug'  => '二次会エンタ',
    'title' => '二次会エンタ',
    'link'  => 'https://partydesk.jp/',
    'thumb' => '/wp-content/uploads/2026/02/partydesk.jp_-大.jpg',
  ),
  // ... 8件
);

URL構造は本番と同じ「ディレクトリ + index.php」方式。/work/{slug}/index.php を置くだけで rewrite もルーターも本番では不要
404ページは本番と同じ挙動（「フロントと同じ見た目でHTTP 404ステータスを返す」）をPHPで再現

アセットのURLは https://ドメイン/... からルート相対（/wp-content/...）に統一しました。画像の置き場所を変えなかったので、uploadsの6.5MBはそのまま再利用できます。手を入れた箇所が最小限だから、検証も単純になります。

手順3: 動く部分だけ再実装する

PHP化で新たに書いたのは、次の3つです。

お問い合わせフォーム（前回の記事で触れた通り、本番では非表示だったフォームを復活させました）。入力チェック・管理者宛メール+自動返信・送信後のリダイレクト（PRGパターン）・スパム対策のハニーポットを実装し、CF7と同じメッセージ文面に合わせています。フォームの実装で重要なのは見た目ではなく、二重送信防止とエラー時の入力保持です。

ブログ（この記事を表示しているシステム）。DBの代わりに「front matterつきMarkdownファイル」を1記事=1ファイルで管理し、一覧・検索・カテゴリ絞り込みはPHPがファイルを読んで生成します。記事の追加は「Markdownを置くだけ」で、更新の手間はWordPressよりむしろ下がりました。

404とリダイレクトの整理。WordPressが自動でやっていた「存在しないURLへの応答」を明示的に書く必要があります。本番ではErrorDocument 1行の .htaccess で済みました:

ErrorDocument 404 /404.php

WP固有の出力（REST APIへのリンク、oEmbed、RSSフィードなど）は、WordPressが無いと到達できないエンドポイントなので削除しました。ここは「本番との差分」として記録に残し、意図しない差分がゼロであることを次の手順で確認します。

手順4: 検証は「差分がゼロ」で終わらせる

移行の検証は感覚でやってはいけません。私のやり方は2段階です。

第1段階: HTMLの文字列比較。 ローカルでPHPを起動して12ページをレンダリングし、本番キャプチャ（手順1の正）とdiffを取りました。残った差分は「アセットURLのルート相対化」「WP固有リンクの削除」といった意図した正規化のみで、描画に関わる差分はゼロ。ここまで追い込むと、見た目が変わっていないことをソースレベルで保証できます。

第2段階: 描画結果の比較。 PC（1280×800）とモバイル（375×812）のスクリーンショットを本番と並べて確認しました。下の画像は実際の比較です。左がWordPressの本番、右が純正PHPの移行後。フロントの見た目が完全に一致していることが分かります。

上: 本番のWordPressサイト。下: 移行後の純正PHPサイト。見た目は同一

ブログのデザインについてはさらに踏み込んで、参考にしたデザインの共通CSSと「同じセレクタの計算済みスタイル（フォント・サイズ・余白・色）」をブラウザで実測して数値差分を潰しました。スクリーンショットの見た目比較は解像度やタイミングでブレるので、数値で一致を確認するのが確実です。

手順5: 本番へ切り替える

本番切替の手順はシンプルです。

新構成（純正PHP一式）をサーバーの public_html へアップロードする
既存のWordPress一式は別ディレクトリへ退避（いきなり削除しない。戻せる状態を維持）
public_html 直下には ErrorDocument 1行の .htaccess だけを置く
PHPのバージョンは8.xを指定（レンタルサーバーの管理画面で切替）
wp-config.php とDBは移行後は不要

切替前のチェックリストは次の通りです。

□ 全URLの応答確認（200になるべきページ・404になるべきページの両方）
□ フォームの送信テスト（メールが届く宛先になっているか）
□ 画像・CSS・JSの参照切れ（ルート相対化の漏れ）
□ スマホ実機での確認（fullPage.jsのようなビヘイビア系）
□ アクセス解析のビーコンが動いているか
□ 検索エンジン向けにURL構造が変わっていないか（今回は全URLを維持したので301リダイレクトは不要だった）

URL構造を1つも変えていないので、SEO上のリスクは最小限です。表示速度の計測（Lighthouseのbefore/after）は本番切替の計測が済み次第、この記事に追記します。

実録ならでは: 実際にハマった点

最後に、手順書には書かれないトラブルをそのまま記録します。

真っ白になるページ: テーマのCSSが .wrapper { opacity: 0 } を初期値にしていて、fullPage.jsが読めないページでは何も表示されなくなる。フルページ遷移系のテーマを流用するときの定番トラップです
ダークモードで「白いはずのページ」が暗くなる: 背景を透過のままにしているとOSのダークモードで暗いキャンバス色が見えてしまう。html { background: #fff } を明示して解決
Windowsでの自動化: ビルドスクリプトがディレクトリロックで失敗する、ローカルPHPにmbstringが無い、など環境起因の問題が複数。本番はLinuxサーバーなので問題になりませんが、ローカル検証環境の差は先に潰すべきでした
先のWP-Cache事件: 調査目的でも本番に触れるなら、副作用の有無を最初に確認する

どれもWordPress自体の問題ではなく「テーマと環境の個性」ですが、CMSが無いと自動で吸収してくれていた部分が全部自分に来る、というのが静的化の本質です。裏を返せば、吸収する量が少ないサイトほど移行に向いている、ということでもあります。

よくある質問

Q. Simply Staticのような静的化プラグインではだめですか?

目的次第です。表示速度とセキュリティの改善だけが目的なら、プラグイン方式の方が圧倒に手軽で正解です。ただしWordPress本体・DB・更新作業は残るため、「更新する人がいない」「サーバーからWordPressをなくしたい」という悩みは解決しません。執筆環境を手放してでも運用リスクをゼロにしたい場合が、CMS廃止の選択ラインです。

Q. どこまでのサイトなら移行できますか?

会員機能・決済・サイト内検索のようなDB型機能がなく、ページ数が20ページ以下程度なら現実的です。予約システムのような機能も、外部サービスを埋め込む形なら移行できます（実案件でも構成次第で対応可能です）。ECや多言語CMSなどは素直にWordPressや専用サービスを続けるべきです。

Q. SEOへの影響はありますか?

URL構造を維持し、HTMLの構造も変えなければ影響は最小限です。今回は全URLを維持してリダイレクト不要でした。逆に、移行を機にURLを変えるなら301リダイレクトの設計が必須です。

Q. 期間と費用はどのくらい?

今回の規模（12ページ・フォーム・ブログ付き）でも、棚卸しから検証までまとまった作業時間は数日程度です。ページ数が増える・デザインを変える・機能を増やす、のどれかが入ると話が変わります。「WordPressの更新だけが目的」の移行なら、デザインもURLも変えないのが最短ルートです。

Q. WordPressのままリスクだけ下げる方法はありますか?

使っていないプラグインの削除・自動更新の設定・定期的なバックアップで相当数のリスクは下がります。静的化プラグインを導入して出力だけ静的にする、という中間の選択肢もあります。ただし「更新する人」が確保できないなら、いずれCMSを手放す判断は必要になります。迷っている段階であれば、相談窓口でサイトの実態を見て判断することもできます。