サイトマップのlastmodはいつ更新する？公式の3条件と書き方

誤字を2カ所直した。バナーを差し替えた。章をひとつ書き足した。——このうち、sitemap.xml の lastmod（そのURLの最終更新日を検索エンジンに伝える項目）を書き換えるべき変更はどれでしょうか。

答えを先に書きます。Google の公式ブログは、lastmod を更新する場面として 主要なテキストを変更したとき・構造化データを追加または変更したとき・一部のリンクを更新したとき の3つを挙げています。章の追記は更新する。バナーの差し替えは、どの条件にも触れません。誤字修正は迷いどころですが、本文の中身が変わったかで線を引けば決められます。

残る問いは3つです。この3条件の根拠はどこにあるのか。日付はどんな書式で書くのか。そして、誤字修正のような迷う変更をどう裁くのか。

公式ブログが挙げる「更新する3条件」

根拠になるのは、Google 検索セントラル ブログの「Sitemaps ping endpoint is going away」（2023年6月）です。サイトマップの ping 送信の廃止を告知した記事ですが、後半に lastmod の運用指針がまとまっています。

その中に、こういう趣旨の一節があります。（〜の場合は）更新しなくてもよい。しかし、主要なテキストを変更した場合、構造化データ（ページの内容を検索エンジン向けに機械が読める形で書き足すマークアップ）を追加・変更した場合、一部のリンクを更新した場合には、lastmod の値を更新してください——。

注目したいのは2点です。ひとつは、更新する場面が具体的に列挙されていること。もうひとつは、その直前が「更新しなくてもよい」場合への言及になっていることです。つまり公式の立場は「変更のたびに必ず書き換えろ」ではありません。書き換える変更と、書き換えない変更がある。その線引きの材料が、この3条件です。

書き方——W3C の日時書式と、Google 自身の「日付のみ」の例

次に書き方です。日付・時刻の表記のよりどころにできるのが、W3C の「Date and Time Formats」です。時刻まで書く場合の形として、次の書式が定義されています。

YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)

時刻を含む書式には、末尾に TZD＝タイムゾーン（標準時との時間差の表記）が付きます。W3C の定義では、時刻の表し方は2通りです。UTC（協定世界時）で書いて「Z」を付けるか、現地時刻で書いて時差を添えるか。時刻まで書くなら、2026-08-08T09:30:00+09:00 のように現地時刻＋時差の形が書きやすいはずです。時差の数値には、自分のサイトが基準にしている標準時とのずれを入れます。

一方で、そこまで細かく書かなくても構いません。Google 自身がドキュメントに載せているサイトマップの例は、こうなっています。

<loc>https://www.example.com/foo.html</loc> <lastmod>2022-06-04</lastmod>

日付のみです。時刻もタイムゾーンもありません。CMS が時刻まで正確に出せるならそれでよし、手で管理しているなら日付のみで十分、という使い分けができます。

どの行を選んでも、大事なのは形式より中身です。実際に変更した日と、書かれている日付が合っていること。ここが次の手順の主題になります。

直近の変更を仕分ける6ステップ

先週サイトに入れた変更が5件あったとして、実際に通してみます。

• 変更1: 記事Aの誤字を2カ所修正した
• 変更2: 記事Bに「よくある質問」の章をまるごと追記した
• 変更3: トップページのキャンペーンバナー画像を差し替えた
• 変更4: 料金ページに構造化データを追加した
• 変更5: 記事Cの末尾の関連リンクを3本張り替えた

1. サイトマップの現状を見る。 自分のサイトの sitemap.xml をブラウザで開き、lastmod が出力されているか、そして全URLが同じ日付になっていないかを確認します。全部が今日の日付なら、CMS やプラグインが一括で書き換えている疑いがあります（後述）。
2. 直近の変更を書き出す。 上の5件のように、URLと変更内容をセットで並べます。記憶が曖昧なら、CMS の更新履歴や社内の作業ログを見ながらで構いません。
3. 3条件に当てはめる。 変更2は「主要なテキストの変更」に当たります。変更4は「構造化データの追加」そのものです。変更5は「一部のリンクの更新」に読めます。この3件は更新する側です。
4. どの条件にも触れない変更を落とす。 変更3のバナー差し替えは、本文も構造化データもリンクも変えていません。装飾の入れ替えです。ここは書き換えない側に置きます。
5. 迷う変更は「中身が変わったか」で決める。 変更1の誤字修正は、文字としては本文に触れています。ただ、ページが伝える内容は前後で同じです。公式ブログが「更新しなくてもよい」場合に言及していることを踏まえると、意味が変わらない修正まで日付を動かす読み方は不自然です。原則そのままにします。
6. 更新すると決めたURLだけ、実際の変更日を書く。 変更2・4・5のURLの lastmod を、それぞれの作業日に合わせます。書式は上の表のどれかに揃えます。ここで「全URLをまとめて今日にする」を選ばないのが、この手順の肝です。

