11月 14, 2026 ガイド約3分で読める

どんなWebサイトでも使えるXMLサイトマップの作成方法

XMLサイトマップは、サイトのルートに置かれ、検索エンジンに発見してほしいURLをリストしたシンプルなファイルです。インデックスを強制するものでもなければ、ランキング要素でもありません。しかし、新しいサイトや大規模サイト、ナビゲーションの奥深くに埋もれたページにとっては、自分でコントロールできる最も確実な発見シグナルの1つです。このガイドでは、sitemap.xmlに何が含まれるか、どのオプションタグを記入してどれをGoogleが無視するのか、サイトマップ自身のホストと異なるURLをエンジンに黙って破棄させてしまう「1ホストルール」、そして無料のXML Sitemap Generatorで準拠ファイルを作成してGoogle Search Consoleに送信する方法までを解説します。

XMLサイトマップとは？

XMLサイトマップは、通常サイトのルートに置かれるsitemap.xmlという名前のUTF-8 XMLファイルで、sitemaps.orgで定義されたプロトコルに従います。これは2006年に登場したオープン標準で、Google、Yahoo、Microsoftが支援しています。フォーマットは極めてシンプルで、すべてのURLは<url>エントリの中に<loc>子要素を持つ形で並び、それ以外はすべてオプションです。

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

検索エンジンはこのリストを読み込み、すでにクロールしたものと照合し、新しいものだけを取得します。サイトマップが最も役立つのは、リンクによる発見が弱いとき。たとえば被リンクのない新規サイト、大規模なカタログ、深い階層のアーカイブ、移行したばかりのサイトなどです。

lastmod・changefreq・priority：記入すべきものと省略すべきもの

多くのチュートリアルでは、<lastmod>、<changefreq>、<priority>のタグを詰め込んだサイトマップが紹介されています。しかしこの3つのうち2つはGoogleにとって無用の長物であり、残る1つも、値を偽れば逆効果になりえます。

<lastmod> — 記入する。ただし本物の日付だけ。値はW3C Datetime形式で、シンプルなYYYY-MM-DDで構いません。Googleがクロールのスケジューリングにlastmodを使うのは、値が「一貫性を持って検証可能な正確さ」を備えている場合だけです。またプロトコルが求めているのは、サイトマップを生成した日付ではなく、ページが最後に更新された日付です。CMSが実際の更新時刻を把握しているなら含めましょう。再構築のたびにすべてのURLへ今日の日付が刻まれる仕組みなら、タグは省略してください。

<changefreq> — 省略する。プロトコルではdailyやmonthlyといった値はあくまでヒントであって命令ではなく、Googleのドキュメントも「Google ignores <priority> and <changefreq> values.」（Googleは<priority>と<changefreq>の値を無視します）と明言しています。

<priority> — これも省略する。値は0.0〜1.0の範囲で、自サイト内の他のURLとの相対値です。Googleはこの値を無視しますし、すべてを1.0に設定するのは、このタグの意味を消す最も典型的なやり方です。

1ホストルール

サイトマップに含められるのは、単一ホストのURLだけです。どのURLが対象になるかは、サイトマップ自身の設置場所が決めます。https://www.example.com/sitemap.xmlにあるサイトマップはhttps://www.example.com/…のURLをリストできますが、https://example.com/…は不可（wwwなしだと別ホスト）、https://blog.example.com/…も不可（サブドメインは別ホスト）、まったく別のドメインはなおさらです。外部ホストのURLは考慮対象から捨てられます。ファイルは取得されても、それらのURLはどこへも届きません。ドメインのwwwあり・なし両方が解決される場合は、サイトマップファイル自体を、カノニカルとして選んだホストに置いてください。

つまり、カノニカルホストを1つ決め（wwwありかなしかのどちらかで、HTTPS限定）、すべての<loc>をその形式に統一し、サイトマップはサイトのルートに置きます。プロトコル上、サイトマップの適用範囲は自身のパスに限定されるため、/catalog/sitemap.xmlは/catalog/配下のURLしかカバーできません。

XMLサイトマップを作成する手順

ステップ1：カノニカルURLを収集する

インデックスしてほしいすべてのURLを、最終的なカノニカル形式でリストアップします。CMSのエクスポート、アナリティクスの上位ページ、クロール結果などから集めます。サイトがまだ新しい小規模サイト、たとえば20ページ程度なら、最も手っ取り早いソースは自分のサイトのナビゲーションです。すべてのメニューを辿って、ページを1つずつ手作業でリストにします。含めるのは、200を返してインデックス可能なページだけ。リダイレクト、404、noindexページ、パラメータ付きの重複は除外します。リダイレクトやリンク切れはクロールバジェットを浪費します。長く汚いリストより、短くきれいなリストのほうが優れています。

