sitemap.xml 実践ガイド:
lastmod・サイトマップ分割・Next.js動的生成

sitemap.xmlは「検索エンジンに公開URLの一覧と更新状況を伝える地図」です。2026年4月14日時点では、Googleは prioritychangefreq を無視し、lastmod の正確さと canonical URL の整合性を重視すると案内しています。本章では、いま本当に効くサイトマップ設計に絞って解説します。

1. sitemap.xml の基本構造

最小限の有効なXMLサイトマップ

sitemap.xml の基本構造XML
<?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-04-13</lastmod>
  </url>
  <url>
    <loc>https://example.com/about/</loc>
    <lastmod>2026-03-01</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article-1/</loc>
    <lastmod>2026-04-10</lastmod>
  </url>
</urlset>

各要素の解説

要素必須/任意説明
<loc>必須ページのURL。絶対URLで記述する
<lastmod>任意(推奨)最終更新日。ページ本文の更新と整合しているときに価値が高い
<changefreq>任意仕様上は記述可能。ただしGoogleは無視すると明言
<priority>任意仕様上は記述可能。ただしGoogleは無視すると明言

2. Googleが重視する項目と、重視しない項目

priority と changefreq は「書ける」が、Google最適化の主役ではない

sitemap の仕様上、prioritychangefreq は今も記述できます。ただし Google Search Central は、Googleはこの2つの値を無視すると案内しています。実務では「値をどう盛るか」に時間を使うより、lastmod の正確さ、内部リンク、canonical、一貫した公開URL設計に注力したほうが再現性があります。

💡 2026年時点の実務整理
Google向けには、prioritychangefreq を頑張るより、lastmod、公開URLの正規化、内部リンク、Search Console での送信と監視を優先するほうが効果的です。

lastmod の重要性と正確な記述方法

lastmod は、実際にコンテンツが更新された日付を正確に伝えられるときに価値があります。Googleは、lastmod がページ本体の更新と整合しているかを見て利用すると案内しています。クロールを促したいだけで毎回現在日付に書き換えるのは逆効果です。

  • 本文や重要な構造が更新されたときだけ更新する
  • テンプレート変更だけで全URLを書き換えない
  • CMSの更新日時と公開ページの実態がずれていないか確認する
  • サイトマップとページ内の更新表示が極端に矛盾しないようにする

3. canonical と sitemap.xml の関係

sitemap.xml は canonical URL の提出リストとして設計する

sitemap.xmlrel="canonical" は役割が違います。canonical は「重複候補の中で、どのURLを正規URLとして扱ってほしいか」を示すシグナルで、sitemap.xml は「このURLを発見・再クロール・評価してほしい」という提出リストです。実務では、この2つが同じ正規URLを指すように揃っている状態が理想です。

Google Search Central は、sitemap.xml 掲載を canonicalization のシグナルの1つとして扱っています。ただし強さとしては canonical リンクのほうが上です。だからこそ、sitemap.xml には canonical URL だけを載せるのが基本ルールになります。

canonical と sitemap.xml の違い

canonical は「このページ群の代表URLはこれです」という正規化シグナルです。

sitemap.xml は「検索結果に出してほしい公開URLはこれです」という発見・提出シグナルです。

canonical、内部リンク、リダイレクト、sitemap.xml が同じURL設計を向いていると、検索エンジンに意図が伝わりやすくなります。

canonical と sitemap.xml がズレると何が問題か

sitemap.xml に登録したURLの canonical が別URLを指していると、検索エンジンから見ると「提出したいURL」と「正規URLとして採用してほしいURL」が食い違います。その結果、sitemap.xml に載せたURLがそのまま採用されず、canonical 先が正規URLとして選ばれやすくなります。

さらに、計測パラメータ付きURLや並び替えURL、重複URLを大量に sitemap.xml に含めると、重複候補を大量提出しているのと同じです。重要ページの再クロール効率が落ちたり、Search Console で「送信したURL」と「インデックスされた正規URL」が噛み合わない状態が起きやすくなります。

よくある不一致の例

sitemap.xml:

<url>
  <loc>https://example.com/products/shoes?color=black&utm_source=ad</loc>
  <lastmod>2026-04-14</lastmod>
</url>

ページ内 canonical:

<link rel="canonical" href="https://example.com/products/shoes" />

この場合、提出すべきなのはパラメータ付きURLではなく https://example.com/products/shoes です。sitemap.xml には最初から canonical URL だけを載せるほうが、シグナルが揃って再現性の高い運用になります。

sitemap.xml に載せるURL・載せないURLの判断基準

URLの種類sitemap.xml に載せるか理由
自己canonicalの公開URL載せる検索結果に出したい正規URLだから
301/302 リダイレクト元URL載せないすでに別URLへ統合されているため
canonical が別URLを向く重複ページ載せないcanonical 先だけを提出すべきだから
noindex ページ原則載せない検索結果に出したくないURLを提出する意味が薄い
robots.txt で Disallow したURL原則載せないクロール禁止と提出が矛盾するため
計測パラメータ・並び替え・絞り込みURL通常は載せないcanonical で正規化する対象になりやすいため

重要な原則
sitemap.xml には「インデックスしてほしい canonical URL だけ」を載せます。canonical、内部リンク、リダイレクト、sitemap.xml の4つが同じURL設計を向いている状態が理想です。

