サイトマップに載せるページの決め方｜除外条件と確認方法

サイトマップに載せるページの判断基準は1つです。「検索結果に表示したい、正規のURLかどうか」。これだけです。noindexを付けたページ、リダイレクトの元になっている旧URL、canonicalで別のURLを指しているページは、すべて載せません。載せると、検索エンジンに向かって「これを見てほしい」と「これは見なくていい」を同時に伝えることになり、どちらの指示も弱まります。

この記事は、WordPressや自社サイトのサイトマップを自分で見直したい広報・Web担当の方に向けて書いています。読み終わる頃には、自社のサイトマップを開いて「このURLは残す・これは外す」を1件ずつ判断でき、サーチコンソールで送信と確認まで済ませられる状態を目指します。

扱うのは検索エンジン向けのXMLサイトマップです。サーチコンソールそのものの見方はサーチコンソールで最初に見る4つの画面の使い方で解説しているので、アカウントを登録したばかりの方は先にそちらを読んでください。

Contents / 目次

1. サイトマップに載せるのは、検索結果に出したい正規URLだけ
2. サイトマップから除外する条件。実際に混ざりやすい7タイプ
3. サイトマップを作ってサーチコンソールに送信するまでの手順
4. サーチコンソールでサイトマップを確認する手順とエラーの読み方
5. 載せるページを絞ると何が変わるか
6. サイトマップでよくある失敗と回避法
7. プラグイン任せの限界と、運用で妥協するところ
8. サイトマップについてよくある質問
9. 今日の1分でできることと、次に読むページ

サイトマップに載せるのは、検索結果に出したい正規URLだけ

XMLサイトマップとは、検索エンジンに「このサイトにはこういうURLがあります」と一覧で知らせるためのファイルです。人が読むページではなく、クローラー（サイトを巡回して情報を集めるプログラム）に渡す名簿だと考えてください。

名簿なので、載せるのは「会いに来てほしい相手」だけです。Google検索セントラルのサイトマップの作成ドキュメントでも、Googleの検索結果に表示させたいURLをサイトマップに含めることが案内されています。逆に言えば、出したくないURLを名簿に書く理由はどこにもありません。

まず、自社サイトによくあるページを一覧で仕分けてみましょう。

ページの種類	サイトマップ	そう判断する理由
トップ・サービス紹介・事例・コラム本文・会社概要	載せる	検索結果に出したい正規URL
canonicalで別のURLを指しているページ	載せない	自分が正規URLだと宣言していない
noindexを付けたページ（送信完了ページ、会員限定など）	載せない	「検索結果に出さない」と自分で指定している
リダイレクト元の旧URL	載せない	開くと別のURLに飛ぶ
404・410になるURL	載せない	ページが存在しない
robots.txtで読み取りを断っているURL	載せない	クローラーが中身を読めない
絞り込み・並べ替えのパラメータが付いたURL	載せない	中身が元のページとほぼ同じ
タグ・著者・年月別アーカイブ、添付ファイルページ	方針で決める	そのページ単体で検索から来てほしいかで判断

載せるか迷ったときの4つの質問

迷ったURLは、次の4問で判定できます。ブラウザのシークレットウィンドウでそのURLを開きながら、上から順に確認してください。

1. そのURLを開いたとき、リダイレクトもエラーもせず、そのページがそのまま表示されるか
2. ページのソースに noindex が入っていないか（ブラウザでページのソースを表示し、robotsで検索する）
3. そのページの canonical が、自分自身のURLを指しているか
4. そのページを、検索結果に出したいと思っているか

4つとも「はい」なら載せます。1つでも「いいえ」があれば載せません。特に4問目で「出したくない」となったページは、サイトマップから外すだけでは足りません。noindexを付けて、検索結果に出さない意思表示までセットで行います。noindexとnofollowの使い分けはnoindexとnofollowの違いと設定手順で解説しています。

サイトマップから外しても、そのページが検索結果に出なくなるわけではありません。Google検索セントラルのサイトマップの概要では、サイトマップはクロールしてほしいURLを伝えるための手段だと説明されており、掲載の有無が検索結果からの除外を決めるものではありません。検索結果から確実に外したいときは、Google公式のnoindexの解説のとおりnoindexを使ってください（2026年8月31日時点）。

