サーチコンソールの除外を正しく診断しPV減少を防ぐ実務対処ガイド

サーチコンソールの「除外」を数字だけ眺めている限り、PVも収益も静かに削られ続けます。インデックス登録済みが数百URLなのに、除外が数千URL。LPやブログ記事が「noindexタグによって除外されました」「検出 – インデックス未登録」「クロール済み – インデックス未登録」に並んでいても、「とりあえず様子見」「全部インデックスさせればいい」という判断で時間だけが過ぎていく。問題は、どのURLが本当に危険で、どれは除外で正解かを切り分ける軸がないことです。

多くの記事は、Google Search Consoleの画面やGoogle公式ヘルプの文言をなぞり、「除外はエラーではない」「意図したnoindexなら問題なし」といった一般論で終わります。しかし現場では、ステージング環境のX-Robots-Tagが残ってキラーLPが検索結果から消えたり、WordPressテーマ変更でカテゴリ一式がnoindexになったり、重複コンテンツをnoindexで削除し過ぎてサイト全体の評価とアクセスが落ちるといった「教科書に載らない損失」が起きています。同じ“除外”でも、1日放置しても問題ないURLと、1時間の遅れがリードや売上に直結するURLが混在しているのに、それを判別する具体的な方法がほとんど語られていません。

この記事は、サーチコンソールの「ページのインデックス」レポートを、単なるエラーチェックツールではなく、インデックスさせる価値のあるURLを選別し、SEOとビジネス成果を守るための管理コンソールとして扱うための実務ガイドです。noindex、robots.txt、meta robots、canonical、リダイレクト、クロールとインデックスの違いを、HTMLやサーバー応答（HTTP/HTTPS、4xx/5xx）、クローラーの挙動まで踏まえて整理し、「今すぐ確認すべき危険パターン」「除外で正解なページ」「AI・ChatGPTで量産した記事がインデックスされない理由」をチェックリストとマップで可視化します。

この記事を読み進めることで、あなたは「除外をゼロにする」のではなく、「インデックスさせるべきURLだけを確実に有効にし、それ以外は意図して整理する」という運用に切り替えられます。その結果、不要なインデックス登録を削りつつ、検索結果で勝たせたいページの評価とアクセスを最大化できます。

セクション	読者が手にする具体的な武器（実利）	解決される本質的な課題
構成の前半（除外の整理、優先順位マップ、noindex・検出/クロール済み未登録、リニューアル時のリスク）	危険な除外を数分で特定できるチェックフロー、noindex/robots/canonical/リダイレクトの正しい使い分け、LPや重要記事を守る確認ルール	「どれから直せばいいか分からない」「設定ミスで検索結果とPVが急落する」状態からの脱出
構成の後半（ケーススタディ、低品質コンテンツ整理、技術トラブル、AI大量生成時代の運用）	実際にPVと収益を守った修正プロセス、サイト全体の評価を上げる除外活用法、自分とチーム用のサーチコンソール運用ガイド	「除外＝悪」という思い込みと場当たり的な対応をやめ、長期的に安定したアクセスと収益を維持する運用への転換

サーチコンソールの「除外」とは何か：エラーとの違いとSEOへの本当の影響
まず“放置OK”か“危険”かを切り分ける：除外URLチェックの優先順位マップ
noindexタグによって除外されました：原因の探し方とやってはいけない削除
「検出 – インデックス未登録」「クロール済み – インデックス未登録」の裏で起きていること
公式マニュアルが教えてくれない「リニューアル・ステージング環境」特有の除外リスク
実録ケーススタディ：除外トラブルがPV・収益を削った3つのパターンと復旧プロセス
除外ステータスを“ゼロにしない”運用：サイト全体の評価UPにつなげる考え方
robots.txt・サーバー応答・表示ツールでハマる技術的な除外トラブル
AI・ChatGPT時代のコンテンツ大量生成と「除外」：評価される記事と切り捨てられる記事
執筆者紹介

サーチコンソールの「除外」とは何か：エラーとの違いとSEOへの本当の影響

「除外」＝全部悪ではない：Google公式の意味と実務のギャップ

サーチコンソールのページのインデックスで「除外」が増えると、多くの担当者が「サイトが壊れた」と感じます。実務で何百サイトを見てきた感覚でいうと、除外の多くは“仕様どおり”で問題なし、一部だけが“事故”です。

Googleの定義では、「除外」は次のようなURLをまとめた箱です。

noindexやrobots.txtのルールにより、サイト側の意図で検索結果から外しているURL
リダイレクトや重複URLなど、Google側がインデックス不要と判断したURL
まだ評価が足りず、「検出 – インデックス未登録」「クロール済み – インデックス未登録」にとどまっているURL

ここでギャップが生まれます。

公式: 「仕様説明」が中心で、どれがビジネス上“致命傷”かまでは触れない
現場: 「除外」の中に問い合わせLPや収益ページが紛れ込んでいても気づきにくい

このギャップを埋めるには、数字を見る前に“中身”を見る癖をつける必要があります。

エラー / 有効 / 除外：サーチコンソール表示の整理とアクセスへの関係

まずはステータスの役割を、アクセスとの距離感で整理します。

