WordPressのnoindex管理、どうするのがベストか
- 「インデックス対象の選択」機能――アーカイブページだけをnoindexにし、記事・固定ページには絶対に触れない安全装置
- なぜ何かを除外する必要があるのか
- 絶対的なルールを最初に決めた
- robots.txtではなくmeta noindexを使う理由
- 3度の試行錯誤を経て、現在の構成にたどり着いた
- ホームページ全体を除外することは絶対にない
- 将来作られるカテゴリーまで自動的にカバーする
- WordPressコアのis_tax()は、カテゴリーとタグを除くタクソノミーでのみtrueになるため、既存の設定と重複することはない。
- 以前の設定もそのまま引き継げるようにする
- 構成を3回も変更したということは、以前のバージョンですでに設定を保存しているユーザーがいるということでもある。
- noindex管理の結論
「インデックス対象の選択」機能――アーカイブページだけをnoindexにし、記事・固定ページには絶対に触れない安全装置
前回までの2回では、構造化データとmax-image-preview:largeについて取り上げた。
どちらも、「記事をどうすればより目立たせられるか」という話だった。今回はその逆で、「検索結果から何を外すべきか」という問題、つまりインデックス対象を選ぶ機能について扱う。
なぜ何かを除外する必要があるのか
WordPressは、基本的にかなり寛容な設計になっている。
日付別アーカイブ、タグアーカイブ、著者アーカイブ、検索結果ページまで、すべてインデックス可能な状態で公開される。
問題は、こうしたページの大半が実際のコンテンツではないことだ。「2026年6月」という日付アーカイブを開いても、その月に書かれた記事の一覧が並んでいるだけである。
私はこれを、コンテンツの品質シグナルが薄まる問題だと考えている。だからこそ、不要なページは明示的に除外しなければならない。
絶対的なルールを最初に決めた
この機能を設計するにあたって、最初に決めたのは「絶対に触れてはいけないもの」だった。
個別の記事と固定ページである。どのような設定の組み合わせでも、この2つをnoindexにすることはできない。
is_singular()で確認してtrueなら、その後にどのような設定値が入っていても無条件でそのまま通す。この早期リターンより前に実行されたり、これを回避したりできるコードは、ファイル内のどこにも存在しない。なぜここまで厳格にしたのか。私は、ここがSEOプラグインに起こり得る最も危険なミスのポイントだと考えている。
設定画面を誤って操作したり、複数のチェックボックスを組み合わせる途中で、誤ってすべての記事をnoindexにしてしまったという話を何度も聞いた。検索流入が一夜にしてゼロに近づく事故である。
復旧にも時間がかかる。私は、こうした事故が構造的に起こり得ない仕組みにしたかった。
そこで、オプションの値を検証するのではなく、「記事と固定ページは、このフィルター処理自体をスキップする」という方式にした。ユーザーがどのような設定をしていても関係ない。そもそも対象が異なるからだ。
この機能で扱える対象は、明確に限定している。
日付・月別アーカイブ、タグアーカイブ、著者アーカイブ、検索結果ページ、ホーム（ブログ一覧）の2ページ目以降、そしてユーザーが明示的に選択したカテゴリーアーカイブ。いずれも「一覧」ページである。実際に何かを作り出すページではなく、コンテンツを集めて表示するページを対象にした。
robots.txtではなくmeta noindexを使う理由
方式も慎重に選んだ。
クロールそのものを止めるrobots.txtではなく、<meta name="robots" content="noindex">タグだけを使う。
理由は、少し逆説的だ。robots.txtでブロックすると、Googleがそのページを再訪問できなくなる。
その結果、すでにインデックスされている問題のあるページが、かえってインデックスに残り続けるという逆説が生じる。
3度の試行錯誤を経て、現在の構成にたどり着いた
ここで、正直に話しておきたいことがある。現在の「種類ごとに3択1」の構成は、最初からこの形だったわけではない。3回作り直した。
最初のバージョンでは、ホーム・カテゴリー・タグ・日付・著者・検索を1つのチェックボックスにまとめて、一括でオン・オフできるようにしていた。実際に使ってみると、問題があった。ユーザーによって必要な範囲は異なるのに、種類ごとに個別指定できなかったのだ。
2番目のバージョンでは、Rank Mathの「Archive Subpages」機能を参考にして、6つのチェックボックスに分けた。すると、今度は別の問題が起きた。
日付・著者・タグ・検索の4種類では、「すべてをnoindex」と「ページネーションだけをnoindex」が、完全に別のチェックボックスとして存在していた。両方をオンにすると、後者のチェックボックスが何の効果もない、いわば死んだスイッチになってしまう。
すべてをすでにnoindexにしているなら、その中の2ページ目以降も当然含まれているからだ。ユーザーから見れば、2つのチェックボックスをオンにしたのに、片方が何の意味も持たないことを知る術がなかった。
現在の3番目のバージョンでは、「種類ごとに1つの設定」という原則で整理し直した。
日付、著者、タグ、検索には、それぞれラジオボタンで3つの選択肢を用意した。インデックスを維持する、すべてをnoindexにする、2ページ目以降だけをnoindexにする、の3つだ。1つの項目が3つの状態のうち1つしか取れないため、構造上、重複が発生しない。
2つのチェックボックスによる4通りの組み合わせのうち、1つが死んだスイッチになる問題そのものが、最初から起こり得ない構造に変えたのである。
ホームページ全体を除外することは絶対にない
カテゴリーは少し異なる方法で処理した。従来の「直接選択」方式は残し、その下に「選択していないカテゴリーは2ページ目以降だけをnoindexにする」というオプションを別途追加した。
一方、ホーム、つまりブログ一覧には、「すべてをnoindexにする」という選択肢自体を設けなかった。
用意したのは、2ページ目以降だけをnoindexにするオプションである。
この点を確認したうえで、選択肢そのものをなくすことにした。ユーザーが誤ってでも押せないようにするほうが、警告文を表示するより確実だと考えたからだ。
将来作られるカテゴリーまで自動的にカバーする
この機能を作った後、もう1つの盲点にも気づいた。
カテゴリーは「直接選択」したものにしか適用されなかった。そのため、新しいカテゴリーを作るたびに、管理者が設定画面を開いてチェックしなければならなかった。
このサイト専用のプラグインではなく、異なるテーマを使う複数のサイトで利用されることを考えれば、明らかな欠陥だった。
そこで、カテゴリーアーカイブにも、日付・著者・タグ・検索と同じ3択1の構成を追加した。
「すべて」または「ページネーション」を選べば、現在存在するカテゴリーだけでなく、今後新しく作成するカテゴリーにも自動的に適用される。カテゴリーごとに毎回チェックする必要はなくなる。
カスタムタクソノミーアーカイブも、5つ目の種類として同じ仕組みを追加した。
WordPressコアのis_tax()は、カテゴリーとタグを除くタクソノミーでのみtrueになるため、既存の設定と重複することはない。
カスタムタクソノミーが存在しないサイトでは、この設定自体が何の効果も持たない。
以前の設定もそのまま引き継げるようにする
構成を3回も変更したということは、以前のバージョンですでに設定を保存しているユーザーがいるということでもある。
私は、こうしたユーザーの設定がアップデート1回で突然変わることを望まなかった。
そこで、新しいコードが古いオプションキーを読み取り、自動的に新しい形式へ変換するようにした。
「すべて」と「ページネーション」の両方がオンになっていた、まさに試行錯誤の途中にあったユーザーについては、「full」として整理した。
実際の本番環境ですでにすべてをnoindexにする動作になっていたため、移行によって配信結果が突然変わらないようにしたのである。
保存ボタンを1度押せば新しいスキーマで再保存され、それ以降は古いキーが使われることはない。
noindex管理の結論
インデックス対象を選ぶ機能は、派手な新機能ではない。
検索結果に表示する必要のない一覧ページを正確に選び、除外するための、基本的ではあるが、誤ると致命的になり得る機能である。
私はこの機能を作るにあたり、2つのことを絶対的な原則とした。
次回はrobots.txtとmeta noindexの違いをさらに掘り下げ、すでにインデックスされているページを実際に検索結果から外すにはどうすればよいのか、その正しい方法を取り上げる。
この記事ではDECOBLOCKSプラグインが適用されています。