robots.txtについて私が間違っていたこと

 (evgeniipendragon.com)
8 ポイント 投稿者 GN⁺ 2025-07-23 | 1件のコメント | WhatsAppで共有
  • robots.txt の設定でウェブサイトのクローラーを全面的に遮断しようとしたところ、予想外の副作用を経験した
  • LinkedIn の投稿プレビューが表示されなくなり、投稿の到達範囲も減少していることを確認した
  • 原因は robots.txt が LinkedInBot のページアクセスを妨げ、メタタグの収集を阻害していたためだった
  • Open Graph Protocol がソーシャルメディアでプレビューを生成する際に重要な役割を果たしていることを改めて認識した
  • robots.txt を部分的に許可する方式へ修正して問題を解決し、今後機能変更時には十分なテストが必要だと実感した

はじめに: robots.txt 設定と意図しない問題の発生

  • 最近、ブログで robots.txt の設定を学びながら、自分のコンテンツに対するデータ権利の問題について考えた
  • ウェブサイト上のすべてのクローラーを遮断しようとして robots.txt を修正した
  • その結果、予想していなかった望ましくない結果がウェブサイトで発生した

LinkedIn の投稿プレビュー問題

  • robots.txt を変更した後、LinkedIn に自分のブログリンクを投稿すると**プレビュー（サムネイル、要約文）**が表示されなくなった
  • それまでは正常にプレビューが提供されていたが、変更後は露出と反応が急激に減少した
  • 最初は一時的な問題だと思ったが、2週間以上この現象が続いた
  • LinkedIn Post Inspector で分析したところ、robots.txt が LinkedInBot のアクセスを制限しているため、メタ情報を取得できないことが判明した
  • ソーシャルメディアのプラットフォームでは、リンクプレビューの生成のためにページへのリクエストとメタタグの収集が不可欠である

Open Graph Protocol の紹介

  • Open Graph Protocol（OGP）は Facebook が作った標準プロトコルで、ウェブページをソーシャルグラフオブジェクトにしてくれる
  • OGP は最低限必要なメタタグを定義している
    • og:title: 投稿タイトル
    • og:type: オブジェクトの種類。例: "video.movie"
    • og:image: サムネイル画像の URL
    • og:url: そのオブジェクトを代表する URL
  • このプロトコルにより、さまざまなソーシャルプラットフォームでコンテンツが効果的に要約され、魅力的に表示されるようになる

robots.txt の部分的な許可で解決

  • 問題を解決するため、robots.txt をLinkedInBot のみ許可する方式に修正した
  • もし他のソーシャルプラットフォームのプレビューも必要であれば、それぞれのボットを個別に許可する必要がある
  • 現在適用している設定例: 
    User-agent: LinkedInBot
Allow: /

User-agent: *
Disallow: /

振り返りと学んだこと

  • すべてのクローラーを無条件に遮断すると、コンテンツの露出や表示方法に問題が生じる可能性がある
  • 変更の効果について十分なテストを行わずに対応したのは自分のミスだったと認識した
  • 今回の経験で Open Graph Protocol、LinkedIn Post Inspector などの有用なツールやウェブ標準について、より深く知ることができた
  • 機能の追加・変更時には、影響範囲全体について十分に理解し検証する必要がある
  • 当初は OGP と robots.txt による遮断の関係を結びつけられなかったが、この経験を通じてその重要性を認識した

関連記事

