WordPressサイトを運営する上で、検索エンジンのクローラーがホームページを巡回する上限枠であるクロールバジェットをどのように管理し、重要なページへと集中させるかは、検索エンジン最適化(SEO)の成否を分ける極めて重要なテーマです。クロールバジェットの基本構造やホームページ運用における全体像については、「クロールバジェット SEO・ホームページ運用における全体像」にて詳しく解説していますが、外部からのスパム攻撃や投稿削除後の添付ファイルページ残存問題と並んで、日々の運用の中で静かに、しかし確実にクロールバジェットを圧迫し続けているのが、WordPress(および同様の動的生成機能を持つCMS)が自動的に生成する各種の「アーカイブページ(一覧ページ)」の存在です。
ホームページの運営者が専門知識を込めた記事を1本公開するたびに、WordPressの裏側ではその記事本体のURLだけでなく、年別、月別、日付別、著者(投稿者)別、カテゴリー別、タグ別といった無数の切り口による一覧ページのURLが自動的に生成されていきます。もし、これらの自動生成される派生URLに対して何の制御も行わないままホームページの運用を続けていると、実際の記事数は数百本程度であるにもかかわらず、検索エンジンのクローラーが巡回しなければならない総URL数はその数倍から十数倍にあたる数千ページ規模へと膨れ上がってしまいます。
かつてのようにインターネット上の情報量が限られており、検索エンジンが発見したほぼすべてのURLを寛容にクロールしてデータベースへ登録していた時代であれば、こうした自動生成ページの放置も決定的な致命傷にはならなかったかもしれません。
しかし、生成AIの普及などによってウェブ上のページ数が爆発的に増加した現在、Googleをはじめとする検索エンジンは自らの計算資源(コンピューティングリソース)を厳格に管理する方針へと完全に移行しており、価値の低いページや重複ページを多く含むホームページに対しては「すべてのURLをクロールしない」という厳しい選別を行うようになっています。
さらに、一般的なSEO対策としてよく知られる「不要なアーカイブページへのnoindexタグの設定」を行っただけでも、この問題は解決しません。なぜなら、クローラーはそのページにnoindexが書かれていることを確認するために結局アクセスしなければならず、ホームページ内のサイドバーや記事上部に自動出力される内部リンクが残っている限り、クローラーは不要なアーカイブページを巡回し続けてクロールバジェットを消費し続けるためです。
今回は、検索エンジンの計算コスト管理やホームページ全体の専門性(ベクトル重心)の評価という最新のアルゴリズム視点から、なぜWordPressの自動生成アーカイブがSEOの足を引っ張るのかという技術的な背景を紐解き、年別・月別・日付・著者・タグアーカイブの整理方針、そしてテーマが自動生成する内部リンクの削除やテンプレート改修によってクローラーの無駄な巡回を根本から遮断する実践的な手法までを詳しく解説します。
検索エンジンの計算コスト管理とWordPressの自動生成アーカイブが招く構造的課題

