Những điều tôi đã hiểu sai về robots.txt

• Sau khi thử chặn toàn bộ trình thu thập dữ liệu của website bằng cách cấu hình robots.txt, tôi đã gặp phải tác dụng phụ ngoài dự kiến
• Phần xem trước bài đăng trên LinkedIn biến mất, và tôi cũng nhận thấy mức độ tiếp cận của bài viết giảm xuống
• Nguyên nhân là vì robots.txt đã chặn LinkedInBot truy cập trang, khiến nó không thể thu thập thẻ meta
• Tôi nhận ra rõ hơn rằng Open Graph Protocol đóng vai trò cốt lõi trong việc tạo phần xem trước trên mạng xã hội
• Tôi đã sửa robots.txt theo hướng chỉ cho phép một phần và giải quyết được vấn đề, đồng thời nhận ra cần phải kiểm thử đầy đủ khi thay đổi chức năng trong tương lai

---

Mở đầu: Cấu hình robots.txt và trải nghiệm với sự cố ngoài ý muốn

• Gần đây, khi tìm hiểu về cấu hình robots.txt trên blog, tôi bắt đầu suy nghĩ về vấn đề quyền dữ liệu đối với nội dung của mình
• Tôi đã chỉnh sửa robots.txt để chặn tất cả crawler trên website
• Không ngờ rằng điều này lại dẫn đến kết quả ngoài mong muốn trên website

Vấn đề với phần xem trước bài đăng trên LinkedIn

• Sau khi thay đổi robots.txt, khi tôi đăng liên kết blog của mình lên LinkedIn, phần xem trước (thumbnail, đoạn tóm tắt) không còn hiển thị
• Trước đó phần xem trước vẫn hoạt động bình thường, nhưng sau thay đổi thì mức độ hiển thị và tương tác giảm mạnh
• Ban đầu tôi nghĩ chỉ là sự cố tạm thời, nhưng hiện tượng này kéo dài hơn 2 tuần
• Khi phân tích bằng LinkedIn Post Inspector, tôi phát hiện robots.txt đã hạn chế quyền truy cập của LinkedInBot, khiến nó không thể thu thập thông tin meta
• Trên các nền tảng mạng xã hội, để tạo phần xem trước liên kết, việc gửi yêu cầu tới trang và thu thập thẻ meta là điều bắt buộc

Giới thiệu về Open Graph Protocol

• Open Graph Protocol (OGP) là một giao thức tiêu chuẩn do Facebook tạo ra, giúp biến trang web thành đối tượng trong social graph
• OGP định nghĩa một số thẻ meta bắt buộc tối thiểu
  • og:title: tiêu đề bài viết
  • og:type: loại đối tượng, ví dụ "video.movie"
  • og:image: URL ảnh thumbnail
  • og:url: URL đại diện của đối tượng đó
• Nhờ giao thức này, nội dung có thể được tóm tắt hiệu quả và hiển thị hấp dẫn trên nhiều nền tảng xã hội khác nhau

Giải quyết bằng cách cho phép một phần trong robots.txt

• Để giải quyết vấn đề, tôi đã sửa robots.txt theo cách chỉ cho phép LinkedInBot
• Nếu cần phần xem trước trên các nền tảng xã hội khác, bạn cũng sẽ phải cho phép riêng từng bot tương ứng
• Ví dụ cấu hình hiện đang áp dụng:

  User-agent: LinkedInBot
  Allow: /
  
  User-agent: *
  Disallow: /
  

Nhìn lại và những điều rút ra

• Nếu chặn toàn bộ crawler một cách vô điều kiện, có thể phát sinh vấn đề về hiển thị nội dung và cách nội dung được trình bày
• Tôi nhận ra sai lầm của mình là đã thay đổi mà không kiểm thử đầy đủ tác động của nó
• Qua trải nghiệm này, tôi đã hiểu thêm nhiều hơn về các công cụ và chuẩn web hữu ích như Open Graph Protocol và LinkedIn Post Inspector
• Khi thêm hoặc thay đổi chức năng, cần hiểu rõ và kiểm chứng đầy đủ toàn bộ phạm vi bị ảnh hưởng
• Ban đầu tôi không liên hệ được giữa OGP và việc chặn bằng robots.txt, nhưng qua trải nghiệm này tôi đã nhận ra tầm quan trọng của nó