3問目の「canonicalが自分自身を指しているか」でつまずく方が多い部分です。wwwのあり・なし、httpとhttpsが混在したままだと、サイトマップに書いたURLと正規URLが食い違います。この土台が崩れている場合は、wwwありなしとhttpsを集約するURL正規化の手順を先に済ませたほうが早いです。

この章の結論。サイトマップは「出したいページの名簿」なので、開けて・noindexでなく・自分が正規URLで・出したいページだけを載せます。この4条件を満たさないURLは、理由を考える前に外して構いません。

サイトマップから除外する条件。実際に混ざりやすい7タイプ

除外の条件は「クローラーに渡しても行き止まりになるURL」と「自分で出さないと決めたURL」の2種類に分かれます。自動生成に任せていると、次の7タイプが知らないうちに混ざります。

• noindexページ：問い合わせ送信完了ページ、資料ダウンロード後のページ、会員限定ページなど。除外の代表格
• リダイレクト元の旧URL：サイトリニューアルやURL変更で301を設定した側。新URLだけ載せる
• 削除済みページ：404・410を返すURL。プラグインのキャッシュに残っていることがある
• robots.txtで拒否しているURL：読み取りを断っているのに名簿には載っている、という矛盾になる
• パラメータ付きURL：?s= のサイト内検索結果、?orderby= の並べ替え、広告用の計測パラメータ付きURL。前章の4つの質問に照らして、canonicalが別URLを指しているものは載せない
• ページャーの2ページ目以降：一覧の /page/2/ 以降。canonicalが自分自身を指していて、そのページ単体で検索から来てほしいかどうかで判断する
• 添付ファイルページ：画像単体を表示するだけのURL。自社サイトで出力されているかは、画像のファイル名を含むURLを実際に開いて確認する

noindexページを載せると何が起きるか

noindexページをサイトマップに載せると、サーチコンソールの「ページのインデックス作成」レポートで未登録として扱われます。未登録の理由の分類や表示名は変わることがあるため、実際の表示はGoogle公式のページのインデックス作成レポートのヘルプで確認してください（2026年8月31日時点）。エラーとして真っ赤になるわけではないので、気づかず放置されがちです。

問題はエラー表示そのものではありません。サイトマップは「クロールしてほしいURL」を伝える手段なのに、そこに出す気のないページが並ぶと、本当に見てほしいページの割合が下がることです。

タグ・著者アーカイブは載せるべきか

タグアーカイブと著者アーカイブは、載せる・載せないの判断が分かれます。決め方はシンプルで、そのページを開いたときに、検索から来た人が納得する中身があるかで決めます。

記事タイトルが3件並んでいるだけのタグページなら、載せる価値はありません。逆に、そのタグに20本以上の記事があり、上部に説明文を置いてまとめページとして作り込んでいるなら、載せて構いません。著者アーカイブも同じで、プロフィールと実績を書いているなら残します。

判断が付かないうちに全部載せると、似た内容のページ同士が検索結果を取り合う原因になります。この症状が出ているときの直し方はキーワードカニバリゼーションの直し方（統合と削除の判断）にまとめています。

robots.txtで拒否したURLは載せない

robots.txtで読み取りを断っているURLをサイトマップに載せるのは、矛盾した指示です。「入らないでください」と貼り紙をした部屋を、案内図に載せているのと同じ状態になります。

robots.txtの記述自体を見直したい場合は、コピペで使えるrobots.txtの書き方と確認手順を参照してください。サイトマップの場所をrobots.txtに書く行についても、この記事の次の章で扱います。

この章の結論。除外すべきURLは「行き止まりになるもの」と「自分で出さないと決めたもの」です。判断が分かれるのはタグ・著者アーカイブだけで、ここは中身の作り込み具合で決めます。

サイトマップを作ってサーチコンソールに送信するまでの手順

作成から送信までは5ステップです。WordPressを使っている場合と、手書きでXMLを用意する場合の両方を書きます。かかる時間はページ数と使っているプラグインの構成で大きく変わるので、まずステップ1の確認から始めてください。

ステップ1。いま自社にサイトマップがあるか確認する

最初にやるのは、すでにあるかどうかの確認です。作る前に探してください。二重に作ってしまう事故がここで防げます。

ブラウザのアドレス欄に、自社ドメインに続けて次のパスを1つずつ入力して開きます。

