フィードURLの「インデックス未登録」を追いかけない基準
未登録の一覧を開いたら、半分以上が /feed/ で終わる URL だった。記事の本数より、未登録の件数のほうが多い。
結論を先に書きます。その行は、直す対象ではありません。公式ドキュメントも、このステータスについてクロールの再送信は不要だと書いています。手を動かすべきなのは、同じリストに混ざっている本命ページのほうです。
公式が書いているのは「クロールした・登録していない・再送信は不要」まで
Search Console ヘルプの「ページのインデックス登録レポート」は、「クロール済み - 現在インデックス未登録」をこう説明しています。Google がクロールしたが、インデックスしていない。将来インデックスされることもあれば、されないこともある。そして、このURLについてクロールの再送信は不要である。
ここが起点です。
同じレポートには「インデックス済み、ただし robots.txt によりブロックされています」という項目もあります。こちらの説明は対照的です。Google は robots.txt を常に尊重するが、他のサイトからリンクされている場合はインデックス登録を必ず防げるわけではない。Google はページをリクエストしてクロールすることはしないが、それでもインデックスすることはある、と書かれています。
二つの項目が並んでいることが、クロールとインデックスは別の工程だと示しています。片方が済んでいても、もう片方が自動的についてくるわけではない。だから「クロールされたのに登録されていない」という状態に、専用の名前が与えられています。
もう一つ、同じヘルプに実務で効く記述があります。Search Console がある URL をインデックス済みと言っているなら、自分の検索結果に出てこなくても、インデックスされていて検索結果に表示される資格があるとみなしてよい、というものです。検索結果は履歴や場所など多くの変数で変わるため、インデックスされていても毎回の検索に出るとは限らない、とも書かれています。
自分で site: 検索して見えないことは、未登録の証拠としては弱い。判断はレポート側の表示に寄せたほうが安全です。
/feed/ が並ぶのは、フィードが購読用のファイルだから
フィードは、記事の更新を配信するためのファイルです。人が読む HTML ページとは役割が違い、フィードリーダーや他のサービスが機械的に読み取ることを前提にしています。そしてこれは、たいていの場合 CMS が自動で作ります。
自分で作った覚えがないのは、そのためです。
WordPress を例にすると、サイト全体の /feed/、コメントの /comments/feed/、カテゴリやタグごとのフィード、記事ごとのコメントフィードが出力されます。記事を1本増やすと、フィードURLも一緒に増える構造です。だから記事30本のサイトで、未登録が300件を超えることもあります。
件数の多さは、サイトの規模ではなくURLの生成規則を映しています。
検索結果に出すために作られたファイルではないので、検索結果に出ていないこと自体は起こり得ることです。ただし、公式ドキュメントがフィードURLを名指しして扱いを説明しているわけではありません。ここはフィードの役割からの解釈であって、出典で確認できる部分ではない、と分けて考えてください。
確認できるのは、さきほどの一文です。再送信は不要。
未登録リストを仕分ける7つの手順
画面をスクロールして眺めても終わりません。数えて分ける作業に切り替えます。
-
Search Console の「ページ」レポートを開き、「クロール済み - 現在インデックス未登録」の行をクリックする。 対象URLの一覧が出ます。
-
一覧をエクスポートして、表計算ソフトか手元のシェルで扱えるようにする。 画面上で数えると、次に同じ作業をするときに再現できません。
-
URLパターンでフィード系に印を付ける。
/feed、/rss、?feed=、/comments/feed、末尾が.xmlの5パターンで、ほとんどが拾えます。手元での数え方は次のとおりです。grep -cE '/(feed|rss)/?$|\?feed=|\.xml$' urls.csv -
印の付かなかった行だけを残す。 ここからが本命候補です。件数がひと桁まで落ちることも珍しくありません。
-
本命候補を、送信しているサイトマップのURLリストと突き合わせる。 自分でインデックスさせたいと申告したURLが、未登録のまま残っているかどうかが分かります。
-
突き合わせで残ったURLを、URL 検査ツールにかける。 公式ヘルプも、レポートで問題が出たURLの調査にこのツールを挙げています。Google 側がそのURLをどう扱っているかは、ここで確認します。
-
対処するのは、この段階まで残った数件だけにする。 内容の見直しや内部リンクの追加は、ここに集中させます。
三番目で印を付ける作業が、実質的にこの手順の本体です。逆にいえば、そこが終われば残りは数件の話になります。
例：記事28本のブログで数えてみる
未登録リストが214件あったとします。手順3で印を付けると、フィード系が198件。残りは16件です。
16件を手順5でサイトマップと突き合わせると、申告済みのURLは6件でした。残る10件は、タグの一覧やページ送りのURLで、そもそも申告していません。
手順6で6件をURL検査にかけ、内容が薄い記事が3件、他の記事と内容がほぼ重なっているものが2件、公開直後のものが1件と分かりました。手を入れるのは前の5件です。最後の1件は待ちます。
214件が5件になりました。
URLの種類別・まず何をするか
| 未登録リストのURL | 正体 | まずすること |
|---|---|---|
/feed/、/comments/feed/ | サイト全体・コメントのフィード | 数えて外す（対処しない） |
/category/xxx/feed/ | カテゴリ別・タグ別のフィード | 同じく外す |
?feed=rss2、?feed=atom | クエリ形式のフィード | 同じく外す |
/wp-json/ 配下、末尾が .xml | API出力・サイトマップなど機械向けの出力 | 外す（サイトマップの状態は専用レポートで見る） |
/tag/xxx/、/page/3/ | 一覧ページ・ページ送り | 残す。中身の薄さを見て判断する |
| 記事・固定ページのURL | 本命 | ここだけ対処する |
上から四行目までが、さきほどの198件にあたります。一件ずつ開いて確かめる価値は薄い。
五行目は判断が分かれるところです。タグ一覧が未登録でも困らないサイトは多い一方、一覧から回遊が生まれているサイトでは残す理由があります。困っているかどうかで決めてください。
六行目だけが、最初の一覧で本当に見たかった行です。
どうしてもリストから消したいとき
「フィードURLの行そのものを消したい」という要望は、それでも出ます。ここで robots.txt に手を伸ばすと遠回りになります。
公式ドキュメントは robots.txt の役割を、サイト上のURLへのクローラーのアクセスを管理するもので、主な目的はサーバーへの過負荷を避けることだと説明しています。そのうえで、robots.txt は Google からページを隠すためのものではなく、隠したいのなら noindex かパスワード保護を使うと明言しています。
隠す道具ではない、ということです。
検索結果から落とすほうは noindex の担当になります。公式は noindex を <meta> タグまたは HTTP レスポンスヘッダーで実装するルールとして説明しています。Googlebot がそのページをクロールしてタグやヘッダーを取り出すと、他のサイトからリンクされているかどうかに関係なく、Google はそのページを検索結果から完全に落とす、という書き方です。
ここに条件が一つ付きます。noindex が有効に働くには、そのページやリソースが robots.txt でブロックされていてはいけない。公式は、noindex を入れたのに消えない原因として、robots.txt が URL をブロックしていてクローラーがタグを見られない状態を挙げています。
フィードは XML です。<head> がないので、<meta> タグを書く場所がありません。
残るのはヘッダー側です。ここから先は実装の話になります。
出典で確認できるのは、noindex を HTTP レスポンスヘッダーで実装できるというところまでです。ヘッダーの具体的な名前や書式、それを返す設定方法は、使っているサーバーや CMS のドキュメントで確認してください。実務では次のような形で書くことが多いはずです。
X-Robots-Tag: noindex
WordPress なら、フィードのリクエストだけを狙ってヘッダーを足す書き方が使えます。
add_action('template_redirect', function () {
if (is_feed()) {
header('X-Robots-Tag: noindex', true);
}
});
入れたら、実際にヘッダーが返っているかを確かめます。
curl -sI https://example.com/feed/ | grep -i x-robots-tag
同時に、robots.txt でフィードのURLを塞いでいないかも見ておきます。塞いだままだと、いま足したヘッダーが読まれない状態が残ります。
そのうえで、やる前に一度考える価値があります。noindex は検索結果に出さないための設定であって、レポートの件数を整えるための設定ではありません。入れたところで、未登録リストの行がすぐに消えるとも限りません。反映は Google 側が再びそのURLを読むタイミング次第になります。
件数を減らすことが目的なら、優先度は低い作業です。
つまずきやすいところ
フィードの出力をプラグインで止めてしまう。 レポートの件数は減りますが、フィードリーダーからの購読や、更新を受け取っている他のサービスとの連携も同時に切れます。代償のほうが大きい場面が多いはずです。
robots.txt で Disallow して終わりにする。 クロールが止まるだけです。公式は、robots.txt でブロックされていても、他のサイトからリンクされている場合にはインデックスされることがあると書いています。リストから消したいという目的に対して、確実な手ではありません。
robots.txt で検証ツールまで塞ぐ。 公式ドキュメントは Google-InspectionTool というユーザーエージェントについて、robots.txt のクロール設定が Search Console の検索テストツール、たとえばリッチリザルトテストや URL 検査に影響すると書いています。Google 検索そのものや他のプロダクトには影響しません。切り分けに使う道具を塞ぐと、確認の手立てが減ります。
robots.txt で守秘を担保しようとする。 公式は、robots.txt の指示に従わないクローラーもあるとしていて、情報を確実に守りたいのならサーバー上のファイルをパスワードで保護するなど別の方法がよいと書いています。フィードに限らず、非公開にしたいURLの扱いはここが分かれ目です。この順序については robots.txtでブロックしたページのnoindexが効かないとき でも扱っています。
本命ページの未登録をフィードのせいにする。 記事が登録されない理由は、フィードURLの件数とは別に立てて調べる話です。ステータス別の切り分けは インデックスされないページの原因を切り分ける にまとめています。
公開前の自己点検
作業を終える前に、次の5つを見てください。
- 未登録リストのうち、フィード系URLが何件・何割かを数えたか
- 印の付かなかったURLは何件残ったか
- そのうち、送信しているサイトマップに入っているURLは何件か
- 検索からの流入がほしいページが含まれていた場合、対処先はそのページの内容と内部リンクになっているか
- フィードに
noindexを入れるなら、robots.txt で同じURLを塞いでいないか
判断の目安を一つ置きます。未登録リストの8割以上がフィード系のURLで占められているなら、リストの件数そのものは追わず、残りの2割だけを見てください。8割を下回るようなら、一覧ページの量産やページ送りの作り方に別の原因が隠れている可能性があります。
数える対象を絞れば、未登録レポートは怖い画面ではなくなります。クロールの量そのものが気になってきた場合は 小規模サイトのクロールバジェット が近い話題です。
出典