[GN⁺]

Ý kiến trên Hacker News

• Trước đây, mục đích chính của robots.txt là ngăn bị công cụ tìm kiếm phạt vì nội dung trùng lặp. Khi vận hành một site động khó quản lý, cùng một trang có thể lộ ra dưới nhiều URL do tham số truy vấn v.v., và bị công cụ tìm kiếm phạt. robots.txt có vai trò kiểu như “đây mới là URL chính thức, còn lại hãy bỏ qua”. Ngoài ra nó còn giúp các crawler “ngoan” không bị lạc trong vòng lặp crawl liên kết vô hạn. Tất nhiên crawler “xấu” thì chẳng quan tâm, và những bot như vậy thường bị chặn bằng IP v.v. Chặn theo User-Agent thì không có nhiều ý nghĩa. Tin rằng bot độc hại sẽ ngoan ngoãn tuân thủ quy định là một suy nghĩ ngây thơ. Header DNT (Do Not Track) cũng tương tự, chẳng khác nào đi xin các công ty sống bằng việc theo dõi rằng “xin đừng theo dõi tôi”. Hoặc giống ý tưởng Evil Bit trong RFC, nơi ta mong các gói tin độc hại tự ghi vào header rằng “tôi là độc hại”

  • Cần nhớ rằng đề xuất Evil Bit là một RFC Cá tháng Tư xem RFC 3514

  • Rốt cuộc cũng có lúc tôi nghĩ robots.txt có vai trò gần giống sitemap, nhưng thật ra nó hoàn toàn ngược lại. robots.txt cho crawler biết nơi không nên truy cập, còn sitemap cho biết nơi bạn muốn được lập chỉ mục. Tôi không biết mục đích ban đầu của nó là để quản lý hình phạt nội dung trùng lặp, nên thấy điều này bổ sung thêm một ngữ cảnh mới cho góc nhìn về kiểm soát SEO

  • Điểm mấu chốt là khi bạn tuyên bố một hành vi là “bị cấm”, điều đó chỉ hiệu quả với một số bên trung thực, hoặc với những bên vô tình không che giấu kỹ tên user agent của họ. Vượt quá mức đó thì hầu như không có tác dụng, nên cuối cùng đây phần nào chỉ là biện pháp mang tính biểu tượng

  • Cũng như header DNT, những nỗ lực có vẻ bất khả thi trong thực tế thường bị chỉ trích, nhưng thực ra ý tưởng DNT vốn là một nỗ lực muốn đi kèm với công cụ pháp lý. Dù khó có thể chặn hoàn toàn bằng kỹ thuật, vẫn phải tính đến việc nếu phạm pháp ở quy mô lớn thì cuối cùng cũng có thể bị lộ ra qua người tố giác nội bộ

  • Có những người tin rằng cứ đặt ra quy tắc là mọi người sẽ tuân theo, và đôi khi tôi tự hỏi liệu niềm tin đó có bắt nguồn từ khác biệt văn hóa hay không