ステータス	意味	アクセスへの影響の近さ
エラー	本来インデックスされるべきURLが登録できていない	直撃しやすい
有効	インデックス登録済み	検索結果に出る候補
有効（警告あり）	正常だが、改善余地あり	じわじわ効く
除外	意図または判断でインデックス外	中に“爆弾”が混ざりやすい

ポイントは、「エラー」よりも「除外」の方が危険なケースがあることです。

実際の相談で多いパターンは次の通りです。

上位表示していたブログ記事が、テーマ変更をきっかけに「noindexタグによって除外」に落ちた
ステージング用のX-Robots-Tagが残り、広告用LPがまとめて除外扱いになった

どちらも表示上は「エラー」ではないため、ダッシュボードを流し見していると見逃されやすいのが厄介です。

除外数字だけ追うと危険な理由：KPIの置き方を現場目線で見直す

セミナーでもよく出る悪手が、「除外の件数をゼロにする」をKPIにしてしまうやり方です。現場感覚でいうと、これは冷蔵庫の“要らない食材”まで全部鍋に放り込むようなものです。

除外をゼロに近づけようとして起きがちな失敗は次の通りです。

本来インデックス不要なURL（リダイレクト先、パラメータ付きURL、完了ページ）まで登録し、クローラーのリソースを浪費
低品質コンテンツまで「とりあえずインデックス」に戻し、サイト全体の評価を下げる
noindexを外すこと自体が目的化し、ビジネス貢献と切り離された運用になる

KPIを置くなら、次の指標の方が現場では役立ちます。

重要キーワードで狙うページの「有効（インデックス登録済）」率
問い合わせ・購入に直結するURLが、「除外」「検出 – インデックス未登録」に混ざっていないか
低品質ページをnoindex化した後の、重要ページの平均掲載順位・クリック数の推移

サーチコンソールはアクセスの“結果”を見るツールではなく、インデックス前後の“原因”を読むツールです。
数字の多寡より、「どのURLがどの箱に入っているか」に意識を切り替えると、除外レポートは一気に“怖い画面”から“改善マップ”に変わります。

まず“放置OK”か“危険”かを切り分ける：除外URLチェックの優先順位マップ

サーチコンソールの「除外」は、全部をゼロにする指標ではなく、仕分けリストです。
最初にやるべきは「どのURLをインデックスさせるべきか」を決め、そこから逆算して優先度を付けることです。

次のシンプルなマップを、Search Consoleの「ページ」レポートとAnalyticsのデータを並べて使ってください。

インデックス可否判断の優先度マップ（ざっくり版）

優先度	URLのタイプ	具体例	基本方針
S	収益直結・リード直結	LP、資料請求ページ、主要サービスページ	「除外」なら即原因調査・修正
A	検索流入を狙う記事	ブログ記事、オウンドメディアの解説コンテンツ	重要KWなら除外は原則NG
B	補助的コンテンツ	会社概要、採用、コラム一覧など	除外でも実害がなければ様子見可
C	システム・重複・管理用	リダイレクト、完了画面、フィルタ付きURL	意図的に除外しておく方が安全

この優先度を決めてから「noindex」「検出–インデックス未登録」など個別ステータスを見た方が、数字に振り回されません。

インデックスさせるべきURLの条件：キーワード・収益・導線から逆算する

「インデックスさせる価値があるページ」は、3つのどれかに当てはまるかで判断します。

キーワード価値が高いページ
- Search Consoleの「検索パフォーマンス」で、そのURLに紐づくクエリを確認
- 指名キーワード、ビッグ・ミドルキーワードでクリックを狙うページは、除外されていないか必ず確認
収益・リードに近いページ
- 問い合わせフォーム、見積もり、資料DL、会員登録など
- Analyticsや広告のコンバージョンでゴールに設定しているURLが「除外」になっていないかを優先チェック
- ここがnoindexやrobots.txtでブロックされると、財布に直撃します
導線のハブになっているページ
- カテゴリページ、タグページ、ランキング一覧
- 自分のサイト構造を紙に書き出し、「ここから多くのページへリンクしている中継点」は原則インデックス対象と考える

これらに該当するのに「noindexタグによって除外」や「クロール済み–インデックス未登録」が付いていたら、“危険寄り”のシグナルです。

すぐ確認すべき危険パターン：LP・ブログ記事・重要コンテンツが除外されていないか

現場でよく見る「やらかしパターン」は、Search Consoleを開いて5分あれば洗い出せます。

チェック手順のおすすめ順序

「ページ」→除外→フィルタでURLを絞り込み
- 例: /lp/ /campaign/ /blog/ /service/ を含むURLだけ表示
ステータス別に以下を確認
- noindexタグによって除外
  - meta robots、X-Robots-Tag、WordPressプラグインの設定ミスを疑う
- robots.txt によりブロック
  - /lp/や/form/配下がDisallowされていないか、サーバー上のrobots.txtを直接確認
- クロール済み – インデックス未登録
  - コンテンツが薄すぎないか、他URLとほぼ同じ内容になっていないかを目視でチェック

特に危険なのは、一時的なテストでnoindexやrobotsを掛けたLPを、そのまま本番で使い回してしまうケースです。
この場合、順位が付いていたページがある日を境に一気に検索結果から消えるので、検索トラフィックのグラフが「崖」になります。

「これは除外で正解」なページの具体例：リダイレクト・完了ページ・モバイル/AMPなど

