サイトマップとは？読者用と検索エンジン用の違いを初心者向けに解説

「サイトマップを作ったほうがよい」と聞いて調べると、見た目が異なる二つのサイトマップが出てきます。一つは読者がページを探すための一覧ページ、もう一つは検索エンジンがURLを見つけるためのXMLサイトマップです。名前は同じでも、届ける相手と役割は異なります。

WordPressでは、テーマやプラグインによって読者用サイトマップを作れる一方、検索エンジン用のXMLサイトマップはWordPress本体にも生成機能があります。そのため、目的を区別しないまま機能を追加すると、似たXMLサイトマップが複数できたり、必要のないページまで一覧に含めたりしがちです。

この記事では、読者用サイトマップと検索エンジン用サイトマップの違い、WordPressでの確認方法、掲載するページの考え方、Search Consoleへ送信する前の注意点を初心者向けに整理します。設定手順だけでなく「自分のサイトには何が必要か」を判断できることを目標にします。

サイトマップとはサイト内の情報を整理して伝える仕組み

サイトマップは、Webサイトにどのようなページがあるかを整理して伝えるためのものです。ただし、すべてのサイトマップが同じ形式で同じ相手に使われるわけではありません。

読者用サイトマップは、一般的なWebページとして表示されます。訪問者がカテゴリーやページ名を見ながら目的の情報を探すための案内図です。検索エンジン用サイトマップは、多くの場合XMLという機械が読み取りやすい形式で作られ、検索エンジンにURLの存在を知らせるために使われます。

両方に共通するのは、サイト内の情報を整理することです。しかし、読者用は「人が迷わず移動できること」、検索エンジン用は「検索エンジンが重要なURLを発見しやすいこと」を主な目的とします。この違いを最初に押さえると、必要な機能や確認項目を選びやすくなります。

読者用と検索エンジン用の違い

読者用サイトマップは人が読む案内ページ

読者用サイトマップは、投稿、固定ページ、カテゴリーなどへのリンクを見やすく並べたページです。「サイト内の記事一覧」「コンテンツ一覧」といった名前で公開される場合もあります。通常のメニューだけでは目的のページを見つけにくいときに、全体像を確認できる補助的な入口になります。

たとえば、記事数が多いブログなら、カテゴリー別に主要記事を並べると読者が関心のあるテーマへ移動しやすくなります。企業サイトなら、サービス、会社情報、よくある質問、コラムなどを大きなまとまりに分ける方法があります。単に全URLを長く並べるのではなく、人が内容を理解できる名前と順序で整理することが重要です。

XMLサイトマップは検索エンジンが読むURL一覧

検索エンジン用サイトマップは、一般にXMLサイトマップと呼ばれます。検索エンジンに、サイト内に存在するURLや更新情報などを伝えるファイルです。ブラウザーで開くと文字やURLが並び、通常の記事ページとは違って見えることがあります。

Googleは、サイトマップを検索エンジンがサイトを効率よくクロールするために読むファイルと説明しています。特に新しいサイト、ページ数が多いサイト、外部リンクが少ないサイト、画像や動画が多いサイトでは、URLの発見を助ける手段になります。一方で、サイトマップへ載せたURLが必ずクロール、インデックス、上位表示されるわけではありません。

二つは置き換えられない

読者用サイトマップにリンクがあるからXMLサイトマップは不要、またはXMLサイトマップがあるから読者用サイトマップは不要、と単純には判断できません。相手と目的が異なるからです。

読者の移動は、グローバルメニュー、パンくずリスト、カテゴリー、関連記事、本文中の内部リンクなどでも支えられます。小規模で導線が明快なサイトなら、読者用サイトマップを設けなくても困らない場合があります。XMLサイトマップも、重要ページが適切なリンクで結ばれていれば検索エンジンは多くのページを発見できますが、WordPressで自動生成されているなら内容を確認して活用する価値があります。

違いを比較すると判断しやすい

違いを理解すると、「サイトマップを作る」という言葉だけで作業を始めずに済みます。読者が迷っているならナビゲーション全体を見直し、検索エンジンに新しいURLが伝わっているか確認したいならXMLサイトマップを確認します。問題に合わせて選ぶことが大切です。

WordPressのXMLサイトマップの基本

WordPress本体にも生成機能がある

