WordPress投稿削除時のクロール浪費問題 残存する添付ファイルページへの対策

事業用のWordPressサイトを長期間運用していると、過去に公開したものの現在では役割を終えたお知らせ記事や事業方針の転換によって本業との関連性が薄れた投稿などが数多く蓄積していきます。現在の検索エンジン最適化（SEO）においては、ホームページ全体のテーマの専門性や情報の純度を高めるために、そうした価値の低い不要なページを定期的に統合・削除するメンテナンスが極めて重要です。検索エンジンのクローラーがホームページを巡回する上限枠であるクロールバジェットの全体像については、「クロールバジェット SEO・ホームページ運用における全体像」で詳しく解説していますが、不要なページを減らすことは、限られたクロールバジェットを重要な主力ページへ集中させるためにも有効な施策となります。

しかし、WordPressをはじめとする動的なコンテンツ管理システム（CMS）を用いて構築されたホームページにおいては、良かれと思って不要な投稿を削除したにもかかわらず、システムの裏側の仕様によって「削除したはずのURLに別の低品質なページが自動的に出現し、クローラーがそこを巡回し続けてしまう」という見落とされがちな現象が発生することがあります。

その代表的な原因が、WordPressがメディアファイルごとに自動生成する「添付ファイルページ（attachmentページ）」の存在です。なお、この事象はデータベース上で記事データとメディアデータを同じ構造で管理し、動的にURLを生成する仕組みを持つ同様のCMSであればWordPressに限定される話ではありませんが、本記事では国内で最も広く普及しているWordPressを具体例として取り上げます。

特に、削除した投稿のURL（スラッグ）と、その投稿にアップロードされていたアイキャッチ画像などのファイル名が全く同じ名前であった場合、投稿本体を削除して本来なら404（Not Found）や410（Gone）になるはずのURLにおいて、画像1枚と代替テキスト程度しか存在しない極端に内容の薄い「添付ファイルページ」が同じURLのまま表に浮上してくることがあります。せっかくホームページの情報純度を高めるために記事を削除したにもかかわらず、さらに品質の低いページがステータスコード200（正常）として居座り続ける事態は、ホームページ全体の品質評価を引き下げ、クロールバジェットを無駄に消費する要因となります。

今回は、WordPressにおいて投稿削除時に添付ファイルページが残存してしまう技術的な仕組みから、noindex設定だけではクロールバジェットの浪費を防げない理由、根本的な解決策である元画像の削除、そして大量の画像を即座に処理できない現場で役立つAll in One SEO（AIOSEO）を活用した仮止めのリダイレクト対策までを詳しく解説します。あわせて、年別・月別アーカイブなどの不要な自動生成ページと内部リンクの整理手法についても体系的に掘り下げていきます。

投稿削除で404になっても添付ファイルページが残る現象

ホームページのトピック純度を高めるために不要な過去記事を削除した際、運営者の意図としては「そのURLは完全に消滅し、クローラーがアクセスしても404エラーが返ることで、やがてインデックスや巡回対象から外れるだろう」と想定するのが一般的です。ところが、WordPressのデータベース構造とURLのルーティング（振り分け）の仕様が重なることで、削除した投稿と全く同じURLのまま、中身だけが「添付ファイルページ」にすり替わって生き残ってしまう現象が起きます。まずはこの現象がなぜ発生するのか、その裏側の仕組みを正確に理解しておく必要があります。

投稿と同一スラッグで生成される添付ファイルページのありがた迷惑

WordPressには、管理画面のメディアライブラリや記事の編集画面から画像やPDFなどのファイルをアップロードすると、サーバーのディレクトリ（/wp-content/uploads/配下）に画像ファイルそのものを保存するのと同時に、データベース内にもその画像に関する情報を1つの「ページ（レコード）」として登録し、その画像を単体で表示するための専用HTMLページを自動生成する機能が備わっています。これが「添付ファイルページ（attachmentページ）」と呼ばれるものです。

WordPressがメディアごとに独立したHTMLページを生成する仕様

