XMLサイトマップとは？作り方とサーチコンソールへの送信方法

新規サイトの公開やリニューアルでは、ページを公開するだけでなく、検索に表示させたいURLを検索エンジンへ正しく伝え、公開後も確認できる状態を整える必要があります。XMLサイトマップはそのためのファイルですが、作成・送信だけで検索結果への表示が決まるわけではありません。

この記事では、XMLサイトマップの役割、掲載URLの選び方、作成方式、Google Search Consoleへの通知、送信後の確認、更新・移行時の運用を実務の順番で解説します。読後には、正規の公開URLを選び、通知・確認・継続運用する手順を自社の公開工程へ組み込めるようになります。

XMLサイトマップは、検索に表示させたい正規URLの発見を補助する仕組みです。作成・通知後も、取得状況と重要URLの状態を分けて確認します。

01SectionXMLサイトマップとは？HTMLサイトマップとの違い

XMLサイトマップは検索エンジン向け、HTMLサイトマップは訪問者向けです。どちらも重要ページへの内部リンクの代わりにはなりません。

XMLサイトマップは、サイト内で検索エンジンに見つけてほしい重要なURLを、機械が読み取れる形式で伝えるファイルです。GoogleはサイトマップをURL発見とクロールの補助に利用します。基本的な役割は、Google Search Centralのサイトマップ概要で確認できます。

HTMLサイトマップもURLを一覧にしますが、主な読み手と目的が異なります。HTMLサイトマップがあるからといって、検索エンジン向けのXMLサイトマップの管理が不要になるわけではありません。

XMLファイルをブラウザで開いたときにタグとURLが表示されても、それだけで異常とはいえません。ただし、ブラウザ表示だけで良否を判断せず、ログインなしで取得できること、掲載URLが意図どおりであること、Search Consoleで取得・処理状況を確認することが重要です。

また、XMLサイトマップもHTMLサイトマップも、重要ページへの内部リンクを置き換えるものではありません。重要なサービスページや問い合わせページなどは、通常のサイト内導線からもたどれるように設計します。

02SectionXMLサイトマップは必要か、どのURLを載せるか

通常運用では、検索に表示させたい正規の公開URLを掲載候補にします。公開状態や検索方針に矛盾があるURLは、掲載前に設定を確認します。

重要ページが内部リンクで十分にたどれる小規模サイトでは、XMLサイトマップが常に必須とは限りません。一方で、新規公開直後のサイト、URL数や階層が多いサイト、公開・削除・URL変更が頻繁なサイトでは、URLの発見と管理を補助する手段として有用になりやすいといえます。

特に、検索対象ページがおおむね500ページ以下で、ホームページから重要ページへ内部リンクで到達でき、検索に表示させたい画像・動画・ニュース用のページが多くない場合、Googleはサイトマップが不要なケースがあると案内しています。これは一律の不要基準ではなく、内部リンクとサイト構成を見直すための目安です。

掲載原則は「Google検索に表示させたい正規の公開URL」

通常運用で掲載する基準は、Google検索に表示させたい正規の公開URLです。URLは相対パスではなく、https://から始まる絶対URLで記載し、プロトコル、ホスト名、末尾スラッシュ、パラメータの扱いを正規表記にそろえます。詳細な要件は、Google Search Centralのサイトマップ作成・送信ガイドを確認してください。

掲載前に確認したい用語を、サイトマップとの関係で整理します。

次の順番で確認すると、サイトマップに入れるURLと、先に設定を見直すURLを分けやすくなります。

robots.txtでクロールを禁止すると、ページ内やHTTPヘッダーで指定したnoindexをGoogleが読めない場合があります。「robots.txtで止めているから検索結果にも出ない」とは扱わず、検索対象外にする目的と設定の組み合わせを確認してください。noindexとクロール制御の関係は、Google Search Centralのrobots metaタグ仕様で確認できます。

技術担当へは、「対象URL群について、HTTP応答、canonical、noindex、robots.txt、ログイン制御、リダイレクトを確認し、Google検索に掲載する正規URLを確定してください」と依頼すると、確認範囲を共有しやすくなります。

なお、ここでの判断は通常運用を前提としています。PDF、絞り込みURL、ページネーションなどは一律に掲載可否を決めず、検索方針と正規URLの設計に基づいて判断します。URL変更を伴う移行中の旧URLは、後述する監視のために別の扱いになることがあります。

03SectionXMLサイトマップの作り方：自動生成・開発・手動の選び方

作成方式は、XMLを編集できるかどうかだけでなく、更新頻度、URL数、公開条件の複雑さ、障害時に対応できる体制で選びます。重要なのは、どの方式でも「誰が更新し、誰が反映を確認し、問題時に誰へ連絡するか」を決めることです。