• Tôi từng tự làm một công cụ tìm kiếm và crawl web vào năm 2003. Tôi đưa địa chỉ email liên hệ vào user agent, rồi nhận được rất nhiều email phản đối. Dù tôi đã cố làm crawler một cách tử tế và lịch sự nhất có thể, tôi cảm thấy mọi người chỉ không muốn nếu đó không phải Google. Chính thái độ như vậy mới là cách ngăn cản sự xuất hiện của đối thủ cạnh tranh với Google. Vấn đề không chỉ giới hạn ở preview của LinkedIn, mà còn là việc web nên mở cho nhiều loại bot và người dùng khác nhau. Tất nhiên phải chặn crawler độc hại, nhưng mặc định coi mọi bot đều có ác ý thì không phải là thái độ đáng khuyến khích

  • Trải nghiệm khiến tôi khó chịu nhất khi vận hành bot tử tế là có người tạo bot độc hại dùng chính user agent của bot tôi để tấn công, rồi khiếu nại lại gửi đến tôi

  • Ai cũng có thể muốn bảo vệ bot của mình, nhưng trên thực tế vấn đề không chỉ là bot của riêng ai đó, mà là có tới khoảng 9000 bot giống hệt nhau chạy ngoài kia và tiêu tốn quá nhiều tài nguyên máy chủ. Những bot như vậy thực tế cũng không mang lại referral traffic

  • Ban đầu tôi cũng theo cách tiếp cận chặn mọi thứ, nhưng rồi nhận ra tính liên kết và phức tạp của web. Tôi cho rằng việc có quyền chủ động đối với tài nguyên của mình là quan trọng. Tuy vậy, khi quyết định cho phép hay chặn loại traffic nào, bạn phải tự hỏi “vì sao” và phải hiểu từng bot đang làm gì. Quá trình đó đòi hỏi thời gian và công sức. Tôi bắt đầu quan tâm đến robots.txt vì thói quen crawl bừa bãi của các công ty AI nhằm lấy dữ liệu huấn luyện. Tôi muốn tự mình chọn cho phép hay chặn. Không phải bot nào cũng tuân thủ robots.txt, nhưng khá nhiều bot có làm theo. Một cách để tự kiểm tra là nhờ một mô hình hỗ trợ duyệt web thực hiện yêu cầu scrape một liên kết cụ thể. Về căn bản, việc bot có độc hại hay không phụ thuộc nhiều hơn vào cách công ty đó sử dụng dữ liệu và cảm nhận của tôi về điều đó

  • Với lập luận “không phải mọi bot đều độc hại nên đừng chặn vô điều kiện”, tôi nghĩ về cơ bản việc cho truy cập khi không có căn cứ để tin tưởng là một chiến lược rủi ro

  • Việc nghi ngờ các crawler không rõ danh tính là điều tự nhiên. Phần lớn crawler là độc hại, và không có cách nào biết trước đâu là tốt đâu là xấu, nên mặc định coi bot lạ là tạm thời độc hại là hợp lý

• Tôi cố tránh ý kiến quá gay gắt, nhưng điều làm tôi ngạc nhiên ở bài này là tác giả có vẻ như đang tỏ ra nhận ra hậu quả từ hành động của mình một cách quá nghiêm trọng. Câu chuyện trưởng thành cá nhân cũng có ý nghĩa, nhưng bài này gần với một lời thú nhận về sự thiếu hiểu biết hơn là một sự khai sáng. Cuối cùng tôi có cảm giác đây là bài đăng để được chú ý

  • Tác giả đã không nhận ra rằng fetcher dùng để tạo preview trang cũng được xem là crawler, và cũng không nghĩ tới chuyện chặn nó bằng robots.txt. Có thể không phải điều quá hiển nhiên, nhưng ít nhất từ góc nhìn của chính tác giả thì vẫn có điều mới để học. Tôi cho rằng các bài blog do người thật tự viết có thể nâng chất lượng trung bình của web

  • Vì không hiển thị trên Google nên họ mới đăng bài ở đây (Hacker News)

  • Với tôi cũng có những phần thực sự mới mẻ. Đây là dịp để tôi tìm hiểu thêm về Open Graph Protocol và Robots Exclusion Protocol. Tôi thường ghi lại và chia sẻ những gì mình tự học được hoặc thấy thú vị. Tôi chia sẻ vì nghĩ rằng người khác cũng có thể thấy nó thú vị

  • Tôi thắc mắc làm sao bài này lại lên được trang nhất. Có cảm giác đây chỉ là một bài dài dòng để nói điều quá hiển nhiên: “chặn nước thì người tốt né đi, kẻ xấu thì phớt lờ”. Rốt cuộc robots.txt chỉ là một lời “xin đừng làm vậy” lịch sự, chứ không phải tường lửa, điều đó vốn đã quá rõ

