robots.txtとは何ですか？

robots.txtがどこにあるかと、それが何を管理するか

Robots.txtは、クロールされているオリジンのルートパスから取得されます。 ロボット排除プロトコル ファイルの場所を定義し、参加するクローラーがそれをどのように解釈するかを示します。

起源の境界は重要です。サブドメインは、メインホストとは異なるルールファイルを持つことができます。HTTPとHTTPSは別々のスキームであり、別のポートは別の起源を特定することができます。同じブランドであるからといって、ダウンロードしたファイルを関連するすべてのアドレスに適用しないでください。

在庫の仕事において、各ルールの決定をどの起源から供給されたかを記録します。ページが他の場所にリダイレクトされる場合、その宛先をその宛先に関連するポリシーの下で評価します。開始URLの適格性は、起源の変更によって自動的に移行するべきではありません。

ファイル名はプロトコルパスであり、フォルダ固有の規則ではありません。コンテンツのサブディレクトリ内に配置されたファイルは、そのオリジンのルールファイルを置き換えることはありません。サイトの所有者は、クローラーがそれを読む場所にルールが保存されたと仮定するのではなく、実際の場所と応答を確認するべきです。

クローラーグループとパスマッチング

Robots.txtは、ユーザーエージェントグループを許可および拒否のパスルールに関連付けます。クローラーは、その製品アイデンティティに適したグループを選択し、プロトコルに従ってURLパスを評価します。

The User-agent クローラーのフィールド名は、グループの製品トークンです。 * フォールバックグループを提供します。名前付き製品のルールとフォールバックは、無差別に単純に統合されるわけではありません。ファイルを検索するための文字列のリストとして扱うのではなく、定義されたマッチング動作を実装してください。

Disallow クローラーが取得すべきでないパスにマークを付けます。 Allow より具体的な許可されたパスを特定できます。複数のルールが一致する場合、最も具体的な一致が優先されます；等しく具体的な許可ルールは、プロトコルの下で優先されます。

パスマッチングは、実際のURL表現に対して敏感です。大文字小文字やパーセントエンコーディングが重要になる場合があります。すべてのパスを小文字に変換する単純な比較は、判断を変更する可能性があります。標準に一致する動作を持つパーサーを使用し、代表的なURLを検証してください。

プライベートに見えるフォルダの例はあくまでクローリングの指示であり、そのフォルダが実際にプライベートであることの証明ではありません。開示自体が問題を生む場合、公開ファイルにセンシティブなパス名を掲載するのは避けてください。

ワイルドカード、エンドアンカー、および拡張

コアロボットルールはパターン機能をサポートしていますが、一般的に見られるいくつかのフィールドは、メインの許可/不許可解釈の外部にある拡張機能です。標準とクローラーの実装の両方を確認してください。

アスタリスクはパターン内のシーケンスに一致し、ドル記号は一致の終わりを固定できます。これらの機能は、パスプレフィックスを完成したパターンと区別するのに役立ちます。一般的な正規表現のようにパターンが振る舞うと仮定するのではなく、意図された許可されたリソースと許可されていないリソースをテストしてください。

A Sitemap フィールドは、クロールャーを公開されたリソースインベントリに指し示すことができます。そのインベントリは発見を助けますが、URLをリストすることは適用可能な拒否ルールを無効にするものではありません。発見と取得の許可は別々の決定として残ります。

Crawl-delay はコアプロトコルの下での普遍的なレート制御指示ではありません。そのサポートはクローラーに依存します。サイトオーナーはサーバー容量を強制するためにこれだけに依存すべきではなく、クローラーオペレーターは独自の適切な集約ペーシングを確立すべきです。

申し訳ありませんが、お手伝いできる情報が不足しています。翻訳したい具体的なテキストを提供していただけますか？ Googleのrobots.txtガイドライン 検索クローラーの役割と制限について説明します。コアルール外のフィールドが設定に影響を与える場合は、クローラー固有のドキュメントを使用してください。

不明なフィールドは、捏造された権限になってはなりません。従来の指示と専門的な指示が混在するファイルを解釈するときは、適用可能な標準ルールとあなたのプロジェクトポリシーを明示的に保ってください。

Robots.txt、noindex、および認証

Robots.txt、インデックス作成ディレクティブ、認証は、それぞれ異なる問題を解決します。サイトの所有者は、意図された結果に一致する制御を選択する必要があります。

許可されていないURLは、他のページからのリンクによって知られることがあります。検索システムは、完全なコンテンツを取得していなくてもURLを表示することがあります。クロールをブロックしてもインデックスからの削除は保証されません。

ページがそのコンテンツ内でnoindex指令に依存している場合、検索クロールがページを取得できないようにすると、指令を見ることを防ぐことができます。関連する検索システムの動作を念頭に置いてインデックス制御を計画してください。

その robots.txtとインデックスの区別 は境界を説明するのに役立ちます。プライベート情報の場合は、ボランタリーなクロール者の行動に依存するのではなく、適切なアクセス制御を使用します。

