XML サイトマップ：作り方、Search Console での送信と確認の手順

結論： XML サイトマップは、検索エンジンに知ってほしいアドレスを列挙するファイルです。ページごとに <url> エントリを1つ置き、アドレスを <loc> に、正確であれば最終変更日を <lastmod> に書きます。CMS やサイト自身のデータから生成し、1ファイルあたり50,000アドレス・50 MB 以内に収め、robots.txt に記載して、Search Console のサイトマップレポートから送信します。送信はヒントであって、約束ではありません。Google は、ファイルに載せたページをクロールやインデックスすることを保証しません。

XML サイトマップには何が書かれているのか

2026年11月4日に取得した seogrinder.com のサイトマップの冒頭です（curl -sS https://seogrinder.com/sitemap.xml | head -5）。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://seogrinder.com/</loc><lastmod>2026-11-04</lastmod></url>
  <url><loc>https://seogrinder.com/imprint</loc><lastmod>2026-11-02</lastmod></url>
  <url><loc>https://seogrinder.com/privacy</loc><lastmod>2026-11-02</lastmod></url>

sitemaps.org のプロトコルが求めるのは3つです。名前空間を付けた開始タグ <urlset>、ページごとの <url> エントリ、各エントリの中の <loc>。それ以外のタグはすべて任意で、任意のタグへの対応は「検索エンジンによって異なることがある」（“may vary among search engines”）とされています。ファイルは UTF-8 でなければならず、& のような文字はエスケープ（&）する必要があり、1つのファイルのアドレスはすべて同じ1つのホストに属していなければなりません。

私たち自身のファイルで <loc> エントリを数えると、425件でした（curl -sS https://seogrinder.com/sitemap.xml | grep -o '<loc>' | wc -l、2026年11月5日）。内訳は、トップページ1件、法的ページ4件（運営者情報とプライバシーポリシーのドイツ語版・英語版）、ブログの一覧ページ12件、記事408件です。各エントリにあるのは <loc> と <lastmod> だけで、<changefreq> も <priority> も hreflang の指定もありません。ファイルのサイズは45,765バイトです（curl -sS https://seogrinder.com/sitemap.xml | wc -c）。

XML サイトマップは必要か

必ずしも必要ではありません。Google のサイトマップの概要には、ページが適切にリンクされていれば、Google は通常、サイトのほとんどを見つけられる、とあります。サイトマップがもっとも役立つのは、大規模なサイト、外部からのリンクが少ない新しいサイト、動画・画像・ニュースが多いサイトです。サイトが小さく（検索結果に出したいページだけを数えて、約500ページ以下）、重要なページがすべてトップページからのリンクで届くなら、なくてもかまいません。それでも、ほとんどのサイトはサイトマップの恩恵を受ける、と Google は付け加えています。

WordPress、Wix、Blogger を使っているなら、Google によれば CMS がすでにサイトマップを用意している可能性が高いそうです。2つめのファイルを作る前に、自分のサイトで /sitemap.xml を開いてください。

サイトマップはリンクの代わりにはなりません。期待したページが Google に出てこないとき、サイトマップがないことは、いくつかある原因の1つにすぎません。公開したばかりのページなら、サイトマップは見つけてもらう助けになりますが、クロールもインデックス登録も保証されません。この点は後で触れます。

XML サイトマップの作り方

ツールからではなく、アドレスの一覧から始めてください。Google によると、サイトマップが示すのは、検索結果に表示したい URL、つまり canonical の URL です。同じ内容が複数のアドレスから届くなら、優先するアドレスだけを載せます。

次に、Google のページサイトマップの作成と送信が説明している方法から選びます。

• CMS に書かせる。 CMS が対応しているなら、その機能を使います。
• 手で書く。 アドレスが数十件に満たないときです。大きな手書きのファイルは面倒で保守しにくい、と Google は述べています。
• 生成する。 それ以上なら、自分のデータから生成します。Google によれば、最善なのはウェブサイトのソフトウェアにファイルを書かせることです。エントリの順序は Google にとって関係ありません。

私たちのファイルは生成しています。スクリプトが記事ファイルからブログのエントリを書き、トップページと法的ページには手を触れません。

ファイルに入れるものと、入れないものです。

