送信されたURLにnoindexマークが付くエラーの直し方
「送信された URL に noindex マークが追加されています」。この文言を手がかりに検索して、ここへたどり着いた方に向けて書いています。画面に出ている表記が少し違っても、確かめる中身は変わりません。対象URLが数十件あると、どこから手を付けるか迷います。
先に答えを書きます。作業はURLの仕分けから始まり、行き先は2つしかありません。検索結果に出したいページなら noindex を消す。出さなくていいページならサイトマップから外す。同じURLに両方を施す必要はなく、むしろどちらか一方に決めることが直しそのものです。
エラーという言葉に身構えるかもしれません。ただ、サイトが壊れているわけではありません。
まず疑うのは、2つの指示の食い違い
まず「送信された」が何を指すのかを押さえます。Search Console ヘルプの「ページ インデックス作成レポート」は、レポートの絞り込みについて、「送信されたすべてのページ」は、Sitemaps レポートまたはサイト上の robots.txt から送信されたサイトマップ(またはサイトマップインデックス)に載っているURLだけを表示すると説明しています。同ヘルプは、「未送信のページのみ」はそうしたサイトマップに載っていないURLだけを表示するともしています。
つまり「送信された URL」は、あなたがサイトマップに載せたURLだと読めます。そこに noindex が付いている。片方の手で招いて、もう片方の手で追い返している状態です。そう読み替えると、直す方向は決まります。
noindex の指定方法は2通りあります。Google 検索セントラルの「noindex を使用して検索インデックス登録をブロックする」は、noindex ルールは <meta> タグまたはHTTPレスポンスヘッダーで実装すると説明しています。同ドキュメントは、HTTPレスポンスヘッダーの形式として X-Robots-Tag: noindex の例を示し、PDFや動画・画像ファイルのようにHTMLではないリソースにはレスポンスヘッダーが使えるとしています。
効き方も明記されています。同ドキュメントは、Googlebot がそのページをクロールしてタグまたはヘッダーを抽出すると、他のサイトからリンクされているかどうかに関係なく、Googleはそのページを検索結果から完全に削除すると述べています。
つまり noindex は、意図せず残っていても、指示として読み取られうるものです。だからこそ、最初にやるのは仕分けです。
仕分けの表:そのURLは、出したいのか出したくないのか
対象URLを1本ずつ、次の表に当てはめます。判断の軸は「検索から人に来てほしいか」だけです。
| URLの例 | 検索結果に出したいか | やること | やってはいけないこと |
|---|---|---|---|
| 商品ページ・記事ページ・サービス紹介 | 出したい | noindex を削除する。テンプレートのどこで付いているかを特定してから消す | サイトマップから外して逃げる。載せたい本命ページを一覧から消すと、代わりの申告手段が減る |
| フォーム完了(サンクス)ページ・検索結果ページ | 出したくない | サイトマップの生成設定で除外する。noindex はそのまま残す | noindex を消して「エラーだけ」を消す。出したくないページが検索結果に出てくる |
| 公開前の下書き・テスト用URL | 今は出したくない | サイトマップから外し、公開のタイミングで載せ直す | 放置する。公開時に noindex を消し忘れる原因になる |
| 判断がつかないページ | 保留 | まず noindex の出どころを調べる。意図して付けたのか、設定の副作用かで結論が変わる | 一括置換でまとめて消す |
1行目が、いちばん多いパターンです。本番公開のときに開発用の noindex を外し忘れる、あるいはSEO向けプラグインの設定変更で意図しない範囲に noindex が広がる。どちらも「出したいページに付いてしまった」側です。2行目は逆で、noindex 自体は正しく、サイトマップの生成ルールのほうが雑になっています。4行目に入るURLがあるなら、次の手順で出どころを先に確定させてください。
手順:noindex の出どころを突き止める6ステップ
推測でテンプレートを触ると、直したつもりで別のページを巻き込みます。実物で確かめます。
- エラー対象URLの一覧を取り出す。 Search Console で該当の項目を開き、URLの一覧を書き出します。テンプレートの種類ごとに1本ずつ、代表を選ぶだけでも十分です。
- URL検査に、代表の1本を貼る。 Search Console の上部にある検査窓にURLを入れます。まずは1本だけで構いません。
- 「公開 URL をテスト」を実行する。 修正した直後の確認では、こちらの実行結果を見るほうが行き違いが起きにくいはずです。
- 「クロールを許可」と「インデックス登録を許可」を分けて読む。 Search Console ヘルプの「URL 検査ツール」は、「クロールを許可」はGoogleがそのページをクロール(訪問)できるか、robots.txt のルールでブロックしているかを示す項目であり、これはインデックス登録を許可しているかどうかと同じではないと説明しています。同ヘルプは、インデックス登録を許可しているかどうかは「インデックス登録を許可」の値で示されるとしています。ここを1つの項目として読むと、原因の切り分けを間違えます。
- HTMLソースで
robotsのメタタグを探す。 公開されているページのHTMLを開き、noindexで検索します。<meta name="robots" content="noindex">が見つかれば、出どころはテンプレートかCMSの設定です。 - 見つからなければ、HTTPレスポンスヘッダーを疑う。 メタタグが無いのに noindex が効いている場合、
X-Robots-Tag: noindexがサーバーやCDNの設定で付いている可能性があります。ブラウザの検証ツールのネットワークタブで、そのURLのレスポンスヘッダーを確認します。
実際に1本通してみます。たとえば https://example.com/service/ がエラー一覧に入っていたとします。表の1行目なので、結論は「noindex を消す」です。手順3の実行結果でHTMLを開き、noindex を検索すると <meta name="robots" content="noindex,nofollow"> が1行だけ見つかった。ここまで来れば、直す場所はサービスページのテンプレートに絞られます。逆に手順5で何も出ず、手順6でヘッダーに X-Robots-Tag が見つかったなら、触るのはテンプレートではなくサーバー設定です。同じエラー表示でも、直す担当も直す場所も変わります。
つまずき所:robots.txt でブロックすると、noindex は読まれない
ここが、このエラーでいちばん多い遠回りです。「検索結果に出したくないなら、robots.txt でクローラーを止めればいい」。そう考えて Disallow を足すと、事態は悪くなります。
「noindex を使用して検索インデックス登録をブロックする」は、noindex ルールが有効に機能するには、そのページまたはリソースが robots.txt でブロックされていてはならないと明記しています。同ドキュメントは、noindex が効かない理由の1つとして、robots.txt ファイルがGoogleのクローラーからそのURLをブロックしているためタグを見られない場合を挙げ、その場合は robots.txt を編集してブロックを解除する必要があるとしています。
ページのインデックス登録レポート側の記述も同じ向きです。Search Console ヘルプは、Google検索から外したい場合、robots.txt はインデックス登録を避けるための正しい仕組みではなく、robots.txt のブロックを解除して noindex を使うことを求めています。
順番を間違えないでください。robots.txt でクロールを止めることは、この場面の解決策になりません。ブロックを外したうえで noindex を使う。それが公式ドキュメントの求めている形です。
直したあとの確認と、反映のタイムラグ
修正が効いたかどうかは、レポートの数字だけを見ていると分かりづらいものです。個別のURLで確かめる方法があります。
確認の起点は、手順3と同じ「公開 URL をテスト」です。手を入れたページから順に当てていくと、直した場所が効いているかどうかを1本ずつ切り分けられます。
もう1つ、覚えておくと無駄な調査を減らせる記述があります。同ヘルプは、検索結果は履歴や場所などさまざまな変数に左右されるため、インデックスされていてもすべての検索に出るわけではなく、Search Console がインデックス済みと示しているなら、検索結果に出てこなくてもインデックスされていて表示される資格があるとみなしてよいと述べています。自分で検索して出てこないことを、修正失敗の証拠と受け取らないための一文です。
反映の速さを、こちらで決めることはできません。Search Console ヘルプの「URL 検査ツール」は、Googleがまだ見たことのないURLについてインデックス登録をリクエストする場面で、インデックス登録には通常、数日かかるとしています。noindex を消した直後にレポートの表示が変わらない、ということもありえます。日数で見切るより、状態で見るほうが確実です。
| 見ている状態 | 読み方 | 次の一手 |
|---|---|---|
| URL検査の「公開 URL をテスト」で noindex が消えている | 修正自体は完了している | レポートの更新を待つ。同じURLを何度も検査し直さない |
| 公開URLのテストでまだ noindex が出る | 直した場所が違う、または別経路で付いている | 手順5と6をやり直す。メタタグとヘッダーの両方を見る |
| レポートのエラー件数が減らない | 対象URLが1本ではない可能性がある | 一覧を再確認し、テンプレート単位でまとめて直せていないか点検する |
| サイトマップ側を直したのにURLが残る | 生成設定の除外が効いていない | サイトマップのファイルを直接開き、そのURLが本当に消えているか見る |
表の1行目に当てはまるなら、待つのが正解です。手を動かしたくなりますが、追加の作業はたいてい別の問題を生みます。
よくある誤解:「エラーだから全部消すべき」ではない
最後に、この項目の性質について。一覧に挙がるURLのうち、フォーム完了ページや内部向けの一覧のように、そもそも検索結果に出す必要のないものは珍しくありません。件数をゼロにすること自体が目的になると、出したくないページの noindex を外すという逆向きの修正に走りがちです。
判断の基準は件数ではありません。そのURLを検索から見つけてほしいかどうか、それだけです。出したくないページなら、サイトマップから外して指示の食い違いを解消すれば、それで筋は通ります。
逆向きの期待も、ここで手放しておくと楽になります。Google 検索セントラルの「サイトマップについて」は、サイトマップは検索エンジンがサイト上のURLを見つける助けにはなるが、サイトマップに載せた項目すべてがクロールされインデックスに登録されることを保証するものではないと述べています。載せれば必ず出る、という道具ではありません。noindex を消したあとにサイトマップへ載せ直すのは、あくまで見つけてもらいやすくするためです。
noindex を消したのに検索結果からページが消えない、という逆向きの症状はnoindexを設定してもページが消えないときの確認手順で扱っています。サイトマップに載せていないURLが登録される側の話はサイトマップに送信していないURLがインデックスされたときの見方にまとめました。
出典
