sitemapのlastmodは何を書く？Googleが値を使う条件と、priority・changefreqの扱い

sitemapのlastmodは何を書く？Googleが値を使う条件と、priority・changefreqの扱い

記事を直してサイトマップも更新されたのに、検索結果の内容が古いまま——そう感じたとき、多くの人は「lastmodの書き方が間違っているのか」と疑います。

その前に確認したい前提があります。<lastmod> は検索エンジンへの申告であって、再クロールの約束ではありません。そして申告が受け取られるかには条件があります。この記事ではその条件と、最初に決めるべき1点を整理します。

30秒で要点

• <lastmod> は申告であり、Googleは「一貫して検証可能に正確」な場合にその値を使うと書いている。無条件の採用ではない
• <priority> と <changefreq> はGoogleが無視すると明記している。ここに時間を使う必要はない
• 最も多い壊れ方は、サイトマップの生成時刻が全URLのlastmodに入ること。仕様は「生成日ではなくページが最後に更新された日」と明記している
• 書き方より先に決めるのは「何をもって更新とみなすか」。Googleは主要コンテンツ・構造化データ・リンクの更新を一般に重要とし、著作権表記の日付は該当しないとしている

lastmodは「約束」ではなく、こちらからの申告

Googleの公式ドキュメントは、<lastmod> をその値が一貫して、かつ検証可能に正確である場合に使うと書いています。検証方法の例として、ページの最終更新と比較することが添えられています（Google検索セントラル。同ページの更新表記は2026-07-08）。

押さえたいのは、条件が「正確である」ではなく「一貫して、検証可能に正確である」点です。1件だけ正しくても足りません。サイト全体として、申告した日時が実際のページの状態と照らして確かめられるかが問われます。

sitemaps.orgのプロトコルでも <lastmod> は任意項目で、日付はW3C Datetime形式とされ、「日付はリンク先ページが最後に更新された日に設定しなければならず、サイトマップが生成された日ではない」と明記されています（sitemaps.org プロトコル）。

なお、不正確なら必ず無視される、サイト全体が信用されなくなる、といった記述は見当たりません。言えるのは「採用される条件を満たさない状態になる」までです。

よくある壊し方——全URLに生成時刻が入る

仕様がわざわざ「生成された日ではない」と書いているのは、それが実際に起こるからです。

CMSやSSG（静的サイトジェネレーター。ビルド時にHTMLを生成する仕組み）で自動生成していると、ビルドのたびに全URLの <lastmod> がビルド時刻で書き換わることがあります。1記事だけ直してデプロイしても、全ページが「今日更新された」と申告されます。

これは先の条件を正面から外します。実際の最終更新と比べて日時が合うURLはごく一部になり、一貫して検証可能に正確、の逆になります。

自動生成が悪いのではありません。元になっている値が「ビルド時刻」なのか「そのページの最終更新日」なのかが分かれ目です。

priorityとchangefreqに時間を使わない

Googleの公式ドキュメントは、___<lastmod>0___ と ___<lastmod>1___ の値を無視すると明記しています。sitemaps.orgの仕様でも ___<lastmod>2___ は命令ではなくヒントと位置づけられ、___<lastmod>3___ は割り当てた優先度が検索結果でのURLの順位に影響する可能性は低いとされています（サイト内のページ間の相対的な指定として説明されています）。

この2項目の設定を検討する時間は、ほぼ無駄になります。削るか既定値のまま放置して構いません。ただしこれはGoogleとsitemaps.org仕様についての記述で、他の検索エンジンの扱いは扱っていません。

先に決めるのは「何を更新とみなすか」

書式を調べる前に、自サイトは何をもって「更新」とみなすのかを決めるほうが先です。これが決まらないと、何を正しく申告すべきかも決まりません。

Googleの公式ドキュメントは、___<lastmod>4___ はページの最後の重要な更新の日時を反映すべきだとし、主要コンテンツ・構造化データ・ページ上のリンクの更新は一般に重要な更新とみなされる一方、著作権表記の日付の更新は該当しないと書いています。

これを判断基準に落とすと、たとえばこうなります。

著作権年までは公式の例示そのもので、最後の1行は「主要コンテンツが変わったか」をあてはめた結果です。この線をどこに引くかは自サイトの判断なので、決めたら文書に残すと担当者が変わっても一貫性が保てます。なお公式の例示は「一般に」という限定付きで、網羅的な基準ではありません。

確かなことと、まだ確かではないこと

確かなこと: Googleがlastmodを一貫して検証可能に正確な場合に使い、priorityとchangefreqを無視すると書いていること。sitemaps.orgの仕様がlastmodを任意項目とし、生成日ではなくページの最終更新日と定め、changefreqをヒント、priorityを順位に影響しにくいとしていること。重要な更新の例示の内容。

まだ確かではないこと: 正しく運用すると再クロールやインデックスがどう変わるか（効果量の記述なし）。不正確だった場合に何が起きるか（条件付きの採用までしか書かれていない）。他の検索エンジンの扱い（情報源に記述なし）。

自分でも試せる、最小の検証

自サイトの ___<lastmod>5___ を開いて、___<lastmod>6___ の値を上から10件ほど見てください。日時がすべて同じなら、入っているのはビルド時刻である可能性が高いです。

もう一手順足すなら、記事を1本だけ直してデプロイし、同じ場所を見直してください。直した1件だけ変わっていれば最終更新が反映されています。全件が変わったなら生成時刻です。

この2分で、「書き方」の問題なのか「何を申告しているか」の問題なのかが切り分けられます。検索エンジンに守らせる指示なのか、こちらからの申告なのか——迷ったらこの問いに戻ると、書式の細部より先に確かめることが見えます。

効力を誤解されやすい指定という点では、canonicalタグは「指示」ではない、robots.txtはアクセス制御ではない、HTTPステータスコードの判断ガイドが同じ系列です。検索エンジン最適化（SEO）の技術面の全体像はテクニカルSEOの基礎にあります。

何を更新とみなすかを決めるところから整理したい場合は、診断ツールで状況を言語化することから始められます。