サイトマップには「50,000 URL・50MB」という上限がある ── 分割とインデックス化を確認する13項目（2026年9月時点）

01 何が起きたか — サイトマップ1ファイルには「50,000 URL・50MB」という共通の上限がある

Googleとsitemaps.org、両方の公式資料が示す同じ2つの数字

サイトマップ（sitemap.xml）を作るとき、「1つのファイルに、ページを何件まで書いてよいのか」を確認したことはあるだろうか。Googleの公式ガイド「Build and submit a sitemap」は、この上限を明確に定義している。「すべての形式で、1つのサイトマップは50MB（非圧縮）または50,000 URLに制限される」というのがそれだ。この基準は、Googleが独自に決めたものではない。サイトマップの仕様そのものを定めている sitemaps.org のプロトコル文書にも、ほぼ同じ数字が書かれている。「提供する各サイトマップファイルは、50,000 URLを超えてはならない」「50MB（52,428,800バイト）を超えてはならない」という記述だ。つまり「50,000 URL・50MB」は、GoogleとBing・Yahoo!などが共同で維持してきた仕様書由来の、業界共通の基準である。

超えたらどうなるかは、実は公式には書かれていない

ここで正直に書いておきたいことがある。上限を超えたサイトマップを実際に送信したら検索エンジンが具体的にどう処理するのか（全体を無視するのか、途中までを読んで打ち切るのか）について、Googleの公式ドキュメントに明示的な記述は見当たらなかった。書かれているのは「より大きなファイル、またはより多くのURLがある場合は、サイトマップを複数のサイトマップに分割する必要がある」という、超過を避けるべき理由ではなく行動の指示だけだ。分からないことを分かるふりで埋めない、という前提のもとに本記事を書いている。確実に言えるのは、上限を守ったサイトマップだけが、仕様どおりに扱われることが保証されているという点である。

この2つの上限は独立している。URL件数が50,000件に届いていなくても、1件あたりの情報量が多い画像サイトマップや動画サイトマップでは、ファイルサイズの方が先に上限へ到達することがある。逆に、URLだけを列挙する軽いサイトマップであれば、件数の上限の方が先に来る。どちらか片方だけを見て「まだ大丈夫」と判断しないことが、この章の出発点になる。

02 なぜ・背景 — 上限が決められている理由と、圧縮の扱い

gzip圧縮は許可されている。ただし基準は解凍した後のサイズ

「50MBを超えそうなら圧縮すればいいのでは」と考えるのは自然だが、これは誤解を招きやすい点だ。sitemaps.orgのプロトコル文書は「gzip形式でサイトマップファイルを圧縮し、帯域幅の消費を抑えてもよい。ただし、サイトマップファイルは解凍した状態で50MBを超えてはならない」と明記している。つまり圧縮は帯域幅（転送量）の節約のために許可されているのであって、上限そのものを回避する手段ではない。圧縮後のファイルが小さく見えても、検索エンジン側が解凍した時点でのサイズが判定基準になる。

1つのサイトに、サイトマップインデックスファイルは500個まで登録できる

分割してもなお足りないほどの規模のサイトのために、もう1段上の上限も用意されている。Googleの公式ガイドは「1つのサイトにつき、Search Consoleアカウントで500個までのサイトマップインデックスファイルを送信できる」としている。サイトマップインデックスファイル1つあたり最大50,000個のサイトマップを列挙できるので、理屈のうえでは1サイトが持てるサイトマップファイルの総数はさらに大きくなる。ただしこれは「上限まで使い切ってよい」という話ではなく、そこまで到達するサイトは極めて限られる、という規模感として押さえておけば十分だ。

lastmodは「正確であれば」使われる。changefreqとpriorityは読まれない

サイトマップのXML規格には <lastmod>（最終更新日時）・<changefreq>（更新頻度）・<priority>（優先度）という3つの付加タグが定義されている。この3つを同じ重みで扱っている解説記事は少なくないが、Googleの公式ガイドの扱いはまったく異なる。<lastmod>については「一貫して、かつ（ページの最終更新と比較するなどして）検証可能な形で正確である場合に、Googleはその値を利用する」とされ、著作権表示の日付だけを更新するような変更は「重要な更新」とはみなされないと補足されている。一方で<changefreq>と<priority>については「Googleは<priority>と<changefreq>の値を無視する」と、はっきり書かれている。「毎日更新」と書いたところで、クロールの優先順位が上がるわけではない。