WordPressにはバージョン5.5からXMLサイトマップの機能が組み込まれています。標準的な環境では、サイトURLの末尾に /wp-sitemap.xml を付けた場所にサイトマップインデックスが生成されます。インデックスから、投稿タイプ別や分類別のサイトマップへ分かれる構造です。

ただし、SEOプラグインが独自のXMLサイトマップを出力している場合や、管理者・開発者が機能を変更している場合はURLや内容が異なります。まず実際のサイトで開けるURLを確認し、WordPress本体とプラグインのどちらが生成しているかを把握してください。

サイトマップインデックスは複数ファイルの入口

XMLサイトマップを開くと、投稿用、固定ページ用、カテゴリー用など複数のURLが並ぶ場合があります。これは異常ではありません。サイトマップインデックスが、用途別に分割されたサイトマップをまとめる入口になっているためです。

Googleの仕様では、一つのサイトマップは非圧縮で50MBまたは50,000URLまでという上限があります。小さなWordPressサイトでは上限を意識する場面は多くありませんが、サイトマップを分割し、インデックスから案内する構造は一般的です。

SEOプラグインを使うときは出力元を一つにする

SEOプラグインには、XMLサイトマップの生成、除外設定、Search Console向けの案内などを備えるものがあります。便利ですが、複数のSEOプラグインを同時に使ったり、WordPress本体のサイトマップとプラグインのサイトマップを理解せず併用したりすると、管理するURLが分かりにくくなります。

同じURLが複数のサイトマップに含まれること自体だけで直ちに問題になるとは限りません。ただし、どれが正式な送信対象か分からない状態は、更新や不具合の確認を難しくします。現在使っているテーマとプラグインの仕様を確認し、管理するサイトマップを一つの系統に整理しましょう。

読者用サイトマップが役立つサイト

記事やカテゴリーが多く全体像を見せたい

記事が増えると、メニューにすべてのページを並べることはできません。カテゴリーの数も多いと、初めて訪れた人はどこから読めばよいか迷います。読者用サイトマップでテーマ別に代表記事を整理すると、サイト全体の案内役になります。

ただし、自動生成された全投稿一覧が必ず読みやすいとは限りません。公開日の順に何百件も並べるだけでは、目的のページを探す負担が増えます。カテゴリーの粒度をそろえ、優先したいページを上に配置し、必要なら短い説明を添えるほうが役立ちます。

メニューに載せにくい補助ページがある

フッターメニューには、運営者情報、プライバシーポリシー、利用規約などを置くことが多いでしょう。読者用サイトマップは、それ以外の案内ページや特集ページも含めて整理できます。ただし、ログイン画面、確認画面、管理用ページなど、一般の読者に見せる必要がないページまで載せないようにします。

読者用サイトマップだけに頼らない

読者用サイトマップは補助的な導線です。主要なサービスや重要記事へ移動するために、毎回サイトマップを経由しなければならない構造は使いやすいとはいえません。ヘッダーのメニュー、記事内リンク、関連記事、パンくずリストなども合わせて整えます。

アクセス解析や問い合わせ内容から「どこにあるか分からない」と言われるページがあれば、サイトマップに追加するだけでなく、関連するページから自然にリンクできないか検討します。読者が必要になる場面にリンクを置くことが、案内ページを増やすより有効な場合があります。

XMLサイトマップが特に役立つケース

公開したばかりで外部からのリンクが少ない

新しいサイトは、検索エンジンがURLを見つける手掛かりがまだ少ない状態です。XMLサイトマップを用意し、重要ページが内部リンクでもたどれるようにすると、URLの発見を助けられます。ただし、送信した直後に検索結果へ出ることを保証するものではありません。

ページ数が多い、または更新が頻繁

ページ数が増えるほど、すべての重要URLが適切にリンクされているかを管理するのは難しくなります。XMLサイトマップはサイト側が重要と考えるURLをまとめて伝える補助手段になります。商品、動画、ニュースなど特定形式のコンテンツが多い場合も、対応するサイトマップが役立つことがあります。

孤立しやすいページがある

ほかのページからリンクされていない「孤立ページ」は、読者にも検索エンジンにも見つけにくいページです。XMLサイトマップに含めれば発見の手掛かりにはなりますが、孤立したままでよいという意味ではありません。重要なページなら、関連する記事やカテゴリーからリンクし、読者が自然に到達できるようにします。

XMLサイトマップに含めるURLの考え方

検索結果に出したい正規URLを中心にする