一方で、むしろ除外しておく方がサイト全体のSEOにプラスになるページもあります。
インデックスさせる価値がないURLを整理することで、クローラーのリソースと評価を重要ページに集中させられます。

除外しておく方が安心なURLの例

リダイレクト用URL
- 旧ページから新ページに301リダイレクトしているURL
- これらが「別URLとしてインデックス」されると、ランキングとリンク評価が分散する原因になります
完了ページ・サンクスページ
- thanks.html、/complete/のような送信完了画面
- 検索結果から直接アクセスされると計測が狂い、CV数が水増しされることもあるため、noindex, followが基本
サイト内検索結果ページやフィルタ付きURL
- ?s=キーワード ?sort=price_asc のようなパラメータ付き
- 無限に近いバリエーションが発生し、クロール予算を食い尽くすので、noindexまたはURLパラメータ設定で制御
モバイル専用 / AMPの旧構成
- 過去のm.example.comやAMP専用URLを運用している場合、
  正規URL側にcanonicalを向けつつ、サブ側はインデックス対象から外す設計も選択肢
  （現行仕様では、モバイルは基本レスポンシブ推奨）

ここで大事なのは、「除外」かどうかではなく、そのURLに検索結果から直接ユーザーが来てほしいかどうかです。
来てほしくないページは、noindexやrobots.txtで意図的に除外し、Search Console上で「除外」が増えても気にしない対象に分類しておきます。

この仕分けを一度やっておくと、「除外が数千URLあるけど大丈夫か」という不安が、「SとAランクURLは全部インデックスされているから問題なし」という確信に変わります。

noindexタグによって除外されました：原因の探し方とやってはいけない削除

「noindexタグによって除外されました」は、GoogleがそのURLを意図的に検索結果から外している状態を教えてくれるメッセージだ。
問題は「意図どおりの除外か」「事故でアクセスと収益を捨てていないか」を見抜けているかどうかだけ。

まず押さえるべき判断軸は次の3つ。

そのページは検索経由でお客さんを連れてきたいか
ビジネス上の導線（LP・問い合わせ・商品ページ）になっているか
noindexを付けた“記憶”が自分やチームにあるか

ここで「集客したいのに、誰もnoindexを設定した覚えがない」が1つでもあれば、事故案件として即調査に回す。

meta noindex / X-Robots-Tag / プラグイン：原因URLの探し方ガイド

同じ「noindex」でも、出どころが3系統ある。Search ConsoleのURL検査ツールだけを眺めていても、原因に辿り着けないケースが多い。

種類	確認方法	現場で多い落とし穴
meta robots noindex	ページのHTMLソース内 `<meta name="robots">`	テンプレート1カ所の設定ミスが全記事に波及
X-Robots-Tagヘッダー	開発者ツールのNetworkタブやcurlでHTTPヘッダーを確認	ステージング用noindexが本番サーバーに残存
CMS / プラグイン設定	WordPressやテーマの画面、SEOプラグインの個別設定	カテゴリ・タグだけ自動noindexになっている

原因特定のチェック手順はシンプルに3ステップで良い。

Search Consoleの「URL検査」で問題URLを入力し、「インデックス登録の有無」→「詳細」を開く
「metaタグによるnoindex」か「HTTPヘッダーによるnoindex」かを確認
HTMLソース / レスポンスヘッダー / CMS設定の3カ所を必ずセットで確認

よくあるのは、「HTMLにnoindexが無いから安全」と判断し、ヘッダー経由のX-Robots-Tagを完全に見落とすパターンだ。
テスト環境で全ページnoindexにしていたケースでは、本番移行後もヘッダー設定だけ残り、上位表示していたページが一斉に除外扱いになった事例も報告されている。

WordPress・ブログで多いnoindexトラブルと設定チェックリスト

ブログ運営者の相談で突出して多いのが、WordPress設定由来の除外だ。テーマ変更やSEOプラグイン導入を境に、カテゴリごと検索結果から消えるケースが典型例として挙がる。

最低限、次のチェックリストを1枚にまとめておくと事故を防ぎやすい。

一般設定
- 「設定」→「表示設定」→「検索エンジンがサイトをインデックスしないようにする」がオフか
SEOプラグイン
- カテゴリアーカイブ / タグ / 検索結果ページに自動noindexが入っていないか
- 投稿タイプ別（固定ページ・カスタム投稿）のデフォルトmeta robots
テーマ独自機能
- 「非公開」「検索結果に表示しない」チェックがmeta robotsに変換されていないか
キャッシュ・CDN
- すでにnoindexを外したのに、古いHTMLが配信され続けていないか

特に怖いのは、テーマ変更やステージングからのコピーで「検索エンジンがインデックスしないようにする」がいつの間にかオンに戻るケースだ。
Search Consoleで新規記事がいつまで経ってもインデックス登録されないときは、真っ先にここを疑う価値がある。

「重複コンテンツはnoindexで解決」はもう古い？canonicalとの正しい役割分担

いまでも「パラメータ違いのページは全部noindexで消す」という運用が見られるが、これは古い教科書だ。
noindexは「検索結果に出したくないページ」を消す道具であって、「どのURLを評価の本体にするか」を示す道具ではない。

役割分担を整理するとこうなる。