• Vấn đề của robots.txt là rốt cuộc nó lọc theo “danh tính” của crawler chứ không phải theo mục đích của crawler. Tác giả cũng chặn mọi bot để ngăn việc thu thập cho AI, nhưng lại cho phép lại crawler dùng cho preview OpenGraph (như LinkedIn). Nhưng rồi nếu liên kết được chia sẻ trên Twitter hay Mastodon thì sao? Bạn sẽ phải cho phép từng UA của mọi mạng xã hội, và cuối cùng cấu trúc đó chỉ có lợi cho một số ít nền tảng lớn. Về bản chất cần có một cách để nói “hãy chặn việc huấn luyện AI, nhưng cho phép lập chỉ mục tìm kiếm, preview, lưu trữ v.v.”. Muốn thực thi điều này trên thực tế có lẽ sẽ cần khung pháp lý đi kèm, nhưng điều đó cũng không dễ

  • Tranh luận về công dụng gốc của robots.txt luôn tồn tại. Theo tôi, ban đầu (và đến giờ vẫn vậy) nó chủ yếu dành cho crawler theo đúng nghĩa, tức là loại đi theo liên kết để khám phá cái mới. Công cụ tìm kiếm là ví dụ tiêu biểu. Nhưng khi người dùng trực tiếp yêu cầu một URL cụ thể (ví dụ: trình duyệt, đăng ký iCal v.v.) thì không cần phải tuân theo robots.txt. Thực tế từng có chuyện các dịch vụ như Google Calendar bị robots.txt chặn khiến không đăng ký được, và tôi cho đó là hành vi sai. Với preview URL, nếu người dùng chỉ yêu cầu một liên kết duy nhất thì nó gần với một yêu cầu cụ thể hơn là crawl. Nhưng nếu trong một tin nhắn dài có nhiều liên kết thì điều đó lại gần với một dạng crawl. Kết luận là tôi vẫn thấy còn mơ hồ về việc tính năng preview URL của mạng xã hội có nên tuân theo robots.txt hay không

  • Dữ liệu như Common Crawl có thể được tái sử dụng cho cả công cụ tìm kiếm lẫn huấn luyện AI v.v. Rất khó phân biệt theo mục đích sử dụng

  • Có thể giải quyết bằng cách tách việc chia sẻ thông tin thành out-of-band thay vì in-band. Nếu cung cấp metadata Open Graph qua một đường dẫn/header riêng, thì có thể cho phép đường dẫn đó (dữ liệu ít giá trị) và từ chối mạnh nội dung chính. Chưa chắc nhất thiết phải cần khung pháp lý

  • Tôi thích ý tưởng tạo ra một tiêu chuẩn cho phép/chặn theo chức năng hoặc mục đích. Tuy nhiên, mấu chốt là xác minh chức năng và ngăn spoofing, và cuối cùng vẫn sẽ vướng vào vấn đề pháp lý. Trên thực tế có vẻ vẫn sẽ phải cho phép lại nhiều nền tảng khác nhau như preview mạng xã hội, và trong quá trình cân nhắc kỹ xem nên cho phép hay chặn ai, tôi đang học được rất nhiều. Việc lắng nghe nhiều ý kiến như thế này là nguồn tham khảo rất lớn

• Với OP, 1) Bạn chỉ nghĩ đến LinkedIn, nhưng thực tế liên kết của bạn có thể được chia sẻ trên Facebook, Bluesky và nhiều mạng xã hội khác. Tôi cũng từng trải qua chuyện trong ai.robots.txt của Facebook, crawler dùng cho preview của FB cũng bị chặn theo (ví dụ ai.robots.txt).