Googleは、検索結果に表示したいURLをサイトマップへ含めるよう案内しています。同じ内容へ複数のURLからアクセスできる場合は、正規URLとして扱いたいものを選びます。httpとhttps、wwwの有無、末尾の違いなどで重複URLが混ざっていないかも確認します。

非公開ページや管理用ページを載せない

下書き、パスワード保護ページ、会員だけが見るページ、注文完了ページ、サイト内検索結果などは、一般の検索結果へ出す目的がないことが多いページです。XMLサイトマップに含める対象は、公開状態だけでなく検索結果へ出したいかという視点で判断します。

なお、サイトマップから除外するだけではインデックス拒否にはなりません。すでに別のリンクから発見されているURLは、サイトマップに載っていなくてもクロールされる可能性があります。検索結果へ出したくないページは、ページの性質に応じてnoindex、アクセス制限、削除など別の方法を検討します。

エラーや転送先ではなく最終的な公開URLを載せる

404エラーになるURLや、別URLへリダイレクトされる古いURLをサイトマップに残すと、確認時のノイズになります。サイト移転やスラッグ変更の後は、XMLサイトマップが新しいURLへ更新されているかを確認します。サイトマップ生成機能が自動で追従しても、キャッシュが残っている可能性があるため実際の出力を見ることが大切です。

WordPressで最初に確認する順番

現在のXMLサイトマップURLを開く

まず https://あなたのドメイン/wp-sitemap.xml を開きます。表示されなければ、利用中のSEOプラグインの設定画面や公式ドキュメントでサイトマップURLを確認します。よく似たURLを推測してSearch Consoleへ登録するのではなく、ブラウザーで正常に開けることを確かめます。

含まれる種類を確認する

サイトマップインデックスから各ファイルを開き、投稿、固定ページ、カテゴリー、著者など何が含まれているかを見ます。すべてを細かく読む必要はありません。公開した主要ページが含まれるか、検索結果へ出す必要のない種類が大量に含まれていないかを確認します。

主要URLの状態を確認する

トップページ、代表的な記事、重要な固定ページをいくつか選び、正しいhttpsのURLになっているか、開いたときにエラーにならないかを確認します。サイトマップの見た目を整えることより、記載されたURLが正常に応答し、意図したページを示すことが重要です。

生成元を把握する

WordPress本体、SEOプラグイン、専用サイトマッププラグインのどれが出力しているかを確認します。プラグインを停止したときにURLが変わる場合もあるため、運用担当者が分かるように記録しておくと、更新後の不具合を調べやすくなります。

Search Consoleへ送信する前に知っておきたいこと

送信するのは通常XMLサイトマップ

Google Search Consoleのサイトマップ機能へ送信するのは、通常、検索エンジン用のXMLサイトマップまたはサイトマップインデックスです。読者用のHTMLページを送る操作ではありません。サイトマップインデックスがある場合は、その入口URLを送信すれば配下のサイトマップをまとめて扱えます。

送信はインデックス登録の保証ではない

Search Consoleで「成功しました」と表示されても、含まれるすべてのURLが検索結果に掲載されるわけではありません。サイトマップはURL発見の手掛かりであり、インデックス登録には、ページが取得できること、重複やnoindexの問題がないこと、検索する人に役立つ内容があることなども関係します。

同じものを何度も送信しない

記事を公開するたびに同じサイトマップを削除して再送信する必要は通常ありません。自動生成されるサイトマップが更新され、Googleが継続して取得できる状態なら、むやみに登録し直さずエラーの有無を見守ります。Googleも、変更のない同じサイトマップを一日に何度も送ることを避けるよう案内しています。

よくある勘違い

サイトマップを作れば順位が上がる

XMLサイトマップはクロールやURL発見を助けますが、内容の品質や検索意図への適合を置き換えるものではありません。読者用サイトマップも、分かりやすい導線づくりには役立つものの、それだけで検索順位が上がると断定できません。重要なのは、価値のあるページを作り、適切なリンク構造でつなぎ、検索エンジンが取得できる状態にすることです。

サイトマップに載せれば孤立ページの問題は解決する

XMLサイトマップにURLがあれば検索エンジンが発見する可能性は高まります。しかし、読者がサイト内から到達できない状態は残ります。重要ページが孤立しているなら、関連ページやカテゴリーからの内部リンクも追加します。

