Search Consoleでサイトマップの異常表示に戸惑っていませんか。
サイトマップがHTMLで返るとクローラーが解析できず、インデックス漏れやカバレッジエラーを招く可能性があります。
この記事では登録URL、XMLフォーマット、Content-Typeヘッダー、HTTPステータス、リダイレクト、robotsや認証といった主要な原因を順に点検し、WordPressプラグインや静的・動的なXML出力、Search Consoleでの再送信まで実践的に解説します。
まずは原因の切り分けから始め、優先的に対処する手順を本文で確認しましょう。
サイトマップがHTMLです
Search Consoleで「サイトマップがHTMLです」と表示された場合、サイトマップとして送信されたファイルがXMLではなくHTMLで返されている可能性が高いです。
ここでは原因の特定と確認方法、対処の方向性をわかりやすく解説します。
登録URLの確認
まずはSearch Consoleに登録したサイトマップのURLを目視で確認してください。
多くのミスは単純に誤ったURLを登録していることに起因します。
例えばサイトのトップページやHTMLでレンダリングされる一覧ページをそのまま登録していると、XMLではなくHTMLが返されます。
末尾のスラッシュやクエリパラメータの有無も見落としやすいので注意が必要です。
サイトマップのURLは通常 sitemap.xml や sitemap_index.xml といったファイル名になります。
XMLフォーマットの確認
次にファイル自体が正しいXMLフォーマットであることを確認します。
XMLヘッダーやurlsetのnamespaceが抜けていたり、特殊文字がエスケープされていないとHTMLとして扱われることがあります。
下記はSearch Consoleでエラーになりやすいポイントです。
- XML宣言の欠如
- 不正な文字エンコーディング
- アンパサンドの未エスケープ
- HTML要素が混入している
- xmlns属性の誤り
自分で生成している場合は生成ロジックを見直し、配布されたプラグインを使っているなら設定やバージョンを確認してください。
Content-Typeヘッダー
サーバーが返すContent-Typeヘッダーが適切でないと、Search ConsoleがHTMLとして認識することがあります。
サイトマップは一般的に application/xml または text/xml を返すべきです。
text/html が返っている場合はブラウザ向けHTMLを返していると判定されますので、サーバー設定の修正が必要です。
確認にはブラウザの開発者ツールや curl -I コマンドが便利です。
HTTPステータスコード
サイトマップに対するHTTPステータスコードも重要な判断材料です。
| ステータスコード | 意味 |
|---|---|
| 200 | 正常に取得できる |
| 301 | 恒久的に別URLへ移動 |
| 302 | 一時的に別URLへ移動 |
| 404 | 存在しない |
| 401 403 | 認証やアクセス制限がかかっている |
サイトマップは基本的に200で直接XMLが返るべきです。
リダイレクトやエラーステータスが返っている場合は、後述のリダイレクト設定や認証を確認してください。
リダイレクト設定
サイトマップを別の場所へリダイレクトしているとHTMLが返される場合があります。
例えば sitemap.xml からトップページへ301で飛ばす設定だと、Search Consoleはその先のHTMLを読み取って「HTMLです」と判断します。
サイトマップは可能な限り直でアクセスできるURLにして、不要なリダイレクトは解除してください。
CMSやロードバランサーの設定で意図せずリダイレクトが発生しているケースがあるので、関係する設定を洗い出すとよいです。
robots.txtとクロール制限
robots.txtでサイトマップのURL自体がブロックされていないか確認してください。
また、robots.txtにSitemapディレクティブを記述しているかどうかもチェックポイントです。
Search Consoleのrobots.txtテスターやオンラインのチェックツールで問題の有無を検証できます。
クロール制限を厳しく設定しているとSearch Consoleが正しく取得できないことがあります。
認証とアクセス制限
サイトマップがベーシック認証やIP制限の内側にある場合、Googlebotはアクセスできません。
Search Consoleに登録していても認証が必要なリソースはクロールされないため、HTMLエラー表示につながります。
可能ならサイトマップへのアクセスは公開にし、一時的に制限を解除してから再送信することをおすすめします。
どうしても公開できない場合は、認証のない環境で生成した静的なXMLを用意する運用に切り替えてください。
Search Consoleでの確認手順
Search Consoleはサイトマップの送信状況や検出された問題を詳しく確認できる、重要なツールです。
ここでは画面上で何を見ればよいか、どの順序で確認すれば効率的かを具体的に説明します。
サイトマップ送信画面の確認
まずはプロパティを選択し、サイトマップの送信画面を開いてください。
送信済みのサイトマップ一覧と、各サイトマップごとのステータスが表示されますので、送信が正しく処理されているかを確認します。
- サイトマップURL
- 送信日時
- インデックス登録済みの件数
- 送信エラーの有無
- 最後の読み取り日時
特に最後の読み取り日時が古い場合は、サイト側での出力場所やアクセス制限を疑ってください。
送信が失敗している場合は、サイトマップURLをコピーしてブラウザで直接開き、表示内容やステータスコードを確認すると原因特定が早まります。
エラー詳細の取得
サイトマップの行をクリックすると、詳細画面でエラー一覧が表示されます。
ここでは各エラーを種類ごとに確認し、優先度を付けて対応策を検討します。
| エラー種別 | 確認ポイント |
|---|---|
| 構文エラー | XML不正 |
| 不正なURL | ステータスコード400系 |
| アクセス制限 | 403や認証が必要 |
| リダイレクト | 301や302での応答 |
各エラーをクリックすると、該当するURL例や発生箇所を確認できますので、まずは代表的なURLで再現性を確認してください。
カバレッジとの照合
サイトマップで報告された数値とカバレッジレポートを照合すると、実際のインデックス状況が把握できます。
カバレッジ画面で「有効」や「除外」などのステータスを確認し、サイトマップに含まれるURLがどのカテゴリに入っているかを確認してください。
除外になっているURLが多い場合は、除外理由の詳細を見て、robotsやnoindex、重複コンテンツなどの原因を特定します。
必要であればカバレッジから問題のURLをエクスポートし、サイトマップの一覧と突き合わせると作業が効率化できます。
最後に、修正後はサイトマップを再送信し、Search Consoleでの反映状況を追跡することを忘れないでください。
XMLサイトマップを正しく出力する方法
XMLサイトマップは、検索エンジンにページ構造を伝える重要なファイルです。
正しく出力するとクロール効率が上がり、インデックス登録が安定します。
WordPressプラグインで生成
WordPressではプラグインを使うのがもっとも手軽で、手動メンテナンスの負担を減らせます。
多くのプラグインは自動で投稿の追加や更新日時を反映し、定期的にサイトマップを再生成します。
導入時は設定項目や除外ルールを確認し、他プラグインとの競合に注意してください。
- Yoast SEO
- All in One SEO
- Rank Math
- Google XML Sitemaps
静的XMLファイルの作成
静的ファイルは生成が安定していて、アクセス負荷が低いサイトに向いています。
まずはサイト内の公開URL一覧を準備し、XML規格に沿ってURL要素を記述してください。
一般的にはサイトルートにsitemap.xmlというファイル名で配置しますが、配置場所はSearch Consoleに合わせてください。
配信時にはContent-Typeヘッダーをapplication/xmlに設定し、必要に応じてgzip圧縮で配信すると効率的です。
ページ数が多い場合は複数のサイトマップに分割し、sitemap indexを用いてまとめることを推奨します。
動的サイトでの出力設定
動的サイトではリクエストごとに最新のXMLを生成する方式が柔軟で、頻繁に更新する場合に有利です。
専用のルートを用意し、テンプレートでXMLを出力する際にはエスケープやエンコードに注意してください。
必ずUTF-8でエンコードし、Content-TypeヘッダーとHTTPステータスを正しく返すよう設定してください。
認証やアクセス制限のあるページはサイトマップに含めないようフィルタリングを実装してください。
| 方式 | ポイント |
|---|---|
| ルートエンドポイント | レスポンスヘッダー設定 |
| バックグラウンド生成 | 静的ファイル出力 |
| キャッシュレイヤー | TTL設定 |
| 分割とインデックス | sitemap index使用 |
最後に出力結果はXML検証ツールやSearch Consoleで必ず確認し、エラーがあれば修正してください。
運用では定期的な検証とログ監視を取り入れ、サイトマップが常に正しい状態で提供されているかを確認してください。
原因別の対処手順
サイトマップに起因する問題は原因ごとに異なる対処が必要です。
ここでは誤ったURL、Content-Typeの誤設定、リダイレクトに分けて具体的な手順を説明します。
誤ったURLの差し替え
サイトマップ内に存在するURLが間違っていると、Search Consoleでエラーになります。
まずは問題のURLを特定し、正しい正規URLを確認してください。
確認後はサイトマップ側のURLを差し替え、再生成と検証を行います。
- 正しいURLの特定
- サイトマップの該当箇所を編集
- サイトマップの再生成
- Search Consoleで再送信
CMSを使っている場合は、パーマリンク設定やプラグインの出力先をチェックすると効率的です。
また、同一ページに複数のURLが存在する場合は正規化を行い、canonicalタグで一本化してください。
Content-Type修正手順
サイトマップはXMLとして配信される必要があり、Content-Typeヘッダーが重要になります。
サーバーが誤ってtext/htmlなどで返していると、GoogleがXMLとして認識できません。
| 現象 | 対処 |
|---|---|
| text/htmlで配信 | Content-Typeをapplication/xmlに設定 |
| charsetが不一致 | UTF-8で統一 |
| 圧縮時にヘッダー欠落 | サーバー設定を確認 |
Apacheなら.htaccessや設定ファイルでHeader setを利用します。
Nginxならadd_headerで正しいContent-Typeを付与してください。
CDNやリバースプロキシを利用している場合は、配信元とキャッシュ層双方のヘッダーを確認します。
リダイレクト解除と修正
サイトマップにリダイレクト先のURLを記載していると、Search Consoleが警告を出すことがあります。
まずはcurlやブラウザの開発者ツールで実際にどのようなステータスが返るか確認してください。
- リダイレクトチェーンの特定
- サイトマップに最終到達URLを記載
- 不要な301や302を削除
リダイレクトが必要な場合は、サイトマップには最終的に到達する恒久的なURLを記載するのが望ましいです。
特に複数のリダイレクトが連鎖していると、クローラーの負荷や評価の分散につながるため避けてください。
修正後は必ずSearch Consoleで該当サイトマップをテストし、問題が解消されたことを確認します。
検証と再送信の手順
サイトマップを修正したら、検証と再送信を必ず行ってください。
適切な手順で確認すれば、インデックス化の問題を早期に発見でき、検索流入の安定につながります。
ここではXMLの検証ツールの使い方から、Search Consoleへの再送信、更新頻度の目安まで、実務に活かせる手順を解説します。
XML検証ツールの利用
まずはXML構文とフォーマットに問題がないかを確認します。
構文エラーやエンコーディングの不一致は自動巡回で排除される原因になりやすいです。
次のチェック項目を順に確認してください。
- XML構文チェック
- スキーマの適合確認
- URLのエンコード確認
- 文字コードの確認
- ファイルサイズ確認
オンラインのXMLバリデータやブラウザ、コマンドラインのxmllintなどを活用すると効率的です。
エラーが出た場合は該当行を確認し、タグの閉じ忘れや不正な文字を修正してください。
Lastmodの値や優先度タグがある場合は、そのフォーマットもチェックすると良いです。
Search Consoleへの再送信
検証が済んだら、Search Consoleでサイトマップを再送信します。
| 操作項目 | 推奨アクション |
|---|---|
| サイトマップURL | 追加または更新 |
| ステータス | エラー確認 |
| 送信後チェック | カバレッジ照合 |
Search Consoleのサイトマップ画面に移動し、新しいURLを入力して送信ボタンを押してください。
送信直後は即時反映されないことが多いので、ステータスを数時間から数日かけて観察します。
エラーが出た場合は、エラー詳細を開き、原因ページや行番号を元に修正します。
重大な問題が続く場合は、サイトマップを一度削除してから再登録する手順も有効です。
更新頻度と送信タイミング確認
サイト更新の頻度に合わせてサイトマップの再送信頻度を決めてください。
ニュースやECのように頻繁にページが追加されるサイトは毎日または数時間ごとの更新が理想的です。
更新が少ないコーポレートサイトでは、月次や更新時のみの再送信で問題ありません。
自動生成のサイトマップであれば、ページ更新時に自動で再出力し、Search Consoleにpingを飛ばす運用が楽になります。
不要な再送信を繰り返すと監視が煩雑になるので、重要なリリース時や構造的な変更時を優先してください。
最後に、送信後も定期的にカバレッジとサーチパフォーマンスを確認し、改善点を継続的に反映しましょう。
再発防止の運用チェックリスト
サイトマップの不具合を根本から防ぐための運用チェックリストをまとめます。
日々の自動監視と定期的な手動確認を組み合わせ、早期発見と確実な対応を目指します。
各項目に担当者と実施頻度を明記し、変更時は必ずログを残してください。
テストと再送信の手順を標準化し、デプロイ時の確認フローに組み込んでください。
- 毎日 サイトマップ送信ステータス確認
- 週次 XML構文検証
- 週次 Content-Typeとヘッダー確認
- 月次 robots.txtとアクセス権の見直し
- 変更時 リダイレクトとステータスコードの検証
チェックリストは運用ルールとしてドキュメント化し、四半期ごとに見直すことをおすすめします。