1件のコメント

 
GN⁺ 2025-07-23
Hacker Newsの意見

  • 以前は robots.txt の主な目的は、検索エンジンで重複コンテンツのペナルティを防ぐことにあった。管理しづらい動的サイトを運営していると、クエリパラメータなどのせいで同じページが複数の URL で露出し、検索エンジンでペナルティを受けていた。robots.txt は「これが正規 URL なので、残りは無視してほしい」と伝える役割だった。このほかにも、「行儀のよい」クローラーが無限リンクのクロールで迷い込まないよう助ける役目もあった。もちろん「悪い」クローラーは気にもしなかったので、そうしたボットは IP ブロックなどで防いでいた。User-Agent ベースの遮断には意味がなかった。悪意あるボットが素直に規則を守ると信じるのは甘い考えだ。DNT(Do Not Track) ヘッダーも同様で、追跡を商売にしている企業に「追跡しないでください」とお願いするようなものだ。あるいは、悪意あるパケットが自分でヘッダーに「自分は悪性です」と書いてくれることを期待する RFC の Evil Bit のアイデアにも似ている

    • Evil Bit の提案はエイプリルフール RFC だったことを覚えておくべきだ RFC 3514 を見る

    • 結局 robots.txt はサイトマップ(sitemap)と役割が似ているのかとも思ったが、実際には正反対だ。robots.txt はクローラーがアクセスしてはいけない場所を、sitemap はインデックスしてほしい場所を知らせる。重複コンテンツのペナルティ管理という本来の目的は知らなかったので、SEO コントロールを見る視点に新しい文脈が加わった気がする

    • 要するに、ある行動を「禁止」と宣言すると、効果があるのは一部の正直な相手か、うっかり User-Agent 名を適切に隠していない場合だけだ。それ以上にはあまり効かず、結局はやや象徴的な措置にすぎない

    • DNT ヘッダーのように、現実的には実行不可能に見える試みはしばしば批判されるが、実際には DNT のアイデアは法的な仕組みと併せて適用しようとした試みだった。完全な技術的遮断が難しくても、大規模に違法行為を続けていれば、結局は内部告発で明るみに出る可能性があることは考慮すべきだ

    • ルールを決めれば皆が守ると信じている人たちがいるが、それが文化的な違いに由来する信念なのか疑問に思うこともある

  • 2003年に自分で検索エンジンを作って Web をクロールしたことがある。代表メールアドレスを User-Agent に入れたところ、本当に大量の抗議メールを受け取った。自分としてはできる限り誠実で礼儀正しいクローラーを作ったつもりだったが、人々は Google でなければ望まないのだと感じた。こうした態度こそが Google に対抗する競争相手の登場を妨げるやり方だ。LinkedIn のプレビュー問題に限らず、Web は多様なボットとユーザーに対して開かれているべきだという点を考える必要がある。もちろん悪質なクローラーは防ぐべきだが、すべてのボットを最初から悪意あるものとして扱う姿勢は望ましくない

    • ボットを善良に運用する立場として最も腹が立った経験は、誰かが自分のボットの User-Agent を使って悪性ボットを作り、攻撃したせいで自分のところに抗議が来たことだ

    • 誰もが自分のボットを守りたいと思うかもしれないが、実際には自分のボットだけの問題ではなく、同じようなボットが 9000 個ほど出回ってサーバー資源を過剰に消費することが問題だ。こうしたボットは実際にはリファラルトラフィックも持ってこない

    • 自分も最初のころはすべてを遮断するアプローチを取っていたが、Web の相互接続性と複雑さに気づくようになった。自分のリソースに対する主導権を持つことは重要だと思う。ただし、望むトラフィックを許可するのか遮断するのかを決めるときは、自分自身に「なぜか」と問い、各ボットが何をしているのかを知る必要がある。こうした過程には時間と労力がかかる。AI 企業がデータ学習目的で無差別にクロールする慣行のために、robots.txt に初めて関心を持った。自分は許可するか遮断するかを自分で選びたい。すべてのボットが robots.txt を守るわけではないが、かなりの数は従う。自分で試せる方法のひとつは、ブラウジング対応モデルに特定リンクのスクレイピングを依頼してみることだ。根本的には、ボットが悪質かどうかは、その会社がデータをどう使うかと、自分がそれをどう感じるかのほうが重要だ

    • 「すべてのボットが悪性ではないのだから無条件に止めるな」という主張に対して、私は基本的に信頼する根拠なくアクセスを許すのは危険な戦略だと思う

    • 正体不明のクローラーを疑うのは当然だ。大半のクローラーは悪質で、善悪を事前に見分ける方法もないのだから、基本的に知らないボットを暫定的に悪性とみなすのが理にかなっている

  • 批判的な意見は控えるよう努めているが、この記事は著者が自分の行動の結果にあまりにも大げさに気づいたふりをしているようで驚く。個人の成長物語にも意味はあるが、この記事は洞察というより無知の告白に近い。結局、注目を集めたくて書いたように感じる

    • 著者はページプレビューの fetcher をクローラーとして認識しておらず、robots.txt で遮断することも考えていなかったのだ。ありふれた内容ではないにせよ、少なくとも本人にとっては新しく学ぶ点があった。実際に人が直接書いたブログ記事は、Web 全体の平均的な品質を高め得ると思う

    • Google に露出しないので、ここ(Hacker News)に投稿したのだ

    • 自分にとっても実質的に新しく感じられる部分があった。Open Graph Protocol と Robots Exclusion Protocol をさらに学ぶきっかけになった。自分で学んだり興味を持ったことは記録して共有するほうだ。他の人にとっても面白いかもしれないと思って共有した

    • この記事がどうしてフロントページに上がったのか疑問だ。「水をせき止めれば善良なやつは避け、悪いやつは無視する」という、あまりにも当たり前の話を長々と書いたように思える。結局 robots.txt は丁寧な「やめてください」にすぎず、ファイアウォールではないという点は自明だ

  • robots.txt の問題は、結局クローラーの目的ではなく、クローラーの「正体」に依存してフィルタリングすることだ。著者も AI 収集を防ぐためにすべてのボットを止めたが、OpenGraph プレビュー用クローラー(LinkedIn など)は再び許可した。だが Twitter や Mastodon など他のプラットフォームで共有されたらどうするのかという問題もある。すべてのソーシャルメディアの UA をいちいち許可しなければならず、これは結局少数の大手プラットフォームだけに有利な構造だ。本質的には「AI 学習は止めるが、検索インデックス、プレビュー、アーカイブなどは許可する」手段が必要だ。これを実質的に執行するには法的枠組みが必要になるだろうが、それも簡単ではない

    • robots.txt の本来的な用途についての議論は常にあった。私の考えでは、もともと(そして今でも)大半はクローラー(リンクをたどって新規探索する動作方式)専用だ。検索エンジンが代表例だ。しかしユーザーが直接特定 URL を要求する場合(例: ブラウザ、iCal 購読など)は、robots.txt に従う必要はない。実際、Google Calendar のようなサービスが robots.txt の遮断に引っかかって購読できないこともあったが、それは誤った動作だと思う。URL プレビューの場合、ユーザーが単一リンクだけを要求するなら、それはクロールではなく特定リクエストに近い。ただし長文メッセージに複数リンクがあるなら、それもある種のクロールに近くなる。結論として、ソーシャルメディアの URL プレビュー機能が robots.txt に従うべきかどうかは、まだ曖昧だと思う

    • Common Crawl のようなデータは検索エンジンにも AI 学習などにも再利用され得る。用途を区別するのは簡単ではない

    • 情報共有の方式を in-band ではなく out-of-band に分ければ解決できる。Open Graph メタデータを別経路/ヘッダーで提供すれば、その経路(大して価値のないデータ)は許可し、本文コンテンツは強く拒否できる。法的フレームワークが必須というわけではない

    • 機能別・目的別に分類して許可/遮断できる標準を作るというアイデアは気に入っている。ただし、機能検証とスプーフィング防止が鍵で、結局は法的問題も絡む。実際にはソーシャルメディアのプレビューなど、さまざまなプラットフォームに再び許可を出さなければならなそうで、何を許可し何を遮断するかを慎重に選ぶ過程で多くを学んでいる。こうしてさまざまな意見を聞くこと自体が大きな参考になっている

  • OP へ。1) LinkedIn だけを想定していたかもしれないが、実際には Facebook、Bluesky など他のソーシャルメディアでも自分のリンクが共有され得る。Facebook の ai.robots.txt でも、FB プレビュー用クローラーまでまとめて遮断してしまうことがある(ai.robots.txt の例)。

  1. Google 順位と robots.txt 遮断の関係では、robots.txt で検索露出を止めても間接リンクなど別要因はあるが、直接クロールを許可するほうが Naver/Google SEO には基本的にはるかに有利だ。遮断すると検索結果でサムネイルや説明が出ず品質が落ちる。検索エンジントラフィックが重要なら、robots.txt での完全遮断は慎重に考えるべきだ

  • フィードバックありがとう! 1) 私も LinkedIn と HN しか考えていなかった。他の人が自分のブログリンクをさまざまなプラットフォームで共有するという点を見落としていた。複数プラットフォームへのアクセス許可を見直す必要があるかもしれない。2) 検索エンジンのトレンドが AI 要約中心に向かっているのを見ると、今後はサイト自体へのオーガニック流入は減るだろうと思う。だから Google 検索トラフィックの減少はそれほど惜しくない。今後考えが変わるかもしれないが、現時点では HN とソーシャル共有による口コミ効果のほうが、自分のブログにはより意味のあるトラフィックをもたらすと見ている。自分の決定が自分の足を引っ張らないか、追加でもう少し調べてみるつもりだ。さまざまな意見が意思決定に大いに役立っている

  • robots.txt で「クロール」と「インデックス」を混同して起きる別の副作用がある。
    新しいページを Google インデックスに根本的に載せないようにするには、robots.txt の遮断が有効だ。
    しかし、すでにインデックスされているページを削除しようとして robots.txt にだけ追加するのは誤りだ。Google はクロールできないため、メタデータなしのまま検索結果に出し続け、noindex メタタグも確認できないので、結果的に長期間検索に残ることがある。Google が後になってそのページを完全に削除することもあるが、この過程は非常にもどかしい

    • Google は robots.txt によって遮断された URL を外部リンクなどから知ることがあり、この場合クロールできなくてもインデックス済みの記録が結果に残ることがある(警告参照: Google 公式文書)。検索結果から完全に削除するにはコード内に noindex タグを必ず入れる必要があり、robots.txt で遮断するとこのタグも読めないので注意が必要だ

    • 私の場合、Google がインデックスから削除することを必ずしも望んではいない。インデックスには無関心で、クロールとスクレイピングだけを気にしている。用語を混同して使っていたことは認める

  • この記事は、本題だけなら一、二行で済む話をあまりに引き延ばして書いた感じがする。まるで学生時代の文字数稼ぎのようだ

    • 問題は一段落で説明できたはずだ。私の文章の目的は、自分の経験と問題、リサーチ、そして解決策に至るまでの道のりを記録することにあった。技術の専門家でない人でも追えるよう、できるだけ詳しく書いたのだ

  • robots.txt の根本的な限界は、実際に問題なのが robots.txt を守るボットではなく、守らないボットだということだ。robots.txt は今日のトラフィック問題を起こしているボットの大半を制御できない。サーバーを傷めるような悪質ボットほど robots.txt をまったく気にしない

    • こうしたボットを捕まえるには「ハニーポット」が有効かもしれない。robots.txt で /honeypot パスを明示的に禁止し、index.html に display:none 処理した <a href="/honeypot">ban me</a> リンクを追加する。このパスにアクセスした IP は即座に遮断すればよい

    • なぜ低評価されたのかわからない。OpenAI、Anthropic など主要企業が robots.txt をどれほど忠実に守っているのか信頼する根拠がない。これらの企業はトラフィックを住宅用 ISP の IP に迂回させるなど、検知自体を難しくし、「第三者広告」を通じて直接追跡を回避する形で責任を分散している

  • 最も衝撃的なのは、robots.txt と meta robots タグを同時に解釈し、衝突した場合にどの優先順位で許可/遮断すべきかについて、よく整理されたパーサーライブラリがほとんど存在しないことだ。公式の Google リファレンスパーサーは C++11 ベースという珍しい存在で、実際によく使われる Python や JS 向けライブラリでは開発者が別途実装しなければならない状況だ。しかも meta robots のような情報は robots.txt ファイルではなく index.html の内部に隠れている。ボット作者が道徳的にきちんとやろうとしても、実装難易度のせいで難しいのが問題だ

    • Python 標準ライブラリには urllib.robotparser がある(公式文書)。一方で rel=nofollow は robots.txt とはまったく別の目的だ。この属性は、そのリンクについて検索エンジンが「信頼(リンク価値の付与)」しないでほしいという意味であり、「このリンクをたどるな」という意味ではない(詳細説明)。本来の意図は、スパムコミュニティで無差別に自分のサイトへのリンクを残す行為を防ぐことだった

    • リソースに余裕のない「善良な」ボット開発者は、サーバーを無差別に叩きまくるわけではないので、実際にはライブラリ不足で大きく困ることはあまりない

    • 善意でまともなボットを作りたいなら、パーサーライブラリを自分で他言語向けにオープンソース化して公開することも十分可能だと思う。難しいことではない

  • 面白いことに Apple はこの問題に別のアプローチをしている。iMessage でリンクを共有するときは、「送る側」のクライアントが直接プレビューを取得して作成する。LinkedIn のようなサービスがサーバー側で直接リンクデータを取りに行く理由(スパム、フィッシング防止など)はあるのだろうが、たしかに変わった方式だ

    • 私も、メッセージ内リンクを受け取った後にクライアントが直接プレビューを生成するのは合理的だと思っていたし、すでに誰かがその点を指摘しているだろうとも思っていた。ただしサーバーが直接スクレイプする理由も理解できる。1) すべてのページを取得して活用できる将来に備えるため。2) ページが変わったり 404 になったり、クライアント側データベースが失われた場合でも、サーバーは事前に抜き出したプレビュー情報を返せるため。3) クライアント側でプレビューを作らなくても、メッセージと一緒にすばやく見通しを示せるため。結局、iMessage のように「送信者」がプレビューを作る方式なら、このうち残るのは「1」と「2 の一部」だけで、サーバーが再試行を続けるほうが信頼性の面ではよりよい選択かもしれない