会社概要サービス実績記事
← Back to Articles自分でやりたくない場合は、定額でサイトの登録を代行します。Baiduサイト登録代行を見る →

Baiduのサイト所有権確認：HTMLファイル、metaタグ、CNAMEの3つの方法

Beijing central business district skyline at dusk

Baidu対応の仕事が回ってきて、最初に立ちはだかるのが所有権確認の画面です。ドメインが自分のものだとBaiduが納得するまで、サイトマップは受け付けられず、インデックスのレポートも開かず、URLを1本たりとも送信できません。証明の方法は3つあり、それぞれ挙動が違います。しかも失敗の仕方が、Google Search Consoleで見慣れたものとは別物です。

ここでは3つの方法それぞれの実装の詳細と、確認が通らない典型的な原因、そしてターミナルから確かめる手順をまとめます。

所有権確認が置かれている場所

Baiduのウェブマスター向け製品は百度搜索资源平台（Baidu Search Resource Platform）で、ziyuan.baidu.com にあります。今でも百度站长（Baidu Zhanzhang）と呼ばれることのほうが多いツールです。サイトを追加して確認方法を選ぶと、Baiduがドメインから何かを取得して管理権を確かめます。リンク提出、サイトマップのアップロード、クロール診断が使えるようになるのは、その後です。

方法を選ぶ前の段階で、プロパティの考え方に引っかかる点が2つあります。

  • プロトコルとホスト名も識別子の一部です。 https://example.com と https://www.example.com はBaiduにとって別のサイトで、http:// 版もまた別です。canonical URLで実際に使っているoriginをそのまま登録してください。間違ったほうを確認してしまうと、その後に提出するものはすべて、トラフィックがまったく流れていないプロパティに紐づきます。
  • 取得は中国本土から行われます。 所有権を証明するものは、中国本土から公衆インターネット経由で、チャレンジページに邪魔されることなく到達できなければなりません。この一点が、記事の後半に並ぶ失敗例のほとんどを説明します。

そしてその手前に、アカウントの問題があります。確認画面にたどり着くにはBaiduアカウントが必須で、登録には中国本土の携帯電話番号へのSMS認証が伴います。欧州や英国の企業にとっては現実的な壁で、DNSに午後を丸ごと費やす前に知っておく価値があります。これについては最後にもう一度触れます。

方法1：HTML確認ファイル

最も一般的な方法で、静的ファイルをデプロイできるなら第一候補です。

Baiduがサイトごとにファイルを生成し、ダウンロードさせてくれます。名前はこういう形です。

baidu_verify_codeva-XXXXXXXXXX.html

古くから登録されているプロパティには baidu_verify_XXXXXXXXXX.html の形式で発行されたものがあり、パネルによっては codeva- ではなく code- が付くこともあります。ブログ記事を見ながらファイル名やトークンを組み立てようとしないでください。Baiduが出したファイルをそのままダウンロードするか、パネルの文字列を1文字ずつコピーします。ファイルの中身は短く、たいていトークンだけです。

置き場所は登録したoriginのルートでなければなりません。

https://example.com/baidu_verify_codeva-XXXXXXXXXX.html

サブディレクトリの下でも、言語プレフィックスの内側でも、別ホスト上でもだめです。

スタック別の置き場所

| スタック | 置き場所 | | --- | --- | | Vite、Create React App、SvelteKit（static）、Nuxt | プロジェクトルートの public/ または static/ | | Next.js（両ルーターとも） | public/ | | Hugo、Astro | それぞれ static/ と public/ | | Laravel | public/ | | Django | collectstatic が集める static/ ディレクトリ、またはnginxが直接配信する場所 | | ASP.NET Core | wwwroot/ | | WordPress | wp-config.php と同じウェブルート（SFTPで設置） | | 素のnginxやApache | ドキュメントルート |

Baiduと同じやり方で確かめる

curl -sSI https://example.com/baidu_verify_codeva-XXXXXXXXXX.html
curl -sS  https://example.com/baidu_verify_codeva-XXXXXXXXXX.html

