記事のビルドが成功し、中国語と日本語の URL がどちらも 200 を返し、トップページにも入口がある。この時点で「公開できた」とは言えます。しかし「Google に登録された」と言うには、まだ見えない段階が残っています。ページは自分たちのサーバーが配信し、検索インデックスは検索サービスが管理します。前者の成功は後者の完了を自動的に証明しません。

今日は谷米ブログを使い、誰でも再確認できる公開情報を点検します。順位を宣言したり、アクセス数から Google の内部状態を推測したりする調査ではありません。問いはもっと具体的です。サイトの管理者が入手できる証拠は何か。それぞれ、どの段階までを裏付けるのか。 点検中に実際に切れていたページのヘッダー内の二つの URL も見つかりました。公開情報を修正したうえで、「信号を直した」と「登録を確認した」を区別します。

1. 「公開された」を四つの問いに分ける

ローカルのビルドは、ソースからページを生成できる証拠です。公開 URL へのリクエストは、点検時にその利用者が応答を取得できた証拠です。robots.txt、サイトマップ、ページのヘッダー、内部リンクからは、クローラーに発見や読み取りの手がかりを渡しているかを調べられます。最後に、Google のインデックスに入ったかどうかは、Google 側の記録です。

この四段階は置き換えられません。Google の説明は、ページの発見とクロール、インデックス登録、個々の検索結果での表示という流れを示し、基本要件を満たしても、すべてのページのクロール、登録、表示を保証しないと明記しています。Google Search Central：検索の仕組み

デプロイしたばかりのページが 404 なら、まずデプロイを直すべきで、内容の評価を論じる段階ではありません。逆に、ページ、サイトマップ、クロールの許可を確認できても、一部の障害を取り除いたと言えるだけです。その公開テストを「登録済み」の画面の代わりにしてはいけません。この証拠の境界が、調査の順番を決めます。

2. 範囲を明示した現場の点検

新しい記事の公開前、2026 年 9 月 30 日に、外部から9 月 29 日の中国語記事と対応する日本語記事を調べました。環境は macOS 上の Python 3.9.6 標準ライブラリです。Google へのログインや、同じサーバーにある他社サイトへのリクエストは行っていません。完全な公開情報の点検スクリプトはダウンロードできます。同一オリジンの二つの HTTPS 記事 URL を渡し、追加パッケージは不要です。

python3 search-discovery-audit.py --self-test
python3 search-discovery-audit.py \
  https://gumi.ink/posts/2026-09-29-when-should-http-requests-retry/ \
  https://gumi.ink/ja/posts/2026-09-29-when-should-http-requests-retry/

最初のコマンドは固定したサンプルで、正常なヘッダー、noindex と canonical の欠落、XML 名前空間のあるサイトマップをパーサーが識別できるかを確認します。二つ目が公開サイトへのリクエストです。スクリプトは二記事、robots.txt、そこで宣言されたサイトマップ、ページのヘッダーに宣言されたリンクを取得します。一応答あたり最大 2 MB、サイトマップは最大五ファイルです。Python の robots パーサーで規則を一度判定しますが、Googlebot の実際のクロールを再現するものではありません。

修正前に観察したのは、「すべて正常」でも「登録されていないことが確実」でもありません。

公開された証拠修正前の実測言えること
二記事の HTTP ステータスどちらも 200、言語は zh-CN と ja-JP当時、外部から読めた
robots.txtAllow: /、sitemap-index.xml への参照読めるサイトマップの入口を宣言している
サイトマップインデックスは sitemap-0.xml を指し、二 URL と相互の言語版も記載発見と言語の対応づけの手がかりがある
HTML ヘッダーのサイトマップ/sitemap.xml を指し、実際は 404ページ自身が壊れたリンクを宣言している
HTML ヘッダーの RSS/feed.xml を指し、実際は 404存在しない購読先を宣伝している
canonical と共有 URLcanonical はなく、両ページの og:url はトップページページの識別情報が不完全または不正確
Google への登録今回は Search Console を参照していない不明

