Meta広告のドメイン認証ができない原因と対処手順｜メタタグ・DNS・HTMLファイルの3方式切り分けフロー

この記事のポイント

• Metaドメイン認証ができない原因はメタタグ・DNS・HTMLファイルの方式別3系統と、伝播待ち・他ビジネス認証済みの共通2系統に分類できる
• 2025年6月のAEM刷新後、ドメイン認証はリンク編集権限とブランドセーフティ管理が主目的になり、必須度は相対的に下がっている
• 「反映されない」の多くは設定ミスではなく、外部ツールで客観確認すれば伝播待ちだと判明するケースが多い
• 「他のビジネスが認証済みです」エラーは所有者特定→権限依頼・削除依頼・パートナー共有の3分岐で対処する

Meta広告の配信準備を進めていて、ビジネスマネージャのドメイン認証だけがどうしても完了しない——この状態で午後の作業が止まってしまう広告運用担当者は少なくありません。メタタグを設置したはずなのに反映されない、DNSにTXTレコードを追加したのに確認ボタンを押すたびにエラーになる、あるいは「ドメインはすでに他のビジネスが認証済みです」という見慣れないメッセージが出て先に進めない。原因はどれも似たような画面の裏側にありますが、実際には方式ごとに切り分け方がまったく異なります。

本記事では、Meta ドメイン認証 できない という状態を、メタタグ・DNS TXTレコード・HTMLファイルアップロードの3方式別に、さらに伝播待ちと他ビジネス認証済みという共通トラブルを加えた5系統で整理します。あわせて2026年時点でこの認証がどこまで必須なのかという前提も見直し、当日中に「直すべきか、待てばいいのか」を判断できる状態を目指します。

Metaのドメイン認証ができない主な原因は？【結論：方式別3系統＋共通2系統】

図1: 5つの原因を切り分ける診断フロー図

Metaのドメイン認証ができない原因は、選択した認証方式（メタタグ・DNS TXTレコード・HTMLファイルアップロード）ごとの設置ミスと、方式に関係なく起こる伝播待ち・他ビジネスによる認証済みという共通要因の、合計5パターンにほぼ収まります。まずこの全体像を掴んでおくと、どのセクションを読めばいいかが一目でわかります。

原因の全体マップと診断の入口

Meta Business Suite（ビジネスマネージャ）のドメイン認証は、ビジネスポートフォリオの「ブランドセーフティ」→「ドメイン」から行います。ここで確認ボタンを押した際に出るエラーメッセージの内容によって、進むべき方向が変わります。「見つかりませんでした」系のメッセージであればメタタグ・DNS・HTMLいずれかの設置不備か伝播待ちを疑い、「すでに他のビジネスが認証済みです」というメッセージであれば所有権の競合を疑う、という切り分けがまず最初の分岐点です。

まず確認する3項目（入力形式・www有無・認証ステータス表示）

具体的な設定に入る前に、次の3点だけは共通で見ておく価値があります。

• 入力したドメインに https:// や末尾のスラッシュが混入していないか
• www.example.com のようにwwwを含めて入力していないか(認証はルートドメイン単位が原則)
• ビジネスマネージャ上のステータス表示が「保留中」なのか「失敗」なのかを区別できているか

この3点だけで解決するケースも一定数あり、次のセクション以降に進む前のスクリーニングとして機能します。

そもそも2026年現在、ドメイン認証は必須なのか？

必須から選択へ、認証の重心の変化

2026年時点では、Metaのドメイン認証は「必須設定」というより「一部の運用形態で必要になる管理設定」という位置づけに変わっています。すべてのアカウントが即座に対応を急ぐ必要はなく、まずは自分のケースが該当するかどうかを見極めることが優先です。

2025年6月のAEM仕様変更で変わったこと

Jon Loomer Digitalの記事「Meta Announces Big Changes to Website Conversion Campaigns」では、2025年6月にMetaがAggregated Event Measurement(AEM)まわりの仕様を刷新し、イベントマネージャからAEMタブ自体が削除されたと指摘されています。iOS14対応期に広く言われていた「コンバージョンイベントの優先順位付けのためにドメイン認証が必須」という前提は、この刷新によって実質的に組み替えられた形です。日本の実務では、この変更をきっかけに「ドメイン認証=計測精度に直結する必須作業」という理解を一度アップデートしておく方がよいと考えられます。認証の役割は、イベント優先順位付けから、リンク編集権限やブランドセーフティ、複数ビジネスマネージャ間の所有権管理へと重心が移っています。

