Search Consoleの新しい未登録メールとAdSenseの低価値判定を受けた時、URLごとの応答、wwwの配信元、サイトマップの記事構成を確かめる手順をまとめました。

目次
  1. 3行まとめ
  2. まず未登録URLを理由ごとに分ける
  3. 404は、実在するページかどうかで分ける
  4. wwwのURLは、別サイトの可能性もある
  5. クロール済み・未登録は、404と同じ扱いにしない
  6. サイトマップをページの種類で数える
  7. サイト運営の記録を公開記事から外す
  8. 新しいサイトは、公開後の確認にも時間がかかる
  9. まとめ

3行まとめ

  • Search Consoleの未登録理由は、404・重複・クロール済み未登録に分け、URLごとに直す必要があるかを判断しました。
  • AdSenseの「有用性の低いコンテンツ」は対象ページが示されないため、サイトマップと公開記事を自分で点検しました。
  • 対処を公開してから時間を置き、記事を増やして再審査に出す予定です。結果が出たら追記します。

Search Consoleから「インデックスに登録されない新しい要因」というメールが届くと、サイト全体に問題があるのか、特定のURLだけなのかが気になります。AdSenseで「有用性の低いコンテンツ」と表示された場合も、どのページを直せばよいかは個別に示されません。

私のサイトでは、Search Consoleの一覧と実際のURL応答、サイトマップの中身を並べて確認しました。ここでは、同じメールを受け取った人が自分のサイトで確認できる順番を書きます。今回のAdSense再審査はまだ結果が出ていないため、以下は合格方法ではなく、確認した事実と実施した対処です。

まず未登録URLを理由ごとに分ける

Search Consoleの「ページのインデックス登録」には、登録済みかどうかだけでなく、未登録の理由が表示されます。私のサイトでは、登録済み64、未登録5でした。5件を理由別にすると、404が2件、重複が1件、クロール済み・未登録が2件です。

この一覧は「書かれた理由をそのまま直す」ためのものではありません。URLが実在するか、どのサイトから配信されているか、応答コードと転送先が何かを確認してから、必要な修正を選びます。まず対象のURLをブラウザーで開くか、curl でヘッダーを見ます。

curl -sI https://example.com/path
curl -sIL http://example.com/path

-I は本文を取らずにヘッダーを表示し、-L は転送先までたどります。最初の応答と最後の応答を見比べると、404なのか、別のURLに転送されているのかが分かります。転送の調査では、最終応答だけでなく途中の HTTP ステータスと Location も確認します。

404は、実在するページかどうかで分ける

私の404の1つは、https://www.oysk2.com/cdn-cgi/l/email-protection でした。Cloudflareのメールアドレス難読化機能が、ページ中の mailto リンクを書き換えて作ったURLです。Search Consoleには404として出ていましたが、記事や固定ページとして公開したURLではありません。難読化を止めるとメールアドレスがそのまま表示され、迷惑メールが増えるため、このURLのために機能を止めることはしませんでした。

もう1つは https://www.oysk2.com/$ です。実在するページではなく、どこから生じたかも確認できていません。このように、404のURLが実際に使っているページか、サイト内リンクから案内しているページかを先に確認します。実在するページならリンク切れや公開設定を直します。意図していないURLなら、原因が分からない段階でページを増やしたり、サイト全体の設定を変えたりせず、サイト内にそのURLへのリンクがないかを調べます。

wwwのURLは、別サイトの可能性もある

重複として出たURLは http://www.oysk2.com/ でした。最初は、wwwを素のドメインへ転送すれば重複が解消すると考えました。しかし、www.oysk2.com は oysk2.com のコピーではなく、GitHub Pagesから配信している別の事業サイトでした。転送すると、そちらのサイトが見えなくなります。

配信元を確かめるには、応答ヘッダーとページタイトルを比べます。たとえば次のようにします。

curl -sI https://www.example.com/
curl -sI https://example.com/
curl -sL https://www.example.com/ | head -40
curl -sL https://example.com/ | head -40

GitHub Pagesからの応答には x-github-request-id があり、HTMLの <title> も2つのホストで異なっていました。これで別サイトだと分かったため、www全体を素のドメインへ転送する案は取りやめました。ホスト名だけを見て転送を設定すると、同じドメインの別用途を壊すことがあります。まず、現在それぞれのホストが何を返しているかを確かめるのが先です。

重複の原因は、wwwのHTTPS側ではなくHTTP側にありました。http://oysk2.com/ はHTTPSへ301転送していた一方、http://www.oysk2.com/ は200を返していました。つまり、www付きのHTTPページが転送されずに表示でき、Search Consoleが別のURLとして見ていました。

Cloudflareの「常に HTTPS を使用」を有効にしたところ、http://www.oysk2.com/ から https://www.oysk2.com/ へ1回の301転送になりました。ループがないことも、転送をたどる curl -sIL で確認できます。Search ConsoleではこのURLについて「修正を検証」を開始しました。検証完了の結果はまだ出ていません。

