2026年版 WordPressのrobots.txt設定（本当に書くべき中身）
WordPressのrobots.txtは5行で足ります。/wp-admin/をブロックし、admin-ajax.phpを許可し、サイトマップを書く。レンダリングを壊すブロックリストは不要です。
公開
よくできたWordPressのrobots.txtは、だいたい5行です。/wp-admin/をブロックし、admin-ajax.phpを許可し、クローラーにサイトマップの場所を伝える。そこで終わりです。フォーラムで見かける40行に膨れたブロックリストは、たいていレンダリングを壊すか、何もしていないかのどちらかです。ファイル全体はこうなります。
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/wp-sitemap.xmlドメインを自分のものに置き換えてください。サイトマップをSEOプラグインが引き継いでいる場合は、Sitemap行をそのプラグインのインデックスに向けます。以上です。これより長いなら、余分な行はおそらく何かを犠牲にしています。
WordPressはすでに生成している。実ファイルを作るまでは
WordPressは仮想のrobots.txtを備えています。/robots.txtへのリクエストが来て、ウェブルートに実ファイルが存在しなければ、WordPressがリクエストを横取りしてメモリー上でレスポンスを出力します。ディスクには何も書き込まれません。既定の出力は上のwp-adminのブロックに加えて、WordPress 5.5以降コアが出力しているwp-sitemap.xmlへのSitemap:行です。
この出力を変えるものは2つあります。ひとつ、設定 → 表示設定 → 検索エンジンがサイトをインデックスしないようにするにチェックが入っていると、WordPressは中身を丸ごとDisallow: /に差し替え、すべてをブロックします。公開後にサイトが検索から消える原因として、このチェックボックスが断然いちばん多いものです。ふたつめ、プラグインやテーマがrobots_txtフィルターを通して仮想出力を書き換えられます。SEOプラグインが自前のサイトマップ行やルールを差し込むのはこの仕組みです。
ここからが、多くの人の午後を無駄にする部分です。ウェブルートに物理的なrobots.txtファイルがあると、以上のすべてが何の警告もなく上書きされます。 ウェブサーバーがディスク上の実ファイルを見つけて配信し、WordPressは読み込まれません。仮想の生成処理は動かず、robots_txtフィルターも発火しません。SEOプラグインのrobots.txt編集画面は、正しいルールが入った立派な画面を表示し続けるかもしれませんが、その内容はクローラーには届いていません。
| ルールの置き場所 | WordPress管理画面で編集できるか | 実際のリクエストでどちらが勝つか |
|---|---|---|
| 仮想（ディスクにファイルなし） | できる。robots_txtフィルターかプラグイン経由 | 物理ファイルが存在しないときだけ |
| ウェブルートの物理ファイル | プラグインがディスクに書き込む場合のみ | 常にこちら |
ですので、何かを調べ始める前に、まずブラウザーでhttps://yoursite.com/robots.txtを開き、次にSFTPかサーバー会社のファイルマネージャーで接続して、wp-config.phpや.htaccessの隣に実物のrobots.txtがあるかを確認してください。あるなら、それがあなたのrobots.txtです。そこで編集するか、削除してWordPressに任せるか、どちらかに決めてください。両方を並行させることが、誰も見つけられない古いサイトマップURLが残る原因です。
なぜ/wp-admin/はブロックし、admin-ajax.phpは許可するのか
/wp-admin/にはダッシュボードが入っています。これらのURLは検索結果では無意味で、クロールさせればログイン画面へリダイレクトされるページにクロール予算を使うことになります。このディレクトリをブロックすることに議論の余地はありません。
admin-ajax.phpはそのディレクトリの中にありますが、管理画面のページではありません。プラグインやテーマがフロント側のAJAXリクエストを処理するために使うエンドポイントです。「もっと読む」ボタン、絞り込み付きの商品一覧、計算ツール、フォームなどがこれにあたります。クローラーがこれを取得できないと、それらの機能が読み込むコンテンツを見られず、Googleは機能が壊れた状態の訪問者と同じ見え方でページをレンダリングすることになります。
自分のサイトでGoogleが実際にadmin-ajax.phpを取得する必要があるかどうかは、フロント側がそれを使っているかどうか次第です。正直に言えば、最近の多くのサイトではまったく関係ありません。テーマが/wp-json/のREST APIを使っているからです。このAllow行は順位を上げる要素ではなく、実在する失敗モードに対する安価な保険です。コストがかからないので、そのまま残しておいてください。
/wp-content/や/wp-includes/はブロックしない
これは、いまだに出回っているrobots.txtの助言の中で断トツに最悪のもので、Googleがまだページをレンダリングしていなかった時代の名残です。
/wp-content/にはテーマ、プラグイン、アップロードした画像、つまりページをページらしく見せるスタイルシート・スクリプト・画像が入っています。/wp-includes/にはプラグインが依存するコアのJavaScriptが入っています。Googleは評価の前に、ヘッドレスブラウザーでページをレンダリングします。これらのディレクトリをブロックすると、レンダラーが受け取るのはCSSも画像もないページです。Googleが評価するのはレイアウトの崩れた無装飾の文字の壁になり、コンテンツの理解の仕方にもモバイルユーザビリティの評価にも影響します。
こうした行が書かれたファイルを引き継いだなら、削除してください。
Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/被害は自分で確認できます。Google Search ConsoleのURL検査ツールで任意のページのライブテストを実行し、レンダリング結果のスクリーンショットを見て、ページリソース一覧にブロックされた項目がないか確認してください。CSSがブロック扱いになっていれば、それが原因です。
Sitemapの指定
1行、絶対URL、そしてファイル内のどこに置いても構いません。User-agentのグループには紐づかないからです。
Sitemap: https://example.com/wp-sitemap.xml実際に開けるURLを使ってください。WordPressコアはwp-sitemap.xmlを配信します。ほとんどのSEOプラグインはコアのサイトマップを無効化し、たいていはsitemap_index.xmlのような別のパスで自前のインデックスを配信します。書き込む前にブラウザーでURLを読み込んでください。404を指すSitemap行は、行がないより悪いものです。監査上は正しく見えてしまうからです。
複数のサイトマップを1行ずつ並べても問題ありません。Search Consoleでのサイトマップ送信も、別途やる価値があります。robots.txtの指定は、あなたのSearch Consoleアカウントを見ることのないクローラーがサイトマップを見つける手段です。
robots.txtはnoindexではないし、セキュリティでもない
robots.txtによる被害のほとんどは、この2つの誤解から生まれます。
URLをブロックしても、Googleから消えるわけではありません。 robots.txtが管理するのはクロールです。他のサイトがブロック済みのURLにリンクしていれば、GoogleはそのURL自体をインデックスできます。結果として、素のアドレスと「情報がありません」という注記だけの検索結果になります。さらに厄介な罠があります。すでにnoindexのmetaタグが入っているページをrobots.txtでブロックすると、Googleはクロールできずnoindexも見られないため、そのページがいつまでもインデックスに残り続けることがあります。ページを削除したいなら、クロールを許可したうえで、ページのhead内にnoindexのmetaタグを置くか、X-Robots-TagのHTTPヘッダーを返してください。Googleは2019年に、robots.txt内のnoindex指定のサポートを終了しています。
パスをブロックしても、それを保護することにはなりません。 robots.txtは定義上、公開されています。/private-client-files/と書くことは、すべての訪問者とすべてのスキャナーに、どこを見ればよいかを教えることです。そして遵守は任意です。Googleは従いますが、敵対的なボットは従いません。保護が必要なものには、認証、IP制限、あるいは.htaccessのサーバー側ルールが必要です。標的の場所を宣伝するテキストファイルの1行ではありません。
追加する価値のあるルール、飛ばしてよいルール
多くのサイトで本当に役立つ追加は2つです。検索結果のパスをブロックすると、サイト内検索から無限に低品質なURLが生成されるのを防げます。WooCommerceでカートや購入手続きのパスをブロックすると、セッションパラメーター付きのURLがクロール対象から外れます。
Disallow: /?s=
Disallow: /search/次のものは飛ばしてください。
Crawl-delay— Googleは完全に無視します。本当にサーバー負荷の問題があるなら、Search Consoleのクロール頻度の設定を使ってください。/feed/や/trackback/のブロック — 無害なURLですし、フィードは役に立ちます。- 個別のボット名の長いリスト — ブロックしたくなるボットの多くは、そもそも正直に名乗りません。
/wp-json/のブロック — テーマがコンテンツの表示に使っている可能性があります。
ファイルの作成にはWordPress robots.txtジェネレーターを使ってください。最小限の正しい構成を出力し、書式を手で書かずに検索やEC向けのルールを追加できます。
変更したあとに
https://yoursite.com/robots.txtを直接読み込み、実際に配信されている中身が意図どおりか確認してください。プラグインの編集画面に表示されている内容ではありません。そのうえで、Search Consoleで通常のページのライブURL検査を実行し、CSSやJavaScriptのリソースがブロック扱いで返ってこないことを確かめます。Googleはrobots.txtをおよそ1日キャッシュするため、修正はすぐには反映されませんし、ミスもすぐには反映されません。この遅延こそが、本番で試して待つのではなく、慎重に検証すべき理由です。
FAQ
よくある質問
WordPressのrobots.txtには何を書けばいいですか？
必要なのは4つだけです。ワイルドカードのユーザーエージェント行、/wp-admin/へのDisallow、/wp-admin/admin-ajax.phpへのAllow、そしてサイトマップの完全なURLを指すSitemap行。それ以外はすべて任意で、ネット上に出回っている長いブロックリストの多くは、解決する問題より生み出す問題のほうが多くなります。
WordPressはrobots.txtを自動で作りますか？
作りますが、仮想的なものだけです。/robots.txtへのリクエストが来たとき、ディスク上に実ファイルがなければ、WordPressがメモリー上でレスポンスを生成します。中身にはwp-adminのルールと、バージョン5.5以降はwp-sitemap.xmlへのSitemap行が含まれます。サーバーには何も書き込まれません。
robots.txtの中身が、WordPressが出力するはずのものと違うのはなぜですか？
ほぼ確実に、ウェブルートに物理的なrobots.txtファイルが存在しているからです。ウェブサーバーがそのファイルを直接配信し、WordPressは動作しないため、仮想出力もrobots_txtフィルターも何の警告もなく素通りされます。他を調べる前に、サイトのルートに実ファイルがないか確認してください。
robots.txtでwp-contentやwp-includesをブロックすべきですか？
いいえ。これらのディレクトリには、ページの表示に必要なCSS、JavaScript、画像が入っています。ブロックするとGoogleがそれらの素材を取得できなくなり、崩れたレイアウトのページを評価することになります。これは何年も前によく言われた助言で、いまでは明確に有害です。
robots.txtでページをGoogleに載せないようにできますか？
できません。robots.txtが制御するのはクロールであって、インデックスではありません。ブロックしたURLでも、他のページからリンクされていれば説明文なしの状態で検索結果に出ることがあります。インデックスから外したいなら、クロールを許可したうえでnoindexのmetaタグかX-Robots-Tagヘッダーを返してください。
robots.txtはセキュリティ対策になりますか？
なりません。むしろ逆です。このファイルは yoursite.com/robots.txt で誰でも読めるため、非公開のディレクトリを書くことはその場所を宣伝することになります。行儀のよいクローラーは自主的に従いますが、悪意あるスキャナーは完全に無視します。守るべきパスは、認証やサーバー側のルールで保護してください。