それでも認証すべき3つのケース

とはいえ、認証を後回しにしてよいわけではありません。次のケースでは実質的に必須と考えた方が安全です。

1. Metaピクセルやコンバージョンリンクの編集権限を細かく制御したい場合
2. 同一ドメインを複数のビジネスマネージャで扱う可能性がある場合(代理店移管・事業部間の分割など)
3. ECプラットフォームとの連携やコマース機能を利用する場合

これらに当てはまらない、単純な自社サイト1本での運用であれば、認証エラーに時間を使いすぎず、いったん配信を優先して後日対応するという判断も現実的な選択肢です。

メタタグが反映されない・確認できない時の対処手順

メタタグ方式で反映されない場合、原因の大半は「head内に設置できていない」か「Metaのスクレイパーからはタグが見えていない」のどちらかです。ブラウザで見えているかどうかと、Metaが見ているかどうかは別問題だと意識することが出発点になります。

ページソースでタグ設置を確認する（Ctrl+U→Ctrl+F）

まず自分の目で客観確認します。該当ページを開き、Ctrl+Uでページソースを表示し、Ctrl+Fで facebook-domain-verification を検索します。ここで見つからなければ、そもそも設置自体ができていません。見つかった場合でも、次の項目までチェックする必要があります。

head内に無い・テーマ上書きで消えるパターンの直し方

WordPressなどCMSでは、テーマ更新やプラグインの設定リセットによって、一度入れたはずのメタタグがheadの外に出てしまったり、丸ごと消えてしまうことがあります。ヘッダー編集用プラグイン経由で入れている場合は、そのプラグインが無効化・更新されていないかを確認します。手打ちでテーマファイルに追記している場合は、子テーマ化されていないと更新のたびに消える点も見落としやすい失敗パターンです。

CDN・キャッシュでMetaのスクレイパーに見えていない場合

Ylopo Help Centerの「Facebook Domain Verification Troubleshooting」では、Metaのスクレイパーが実際に取得しているHTML(scraper view)を確認し、そこにタグが存在するかで設置不備を断定するフローが紹介されています。自分のブラウザには表示されていても、CDNやキャッシュプラグインが古いHTMLを配信していれば、Meta側からは反映前の状態にしか見えません。この確認にはMetaシェアデバッガー(Sharing Debugger)が使えます。対象URLを入力して「もう一度スクレイピングする」を実行し、取得結果にタグが含まれているかを見ることで、キャッシュ起因かどうかを客観的に切り分けられます。CDN側でキャッシュパージを行ってから再度確認するのが定石です。

DNS TXTレコードで所有確認が完了しない時の対処手順

DNS方式が完了しない場合、原因のほとんどは「サブドメインへの誤設置」か「DNS反映待ち」のどちらかに集約されます。まず外部ツールで伝播状況を見てから、設定ミスかどうかを判断する順序が効率的です。

DNSチェッカーで伝播状況を外部確認する

Graphed Blogの「How to Verify Domain in Meta Business Manager」では、dnschecker.orgのような外部DNSルックアップサービスで世界各地からの伝播状況を確認したうえで、Meta側の確認ボタンを押すという検証順序が紹介されています。自分の環境だけでTXTレコードを確認しても、それはローカルのDNSキャッシュを見ているにすぎず、Meta側のサーバーからの見え方とは限りません。ドメインを入力し、TXTレコードの一覧に発行された値が表示されているかを世界規模で確認することで、「待てばいいのか」「設定自体が間違っているのか」を切り分けられます。

ルートドメインではなくサブドメインに追加している誤り

典型的な失敗が、example.com ではなく www.example.com や blog.example.com といったサブドメイン側のDNS設定にTXTレコードを追加してしまうケースです。認証対象がルートドメインである以上、レコードもルートドメインのゾーンに追加する必要があります。DNS管理画面でホスト名を @ にして登録するのが一般的な指定方法ですが、レジストラやDNSサービスによって表記が異なるため、設定後は必ず前項のDNSチェッカーで実際に反映されているか確認します。

最大72時間待つべきケースの見極め

