WordPressでのマルチサイト化に伴いわたしの場合は実際の運用に向けていくつかのハードルがありましたが、ふと疑問に思ったのがrobots.txtでした。
robots.txtの重要性
robots.txtはサイト内の検索エンジンのクローラーをスムーズに巡回させるための案内役であり、不要なコンテンツをインデックスさせないという役割も持っています。
パンダアップデートは重複コンテンツや低品質コンテンツ（内容が薄いなど）を嫌います。このため、カテゴリーやアーカイブなど、とかく類似コンテンツを生成しがちなWordPressにとっては、とくに重要な要素を担っていると思われます。
※robots.txtの処理があまりにも複雑な場合、クローラーがスキップしてしまうということもあるようですので、基本の骨格的なものを定義して、CMS固有の重複コンテンツ対策にはcanonical属性を使うのがよいかもしれません。
robots.txtの書き方自体が分からない方には以下のようなサイトが参考になると思います。
WordPressでのrobots.txt
WordPressでサイト構築した場合、robots.txtはどうすればよいのでしょう？
実はWordPressでは特に何も設定しなくても標準機能で仮想robots.txtというものを出力します。(サーバ上に実際にファイルは存在しない)
内容としては下のように管理ファイルなどにアクセスさせないという最低限の記述となっています。
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xmlそれでは自分のルールが加えられないと思われるかもしれませんが、心配はいりません。WordPressサイトであっても通常のHTMLサイトと同様にサーバのルート階層にrobots.txtをアップロードした場合はそちらが優先されます。
ですから、ルールを加えたければ、自前のrobots.txtをサーバにアップロードすれば問題ありません。
また、robots.txt用プラグインを使うことでも簡単にルールを加えることができます。
※ちなみにfunctions.phpに記述することで仮想robots.txtに追記することができるのですが、テーマ変更に対応できませんし、数が多くなると煩雑なため、ここでは取り上げません。
robots.txtのチェック
robots.txtがサイトの適切な位置に設置されているかは次のようなチェッカーで確認することができます。
もっとも簡単な方法はSearch Consoleのクロールメニューのrobots.txtテスターを使うことです。
「構文が認識できません」とのエラーの場合はrobots.txtの文字コードを確認ください。
文字コードをBOMなしのUTF-8Nとします。
Search Consoleを使っていない場合は以下のようなサイトからでもチェックできます。
（解析を行うURLにチェックしたいサイトのトップURLを入力ください）
上記のようにWordPressの場合は特に自分で設置していなくても、仮想的にルート直下にrobots.txtが確認できると思います。
マルチサイトの場合はどうすればよい？
サブドメイン型
通常のサブドメインサイトの場合はディレクトリが分かれていると思いますので、そのルートにrobots.txtを置けばよいので、とくに問題はありません。しかし、WordPressのマルチサイトの場合は「サブドメインのルートはどこ？」という話になりますね。
自分でrobots.txtの設定をしていない場合には仮想robots.txtが以下のようなURLで認識されます。
http://aaa.example.com/robots.txt
サブドメイン型では仮想robots.txtを書き換えることができるKB robots.txtなどのプラグインを使うのが便利です。（もちろんシングルサイトのWordPressにも使えます）
サブディレクトリ型
robots.txtはドメインのルート階層にしか置くことができないため、こちらは別のサイトであってもルートのrobots.txtに加えます。
WordPressに限らずですが、サブディレクトリ型サイトexample.com/bbb/のrobots.txtはドメインルートになります。
〇→http://example.com/robots.txt
×→http://example.com/bbb/robots.txt
最後に例としてサブディレクトリ型でサイト構築している価格コムを見てみます。
やはり、ルートのrobots.txtにすべてルールとそれぞれのサイトマップへのリンクが記述してあります。
サブディレクトリ型のrobots.txtとして大変参考になります。
User-agent: *
Allow: /auth/profile/
Disallow: /ksearch/
Disallow: /auth/
Disallow: /kuruma/used/uc_jump.asp*
Disallow: /script/segment/
Disallow: /prdsearch/pricehistory_data/
Disallow: /kakakuad/
Disallow: /history/
Disallow: /jump/
Disallow: /ad/
Disallow: /card/jump.asp*
Disallow: /ria/
Disallow: /item/*/localshops/
Disallow: /localshops/shop/*/print/
Disallow: /loan/housing-loan/jump/
Disallow: /BBSsearch/
sitemap: http://kakaku.com/sitemap_kakaku_index.txt
sitemap: http://kakaku.com/sitemap_system_product-item_index.txt
sitemap: http://kakaku.com/sitemap_system_search-item_index.txt
sitemap: http://kakaku.com/sitemap_system_product-itemlist_index.txt
sitemap: http://kakaku.com/sitemap_system_search-itemlist_index.txt
sitemap: http://kakaku.com/sitemap_system_product-images_index.txt
sitemap: http://kakaku.com/sitemap_system_product-kurumaitem_index.txt
sitemap: http://kakaku.com/sitemap_system_product-kurumaitemc_index.txt
sitemap: http://kakaku.com/sitemap_system_product-kurumagrade_index.txt
sitemap: http://kakaku.com/sitemap_system_chosatai-article_index.txt最新の追記：コンテンツ内構成ファイルを隠さない
最新の追記情報です。
最近のGoogleではJavascriptなどプログラムの内容も解析できるようになっています。
そして基本的に「コンテンツ内構成ファイルを隠すな」という趣旨のことをいっているようですね。
WordPressなどのCMSの場合、コアの部分まではクロールさせる必要はないかもしれませんが、低品質や重複を理由に検索結果に表示する必要がないというコンテンツページはrobots.txtでブロックするのではなく、メタタグのnoindexを使う方がよさそうです。
WordPressで任意のページにnoindexをつける方法は下記をご覧ください。
※非公開の会員専用コンテンツなどはrobots.txtで一切のクロールを拒否した方がよいです。
