記事351本を全数でインデックス確認したら28.5%だった──URL Inspection APIで測った記録

2026年8月14日、当サイトの記事351本を1本ずつURL Inspection APIに投げ、Googleがどう扱っているかを全数で調べた。結果はインデックス済み100本（28.5%）／「検出したがまだクロールしていない」201本（57.3%）／GoogleがURLの存在を知らない48本（13.7%）／重複2本（0.6%）である。落ちている記事の共通点として真っ先に疑った「本文が短い」「1日に出しすぎた」は、どちらもこのデータでは説明が付かなかった。インデックス済み100本の本文中央値は3,190.5字で、検出のみ201本の3,530字より短い。公開本数が9本以下だった日の記事のインデックス率は31.4%、10本以上だった日は27.3%で、差は4.1ポイントしかない。説明が付いたのは公開日で、2026年7月9日以前に公開した251本は12.4%、7月10日〜8月7日の64本は98.4%だった。以下、測り方・全数の結果・分からなかったことを、再現できる形で置く。

1. 全351本のうちインデックス済みは100本（28.5%）。 最大の塊は「Discovered - currently not indexed（検出 - 現在インデックス未登録）」の201本（57.3%）で、この201本は全部がlastCrawlTime空＝一度もクロールされていない（2026年8月14日11時51分・URL Inspection API・全数）
2. 本文の長さでは説明が付かない。 インデックス済み100本の中央値3,190.5字＜検出のみ201本の3,530字。公開日を2026年7月9日以前に揃えて比べても、インデックス済み31本が3,258字・未登録220本が3,352字でほぼ同じ
3. サンプルでは見えなかった。 同じ日の40本サンプル（scripts/gsc_daily_snapshot.py）では「どの記事が落ちているか」の一覧が出ず、公開日で切ったコホート差（12.4% vs 98.4%）も、lastCrawlTimeが空の249本という事実も出てこない

測り方

使ったAPI：Search Console APIのurlInspection.index.inspect。リクエストは全351本で共通にsiteUrl: "https://www.ai-jitan-hub.com/"、inspectionUrlをhttps://www.ai-jitan-hub.com/news/{slug}と組み立てて1本ずつ投げる。認証はサービスアカウント（スコープhttps://www.googleapis.com/auth/webmasters）。

