サイトマップに載せるURL・載せないURLの判定基準
sitemap.xml には、公開しているページを一通り載せてある。それでも、載せたURLの数と、実際に検索結果へ出ているページの数はいつまでも噛み合わない。
基準は一行です。Googleのドキュメントは「検索結果に出したいURLをサイトマップに含めなさい」と書き、続けて「それは正規URLです」と補足しています。正規URL(canonical URL)とは、重複・類似する複数ページのなかで、検索結果に代表として表示させたい標準のURLのこと。裏返すと、検索結果に出す気のないURLは載せない。全ページの網羅は基準ではありません。
基準は「検索結果に出したい正規URL」だけ
サイトマップを作る行為は、公式の言い方では「どのURLを検索結果に出してほしいかを検索エンジンに伝えること」です。同じ内容が複数のURLで見られる場合についても、「好きな1つを選び、同じ内容に行き着くすべてのURLではなく、その1つをサイトマップに入れる」と明記されています。
ここから、載せるかどうかの判断は次の4つに分解できます。
| 基準 | 問い | 外れるとどうなるか |
|---|---|---|
| 検索価値 | このURLを検索結果に出したいか | 出したくないURLを載せると、伝える内容と実際の設定が食い違う |
| 正規性 | このURLは、その内容の代表(正規URL)か | 代表にしたいURLへ寄せる手がかりが1つ減る |
| 応答 | いま200を返しているか | 消したページや転送されるページを勧めていることになる |
| 遮断 | robots.txtやnoindexで塞いでいないか | 出したくないと宣言したURLを、同時に出してほしいと送ることになる |
4つのうち1つでも満たさないURLは、サイトマップから外す側です。順に、具体的なURLの形に当てはめます。
載せないURLの4類型
1. 並び替え・絞り込み・パラメータ付きのURL
一覧ページの ?sort=price や ?color=beige のような派生URLは、たいてい代表ページと同じ内容にたどり着きます。公式が言う「1つを選んで、その1つだけを入れる」の対象がまさにこれです。
ここで一番やりがちな事故は、サイトマップとHTMLの指定が食い違うことです。公式は正規化の注意点として、「同じページに対して、サイトマップで1つのURLを、rel="canonical" で別のURLを指定するな」と名指しで書いています。サイトマップ側だけ自動生成のまま放置していると、この食い違いが静かに積み上がります。
2. リダイレクトするURL
転送元の古いURLは載せません。理由は効き目の差です。公式は正規URLを決める手がかりを並べたうえで、rel="canonical" の指定を「強いシグナル」、サイトマップへの掲載を「含まれたURLが正規になるのを助ける弱いシグナル」と書き分けています。
転送元を載せても、弱い方の手がかりを1つ足すだけです。転送先だけを載せれば、サイトマップと転送が同じURLを指します。
3. 削除して404・410を返すURL
外す理由は、最初の基準そのものです。検索結果に出したいURLではないからです。エラー表示が出るかどうかは関係がありません。
キャンペーン終了ページのように、意図して消したURLが生成ロジックに残り続けている例はよくあります。公開フラグだけでサイトマップを組み立てていると、DBに行が残っている限り出力されてしまう。
4. noindexやrobots.txtで塞いでいるURL
購入完了ページ、会員専用画面、検索結果ページ。これらは検索結果に出さない設定を入れているはずで、サイトマップに載せる対象ではありません。
robots.txtで塞いだURLについては、公式の記述もあります。Search Consoleのサイトマップレポートは「サイトマップに、robots.txtでブロックされたURLが含まれています」というエラーを返します。Googleがサイトマップ自体、あるいはそこに載っているURLの内容にアクセスできない、という意味です。
なお、robots.txtで正規化をしようとするのも公式が止めている手です。「正規化の目的でrobots.txtを使わないでください」「robots.txtで拒否されたURLでも、内容なしでインデックスされることがあります」と書かれています。塞ぐのと、代表を決めるのは別の作業です。
実例: アパレルECの5URLを仕分ける
抽象的な基準は、1回通してみないと自分のサイトに移せません。商品ページを持つECサイトのサイトマップに、次の5つが並んでいたとします。
| URL | 検索価値 | 正規性 | 応答 | 遮断 | 判定 |
|---|---|---|---|---|---|
/items/knit-cardigan-navy | あり | 正規 | 200 | なし | 載せる |
/items/knit-cardigan-navy?color=beige | あり | 非正規 | 200 | なし | 外す |
/search?category=knit&sort=price | 薄い | 非正規 | 200 | なし | 外す |
/cart/complete | なし | 正規 | 200 | noindex | 外す |
/items/linen-shirt-ss | 終了 | 転送元 | 301 | なし | 外す |
1行目は素直な合格です。残る4行が、それぞれ別の理由で落ちています。
2行目の色違いは、内容がほぼ同じで、rel="canonical" は代表商品を指しているはず。ここで2つとも載せると、さきほどの「サイトマップとcanonicalの食い違い」そのものになります。3行目の絞り込み結果は、組み合わせの数だけURLが増えるのが本質的な問題です。検索価値のある組み合わせが本当にあるなら、それは独立したページとして作り、そのURLだけを載せる判断になります。
4行目の購入完了ページは、検索価値の欄で即座に落ちます。noindexを入れているなら、サイトマップに載せるのは自分の設定と矛盾した宣言です。5行目の販売終了商品は、301で代表商品に転送している時点で、載せるべきURLは転送先の方です。
落ちた4行のうち3行は、生成ロジックが「公開中のレコードを全部出す」になっていれば自動的に混入します。手で消しても、次のデプロイで戻ってきます。
自社のサイトマップを点検する手順
いま出力されているXMLを、実際に突き合わせます。
- サイトマップを取得して、
<loc>の中身だけをURLの一覧にする。curl -s https://www.example.com/sitemap.xml | grep -o '<loc>[^<]*' | sed 's|<loc>||'で十分です。サイトマップインデックスなら、子サイトマップごとに同じことをします。 - 各URLの最終ステータスコードを取る。
curl -o /dev/null -s -w '%{http_code} %{url_effective}\n' -L <URL>を一覧に対して回します。200以外が出た行は、それだけで外す候補です。転送があった場合はurl_effectiveが転送先を示すので、載せ替え先もここで分かります。 - 各URLのHTMLから
rel="canonical"の値を抜き、そのURL自身を指しているかを見る。自分以外を指していれば非正規なので、サイトマップからはその指し先に置き換えます。 <meta name="robots">とレスポンスヘッダーのX-Robots-Tagにnoindexが無いかを見る。ここで引っかかるURLは、サイトマップと設定のどちらが正しいのかを先に決める必要があります。- Search Consoleのサイトマップレポートで「検出されたページ」の数を確認する。これはサイトマップから読み取られたページURLの数で、サイトマップインデックスの場合は子サイトマップすべての合計です。手元で数えたURL数と大きく違うなら、読み取りの段階でつまずいています。
- 1〜4で出た除外対象を、手作業ではなく生成ロジックに戻す。公開フラグだけでなく、canonicalの出力値とnoindexの有無を条件に組み込みます。
この6つを一度通すと、たいていは「生成ロジックが1種類のフラグしか見ていない」という一点に収束します。
上限と置き場所でつまずく箇所
URLの中身が正しくても、ファイルの側で落ちることがあります。
- サイズと件数の上限: どの形式でも、1つのサイトマップは非圧縮で50MBまで、URLは50,000件までです。超えるなら分割し、まとめ役のサイトマップインデックスファイルを送ります。
- 絶対URL: サイトマップのURLは、プロトコルから書いた完全修飾の絶対URLにします。公式は「Googleは記載されたとおりに正確にクロールしようとする」と書いていて、
/mypage.htmlのような相対URLは避けるよう例示しています。 - 置き場所より上の階層: サイトマップレポートの「URLが許可されていません」は、サイトマップファイルより上の階層や別ドメインのURLが含まれている状態です。サイトルートに置けば、この問題はほぼ起きません。
- サイトマップ自身のURL: Search Consoleに送信したサイトマップのURLについて、公式は「リダイレクトは追わない」と明記しています。サイトマップの置き場所を変えたときは、転送でつなぐのではなく、新しいURLを送り直します。
「載せればインデックスされる」は成り立たない
件数を増やす方向に走る前に、効き目の天井を確認しておく価値があります。公式の記述はかなりはっきりしています。サイトマップはサイト上のURLの発見を助けるが、サイトマップ内のすべての項目がクロールされインデックスされることを保証するものではない、と。
サイトマップが必要かどうかの目安も同じ考え方です。公式は「小規模なサイト(およそ500ページ以下)で、内部リンクが行き届いているならサイトマップは必要ないかもしれない」としたうえで、その500ページの数え方について「検索結果に出す必要があると考えるページだけが、この合計に数えられる」と書いています。
数えるときも、載せるときも、基準は同じ一行です。
点検チェックリスト
| 確認項目 | 合っている状態 | ずれているときの直し方 |
|---|---|---|
| 載せる範囲 | 検索結果に出したいページだけ | 完了画面・会員画面・絞り込み結果を生成条件から外す |
| 正規性 | 各URLのcanonicalが自分自身を指す | canonicalの指し先URLに載せ替える |
| canonicalとの整合 | サイトマップとcanonicalが同じURLを指す | 生成ロジックにcanonicalの出力値を読ませる |
| ステータス | すべて200 | 301は転送先に置換、404・410は削除 |
| 遮断設定 | noindex・robots.txtでの拒否なし | 出したいページなら遮断を外し、そうでなければ載せない |
| ファイル | 50MB・50,000件以内、絶対URL、ルート配置 | 分割してサイトマップインデックスを送信 |
サイトマップの点検は、一度やって終わりにはなりません。商品の入れ替えやキャンペーンの終了のたびに、外すべきURLが増えるからです。生成条件を直すところまでやって、ようやく手が離れます。
インデックス登録レポートで「送信されたURLにnoindexマークが追加されています」が出ている場合は、noindexの出どころを突き止める手順が近道です。「ページにリダイレクトがあります」の扱いは放置してよい場合との切り分けに、「インデックス登録済み、サイトマップに送信していません」の判断は載せるべきURLかで判断する手順にまとめています。
出典