• /wp-sitemap.xml：WordPressが標準で出力するサイトマップのパス。実際に出力されているかは、このURLを開いてXMLが表示されるかで確認する
• /sitemap.xml：もっとも一般的な置き場所
• /sitemap_index.xml：サイトマップを分割している場合に、親ファイルの置き場所としてよく使われるパス
• /robots.txt：ファイル内に Sitemap: で始まる行があれば、そこに書かれたURLが正解

2つ以上開けてしまった場合は、二重にサイトマップが存在している状態です。この場合の対処はステップ3で扱います。

ステップ2。載せるURLの一覧を作る

プラグインに任せる場合でも、この作業はやってください。出力結果を確認するための「正解の一覧」がないと、何が余計なのか判断できないからです。

Excelやスプレッドシートに1列でURLを書き出し、隣の列に前章の4つの質問の結果を記入します。実際にやると、思っていたより余計なURLが多いことに気づきます。混ざる量はサイトの作りやプラグインの設定で大きく変わるので、件数を見積もらずに、まず自社の出力を1件ずつ確認してください。

ステップ3。サイトマップを1本に決めて出力する

WordPressの場合、サイトマップの出力元は1つに絞ります。標準機能とSEOプラグインの両方から出ている状態を放置すると、更新されない古い名簿がネット上に残り続けます。

SEOプラグイン側のサイトマップ機能を使う場合は、使っているプラグインの公式ドキュメントで挙動を確認し、そのうえで必ず自分で /wp-sitemap.xml を開いて実際の出力を確かめてください。まだ開ける状態なら、出力元が2本ある状態です。設定画面の表示と実際の出力が食い違っていることが、実際にあります。

プラグイン選びの注意。使っているプラグインにサイトマップ機能があるかどうか、あるなら標準の /wp-sitemap.xml がどう扱われるかは、そのプラグインの公式ドキュメントで確認してください（2026年8月31日時点）。

手書きで作る場合は、次のXMLをコピーして使えます。テキストエディタで作り、UTF-8で保存してサイトのルート直下にアップロードします。

<?xml version="1.0" encoding="UTF-8"?>
<!-- 保存はUTF-8。サイトのルート直下（例 https://example.com/sitemap.xml）に置く -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

  <url>
    <!-- ［ここを自社の正規URLに変更］httpsから始まる絶対URLで書く -->
    <loc>https://example.com/</loc>
    <!-- 最後に中身を意味のある形で更新した日。YYYY-MM-DD でよい -->
    <lastmod>2026-08-31</lastmod>
  </url>

  <url>
    <loc>https://example.com/service/</loc>
    <lastmod>2026-08-20</lastmod>
  </url>

  <!-- 載せるURLの数だけ <url>〜</url> を繰り返す -->

</urlset>

つまずきやすいのは、次の3か所です。1つ目と2つ目は sitemaps.org のプロトコル仕様の「XML タグの定義」と「エンティティのエスケープ」の項に、3つ目は同ページの「サイトマップファイルの場所」の項に書かれています。Googleの扱いはGoogle検索セントラルのサイトマップの作成と送信で確認してください（2026年8月31日時点）。

• 相対パスは使えない：<loc> には /service/ のような書き方ではなく、httpsから始まる絶対URLを書く
• 特殊文字はエスケープする：URLに & が含まれる場合は & に置き換える
• 置き場所より上の階層は載せられない：サイトマップの適用範囲は、置いた場所の階層から下に限られる。/blog/sitemap.xml に置くとそれより上のURLは載せられないため、特別な理由がなければルート直下に置く

ページ数が多くてファイルを分けたいときは、分けたサイトマップをまとめる「サイトマップインデックス」を作ります。

<?xml version="1.0" encoding="UTF-8"?>
<!-- 複数のサイトマップをまとめる親ファイル。これをサーチコンソールに送信する -->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">

  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-08-31</lastmod>
  </sitemap>

  <sitemap>
    <loc>https://example.com/sitemap-posts.xml</loc>
    <lastmod>2026-08-31</lastmod>
  </sitemap>

</sitemapindex>

1つのサイトマップファイルに入れられるURL数と容量には上限があります。Google検索セントラルのサイトマップの作成ドキュメントでは、1ファイルにつき50,000 URLまたは50MB（未圧縮）が上限とされています（2026年8月31日時点）。上限は変わることがあるので、大規模サイトで分割設計を決めるときはGoogle検索セントラルのサイトマップの作成と送信で最新の値を確認してください。

