サイトマップのlastmod・priority・changefreqは必要？3つのうちGoogleが使うのはlastmodだけ、リライト後の日付の扱い

プラグインの設定画面やサイトマップの中身を見て、priority や changefreq という欄に気づいたことはありませんか。大事な記事は priority を 1.0 にしたほうがいいのか、changefreq を daily にすればよく見に来てもらえるのか、リライトのたびに lastmod を新しくすべきなのか。気になり出すと、触っていいのかも分からなくなります。

この記事は、サイトマップの3つのタグをどう扱えばいいか迷っている個人ブロガーに向けて書いています。読み終えたときには、Googleが3つのタグのどれを使い、どれを使わないのか、リライトの後に日付をどう扱えばいいか、自分のサイトマップの日付が正しいかをどう確かめるかが分かるはずです。Googleの公式ドキュメントと公式ブログ、Search Consoleのヘルプ、サイトマップの仕様を定めた sitemaps.org のプロトコルは、2026年10月10日に日本語版と英語版の原文で確かめました。

そもそも個人ブログにサイトマップが要るのかは、サイトマップは必要か・robots.txtの書き方、個人ブログは無くても困りにくいに書きました。この記事は、サイトマップの中に書くタグの話だけを扱います。

結論:Googleが使うのはlastmodだけ。priorityとchangefreqは無視される

サイトマップの作成と送信(Google 検索セントラル)と2023年の公式ブログの記述と、そこから私が決めている扱いをまとめると、次の4つです。

• priority と changefreq は、Googleが無視する。1.0 にしても daily にしても、Google検索では何も変わりません
• lastmod は、正確だと確かめられる場合に使われる。使い道は、すでに見つけているURLをいつクロールし直すかの手がかりです
• lastmod に入れるのは「最後の重要な更新」の日付。本文・構造化データ・リンクの変更は入り、著作権の年やサイドバー・フッターの小さな変更は入りません
• リライトでは、本文や構造化データなど、ページの中身を直したときだけ日付を変える。何も変えずに日付だけ新しくし続けると、いずれ最終更新日を信用されなくなります

3つのタグは、もともと何を書く欄か

サイトマップの書き方は、sitemaps.org のプロトコルで決められています。Googleのドキュメントも、おすすめの方法はこのプロトコルで定義されている、と書いています。3つのタグはどれも省略できる(オプション)タグで、1つのURLにつき次のように書きます。

<url>
  <loc>https://example.com/blog/kiji/</loc>
  <lastmod>2026-10-10</lastmod>
  <changefreq>monthly</changefreq>
  <priority>0.8</priority>
</url>

プロトコル自体も、priority について、ページに付けた優先度が検索結果の掲載順位に影響する可能性は低い、全部のURLを高くしても役に立つ可能性は低い、と英語版で書いています。もともと「順位を上げる欄」として作られたものではありません。

priorityとchangefreqは、Googleが「無視する」と書いている

公式ドキュメントの1行

サイトマップの作成と送信の「XML サイトマップに関するその他の注意事項」に、次の1行があります。

Google は、<priority> と <changefreq> の値を無視します。
— Google 検索セントラル「サイトマップの作成と送信」

英語版も "Google ignores <priority> and <changefreq> values." で、条件は付いていません。

2023年の公式ブログが書いている理由

Google 検索セントラルのブログサイトマップの ping エンドポイントのサポート終了について(2023年6月26日)は、終わりの節で2つのタグに触れています。

Google は、まだ changefreq 要素や priority 要素をまったく使用していません。
— Google 検索セントラル ブログ「サイトマップの ping エンドポイントのサポート終了について」

英語版は "Google still doesn't use the changefreq or priority elements at all." です。続けて、changefreq は考え方として lastmod と重なっていること、priority はかなり主観的な欄で、社内の調査ではサイト内のほかのページと比べた実際の重要度を正しく表していないことが多い、と理由が書かれています。全部の記事を 1.0 にしたくなる気持ちを考えると、うなずける理由です。

消さなくてもいいし、整えなくてもいい

