WordPress のサイトマップが生成されない、Search Console に送信できない、あるいは古い URL が残っている場合、単なるプラグイン不具合ではなく、パーマリンク設定や URL 設計の問題が表面化していることがあります。
パーマリンク変更の記事では URL 移行の手順を扱いました。この記事では、サイトマップを URL 設計の健康診断として見て、WordPress が公開すべき URL を正しく出せているかを確認します。
サイトマップで見るもの
サイトマップは、検索エンジンに URL を知らせるための XML ですが、それだけではありません。サイト内で正規の URL として扱いたいものが何かを確認する一覧でもあります。
| 見る項目 | 確認すること |
|---|---|
| 投稿 URL | 公開済み記事が現在のパーマリンクで出ているか |
| 固定ページ URL | 不要なページや古い URL が混ざっていないか |
| カテゴリ URL | カテゴリ slug と URL 設計が意図通りか |
| タグ URL | インデックスさせたいタグだけが出ているか |
| 旧 URL | 移行前の URL が残っていないか |
WordPress 標準サイトマップとプラグインサイトマップ
WordPress には標準のサイトマップ機能があります。一方で、SEO プラグインやサイトマップ生成プラグインも独自のサイトマップを出すことがあります。まず、どのサイトマップを Search Console に送るのかを決めます。
| 種類 | 代表的な URL | 特徴 |
|---|---|---|
| WordPress 標準 | /wp-sitemap.xml | WordPress 本体が生成する標準サイトマップ |
| SEO プラグイン | /sitemap_index.xml など | 投稿種別や noindex 設定と連動しやすい |
| 独自生成 | 環境により異なる | キャッシュや生成タイミングに注意が必要 |
複数のサイトマップが存在している場合、Search Console に送っている URL と、実際に最新状態を反映しているサイトマップがずれていないかを確認します。
まずサイトマップ URL を確認する
最初に、サイトマップが HTTP として正常に取得できるかを確認します。ブラウザで見えるかだけでなく、ステータスコードと Content-Type も見ます。
コマンド
curl -I https://www.example.com/wp-sitemap.xml
curl -I https://www.example.com/sitemap_index.xml
curl -s https://www.example.com/wp-sitemap.xml | head404、403、500 が返る場合は、サイトマップ生成以前に、rewrite、WAF、キャッシュ、プラグイン、Web サーバー設定を確認します。HTML のエラーページが返っている場合も、Search Console から見るとサイトマップとしては不正です。
パーマリンク設定との関係
サイトマップに出る URL は、WordPress のパーマリンク設定に従います。パーマリンクを変更したのにサイトマップが古い URL を出している場合、キャッシュ、プラグイン、サイトマップ生成元の不整合を疑います。
カテゴリを URL に含める構成では、投稿に複数カテゴリが付いていると URL が不安定になることがあります。サイトマップには、その時点で WordPress が正規 URL と判断した URL が出ます。
- 投稿 URL が現在のパーマリンク構造になっているか
- カテゴリ slug が意図したものになっているか
- 複数カテゴリの投稿で URL が揺れていないか
- タグやカテゴリのアーカイブをインデックスさせる方針か
Search Console に送る URL を確認する
Search Console に送るサイトマップ URL は、実際に公開されている正規のサイトマップにします。WordPress 標準サイトマップを使うのか、SEO プラグインのサイトマップを使うのかを混ぜない方が分かりやすいです。
| 確認点 | 理由 |
|---|---|
| 送信している sitemap URL | 古いサイトマップを送っていないか確認する |
| 最終読み込み日時 | Search Console が最新状態を見ているか確認する |
| 検出 URL 数 | 投稿数や公開ページ数と大きくずれていないか見る |
| エラー URL | 404、リダイレクト、noindex の混入を確認する |
旧 URL が残っていないか確認する
パーマリンク変更後は、旧 URL がサイトマップに残っていないかを確認します。旧 URL は 301 リダイレクトで受けるべきですが、サイトマップには新 URL だけを載せるのが基本です。
コマンド
curl -s https://www.example.com/wp-sitemap-posts-post-1.xml | grep old-category
curl -s https://www.example.com/wp-sitemap-posts-post-1.xml | grep new-category旧カテゴリ slug、古い URL パターン、変更前のディレクトリ名などで検索すると、移行漏れを見つけやすくなります。
キャッシュとプラグインを確認する
サイトマップが更新されない場合、WordPress 本体ではなくキャッシュやプラグインが原因のことがあります。ページキャッシュ、オブジェクトキャッシュ、CDN、SEO プラグインのキャッシュを分けて確認します。
- WordPress 標準サイトマップかプラグインサイトマップか
- ページキャッシュが古い XML を返していないか
- CDN がサイトマップ XML をキャッシュしていないか
- SEO プラグイン側で投稿タイプやカテゴリが除外されていないか
- noindex 設定とサイトマップ出力が矛盾していないか
URL 設計の健康診断として見る
サイトマップを見ると、URL 設計の癖が見えます。カテゴリ URL が長すぎる、タグが増えすぎている、古い分類が残っている、slug の表記ゆれがある、といった問題はサイトマップ上にも現れます。
| 状態 | 見直すこと |
|---|---|
| カテゴリ URL が多すぎる | カテゴリを記事分類として整理する |
| タグ URL が大量にある | タグをインデックス対象にするか考える |
| 旧 URL が混ざる | リダイレクトとキャッシュを確認する |
| 投稿 URL が不安定 | 複数カテゴリ運用を見直す |
| サイトマップ URL が複数ある | Search Console に送る正本を決める |
パーマリンク変更後に見ること
パーマリンク変更後は、サイトマップ、Search Console、404 ログをセットで確認します。リダイレクトがあるから大丈夫、ではなく、新 URL がサイトマップに出て、旧 URL は 301 で受け、404 が増えていない状態を確認します。
- 新 URL がサイトマップに出ているか
- 旧 URL がサイトマップから消えているか
- 旧 URL が 301 で新 URL に向くか
- Search Console の 404 が増えていないか
- 内部リンクが旧 URL のまま残っていないか
参考書籍
書籍
WordPress の管理画面、テーマ、プラグイン、運用まわりを体系的に確認したい場合の参考書籍です。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連する記事
旧 URL を守りながらパーマリンクを変更するための URL 移行手順です。
URL 変更後のアクセス状況や流入変化を確認するためのアクセス解析記事です。
REST API、WAF、PHP、パーマリンクの問題を切り分ける記事です。
まとめ
WordPress のサイトマップが生成されない、または意図しない URL が出ている場合は、サイトマップ単体ではなく、パーマリンク設定、カテゴリ slug、投稿 slug、キャッシュ、SEO プラグイン、Search Console まで含めて確認します。
パーマリンク変更記事が URL 移行の手順だとすれば、この記事は移行後に正しい URL が検索エンジンへ提示されているかを見るための記事です。
サイトマップは SEO 用の XML であると同時に、サイトの URL 設計が整っているかを確認する一覧でもあります。大量記事サイトほど、サイトマップを定期的に見て URL の揺れや旧 URL の残りを確認する価値があります。
関連記事
WordPress のパーマリンク変更手順 – 旧 URL を守るリダイレクト設計
WordPress で GA4 を使う理由 – アクセス解析を記事改善に活かす
WordPress が wordpress.org に接続できない時の切り分け – DNS / Proxy / Firewall / Kubernetes を確認する
WordPress の JSON レスポンスエラーを切り分ける – REST API / WAF / PHP / パーマリンクを見る
コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける
WordPress のメール送信が遅い原因 – sendmail / Postfix / DNS の待ち時間を切り分ける
WordPress 更新後に ModSecurity が反応する理由 – WAF の偽陽性と例外設計を見る
WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える