AdSenseで「有用性の低いコンテンツ」と判定されたのでサイト構成と記事導線を見直した

Google AdSenseの初回審査で「有用性の低いコンテンツ」と表示されたゆまラボで、原因を一つに決めつけず、旧連載導線、カテゴリ構成、テーマ別まとめ、記事ページ、共通サイドバーを見直した記録。修正前後の画面とビルド結果を残す。

公開：
AdSenseで「有用性の低いコンテンツ」と判定されたのでサイト構成と記事導線を見直した

AdSenseの審査で「有用性の低いコンテンツ」と表示されたものの、「結局どの記事を直せばいいのか」「記事数を増やせばいいのか」「サイト全体の構成まで見直すべきなのか」と迷っていないでしょうか。表示された理由だけでは、修正箇所をそのまま特定できないところが難しいです。

ゆまラボでも初回審査で同じ表示になりました。そこで原因を一つに決めつけず、記事本文だけではなく、旧連載の見せ方、カテゴリ構成、個別記事のタイトルと冒頭、テーマ別まとめ、共通サイドバーまで実際に見直しました。

今回の修正では、連載順を知らないと記事を選びにくい状態をやめ、目的から読めるテーマ別まとめへ変更しています。あわせて、細かく分かれていた分類を大カテゴリ中心にし、個別記事から別のカテゴリやテーマへ移動しやすい導線も追加しました。

この記事では、AdSenseで「有用性の低いコンテンツ」と表示された後に、ゆまラボでどこを確認し、何を変更したのかを修正前後の画面で紹介します。AdSenseの不合格原因を断定するのではなく、再審査前にサイト全体をどう見直したかを確認できます。

AdSenseの審査結果は「有用性の低いコンテンツ」#

AdSenseのサイト画面を確認すると、bringain.comは「サイトは広告を表示できない状態です」となっていた。

Google AdSenseでbringain.comに「有用性の低いコンテンツ」と表示された画面

所有権の確認自体は完了済み。一方、ポリシー違反の欄には「有用性の低いコンテンツ」と表示され、再送信前に確認する内容として品質、独自性、ユーザーの関心などが案内されている。

ここで少し迷った。画面には問題の種類は出ているが、「このページを直す」「この記事を削除する」といった具体的な指示まではない。

GoogleのAdSenseヘルプでは、AdSense向けのサイトについて、独自性があり訪問者に関連するコンテンツ、分かりやすく使いやすいナビゲーション、良好なユーザー体験を確認するよう案内している。Publisher Policiesでも、パブリッシャーのコンテンツがない、または有用性の低いコンテンツを含む画面への広告配信を認めていない。

ただし、今回の不合格理由がナビゲーションだけにあったと判断できる材料ではない。記事数や特定ページ、カテゴリ数をGoogleが個別に指定したわけでもない。

そこで、審査対策の正解を推測するのではなく、現在のゆまラボを読者側から見て気になる部分を一度洗い出すことにした。

修正前は「連載」がサイト内の大きな導線になっていた#

最初に確認したのは連載ページ。

修正前の/series/では、Astro＋Cloudflare、サイト運用、収益化、AIオーケストレーションという連載をカードで並べていた。

修正前の連載一覧ページ

各カードには説明と記事数があり、リンクとしては機能している。ただ、読者が知りたいことより「サイトを作った順番」「運営側が連載として分けた単位」が前に出ていた。

連載詳細へ入ると、その傾向はさらに強い。

修正前の連載詳細で記事が一覧表示されている画面

記事は古い順へ並べ替えられるものの、基本は記事一覧。初めて来た人が「自分は今どの段階か」「次にどれを読めばよいか」を判断するには、タイトルを一つずつ読む必要がある。

作業記録を時系列で残す用途なら、この形でも成立する。ただ、記事数が増えた現在の入口として見ると役割が合わなくなっていた。

