sitemapのpriorityとchangefreqは無視される｜見直し手順

トップページは 1.0、記事は 0.8、タグ一覧は 0.3。更新頻度は daily と weekly を使い分ける。——sitemap.xml の priority と changefreq を、こうやって設計してきたサイトは少なくありません。

結論から書きます。Google はこの2つを使っていません。Google 検索セントラルの「サイトマップの作成と送信」には、Google は <priority> と <changefreq> の値を無視すると書かれています。

だから、値の調整に時間をかける必要はありません。手間を移すべき先は2つです。<lastmod>（最終更新日）を正確に保つこと。そして、<loc> に正規URLだけを並べること。切り替えの手順は、架空の例に通しながら後半で示します。

公式ドキュメントに書かれていること

根拠になる一文は、「サイトマップの作成と送信」の XML サイトマップの補足にあります。<priority> と <changefreq> の値は無視する、と短く言い切っています。

続く文で、<lastmod> の扱いが説明されています。Google が <lastmod> の値を使うのは、それが一貫して、かつ検証できる形で正確な場合です。検証の例として、ページの最終更新と比べることが挙げられています。

ここで、3つのタグの扱いがはっきり分かれます。priority と changefreq は、値そのものが無視される。lastmod は、正確なら使われる。つまり「書いても値が使われない」タグと「正確でなければ使われない」タグが、同じファイルに並んでいるわけです。

もう1つ、同じページの要約には、サイトマップの URL は絶対URLかつ正規URLにするよう書かれています。サイトマップで効くのは、どのURLを載せるかと、その日付。ここに集約されます。

値は無視されても、XML の誤りは無視されない

ここで1つ、取り違えやすい点があります。「無視されるなら、適当な値でも壊れていても構わない」とは限りません。

Search Console ヘルプの「サイトマップ レポート」には、エラーの例として、1つの <url> の中に同じタグが2回書かれたサンプルが載っています。そのサンプルには <changefreq>monthly</changefreq> と <priority>0.8</priority> も含まれています。レポートは問題のタグと行番号を示し、重複したタグを取り除いて再送信するよう案内しています。

値が使われないことと、ファイルが XML として正しく読めることは別の話です。テンプレートを手で直すと、閉じタグの抜けや重複が入り込むことがあります。タグを消すにせよ残すにせよ、最後にレポートで読み込み結果を確かめる工程は外さないでください。

なお、同じヘルプには、サイトマップの取得に失敗した場合、Google は何度か再試行するものの、最終的にはそのサイトマップの読み込みをやめる、とも書かれています。壊れたまま放置するのが一番まずい、ということです。

lastmod は「正確なら使われる」

priority と changefreq の代わりに気を配るべきなのが lastmod です。

Google 検索セントラル ブログの「Sitemaps ping endpoint is going away」（2023年6月）は、lastmod が役に立つ条件を2つ挙げています。1つめは、sitemaps.org の文書に沿った、サポートされている日付形式であること。形式が正しくない場合は、送信後に Search Console が知らせてくれます。2つめは、実際と一致していることです。

同じ記事は、更新すべき場面として、主要なテキストを変えたとき・構造化データを追加または変更したとき・一部のリンクを更新したときを挙げています。

また「大規模サイトのクロール予算の管理」には、更新されるコンテンツがあるサイトでは <lastmod> タグを含めることを勧める、と書かれています。

ありがちなのは、サイトマップを生成するたびに全URLの lastmod を生成時刻にしてしまう実装です。どのページも毎回「今日更新された」ことになる。これは、公式が条件にしている「実際と一致」から外れます。この状態だと、lastmod が更新の手がかりとして使われにくくなることがあります。どの変更で日付を書き換えるかの線引きは、サイトマップのlastmodはいつ更新する？で詳しく扱っています。

載せるURLは正規URLだけ

もう1つの手間の移し先が <loc> です。

「重複した URL の統合」では、正規URL（同じ内容のURLが複数あるとき、検索結果に代表として出したいURL）を Google に伝える方法として、リダイレクト、rel="canonical"、サイトマップへの掲載が並べられています。このうち最も強いのはリダイレクトです。サイトマップへの掲載は、それと並ぶ方法の1つとして挙げられています。

つまりサイトマップも「このURLを正規として扱ってほしい」という意思表示の1つです。並べ替えパラメータ付きのURLや、リダイレクト元の古いURLが混ざっていると、ほかの指定と食い違うことになります。同じ文書は、各ページの正規URLを選んでサイトマップに載せるよう勧めています。

「大規模サイトのクロール予算の管理」は、長いリダイレクトの連鎖がクロールに悪影響を与えるので避けるよう書いています。サイトマップにリダイレクト元を載せ続けると、クローラー（Google の自動巡回プログラム）にわざわざ遠回りをさせることになりかねません。

タグ別の判定表

ここまでを、<url> の中に書く4つのタグごとにまとめます。

表の上2行は「正確さが問われる」タグ、下2行は「値が使われない」タグです。点検の時間配分も、この並びのとおり上に寄せます。

自社のサイトマップを見直す5ステップ