WordPressのデータベース構造（wp_postsテーブル）を見ると、通常の投稿（post）も、固定ページ（page）も、そしてアップロードされた画像などのメディアファイル（attachment）も、すべて同じテーブルの中で「投稿タイプ（post_type）が異なるだけの同列のデータ」として管理されています。そのため、画像を1枚アップロードするごとに、通常の投稿と同じように固有のIDと、URLの一部となるスラッグ（post_name）が自動的に割り当てられます。

このとき、画像データに割り当てられるスラッグは、アップロードした際の「拡張子を除いた画像ファイル名」がそのまま使われる仕様になっています。たとえば、「2025-summer-campaign.jpg」というファイル名の画像をアップロードすると、データベース上には「2025-summer-campaign」というスラッグを持った添付ファイルページが自動的に生成されます。初期状態のWordPressでは、この添付ファイルページにアクセスすると、ヘッダーやフッター、サイドバーといったホームページ共通の枠組みの中に、アップロードした画像が1枚だけポツンと表示されるだけの独立したWebページが出力されます。

投稿のスラッグとアイキャッチ画像のファイル名が一致する運用パターン

日々のホームページ運用や記事作成の現場において、管理のしやすさや規則性を重視するあまり、記事のURL（スラッグ）と、その記事に使用するアイキャッチ画像や挿入画像のファイル名を全く同じ文字列に揃えて作成しているケースは珍しくありません。たとえば、夏季休業のお知らせ記事を作成する際に、記事のスラッグを「summer-holiday-notice」と設定し、同時にその記事のアイキャッチ画像として作成した画像ファイルにも「summer-holiday-notice.jpg」という名前をつけてアップロードするような運用です。

あるいは、先に記事の編集画面で画像をアップロードした際、まだそのスラッグが使われていないために画像側に「new-service-launch」というスラッグが割り当てられ、その直後に投稿本体のスラッグとしても同じ「new-service-launch」を手動で入力して公開するといったケースもあります。通常の投稿と添付ファイルページは内部的な投稿タイプが異なるため、設定やアップロードの手順によっては、同じホームページ内で「投稿のスラッグ」と「添付ファイルページのスラッグ」が全く同じ名前（あるいは末尾にハイフンと枝番がついた非常に似通った名前）としてデータベース内に並存する状態が作られます。

投稿本体の削除によって隠れていた添付ファイルページが表に出る仕組み

ホームページのパーマリンク設定を「投稿名（/%postname%/）」などのシンプルな構造にしている場合、もし投稿のスラッグと添付ファイルページのスラッグが同一であったとしても、投稿本体が公開されている間は、そのURLにアクセスするとWordPressの内部ルーティングの優先順位によって「投稿本体」が優先的に表示されます。そのため、運営者は同じURLの裏側に添付ファイルページが潜んでいることに全く気づかないまま運用を続けることになります。

問題は、数年後にホームページの情報整理（コンテンツの棚卸し）を行う段階になって表面化します。類似する他の記事へ統合できる場合は、ホームページ内部のURL変更とリダイレクト設定 SEOへの影響と記事統廃合の実践 で触れているように301リダイレクトを設定して評価を引き継ぎますが、過去の「お知らせ」や一時的な告知記事のように統合先となる関連ページが存在しないものは、そのまま投稿を削除（ゴミ箱へ移動し、さらに完全に削除）して404や410にするのが通常の処置です。

しかし、WordPressの管理画面から「投稿」を削除しても、その投稿に貼り付けられていた「メディアライブラリ内の画像データ」までは連動して削除されず、そのままサーバーとデータベースに残り続けます。すると、これまで優先的に表示されていた「投稿本体」のデータがデータベースから消滅した結果、同じスラッグを持って裏側に控えていた「添付ファイルページ」が優先順位を繰り上げて表に浮上してきます。

つまり、運営者が「https://example.com/summer-holiday-notice/」という投稿を完全に削除したにもかかわらず、そのURLにブラウザやクローラーがアクセスすると、404エラーにはならず、同じ「https://example.com/summer-holiday-notice/」というURLのまま、ステータスコード200（正常）としてアイキャッチ画像だけが貼られた添付ファイルページが表示され続けてしまうという現象が発生します。また、投稿作成時に画像をその記事へ直接アップロード（紐づけ）していた場合でも、親となる投稿が完全に削除されたことで画像の紐づけ先（post_parent）が外れ、ルート階層（ドメイン直下）のURLとして添付ファイルページが独り歩きし始めるケースもあります。

