サーチコンソールのサイトマップ送信手順｜成功・取得エラー・登録状況の確認

2026年6月4日

著者: 与謝秀作

Search Consoleへのサイトマップ送信は、Googleに確認してほしいURLの一覧を知らせる方法です。送信が成功しても、すべての記事がクロール・登録されたとは限りません。ファイルの取得、現在のURL掲載、個別ページの状態を分けて確認すると、取得エラーと登録の問題を混同せずに対応できます。

サイトマップの送信でできることと、保証されないこと

サイトマップは、サイト内のURLと必要な更新情報を機械が読み取れる形でまとめたファイルです。送信はファイルをGoogleへアップロードする操作ではなく、公開済みファイルの場所を知らせる操作です。実際のファイルはCMSやサーバー側で生成・公開します。

Googleのサイトマップ作成・送信ガイドは、サイトマップをクロールのヒントとして扱い、クロールやインデックス登録を保証するものではないと説明しています。送信済みURL数が増えても、検索表示やクリックが増えた証拠にはなりません。まず「何を確認したいか」を取得と個別登録に分けましょう。

送信前の確認：プロパティ・所有者権限・XMLのURL

最初に、対象サイトのSearch Consoleプロパティを選びます。URLプレフィックスプロパティでは、http/https、wwwの有無、対象パスが一致しているかを確認します。ドメインプロパティでは対象範囲が異なります。表示中のサイト名だけでなく、選択したプロパティの範囲を確かめます。

送信するには必要な所有者権限を確認します。Search Consoleのサイトマップレポートの説明を参照し、権限が足りない場合は管理者へ依頼します。別の権限やサイトの認証を不用意に変更する必要はありません。

CMSや生成プラグインの案内から、実際のサイトマップURLを取得する。
ログインなしでGoogleが取得できる公開先かを確認する。
XMLなのか、XML一覧のインデックスなのかを確認する。
対象URLと確認日時、選択プロパティを記録する。

ブラウザに表示されない場合も、そのエラーが端末や拡張機能由来か、サーバー由来かを分けます。手元の表示不能だけでGoogleも取得できないとは断定しません。

通常のサイトマップとサイトマップインデックスを用意する

通常のXMLサイトマップはurlsetの中にページごとのurlを並べ、locにそのページの絶対URLを入れます。サイトマップインデックスはsitemapindexの中にsitemapを並べ、locに子ファイルの絶対URLを入れます。次の表は構造の説明用であり、貼り付けて使う完成XMLではありません。

ファイルの例	簡略化した構造	掲載する内容
通常のサイトマップ	urlset → url → loc	記事A・記事Bそれぞれの絶対URL
2つの子を持つインデックス	sitemapindex → sitemap → loc を2件	記事一覧用XML・固定ページ用XMLの絶対URL

たとえば通常ファイルの要素関係は「<url><loc>記事Aの絶対URL</loc></url>」です。実際のXMLでは名前空間等も必要なので、CMSの生成結果を公式仕様と照合してください。

Googleの作成ガイドでは、UTF-8、絶対URL、正規として扱いたいURLを使用し、1ファイルの上限は非圧縮50MB・50,000URLです。大きい場合は分割し、サイトマップインデックスの案内に沿ってまとめます。lastmodを出すなら、日付を毎日一律に変えるのではなく、本文等の実際の重要な更新と対応させます。

Search Consoleへ送信し、最終読み込みとステータスを確認する

プロパティ内でサイトマップのレポートを開き、新しいサイトマップの入力欄を確認します。画面がどの部分を補っているかを見て、必要なURLを入力します。「必ず末尾の相対パスだけ」と決めつけず、選択プロパティと表示された入力形式に合わせます。送信後は一覧から詳細を開き、結果を記録します。

項目	確認できること	それだけでは分からないこと
送信したURL・日付	どこをいつ知らせたか	その後の取得・登録
最終読み込み	Googleが最後に読み込んだ時点	現在のXMLと同じ内容か
成功	対象ファイルの取得・読み取りが成功したこと	各記事の登録や検索表示
取得不可・構文エラー	ファイル取得や読み取りで問題があること	本文品質が原因かどうか
検出ページ数	ファイルから認識したページ数	登録済みURL数・クリック数

Googleは送信済みサイトマップを再取得しますが、記事を更新するたびに即時取得されるという意味ではありません。大きな変更や継続する取得失敗では詳細を確認し、再送信を検討します。毎日同じファイルを送り直すことを登録の保証として扱わないようにしましょう。

取得・HTTP・構文エラーを証拠から切り分ける

「取得できませんでした」と表示されたときは、推測でCMSを変更する前に正確なURLと詳細メッセージを残します。サイトマップファイルの失敗と、子ファイルや掲載記事の失敗が同じとは限りません。

観察した証拠	原因候補	確認する担当・作業
404等のHTTP応答	URL違い・未生成・公開先の変更	生成元と実際の公開先を確認
認証画面や拒否応答	ログイン要求・アクセス制限	サーバー管理者とGoogle側の取得を確認
XMLの解析エラー	壊れた要素・文字・出力混入	エラー箇所と生成内容を照合
特定ブラウザだけの表示失敗	拡張機能・端末環境等	端末エラーをGoogleのエラーとして記録しない
ファイルは取得成功、記事が未登録	URL掲載や個別ページの状態等	URL検査で別に調べる

パラメータ付きURLというだけで不正と決めたり、プラグインを入れ直したりするのは早計です。応答、リダイレクト、アクセス制限、構文を順に確認し、再確認した日時と結果も残します。

送信後は個別URLの掲載・canonical・登録状態を別々に追う

最後に重要な記事を1つ選び、現在のXMLにあるかとGoogleでの状態を別々に追います。サイトマップレポートの成功やURL検査に過去のサイトマップ参照があることは、現ファイルへの掲載を直接確認した証拠ではありません。

記録項目	架空の記入例
記事の識別	対象記事Aの正規候補URL
現在XMLへの掲載	2026年10月11日に内容を直接確認し、掲載あり
サイトマップ最終読み込み	2026年10月10日・成功
URL検査の状態	検出・インデックス未登録
最終クロール・canonical	表示された値をそのまま記録。該当なしは推測しない
次の確認	取得可否と内部リンク等を確認し、状態の変化を追う

これは送信成功と未登録が両立する架空例です。GoogleのURL検査ツールの説明に沿って、保存された登録情報と公開URLテストを区別します。ライブテストで取得できても登録は保証されません。未認識、検出未登録、クロール済み未登録、登録済みを分け、原因を本文だけに限定せず、証拠に合わせて次の作業を選びます。

次の実務に進むための関連記事です。