制御手段	役割	使うべきケース
rel=”canonical”	どのURLを正規の評価対象にするかを示す	商品ページの色違い・ソート違いなど、内容はほぼ同じだがアクセスさせたい場合
meta noindex / X-Robots-Tag	そもそも検索結果に出したくないURLを除外	完了ページ、社内専用ページ、テスト用URLなど
robots.txt Disallow	クローラーを入れないエリアを指定	管理画面、負荷の高いシステムディレクトリなど

重複URLを片っ端からnoindexにすると、内部リンクの「評価の通り道」まで一緒に塞いでしまうことがある。
ECサイトでパラメータ付きURLをすべてnoindexにした結果、カテゴリ一覧の評価が落ち、検索順位とアクセスが下がった事例も共有されている。

重複対策の方針は次の順で考えると失敗しにくい。

まず正規URLを1つ決めてcanonicalを設定
それでも「検索結果に不要」と判断したURLだけnoindex
クローラー自体を入れたくないエリアはrobots.txtでブロック

noindexは「ゴミ箱」ではなく、インデックスの質を高めるための精密ドライバーとして扱う意識が重要だ。

「検出 – インデックス未登録」「クロール済み – インデックス未登録」の裏で起きていること

Search Consoleの除外メッセージの中でも、この2つは「今すぐエラーではないが、放置するとじわじわSEOが痛む」ゾーンだと捉えた方がいい。表面的には同じ「除外」でも、Google側の内部ではまったく違うプロセスが走っている。

検出 – インデックス未登録：クロール予算・サイト構造と品質シグナルの関係

このステータスは「URLは知っているが、まだクロールする価値が高くない」と判断されているサインに近い。クローラーから見えているのは次のような情報だ。

視点	裏で見られているポイント
クロール予算	1日あたりのクロール可能回数に対してURLが多すぎないか
サイト構造	内部リンクが浅すぎないか、孤立ページになっていないか
品質シグナル	似たコンテンツが大量に存在していないか

現場でこのメッセージが増えるパターンは決まっている。

カテゴリーマップが整理されておらず、深い階層に記事を量産している
サイトマップに「テストページ」「タグページ」「薄いコンテンツ」を一緒に登録している
内部リンクがトップや主要カテゴリから届いていない

「検出」の段階は、まだクロールされていない。ここでやるべきは、URLを増やすことではなく、「このページは本当にインデックスする価値があるか」を1件ずつ見直すことだ。価値のある記事であれば、カテゴリページや関連記事リンクからしっかりリンクを張り、HTML上でもクローラーの経路を強化する。

クロール済み – インデックス未登録：コンテンツ評価・内部リンクの“静かな減点”

こちらは一段階重い。Googleは実際にページを取得して中身を読み、その上でインデックスを見送っている。

状態	Googleの心理に近い評価
クロール済み	コンテンツの内容は把握している
インデックス未登録	類似ページの方が優れている、または情報量が薄い

現場感覚で多いのは次のパターンだ。

AIで量産した解説記事が既存の上位ページとほぼ同じ内容
ブログで似たテーマの記事を何本も書き、キーワードが完全にかぶっている
重要キーワードで書いたつもりだが、内部リンクが弱くサイト内での「序列」が曖昧

ここで怖いのは、明確なエラーが出ないことだ。PVが落ちてもメッセージは「除外」のままなので、「とりあえず記事数を増やそう」と判断しやすい。結果として、クロール予算とコンテンツ評価が静かにすり減っていく。

対処の軸は3つに絞るといい。

ほぼ同じテーマの記事は1本の「決定版」に統合し、余分なURLはnoindexかリダイレクト
その決定版ページへ、カテゴリ・関連記事・TOPから内部リンクを集中
インデックスさせたいキーワードをタイトル、見出し、本文で一貫させる

いつまで様子見して、どこから対処するか：現場で使える判断ライン

除外ステータスは、変化のタイミングを読めば怖くない。現場で回しやすい判断ラインを整理すると次の通りになる。

期間・状況	ステータス	行動方針
新規公開〜2週間	検出 – インデックス未登録	サイトマップ登録と内部リンク付与までで様子見
2〜4週間継続	検出 – インデックス未登録	コンテンツの独自性と文字数、タイトルを見直す
4週間以降も継続	検出 or クロール済み – インデックス未登録	重要ページならURL検査から手動でインデックス登録をリクエスト
2カ月以上継続	クロール済み – インデックス未登録	近いテーマの記事を洗い出し、統合・リダイレクト・noindexを検討

特にビジネス上重要なLPや収益ページは、「2週間経ってもどちらかのステータスから動かない」時点で具体的に手を打った方がいい。Search Consoleのメッセージは、数字そのものより「変化のスピード」と「ページの重要度」を掛け合わせて見ると、対応の優先順位が明確になる。

公式マニュアルが教えてくれない「リニューアル・ステージング環境」特有の除外リスク

リニューアルやテーマ変更で一番事故が起きるのは、コンテンツではなく「インデックス制御」です。Search Consoleの除外レポートを見て青ざめるパターンは、ほぼ事前チェック不足で防げます。

一時的noindex/robots制限が本番に残る“設定の亡霊”シナリオ

ステージング環境では、検索エンジンに触らせないために次のような制限を置きます。