画像と代替テキストのみの低品質ページがホームページ全体に与える影響

投稿を削除した後に添付ファイルページが生き残ってしまうことがなぜ大きな問題なのかというと、それが単なる表示上の不具合にとどまらず、ホームページ（ウェブサイト）全体のSEO評価を根底から揺るがす原因になるためです。

コンテンツの独自性が存在しない極端な薄っぺらいページの量産

そもそも、ホームページの運営者が過去の不要な「お知らせ」や本業と無関係な雑記記事をわざわざ削除するのは、検索エンジンに対して「このホームページは特定の事業分野に関する専門性の高い情報だけを集めた、情報純度の高いホームページである」と正しく認識してもらうためです。仮に300文字程度の簡単な告知記事であったとしても、それが何百件も残っていればホームページ全体の専門性が薄まるため、手間をかけて削除の判断を下したはずです。

ところが、その300文字の投稿を削除した結果として同じURLに出現する添付ファイルページは、本文のテキストが1文字も存在せず、画像が1枚と、画像のタイトルや代替テキスト（alt属性）の単語が一行だけ出力されているような、投稿削除前よりもさらに情報量が乏しいページです。もし過去に削除した何百件もの投稿の跡地に、こうした画像1枚だけの添付ファイルページが大量に残存していた場合、ホームページ内には何の独自の価値も持たない極端な低品質ページ（シンコンテンツ）が大量に放置されている状態となります。

トピック純度を高めるための記事削除が逆効果になる矛盾

検索エンジンのアルゴリズムは、個々のページの品質を評価するのと同時に、ホームページ全体（ドメイン全体）にどれくらいの割合で有益なページが含まれており、どれくらいの割合で低品質なページが含まれているかという全体のバランスを厳しく見ています。

せっかくホームページの品質を高めようと過去記事を大幅に整理したにもかかわらず、削除した投稿のURLが404にならずに添付ファイルページとしてステータスコード200を返し続けていれば、検索エンジンのクローラーからは「これまでテキストが書かれていたページが、ある日突然、画像1枚だけのほとんど白紙に近い低品質なページに書き換えられた」としか見えません。これでは、トピック純度を高めるための記事整理が全く機能しないばかりか、かえってホームページ全体の平均的な品質スコアを押し下げ、主力となる重要なサービスページや専門記事の検索順位にまで悪影響を及ぼすという本末転倒な結果を招いてしまいます。

noindexページもクロールバジェットを消費するという事実

この添付ファイルページの問題を指摘すると、SEOについて一定の知識がある制作者や運営者からは「うちのホームページでは、プラグインの設定で添付ファイルページにすべてnoindexタグが出力されるようになっているから、インデックスされることはなく問題ないはずだ」という意見が返ってくることがあります。確かに、添付ファイルページがそのまま検索結果にインデックス登録されてしまう最悪の事態を防ぐ上で、noindexの設定は有効に働きます。しかし、クロールバジェット（クローラーの巡回枠）の観点から見れば、noindexを設定しているだけでは問題の半分しか解決していません。

クローラーがnoindexタグを認識するまでの通信プロセス

ここで改めて検索エンジンのクローラーの動作原理を考えてみる必要があります。ページのHTMLヘッダー内に出力される「」という記述は、あくまで「このページのデータを読み取った後、検索結果のデータベース（インデックス）には登録しないでください」という命令であり、「このページへアクセス（クロール）しないでください」という命令ではありません。

クローラーは、あるURLにnoindexが設定されているかどうかを透視して事前に知ることはできません。実際にそのURLへHTTPリクエストを送り、サーバー側でWordPressとデータベースを起動させてHTMLファイルを生成させ、そのHTMLデータをダウンロードして中身を解析して初めて、「ここにはnoindexと書かれているからインデックスから除外しよう」と判断することができます。つまり、noindexが設定されたページであっても、クローラーがそのページへアクセスした時点で、1ページ分のクロールバジェットとサーバーの処理リソースは完全に消費されています。