連載一覧を「テーマ別まとめ」へ変更した#

/series/のURLは残し、ページの役割を変更した。

現在は「テーマ別まとめ」として、目的から読み始める3つの入口を表示している。

修正後のテーマ別まとめ一覧

用意した入口は、Astro＋Cloudflareでブログを作る流れ、サイト公開後の運用、AIをWeb制作・ブログ運営へ使う流れの3つ。

以前のように連載名と全記事数を見せるのではなく、何をしたい人向けかをカード内に出した。説明も、そのテーマでどこからどこまで確認できるか分かる内容へ変更している。

これは「連載」という名前だけを置き換えたものではない。

カテゴリは記事の所属先として残し、テーマ別まとめは複数の記事から目的に合う読む順番を作る役割に分けた。同じ記事が複数テーマで必要になっても、記事そのものを複製する必要はない。

テーマ詳細を記事一覧からロードマップへ変更した#

テーマ詳細も、記事カードを同じ重みで並べる方式から変更した。

ページ上部には、対象読者、何が分かるか、目次・ロードマップを配置している。

テーマ別まとめ詳細のタイトルと「このまとめで分かること」

その下のロードマップでは、01から05まで段階を分けた。

テーマ別まとめ詳細の目次・ロードマップとSTEP表示

Astro＋Cloudflareのテーマなら、最初にAstroを使う理由とローカル環境を確認し、その後GitHubとCloudflareへの公開、独自ドメイン、ブログ機能、画像と公開品質へ進む。

各STEPには「この段階で行うこと」「この段階のゴール」を持たせた。通常ルートとは別に、エラー時だけ読む記事、比較したい人だけ読む記事も分けられるようにしている。

記事の本数が増えても、全タイトルを最初から確認する必要はない。現在地に近いSTEPから記事を選べる構成に変わった。

カテゴリは大カテゴリだけにした#

カテゴリページも見直した。

修正前のAIカテゴリには、AIサービス、画像生成、開発支援、自動化という細かい分類が並んでいた。

修正前のAIカテゴリと細分化された分類

分類としては機能するが、記事数が少ない分類もあり、カテゴリ、細かい分類、連載、タグが同時に存在していた。どの入口を使えばよいのか、運営側でも役割が重なり始めている感覚があった。

現在は大カテゴリを基準にしている。

修正後のAIカテゴリと共通サイドバー

AI、WEB制作、サイト運用、収益化という大きな入口から記事を探し、目的別に読みたい場合はテーマ別まとめへ移動する。

分類を増やすより、「カテゴリは分野」「テーマは読む順番」と役割を分けた方が、現在のサイト構成では分かりやすい。

記事タイトルと冒頭も見直した#

個別記事には、連載順に読むことを前提にした見え方が残っていた。

代表として、サイト構築の最初の記事を比較する。

修正前の記事ページで「第1回」から始まるタイトルが表示されている状態

修正前は「第1回 WordPressを使わずAstroとCloudflare Workersでサイトを作ることにした」というタイトルだった。

現在は「Astro＋Cloudflare Workersでブログを作る｜WordPressを使わない構成と選んだ理由」とし、検索や内部リンクからその記事だけを開いても内容を判断できるタイトルへ変更している。

修正後の記事タイトルと右側の共通サイドバー

記事冒頭も同じ考え方で見直した。

「前回は」「第○回では」から始めるのではなく、読者が何に困っているか、ゆまラボで実際に何を試したか、その記事で何を確認できるかを早い段階で出す。

ここは今回かなり大きく変えた部分。ただし、記事本文まで営業的な口調へ変えたわけではない。目次前の導入だけ読者へ近い口調にし、本文へ入ったら従来どおりの実作業記録へ戻している。

この段階では記事をまとめて削除する作業までは行っていない。まず既存記事を単独で読める状態にし、入口と導線の修正を優先した。

個別記事とカテゴリへ共通サイドバーを追加した#

