LP制作でWordPressを使うと保守費用が積み上がる理由

LP制作の納品後、クライアントから「更新は自分でやらない予定」と言われているのに、WordPressの保守費用が毎月かかり続けていませんか？
プラグイン更新・セキュリティ監視・PHPバージョン対応——こうした維持コストは、更新が発生しないLPには本来不要なものです。
WordPressを外すかどうかの判断軸と、実案件でハマった具体的なトラブルと対処を整理します。

保守費用が消えないLPに当てはまる症状

LP案件を納品した後、次のどれかに当てはまるなら、この記事が参考になります。

• クライアントが自分でページを更新することはなく、今後も予定がありません
• プラグイン更新・セキュリティ対応を月次または年次で請求しているが、クライアントに「何をやってもらっているかわからない」と言われることがあります
• PageSpeed InsightsのスコアがPCで70点台、モバイルで50点台以下になっています
• WordPressのダッシュボードがほぼ使われていないのに、管理画面へのログイン試行通知が届きます
• LPとして完成したページなのに、テーマ・プラグイン・コア全部のアップデート対応が毎月発生しています

WordPressはもともと「コンテンツを定期的に更新するサイト」向けに設計されたCMSです。
告知ページやイベントLPのように「公開後は変更しない」サイトにWordPressを使うと、機能の半分以上を使わないまま維持コストだけが積み上がります。

更新不要なLPでWordPressを使うと起きること

問題は大きく3つに分けられます。

表示速度の問題
WordPressはページを表示するたびにPHPが実行され、MySQLへ接続してコンテンツを組み立てます。
静的なLPではこのサーバーサイドの処理が不要なのに、毎回DB接続が走るためレスポンスが遅くなります。
PageSpeed Insightsのモバイルスコアが50点台以下になっているLP案件では、このWordPress由来のTTFB（最初のバイトが届くまでの時間）が原因のことが多いです。

セキュリティ維持コスト
WordPressのプラグインは定期的に脆弱性が見つかり、放置すると攻撃対象になります。
WP-Cronによる定期処理も常に動いているため、クライアントが使っていないサイトでも外部からのアクセスは発生し続けます。
「更新しないLP」ほど、管理が止まって気づかないうちに脆弱な状態になっていることがあります。

使われないCMSの維持
クライアントがダッシュボードを一切使わない場合でも、管理画面・DBサーバー・ログイン機能のセキュリティを維持する必要があります。
保守費用の根拠にはなりますが、クライアント視点では「何に払っているかわからない費用」になりやすいです。
この積み重ねが、次の更新や改修時に解約・移転を検討されるきっかけになります。

Astroを選ぶ判断軸と、初案件でハマった相対パス問題

WordPressとAstroを使い分ける判断軸は、1つです。

「クライアント自身がコンテンツを更新するか？」

• Yesなら → WordPress（またはヘッドレスCMS）
• Noなら → Astroのような静的サイト生成ツール

Astroで静的出力すれば、デプロイ後に配信されるのはHTMLとCSSとJSのファイルだけです。
PHPもDBも動かないため、セキュリティ監視やプラグイン更新の対応は不要になります。
レンタルサーバーに置くだけで動作し、公開後の保守費用をほぼゼロにできます。

実際に、ある地域イベントの告知LP案件でこの判断をしました。
要件は「カウントダウン表示・アニメーション多め・Google Analytics導入」で、公開後にクライアントが自分でページを更新する予定はありませんでした。
期間限定の告知ページだったこともあり、Astroを選びました。

tsxコンポーネントがサブディレクトリで壊れる問題

AstroプロジェクトでReact（tsx）コンポーネントを使った場合、ビルド時に出力されるJSのパスが相対パスで出力されることがあります。
ルートディレクトリへのデプロイなら問題ないのですが、この案件はサブディレクトリに公開する構成でした。
ビルドしてデプロイした直後、CSSとJSのパスが全部壊れてスタイルもスクリプトも当たらない状態になりました。

対応は2段階で行いました。

1. 応急処置: ビルド成果物（distフォルダ内のHTMLファイル）を手動で開いて、壊れているパス文字列を書き換えて公開しました
2. 根本解決: astro.config.mjs に base オプションを追加して、出力パスをサブディレクトリ基準に制御するよう設定しました

設定は1行の追加で済みます。

import { defineConfig } from 'astro/config';

export default defineConfig({
  base: '/サブディレクトリ名/',
});

base に指定した文字列を起点に全アセットのURLが組み立てられるため、サブディレクトリへのデプロイでもパスが壊れなくなります。
公式ドキュメントに記載されているオプションですが、ルートにデプロイする案件しかやっていないと気づきにくいポイントです。
事前にテストサイトを作って学習していても、本番の環境構成が違えば同じトラブルは出ます。

自分で判断できること / ここからはプロ領域

技術選定の判断自体は、次の2点を確認すれば自力でできます。

• クライアントがコンテンツを自分で更新するか（ブログ・お知らせ・商品情報の定期更新など）
• 公開後に動的な機能（会員登録・ECカート・フォーム連携）を追加する可能性があるか

どちらもNoなら、Astroのような静的ツールの方が保守コストを下げやすいです。
どちらかでもYesなら、WordPressやヘッドレスCMSを組み合わせる選択肢を検討します。

一方、以下はプロ領域になります。

• 特殊なサーバー環境（サブディレクトリ公開・独自ホスティング）への初デプロイが必要なとき
• 既存WordPressサイトを静的サイトへ移行するとき
• APIを使った動的機能（外部フォーム連携・投稿一覧取得・認証）を実装するとき

特殊なサーバー環境へのデプロイは、設定が1行違うだけでCSSやJSが全部崩れます。
「スタイルが当たらない」「JSが動かない」という状態になったときに根本原因を特定するには、環境への慣れが必要です。
自分の案件でも、応急処置で手動パッチを当てた後に根本解決するまで、ビルド設定の確認に時間がかかりました。

WordPressとAstroのどちらを選ぶかは受注前に決められますが、決めた後の実装と環境対応はプロに任せる方が確実です。

WordPressを使ったサイトの保守や改修については、WordPressのコラム一覧もあわせて参考にしてみてください。

まとめ

• 更新不要なLP案件でWordPressを使うと、プラグイン・セキュリティ・PHPの保守費用が永続的に発生します
• 「クライアント自身がコンテンツを更新するか？」がWordPressとAstroの選択基準です
• 更新不要なLPはAstroのような静的ツールで作ると、デプロイ後の保守費用をほぼゼロにできます
• Astroでサブディレクトリにデプロイするときは astro.config.mjs の base オプションの追加が必要です
• 応急処置（手動パッチ）と根本解決（設定追加）の2段階で対処すると、スピードと正確さを両立できます

LP・告知ページのコーディングや技術選定で詰まったら、Build にご相談ください。
「この案件、Astroの方が保守コスト下がりますよ」という提案から入ることもあります。
コーディング代行・実装パートナーとして動ける体制があります。