// 無料ツール · XML サイトマップ検証

XML サイトマップ検証ツール

sitemap.xml を貼り付けるか、ファイルをそのままドロップしてください。loc・lastmod・priority・changefreq・hreflang の相互参照・50,000 URL の上限まで、プロトコル違反を行番号と直し方つきで表示します。無料、ブラウザ内で完結、アップロードなし。

無料即時登録不要ブラウザ内で動作

他の言語:EnglishDeutschEspañolFrançais日本語한국어Português (Brasil)繁體中文

sitemap.xml · 検証

入力するたびに検証します。sitemap.xml や sitemap.xml.gz をこの枠にドロップしても構いません。ファイルの読み込みと解凍はブラウザ内で行われ、外には一切出ません。

エラーと警告
    レポート
    
              

    XML サイトマップを検証する手順

    すべてこのページの中で完結します。検証するのは「あなたが渡したファイル」です。サイトを取得しに行くことはないので、URL を打つのではなく XML を貼り付けるかファイルをドロップしてください。

    1. 貼り付けるか、ドロップする。 左の枠に XML を貼り付けるか、sitemap.xml(または sitemap.xml.gz。ブラウザが解凍します)をドラッグしてください。1 文字打つたびに、その場で検証が走ります。
    2. 指摘を上から潰す。 すべての指摘に行番号と直し方が付きます。エラーはクローラーが拒否する / 誤読するもの、警告は XML としては正しいのに損をしているもの(未来の lastmod、重複 URL など)です。
    3. レポートをコピーして、直して、もう一度。 右側はプレーンテキストのレポートです。ファイルの種類、50,000 URL と 50 MB の上限までの余裕、指摘の全件が入っているので、そのままチケットに貼れます。直したファイルを貼り直して、きれいに返ってくることを確認してください。

    この検証ツールが見ているもの

    貼り付けたファイルに対して 3 周します。1 周目は XML として妥当かどうか。閉じ忘れ、入れ子の交差、クエリ文字列の中の生の &、宣言されていない名前空間接頭辞 —— これらを「パースエラー」という 1 行ではなく、起きた行ごとに報告します。2 周目は sitemaps.org のプロトコル。ルートが <urlset><sitemapindex> で、名前空間が http://www.sitemaps.org/schemas/sitemap/0.9 であること、各項目に絶対 URL の <loc> がちょうど 1 つあること、<lastmod> が本物の W3C Datetime であること、<priority> が 0.0〜1.0、<changefreq> が既定の 7 語のいずれかであること。3 周目は上限と相互参照。50,000 URL、非圧縮 50 MB、重複 URL、ホストの混在、そして xhtml:link による hreflang 注釈の双方向チェックです。

    XML サイトマップとは、クロールしてほしいページを列挙した、固定の URL に置くファイルです。各ページを <loc> 要素として書き、必要なら <lastmod> を添え、<urlset> をルートにまとめます。複数のサイトマップを指す場合はルートを <sitemapindex> にします。 プロトコルはこれで全部で、いまも検索エンジンが合意した 0.9 スキーマのままです。だからこそ、サイトマップの検証は「生成側を変えたときに 1 回」で足ります。失敗は機械的で、行さえ分かればどれも 1 行の修正だからです。

    逆に、このツールが答えられないことも先に書いておきます。<loc> のページが本当に 200 を返すか、noindex が付いていないか、robots.txt がこのファイルを指しているか —— これらは 1 URL につき 1 回の取得が必要で、ブラウザの中では原理的に無理です(理由は後述)。書式が正しいことと、中身が正しいことは別の問題で、このページが引き受けるのは前者です。

    文字コード:Shift_JIS 宣言、BOM、そして連結されたファイル

    日本語サイトのサイトマップで、日本語サイトにしか起きない壊れ方があります。XML 宣言に書かれた encoding と、ファイルの実際のバイト列が食い違う系の失敗です。既存システムからの出力、社内ツールの CSV 変換、古いテンプレートの流用 —— 出どころはいろいろですが、サイトマップの仕様は明確で、UTF-8 以外は認められていません。このツールは 1 行目の宣言を読み、encoding="Shift_JIS"encoding="EUC-JP" であればその場でエラーにします(大文字小文字と utf8 / UTF-8 の表記ゆれは許容します)。上の「壊れた例」ボタンがまさにこれを読み込みます。

    BOM については誤解が多いので、このツールの実際の挙動を書きます。先頭の UTF-8 BOM は取り除かれ、警告も出しません。 XML 仕様上、先頭の BOM は許されているからです。問題になるのは位置がずれたときで、次の 2 つは実際に報告されます。

    • 宣言の前に空行・空白・コメントがある「<?xml …?> 宣言はファイルの先頭になければなりません」。PHP のテンプレートで <?php の閉じタグの後ろに改行が残っている、というのが典型です。BOM の後ろに宣言が来るのは問題ありませんが、宣言の後ろに BOM が来ると壊れます。
    • 分割生成したファイルを連結した → 2 つめの <?xml 宣言が途中に現れ、「宣言が先頭にない」「最上位に 2 つめの要素があります」が同時に出ます。シャードは連結するのではなく、<sitemapindex> で並べるのが正解です。ファイルごとに BOM が付いていると、この失敗はさらに見つけにくくなります(BOM は画面上に見えないため)。

    そしてもうひとつ、ドロップしたファイルについて。ブラウザはファイルを UTF-8 として読みます。 中身が本当に Shift_JIS のバイト列なら、入力欄の日本語はその時点で文字化けして見えます。これは検証結果ではなく、文字コードが違うことの直接の証拠です。文字化けした文字が <loc> に入っていれば 「URL に ASCII 以外の文字が含まれています」という警告が出ますが、原因はエスケープ漏れではなく保存時の文字コードなので、直す場所は生成側です。なお、この警告は正しく UTF-8 で保存された日本語 URL(/料金/ のような日本語スラッグや日本語ドメイン)でも出ます。壊れてはいませんが、クローラーごとの正規化の違いを避けるため、パスはパーセントエンコード、ホストは Punycode に変換して出力するのが安全です。

    サイトマップの中の hreflang を、双方向で検証する

    各ページの <head> ではなくサイトマップ側に hreflang を書くのは、規模の大きいサイトが選ぶやり方で、検証ツールがいちばん役に立つ場所でもあります。失敗が目に見えないからです。Google のルールは対称で、ページ A が B を代替版として挙げるなら、B の項目も A を挙げ返していなければなりません。そして、どの版も自分自身を挙げる必要があります。1 本でも戻りリンクが欠けると、Google はその組を部分的に採用したりせず、注釈ごと破棄します。Search Console のどこにも大きな警告は出ません。

    そこでこのツールはグラフを組み立てます。xhtml:link を持つ各 <url> について、自分の <loc> を挙げているか、同じファイル内の URL を指す代替版すべてに戻りリンクがあるか、同じ言語コードが二重に出ていないか、そして各コードが実在する ISO 639-1 の言語(必要なら文字体系と地域つき)かを確認します。日本語サイトでいちばん多い間違いは hreflang="jp" です。jp は国コードであって言語コードではないため、日本語は ja、日本向けの日本語なら ja-JP と書きます。もうひとつ、ja_JP のようにアンダースコアで書いたものはエラー、ja-jp のように小文字で書いたものは警告として、正しい表記を出します。

    代替版がこのファイルの外を指している場合は、そう報告します。確認できないことを確認できたふりはしません。末尾のスラッシュだけが違う 2 つの URL も、そう指摘します。人間の目がいちばん滑る場所だからです。x-default の無いグループはエラーではなく警告にしています。任意の指定であること、そして「あなたが用意していない言語で検索した人が着地する版」でもあることの両方が本当だからです。

    注釈を直すのではなく最初から書くなら、hreflang タグ生成ツールが URL パターンひとつから head 用の <link> ブロックと、サイトマップ用の xhtml:link ブロックの両方を出します。同じ元データから出るので、2 つがずれることがありません。あちらで生成して、こちらに貼れば、戻りリンクは構造上正しくなります。

    検証が通ったあと:サイトマップの ping は廃止されました

    いまだに「ファイルが通ったら Google に ping しましょう」と案内するツールがあります。その google.com/ping?sitemap= は 2023 年に廃止され、いま叩いても何も起きません。それを機能として売っているページがあれば、そのページが最後に更新された時期が分かる、というだけの話です。

    代わりになるのは地味で、そして効きます。robots.txt に Sitemap: 行として絶対 URL を書いておくこと。これはどのクローラーも自分の周期で読み、アカウントも要りません。そのうえで Search Console と Bing Webmaster Tools に 1 回だけ登録し、あとは放っておくこと。再送信しても速くはなりません。そして <lastmod> を正確に保つこと。Google が使うと明言している唯一のフィールドで、正確な値こそが再クロールを組む理由になります。IndexNow を使っているなら、公開時に通知してください。こちらは生きています。

    そのうえで、推測ではなく測ってください。clize seo check --domain yourdomain.jp は、あなたのサイトマップと Search Console のプロパティを合わせて読み、「ファイルには載っているのに一度も表示されていないページ」を、実際の HTTP ステータスとインデックス状況つきで出します。「登録した意味はあったのか」という問いに答えられるのはこちら側で、検証ツールにはできません。機械可読なファイルつながりでは、llms.txt 検証ツール(AI が読む索引ファイル)と、FAQ スキーマ生成ツール(表示テキストと 1 文字も違わない JSON-LD)が、このページと同じ「1 つの元データから生成し、手で書かない」という原則で動いています。

    // よくある質問

    XML サイトマップの検証では何を見るのですか?

    3 つです。まず XML として妥当か —— タグが閉じて入れ子が正しいか、アンパサンドがエスケープされているか、名前空間の接頭辞が宣言されているか。次に sitemaps.org のプロトコルに従っているか —— ルートが 0.9 名前空間の <urlset> か <sitemapindex> で、各項目に絶対 URL の <loc> がちょうど 1 つあり、<lastmod> が正しい W3C Datetime、<priority> が 0.0〜1.0、<changefreq> が既定の語であること。最後に上限の中に収まり、内部で矛盾していないか —— 50,000 URL 未満、非圧縮 50 MB 未満、重複 URL がないこと、そして hreflang の代替版が互いを指し合っていることです。

    サイトマップは Shift_JIS で出力してもよいですか?

    いけません。サイトマップの仕様は UTF-8 を要求しています。XML 宣言に encoding="Shift_JIS" や encoding="EUC-JP" と書かれていれば、このツールは 1 行目でエラーにします。宣言だけ UTF-8 に書き換えても直りません。実際のバイト列も UTF-8 で保存し直す必要があります。判断が付かないときは、このページにファイルをドロップしてみてください。入力欄の日本語が文字化けして見えるなら、中身は UTF-8 ではありません。

    サイトマップに BOM が付いていると問題になりますか?

    ファイルの先頭にある UTF-8 BOM は XML の仕様上許されており、このツールも取り除いたうえで検証するので、それ自体はエラーにも警告にもなりません。問題になるのは位置です。BOM や空行やコメントが <?xml 宣言より前ではなく、宣言より後ろに現れると「宣言が先頭にない」というエラーになります。分割生成したファイルを連結したときにこれが起きやすく、そのときは「最上位に 2 つめの要素があります」も同時に出ます。連結ではなくサイトマップ索引を使ってください。

    hreflang は jp と ja のどちらですか?

    ja です。hreflang の第 1 要素は ISO 639-1 の言語コードで、jp は国コード(ISO 3166-1)なので言語としては存在しません。日本向けの日本語を明示したい場合は ja-JP と書きます。ただし日本語版が 1 つしかないなら ja だけで十分で、地域を足す必要はありません。このツールは jp を警告として、ja_JP のようなアンダースコア表記をエラーとして報告します。

    サイトマップ索引ファイルも検証できますか?

    できます。ルートが <sitemapindex> のファイルを貼り付けると、索引のルールに切り替わります。各項目は <sitemap> で、<loc> が 1 つ、任意で <lastmod>、<priority> や <changefreq> や <url> が混ざっていないこと。子のサイトマップを辿ることはできません。何も取得しに行かない設計だからです。子ファイルは 1 つずつ貼り付けて検証してください。

    gzip 圧縮された sitemap.xml.gz も検証できますか?

    できます。.gz ファイルを枠にドロップするか、ファイルボタンから選んでください。ブラウザがローカルで解凍してから検証します。なお gzip は上限を変えません。50 MB は非圧縮のサイズに対する上限で、レポートに出ているのもその値です。

    ファイルはアップロードされますか?なぜ URL を指定できないのですか?

    アップロードされません。この検証ツールはブラウザの中で動くスクリプトです。貼り付けたものもドロップしたものもページの外に出ず、アカウントも登録も不要で、ページを読み込んだあとはオフラインでも動きます。URL を取得できないのも同じ理由です。同一オリジンポリシーにより、あるドメインのページが別ドメインのファイルを読むには相手が CORS ヘッダーを返す必要があり、サイトマップにそれを付けているサイトはまずありません。curl で取得して出力を貼り付けてください。その代わり、まだ公開していないファイル、CI で生成された成果物、ログインの内側にあるサイトマップも検証できます。

    clize seo check — 自分のドメインなら無料

    書式が通るのは出発点。次は、何がインデックスされたかを見る。

    自分のサイトを調べるのは無料です。サイトマップと Search Console のプロパティを合わせて読み、各ページを実際の HTTP ステータスとインデックス状況つきで一覧にし、一度も表示されていないページを印を付けて示し、流入を参照元別に(AI エンジンは分けて)出します。エージェントから 1 コマンドで。

    $ npm i -g @clize/clize && clize install
    $ clize seo check --domain yourdomain.jp
    [ Agent SEO by Clize → ]