WordPressのXMLサイトマップとは、サイト内のURLを一覧にして検索エンジンのクローラーに伝えるXML形式のファイルです。WordPress 5.5以降は標準で「wp-sitemap.xml」が自動出力されるため、特別な作業をしなくてもサイトマップは存在します。やるべきことは「作る」ことよりも、正しく出力されているか確認し、Search Consoleに登録して状態を監視することです。
XMLサイトマップの役割と標準機能の中身
XMLサイトマップの役割は、クローラーに「このサイトにはどんなURLがあるか」を一覧で渡すことです。リンクを辿るだけでは発見が遅れるページを、確実に認識させるための補助手段と考えると分かりやすくなります。
WordPress標準の出力は、ドメイン直下の「/wp-sitemap.xml」にアクセスすれば確認できます。中身はインデックス形式で、以下のような個別サイトマップに分かれています。
- wp-sitemap-posts-post-1.xml（投稿）
- wp-sitemap-posts-page-1.xml（固定ページ）
- wp-sitemap-taxonomies-category-1.xml（カテゴリー）
- wp-sitemap-users-1.xml（投稿者アーカイブ）
標準機能は手軽ですが、更新日時（lastmod）や優先度の出力、不要なアーカイブの除外といった細かな制御ができません。投稿者アーカイブやタグページまで一律に載ってしまい、評価を分散させたくないURLまで申告してしまうケースがあります。
プラグインを使うべきケース
次のどれかに当てはまるなら、サイトマップ系プラグインやSEOプラグインの利用を検討します。
- タグ・投稿者アーカイブなど特定のURL群を除外したい
- 更新日時を正確に伝え、リライトした記事を早く再クロールさせたい
- 画像サイトマップやニュースサイトマップが必要
- カスタム投稿タイプの出力範囲を細かく決めたい
どのプラグインを選ぶべきか迷う場合は、サイトマップ自動生成プラグインの比較も合わせて確認すると判断しやすくなります。
作成からSearch Console登録までの手順
手順は「出力確認 → 登録 → 状態確認」の3ステップで完了します。所要時間は10分程度です。
- 出力の確認：ブラウザで「https://自サイトのドメイン/wp-sitemap.xml」を開き、URL一覧が表示されるか確認します。プラグインを使う場合は「/sitemap.xml」や「/sitemap_index.xml」になることが多いです。
- Search Consoleへ送信：左メニューの「サイトマップ」を開き、ドメイン以降のパス（例：wp-sitemap.xml）を入力して送信します。
- ステータスの確認：数分〜数日で「成功しました」と検出URL数が表示されます。ここまで確認して初めて登録完了です。
標準機能とプラグインの違いは次の通りです。
| 観点 | 標準（wp-sitemap.xml） | プラグイン |
|---|---|---|
| 導入の手間 | 不要（自動出力） | インストールと設定が必要 |
| 除外設定 | コード編集が必要 | 画面から選択可能 |
| 更新日時の制御 | ほぼ不可 | 対応するものが多い |
| 向くサイト | 小〜中規模の情報発信 | 記事数が多い・運用型 |
よくある失敗と回避のチェックリスト
サイトマップのトラブルは、ほとんどが「取得できない」「URLが載らない」の2種類です。原因は限られているため、次の順で切り分ければ早く解決できます。
- 「取得できませんでした」と出る：送信パスの打ち間違い、キャッシュプラグインが古いファイルを返している、リダイレクト設定でXMLがブロックされている、のいずれかが典型です。ブラウザで直接URLを開いて表示されるなら、キャッシュ削除後に再送信します。
- 新しい記事が載らない：noindex設定、下書き・非公開状態、カスタム投稿タイプの除外設定を確認します。
- サイトマップが2つある：標準とプラグインが両方出力していると管理が混乱します。使う側に一本化し、不要な方は停止します。
- サイトマップ送信＝インデックスではない：あくまで発見の補助です。内容の薄いページは送信しても登録されません。
なお、プラグインの追加や更新のタイミングで出力が変わることもあるため、更新作業の前後に確認する項目のひとつとしてサイトマップのURLを開く習慣をつけておくと安心です。
AI検索時代のサイトマップ運用
これからのサイトマップは「新規記事を知らせる仕組み」から「更新を知らせる仕組み」へ比重が移ります。検索エンジンもAI検索エンジンも、情報の鮮度と構造を重視するためです。
特に重要なのが更新日時（lastmod）です。既存記事をリライトしても更新日が変わらない運用だと、せっかくの改善が再クロールにつながりません。記事を書き換えたら更新日を正しく反映させ、サイトマップ経由で変更を伝える流れを作ることが、地味ですが効果の大きい施策です。
運用上のチェックポイントは次の3つです。
- 月に一度、Search Consoleでサイトマップの検出URL数と最終読み取り日を確認する
- リライト時に更新日を反映させる（固定したままにしない）
- 重複・低品質なアーカイブURLをサイトマップから外す
例えば記事数が100本を超えるオウンドメディアの場合、新規公開より既存記事の改善のほうが成果に直結することが多く、その改善をクローラーに伝える経路としてサイトマップが機能します。あわせて、内部リンクの整備を進めると、サイトマップに頼らない自然なクロール経路も確保できます。
AP Writer Proは、自社サイトのURLを学習して「うちの話」として記事を自動生成するWordPressプラグインです。毎朝の下書き自動生成に加え、公開済み記事をSearch Consoleのデータと連携して定期的に書き直すリフレッシュ機能を備えているため、本記事で触れた「更新をクローラーに伝える運用」と相性よく使えます。目次の自動生成や構造化データ出力、AI検索からの流入計測といったLLMO対策機能も無料で利用できます。
This article was drafted with AI assistance and reviewed and edited by APWP before publication.