ステップ4。robots.txtにサイトマップの場所を書く

robots.txtの末尾に1行足すだけです。これを書いておくと、サーチコンソールに登録していない検索エンジンにもサイトマップの場所が伝わります。

# robots.txt の末尾に追記する。1行だけでよい
# ［ここを自社のサイトマップURLに変更］絶対URLで書く

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

サイトマップを分割している場合は、親のサイトマップインデックスのURLを1本書けば足ります。子のファイルを全部並べる必要はありません。

ステップ5。サーチコンソールにサイトマップを送信する

サーチコンソールの左メニューから「サイトマップ」を開き、新しいサイトマップの追加欄にサイトマップのURLを入力して送信します。プロパティの所有者権限が必要なので、制作会社にアカウントを預けたままの方は権限の確認から始めてください（権限の渡し方はサーチコンソールの権限付与と削除の手順にまとめています）。

入力欄にはドメイン部分がすでに入っているので、その後ろの部分だけを入れます。画面の名称やボタンの位置は変わることがあるため、迷ったらGoogle公式のサイトマップレポートのヘルプで最新の操作を確認してください。

送信前に、次の6項目を確認しておくと差し戻しがなくなります。

• ブラウザで開けるか：サイトマップのURLを直接開いて、XMLが表示されるか
• httpsで書かれているか：サイト内のURLがhttpのまま残っていないか
• wwwの有無が一致しているか：正規URLと1文字ずつ同じか
• noindexページが混ざっていないか：送信完了ページ、会員ページ、テスト用ページ
• 削除済みページが残っていないか：気になるURLを3つほど抜き取って開いてみる
• サイトマップが1本に絞れているか：ステップ1で開いた候補が1つだけになっているか

この章の結論。手順の山場は、作ることではなく「出力元を1本に絞ること」と「送信前に中身を自分の目で見ること」です。ここさえ通れば、送信自体は数分で終わります。

サーチコンソールでサイトマップを確認する手順とエラーの読み方

送信して終わりにせず、翌日と1週間後にサイトマップのレポートを開いてください。見るのは「ステータス」と「検出されたページ数」の2つだけです。

ステータスは、正常に読めていれば成功と表示されます。読み取れなかった場合や、読めたけれど中にエラーがある場合は、その旨が表示されます。表示名は変わることがあるので、見慣れない文言が出たらヘルプで確認してください。

症状ごとの原因と対処を一覧にします。

症状	よくある原因	対処
サイトマップを取得できない	URLの打ち間違い、ファイル未アップロード、robots.txtで拒否している	ブラウザでそのURLを開き、XMLが表示されるか確認する
読めたがエラーがある	相対URLで書いている、&のエスケープ漏れ、タグの閉じ忘れ	該当行をXMLの記述例と1字ずつ見比べる
検出されたページ数が0	URLが1件も書かれていない、生成が空振りしている	サイトマップを開いて中身が空でないか確認する
検出されたページ数が実際より極端に少ない	分割したうち親だけ送信、生成キャッシュが古い	親のインデックスファイルを送信し、キャッシュを更新する
検出されたページ数が実際より多い	パラメータ付きURLや添付ファイルページが混ざっている	プラグインの除外設定を見直し、出力を再確認する

「検出されたページ数」は、サイトマップから読み取れたURLの件数です。インデックス登録された件数ではありません。ここを取り違えて「サイトマップは正常なのに順位が上がらない」と悩む方が多いので、最初に押さえておいてください。

実際にインデックスされたかどうかは、サイトマップのレポートではなく「ページのインデックス作成」レポートで見ます。このレポートで何が確認できるか、画面のどこで絞り込むかは変わることがあるため、Google公式のページのインデックス作成レポートのヘルプで最新の操作を確認してください。未登録の理由の読み方はサーチコンソールで除外を確認する手順と未登録の直し方で詳しく解説しています。

この章の結論。サイトマップのレポートで分かるのは「名簿を渡せたか」までです。渡した後どうなったかは、ページのインデックス作成レポートで別に確認します。この2画面の役割を分けて見ると、原因の切り分けが一気に速くなります。

載せるページを絞ると何が変わるか