WordPressのアーカイブ設定や内部リンクの改修といった具体的な実務に入る前に、まず理解しておくべきなのが「なぜ現在の検索エンジンは、ホームページ内の不要な一覧ページの放置に対してこれほどまでに厳しい評価を下すようになったのか」という検索エンジン側の事情です。そこには、クローラーの通信コストだけでなく、インデックスとランキングの裏側で動く膨大な計算処理のコストと、ホームページ全体の専門性を測る評価モデルの変化が深く関わっています。
すべてのURLを無条件にクロールしない時代の計算資源(コンピューティングリソース)管理
検索エンジンがインターネット上のホームページ(ウェブサイト)を見つけ出し、検索結果に表示するまでには、多段階の重い処理が行われています。多くの運営者は「クローラーがHTMLテキストをダウンロードするだけなら、それほど大きな負荷にはならないのではないか」と考えがちですが、現在の検索エンジンが1つのURLを処理する際にかかる計算コストは、過去とは比較にならないほど増大しています。
AIによる記事量産時代における検索エンジンの防衛策とクロール選別
近年、生成AIの急速な普及によって、世界中のホームページで毎日天文学的な数のテキストやページが機械的に量産されるようになりました。検索エンジンを運営するGoogleなどの企業にとって、世界中のサーバーからデータを取得する通信帯域、取得したページを仮想ブラウザ上で組み立てるレンダリング用のCPU・メモリ資源、そして解析したデータを保持し続ける巨大なストレージ(データベース)は、すべて莫大な電力と資金を消費する有限の物理リソースです。この計算コストの問題と検索エンジンのリソース管理の仕組みについては、検索エンジンの計算コストとベクトル重心の判定構造|URL・titleの優位性と滞在時間の誤解を解くSEO設計 で触れています。
現在の検索エンジンは自らのインフラコストを守るため、「発見したすべてのURLをクロールするのではなく、クロールする価値があるホームページの、価値があるURLだけを選んで計算資源を投下する」という極めてシビアな選別を行っています。もし、ある事業用ホームページにアクセスしたクローラーが、巡回しても巡回しても「2024年3月の記事一覧」「2024年3月15日の記事一覧」「タグ:お知らせの一覧」といった、同じ記事のタイトルと抜粋文が並び替えられただけの自動生成アーカイブばかりに遭遇したとします。すると検索エンジンのスケジューラーは、「このホームページを巡回しても、既存の情報の焼き直し(重複データ)ばかりで新しい有益な情報が得られないため、ここに計算コストを割くのは非効率である」と判定し、ホームページ全体に対するクロールバジェットの割り当て枠そのものを冷徹に削減してしまいます。
HTMLの取得からレンダリングおよびインデックス格納に至るコスト構造
さらに、WordPressのアーカイブページが検索エンジンに強いる計算コストの内訳を分解してみると、問題の大きさがより明確になります。クローラーが1つの月別アーカイブページにアクセスした際、ただ数キロバイトのHTMLテキストだけを読んで帰るわけではありません。その一覧ページがどのように画面上に表示されるかを確認するため、共通のCSSやJavaScript、ヘッダー画像、さらには一覧に並んでいる10件や20件の記事それぞれのアイキャッチ画像のサムネイルファイルなど、多数のサブリソースの読み込みとレンダリング処理が発生します。
また、検索エンジンはその一覧ページをインデックスに登録すべきか、それとも重複ページとして除外すべきかを判定するために、ページ内のテキストを抽出して既存のインデックスデータと照合する重複排除(デデュプリケーション)の計算を行わなければなりません。つまり、不要なアーカイブページをホームページ内に何千ページも放置しておくことは、検索エンジンに対して「何の価値も生まない重複確認とレンダリングの計算コスト」を一方的に押し付けている状態であり、結果として本当に評価してほしい新規記事や主力サービスページのクロールおよび再評価が後回しにされる直接の原因となります。
ホームページ全体のベクトル重心(専門性の純度)を乱す低品質な一覧ページの弊害
検索エンジンの計算コストと並んで、自動生成アーカイブの放置がもたらすもうひとつの深刻な悪影響が、自然言語処理およびベクトル検索モデルにおける「ホームページ全体の専門性評価(ベクトル重心)の希釈とブレ」です。
文脈の異なる記事が時系列で混在するアーカイブがトピックの輪郭をぼやかす理由
現在の検索エンジンは、ページ内の文章を単なるキーワードの出現頻度(単語の一致)だけで見ているのではなく、文章全体の意味を高次元の数値データ(ベクトル)へと変換し、そのページが「どの専門領域の、どのような概念について深く語っているか」を空間上の座標として計算しています。そして、ホームページ内に存在するすべてのページのベクトルを集約した中心点(ベクトル重心)を算出することで、「このホームページはWeb制作とSEOの専門サイトである」といったドメイン全体の専門性(トピックオーソリティ)を判定しています。このベクトル重心と計算コストの関係性についても、先述の AIによる記事量産時代と「すべてのURLをクロールしない」Googleの計算資源管理 にて詳しく掘り下げています。
ここで、WordPressが自動生成する「月別アーカイブ」や「日付別アーカイブ」、あるいは単一運営サイトにおける「著者アーカイブ」の中身を考えてみます。適切に設計された「カテゴリーアーカイブ」であれば、たとえば「WordPressの保守・トラブル解決」という明確な単一テーマに属する記事群だけが集まっているため、その一覧ページ自体も明確なトピックの方向性(ベクトル)を持ちます。 しかし、「2025年8月の記事一覧」という月別アーカイブには、その月に公開された「サーバー移転の技術解説」「夏季休業のお知らせ」「SEOの期間に関する考察」「デザインの配色理論」といった、本来であれば別々のカテゴリー(異なる意味空間)に属するはずの記事のタイトルと抜粋文が、「たまたま同じ月に投稿された」というだけの理由でごちゃ混ぜになって1ページ内に羅列されます。
このような「意味的なまとまりを一切持たない断片的なテキストの寄せ集めページ」がホームページ内に何百、何千と生成され、クローラーに読み込まれていると、検索エンジンがホームページ全体のトピック構造やベクトル重心を解析する際の巨大なノイズ(雑音)となります。個別の記事をどれほど論理的に書き分けてトピッククラスターを構築していても、時系列アーカイブや雑多なタグアーカイブがそれらを無秩序にかき混ぜたページを大量に出力し続けていれば、ホームページ全体の情報純度は著しく損なわれてしまいます。
SEO効果が現れるまでの期間を引き延ばすアーカイブ巡回のタイムロス
また、クローラーがこうした大量のアーカイブページと、そこから派生するページネーション(2ページ目、3ページ目など)の巡回に時間を奪われることは、SEO施策の成果が出るまでのスピードにも直結します。SEO対策を行ってから実際に検索順位の上昇などの効果が現れるまでには数ヶ月程度の期間を要しますが、その期間の仕組みについては SEOの効果が出るまでの期間は?「4ヶ月〜1年」の定説とサイト規模ごとの本当の目安 で解説している通り、改善したページ群がクローラーに一通り再巡回され、ドメイン全体の評価が再計算されるまでの物理的な時間が大きく影響しています。 もしホームページ内の総URL数の7割〜8割が不要なアーカイブページで占められていれば、クローラーのリソースの大半がその無駄な迷路の探索に消えてしまい、肝心の記事本体の再評価が完了するまでの期間が何倍にも引き延ばされてしまいます。検索エンジンの計算コストを節約し、自社の正規コンテンツの解析だけに100パーセントの計算資源を使ってもらう環境を作ることこそが、現代のテクニカルSEOにおける核心的なアプローチです。
WordPressの自動生成アーカイブによるクロールバジェットの消費と重複コンテンツの実態
ここからは、WordPress(および同様のアーキテクチャを持つCMS)が具体的にどのような種類のアーカイブページを裏側で自動生成し、それがどれほどの規模のURL増殖を引き起こしているのか、その実態を数値と仕様の両面から詳しく検証していきます。記事を1本公開するたびに、その裏側でどれだけの数の派生URLが生み出され、クローラーの巡回枠を奪っているのかを正確に把握することが、適切な制御を行うための第一歩となります。
1つの投稿から派生する無数のアーカイブURLと組み合わせ爆発の仕組み
WordPressはもともと個人の日記やブログを手軽に公開するためのシステムとして発展してきた歴史があるため、初期設定のままでも投稿された記事をあらゆる角度から自動的に分類し、一覧ページを生成するルーティング機構(WP_Rewrite)が標準で組み込まれています。具体的には、「カテゴリー別アーカイブ」「タグ別アーカイブ」といった分類軸に加え、「年別アーカイブ(2025年など)」「月別アーカイブ(2025年8月など)」「日付別アーカイブ(2025年8月15日など)」といった時系列軸、さらには記事を作成したログインユーザーごとの「著者(投稿者)別アーカイブ」が自動的に生成されます。
時系列アーカイブ(年別・月別・日付別)が機械的に生み出すページ数の試算
これらの自動生成アーカイブがクロールバジェットに与える影響を、具体的な運用年数と数字でシミュレーションしてみます。たとえば、ある事業用ホームページで3年間、毎日欠かさず記事や新着情報を1本ずつ更新し続けたとします(記事本体の数は約1,095記事となります)。 このとき、時系列のアーカイブ機能だけでも、まず「年別アーカイブ(/2024/、/2025/、/2026/など)」が3ページ生成され、「月別アーカイブ(/2024/01/〜/2026/12/)」が36ページ生成され、そして「日付別アーカイブ(/2024/01/01/〜/2026/12/31/)」に至っては、記事を公開した日数分、すなわち約1,000ページ以上が自動的に生成されます。記事を1本投稿するたびに、その日の「日付別アーカイブ」という新しいURLが必ず1つ道連れとして作り出されている計算になります。
ページネーション(/page/2/以降)とフィードURL(/feed/)による二次的な増殖
さらに恐ろしいのは、URLの増殖がこれらのアーカイブの1ページ目だけでは終わらないという点です。WordPressの標準設定では、1つの一覧ページに記事が10件以上並ぶと、自動的に11件目以降を表示するための「/page/2/」「/page/3/」といったページネーション(分割ページ)のURLが枝分かれして生成されていきます。 先ほどの3年間で1,000記事を公開した例でいえば、年別アーカイブ(1年あたり約365記事)にはそれぞれ「/page/2/」から「/page/37/」までのページネーションが生成され、これだけで約110ページが増えます。月別アーカイブ(1ヶ月あたり約30記事)にもそれぞれ3ページ分のページネーションが生成されて約100ページが増え、同様にブログ全体の一覧、各カテゴリー一覧、各タグ一覧、そして著者アーカイブのすべてにおいて、記事数に応じた大量の「/page/N/」というURLが派生します。
しかも、WordPressはそれぞれのカテゴリーアーカイブやタグアーカイブ、著者アーカイブのURLの末尾に「/feed/」を付与した個別のRSSフィード用URLまで自動生成し、HTMLのヘッダー内やリンクに出力する仕様を持っています。その結果、もしホームページ全体の正規の記事数が500記事程度であったとしても、年別・月別・日付別アーカイブや著者アーカイブ、細かく付けすぎたタグのアーカイブ、そしてそれらのページネーションやフィードURLをすべて合算すると、記事本体の数倍から十倍近くにあたる数千ページもの「一覧・派生URL」が裏側で自動的に作り出されているケースは決して珍しくありません。
検索意図を満たさない時系列アーカイブと単一運営ホームページにおける著者アーカイブの無意味さ
このように数千ページ規模で自動生成されるアーカイブページですが、検索エンジン最適化(SEO)およびユーザーの利便性という観点から見たとき、その大部分は存在意義を持たないばかりか、ホームページの評価を毀損する重複コンテンツとして機能してしまいます。
カテゴリーページと時系列アーカイブにおける検索需要と存在意義の決定的な違い
自動生成されるアーカイブページの中で、事業の専門分野やサービスの体系に沿って論理的に設計された「カテゴリー別アーカイブ」は、例外的に重要な価値を持っています。ホームページを訪れた見込み客が「SEO対策に関する記事だけをまとめて読みたい」「WordPressの不具合解決事例を探したい」と考えた際、カテゴリー一覧は目的の情報へ辿り着くための優れた案内板となり、また検索エンジンにとっても、どの記事とどの記事が同じトピッククラスターに属しているかを理解するための重要な構造的シグナルとなるためです。 しかし、それ以外の時系列アーカイブ(年別・月別・日付別)はどうでしょうか?
たとえば、検索エンジンの検索窓にキーワードを打ち込む一般のユーザーの中で、「あの会社のホームページで2024年5月に公開された記事の一覧が見たい」とか「2024年5月12日に投稿された記事一覧を探そう」という検索意図(インテント)を持って検索するユーザーは皆無といえます。 検索需要がゼロであるにもかかわらず、クローラーがそれらの月別・日付別アーカイブにアクセスすると、そこにはトップページの新着一覧やカテゴリー一覧ですでに表示されている記事のタイトル、アイキャッチ画像、冒頭の抜粋文(または全文)が、ただ「公開された日付順」という別の切り口で並び替えられて表示されているだけの、100パーセント完全な重複コンテンツが横たわっています。特に日付別アーカイブなどは、1日に1記事しか公開していないホームページであれば、「その日に書いた1記事の抜粋だけがポツンと1件だけ載っている極めて内容の薄い一覧ページ」が、記事を公開するたびに1日1ページずつ量産されていくことになります。これは、本体記事に対する低品質なコピーページを自ら毎日作り出しているのと同じ状態です。
少人数運営の事業用ホームページで著者アーカイブが100パーセント重複ページになる理由
また、盲点になりやすいのが「著者(投稿者)アーカイブ(/author/ユーザー名/)」の存在です。たとえば、数十人の医師や弁護士、アナリストといった異なる分野の専門家がそれぞれ実名で署名記事を寄稿しているような大規模な専門メディアであれば、「どの専門家が執筆した記事の一覧か」を示す著者アーカイブは、E-E-A-T(経験・専門性・権威性・信頼性)を証明するプロフィール兼一覧ページとして明確な意味を持ちます。
しかし、代表取締役1人、あるいは社内のWeb担当者や少数のスタッフだけで全ての記事を作成・公開している一般的な事業用ホームページにおいては、管理画面の同じ1つのアカウント(たとえば管理者アカウント)で全ての記事が投稿されています。
この状態で著者アーカイブが生成されると、「ホームページ内のすべての記事が時系列で並ぶブログトップ(投稿一覧ページ)」と、「その1人の管理者が投稿したすべての記事が時系列で並ぶ著者アーカイブページ」の2つが、1ページ目から最後のページネーション(たとえば /page/50/ )に至るまで、1文字違わぬ完全な同一内容(100パーセントの重複ページ群)としてホームページ内に2セット並存することになります。
さらに技術的なセキュリティの観点から補足すると、WordPressの標準仕様では、著者アーカイブのURLスラッグには管理画面へのログインに使用する「ユーザー名(ログインID)」がそのまま出力されます。著者アーカイブを有効のまま放置し、内部リンクを張っていると、外部の攻撃者にログインIDを簡単に知られることになり、パスワード総当たり攻撃(ブルートフォースアタック)の標的になりやすくなるという防犯上の弱点まで抱え込むことになります。
無計画なタグ(post_tag)の乱造が引き起こす低品質ページの増殖
時系列アーカイブや著者アーカイブと並んで、多くのWordPressサイトでクロールバジェット枯渇の最大の原因となっているのが、記事投稿時に付与する「タグ(post_tag)」の無計画な運用です。
SNSのハッシュタグ感覚でタグを付与する運用が招く1記事のみのタグ一覧ページ
ホームページの運営担当者の中には、WordPressの「タグ」機能を、SNS(XやInstagramなど)のハッシュタグや、かつてのメタキーワード(meta keywords)のようなものだと誤解し、記事を1本公開するたびに思いつくままに関連しそうな単語を5個も10個も新しいタグとして入力しているケースが数多く見受けられます。 しかし、WordPressにおけるタグとは、単なる記事への目印ではなく、「新しいタグを1つ登録するごとに、そのタグが付いた記事だけを集めた独立した一覧ページ(/tag/タグ名/)のURLを1つ新規生成する命令」です。もし100本の記事を書きながら、毎回思いつきで新しい単語を5個ずつタグとして追加していけば、ホームページの裏側には500ページのタグアーカイブURLが誕生します。
そして、そのように場当たり的に作られたタグの大半は、他の記事で二度と使われることがないため、500ページのうちの400ページ以上が「該当する記事がたった1件しか入っていないタグ一覧ページ」となります。1記事しか入っていないタグ一覧ページは、先ほどの日付別アーカイブと全く同じように、その1記事のタイトルと抜粋文が数行表示されているだけの極端な低品質ページ(シンコンテンツ)であり、本体記事の劣化コピーにすぎません。
各記事に出力される関連タグリンクがクローラーの無限回遊を生む構造
しかも、タグアーカイブが日付別アーカイブ以上にタチが悪いのは、ほとんどのWordPressテーマが「各記事のタイトル付近や本文の直下に、その記事に付与されたタグへのリンク一覧を自動的に出力する」という仕様になっている点です。 1つの記事に10個のタグが付けられていれば、その記事を訪れたクローラーは10個のタグアーカイブURLへの内部リンクを発見し、それらすべてを巡回リストに追加します。そして巡回した先のタグページには、1記事の抜粋しか載っていないため、検索エンジンはそれを「クロール済み – インデックス未登録(価値のない重複・低品質ページ)」として処理します。ホームページ内にこうした乱造タグが数百個存在し、全記事から相互にリンクが張られている状態は、クローラーをゴミページの迷宮へと意図的に誘導してクロールバジェットを焼き尽くしているのと同じ構造です。
不要なアーカイブへのnoindex設定の限界と内部リンク制御の重要性

