自分のサイトのサイトマップはどこにあるか|構成別の場所と、送信前に実際に開いて確かめる手順
自分のサイトのサイトマップはどこにあるか|構成別の場所と、送信前に実際に開いて確かめる手順
Search Consoleにサイトマップを送信しようとして、「自分のサイトのsitemap.xmlがどこにあるのかわからない」で手が止まる。よくある状態です。結論から言うと、sitemap.xmlの場所はサイトの構成で決まります。そして構成ごとの「定番の場所」はあるものの、それを推測のまま送信するのは危険で、必ずブラウザで実際に開いて、中身まで確かめてから送信するのが正しい手順です。
この記事では、構成別の場所の一覧と、開いたときに何を確認すべきかを、当社が実案件で25サイトのサイトマップを統一したときの実測をもとに解説します。
最短の答え:robots.txtを見る
候補URLをあれこれ試す前に、まず一箇所だけ見てください。自分のドメインの後ろに /robots.txt を付けて開く(例:https://example.com/robots.txt)。
このファイルの中に、
Sitemap: https://example.com/sitemap.xml
という行があれば、そこに書かれているURLが答えです。robots.txtのSitemap行は「Googleにサイトマップの場所を教えるための行」なので、まともに設定されたサイトならここに書いてあります。
書いていない場合、あるいはrobots.txt自体が無い場合は、次の構成別一覧から探します。
構成別:sitemap.xmlの定番の場所
| サイトの構成 | サイトマップのURL |
|---|---|
| WordPress(バージョン5.5以降・プラグインなし) | /wp-sitemap.xml |
| WordPress+Yoast SEO | /sitemap_index.xml |
| WordPress+XMLサイトマップ系プラグイン | /sitemap.xml が多い(プラグイン設定による) |
WordPressをサブディレクトリに設置(/wp/など) |
/wp/wp-sitemap.xml のようにサブディレクトリが頭に付く |
| ShopifyなどのASP型EC | /sitemap.xml(自動生成・設定不要) |
| 制作会社が作った静的サイト | /sitemap.xml に手動設置されているか、そもそも無いことも多い |
ここで重要な注意がひとつあります。WordPressにサイトマップ系のプラグインが入っている場合、WordPress標準の /wp-sitemap.xml は機能を止められます。つまり「標準の場所」と「プラグインの場所」の両方が存在するように見えて、実際に生きているのはどちらか片方だけ、という状態が起こります。これが後述する落とし穴の入口です。
また、トップページは自作でブログだけ /wp/ 配下のWordPressに置いている、という二段構成のサイトでは、サイトマップも2つに分かれます。サイト本体用の /sitemap.xml と、ブログ用の /wp/wp-sitemap.xml の両方をrobots.txtに書き、両方をSearch Consoleに送信するのが正解です。
開いたら「表示された」で終わらせない。中身を3点確認する
URLがわかったら、送信前にブラウザで開いて次の3点を確認します。ここを飛ばして送信すると、Search Console上でエラーになってから原因を探すことになり、かえって時間がかかります。
1. XMLとして表示されているか
正常なサイトマップは、<urlset> や <sitemapindex> というタグの中に <loc>https://…</loc> の形でURLが並びます。開いた結果が普通のWebページ(HTML)だったら、そのURLは間違っているか、リダイレクトでどこかへ飛ばされています。
2. 中身が空でないか
<urlset></urlset> とタグだけあって中のURLが0件、という「空のサイトマップ」があります。開くと一応何かが表示されるため、これが一番気づきにくい。Search Consoleは0件のサイトマップをエラーとして扱います。
3. URLの件数がページ数と桁で合っているか
10ページあるサイトのサイトマップに1件しか載っていなければ、それは実質機能していません。1件ずつ数える必要はなく、「桁が合っているか」を見れば十分です。
実例:25サイトを実測したら、同じ構成のはずが3サイトだけ場所が違った
当社は名古屋の美容サロンFCのサイト群25店舗分を管理しており、2026年8月にサイトマップとrobots.txtを全店で統一する作業を行いました。全店が「サイト本体+ /wp/ 配下にWordPressブログ」という同じ構成です。
このとき最初に決めたのが、robots.txtに書くサイトマップURLは、全店一律に書かず、1店ずつ実際に開いて確かめてから書くというやり方でした。結果として、これが正解でした。同じ構成のはずの25店のうち、3店だけWordPress側のサイトマップの場所や挙動が違ったからです。
- 9店にはXMLサイトマップ生成プラグインが入っており、生きているのはプラグイン側の
/wp/sitemap.xml。WordPress標準の/wp/wp-sitemap.xmlは空の<urlset></urlset>を返す状態でした。開けば何か表示されるので一見正常に見えますが、Search Consoleに送ればエラーになります - 1店はパーマリンク設定が初期値のままで、サイトマップのURLを開くとリダイレクトされてHTMLが返ってくる状態でした。この店だけ
/wp/?sitemap=indexという形式のURLが正解でした - 判定は「開いて中身の
<loc>の件数を見る」だけ。全店このやり方で確認してからrobots.txtに書きました
もし「WordPressのサイトマップは /wp/wp-sitemap.xml」という一般論を信じて全店一律に書いていたら、複数の店で存在しない・空のサイトマップURLをGoogleに案内し続けるところでした。構成が同じでも、プラグインの有無や設定ひとつで場所は変わる。これが「送信前に実際に開く」を推す理由です。
実例その2:手書きサイトマップは「更新されない」前提で疑う
もうひとつ、当社の自社サイトで見つけた例です。サイト診断の際にサイトマップを開いたところ、載っていたのは7URLだけ。しかも実在しないURLが1本混ざっており、200本以上あるブログ記事は1本も載っていませんでした。制作時に手書きで置いたサイトマップが、その後のページ追加にまったく追従していなかったのです。
これは手書き・静的設置のサイトマップに共通する構造的な問題です。CMSが自動生成するサイトマップと違い、手書きのものは誰かが更新しない限り古いままです。現在は記事を含む全URLを更新日付きで自動出力する方式に作り直しました。
制作会社にサイトを作ってもらった方は、一度自分のサイトマップを開いて、最近追加したページが載っているか確認してみてください。載っていなければ、それは「作った日のサイト」のサイトマップです。
Search Consoleへの送信手順と、知っておくと楽になる仕様
場所と中身が確認できたら、Search Consoleの「サイトマップ」メニューでURLを送信します。送信後「成功しました」と検出URL数が表示されれば完了です。ここでエラーや「0件」が出たら、前述の空サイトマップ・HTML返却を疑ってください。
あわせて知っておくと楽になる仕様が2つあります。
- robots.txtにSitemap行を書いておけば、Googleはクロール時に自動発見します。Search Consoleでの手動送信は発見を早める意味はありますが、必須ではありません。逆に言うと、手動送信を忘れてもrobots.txtが正しければ致命傷にはなりません
- サイトマップはインデックス登録の約束ではなく、URLの案内です。送信したのに検索に出ない場合、原因はサイトマップではなくページ側の品質や構造にあることがほとんどです
まとめ
- sitemap.xmlの場所は構成で決まる。まず
/robots.txtを開き、Sitemap行があればそれが答え - WordPress標準は
/wp-sitemap.xml。ただしサイトマップ系プラグインが入っていると標準側は空になり、生きている場所が変わる - 送信前に必ずブラウザで開き、「XMLで返るか・空でないか・件数の桁が合うか」の3点を確認する
- 同じ構成のサイトが複数あっても、場所は1サイトずつ実測する。25サイト中3サイトで場所が違った、というのが実測の現実
- 手書きサイトマップは更新されない前提で疑う。最近追加したページが載っているかで判定できる
サイトマップは一度正しく設定すれば手離れする部分です。逆に、間違ったURLを案内したまま放置しても誰も教えてくれません。5分で確かめられるので、この記事を開いたまま自分のサイトのrobots.txtから順に開いてみてください。