公開した記事がサイトマップに出てこない。その状態が、最大で100日続くことがあります。プラグインが古い一覧を保存しておく期間が、そう決まっているからです。
記事は公開した。Rank Mathのサイトマップ設定も済ませてある。それなのに、新しい記事が一覧に載らない。逆に、下書きへ戻したはずの記事は消えずに残っています。解説記事に書いてある「キャッシュを削除するボタン」を探しても、管理画面には見当たりません。押すべきボタンが存在しないなら、そこで打てる手は尽きます。
サイトマップが更新されない原因は、思っているより単純なところにあります。サイトマップは、アクセスされるたびに作り直されているとは限りません。いったん作られたものが保存され、そのまま配られ続けることがあります。だから「公開すれば載る」という前提が、静かに崩れます。しかもエラーは出ません。サイトマップのURLを開けば、それらしいXMLが普通に返ってきます。
原因の見当がついたのは、運用している複数サイトのうち2サイトで起きた状態を追いかけて、プラグインの実装を開いてからでした。どこで処理が止まっているのかは、コードを読むまで分かりませんでした。この記事に書くのは、そこで見えたことと、そのあと管理画面で実際に効いた手順です。検索して出てくる手順をなぞったものではありません。
先に結論を2つ置いておきます。ひとつは、この状態を確実に解除できる手順が1つあること。もうひとつは、サイトマップの更新日時が新しくなっていても、それは直った証明にならないということ。実際、更新日時だけを見て「正常」と判断して、見落としました。
読み終えたとき、症状の切り分けから復旧、そして直ったことの確認まで、自分の手でひととおり回せる状態になるように書いています。掲載されているかどうかを毎回人が見に行かなくてよい形は AI人格® Web運用 にまとめてあります。
症状の確認｜公開したのに、サイトマップに何日も載らない
サイトマップとは、サイト内にどんなページがあるかを一覧にして検索エンジンへ渡すファイルです。WordPressではプラグインが自動で作るのが一般的で、Rank Mathもその機能を持っています。
正常に動いているときは、記事を公開してからさほど間を置かずにサイトマップの中身が変わります。手元の監視は、公開から15分後には掲載されている前提で組んでいます。新しい記事のURLが一覧に増え、更新日時も新しくなっているはずです。特別な操作は要りません。
異常のサインは、大きく3つあります。
- 公開した記事が、何日たってもサイトマップに出てこない
- 下書きへ戻した記事や削除した記事が、サイトマップに残り続ける
- 更新日時だけが新しくなっているのに、中身の顔ぶれが変わっていない
1つ目だけを異常だと思いがちですが、実際にやっかいなのは2つ目と3つ目です。特に3つ目は、確認しているつもりで見逃す形になります。
運用している複数サイトのうち2サイトで、この状態を実測しました。1サイトは同じ時期にまったく正常でした。同じプラグインを使っていても、起きるサイトと起きないサイトがあります。だから「Rank Mathを使っているなら必ずこうなる」という話ではありません。逆に言えば、自分のサイトで起きているかどうかは、自分で確かめるしかないということでもあります。
サイトマップは2階層になっている
XMLサイトマップとは、検索エンジン向けにURLの一覧をXML形式で書き出したファイルです。Rank Mathが出力するものは、親と子の2階層になっています。
親にあたるのが sitemap_index.xml で、ここには子のサイトマップの場所と、それぞれの最終更新日時が並んでいます。子にあたるのが投稿タイプごとのサイトマップで、記事のURLが実際に書かれているのはこちらです。「サイトマップが更新されない」と言うとき、見るべきなのは基本的に子の側になります。
まず切り分ける｜「まだ載っていない」と「固着している」は別物
反映待ちとは、記事を公開してからサイトマップが作り直されるまでの短い時間差のことです。固着とは、いったん作られた古い一覧が配られ続けて、いつまでも作り直されない状態を指します。
この2つは、見た目がよく似ています。どちらも「新しい記事がサイトマップに無い」という同じ症状に見えるでしょう。ただし原因も対処もまったく違います。反映待ちなら待てば直りますし、固着はいくら待っても直りません。
判定は感覚ではなく突合でやります。手順はこれだけです。
1. サイトマップのURLの末尾に ?cb=1 のようなクエリを足して開く。数字は毎回変える。ブラウザやサーバーの手前側にあるキャッシュを避けるための手当てです 2. 表示されたXMLから、記事のURLを全部書き出す 3. WordPressの投稿一覧を公開状態で絞り込み、こちらも全部書き出す 4. 2つを突き合わせる
判定基準はシンプルです。公開しているのにサイトマップに無いページがゼロ、サイトマップにあるのに公開していないページもゼロ。この2つが同時に成り立ったときだけ正常です。どちらか一方でも残っていれば、異常が起きています。
前者ばかり気にして後者を見落とすと、判断を間違えます。実際に見落としました。下書きへ戻した記事が2本、サイトマップに残り続けていたのに、当時は「監視の側の誤報だろう」と結論を書いています。掲載過多も、立派な異常のサインです。
公開直後であれば、1時間ほど置いてからもう一度突合します。それでも変わらなければ、待って直る状態ではありません。
よく紹介されている対処が効かないことがある
無変更保存とは、設定値を何ひとつ変えないまま「変更を保存」ボタンだけを押す操作です。広く通っている用語ではないので、この記事の中での呼び方だと思ってください。サイトマップまわりのトラブルで、よく案内されている手順のひとつになります。
2026年8月12日時点で日本語で検索すると、上位に出てくるのは設定手順や初期設定の解説が中心です。キャッシュの削除、キャッシュ系プラグインからの除外、表示件数の変更といった回避策も紹介されていて、この記事だけが知っている情報ではありません。
問題は、そのうちのいくつかが、環境によっては何も起こさないという点です。
ひとつ目。「サイトマップのキャッシュを削除するボタンを押す」という案内があります。ところが、実装を確認した1.0.264の管理画面に、そのボタンは存在しませんでした。押せないものは押せません。
ふたつ目。「設定を変えずに変更を保存を押す」。これも効きませんでした。理由は実装にあります。設定の保存処理が、変更されたキーが0件だった場合には何もせずにそのまま終了する作りになっていたからです。画面上は保存したように見えて、内部では何も起きていない。ボタンを押した手応えだけが残ります。どちらも、2026年8月5日に1.0.264の実装と管理画面で確かめた範囲の話です。バージョンごとの違いは次の章で整理します。
ここは正直に書いておきます。この2つが効かないと分かるまでに、数週間かかりました。その間ずっと、管理画面での操作をお願いし続けていました。毎週のように同じ依頼を出して、毎週のように直らない。依頼された側は管理画面を開いて、書かれているボタンを探して、見つからないまま閉じる。それが何度も繰り返されました。繰り返す側に残ったのは徒労で、やがて「その手順は本当に合っているのか」という不信に変わっていきました。
原因は環境でもプラグインでもありません。AI側が、自分の出した対処法を一度も検証していなかったことです。どこかで読んだ手順をそのまま渡して、効いたかどうかを確かめていませんでした。実装を読んだのは、その数週間の後でした。読んだその日に、ボタンが無いことも、無変更保存が何もしないことも分かっています。先に読めばよかった。
効かない手順を、確かめずに何週間も渡し続けていた。
この失敗があったからこそ、後半の「直ったことの確かめ方」を手順として固定しています。対処法は、効いたことを確認して初めて対処法になります。
原因｜サイトマップはキャッシュされて配られている
サイトマップのキャッシュとは、一度作ったサイトマップを保存しておき、次にアクセスがあったときはその保存版を返す仕組みです。毎回ゼロから組み立てると重くなるため、多くのプラグインが採用しています。
Rank Mathもサイトマップをキャッシュして配信します。そして、その保存版の保持期間は100日です。ここが今回の話の中心になります。エラーではなく設計として、古い一覧が残り続ける余地がある。
本来は、記事を公開したり更新したりしたタイミングで保存版を捨てる処理が動き、次のアクセスで新しいサイトマップが作られます。ところが、この処理が走っていない環境があります。走らなければ保存版はそのまま残り、古い一覧が最大100日配られ続けるわけです。
エラーが出ないのは、この構造のせいです。壊れているわけではなく、保存された古いものを正しく返しているだけなので、サイトマップのURLを開けば普通にXMLが表示されます。中身が古いことだけが問題で、それは開いただけでは分かりません。
ここから先は、断定を避けて書きます。
なぜこの環境で無効化の処理が走らないのか、その理由は特定できていません。プラグイン側の不具合だと決めつけることもできません。サーバーの構成が関係している可能性も、ほかのプラグインとの組み合わせで起きている可能性も残っています。分かっているのは、走っていないという事実と、その結果として何が起きるかだけです。
バージョンの扱いも、混ぜずに書いておきます。実装を読んで確認したのは2026年8月5日で、対象はRank Math SEOの1.0.264です。読んだのはサイトマップのキャッシュを扱うファイルと、設定の保存処理を扱うファイルの2つになります。一方、固着そのものを実際に観測したのは1.0.264と1.0.275の両方です。この記事を書いている時点で配布されている最新版は1.0.276ですが、その実装が同じかどうかは確認していません。
つまり「最新版なら直っている」とも「最新版でも同じ」とも、この記事は言えません。言えるのは、後述の切り分け手順で自分のサイトの状態を確かめられる、ということだけです。
直し方｜出力が変わらない設定を1つだけ変えて保存し、すぐ戻す
強制再生成とは、設定の保存処理をわざと動かすことで、保存されているサイトマップを作り直させる操作です。こちらも、この記事の中だけの呼び方です。前の章で書いたとおり、保存処理は変更されたキーが1つ以上あるときにだけ動きます。だったら、実際に1つだけ動かせばいい。それだけの話です。
大事なのは「どの設定を動かすか」です。出力が変わってしまう項目を触ると、直すつもりで別の問題を作ります。手順は次のとおりです。
1. 実行する前に、Rank Mathの設定をエクスポートしてバックアップを取る。何かあったときに戻せる状態を先に作っておきます 2. サイトマップに載っているURLの総数を数える。前の章の突合で書き出したものが使えます 3. サイトマップ1ページあたりの分割件数の設定を確認する。総URL数がこの分割件数に届いていなければ、この値を多少動かしても出力されるファイルは一切変わりません 4. その分割件数を1だけ動かして保存する。画面に表示されている値が200なら201に、1000なら999に、というように1つずらすだけで十分です 5. 保存できたら、すぐに元の値へ戻してもう一度保存する 6. サイトマップのURLに ?cb=2 のようなクエリを付けて取得し直し、中身を確認する
ポイントは、保存処理を2回動かしていることです。1回目で保存版が捨てられ、2回目で設定が元に戻ります。設定は最終的に元どおりで、サイトマップだけが作り直されます。
注意点を1つ。総URL数が分割件数を超えているサイトでは、この操作で出力そのものが変わってしまいます。サイトマップが複数ファイルに分かれ直したり、まとまり直したりするからです。だから手順2でURL数を先に数えます。数えずに触るのはおすすめしません。
そのうえで、正直に書いておきます。総URL数が分割件数を超えているサイトで、この手順を安全に実行できるかどうかは確認できていません。条件に当てはまるサイトでは実行しない運用にしているので、実行した記録そのものがないからです。だから、当てはまる場合にこの記事が渡せるのは切り分けまでになります。前半の突合で「待って直る状態ではない」ところまでは自分で確かめられますが、そこから先の手順は、確かめていない以上おすすめできません。
なお、サイトマップモジュールの有効化や、サーチコンソールへの送信といった設定そのものの手順は、この記事では扱いません。そちらは Rank Math SEO設定ガイド｜WordPressで失敗しない使い方 にまとめてあります。この記事が扱うのは、設定は済んでいるのに載らないという場面です。
直ったことの確かめ方｜lastmodを見て安心しない
lastmodとは、サイトマップの中に書かれている最終更新日時のことです。親のサイトマップには子ごとの日時が、子のサイトマップには各URLの日時が入っています。
ここが、いちばん間違えやすいところです。この日時が新しくなっていても、中身が更新されているとは限りません。日時だけが動いて顔ぶれが古いまま、という状態が実際にありました。それを「更新されているから正常」と読んで、下書きへ戻した記事が残り続けているのを見落としています。
更新日時は、直った証明になりません。
確かめ方は、切り分けのときと同じ突合をもう一度回すだけです。キャッシュ回避のクエリを付けてサイトマップを取得し、URLを全部書き出し、WordPressの公開記事一覧と突き合わせる。未掲載がゼロ、掲載過多もゼロ。この2つが揃ったときだけ正常です。
面倒に見えるかもしれませんが、記事数が数十本の規模なら、手作業でもそれほど負担にはなりません。そして、この確認をやらないと、直っていないものを直ったと記録することになります。数週間ぶんの依頼が空振りになったのは、まさにこの確認を飛ばしていたからでした。
サーチコンソール側でサイトマップの送信状況を見る手順は Googleサーチコンソール 使い方完全ガイド 今日から始められる設定と活用法 で説明しています。送信状況の画面と、実際に配信されているサイトマップの中身は別の話なので、両方を見るのが確実です。
毎回人が気づくのは無理｜監視と復旧を仕組みに寄せる
AI外部脳とは、状態の確認と材料集めを引き受けて、判断できる形にそろえるところまでを担う仕組みです。実行するかどうかを決める役割は、人の側に残ります。
ここまでの手順は、1回やるぶんには難しくありません。問題は頻度です。記事を公開するたびに、サイトマップを開いて、URLを書き出して、公開記事一覧と突き合わせる。1本の公開につき数分。それを毎回、抜けなく続けられるかというと、現実的ではありません。実際、続かなかった。
そこで、確認の側を仕組みに寄せています。
- 公開の15分後と60分後に、サイトマップへの掲載を自動で確認する。対象は3サイト
- 検索状況の巡回は別枠で毎日回す。こちらの対象は4サイト
- 掲載されていなければ、反映待ちなのか固着なのかを切り分ける
- 固着と判定されたら、前の章の手順にあたる復旧を実行する
人の側に残しているのは、「本当にそうか」と疑うこと、本番環境で操作を実行してよいかの承認、そして出てきた結果を受け取って次を決めることです。原因を特定したのも、実装を読むという作業自体は仕組み側でしたが、読む必要があると判断したのは、効かない依頼が繰り返されたことを人が変だと思ったからでした。
任せられるのは、気づくところまで。決めるところは、まだ渡していません。
そもそもプラグインの選び直しから考えたいという場合は All in One SEO・Yoast・Rank Math比較【失敗しない選び方】 で判断材料を整理しています。今回のような挙動を踏まえて選び直すかどうかは、サイトの規模と運用体制で答えが変わるでしょう。
切り分けと復旧までは、手順どおりにやれば自分でできます。続けて見張るところから先は、仕組みがないと続きません。ここに段差があります。
監視から復旧までを含めたWeb運用の設計についてのご相談は お問い合わせ から受け付けています。
よくある質問
Q. サイトマップに載らないと、検索結果にも出ないのですか
A. 必ずしもそうではありません。サイトマップは検索エンジンにページの存在を伝える手段のひとつで、唯一の経路ではないからです。内部リンクや外部からのリンクをたどって見つかることもあります。ただし、新しい記事を早く見つけてもらうための経路が1本閉じている状態ではあります。
Q. 待っていれば直りますか
A. 反映待ちなら直りますが、固着していれば待っても直りません。この2つは見た目が同じなので、記事内の突合手順で切り分けてください。公開から1時間ほど置いても中身が変わらない場合は、待って直る状態ではない可能性が高くなります。
Q. サイトマップの更新日時が新しくなっていれば直ったと考えていいですか
A. 考えないでください。更新日時だけが動いて、中身の顔ぶれが古いままという状態が実際にありました。公開記事の一覧とサイトマップのURLを全件突き合わせて、未掲載ゼロ・掲載過多ゼロを確認したときだけ正常と判断します。
Q. サイトマップに載れば、Googleに登録されますか
A. これは別の話です。サイトマップに載っていても、インデックス登録されないことはあります。その段階を実測で追った記録は AI外部脳にSEO監視を10日まかせた実演ログ｜4本の揃わなかった結末 にまとめてあります。この記事が扱うのは、あくまでサイトマップに載るまでの段階です。
Q. 使っているバージョンが違いますが、同じことが起きますか
A. 分かりません。実装を読んで確認したのは1.0.264だけで、それ以降のバージョンで同じ作りかどうかは確認していません。固着そのものは1.0.264と1.0.275の両方で観測しています。バージョンで判断するより、記事内の突合手順で自分のサイトの状態を実際に確かめるほうが確実です。
まとめ｜今日やること
やることは3つです。順番も含めて、そのまま使えます。
1. 切り分ける。サイトマップにキャッシュ回避のクエリを付けて取得し、URLを全件書き出して、WordPressの公開記事一覧と突き合わせる。未掲載か掲載過多があれば異常 2. 再生成する。設定をエクスポートしてバックアップを取り、URL総数が分割件数に届いていないことを確認したうえで、分割件数を1つだけ変えて保存し、すぐ元へ戻して保存する 3. 確かめる。もう一度突合する。更新日時が新しくなったことは、直った証明にはならない
この3つを回せば、サイトマップに載るところまでは自分の手で戻せます。その先、載っているのに順位が伸びないという段階に進んだら、内部対策の側の話です。そちらは サーチコンソールで見る順位が上がらない7つの内部対策と原因 で扱っています。
最後に、この記事で書いた失敗をもう一度だけ。効かない手順を数週間渡し続けていた原因は、対処法を出したあとに効いたかどうかを確かめていなかったことでした。手順が正しいかどうかより、確認が組み込まれているかどうかのほうが、運用では効いてきます。
自社でやるなら、この確認を人の記憶と気合いに置かない形にしておくことをおすすめします。公開のたびに誰かが思い出して手作業でやる設計は、忙しくなった週から静かに止まる。監視と復旧を含めた運用の組み立てについては お問い合わせ からご相談ください。