結果は「5件中、更新は3件」。全部書き換えるのでも、全部放置するのでもない、というのが仕分けの答えです。

判定表

手順3〜5を早見表にしたものです。自分の変更をどれかの行に当てはめてください。

下2行を「そのまま」にできることが、この表の価値です。更新すべき変更だけが日付に反映されていれば、lastmod は「このページはいつ中身が変わったか」の一覧として信用できる状態になります。

よくある誤解：毎日全ページを今日の日付にする設定

手順1で触れた「全URLが同じ日付」の話です。CMS やサイトマップ生成プラグインの設定によっては、中身を変えていないページまで含めて、lastmod が毎日その日の日付で出力されることがあります。

これは3条件のどれとも関係なく日付が動いている状態です。どのページがいつ変わったのかを伝える情報としては、何も伝えていません。サイトマップの概要ドキュメントには、検索エンジンはこのファイルを読んでサイトを効率よくクロール（検索エンジンのロボットがページを巡回すること）する、ページやファイルについての有用な情報を提供するものだ、という趣旨の説明があります。全URL同日付の lastmod は、この「有用な情報」の役割を果たせていない、と考えるのが自然です。生成ツールの設定に「実際の更新日時を使う」に相当する項目がないか、まず確認してください。

もうひとつ、期待の掛けすぎにも注意が要ります。同じ概要ドキュメントは、サイトマップの効果が出やすい場面として、規模が大きいサイトや構成が複雑なサイト、専門的なファイルのクロール改善を挙げています。そして、重要なページはメニューやページ内リンクといったナビゲーションからたどり着けるようにしたうえで、という前提つきです。概要ドキュメントの言い方では、サイトマップは検索エンジンによるサイト内URLの発見を助けるものです。lastmod を正しく整えることは、その助けの精度を上げる作業だと捉えるのがよさそうです。載せさえすれば思いどおりに扱われる、という期待までは、概要ドキュメントの記述からは出てきません。

lastmod の「効果」はどこまで言えるか

検索すると「lastmod でクロール頻度が上がる」「順位に効く」といった説明も見かけます。今回参照した公式ドキュメントとブログの範囲では、そこまでの断定はできません。

言えるのは次の2つの事実です。Google は「どういうときに lastmod を更新すべきか」を公式ブログでわざわざ案内している。サイトマップは検索エンジンが効率よくクロールするために読むファイルだと位置づけている。この2つが並ぶ以上、lastmod は読まれる前提の項目として整えておく価値がある——出典に裏づけて言えるのは、その範囲までです。逆に、日付を新しくしただけで巡回や順位が動くという期待は、根拠側に支えがありません。

作業後のチェックリスト

• sitemap.xml に lastmod が出力されているか確認した
• 全URLが同じ日付・毎日更新になっていないか確認した
• 直近の変更を「テキスト・構造化データ・リンク」の3条件で仕分けた
• 意味の変わらない誤字修正や装飾の差し替えで日付を動かしていない
• 書式を、日付のみ（Google の例と同じ形）か、時刻＋タイムゾーンつき（W3C の書式）のどちらかに揃えた
• 時刻まで書く場合、タイムゾーン（+09:00 や Z）を付けた

なお、サイトマップまわりで Search Console に出る「インデックス登録済みですが、サイトマップに送信されていません」という表示の扱いはサイトマップ未送信の警告の読み方で、更新をより早く知らせたいときに手動リクエストを繰り返すべきかはインデックス登録リクエストの正しい使いどころで扱っています。lastmod を実態に合わせて整えることは、この2記事で扱った「サイトマップを信頼できる状態に保つ」作業の土台にあたります。