ここまで解説してきたアーカイブページによる重複コンテンツと低品質ページの量産を防ぐため、一般的なSEOのノウハウとしては「不要なアーカイブページにnoindexを設定しましょう」という対策が広く語られています。もちろんnoindexの設定自体は必要な処置ですが、クロールバジェットの最適化という視点に立ったとき、noindexだけで満足して対策を止めてしまうことには大きな落とし穴があります。
SEOプラグインによるnoindex設定の基本方針とそれが解決できる範囲
まずは基本となるインデックス制御の整理として、どのアーカイブをインデックス対象に残し、どのアーカイブにnoindex(インデックス登録の拒否)を設定すべきかという基準を明確にします。
インデックスから除外すべきアーカイブ種別の明確な仕分け
事業用のホームページにおいて、検索ユーザーにとって独自の価値を持たず、ホームページ内の重複コンテンツをいたずらに増やす原因となる以下のアーカイブページについては、検索結果にインデックスさせる必要は一切ありません。 具体的には、「年別アーカイブ」「月別アーカイブ」「日付別アーカイブ」のすべての時系列アーカイブ、単一または少人数で運営しているホームページにおける「著者(投稿者)アーカイブ」、そして記事が1〜2件しか入っていないような整理されていない「タグアーカイブ」です。All in One SEO(AIOSEO)などのSEOプラグインを導入している環境であれば、管理画面の「検索の外観」メニュー内の「アーカイブ」や「タクソノミー」の設定タブにおいて、これらの不要なアーカイブページの「検索結果に表示」の項目をすべて「いいえ(noindex)」に設定しておくことが、ホームページ全体の情報純度を守り、低品質な一覧ページによる評価の希釈(ベクトル重心のブレ)を防ぐための第一段階の基本処置となります。
noindexはインデックス登録を防ぐだけでありクロール自体は拒否しないという仕様
しかし、ここで検索エンジンのクローラーの動作原理を改めて冷静に考える必要があります。HTMLのheadタグ内に出力される「」というメタタグ(またはHTTPレスポンスヘッダーのX-Robots-Tag: noindex)は、検索エンジンに対して「このページのデータを読み取った後、検索結果のデータベース(インデックス)には収録しないでください」と指示する命令であり、「このURLへアクセス(クロール)しないでください」という命令ではありません。 したがって、不要なアーカイブページに対してプラグインで「noindex」を設定しただけでは、検索結果にその一覧ページが表示されること(インデックス汚染)は防げても、クローラーがそのページへアクセスすることによる「クロールバジェットの消費」までは一切防ぐことができません。
noindexを設定しても内部リンクが存在する限りクローラーが巡回し続ける技術的理由
なぜnoindexにしたはずの年別・月別・日付別アーカイブや著者アーカイブに対して、その後も何ヶ月、何年にもわたってGoogleのクローラーが毎日アクセスし続け、クロールバジェットを浪費し続けるのかというと、ホームページの画面上に「それらのアーカイブURLへの内部リンク(aタグ)」が自動出力されたまま残っているためです。
HTMLソース内のaタグ(href属性)を抽出してクロールキューへ追加する仕組み
検索エンジンのクローラーは、ある記事のページへアクセスすると、そのページのHTMLソースコードを上から下まで一行ずつ解析(パース)し、その中に記述されているすべてのアンカータグ(<a href=”…”>)を機械的に抽出して、次に巡回すべきURLの待機リスト(クロールキュー)へと追加していきます。 このとき、リンク元のページ上に張られているリンクを見た段階では、クローラーは「そのリンク先のページにnoindexが書かれているかどうか」を知る術がありません。リンク先のページが正規の重要記事なのか、それともnoindexが設定された日付アーカイブなのかを判別するためには、クローラーは実際にそのURLへ向けてHTTPリクエストを送信し、WordPressとデータベースを起動させてHTMLを生成させ、そのデータをダウンロードしてheadタグの中身を読み取らなければなりません。
アクセスしてnoindexを確認して帰るという無駄な往復運動とサーバー負荷
もし、ホームページ内の各記事やサイドバーに「月別アーカイブへのリンク」や「日付アーカイブへのリンク」「著者アーカイブへのリンク」が設置されたままになっていれば、クローラーは新しい記事や既存の記事を読みに来るたびにそれらの内部リンクを発見し、「ホームページの運営者が自ら内部リンクを張って案内している以上、中身を確認しに行かなければならない」と判断して、年別・月別・日付別のURLへ次々とアクセスします。
そして、アクセスした先でサーバーに動的生成処理をさせてHTMLを読み込み、「ああ、ここにはnoindexと書かれているからインデックスはしないでおこう」と処理してそのまま帰っていきます。
この「リンクを辿ってアクセスし、noindexを確認して、何もせず帰る」という100パーセント無意味な往復運動が、何百、何千というアーカイブURLに対して日々繰り返されることで、ホームページの貴重なクロールバジェットと検索エンジンの計算コストが静かに、しかし大量に削り取られていきます。 さらに、アーカイブ一覧ページはデータベースから複数の記事データを検索・抽出して一覧を組み立てるため、単一の記事を表示するよりもデータベースのクエリ負荷が重くなりがちです。
クローラーが何千ものnoindexアーカイブページを巡回し続けることは、サーバーの応答速度を低下させ、結果的にホームページ全体のクロールレート制限(巡回上限)まで引き下げてしまう原因となります。クローラーの無駄な巡回を根本から断ち切るためには、noindexの設定にとどまらず、ホームページの画面上に自動的に出力されている「不要なアーカイブページへの内部リンク」そのものを物理的に削り取る工夫が極めて有効です。
テーマの自動生成内部リンクを削除してクロールバジェットの浪費を防ぐ実践手順