2. Về thứ hạng Google và việc chặn bằng robots.txt, dù chặn bằng robots.txt có thể vẫn còn các biến khác như liên kết gián tiếp, nhưng về cơ bản việc cho phép crawl trực tiếp vẫn có lợi hơn rất nhiều cho SEO trên Naver/Google. Nếu chặn thì thumbnail/mô tả sẽ không hiển thị trong kết quả tìm kiếm, làm chất lượng giảm đi. Nếu traffic từ công cụ tìm kiếm là quan trọng, bạn nên cân nhắc kỹ việc chặn hoàn toàn bằng robots.txt

• Cảm ơn phản hồi! 1) Tôi cũng chỉ nghĩ đến LinkedIn và HN. Tôi đã không nghĩ tới việc người khác có thể chia sẻ liên kết blog của tôi trên nhiều nền tảng khác nhau. Có lẽ tôi sẽ phải xem xét lại việc cho phép truy cập từ nhiều nền tảng. 2) Thấy xu hướng công cụ tìm kiếm chuyển sang tóm tắt bằng AI, tôi nghĩ về sau organic traffic đi thẳng vào site sẽ giảm. Vì thế việc giảm traffic từ tìm kiếm Google không khiến tôi tiếc lắm. Có thể sau này suy nghĩ của tôi sẽ thay đổi, nhưng hiện tại tôi cho rằng hiệu ứng truyền miệng qua HN và chia sẻ mạng xã hội sẽ tạo ra traffic có ý nghĩa hơn cho blog của tôi. Tôi định tìm hiểu thêm để xem quyết định này có tự làm khó mình hay không. Các ý kiến đa dạng đang giúp ích rất nhiều cho việc ra quyết định

• Có một tác dụng phụ khác phát sinh khi dùng robots.txt và nhầm lẫn giữa “crawl” và “index”.
  Muốn chặn ngay từ đầu một trang mới khỏi Google index thì chặn bằng robots.txt có hiệu quả.
  Nhưng nếu muốn xóa một trang đã được index rồi mà chỉ thêm vào robots.txt thì đó là sai lầm. Google không crawl được nên vẫn tiếp tục hiển thị trong kết quả tìm kiếm mà không có metadata, và cũng không thể kiểm tra thẻ meta noindex, nên cuối cùng trang có thể còn nằm trong tìm kiếm rất lâu. Sau đó Google sẽ gỡ hẳn trang đó, nhưng quá trình này có thể rất bực bội

  • Google có thể biết đến một URL bị robots.txt chặn qua liên kết bên ngoài v.v., và trong trường hợp đó dù không crawl được thì bản ghi đã được index vẫn có thể còn xuất hiện trong kết quả (xem cảnh báo: tài liệu chính thức của Google). Muốn xóa hoàn toàn khỏi kết quả tìm kiếm thì nhất định phải thêm thẻ noindex trong mã, và cần lưu ý rằng nếu chặn bằng robots.txt thì Google cũng không đọc được thẻ này

  • Trường hợp của tôi thì không nhất thiết phải gỡ khỏi chỉ mục Google. Tôi không quan tâm đến việc lập chỉ mục, mà chỉ để ý chuyện crawl và scrape. Tôi thừa nhận mình đã dùng nhầm thuật ngữ

• Bài này có cảm giác kéo dài quá mức một chuyện mà lẽ ra chỉ cần một hai dòng là đủ. Giống kiểu ngày còn đi học cố kéo cho đủ số chữ

  • Vấn đề này có thể giải thích trong một đoạn là xong. Mục đích bài viết của tôi là ghi lại hành trình từ trải nghiệm, vấn đề, nghiên cứu cho đến giải pháp. Tôi viết thật chi tiết nhất có thể để cả người không chuyên kỹ thuật cũng theo dõi được