欲しいのは HTTP/2 200、text/html の content-type、location ヘッダーが無いこと、そして本文がトークンそのものであることです。次の3つの結果が出たら、まだ終わっていません。

  • 301または302が返る。 何かがパスを正規化しています。多いのは末尾スラッシュのルールか、マッチしないパスをすべて /en/... へ飛ばすロケールのリダイレクトです。catch-allより前に例外を足してください。
  • 200が返るが、中身はアプリのシェル。 通ったように見えて通っていない、というパターンの中でこれが群を抜いて多いものです。catch-allルートを持つSPAはどんなパスにも index.html を200で返すので、ファイルは存在しているように見えるのに、本文はReactのマークアップです。Baiduは本文を読み、トークンが見つからないので拒否します。SPAのフォールバックより先に静的ファイルを配信してください。
  • デプロイ後も404のまま。 たいていはCDNがネガティブレスポンスをキャッシュしています。そのパスだけをパージして、curl -H 'Cache-Control: no-cache' で確認し直します。

確認が通った後もファイルはリポジトリに残しておいてください。Baiduは定期的に所有権を再チェックするので、確認ファイルを失ったサイトは黙ってパネルから消えます。

方法2：HTMLのmetaタグ

ウェブルートにファイルを置けないがテンプレートは編集できる場合、つまりマネージドCMSやプラットフォーム型ホスティングでの通常の状況で使う方法です。

Baiduはこの形のタグを渡してきます。トップページの <head> に入れます。

<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />

name 属性は常に baidu-site-verification で、ハイフンも含めてこの綴りのままです。content の値はパネルのトークンです。

動くかどうかを決めるルールが3つあります。

  1. <head> の中にあること。 パーサーが <body> でこれを見つけた時点で、headはすでに閉じられたものとして扱われます。head以外の最初の要素より後に注入されたものは手遅れです。
  2. サーバーが返すHTMLに含まれていること。 view-source: で開くか、できれば curl -sS https://example.com | grep baidu-site-verification で確認します。DevToolsの要素インスペクタにしか出てこないなら、それはハイドレーション後にJavaScriptが足したもので、カウントされません。クライアントレンダリングのReactやVueのアプリで失敗するのはこれが理由で、SPAならファイル方式のほうが楽なのも同じ理由です。
  3. フレームワークを生き延びること。 ヘッド管理のライブラリは重複排除とサニタイズを行います。Next.jsは、コンポーネントに書かれた野良の <meta> ではなくmetadataのexportに書かれることを期待します。React Helmetはプロバイダの外でレンダリングされたタグを落とします。CMSのセキュリティ系プラグインには、名前を知らないmetaタグを削るものがあります。タグマネージャーで置くことはできません。タグマネージャーはクライアント側で動くからです。

フレームワーク別の書き方です。

// Next.js App Router、app/layout.js
export const metadata = {
  other: { 'baidu-site-verification': 'codeva-XXXXXXXXXX' },
}

// WordPress、子テーマの functions.php
add_action('wp_head', function () {
  echo '<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />' . "\n";
}, 1);

サーバーレンダリングのサイトなら、charsetやviewportのタグの隣、ベーステンプレートに書いて忘れてしまえば済みます。Hugoなら layouts/_default/baseof.html、Djangoなら全ページが継承するベーステンプレートです。

方法3：CNAMEレコード

DNS方式は、そもそもデプロイできないとき、自分の管理下にないアプライアンスの後ろにサイトがあるとき、あるいは今後の再デプロイをすべて生き延びさせたいときの選択肢です。1つのファイルではなくドメイン全体の管理権を証明できる、という違いもあります。

Baiduはドメインの下に作るランダムなホストラベルを表示します。向き先はBaiduです。

abcdef123456.example.com.  3600  IN  CNAME  ziyuan.baidu.com.

たいていのDNSパネルではゾーンが暗黙に補われるので、入力するのは左側のラベルだけです。

| 項目 | 値 | | --- | --- | | タイプ | CNAME | | 名前／ホスト | abcdef123456 | | 値／ターゲット | ziyuan.baidu.com | | TTL | 3600、またはテスト中はパネルが許す最小値 |

ここで繰り返し起きる失敗が4つあります。

  • ドメインが二重に付く。 ゾーンが暗黙に補われるパネルに abcdef123456.example.com と打ち込むと、abcdef123456.example.com.example.com ができます。保存後にFQDNを表示するパネルなら、必ず読み返してください。
  • ターゲットの末尾のドット。 生のゾーンファイルでは、末尾のドットが無い ziyuan.baidu.com はゾーンからの相対名と解釈され、ziyuan.baidu.com.example.com になります。パネルは面倒を見てくれますが、named の設定やTerraformのファイルは見てくれません。
  • レコードの手前にプロキシがある。 Cloudflareでプロキシ有効（オレンジの雲）のレコードは、外からはCNAMEとして解決されなくなります。権威側の答えがCloudflareのAレコードに変わるためです。確認用のレコードはDNS onlyにしてください。
  • TTLより短い時間しか待っていない。 リゾルバがその名前のネガティブな答えをすでにキャッシュしていれば、古いTTLが効きます。パネルの表示ではなく、世界から実際にどう見えるかを確かめてください。