WordPressのホームページから不要なアーカイブページへのクローラーの流入を完全に遮断するためには、クローラーが辿る「入り口(内部リンク)」が画面上のどこに潜んでいるのかを洗い出し、管理画面の設定やテーマのテンプレート改修によってそれらを1つ残らず撤去する必要があります。ここでは、実務の現場で必ず点検・改修すべき具体的な箇所と手順を解説します。
サイドバーやフッターの月別アーカイブ・カレンダー・タグクラウドウィジェットの撤去
無駄なアーカイブ巡回を止めるために真っ先に行うべきなのが、WordPressの管理画面の「外観」メニュー内にある「ウィジェット(またはブロックエディタ型のサイトエディタ)」等で、サイドバーやフッターなどの全ページ共通エリアに配置されている不要なナビゲーション要素を撤去する作業です。
カレンダーウィジェットが過去数年分の何千という日付ページへクローラーを誘い込む罠
初期状態のWordPressや、ブログ用途を想定して作られたテーマを有効化すると、サイドバーに標準で配置されていることが多いのが「アーカイブ(2026年10月、2026年9月…と月別の一覧リンクが縦にずらっと並ぶもの)」「カレンダー(日付ごとにリンクが張られた月間カレンダー表)」、そして「タグクラウド(登録されているタグのリンクが一覧で並ぶもの)」といったウィジェットです。これらはまさに、全ページからクローラーを不要なアーカイブページへと大量に送り込むための巨大な入り口となっています。
とりわけクロールバジェットに対して破壊的な悪影響を及ぼすのが「カレンダー」ウィジェットです。カレンダーウィジェットをサイドバーに1つ設置すると、その月の記事が投稿された日付すべて(最大30個前後)に対して「日付別アーカイブ(/2026/10/25/など)」への内部リンクが生成されます。さらに深刻なのは、そのカレンダーの下部に「« 9月」といった「前の月へのリンク」が出力される点です。 クローラーはこの「前の月へのリンク」を辿って先月のカレンダーを表示させ、そこにある30日分のリンクを抽出し、さらにその前の月へ、またその前の月へと、ホームページが開設された何年も前の月まで無限に遡っていきます。
たった1つのカレンダーウィジェットがサイドバーに置かれているだけで、クローラーは過去数年分の何千ページにおよぶ月別・日付別アーカイブの迷宮へと引きずり込まれ、そこから抜け出せなくなってしまいます。
ユーザー行動の観点からも不要な時系列ウィジェットを廃止し重要ページへの導線へ置き換える効果
そもそも、人間のユーザーの行動(UX)という観点から冷静に考えてみても、事業用のホームページに解決策やサービスを探しに訪れた見込み客が、サイドバーにある「2023年11月」という月別リンクや、カレンダーの「14日」という数字をクリックして過去の記事を探すことなどまずあり得ません。 人間のユーザーにとっても全く役に立たず、サイドバーの貴重な表示領域を占領し、その上で検索エンジンのクローラーの巡回枠を激しく浪費させるだけの月別アーカイブウィジェット、カレンダーウィジェット、および無秩序なタグクラウドウィジェットは、思い切って画面上から完全に削除することが最善の選択です。
そして、それらを撤去して空いたサイドバーやフッターのスペースには、事業の成約に直結する主力サービスページへのバナーや、トピッククラスターの親となる「ピラー記事(まとめ記事)」へのリンク、あるいは厳選された主要カテゴリーへの案内を配置します。これによって、人間の訪問者にとっての回遊性(コンバージョンへの導線)と、クローラーにとっての重要ページへの巡回効率の双方を劇的に高めることができます。
投稿メタ情報(公開日・更新日・投稿者名)に自動付与されるリンクの解除とテンプレート改修
サイドバーやフッターから月別一覧やカレンダーのウィジェットを完全に撤去したにもかかわらず、Googleサーチコンソールの「クロールの統計情報」やアクセスログを確認すると、依然として日付別アーカイブや著者アーカイブへのクロールが止まっていないことがあります。その原因となっているのが、市販や無料のWordPressテーマが「各記事のタイトル直下や記事末尾のメタ情報表示エリア」に自動的に出力している内部リンクです。
市販や無料のWordPressテーマが日付や著者名にaタグを自動出力する仕様
多くのWordPressテーマでは、個別記事(投稿ページ)や一覧カードにおいて、記事の公開日(たとえば「2026年10月25日」)を画面に表示する際、ただの文字(テキスト)として表示するのではなく、その日付の文字列に対して自動的に「https://example.com/2026/10/25/」という日付別アーカイブ(テーマによっては月別アーカイブ)へのリンク(aタグ)を付与するプログラムが組まれています。
同様に、記事の公開日の横に執筆者名(たとえば「管理者」や「株式会社〇〇」など)を表示する部分にも、自動的に「https://example.com/author/admin/」といった著者アーカイブへのリンクが張られています。パッと見た目のデザイン上は、ただ小さく日付と作成者名が書かれているだけに見えるため、ホームページの運営者自身もそこがクリック可能なリンクになっており、HTMLソース上に「<a href=”…”>」が出力されていることに気づいていないケースが極めて多く見られます。
しかし、ウィジェットから月別一覧を消したとしても、公開されている全500記事、全1,000記事のタイトル直下にこの「日付リンク」と「著者リンク」が残っていれば、クローラーはすべての記事を巡回するたびにそこから日付アーカイブと著者アーカイブへのリンクを発見し、巡回し続けてしまいます。
子テーマのテンプレートファイルや出力関数からリンクタグを除去し純粋なテキスト(timeタグ・spanタグ)へ変更する手順
このメタ情報からのクロール漏出を防ぐためには、まず使用しているWordPressテーマのカスタマイザーや設定画面を確認し、「投稿者名を表示しない(またはリンクを出力しない)」「日付にアーカイブリンクを張らない」といった切り替え設定が用意されていれば、それをオフにします。 もしテーマの管理画面に設定項目が存在しない場合は、子テーマ(Child Theme)を用いてテンプレートファイル(single.php、content.php、あるいはテーマ独自のメタ情報出力用関数が記述されたファイル)をカスタマイズし、公開日や著者名を出力している箇所のPHPコードを改修します。
より専門的にWordPressのコード構造を説明すると、テーマ内で日付にリンクを張っている箇所では、多くの場合「get_day_link()」や「get_month_link()」といったアーカイブURL取得関数を使ってaタグを組み立てているか、テーマ独自のテンプレートタグが使われています。
また、著者名にリンクを張っている箇所では「the_author_posts_link()」や「get_author_posts_url()」という関数が使用されています。これらのコードを改修し、公開日や更新日については「<a href=”…”>」のリンクタグを完全に取り除いて、「<time datetime=”2026-10-25″>2026年10月25日</time>」というように、検索エンジンに日付の意味だけを正しく伝える純粋なtimeタグとテキストのみの出力へと書き換えます。同様に、著者名についてもリンクタグを除去し、「<span class=”author-name”>著者名</span>」といった純粋なテキスト表示に変更する(あるいは単一運営のコーポレートサイトであれば著者名の表示自体を非表示にする)改修を行います。 このわずか数行のテンプレート改修を行うだけで、ホームページ内の全記事から何千本と張られていた不要な日付・著者アーカイブへの内部リンクが一瞬にして消滅し、クローラーが脇道へ逸れる入り口を完全に塞ぐことができます。
さらに踏み込んだ不要アーカイブの無効化とリダイレクト・ステータスコード制御
不要なアーカイブをnoindexにし、さらにウィジェットや記事メタ情報から内部リンクを完全に削除すれば、新しく生成される日付アーカイブ等へクローラーが迷い込むことはなくなります。
しかし、長年運用してきたホームページの場合、内部リンクを消すよりも前に、すでに検索エンジンのクローラーが過去の巡回によって何百、何千という月別・日付別・著者アーカイブのURLを記憶(クロールキューに保持)してしまっているケースがあります。 内部リンクを消した後も、クローラーが過去の記憶を頼りに直接アクセスしてくるのを最短で終わらせるためには、不要なアーカイブ機能そのものを無効化し、アクセスに対して適切な転送またはエラーステータスを返す処置を組み合わせると完璧です。
すでにクローラーに記憶された年別・月別・日付・著者アーカイブURLの無効化と404/410処理
WordPressの内部では、子テーマの「functions.php」や「mu-plugins(必須プラグイン)」に短いPHPコードを記述することで、年別・月別・日付別アーカイブ(is_date())や著者アーカイブ(is_author())へのリクエストが来た際に、ページを表示させずに強制的に404エラー(または410 Gone)を返したり、ホームページのトップへリダイレクトさせたりする制御が可能です。さらに、WordPressが内部で保持しているURLの振り分けルール(rewrite_rules_arrayフィルター)から、日付アーカイブや著者アーカイブ、不要なフィード用のリライトルールそのものを削除してしまうこともできます。
もし、過去の月別・日付別アーカイブや著者アーカイブに対して外部からの被リンクなどが一切ついておらず、純粋にクローラーの無駄な巡回だけが続いている状態であれば、それらのURLへのアクセスに対してHTTPステータスコード「410(Gone:恒久的な消滅)」または「404(Not Found)」を返すように設定します。特に別のクラスター記事でも解説した通り、410ステータスを返すように制御すれば、クローラーは「このアーカイブURL群は完全に廃止された」と即座に理解し、再確認のクロールを打ち切って巡回リストから素早く消去してくれます。
アーカイブ自動生成のフィードURL(/feed/)やコメントフィードの停止によるクロール節約
また、アーカイブ制御において見落とされがちなプロの視点として、WordPressが全ページのheadタグ内に自動出力する「フィードリンク(rel=”alternate” type=”application/rss+xml”)」と、各記事やアーカイブの末尾に自動生成される「/feed/」URLの制御があります。WordPressは初期状態では、サイト全体のフィードだけでなく、「コメント用のフィード(/comments/feed/)」「各記事ごとの個別コメントフィード(/記事スラッグ/feed/)」「各カテゴリーやタグごとのフィード(/category/名/feed/)」を自動生成し、HTMLヘッダー内にリンクを出力します。一般ユーザーからのコメント機能を受け付けていない事業用ホームページであっても、この仕様が生きているために、クローラーが全記事の末尾に「/feed/」をつけた中身のないXMLデータを何百件も巡回してクロールバジェットを消費している事例が多発しています。
サイト全体の更新を通知するメインのRSSフィード1つだけを残し、個別記事のコメントフィードや不要なアーカイブフィードの生成とヘッダー出力を「remove_action( ‘wp_head’, ‘feed_links_extra’, 3 );」などの記述によって停止させ、不要なフィードURLへのアクセスを410等で遮断することも、クロールバジェットの漏出を防ぐ上で非常に効果的です。
カテゴリーとタグの役割整理および情報純度を高めるアーカイブ再設計

