WordPressサイトを静的サイトに移行してサーバーはそのままにした話｜判断基準と移行手順

ℹ️ 本記事はアフィリエイトプログラム（エックスサーバー株式会社／A8.net）による収益を含みます。料金・仕様は変わることがあるため、申し込み前に必ず公式サイトの最新情報をご確認ください（本記事は2026年8月時点）。

この記事のポイント

• WordPressの更新・プラグイン管理がしんどくなったら、静的サイト化は「サーバーを変えずに」解決できる場合が多い
• 静的サイトに移行してもサーバー契約自体はそのまま使い回せる。乗り換えが必要なのは「今のサーバーに機能が足りない」ときだけ
• 移行で一番事故りやすいのは「デプロイの同期はマージ動作」という点。消したはずのファイルが本番に残り続ける
• 複数サイトを1契約で同居させる運用は便利だが、デプロイ先の取り違え事故が起きやすい
• 新規契約・乗り換えで検討するなら、月額は契約期間で大きく変わるので12ヶ月契約を基準に見積もるのが現実的

WordPressの運用、そろそろしんどくなっていませんか

更新ボタンを押すたび不安になる日々

「毎回ログインしてプラグインの更新通知を消すだけの時間がもったいない」「セキュリティパッチが出るたびに、壊れないかヒヤヒヤしながら適用している」「制作会社に運用を任せているけど、サーバーの中身がブラックボックスで不安」——こういう相談を、Web制作や広告運用の現場でよく耳にします。

私自身、真策堂の自社サイト（shinsakudo.com）を長らくWordPressで運用していましたが、2026年4月にAstroという静的サイト生成の仕組みに移行しました。今日はその実体験をベースに、「静的サイト化」という選択肢と、サーバーをどう扱うべきかの判断基準を具体的にお話しします。結論から言うと、サーバーを変える必要はほとんどありません。私自身、Xserverはそのまま使い続けています。

この記事は「WordPressが重い・しんどい」という悩みへの処方箋であり、同時に「これからサーバーを借りる・乗り換える」人向けの判断材料でもあります。

静的サイトとWordPress、何が違うのか

WordPressは「PHPとデータベースが記事を組み立てて、リクエストが来るたびにHTMLを生成する」動的サイトの仕組みです。管理画面から記事を書けて便利な反面、サーバー側で毎回処理が走るので重くなりやすく、プラグインやコアのアップデートが継続的に必要になります。

静的サイトは逆で、あらかじめHTMLファイルを作っておき、サーバーはそれを「そのまま配る」だけです。データベースへの問い合わせもPHPの実行も発生しないので、表示は速く、脆弱性の面積も小さくなります。Astro・Next.js・Hugoなどのツールで記事のmdファイルからHTMLを生成し、できあがったdist/フォルダをサーバーにアップロードする、という流れになります。

ここで大事なのは、静的サイトを配信するのに特別なサーバー機能は要らないということです。ファイルを置いてWebサーバーが返すだけなので、WordPressを動かしていたレンタルサーバーでもそのまま配信できます。「静的サイトにするならサーバーも変えないと」と思い込んでいる方が意外と多いのですが、それは誤解です。

サーバーを変えなかった理由（判断基準）

図1: サーバーを変える・変えない判断基準

私が移行にあたって最初に確認したのは「今のサーバーに、静的サイトを置けない理由があるか」でした。具体的には以下を見ます。

• FTP/SFTPでファイルをアップロードできるか
• 独自ドメインの設定が済んでいて、DNSをいじらずに済むか
• 容量に余裕があるか（静的サイトは画像を除けばWordPress時代よりむしろ軽くなることが多い）
• 無料独自SSLがそのまま使えるか

Xserverはこの4つすべてを満たしていたので、契約はそのままにしました。旧WordPressのデータも public_html.wp-backup-YYYYMMDD のような名前で退避させ、数ヶ月は残して様子を見る形にしています。いきなり消すのではなく、問題が出たときに戻せる状態を作っておくのがポイントです。

逆に、サーバーを変えるべきタイミングは次のような場合です。

• ディスク容量が慢性的にカツカツで、バックアップ世代も持てない
• SFTP/SSHでの操作ができず、管理画面（FTPのみ）に頼らざるを得ない
• 独自SSLの自動更新でトラブルが多発している
• 複数サイトを運用したいのに、マルチドメインが制限付きプランしか使えない

今のサーバーがこれらに該当しないなら、静的サイト化は「引っ越しなしのリフォーム」で済みます。該当するなら、静的化のタイミングでサーバーごと乗り換えるのが合理的です。

移行の実務：SFTPデプロイをどう組んだか

私の場合、ssh2-sftp-client というライブラリでデプロイスクリプトを書き、ビルドした dist/ フォルダをまるごとサーバーに同期する形にしています。接続はポート10022、認証はパスワードではなく秘密鍵認証です。パスワード認証よりセキュリティ面で安心できますし、CIに組み込むときも鍵ファイルを渡すだけで済みます。

