sitemap.xml の運用判断: lastmodをいつ更新するか、サブドメインをどう分けるか
📌 記事の取り扱いについて（公開当時の内容を含みます — タップで詳細）
本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。
サイトを公開した直後にやった地味な初期設定（Search Console への登録や、ページ一覧ファイルを手で書く話）は、別記事「公開直後にやった地味なSEO初期設定」にまとめてあります。あの頃の「とりあえず動かす」体験はそちらに譲って、この記事では sitemap.xml を**何ヶ月か運用してみて迷った「判断」**のほうに絞って書いていきます。サブドメインを複数抱えてからは、sitemap を「一度書いて終わり」にはできず、どこを・いつ更新するかの方針を自分で決める必要が出てきました。
結論を先に書くと、私の場合は「サブドメインごとに sitemap.xml（ページ一覧を渡すファイル）を一枚置き、実質的に変わったページの lastmod（最終更新日）だけを書き換える」という運用に落ち着いています。以下はその判断の理由と、途中でつまずいた点の記録です。
サブドメインごとに sitemap を分ける判断
私のサイトはサブドメインで役割を分けています。トップサイト、ホテル検索、料金比較、子連れスポット、お金診断、買い物、といった具合です。最初はこれを1枚のページ一覧ファイル（sitemap.xml）にまとめようとしたのですが、Googleの管理画面（自分のサイトが検索エンジンからどう見えているかを確認する画面で、正式には Search Console というらしいです）では、登録したプロパティごとに sitemap を送信できます。私の場合は、サブドメインごとの管理に合わせて sitemap も分けるのが結局いちばん楽でした。各サブドメインの一覧ファイルは、それぞれ https://<サブ>.example.com/sitemap.xml のように、そのサブドメインの中に置くのが分かりやすいです。別ドメインや別サブドメインの URL を無理に1つの sitemap にまとめようとすると、管理や確認がややこしくなります。ここは素直に分けておくのが無難だと感じました。
分けておくと、特定ドメインの一覧ファイルが巨大になりすぎる心配も減りそうです。調べてみると1ファイルあたり 50,000 URL・50MB（非圧縮） という上限があるらしいのですが、私くらいの個人サイトの規模だと、分割しなくてもあふれることはまずなさそうでした。なので正直なところ、この上限を気にしてサブドメインを分けているというより、Googleの管理画面のプロパティの切り方に合わせていたら結果的に分かれていた、という感じです。プロパティをどう切るか（ドメインプロパティかURLプレフィックスか、というやつ）という管理画面側の話は私もまだうまく説明できないので別記事に譲るとして、この記事はあくまで一覧ファイルそのものをどう扱うか、に絞って書きます。
lastmod を「いつ」書き換えるか
この記事でいちばん書いておきたかったのが、ここです。<lastmod> は最終更新日の欄なのですが、これを毎日・全ページぶん書き換えるようにしてしまうと、「本当に中身が変わったページ」が分かりにくくなるのでは、と心配になりました。それで私は、実質的に中身が変わったページだけ lastmod（最終更新日の欄）を更新する、というやり方に落ち着いています。
どこで線を引くかを自分なりに決めておかないと毎回迷ってしまうので、私の場合はこんなふうにしています。
- 更新しない: 誤字の修正、句読点の調整、表記ゆれの直し、CSSだけの見た目の微調整。読者が受け取る情報がほとんど変わらないものは触りません。
- 更新する: 料金表の数値が変わった、構造化データ（検索エンジンに内容を機械的に伝えるための補足データ）を追加・修正した、内部リンクを大きく整理した、本文の主張や結論が変わった。読者にとっての中身が動いたときだけ書き換えます。
たとえば料金比較のページで「割引後の金額」を直したときは更新しますが、同じページの「てにをは」を直しただけの日は触りません。この線引きをあらかじめ決めておくと、「これは更新日を動かすべきだろうか？」と毎回悩まずに済んで、ずいぶん気が楽になりました。
sitemap index を使う場合は、各 sitemap の <lastmod> を、その sitemap 内のどれかのページが実質的に更新された日に合わせるようにしています。
自動で埋めるのはやめて、一覧ファイルは手で書き換えることにした
最終更新日を自動で埋める仕組みも考えました。サイトを組み立てる処理（ビルドスクリプト）の中で、「ファイルの最終更新時刻（mtime というやつです）」を拾って書き出す方式です。ただ、これは私の環境では当てにならなさそうでした。
私は複数のMacを iCloud で同期して使っているのですが、中身は何も変えていないのに、iCloud 同期の都合でファイルの最終更新時刻だけが書き換わってしまうことがあるようなのです。それを根拠に自動で埋めると、実質は何も直していないページの最終更新日が勝手に動いてしまって、「中身が変わったページだけ更新する」というさっきのルールが台無しになってしまいます。
それで結局、一覧ファイルそのものを手で管理することにしました。実質的な更新をしたときに、そのページのぶんだけ日付を手で書き換える、という素朴なやり方です。自動化としては後退かもしれませんが、私の規模なら手間はごくわずかですし、「この日付は自分が意図して書いた」と言い切れる安心感のほうが勝ちました。複数の端末で運用するなら、ファイルの更新時刻はあまり当てにしないほうがよさそうだ、というのがここでの学びでした。
複数の sitemap をまとめる仕組みは、無理には使わないことにした
ページ数が増えてくると、複数の sitemap をひとまとめにする仕組み（sitemap index というやつです）の出番だ、と書かれているのをよく見かけます。確かにこれを入れると、まとめられた sitemap ごとに最終更新日を持てるので、どのまとまりが更新されたかを伝えやすくなります。
ただ、私のサイトは1ドメインあたりせいぜい数十〜数百ページの規模なので、いまのところは一枚の一覧ファイルのままにしています。理由は単純で、いまのページ数だとまとめる仕組みを入れて管理が複雑になるぶんのほうが、得られる効果より大きい気がしたからです。これを入れると、どの一覧にどのページが入っているかを自分で把握しておく手間が増えてしまいます。先回りして仕組みを重くするより、さっきの上限（5万URL・50MB）に近づいたり、管理上分けたくなったりしてから考えればいいかな、というくらいの気持ちでいます。
検索の登録状況をぼんやり眺めていても、効いているのはサイトの構造やリンクのつながりのほうみたいで、私の規模では sitemap を分割すること自体は思ったほど大きな差にはならない印象でした。なので一覧ファイルは「URLの一覧をきちんと渡す」役割だと割り切って、気楽に付き合うようにしています。
URL正規化で「重複の真因」をつぶす
地味ですが、後からじわじわ効いてくると感じているのがURLの揃え方です。一覧ファイルに載せる URL は、自分の中でルールをひとつ決めて統一するようにしました。具体的には次の3点を揃えています。
- 末尾スラッシュの有無（
/pageか/page/か） - www あり/なし（
example.comかwww.example.comか） - 大文字小文字（ホスト名やパスの綴り）
そして大事だと感じたのは、この綴りを 一覧ファイル・canonical（このページの正規URLはこれだ、と伝える指定）・内部リンク の3箇所すべてで同じに揃えることでした。どれか1つでもズレていると、検索エンジンからは別々のURLとして扱われることがあり、同じ内容のページの評価が分散してしまうかもしれません。
私が「重複の本当の原因はこれだったのか」と感じたのもここで、文章自体は被っていなくても、URLの表記ゆれだけで自分のページ同士が別ページのように見えてしまう、ということが起きていました。一覧ファイルだけ直しても、内部リンクが古い綴りのままだと意味が薄いので、いまは3箇所セットで見直すようにしています。
あわせて、一覧ファイルに 載せないURL も決めました。noindex（検索結果に出さないでください、という指定）を付けたページや、レビュー用・開発用の /preview/ のような非公開のURLは載せません。noindex のページを一覧に載せてしまうと、「見つけてほしいURL」と「検索結果には出したくないURL」が混ざってしまうので、私は sitemap には載せないようにしています。公開前のプレビューURLがうっかり混ざると、未完成のページが見つかってしまう事故にもつながるので、ここはつまずかないように気をつけています。
デプロイ後に自分の目で見ることだけは続けている
最後に、保険のつもりで続けているのが、サイトに反映した直後に自分の目で確かめることです。デプロイのあと、https://<サブ>.example.com/sitemap.xml の実物を取得して、URL一覧と最終更新日の値を一通り眺めるようにしています。
というのも、サイトを組み立てる処理のバグで一覧ファイルが空になっていたり、最終更新日が全ページ同じ日付に書き換わってしまっていたりしても、Googleの管理画面の警告は少し遅れて届くので、その場では気づけないのです。何度かヒヤッとしたので、デプロイ後の数十秒だけ実物を見る、というのは最低限の安全策として残しています。
一覧ファイル（sitemap.xml）は派手な機能ではありませんが、どのページを検索エンジンに見つけてほしいか、どのページを実質的に更新したか、という運用のメモを兼ねたファイルでもあるように感じています。だからこそ、自動で雑に埋めてしまうより、「いつ書き換えるか」を自分でちゃんと決めておくほうが、長く付き合ううえでは扱いやすいのかな、と今のところ思っています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