削除したはずの投稿URLへクローラーが巡回し続ける構造的な無駄

さらに厄介なのが、削除する前の「元の投稿」がすでに検索エンジンにインデックスされており、一定の評価や内部リンク、あるいは外部からのリンクを持っていたケースです。検索エンジンのクローラーは、これまで正規の記事として認識していたURLを定期的に再巡回（リフレッシュクロール）しにやってきます。

もし投稿を削除した際に正しく404や410が返っていれば、クローラーは「ページが消滅した」と認識し、やがて巡回リストからそのURLを外してくれます。しかし、同じスラッグの添付ファイルページが浮上して「ステータスコード200（ただしnoindex）」を返し続けていると、クローラーの目には「URL自体は今も正常に稼働してページが存在している（ただ現在はnoindexが指定されている）」と映ります。そのため、クローラーはその後も長期にわたって「もしかするとnoindexが外れて記事が復活しているかもしれない」「内容が更新されているかもしれない」と確認するためにそのURLへアクセスし続け、何の価値もない添付ファイルページのためにクロールバジェットを浪費し続けることになります。

添付ファイルページ問題を解決する具体的な手順と仮止めの運用

投稿削除後に残存する添付ファイルページによる品質低下とクロールバジェットの浪費を防ぐためには、WordPressのデータ構造を踏まえた適切な処置を講じる必要があります。ここでは、最も正攻法となる根本的な解決策と、実務上のリソース不足を補うための現実的な「仮止めの解決策」の2つのアプローチを詳しく解説します。

最も望ましい解決策である元画像の削除と運用上の課題

クロールバジェットの最適化およびホームページの健全なデータ管理という視点において、この問題を根本から断ち切る最も望ましい解決策は、添付ファイルページが生成される原因そのものとなっている「不要な元画像ファイル」をメディアライブラリから完全に削除することです。

不要な投稿を削除する際に紐づくメディアファイルも完全削除する手順

WordPressで特定の投稿を削除する際、ただ投稿一覧画面から記事をゴミ箱へ入れて消去するだけでなく、その投稿の中でしか使用されていなかったアイキャッチ画像や本文内の挿入画像についても、メディアライブラリから特定して「完全に削除する」という工程を業務フローに組み込むのが理想的な姿です。

メディアライブラリから画像データを完全に削除すれば、サーバーのuploadディレクトリ（/wp-content/uploads/）から実体ファイルが消去されるとともに、データベース（wp_postsテーブル）内に登録されていた「attachment」タイプのレコードも完全に抹消されます。これにより、投稿本体のレコードも添付ファイルページのレコードも両方ともデータベースから存在しなくなるため、削除した投稿のURLへクローラーがアクセスしてきた際には、確実に404（Not Found）またはサーバー設定に応じた410（Gone）が返却されるようになります。不要なページを消すときは、それに付随する不要なメディアデータもセットで消すという原則を守ることで、データベースの肥大化とクロールバジェットの浪費を同時に防ぐことができます。

大量の画像が蓄積されたホームページで元画像の特定が困難になる理由

このように理屈の上では「元画像を削除する」のが最も確実な解決策ですが、長年にわたって運用されてきた事業用ホームページの現場においては、この作業をすぐに完遂できない現実的な課題に直面することが少なくありません。

たとえば、ホームページ全体の構造再編やトピック純度の向上を目指して、過去に書き溜めた1,000件以上の記事のうち、低品質な500件の記事を一気に削除・整理したとします。1つの記事につき平均して5枚の画像が使われていたとすれば、削除対象となる記事に関連する画像だけで2,500枚以上にのぼります。さらに、WordPressのメディアライブラリには全体で数万枚の画像が蓄積されており、その中には「削除した記事でしか使われていなかった画像」と、「現在も公開中の重要な固定ページや他の記事で共通して使い回されている画像」が混在しています。

もし誤って、現在も他のページで使用されている画像までメディアライブラリから削除してしまうと、公開中のページの画像がリンク切れ（表示崩れ）を起こしてしまいます。それを避けるために、数千枚から数万枚の画像がどの記事で使われているかを1枚ずつ目視やデータベース検索で照合し、安全を確認してから削除していく作業には膨大な時間と労力がかかります。