無視される値なので、プラグインが自動で入れている priority や changefreq を、わざわざ消す必要はありません。記事ごとに 1.0 と 0.5 を付け分ける手間も、Google検索のためには要りません。このブログのサイトマップにも2つのタグは入っていますが、記事ごとの付け分けはしていません。Google以外の検索エンジンがこの2つをどう扱うかは、今回は確かめていません。

lastmodは「正確だと確かめられる場合」に使われる

使われる条件

同じ注意事項に、lastmod の扱いが書かれています。

Google は、<lastmod> 値が一貫して正確であることを（ページの最終更新との比較などにより）検証できる場合に、この値を使用します。
— Google 検索セントラル「サイトマップの作成と送信」

英語版は "Google uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate." です。書いてあれば使われるのではなく、ページの実際の変更と比べて、ずっと正確だと確かめられたときに使われる、という条件付きです。

使い道は、クロールし直す時期の手がかり

2023年の公式ブログは、lastmod が今では多くの場合に役立っていて、「以前に検出した URL のクロールをスケジュールするためのシグナルとして使用されています。」と書いています(英語版は "a signal for scheduling crawls to URLs that we previously discovered")。すでに知っている記事を、いつ見に行き直すかを決める手がかりです。lastmod を新しくすると順位が上がる、という話は、私が読んだ2つの文書のどちらにも書かれていませんでした。

事実と違う日付を出し続けると、信用されなくなる

同じブログは、lastmod が役に立つ条件として、事実と一致していることを挙げています。

ページが 7 年前に変更されているのに、lastmod 要素で前日に変更したと伝えていては、ページの最終更新日に関して信用が得られなくなります。
— Google 検索セントラル ブログ「サイトマップの ping エンドポイントのサポート終了について」

英語版は "eventually we're not going to believe you anymore when it comes to the last modified date of your pages." で、「いずれは(eventually)」信じなくなる、という言い方です。1回まちがえたら終わり、ではなく、ずれ続けると使われなくなる、と読むのが近いと思います。そうなれば、本当に直した記事の日付まで手がかりにされなくなるおそれがあります。

「重要な更新」に入るもの・入らないもの

サイトマップの作成と送信は「<lastmod> 値は、ページに対する最後の重要な更新の日時を反映する必要があります。」と書き、例を挙げています。2023年のブログも「Google のいう「最終更新」は、実際には「最終の重要な更新」を意味しています。」と書き、同じ方向の例を足しています。2つを並べるとこうなります。

ブログはさらに、lastmod は全部のページに付けても、自信のあるページだけに付けてもよい、と書いています。ホームやカテゴリのように、ほかのページを集めて並べているだけのページは、サイトの仕組みによっては最終更新日を決めにくいので、lastmod を外してかまわない、という例も挙がっています。

リライトでは、ページの中身を直したときだけ日付を変える

個人ブログでは、lastmod を手で書くことはまずありません。たいていはCMSやプラグインが、記事の更新日時からサイトマップを作ります。このブログも、記事の一覧に持たせた更新日を、そのまま lastmod に出しています。つまり、lastmod を正しく保つというのは、記事の更新日を、本文や構造化データなど、ページの中身を直したときだけ動かすということです。

表示する更新日をどこまで直したら変えるかは、リライトしたら更新日は変える？公開日は動かさない理由と線引きに線引きの表を置きました。そちらでは、関連記事への案内を足しただけなら更新日を動かさない、としています。上の表のとおり、サイトマップの作成と送信はリンクの変更も一般に重要な更新に入れていて、2023年のブログは「一部のリンクを更新した場合は、lastmod 値を更新してください。」とまで書いているので、ここはGoogleの例と食い違います。表示の日付と lastmod を別々に持てる仕組みなら、lastmod だけ動かしてもかまいません。別々に持てないなら、私は表示の線引きを優先して、関連記事への案内やリンク切れの修正だけなら日付を据え置き、本文や構造化データなど、ページの中身を直したときだけ動かしています。