二つのサイトマップは内容を完全に一致させるべき

読者用とXML用では目的が異なるため、一覧が完全に同じである必要はありません。読者用には、利用者が探しそうなカテゴリーや案内ページを分かりやすく載せます。XML用には、検索結果へ出したい正規URLを中心に載せます。たとえば、読者向けに便利な絞り込みページでも、検索結果へ出す必要がなければXMLサイトマップへ含めない判断があります。

プラグインを追加すれば確認は不要

プラグインが自動生成していても、設定、他プラグインとの競合、キャッシュ、公開状態の変更などで期待と異なる出力になる可能性があります。導入直後と大きな更新後には、サイトマップURLを実際に開き、主要ページを確認してください。

サイト構造を整えるときの実践的な考え方

読者が探す単位で分類する

読者用サイトマップを作るなら、運営者の都合ではなく読者の目的に合わせて分類します。「WordPressを始めたい」「記事を書きたい」「画像の問題を直したい」のように、悩みや作業のまとまりで整理すると選びやすくなります。カテゴリー名だけでは意味が伝わりにくい場合は、一文の説明を添えます。

重要なページほど少ない移動で到達できるようにする

サイトマップは深い階層のページを見つける助けになりますが、重要ページを深い場所へ置く理由にはなりません。トップページ、メニュー、関連記事などから、重要度に応じた短い経路で到達できる構造を目指します。

定期的に不要なURLを見直す

サイトを長く運営すると、削除した記事、統合したカテゴリー、使わなくなったタグなどが増えます。読者用サイトマップのリンク切れを確認し、XMLサイトマップでは不要な種類が出力されていないかを見直します。記事公開のたびに手作業で点検する必要はありませんが、テーマやSEOプラグインを変更したとき、サイトを移転したとき、URL構造を変えたときは優先して確認します。

初心者向け確認チェック

• 読者用と検索エンジン用の目的を区別できている
• 現在使われているXMLサイトマップのURLを把握している
• WordPress本体またはプラグインのどちらが生成しているか分かる
• 主要な投稿と固定ページが正しいURLで含まれている
• 404、転送前URL、非公開ページなどが不用意に含まれていない
• 重要ページがサイト内リンクからもたどれる
• 読者用サイトマップは人が探しやすい順序と名称になっている
• Search ConsoleにはXMLサイトマップまたはインデックスを送信している
• 送信成功とインデックス登録を同じ意味だと考えていない
• テーマ、プラグイン、URL構造の変更後に再確認している

表示や送信で困ったときの切り分け方

サイトマップURLが404になる

最初にURLの入力間違いを確認し、WordPress本体の標準URLと、利用中のSEOプラグインが案内するURLを区別します。次に、管理画面の「設定」にあるパーマリンク設定を開き、現在の設定を把握します。設定を変更する必要がない場合でも、運用環境によっては保存によってURLの書き換えルールが更新されることがあります。ただし、公開サイトの設定変更には影響が伴うため、保守担当者がいる場合は先に相談してください。

セキュリティ機能、キャッシュ、サーバー側の転送設定がサイトマップへのアクセスを妨げる場合もあります。いきなり複数のプラグインを停止すると原因が分からなくなるため、直前に行った変更、発生時刻、表示された状態を記録し、一つずつ確認します。

Search Consoleで取得できないと表示される

ブラウザーでサイトマップが開けても、検索エンジンから取得できるとは限りません。ログインを要求していないか、アクセス制限やWAFがGooglebotまで遮断していないか、サーバーが一時的なエラーを返していないかを確認します。URLがhttpからhttpsへ転送される場合や、ドメインを変更した場合は、Search Consoleで選択しているプロパティと送信URLの組み合わせも見直します。

一時的な取得失敗なら、原因を直した後に状態が更新されるまで待つ必要があります。短時間に何度も削除と再送信を繰り返すより、URLを直接開いた結果とサーバーの応答を確認し、修正内容を一つずつ検証するほうが確実です。

送信URL数とインデックス数が一致しない

この二つが一致しないだけで異常とは判断できません。サイトマップに含まれるのは候補URLであり、Googleは重複、リダイレクト、noindex、クロール状況、ページ内容などを踏まえてインデックス登録を判断します。Search Consoleのページインデックス登録レポートやURL検査で、代表的な除外理由を確認します。

