サイトマップ未送信の表示は載せるべきURLかで判断する

Search Console（Googleが提供する、自分のサイトが検索でどう扱われているかを見る無料ツール）を開いたら、「インデックス登録済みですが、サイトマップに送信されていません」という長い一行が並んでいた。数字が数百件あって、何かをやり損ねた気がして手が止まった——この記事はそこで検索してきた方に向けたものです。

このとき現場でよく起きるのが、「表示された件数をゼロにしよう」と考えて、タグページも絞り込みページも含めた全URLをサイトマップ（サイト内のページ一覧を検索エンジンに渡すためのファイル）に流し込む対応です。ただ、Google公式ドキュメントを開いて突き合わせると、そこで語られているのは「全部載せる」ことではなく、サイトマップがどういう場面で役に立つファイルなのかという手前の話です。位置づけがずれたまま作業すると、本来やるべき「重要なページの載せ漏れを見つける」作業が、件数減らしに置き換わってしまいます。

この記事では、自社サイトを自分で良くしたい担当者の方に向けて、公式の記述からサイトマップの位置づけを引き直し、そのうえで「このURLは載せるべきか」を仕分ける6ステップを、実際のURLに1回通してみせます。読み終わったときに、いま画面に出ている一覧のうち手を動かすべき行がどれかを、自分で線引きできている状態を目指します。

公式が「サイトマップは必要か」について書いていること

まず、Googleの「サイトマップについて」というページには、必要性そのものを扱った節があります。

サイトの各ページが適切にリンクされていれば、Google は通常、サイトのほとんどのページを検出できます。

続けて、「適切にリンクされている」の中身も定義されています。

適切にリンクされているというのは、なんらかのナビゲーション（ページに配置したサイトのメニューやリンクなど）によって重要なすべてのページに移動できる状態を指します。

つまり公式が最初に置いている基準は、サイトマップに載っているかどうかではなく、メニューやリンクをたどって重要なページに行き着けるかどうかです。そのうえで、同じページはこう続けます。

サイトの各ページが適切にリンクされている場合でも、大規模なサイト、複雑なサイト、専門性の高いファイルのクロールを改善する手段としてサイトマップが役立ちます。

役立つ場面として名指しされているのが、大規模・複雑・専門性の高いファイルの3つです。クロールというのは、Googleのロボットがページを巡回して読み取る作業のことで、その巡回を良くする手段としてサイトマップが位置づけられています。

さらに、CMS（サイトを管理するシステム）を使っている場合の記述もあります。

WordPress、Wix、Blogger などの CMS を使用している場合は、CMS によって 検索エンジンが利用できるサイトマップがすでに用意されている ことが多く、その場合は何もする必要はありません。

「何もする必要はありません」と明記されているのは、ここで焦って自作の一覧を追加する前に読んでおきたい一文です。

なお、サイトマップというファイル自体の役割も同じページに書かれています。サイト上のページや動画などのファイルについての情報や、各ファイルの関係を伝えるファイルであり、検索エンジンはこれを読み込んでより効率的にクロールを行う。加えて、重要なファイルについての貴重な情報（ページの最終更新日やすべての代替言語ページなど）も提供する、という説明です。ここまで読むと、サイトマップは「登録の申請書」ではなく「巡回のための案内図」として書かれていることが分かります。

送信すれば載せた分だけ登録される、とは書かれていない

もうひとつ、件数をゼロにしに行く前に読んでおきたい記述があります。「サイトマップ レポートを使用してサイトマップを管理する」のページには、送信直後の挙動についてこう書かれています。

サイトマップがすぐに取得されます。ただし、サイトマップに記載された URL のクロールには時間がかかることがあります。また、サイトのサイズ、アクティビティ、トラフィックなどによっては、サイトマップ内のすべての URL がクロールされるとは限りません。

取得は早い。ただしそこに書いたURLの巡回には時間がかかることがあり、しかもサイズ・活動状況・訪問の多さによっては、載せた全URLが巡回されるとは限らない。同じページには、正常にクロールされたサイトマップについて、Googleが通常のサイトのクロールとは関係のないペースで定期的に再クロールする、という記述もあります。