ファイル数が2,600件規模になると、同期に8〜9分かかりました。手動で「デプロイボタンを押して数分待つ」運用ならそこまで気になりませんが、CIで自動デプロイを組む場合はこの時間を織り込んでおく必要があります。「毎回のプッシュで9分待たされる」設計にしないよう、ビルドとデプロイのタイミングは分けて考えるのがおすすめです。

一番ハマったこと：同期は「マージ」であってミラーではない

図2: 同期はマージ、ミラーではない

ここが今回の移行で一番学びになった部分です。SFTP同期は基本的に「ローカルにあるファイルをサーバーに上書き・追加する」動作であり、ローカルから消したファイルが自動でサーバー側から消えるわけではありません。

私の場合、記事のURL構造を変更したタイミングでこれにハマりました。ローカルでは古いディレクトリを消していたのに、本番サーバーには古いファイルが残り続け、Search Consoleを見たら消したはずの旧URLがインデックスされ続けていたんです。慌てて調べて、「同期はマージだから、削除は明示的にやらないと反映されない」ことに気づきました。以降は、削除対象を洗い出して明示的に消すスクリプトを別途用意する運用に変えています。

もう一つ厄介だったのが、同一アカウントに複数サイトを同居させている場合のデプロイ先取り違えです。私も1つの契約で複数のサイトを運用しているのですが、あるとき一方のサイトのファイルが、もう一方のドキュメントルートに撒かれてしまいました。同期がマージ動作なので気づきにくく、Search Consoleに身に覚えのないクエリが出てきて初めて発覚した、という経緯です。今はデプロイスクリプト側で「アップロード先パスが想定のドメイン宛てになっているか」を検査するようにして、事故を防いでいます。

複数サイトを1契約で回す運用は、コスト面ではメリットが大きい一方、こういう「取り違え」のリスクとセットです。制作・運用を仕事にしている方が複数の顧客サイトを1契約に同居させるケースもあると思いますが、デプロイ先の検査は最初から仕組みに組み込んでおくことを強くおすすめします。

なお、旧WordPress時代の画像（/wp-content/配下）はシンボリックリンクで新サイトから参照できるようにして、旧URLから新URLへの301リダイレクトは .htaccess をビルド時に自動生成する形にしました。手作業でやると抜け漏れが出るので、機械的に生成する仕組みにしておくと安心です。

静的化 vs WordPress継続 vs サーバー乗り換え、どれを選ぶか

図3: 3つの選択肢を分ける判断フロー

判断に迷ったときのために、3つの選択肢を整理しておきます。

観点	WordPress継続	静的サイト化（サーバーはそのまま）	サーバーごと乗り換え
初期コスト	低い（現状維持）	中（移行作業・ビルド環境構築）	中〜高（データ移行含む）
運用の手間	継続的な更新対応が必要	記事更新以外の手間はほぼ消える	変わらない（サーバーが変わるだけ）
表示速度	サーバー・プラグイン次第	動的処理が無いぶん有利になりやすい	サーバー性能次第
向いている場面	会員機能・EC等、動的処理が必須	ブログ・コーポレートサイト中心	現サーバーの容量・機能が不足している
今回の実務での学び	—	同期のマージ挙動に注意	ドメイン・SSL再設定の手間が発生

「動的な機能（会員登録、EC、フォームのDB保存など）が必須かどうか」がまず最初の分岐点です。それが不要で、コンテンツ配信が中心のサイトなら、静的化は検討する価値が大いにあります。そして、静的化するからといってサーバーを変える必要は基本的にない、というのが今回一番伝えたいことです。

向いている人・向いていない人

静的サイト化が向いているのは、ブログやコーポレートサイトのように「コンテンツを配信する」ことが主目的で、更新頻度は高いが会員機能やEC機能が要らないサイトです。また、記事生成をコードやスクリプトから自動化したい、複数人でのレビューをGit上で回したい、といったチーム開発的な運用をしたい方にも向いています。

逆に向いていないのは、WordPressの管理画面から非エンジニアが直接更新する運用が定着していて、それを変える予定がない場合です。静的サイトはビルド・デプロイの仕組みが挟まるぶん、ノーコードでの更新のしやすさはWordPressに軍配が上がります。また、ECサイトや会員制サイトなど、動的な処理がサイトの根幹をなす場合は、そもそも静的化の対象になりません。

これから借りる・乗り換える人向け：契約期間の考え方

ここからは「これからサーバーを借りる」「他社から乗り換える」方向けの話です。Xserverのスタンダードプランは、契約期間によって月額が大きく変わります。

契約期間	月額（税込）
3ヶ月	1,320円
6ヶ月	1,210円
12ヶ月	990円
24ヶ月	836円
36ヶ月	693円