不要な時系列アーカイブや著者アーカイブを封じ込めたら、最後に手をつけるべきなのが、ホームページの論理構造そのものである「カテゴリー(category)」と「タグ(post_tag)」の整理です。これらを漫然と放置せず、トピッククラスターを支える強固な骨組みへと再編することで、クロール効率とSEO評価の双方が大きく向上します。
乱造されたタグページの統廃合と記事画面からの自動タグリンク出力の停止
前半で指摘した通り、1記事や2記事しか紐づいていない無数のタグアーカイブページは、重複コンテンツの温床であり、クロールバジェットを激しく消耗させる原因となります。タグの扱いについては、自社の運用体制と情報設計に合わせて、以下の2つの道のうちいずれかを明確に選択する必要があります。
タグをSEO評価対象から完全に切り離す場合のnoindex設定とテンプレートからのリンク撤去
まず1つ目の選択肢は、ホームページ内の記事分類を「カテゴリー」と「ピラー・クラスター間の本文内リンク」だけに一本化し、タグ(post_tag)機能によるアーカイブをSEOおよびナビゲーションから完全に切り離す(廃止する)方針です。実は、数百記事規模の事業用ホームページであれば、適切に設計されたカテゴリーと緻密な本文内リンクがあれば、タグアーカイブが存在しなくてもユーザーもクローラーも全く困りません。
管理しきれないタグがすでに乱立している場合は、SEOプラグインでタグアーカイブ全体を一括で「noindex」に設定するとともに、先ほどの日付リンクと同様に、各記事の画面上(タイトル下や記事末尾)に自動出力されている「関連タグ一覧リンク」をテーマの設定またはテンプレート改修によって完全に停止します。さらに、既存の不要なタグ自体を管理画面から削除し、過去のタグURL(/tag/…/)へのアクセスを410ステータスで遮断するか、関連する正規記事へ301リダイレクトさせることで、何百ページもの無駄なクロール対象を一気にゼロにすることができます。
タグやタームを統合・厳選しインデックス可能な専門解説記事へと書き換える構造再編
もう1つのより積極的な選択肢は、過去に乱造された数百個のタグやターム(分類)を徹底的に棚卸しし、重複や不要なものを削除・統合した上で、本当に検索需要のある重要なテーマについては単なる自動生成の「タグ一覧ページ」としてではなく、独立した「インデックス可能な専門解説記事」へと書き換えて昇華させる手法です。 この記事統廃合とURL変更・301リダイレクトの実践的な考え方については、ホームページ内部のURL変更とリダイレクト設定 SEOへの影響と記事統廃合の実践 および「クロールバジェット視点から考えるホームページの構造再編と不要ページの統合戦略」でも詳しく解説していますが、たとえば500個あったタグページを廃止し、その中核となっていたテーマを100本の深い専門記事へと作り替えて301リダイレクトで評価を統合すれば、クロールバジェットを浪費していた負債領域が、検索流入を生み出す強力な資産領域へと生まれ変わります。
検索エンジンに評価されるカテゴリーアーカイブの設計とページネーションの最適化
不要な時系列アーカイブ、著者アーカイブ、そして乱造されたタグアーカイブをすべて整理し終えると、ホームページ内に残る一覧ページは、厳選された「カテゴリーアーカイブ」だけになります。最後に、この残されたカテゴリーアーカイブを、クローラーにとって最も巡回しやすく、かつSEO評価の高いページへと磨き上げるポイントを解説します。
単なる記事抜粋の羅列からトピックを俯瞰するハブページへの昇華
初期状態のWordPressのカテゴリーページは、ただ属している記事のタイトルと抜粋文が新着順に並んでいるだけであり、独自の解説テキストが存在しないため、それ単体では検索キーワードに対して上位表示されにくい構造になっています。 カテゴリーページをクロールバジェットに見合う価値あるページにするためには、まずカテゴリーの数を無闇に増やさず、事業の主要テーマに沿った少数精鋭の分類(たとえば5個〜10個程度)に絞り込みます。その上で、カテゴリー編集画面の「説明」欄や、カテゴリーページ専用のカスタマイズ機能を活用し、そのカテゴリーが扱う分野の概要や、どのような順序で記事を読むべきかを案内する独自のリード文・解説コンテンツをカテゴリーページの上部に配置します。これにより、カテゴリーページ自体が単なる機械的な一覧から、トピッククラスターを統括するハブページへと進化し、検索エンジンの計算コストに見合う高い情報価値を持つようになります。
ページネーションの階層深化を防ぎクロール深度(Crawl Depth)を浅く保つ表示件数と導線設計
また、カテゴリーページにおいてクロールバジェットの観点から注意すべきなのが、記事数が増えた際に発生するページネーション(/category/seo/page/2/、/page/3/…)の深さです。 WordPressの初期設定では「1ページに表示する最大投稿数」が「10件」に設定されています。もし1つのカテゴリーに100本の記事が入っている場合、1ページあたり10件表示のままだと、ページネーションが「/page/10/」まで10階層も生成されることになります。
クローラーが1ページ目から順番に「次のページへ」のリンクを辿っていくと、古い記事に到達するまでに何段階もの一覧ページを経由しなければならず、一覧ページ自体のクロールにバジェットが消費されるとともに、奥にある記事のクロール深度(トップページからのクリック階層)が深くなって巡回頻度が落ちてしまいます。
これを防ぐためには、管理画面の「設定」内の「表示設定」において、1ページあたりの表示件数を10件といった少ない数にするのではなく、ページの表示速度を損なわない範囲で「20件」や「30件」程度へと引き上げ、生成されるページネーションの総ページ数そのものを半分から3分の1に圧縮する工夫が有効です。同時に、カテゴリー内の重要な記事については、ページネーションの奥に埋もれさせず、ピラー記事の本文中から直接内部リンクを張ることで、常に浅い階層からクローラーが直行できる経路を確保しておくことが大切です。
CMSの初期仕様に依存せずクロール効率と情報純度を最大化するホームページ運用

