Manual:robots.txt/ja
robots.txtファイルはRobots Exclusion Standardに含まれ、Search engine optimization (検索エンジン最適化)を補助します。インターネットボットにサイトのインデックス作成 (index, crawl) の方法を指示します。robots.txtファイルは必ずドメインのwebルートに置きます。
例
インデックス作成をすべて回避
ご利用のサイトで一切のボットにインデックス作成をさせないためには、以下のコードを使用します:
User-agent: *
Disallow: /
特定のスパイダーのみブロックする場合は、アスタリスク(記号「*」)にスパイダーのユーザーエージェント名を代入します。
ページ以外のインデックス作成を防止
MediaWikiが生成するページには実在の人間しか利用しないものが多くあります: 古いリビジョンや差分ファイルは記事内のコンテンツを複製しがちです。 編集ページとおおかたの特別ページは動的に生成される結果、実在の人間の編集者のみが使用でき、サーバには比較的、負荷が高めです。 指示がない限り、スパイダーはそのようなページでも数千回索引付けを試み、ウェブサーバに高い負荷をかけてしまいます。
短縮URLあり
もしウィキペディアに似た形式の短縮URLを採用していると、記事ではないページにスパイダーのインデックス作成を防止するのは難しくありません。
記事は /wiki/Some_title
経由でアクセスし、その他は /w/index.php?title=Some_title&someoption=blah
経由で利用可能だとした場合:
User-agent: *
Disallow: /w/
ただし、ご注意! 次の行を間違えて追加してしまうと:
Disallow: /w
/wikiディレクトリへのアクセスをブロックしてしまい、検索エンジンに無視されてしまいます!
またこの解決策だとCSSもJavaScriptあるいは画像ファイルもブロックしてしまい、Google他の検索エンジンがウィキ記事のプレビューをレンダリングできません。
それを回避するにはブロックの対象を /w
ディレクトリ全体ではなく、index.php
にのみ限定します:
User-agent: *
Disallow: /w/index.php?
こうすると、/w/load.php
経由で CSS や JavaScript が検索されるため検索対象からの脱落を回避できます。
また、 Wikimedia系のプロジェクトでも同じ結果が出ます:
User-agent: *
Allow: /w/load.php?
Disallow: /w/
短縮URLなし
短縮 URL を使用しない場合、ロボットの制約方法は少し難しくなります。CGI として PHP を走らせていて、 URL を短縮していない場合、記事へのアクセスは /index.php?title=Some_title
経由で検索できます:
User-agent: *
Disallow: /index.php?diff=
Disallow: /index.php?oldid=
Disallow: /index.php?title=Help
Disallow: /index.php?title=Image
Disallow: /index.php?title=MediaWiki
Disallow: /index.php?title=Special:
Disallow: /index.php?title=Template
Disallow: /skins/
PHP を Apache モジュールとして走らせても URL を短縮していないと、記事は /index.php/Some_title
経由で検索できます:
User-agent: *
Disallow: /index.php?
Disallow: /index.php/Help
Disallow: /index.php/MediaWiki
Disallow: /index.php/Special:
Disallow: /index.php/Template
Disallow: /skins/
名前空間の行末にコロン (:)がない場合、トークページが制限されます。
英語以外のウィキでは、上記の各行にそれぞれ翻訳を添える必要があるかもしれません。
外装に属する画像を表示するには、/skins/
の制限を採用しないという選択をします。
/skins/
ディレクトリにアクセスできないと、Google 等プレビュー画像を提供する検索エンジンにおいては記事の画像が表示されません。
他の方法として
Disallow: /*&
このようにワイルドカード拡張を適用すると、Googlebot等のロボットがrobots.txt標準に受け入れることから、ちょうど前出の /w/ 解決策同様、ロボットに検出させたくないもののほとんどを対象外にします。
ただしこの方法でもCSS検索をブロックしてしまうことから同様の制限を受け、検索エンジンがプレビュー画像を正しく表示できなくなります。
その回避策として Allow: /load.php
という1行を追加することは可能ですが、この原稿の執筆時点ではテストが済んでいません。
インターネットアーカイバに生のページを索引化を許可
インターネットアーカイブにraw pages加工していないページを索引付けさせて、ページの生のウィキテキストを永遠に記録しようと考えることでしょう。この方法だと、ウィキがアクセス不能に陥った場合も別のウィキに簡単にコンテンツを載せることができます。その場合の処理は:
# Allow the Internet Archiver to index action=raw and thereby store the raw wikitext of pages
User-agent: ia_archiver
Allow: /*&action=raw
問題点
レートの管理
ボットがスパイダーできる範囲は、パスのみ指定できます。平文のページ領域のみ許可するだけでも、1秒間に2、3ページを読み込むスパイダーが20万ページを処理しようとすると、大きな足かせになります。
ボットによってはカスタムの仕様があります。例えばInktomiの場合、ヒット数の最小遅延時間を秒単位で指定できる「Crawl-delay」行に反応します(既定は15秒。)
悪意があるボット
カスタム作成のボットの中には、あまり賢くない処理や、完全に悪意のあるものが含まれ、robots.txtにまったく従わないものです(あるいはパスの制限に従ってもスパイダーが非常に速いせいでサイトが減速してしまいます)。特定のユーザエージェントの文字列または違反者の個々のIPをブロックする必要があるかもしれません。
繰り返し操作しなくても、request throttlingでそのようなボットを停止させる方法が、より一般的です。
代替策あるいは補完的な戦略として、spider trapを配備します。
スパイダリング vs 索引付け
robots.txtは(悪意のある)ボットのURLのダウンロードを止めても、索引付けを阻止することはできません。
つまりそれらを指し示す外部リンクが存在する限り、Google等の検索エンジンの結果に表示される可能性があります。
(さらに悪いことに、ボットはページをダウンロードしないため、noindexメタタグを与えても効果はありません。)
単ページのwikiページを検索結果に表示させないためには、__NOINDEX__
マジックワードがより安全な選択肢になるかもしれません。