使っていないWordPressサイトを放置する危険｜「DNSを外したから見えない」は閉鎖ではない
使っていないWordPressサイトを放置する危険｜「DNSを外したから見えない」は閉鎖ではない
リニューアル前の旧サイト。テスト用に作ったサブドメイン。契約が終わったクライアントのサイト。使わなくなったまま、サーバーの中に残っているサイトはありませんか。
こうしたサイトは「もう誰も見ていない」ので、被害が出ても長く気づかれません。実務上、深刻な脆弱性を抱えたまま外部に露出しているのは、現役サイトではなくこの忘れられたサイトのほうです。現役サイトは不具合が出れば誰かが気づき、更新も回るからです。
この記事では、使わなくなったサイトを安全に閉じる手順と、「閉じたつもり」で閉じられていない状態をどう見分けるかをまとめます。制作会社に任せている場合に何を確認すればよいかも最後に書きます。
結論：公開ディレクトリから中身を出すまで、サイトは閉じていない
先に結論から書きます。サイトを止める方法として思いつく操作の多くは、閉鎖として成立していません。
| よく行われる操作 | 閉鎖として成立するか |
|---|---|
| サイト内のリンクを外す・メニューから消す | ✕ URLを直接叩けば開く |
| 検索結果に出ないようにする | ✕ 検索に出ないだけで公開されている |
| ドメインの向き先（DNS）を外す | ✕ 後述。サーバー側の受け口は開いたまま |
| 管理画面のパスワードを変える | ✕ 狙われるのは管理画面のログインだけではない |
| 公開ディレクトリから中身を退避する | ○ 外部からの到達が消える |
| サーバー契約ごと解約する | ○ ただしデータも同時に失う |
判断の基準はひとつです。「外部から中身に到達できるか」だけが問題であり、リンクの有無も検索結果の有無も関係ありません。
そして退避する前に、必ず完全なバックアップを取ります。「使っていない」と思っていたサイトに、後から必要になる問い合わせ履歴や記事が入っていることは珍しくありません。
ドメインの向き先を外しても、外部から開けてしまう理由
ここが最も誤解されやすい部分なので、仕組みから説明します。
DNS（ドメインネームシステム）は、訪問者が「このドメイン名はどのサーバーか」を調べるための電話帳です。電話帳から名前を消しても、電話番号（サーバーのIPアドレス）そのものは変わりません。
さらに現在のレンタルサーバーは、1台のサーバーに多数のサイトを同居させ、アクセス時にブラウザが伝えてくるドメイン名を見て、どのサイトを返すかを振り分けています（TLSのSNIという仕組み）。つまりサーバー側の受け口は、DNSの設定とは無関係に開いたままです。
そのため、次のような手順で外部から到達できます。
- サーバーのIPアドレスを機械的に走査する
- 応答したサーバーの証明書に載っているドメイン名を読む
- DNSを一切引かずに、そのドメイン名を指定して直接アクセスする
技術的な確認方法としては、ターミナルで次のように「DNSを介さないアクセス」を試せます。
curl --resolve example.com:443:203.0.113.10 -k https://example.com/この確認は必ずやってください。サーバー点検の実務では、向き先が外れていて通常アクセスに応答しない2サイトを「到達できないので安全」と判断しかけたことがあります。上の直接アクセスを試すと、どちらも普通に表示されました。中身は当時公表されていた深刻な脆弱性の影響を受けるバージョンで、「向き先を外したから見られない」という前提が丸ごと成り立っていなかったわけです。
安全かどうかを、DNSの状態やブラウザでの見え方だけで判定しない。これが最初の分岐点です。
「使っていないサイト」ほど危ない、3つの理由
放置サイトのリスクは、単に古いというだけではありません。
1. 更新が止まる
現役サイトは表示崩れや不具合で気づく人がいて、更新の機会があります。使っていないサイトは誰も開かないため、公開された脆弱性がそのまま残り続けます。
2. 改ざんされても気づかない
乗っ取りの目的は、多くの場合サイトの破壊ではありません。気づかれないまま、スパムの発信や別サイトへの誘導に使うことです。見た目が変わらないため、見ている人がいないサイトでは何か月も発覚しません。
3. 同居している現役サイトの入口になる
同じサーバー契約に現役サイトが同居していれば、放置サイトが踏み台になり得ます。守るべきなのは放置サイト自体ではなく、そこから届く範囲全体です。
これは感覚的な話ではありません。サーバー3台のWordPressを1件ずつ全数点検したところ、1台目だけで50件以上が見つかり、そのうち深刻な脆弱性の影響を受けるバージョンだったのは8件。その8件すべてが、過去のデモサイト・旧本番サイト・移行前に使っていたサブドメインでした。集客に使っている現役サイトは、いずれも更新されていました。
バージョンより先に、公開ディレクトリに何が置いてあるかを見る
脆弱性というと本体のバージョンに目が行きますが、先に見るべきは公開ディレクトリに置きっぱなしのファイルです。
実際の点検で、サイト移行に使うデータベース一括置換ツールが、1年以上にわたって誰でもアクセスできる状態で公開ディレクトリに残っていたケースがありました。この種のツールは設定ファイルから接続情報を自動で読み込む作りのため、認証なしでデータベースを操作できる状態だったことになります。本体のバージョンとは無関係に、これ単体で乗っ取りが成立します。
一般化すると、次の作業のあとは撤去の確認を必ず工程に入れるべきです。
- サーバー移行・ドメイン移行で使った一括置換ツール
- 動作確認用に置いたPHPファイル（
info.phpのような情報表示スクリプト） - 圧縮したまま置いたバックアップファイル（
.zip/.sql） - 役目が終わった検証用ディレクトリ（
/test//old//backup/など）
公開ディレクトリ直下のファイル一覧を1画面ぶん眺めるだけで見つかります。脆弱性情報を追うより先に、これを見るほうが早いです。
安全に閉じる3ステップ
閉じると決めたサイトは、次の順番で進めます。
ステップ1：完全なバックアップを取り、中身を検証する
ファイル一式とデータベースの両方を取ります。取っただけで終わらせず、中身が揃っているかを確認するところまでが1工程です。
- ファイルは「件数が合っている」だけで安心しない。サーバー側とローカル側のファイルパス一覧を双方向で突き合わせると、欠損も余剰も出ます
- データベースのダンプは、末尾に完了行が入っているかとテーブル数を確認する。転送が途中で切れたダンプも、開けば一見それらしく見えます
なお、SSHが使えない共有サーバーでも、設定ファイルから接続情報を読んで一時的なスクリプトを置けばデータベースは取得できます。その際は自分のIPアドレス以外からは動かないよう制限をかけ、取得後にスクリプトを削除したことを目視で確認してください。消し忘れると、閉鎖しに行ったはずが新しい侵入口を作ることになります。アクセス制御ファイル（.htaccess）は書き換えないでください。サイトが表示できなくなります。
ステップ2：削除ではなく「退避」する
復活の可能性が少しでもあるなら、削除ではなく公開ディレクトリの外へ移動します。_closed_20260804 のように日付を付けたフォルダへ移し、公開ディレクトリを空にします。
外部からの到達は、公開ディレクトリから外れた時点で消えます。リスクを止めるという目的は、削除しなくても達成できます。取り返しがつかない操作は、目的が同じなら選ばないほうが安全です。
判断は次の基準で分けられます。
| サイトの状態 | 判断 |
|---|---|
| 集客・問い合わせに使っている | 残す。更新を回す |
| 今は使っていないが復活の可能性がある | バックアップして退避 |
| 契約終了・先方と連絡が取れない | データを保全して退避 |
| 検証用・デモ用で役目が終わった | バックアップを取ったうえで削除 |
ステップ3：閉じられたことを外部から検証する
ここを飛ばすと「閉じたつもり」が残ります。
HTTPのステータスコードだけで判定しないでください。実際に、削除したはずのディレクトリが削除後も正常応答（200）を返し続けたことがあります。中身を確認すると、親サイト側の転送設定がそのURLを拾い、親サイトのトップページを返していただけでした。削除は成功していたのに、応答だけを見て「消えていない」と誤判定しかけたわけです。逆方向の誤認も同じ理屈で起こります。
確認するのは次の2点です。
- 主要なURLの応答：トップ、
/wp-login.php、/wp-admin/、/wp-json/、/index.phpが想定どおり閉じているか - 返ってきたHTML本文の中身：
wp-content/wp-includes/ 生成情報（generator）/ 旧サイトのタイトルが残っていないか
2の本文確認まで含めて、初めて閉鎖の検証になります。同時に、同居している現役サイトが無傷であることも必ず確認してください。
閉じずに残すと決めた場合に見るところ
「使っていないが残す」という判断もあります。その場合は現役サイトと同じ管理下に入れます。
バージョンは正しい場所で確認する。サイトのソースに出てくる ?ver= のような表記は、テーマやプラグインが自前で付けた番号であって本体のバージョンではありません。これを本体のバージョンと読み違えると、安全なサイトを危険と判定したり、その逆をやったりします。本体のバージョンは、生成情報（generatorの記述）か、サーバー上の本体ファイルを直接確認するのが確実です。
改ざんの確認はファイル名ではなく中身で行う。「shell」「upload」といった単語でファイル名を検索すると、管理画面の正規ファイルまで拾って数千件になり、判定に使えません。実際の点検でも、アップロードフォルダ内のPHPファイルが多数ヒットしましたが、中身を見ればすべてプラグインが自動生成する空ファイルでした。見るべきは、外部から受け取った文字列をそのまま実行する類のコードが含まれているかどうかです。
サーバー側の一時的な遮断を、恒久対策と考えない。脆弱性が公表された直後は、サーバー会社が該当機能を一時的に塞ぐことがあります。これは緊急措置で、解除されれば元の状態に戻ります。「今は塞がれているから大丈夫」で止めず、バージョンを上げ切ってください。
今日からできる棚卸しの手順
- 契約中のサーバーとドメインを全部書き出す。ここが漏れると、以降が全部漏れます
- 各サーバーの公開ディレクトリ配下で、WordPress本体ファイルを全部探す。階層の深さに注意してください。店舗ごと・案件ごとにフォルダを切っている構成では6〜7階層まで潜るため、浅い階層までしか探さないと店舗ぶんが丸ごと漏れます
- 1件ずつ「残す／残すが更新する／閉じる」を決める（前掲の判断表）
- 閉じるものはバックアップ → 退避 → 検証の順で進める
更新も退避も、必ずバックアップを取ってから行ってください。逆にすると、失敗したときに戻す先がありません。
制作会社に任せている場合に聞くこと
自社で操作しない場合でも、次の3点は確認しておく価値があります。
- 今このサーバー契約の中で、何サイトが動いていますか（把握できていないサイトの数が、そのままリスクの量です）
- 使っていないサイトはどう閉じましたか（「ドメインの向き先を外しました」という回答なら、閉鎖できていません）
- バックアップはどこに、いつ時点のものがありますか（保存先とデータの日付を具体的に）
答えが曖昧なら、それ自体が棚卸しの必要性を示しています。
まとめ
- 使わなくなったサイトは、公開ディレクトリから中身を出すまで閉じていない
- ドメインの向き先を外しても外部からは到達できる。共有サーバーはドメイン名で振り分けているだけで、受け口は開いたまま
- 危険が溜まるのは現役サイトではなく、デモ・旧本番・移行前サブドメインなどの忘れられたサイト
- 本体のバージョンより先に、公開ディレクトリに残った作業用ファイルを確認する
- 閉じる手順は バックアップ（中身の検証まで）→ 削除ではなく退避 → 外部からの検証
- 検証は応答コードだけでなく、返ってきた本文に痕跡が残っていないかまで見る
サイトは作るときより、たたむときのほうが手順を間違えやすいです。使っていないサイトが1つでも思い当たるなら、まずは契約中のサーバーとドメインを書き出すところから始めてください。
よくある質問
Q. ドメインの契約を解約すれば、サイトは閉じたことになりますか？
ドメインを解約しても、サーバー上のファイルは残ります。ドメイン名での通常アクセスは届かなくなりますが、サーバー側の受け口は開いたままなので不十分です。サーバー側で公開ディレクトリから中身を出すのが確実です。加えて解約したドメインは第三者が取得できるため、他人が同じドメイン名を使う可能性も残ります。
Q. 旧サイトは検索評価を引き継ぐために残しておく、と言われました。
その目的なら、サイトの中身を残す必要はありません。転送設定（301リダイレクト）だけを残し、中身は退避できます。転送用の設定ファイルは残しつつ、WordPress本体は公開ディレクトリから外す形です。「評価の引き継ぎのため」と「WordPressを動かしたまま置く」は別の話なので、混同しないでください。
Q. 使っていないサイトが乗っ取られているかどうか、自分で確認できますか？
見た目の変化では判断できません。改ざんは気づかれないように行われるためです。目安として、身に覚えのない管理者アカウントが増えていないか、公開ディレクトリに覚えのないファイルがないかは、管理画面とFTPで確認できます。ただし痕跡を残さない改ざんもあるため、判断がつかない場合は制作会社かサーバー会社に調査を依頼してください。
Q. バックアップはサーバーの自動バックアップ機能で足りますか？
サーバー側の自動バックアップは保存期間に上限があり、契約を解約すると同時に消えます。閉鎖の前提として取るバックアップは、サーバーとは別の場所（手元のパソコンや外部ストレージ）へ保存してください。ファイルとデータベースの両方が揃っているかも取得時に確認を。片方だけでは復旧できません。