meta robotsのnoindex
X-Robots-Tagヘッダーのnoindex
robots.txtでDisallow: /
ベーシック認証

問題は、これを「本番公開時に戻し忘れる」ことです。実務の相談で多いのは、次の2パターンです。

サーバーレベルのX-Robots-Tagを外し忘れ、サイト全体が「noindexタグによって除外」
WordPress移行時に「検索エンジンがサイトをインデックスしないようにする」がオンのまま

チェックはHTMLソースを見るだけでは不十分です。必ずHTTPレスポンスとrobots.txtを合わせて確認します。

確認の優先順位を整理すると次の通りです。

チェック項目	場所	優先度	見るポイント
meta robots	HTML head	高	content=”noindex”が無いか
X-Robots-Tag	HTTPヘッダー	高	noindex, nofollowが無いか
robots.txt	/robots.txt	高	Disallow: / や重要ディレクトリのブロック
WP表示設定	管理画面	中	インデックス拒否チェックが外れているか
プラグイン設定	SEOプラグイン	中	一括noindexやカテゴリnoindex

「設定の亡霊」を消すには、本番公開チェックリストに上記を必ず入れ、誰がいつ確認したかを残すのが安全です。

HTTPS・HTTP / WWW切り替え時のリダイレクトと除外のよくある勘違い

プロジェクトでHTTPS化やwww有無の統一を行うと、Search Console上はURLが大量に動きます。この時に起きがちな勘違いが2つあります。

301リダイレクトされた旧URLの「除外」をエラーだと思い込む
HTTPプロパティ側だけを見て「インデックスが減った」と誤解する

実際には、301で正しく転送されていれば、旧URLが「リダイレクトのために除外」と出るのは正常です。重要なのは、正規URL側（https + 正しいホスト名）が「有効」でインデックス登録済みになっているかどうかです。

確認手順は次の流れが効率的です。

HTTP版URLをブラウザで開き、HTTPS版へ301で遷移するか確認
Search Consoleで「サイトマップ」「ページのインデックス」をhttpsプロパティ側で確認
URL検査ツールでhttps版を指定し、インデックス済みか、canonicalが自分自身かを見る

HTTP側やwww側の「除外」数値をゼロにしようとすると、過剰なnoindexやrobots.txt修正に走りがちです。評価すべきは、最終的な正規URL群のインデックス状況です。

リニューアル前後で必ず見るべきサーチコンソール画面とテスト手順

リニューアルでは、Search Consoleのどこを見るかを決めておくと、事故の早期発見率が一気に上がります。

リニューアル1〜2週間前に準備しておく画面

「ページのインデックス」レポートのスクリーンショット
重要LP・ブログ記事のURLリストとインデックスステータス
サイトマップ送信状況

本番公開直後のテスト手順は次の通りです。

代表URLでURL検査ツールを実行
- 「URLはGoogleに登録されています」か
- インデックスカバレッジが「有効」か
- robots.txtによりブロックされていないか
「ページのインデックス」で急増しているステータスを確認
- 「noindexタグによって除外されました」が急増していないか
- 「robots.txtによりブロック」が重要パスに出ていないか
- 「検出 – インデックス未登録」が一気に増えていないか
サイトマップを更新・再送信
- 新URL構造に合わせたXMLサイトマップを用意
- 特に収益に直結するLPやブログ記事を含める

リニューアルは、Search Consoleを「後から眺めるツール」ではなく、「事前比較と事後検証のための計測器」として使うと、除外トラブルの大半を未然に防げます。

実録ケーススタディ：除外トラブルがPV・収益を削った3つのパターンと復旧プロセス

Search Consoleの「除外」は、設定ミスが混じるとPVや問い合わせ数を一気に削ります。現場で共有されている代表的な3パターンを、時系列と復旧手順まで含めて整理します。

ケース1：ステージング環境のX-Robots-Tagが残り、キラーLPがnoindexになった例

新LPをリニューアル公開後、数日で問い合わせが半減。Search Consoleの「ページのインデックス」で該当URLを見ると「noindexタグによって除外されました」。HTMLソースにmeta noindexは見当たらず、原因不明という状態でした。

原因は、ステージング環境で使っていたHTTPヘッダーのX-Robots-Tag。サーバー設定が本番へコピーされ、キラーLPだけnoindexが応答されていました。

発見〜復旧の流れは次の通りです。

URL検査ツールで「公開URLをテスト」し、HTTPヘッダーのX-Robots-Tag:noindexを確認
サーバー設定から該当ディレクトリのヘッダーを削除
重要LPを優先して「インデックス登録をリクエスト」
数日で検索結果に復帰。ただしSearch Console上の「noindexによる除外」履歴はしばらく残存

このケースのポイントを整理します。

観点	内容
影響	メインLPの検索流入が数日〜数週間ゼロ
技術要因	X-Robots-Tagをステージングから本番に引き継ぎ
チェック漏れ	HTMLだけ見て「noindexは無い」と誤認
教訓	リリースチェックで「HTTPヘッダー＋meta robots」を両方確認するルール必須

ケース2：ブログのテーマ変更でカテゴリ一式が「noindexによる除外」になった例

WordPressブログでテーマ変更後、カテゴリページからのアクセスが急減。Search ConsoleではカテゴリURLがまとめて「noindexタグによって除外」と表示されていました。