「990円から」という表示をよく見かけますが、これは12ヶ月契約時の価格です。3ヶ月契約だと1,320円と、1.3倍以上の差が出ます。短期で様子を見たい気持ちは分かりますが、価格面では12ヶ月契約を基準に考えるのが現実的です。まずは10日間の無料お試し期間で管理画面やSFTPの挙動を確認してから、12ヶ月以上の契約に進む、という流れが無理がないと思います。

法人サイトで複数サイトの同居や独自ドメインを多く使う予定がある場合は、プレミアムやビジネスプランも選択肢に入ってきます。ディスク容量やドメイン特典（永久無料の独自ドメイン数）がプランごとに違うので、公式サイトの料金ページで最新の内訳を確認しておくとよいと思います。

デメリット・注意点も正直に

ビルド環境構築という新たなハードル

静的サイト化は良いことばかりではありません。ビルド環境（Node.jsなど）を用意する必要があり、非エンジニアが一人で完結させるのは難しくなります。また、今回説明した「同期はマージ」という挙動は、静的サイトホスティング全般に共通する落とし穴で、デプロイの仕組みを自分で書く場合は必ず意識しておく必要があります。

さらに、フォームや検索機能など「サーバー側での処理」が必要な部分は、外部サービス（フォーム送信API、検索SaaSなど）と組み合わせる設計が必要になります。「静的にすれば全部解決」ではなく、「動的な部分だけ外に出す」という発想の切り替えが要る、という点は正直にお伝えしておきます。

「静的化しても意味ない」って本当？

「表示速度なんてどうせプラグイン減らせば済むのでは」という声もあると思います。実際、プラグインの整理やキャッシュ設定でWordPressのままでも改善できる部分はあります。ただ、運用の手間そのもの（更新通知への対応、脆弱性対応、バックアップの確認）は、WordPressを動かし続ける限りゼロにはなりません。「表示速度」だけでなく「継続的な運用コスト」まで含めて考えると、静的化の意味は変わってきます。動的な機能が不要なサイトであれば、検討する価値は十分あると思います。

よくある質問

Q. 静的サイトに移行したら、今使っているサーバーは解約したほうがいいですか？ いいえ、その必要はありません。静的サイトの配信にはFTP/SFTPと無料独自SSLがあれば十分で、今使っているサーバーの容量・機能が足りているなら、そのまま使い続けるのが合理的です。

---

Q. WordPressの記事データはどうやって静的サイトに移すのですか？ 記事データをエクスポートしてMarkdown形式に変換し、静的サイト生成ツールに読み込ませる、という流れが一般的です。移行スクリプトの作り方はツールによって異なるので、使うツール（Astro、Hugoなど）のドキュメントに沿って進めるのが確実です。

---

Q. サーバーを乗り換える場合、3ヶ月契約でお試しするのはアリですか？ 価格面では割高になります。3ヶ月契約は12ヶ月契約の1.3倍以上の月額になるので、短期で試したいなら契約前の10日間無料お試しを使うほうが合理的です。そのうえで契約するなら12ヶ月以上を基準に見積もることをおすすめします。

---

Q. 複数サイトを1つのサーバー契約で運用しても大丈夫ですか？ 可能です。マルチドメインが無制限のプランであれば技術的な制限はありません。ただし、デプロイ先の取り違えなど運用上の事故は起きやすいので、デプロイスクリプト側でアップロード先を検査する仕組みを入れておくと安心です。

---

Q. 独自SSLは静的サイトに移行しても引き続き使えますか？ 使えます。無料独自SSLはドメイン単位で発行されるものなので、コンテンツが動的か静的かは関係ありません。ただし、Cloudflareなどを経由させる場合はSSLの自動更新に失敗することがあるサーバーもあるため、事前に検証しておくと安心です。

---

まとめ

WordPressの運用がしんどくなってきたとき、「静的サイトに移行する」ことと「サーバーを乗り換える」ことは、実はセットで考える必要がありません。私自身、shinsakudo.comをAstroに移行した際もXserverの契約はそのまま使い続けています。移行で本当に注意すべきは、同期がマージ動作であること、複数サイト同居時のデプロイ先取り違えといった、実務レベルの落とし穴です。

これから自社サイトをサーバーごと立ち上げる、あるいは他社から乗り換えを検討している方は、まず10日間の無料お試しで管理画面やSFTPの操作感を確かめてみるのがおすすめです。契約する場合は、月額が3ヶ月契約の1,320円に対して12ヶ月契約なら990円と大きく変わるので、12ヶ月契約を基準に見積もっておくと後悔が少ないと思います。詳しいプランや容量の内訳はエックスサーバー公式サイトで確認できます。

複数サイトの同居運用やステージング環境の組み方など、実務の設計で迷ったときも、まずはエックスサーバー公式サイトの機能一覧で無料独自SSLやマルチドメインの仕様を確認してから、無料お試しで実際の管理画面を触ってみるとイメージがつかみやすいと思います。