この記事の内容
  1. 公開一覧と掲載URLを照合する
  2. lastmodが何の変更を表すか決める
  3. 一言語だけ料金を直した場合の例
  4. 実際に配られるファイルとページを見る
  5. 規模だけで有料化を決めない
  6. 移行時は日時の意味も引き継ぐ

公開一覧と掲載URLを照合する

まず現在公開する記事、料金、カテゴリ、言語版のURLを用意し、サイトマップにある一覧と照合します。管理画面、未完成の翻訳、存在しない記事、転送前の旧URLが混ざっていないかを調べます。正常にXMLを返すことだけでは、掲載する対象の正しさは分かりません。各URLがどの役割で検索入口になるかを確認し、canonicalの方針とも合わせます。旧URLを消す判断と、そのURLの転送や終了の扱いも別に記録してください。サイトマップから外しただけで公開や検索の状態がすべて変わるとは考えません。一覧は機械の発見を助ける資料であり、ページの実際の内容やアクセス制御の代わりではないことを前提にします。

lastmodが何の変更を表すか決める

Googleの現行案内は、lastmodをページの重要な更新の日時として扱い、本文、構造化データ、リンクなどの変更を例にしています。一方、著作権年の変更だけを同じ更新として扱う例ではありません。サイトの実装では、生成した時刻、調査した日、公開した日、本文を直した日が別に存在することがあります。どの記録を使うかを編集と開発で決め、取得できない日時を毎回の現在時刻で補わないようにします。価格の根拠を再確認して内容が変わらなかった場合も、実際にどこを直したかを分けて残します。新しい日付を増やすことが目的ではなく、値が表す変更を後から説明できることが目的です。

一言語だけ料金を直した場合の例

仮に日本語の料金記事で契約条件を直し、英語版はまだ確認中とします。更新する本文と掲載する各URLの状態を点検し、言語ごとの実際の反映を残します。共有の製品表が両方へ出るなら、その影響も確認してください。すべての日付を揃えるために未確認の英語本文を更新済みと扱わず、必要な翻訳修正を担当者へ渡します。反対に、共通の表やリンクが全記事へ影響したなら、その変更が各ページで重要かを確認します。日付だけの一致より、読者が見る条件と元資料が整合することが重要です。この例は更新管理の考え方であり、特定のサイトが誤った値を出しているという実測ではありません。

実際に配られるファイルとページを見る

生成コードだけでなく、公開URLから得るサイトマップと代表ページを確認します。キャッシュや公開環境の違いで古い一覧が残る場合は、どの時点の内容を見ているかを切り分けます。新記事、改稿した記事、変更していない記事、削除した記事を代表例として比べると、一律更新や反映漏れを発見しやすくなります。ページが転送される場合は最終URLと方針を確認し、掲載した文字列だけで合格にしません。適切な文字コード、絶対URL、必要な分割も現行仕様で照合します。ファイルが取得できたこと、項目が正しいこと、Googleが扱ったことはそれぞれ別の確認として記録してください。

規模だけで有料化を決めない

数千ページのサイトでも、公開データから正確な一覧を作り、代表例と差分を確認できるなら、特定の有料契約が自動的に必要になるわけではありません。クローラーで大量の応答や参照を照合するなら、対象URL、保存、比較、実行負荷を見積もります。無料枠で全体を調べられない場合は、点検した範囲を明示し、未確認を正常として扱いません。費用には生成の実装、編集者の変更記録、翻訳の追随、公開後の確認も含めます。lastmodを新しくするだけで順位が上がるという前提で予算を決めず、公開と更新の整合を維持するために何が不足するかを具体化してください。

移行時は日時の意味も引き継ぐ

CMSや配信方式を替える前に、各URLの役割、重要な更新日時、その根拠、現在のサイトマップを保存します。移行先に同じ項目名があっても、作成時刻や最終保存時刻を指す場合があるため、値の意味を照合します。担当者交代では、どんな編集が日時を変え、どの変更は変えないかの例を渡してください。旧ツールの出力や履歴へ必要な期間アクセスできるかは、現在の条件で確認してから整理します。移行後は旧新URL、改稿例、未変更例を再確認し、Google側の処理は別に追います。日付の新しさを成果と呼ばず、正しい変更が反映され続ける運用を完了条件にします。

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について