株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
XMLサイトマップとは
XMLサイトマップ（sitemap.xml）とは、検索結果に載せたい正規ページなどのURLをXML形式で記述したファイルです。検索エンジンによるURLの発見やクロールを助けるために使用します。
サイトマップは検索順位を直接上げるものではありませんが、新規・更新コンテンツの存在を検索エンジンに伝える役割があります。新しい記事を公開した際には内部リンクと併せてURLを知らせます。ただし、掲載した全URLのクロールやインデックスは保証されず、反映までの期間も一定ではありません。
サイトマップが特に重要なケース
- 大規模サイト（重要ページへのリンクを管理しきれない場合）：クローラーがすべてのページを発見できない可能性がある
- 新しいサイト：被リンクが少なく、外部からの発見経路が限られる
- 頻繁に更新するサイト：ブログ・ニュースサイト・ECサイトなど、日常的にページが追加される
- 孤立したページがあるサイト：内部リンクが十分でないページの発見を助ける
- CMS連携で記事数が急増するサイト：ヘッドレスCMSで公開記事が増える場合、サイトマップのURL一覧とCMSの公開状態を照合し、掲載漏れや非公開URLの混入を確認する
XMLサイトマップの技術仕様
| 要素 | 必須/任意 | 説明 |
|---|---|---|
| <loc> | 必須 | ページの絶対URL（https://から始まる正規URL） |
| <lastmod> | 推奨 | 最終更新日（YYYY-MM-DD形式）。Googleが更新検知に使用 |
| <changefreq> | 任意 | 更新頻度（daily/weekly等）。2026年現在、Googleは無視する |
| <priority> | 任意 | 優先度（0.0〜1.0）。2026年現在、Googleは無視する |
重要な制約：1つのサイトマップファイルにつき最大50,000URL、ファイルサイズ最大50MB（非圧縮）。超える場合はサイトマップインデックスファイルで分割が必要です。上限はURL数と非圧縮ファイルサイズの両方です。管理しやすいカテゴリや更新頻度で分割し、各ファイルの件数・サイズとSearch Consoleの処理状況を確認します。3万URLなら数日で処理されるという期限保証はありません。
クロールバジェットとサイトマップの関係
Googleは各サイトに「クロールバジェット」（一定期間にクロールするページ数の上限）を割り当てています。サイトマップに不要なURLが含まれていると、このバジェットが浪費され、本当にインデックスしたいページのクロールが遅れます。
クロールバジェットを浪費する典型パターン
| パターン | 問題 | 対策 |
|---|---|---|
| noindexページがサイトマップに含まれる | 「インデックスして」と「インデックスしないで」の矛盾シグナル | noindexページをサイトマップから除外 |
| リダイレクト元URLの掲載 | クローラーが301/302を辿る必要がある | 検索結果に載せたい最終到達先の正規URLを掲載 |
| パラメータ付きURLの重複 | ?sort=price等が大量に含まれる | canonical URLのみ掲載 |
| robots.txtでブロック中のURL | クロールしようとして失敗を繰り返す | ブロックURLをサイトマップから除外 |
| Feedページ・カテゴリ一覧ページ | 独自コンテンツがなくインデックス価値が低い | noindex設定＋サイトマップ除外 |
サイトマップに混入していないか確認するURL
本稿では、インデックス未登録URLを確認する際に、記事本体と以下のURLを分けて調べる手順を提案します。掲載の要否は各ページを検索結果に載せたいかで判断します。
- RSSフィード（/feed/）：CMSが自動生成するフィードページがサイトマップに含まれるケース → noindexに設定しサイトマップから除外
- カテゴリー・タグアーカイブページ：記事一覧だけで独自コンテンツがないページ → noindex設定で対応
- CMSの初期設定ページ：Hello World等のサンプルページ → 削除
- XMLサイトマップ自体：URL検査でのインデックス有無と、サイトマップ送信の取得・解析エラーは分けて確認する。送信で取得失敗や形式エラーが出ている場合は、その原因を修正する
確認手順として、まず検索対象にする正規ページの一覧とサイトマップを照合し、次にSearch Consoleで未登録理由を確認します。対象ページのインデックス状況を変更前後で追い、同時に行った本文修正や内部リンク変更も記録します。サイトマップの変更だけの効果とは決めつけません。
動的サイトマップの実装（Next.js）
2026年の多くのWebサイトはNext.jsなどのフレームワークで構築されており、サイトマップも動的に生成するのがベストプラクティスです。
Next.js App Routerでの実装
Next.jsのApp Routerでは、app/sitemap.tsからURL配列を返す関数を公開し、MetadataRoute.Sitemap型を使ってサイトマップを生成できます。CMSやデータベースから公開ページ一覧と更新日を取得する処理は実装が必要です。このルートは、リクエスト時APIや動的設定等を使わなければ標準でキャッシュされます。
ヘッドレスCMSと連携する場合は、ページ分割された取得結果も含めて公開記事を集め、サイトマップを生成します。記事の追加・削除・更新が反映される時点は、再生成・キャッシュ更新の設定で変わります。公開・非公開への変更後に実際のサイトマップを取得し、URL一覧と更新日を確認します。
大規模サイトでのサイトマップ分割
複数ファイルに分ける場合は、Next.jsのgenerateSitemaps関数で各サイトマップのIDを返し、IDに対応するURL一覧を生成します。公式の複数サイトマップ例を参考に、各ファイルを50,000URL以下・非圧縮50MB以下に収めます。関数名だけでURL取得や分割処理が自動実装されるわけではありません。
lastmodの正確性が与えるSEOインパクト
lastmod（最終更新日）はGoogleがページの再クロール判断に使用する重要なシグナルです。ただし、実質的なコンテンツ更新がないのにlastmodだけを変更する行為は逆効果です。
- 正しい運用：記事の本文を加筆・修正した場合にlastmodを更新。CMSの更新日時と自動連動させるのが理想
- 避けるべき運用：テンプレート変更やCSS修正でlastmodが全ページ一括更新されるケース → Googleがlastmodを信頼しなくなる
- 効果的な活用：記事に1次情報（実績データ、専門家の見解、独自調査結果）を追記した際にlastmodを更新すると、再クロール→再評価のサイクルが早まる
Google Search Consoleでのサイトマップ運用
提出と監視の手順
- サイトマップの提出：Search Console → サイトマップ → URLを入力して送信
- ステータス確認：「成功」表示を確認。エラーがある場合はURL形式や文字コード（UTF-8必須）を確認
- 検出URL数の監視：提出URL数とインデックス済みURL数の乖離が大きい場合、コンテンツ品質やnoindex設定を見直す
インデックスカバレッジレポートの活用
Search Consoleの「ページ」レポートで「クロール済み - インデックス未登録」のURLを定期分析します。対応方針は以下の通りです。
- コンテンツが薄い記事：1次情報・独自データ・専門家の見解を追加してリライト
- 重複コンテンツ：類似記事を統合し、canonical URLに集約
- 低品質ページ：削除してサイト全体の品質比率を改善
- 技術的問題：noindex/canonicalの誤設定を修正
運用例として、担当者と確認日を決めてインデックス数の推移を記録し、URL検査ツールで個別ページの未登録理由を確認します。大きな更新や公開状態の変更後には、定例確認を待たずに対象URLも確認します。
サイトマップチェックの自動化
サイトマップの健全性を手動で確認し続けるのは、記事数が増えるほど困難です。以下の自動チェック体制で問題を早期発見できます。
- URL数の監視：サイトマップ内のURL数とCMS上の公開記事数の一致を定期確認
- noindex矛盾の検出：サイトマップ内URLにnoindexが含まれていないか自動スキャン
- リダイレクトチェーンの検出：301/302リダイレクトが発生するURLを自動除外
- lastmodの妥当性検証：全URLのlastmodが同一日に集中していないかチェック
2026年のサイトマップ最新トレンド
priorityとchangefreqのGoogleでの扱い
Googleはpriority・changefreqを無視しますが、Sitemapsプロトコルには任意要素として存在しています。Google向けの運用では、それらの値によるクロール順序の指定を期待せず、lastmodの正確さや掲載URL、本文品質を確認します。
hreflangとサイトマップの連携
多言語サイトでは、サイトマップ内にhreflangアノテーションを含めることで、各言語バージョンのページを正確に検索エンジンに伝えられます。
動的生成 × CI/CDパイプライン
モダンなWeb開発ではCI/CDパイプラインにサイトマップの検証ステップを組み込む手法が広がっています。デプロイ前にURL数・形式・noindex矛盾をチェックし、問題があればデプロイを停止する仕組みです。
よくある質問（FAQ）
Q. サイトマップがないとSEOに不利ですか？
A. 検索順位を直接上げる仕組みではなく、URLの発見を助けます。Googleは約500ページ以下で内部リンクが十分なサイト等では不要な場合もあると説明しています。500ページを超えると必須になる規則ではなく、大規模・複雑なサイトや外部リンクが少ない新規サイトでは利用を検討します。
Q. サイトマップはどこに設置すべきですか？
A. ルートディレクトリ（https://yourdomain.com/sitemap.xml）に設置し、robots.txtにURLを記載、Search Consoleにも提出します。
Q. サイトマップに含めるべきでないURLは？
A. noindexページ、リダイレクトURL、robots.txtでブロック中のURL、パラメータ付き重複URL、フィードページ、独自コンテンツのないアーカイブページです。
Q. 「クロール済み - インデックス未登録」が増えた場合は？
A. サイトマップから不要URL（noindex・feed等）を除外し、薄い記事には1次情報を追加してリライトします。アルゴリズム変更の一時的影響の場合もあるため、URL検査で個別確認します。
SEO・サイトマップ最適化のご相談はrenueへ
renueは動的サイトマップの実装からインデックス最適化・クロールバジェット管理まで、テクニカルSEOを支援しています。公開URL一覧・サイトマップ・Search Consoleの状態を照合し、御社のインデックス課題の整理と改善をご支援します。