ステップ2：リスクのあるURLが正常に解決されることを確認する

少なくとも、前回の移行やリニューアルより前から存在するURLすべてと、その他のURLのサンプルを確認してください。リンク切れが潜んでいるのは、たいてい古いURLです。redirect chain checkerは1回に1つのURLを扱います。URLを貼り付けてCheck redirectsをクリックし、カノニカルホスト上で余分なホップなしに200を返すことを確認します。そうでないURLは、最終的な宛先に置き換えてください。

ステップ3：無料のXML Sitemap Generatorでファイルを生成する

XML Sitemap Generatorを開き、URLをYour URLsボックスに貼り付けます。1行に1つの絶対URL、最大500件です。次に、3つのオプションを設定します。Last modified dateはデフォルトでUse todayになっていますが、本当にすべてのページが今日更新されたのでない限りOmit lastmodに切り替えてください。ツールはリスト全体に同じ1つの日付を刻むためです。Custom dateは、ページがその日に更新された場合にだけ使います。Change frequencyとPriorityでは、上で説明した理由によりOmit changefreqとOmit priorityを選びます。Generate sitemap.xmlをクリックしたら、チェック結果を確認します。ツールは重複行をスキップし、形式が不正なURLを拒否し、異なるホストのURLが混ざったリストには警告ではなくエラーを表示します。これは「まずリストを修正しよう」という合図です。チェックがすべてグリーンになったら、Copy codeまたはDownload sitemap.xmlを使います。正しい名前空間を持つエンティティエスケープ済みのXMLが、そのままアップロードできる形で出力されます。

URLが500件を超える場合は？リストを分割してsitemap-1.xml、sitemap-2.xml……を生成・アップロードし、1つのサイトマップインデックスでそれらを参照して、Search Consoleには子ファイルではなくインデックスを送信します。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://yourdomain.com/sitemap-1.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://yourdomain.com/sitemap-2.xml</loc>
  </sitemap>
</sitemapindex>

ステップ4：サイトのルートにアップロードし、robots.txtで宣言する

まず、そもそもファイルをアップロードできる環境かどうかを確認します。ホスティング型プラットフォームはサイトマップを自動的に維持してくれます。Shopify、Wix、Squarespaceはいずれも/sitemap.xmlで自動サイトマップを配信しています。その環境を使っている場合は、ステップ5まで読み飛ばしてそのURLを送信してください。それ以外の場合は、SFTPかホスティング事業者のファイルマネージャーでファイルをhttps://yourdomain.com/sitemap.xmlへアップロードし、robots.txtで次のように宣言します。

Sitemap: https://yourdomain.com/sitemap.xml

このディレクティブはUser-agentブロックとは独立していて、複数回記述することもできます。どうせrobots.txtを書き直すなら、無料のRobots.txt Generatorを使えば、Sitemap行を含んだファイルを生成できます。あわせて、robots.txtがリストに上げたページをブロックしていないことも確認してください。サイトマップはdisallowを上書きできないからです。

ステップ5：Google Search Consoleに送信する

robots.txtは発見をもたらし、Search Consoleは診断をもたらします。サイトがまだGSCに登録されていない場合は、まず追加します。Domainプロパティ（全サブドメイン・両プロトコル）かURL prefixプロパティ（1つの正確なプレフィックス）を選び、所有権を確認します。次にIndexing → Sitemapsを開きます。プロパティのアドレスは最初から入力されているので、sitemap.xmlとだけ入力してSubmitをクリックします。1日以内に、Googleがファイルを取得できたか、いくつのURLが発見されたかがレポートに表示されます。大きな変更のあとは再送信してください。2点だけ補足です。旧/ping?sitemap=エンドポイントは2023年6月に廃止されたので、pingの自動化はやめてください。また、Bing Webmaster ToolsはSearch Consoleからサイトをインポートできます（My Sites → Import）。ただしインポートされるのはサイトであってサイトマップの送信履歴ではないので、BWTのSitemapsページで改めてサイトマップを送信してください。

XMLサイトマップでよくあるミス