据え置いた場合に起きうるのは、足したリンクにGoogleが気づくのが遅れることです。事実より新しい日付を伝えるわけではないので、信用を失う向きのずれではない、と私は考えています。ブログの例が信用を失う形として挙げているのは、7年前に変わったページを前日に変わったと伝える向きです。危ないのは、何も直していないのに日付が新しくなるほうです。中身を変えずに日付だけ新しくするのが、検索の公式ガイドで見直すべき行為に挙がっていることは古い記事の情報を更新するリライトの方法、優先順位は3段階、日付だけ変えても意味がないに書きました。

本文を直して日付が正しく動いても、それは「見に来てもらう順番」の手がかりが1つ増えるだけです。クロールされたあと、インデックスが更新され、検索結果の表示が変わり、順位や表示回数が動くまでには別々の工程があり、どこで止まっているかの見分け方はリライトが反映されない4つの工程、検索結果が更新されない原因の切り分けにまとめました。直した記事が多いときにURLを1本ずつリクエストしなくてよい理由はインデックス登録をリクエストしても反映されないのはなぜ？押して動くのはクロールの順番だけにあります。

日付が正しく動く状態を作っておくと、あとは「どの記事の本文を直すか」に手を使えます。その1本は、Search Consoleで表示回数があり、平均掲載順位が4.0〜20.5位にいる記事から探すのが、私のやり方です。検索結果には出ているのに、クリックまで届いていないかもしれない記事だからです。

自分のサイトマップで、lastmodが正しいかを確かめる3つの見方

サイトマップのURLをブラウザで開くと、中身をそのまま読めます。Search Consoleに送ったサイトマップのURLが分からなければ、サーチコンソールのサイトマップ登録は？ステータス別の次の一手の手順で、サイトマップ レポートの一覧から確かめられます。開いたら、次の3つを見ます。

1. 全部のURLが同じ日付(今日や、サイトマップを作った日)になっていないか。なっていれば、ページの更新日ではなく、サイトマップを作った日時が入っている可能性があります
2. 直していない記事の日付が、最近の日付に動いていないか。テーマの変更やサイドバーの差し替えのような、本文と関係ない作業のあとに、一斉に日付が動いていないかを見ます
3. 最近直した記事の日付が、直した日になっているか。本文を直したのに古い日付のままなら、日付が正しく出ていません

1つ目は、sitemaps.org のプロトコルがはっきり書いている注意です。

この日付は、サイトマップが生成されたときではなく、リンク先のページが最後に更新された日に設定しなければならないことに注意してください。
— sitemaps.org「プロトコル」

英語版は "Note that the date must be set to the date the linked page was last modified, not when the sitemap is generated." です。このブログのサイトマップを作るコードにも、「今日の日時」を入れるとビルドのたびに全ページの更新日が動くので、日付は記事ごとに持たせる、という注意を書いてあります。2026年10月10日に開いたときは、330件のURLの lastmod は、書いた日・直した日によって26通りに分かれていて、全部が同じ日付にはなっていませんでした。

日付がおかしいのに、自分では直せない仕組みのこともあります。そのときは、使っているCMSやプラグインの設定に lastmod を出さない選択肢がないかを探します。2023年のブログが書くとおり、自信のないページの lastmod は外してかまわないので、まちがった日付を出し続けるよりは、出さないほうが安全です。

サイトマップの上限は、1ファイル50,000 URL・50 MB

「サイトマップ 分割」で調べている方のために、上限も書いておきます。サイトマップの作成と送信によれば、どの形式でも、1つのサイトマップの上限は、圧縮していない状態で50 MB、URLは50,000件です。超える場合は複数に分ける必要があり、分けたサイトマップはサイトマップ インデックス ファイルにまとめて、それだけを送ることもできます。記事が数百本の個人ブログが、この上限に届くことはまずありません。

よくある質問

大事な記事の priority を 1.0 にすると、順位は上がりますか

Google検索では変わりません。サイトマップの作成と送信が、priority と changefreq の値を無視すると書いています。sitemaps.org のプロトコルも、priority が掲載順位に影響する可能性は低い、と書いています。

changefreq を daily にすると、クロールが増えますか

Googleについては、無視すると書かれています。2023年のブログは、changefreq は考え方として lastmod と重なる、としています。クロールし直す時期の手がかりにされるのは、正確な lastmod のほうです。

