Search Consoleの手間を減らしたい。WordPressのサイトマップを確認して分かったこと

ブログを公開したあと、毎回行っていた作業があります。新しい記事のURLをコピーし、Google Search Consoleを開いて、URLを検査してから「インデックス登録をリクエスト」を押すことです。

一つひとつは難しくありませんが、記事を公開するたびに繰り返すので、少しでも手間を減らせないかと思っていました。

自宅のMac miniと、有料で使っているChatGPT。せっかくならブログ運営にももっと役立てたい。そこで今回は、ChatGPTに相談しながら、サイトマップを使う方法を確認してみました。

結論からいうと、モノトキのサイトマップはすでに動いていて、最新記事も含まれていました。 新しい自動化の仕組みを作る前に、今ある設定を確認するところから始めてよかったです。

記事を公開するたびに行っていたSearch Consoleの操作

これまでは、記事を公開したあとに次のような操作をしていました。

1. 公開した記事のURLをコピーする
2. Search Consoleを開く
3. 記事のURLを検査する
4. 「インデックス登録をリクエスト」を押す

公開後の作業が少しずつ増えていくと、記事を書き終わっても、まだやることが残っている感覚になります。投稿まわりの作業を効率化してきたので、次はこの操作も見直したいと思いました。

最初は、このボタンを押すところまで自動化できないかと考えていました。ただ、今回はサイトマップを確認し、記事の存在をGoogleに知らせる仕組みがすでに整っているかを見ることにしました。

サイトマップと個別の登録リクエストは別の仕組み

サイトマップは、サイト内のページのURLなどを検索エンジンに伝えるためのファイルです。Googleが新しい記事や更新されたページを見つける手がかりになります。

Googleの公式ヘルプでは、正常に読み取られたサイトマップは、その後も定期的に再クロールされると説明されています。通常の記事追加のたびに、サイトマップを手動で再送信し続ける運用は必要ありません。

ただし、サイトマップへの掲載は、個別の「インデックス登録をリクエスト」と同じ操作ではありません。 サイトマップに載っただけで、すぐに検索結果に表示されるわけでもありません。

今回は「登録リクエストのボタン操作を自動化できた」という話ではなく、「手作業を減らせる運用になっているかを確かめた」という内容です。

Search Consoleを開くと、サイトマップはすでに登録されていた

まず、Search Consoleでモノトキのプロパティを選び、左メニューの「サイトマップ」を開きました。そこには、次の3件が登録されていました。

サイトマップ	状態	検出ページ数
/wp-sitemap.xml	成功	43
/wp-sitemap-posts-post-1.xml	成功	35
/sitemap_index.xml	取得できませんでした	0

※2026年10月20日の確認時点の表示です。検出ページ数は、インデックス登録済みのページ数ではありません。また、親のサイトマップと投稿用のサイトマップには重複があるため、43と35を合計するものではありません。

投稿用のサイトマップは、最終読み込み日時が2026年10月20日になっていました。少なくとも、Googleがこのサイトマップを読み取り、正常に処理できていることは確認できました。

WordPressのサイトマップに最新記事があるか確認する

次に、投稿用のサイトマップをブラウザで開きました。モノトキでは、次のURLです。

モノトキの投稿用XMLサイトマップ

画面には「このXMLサイトマップはWordPressが生成しているもの」と表示され、記事のURLと最終更新日が並んでいました。

Macでは⌘＋Fでページ内検索を開き、最新記事のURLの末尾を検索すると探しやすいです。今回は、当日公開したRectangleの記事が一覧に含まれていることを確認できました。

記事を公開したあと、サイトマップを手で編集する作業はしていません。 それでも最新記事が含まれていたので、WordPress側で記事が反映されていることを確かめられました。

ただし、ここで見ているのは現在のサイトマップです。Search Consoleの読み込み日は同じ日でも、Googleが取得した時点で最新記事が含まれていたかまでは、この画面だけでは分かりません。

取得できないサイトマップの登録を整理した

一方、/sitemap_index.xmlだけは「取得できませんでした」と表示されていました。詳細画面を開くと、「一般的なHTTPエラー」となっています。

ここで、すぐに削除せず、右上の「サイトマップを開く」から実際のページも確認しました。表示されたのは、モノトキの「404 NOT FOUND」画面でした。

正常に動いているWordPressのサイトマップは別に確認できているので、今回は使えないURLの送信登録を整理することにしました。操作は次のとおりです。

1. 失敗している/sitemap_index.xmlの詳細画面を開く
2. 右上の「︙」を押す
3. 「サイトマップの削除」を選ぶ

この操作で削除するのは、Search Consoleのレポートにあるサイトマップの登録です。ブログの記事や、Googleに登録済みのページを削除する操作ではありません。

なお、別のサイトで同じエラーが出ていても、一律に削除するのではなく、使っているサイトマップとURLの状態を先に確認してください。

今回できたことと、まだ分からないこと

今回行ったのは、新しいプログラムの導入ではありません。既存のサイトマップの動作確認と、使えない送信登録の整理です。

• WordPressが生成するサイトマップに最新記事が含まれていると確認できた
• Googleによる投稿用サイトマップの取得が成功していると分かった
• 404になっていたサイトマップの送信登録を削除できた

一方、個別リクエストを省いた場合に、何日でインデックス登録されるかはまだ試していません。登録の速さが変わるか、アクセスが増えるかも、今回の作業だけでは判断できません。

作業時間も実測していないので、「何分短縮できた」という数字は出せません。ただ、今後個別リクエストを省けるなら、記事のURLをコピーして、検査して、ボタンを押すという毎回の操作を減らせます。

次の記事では、個別リクエストをせずに様子を見てみる

次に公開する記事では、サイトマップに任せる方法を試す予定です。

1. 通常どおり記事を公開する
2. 公開した日時とURLをメモする
3. 個別の「インデックス登録をリクエスト」は押さない
4. 後日、Search ConsoleのURL検査で登録状況を確認する

確認時には、状況を見るだけにして、登録リクエストは押さないようにします。また、確認した日時も残し、登録済みになったことを確認できるまでの経過を記録するつもりです。確認の間隔があるため、実際に登録された時刻まで正確に測れるわけではありません。

自動化というと、何か新しいアプリやスクリプトを作るイメージがありました。でも今回は、すでに動いている機能を知ることが、作業の見直しにつながりました。

ChatGPTに相談しながら画面を一つずつ確認できたので、設定をよく分からないまま増やさずに済んだのもよかったです。次は実際の公開後の経過を見ながら、続けやすい運用にしていこうと思います。

あわせて読みたい

• Mac miniを使ったブログ作業の自動化について
• ChatGPTを使った記事作成について

参考にした公式情報

• Google Search Console ヘルプ：サイトマップ レポートを使用してサイトマップを管理する
• Google 検索セントラル：URLの再クロールをGoogleにリクエストする

※画面と確認結果は2026年10月20日時点のものです。