• 入れる： https:// 付きの完全なアドレスで、ステータス200を返し、インデックス登録でき、検索に出したいページ。Google は完全修飾のアドレスを求め、書かれたとおりにクロールします。
• 入れない： リダイレクトするアドレス（Search Console のヘルプは、クロールさせたいアドレスに置き換えるよう述べています）、エラーを返すページ、すでに載せているページの重複。私たちの考えでは、noindex のページも入れません。サイトマップが Google を招き入れ、タグがそれを追い返すからです。

ファイルはルート直下に置きます。たとえば https://example.com/sitemap.xml です。Google はルートを推奨しています。サブフォルダーに置いたサイトマップは、そのフォルダー以下のアドレスにしか効きません。Search Console から送信する場合は別です。

XML サイトマップの大きさの上限

1つのファイルに入れられるアドレスは最大50,000件、圧縮しない状態での大きさは最大50 MB です。gzip で圧縮してもかまいませんが、数えられるのは展開後のサイズです（sitemaps.org）。上限を超えるなら、一覧を分割し、ファイルの名前をサイトマップインデックスファイルに書きます。インデックスファイルには最大50,000個のサイトマップを載せられますが、載せられるのは同じサイトのサイトマップだけです。私たちのファイルはどちらの上限よりもはるかに小さいので、インデックスは要りません。

lastmod：ページが本当に変わったときだけ設定する

<lastmod> は、任意のタグの中で、唯一きちんと書く価値があるものです。Google は、その値が “consistently and verifiably”（常に、検証可能な形で）正確なときに利用します。大きな更新とは、メインコンテンツ、構造化データ、リンクの変更を指し、著作権表示の年を新しくしただけでは数えられません。プロトコルはもっとはっきりしています。日付は “the date the linked page was last modified, not when the sitemap is generated”（リンク先のページが最後に変更された日であり、サイトマップが生成された日ではない）でなければなりません。

だから、ビルドのたびにすべてのエントリへ今日の日付を書き込まないでください。Google は <priority> と <changefreq> を無視するので、どちらも書かないでください。

私たちのファイルでは、425件のエントリのうち313件が 2026-11-04、108件が 2026-11-05、4件が 2026-11-02 です（curl -sS https://seogrinder.com/sitemap.xml | grep -o '<lastmod>[^<]*' | sort | uniq -c、2026年11月5日）。記事のエントリは、各記事の updated の行から日付を取ります。そのため、記事を同じ日に書いたり改訂したりすると、多くのエントリが同じ日付になります。

XML サイトマップを Google に送信する方法

方法は3つあり、組み合わせて使えます。

1. robots.txt。 完全なアドレスで Sitemap: https://example.com/sitemap.xml を追加します。この行はどのユーザーエージェントのグループにも属さないので、ファイル内の位置は関係なく、複数書けます。Google は、次に robots.txt をクロールしたときに見つけます。インデックスファイルがあるなら、送信するのはインデックスファイルです。私たちのファイルでは、2026年11月4日時点で robots.txt の最終行がこれです：Sitemap: https://seogrinder.com/sitemap.xml
2. Search Console のサイトマップレポート。 手順は下にあります。
3. Search Console API。 コードから送信したいときに使います。

送信とは、ファイルの場所を Google に知らせることです。Google のサイトマップレポートのヘルプには、“You cannot actually upload a sitemap to Google.”（実際には Google にサイトマップをアップロードすることはできません）とあります。手順は次のとおりです。

1. プロパティの所有者の権限があることを確認します。ない場合は、代わりに robots.txt にサイトマップを記載してください。
2. サイトマップをサイトで公開します。
3. そのアドレスについて、URL 検査で「公開 URL をテスト」を実行し、ページの取得が成功（英語表示では “Successful”）になっていることを確認します。
4. サイトマップのレポートを開き、「新しいサイトマップの追加」にアドレスを貼り付けて、「送信」をクリックします。

Google は、ファイルはすぐに取得されるはずだが、中のアドレスのクロールには時間がかかることがあり、すべてがクロールされるわけではないと述べています。Google の言葉では、“submitting a sitemap is merely a hint”（サイトマップの送信は単なるヒントにすぎない）です（Google）。レポートには、サイトマップごとにステータス（英語表示では “Success”、“Couldn't fetch”、“Sitemap had X errors”）、Google が最後に読んだ日、見つけたページ数が表示されます。見つかったことは、インデックスされたことではありません。Google は、見つかったページがクロールやインデックスされた、あるいはされる保証はないと述べています。また、このレポートに一覧表示されるのは、レポートまたは API から送信したサイトマップだけで、Google が robots.txt から見つけたものは表示されません。