対象：content/news/*.mdの全数。slug昇順で351本。サンプリングはしていない。

実行日時：2026年8月14日、出力ファイルdata/gsc/full-inspect-2026-08-14.jsonの保存は同日11時51分（日本時間）。

上限：URL Inspection APIのクォータは公式ドキュメント「Search Console API usage limits」（最終更新2025年8月28日UTC・2026年8月14日確認）に載っている。

351本は1サイトあたり2,000クエリ／日の上限に収まる。実装では1本ごとにtime.sleep(0.12)を入れていて、これは理論上毎分500回で、毎分600回の上限の下に収まる計算になる。HTTP 429／500／503が返った場合だけ最大3回まで5秒・10秒待って再試行する。この走査でのエラーは0本（351本すべてがindexStatusResultを返した）。

記録した項目：verdict／coverageState／lastCrawlTime／robotsTxtState／googleCanonical／userCanonical／referringUrls（先頭3件）。加えて記事側からtype／category／date／updatedAt／本文字数（空白除去後）を取って同じ行に並べてある。

このAPIが返すものの制約：Search Consoleヘルプ「URL Inspection Tool」（2026年8月14日確認）は明記している。

This is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web.

（これはライブテストではない。表示される結果は、ウェブ上の現在のバージョンではなく、最後にインデックスされたバージョンのものである）

つまりこの351行は「いまGooglebotが取りに行ったらどうなるか」ではなく「Google側にいま何が記録されているか」のスナップショットである。

結果

インデックス状態（全351本）

※割合は小数第1位で四捨五入しているため合計が100%にならない。

verdictはPASSが100件、NEUTRALが251件だった。APIリファレンス（最終更新2025年1月21日UTC）はPASSを「Equivalent to "Valid" for the page or item in Search Console.（Search Consoleでの"有効"に相当）」、NEUTRALを「Equivalent to "Excluded" for the page or item in Search Console.（Search Consoleでの"除外"に相当）」と定義している。251本が「除外」側にいる。

クロールされたかどうか

lastCrawlTimeが入っていたのは102本だけで、残り249本は空だった。APIリファレンスのlastCrawlTimeの定義は「Last time this URL was crawled by Google using the primary crawler. Absent if the URL was never crawled successfully.（Googleがプライマリクローラでこのurlを最後にクロールした時刻。一度も正常にクロールされていない場合は存在しない）」である。Search Consoleヘルプの「Discovered - currently not indexed」の説明も、この空欄と同じ話をしている。

The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report.

（ページはGoogleに見つかったが、まだクロールされていない。通常、GoogleはそのURLをクロールしようとしたが、サイトに過負荷をかけると見込まれたため、クロールを再スケジュールした。レポート上で最終クロール日が空なのはこのためである）

robotsTxtStateが249本でROBOTS_TXT_STATE_UNSPECIFIEDだったのも、robots.txtの設定ミスではなく同じ理由で説明できる。この列挙値の定義は「Unknown robots.txt state, typically because the page wasn't fetched or found, or because robots.txt itself couldn't be reached.（robots.txtの状態が不明。通常はページが取得も発見もされなかったため、あるいはrobots.txt自体に到達できなかったため）」である。ページが取りに行かれていないので、robots.txtの判定結果も無い。

なおlastCrawlTimeが入っていた102本の範囲は2026年6月13日04:35:06 UTC〜8月13日19:11:19 UTCだった。

本文の長さ（空白除去後の文字数）

インデックスされていない記事の方が長い。 文字数で区切っても順序は出ない。

長さと公開日が絡んでいる可能性があるので、公開日を2026年7月9日以前（251本）に揃えて比べ直した。インデックス済み31本の中央値3,258字に対し、未登録220本は3,352字で、同じコホートの中でも長さでは分かれなかった。

1日あたりの公開本数

「1日に出しすぎたから弾かれた」という仮説も、このデータでは支持されなかった。公開日は60日に分かれる。

差は4.1ポイントである。1日の最大は2026年6月19日の100本で、この日のインデックス率は15.0%（15/100）だった。10本以上の日の249本のうち100本がこの1日に集中しているので、公開日の偏りを外して2026年7月9日以前公開の251本だけで切り直した。9本以下の日は11.4%（9/79）、10本以上の日は12.8%（22/172）で、こちらでも差は出なかった。なお2群とも大半が7月9日以前の記事である（9本以下102本のうち79本＝77.5%、10本以上249本のうち172本＝69.1%）。

公開日

2026年7月10日は、当サイトがapexドメインからwwwへ308恒久リダイレクトを入れた日である（詳しくはURLプレフィックス型プロパティの集計範囲の記事）。8月8日以降の16.7%は、測定当日の8月14日公開分31本を含むので、そのまま「新しい記事も通っていない」とは読めない。

公開からの経過日数で切り直したのが次で、これはscripts/newest_articles_watch.pyが同日15時56分に出したdata/gsc/newest-watch.csvである（対象は2026年7月12日以降に公開した108本）。

15日以上で唯一インデックスされていないのはai-daily-standup（2026年7月16日公開・経過29日・Discovered）の1本だった。2〜7日のセルはそれぞれ2本しかないので、この表で言えるのは「0〜1日はまだ入っていない」までである。

記事の型・カテゴリ

型・カテゴリと公開日は独立ではない（guideは新しい記事に偏っている）ので、この2表だけでは型の効果と公開日の効果を分離できない。

内部リンクと正規URL

referringUrls（APIの定義は「URLs that link to the inspected URL, directly and indirectly.」＝検査対象URLに直接・間接にリンクしているURL）が1件以上返ったかどうかを数えると、状態できれいに分かれた。

googleCanonical（「The URL of the page that Google selected as canonical. If the page was not indexed, this field is absent.」）が入っていたのは102本で、うち100本はwwwホスト、2本は非wwwホストだった。この2本が「重複」判定を受けた記事で、どちらもuserCanonicalはwwwを宣言している。

2本とも、記録された参照元がVercelのプレビュードメインだった。Search Consoleヘルプの「Duplicate, Google chose different canonical than user」の定義は「This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical. Google has indexed the page that we consider canonical rather than this one.（このページは一連のページの正規として指定されているが、Googleは別のURLの方が正規にふさわしいと考えている。Googleはこのページではなく、正規とみなしたページをインデックスしている）」である。プレビュードメインの参照が正規URLの選択にどう効いたかは、このデータからは確認できていない。

分かったこと／分からなかったこと

分かったこと

• 全351本のうち、Googleが一度でも取りに来たのは102本（29.1%）だけだった。残り249本はlastCrawlTimeが空である
• 「インデックスされない」の内訳は一様ではない。201本はGoogleは知っているがクロールしていない、48本はGoogleが存在自体を知らないで、打つ手が違う
• 48本の「知らないURL」はreferringUrlsが全件0だった。Search Consoleヘルプは「URL is unknown to Google: This means that Google hasn't seen this URL before.（GoogleがこのURLをこれまで見たことがない）」と書いている
• 本文の長さ・1日あたりの公開本数では、インデックスされた記事とされなかった記事を分けられなかった

分からなかったこと

• 201本がクロールされない理由は特定できていない。 公式の説明は「サイトに過負荷をかけると見込まれたため再スケジュールした」だが、当サイト側でGooglebotのクロール要求とサーバ応答を突き合わせた記録は取っていない
• 被リンクは測れなかった。 同日に測定を試みて失敗した記録がdata/gsc/backlinks-2026-08-14.txtにある。検索結果HTMLから抽出したドメインはリンク元ではなく同じクエリの他の検索結果で、被リンク数として使えるものではなかった。弱い傍証として、Wayback Machineに保存されている当サイトのURLが2026年1月1日以降で7件だったこと、"AI時短ラボ" -site:ai-jitan-hub.comで出た外部ドメインがyoutube.com／note.com／x.com＝いずれも運営者自身の面だったことだけを記録している
• 旧ホスト側との差は抜き取りでしか見ていない。 www側で「検出のみ」かつ2026年7月9日以前公開の186本から40本を無作為抽出（seed 20260814）して旧ホストで同じ検査をかけた結果は、Submitted and indexed 13本（32.5%）／URL is unknown to Google 26本（65.0%）／Crawled - currently not indexed 1本（2.5%）だった。186本への外挿は約60本になるが、抽出した40本を数えただけで、残り146本は検査していない
• Bingは別の症状だった。 Googleでインデックス済みの記事から40本を無作為抽出（seed 814）してタイトル完全一致で検索したところ、当サイトが出たのは0本だった。対照群のブランド名検索ではドメインが6回出ている。この0本の原因はこの記事では調べていない

使ったスクリプト

scripts/gsc_full_inspect.py（全数検査・出力はdata/gsc/full-inspect-YYYY-MM-DD.json）

設計は3つだけである。

1. content/news/*.mdを読んで記事の素性を先に作る。 frontmatterからtype／category／date／updatedAt、本文から空白除去後の文字数を取り、slugをキーにした辞書にする。APIの結果と同じ行に並ぶので、「落ちている記事の共通点」を後から何軸でも切れる
2. 全slugをループしてinspectを叩く。 1本ごとにtime.sleep(0.12)、429／500／503のときだけ最大3回まで5秒・10秒待って再試行する。ネットワーク断などの例外はその行のerrorフィールドに記録して次へ進む（1本の失敗で走査全体を落とさない）
3. 1行1記事のJSONで保存する。 集計は後段に任せ、このスクリプトは生の応答を落とすことに徹する

scripts/gsc_compare_inspect.py（2時点の差分）は、同じ形式のJSON 2本を読んで公開日コホート別に状態遷移を出す。2026年7月10日を境界に置いてあり、旧URLへの手当てが効いたかを、新記事が通っている効果と混ぜずに見るためのもの。

scripts/newest_articles_watch.py（新記事の追跡）は、直近に公開した記事だけを毎日検査して、公開からの経過日数別インデックス率をdata/gsc/newest-watch.csvに追記する。上の経過日数の表はこれの出力である。

APIキーはリポジトリに置いていない。スクリプトはホームディレクトリ配下のサービスアカウント鍵を参照する。

正直な但し書き

1時点のスナップショットである。 2026年8月14日11時51分の1回の走査で、インデックス状態は日単位で揺れる。この記事の数字を「確定した比率」として扱わない。 効果を見るには最低2〜4週間空けて同じスクリプトを回し、同じ方向に動いているかを見る必要がある。

因果は確定していない。 2026年7月9日以前と7月10日以降で12.4%対98.4%という差が出ているが、この日付は当サイトが308リダイレクトを入れた日であると同時に、記事の作り方・内部リンクの通し方が変わった時期でもある。どの変更がどれだけ効いたかは、このデータからは分離できない。

「知らないURL」48本の一部は単に新しすぎる。 2026年8月14日（測定当日）公開の31本のうち16本がここに含まれている（残る15本は「検出のみ」14本・インデックス済み1本）。48本すべてが「発見されないまま放置されている記事」ではない。ただし残り32本はすべて2026年7月9日以前の公開である。

referringUrlsは先頭3件しか保存していない。 上の表の「1件以上」はリンクが存在するかどうかであって、リンク本数の多寡は測っていない。APIの定義も「directly and indirectly（直接・間接）」で、内部リンクと外部リンクを区別していない。

記録していない応答項目がある。 APIはsitemap[]（そのURLが載っていたサイトマップ）・indexingState（noindexで弾かれていないか）・pageFetchState（サーバから取得できたか）・crawledAs（どのクローラで来たか）も返すが、今回のスクリプトはこれらを保存していない。したがって「サイトマップに載っているのにクロールされていない」という言い方は、この記事のデータでは裏付けられない。

文字数はマークダウンの生テキストの長さである。 frontmatterを除いた本文から空白を除いた文字数で、見出し記号・リンク記法・コードブロック・出典リストを含む。読者が読む本文の量とは一致しない。

記事の中身は評価していない。 有用性・独自性・重複といった内容側の要因はこのデータに入っていない。ここで扱ったのは長さ・公開日・型・カテゴリ・参照元の有無という、機械的に取れる素性だけである。

Search Consoleヘルプの日本語ページには機械翻訳の注記が付くものがある。 引用は英語版の原文を採り、訳は当サイトで付けた。訳の責任は当サイトにある。

出典

• Search Console API usage limits | Search Console API（最終更新2025年8月28日UTC、2026年8月14日確認）: https://developers.google.com/webmaster-tools/limits
• Method: index.inspect | Search Console API（最終更新2024年7月23日UTC、2026年8月14日確認）: https://developers.google.com/webmaster-tools/v1/urlInspection.index/inspect
• UrlInspectionResult | Search Console API（最終更新2025年1月21日UTC、2026年8月14日確認）: https://developers.google.com/webmaster-tools/v1/urlInspection.index/UrlInspectionResult
• Page Indexing report - Search Console Help（2026年8月14日確認）: https://support.google.com/webmasters/answer/7440203
• URL Inspection Tool - Search Console Help（2026年8月14日確認）: https://support.google.com/webmasters/answer/9012289
• AI時短ラボ 実測ログ: data/gsc/full-inspect-2026-08-14.json（全351本・2026年8月14日11時51分）／data/gsc/newest-watch-2026-08-14.json・data/gsc/newest-watch.csv（同日15時56分）／data/gsc/oldhost-check-2026-08-14.txt／data/gsc/bing-coverage-2026-08-14.txt／data/gsc/backlinks-2026-08-14.txt
• 使用スクリプト: scripts/gsc_full_inspect.py／scripts/gsc_compare_inspect.py／scripts/newest_articles_watch.py