この2点から言えるのは、URLを追加した直後に画面の表示が変わることを期待して待つのは、あまり実りのある待ち方ではなさそうだ、ということです。手を入れるなら、待って確かめる対象を絞っておいたほうが確認が楽になります。

レポートの数字をそのまま総数として読まない

もうひとつ、実務でつまずきやすいのが件数の読み方です。「ページ インデックス登録レポート」のヘルプには、問題ごとに表示されるURLの例リストについて、次のように書かれています。

このリストには必ずしもそのような問題がある URL がすべて表示されるわけではなく、行数は 1,000 に制限されています。

サイトマップ レポート側にも同様の制限があり、送信したリクエストをレポートに表示できる件数は最大で1,000件、それより多く送信はできるがレポートに表示できるのは1,000件まで、と書かれています。

つまり画面に並んでいる行は、その状態にあるURLの全部ではないことがあります。一覧を書き出して「これで全件そろった」と考えて突き合わせると、手元のリストに載らなかったURLが後から出てきて、二度手間になります。数百件のうち何件片づけたか、という進め方より、次に説明する仕分けのほうが再現性があります。

載せるべきURLかを決める6ステップ

ここからが手を動かす部分です。実際に3つのURLを通してみます。

• ケースA: example.com/service/pricing（料金ページ。問い合わせの手前にある主要ページ）
• ケースB: example.com/blog/tag/seo（タグの一覧ページ。記事へのリンクが並ぶだけのページ）
• ケースC: example.com/blog/2021-campaign-report（4年前のキャンペーン報告記事。いまも公開している）

1. そのURLを検索から入ってきてほしいページかどうか、先に決める。 画面の一覧を上から処理し始める前に、この設問を通します。ケースAは「ほしい」、ケースBは「記事本体に来てほしいので、一覧そのものは不要」、ケースCは「古いが、内容は今も間違っていないので入口として残す」。ここを決めずに件数を減らしにいくと、Bのようなページまで載せることになります。
2. メニューやリンクからそのページに行き着けるかを、実際にたどって確かめる。 公式が「適切にリンクされている」の定義として挙げているのが、まさにこのナビゲーションからの到達性です。トップページから、人が押せるリンクだけを使って目的のページまで行けるかを試します。ケースAは共通ヘッダーにあり2クリック。ケースCは記事一覧の6ページ目にあり、たどり着くまでに5回ページ送りが必要でした。ここで詰まったページは、サイトマップに書き足すより先に内部リンクを見直したほうが効きます。
3. 手順1で「ほしい」としたページだけを、いまのサイトマップと突き合わせる。 サイトマップのURL（多くの場合 example.com/sitemap.xml などの形）をブラウザで直接開き、対象のURLが本文中にあるかをページ内検索で探します。ケースAは記載あり。ケースCは記載がなく、CMSの設定で古い年の記事を出力対象から外していたことが分かりました。この「載っていないほう」がこの作業の収穫です。
4. CMSの出力設定を確認してから、手で足すかどうかを決める。 公式にはCMSがサイトマップを用意していることが多いと書かれているので、まず疑うのは自作の一覧ではなくCMS側の設定です。ケースCは出力対象の条件を変えるだけで済みました。ここで別ファイルを手作りして追加すると、CMSが出す一覧と二重管理になります。
5. 送信済みのサイトマップURLが、いま見ているファイルと同じかを確かめる。 公式には、レポートに表示されるサイトマップURLについて「サイトマップ送信時に指定された正確な URL。リダイレクトは行われません」「このレポートまたは API を使用して送信したサイトマップのみがここに表示されます」と書かれています。過去に送ったURLと、いまCMSが出しているファイルのURLが違っていると、手順3で見ていたファイルと、Googleに渡っているファイルが別物ということが起こります。文字列として一致しているかを目で確かめてください。
6. 確認するURLを1〜2本に絞って、URL検査ツールで様子を見る。 すべてを追いかけると確認が終わらないので、ケースCのように今回手を入れたURLだけを対象にします。次の節で扱います。