実際には、SEOプラグインと新テーマの両方が「アーカイブをnoindexにする」設定を持っており、二重の設定でカテゴリ・タグ・検索結果ページが一括noindex状態になっていました。

現場での復旧フローは次の通りです。

WordPress管理画面の「表示設定」「パーマリンク設定」を確認
SEOプラグインの「カテゴリーをnoindexにする」チェックを確認
新テーマの独自SEO項目も確認し、重複するnoindex設定を片方だけに統一
カテゴリの役割を再整理し、収益記事へ誘導するカテゴリだけindexを許可

カテゴリごとの扱いを決めておくと、同じ事故を防ぎやすくなります。

URL種別	index/noindex	理由
収益記事を束ねる主要カテゴリ	index	検索結果からの入口として機能
雑記系・古い企画カテゴリ	noindex	キーワードがぼやけ、SEO評価を散らす
サイト内検索結果	noindex	重複コンテンツの温床になりやすい

ケース3：重複URLを片っ端からnoindexにして、検索評価が落ちたECサイトの例

パラメータ付きURLが多いECサイトで、「重複コンテンツ対策」の名目で片方のURL群を一括noindex。数週間後、カテゴリページと商品の平均順位が下落し、Search Consoleでは「クロール済み – インデックス未登録」が増加しました。

ヒアリングすると、以下の問題が重なっていました。

本来はrel=”canonical”で正規URLを示すべきところを、noindexで潰していた
内部リンクがnoindex側URLを指しており、評価が正規URLに集約されていなかった
サイトマップXMLにもnoindex対象のURLが多数残り、クローラーのリソースを浪費

そこからの立て直しは、次のステップで行われていました。

正規URLと重複URLを棚卸しし、「カテゴリ構造」と「フィルターパラメータ」を整理
重複URLのnoindexを撤去し、正規URLへcanonicalを設定
重要カテゴリと売れ筋商品の内部リンクを、正規URLのみ指すようテンプレートを修正
サイトマップからnoindex予定のURLを削除し、クロールを正規URLに集中

整理後、数週間かけてカテゴリ・商品ページのインデックスが安定し、検索順位も徐々に戻りました。

誤った対処	望ましい対処
重複URLをすべてnoindexで削除	正規URLを決めcanonicalで統一
noindex URLに内部リンクが集中	正規URLに内部リンクとサイトマップを集約
「除外URLを減らすこと」をKPIに設定	「売上に直結するページの評価を集める」ことをKPIに設定

3つに共通するのは、Search Consoleの「除外」を数字ではなくビジネス指標と結びつけて読むことです。どのURLが財布に直結するかを先に決め、そのページがnoindexやクロール制限で止まっていないかを優先的に確認する視点が、事故を最小限に抑えます。

除外ステータスを“ゼロにしない”運用：サイト全体の評価UPにつなげる考え方

Search Consoleの「除外」をゼロにする発想は、現場ではほぼ必ずどこかで破綻する。Googleは「インデックスする価値があるURLだけを検索結果に出したい」ので、サイト側も同じ視点でURLを整理した方が、長期的にはSEO評価と収益の両方が安定する。

低品質コンテンツをnoindexで整理したら、SERPとPVがどう変わるか

実務者の検証では、日記レベルの記事や重複度の高いページをnoindexに切り替えたあと、重要記事の平均順位がじわじわ改善したケースが報告されている。ポイントは「アクセスが少ないページ」ではなく、「検索エンジンから見て価値が薄いページ」を見極めることだ。

低品質コンテンツかどうかの判断軸は、次の3つが実用的だ。

検索キーワードが明確か（誰のどんな質問に答えているページか）
Googleからのアクセスが3〜6カ月ほぼゼロか
そのURLがなくなっても、導線や成約（問い合わせ・申込）に影響が出ないか

これらに当てはまり、内容をリライトする時間も割けないなら、思い切ってnoindexにする。クロール予算が薄いサイトほど、クローラーに「見てほしいページ」だけを渡した方が、インデックス済みページの評価が上がりやすい。

種類	代表的なページ例	推奨アクション
低品質コンテンツ	100〜200文字の日記、意味の薄いタグページ	noindex＋時間が取れれば統合
ビジネスに直結しない情報	古いキャンペーン告知、終了済サービス紹介	noindex＋アーカイブ化
コアコンテンツ	商品ページ、サービスLP、検索流入が多い記事	インデックス維持＋継続改善

「全部インデックスさせる」をゴールにせず、「インデックス一覧は“勝負ページのショーケース”」と捉え直すと判断がしやすい。

「とりあえずインデックスさせる」発想から、「インデックスさせる価値があるURL」思考へ

大量に記事を作成しているブログやAI活用サイトほど、「とりあえず公開してクローラーに任せる」運用に陥りやすい。Search Consoleで「クロール済み − インデックス未登録」が増えているなら、Google側から「このURLは検索結果に出す価値が薄い」と評価されているサインだ。

現場で使いやすい判定フローは次の通りだ。

① そのページ単体で検索ニーズがあるか
② 既存記事と内容が8割以上かぶっていないか
③ 内部リンクで他ページを支えている役割があるか