Next.js で起きやすい canonical 不一致

Next.js ではページ側の metadata.alternates.canonicalapp/sitemap.ts を別々に管理することが多く、片方だけ更新される事故が起きがちです。スラッグ変更、末尾スラッシュ方針変更、URL構造変更のあとに sitemap.xml だけ旧URLのまま残ると、Search Console で提出URLと正規URLのズレが起こりやすくなります。

  • ページの canonical と sitemap の URL を同じソースから生成する
  • 末尾スラッシュ有無、HTTP/HTTPS、www有無をアプリ全体で統一する
  • プレビューURLやパラメータ付きURLを sitemap の生成対象に含めない
  • URL変更時は 301 リダイレクト、canonical、内部リンク、sitemap をセットで更新する

4. 画像・動画サイトマップ

画像サイトマップで補助情報を渡す

通常のサイトマップに画像情報を拡張として追加すると、画像検索や画像発見の補助情報として使えます。特にJavaScriptで遅延表示される画像や、商品ページの複数画像を明示したいときに有効です。

画像サイトマップの構造XML
<?xml version="1.0" encoding="UTF-8"?>
<urlset
  xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://example.com/products/camera-a/</loc>
    <image:image>
      <image:loc>https://example.com/images/camera-a-main.jpg</image:loc>
      <image:title>カメラA 正面写真</image:title>
      <image:caption>○○社製カメラA。重量350g、解像度2400万画素。</image:caption>
    </image:image>
  </url>
</urlset>

5. 大規模サイトでのサイトマップ分割

サイトマップの制限と分割の必要性

1つのサイトマップファイルには最大50,000 URL・50MB(非圧縮)という制限があります。これを超える場合は、複数のサイトマップファイルに分割し、サイトマップインデックスファイルでまとめます。

サイトマップインデックスの構造XML
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-articles.xml</loc>
    <lastmod>2026-04-13</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-04-13</lastmod>
  </sitemap>
</sitemapindex>

6. Next.js での動的 sitemap.xml 生成

app/sitemap.ts の実装

app/sitemap.ts の実装例TypeScript / Next.js
// app/sitemap.ts
import { MetadataRoute } from 'next';

async function getArticles(): Promise<{ slug: string; updatedAt: string }[]> {
  return [
    { slug: 'article-1', updatedAt: '2026-04-10' },
    { slug: 'article-2', updatedAt: '2026-04-08' },
  ];
}

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const baseUrl = process.env.NEXT_PUBLIC_SITE_URL || 'https://example.com';

  const staticPages: MetadataRoute.Sitemap = [
    {
      url: baseUrl,
      lastModified: new Date('2026-04-13'),
    },
    {
      url: baseUrl + '/articles',
      lastModified: new Date('2026-04-13'),
    },
    {
      url: baseUrl + '/about',
      lastModified: new Date('2026-01-01'),
    },
  ];

  const articles = await getArticles();
  const articlePages: MetadataRoute.Sitemap = articles.map((article) => ({
    url: baseUrl + '/articles/' + article.slug,
    lastModified: new Date(article.updatedAt),
  }));

  return [...staticPages, ...articlePages];
}

7. Google Search Console へのサイトマップ送信

送信手順と確認ポイント

1
Search Console で対象プロパティを選択Domain property か URL-prefix property のどちらかで管理します。
2
「インデックス作成」→「サイトマップ」を開く送信済みサイトマップの状態と、最近の処理結果を確認できます。
3
/sitemap.xml またはインデックスファイルを送信分割している場合は、個別ファイルではなくインデックスファイルを送ると運用しやすくなります。
4
送信後はURL数の差より「含めるべきURLだけが入っているか」を確認インデックス数との差異は自然に出ます。まずは noindex、canonical、robots.txt との矛盾がないかを見ます。

サイトマップに含めてはいけないURL

sitemap.xml に含めるURLは、クロール可能・インデックス可能・canonical が自分自身を指しているページに限定します。

⚠️ サイトマップに含めてはいけないもの
・robots.txt でDisallowしているURL
<meta name="robots" content="noindex"> が設定されているページ
・301リダイレクト元URL
・canonical が別URLを指しているページ
・認証が必要なページ

sitemap.xml の問題を
自動検出しましょう

AIOGeoScanは、sitemap.xmlに含まれるURLのインデックス状況、noindexとの矛盾、lastmodの精度、Search Consoleとの差異をまとめて診断します。

今すぐ自社サイトを無料診断する
Editorial Trust Signals

このナレッジベースの編集方針

`AIOGeoScan Knowledge` は、Bennu Inc. が運営する AI検索・構造化データ・クローラー制御に関する実務ナレッジです。 Google Search Central、Schema.org、OpenAI などの一次情報を優先し、観測ベースの実務知見は本文中で区別して扱います。

運営主体
Bennu Inc. / AIOGeoScan
更新方針
仕様変更や検索機能の更新にあわせて都度改訂
優先ソース
公式ドキュメント・標準仕様・公式ヘルプ
補助ソース
実装観測・運用知見・再現性のある検証結果

あなたのサイト、AIに正しく伝わっていますか?

解説を読み終えたら、実際にあなたのサイトを診断してみましょう。
100項目以上の診断で、AI時代の構造課題を可視化します。

無料で診断を開始する