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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
XMLサイトマップで「XML 宣言はドキュメントの先頭でのみ許可されています」エラーの直し方
XMLサイトマップのURLを開いたときに「XML 宣言はドキュメントの先頭でのみ許可されています」というエラーが表示された場合、原因はほぼ確実に出力の先頭に空行や余計な改行が混入していることにある。この症状は、PHPファイルの末尾の閉じタグ ?> のあとの空白や、プラグイン・テーマが意図せず出力した文字がXML宣言より前に現れることで発生する。解決には、サイトのキャッシュを完全にクリアしたうえで、すべてのプラグインを停止し標準テーマに切り替えて原因を切り分け、問題のファイルから不要な空白を取り除く手順を踏む。
なぜXMLサイトマップに「XML 宣言は先頭でのみ許可」エラーが出るのか
XMLサイトマップはブラウザや検索エンジンが読み取る形式で、文書の最初に <?xml version="1.0" encoding="UTF-8"?> という宣言がなければならない。ところが、この宣言よりも前に空白や改行が1文字でも出力されると、パーサーが「XML宣言はドキュメントの先頭でのみ許可されています」という旨のエラーを返す。
WordPress環境では、PHPスクリプトが実行されて最終的なXMLを生成するが、意図しない場所で echo や ?php 外の空白が出力されると、それが先頭に紛れ込む。代表的なのは、テーマの functions.php やプラグインファイルの末尾に閉じタグ ?> を書いたうえでその後に改行が入っているパターンだ。PHPファイルでは閉じタグを省略することが推奨されており、記述すると余計な空白が出力されるリスクが常につきまとう。
← ここに空白行が存在する
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url><loc>https...</loc></url>
</urlset><?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <url><loc>https...</loc></url> </urlset>
この図のように、たった1行の空行がXML宣言の前に置かれるだけでサイトマップ全体がエラーになる。実際に自分のサイトのサイトマップURLを開き、ページのソースを表示（ブラウザの「ページのソースを表示」機能）すると、1行目に空行が入っていないか容易に確認できる。
空白行の混入源を特定する手順
STEP 1 キャッシュを完全にクリアする
まず、キャッシュ系プラグイン（WP Super CacheやW3 Total Cacheなど）のキャッシュをすべて削除する。サーバー側のキャッシュが有効な場合、そちらも管理パネルからクリアする。さらにブラウザのキャッシュも念のため削除しておくと、変更がすぐに反映される。
STEP 2 全プラグインを無効化し標準テーマに切り替える
プラグイン画面からすべてのプラグインを一括で無効化する。その際、SEOプラグイン（Yoast SEOなど）も例外なく停止する。その後、外観→テーマで「Twenty Twenty-Five」など公式の標準テーマを有効化する。この状態がいわゆる「切り分けの初期状態」になる。
もし管理画面にすら入れない障害がある場合は、FTPソフトやレンタルサーバーのファイルマネージャーで /wp-content/plugins/ ディレクトリごとリネームする方法でも一括無効化できる。
STEP 3 サイトマップを開きエラーが消えたか確認する
プラグインを無効にして標準テーマの状態で、Yoast SEOのサイトマップURL（通常 /sitemap_index.xml）にアクセスする。この時点でエラーが消え、正常なXMLが表示されれば、テーマやプラグインのいずれかが原因だと確定できる。
STEP 4 原因のプラグインかテーマを特定する
1つずつプラグインを有効化しながらサイトマップを確認し、エラーが再発するタイミングを探る。エラーが出た時点で最後に有効化したプラグインが原因だ。テーマの場合は、標準テーマで問題が消えた段階で疑いが濃くなる。自作ブロックテーマやカスタムブロックを使っているなら、そのテーマの functions.php に余計な空白がないかも確認しよう。
空白を出力しているファイルを修正する具体的方法
原因が特定できたら、実際のPHPファイルを編集して不要な空白を取り除く。典型的な作業は次のとおりだ。
閉じタグ ?> を削除する PHPファイルの末尾に ?> が記述されていると、その後の改行が出力の先頭に混入する。ファイルの最終行が ?> で終わっている場合は、この閉じタグをまるごと削除する。PHPではファイル末尾の閉じタグが省略可能で、むしろ推奨されていない。削除後に空行が残っていればそれも取り除く。
ファイルの先頭と末尾の空白を確認する <?php の前や、ファイルの最終行より後ろに空白がないかエディタで確認する。改行やスペースが残っている場合はそれらを削除する。複数の開発者が触るテーマでは、意図せず混入していることが多い。
プラグインやテーマのファイルを直接編集する FTPクライアントやレンタルサーバーのファイルマネージャー、あるいはWordPress管理画面の「プラグインファイルエディター」「テーマファイルエディター」を使って該当ファイルを開き修正する。編集後は必ず再度キャッシュをクリアしてからサイトマップを確認する。
キャッシュとPHP設定が影響するケース
空白行が混入していなくても、キャッシュが原因でエラーが表示され続けることがある。ページキャッシュがXML出力の古い状態を保持していると、修正後もエラーが消えないように見える。以下の点を必ず実施しよう。
WP Super Cacheなどキャッシュプラグインのキャッシュを完全に削除する
キャッシュプラグインの設定画面にある「キャッシュを削除」「全キャッシュを削除」といったボタンで全データをクリアする。さらに、サイトマップURLにクエリパラメータ（例 ?nocache=1）を付けてアクセスすることでキャッシュを通さずに表示し、エラーの有無を確認できる。
PHPのメモリ制限は256MBあれば十分だが512MBにしても直らない
メモリ不足が原因で似たエラーが出ることはあるが、今回の「XML宣言は先頭のみ」というエラーはメモリとは無関係であることがほとんどだ。実際に256Mから512Mに増やしても改善しなかったという報告も多い。メモリ増加で解決しなかった場合は迷わず空白行の調査に戻る。
よくある質問
サイトマップのエラーが特定の投稿タイプ（例 商品）でのみ発生するのはなぜか
WooCommerceの商品サイトマップなど、特定の投稿タイプだけ別のファイルで生成される場合、その処理を行うプラグインやテーマの該当部分に空白が混入している可能性が高い。原因箇所を特定するには、SEOプラグインが生成する個別のサイトマップURL（product-sitemap.xmlなど）に直接アクセスし、同じ手順で切り分けを行う。
空白行を削除してもエラーが直らない場合に次に試すことは
キャッシュの削除漏れや、サーバー側のVarnishやCDNがXMLをキャッシュしている可能性を疑う。また、wp-config.php ファイルの先頭や末尾に空白が入っているケースも、サイト全体の出力に影響を及ぼすため確認する。さらに、PHPの出力バッファリングが影響している場合もあるが、まずは wp-config.php まで含めた全ファイルの空白確認を徹底する。
Health Checkトラブルシューティングプラグインは役に立つのか
Health Check & Troubleshootingプラグインは、管理画面からセッションベースでプラグインの停止やテーマの切り替えを安全に行えるため、切り分け作業を効率化できる。有効化して「トラブルシューティングモード」に入れば、他の訪問者には影響を与えずにテストできる。ただし、空白行の直接の修正までは行わないため、あくまで原因特定の補助ツールとして使う。
Yoast SEOのXMLサイトマップキャッシュを個別にクリアする方法は
Yoast SEOはサイトマップの生成結果をキャッシュしないが、外部のキャッシュプラグインと競合することがある。Yoast SEO側で直接キャッシュをクリアする機能はないため、前述のようにサイト全体のキャッシュを削除し、可能ならSEOプラグインを一度無効化してから再度有効化すると、内部のトランジェントが更新されて問題が解消されることもある。
オリジナルブロックテーマを使っているが、どこに注意すればよいか
ブロックテーマでは functions.php の末尾に空白が入っていないか、そしてカスタムブロックのプラグインとしてのPHPファイル（ブロックの動的レンダリング部分）に閉じタグ ?> と空白が残っていないかを必ずチェックする。自作ブロックは開発時にテストを繰り返すため、ファイル末尾の処理が甘くなりがちで、意外な場所から空白が出力されることがある。
この記事のポイント
- エラーの直接原因はXML宣言より前に出力された空白行か改行である
- キャッシュを完全にクリアし、全プラグイン無効化と標準テーマ切り替えで切り分ける
- PHPファイル末尾の閉じタグ
?>とその後ろの空白を削除する wp-config.phpの先頭・末尾や自作テーマのファイルも忘れずに確認する- メモリ増加ではこのエラーはまず直らないため空白行調査に集中する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている