XMLサイトマップを送信した後の確認 URLと公開状態の見方

XMLサイトマップを送信した後の確認 URLと公開状態の見方

XMLサイトマップに掲載するURL、提出先、読み取り状況、重要ページの公開と検索登録を順番に確認します。

XMLサイトマップを送信した後は、提出先のプロパティとファイルの読み取り状況を見て、重要なURLを実際に開きます。XMLは検索エンジンに知らせるURLの一覧です。ファイルが読まれること、各ページが閲覧できること、検索のインデックスに登録されることは別々の確認項目です。



公開ページの一覧をサイトマップにまとめるイメージ


XMLと人向け一覧を区別する

ホームページには、読者がページを探すサイト案内と、検索エンジン向けのXMLサイトマップがあります。人向けの一覧には、読み手が選べる言葉でカテゴリやページへのリンクを置きます。XMLには、検索結果に掲載してほしい代表のURLを指定します。両方を用意する場合は、生成される場所と、どのページを含めるかを別々に確認します。


最初に、実際のサイトマップのURLと、誰が生成・更新するかを書きます。編集用のファイルと公開されているXMLが別の場合は、公開側をブラウザーで開きます。XMLが想定したサイトのURLを含み、ログインやエラー画面に転送されないかを見ます。複数のXMLを分けて管理する構成なら、どのファイルがどの範囲を扱い、一覧をまとめるファイルがあるかを確認します。


サイトマップを作成ツールが出す場合も、設定の名称だけでは判断せず、公開先に生成された実際のファイルを照合します。下書き、検収用のURL、以前の公開先が混ざらないようにし、対象に入れるページの決め方を担当者へ共有します。


人向けの一覧を更新した時も、XMLが自動で変わるとは限りません。反対にXMLに載ったページでも、人が一覧から探せるとは限りません。例えば予約への導線はメニューや関連ページで確かめ、新しい記事がXMLに入っているかは生成結果で別に見ます。用途ごとに確認する人と場所を決めます。

提出前に掲載URLを点検する

正規のURLを載せる

プロトコル、ドメイン、パスまで含む完全なURLを使用し、現在公開する正式なURLにそろえます。同じ内容を複数のURLで閲覧できる場合は、どれを代表として使うかを確認します。本文中のリンクと正規URLの指定も照合します。最終更新日を載せる場合は、本文やリンクなどの重要な内容を実際に更新した日を使い、ファイルを作り直しただけの日をすべてのページへ割り当てないようにします。


下書きや転送先の扱いを確認する

利用を終えた資料、下書き、別のURLへ転送される旧ページは、原則として現在の案内用の一覧に含めるかを見直します。検証用のXMLに二つのURLを載せてブラウザーで開くと、一つは200で表示され、もう一つは410で提供終了でした。ローカルの試験であり、検索へ送信した結果ではありません。XMLを作れたことに加えて、載っているURLを確かめる理由を示しています。


点検する項目 見るもの 対応の例
正規URL 公開URLとHTMLの指定 表記を統一
公開状態 実際の応答と画面 下書きや提供終了を除く
転送 最終的に開くURL 現在のページへ合わせる
更新日 重要な変更の記録 作り直した日と区別

正規URLの候補には、大文字小文字、末尾のスラッシュ、ファイル名の有無、計測用の付加情報で表記が異なるものが含まれます。見た目が同じでも運用上の代表を確認し、転送、本文のリンク、XMLの記載が食い違う場合は、どの設定を正とするかを担当者と決めます。



サイトマップ内のURLを実ページとレポートで確認する図
検証用XMLの2件をブラウザーで確認した例です。各項目は本文でも確認できます。

プロパティと提出先を照合する

Search Consoleのサイトマップレポートを開く場合は、先にサイトのプロパティを確認します。URLプレフィックスのプロパティでは、設定したURLの範囲に含まれるかを照合します。ドメインのプロパティを利用する場合も、提出したファイルとその中に掲載されている公開先を確認します。別の事業や検証先のプロパティを選ばないよう、URLとアクセス権限を運用担当者とそろえます。


次に、サイトマップを提出したURLと、最後に読み取られた状態を見ます。取得できない場合は、公開先でXMLが開くか、生成されている場所が変わっていないか、ログインや転送が必要になっていないかを確認します。形式に関する指摘がある場合は、生成結果で該当する記述を見ます。ファイルの提出を繰り返す前に、公開先の不一致、ファイルの取得、掲載URLのうち、どこを直す必要があるか整理します。


サイトマップが取得できない場合は、いきなり本文を作り直す必要はありません。公開されているXMLのURLを開き、そこに画面表示のHTMLが返っていないか、提出先のプロパティに合うかを確認します。生成担当と提出担当が異なる場合は、ファイル名と公開URLを一緒に引き渡します。

重要URLを抜き取って確認する

全部のURLを毎回見る代わりに、トップ、申込み、サービス詳細、新しく追加した記事など、役割の違うページから抜き取って確認します。対象URLをブラウザーで開き、ページの内容が合っているか、メニューや関連記事からもたどれるかを見ます。サイトマップには入っているが、利用者がどこからも進めないページが見つかった場合は、必要なリンクを本文やカテゴリに置くことを検討します。


Search ConsoleのURL検査では、インデックス上の情報と、現在の公開ページに対するテストを分けて確認します。公開先を開けたという結果だけで、検索に登録されたことを判断しないようにします。登録されない理由を調べる場合は、正規URL、取得の状態、検索向けの指示、内部リンクを、確認できる範囲で順に見ます。対象を広げる前に、代表のURLでどの条件が異なるかを確かめます。


確認表に「ブラウザーで読めた」「XMLにある」「URL検査で確認した」の三欄を置きます。例えば重要ページの一つで正規URLが想定と違うなら、そこだけを対象に本文のリンク、転送、公開状態の差を確認します。同じ問題が代表ページで繰り返される場合に、確認範囲を広げます。

再生成と再確認の条件を決める

ページを増減したとき、URLを変更したとき、公開を停止したときに、XMLの再生成と提出済みの場所を確認します。新しい記事を公開した場合は、編集画面と公開されたHTML、XMLに同じURLが出ているかを見ます。生成時に一部のページが意図せず含まれた場合は、対象の公開状態とサイトマップの設定を確かめます。


作業の記録は、サイトマップURL、更新日、変更した掲載範囲、読み取られた状態、抜き取ったURLを一行にまとめます。検索結果への反映日を確定して扱う代わりに、次にレポートを見る日を決めます。構成変更の規模が大きい場合は、公開を続けるURLと提供を終えたURLを先に一覧にし、元のリンクの見直しとXMLの更新を同じ作業で追えるようにします。


定期的に記事を加えるサイトでは、公開が成立した時点で掲載URLを確認し、取り下げた記事が一覧に残っていないかも見ます。検索へ同じファイルを再提出する回数より、内容と公開範囲が合っていることを点検の中心にします。


確認に使った資料

情報確認 2026/11/09。製品・サービスの仕様は参照先でご確認ください。