リダイレクトURLやリンク切れURLを載せる。どれもクロールバジェットの無駄です。生成する前に、リスクのあるURL（少なくとも前回の移行より前のものすべて）を確認しましょう。
ホストを混在させる。1つのファイルにwwwありとなしを混ぜるのが定番のパターンです。プロトコルは外部ホストのURLを切り捨てます。
lastmodにビルド日を刻む。サイトマップを再生成しても、ページが更新されたことにはなりません。Googleがlastmodを使うのは値が一貫して正確な場合だけです。水増しされた日付は、Googleにあなたの値を無視する理由を与えます。
noindexページやカノニカル化されたページを含める。「これをクロールして」と「これはインデックスしないで」という矛盾したシグナルです。
サイトマップを放置して古くする。3ヶ月前に新しいセクションを公開したのにファイルに載っていない？それはGoogleではなくサイトマップ側の責任です。
robots.txtでブロックする。Disallow:ルールが/sitemap.xmlに一致すると、このディレクティブを尊重するクローラーからファイルが隠されます。

よくある質問

サイトマップにchangefreqとpriorityは必要？

必要ありません。Googleのドキュメントでは、<priority>と<changefreq>の値はどちらも無視されると明記されています。Googleが頼りにする唯一のオプションタグは<lastmod>で、しかも日付がページの実際の更新日時と検証可能な形で一致している場合に限ります。シンプルな<loc>URLと正直なlastmod日付だけを記すのが、今のベストプラクティスです。

1つのsitemap.xmlに含められるURLは何件まで？

sitemaps.orgのプロトコルでは、1つのサイトマップファイルは最大50,000URL、または非圧縮で50MBまで。どちらかに先に達した時点が上限です。sitemap.xml.gzとして圧縮して配信しても構いませんが、上限はあくまで非圧縮サイズでカウントされます。それを超える場合は、リストを複数のファイルに分割し、サイトマップインデックスから参照してSearch Consoleに送信します。無料ジェネレーターは1ファイル500URLが上限なので、長いリストの場合はチャンクごとにsitemap-1.xml、sitemap-2.xmlを生成し、ステップ3のインデックスでまとめてください。

sitemap.xmlはサーバーのどこに置くべき？

ドメインのルートディレクトリです。そこに置けばhttps://yourdomain.com/sitemap.xmlとして配信されます。設置場所は内容の範囲も決めます。サブディレクトリにあるサイトマップはそのパス配下のURLしかリストできませんし、リストできるのは常に自身のホストのURLだけです。wwwあり・なし両方が解決される場合、ファイルはカノニカルホストに置くべきです。カノニカルホストのルートに置けば、これらの問題はすべて回避できます。

プラットフォームがサイトマップを自動生成してくれる？更新の頻度は？

おそらくそうです。WordPressはバージョン5.5以降、/wp-sitemap.xmlにサイトマップを自動生成しており、Rank MathやYoastなどのSEOプラグインはこれを独自のインデックス（通常は/sitemap_index.xml）に置き換えます。Shopify、Wix、Squarespaceは/sitemap.xmlを自動的に維持します。CMSが維持してくれるなら再生成は不要です。Search Consoleで内容を確認し、プラグインの設定でnoindexの投稿タイプを除外するだけで済みます。手作業でファイルを作っている場合は、重要なページを追加・削除するたびに再生成して再送信してください。

送信後、インデックスまでどれくらいかかる？保証はある？

取得レポートは通常1日以内に更新されます。インデックスは別の話です。ページが検索結果に現れるまで数日から数週間かかることもあり、送信しても何も保証されません。サイトマップは発見を助ける道具であって、インデックスは依然としてクロールバジェット、コンテンツの品質、robots.txtやnoindexによるブロックに左右されます。発見済みURLがインデックス済みURLよりはるかに多いのは普通のことです。インデックスの問題が解消しない場合、その原因は通常、ファイルではなくページ側にあります。

Search Consoleが「サイトマップを取得できませんでした」と表示した。何を確認すればいい？

原因は3つ考えられます。「Couldn’t fetch」は通常、ファイルが正しく配信されていないことを意味します。ブラウザで/sitemap.xmlを開いて200が返ることを確認し、次にrobots.txtを調べてください。パスに一致するDisallow:ルールはGooglebotをブロックします。個々のURLに「URL blocked by robots.txt」と表示される場合は、サイトマップがrobots.txtで許可されていないページをリストしているということです。リストから外すか、robots.txtのほうを修正してください。そして、フォーマットエラーはXMLの破損を意味します。ルート要素がsitemaps.orgの名前空間を持つ<urlset>であること、アンパサンドが&にエスケープされていることを確認してください。