XMLサイトマップとRSSフィードの違いと使い分け
「RSSフィードもサイトマップとして送信できる」と知って、Search Console の送信欄にフィードのURLを足そうとしている。その操作自体は公式に認められたやり方です。ただ、そこで期待している効果は、たぶんドキュメントに書かれていることとずれています。
先に答えを書きます。Google のドキュメントがフィードについて述べているのは、速さではありません。「このフィードで提供されるのは最近の URL に関する情報のみです」——載る範囲の話です。フィードは XML サイトマップの高速版ではありません。持っている情報の幅が違うファイルです。
だから使い分けの軸は「どちらが速いか」ではなく、「サイト全体を伝えたいのか、直近の分だけを伝えたいのか」になります。判定は、自分のサイトのファイルを2つ数えれば数分で終わります。
公式が書いているのは「速さ」ではなく「範囲」
まず、XMLサイトマップ（検索エンジン向けの、サイト内URLの一覧ファイル）の側から確認します。
Google 検索セントラルの「サイトマップの概要」は、検索エンジンがこのファイルを読み込んでより効率的にクロールを行うと説明しています。クロールとは、検索エンジンの巡回プログラムがページを見て回ることです。そのうえで、サイトマップは重要なページとファイルを伝えるだけでなく、ページの最終更新日やすべての代替言語ページといった情報も提供すると書かれています。動画・画像・ニュースについては、それぞれ専用のエントリで追加情報を渡せます。
一方のフィードはどうか。「サイトマップの作成と送信」には、こうあります。
RSS フィードや Atom フィードが生成される場合、そのフィードの URL をサイトマップとして送信できます。ほとんどの CMS でフィードが作成されますが、このフィードで提供されるのは最近の URL に関する情報のみです。
ここが分かれ目です。送信できる、とは書いてある。速くなる、とは書いていない。書いてあるのは「最近の URL に関する情報のみ」という制限です。
形式の受け入れ範囲も明示されています。Google は RSS 2.0 と Atom 1.0 のフィードを受け入れており、動画については mRSS（media RSS）フィードで詳細情報を渡せます。
つまり、両者は上位互換の関係にありません。役割が違います。
その前に「そもそも要るのか」を確かめる
送信の話に入る前に、飛ばされがちな確認があります。作る必要があるのか、という確認です。
「サイトマップの概要」は、WordPress、Wix、Blogger などの CMS を使っている場合、CMS によって検索エンジンが利用できるサイトマップがすでに用意されていることが多く、その場合は何もする必要はないと述べています。フィードも同様で、ほとんどの CMS が自動的に作ります。手で用意しようとしている人の多くは、実はもう持っています。
必要になる場面も挙げられています。
- サイトのサイズが大きい。大きなサイトでは、すべてのページが他のページから最低1ページ以上リンクされている状態を保つのが難しくなります。その結果、Googlebot が新規ページの一部を検出できない可能性が高くなります。
- サイトが新しく、外部からのリンクが少ない。クローラーは以前クロールしたページにある URL をたどって巡回するため、他サイトからのリンクがないページは検出されないことがあります。
逆に、同じページには小規模（500ページ未満）でよくリンクされており、メディアやニュースのコンテンツを持たないサイトなら、サイトマップは必要ないかもしれない、という趣旨の記述もあります。
ここまでで判断が一つ決まります。CMS が既にサイトマップとフィードを出しているなら、次の作業は「新しく作ること」ではありません。何が載っているかを見ることです。
実測：2つのファイルが何を持っているか数える
役割の違いは、説明を読むより自分のサイトで数えたほうが早く腹に落ちます。ターミナルで完結する6ステップです。
- サイトマップのURLを特定する。
curl -s https://example.com/robots.txt | grep -i sitemapを実行し、Sitemap:行を確認します。行がなければ/sitemap.xml/sitemap_index.xmlを直接叩きます。 - フィードのURLを特定する。トップページのHTMLから
curl -s https://example.com/ | grep -o '<link[^>]*application/\(rss\|atom\)+xml[^>]*>'で拾えます。CMS標準なら/feed/rss/atom.xmlのいずれかです。 - サイトマップ側の件数を数える。
curl -s https://example.com/sitemap.xml | grep -c '<loc>'。返ってきたのがサイトマップインデックス（複数のサイトマップをまとめたファイル）なら、子のファイルごとに同じことをします。 - フィード側の件数を数える。RSS 2.0 なら
grep -c '<item>'、Atom 1.0 ならgrep -c '<entry>'です。 - フィード側の最も古い日付を見る。
<pubDate>または<updated>の並びの末尾を確認します。ここがフィードの「射程」です。 - 2つの件数と日付を並べて判断する。件数比と、フィードが何日前まで遡れるかを書き出します。
記事120本のオウンドメディアで実際に通すと、たとえばこうなります。手順3のサイトマップは134件。手順4のフィードは10件。手順5の最古の pubDate は3週間前。——このサイトのフィードは、直近3週間・10本分しか語っていません。残り124件は、サイトマップにしか存在しない。
この数字が出た時点で、「どちらを主にするか」は考えるまでもありません。網羅を担うのは XML サイトマップです。フィードはその横で、直近の更新だけを別経路で伝える補助になります。
数え方に一つ注意があります。手順3で <loc> が0件だったとき、それは壊れているとは限りません。サイトマップインデックスだと <loc> は子ファイルのURLを指すので、階層を一段降りる必要があります。ここを飛ばすと「サイトマップが空だ」と誤診します。
形式ごとの向き不向き
公式ドキュメントは、形式ごとの長所と短所も並べています。手順6で出した数字を、この表に当てはめてください。
| 形式 | 長所 | 短所 | 向く場面 |
|---|---|---|---|
| XML サイトマップ | サポートされている形式の中で最も用途が広い。ローカライズ版・画像・動画・ニュースの情報を追加できる | 自動生成の仕組みがないと自前で管理する必要がある | サイト全体の網羅を伝えたいとき（既定の選択） |
| RSS / mRSS / Atom 1.0 | ほとんどの CMS で自動生成される。動画に関する Google 向け情報を提供できる | インデックス登録可能なテキストコンテンツのほかに提供できるのは動画の情報のみで、画像やニュースの情報は渡せない。扱いが面倒な場合がある | 直近の更新を、手間をかけずに伝えたいとき |
| テキストサイトマップ | 最もシンプルな形式 | 登録できるものが限られる | URL一覧だけを最小構成で渡したいとき |
表の一段目は、さきほどの134件がまさにここに入ります。二段目の「画像やニュースの情報は渡せない」は、画像検索を意識しているサイトほど効いてきます。フィードだけに寄せると、その情報経路がまるごと落ちます。三段目は、CMS を使わない静的サイトで出番があります。
そして、どれか一つを選ばなければならない決まりはありません。サイトマップやサイトマップインデックスファイルは Google に複数送信できます。複数に分けておくと、Search Console で個々のサイトマップの検索パフォーマンスをトラッキングする場合に便利だ、とも書かれています。フィードを追加で送るなら、この「分けて送ると個別に追える」利点のほうが、速度より現実的な理由になります。
送る前に落ちやすい4点
送信そのものは数クリックです。つまずくのは、その手前のファイルの条件です。
| 確認項目 | 公式の条件 | 見落とすとどうなるか |
|---|---|---|
| 置き場所 | Search Console でサイトマップを送信しない限り、サイトマップが伝えるのは親ディレクトリから下の階層のみ。サイトのルートへの配置が推奨されている | 深い階層に置いたまま送信もしていないと、対象範囲がその階層より下に限られる |
| エンコード | サイトマップファイルは UTF-8 でエンコードされている必要がある | 日本語を含むURLやタイトルで読み込みに失敗することがある |
| サイズ上限 | どの形式でも、1つのサイトマップにつき未圧縮50MB・URL 50,000件が上限 | 超えた場合は、分割するか、サイトマップインデックスファイルを作ってインデックスのみを送信する必要がある |
| エスケープ | 他のXMLファイルと同様、すべてのタグ値をエスケープする必要がある | & や < を含むURL・タイトルでファイルが壊れる |
一つめは、CMS 任せにしていれば普通はルートに出ます。自前で /assets/ などに置いた場合だけ気にしてください。四つめは、クエリ付きURL（?a=1&b=2）を手書きで並べたときに踏みます。
上限の行は、ほとんどのサイトで無縁に見えます。それでも、確かめるときは記事の本数を思い浮かべないでください。数えるのは、ファイルに実際に並んでいる件数です。手順3で出した <loc> の数が、その値にあたります。
「送ったのに増えない」の読み方
ここまでを踏まえると、送信後によくある2つの引っかかりは、どちらも想定内の挙動として説明がつきます。
一つめ。フィードを追加送信したのに、検出されたURLの数が思ったほど増えない。フィードで提供されるのは最近のURLに関する情報のみなので、そこに載る件数は、さきほどの実測でいえば10件でした。サイトマップ側の134件と並べたとき、増分が小さく見えるのは自然です。件数の一致を成功の指標にしないでください。
二つめ。送ったURLがインデックスに登録されない。これは公式が明示的に線を引いています。サイトマップによって検索エンジンはURLを検出できますが、必ずしもサイトマップ内のすべての項目がクロールされてインデックスに登録されることが保証されるわけではありません。それでもほとんどの場合、サイトマップを提供することで有益な結果が得られる、とも続きます。
送信は「見つけてもらうための材料を渡す作業」です。登録の確約ではありません。ここを取り違えると、フィードを何度も送り直す時間の使い方になります。
公開前チェックリスト
自分のサイトで、上から順に当てはめてください。
- CMS が既にサイトマップとフィードを出していないか確認した（出ているなら新規作成は不要）
- 手順1〜2で、サイトマップとフィードのURLを両方特定した
- 手順3〜5で、件数と、フィードが遡れる日付を数字で書き出した
- 網羅の担当を XML サイトマップに置き、フィードを補助と位置づけた
- 置き場所・UTF-8・50MB/50,000件・エスケープの4点を確認した
- 画像やニュースの情報を渡したいなら、その経路がフィード側に無いことを踏まえて XML 側に持たせた
- 件数の一致や増加を成功指標にしない、と決めた
4番と7番が、この記事の実質です。残りは事故を避けるための確認です。
フィードを送るかどうかで迷っていた時間は、たいてい数字を見れば数分で終わります。まず数える。話はそのあとです。
サイトマップまわりでは、lastmodをいつ更新するか、検出されたURLが0件になるとき、フィードURL自体がインデックスされないときも、あわせて確認しておくと判断が速くなります。
出典