第11回 Search Consoleのインデックス未登録を調査する―原因修正と再クロール依頼まで

第10回では、GA4 Data APIから取得した直近30日のPVを使い、ゆまラボのTOPページへ人気記事を自動表示した。

検索側では、第2回のGoogle Search Consoleへゆまラボを登録でbringain.comを登録し、sitemap.xmlの送信とトップページのインデックス登録リクエストまで進めている。

そこから10日ほど経ち、Search Consoleの「ページ」を開くと未登録が131ページまで増えていた。

数字だけ見るとかなり多い。

ただし、GoogleのPage indexing reportは「未登録をすべて0にするための一覧」ではない。noindex、重複URL、404など、意図どおり検索結果へ出していないURLも含まれる。

今回は131件を理由別に確認し、正常な除外はそのまま残す。修正が必要なものだけ直し、公開後にURL検査とインデックス登録リクエストまで進めた。

2026年9月17日時点では、サイト側の修正と再クロール依頼まで完了している。Search Consoleの「クロール済み - インデックス未登録」などが更新された結果は、後日このページへ追記する。

未登録131ページを理由ごとに確認する#

Search Consoleの「インデックス作成 > ページ」を開くと、登録済みは101、未登録は131になっていた。

Search Consoleで登録済み101ページ、未登録131ページを確認した画面

未登録の理由は5種類。

Search Consoleに表示された5種類のインデックス未登録理由

横にスクロールできます

理由	ページ数	最初の判断
noindex タグによって除外されました	105	意図した除外か確認
代替ページ（適切な canonical タグあり）	9	HTTP→HTTPS等は正常、ページネーションを確認
見つかりませんでした（404）	2	意図した404と内部リンク由来を切り分け
クロール済み - インデックス未登録	8	実記事を優先して確認
検出 - インデックス未登録	7	クロール前のURLを確認

105 + 9 + 2 + 8 + 7で131件になる。

最初は「131件も直すのか」と思ったが、一覧を開くと話が変わった。大半は、以前こちらで意図的に検索対象から外したURLだった。

Googleの公式ヘルプでも、Page indexing reportについて「未登録は必ずしも問題ではない」とされている。重要なのは、検索結果へ出したいURLが正しい理由でインデックス可能になっているかどうかになる。

noindex 105件は修正しない#

最も多かったのはnoindexによる除外で105件。

例を見ると、ほぼ個別タグページだった。

個別タグページがnoindexによって除外されているSearch Consoleの画面

たとえば、

/tags/トップページ改善/
/tags/アンカーリンク/
/tags/ui改善/
/tags/google analytics/
/tags/chatgpt/

といったURLが並んでいる。

これは異常ではない。

旧連載の第13回タグページとフッターを見直すで、個別タグページへnoindex, followを設定している。タグはサイト内の導線として残す一方、検索結果へは通常記事やカテゴリを優先する方針にしたためだ。

後から/tags/の一覧ページもnoindexへ変更している。

ここで未登録数を減らすためだけにnoindexを外すと、以前決めた方針を逆に壊してしまう。

105件はそのまま残すことにした。

canonical 9件の中にページネーションの問題があった#

「代替ページ（適切なcanonicalタグあり）」は9件。

Search Consoleの代替ページ一覧でHTTP URLとpage=2を確認した画面

HTTPからHTTPSへ寄せているURLは想定内だった。

一方で、次のURLが混ざっている。

https://bringain.com/category/web-development/operation/?page=2

このURLは記事一覧の2ページ目なので、1ページ目と同じページではない。

URL検査の詳細を見ると、ユーザーが指定した正規URLは次の値だった。

https://bringain.com/category/web-development/operation/

Googleが選択した正規URLも同じ。

page=2なのに1ページ目がcanonicalとして指定されていたURL検査画面

ここは少し違和感があった。

Googleのページネーション向けドキュメントでは、?page=nの各URLは別ページとして扱い、1ページ目をすべてのcanonicalにしないよう案内されている。2ページ目なら2ページ目自身をcanonicalにする形になる。

原因をリポジトリ側で調べると、BaseHead.astroがAstro.url.pathnameだけを使ってcanonicalを生成していた。

そのためクエリパラメータの?page=2がcanonicalへ入らず、静的HTMLでは1ページ目のURLになっていた。

ページネーションの表示処理自体は動いている。ブラウザ側JavaScriptが現在ページを判定し、?page=2では2 / 2と2ページ目の記事10件を表示していた。

問題は記事一覧の中身ではなくcanonicalだった。

canonicalの最初の修正方法を一度やり直す#

最初の修正では、HTMLにある1ページ目のcanonicalを、JavaScript実行後に2ページ目のURLへ書き換える方法を使った。

