WordPress記事が検索に出ないときは、本文を直す前に、公開ページが現在返しているnoindexを確認します。見る場所は、HTMLのrobots metaとHTTPヘッダーのX-Robots-Tagです。
Search ConsoleのURL検査には、Googleが前回取得した状態が表示される場合があります。設定を直したあとも、最終クロールが修正前なら古い結果は残ります。Search Consoleの取得結果と、いま公開URLが返している値を分けて調べるのが、この記事の手順です。
Search Consoleの取得日時を先に確認する
URL検査を開いたら、まず最終クロール日時を確認します。その日時が設定変更より前なら、画面のnoindex判定だけで「現在も問題が続いている」とは決められません。
先に公開ページを以下の方法で確認し、そのあとに「公開URLをテスト」の結果と照合します。URL検査画面の読み方は、「検出 – インデックス未登録」と表示されたときの確認手順でも整理しています。
ページソースでrobots metaを探す
- ログイン画面や編集画面ではなく、検索に出したい公開URLを開きます。
- ページ上で右クリックし、「ページのソースを表示」を選びます。対応ブラウザでは、MacはCommand＋Option＋U、WindowsやLinuxはCtrl＋Uでも開けます。
- ソース内で
name="robots"とname="googlebot"を探し、content属性にnoindexまたはnoneが含まれるか確認します。noneはnoindex, nofollowと同じ扱いです。
たとえば、次の行があれば、そのHTMLはnoindexを出しています。
<meta name="robots" content="noindex,follow">
<meta name="googlebot" content="none">どちらのmetaも見つからない、またはcontentにnoindexとnoneがなければ、HTML側では現在noindexを確認できません。ただし、HTTPヘッダーで指定されている可能性が残るので、そこで終わらず次も調べます。
curlでHTTPヘッダーとHTMLを分ける
以下はexample.comを使った例です。実際には、自分が管理する記事の公開URLへ置き換えます。Cookieやログイン情報、管理画面のURLは付けません。
リダイレクトをたどり、GETリクエストのHTTPヘッダーを表示します。
curl -sS -L --max-time 20 -D - -o /dev/null 'https://example.com/'出力に複数のHTTPレスポンスが並ぶ場合は、最後のレスポンスを読みます。X-Robots-Tagが無指定でnoindexまたはnoneを返す場合と、googlebot:に続いて同じ指定を返す場合を、Googleウェブ検索向けのnoindexとして扱います。
X-Robots-Tag: noindex
X-Robots-Tag: googlebot: noneotherbot: noindexやgooglebot-news: noindexだけなら、Googleウェブ検索全体のnoindexとは決めません。対象クローラーまで読んで区別します。
続いて、リダイレクト後のHTMLを取得してrobots metaを探します。
curl -sS -L --max-time 20 'https://example.com/' | grep -iE 'robots|googlebot'robotsという文字が出ただけでは、noindexがあるとは限りません。metaタグの名前とcontent属性まで読みます。HTMLの途中で改行され、コマンドの結果に出ないこともあるため、見つからない場合はブラウザのページソースでも確かめます。
-sSは通常の進捗表示を消しながらエラーを残し、--max-time 20は20秒で打ち切る指定です。curlがエラーを返した、最終HTTPステータスが200ではない、または判定対象のレスポンスを最後まで取得できていない場合は、「noindexなし」と結論づけません。
結果によって次の作業を変える
- HTMLにnoindexまたはnoneがある
- 現在の公開HTMLが検索除外を指定しています。本文のリライトより先に、WordPressとテーマの記事設定を確認します。
- X-Robots-Tagに対象クローラー向けのnoindexまたはnoneがある
- HTTP側で検索除外が指定されています。WordPress画面だけで原因を決めず、キャッシュやサーバー、配信設定も確認します。
- 両方になく、最終レスポンスが200
- 現在の公開ページについて、Googleウェブ検索向けのnoindex指定は確認できませんでした。ただし、インデックス登録を保証する結果ではありません。Search Consoleの取得日時を比べ、canonicalや内部リンク、本文内容へ進みます。
- 途中が301または302で、最終レスポンスが200
- 転送先のURLが確認対象です。最後のHTTPレスポンスと、リダイレクト後に取得したHTMLを調べます。
- 最終レスポンスも3xx、または401・403
- 判定対象を正常に取得できていないため、noindexの有無はまだ分かりません。Search Consoleの公開URLテストやサーバー側の応答確認を優先します。
- 5xx、タイムアウト、DNS・SSLエラー
- 先に配信エラーを解消します。公開ページを正常に取得できるようになってから、noindexを再確認します。
WordPress全体、Cocoon全体、記事個別の順で見る
最初はWordPress全体です。「設定」から「表示設定」を開き、「検索エンジンがサイトをインデックスしないようにする」が選ばれていないか確認します。WordPress公式の表示設定画面の解説によると、この項目を選ぶとrobots metaにnoindex、nofollowを出す仕組みです。公開ページ自体は閲覧できるため、「ブラウザで開けるから問題ない」とは判断できません。
次にCocoon全体を確認します。「Cocoon設定」のSEOタブでは、カテゴリ、タグ、各種アーカイブなど、ページ種別ごとのnoindexを設定できます。確認箇所はCocoon公式FAQのSEO項目にまとまっています。
最後に記事個別です。投稿編集画面のSEO設定にあるnoindex項目を確認します。個別記事だけに問題が出ているなら、ここが原因のことがあります。
設定を保存したあとは、編集画面の表示だけで済ませず、公開ページのソースとHTTPヘッダーをもう一度取得します。反映されなければ、ページキャッシュも確認します。
robots.txtはnoindex確認の代わりにならない
robots.txtでクロールを止めても、公開HTMLやHTTPヘッダーにnoindexがあるかは確認できません。Googlebotがページを取得できなければ、ページ側のnoindexも読めません。
Googleはnoindexの公式ガイドで、metaタグまたはX-Robots-Tagを使い、Googlebotがページへアクセスできる状態にするよう案内しています。robots.txt内のnoindex指定もサポートされていません。
2026年9月8日時点、このサイトの34記事では両方0件だった
2026年9月8日時点で、公開中の34記事について、HTMLのrobots metaと最終HTTPレスポンスのX-Robots-Tagを別々に確認しました。noindexが見つかった記事は、HTML側が0件、HTTPヘッダー側も0件でした。
ここから言えるのは、確認時点の公開ページがnoindexを返していなかったことまでです。Googleが各ページを登録済みか、今後登録するかまでは分かりません。Search Consoleに古いnoindex判定が残っている場合は、最終クロール日時と現在値のずれを疑います。
noindexがなければcanonicalと発見経路へ進む
HTMLとHTTPの両方にnoindexがなく、公開URLが200を返すなら、同じ確認を繰り返す必要はありません。次は、Googleへ別URLを正規版として伝えていないか、WordPressとCocoonでcanonicalを確認する手順に沿って公開ソースを調べます。そのうえで、関連ページから本文リンクがあるか、記事が検索意図に答えているかを確認します。
調査の順番に迷ったら、検索表示がないときに行った確認の一覧から、該当する項目へ進めます。noindexが見つからなかった場合は、Search Consoleの古い結果に引っ張られず、次の原因へ進みます。
コメント