先に、期待してはいけないことを書きます。サイトマップを直しても、検索順位は上がりません。サイトマップは順位を決める要素ではなく、あくまで発見を助けるファイルです。Google検索セントラルのサイトマップの概要でも、サイトマップはURLの発見を助けるが、サイトマップに含まれるすべての項目がクロール・インデックスされることを保証するものではない、と明記されています（2026年8月31日時点）。

では何が変わるのか。変わるのは次の3つです。

• 新しいページが見つかるまでの時間：公開したページが名簿に自動で載る状態になり、内部リンクが少ない新規ページでも発見されやすくなる
• 問題の切り分けにかかる時間：「送ったURL」と「登録されたURL」を突き合わせられるので、原因がページ側かサイト側かを分けて考えられる
• 更新シグナルの信頼度：lastmodが正確に動いていれば、更新を伝える手がかりとして使われる

3つ目のlastmodは、雑に扱うと逆効果になります。Google検索セントラルのサイトマップの作成と送信では、lastmodについて「一貫して検証可能なほど正確である場合に、その値を使用します」と説明されています（2026年8月31日時点）。裏を返せば、中身を変えていないのに日付だけ今日にする運用を続けると、その値は当てにされなくなるということです。

テーマの更新やデータベース移行の後に全記事のlastmodが同じ日付になっていないか、送信後に一度だけ確認してください。数百件のlastmodが全部同じ日付になっているサイトマップは、実際に見かけます。

もう1つ、率直に書いておきます。そもそもサイトマップが要らないサイトもあります。Google検索セントラルのサイトマップの概要では、ページ数がおおむね500ページ以下で、内部リンクで全ページにたどり着ける小規模サイトなら、サイトマップは必要ないとされています（2026年8月31日時点）。

20ページのコーポレートサイトでサイトマップの精度に時間をかけるより、内部リンクの張り方を見直したほうが効きます。優先順位に迷ったら内部リンクの貼り方とアンカーテキスト最適化の5ステップを先に読んでください。

この章の結論。サイトマップの整備で得られるのは「発見の速さ」と「原因の切り分けやすさ」であって、順位そのものではありません。500ページ以下で内部リンクが行き届いているサイトなら、力の入れどころは別にあります。

サイトマップでよくある失敗と回避法

サイトマップ特有の失敗は、ほとんどが「一度作ったあとの変化に追いつけていない」ことから起きます。4つ挙げます。

失敗1。プラグインを乗り換えて、サイトマップが2本になったまま

SEOプラグインを別のものに入れ替えたとき、前のプラグインが出していたサイトマップのURLが残ることがあります。サーチコンソールには古いURLが登録されたまま、実際に更新されているのは新しいURL、という状態になります。

こうなると、古い名簿には削除済みのページが残り、新しく公開したページは載りません。取得できないエラーが出ればまだ気づけますが、古いファイルがそのまま開ける状態だと、成功の表示のまま何か月も気づかないことがあります。

防ぎ方は、プラグインを入れ替えた日に、ステップ1で挙げた4つのURLをもう一度開くことです。開けるサイトマップが2本以上あれば、使わないほうを止めて、サーチコンソール側の登録も削除します。

失敗2。noindexを付けたのに、サイトマップから外し忘れる

キャンペーン終了後のLPや、古い採用ページにnoindexを付けたときに起きます。noindexは付けたけれど、サイトマップの生成設定は触っていない、というパターンです。

結果として、名簿には載っているのに「見なくていい」と書かれたページが増えます。すぐ順位が落ちるような話ではありませんが、送信URLに対する登録率が下がるので、レポートを見たときに状況が読み取りづらくなります。

防ぎ方は、noindexを付ける作業とサイトマップの確認を1セットの作業にしておくことです。noindexを付けたら、その足でサイトマップのURLを開き、ブラウザの検索機能でそのURLが残っていないかを確認します。30秒で終わります。

失敗3。URL正規化の直後に、サイトマップだけ古い書式のまま

常時SSL化やwww統一を行った直後に起きます。サイト側は301でhttpsに集約されているのに、サイトマップの中のURLはhttpのまま、という状態です。手書きのサイトマップや、生成結果をキャッシュしているプラグインで起こります。

この場合、サイトマップに書かれた全URLがリダイレクトされることになり、クローラーは毎回1回余分に移動させられます。エラーにはならないので気づきにくく、順位が下がった原因を探して何週間も別のところを見てしまうことがあります。

