「もう使わなくなったWebサイトの独自ドメインを解約（失効）したから、レンタルサーバーの中のWordPressファイルはそのまま放置していても誰にも見られないはず」と思い込んでいないでしょうか。
実は、レンタルサーバーの契約自体が継続していて、サーバー上にWordPressのプログラム一式やデータベース、ドメイン設定が残っている場合、独自ドメインが失効した後でも外部からアクセスされたり、攻撃の踏み台にされたりする危険性が十分にあります。
本記事では、なぜドメイン廃止後も外部から到達されてしまうのかという4つの具体的な仕組み（意味）と、現在稼働中の別サイトを守るための安全な削除・アクセス遮断手順を図解付きで詳しく解説します。
独自ドメインが失効してもサーバー上のWordPressが安全ではない理由
インターネットにおける「独自ドメイン（例：old-example.com）」は、現実世界の店舗に例えるなら「表通りに出している看板や住所表記（案内板）」にあたります。一方で、レンタルサーバー上にあるWordPressのファイル群やデータベースは「店舗の建物そのもの」です。
独自ドメインの契約を廃止（失効）すると、通常のブラウザ検索や標準的なDNS（名前解決）からはそのサイトへたどり着けなくなります。
しかし、レンタルサーバーの契約が生きている限り、サーバー上の「建物（WordPressのPHPプログラムやMySQLデータベース）」は電気も水道も通ったまま稼働し続けています。そのため、表通りの看板を使わずに直接建物の裏口を叩くような方法を使われると、外部からあっさりとページやログイン画面（wp-login.php）を開かれてしまいます。
| 外部からの到達経路 | なぜアクセスできてしまうのか（仕組みの要点） | 主な危険度と影響 |
|---|---|---|
| サーバー会社の初期ドメイン経由 | サーバー契約中に有効な初期ドメインのURL＋フォルダ名で直接開かれる | 管理画面の露出・不正ログイン試行 |
| Hostsファイルの書き換え | 攻撃者が自分のPCで「サーバーIPと旧ドメイン」を直接紐づけて開く | 失効後でも旧サイトがそのまま動作 |
| ドメインのドロップキャッチ | 手放したドメインを第三者が再取得し、元のサーバーIPやNSに向ける | 他人のドメインで自サーバーのWPが表示 |
| 同一サーバー内の内部侵入 | 放置された古いWPが突破口となり、同じサーバー内の別サイトへ感染する | 最危険（稼働中の本番サイトまで改ざん） |
ここからは、これら4つの経路がそれぞれどのような仕組みで発生するのか、1つずつ詳しく見ていきましょう。
サーバー会社の初期ドメイン経由で直接アクセスされる仕組み
レンタルサーバーを契約すると、最初にサーバー会社から「初期ドメイン（例：〇〇.xsrv.jp や 〇〇.sakura.ne.jp など）」が自動で付与されます。この初期ドメインは、自分で取得した独自ドメインとは無関係に、レンタルサーバーの契約が継続している限りずっと有効な状態でインターネット上に公開されています。
初期ドメイン配下にサブフォルダを作る構造（さくらインターネット等）
さくらインターネットなどのように、初期ドメインの公開ディレクトリ（例：/home/ユーザー名/www/）の直下にサブフォルダ（例：/www/old-site/）を作成し、そこへ独自ドメインを割り当ててマルチドメイン運用する構造のサーバーでは特に注意が必要です。
この構造では、独自ドメインが失効した後も、初期ドメインのURLの末尾にフォルダ名を繋げるだけ（例：https://ユーザー名.sakura.ne.jp/old-site/）で、外部の誰もがそのまま古いWordPressのトップページやログイン画面にアクセスできてしまいます。
ドメインごとにフォルダが独立している構造（エックスサーバー等）
エックスサーバーなどのように、初期ドメイン用のフォルダ（/〇〇.xsrv.jp/public_html/）と独自ドメイン用のフォルダ（/old-domain.com/public_html/）が上の階層から別々に分かれている構造であれば、初期ドメインのURLから独自ドメインのフォルダへ直接回り込むことはできません。
ただし、テスト環境や初期構築として「初期ドメインの公開ディレクトリ直下（またはそのサブディレクトリ）」にWordPressをインストールして残していた場合は、当然ながら初期ドメインのURLを直接叩くことで外部からアクセス可能な状態になります。
Hostsファイル書き換えやドロップキャッチ（第三者再取得）による到達経路
「エックスサーバーのようにフォルダが独立している構造なら、独自ドメインが失効すればもうアクセスできないのでは？」と思うかもしれません。
ところが、レンタルサーバーの管理パネル側で「その独自ドメインの登録設定（Webサーバーのバーチャルホスト設定）」を削除していない場合、以下の2つの方法で外部から強制的に呼び出すことが可能です。
自身のPCのHostsファイルを書き換えて強制アクセスする手法
そもそもWebサーバー（ApacheやNginx）は、アクセスしてきたブラウザから「どのドメイン名を見に来ましたか？（HTTPのHostヘッダ）」という申告を受け取り、サーバー内の設定一覧（バーチャルホスト設定）と照合して表示するフォルダを振り分けています。
独自ドメインが失効して世界中のDNSから消えていたとしても、攻撃者や第三者が自分のパソコン内にある「Hosts（ホスツ）ファイル」に以下の1行を書き加えるとどうなるでしょうか。
# 攻撃者のパソコン内の hosts ファイル記述例
203.0.113.50 old-example.com
このように設定してブラウザで old-example.com を開くと、パソコンは世界中のDNSに問い合わせることなく、直接そのレンタルサーバーのIPアドレス（203.0.113.50）へ通信を送り、「old-example.com を見に来ました」とリクエストします。サーバー側にドメイン設定が残っていると、サーバーは正規のアクセスだと判断して、残っていた古いWordPressをそのまま表示・動作させてしまいます。
なお、「昔そのドメインがどのサーバーのIPアドレスを使っていたか」という履歴は、魚拓サービス（Wayback Machine）やセキュリティ調査ツール（SecurityTrailsなど）を使えば誰でも簡単に調べられるため、狙われるリスクは決してゼロではありません。
手放したドメインを第三者が再取得する「ドロップキャッチ」
運用を終えて契約更新しなかった独自ドメインは、一定の猶予期間を過ぎると誰でも再取得できる状態になり、ドメインオークションやバックオーダー業者を通じて第三者（中古ドメイン業者やアフィリエイターなど）にすぐ再取得されることがあります。これを「ドロップキャッチ」と呼びます。
もし新しい所有者がそのドメインのネームサーバーを元のレンタルサーバー会社のままにした場合や、過去のDNS履歴を参考に元のサーバーのIPアドレスをAレコードに設定した場合、サーバー側にドメイン設定とWordPressファイルが残っていると、「赤の他人が所有するドメインなのに、自分のレンタルサーバー上にある古いWordPressが表示されてしまう」という事態が発生します。
最も危険な「同一サーバー内の別サイトを経由した内部侵入（クロスサイトコンタミネーション）」
ここまで紹介した3つは外部から直接その古いサイトへアクセスされる経路でしたが、実務上もっとも深刻な被害をもたらすのが「クロスサイトコンタミネーション（同一サーバー内での交差汚染・内部感染）」と呼ばれるパターンです。
1つのレンタルサーバー契約（1つのサーバーアカウント）の中で、現在も運営しているメインのWebサイトとは別に、昔作った使っていないWordPressを放置しているケースは少なくありません。このとき、放置された古いWordPressがサーバー全体の致命的なセキュリティホール（侵入窓口）になります。
- 放置された古いWordPressは脆弱性の塊になる：使わなくなったサイトは誰も管理画面を開かなくなるため、WordPress本体やプラグイン、テーマの更新が何年も止まった状態になります。既知の脆弱性が放置されているうえ、推測されやすいパスワードのままログイン画面が初期ドメインやHosts経由で突破されると、攻撃者に不正なプログラム（バックドア・Webシェル）をサーバー内に設置されます。
- 同じサーバーアカウント内の別フォルダへ水平移動される：一般的な共用レンタルサーバーでは、1つの契約アカウント内にある複数のドメインフォルダはすべて「同じOSユーザー権限」で動いています。そのため、古いWordPressのフォルダから一度サーバー内部へ侵入されると、プログラムから隣のフォルダにある「現在稼働中の本命サイトのファイル」も自由に読み書き（改ざん）できてしまいます。
- 稼働中のメインサイト改ざんやサーバー凍結に直結する：結果として、「現在運営しているメインサイトのWordPressは常に最新にアップデートしてセキュリティ対策もしていたのに、同じサーバーの隅に放置していた古いWordPressから侵入されてメインサイトまで改ざんされた」「サーバー全体がフィッシングサイトやスパムメール送信の踏み台にされ、サーバー会社からアカウントごと利用停止（凍結）された」という深刻な被害につながります。
不要なWordPressを安全に消去・遮断するための手順
このように、使わなくなったWordPressをレンタルサーバー上に残しておくメリットは1つもなく、放置するほどセキュリティ上の大きな負債になります。
すでに独自ドメインを廃止したサイトや、今後使う予定のないWordPressがある場合は、以下の手順でファイル・データベース・ドメイン設定をセットで確実に消去しましょう。
WordPressのディレクトリとファイル一式の削除（事前にDB名を確認）
FTPソフト（FileZillaなど）やレンタルサーバーの「ファイルマネージャー」を開き、不要になったWordPressがインストールされているディレクトリ（フォルダ）ごと、すべてのファイルを削除します。
ただし、いきなりファイルを消してしまうと「どのデータベースを使っていたか」が分からなくなるため、削除する直前にWordPress直下にある wp-config.php を開いて、以下の行に書かれているデータベース名（DB_NAME）を必ずメモしておきましょう。
// wp-config.php 内の確認箇所
define( 'DB_NAME', 'example_wp1' ); // ← このデータベース名を控えてからファイルを削除するMySQLデータベースの削除
先ほど wp-config.php で確認したデータベース名を、レンタルサーバーの管理パネル（「MySQL設定」や「データベース設定」メニュー）または phpMyAdmin で照合し、該当するMySQLデータベースそのものを削除します。
※同じサーバー内で現在も稼働している別サイトのデータベースを誤って消さないよう、データベース名を一文字ずつ指差し確認してから削除してください。
サーバー管理画面でのドメイン設定削除
ファイルとデータベースを消しただけでは、サーバーのWeb設定（バーチャルホスト設定）が残ったままになり、不要なアクセスやエラーログ、ドロップキャッチ時のトラブルの原因になります。
レンタルサーバーの管理パネルにある「ドメイン設定」メニューを開き、廃止した独自ドメインの登録設定自体をサーバーから削除してください。これでHostsファイル書き換えやドロップキャッチによる強制アクセスも受け付けなくなります。
過去の参照用などでどうしてもデータを残したい場合の処置
「過去の記事データや画像ファイルを資料として残しておきたい」という場合は、FTPソフトやバックアップ機能を使って自分のパソコン（ローカル環境）やクラウドストレージに一式ダウンロードして保管し、レンタルサーバー上からは削除するのが一番安全です。
どうしても一時的にレンタルサーバー上にファイルを置いておく必要がある場合は、そのまま公開状態にせず、以下のいずれかの方法で外部からのHTTPアクセス（Web経由のプログラム実行）を確実に遮断してください。
- 該当フォルダのパーミッション（属性）を「000」に変更する：FTPソフトやファイルマネージャーから、対象ディレクトリのアクセス権限を
000（すべての読み取り・書き込み・実行を拒否）に変更します。 - .htaccess ファイルで外部からのアクセスを拒否する：対象のWordPressフォルダ直下にある
.htaccessファイルの先頭に、以下の記述（Apache 2.4系の場合）を追加してすべてのWebアクセスを遮断します。
# .htaccess の先頭に記述して外部からのHTTPアクセスをすべて遮断する（Apache 2.4以降）
Require all deniedまとめ
独自ドメインの契約を廃止（失効）した後に、レンタルサーバー上にWordPressを残しておくことで生じる4つのリスクと対策について解説しました。最後に重要なポイントを振り返ります。
- 初期ドメイン経由での到達：サーバー契約中はずっと生きている初期ドメイン（〇〇.sakura.ne.jpなど）のURLにフォルダ名を繋げることで、古いWordPressに直接アクセスされるケースがある。
- Hosts書き換え・ドロップキャッチによる到達：サーバー管理画面でドメイン設定を消していないと、攻撃者がPCのHostsファイルを書き換えてIP直結で開いたり、第三者にドメインを再取得（ドロップキャッチ）された際に古いサイトが表示されたりする。
- 同一サーバー内の別サイトへの内部侵入（クロスサイトコンタミネーション）：更新が止まった古いWordPressが突破口となり、同じサーバーアカウント内で稼働している本番サイトまで改ざんや踏み台被害に遭うリスクが最も危険。
- 安全な撤去の3点セット：不要になったWordPressは「ディレクトリごとのファイル削除」「MySQLデータベースの削除」「サーバー管理パネルでのドメイン設定削除」の3つをセットで実施する。データを残す場合はPCへダウンロードするか、パーミッション
000またはRequire all deniedでWebアクセスを遮断する。
過去のキャンペーンサイトやテスト用のWordPress、すでに閉鎖したブログのデータがレンタルサーバーの片隅に眠っていないか、ぜひこの機会にサーバーのファイルマネージャーとドメイン設定画面を点検してみてください。
