実践ログ|サイト運用

Claude Codeでサイトマップ108本を一括点検した記録

「記事を足しているのに順位が上がらない」という状態が続いたとき、本文を疑う前に確認すべきことがありました。そもそもクロールされていたのかです。Claude Codeで運用中の全サイトのサイトマップ状態を一括取得したところ、108本のうち26本が30日以上ダウンロードされておらず、最長で169日放置されていました。その調査と修正の記録です。

このサイトは Anthropic や Claude の公式サイトではありません。実践ログでは、認証情報・サーバー構成・非公開の運用情報は伏せ、一般化した作業内容と考え方のみを掲載しています。

きっかけ:1サイトの不調が、実は全体の問題だった

ある1サイトで「クロールが数か月止まっている」ことに気づいたのが発端です。個別の事故だと思って直そうとしたのですが、「同じことが他でも起きていないか」を確かめないまま個別対応するのは筋が悪いと考え直し、全サイトを一括で調べることにしました。

この判断が正解でした。結果は次の通りです。

状態件数
登録済みサイトマップ108本
30日以上ダウンロードされていない26本
最長の放置期間169日

そして重要な点として、クロール停止は表示回数の多寡と無関係に起きていました。「調子の良いサイトだから大丈夫」ではありませんでした。これは1サイトずつ画面を見ていたら絶対に気づけない種類の発見です。

やったこと:状態を一覧化するスクリプトを書かせる

Claude Codeに頼んだのは、要するに次の2つです。

  1. 一覧化──全プロパティのサイトマップについて、最終ダウンロード日・登録URL数・エラー件数を取得して表にする。そのうえで「一度もダウンロードされていない/N日以上ダウンロードされていない/未登録/エラーあり」に層別する
  2. 一括再送信──引っかかったものをまとめて再送信する。ただし別の担当が触っているサイトは除外し、明らかな誤登録も対象から外す

どちらも数分で用意できます。大事なのはスクリプトの中身ではなく、「全件を機械的に確認する」という発想に切り替えたことでした。人間は無意識に標本を見て全体を判断しますが、この種の不調は分布がばらばらなので標本では見つかりません。

見つかった「壊れた登録」5パターン

再送信で直るものばかりではありませんでした。そもそも登録内容が壊れているものが複数あり、分類すると次の5つです。

パターン症状対処
拡張子のタイプミスsitemap.xnl のような打ち間違いで登録され、当然404登録を削除して正しいURLで再登録
ファイル名の複数形sitemaps.xml と複数形で登録されていた同上
存在しない拡張子sitemap.html が登録されていた削除
301するサイトマップドメイン移転で転送されるURLを登録したまま。転送されるサイトマップは永久にエラーのまま登録を削除し、移転先で登録し直す
RSSフィードの誤登録WordPressの /feed/ をサイトマップとして登録。500日以上放置されていた削除

いずれも「登録した時に一度も確認していない」ことが共通の原因です。登録操作は成功したように見えるので、そのまま忘れられます。

いちばん厄介だった罠:ファイルを直しても配信内容が変わらない

これが今回いちばんの学びでした。あるサイトでサイトマップのXMLが壊れていたので修正したのですが、いくら直しても配信される内容が変わりません。

原因は、サーバー設定の書き換えルールによってまったく別のファイル(PHPで動的に生成しているもの)が配信されていたことでした。FTPで見えている静的なファイルは、もう誰も参照していない置物だったのです。同じ構造のサイトが他にも複数ありました。

さらにそのPHP側にも不具合がありました。PHPのシングルクォート内に改行のエスケープを書いていたため、リテラルの文字がそのまま出力されてXMLが壊れていたのです。これは静的ファイルを眺めていても永久に分かりません。

そこで手順に固定したのが次の一手間です。

触る前に「HTTPで取得した内容」と「サーバー上のファイル」を突き合わせる。一致しなければ、サーバー設定を読む。

Claude Codeなら「この2つを比較して」で終わるので、コストはほぼゼロです。同じ発想で、修正後の確認も必ずHTTPで実測しています(FTP経由でサイトを編集した記録)。

再送信は副作用がない、と分かったことの意味

作業前に確認したのは「再送信して悪影響はないか」でした。結論として、再送信は同じURLをもう一度送るだけなので副作用はありません。登録が二重になったり、評価が下がったりはしません。

これが分かると判断が軽くなります。「怪しいものは全部送り直す」で構わないので、1本ずつ慎重に見極める必要がなくなりました。効果の判定も単純で、最終ダウンロード日が動いたかどうかを後日見るだけです。

教訓:本文を触る前に、届いているかを確認する

この作業を通して、順位が上がらないときの手順を変えました。

  1. まずクロールが生きているか確認する──サイトマップの最終ダウンロード日を見る。止まっていれば、何を書いても届きません
  2. 次にインデックスされているか確認する──クロールされていても登録されていないことがあります
  3. そのうえで内容を見る──ここで初めて本文・タイトル・狙う語の話になります

順番を逆にすると、届いていない記事を書き直し続けることになります。「書けば届く」という前提そのものを、最初に検算すべきでした。この考え方は、検索データそのものを疑った分析の記録とも通じています。

FAQ

サイトマップの状態はどこで確認できますか?

Search Consoleのサイトマップ画面で、最終読み込み日とエラー件数が確認できます。サイト数が多い場合は画面を1つずつ見るのが現実的でないため、APIでまとめて取得する方法を採りました(その記録)。

クロールが止まる原因は何ですか?

今回の調査では、登録内容の不備(404・転送・誤登録)が多数を占めました。それ以外にサイト側の更新頻度や評価も影響しますが、まず機械的に潰せる原因から確認するのが順番として妥当です。

再送信すればすぐ再クロールされますか?

すぐとは限りません。効果は最終ダウンロード日が更新されたかで後日確認します。数日から数週間の幅を見ておくのが現実的です。

プログラミングができなくても同じことができますか?

今回こちらが書いたコードは1行もありません。「全部のサイトマップの状態を一覧にして」と頼むだけです。ただし出てきた結果を疑って検算する姿勢は必要です。