手動作成・出力実装で押さえる最低限の仕様

手動作成や開発実装では、UTF-8、XML構文、絶対URLを守ります。lastmodは、重要な更新日時を正確かつ一貫して出せるURLだけに使用してください。更新頻度や優先度を示す項目に依存せず、URLの選定と内部リンクを優先します。

1ファイルのURL数・容量には上限があるため、対象サイトのURL数が多い場合は分割やサイトマップインデックスを検討します。配置場所、分割条件、lastmodの扱いを含む現行仕様は、実装前にGoogle Search Centralのサイトマップ作成・送信ガイドで再確認してください。

サイト全体の検索対象URLを扱う場合は、サイトルートへの配置を基本に考えます。下位ディレクトリに置く場合や、複数のホストを扱う場合は、掲載できるURLの範囲に関わるため、構成に合わせて公式要件を確認します。

robots.txtでの通知も準備する

robots.txtには、Sitemap:フィールドでサイトマップの完全URLを記載できます。たとえば、サイトマップの場所を検索エンジンへ伝えるために、Sitemap: https://example.com/sitemap.xmlのように記載します。記述方法はGoogleのrobots.txt仕様を確認してください。

ただし、robots.txtでの通知は、Search Consoleで送信したことと同じではありません。通知方法と確認方法は、次の章で分けて整理します。

04SectionGoogle Search Consoleへサイトマップを通知する方法

Search Consoleでは公開済みサイトマップの場所を通知します。送信後は、検索表示の有無ではなく、まず取得・処理状況を確認します。

Search Consoleでのサイトマップ送信は、ファイルをGoogleへアップロードする操作ではありません。公開済みのサイトマップファイルがどこにあるかをGoogleへ知らせる操作です。送信前には、対象プロパティ、公開済みサイトマップURL、送信者の権限を順に確認します。

ドメインプロパティとURLプレフィックスプロパティでは対象範囲が異なるため、公開サイトとサイトマップURLを適切に含むプロパティを選びます。プロパティの範囲は、Google Search Consoleヘルプのプロパティ設定で確認できます。

送信条件や表示内容は変更されることがあるため、操作時にはGoogle Search Consoleヘルプのサイトマップレポートを確認してください。

所有者権限がない場合の選択肢

所有者が不明、または自分に所有者権限がない場合は、所有者へ送信を依頼します。権限を得られない場合でも、robots.txtのSitemap:で完全URLを通知する方法があります。

ただし、robots.txt経由でGoogleが発見したサイトマップと、Search Consoleのサイトマップレポートから送信したサイトマップは、同じ送信履歴として扱われません。robots.txtで発見されたサイトマップは、レポートの送信済み一覧で追跡できないため、取得・処理結果をSearch Console上で継続確認したい場合は、所有者による送信と結果共有を依頼するのが実務的です。

05Section送信後は取得・処理と個別URLを分けて確認する

サイトマップの確認と、個別ページがGoogleに登録されているかの確認は別の作業です。サイトマップレポートではファイルの取得・処理を、URL検査では特定URLの状態を確認します。サイトマップが正常に取得・処理されても、すべてのURLのクロールやインデックス登録、検索順位は保証されません。

個別URLの確認には、Google Search ConsoleヘルプのURL検査ツールを利用します。サイトマップの処理に問題がないのに重要URLが検索に現れない場合は、URL検査を起点にHTTP応答、canonical、noindex、robots.txt、内部リンクなどを切り分けてください。インデックス未登録の原因と対処を詳しく確認したい場合は、サイトがインデックスされない原因と対処法を参照してください。

06Section通常更新とリニューアル時の運用

通常更新では、サイトマップを毎回手動送信すること自体を目的にせず、新規公開・削除・URL変更がサイトマップへ正しく反映されたかを確認します。自動生成なら実ファイルの出力結果を、手動管理なら更新済みファイルを確認します。新しいサイトマップへの切り替えや大幅変更、取得・構文上の問題を修正した後は、所有者による送信・再送信と処理結果の確認を検討します。

URL変更を伴うリニューアルは、通常更新と別に管理する

URL変更を伴うリニューアルでは、サイトマップだけを更新して終わりにはできません。旧新URLの対応を整理し、旧URLから対応する新URLへ恒久的リダイレクトを設定します。加えて、新URLのcanonical、内部リンクの参照先、新URLを含むサイトマップ、旧新サイトマップの監視方針をまとめて確認します。詳しい移行要件は、Google Search CentralのURL変更を伴うサイト移行ガイドを参照してください。

公開・引き渡しの工程全体で確認したい項目は、Webサイト公開の進め方もあわせて確認すると、サイトマップ以外の公開作業との抜け漏れを防ぎやすくなります。