対処するときは、数だけを増やすのではなく、検索結果へ出したいページを優先します。統合すべき重複記事、内容がほとんどないページ、意図せず生成されたタグ一覧などがあれば、サイト全体の方針に沿って整理します。重要記事が除外されている場合は、正規URL、noindex、内部リンク、取得エラーの順に確認すると原因を切り分けやすくなります。

更新日が期待どおりに変わらない

XMLサイトマップに更新日が記載されるか、どの変更を更新として扱うかは生成機能によって異なります。見た目だけを変更したのに更新日を頻繁に書き換えたり、実際に本文を大きく更新したのに古い情報のままになったりすると、運用状況を把握しにくくなります。利用中の生成機能の仕様を確認し、更新日を手作業で偽らないようにします。

運用担当者が残しておくとよい記録

サイトマップは一度設定すると普段は意識しにくい機能です。そのため、担当者が変わったときやプラグインを入れ替えたときに、どれが正式なサイトマップか分からなくなることがあります。次の情報を運用メモに残しておくと、確認が速くなります。

• Search Consoleへ送信しているサイトマップの完全なURL
• WordPress本体またはプラグインなどの生成元
• 投稿、固定ページ、カテゴリーなどの掲載対象
• 意図的に除外している投稿タイプや分類
• 最後に正常表示と主要URLを確認した日
• テーマ、SEOプラグイン、ドメインを変更した履歴

記録には認証情報や管理画面のパスワードを書かず、設定の目的と確認結果を中心に残します。何のために除外したかが分かれば、将来の担当者が安易に設定を戻すことも防げます。

サイトマップに関するよくある質問

小さなブログにもXMLサイトマップは必要ですか

適切な内部リンクがあり、ページ数が少ないサイトでは、検索エンジンが主要ページを発見できる場合があります。ただしWordPressが自動生成しているなら、正常に開けて重要URLが含まれていることを確認して活用するとよいでしょう。サイトマップだけに頼らず、カテゴリーや関連記事からもページをつなぎます。

読者用サイトマップは必ず作るべきですか

必須ではありません。メニューやカテゴリーが分かりやすく、目的のページへ迷わず到達できる小規模サイトでは、優先度が低いこともあります。記事数が増え、通常のナビゲーションだけでは全体像を伝えにくくなったときに検討します。

XMLサイトマップをブラウザーで開くと装飾がありません

XMLは検索エンジンなどの機械が読み取るための形式なので、通常のWebページのようなデザインがなくても問題とは限りません。重要なのは、ファイルが正常に取得でき、正しいURL情報が含まれていることです。プラグインによっては、人にも見やすい表示を加える場合があります。

サイトマップのURLが複数見つかりました

WordPress本体とSEOプラグインがそれぞれ生成している可能性があります。利用中のプラグイン設定と公式説明を確認し、どのサイトマップをSearch Consoleへ送るかを決めます。判断できない場合は、むやみに機能を停止せず、制作会社や保守担当者に現在の生成元と送信先を確認してください。

公開した記事がサイトマップに出てきません

記事の公開状態、noindex設定、投稿タイプの除外設定、キャッシュを確認します。SEOプラグインを使っている場合は、コンテンツ種類ごとのサイトマップ設定も見ます。問題を切り分けるため、対象記事のURLが直接開けるか、サイト内からリンクされているかも確認してください。

まとめ

サイトマップには、主に読者がページを探すためのHTML形式の一覧と、検索エンジンがURLを見つけるためのXML形式のファイルがあります。名前は似ていますが、相手と目的が異なるため、同じ設定で代用するものではありません。

WordPressではXMLサイトマップが標準機能やSEOプラグインで自動生成されることが多いため、まず現在のURLと生成元を確認しましょう。検索結果へ出したい正規URLが含まれ、エラーや不要なページが混ざっていないことが大切です。Search Consoleへの送信はURL発見を助けますが、インデックス登録や順位を保証しません。

読者用サイトマップは、記事数が増えて全体像を伝えにくくなったときに役立ちます。ただし、主要メニューや内部リンクの代わりではありません。読者が迷わない導線と、検索エンジンが取得しやすい構造をそれぞれ整え、二つのサイトマップを目的に合わせて使い分けてください。

参考にした公式情報

• Google Search Central「サイトマップについて」
• Google Search Central「サイトマップを作成して送信する」
• Developer.WordPress.org「WP_Sitemaps」
• Make WordPress Core「Extensible Core Sitemaps」