防ぎ方は、URLに関わる変更をした日に、サイトマップを開いて先頭のURLを1つ見ることです。<loc> の中身がhttpsで始まり、wwwの有無が正規URLと一致していれば通過です。

失敗4。サイトマップの中身をコピーで作り直して、書式が壊れる

手書きでサイトマップを運用しているとき、既存のブロックをコピーしてURLだけ書き換える作業で起きます。多いのは次の3パターンです。

• 閉じタグの消し忘れ：</url> や </loc> が欠けている
• 全角スペースの混入：タグやURLの中に全角スペースが紛れ込んでいる
• エスケープ漏れ：URLに含まれる & をそのまま書いてしまう

1か所壊れると、サーチコンソールでは読めたけれどエラーがある、という表示になります。壊れた行より後ろのURLが読み取られないこともあり、検出されたページ数が急に減ります。

防ぎ方は、アップロードする前にブラウザでそのXMLファイルを直接開くことです。書式が壊れていれば、ブラウザがその場でエラーを表示します。サーバーに上げてから気づくより、はるかに速く直せます。

この章の結論。4つとも「サイトの何かを変えた日」に起きています。プラグイン変更・noindex追加・URL変更・手作業での編集。この4つの作業の直後にサイトマップを開く習慣を付けるだけで、ほぼ防げます。

プラグイン任せの限界と、運用で妥協するところ

ここからは、教科書には書きにくい話をします。サイトマップの運用は、精度を上げようとするとキリがない領域です。どこで手を止めるかを先に決めておかないと、時間だけ溶けます。

プラグインの除外設定は、設定画面を信じきらないこと。除外にチェックを入れたのに出力には残っている、という状況は、キャッシュ系プラグインとの組み合わせやサーバー側のキャッシュで実際に起こります。

設定を変えたら、必ず実際のサイトマップURLを開いて、ブラウザの検索機能で該当URLが消えているかを確認してください。設定画面のチェックは「意図」であって「結果」ではありません。

タグアーカイブの精査は、ほどほどでよいこと。タグが200個ある古いブログで、1つずつ「載せる・載せない」を判断していると半日かかります。実務では、記事数が少ないタグをまとめて除外し、残ったものだけ目視する、という割り切りをします。何本を境目にするかは、そのサイトのタグの付き方を見て自分で決めてください。完璧に分類することより、明らかに中身の薄いURLを大量に落とすことのほうが効きます。

制作会社に頼むときは、更新の責任者を決めること。サイトマップは制作の納品物に含まれることが多い一方、公開後の更新責任が誰にあるかは曖昧なままになりがちです。「公開時に1回作って送信した」で止まっているサイトを何度も見ています。見積もりや契約の段階で、ページを追加したときサイトマップが自動更新される仕組みになっているのか、それとも手動なのか、手動なら誰がやるのかまで確認してください。この一問を聞けるかどうかで、公開後1年の状態が変わります。

生成AIにXMLの書式を整えてもらうのは有効です。ただし、載せるURLの一覧そのものは必ず自社サイトから書き出したものを渡してください。AIは足りないURLを推測で補うことがあり、実在しないURLが混ざります。AIに任せていいのは書式の作業で、URLの中身は人が用意します。

この章の結論。手を止めていい場所は「タグの完全分類」で、止めてはいけない場所は「出力の実物確認」と「更新の担当決め」です。この線引きを決めておけば、サイトマップの運用は月に数分で回ります。

サイトマップについてよくある質問

今日の1分でできることと、次に読むページ

まずブラウザで自社ドメインの後ろに /sitemap.xml と /wp-sitemap.xml を入力して、どちらが開くかだけ確認してください。両方開いたら、そこが最初の直しどころです。

開いたサイトマップの中に見覚えのないURLが混ざっていた場合や、送信済みなのに登録されていないURLが多い場合は、URL検査でインデックス登録をリクエストする手順を続けて読むと、1ページ単位での確認と再申請まで進められます。

ここまで読んで、「自社のサイトマップを開いてみたけれど、どのURLを外すべきか判断が付かない」と感じた方もいると思います。プラグインの設定と実際の出力が食い違っている場合は、原因の特定に時間がかかりがちです。サイトマップ運用まで見るSEO内部対策の支援では、直す順番を毎月決めて実装まで進め、判断の理由と手順を文書に残すので、社内で引き継げる形になります。いまの状況をうかがうだけでも大丈夫なので、気軽にお声がけください。