Google Search Console(サーチコンソール)のインデックス登録レポートを確認していて、/feed/ のようなフィードURLが「未登録」として表示されているのを見つけると、「何か重大な設定ミスがあるのではないか」「ブログ全体の評価が下がるのではないか」と不安になりますよね。
結論からお伝えすると、Search ConsoleにfeedのURLが表示されたり未登録になっていたりしても、それだけで修正が必要とは限りません。意図して検索結果に出さないようにしている(noindexなどの)状態であれば、検索登録させるための対応は不要です。
ブログを運営するうえで大切なのは、「検索ユーザーに読んでもらう記事本文」と「購読アプリなどに更新を届けるfeed」の役割を分けて考えることです。すべてのURLを検索結果に登録させる必要はありません。feedの提供を維持したまま、本当に対応が必要なURLだけを切り分けることで、不要な設定変更によるトラブルを防げます。
今回は、feedが未登録になる理由ごとの判断基準と、検索表示を適切に制御するための確認ポイントを整理しました。
feedが未登録でも、すぐに修正が必要とは限りません
まずは、Search Consoleにfeedが表示されたときに慌てて設定を変える必要がない理由と、状況ごとの判断基準を見ていきましょう。
feedの役割と未登録の考え方
WordPressのRSSやAtomといったfeedは、本来、フィードリーダーなどの購読ツールへ記事の更新情報を配信するための仕組みです。WordPressでは、サイト全体の最新投稿を配信する /feed/ だけでなく、個別記事へのコメントを配信する /記事slug/feed/ など、複数のfeedが標準で生成されます。
feedのURLをブラウザで開くと、XML形式のコードや記事の要約が並んで表示されます。これは購読ツールが機械的に読み取るための正常なデータ形式であり、コードが表示されているからといってページ自体が「低品質」というわけではありません。
また、Search Consoleを使ううえで混同しやすいのが、「レポートの一覧にURLが載ること」「Googleがインデックス登録していること」「個別の検索結果に表示されること」の違いです。
- インデックス登録レポートへの掲載:GoogleがそのURLを検出した記録であり、掲載されていること自体がエラーを意味するわけではありません。
- URL検査ツールの登録情報:Googleが取得した版について、登録の有無や未登録の理由を確認する情報です。一方、「公開URLをテスト(ライブテスト)」は現時点の取得・登録可能性を調べる機能で、登録済みかを確認する検査とは異なります。
- 検索結果への表示:インデックスに登録されていても、特定の検索キーワードで必ず検索結果に表示されるとは限りません。また、
site:検索の結果は網羅的ではないため、検索演算子でヒットしないことだけを理由に未登録と決めつけることはできません。
詳しくは、Googleの公式ドキュメントである Page indexing report(インデックス登録レポート)、URL検査ツール、および 検索演算子site: の制限 を確認してください。WordPressの標準的なfeedの仕様については WordPress Feeds に記載されています。
feedの状態別・判断表
Search ConsoleでfeedのURLを見かけたときは、表示されている「理由」を確認し、次の表を参考に判断してみてください。
| 状態・表示理由 | 主な意味 | 判断と対応の目安 |
|---|---|---|
| noindex タグによって除外されました | Googleが取得した時点でnoindexを検出した | 検索表示させない意図なら維持。購読用feedを検索登録させるための対応は不要です。現在の指定を確認したい場合はレスポンスヘッダーを調べます。 |
| クロール済み – インデックス未登録 | Googleがクロールしたが、登録されていない | 検索に出す必要がなければ維持。この表示だけでは、サイト全体の低評価やnoindexの有無は判断できません。 |
| 重複ページ・代替ページとして未登録 | Googleが別のURLを正規として扱っている | 選択された正規URLを確認。意図した記事本文が選ばれていれば維持します。別のURLが選ばれている場合は、記事とfeedを個別に調べます。 |
| 検索結果にfeedのURLが実際に表示されている | その検索でfeedのURLが表示された | まず現在のヘッダーを確認。表示を止めたいのにnoindexがなければ、feedだけへの付与を検討します。既にあれば、Googleの取得時点と現在の応答を照合します。 |
| robots.txt によりブロックされました | robots.txtのDisallow指定により、クローラーのアクセスが遮断されている | 設定の見直し。feedのnoindexをGoogleに認識させたい場合は、アクセスを遮断しないようにrobots.txtの設定を確認します。 |
| feedが403・404・5xxになったり、XMLを取得できなかったりする | アクセスや配信に問題がある可能性がある | URLと配信状態の確認。正確なURL、HTTPステータス、転送先、XML応答、アクセス制限を調べます。必要な購読用feedなら、検索登録とは別に配信の問題を確認します。 |
| 記事HTMLが未登録になっている | Googleが記事のURLを未登録と報告している | 記事側の確認へ戻る。記事のURL検査で理由を確認し、noindex、正規URL、リンクなどを個別に調べます。feed送信だけで解決するとは決めません。 |
意図した設定によって未登録になっているのであれば、慌てて新しい設定を追加する必要はありません。もし「記事本文が検索に出ない」ことで困っている場合は、feedではなく記事のURLを個別に確認しましょう。
購読を残して、必要なfeedだけ検索表示を制御する
「購読ツールへの配信は続けたいけれど、検索結果には記事本文を出したい」という場合、feedの配信自体を止める必要はありません。feedの提供を維持したまま、検索結果への表示だけを制御する方法を確認しましょう。
まずHTTP応答のnoindexを確認する
通常のWebページ(HTML)では、<head> タグ内に <meta name="robots" content="noindex"> を記述して検索結果への表示を防ぎます。しかし、XML形式で配信されるfeedにはHTMLの <head> タグがありません。
そのため、feedを検索結果に出さないようにするには、サーバーが返すHTTPレスポンスヘッダーに X-Robots-Tag を含めます。
X-Robots-Tag: noindex
※上記はHTTPレスポンスヘッダーの説明用の例です。サーバーの設定ファイルに直接貼り付けるコードではありません。
HTTPステータス200でXMLデータを配信しながら、このヘッダーを返すことで、対応する検索エンジンへ「このURLを検索結果に登録しない」と伝えられます。noindexの有無とは別に、必要なfeedが取得できる状態も確かめましょう。なお、feedにnoindexを設定しても、リンク先の記事本文までnoindexになるわけではありません。同時に、記事側のクロールや登録が保証されるわけでもないため、記事の状態は別に確認する必要があります。
feedに X-Robots-Tag が出力されているかどうかは、パソコンのブラウザで簡単に確認できます。
- Google Chromeなどのブラウザで、確認したいfeedのURL(例:
https://example.com/feed/)を開きます。 - 画面上で右クリックして「検証」を選択し、開発者ツールを開きます。
- 「Network(ネットワーク)」タブを選択し、ページを再読み込み(リロード)します。
- 開いたfeedのURLと一致するリクエスト名をクリックします。
- 「Headers」タブ内の「Response Headers(レスポンスヘッダー)」を確認し、
x-robots-tag: noindex(またはnoindex, follow)が含まれているかを確認します。
HTTPヘッダーによる検索除外の仕組みについては、Google検索セントラルの noindexによる除外 および Robots設定(X-Robots-Tag) で詳しく解説されています。
当サイトでは、すでにnoindexが返っていました
設定を新しく追加する前に、まずは現在のサイトがどのような応答を返しているかを確認することが重要です。
2026-10-20に当サイトのHTTP応答を確認したところ、全体の最新投稿用feed(/feed/)やコメント用feed(/comments/feed/)などにおいて、HTTPステータス200とともに X-Robots-Tag: noindex, follow が返されており、robots.txtによるfeedの遮断指定もありませんでした。
当サイトの公開HTMLには、WordPress用プラグイン「SEO SIMPLE PACK 3.7.0」の出力マーカーが確認できます。公式配布コード(3.7.0)では、feed_noindex の初期値は false で、この設定が有効な場合にfeedの応答へ X-Robots-Tag: noindex, follow を送信する処理があります(参考:初期値を定義するdata.php、ヘッダーを送信するhooks.php)。
配布コードの初期値と、各サイトで実際に保存されている設定は分けて確認する必要があります。また、当サイトでヘッダーが出力されている要因がこのプラグイン単独によるものと特定したわけではありません。お使いの環境によって、テーマの独自機能やサーバー側の設定で制御されている場合もあります。管理画面の推測だけで設定を変更するのではなく、まずはブラウザの開発者ツールで実際のレスポンスヘッダーを確かめるのが確実です。
noindexを読ませるURLをrobots.txtで遮断しない
feedを検索結果に出したくないとき、やってしまいがちな誤りが「robots.txtでfeedのURLをDisallow(巡回拒否)にしてしまう」ことです。
- noindex:検索エンジンに対して「検索インデックスに登録しない」よう指示する仕組み。
- robots.txt:検索エンジンのクローラーに対して「そのURLにアクセス(クロール)しない」よう指示する仕組み。
GoogleがHTTPヘッダーの noindex を認識するためには、クローラーが実際にそのURLへアクセスしてヘッダーを読み取る必要があります。robots.txtでクローラーの巡回を遮断してしまうと、noindex の指示がGoogleに届きません。その結果、他のWebページからのリンクなどを手がかりに、URLだけが検索結果に表示されてしまうことがあります。
feedの検索表示を制御したい場合でも、robots.txtで一括拒否するのではなく、Googleがアクセスできる状態を維持したうえで X-Robots-Tag: noindex を読み取らせるのが適切な手順です。詳しくは Googleの公式ガイド robots.txtの概要 を参照してください。
すでにブラウザの確認で意図したヘッダーが返っているなら、追加で設定を変更する必要はありません。もし検索結果にfeedの表示が残っている場合は、Googleが最後にページを取得した日時と、現在のレスポンスヘッダーの内容を照合してみましょう。
feedのサイトマップ送信は、最近の記事URLを伝える手段です
Search Consoleの「サイトマップ」機能にfeedのURLを送信できることについて、その目的と仕様上の範囲を整理しておきましょう。
サイトマップ送信の目的と限界
Search Consoleでは、一般的なXMLサイトマップ(sitemap.xml など)に加えて、RSS 2.0 や Atom 1.0 のfeedをサイトマップとして送信することができます。
ここで注意したいのは、「feedファイルそのものを検索結果に登録させること」と、「feedの中に記載されている記事のURLをGoogleに知らせること」は全く別の話だという点です。feedをサイトマップとして送信する目的は、Googleに新しく追加された記事のURLを検出してもらうためのヒントを提供することにあります。
ただし、通常のXMLサイトマップとサイト内の内部リンクが正しく機能していれば、追加でfeedを送信することがすべてのブログ運営者にとって必須というわけではありません。送信を行う場合は、feedの完全なURLが、Search Consoleで管理している対象プロパティの範囲(ドメインプロパティかURLプレフィックスか)に含まれているかを確認してください。
また、WordPressの標準的なfeedは、新しい投稿を一定件数まで配信する仕組みになっています(参考:WordPressのfeed、投稿の標準的な並び順)。そのため、過去に書いた古い記事のリライト情報がすべて即座にfeedへ掲載されるとは限りません。さらに、サイトマップの送信が成功したからといって、記載された記事が必ず即座にクロール・インデックス登録されるわけではない点にも留意が必要です。
サイトマップの仕様や扱いについては、Google検索セントラルの サイトマップの作成と送信 および サイトマップについて を確認してください。なお、Googleの旧sitemap pingエンドポイントは廃止されています(公式のお知らせ)。
送信時にエラーが表示された場合の確認ポイント
Search Consoleにfeedを送信した際、「取得できませんでした」などのエラーが表示されることがあります。
エラーが出たら、まずは対象URLと現在の応答を確認します。設定変更に進む前に、次の項目から原因の手がかりを探しましょう。
- URLの正確さ:入力したfeedのURLにスペルミスや不要なパラメータが含まれていないか。
- HTTPステータスとXMLの出力:ブラウザで直接feedのURLにアクセスし、404(Not Found)や500などのサーバーエラーにならず、正しいXMLデータが表示されるか。
- アクセス制限:BASIC認証やセキュリティプラグイン等によって、外部からのアクセスが遮断されていないか。
- Search Consoleの詳細メッセージ:管理画面に表示される詳細や最終取得日時を確認し、現在の応答と照らして原因を絞り込む。
feedの送信は記事のインデックス登録を保証する万能の解決策ではありません。記事が検索に登録されないことで悩んでいる場合は、feedの送信状況にとらわれず、記事そのもののURL検査結果やコンテンツ内容の確認に戻りましょう。
まずはfeedのURLと、表示されている理由を確認しましょう
Search ConsoleでfeedのURLを見つけると不安になるかもしれませんが、焦ってサイト全体の設定を変更したり、feedを停止したりする必要はありません。
まずは、次の小さなステップから確認を進めてみてください。
- 対象のURLを確認する:表示されているURLが「記事本文」なのか、それとも
/feed/などの「feed」なのかを確認します。 - 未登録の理由を照合する:Search Consoleのインデックス登録レポートで理由を確認し、購読用feedとして意図通りの未登録(noindexなど)であれば、そのまま維持します。
- 必要な場合だけレスポンスを確認する:feedの検索表示を止めたい場合や、意図した指定が返っているか確かめたい場合は、ブラウザの開発者ツールで
X-Robots-Tag: noindexを確認します。配信エラーがある場合は、HTTPステータスやXML応答も調べましょう。
記事本文のインデックス登録と、購読用feedの提供を切り分けて整理し、本当に必要な確認だけを落ち着いて進めていきましょう。

