AdSenseに3回落ちた。全ページが「トップページの複製」だと申告していた
個人開発しているHonne.logで、Google AdSenseの審査に3回落ちました。この記事はその記録です。まだ通っていない現在進行形の話なので、成功体験談ではありません。ただ、3回目のあとでようやく見つけた原因が、コンテンツの質や量とはまったく別の、技術的な設定ミスでした。同じ構成でNext.jsを使っている方には、他人事ではないかもしれません。
1回目の否認
最初に申請したのは、サービスの実装がひと通り終わった頃でした。結果は否認。理由は「有用性の低いコンテンツ」でした。
正直、最初はピンときませんでした。日記を書いてAIが分析するという機能はきちんと動いていましたし、料金プランもFAQも用意していました。それでも「有用性が低い」と判定されたわけです。
思い当たるところを一通り直しました。サイト内に残っていた「準備中」の表示を消し、AI分析のサンプルページを新設し、コラム記事を4本書き、sitemapとrobots.txtを確認し、OGP画像の不具合を修正し、同意メッセージの設定も済ませました。それなりの量の改善をしたつもりでした。
2回目も否認、しかも理由が分からない
再審査を申請し、結果はまた否認でした。
このとき一番つらかったのは、否認そのものよりも「何が悪いのか分からない」ことでした。コンテンツの量が足りないのか、ポリシーに違反しているのか、サイトの構造に問題があるのか、切り分けができない。何を直せばいいのか分からないまま、しばらく手が止まりました。
後から分かったのですが、これは私の確認不足でもありました。AdSenseの管理画面には、否認の理由と、参照すべきポリシーへのリンクがきちんと表示されていたのです。「コンテンツの最小要件」「独自性のある質の高いコンテンツ」「品質に関するガイドライン」の3つが挙げられていました。
立てた仮説：アプリの中身が見えていない
理由がはっきりしたところで、一つの仮説に思い当たりました。
Honne.logの価値は、ログインした先にあります。日記を書く画面、カレンダーで振り返る画面、AIが分析する画面。これらがサービスの中身そのものです。
そして私は、これらのページをすべてrobots.txtでクロール禁止にしていました。個人の日記を扱うサービスなので、当然の判断です。検索結果にユーザーのページが出てきては困ります。
しかしその結果、クローラーや審査担当者から見えるサイトは、トップページの機能紹介、サンプルページ、コラム4本、お知らせだけになっていました。
つまり「アプリの説明書」はあるけれど「アプリの中身」が一切見えない状態だったのです。これでは「このサイト独自の価値は何か」が伝わりようがありません。コンテンツの量を足すという発想では、そもそも解けない問題でした。
これは私だけの話ではなく、価値がログインの向こう側にあるWebアプリ全般に共通する構造的な難しさだと思います。ブログやメディアと違って、アプリは「見せられる中身」が公開範囲にほとんどありません。
仮説にもとづいて打った手
そこで方針を変えました。「コンテンツを増やす」のではなく「このサイトにしか出せないものを、ログインなしで見えるところに置く」という考え方です。
一つは、登録不要でAI分析を体験できるデモを作りました。用意した複数日分の日記例を選ぶと、その場で実際にAIが分析します。1日分ではなく複数日分にしたのは、Honne.logの分析が「複数の記録から背景やパターンを読む」ことを核にしているからで、単発では価値が伝わらないためです。これで、訪問者にも審査担当者にも「アプリの中身」を直接見てもらえるようになりました。
もう一つは、記事の方向性を変えたことです。それまで書いていたのは「日記の続け方」「自己分析のコツ」といった、正しいけれどこのサイトでなくても書ける内容でした。一般論をいくら積み上げても独自性にはならないと考え直し、開発の過程や設計の判断といった、自分にしか書けない一次情報を書くことにしました。この記事自体がその一本です。
運営者が何者で、なぜこのサービスを作ったのかを書いたページも用意しました。
3回目も、同じ理由で落ちた
デモを公開し、コラムを一次情報中心に書き直し、運営者ページも用意した上で、3回目を申請しました。結果はまた否認で、理由も同じ「有用性の低いコンテンツ」でした。
打った手そのものは間違っていなかったと今でも思っています。それでも結果が一切動かないということは、自分が見ている場所とは別のところに問題があるということです。ここでようやく、コンテンツの中身ではなく、サイトが技術的にどう見えているかを疑い始めました。
全ページが「トップページの複製」だと申告していた
原因は、サイトが自分自身をGoogleにどう申告しているか、にありました。
Webページには、canonicalという「このページの正規URLはこれです」と宣言するタグがあります。同じ内容が複数のURLで見られるときに、どれを本物として扱うかを検索エンジンに伝えるためのものです。
Next.jsのApp Routerでは、ルートのlayoutに書いたmetadataが、その配下の全ページに継承されます。そして私は、そのlayoutにcanonicalとしてサイトのトップページのURLを書いていました。
結果として、すべてのページが「このページの正規URLはトップページです」と宣言している状態になっていました。コラム14本も、デモも、運営者ページも、全部です。Googleから見れば、それらはトップページの複製でしかなく、独立したコンテンツとして評価する対象になりません。
つまり、審査のために書いた記事も、作ったデモも、そもそも中身を見てもらえていなかった可能性が高い。コンテンツをいくら足しても結果が変わらなかったのは、足したものが評価の土俵に上がっていなかったからだと考えています。
修正自体は単純で、layoutからcanonicalの指定を外し、各ページが自分のURLを指定する形に変えるだけです。コラム詳細のような動的なページは、slugごとに個別に設定しました。
なぜ3回も気づけなかったのか
ブラウザで見る限り、サイトは何も問題なく動いていました。コラムはそれぞれのURLで開けるし、デモも正常に動作する。人間の目には正しく見えるので、疑う理由がありませんでした。
canonicalはページのソースを開いてhead要素の中を見ないと分かりません。しかも1ページだけ見て「ここに入っているURLが自分のものではない」と気づける人は、そう多くないと思います。複数のページを並べて初めて、全部が同じURLを指していることに違和感を持てる種類のミスでした。
審査に落ちた原因を探すとき、どうしても指摘された言葉に引きずられます。「有用性の低いコンテンツ」と言われれば、コンテンツを疑ってしまう。実際には、コンテンツが届いていたかどうかを先に確認すべきでした。
現在地
修正はすでに反映済みで、各ページが自分のURLをcanonicalとして出力する状態になっています。ただしGoogleが再クロールして評価をやり直すまでには時間がかかるため、今はインデックスが更新されるのを待っている段階です。4回目の申請はそのあとになります。
canonicalが直接の原因だったという判断が正しいかどうかは、まだ確定していません。結果が出たら、また追記します。
ただ、仮にこれが決め手でなかったとしても、全ページが複製として申告されている状態が正常でないことは確かです。Next.jsで同じようにlayoutへcanonicalを書いている方は、一度ページのソースを開いて、head要素の中のcanonicalが自分のURLになっているか確認してみてください。私のように、気づかないまま何ヶ月も過ごしているかもしれません。