ドメインごと買ったのに、3ヶ月でURLが消えた
Webサイトを買収した翌日から、あなたはそのURLの「所有者」になったつもりでいます。でも実際には、ドメインという権利はレジストラの契約・WHOIS上の登録情報・ネームサーバーの権威設定・更新料の自動引き落とし口座、この4点が全部あなた名義に切り替わって初めて「あなたのもの」になります。そのどれか1点でも前オーナーの名義のまま放置された瞬間に、URLは「資産」から「時限爆弾」に変わります。買収後3ヶ月でドメインが失効し、SEOで積み上げた資産が一夜で蒸発するシナリオは、決して珍しくない。財務DDでは絶対に検出されない、ドメイン移管という名の最悪シナリオを、移管手続きの死因から、DNSレベルの乗っ取り手口、301リダイレクト崩壊、そして移管前DDの実務チェックリストまで分解してまいります。
1. 「URLを買った」という幻想 ── ドメイン移管に失敗する3つの死因
1-1. 死因①：トランスファーロック期間を「知らなかった」だけで60日間足止めになる現実
ドメインの移管（レジストラ間トランスファー）には、ICANN規約に基づく「60日ロック（Transfer Lock）」が存在します。ドメインを新規登録した直後・前回のトランスファーから60日以内のドメインは、別レジストラへの移管申請が拒否されます。M&Aのクロージング日程を逆算して移管スケジュールを組む買い手の大半は、この60日ロックを事前に確認せず、「クロージング後すぐに移管しよう」と思ったら60日間身動きが取れないという状況に陥ります。その60日間、ドメインは売り手のレジストラアカウント配下に存在し続けます。売り手側が悪意を持つケースは少ないですが、売り手が法人清算・倒産・代表交代といった状況に入ったとき、60日間のロック中にドメインがどうなるかは保証されません。
1-2. 死因②：WHOIS情報の連絡先が旧オーナーのメールアドレスのまま更新期限通知が届き続ける
ドメインの更新期限通知・移管承認メール・レジストラからのセキュリティ警告は、すべてWHOIS上に登録された「登録者メールアドレス」に届きます。移管が完了してもWHOIS上の連絡先が旧オーナーのメールアドレスのままになっているケースは、買収後のドメイン管理において最も頻繁に見落とされる盲点です。旧オーナーが退職・廃業してそのメールアカウントが失活した場合、更新期限通知は誰にも届かずにレジストラのシステムに吸い込まれ、更新料の未払いによるドメイン失効→第三者への解放→ドロップキャッチという最悪のシナリオが静かに進行します。ドメインが一度ドロップキャッチされると、取り戻すには法的紛争（UDRP/JPドメインなら裁判）しか手段がなく、費用と時間は膨大です。
1-3. 死因③：更新料の自動引き落とし口座が旧オーナーのクレジットカードに紐づいたまま失効する
移管が完了した後でも、レジストラの決済情報が旧オーナーのクレジットカードに紐づいたままになっているケースが珍しくありません。旧オーナーがカードを解約・変更した瞬間、次の更新日に決済が失敗し、レジストラの猶予期間（通常30〜45日）経過後にドメインが失効します。失効したドメインは「贖回期間（Redemption Grace Period）」に入り、追加費用を払えば元の登録者が取り戻せる状態になりますが、その期間も過ぎれば一般解放されます。決済情報の更新はWHOIS情報の書き換えと同時に確認しなければ、ドメインは「見えない形で失効予約済み」の状態になる── この事実を認識しているM&A実務者は、財務系の仲介業者の中にはほぼ皆無です。
2. ドメインが「消えない」代わりに「別人のもの」になる ── DNS乗っ取りとサブドメインテイクオーバー
2-1. DNSキャッシュポイズニング ── 「正しいURLを入力したのに、全く別のサイトに飛ぶ」状態を作る攻撃
DNSキャッシュポイズニングは、DNSリゾルバのキャッシュに偽の名前解決情報を注入し、正規のドメインを入力したユーザーを攻撃者の管理するIPアドレスへ誘導する攻撃手法です。移管直後の「ネームサーバー変更期」は特に脆弱で、旧ネームサーバーと新ネームサーバーの間でDNS権威の空白が生じる数時間〜数十時間の間、一部のリゾルバが古い情報をキャッシュし続ける状態が発生します。この状態を突かれると、ユーザーは「本物のURL」を入力しているのに「偽サイト」へ誘導されるため、フィッシング・マルウェア配布・ログイン情報詐取といった被害が発生しても運営者側はすぐに把握できません。移管作業はTTL（Time to Live）値を事前に短縮し、DNS伝播を段階的に検証しながら進めるべきです。
2-2. サブドメインテイクオーバー ── 「使い捨てにした旧サブドメイン」を第三者が即座に乗っ取る手法
サブドメインテイクオーバーは、DNSのCNAMEレコードが削除済みの外部サービス（GitHub Pages・Heroku・Netlify・Vercel・AWS S3等）を指したままになっているサブドメインを、第三者が当該外部サービス上で同名のプロジェクト・バケットを作成することで乗っ取る攻撃です。たとえば `staging.example.com` というサブドメインのCNAMEが `example.github.io` を指しているにもかかわらず、GitHub上のリポジトリが削除されていれば、攻撃者は `example.github.io` という名前でGitHub Pagesリポジトリを作成するだけで `staging.example.com` の制御を獲得できます。M&A後のサイト移行でステージング環境・旧CMS・旧CDNのサブドメインが「使われなくなったけどDNSは消していない」状態は非常に多く、これがサブドメインテイクオーバーの温床になります。主要ドメインが安全でも、サブドメインが乗っ取られればクッキーのスコープ次第でセッション情報・認証情報が漏洩します。
2-3. リダイレクト詐称 ── 旧ドメインから新ドメインへの301設定が残ったまま、旧ドメインが第三者に渡る
Webサイト買収後にドメインを新ドメインへ移行するケース（例：`old-example.com` → `new-example.com`）では、旧ドメインから新ドメインへの301リダイレクトを設定した上で、旧ドメインを一定期間保持し続ける対応が標準的です。ところが旧ドメインの更新管理を怠り、第三者に取得されると、旧ドメインの301リダイレクト設定が消去され、代わりに全くの別サイトが公開されるという逆転が起きます。旧ドメインのSEOインデックスが残っていれば、その検索流入は攻撃者のコンテンツへ流れ込み、あなたのブランドイメージの毀損と攻撃者の広告収益化が同時に進行します。
3. PVがゼロになる日 ── 301リダイレクトの引き継ぎ失敗とSEO資産の蒸発
3-1. GoogleはURLを評価する ── ドメインではなく「パーマリンク単位」で積み上がるSEO資産の正体
Googleの検索エンジンは「ドメイン全体」ではなく「URL単位」で評価を積み上げています。被リンク・E-E-A-T・クロール頻度・インデックス状態は、すべて個々のURLに対して蓄積されます。つまり、Webサイト買収で「ドメインのSEO資産を買った」と思っていても、実態は「そのドメイン配下の全URLが持つ個別の評価の集合体を買った」のです。ドメイン移管後にURLが変わる・301リダイレクトの設定が抜ける・Googleに正しくクロールされない期間が生じる、そのどれかが起きた瞬間に、個別URL単位の評価の引き継ぎが止まり、月間数百万PVのサイトが数週間で急落します。
3-2. 「301は設定した」のに機能しない ── .htaccessの記述ミス・CloudflareのSSL設定漏れ・CMSのパーマリンク再設定忘れ
「301リダイレクトは設定しました」という言葉ほど信用できないものはなく（これはM&A仲介の現場で実際に何度も聞いた言葉です）、設定したつもりが機能していないケースは3つの場所で起きます。①.htaccessの記述順序ミス（RewriteRuleより先にRewriteBaseが必要なのに逆になっている等）、②CloudflareのSSL/TLS設定との不整合（HTTPSへのリダイレクトループが発生し、Googlebotがクロールを中断する）、③CMSのパーマリンク設定リセット（WordPressを新サーバーへ移行した際にパーマリンク設定が「数字ベース」に戻り、全記事URLが変わる）。これらは「ツールで確認しなければ気づかない」種類のミスであり、移管後すぐにSearch Consoleのカバレッジレポートを目視確認しなければ、発覚まで数週間のロスが生じます。
3-3. 301のクロール引き継ぎには「最大1年」かかる ── 急落後に後手で直しても、評価が戻るまでの不可逆な時間コスト
Googleが301リダイレクトを完全に評価し、リンクエクイティ・インデックス・検索順位を新URLへ引き継ぐには、ページの規模・被リンク数・クロール頻度に応じて最短で数週間、一般的には数ヶ月、大規模サイトでは1年以上かかることが実測されています。301の設定が正しかったとしても、この引き継ぎ期間中にオーガニック流入が30〜70%落ちることは珍しくありません。問題は「後から正しく直しても、落ちた評価がそのまま戻るわけではない」という点で、移管後の急落を「様子を見ましょう」で放置した3ヶ月は、競合がその期間に検索順位を埋めていくため、回復しても元の水準に届かない状況が生まれます。SEO資産の引き継ぎは、移管後の対応ではなく移管前の設計の問題です。
4. 移管前DDで確認すべき7項目 ── 実務チェックリストと確認コマンド
4-1. ①ネームサーバーの現状確認 ── whoisコマンドとdigコマンドで「権威の所在」を特定する
移管作業を始める前に、まず「今このドメインのDNS権威を誰が持っているか」を確認します。ターミナルから `whois ドメイン名` を実行するとレジストラ情報・登録者情報・ネームサーバーが取得でき、`dig ドメイン名 NS` を実行すると現在の権威DNSサーバーが確認できます。CloudflareやRoute 53への移行後は、`dig ドメイン名 NS +short` の出力が新ネームサーバーを正しく返すことを必ず検証してください。移管後もwhoisが旧レジストラのネームサーバーを返している状態は、DNS伝播が未完了または設定誤りの証拠です。TTL値（`dig ドメイン名 A` の応答で確認）が高いまま移管を実施すると、古い情報が世界中のリゾルバにキャッシュされ、伝播完了まで想定外の時間がかかります。移管の72時間前にはTTLを300秒（5分）以下に下げておくのが実務上の標準です。
4-2. ②DNSレコードの棚卸し ── CloudflareダッシュボードとZone Transfer出力で全レコードを一覧化する
Cloudflareへの移行後に最も頻繁に起きる問題が「移行前に存在したDNSレコードの一部が新環境に引き継がれていない」というレコード欠落です。移管前にZone Transferが許可されている場合は `dig ドメイン名 AXFR @旧ネームサーバー` で全レコードを取得できますが、許可されていない場合は旧ホスティング管理画面のDNS設定画面からCSVエクスポートまたはスクリーンショットで記録します。特に見落とされやすいのはMXレコード（メール送受信）・SPFレコード（メール送信ドメイン認証）・DKIMレコード（メール署名）・DMARCレコードで、これらが引き継がれていないとメール送信がスパム判定されるため、M&A後の顧客への一斉連絡が届かないという笑えない事態が起きます。
4-3. ③サブドメイン一覧の取得 ── 公開情報から棚卸しし「使われていないCNAME」を全件削除する
サブドメインテイクオーバーを防ぐためには、まず「存在するサブドメインの全件一覧」を取得する必要があります。非公開の内部サブドメインは開示を受けるとして、公開情報から掘り起こす方法として有効なのが、証明書透明性ログ（Certificate Transparency Logs）の参照です。`crt.sh` というウェブサービスでドメイン名を検索すると、そのドメインに対してこれまで発行されたSSL/TLS証明書の履歴が全件表示され、かつてサブドメインとして稼働していたURLが芋づる式に把握できます。一覧取得後、各サブドメインについて `dig サブドメイン CNAME` を実行し、そのCNAMEが指す先のサービスが現在も有効かを確認、有効でない外部サービスを指しているCNAMEはテイクオーバーリスクが高いため即時削除してください。
4-4. ④有効期限アラートと決済情報の二重確認 ── 移管直後に最初にやるべき最重要作業
ドメイン移管が完了した翌日に必ず実施すべきことが2点あります。ひとつは有効期限アラートの設定で、新レジストラのダッシュボードで「有効期限の90日前・30日前・7日前」に更新リマインダーメールが届くよう設定し、受信先メールアドレスが確実に生きているアドレス（できれば2人以上のメンバーが受信する共有メールアドレス）に設定します。もうひとつは決済情報の更新確認で、旧オーナーのクレジットカードが解除されていること、新しいクレジットカードが有効期限付きで登録されていること、自動更新が有効（オプトイン）になっていることを新レジストラの設定画面から目視で確認します。この2点だけで死因②と死因③の大半は防げますが、M&A後の引き継ぎ作業リストに「ドメイン更新アラートの設定」を明示的に入れているケースは、経験上ほぼ皆無です。
4-5. ⑤WHOIS情報の書き換え確認 ── プライバシー保護機能の有無と「実体の連絡先」の切り替え
WHOISは、プライバシー保護（WHOIS Privacy/Proxy Service）を有効にしている場合、登録者情報の代わりにレジストラ側のプロキシ情報が表示されます。プライバシー保護が有効な状態では表面上のWHOISは変わらないため「書き換えた」と誤認しやすいのですが、プライバシー保護の「実体」側の連絡先（メールアドレス・組織名）も確実に新オーナーのものに変更する必要があります。これを確認するには、プライバシー保護機能を一時的に無効化してWHOISを取得するか、レジストラの管理ダッシュボードで「実際の登録者情報」を直接確認するしかありません。旧オーナーの情報が残ったままだと、移管承認メールや更新確認メールが旧オーナー宛てに届き続けます。
4-6. ⑥301リダイレクトの動作確認と検索インデックスの引き継ぎ検証
301リダイレクトの設定後、確認はブラウザのアドレスバーではなく `curl -I -L 旧URL` コマンドで行います。ブラウザはキャッシュの影響でリダイレクトが正しく動作しているように見せてしまうため、ヘッダーを直接確認するcurlが正確です。出力の1行目が `HTTP/1.1 301 Moved Permanently` であること、そしてその後 `Location:` ヘッダーが正しい新URLを指していることを確認してください。Search Consoleでは移管後にURL検査ツール（旧フェッチ機能）を使い、Googlebotが旧URLから新URLへ正しく辿れることを検証します。インデックス引き継ぎの進捗はSearch Consoleの「カバレッジ」レポートの「有効（リダイレクトあり）」から「有効（正規URL）」への移行数を週次でウォッチし、停滞が見られた場合は即座に設定を見直します。
4-7. ⑦トランスファーロックの解除タイミングとクロージング日程の逆算設計
最後に、M&Aのクロージング日程設計に組み込むべき移管スケジュールの考え方です。移管には「①ロック解除確認→②移管申請→③メール認証（旧オーナー・新オーナー双方）→④レジストラ間の移管処理（最大5〜7営業日）→⑤DNS伝播（最大72時間）」という工程があり、最悪ケースで約10〜14日かかります。クロージング当日に移管作業を開始しても、最長2週間はドメインが「移管中」の不安定な状態に置かれることを前提に、クロージングの最低2週間前に移管作業を開始できるよう、LOI（意向表明書）段階から売り手に協力を要請するのが実務上の正解です。これをクロージング後のToDoリストに入れている仲介業者は、残念ながらほぼ存在しません。
5. 売り手の「移管準備」が、最終的な譲渡対価を守る
5-1. ドメイン・DNS管理の属人化 ── 「自分しか触ったことがないレジストラアカウント」が買収を難航させる
売り手サイドのM&A準備で、ドメイン・DNS管理が代表1人の個人アカウントに集約されているケースは非常に多くあります。「自分しかログインできないGodaddyアカウント」「二段階認証の登録デバイスが手元にないと入れないレジストラ」「WHOIS情報が個人名義の個人メールアドレスのみ」── これらは売り手にとっては日常の些細な問題ですが、買い手の立場から見れば「ドメインの権利が個人に紐づいており、万一のときに移管できないリスク」として映ります。譲渡前の準備として、法人名義・法人メールアドレスへのWHOIS書き換え、法人クレジットカードへの決済切り替え、複数担当者がアクセス可能なレジストラアカウントへの移行を完了させた売り手のIMは、ドメイン移管リスクを個別交渉の減額材料にされることなく、スムーズに対価交渉を進められます。
5-2. 「ドメインDD」を正式な工程として組み込む時代への転換
財務DD・法務DD・税務DDという3大DDに加えて、技術系Webサイト買収において「ドメインDD」を正式な工程として組み込む必要性は、ドメインのセキュリティリスクの高度化と、SEO資産の財務的価値の大きさから、2024年以降明確に高まっています。ドメインDD の確認項目は本記事で列挙した7点が基本ですが、さらに踏み込めばHTTPSの証明書発行元の確認・HSTS（HTTP Strict Transport Security）の有効期限・DNSSECの有効/無効・CAA（Certification Authority Authorization）レコードの設定まで含め、ドメインとDNSに関わるセキュリティ設定を体系的にチェックすることが、Web資産を扱うM&AにおけるDDの最前線です。「ドメインの管理状況に問題がある」という事実が発覚した場合は、移管作業の工数・専門家費用・移管期間中の事業リスクを定量化した上で、譲渡対価の調整材料として堂々と交渉のテーブルに載せるべきです。
ドメインは「URLという文字列」ではなく、レジストラ契約・WHOIS情報・ネームサーバー設定・DNS全レコード・SSL証明書・有効期限管理・決済情報、この7層が重なって初めて成立する「権利の集合体」です。この7層のどれか1枚が剥がれた瞬間に、SEOで積み上げた何年もの資産が数週間で消えます。財務DDは数字を見ます。税務DDは過去の申告を見ます。でも誰もネームサーバーを `dig` で叩かない、サブドメインを `crt.sh` で棚卸しない、WHOISの連絡先メールアドレスが生きているかを確認しない── その「誰もやらない」作業の中に、数百万PVと数千万円の価値が眠っています。
