サイトマップに載せたURLが、canonical で「登録しないで」と言っていた

01 / 本文

2万字あるのにインデックスされない

サーチコンソールに Discovered - currently not indexed が46件。サイトマップに載せているのは49URLで、インデックスされているのはトップページだけだった。

各ページには19,000〜20,000字の中身がある。薄いページではない。

02 / 本文

同じサイトが、同じURLについて正反対のことを言っていた

サイトマップの全URLを取得して、ステータス・本文量・canonical を並べた。47件すべてで canonical が自分自身ではなく、クエリを外した親ページを指していた。

サイトマップは「このURLを登録してほしい」という依頼。canonical は「このURLは登録しないでほしい」という宣言。同じサイトが、同じURLについて正反対のことを言っていた。

Googleは canonical のほうを信じる。結果、1件が重複として処理され、残り46件は取りに来ることすらしなくなった。

robots.txt も見たら、Sitemap の行が example.com を含む雛形のままだった。存在しないドメインを案内していた。

03 / 本文

リポジトリでは直っていた

テンプレートはクエリを含んだ自己canonicalを作るコードになっていたし、robots.txt も正しいドメインを指していた。コミットの日付は1か月半前だった。

本番に届いていないだけだった。

自動デプロイが失敗し続けていた。手動実行して確かめると、鍵は受理されたあとサーバー側から接続を切られていた。認証エラーではないので、ログを流し読みすると「鍵が悪い」と誤読しやすい。

そして「ローカルから手で流している」という運用は、忘れた瞬間に実行されなくなる。1か月半、誰も実行していなかった。

04 / 本文

「直した」と「届いた」は別のことだ

コミットは直した記録であって、本番の状態ではない。手動デプロイの運用は、忘れた瞬間に「直したはずのバグ」を生む。しかもコードを見ると直っているので、調査でいちばん最後に疑う場所になる。

確認するなら、リポジトリではなく本番を取得する。robots.txt を curl で叩く。canonical を grep する。

example.com が本番に出ていたのは、誰も本番の robots.txt を開いたことがなかったということでもある。