• Giới hạn căn bản của robots.txt là bot có vấn đề thật sự không phải là bot tuân thủ robots.txt, mà là bot không tuân thủ. robots.txt hiện nay không kiểm soát được phần lớn các bot gây vấn đề về traffic. Càng là bot độc hại làm hư hại máy chủ thì càng chẳng quan tâm đến robots.txt

  • Để bắt loại bot này, có thể dùng “honeypot”. Khai báo chặn rõ ràng đường dẫn /honeypot trong robots.txt, rồi thêm vào index.html một liên kết <a href="/honeypot">ban me</a> được ẩn bằng display:none. Chỉ cần chặn ngay IP nào truy cập đường dẫn đó

  • Tôi không hiểu vì sao bị downvote. Không có cơ sở nào để tin rằng các công ty lớn như OpenAI hay Anthropic thực sự tuân thủ robots.txt tốt đến đâu. Những công ty này còn làm cho việc phát hiện khó hơn bằng cách chuyển traffic qua IP của ISP dân dụng, và phân tán trách nhiệm bằng cách né việc theo dõi trực tiếp thông qua “quảng cáo bên thứ ba”`

• Điều khiến tôi sốc nhất là gần như không có thư viện parser được tổ chức tử tế nào để cùng lúc diễn giải robots.txt và thẻ meta robots, cũng như xử lý thứ tự ưu tiên khi chúng xung đột. Parser tham chiếu chính thức của Google là một trường hợp hiếm vì dựa trên C++11, còn các thư viện phổ biến cho Python hay JS thì có vẻ nhà phát triển phải tự xử lý. Thậm chí với meta robots thì thông tin còn không nằm trong file robots.txt mà ẩn bên trong index.html. Vấn đề là ngay cả tác giả bot muốn làm điều đúng đắn về mặt đạo đức cũng gặp khó vì độ khó triển khai

  • Trong thư viện chuẩn Python có urllib.robotparser (tài liệu chính thức). Mặt khác, rel=nofollow có mục đích hoàn toàn khác robots.txt. Thuộc tính này có nghĩa là công cụ tìm kiếm không nên “tin tưởng” liên kết đó (không truyền giá trị liên kết), chứ không có nghĩa là “đừng đi theo liên kết này” (giải thích chi tiết). Ý định ban đầu là để ngăn việc spam link website của mình hàng loạt trong các cộng đồng đầy thư rác

  • Các nhà phát triển bot “tử tế” với nguồn lực hạn chế vốn không bắn phá máy chủ bừa bãi, nên thực ra việc thiếu thư viện cũng không gây ra quá nhiều khó khăn trong thực tế

  • Nếu thật sự muốn tạo một bot tử tế một cách thiện chí, thì hoàn toàn có thể tự viết thư viện parser rồi open source sang ngôn ngữ khác để công khai. Tôi nghĩ chuyện đó không khó

• Một cách thú vị là Apple tiếp cận vấn đề này theo hướng khác. Khi chia sẻ liên kết trong iMessage, chính client phía người gửi sẽ tự lấy dữ liệu để tạo preview. Các dịch vụ như LinkedIn có lý do để scrape dữ liệu liên kết ở phía máy chủ (chống spam, chống phishing v.v.), nhưng đây rõ ràng là một cách làm khác biệt

  • Tôi cũng từng nghĩ việc client tự tạo preview sau khi nhận liên kết trong tin nhắn là hợp lý. Và tôi cũng mong sẽ có người chỉ ra điểm này. Tuy vậy tôi cũng hiểu có nhiều lý do để máy chủ trực tiếp scrape: 1) chuẩn bị cho tương lai nơi mọi trang đều có thể được scrape và tận dụng; 2) ngay cả khi trang thay đổi, trả về 404, hoặc cơ sở dữ liệu phía client bị mất, máy chủ vẫn có thể trả về thông tin preview đã trích trước; 3) không cần tạo preview ở phía client mà vẫn có thể xem trước nhanh cùng với tin nhắn. Cuối cùng, nếu như iMessage để “người gửi” tạo preview, thì chỉ còn “lý do số 1” và “một phần của lý do số 2”, còn việc máy chủ tiếp tục retry có thể vẫn là lựa chọn tốt hơn về mặt độ ổn định