dig +short abcdef123456.example.com CNAME
# ziyuan.baidu.com.

dig +short @8.8.8.8 abcdef123456.example.com CNAME

レコードはそのまま残してください。確認が通った後に消すと、後々の再確認で失敗する原因になります。

設定は正しく見えるのに確認が通らないとき

ファイルをcurlして200が返るのに、Baiduは首を縦に振らない。そんなときは上から順に潰していきます。

  • botチャレンジやWAFのルール。 Cloudflare Bot Fight Mode、AWS WAFのマネージドルール、そして各種の攻撃対策モードは、スクリプトを実行しないクライアントに403か503とJavaScriptの中間ページを返します。Baiduのフェッチャーはスクリプトを実行しません。確認用のパスか、クローラー自体を許可リストに入れてください。
  • 地域ブロック。 スクレイピング対策として中国本土からのトラフィックをブロックしたりレート制限したりしている欧州のサイトは珍しくありません。確認のためのフェッチは、まさにその範囲から来ます。エッジで落としているものが無いか確かめてください。
  • User-Agentで弾かれている。 クローラーは Baiduspider と名乗ります。セキュリティ製品によっては、見慣れないクローラー名をスクレイパーとして扱います。許可リストに入れる前にリクエストが本物か確かめたい場合は、送信元IPの逆引きが *.baidu.com または *.baidu.jp になり、その正引きが一致することを確認します。
  • robots.txt で止めている。 ワイルドカードのUser-Agentに対する Disallow: / や、誰かが残した User-agent: Baiduspider のブロックがあると、フェッチはそもそも始まりません。
  • ブラウザが隠してくれているTLSの問題。 中間証明書の欠落はデスクトップブラウザが黙って補ってくれますが、単純なフェッチャーは補いません。緑の鍵マークを信じず、外部のTLSチェッカーにドメインを通してください。
  • 確認しているoriginが違う。 ファイルは www.example.com にあるのに、Baiduのプロパティは example.com になっている。エラーメッセージからこれを読み取ることはできません。
  • 最初の1バイトが遅い。 中国国内に拠点を持たない欧州のサーバーは、北京からのリクエストへの応答が遅く、そこにサーバーレスのコールドスタートが重なるとフェッチのタイムアウトを超えることがあります。時間帯を変えて再試行するのは、実際に効きます。

どの方法を選ぶか

ビルドパイプラインがあるなら静的ファイルをデプロイしてください。壊されにくく、テストも一番簡単です。CMSの中で日々作業していてページがサーバーレンダリングなら、metaタグを選びます。サイトに一切手を入れられない場合、あるいはドメイン単位で一度証明して二度と触りたくない場合はCNAMEです。

どれを選んだ場合も恒久的に残したうえで、ほかのDNSレコードと並べてインフラのメモに書いておいてください。18か月後に得体の知れないファイルを消す人は、たぶんあなたです。

この3つの方法では解決しない部分

3つの方法はいずれも、Baiduアカウントにすでにログインしていることが前提です。登録は中国本土の携帯電話番号へのSMSで確認され、プロパティによってはBaiduが中国の身分証または中国の営業許可証による実名認証（实名认证）も求めます。フランクフルトやマンチェスターの企業は、DNSゾーンを完璧に設定しても、確認画面にすらたどり着けません。

そこで役に立つのが当社の Baiduサイト登録代行 です。ドメインをお知らせいただき、お客様側でドメイン所有権の確認を1回だけ済ませていただければ、あとは当社が登録を実行し、Baiduが実際に何をインデックスしたかをご報告します。料金は1ドメインあたり定額です。中国の電話番号も、中国法人も、御社名義のBaiduアカウントも必要ありません。

まず全体像を知りたい方は、Baiduサイト登録の完全ガイド がサイトマップ、push API、そしてBaiduのランキングが実際に何を評価するのかを解説しています。直接話したい場合は、お打ち合わせをご予約ください。

サービス

この作業、まとめて代行します

ドメイン所有権の確認、サイトマップとURLの送信、2週間後のインデックス状況レポートまで。1ドメイン、定額制。中国の携帯電話番号も、中国法人も、御社名義のBaiduアカウントも不要です。

Baiduサイト登録代行を見る
← Back to All Articles