この確認作業が追いつかないまま時間だけが経過すれば、その間ずっとクローラーは残存した大量の添付ファイルページを巡回し続け、SEO効果が現れるまでの期間（詳細は SEOの効果が出るまでの期間は？「4ヶ月〜1年」の定説とサイト規模ごとの本当の目安 を参照）を遅らせる原因となってしまいます。

AIOSEOを活用した画像URLへのリダイレクトという仮止めの対策

このように、不要な元画像を1枚ずつ特定して削除する処理がすぐには追いつかない場合や、すでに大量の投稿を削除してしまった後で添付ファイルページの残存に気づいた場合に、即座に導入できる実務上の「仮止めの解決策」があります。それが、SEOプラグインの機能などを活用して、添付ファイルページへのアクセスを「画像ファイルそのもののURL」へとリダイレクトさせる手法です。ここでは、多くのWordPressサイトで導入されているAll in One SEO（AIOSEO）を使用している場合を例に、設定の選択肢と注意点を具体的に解説します。

All in One SEOの「添付ファイル URL をリダイレクト」における3つの選択肢

All in One SEO（AIOSEO）の管理画面から「検索の外観（Search Appearance）」を開き、「メディア（Media）」タブへ進むと、「添付ファイル URL をリダイレクト（Redirect Attachment URLs）」という設定項目が用意されています。ここには、WordPressが自動生成する添付ファイルページをどのように扱うかについて、「無効（Disabled）」「添付ファイル（Attachment）」「添付ファイルの親（Attachment Parent）」という3つの選択肢が存在します。

まず「無効」を選択した場合、リダイレクトは一切行われず、添付ファイルページがそのまま独立したHTMLページとして表示されます。前述の通り、これでは投稿削除後に同じスラッグの添付ファイルページがステータスコード200でそのまま表に出てきてしまうため、今回の問題に対する解決策にはなりません。残る選択肢は「添付ファイルの親」か「添付ファイル」のどちらかとなりますが、ここでの選択を誤ると新たなトラブルを引き起こすことになります。

「添付ファイルの親」を選択した際に投稿削除済みで生じる矛盾

一般的なSEOの解説記事などでは、この設定項目について「添付ファイルの親（Attachment Parent）を選んでおけば、画像が貼られている元の記事へリダイレクトされるため安心だ」と説明されていることがよくあります。確かに、親となる投稿が現在も公開されている状態であれば、添付ファイルページへのアクセスを親投稿へ転送する設定は理にかなっています。

しかし、今回問題にしている「トピック純度を高めるために、統合先のない不要な投稿を削除したケース」において「添付ファイルの親」を選択していると、システム上の矛盾が生じます。なぜなら、転送先となるはずの「親（元の投稿）」自体をすでに削除してしまっているためです。

親投稿が削除されて存在しない状態で「添付ファイルの親」という設定になっていると、プラグインのバージョンやWordPressの内部状態によって、すでに消滅した親投稿への紐づけ情報が失われてリダイレクトが機能せず、結局そのまま添付ファイルページが表示されてしまったり、あるいは同じスラッグである自分自身のURLへ転送を繰り返して「リダイレクトループ（無限転送エラー）」を引き起こしてしまったりすることがあります。リダイレクトループや不完全な転送は、クローラーのリソースを激しく消耗させる原因となるため、投稿の削除を伴う運用においては「添付ファイルの親」では完全にカバーしきれません。

「添付ファイル」を選択して画像そのもののURLへリダイレクトさせる合理性

そこで、削除した投稿の跡地に添付ファイルページが残ってしまう問題への対策として有効に機能するのが、選択肢のうち「添付ファイル（Attachment）」を選ぶ方法です。

この「添付ファイル」を選択すると、添付ファイルページ（たとえば「https://example.com/summer-holiday-notice/」というHTMLページ）へのアクセスが、すべてその画像ファイル自体の実体URL（たとえば「https://example.com/wp-content/uploads/2025/08/summer-holiday-notice.jpg」という画像ファイル直リンク）へと301リダイレクトされるようになります。