3つすべてに「はい」と言えるページだけを「インデックスさせる候補」とする。どれか1つでも「いいえ」なら、統合・リライト・noindexのいずれかを検討した方が、サイト全体の構造が引き締まり、クローラーの評価も安定する。

この発想に切り替えると、除外ステータスは「事故警報」ではなく「サイト設計のダメ出しシート」として活用できる。

チームで共有すべき運用ルール：公開前チェック項目と手動レビューのポイント

兼務でWebを見ている担当者ほど、「誰かがミスっても気づけない」状態になりやすい。Search Consoleの除外トラブルを減らすには、公開前チェックをルール化してしまうのが一番早い。

公開前に最低限見るべきチェックリストは次の通り。

meta robotsに意図しないnoindexが入っていないか
WordPressなら「検索エンジンがインデックスしないようにする」がオフか
重要LP・ブログ記事がrobots.txtでブロックされていないか
URLがリダイレクトやパラメータ付きURLに勝手に変わっていないか
内部リンクから、関連するコアコンテンツに最低1本はリンクしているか

加えて、月1回はチームでSearch Consoleの「ページのインデックス」レポートを開き、「除外が増えているタイプ」「インデックスが落ちた重要URL」を口頭で共有する。数字ではなく、実際のページを開いてレビューすることで、「これは除外で正解」「これは致命的」という感覚がメンバー間でそろい、忙しい時期でも危険な設定ミスを早期に検知できる。

robots.txt・サーバー応答・表示ツールでハマる技術的な除外トラブル

サーチコンソールの「除外」の中でも、robots.txtやサーバー応答が原因のものは、設定1つでアクセスと収益を一気に削る危険ゾーンになる。ここでは、技術寄りだが中小企業サイトやブログでも頻発しているポイントだけを絞って整理する。

robots.txtとmeta robotsの役割分担：クローラー制限が評価に与える影響

まず押さえるべきは、検索エンジンのクローラーに対する2つの指示の違い。

種類	設定場所	主な役割	Search Consoleで出やすいステータス	ハマりどころ
robots.txt	/robots.txt	クロール自体を許可/禁止	robots.txtによりブロック	noindexが読まれず「除外の原因が見えない」状態になる
meta robots / X-Robots-Tag	HTMLのmeta・HTTPヘッダー	インデックスしてよいかを指示	noindexタグによって除外	テーマ変更やステージングの設定が残り、意図せずnoindex

実務でやってはいけない組み合わせは1つだけある。

検索結果に出したくないページを、robots.txtでDisallowしつつmetaでnoindexを指定すること

この場合、クローラーはページに到達できないためmetaのnoindexを読めない。結果として「検索結果から消したいのに、古いキャッシュだけが残り続ける」「Search Consoleでは詳細が見えず原因不明に見える」という相談が多発する。

検索結果に出したくないだけなら、基本は「クロールは許可して、metaまたはX-Robots-Tagでnoindex」。サーバーへの負荷を本気で下げたい一部のパスだけ、robots.txtでブロックする方が安全だ。

4xx/5xxエラー・遅延レスポンスが「除外」に見えるときのデバッグ手順

トラフィックが落ち始めたタイミングで、「クロール済みだが現在はインデックス未登録」「探索済みのページ」などが増える背景に、サーバー側の小さなエラーやレスポンス遅延が隠れているケースも多い。

現場では次の順番で確認すると無駄が少ない。

WebサーバーログでHTTPステータスを集計
- 4xx(404,410等)が急増していないか
- 5xx(500,503等)が特定時間帯に固まっていないか
レスポンス時間の確認
- PageSpeed Insightsやサーバーモニタで、TTFB(最初のバイトまでの時間)が1秒を大きく超えていないか
リダイレクトチェーンの有無
- HTTP→HTTPS→WWWあり/なしの切り替えで、301が2回以上連続していないか

特に503(サービス一時停止)やタイムアウトが多いと、クローラー側の評価は「このURLは今アクセスしにくい」「優先度を落として様子を見る」になりやすい。Search Consoleのメッセージ欄に「サーバーからの応答が遅い」「一時的にアクセスできませんでした」といった警告が出ていないかも合わせて見ると原因特定が早くなる。

表示URL検査ツールでのテストの読み方：HTTPヘッダー・リソース制限の確認ポイント

URL検査ツールは、インデックス状況だけでなくサーバー応答とrobots設定の「現在値」を確認するためのデバッグツールとして使うと精度が一気に上がる。

確認ポイントは3つに絞るとよい。

「ライブテスト」でのHTTPステータス
- 200以外(301,302,404,500,503)になっていないか
「ページの取得」詳細
- robots.txtにブロックされていないか
- HTMLレスポンスヘッダーにX-Robots-Tag:noindexが付いていないか
「リソース」タブ
- CSSやJavaScriptがrobots.txtでブロックされ、モバイル表示が崩れていないか

HTMLソースだけ見て「meta noindexは無いから大丈夫」と判断しても、HTTPヘッダーでnoindexが返っていればSearch Consoleは「noindexタグによって除外」と判定する。URL検査ツールでレスポンスヘッダーまで確認する習慣を付けておくと、ステージング由来の設定ミスやセキュリティプラグインの制限がすぐ浮かび上がる。

AI・ChatGPT時代のコンテンツ大量生成と「除外」：評価される記事と切り捨てられる記事