この記事は Google のドキュメントに沿っています。Search Console のスクリーンショットは載せておらず、私たち自身のファイルを送信した結果も報告しません。

XML サイトマップを確認する方法

1. 取得する。 curl -sSI https://example.com/sitemap.xml で、ステータス200と XML のコンテントタイプが表示されるはずです。私たちのファイルでは、2026年11月4日に HTTP/2 200 と content-type: application/xml; charset=utf-8 が返りました。
2. 冒頭を読む。 ファイルは <urlset と名前空間で始まり、UTF-8 で、相対アドレスを含みません。
3. すべてのアドレスにリクエストする。 下のループはリダイレクトをたどらないので、リダイレクトは 301 や 302 として表示されます。
4. Google が取得できるか確認する。 上のライブテストを使います。Google はサイトマップを取得するときも robots.txt を守るので、そのファイルをブロックするルールがあると取得が止まります。
5. サイトマップレポートを読む。 送信したあとに確認し、エラーのあるサイトマップはクリックして詳細を見ます。

for u in $(curl -sS https://seogrinder.com/sitemap.xml | grep -o 'https://seogrinder.com/[^<]*'); do
  curl -sS -o /dev/null -w '%{http_code}\n' "$u"
done | sort | uniq -c

2026年11月5日の13:40 UTC ごろ、これは 425 200 を出力しました。425件のアドレスすべてが200で応答したということです。

SEOgrinder は私たち自身の無料ツールで、私たちが開発しています。ページをスキャンして、タスク の一覧と、AI 対応 タブの「エージェントに道筋を示す」の項目（タグは “Sitemap”）を見てください。robots.txt に記載されたサイトマップを読み、記載がなければ /sitemap.xml を読みます。次の指摘を報告することがあります。

確認するのは、一覧に均等に散らした最大15件のアドレスのサンプルで、全アドレスではありません。そのため、上のループを実行する価値があります。また、ファイルごとに最大3 MB、インデックスの中のサイトマップは10個まで読み、それより大きいものは、最後まで読めなかったものとして扱います。

よくある間違い

• リダイレクトする、失敗する、noindex を持つアドレス。 Search Console は到達できないものを報告します。リダイレクトは、リダイレクト先に置き換えてください。
• ページのあらゆるバリエーション。 http と https、www の有無、パラメーター付きのバージョンを並べて載せるのはやめましょう。canonical のものだけを載せます。
• ビルドのたびに今日の日付を lastmod にする。 Google は、日付が常に検証可能な形で正確なときに、その日付を利用します。
• ファイルに含めてはいけないアドレス。 レポートはこれを “URL not allowed”（英語表示）と呼びます。別のドメイン、別のプロトコル、サイトマップ自身より上のフォルダーです。
• 「送信済み」を「インデックス済み」と読む。 送信したサイトマップは、何も保証しません。
• 失敗しているファイルを放置する。 Google は失敗した取得を数日間再試行し、その後やめます。原因を直して、もう一度送信してください。

よくある質問

robots.txt にすでに記載してあれば、送信しなくてもよいですか？

はい。robots.txt に記載されたサイトマップは、Google が次にそのファイルをクロールしたときに見つけます。送信すると、レポートが使えるようになります。Googlebot がいつファイルにアクセスし、どんなエラーに当たったかが分かります。

XML サイトマップで順位は上がりますか？

Google はサイトマップの目的を、発見の手助けとして説明しています。検索エンジンがアドレスを見つけるのを助け、大規模なサイトや複雑なサイトのクロールを改善できる、というものです。私たちが引用したページは、順位については何も約束していません。誰にも約束はできません。

次の一歩

上のループを自分のサイトマップで実行し、200で応答しないアドレスをすべて直してください。そのあと SEOgrinder でサイトをスキャンし、タスク一覧を開いて、サイトマップに関する指摘から始めます。変更したら 再チェック を押し、まだ送信していないなら、Search Console のサイトマップレポートでファイルを送信してください。

あわせて読みたい

• サイトが Google に表示されない？原因を見つける7つのチェック
• Google インデックス登録：新規ページを見つけてもらう5ステップ（検証しました）
• canonical タグとは？必要な場面と、よくある5つのミス