03 この記事で出てくる用語

「サイトマップファイル」と「サイトマップインデックスファイル」は別物

本記事では2種類のXMLファイルが登場する。1つは個々のページURLを列挙する「サイトマップファイル」（sitemap.xml）。もう1つは、複数のサイトマップファイルへのパスだけをまとめて列挙する「サイトマップインデックスファイル」である。後者にはページのURLは1つも含まれない。含まれるのは、他のサイトマップファイルの所在だけだ。

載せるURLは、絶対URL・正規URLに揃える

サイトマップに何を載せるかにも、公式の条件がある。Googleの公式ガイドは「サイトマップには完全修飾の絶対URLを使うこと。Googleは記載されたとおりの形でURLをクロールしようとする」としたうえで、「Googleの検索結果に表示したいURLをサイトマップに含める。Googleは検索結果に正規URLを表示するのが一般的で、これはサイトマップで影響を与えられる」と続けている。モバイル版とデスクトップ版で別URLを使っている場合は、どちらか一方だけをサイトマップに載せることが推奨されている。同じ内容が複数のURLに存在するなら、代表となる1つだけを選んで載せるという考え方は、重複コンテンツを統合する際の判断とも重なる。

参照先のサイトマップには、置き場所の条件がある

サイトマップインデックスファイルから参照するサイトマップファイルには、置き場所の制約がある。Googleの公式ガイドは「参照するサイトマップは、サイトマップインデックスファイルと同じサイトにホストされている必要がある」とし、さらに「サイトマップインデックスファイルと同じディレクトリ、またはサイト階層でそれより下位に置かれている必要がある」と続けている。別ドメインや別サブディレクトリの上位にあるサイトマップを、勝手にインデックスへまとめることはできない。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どのくらいのページ数からこの記事が関係してくるか

公開ページが数百件程度のサイトであれば、この記事の大半は今すぐ必要な知識ではない。50,000 URLという上限に、通常のページ運用で到達することはまずない。関係してくるのは、次のいずれかに当てはまるサイトである。URL数が50,000件に近づいている、または既に超えているサイト。1URLあたりの情報量が多く、ファイルサイズが50MBに近づいているサイト（画像・動画のメタデータを大量に含むサイトマップなど）。そして既に複数のsitemapファイルを手作業で管理していて、送信経路を整理したいサイトだ。当サイト自身のURL件数は、この上限とは桁が2つ以上離れている（07章で実際に測った数字を示す）。

件数・サイズだけでなく、コンテンツの種類でも分割できる

分割の理由は、上限に近づいたときだけではない。Googleの公式ガイドは「Googleがサポートするサイトマップ拡張機能を使うと、画像・動画・ニュースコンテンツについて追加の情報を提供できる」としており、画像用・動画用・ニュース用のサイトマップをそれぞれ個別に用意することも想定している。つまりサイトマップインデックスファイルは、上限を超えたときの避難先としてだけでなく、コンテンツの種類ごとに情報を分けて渡す設計としても使える。記事ページ用・商品ページ用・画像用のように用途で分けておけば、どれか1つを更新するときに他のファイルへ触れずに済むという運用上の利点もある。

🅱 この記事が測っていないこと・分からないこと

本記事はGoogleの公式ドキュメントとsitemaps.orgの仕様書を中心に確認した。Bing・Yahoo!など他の検索エンジンが、同じ上限をどこまで厳密に適用しているかは、それぞれの公式資料を個別に確認しておらず、本記事の範囲外である。また、上限を超えたサイトマップを実際に送信した場合にサーバーログやSearch Console上でどう表示されるかという実地の挙動も、当サイトでは検証していない。分からないことを、分かるふりで埋めていない。

🅲 手順 — 分割するかどうかを判断する4段階

URLが1件でも増えるたびに神経質になる必要はない。手順としては、まず現状を数えるところから始まる。

この4段階のうち、最初の「数える」を後回しにすると、あとの判断がすべて推測になる。まず数字を出すことが、分割設計より先にやるべき作業である。