なぜこの設定が有効な仮止め策になるのかというと、検索エンジンのクローラーにとって「HTMLで構築されたWebページ（ドキュメント）」と「.jpgや.pngなどの単なる画像ファイル（メディアリソース）」とでは、評価の対象としての扱いが全く異なるためです。添付ファイルページのまま放置されていれば、検索エンジンはそれを「1つの独立したWebページ（ただし中身が画像1枚しかない極端な低品質ページ）」として通常の検索インデックスの評価対象に含め、ホームページ全体のテキスト品質やトピック純度の計算においてマイナス要素としてカウントしてしまいます。また、そのHTMLページを描画するためにCSSやJavaScriptなどのサブリソースも読み込もうとします。

一方、添付ファイルページへのアクセスを「.jpg」などの画像ファイルそのもののURLへリダイレクトさせてしまえば、クローラーは「ここはWebページ（記事）ではなく、単なる画像ファイルの置き場所へ移動した」と認識します。画像ファイル自体は通常のウェブ検索のテキスト品質評価（低品質コンテンツ判定）の対象からは切り離され、必要に応じてGoogle画像検索の枠組みで処理されるだけになります。また、HTMLページとしてのレンダリング処理も発生しないため、クローラーの負荷も大幅に軽減されます。

低品質ページのインデックスやクロール浪費を防ぐ仮止め策としての位置づけ

もちろん、削除した投稿のURLが本来であれば404や410になって消滅すべきところ、過去のアイキャッチ画像のファイルURLへリダイレクトされるという挙動は、厳密な意味での完全な理想形ではありません。最も正しい最終形態は、先述した通り「使われなくなった元画像ファイルをメディアライブラリから完全に削除し、URL自体を404または410にすること」です。

しかし、実務の現場において何千枚もの画像の棚卸しと削除に何ヶ月もかかってしまうような状況下では、優先順位を明確にして被害を最小限に食い止める判断が求められます。中身がスカスカの低品質な添付ファイルページ（HTML）がそのまま残存し、インデックスされたりnoindexのままクローラーに巡回され続けたりしてホームページ全体の情報純度が希釈されるくらいであれば、とりあえずAIOSEOの設定で「添付ファイル（画像そのもののURL）」へリダイレクトさせておき、HTMLページとしての存在を消してしまう方が、SEOおよびクロールバジェットの観点から見て遥かにマシであり合理的な処置といえます。

まずこの設定によって低品質な添付ファイルページの露出を即座に封じ込める「仮止め（止血）」を行った上で、日々の運用の中で少しずつ不要なメディアファイルの削除を進め、最終的には画像の存在そのものを消して404や410へと移行させていく二段階の進め方が、大規模なコンテンツ整理においては非常に現実的です。

WordPress 6.4以降のコア仕様変更と過去データの扱いに関する注意点

なお、より専門的な技術背景として補足しておくと、WordPressはバージョン6.4（2023年後半リリース）のアップデートにおいて、コアプログラムの仕様が一部変更され、「WordPress 6.4以降に新規インストールされたホームページ」では、標準で添付ファイルページが生成されない（画像ファイル自体のURLへリダイレクトされる）仕組みが導入されました。

しかし、ここで注意しなければならないのは、この仕様変更が自動適用されるのはあくまで「バージョン6.4以降に新しく立ち上げたホームページ」だけであり、それ以前から運用を続けている既存のWordPressサイト（アップデートを重ねて現在最新バージョンになっているサイトを含む）においては、過去の互換性を保つためにデータベース内のオプション値（wp_attachment_pages_enabled）が「有効（1）」のまま維持されているという点です。

長い歴史を持つ事業用ホームページほど、過去の投稿数や画像数が多く、かつこの古い仕様がそのまま生きているため、投稿削除時に添付ファイルページが浮上する現象が現在も変わらず発生し続けています。自社のWordPressが最新バージョンだからといって安心するのではなく、AIOSEOなどのプラグイン設定やデータベースの設定値を必ず確認し、添付ファイルページが表に出ない制御を明示的に行っておく必要があります。

