sitemap作成：4つの項目とGoogleが無視する2つ

sitemap作成に必要なのは、検索結果に出したいURLを絶対URLで並べたUTF-8の1ファイルを、サイトのルートに置くことです。人がよく埋める4つの項目のうち2つはGoogleに無視されます。ファイルは何かをインデックスさせるものではありません。何が存在するか、そして1つの項目を正直に書くなら、いつ変わったかを伝えるものです。

最初に作るのは「載せたいページの一覧」です。サイトの全ページ一覧ではありません。絞り込み一覧、タグのアーカイブ、ページ送りの重複、サンクスページは外します。sitemapは意図の宣言であり、他のシグナルと実ページが照合されます。

すでにシステムがsitemapを出しているなら、2つ目を作らないでください。まず既存のものを読みます。この章の大半は構築ではなく確認になります。

4つの項目のうち2つが無駄な理由

XMLのsitemap形式はURLごとに4つの要素を許します。2026年8月24日に読んだGoogleのsitemapドキュメントは、その半分を1文で片づけています。「Google ignores <priority> and <changefreq> values.」

2行目の条件が要点です。これは好みではなく条件です。Googleは「uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate」としています。さらに何が該当するかを定義しています。「an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not」。

毎晩すべてのURLに今日の日付を入れるテンプレートは、鮮度のシグナルを送っていません。ページと照合すれば嘘だと分かる項目を、すべてのURLで、毎晩送っています。私たちはその頻度を測りました。24サイト中13サイトはlastmodで何も伝えていない（英語）。

Bingも同じ判断を自分について書いています。これで2つの検索エンジンが記録に残りました。「Optional sitemap tags like changefreq and priority are ignored by Bing and do not influence how your content is crawled or ranked」（Keeping content discoverable with sitemaps in AI-powered search、2025年7月31日公開、2026年9月9日閲覧）。2026年9月9日に読んだ168,434件のURLエントリでは、24件のsitemapのうち7件がまだchangefreqを持ち、17件はどちらの項目も持っていませんでした。7件のうち4件はファイルの97%以上に同じ値を入れており、判断ではなく生成器の初期値の形です。

sitemapは検索エンジンが検証できる自社サイトについての主張です。いい加減に埋めた項目は、その検証に失敗する主張です。

sitemap作成の5ステップ

小さなサイトなら手作業で20分ほどです。後からプラグインに任せるとしても、一度は手でやる価値があります。手でやると、想定していなかったURLが見えてきます。

1. 検索結果に出したいURLを絶対アドレスで並べます。Googleは「Google will attempt to crawl your URLs exactly as listed.」と明記しています。相対パスでは足りません。
2. アドレスごとに<url>ブロックを書き、<loc>と、正直に作れるなら<lastmod>を入れます。ほかのXMLと同じく、アンパサンドなどはエスケープします。
3. UTF-8で保存し、サイトのルートに置きます。場所は重要です。「unless you submit your sitemap through Search Console, a sitemap affects only descendants of the parent directory」。
4. robots.txtにSitemap:行を書き、Search Consoleでも送信します。2つの経路は独立していて、どちらも安価です。
5. 上限で分割します。1つのsitemapは「50MB (uncompressed) or 50,000 URLs」までです。どちらかを超えたら分割し、sitemapインデックスを送信します。

手順4には大きなサイトでの副次的な利点があります。複数のsitemapを分けて送ると、Search Consoleでグループごとのカバレッジを読めます。あるセクションは索引され、別のセクションはされていない、という状態が見つかります。

成果物：2つのファイルと1つの数え方

最小のsitemapです。形式はこれで全部です。この2行以外に正しく書くヘッダーはありません。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/foo.html</loc>
    <lastmod>2026-08-24</lastmod>
  </url>
</urlset>

上限を超えたとき、またはセクション別のレポートが欲しいときのsitemapインデックスです。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap-blog.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap-products.xml</loc>
  </sitemap>
</sitemapindex>

そしてデプロイ後に走らせる価値のある数え方です。実際に何件のURLを主張しているか、ファイルが上限に近いかが分かります。

curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*' | sed 's/<loc>//' | tee /tmp/sitemap-urls.txt | wc -l

# バイト数（50MBの上限に対して）
curl -s https://example.com/sitemap.xml | wc -c

# 200を返さないURL
while read -r u; do
  printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$u")" "$u"
done < /tmp/sitemap-urls.txt | grep -v '^200'

壊れるところと見分け方

リダイレクトするURLが載っている

症状：Search Consoleが「リダイレクトされたページ」を、サイトのあるセクションと同じ数だけ報告します。原因：URL変更の前にファイルが生成された。上の3つ目のコマンドで一度に見つかります。

sitemapとcanonicalが食い違う

Googleのcanonicalizationガイドはまさにそれを避けるよう書いています。「specify one URL in a sitemap, but a different URL for that same page using rel="canonical"」をしてはいけません。sitemapへの掲載は弱いcanonicalizationシグナルなので、矛盾が勝つことは通常ありません。ただシグナルを無駄にします。

モバイル用とデスクトップ用のURLが両方載る

ページに2つのアドレスがある場合、Googleはsitemapには1つだけ載せることを勧めています。注記なしで両方載せるのは、あなたがすでに知っていることを検索エンジンに決めさせる行為です。

ファイルはあるが、誰も指していない

誰にも知らされていないsitemapは、慣習でしか見つかりません。robots.txtの1行は安いものです。宣言とその開示状況は想像以上にばらつく（英語）ことが分かっています。

sitemapにできないこと

ページをインデックスさせることはできません。発見可能にするだけであり、それはもっと弱い主張です。自分のリンクで発見できるページには何の足しにもなりません。内部リンクが整理された小さなサイトでは、現実的な価値は差分を取れる一覧であって、流入源ではありません。

ブロックされたページ、壊れたページ、意図的に除外したページを救うこともできません。リダイレクト、404、noindexを返すURLを載せても、どれも上書きされません。Search ConsoleのURL数がファイルの数と一致し、発見されたページが意図したものになったら止めます。その先の状態はありません。

次の段階は、何かが変わったと検索エンジンに伝えることです。別の仕組みで、別の失敗の仕方があります。ページをより早くインデックスさせる方法を参照してください。クロールから引用までの連鎖をまとめたいなら、診断の流れはここから始まります。

よくある質問

sitemapは必須ですか

小さなサイトで、すべてのページが自分のリンクから到達できるなら必須ではありません。サイトが大きくなったとき、ページのリンクが弱いとき、セクション別のカバレッジを見たいときに役立ちます。作成費用はほぼゼロなので、実際には「はい」、原則としては「いいえ」です。

ファイルはどこに置きますか

ルートです。Search Consoleから送信しない限り、sitemapは「affects only descendants of the parent directory」だからです。/blog/sitemap.xmlのファイルは/products/について語れません。

RSSフィードをsitemapにできますか

できます。GoogleはRSS 2.0とAtom 1.0のフィードをsitemapとして受け付けます。ただしフィードは「only provides information on recent URLs」です。鮮度の経路としては良く、在庫一覧としては不十分です。

1つのsitemapに何件のURLを入れられますか

50,000件、または非圧縮50MBの早いほうです。超えたらファイルを分け、sitemapインデックスを送信します。ほとんどのサイトは遠く、到達するサイトは数え方ではなく検証エラーで気づきます。