AIで記事を量産すると、サーチコンソールの「クロール済み – インデックス未登録」「除外」が一気に増えた、という相談が増えている。Search Consoleは正直で、価値が薄いページはクロールしても検索結果に登録しない。AIコンテンツ運用は、ここを理解して設計しないと、SEOどころかサーバーとクローラーのリソースを浪費するだけになる。

量産コンテンツが「クロール済み – インデックス未登録」に陥りやすい理由

AI量産サイトで起きがちな構造を分解すると、除外の理由がはっきり見える。

キーワードの薄い差分量産
- 「◯◯とは」「◯◯ やり方」「◯◯ 方法」のように、狙う検索キーワードだけ変えて本文はほぼ同じ構成・表現のページを作成
- Google側から見ると、URLだけ違うほぼ同じコンテンツなので、クロール済みでもインデックスする意味がないと判断される
内部リンクとサイトマップの優先度設計がない
- すべての記事を同じレベルでリンクし、XMLサイトマップにも一律登録
- クローラーが「どのURLが重要か」を判別できず、クロール予算が薄く分散してしまう
体験情報ゼロのAI文章
- サーチコンソールのデータや自サイトのアクセスログを引用せず、どのページも同じような説明メイン
- 現場でしか書けない比較・失敗談がないため、評価アルゴリズムから見ると差別化シグナルに欠ける

AIによる量だけの拡張は、クロールはしても評価しづらい“ノイズ”をURL単位で増やしている状態に近い。結果として「クロール済み – インデックス未登録」が累積し、肝心のキラーページまでクロール頻度が落ちることがある。

AI記事をインデックスさせる前に見るべきチェックリスト（キーワード・重複・独自性）

AIで書いた記事をSearch Consoleに投げ込む前に、最低限のチェックを通すだけでも「除外」リスクは大きく下がる。運用担当者向けに、1記事ごとの確認ポイントを整理する。

【AI記事公開前チェックリスト】

キーワード設計
- そのページで狙う検索キーワードは1〜2個に絞れているか
- 既存記事とテーマが完全に被っていないか（自サイト内検索で確認）
重複・焼き直し度合い
- 同じ検索意図を狙う既存URLがあるなら、統合かリライトで済まないか
- AIが出したアウトラインが、既に上位表示ページと「見出し構造」レベルで酷似していないか
独自性・一次情報
- サーチコンソールの実データ（インプレッション推移、除外ステータスのスクリーンショット説明）を1つ以上盛り込んでいるか
- 自社サイト・自分のブログで実際に起きた問題と、そのときの修正手順を1ステップずつ書き起こしているか
- 失敗パターンとその理由を、自分の言葉で説明しているか
技術・メタ情報
- meta titleとmeta descriptionに、狙うキーワードが自然に入っているか
- 不要なnoindex・canonicalを付けていないか（テンプレートのコピーミスをHTMLソースで確認）
- 内部リンクで、「より強い関連ページ」からしっかりリンクを張っているか

このチェックを通すと、単なるChatGPTの自動生成文から、「サイト固有のデータ」と「運営者の判断」が混ざったページに変わる。Googleが評価しやすいのは、まさにこの「サイト固有成分」の濃さだと考えた方が動きやすい。

セミナーやマスター講座より役立つ“自分用ガイド”の作り方とLINE共有のススメ

Search Consoleの除外対策は、一度セミナーで聞いても、現場に戻った瞬間に細かい手順を忘れがちだ。実務で効くのは、チームや自分専用のミニ教科書を作り、すぐ取り出せる場所に置く運用だと感じている。

自サイト専用の「除外対処マップ」を作成する
- サーチコンソールに出ているステータスと、自サイトでの方針を表に落とす

インデックス除外ステータスと自サイト方針の例

ステータス例	基本方針	担当者のアクション
noindexタグによって除外	意図したnoindexかを毎月確認	LP・ブログ記事に紛れ込んでいないかをチェック
検出 – インデックス未登録	優先度中	内部リンク・コンテンツ量を見直し、重要URLだけ再インデックスリクエスト
クロール済み – インデックス未登録	優先度高	タイトル・本文の独自性を追加し、30日以内に状態再確認
robots.txtによりブロック	優先度最高	LP・フォームが含まれていないかを即確認し、設定を修正

このマップとチェックリストを、LINEや社内チャットにピン留め
- 夜中にブログを更新する副業ブロガーなら、自分だけのLINEグループを作り、「公開前チェック」「除外方針マップ」をメモとして保存
- 制作会社やマーケチームなら、SlackやChatworkの固定メッセージに貼り、テーマ変更やリニューアル時に必ず参照するルールを明文化
AIプロンプトもガイドに紐付けておく
- 「このキーワードで既存記事との重複がないか、サイト内検索結果も踏まえて提案して」といったプロンプトを、自分用のテンプレとして記録
- ChatGPTを“文章生成エンジン”ではなく、“構造チェックと重複監視のアシスタント”として使う意識を持つ

サーチコンソールの除外は、単発の対処より「自分のサイト向けルールを明文化して、いつでも見返せる状態」にした瞬間から、事故が激減する。AI・ChatGPT時代にコンテンツを量産するほど、この自分用ガイドの価値は上がっていく。

執筆者紹介

執筆者紹介はできません。