WordPressをはじめとするCMSは、誰でも簡単にホームページ(ウェブサイト)を構築し、記事を更新できる優れた仕組みを提供してくれますが、その初期設定は決して「検索エンジンのクロールバジェットや計算コストの最適化」を前提として作られているわけではありません。むしろ、あらゆる用途に対応できるよう、年別・月別・日付別アーカイブ、著者アーカイブ、タグアーカイブ、添付ファイルページ、各種フィードといった考えられる限りの一覧や派生URLをすべて自動で生成する「過剰出力」の状態で提供されています。
生成AIによるコンテンツ量産が進み、検索エンジンが自らの計算資源を守るために「価値の低いURLや重複ページが多いホームページは最後までクロールしない」という厳格な基準でホームページを選別している現在、CMSの初期仕様に身を任せて不要なアーカイブURLを何千ページも垂れ流しておくことは、自らのホームページのSEO評価とインデックス速度に重い足かせをはめているのと同じことです。 検索ユーザーにとって何の検索意図も存在しない年別・月別・日付別アーカイブや、単一運営サイトにおける著者アーカイブ、そして乱造されたタグアーカイブには確実にnoindexを設定すること。
そして、noindexページであってもクローラーが巡回すればクロールバジェットを消費するという事実を直視し、サイドバーのカレンダーや月別ウィジェットの撤去、さらにはテーマが記事の公開日や投稿者名に自動付与する内部リンク(aタグ)の除去まで踏み込んで、クローラーが不要なアーカイブへ迷い込む入り口を物理的に塞ぐこと。 こうしたシステムの裏側まで見通した緻密なクロール制御と内部リンクの整理を徹底することで、ホームページ全体のベクトル重心(専門性の純度)は研ぎ澄まされ、検索エンジンのクローラーが自社の最も価値ある専門記事やサービスページだけを最短距離で巡回・評価してくれる理想的な運用環境が実現していきます。