ケースBを「載せない」と決められたことが、この6ステップの実利です。件数を減らす作業として進めていたら、記事本体に来てほしいはずのタグ一覧まで、案内図に書き込む対象として扱うことになっていました。

判定表

手順1と2の答えを組み合わせた早見表です。判定の軸は「検索から入ってきてほしいか」の一列に集約されます。

表の右列に「何もしない」が2行あるのが要点です。画面の一覧に出ているURLの多くは、この2行に落ちます。

URL検査ツールでできること・できないこと

手順6で使うURL検査ツールについては、ヘルプに範囲がはっきり書かれています。まず、対象にできるURLの制限です。

現在のプロパティ内の URL を指定する必要があります。

自分が所有していないプロパティのURLをテストしたい場合は、リッチリザルト テストやAMPテストなどの非所有者向けテストを使うように案内されています。競合サイトを同じ方法で調べることはできない、ということです。

次に、結果の読み方です。ライブテスト（その場でページを取得して調べる機能）については、次のように書かれています。

よい結果が出たからといって検索結果への掲載は保証されませんが、URL のクロールと解析は可能です。

さらに、ライブテストではインデックス登録の条件をすべて網羅するわけではなく、手動による対策、コンテンツの削除、品質やセキュリティの問題、URLの一時的なブロックはいずれも考慮されない、とも書かれています。ツールが緑になったことを到達点にしないための注意書きです。

そして、実際に手を入れたあとの選択肢について、ヘルプにはこう書かれています。

必要なアクション: ページがインデックスに登録されたバージョンと異なる場合は、レポートの [ インデックス登録をリクエスト ] をクリックするとインデックス登録がリクエストできます。また、 サイトマップを送信 するか、クロールされるのを待つという方法もあります。

リクエスト、サイトマップの送信、待つ。この3つが並記されています。どれかが必ず速いという書き方ではないので、送信したうえで待つ、という進め方で十分だと考えてよさそうです。手動のリクエストを繰り返すことについては、インデックス登録リクエストを何度も送っても速くならない理由で別途整理しています。

もうひとつ、混同しやすい表示の違いも明記されています。URL検査の「クロールを許可？」という項目について、ページへのクロール（アクセス）を許可するか、robots.txtルールでブロックするかを示すものであり、「インデックス登録を許可？」が示すインデックス登録への許可とは異なると書かれています。見つけてよいかと、登録してよいかは別の欄です。今回の話も同じ構造で、どの経路で見つかったかと、登録できているかは別の軸として読むと混乱しません。

よくある誤解: 表示が消えることをゴールにしてしまう

最後に、この件で最もよく起きる回り道に触れておきます。一覧の件数が減ることを成果として扱うと、判定表の右列で「何もしない」に落ちるURLまで作業対象になります。そして手順4を飛ばして自作のファイルを足すと、CMSが出すサイトマップと二重に管理することになり、次に誰かが記事を増やしたときに片方だけ更新されます。

参考までに、インデックス登録レポート側には「修正を検証」という機能があり、そのヘルプには検証処理について「この処理には数日以上かかることがあります」と書かれています。確認が数日単位の作業である以上、対象を絞っておくほど楽になります。件数ではなく、手順1で「ほしい」と決めたページが載っているか、という数本の確認に置き換えてください。

公開前・作業後のチェックリスト

• 手順1の「検索から入ってきてほしいか」を、URLごとに書き出して決めた
• 「不要」と決めたURLをサイトマップに足していない
• 追加したURLは、自作ファイルではなくCMSの出力設定から出るようにした
• 送信済みのサイトマップURLと、いま開いているファイルのURLが文字列として一致している
• 確認対象を1〜2本に絞り、URL検査ツールで様子を見る予定を決めた
• レポートの一覧を「全件」として扱っていない（例のリストは1,000行までと明記されています）

サイトマップに載っているかどうかは、あくまで見つけてもらう経路の話です。載せる価値のあるページを決める作業のほうが、画面の件数より先にあります。同じ考え方で、そもそも登録されないページの切り分けについては新規ページがインデックスされない原因の切り分け方を、巡回の頻度そのものを気にしたくなったときはクロールバジェットは小中規模サイトで気にすべきかを合わせて読んでみてください。