サイトマップの作り方｜XML・HTMLの使い分けと送信後の確認

サイトマップは、検索エンジンへURLを知らせるXMLファイルと、利用者がページを探すHTML一覧を分けて設計します。作成より先に、載せる正規URLと更新の責任者を決めましょう。送信できたことと各ページが検索に登録されたことは、別の確認です。

XMLとHTMLサイトマップの目的と必要性

XMLサイトマップはページの発見を助けるファイル、HTMLサイトマップは人が目的のページへ進むための案内です。両方を作ること自体を目標にする必要はありません。小規模で各ページへ適切なリンクがあるサイトでは、XMLサイトマップが必須とは限りません。

Googleのサイトマップ概要は、大規模サイト、新しいサイト、複雑なメディア構成など、活用が役立つ状況を説明しています。ファイルを置いても、クロールや登録が保証されるわけではありません。

掲載する正規URLと除外する転送元を選ぶ

掲載するのは、検索に出したい正規URLです。通常は、最終的に200で内容を返すURLを選び、noindex、削除済み、重複する別名、転送元は除きます。リダイレクトの転送先を一律に除くのは逆です。転送先が正規の公開ページなら掲載候補になります。

架空例で旧パス /old-guide が /guide に恒久転送されるなら、掲載するのは /guide です。両方を閲覧可能なまま残す場合は代表URLを決め、内部リンク・サイトマップ・canonicalの希望をそろえます。Googleの重複URLの正規化説明にあるとおり、canonicalは検索エンジンに対するシグナルであり、指定の強制ではありません。

CMS生成と手作成の方法を選ぶ

更新が多いサイトでは、CMSが正規URLの採否と最終更新日を反映できるかを確認して自動生成を選びます。既存機能の出力を先に調べ、複数の生成機能を重ねて競合するファイルを作らないようにします。

手作成はURLが少なく、追加・削除のたびに担当者が更新できる場合に向きます。作成ツールがクロールで見つけたURLを、そのまますべて公開する必要はありません。管理画面、検索結果ページ、不要なパラメータ付きURLが混ざっていないか確認します。機能・料金・生成上限は選ぶ製品の現行仕様で確認してください。

XMLの必須項目・lastmod・ファイル上限を確認する

GoogleのXMLサイトマップ作成仕様に従い、urlsetに名前空間を指定し、各url内に絶対URLのlocを置きます。文字コードやXMLのエスケープも確認します。lastmodは重要な内容の最終更新を正確に表せる場合に使い、毎日一律に今日の日付へ変えません。Googleはpriorityとchangefreqを無視するため、これらの値で検索順位やクロール優先度を操作しようとしないでください。

次は架空の2ページを掲載する最小構成の記入例です。表の各行はurl要素1個に対応し、loc以外を無理に追加する必要はありません。実ファイルのurlset・名前空間・終了タグは公式例に合わせ、下記URLを自社の絶対URLへ置き換えます。

1ファイルの上限は50,000 URLまたは非圧縮で50MBです。どちらかを超えるなら分割し、サイトマップインデックスでまとめます。圧縮後のサイズだけで判断しないでください。

公開ファイルの取得・構文・掲載URLを検証する

公開後は、サイトマップURLがログインやエラーページではなくXMLを返すかを調べます。取得できても構文に誤りがあれば処理できないため、ファイル取得と構文検証を分けます。生成元の一覧とも照合し、対象URLの漏れや不要URLの混入を確認してください。

• ファイルのHTTP応答と内容を確認する。
• locが意図したホスト・言語・絶対URLになっているか確認する。
• 掲載ページの応答、canonical、noindexの有無を確認する。
• 追加・削除・転送の例を少なくとも1件ずつ照合する。

サイトマップの整合が取れていても、本文やリンクの問題が解消された証拠にはなりません。発見を助ける仕組みとして、通常の内部リンクと併用します。

Search Consoleの送信と各URLの登録を分けて確認する

Search Consoleのサイトマップ画面からURLを送信し、取得・解析の状態を確認します。robots.txtから場所を知らせる方法もあります。サイトマップレポートの公式説明にある成功表示を、全URLのインデックス登録成功と読み替えないことが大切です。

送信、ファイル取得、URL発見、ページのクロール、登録、検索での表示は別の段階です。重要なURLはURL検査で確認し、検出未登録とクロール済み未登録を区別します。検索パフォーマンスに行がない場合も、それだけで未登録とは判断できません。必要な証拠を段階ごとに残しましょう。

HTML一覧を利用者の探し方で設計する

HTML一覧は、URLの文字列順より利用者の探し方を優先します。架空の業務サービスサイトなら「導入を検討する」にサービス概要・料金・導入手順、「利用中の疑問を解決する」に操作案内・問い合わせを置く設計が考えられます。

リンク名は移動先が分かる言葉にし、通常のナビゲーションからも必要なページへ到達できるようにします。Googleのクロール可能なリンクの説明に沿ってリンクを確認し、HTML一覧を孤立したページの唯一の入口にしないでください。大量のリンクで見渡しにくくなるなら、カテゴリ別一覧への分割も検討します。

更新・削除・転送を反映する運用台帳

生成を自動化しても、URL変更や削除の運用確認は残ります。変更理由、転送元と転送先、掲載対象、確認日を記録すると、古いURLが再び混ざったときに調べやすくなります。次の一行例は架空です。

更新後にファイルだけでなく主要URLも読み返します。送信結果、URL検査、検索表示は別欄に残し、確認できた範囲から対応してください。

次に確認する内容に合わせて、SEOを考えたURL設計｜命名・パラメータ・変更時の確認表、ページ表示速度の評価と改善｜Core Web Vitalsと成果を分けて考える、SEOの始め方｜初心者向けの確認・企画・公開・改善手順、ミラーサイトとは？正当な複製・重複URL・無断コピーの対処も参照してください。