ここで二つのサイトマップのアドレスを混同しないことが重要です。robots.txt が指す実際のサイトマップは使えました。壊れていたのは HTML ヘッダー側の /sitemap.xml です。したがって、このリンクは修正すべきですが、「Google は記事をまったく発見できない」とは言えません。また、RSS のリンク切れは購読したい読者にとって具体的な問題ですが、検索インデックスに入っていないことの証拠にはなりません。

3. サイトマップは手がかりであり、登録証明書ではない

サイトマップが答えるのは、「サイトが発見してほしいと列挙した URL は何か」という問いです。谷米のサイトマップインデックスは一つの実際のサイトマップを含み、点検時には二記事もそこに載っていました。両言語には zh-CN と ja-JP の対応もあります。/sitemap-index.xml が 200 というだけで済ませず、XML の <loc> に対象 URL があることまで解析できます。

Google のサイトマップ文書では、提出はあくまでヒントです。Google がサイトマップをダウンロードすること、各 URL をクロールすること、インデックスへ登録することは保証されません。内部リンクも発見の経路です。新しい記事が孤立したファイルだけにあり、一覧やほかのページからリンクされていなければ、サイトマップがあるだけで訪問済みだとは推測できません。Google Search Central：サイトマップの作成と送信

今回の旧記事はサイトマップに載り、ブログのトップページからも最近の記事へリンクされています。この証拠は「デプロイ時にページが失われた」「サイトマップにまったく載らなかった」という可能性を狭めます。しかし、Google がいつサイトマップを読んだかは示しません。Google 側の処理を知るには、対象サイトの Search Console の報告が必要です。公開 XML と誰でも実行できるスクリプトには、その権限がありません。

4. 200、robots、noindex は別の問いに答える

robots.txt はクローラーにクロール可能な経路を伝えます。noindex はページの robots meta タグやレスポンスヘッダーに置けて、対応する検索エンジンにインデックス登録をしないよう伝えます。直感に反しやすい点は、最初に robots.txt でクロールを禁止すると、Google がページ内の noindex を見られない可能性があることです。そのため Disallow を確実な「インデックス禁止」のスイッチとして扱えません。Google Search Central：noindex

今回のツールは HTTP ステータス、X-Robots-Tag、ヘッダー内の robots と googlebot meta を確認します。二つのサンプルで noindex は見つからず、Python の robots パーサーも Googlebot からのアクセスを許可と判定しました。読者は URL を自分の記事に替え、直接の技術的な障害がないか調べられます。

ただし、Googlebot が自分のネットワークから実際に取得できた記録ではありません。サーバーはアクセス元、頻度、時刻、追加の規則によって異なる応答を返すことがあります。また、このスクリプトは元の HTML だけを読み、JavaScript の実行後の内容は見ません。「スクリプトでは正常、検索サービスではクロールエラー」という場合、キーワードを繰り返し変更する前に、Search Console の具体的なクロール結果とライブテストを見ます。

5. 二言語の記事を一つの代表 URL にまとめない

谷米では、一つのテーマに中国語と日本語の完全な本文があり、各言語に URL があります。点検前の HTML に canonical はなく、og:url はどちらもトップページを指していました。og:url は主として共有時のページの識別に関わります。トップページを指すのは確認できるテンプレートの誤りですが、そのために検索順位がどれだけ変化したかは推測できません。

今回は共通テンプレートから、各ページ自身の canonical URL を生成しました。中国語は中国語へ、日本語は日本語へ向け、og:url も現在の記事 URL に合わせます。日本語記事を中国語トップページや中国語記事へ一律に正規化するのではありません。Google は canonical を希望のシグナルと扱い、最終的には別の URL を選ぶこともあります。hreflang があるときは同じ言語の canonical を優先するようにも勧めています。Google Search Central：canonical URL の指定

サイトマップには、元からこの二記事を相互に指す言語版の注釈がありました。Google は HTML ヘッダー、HTTP レスポンスヘッダー、サイトマップでの言語版の指定を認めています。今回は単に「もう一か所増やす」ために、同じ hreflang の設定を HTML ヘッダーへ複製しません。二か所の対応関係が将来ずれるより、検証済みの一組を維持する方が分かりやすいからです。Google Search Central：言語別ページ

変更したコードはブログの共通テンプレートに集中しています。現在のパスから URL を作り、公開リンクを直す部分は次のとおりです。

