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 で一切のクロールを拒否した方がよいです。