Meta Business Help Centerの「Troubleshoot Why You Can’t Verify Your Domain」では、DNS反映には最大72時間かかる場合があると明記されています。DNSチェッカーで正しい値が世界的に反映されているにもかかわらずMeta側の確認だけ通らない場合は、設定ミスではなく単純な伝播待ちである可能性が高く、時間を空けて再確認する対応で足ります。逆に、24時間以上経っても外部ツール側でも反映が確認できない場合は、レコードの追加先や値そのものを見直す必要があります。

HTMLファイルアップロードで認証できない時の対処手順

HTMLファイル方式は設置場所さえ合っていれば確実性が高い一方、サーバー構成によっては見落としが起きやすい方式でもあります。ポイントは「ダウンロードしたファイルをそのままの名前で、ルート直下に置けているか」です。

ルートディレクトリ直下に置けているかをURLで確認

Metaからダウンロードしたファイルは、https://example.com/ファイル名.html の形でルートディレクトリ直下に配置する必要があります。サブディレクトリに置いてしまう、あるいはCMSの管理画面経由でアップロードした結果、意図しないパスに保存されてしまうケースがよくあります。確認方法はシンプルで、実際にそのURLをブラウザで直接開き、ファイルの中身が表示されるかどうかを見るだけです。404が返る場合は設置場所の誤りが確定します。

ファイル名変更・リダイレクト・Basic認証が失敗を招くパターン

Meta Business Help Centerが挙げる失敗原因の中には、コード設置場所の誤りとあわせて、コピー時のタイプミスやキャッシュも含まれています。HTMLファイル方式で実務上つまずきやすいのは次のようなパターンです。

失敗パターン	症状	対処
ファイル名を変更してしまった	直URLアクセスで404	ダウンロード時の名前のまま設置し直す
wwwなし↔ありでリダイレクトが発生	ブラウザでは表示されるがMeta側で失敗	リダイレクト先ではなく認証対象URL自体で200が返るか確認
Basic認証やIP制限がかかっている	Metaのスクレイパーがアクセスできない	対象ファイルのみ認証除外設定を行う

開発中のステージング環境にBasic認証をかけたまま本番切り替え作業をしている場合など、意外と見落としやすいのがこのアクセス制限のパターンです。

「ドメインはすでに他のビジネスが認証済みです」と出る場合の対処

同じ領土をめぐる二つの旗のせめぎ合い

このエラーが出る場合、自分たちの設定が誤っているのではなく、同じドメインが別のビジネスマネージャですでに認証済みであることが原因です。まず所有者を特定し、そのうえで3つの対処に分岐させます。

所有しているビジネスIDを特定する方法

多くの場合、心当たりがあるのは過去に利用していた代理店のビジネスマネージャか、自社内の別ポートフォリオです。Meta広告アカウントの初期設定を担当した部署や、以前配信を委託していた代理店に心当たりを確認するのが最初のステップになります。

前代理店が保持しているケースの依頼手順と移管時の注意

AdScale Help Centerの「Facebook integration - Domain verified by another business」では、このエラーへの対処を、所有者の特定を前提に①アクセス権限の付与を依頼する②所有側からドメインを削除してもらう③パートナー割り当てで共有する、という3分岐で整理しています。前代理店が保持している場合は、削除を依頼する際に、旧代理店側で設置されたメタタグやDNSのTXTレコードも撤去してもらうよう併せて依頼する必要があります。旧タグが残ったままだと、新たに自社側で設置したはずのタグと競合し、再度認証が通らなくなることがあるためです。代理店移管全体で見るべき論点は、広告アカウント移管時に失うデータと守るべき設定のチェックリストにも整理しています。

自社の別ビジネスポートフォリオが保持しているケース

社内に複数のビジネスマネージャが存在し、過去の担当者が別のポートフォリオで先に認証していた、というケースも珍しくありません。この場合は削除の依頼ではなく、社内での権限調整で完結します。同じ組織内であれば、パートナー割り当て機能を使って現行のビジネスマネージャにドメインの利用権限だけを共有する方法が、削除・再認証よりも手間が少なく済みます。

どの方式を選ぶべきか？メタタグ・DNS・HTMLファイルの使い分け

図2: 3つの認証方式を比較する選択マトリクス

3方式のうちどれを選ぶべきかは、サイトの管理権限とCMS構成によって決まります。迷った場合はDNS方式を軸に考えるのが実務上の基本線です。

DNS方式が最も堅牢な理由と向かないケース