ここからは実作業です。ターミナルで curl が使える前提で書きます。https://example.com は自社のドメインに置き換えてください。

1. 本番の sitemap.xml に、どのタグが何回出ているかを数える。 まず現状を数字で押さえます。

   curl -s https://example.com/sitemap.xml | grep -o '<[a-z]*>' | sort | uniq -c
   

   <url> と <priority> の数が同じなら、全URLに優先度が付いています。サイトマップが複数ファイルに分かれている場合は、インデックスファイル（サイトマップの一覧）から各ファイルをたどって同じことをします。

2. priority と changefreq を出力している場所を特定する。 CMS のプラグイン設定か、自前のテンプレートか、ビルド時のスクリプトか。ここで「値を調整する運用」を止めます。出力そのものを止めるかは、次の「よくある誤解」の節を読んでから決めてください。

3. lastmod が実際の更新と合っているかを確かめる。 日付ごとの件数を並べます。

   curl -s https://example.com/sitemap.xml | grep -o '<lastmod>[^<]*' | sort | uniq -c | sort -rn | head
   

   ほぼ全URLが同じ日時に集まっていて、その日時がサイトマップの生成時刻と一致するなら、生成時刻をそのまま入れている可能性が高いです。生成元を、記事データの更新日を参照する形に直します。

4. <loc> のURLが正規URLかを確かめる。 全URLのステータスコードを一覧にします。

   curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//' \
     | while read u; do echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"; done | grep -v '^200 '
   

   何も表示されなければ全件 200 です。表示された 301・302・404 などのURLは、サイトマップから外すか、移転先のURLに差し替えます。? を含むURLも、正規URLかどうかを1件ずつ見ます。

5. Search Console のサイトマップ レポートで再送信し、読み込み結果を見る。 エラーが出たら、レポートが示すタグと行番号から直します。なお、レポートに登録したサイトマップのURLがリダイレクトしていると、そのリダイレクトはたどられません。登録するのは最終的なURLにします。

例: 業務用品の自社ECでやってみる

架空の例で通してみます。業務用品を売る自社EC で、商品ページと読み物記事を合わせて約1,200URL。サイトマップはプラグインが自動生成しています。

ステップ1で数えると、<url> が1,214、<priority> と <changefreq> も1,214ずつ。全URLに両方が付いていました。トップは 1.0 と daily、商品は 0.8 と weekly、記事は 0.6 と monthly。過去に誰かが「売れ筋商品は0.9に上げる」運用を始め、四半期ごとに見直していた形跡もあります。

ステップ2で、この見直し作業を止めます。Google が値を無視すると明記している以上、四半期ごとの調整に Google 検索上の見返りは期待できません。プラグインに出力停止の設定があったので、検証環境で止めてファイルを生成し直しました。

ステップ3では、1,214件中1,209件の lastmod が同じ日時でした。サイトマップの再生成時刻です。これが今回いちばん大きな問題でした。プラグインの設定を、各ページの更新日を使う形に切り替えます。

ステップ4では、11件が301を返しました。商品の統合で URL を変えたときの旧URLです。さらに ?sort=price 付きの一覧ページが3件。あわせて14件をサイトマップから外しました。

ステップ5で再送信し、レポートで読み込みに問題がないことを確認して完了です。

振り返ると、判定表の4行がそのまま作業に対応しています。priority と changefreq の行は、四半期ごとの作業が1つ減っただけ。手を動かす価値があったのは、lastmod の1,209件と loc の14件でした。

よくある誤解：「無視されるなら、消さないとまずい？」

逆向きの心配もあります。値が無視されるなら、残しておくと害があるのか。消さないといけないのか。

公式の記述は「値を無視する」までです。残しておくと順位やインデックスに悪影響がある、とは書かれていません。ですから、急いで消す理由はありません。止めるべきなのは「値を調整する作業」のほうです。

一方で、消すかどうかを決める前に確かめたいことが2つあります。1つは、Google 以外の仕組みがこの値を読んでいないか。社内の検索システムや、ほかの検索エンジン向けの設定として使っている場合があります。公式ドキュメントが述べているのは Google の扱いだけで、ほかの仕組みの扱いはここからは分かりません。もう1つは、出力を止める変更で XML が壊れないか。前の節で見たとおり、値は無視されても XML の誤りはエラーになります。

この2つに問題がなければ、出力を止めてファイルを軽くしておくと、次に見る人が「この値に意味があるのか」と迷わずに済みます。

点検チェックリスト

• priority / changefreq の値を調整する定例作業がない
• 出力を止める場合、Google 以外にその値を使っている仕組みがないか確認した
• lastmod がサイトマップの生成時刻ではなく、各ページの実際の更新日になっている
• lastmod の日付形式について、Search Console でエラーが出ていない
• <loc> が全件 200 を返し、リダイレクト元やパラメータ付きURLが混ざっていない
• 変更後、Search Console のサイトマップ レポートで読み込み結果を確認した

サイトマップに載せるURLそのものの選び方は、サイトマップに載せるURL・載せないURLの判定基準にまとめています。loc の点検で外すURLに迷ったら、あわせて確認してください。