www化した日を境にインデックス率が12.4%と98.4%に割れた──351記事の実測

2026年7月10日、当サイトはapexドメイン（ai-jitan-hub.com）からwww（www.ai-jitan-hub.com）への308恒久リダイレクトを入れた。その35日後の2026年8月14日、全351記事をSearch ConsoleのURL Inspection APIで1本ずつ検査したところ、インデックス率が公開日でほぼ二値に割れていた。7月9日以前に公開した251本は12.4%（31本）、7月10日から8月7日までに公開した64本は98.4%（63本）。7月だけを9日で切ると、7月1〜9日が5.9%（17本中1本）、7月10〜31日が98.3%（59本中58本）である。境目は9日しか離れていない。そして移行前に公開した251本は測定時点で最短36日・中央値56日が経過してもなお12.4%にとどまるのに対し、移行後に公開した記事は公開から2日で98.5%（68本中67本）が登録されていた。移行の取り残しは、待っていても解消されない。 ただし原因は特定できていない。旧ホスト側で調べ直すと未登録記事の65%はそちらでも一度もクロールされておらず、さらに7月10日のコミットでは308の導入とサイトが宣言する正規ホストの変更が同時に入っている（詳細は後述）。この記事が言えるのは「7月10日を境に割れた」までである。

1. 全351記事の全数検査（2026年8月14日11時51分・URL Inspection API）で、**7月9日以前公開の251本は12.4%（31本）、7月10日〜8月7日公開の64本は98.4%（63本）**がインデックス済み。境目は308恒久リダイレクトを入れた2026年7月10日と一致する
2. 移行前コホート251本のうち218本（86.9%）はAPIがlastCrawlTimeを返さない＝www側のURLが一度もクロールされていない。「重複」と判定された2本は、どちらもGoogleが選んだ正規URLが非www・サイトが宣言している正規URLがwww
3. www側で未登録の186本から40本を抜いて旧ホストで検査すると、32.5%（13本）は旧ホストでSubmitted and indexed、65.0%（26本）は旧ホストでもURL is unknown to Google。旧ホストでの状態が2つに割れており、移行の取り残しだけでは説明できない

測り方

全数検査（表1〜5・表8のもと）

