WordPress 7.1で標準サイトマップが404になる原因と解消手順
WordPress 7.1 に更新した後、プラグインなしのサイトで標準 XML サイトマップが 404 になる場合は、パーマリンク設定の再保存でリライトルールを再生成する。同じ環境で 7.0.4 では正常だった場合は WordPress 7.1 本体のリグレッションの可能性が高いため、急ぎなら 7.0.4 へ戻すのが確実だ。
WordPress 7.1 で標準サイトマップが 404 になる原因
標準 XML サイトマップは WordPress 5.5 から搭載された機能だ。パーマリンク設定に基づき wp-sitemap.xml という URL でインデックスを出力し、wp-sitemap-posts-page-1.xml のように投稿タイプ別・ページ番号別の子サイトマップを生成する。検索エンジンがサイトを巡回する入り口の役割を持つ。
WordPress 7.0.4 から 7.1 へ更新した直後から wp-sitemap.xml と wp-sitemap-posts-page-1.xml の両方が 404 を返す場合は、プラグインの競合やテーマの影響を疑う前に、WordPress 本体のリライト処理と更新後のルール再生成状況を確認する。特に Nginx を Apache の前段に置くリバースプロキシ環境では、拡張子 .xml を静的ファイルとして振り分ける設定や、Apache 側の .htaccess にリクエストが届かない構成が原因になることがある。
同じ環境・同じテーマ・プラグインなしで 7.0.4 に戻すと直る場合、WordPress 7.1 の標準サイトマップ機能に起因する不具合の可能性が高い。設定を見直しても直らないときは、コア側の更新によるリグレッションを視野に入れる。
最初に試すパーマリンク再保存とキャッシュ確認
WordPress はバージョン更新後に、パーマリンクのリライトルールが内部にキャッシュされたままになることがある。最初に管理画面の「設定」→「パーマリンク」を開き、内容を変更せずに「変更を保存」を押す。これによって .htaccess やデータベース上のルールが再生成される。
保存後は、ブラウザのシークレットウィンドウか curl で wp-sitemap.xml の HTTP ステータスコードを確認する。キャッシュ系プラグインを入れていなくても、レンタルサーバーや Nginx、CDN がレスポンスをキャッシュしている可能性があるため、まずキャッシュを削除する。
この切り分けで、リライトルールの再生成だけで直るのか、Nginx と Apache の設定まで必要なのかが区別できる。
ここで 200 OK に戻れば、更新によるリライトルールの再生成漏れが原因だったことになる。それでも 404 なら次の転送設定の確認へ進む。
Nginx リバースプロキシと Apache の転送設定を確認する手順
Nginx をリバースプロキシとして Apache の前に置く構成では、location / が proxy_pass で Apache へ向いているかを確認する。もし location ~* \.(xml)$ のような拡張子判定があり、Nginx が XML を静的ファイルとして処理してしまうと、WordPress に到達せず 404 になる。
Apache 側の .htaccess は、# BEGIN WordPress から # END WordPress の間に標準の mod_rewrite.c ブロックがあるかを確認する。独自の RewriteCond や RewriteRule を追記していないこと、RewriteBase / がサイトの設置パスに合っていることが重要だ。
curl で example.com/wp-sitemap.xml と example.com/?sitemap=posts&sitemap-subtype=page&paged=1 をそれぞれ確認する。クエリ形式でも 404 なら、WordPress がサイトマップを出力できていないか、Nginx から Apache への転送が正しくない可能性がある。
WordPress 7.1 から 7.0.4 へ戻す一時対処と注意点
設定変更でも症状が変わらない場合は、バックアップを取得したうえで WordPress 7.0.4 へ戻す。公式パッケージの 7.0.4 でコアファイルを置き換え、管理画面にデータベース更新の案内が出た場合はそれを実行する。
このデモは 7.1 で 404 を返していたサイトマップが、7.0.4 へ戻すと 200 OK に変わることを示している。
ファイルとデータベースのバックアップを取らずにダウングレードすると、予期しない不整合からの復旧が難しくなる。WP Downgrade のようなダウングレード用プラグインを使う場合も、更新前のスナップショットが必須になる。
7.0.4 へ戻すと、同じ URL wp-sitemap.xml が正常に XML を返すようになる。ただし 7.1 の修正版がリリースされたら、そのまま使い続けずに安全なタイミングで更新する。
Google Search Console の再読み込みと標準サイトマップの再送信
サイトマップが正常に戻ったら、Google Search Console の「サイトマップ」で登録済みの wp-sitemap.xml を確認する。「取得できませんでした」と表示されていた場合は再読み込みを行い、ステータスが「成功しました」に変わるのを待つ。
古いレポートが残っている場合は、一度サイトマップを削除してから wp-sitemap.xml を再送信する。フェッチが完了するまで数分かかることがあるため、すぐに結果が出なくても時間を置いて再確認する。
再発防止と WordPress 7.1 の修正状況の追い方
WordPress 7.1 の後続リリースで標準サイトマップの修正が含まれるかは、ダッシュボードの更新通知と WordPress のリリース情報で確認する。本番環境へメジャー更新を適用する前には、ステージング環境で wp-sitemap.xml が 200 OK を返すことを必須のチェック項目にする。
Nginx と Apache を併用している構成では、更新前後の curl の応答コードを記録しておくと、今回のような更新起因のリグレッションを素早く特定できる。SEO プラグインのサイトマップで代替することも一時的には可能だが、パーマリンク全体の不具合を隠す可能性があるため、先に WordPress 本体とサーバー設定の切り分けを行う。
よくある質問
標準サイトマップが404になったらまず何をすればいい？
管理画面の「設定」→「パーマリンク」を開き、内容を変えずに保存してリライトルールを再生成する。これで直らない場合は、Nginx の静的ファイル判定や Apache の .htaccess を確認し、それでも再現するなら WordPress 7.0.4 へ戻して切り分ける。
Nginx リバースプロキシだと何が問題になる？
Nginx が .xml のリクエストを静的ファイルと判断すると、Apache へ渡さずに 404 を返す。Apache の前段で location 設定を見直し、WordPress の index.php までリクエストが届く構成になっているか確認する。
WordPress 7.1 に更新しない方がいい？
通常の単純な LAMP 構成では問題が起きにくいが、標準サイトマップを運用中のサイトで更新直後の 404 が許容できないなら、修正版が出るまで 7.0.4 を使う判断も現実的だ。本番更新前にステージングで確認するのが基本になる。
7.0.4 に戻した後、Google Search Console で何をすればいい？
サイトマップの再読み込みを行い、ステータスが成功に変わるのを確認する。エラーが残っている場合は一度削除して wp-sitemap.xml を再送信し、数分後にもう一度確認する。
SEO プラグインのサイトマップに切り替えてもいい？
切り替え自体は可能だが、WordPress 標準のサイトマップが壊れた原因を残したままだと、他のパーマリンクでも同様の不具合が出る可能性がある。一時的な代替には使えるが、本体側の切り分けを先に行う。
この記事のポイント
- WordPress 7.1 更新後に標準サイトマップが 404 になる場合、最初にパーマリンクを再保存する
- Nginx と Apache の組み合わせでは静的ファイル判定や .htaccess を確認する
- 7.0.4 で同じ環境が正常なら WordPress 本体のリグレッションを疑う
- 急ぐ場合はバックアップを取って 7.0.4 へ戻すのが確実
- 修正版のリリースと Google Search Console のステータスを確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
PixelYourSite が Nginx FastCGI キャッシュを無効化する問題の直し方
PixelYourSite を有効にしたとたん Nginx FastCGI キャッシュがまったく効かなくなり、PHP の負荷が急増して 504 Gateway Timeout が頻発するなら、プラグインの「PHP セッションを無効にする」設定をオンにするだけで解決できる。
この問題は、PixelYourSite が訪問者のトラフィック情報を一時保存するために PHP セッションを開始することで発生する。セッション開始時に送信される Cookie（PHPSESSID）とキャッシュを禁止するヘッダー（Cache-Control: no-store など）が Nginx の FastCGI キャッシュを素通りさせ、毎回バックエンドの PHP が起きてしまうのが根本原因だ。
なぜ PixelYourSite が FastCGI キャッシュを無効化するのか
PixelYourSite には、ランディングページの URL やトラフィックソース、UTM パラメータなどをセッション変数に保持する仕組みがある。この処理は includes/class-pys.php 内の controllSessionStart() メソッドで行われ、まだセッションが始まっていなければ session_start() を呼び出す。サーバー側の PHP 設定で session.cache_limiter が nocache に設定されていると、この瞬間に以下の HTTP レスポンスヘッダーが自動的に追加されてしまう。
Set-Cookie: PHPSESSID=...Cache-Control: no-store, no-cache, must-revalidatePragma: no-cache
Nginx FastCGI キャッシュは、これらのヘッダーがついたレスポンスをキャッシュしない。結果として、匿名の一般訪問者に対しても毎回 PHP が実行され、PHP-FPM ワーカーが占有され続ける。アクセスが集中するとすべてのワーカーがビジーになり、レスポンスを返せず 504 エラーに至る。
✗ Cache-Control: no-store, no-cache, must-revalidate
✗ Pragma: no-cache
✗ X-FastCGI-Cache: MISS
✓ （Set-Cookie やキャッシュ禁止ヘッダーは付かない）
上記の通り、問題の本質はセッションに伴うキャッシュ抑制ヘッダーにある。幸い PixelYourSite には、この PHP セッション機能をまるごとオフにする設定が用意されている。
設定変更で PHP セッションを無効化する手順
PixelYourSite のグローバル設定画面から 1 か所切り替えるだけで、セッションに依存しない動作に切り替えられる。手順はどこのサーバーでも共通だ。
「Disable PHP Sessions」の場所と見つけ方
この設定項目は、PixelYourSite のバージョンによっては「PHP Sessions」というセクションに含まれている。「Global Settings」タブを開き、下にスクロールしていくと「Track UTMs」「Track Traffic Source」といった項目の近くに配置されていることが多い。チェックボックスにチェックを入れると、即座に session_start() が呼ばれなくなる。
設定保存後に必ずキャッシュをクリアする
変更を保存したあとは、WordPress のキャッシュプラグイン（WP Rocket など）と Nginx FastCGI キャッシュの両方を必ずクリアする。さもないと、以前のセッション付きレスポンスがキャッシュされたまま残ってしまう。一般的な手順は次のとおりだ。
- WP Rocket の「キャッシュをクリア」を実行する
- サーバーのシェルから
nginx -s reloadまたはキャッシュディレクトリの削除を行う（環境に応じて） - Cloudflare を利用している場合は、Cloudflare 側のキャッシュもパージする
設定変更後の影響とデータ精度について
PHP セッションを無効にすると、ランディングページ、トラフィックソース、UTM パラメータといった情報の受け渡し方法が、サーバーサイドのセッションからブラウザの Cookie へと切り替わる。プラグインはこれらの値を Cookie に保存し、それを読み取って各ピクセルに渡す形になる。そのため、トラッキング自体は継続して機能する。
精度の面で多少の劣化が生じる可能性はあるものの、PixelYourSite の開発チームは「精度の低下は最小限」としている。実際、セッションに頼らなくても、Cookie を正しく読み取れればデータ取得に大きな支障は出ない。EC サイトで大量のアクセスをさばく場合、キャッシュが効かないことによるサーバーダウンのリスクと比較すれば、この切り替えのデメリットはほとんど無視できるレベルだ。
PHP セッション無効化後も問題が続く場合の追加チェック
設定を変更してもキャッシュが MISS のままだったり、PHP ワーカーの高負荷が解消されない場合は、以下のポイントを順に確認する。
キャッシュ除外設定の見直し
Nginx の設定で、特定の Cookie が存在するとキャッシュをバイパスするルールが書かれていないか確認する。たとえば wp- や wordpress_logged_in といった Cookie は除外対象になるが、PHPSESSID が消えたことで意図しないキャッシュ ON が起きていないかもあわせてチェックする。
他のプラグインがセッションを開始していないか調べる
PixelYourSite だけを無効化したときに問題が消えたとしても、同様にセッションを使う別のプラグインが有効になっていないか切り分ける。WooCommerce のカートなどはログインユーザー向けにセッションを使うが、匿名訪問者にまでセッションを開始するプラグインは稀だ。すべてのプラグインを一時停止し、1 つずつ有効にして原因を特定するとよい。
よくある質問
「Disable PHP Sessions」を有効にしてもトラッキングは引き続き動作するか
動作する。セッションの代わりにブラウザの Cookie を使ってランディングページや UTM パラメータを保持するため、Facebook ピクセルや Google アナリティクスへのデータ送信は継続される。
Nginx FastCGI キャッシュ以外のキャッシュ（Varnish や CDN）でも効果はあるか
非常に効果が高い。Cache-Control: no-store や Set-Cookie ヘッダーは、Varnish をはじめとするほとんどの HTTP キャッシュ層で「キャッシュしてはいけないレスポンス」と判定される。PHP セッションを止めるだけで、あらゆるキャッシュ層が正常に機能し始める。
この設定はサイトの表示速度にどれくらい影響するのか
キャッシュが有効になると、PHP の処理を経由せず Nginx が直接静的 HTML を返すため、TTFB（最初の 1 バイトが届くまでの時間）が劇的に短縮される。同時にサーバーの CPU 使用率も下がるため、アクセス集中時のタイムアウトも防ぎやすくなる。
PixelYourSite を最新版にアップデートしてもセッション問題は解決されないのか
2026 年 8 月時点のバージョンでは、PHP セッションを利用する設計が残っている。今後アップデートで標準動作が変わる可能性はあるが、現状はユーザーが手動で「Disable PHP Sessions」をオンにする必要がある。
この記事のポイント
- PixelYourSite が PHP セッションを開始するため、Nginx FastCGI キャッシュが無効化される
- 「Disable PHP Sessions」をオンにするだけでキャッシュが正常に機能するようになる
- 設定後は必ず Nginx と WordPress のキャッシュをクリアする
- トラッキングは Cookie ベースに切り替わり、精度への影響はごくわずか
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Shield SecurityのcookieがNginxキャッシュを止める時の解決策
Shield Security の icwp-wpsf-notbot cookie がサーバーのページキャッシュを妨害する問題は、Shield の設定で「silentCAPTCHA」の複雑度を「なし」にし、かつカスタムフィルターで匿名ユーザーへの cookie 送信を停止することで解決できる。
なぜ Shield Security が全ページでキャッシュを止めてしまうのか
Shield Security はボット判定や silentCAPTCHA の動作のために icwp-wpsf-notbot という cookie をフロントエンドの全ページで発行する仕様になっている。Nginx のキャッシュ機構は原則として Set-Cookie ヘッダを含むレスポンスをキャッシュしないため、この cookie がすべてのページキャッシュを無効化してしまう。結果として x-proxy-cache: MISS が返り続け、サーバーへのリクエストが毎回発生し、レスポンスタイムが 1000ms を超える状況に陥る。
サーバー側で特定の cookie だけをキャッシュ対象から除外する設定ができない場合、プラグイン側でこの cookie を止めるのが唯一の現実的な解決策になる。
管理画面で silentCAPTCHA の複雑度を「なし」にする
Shield Security の silentCAPTCHA は、ボット防御のためにフロントエンドのページにも cookie をセットする。設定を最小限に絞り込むには、まず管理画面から操作する。
これだけでは cookie の出力が止まらないケースが多い。Shield は silentCAPTCHA の設定に関わらず、フロントエンドの訪問者に対して一律に icwp-wpsf-notbot をセットする内部ロジックを持っているためだ。ここから先はコードレベルの対応が必要になる。
フィルターフックで匿名ユーザーへの cookie 送信を無効化する
Shield Security は icwp-wpsf-notbot cookie を制御するための専用フィルターを提供している。テーマの functions.php に数行のコードを追加すれば、ログインしていない一般訪問者に対する cookie の送信だけを停止できる。
functions.php に追加するコード
以下のコードを子テーマの functions.php に追加する。子テーマを使用していない場合は、Code Snippets プラグインなどで追加してもよい。テーマの直接編集はアップデートで消えるため避ける。
/**
* Shield Security の icwp-wpsf-notbot cookie をログインしていないユーザーには送信しない
*/
add_filter( 'icwp_shield_set_notbot_cookie', function( $set_cookie ) {
if ( ! is_user_logged_in() ) {
return false;
}
return $set_cookie;
} );このフィルターは icwp-wpsf-notbot cookie をセットする直前に呼び出される。ログインしていないユーザーの場合は false を返して cookie の発行をブロックし、ログイン済みユーザーには通常通り cookie を許可する。管理画面のログイン保護や IP ブロック、ファイアウォールなどのコア機能には影響しない。
動作確認の手順
- シークレットウィンドウでサイトにアクセスする
- ブラウザの開発者ツール（F12）→「アプリケーション」タブ→「Cookie」で
icwp-wpsf-notbotが存在しないことを確認する - レスポンスヘッダーから
Set-Cookieが消えていることを確認する - 2回目以降のアクセスで
x-proxy-cache: HITが返ることを確認する
全プラグインを最新に保って不要な干渉を防ぐ
Shield Security はアップデートの頻度が高く、バージョンによって内部のフィルター名が変更されることがある。Shield 22.1.3 および WordPress 7.0.1、PHP 8.2 環境では上記のフィルターが有効だが、プラグインが更新された際にはフィルター名が維持されているかを確認する必要がある。
また、キャッシュ系プラグインや CDN を併用している場合は、cookie 停止後にキャッシュを完全にクリアしてからテストすること。古いキャッシュが残っていると HIT になっていてもレスポンスが遅いままに見える場合がある。
よくある質問
SilentCAPTCHA を無効にしただけでは cookie は消えないのか
多くの場合、管理画面の設定だけでは cookie の出力は止まらない。Shield は silentCAPTCHA が無効でもフロントエンドの全リクエストに cookie をセットする内部挙動を持っている。確実に止めるにはフィルターフックの追加が必要だ。
このフィルターでログイン保護やファイアウォールは機能しなくなるか
今回のコードは匿名ユーザーへの icwp-wpsf-notbot cookie 送信だけを止めるもので、IP ブロックやブルートフォース保護、ファイアウォールといった Shield の主要防御機能はすべて通常通り動作する。ログインしたユーザーには引き続き cookie がセットされる。
functions.php を直接編集するのはリスクがないか
テーマの functions.php を直接編集すると、テーマのアップデートで変更が失われる。必ず子テーマを作成するか、Code Snippets のようなコード管理プラグインを使用する。また、コード追加前にサイトのバックアップを取得しておくと安全だ。
フィルターが効かない場合の確認ポイントは
Shield のバージョンが古い、あるいは逆に新しすぎてフィルター名が変更されている可能性がある。Shield の公式ドキュメントや変更履歴を確認する。また、キャッシュ系プラグインでサーバー側のキャッシュとは別にページキャッシュが残っていると、cookie 停止後も古いレスポンスが返り続けるため、すべてのキャッシュをクリアしてからテストする。
レンタルサーバーのキャッシュ設定で cookie ごとの除外はできないのか
共用サーバーの Nginx キャッシュ設定はサーバー全体で一律に適用されることが多く、特定の cookie だけを除外する柔軟な設定は提供されないケースがほとんどだ。サーバー側で対応できない以上、プラグイン側で cookie を止めるのが最も確実な方法になる。
この記事のポイント
- Shield Security の icwp-wpsf-notbot cookie が Nginx のページキャッシュを全面的に阻害する
- 管理画面で silentCAPTCHA の複雑度を「なし」にしても cookie は止まらない
- functions.php にカスタムフィルターを追加しログインしていないユーザーへの cookie 送信を停止する
- フィルター追加後はシークレットウィンドウで Set-Cookie ヘッダーと x-proxy-cache の値を確認する
- プラグインのアップデート後はフィルター名の変更に注意しキャッシュを完全クリアして再テストする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている