ログオフ
開発2026-08-15

AdSense の画面が言うことを真に受けると溶かす2箇所:所有権確認と「有用性の低いコンテンツ」

「クローラがアクセスできるようにしてください」と言われるが、実際はアクセスできている。「有用性の低いコンテンツ」と言われるが、理由は1行しか出ない。どちらも自分で測ったほうが速い。

AdSense のエラーメッセージには、実態とずれているものがある。書いてあるとおりに直しに行くと、直すところが無い場所を延々いじることになる。実際に時間を溶かした2箇所を書く。

1. 所有権確認は、サイトが正常でも「確認方法」で結果が割れる

事象

AdSense にサイトを追加して所有権確認をすると、これで弾かれる。

サイトを確認できませんでした。
変更内容を公開し、クローラがアクセスできるようにしてください。

言われたとおりクローラ側を疑って一通り測ったが、サイトは正常だった。実測した状態は次のとおり。

  • www なしの本体(apex)が HTTP 200 を返す
  • 指定されたコードが本番のHTMLに出力されている
  • http から https へは 308 で正常に転送されている
  • robots.txt は全許可
  • AdSense のクローラの名乗り(Mediapartners-Google)で取得しても、そのコードが見える

つまり「クローラがアクセスできない」と言われているが、アクセスはできている。それでもコードスニペット方式(HTMLに解析タグを貼る方式)は2回連続で失敗した。

原因

判定の内側は分からない。分かったのは、同一サイト・同時刻・同じ publisher ID のまま、確認方法だけを変えたら結果が割れたということだ。ads.txt スニペット方式(サイトのルートに ads.txt という1行のテキストを置く方式)に切り替えたら、一発で通った。

メッセージの文面は原因を指していなかった。文面を信じて DNS やキャッシュを疑い始めると、そちらには直すものが無いので、いくらでも時間が使える。

解決策

確認方法は画面のラジオボタンで即切り替えられる。コード方式が2回落ちたら粘らず ads.txt へ行く。

ads.txt に書く行は pub- から始まる形式で、管理画面に表示されている ca-pub- ではない。ここを取り違えると、後から「ads.txt ファイルの問題」として別の警告が出る。

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

先に ads.txt を用意しておくと、この逃げ道がいつでも使える。

もうひとつの落とし穴が、環境変数でタグを出し分けている場合だ。ビルド時にクライアント側へ埋め込まれる型の変数(Next.js の NEXT_PUBLIC_ で始まるもの等)は、管理画面で値を保存しただけでは本番に載らない。保存後に再デプロイして初めて反映される。載っていない状態で「確認」を押せば当然落ちる。

押す前に、本番のHTMLを実際に取得して確かめる。

curl -s https://example.com/ | grep -o 'pub-[0-9]\{16\}'

何も返らなければ、まだ載っていない。

2. 「有用性の低いコンテンツ」は、勘で直す前に本文の文字数を測る

事象

審査に落ちる。理由は「ポリシー違反:有用性の低いコンテンツ」の1行だけ。どのページが該当するかは書かれていない。

この抽象度だと、疑い先がいくらでも作れる。文章がAIっぽいのか、構成が悪いのか、テーマが弱いのか、記事数が足りないのか。全部それらしく見えて、全部確かめられない。

原因

測ったら、文章の質の問題ではなかった。frontmatter を除いた本文の文字数を全記事について数えたところ、一部のカテゴリだけ極端に薄い記事が並んでいた。1000字未満が大半で、最短は452字。

もうひとつ出てきたのが、プレースホルダが残ったままの未完成記事だった。「(ここに書く)」のような穴が埋まらないまま公開状態になり、sitemap にも載っていた。

どちらも、読めば分かる。ただ「どのページが該当するか」を教えてくれない審査結果とにらめっこしている限り、読みに行こうとは思わない。

解決策

全記事の本文文字数を機械的に出す。frontmatter を落として、空白を除いて数えるだけでいい。

for f in $(find content -name '*.mdx'); do
  n=$(awk 'BEGIN{fm=0} /^---$/{fm++; next} fm>=2' "$f" | tr -d '[:space:]' | wc -m)
  printf '%6d  %s\n' "$n" "$f"
done | sort -n | head -20

短い順に20件見れば、薄いページ群があるかどうかは一目で分かる。あわせて、書きかけの痕跡も探す。

grep -rn 'TODO\|(.*)を書く\|XXXX' content

薄い記事は消すか、統合して厚くする。未完成記事は下書きに戻す。文章の書き方をいじるのは、この2つを片付けてからでいい。

補足:再申請の押し方

不合格になったサイトは管理画面の[サイト]に残る。再申請は「新規申請」ではなく、その行から[問題を修正しました]→[審査をリクエスト]の順に押す再審査リクエストになる。新規で追加し直そうとすると、すでに登録済みのサイトなので進めない。

押すタイミングにも順序がある。修正が Google に再クロールされる前に押すと、古いクロール結果で評価されるだけで終わる。修正を本番に反映してから数日おいて押す。具体的な待ち日数は公表されていないので、ここは待つしかない。

測ってから押す

2箇所とも、画面の文言が実態とずれていた。片方は「アクセスできない」と言いながらアクセスできていて、もう片方は理由を1行しか言わない。前者は言い分が具体的すぎて外れており、後者は抽象的すぎて当たらない。ずれ方は逆だが、対処は同じだった。

押す前に、自分の側で1つ測る。HTMLを取る。文字数を数える。どちらも1コマンドで済む。画面の文言を読み解く時間より短い。

関連記事

開発 一覧へ