• 対象：content/news/*.md の全351本（2026年8月14日11時51分に走査を回した時点の実ファイル数）。サンプリングではなく全数。なお同じ日のうちにも記事は増えており、本稿の検品時点（同日19時06分・この記事自身を含む）で375本になっている。以下の表1〜5・表8はすべて「11時51分の351本」の上の数字である
• API：Search Console APIのurlInspection.index.inspect
• siteUrl：https://www.ai-jitan-hub.com/（URLプレフィックス型プロパティ・末尾スラッシュあり）
• inspectionUrl：https://www.ai-jitan-hub.com/news/<slug> を1本ずつ
• 認証：https://www.googleapis.com/auth/webmasters スコープのサービスアカウント（鍵の所在は非公開）
• 保存したフィールド：verdict / coverageState / lastCrawlTime / robotsTxtState / googleCanonical / userCanonical / referringUrls（先頭3件）
• 記事側の素性：公開日・更新日・種別・カテゴリはfrontmatterから、本文字数は本文から空白を除いて数えた
• レート制御：1件ごとに0.12秒スリープ。429/500/503は同じURLを最大3回まで試行（リトライは2回）
• スクリプト：scripts/gsc_full_inspect.py
• 出力：data/gsc/full-inspect-2026-08-14.json（351件・1件1オブジェクト）

制約は3つある。第一に、URL Inspection APIの上限は公式に「2000 QPD」「600 QPM」（いずれもサイトあたり）と書かれており、351本は1回の全数走査に収まるが、日に何度も回せるものではない。第二に、coverageStateは測定した瞬間の状態であって、日単位で揺れる。第三に、これはGoogleがそのURLについて何を知っているかであって、検索順位でも表示回数でもない。

旧ホスト側の抜き取り（表7のもと）

• 母集団：www側でDiscovered - currently not indexedかつ2026年7月9日以前公開の186本
• 標本：そこから40本を無作為抽出（seed 20260814）
• やったこと：同じAPIをsiteUrl＝https://ai-jitan-hub.com/（非www）に切り替えて叩き直す
• 出力：data/gsc/oldhost-check-2026-08-14.txt

全数ではなく40本なのは、一時スクリプトで手早く確かめたためである。標本の小ささについては最後の但し書きに書く。

公開からの経過日数別（表6のもと）

• 対象：2026年7月12日〜8月14日に公開した108本（すべて移行後の公開）
• スクリプト：scripts/newest_articles_watch.py
• 出力：data/gsc/newest-watch-2026-08-14.json / data/gsc/newest-watch.csv（2026年8月14日15時56分）

リダイレクトが実在することの確認

記事執筆時点（2026年8月14日18時50分・日本時間）にcurl -sIで叩き直した結果は次のとおりで、トップと記事URLの両方で308が返る。

$ curl -sI https://ai-jitan-hub.com/news/rag-retrieval-augmented-generation-guide-2026
HTTP/2 308
location: https://www.ai-jitan-hub.com/news/rag-retrieval-augmented-generation-guide-2026

結果

表1：全351本のインデックス状態（2026年8月14日11時51分）

表2：公開日コホート別のインデックス率

表3：7月を9日で切る

9日しか離れていない2つの窓で、率が5.9%と98.3%に分かれる。ただし前者は17本しかない。

表4：月別

7月が77.6%と中途半端なのは、7月の中に境目があるからである（表3）。8月が下がるのは、公開から日が浅い記事を含むからである（表6）。

表5：移行前コホート251本の内訳

表6：移行後に公開した108本を、公開からの経過日数で分ける

「2〜3日」「4〜7日」は各2本しかない。この2行の100.0%は率として読める数字ではなく、本文で使うのは合計の68本の方である。

表6は15時56分の取得なので、11時51分の全数走査（表1〜5）より母集団が新しい。差分は8本あり、**8本とも公開当日（経過0日）**である。したがって「2日以上」の68本は表1〜5の351本に完全に含まれており、増えているのは「0〜1日」の40本の側だけである。

表7：www側で未登録の40本を、旧ホストで検査し直す

表8：「重複」と判定された2本

分かったこと

1. 境目は公開日であって、本文の長さではない。 インデックス済み100本の本文字数の中央値は3,190.5字、Discovered201本は3,530字で、未登録の方が長い。長さで説明しようとすると符号が逆になる。

2. 移行前コホートは「クロールされていない」。 Discovered - currently not indexedの201本は全件でlastCrawlTimeが空、URL is unknown to Googleの48本も全件で空だった。robotsTxtStateも、ROBOTS_TXT_STATE_UNSPECIFIEDが249本／ALLOWEDが102本で、ALLOWEDの102本は「インデックス済み100本＋重複2本」＝クロールされた記事とちょうど一致する。移行前コホート251本のうち218本（86.9%）がlastCrawlTimeなしである。

Search ConsoleヘルプのDiscovered - currently not indexedの定義は「The page was found by Google, but not crawled yet.（そのページはGoogleに見つかったが、まだクロールされていない）」である。当サイトの実測はこの定義と符合する。

3. 「重複」2本の中身が、移行の取り残しの形をしている。 表8のとおり、2本ともGoogleが選んだ正規URLが非www側で、サイトが宣言している正規URLはwww側である。ヘルプの定義は「This page is marked as canonical for a set of pages, but Google thinks another URL makes a better canonical.（このページは正規として指定されているが、Googleは別のURLの方が正規として適切だと判断している）」。参照元URLがさらに前のホスト（ai-jitan-hub.vercel.app）である点も含めて、Googleが古いURLを持ったままであることを示している。

4. 時間では解決しない。 移行後に公開した記事は、公開から2日以上経った68本のうち67本＝98.5%が登録されている（表6）。一方、移行前に公開した251本は最短36日・中央値56日・最長183日（最古は2026年2月12日公開）が経過しても12.4%である。**「新しく作れば2日で入るのに、古いものは半年待っても入らない」**という状態になっている。

5. クロールされさえすれば登録されている。 移行前コホートでインデックス済みの31本のlastCrawlTimeを見ると、30本が2026年7月10日以降にクロールされている（範囲は2026年6月13日〜8月9日）。つまり移行前の記事が拒否されているのではなく、そもそも取りに来られていない。

Google Search Centralの「How to move a site」（最終更新2026年6月17日UTC・2026年8月14日確認）はこう書いている。

To consider a site move complete, Googlebot will have to visit every URL on your old and new site at least once. There are no fixed crawl frequencies; how fast Googlebot crawl depends on the size of your site, and the speed of crawling that's possible. The move takes place on a per-URL basis.

（サイト移転が完了したとみなすには、Googlebotが旧サイトと新サイトのすべてのURLを少なくとも1回は訪問する必要がある。固定のクロール頻度は存在せず、Googlebotがどれだけ速くクロールするかはサイトの規模と可能なクロール速度に依存する。移転はURL単位で進む）

「Redirects and Google Search」（最終更新2026年4月14日UTC・2026年8月14日確認）は308を恒久リダイレクトに含めたうえで、こう書く。

Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.

（Googlebotはリダイレクトをたどり、インデックスのパイプラインはそのリダイレクトを「リダイレクト先が正規であるべき」というシグナルとして使う）

リダイレクトはたどられて初めてシグナルになる。 旧URLが再クロールされない限り、308は誰にも読まれないまま置かれている。

分からなかったこと

1. 「308が原因」とは言えない。7月10日に変わったのは308だけではないからである。 リポジトリの該当コミット（8bc70bf・2026年7月10日11時49分01秒 +0900）を開くと、変更は14ファイルに及び、そのうち少なくとも次の3つが同時に入っている。

SITE.urlはcanonicalタグ・サイトマップ・構造化データの生成元なので、この1コミットで「リダイレクトの導入」と「サイトが名乗る正規URLの変更」が同時に起きている。7月10日の前後でインデックス率が割れているという観測は変わらないが、割れた原因を308だけに帰属させることはできない。 表8の2本のreferringUrlsがai-jitan-hub.vercel.appを指していることも、それ以前は別のホストが正規として出回っていたという読みと矛盾しない。矛盾しないというだけで、確認はしていない。

2. 旧ホストでも65%は未認識だった。 表7のとおり、www側で未登録の40本のうち26本（65.0%）は**非wwwプロパティで検査してもURL is unknown to Google**である。この65%は「308の取り残し」では説明できない。旧ホスト時代からクロールが公開ペースに追いついていなかった可能性が残るが、当サイトはそれを確かめていない。少なくとも2つの異なる状態が混ざっており、1つの説明では足りない。

3. 2026年8月8日以降の36本（16.7%）を移行の話に混ぜてはいけない。 内訳はURL is unknownが16本、Discoveredが14本、インデックス済みが6本で、公開0〜1日の40本のうち23本がunknownである（表6）。単に新しすぎるだけの可能性が高く、移行前コホートと同じ扱いはできない。

4. 被リンクは測れていない。 検索結果HTMLから外部リンク元を抽出しようとしたが、抽出されたドメインはリンク元ではなく同じクエリの他の検索結果だった（data/gsc/backlinks-2026-08-14.txtに失敗として記録）。したがって「移行前コホートが登録されないのは被リンクが足りないから」という説明は、手元のデータでは支持も否定もできない。

打った手：旧URLだけを並べたサイトマップを出す

2026年8月14日、/sitemap-legacy.xml を新設して旧ホスト（非www）のURLだけを並べ、非wwwプロパティに登録した。

• 実装：src/app/sitemap-legacy.xml/route.ts。date < "2026-07-10" の記事だけを、オリジンをhttps://ai-jitan-hub.comに置き換えて<loc>に並べる（lastmodはupdatedAtがあればそれ、無ければdate）
• 実物の確認（2026年8月14日18時50分・日本時間）：HTTPステータス200、<loc>が251件、うちwwwを含むものは0件
• 登録の記録：非wwwプロパティに登録済み。最終取得 2026-08-14T03:27:48Z／エラー0／警告0／web 251件（data/gsc/README.mdに記録）

根拠。 「How to move a site」の「Use Search Console to monitor traffic」の節には、旧URLのサイトマップを送ることが明記されている。

Submit the two sitemaps you saved earlier from the mapping. Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many pages indexed. Over time the number of pages indexed from the old URLs sitemap would drop to zero with a corresponding increase of indexing of the new URLs. Note that Search Console may show warnings for the sitemap that contains the old URLs about the URLs redirecting; this is normal and you can ignore these warnings: you are, in fact, moving to new URLs after all.

（マッピングから先に保存しておいた2つのサイトマップを送信する。当初は新URLを含むサイトマップのインデックス数はゼロで、旧URLのサイトマップは多くのページがインデックスされているはずである。時間が経つにつれ旧URLサイトマップのインデックス数はゼロへ下がり、それに対応して新URLのインデックスが増える。なお、旧URLを含むサイトマップについて、Search ConsoleがURLのリダイレクトに関する警告を表示することがあるが、これは正常であり無視してよい。実際に新URLへ移転しているのだから当然である）

同ページは「Submitting a sitemap can help make the discovery process quicker（サイトマップの送信は発見のプロセスを速める助けになる）」とも書いている。当サイトの実測（移行前コホートの86.9%が未クロール、うち抜き取りの32.5%は旧ホストでは登録済みのまま）と、この2つの引用を突き合わせた結果として打った手である。

ただし公式は一意に指示していない。 同じページの「Start the site move」の節にはこう書いてある。

Submit the new sitemap in Search Console. This will help Google learn about the new URLs. At this point you can remove your old sitemap, since Google will use the new sitemap going forward.

（新しいサイトマップをSearch Consoleに送信する。これによりGoogleは新URLを知ることができる。この時点で旧サイトマップは削除してよい。以降Googleは新サイトマップを使うからである）

「旧サイトマップは消してよい」と「2つ送って監視する」が同じページに併記されている。 当サイトは後者を採ったが、公式が片方だけを指示しているわけではない。

消す条件も先に決めてある。 出しっぱなしにすると恒久的にリダイレクト元をクロールさせ続けることになるため、「2026年7月9日以前公開コホートのインデックス率が十分に上がったら、このルートとSearch Console側の登録の両方を消す」としている（判定はscripts/gsc_full_inspect.pyの再実行）。

同じ日に3つ手を打っているので、効果の切り分けが要る。 (A) 旧URLサイトマップ、(B) 本文からの内部リンクが無い記事を167本→69本に減らす、(C) 同一イベントの重複記事2組をcanonicalSlugで1本に寄せる（記事は削除していない）。(A)は「7月9日以前公開の記事」だけに効き、(B)は「リンクを通した記事」に効くので、公開日コホートで分ければ切り分けられる、という設計にしてある。

使ったスクリプトとデータ

再測定は次の2コマンドで、公開日コホート別の差分が出る。

python3 scripts/gsc_full_inspect.py
python3 scripts/gsc_compare_inspect.py

正直な但し書き

因果を確定していない。 7月10日という境目は相関である。しかも上に書いたとおり、その日のコミットでは308と正規ホストの宣言が同時に変わっているので、この記事は「7月10日を境に割れた」までしか言っていない。「308リダイレクトのせいで割れた」とは言っていない。 切り分けは2〜4週間空けてgsc_compare_inspect.pyを回し、7月9日以前コホートだけが動くかどうかで見る。1回の比較では結論を出さない。

旧ホストの抜き取りは40本しかない。 32.5%（13/40）の95%信頼区間をWilson法で計算すると20.1%〜48.0%になる。186本への外挿「およそ60本」は、37本〜89本くらいの幅を持つ数字として読む必要がある。

表3の5.9%は17本の上に乗っている。 9日という窓が短いぶん母数が小さい。表2の12.4%（31/251・95%信頼区間8.8%〜17.0%）と98.4%（63/64・同91.7%〜99.7%）の方が母数が大きい。

coverageStateは測定した瞬間の値である。 この記事の数字は2026年8月14日11時51分の1回の測定にすぎない。同じ日の11時51分と15時56分の両方に含まれる100本を突き合わせると、1本（ai-video-prompt-concrete-nouns）がURL is unknown to GoogleからDiscovered - currently not indexedへ4時間で変わっていた。

サイトマップ登録の効果はまだ出ていない。 登録したのは同じ2026年8月14日で、この記事の時点で再測定はしていない。効果が出たかどうかはこの記事では言えない。

Bing側は別問題として残っている。 Googleでインデックス済みの40本をタイトル完全一致でBingに投げたところ0本だった（対照群のブランド名検索ではドメインが6回出たので、遮断されているわけではない・data/gsc/bing-coverage-2026-08-14.txt）。この記事はGoogleの話に限っている。

英語版から引用し、訳は当サイトで付けた。 引用したGoogleのヘルプ／ドキュメントの日本語ページには機械翻訳の注記があるページがあるため、原文は英語版を採った。訳の責任は当サイトにある。

1サイト・1回の測定である。 他のサイトで同じことが起きるかどうかは、当サイトのデータからは分からない。

出典

• How to move a site | Google Search Central（最終更新2026年6月17日UTC、2026年8月14日確認）: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
• Redirects and Google Search | Google Search Central（最終更新2026年4月14日UTC、2026年8月14日確認）: https://developers.google.com/search/docs/crawling-indexing/301-redirects
• Page Indexing report - Search Console Help（2026年8月14日確認）: https://support.google.com/webmasters/answer/7440203
• Method: index.inspect | Search Console API（2026年8月14日確認）: https://developers.google.com/webmaster-tools/v1/urlInspection.index/inspect
• Usage Limits | Search Console API（最終更新2025年8月28日UTC、2026年8月14日確認）: https://developers.google.com/webmaster-tools/limits
• AI時短ラボ 実測ログ（いずれも2026年8月14日取得）: data/gsc/full-inspect-2026-08-14.json／data/gsc/oldhost-check-2026-08-14.txt／data/gsc/newest-watch-2026-08-14.json／data/gsc/backlinks-2026-08-14.txt／data/gsc/bing-coverage-2026-08-14.txt／data/gsc/README.md