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コマンドで済む。画面の文言を読み解く時間より短い。