ただ、GoogleのJavaScript SEOガイドを確認すると、元HTMLにあるcanonicalをJavaScriptで別URLへ変更する方式は避けるよう案内されている。

HTML側でcanonicalを出せない場合は、元HTMLからcanonicalを外し、JavaScript側で1つだけ生成する方法が示されていた。

ここは一度やり直した。

最終的には次の構成に変更している。

BaseHead.astro
  includeCanonicalを追加
  通常ページは従来どおりcanonicalを出す

SiteLayout.astro
  includeCanonicalをBaseHeadへ渡す

ArchiveLayout.astro
  ページネーション対象だけ初期HTMLのcanonicalを停止

PaginatedArticleList.astro
  現在ページ判定後、canonicalが無い場合だけ1個生成

?page=1は新しい正式URLとして扱わない。

結果は、

1ページ目
https://bringain.com/category/web-development/operation/

2ページ目
https://bringain.com/category/web-development/operation/?page=2

となる。

ページネーション対象の初期HTMLにはcanonicalを出さず、ブラウザ側で現在ページ確定後に1個だけ追加する。通常記事はこれまでどおり自己参照canonicalを維持した。

Googleのガイドでも、JavaScriptでcanonicalを挿入する場合はページ上で唯一のrel="canonical"にするよう案内されている。

404の2件は1件だけ修正する#

404は2件。

Search Consoleで検出された2件の404 URL

1つは、

https://bringain.com/404-test-before-custom-page/

これは第25回ゆまラボ専用の404ページを作るで、存在しないURLの動作確認に使ったもの。

HTTP 404を返すこと自体が正しいので変更しない。

もう1つは、

https://bringain.com/blog/example/

だった。

こちらは実ページとして作った覚えがない。

リポジトリを検索すると、CodexにX投稿を手伝わせるなどで、説明用の架空URLとしてbringain.com/blog/example/を使っていた。

検索エンジンから見ると、同じドメインへの通常リンクに見える。GoogleがURLを発見して404を確認しても不思議ではない。

説明用URLは、

https://example.com/blog/example/

へ変更した。

codex-x-web-intent.mdは5箇所、sns-publishing-candidates.mdは2箇所を変更している。

内部リンクチェックの記事では説明上「同一サイト内リンク」である必要があったため、架空URLへ置き換えず、実在する/blog/404-page-guide/へ変更した。

404を全部消すのではなく、意図的な404は残し、サイト内部から誤って発見させていたURLだけ直した。

クロール済み未登録8件を確認する#

次に「クロール済み - インデックス未登録」の8件を見る。

クロール済みインデックス未登録として表示された8 URL

8件の内訳は、通常記事2件、タグページ3件、XML/RSSが3件だった。

通常記事は次の2つ。

https://bringain.com/blog/07-bing-webmaster-tools-x-ga4-utm/
https://bringain.com/blog/ga4-internal-traffic-exclusion/

タグページは既存方針でnoindex対象なので変更しない。

sitemap-0.xml、sitemap-index.xml、rss.xmlも、通常の記事ページとして検索結果へ載せるためのURLではないため、インデックスさせる方向の変更は行わなかった。

実記事2件については、公開ページと生成HTMLを確認した。

横にスクロールできます

確認項目	第7回 Bing Webmaster Tools	GA4内部トラフィック
HTTPステータス	200	200
robots meta	なし	なし
noindex	なし	なし
canonical	自己参照	自己参照
sitemap掲載	あり	あり
生成HTML	正常	正常
内部リンク	59件	48件

技術的なインデックス阻害要因は見つからなかった。

本文やSEO設定を無理に書き換える理由もないため、ここは公開URLのライブテストと再クロール依頼へ進める。

検出未登録7件もサイト側の問題か確認する#

「検出 - インデックス未登録」は7件。

検出インデックス未登録として表示された7 URL

代表として、第4回のGA4導入記事をURL検査した。

https://bringain.com/blog/04-google-analytics-ga4-install/

Search Console上ではまだ未登録だが、サイトマップからURL自体は検出されている。

サイトマップ側を見ると、https://bringain.com/sitemap.xmlは2026年9月17日に正常読み込みされ、112ページを検出していた。

Search Consoleでsitemap.xmlが成功し112ページ検出されている画面

ライブテストを実行すると「URL は Google に登録できます」と表示された。

GA4導入記事のライブテストでGoogleに登録可能と確認した画面

この時点では、少なくとも現在の公開ページにクロールやインデックスを妨げる設定は検出されていない。

そのままインデックス登録をリクエストした。

GA4導入記事のインデックス登録リクエストが受け付けられた画面

修正を公開してビルドとリンクを確認する#

サイト側で変更したファイルは7つ。