05 明日、自分のサイトで確認できることチェックリスト

以下は、今日からブラウザとSearch Consoleだけで確認できる項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。

• 自分のサイトのsitemap.xmlをブラウザで開き、含まれているURLの数を数える
• sitemap.xmlのファイルサイズを、保存ダイアログかコマンドで確認する
• URL数とファイルサイズが、それぞれ50,000件・50MBにどれだけ近いかを計算する
• sitemap.xml内のlastmodタグを3件サンプリングし、実際のページ更新日と一致しているか確認する
• sitemap.xml内にchangefreqタグやpriorityタグが書かれていないか確認する
• 複数のsitemapファイルを使っている場合、それらを1つのsitemapindex.xmlでまとめているか確認する
• サイトマップインデックスファイル内の<loc>タグの数を数え、50,000件を超えていないか確認する
• サイトのrobots.txtを開き、Sitemapの行が記載されているか確認する
• Google Search Consoleの「サイトマップ」メニューを開き、送信済みサイトマップのステータスを確認する
• sitemapファイルを圧縮している場合、拡張子が.xml.gzになっているか確認する
• サイト全体の公開ページ数を数え、50,000件に近づいているかどうかを判定する
• sitemap内のURLを3件クリックし、実際に200が返るページへつながっているか確認する
• sitemapに、noindexを設定しているページのURLが混ざっていないか、3件サンプリングして確認する

すべてに目を通す時間の目安は1サイトあたり60〜65分程度である。複数のsitemapファイルを既に運用しているサイトでは、インデックスファイルの点検に追加の時間がかかることがある。件数の把握でつまずくようなら、当サイトの🔧 WEBサイト総合分析・レポートツールでサイト内のURL構成を先にまとめて確認すると早い。

06 代替・他の選択肢（表で）

サイトマップの形式は、XMLだけではない

ここまでXML形式のsitemap.xmlを前提に書いてきたが、Googleの公式ガイドはXML以外の形式も受け付けている。「プレーンテキストファイルでURLを列挙してもよい。ファイル名は自由で、拡張子は.txtとする」という記述がある。さらにsitemaps.orgの仕様では、既存のRSS 2.0やAtom 1.0のフィードをサイトマップとして扱える、とされている。どの形式を選んでも、URL数とファイルサイズの上限自体は変わらない。

サイトマップは、内部リンクの代わりにはならない

サイトマップにURLを載せれば、そのページへの経路ができたと考えるのは早計だ。サイトマップは「このURLが存在する」という一覧を渡す仕組みであって、サイト内のどこからもリンクされていないページを、検索エンジンが見つけやすくする保証まではしていない。実際に、末尾スラッシュの有無だけでサイトマップのURLとGoogleが認識するURLがずれていた例を、当サイトで確かめたことがある(archives/38)。canonical・内部リンク・サイトマップの記載が食い違うと、どれか1つを直しても解決しないことも、別の記事で扱った(archives/39)。サイトマップと内部リンクは別の仕事をしている。一覧を渡すサイトマップと、経路を作る内部リンクは、両方そろって初めて機能する。noindex・nofollow・robots.txtがそれぞれ何を止めているのかを混同しないための整理は、別の回で扱っている(noindex・nofollow・robots.txtは、それぞれ何を止めているのか)。

07 自社サイトで確認したこと — 上限との距離を数字で見る

自社のsitemap.xmlは262件・約47KBだった

当サイトのsitemap.xmlを実際に開いて数えたところ、含まれるURLは262件、ファイルサイズは約47,868バイト（約46.7KB）だった。50,000 URL・50MBという上限との差は、件数で190倍以上、サイズで1,000倍以上ある。分割やインデックスファイルが必要になる状況には、まったく到達していない。上限を意識する必要があるかどうかは、まず自分のサイトの実数を出してから判断すればよい話であり、件数を数えもせずに「うちも対応が必要かもしれない」と身構える必要はない。

画像・動画向けの拡張サイトマップは、まだ用意していない