WordPressの仕様を理解したクロール制御と情報純度の維持

WordPressは非常に便利で拡張性の高いCMSですが、初期状態のまま何も手を加えずに運用を続けていると、今回解説した「投稿削除後に残存する添付ファイルページ」や「大量に自動生成される年別・月別・日付・著者アーカイブ」などによって、運営者が意図しない低品質なURLが裏側で増殖し続けます。そして、それらの不要なページや外部からのスパムURL（m3u8スパムへの410対応などについては  uploadディレクトリ .m3u8スパム攻撃の目的と「410 Gone」による対処法 を参照）が重なり合うことで、ホームページの限りあるクロールバジェットは容易に枯渇してしまいます。

ホームページ（ウェブサイト）の専門性を高め、検索エンジンから正当な評価を獲得するためには、単に新しい記事を書き足すだけでなく、「クローラーにどのページを見せて、どのページを存在しないものとして扱うか」をシステムレベルで厳密にコントロールする視点が欠かせません。

不要な投稿を削除する際は、同一スラッグの添付ファイルページが浮上してこないよう元画像の削除まで徹底すること。もし大量の画像の削除がすぐには追いつかない場合は、All in One SEO（AIOSEO）などの機能を用いて添付ファイルページを「画像そのもののURL」へリダイレクトさせ、低品質なHTMLページとしての露出を防ぐ仮止めを行うこと。そして、年別や月別などの不要なアーカイブはnoindexにするだけでなく、テーマが自動生成する内部リンクそのものを削り取ってクローラーの巡回経路から完全に切り離すこと。

こうしたCMSの裏側の挙動まで見据えた丁寧なメンテナンスを積み重ねることで、ホームページ全体の情報純度は極限まで高まり、検索エンジンのクローラーが自社の最も価値あるページだけを効率よく巡回・評価してくれる強固な運用環境が整っていきます。

添付ファイルページと並ぶクロール浪費の原因 自動生成アーカイブの制御

ここまで、WordPressにおいて投稿を削除した際に裏側で残存してしまう添付ファイルページの問題と、その具体的な対策について解説してきました。しかし、ホームページ（ウェブサイト）のクロールバジェットを最適化する上で、対処すべきシステム側の自動生成ページは添付ファイルページだけではありません。

計算コスト増大と情報純度の希釈を招くアーカイブページ問題への展開

添付ファイルページの残存と並んで、あるいはそれ以上にホームページ全体のクロールバジェットを激しく圧迫しているのが、WordPressが記事を公開するたびに自動生成する「年別・月別・日付別アーカイブ」や「著者アーカイブ」、そして無計画に乱造された「タグアーカイブ」です。

これらの不要なアーカイブページも、添付ファイルページと同様に検索ユーザーにとって独自の価値を持ちません。そればかりか、同じような一覧ページが何千ページも自動生成されることで、検索エンジンのクローラーに膨大な重複確認やレンダリングといった計算コストを強いることになります。さらに、文脈の異なる記事が時系列でごちゃ混ぜになった一覧ページが放置されていると、検索エンジンが判定するホームページ全体の専門性（ベクトル重心）が希釈され、主力となるサービスページや専門記事のSEO評価まで引き下げられてしまいます。

添付ファイルページの対策としてAIOSEO等によるリダイレクトや元画像の完全削除を行った後は、次の段階としてこの「自動生成アーカイブ」への対策に進むことが極めて重要です。不要なアーカイブページは単にnoindexを設定するだけではクローラーの巡回を止められないため、テーマが自動出力する内部リンクの撤去やテンプレートの改修といった、システム構造を見据えたより専門的な制御が求められます。

これらのアーカイブページがもたらす検索エンジンの計算コスト増大の仕組みや、内部リンクを断ち切る具体的な実践手法については、「WordPressの自動生成アーカイブによるクロールバジェット消費：検索エンジンの計算コストと内部リンク制御」にて詳しく解説しています。クロールバジェットの無駄遣いを徹底的に塞ぎ、専門性と情報純度の高いホームページ運用を実現するための次のステップとして、ぜひ併せてご確認ください。

クロールバジェット SEO・ホームページ運用における全体像