欠落したルールと取得失敗

クローラーは、robots.txtを取得する際の定義されたポリシーと、成功したファイルを解析するためのものが必要です。異なる失敗状況には、プロトコルの下で異なる意味があります。

標準は、サーバーまたはネットワークの障害によって引き起こされたアクセス不能なルールファイルを、使用できないルールファイルと区別します。クライアントエラーの応答は、プロトコルの利用できないファイル処理の下でアクセスを許可できる一方で、アクセス不能状態はリソースを許可されていないとして扱う必要があります。関連する標準の動作や任意の厳格なプロジェクトポリシーを実装してください。

空のダウンロードを制限が存在しない証拠として解釈しないでください。応答の分類と最終目的地を確認してください。エラーページ、接続の失敗、または無関係なリダイレクトには独自の処理が必要です。

プロトコルと進行中のジョブのニーズに基づいてルールをキャッシュします。証拠が重要な場合は、どのルールバージョンがコレクション決定に影響を与えたかを記録してください。長期的なプロジェクトは、古いファイルを無期限に使用するのではなく、重要なポリシーの変更を認識する方法を持つべきです。

欠落したファイルも法的許可を確立しません。プロトコルはクロール者の行動を説明しますが、ウェブサイトの契約、コンテンツの権利、およびデータ保護はまだ別個にレビューする必要があります。プロジェクトの厳格な許可ポリシーは、プロトコル自体が取得を許可する場合でもコレクションを停止することができます。

サイト所有者としてのrobots.txtのテスト

サイト所有者は、ロボットルールを具体的なURLおよび意図されたクローラーの識別子に対してテストするべきです。文法的に有効なファイルは、誤ったセクションをブロックしたり、意図した制限と一致しない可能性があります。

各境界の両側のケースを準備します。パスプレフィックスがエリアを制限することを意図している場合、そのエリア内のリソースと同様に名前の付けられたリソースを含めます。実際のURL構造に影響を与える場合は、大文字と小文字のバリエーションやクエリのバリエーションを追加してください。

意図したオリジンへの展開を確認してください。正しいステージングルールが、本番環境が同じファイルを提供しているという証拠ではありません。変更後にファイルの最終的な位置と内容を確認し、リダイレクトの動作も含めます。

意図されたインデックスの結果を別々にテストしてください。クロールを停止するルールは削除要求ではなく、認証を置き換えるものではありません。インデックスの管理とプライベートリソースのサーバー制御のために関連する検索制御を選択してください。

ファイルの所有権を明確に保ちます。コンテンツの移行やインフラの変更により、パスやホストが変更される可能性があるため、以前に機能していたルールが現在のサイトを記述しないことがあります。各重要な制限が存在する理由の簡潔な記録を保持してください。

データ収集プロジェクトでのロボットルールの使用

データ収集プロジェクトは、候補リソースを取得する前にロボットの決定をスコープ制御に組み込むべきです。オリジン、クローラーのアイデンティティ、ルールの証拠、および除外理由を一緒に保持してください。

説明的な文書クロールの場合、オペレーターは承認されたシードから始まり、文書オリジンのルールを読み、候補を適格または除外としてマークします。ジョブは、静かにカバレッジの主張を減らすのではなく、除外を報告します。

Scrapelessウェブサイトクロール は管理されたコレクションの表面を説明します。あなたのジョブに対する実際の設定とポリシー処理を確認してください。この文書は、すべてのプロバイダー設定が自動的にすべてのクロールルールを強制するとは主張していません。

Scrapelessエージェントブラウザ はブラウザベースのコレクションの実行を提供します。実行レイヤーは、プロジェクトの許可されたソーススコープ内で操作します。 Scrapelessの価格設定 は、そのスコープが必要とする作業のためのものです。

関連する robots.txt解釈の記事 はさらなる文脈を提供します。正確なマッチング動作のために現在のプロトコルとクローラー文書を使用してください。特に歴史的な例が非標準フィールドを普遍的な制御として記述する場合です。

ポリシーが訪問を妨げる場合、その結果を意図された除外として記録します。それは有効な空の抽出結果やソースがデータを含まないという主張に変換されるべきではありません。

結論

robots.txtは、クロール者グループとパスルールを通じてオリジンに対するクロールの好みを伝えます。それをプロトコルを使用して解釈し、実際のURLに対してテストし、それに伴う制限を明確に保ちます。

サイト所有者にはプライベートな素材に対するアクセス制御と、検索結果に対する適切なインデックス指示を使用してください。収集オペレーターには除外の証拠を保持し、許可を別個にレビューしてください。これらの区別により、小さなルールファイルが解決するために設計されていない問題を解決することを求められなくなります。

参照

• Scrapelessウェブサイトクローリング設定
• コレクションワークフローのためのエージェントブラウザの実行
• ウェブスクレイピングにおけるRobots.txtの解釈