04章で触れた画像・動画・ニュース向けの拡張サイトマップについて、当サイトのsitemap.xmlを確認したところ、現時点ではURLだけを列挙する標準形式のみで、画像や動画に関する拡張情報は含まれていなかった。これは今すぐ対応が必要な不備というより、記事本数・画像点数の規模を踏まえたうえで、優先度が高くないと判断している状態である。何を持っていて、何を持っていないかを、測ったまま記録しておく。

changefreqとpriorityは書かれていたが、効果は確認できなかった

当サイトのsitemap.xmlには、changefreqとpriorityのタグが記載されていた。02章で触れたとおり、Googleはこの2つの値を無視すると公式に明言している。書いてあること自体が問題になるわけではないが、値を細かく調整する作業に時間をかけても、検索結果への反映は期待できない。時間を割くべきはlastmodの正確さのほうであることを、自社のファイルで確認した形になる。

08 このテーマの、これまで

2005年、Google単独の提案として始まった

サイトマップの仕組みは、もともと1つの検索エンジンの独自機能として始まった。Googleは2005年6月にSitemaps 0.84を公開し、クリエイティブ・コモンズのライセンスで仕様を公開した。他の検索エンジンにも採用されることを見込んだ動きだった。

2006年、3社共同のプロトコルになった

その見込みは翌年に実現する。2006年11月16日、Google・Yahoo!・Microsoftの3社が共同で、サイトマップ・プロトコル0.90への対応を発表した。当時のGoogle担当者のコメントが、発表文に残っている。

"Announcing industry supported Sitemaps is an important milestone for all of us because it will help webmasters and search engines get the most relevant information to users faster."

（訳: 業界共通のサイトマップを発表できることは、私たち全員にとって重要な節目だ。ウェブマスターと検索エンジンが、より速くユーザーへ最も関連性の高い情報を届けられるようになる。）

この発表を機に、3社共同運営のsitemaps.orgが仕様書の公開場所になった。ちなみにこの仕様書自体は2016年11月21日の更新を最後に、大きな改定はされていない。一方でGoogle側の解説ページは、2026年7月にも更新されており、数字の基準は同じでも、解説の細部は今も動いている。

2023年、「押す」経路が消えて、「探しに来てもらう」経路だけが残った

もう1つの節目は2023年だ。Googleは2023年6月、サイトマップの更新を検索エンジンへ即座に知らせる「ping」エンドポイントを、半年後に廃止すると発表した。認証なしで誰でも叩けるこの経路の大半が、実際にはスパム目的の送信だったことが理由とされている。既存のコードがこのエンドポイントを呼び続けても検索結果に問題は起きないが、効果も無いという。以後、サイトマップの更新を伝える経路は、robots.txtへの記載とSearch Consoleでの送信という、検索エンジン側が「取りに来る」形の経路に一本化された。再クロールの待ち行列がどれだけの規模になるかを当サイトで実際に測った記事とも、根はつながっている(archives/108)。

この記事の数字も、確認した時点のものとして扱ってほしい

本記事で示したGoogle公式ガイドの更新日は、サイトマップの作成・送信ガイドが2026年7月8日、サイトマップインデックスのガイドが2025年12月10日だった。一方でsitemaps.orgの仕様書自体は2016年11月21日の更新を最後に変わっていない。数字の基準（50,000 URL・50MB）は長く安定している一方、解説の細部はGoogle側で今も更新され続けているという構図がある。本記事の内容も、確認した時点（2026年9月）のものとして扱い、必要なら公式ガイドを直接開いて最新の記載を確認してほしい。

2026年、AIクローラーの時代にも、同じ上限がそのまま使われている

生成AIの検索クローラーが登場した現在も、URL数とファイルサイズの上限は変わっていない。sitemap.xmlとllms.txtは役割も書式もまったく別物だが、「クローラーに一覧を渡して発見を助ける」という発想そのものは共通している。当サイトがllms.txtに59本のURLを積んだまま52日間ログを開かずにいた話(archives/127)は、サイトマップにも同じ形で起こりうる。一覧を用意することと、その一覧が実際に読まれているかを確かめることは、別の作業である。noindexを設定した記事群を1,000件単位で一括解除した際の記録(archives/105)や、出力の値そのものに見つけた4つの小さな穴の中にsitemapが含まれていた回(archives/128)も、この一覧を「渡して終わり」にしないための記録として残している。