GitHub Pages側でHTTPSを強制する方法も確認しましたが、GitHub側には証明書がなく、このサイトはCloudflare経由で配信していたため使えませんでした。設定する場所はホスト先の見た目ではなく、実際に応答を返している経路に合わせます。

クロール済み・未登録は、404と同じ扱いにしない

残りの未登録は https://oysk2.com/rss.xml と https://www.oysk2.com/favicon.ico で、どちらも「クロール済み・未登録」でした。RSSは記事一覧を機械向けに配るファイルで、faviconはブラウザーや検索結果で使うアイコンです。どちらも通常の記事ページではありません。

この理由だけで、記事のようにインデックスへ登録されるべきURLだとは限りません。まずURLが何を返すかを確認し、記事や固定ページなのに未登録なら本文、内部リンク、正規URLなどを点検します。RSSやアイコンのような補助ファイルなら、その形式の役割を確認して、本文ページの不備と混同しないようにします。私の一覧では、この2件を今回の404や転送漏れと同じ修正対象にはしませんでした。

サイトマップをページの種類で数える

Search ConsoleのURL一覧を見た後、公開サイトのサイトマップも確認しました。登録URLは63件で、そのうちタグページが41件、記事が16件、ホーム・about・contact・privacy・worksが各1件でした。タグページ41件のうち39件は、記事が1件だけのタグでした。

タグページは記事を分類する入口ですが、1本の記事しかないタグが大量に並ぶと、サイトのURLの多くが同じ記事への一覧ページになります。これがAdSenseの不合格理由だと断定はできません。AdSenseは個別の該当ページを教えてくれず、タグ数が原因だという説明も推測です。ただ、サイトマップの6割強が単独記事のタグ一覧だったことは、数字で確認できた改善候補でした。

そこで、記事が1件だけのタグページには noindex を付け、サイトマップからも外すようにしました。記事が2件以上あるタグページは、これまで通り表示し、サイトマップにも残します。記事データの件数で判断するため、タグ名に日本語や空白があってURLエンコードされても同じタグとして照合します。

同じ状態を調べるには、サイトマップからURLを取得し、最初の階層ごとに数えます。

curl -s https://example.com/sitemap-0.xml | grep -o '<loc>[^<]*' | sed 's#<loc>https://example.com##' | awk -F/ '{print $2}' | sort | uniq -c

tags の行がタグページの数です。より詳しく見る場合は、サイトの記事データから各タグの出現数を数えて、一覧ページのURLと対応づけます。件数を確認するだけでなく、1件のタグと複数記事のタグが実際にどう出力されたかをビルド後のHTMLで確認します。

サイト運営の記録を公開記事から外す

記事の内容も見直しました。審査に出すまでの作業記録、ブログの公開・非公開の仕組み、記事デザインのメモは、サイトを使う読者向けの手順というより運営側の記録に寄っていました。この3本は本文を書き換えず、公開設定だけを非公開にしました。

これは、運営の話をすべて公開してはいけないという意味ではありません。読者が自分の問題を解決する手順として再構成できる内容なら、公開記事として役立つ形にできます。今回は、サイトの内部運用を説明する記事をいったん公開対象から外し、同じ経験を自分のサイトで確認できる手順に整理した新しい記事を用意しました。

新しいサイトは、公開後の確認にも時間がかかる

このサイトの記事は9月22日から10月6日まで、1日1本のペースで16本公開しました。開設から3週間あまりでAdSenseの審査に出しています。今回の時点で、個別の不合格ページは分からず、改善が審査結果にどう影響するかもまだ分かりません。

ページの修正を公開した直後に、Search ConsoleやAdSenseの表示がすぐ変わるとは限りません。URLの再クロールや審査には時間がかかります。私の場合は、対処を公開してから1か月ほど運用し、記事を増やした後、2026年11月中旬を目安に再審査を検討しています。これは今回の運用計画であり、Googleが示した審査期間ではありません。

確認するときは、メールの文言だけで原因を決めず、URLのステータス、転送先、サイトマップの内訳、公開記事の内容を別々に記録します。修正したURLはSearch Consoleの検証結果を待ち、審査の結果が出る前に「この対処で通る」とは書かないようにします。結果が分かったら、確認した数字とともに追記します。

まとめ

Search Consoleの未登録理由は、404・重複・クロール済み未登録に分け、対象URLが何を返すかを確かめてから対処します。wwwが別サイトなら、ホスト全体を安易に転送せず、応答ヘッダーやタイトルで配信内容を比べます。AdSenseの低価値判定は個別URLが分からないため、サイトマップの構成や公開記事を自分で点検し、確認できた事実と推測を分けて記録します。私の再審査結果はまだ出ていません。結果が出たら追記します。

書いた人

Kyohei T.

個人開発者。つくったものと、その作り方を記録しています。運営者情報

記事一覧へ戻る