DNSレコード(TXT)による認証は、テーマ更新やキャッシュクリアの影響を受けず、一度設定すれば安定して維持できる点が強みです。一方で、DNS管理権限が代理店やシステム担当者側にあり、広告運用担当者自身が触れない場合は、都度依頼が発生するため小回りが利きにくいという弱点もあります。

WordPressなどCMS別の現実的な選択

WordPressサイトであれば、ヘッダー編集用プラグインでメタタグを入れる方法が最も着手しやすく、DNS管理権限を持たない運用担当者でも完結できます。ただし前述の通りテーマ更新で消えるリスクがあるため、可能であればDNS方式との併用、あるいは長期的にはDNS方式への一本化が安定運用につながると考えられます。静的サイトやサーバー管理権限がある場合は、HTMLファイル方式も設置さえ間違えなければ十分に堅実な選択肢です。

それでも認証できない時のチェックリストとサポート問い合わせ

上記の手順を一通り試しても解決しない場合は、Metaサポートへの問い合わせに進みます。ただし問い合わせ前に、自分でつぶせる項目を最終確認しておくと、やり取りの往復を減らせます。

問い合わせ前の最終チェックリスト

• ドメイン入力欄にプロトコルやwwwが混入していないか
• 選択した認証方式のタグ・レコード・ファイルが、外部ツールで客観的に確認できているか
• DNS方式の場合、追加24〜72時間の伝播待ちを経過しているか
• 「他のビジネスが認証済み」エラーの場合、社内外の心当たりを一通り確認したか
• ブラウザのキャッシュではなく、シェアデバッガーなど外部ツールでの再取得を試したか

サポートに伝える情報の準備

問い合わせ時は、対象ドメイン名、使用した認証方式、エラーメッセージの正確な文言、ビジネスマネージャのID、そして上記チェックリストで何を確認済みかをまとめて伝えると、やり取りがスムーズです。特にエラーメッセージのスクリーンショットは、状況を正確に伝えるうえで有効です。

よくある質問

Q：Metaのドメイン認証はどれくらい時間がかかりますか？すぐ反映されないのは異常ですか？ メタタグとHTMLファイル方式は通常数分〜数時間で反映されますが、DNS方式は最大72時間かかる場合があるとMeta Business Help Centerで案内されています。外部のDNSチェッカーやシェアデバッガーで設置状態そのものが正しいと確認できていれば、異常ではなく単純な伝播待ちである可能性が高く、時間を置いて再確認する対応で問題ありません。

Q：ドメイン認証を解除・削除したいのにできない場合はどうすればいいですか？ 認証済みドメインの削除は、そのドメインを認証したビジネスポートフォリオの「ブランドセーフティ」→「ドメイン」から行います。自分の権限で削除できない場合は、そのビジネスマネージャの管理者権限を持つ担当者に依頼する必要があります。代理店が認証している場合は、前述の3分岐の対処に沿って削除を依頼します。

Q：wwwありのサブドメインとルートドメイン、どちらで認証すべきですか？ 認証の単位はルートドメインです。www.example.com のようにwwwを含めて入力すると、意図した認証にならず失敗の原因になります。なお、ルートドメインが認証済みであれば、そのサブドメインは基本的に同じ認証範囲として扱われます。

Q：2026年現在、ドメイン認証をしないとMeta広告は配信できませんか？ 配信自体は認証なしでも可能なケースが多いのが実情です。2025年6月のAEM仕様変更以降、ドメイン認証の役割はリンク編集権限やブランドセーフティ、複数ビジネスマネージャ間の所有権管理に整理されており、単純な自社サイト1本の運用であれば必須度は下がっています。ただし複数ビジネスマネージャでの利用やコマース連携がある場合は、実質的に必要な設定と考えた方が安全です。

Meta広告のドメイン認証は、一見単純な設定作業に見えて、実際にはCMSの構成やDNS管理権限、代理店との関係性まで絡む論点です。真策堂では、こうしたドメイン認証まわりの切り分けに加えて、認証後に発生しやすいMetaピクセルのイベントが反映されない時の切り分け手順や、認証と混同されやすいMetaビジネス認証が承認されない場合の原因と再申請手順、これから初めてMeta広告アカウントを構築する方向けのFacebook広告アカウントの作成・初期設定ガイドといった観点も含めて、広告運用の初期設計に関するご相談を受けています。