WEBサイトサイトマップのpriorityとchangefreqはGoogleに使われず、lastmodは正確なときだけ使われる ── 自社のサイトマップの各項目を確認する14項目（2026年10月時点）
サイトマップのpriorityとchangefreqはGoogleに使われず、lastmodは正確なときだけ使われる ── 自社のサイトマップの各項目を確認する14項目（2026年10月時点）
目次
01 何が起きたか — Googleの担当者が、サイトマップの項目ごとの扱いをポッドキャストで語った
2026年10月1日公開の第114話「Do sitemaps still matter?」
Googleの検索の担当チーム（Search Relations）は、ポッドキャスト「Search Off the Record」を配信している。第114話の題は「Do sitemaps still matter?」（訳: サイトマップはまだ重要か）で、配信ページには「Oct 1, 2026」（訳: 2026年10月1日）と書かれている。2026年10月12日にこのページと、書き起こしのPDFを開いて確かめた。
話したのは、Martin Splitt氏とJohn Mueller氏の2人である。題材はサイトマップの歴史、XMLとRSSの違い、HTMLのサイトマップ、llms.txt、Search Consoleの「取得できませんでした」まで広い。この記事は、そのうちサイトマップの項目ごとの扱いと、自社のサイトマップを数えて確かめる手順に絞ってまとめる。
一次情報
配信ページの要約と、公式の書き起こし（PDF）を読んで書いた。書き起こしは話し言葉なので、引用した英文は書き起こしの文のままで、日本語訳は筆者による。音声そのものは聞いていない。文書の側の根拠には、Googleの「Build and Submit a Sitemap」（最終更新2026年7月8日 UTC）を使った。
02 なぜ・背景 — 「サイトマップはまだ要るのか」という問いが、2026年にも出る理由
始まりは、20年ほど前の、3社の取り決め
Mueller氏によると、サイトマップは、当時のMicrosoftとYahooに案を見せ、3社が合意した準標準として広まった。本人は、サイトを巡回してURLの一覧を作るソフトを作ったことが縁でGoogleに入った。年数は「this must be like 20-ish years」（訳: たぶん20年ほどになる）と概算である。
priorityは、全部が最優先になって役に立たなくなった
サイトマップには、かつてpriorityという欄があった。持ち主に「各ページの優先度は」と聞けば、答えはどのページも最優先になる、という趣旨である。次のように話している。
"Every URL is a maximum priority. It ended up not being very useful."
（訳: どのURLも最高の優先度になった。結局、あまり役に立たなかった。）
サイトマッププロトコルは、priorityを0.0から1.0（既定は0.5）の、サイト内のURLの間の相対値と書く。全部を高くすれば差が消える。
changefreqは、動的なサイトでは常に「新しい」になる
もう1つの欄が、更新頻度を示すchangefreqである。Mueller氏は、SEOの担当者は「always fresh」（訳: いつも新しい）と書きがちで、サーバー側で動くページは実行のたびに新しく出力されるので、理屈の上では正しく、実際には役に立たない、と整理している。
残ったのは、URLと日付の2つ
この2つの欄を、どうしたのか。話の中の言い方は、次のとおりである。
"I think those were the two fields that we dropped."
（訳: その2つの欄が、私たちが外したものだと思う。）
"Basically, what we primarily focus on is the URL and the date, the change date."
（訳: 基本的に、私たちが主に見るのは、URLと日付、つまり変更日である。）
「I think」（訳: 思う）と前置きがあるように、これは担当者個人の説明である。Googleの文書の側は、もっとはっきり書いている。「Google ignores <priority> and <changefreq> values.」（訳: Googleはpriorityとchangefreqの値を無視する）。話と文書が同じ向きを示しているので、この2つは、Googleの検索向けには、書いても効かないと読める。
03 用語 — lastmod・サイトマップ・クロール需要を、先に分けておく
lastmod（最終更新日）
サイトマップの各URLに付ける、ページの最終更新日である。W3C Datetimeという形式で、2026-10-12のように日付だけでも、時刻まで入れても書ける。sitemaps.orgのプロトコルは、この日付の意味を次のように書いている。
"Note that the date must be set to the date the linked page was last modified, not when the sitemap is generated."
（訳: この日付は、リンク先のページが最後に更新された日に設定すること。サイトマップを生成した日ではない。）
用語
lastmodは「last modified」の略である。ここで日付が合うのは、ページの内容を最後に変えた日であり、サイトマップのファイルを作り直した日ではない。自動生成のサイトマップが、生成のたびに全URLへ今日の日付を入れると、この意味から外れる。
priorityとchangefreq
priorityは、サイト内での優先度（0.0〜1.0）、changefreqは、更新頻度の見込みである。プロトコルは、changefreqを「a hint and not a command」（訳: 命令ではなくヒント）と書く。
サイトマップインデックス
サイトマップを複数に分けたとき、束ねるファイルがサイトマップインデックスである。Googleの文書は、1つのサイトマップは50MB（圧縮前）か50,000 URLまで、と書く。分割は、当サイトの記事「サイトマップには「50,000 URL・50MB」という上限がある ── 分割とインデックス化を確認する13項目（2026年9月時点）」で扱った。この記事は、1つのファイルの中の項目の扱いを対象にする。
ホストの負荷とクロール需要
「取得できませんでした」の説明に出る、2つの言葉である。ホストの負荷（host load）は、Googleがそのサイトに対して、どれだけ巡回できるかの量を指す。クロール需要（crawl demand）は、Googleの側が、そのサイトをどれだけ巡回したいかの強さである。後者は、サイトの質の見え方に左右される、と話の中で説明されている。詳しくは04章で扱う。
04 型別 — 項目ごと・仕組みごとに、Googleがどう扱うかを分けて読む
4つの項目を、表で並べる
最初に、4つの項目の扱いを、Googleの文書と、第114話での説明で並べる。「自社で確かめること」の欄が、05章のチェックリストにつながる。
| 項目 | Googleの文書での扱い | 第114話での説明 | 自社で確かめること |
|---|---|---|---|
| loc | 絶対URLを書く。検索結果に出したいURLを入れる | 正規にしたいURLを入れる | 載っているURLが200で返り、正規が自分自身か |
| lastmod | 一貫して確かめられる形で正確なときに使う | 日付が妥当に見えれば考慮に入れる | ページの実際の更新日と合っているか |
| priority | 無視する | 外した欄の1つ | 付いている件数を数える |
| changefreq | 無視する | 外した欄の1つ | 付いている件数を数える |
lastmodは「正確で、確かめられる」ときに使われる
Googleの文書は、lastmodの扱いを次のように書いている。
"Google uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate."
（訳: Googleは、lastmodの値を、一貫して、かつ確かめられる形（たとえばページの最終更新と比べる）で正確なときに使う。）
第114話の説明も、同じ方向である。Mueller氏は、まず「My understanding is we want to use it, but a lot of sites get it wrong.」（訳: 私の理解では、使いたいが、多くのサイトが間違えている。）と話している。続けて、日付が妥当に見えれば考慮に入れ、見えなければ、個々のURLの側を重くみる、と話した。
"My understanding is that if we can tell that within a sitemap file the dates are kind of reasonable, then we will try to take that into account."
（訳: 私の理解では、サイトマップのファイルの中の日付がおおむね妥当だと判断できれば、それを考慮に入れようとする。）
"Whereas if we can't tell that the dates are reasonable, then we will focus more on the individual URLs."
（訳: 一方、日付が妥当だと判断できなければ、個々のURLの側により注目する。）
日付が妥当と見えないと不利益を受ける、と読むのは誤りで、次の節で担当者が否定している。
全URLを「今日」にすると、日付の重みが下がる
よくある失敗が、サイトマップを作るたびに、全URLのlastmodを今日の日付にすることである。Mueller氏は、そのときの扱いを次のように話している。
"If you basically give us today as a change date for all of your URLs, we will realize that it doesn't make much sense to focus on that."
（訳: すべてのURLの変更日として今日を渡すと、そこに注目しても意味がないと私たちは気づく。）
"But this is not like a spam thing where our spam systems would say this is a bad site."
（訳: ただし、これは、スパム対策の仕組みが「悪いサイトだ」と判定するようなことではない。）
つまり、全部を今日にしても、罰を受けるのではなく、日付が参考にされなくなる。日付が参考にされないだけなら、巡回の優先を、自分の日付で伝える手段が1つ減る、という損である。
「更新」に数えるもの、数えないもの
何を更新と呼ぶかは、Googleの文書が具体的に書いている。
"The <lastmod> value should reflect the date and time of the last significant update to the page. For example, 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."
（訳: lastmodの値は、ページの最後の重要な更新の日時を反映するべきである。たとえば、主要なコンテンツ、構造化データ、ページ上のリンクの更新は、一般に重要と見なされるが、著作権の日付の更新はそうではない。）
本文・構造化データ・リンクの更新は日付を動かしてよく、フッターの著作権の年の書き換えは動かさない、という線引きである。共通のテンプレートを1回直したら全ページの日付が動いた、という作りのサイトでは、この線引きに合っているかを、確かめる価値がある。
サイトマップに入れるURLは、正規にしたいもの
第114話の中で、Mueller氏は、サイトマップに入れるURLについて、次のように話している。
"In the sitemap file, the idea is that you include the URLs that you want to be canonical."
（訳: サイトマップのファイルでは、正規にしたいURLを入れる、という考え方である。）
Googleの正規化の文書も、サイトマップに含めることを「A weak signal」（訳: 弱いシグナル）と位置づけている。文書の原文は「Sitemap inclusion: A weak signal that helps the URLs that are included in a sitemap become canonical.」（訳: サイトマップへの掲載: サイトマップに含まれるURLが正規になるのを助ける、弱いシグナル。）である。転送や、canonicalのリンク注釈より弱い。パラメータ付きの計測用URLを入れると、自分で入れた弱いシグナルが、正規にしたくないURLを指す。正規の扱いは、当サイトの記事「canonicalタグは『ヒント』であって『命令』ではない ── Search Consoleで、Googleが選んだ正規URLを自分のサイトで確認する15項目（2026年9月時点）」で、Search Consoleでの確かめ方を整理している。
この話が測っていないこと
第114話は、数字を使った調査ではない。担当者が経験を話したもので、「my understanding」（訳: 私の理解では）という前置きが多い。次のことは、話からも文書からも分からない。
- 日付が「妥当」と判断される基準の、数値の線。そして、妥当と判断されたとき、巡回の頻度や順番がどれだけ変わるか。
- priorityとchangefreqを、Google以外の検索エンジンが、どう扱うか。サイトマッププロトコルは、この2つを「ヒント」と書くが、各社の今の扱いは、今回確かめていない。
RSSをサイトマップとして送る
RSSの扱いについて、Mueller氏は、次のように話している。
"So, in a sense, an RSS file can be used as a sitemap file. You can also submit it in Search Console as a sitemap."
（訳: だから、ある意味で、RSSのファイルは、サイトマップのファイルとして使える。Search Consoleにサイトマップとして送ることもできる。）
Googleの文書も、同じ内容を書いている。「If your CMS generates an RSS or Atom feed, you can submit the feed's URL as a sitemap.」（訳: CMSがRSSかAtomのフィードを生成するなら、そのフィードのURLをサイトマップとして送れる。）。続けて、注意も書いている。
"Most CMSes create a feed for you, however keep in mind that this feed only provides information on recent URLs."
（訳: ほとんどのCMSはフィードを作ってくれるが、このフィードが教えるのは、最近のURLの情報だけだと覚えておくこと。）
XMLのサイトマップが「全体の地図」なら、RSSは「最近の更新の一覧」である。サイトマップが1,000ファイルに分かれる規模でも、RSSなら、最近変わった50ページだけを先に見つけられる、という例で説明されている。
HTMLのサイトマップは、XMLの代わりにならない
HTMLのサイトマップについては、次のように話している。
"It's not something that replaces an XML sitemap file."
（訳: それは、XMLのサイトマップのファイルを置き換えるものではない。）
HTMLのサイトマップは、人のための地図で、巡回の側から見れば、普通のリンクの集まりである。通販サイトなら、商品1つずつではなく、カテゴリだけを並べる、という例が挙がっている。
llms.txtは、検索のサイトマップとしては使えない
llms.txtについて、Mueller氏の見立ては慎重である。
"I think the hope is bigger than the reality, but maybe that will change at some point."
（訳: 期待のほうが現実より大きいと思うが、いつか変わるかもしれない。）
さらに、実務の向け方として、次のように話した。
"I would not rely on it. I would not treat that as a priority."
（訳: それに頼らない。優先事項としては扱わない。）
当サイトでは、llms.txtを置いた後の測定を、記事「llms.txt を置いて51日、正直に答え合わせ第2弾 ── Google が『効かない』と言った以上に、他の AI も読みに来ていなかった」などで記録している。置いても効くとは限らない、という、実際に測った結果の話である。
「取得できませんでした」は、技術の問題とは限らない
Search Consoleのサイトマップのレポートに「取得できませんでした」と出ることがある。Martin氏の質問は、サイトマップのXMLが正しく、公開されていて、robots.txtにも書いてあるのに、なぜ出るのか、だった。Mueller氏は、主な理由は2つだと答えている。1つ目は、巡回の負荷の側の理由で、他の巡回で手一杯なので、サイトマップを取る時間がない場合である。2つ目は、クロール需要の側の理由である。
"And the crawl demand is very often based on the perceived quality of a website."
（訳: そして、クロール需要は、多くの場合、サイトの質がどう見えるかに基づく。）
Search Consoleのヘルプにも理由の一覧がある。robots.txtで塞いでいる、手動の対策が出ている、URLが間違っている、サーバーの一時的な不具合、そして「There is low crawl demand for the sitemap.」（訳: サイトマップへのクロール需要が低い。）である。
レポートの見方に迷うときは、当サイトの無料ツール🔧 Google Search Console お助け。もうちょっと詳しく知りたいよツールが、Search Consoleの画面の読み方の手がかりになる。
注意
「取得できませんでした」が出たとき、まず確かめるのは、robots.txtで塞いでいないか、URLが正しいか、手動の対策が出ていないかの3つである。3つとも問題がなければ、一時的な負荷か、クロール需要が理由の可能性がある。後者は、サイトマップのファイルを直しても、すぐには変わらない。
05 自分のサイトで確認するチェックリスト
下の14項目は、1項目5分ほどでできる作業である。サイトマップのファイルを開く項目3〜5を先に済ませると、あとの数字が決まる。チェックの状態は、ブラウザの中にだけ保存される。
- 第114話の配信ページを開き、公開日の表示（Oct 1, 2026）と、書き起こしPDFへのリンクがあることをメモに書き写す
- Googleの文書「Build and Submit a Sitemap」を開き、末尾の「Last updated」の日付を書き、「Google ignores <priority> and <changefreq> values.」の行が今もあるかを「ある」「ない」で書く
- 自社のサイトマップのXMLをブラウザで開き、<url>の数を数えて書く（ブラウザのページ内検索に「<loc>」と入れて、件数を読む）
- 同じファイルで、「<priority>」「<changefreq>」「<lastmod>」を1つずつ検索し、件数を3つ並べて書く
- lastmodの日付を上から30件ほど目で追い、同じ日付が何件並ぶかを数えて、いちばん多い日付と件数を書く
- サイトマップから5ページを選んで開き、各ページの更新日（本文の表示か、構造化データのdateModified）とlastmodを並べて、一致した数を「5件中◯件」で書く
- フッターの著作権の年や、サイドバーだけを直す作業の手順を確認し、その作業でlastmodが動く設定かどうかを、設定画面か担当者への質問で調べて「動く」「動かない」「分からない」で書く
- サイトマップのURLから10件を選んでcurlで開き、ステータスコードが200で、canonicalが自分自身を指すかを「10件中◯件」で書く
- サイトマップの中で、「?」を含むURLと、日付や識別子を足した別のURLが混ざっていないか、「?」で検索して件数を書く
- robots.txtを開き、「Sitemap:」の行の数と、そのURLがcurlで200を返すかを書く
- Search Consoleの「サイトマップ」レポートを開き、送ったサイトマップの状態（成功・エラーあり・取得できませんでした）を1つずつ書き出す
- 状態が「取得できませんでした」のサイトマップを1つ選び、URL検査でライブテストを実行して、「クロールを許可？」と「ページの取得」の2つの欄を書き写す（該当がなければ「該当なし」と書く）
- RSSかAtomのフィードのURLを書き、いちばん新しい項目の日付を書き、トップページのHTMLの<head>に、フィードを案内する<link>の行があるかを「ある」「ない」で書く
- HTMLのサイトマップのページがあれば開き、リンクの数と、XMLのサイトマップに無いURLが上位10件に混ざっているかを書く（llms.txtを置いているなら、サイトマップとして送っていないことも、Search Consoleの一覧で確かめて書く）
06 代替・他の選択肢 — 送る手段を、サイトの形で選ぶ
手段は、重ねて使える
XMLのサイトマップ、RSSかAtomのフィード、テキストのサイトマップ、そしてHTMLのサイトマップは、どれか1つだけを選ぶものではない。役割が違うので、重ねられる。Googleの文書は、サイトマップの形式として、XML、RSSかAtom、テキストの3つを挙げている。HTMLのサイトマップは、その3つには入っていない。
| 手段 | 役割 | 向く場面 | 注意 |
|---|---|---|---|
| XMLサイトマップ | 全URLを決まった形で知らせる | 記事や商品が多い、新しいサイト | 1ファイル50,000 URLか50MBまで |
| RSS・Atom | 直近の更新の一覧 | 更新の多いブログやニュース | 最近のURLの情報だけ |
| テキストのサイトマップ | URLを1行ずつ並べる | 日付などの情報が要らないとき | HTMLなどの検索できるページだけ |
| HTMLのサイトマップ | 人向けの地図 | 利用者が迷うとき | XMLの代わりにならない |
| llms.txt | AI向けの案内ファイル | CMSが自動で作るとき | 頼らない、優先しない |
作り直す場面では、当サイトの無料ツール🔧 WEBサイトの sitemap.xml 作成ツールで、locとlastmodだけの最小の形を作って、いまのファイルと見比べられる。
小さなサイトは、サイトマップが無くても見つかる
小さなサイトにサイトマップは要るか、という問いも出た。Mueller氏は、小さなサイトは普通に巡回で見つけられるので要らないだろう、と話し、ただし境界は決めにくいので、勧めは「入れておく」だった。
"There's no harm in having a sitemap file if your site is small."
（訳: サイトが小さくても、サイトマップのファイルがあって困ることはない。）
Googleの文書は、数字で線を引いている。「By small, we mean about 500 pages or fewer on your site.」（訳: ここで小さいとは、サイトのページが約500以下のことである。）。ただし、数えるのは検索結果に出したいページだけで、内部のリンクがしっかりしていること、動画や画像やニュースが少ないことも、条件に挙がっている。
07 当サイトで確かめたこと
1ファイル・360件で、priorityとchangefreqは全件に付いていた
当サイトのサイトマップを、2026年10月12日の午後5時台に取得して、タグごとに数えた。ファイルは1つで、urlset（サイトマップインデックスではない）、65,645バイト、URLは360件である。上限の50,000 URLに対して、ずっと少ない。
| タグ | 件数 | 内訳・読み方 |
|---|---|---|
| <loc> | 360件 | URLの総数 |
| <lastmod> | 356件 | 付かない4件は、一覧ページ（ツール・AI Ron のブログ・運営者ブログ・解説記事のトップ）。日付の種類は43通り |
| <priority> | 360件 | 0.7が175件、0.8が163件、0.9が16件、ほか6件 |
| <changefreq> | 360件 | monthlyが180件、weeklyが176件、dailyとyearlyが各2件 |
priorityとchangefreqは、360件のすべてに付いている。Googleの文書の「無視する」を読む限り、付いていても外れていても、Googleの扱いは変わらない。他の検索エンジンの扱いは確かめていない。今回は、外すかどうかは決めていない。
lastmodは、同じ日付の集まりが目立つ
lastmodは356件で、日付の種類は43通りだった。いちばん多い2026年8月19日が88件、次の2026年9月10日が47件ある。同じ日付が並ぶ理由は、1ページずつは確かめていない。ただし、全URLが同じ日付の形ではなく、43通りに分かれている。
抜き出した24件のうち、21件でページの更新日と一致した
lastmodが付いた356件から、15件おきに24件を抜き出し、各ページを開いて、構造化データのdateModifiedを読んだ。24件のうち、dateModifiedを持つのは21件で、その21件はすべて、サイトマップのlastmodと同じ日付だった。残る3件（トップページとツール2本）はdateModifiedを持たず、照らせなかった。
注意
照らしたのは、ページが自分で出している更新日と、サイトマップの日付である。本文が実際にその日に変わったかは、確かめていない。2つが同じ元の記録から作られているなら、一致は当然で、日付の正確さの証明にはならない。
RSSは1本が動いていて、案内のlinkは見つからなかった
AI Ron のブログ（/ai_ron/）のRSSは、200で返り、種類はapplication/rss+xmlで、項目は10件、いちばん新しい日付は2026年10月11日だった。運営者ブログ（/blog/）のRSSも200で返り、項目は10件で、いちばん新しい日付は2025年8月2日だった。一方、トップページと AI Ron のブログの一覧のHTMLを取得してalternateのlinkを探したが、どちらにも見つからなかった。第114話では、RSSは普通HTMLのheadからリンクされる、と話されている。ここは案内が足りない可能性がある。RSSをSearch Consoleに送っているかは、確かめていない。
HTMLのサイトマップとrobots.txt
HTMLのサイトマップのページ（/sitemap）は200で返り、リンクは380本あまり（共通のヘッダーなどを含む）あった。このページ自体も、XMLのサイトマップに載っている。robots.txtの「Sitemap:」の行は1行で、XMLのサイトマップを指している。
測っていないこと
Search Consoleの「サイトマップ」レポートの状態は、開いて確かめていない。24件は15件おきの機械的な抜き出しで、ツールのページは2本しか入っていない。priorityとchangefreqを外した場合の、Google以外の検索エンジンの反応は、測っていない。
08 このテーマの、これまで
サイトマップの項目の扱いの、これまでの流れ
約20年前に3社が準標準として合意し、priorityとchangefreqを含む形が広まった。やがて全部が最優先、全部が「いつも新しい」になって役に立たなくなり、Googleの文書は今、2つを無視すると書く。2026年10月1日の第114話は、その整理を、lastmodの扱いとあわせて担当者が話したものである。lastmodは「使いたいが、多くのサイトが間違える」という、期待と現実の間にある。
公式の文書の、最終更新日
- Build and Submit a Sitemap（訳: サイトマップの作成と送信）: 最終更新2026年7月8日 UTC。priorityとchangefreqを無視する、と書かれている文書
- What Is a Sitemap（訳: サイトマップとは）: 最終更新2025年12月10日 UTC。500ページ以下を小さなサイトとする目安が書かれている
- How to Specify a Canonical（訳: 正規URLの指定の仕方）: 最終更新2026年7月10日 UTC。サイトマップを弱いシグナルとして位置づけている
当サイトの、これまでの記事
- サイトマップには「50,000 URL・50MB」という上限がある ── 分割とインデックス化を確認する13項目（2026年9月時点） — 上限と、分割の仕方
- sitemap に書いた URL が Google から見えていなかった日 — 末尾スラッシュの落とし穴と1分検証 — サイトマップのURLが見えなかった日の、検証の記録
- 出力は在った。だから誰も測らなかった ── datePublished・og:type・用語ハイライト・sitemapで見つけた4つの「値だけ違う」穴 — sitemapの日付の穴を見つけた記録
現在の貴方のIPアドレス
このサイトで書いている人