lastmod は書かないといけませんか

必須ではありません。sitemaps.org のプロトコルでも省略できるタグで、2023年のブログも、全部のページに付けても、自信のあるページだけに付けてもよい、と書いています。付けるなら、正確な日付にしておくことが条件です。

大事な記事を、サイトマップの上のほうに並べたほうがいいですか

その必要はありません。サイトマップの作成と送信に「サイトマップ内の URL の順序を気にする必要はありません。Google 側に影響はありません。」とあります。英語版も "it doesn't matter to Google" です。

リライトしたら、サイトマップを送信し直したほうがいいですか

記事を1本直すたびに送り直す必要はありません。Search Consoleのヘルプによれば、正常にクロールされたサイトマップは、Googleが定期的にクロールし直します。lastmod が正しく動いていれば、直した記事の日付はそのときに伝わります。送り直しが勧められている場面はサーチコンソールのサイトマップ登録は？ステータス別の次の一手のFAQにまとめています。

HTMLサイトマップ(記事一覧のページ)にも lastmod は要りますか

HTMLサイトマップは読者向けの一覧ページで、ここで扱ったXMLのサイトマップとは別物です。lastmod の欄もありません。違いはHTMLサイトマップは必要？XMLサイトマップとの違いと、どこからもリンクされていない記事で決める考え方に書きました。

まとめ

• サイトマップの priority と changefreq は、Googleが無視すると公式ドキュメントに書いている。消さなくても、整えなくてもよい
• lastmod は、一貫して正確だとGoogleが確かめられる場合に、すでに見つけているURLをクロールし直す時期の手がかりとして使われる
• lastmod は「最後の重要な更新」の日付。本文・構造化データ・リンクの変更は入り、著作権の年やサイドバー・フッターの小さな変更は入らない
• 何も変えずに日付だけ新しくし続けると、最終更新日を信用されなくなる。リライトでは、本文や構造化データなど、ページの中身を直したときだけ記事の更新日を変える
• 自分のサイトマップを開き、全部のURLが同じ日付になっていないか、直した記事だけ日付が動いているかを見る
• 上限は1ファイル50,000 URL・50 MB(圧縮していない状態)。個人ブログで分割を考えることはまずない

日付を正しく保つのは、リライトの土台です。どの記事の本文を直すかは、Search Consoleのページ別の数字を並べ替えて決めます。

ここから先は、その並べ替えを機械にやらせる自作ツールの宣伝です。

Search Consoleの「ページ」タブのエクスポートをZIPのまま置くと、掲載順位が4.0〜20.5位のページを拾い、表示回数100回以上は通常判定、30〜99回は参考判定、30回未満は本文中心の監査に分けます。並び順は、通常判定 → 参考判定 → 本文中心の監査の順。前2つの中は CTR機会差の多い順、30回未満は表示回数の多い順です。 判定と、そのうち1記事分の診断カードまでは無料です。有料は2,980円(税込)の買い切りで、無料の1件を除いた3記事分の診断カードが対象です。3記事分が揃うとき(判定に出た候補が4件以上のとき)だけご案内します。生成の利用期限は購入から7日間で、月額課金や自動更新はありません。ログインも不要です。 CSVファイルそのものはブラウザの外に出ませんが、診断カードを出すときは選んだ1ページぶんの数値(URL・キーワード・順位・表示回数・CTR)を、タイトル取得を押したときは最大10件のURLを送ります。

⚠️ 判定に使うのは、Google検索のページごとの平均掲載順位・表示回数・CTRです(診断カードでは選んだ1ページの本文を読みます)。サイトマップや lastmod は読まないので、日付を直してもツールの判定は変わりません。期間はエクスポートのときに選んだもので決まります(おすすめは過去12か月です)。表示回数が0の行は読み込み時に除くので、検索結果に出ていない記事は候補に出てきません。並べ替えるだけで、順位やクリック数が上がることを約束するものではなく、掲載順位4.0〜20.5位に入るページが無いブログでは、候補が0件になることがあります。