以前の記事ページは本文が中心で、別の記事へ移動するにはヘッダーや本文末尾の導線を使う必要があった。

現在はTOP以外の主要ページへ共通サイドバーを追加している。

共通サイドバーのサイト内検索、カテゴリ、テーマから読む

サイドバーには、サイト内検索、カテゴリ、テーマ別まとめへの入口、人気記事を配置した。

単純な下線リンクは並べず、カテゴリはアイコン付きカード、テーマは対象読者も分かるカードとして、カード全体をクリックできる形にしている。

検索は既存のサイト内検索を再利用した。新しい検索方式は追加していない。

最初にサイドバーを置いただけの状態では、カテゴリがただの文字リンクに見え、テーマもクリックできるのか分かりにくかった。ここは実際の画面を見て違和感があり、テーマとカテゴリをカード化する方向へ変更している。

人気記事はアイキャッチを大きく表示した#

人気記事も途中で見直した。

小さいサムネイルを横へ置く案では、ゆまラボのアイキャッチ内にある文字や図がほとんど読めない。画像を付ける意味が薄かったため、画像を上、記事タイトルを下にした縦型へ変更した。

共通サイドバーの人気記事を大きなアイキャッチ付きで表示している状態

表示件数は5件。順位やPV数は出していない。

「何位だから読む」という見せ方ではなく、画像と記事タイトルを見て内容を選ぶ構成にした。人気記事の取得方法自体を今回作り直したわけではなく、既存の人気記事データをサイドバーへ利用している。

AdSense対策だけを目的にした変更にはしなかった#

AdSenseの不合格が今回の見直しを始めたきっかけだった。

ただし、修正内容を「AdSenseに通すためのチェックリスト」にはしていない。

Google公式ヘルプでは、独自性のある内容、利用者にとっての価値、分かりやすいナビゲーションなどが確認事項として案内されている。一方、今回のAdSense画面だけから「テーマ別まとめがないから不合格」「細かいカテゴリがあるから不合格」と結論付けることはできない。

今回変更したのは、AdSenseとは無関係に読者側から見ても気になっていた部分。

  • 連載順を知らないと記事を選びにくい
  • 分類方法が複数あり、役割が重なっている
  • 個別記事から別テーマへ移動しにくい
  • タイトルや冒頭が過去記事を読んでいる前提になっている
  • 人気記事の画像が小さく、内容を判別しにくい

審査結果を見て記事数だけを増やすのではなく、既存の記事をどう見せているかまで確認した。

AstroのビルドとPagefind生成を確認した#

修正後にnpm run buildを実行した。

AstroのビルドとPagefindインデックス生成が完了したターミナル

Astro側のビルドは完了。

画面では101 page(s) built in 45.91sとなり、その後Pagefindも正常に実行された。Pagefindはdistから101件のHTMLを検出し、86ページを検索対象としてインデックスしている。言語はjaとして認識された。

Pagefindからは、日本語ではstemmingをサポートしていないため語幹をまたいだ一致は行わない、という注意も出ている。表示上はSearch will still workとなっており、ビルド失敗ではない。

検索インデックス生成まで終わり、今回のサイト変更がビルドを壊していないことを確認できた。

この時点で確認できた状態#

今回行ったのは、AdSenseの審査結果をきっかけに、サイト全体の入口と記事への移動経路を見直す作業。

実際に変更した範囲は、旧連載を前提にした一覧、テーマ詳細、カテゴリ、個別記事のタイトルと冒頭、共通サイドバー、人気記事の表示になる。

修正後はAstroのビルドまで完了し、Pagefindの検索インデックスも生成できた。

この時点では、これらの変更によってAdSenseの審査結果が変わるかは分からない。今回の修正を「これで承認される」とは扱わず、公開後の状態を確認してから再審査へ進む。結果が出たら、その時点の画面と実際に行った作業を別に記録する。

参考情報#