const canonicalUrl = new URL(Astro.url.pathname, 'https://gumi.ink').href;

<meta property="og:url" content={canonicalUrl}>
<link rel="canonical" href={canonicalUrl}>
<link rel="sitemap" href="/sitemap-index.xml" type="application/xml">

404 を指す RSS の宣言は削除しました。実際の /feed.xml を作っていないのに、購読ソフトに存在すると知らせ続けるべきではありません。これは誤った宣言の修正で、新しい購読機能を作ったわけでも、クロール頻度を約束したわけでもありません。

6. 何を見れば「Google に登録済み」と言えるか

対象サイトの Search Console プロパティに権限があれば、URL 検査ツールに記事の完全な URL を入れ、Google が保持している版、クロール状況、Google が選んだ canonical URL を確認します。続いて「公開 URL をテスト」を使えば、現在のページにアクセスし解析できるかを調べられます。二つは異なる時点の情報です。インデックスの結果は保存済みの状態、ライブテストは今のページを対象とします。ライブテストが通っても登録は保証されません。Search Console：URL 検査ツール

今回はそのプロパティを参照していないため、「谷米は登録済み」とも「未登録」とも書けません。公開スクリプトは意図的に googleIndexStatus: unknown: Search Console not queried を出力します。テンプレートを修正し、再デプロイして公開ページを確かめても、既知の技術的な誤りを解消したところまでです。実際のインデックス状態は、権限のある報告で確認する必要があります。

もう一つの近道として、site:gumi.ink を検索する方法があります。Google 自身、インデックスにある URL でも特定の site: 検索結果に現れるとは限らないと説明しています。見つからなければ URL 検査ツールで詳しく調べます。一回の検索結果画面を完全なインデックス一覧と見なすと、「見えた現象を内部の状態と同一視する」誤りを繰り返します。Google Search Central：site: 演算子

ツールが登録済みと示していても、思い浮かべたキーワードで表示されるとは限りません。検索意図、記事のテーマ、言語、内容の質なども関わるため、もう一度 canonical を加えたり、サイトマップを送ったりするだけで改善を証明することはできません。今回の現場点検が扱うのは、直接検証できる公開情報までです。

7. 証拠に応じて次の作業を選ぶ

URL が 404 を返す、あるいはデプロイ後の本文が意図したものではないなら、ビルド、公開経路、サーバーから直します。ページが 200 でも、サイトマップから漏れ、内部の入口も見つからないなら、ルーティング、内部リンク、サイトマップの生成を確認します。Google の報告でクロールが妨げられているなら、robots、アクセス制御、レスポンス状態、具体的なエラーへ戻ります。クロールされたのに登録されていないなら、報告された理由に従い、重複ページ、canonical、本文の価値を検討します。単に発行頻度が足りないと決めつけません。

登録されていても、ほとんど読まれていないこともあります。その場合は具体的な検索語、入口となるページ、読者の行動を見て、記事が問題に明確に答えているかを考えます。「今日は訪問者が少ない」だけではクロールの失敗を逆算できません。また、技術的な信号がそろっても、内容が読者の役に立つとは限りません。調べる対象が変われば、対応も変える必要があります。

今回の再現用スクリプトは、同一オリジンの二つの HTTPS URL だけを対象とし、サイトマップのファイル数に上限があります。robots の判定には Python 標準ライブラリを使い、Google の実装は使っていません。ページの JavaScript も実行しません。公開後の巡回点検には役立ちますが、クローラーの再現器でも順位の検査器でもありません。修正前の失敗例と修正後の両言語ページは、スクリプトの出力から改めて調べられます。

最初の問いへの答えは簡潔でも、証拠の線引きが必要です。ページが開くことは、その時点の外部アクセスの成功を示す。サイトマップと指示が正しいことは、発見とクロールの手がかりを示す。登録されたかどうかは、検索エンジン自身の記録で確かめる。 この三つを報告で分ける方が、「SEO は正常」という一言より、次の修正に役立ちます。

外部の文書と公開サイトの確認日：2026 年 9 月 30 日。「修正前」のデータは当日のデプロイ前の外部リクエストによります。修正後の記述は今回のデプロイと再点検に基づきます。