src/components/BaseHead.astro
src/components/PaginatedArticleList.astro
src/layouts/ArchiveLayout.astro
src/layouts/SiteLayout.astro
src/content/blog/site-operation/sns/codex-x-web-intent.md
src/content/blog/site-operation/sns/sns-publishing-candidates.md
src/content/blog/web-development/operation/26-build-internal-link-check.md

ビルド結果は正常。

npm run build                 成功
生成ページ                     245
Pagefind                       84ページ / 5,622語
内部リンクチェック             245 HTML / 10,061リンク
壊れたリンク                   0
既存Frontmatter警告            17件

17件のFrontmatter警告は既存のもので、今回の修正対象には含めていない。

commitは次の内容で作成した。

0b57be3050b3da9da1a79ea0c1ab9b439dbab7de
fix(seo): correct paginated canonical and broken example links

origin/mainへのpushも成功し、Cloudflare公開後に確認した。

ページネーションは、

1ページ目
表示        1 / 2
canonical   https://bringain.com/category/web-development/operation/

2ページ目
表示        2 / 2
canonical   https://bringain.com/category/web-development/operation/?page=2

となり、それぞれcanonicalは1個だけ。

bringain.com/blog/example/を説明用に使っていた記事もexample.comへ反映され、404確認用の/404-test-before-custom-page/は引き続き404を返している。

公開後のpage=2をSearch Consoleで再確認する#

公開反映後、問題だった?page=2をもう一度ライブテストした。

2026年9月17日20:28時点で「URL は Google に登録できます」と表示された。

修正後のpage=2をライブテストしてGoogleに登録可能と確認した画面

そのままインデックス登録をリクエスト。

修正後のpage=2でインデックス登録リクエストが受け付けられた画面

Googleの公式ドキュメントでも、個別URLの再クロールにはURL検査ツールからインデックス登録をリクエストできる。ただし、リクエストしたから即座にインデックスされるわけではなく、同じURLを何度も送っても処理が速くなるわけではない。

ここから先はGoogle側のクロールとインデックス処理を待つ。

クロール済み未登録だった2記事も再クロールを依頼する#

技術的な問題が見つからなかった2記事もライブテストした。

第7回 Bing Webmaster Toolsの記事は20:29に「URL は Google に登録できます」を確認。

Bing Webmaster Tools記事のライブテスト成功画面

インデックス登録リクエストも受け付けられた。

Bing Webmaster Tools記事のインデックス登録リクエスト済み画面

GA4内部トラフィックの記事は20:30にライブテストを実行した。

GA4内部トラフィック記事のライブテスト成功画面

こちらもインデックス登録をリクエスト済み。

GA4内部トラフィック記事のインデックス登録リクエスト済み画面

これで、今回確認したインデックス対象URLはサイト側の問題を直すか、技術的な阻害要因がないことを確認したうえで再クロール待ちにできた。

未登録131件を0にする作業ではなかった#

作業前は「未登録131」という数字が目立った。

実際に分けてみると、対応はかなり違う。

noindex 105件
→ 意図したタグページ除外。変更しない

canonical 9件
→ HTTP→HTTPS等は正常
→ page=2のcanonicalだけ修正

404 2件
→ 404テストURLは正常
→ /blog/example/ の内部参照だけ修正

クロール済み未登録 8件
→ タグ/XML/RSSは変更しない
→ 通常記事2件は技術的問題なし、再クロール依頼

検出未登録 7件
→ 代表URLをライブテスト
→ 登録可能を確認して再クロール依頼

Google自身も、すべてのURLを100%インデックスさせることを目標にはしていない。重複URL、noindex、削除済み404などが正しい理由で未登録なら、その状態で問題ない。

今回必要だったのは、灰色の数字を全部緑にすることではなく、「検索結果へ出したいページ」と「出さなくてよいURL」を分けることだった。

2026年9月17日時点の結果#

Search Consoleの未登録理由を確認し、サイト側で必要だった修正は公開まで完了した。

ページネーション2ページ目は自己参照canonicalになるよう変更。説明用の架空内部URLは外部のexample.comまたは実在記事へ置き換えた。

04-google-analytics-ga4-install、07-bing-webmaster-tools-x-ga4-utm、ga4-internal-traffic-exclusionと、修正した?page=2はライブテストで「URL は Google に登録できます」を確認し、インデックス登録リクエストまで済ませている。

Search Consoleの集計はまだ更新前なので、「クロール済み - インデックス未登録」や「代替ページ」から対象URLが消えたところまでは確認していない。

この部分はGoogle側の再クロール後に追記する。

追記予定#

後日、Search Consoleで次を確認する。

クロール済み - インデックス未登録から通常記事2件が外れたか
検出 - インデックス未登録からGA4導入記事が外れたか
代替ページ（適切なcanonicalタグあり）から?page=2が外れたか

105件のnoindexや意図した404は、残っていて正常と判断する。