สิ่งที่ฉันเข้าใจผิดเกี่ยวกับ 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 จากพารามิเตอร์ query เป็นต้น แล้วก็โดนเสิร์ชเอนจินลงโทษ robots.txt มีหน้าที่บอกว่า "นี่คือ URL ทางการ กรุณาไม่ต้องสนใจที่เหลือ" นอกจากนี้ยังช่วยให้ crawler ที่ "ดี" ไม่หลงวนกับการ crawl ลิงก์แบบไม่สิ้นสุด แน่นอนว่า crawler ที่ "ไม่ดี" ไม่สนใจอยู่แล้ว และบอตพวกนี้ก็มักต้องบล็อกด้วยวิธีอย่างการบล็อก IP การบล็อกตาม User-Agent แทบไม่มีความหมาย การเชื่อว่าบอตไม่หวังดีจะเชื่อฟังกติกาอย่างเรียบร้อยเป็นความคิดที่ไร้เดียงสา เช่นเดียวกับ header DNT (Do Not Track) ที่ก็เหมือนการขอร้องบริษัทที่ทำมาหากินจากการติดตามว่า "ช่วยอย่าติดตามนะ" หรือคล้ายกับไอเดีย Evil Bit ใน RFC ที่หวังให้แพ็กเกจอันตรายใส่ header มาบอกเองว่า "ฉันเป็นอันตราย"

    • ต้องจำไว้ว่า Evil Bit เป็นข้อเสนอ RFC วันเมษาหน้าโง่ ดู RFC 3514

    • ฟังดูเหมือน robots.txt จะมีบทบาทคล้าย sitemap แต่จริง ๆ แล้วตรงกันข้าม robots.txt บอกตำแหน่งที่ crawler ไม่ควรเข้า ส่วน sitemap บอกตำแหน่งที่อยากให้ทำดัชนี ผมไม่เคยรู้มาก่อนว่าเดิมมันมีจุดประสงค์เพื่อจัดการโทษจากเนื้อหาซ้ำ ทำให้ได้บริบทใหม่ในการมองเรื่องการควบคุม SEO

    • แก่นคือเมื่อเราประกาศว่าพฤติกรรมใดเป็นสิ่งต้องห้าม มันจะได้ผลเฉพาะกับคนที่ซื่อสัตย์ หรือกรณีที่เผลอไม่ปกปิดชื่อ user agent ให้ดีเท่านั้น มากกว่านั้นมักไม่ได้ผล จึงเป็นมาตรการเชิงสัญลักษณ์พอสมควร

    • เช่นเดียวกับ header DNT ความพยายามที่ดูเหมือนบังคับใช้จริงไม่ได้มักถูกวิจารณ์ แต่จริง ๆ แล้วแนวคิด DNT พยายามจะใช้ร่วมกับกลไกทางกฎหมาย ถึงจะบล็อกทางเทคนิคแบบสมบูรณ์ได้ยาก แต่ถ้าทำผิดกฎหมายในวงกว้าง สุดท้ายก็อาจถูกเปิดโปงจาก whistleblower ได้

    • มีคนที่เชื่อว่าถ้าตั้งกฎขึ้นมาแล้วทุกคนจะทำตาม ซึ่งก็อดสงสัยไม่ได้ว่าความเชื่อแบบนี้มาจากความต่างทางวัฒนธรรมหรือเปล่า

  • ผมเคยทำเสิร์ชเอนจินเองและ crawl เว็บในปี 2003 พอใส่อีเมลติดต่อไว้ใน user agent ก็ได้รับอีเมลร้องเรียนจำนวนมาก ผมทำ crawler อย่างสุภาพและรอบคอบที่สุดแล้ว แต่ผู้คนดูเหมือนไม่ต้องการอะไรที่ไม่ใช่ Google ท่าทีแบบนี้เองที่ขัดขวางการเกิดคู่แข่งของ Google มันไม่ใช่แค่เรื่อง preview ของ LinkedIn แต่คือการมองว่าเว็บควรเปิดกว้างสำหรับบอตและผู้ใช้ที่หลากหลาย แน่นอนว่าต้องกัน crawler แย่ ๆ ออกไป แต่การมองว่าบอตทุกตัวเป็นอันตรายตั้งต้นไม่ใช่ท่าทีที่ดี

    • ในฐานะคนที่พยายามรันบอตอย่างสุภาพ ประสบการณ์ที่น่าหงุดหงิดที่สุดคือมีคนเอา user agent ของบอตผมไปทำบอตอันตรายโจมตี แล้วคำร้องเรียนกลับมาหาผม

    • ใคร ๆ ก็อาจอยากปกป้องบอตของตัวเอง แต่ในความเป็นจริงปัญหาไม่ได้มีแค่บอตของคุณตัวเดียว ปัญหาคือมีบอตแบบเดียวกันวิ่งอยู่สัก 9000 ตัว ใช้ทรัพยากรเซิร์ฟเวอร์มากเกินไป และบอตเหล่านี้แทบไม่ได้นำ referral traffic มาให้จริง

    • ตอนแรกผมก็ใช้แนวทางบล็อกทุกอย่างเหมือนกัน แต่ต่อมาก็เข้าใจความเชื่อมโยงและความซับซ้อนของเว็บมากขึ้น ผมคิดว่าสำคัญที่เจ้าของทรัพยากรจะมีสิทธิ์ควบคุมมันเอง แต่เวลาจะอนุญาตหรือบล็อกทราฟฟิกแบบไหน เราควรถามตัวเองว่า "ทำไม" และต้องรู้ว่าบอตแต่ละตัวทำอะไร กระบวนการนี้ต้องใช้เวลาและความพยายาม ผมเริ่มสนใจ robots.txt เพราะบริษัท AI มีพฤติกรรม crawl แบบกวาดทุกอย่างไปใช้ฝึกข้อมูล ผมอยากเป็นคนเลือกเองว่าจะอนุญาตหรือบล็อก ไม่ใช่บอตทุกตัวจะทำตาม robots.txt แต่ก็มีจำนวนมากที่ทำตาม วิธีทดสอบอย่างหนึ่งคือขอให้โมเดลที่รองรับการท่องเว็บ scrape ลิงก์ที่กำหนดให้ดู โดยพื้นฐานแล้ว ความเป็นอันตรายของบอตขึ้นกับวิธีที่บริษัทนั้นใช้ข้อมูลและความรู้สึกของผมต่อเรื่องนั้นมากกว่า

    • ต่อคำกล่าวที่ว่า "ไม่ใช่ทุกบอตจะเป็นอันตราย ก็ไม่ควรบล็อกแบบเหมารวม" ผมคิดว่าโดยหลักแล้วการเปิดให้เข้าถึงโดยไม่มีเหตุผลให้เชื่อใจเป็นกลยุทธ์ที่เสี่ยง

    • การระแวง crawler ที่ไม่รู้จักเป็นเรื่องปกติ crawler ส่วนใหญ่เป็นอันตราย และไม่มีทางรู้ล่วงหน้าว่าตัวไหนดีหรือร้าย ดังนั้นการถือว่าบอตที่ไม่รู้จักเป็นอันตรายไว้ก่อนจึงสมเหตุสมผล

  • ผมพยายามไม่ออกความเห็นเชิงวิจารณ์มากนัก แต่สิ่งที่ทำให้แปลกใจคือบทความนี้เหมือนผู้เขียนทำเป็นเพิ่งตระหนักถึงผลลัพธ์จากการกระทำของตัวเองอย่างยิ่งใหญ่ เรื่องการเติบโตส่วนตัวก็มีคุณค่า แต่บทความนี้ดูใกล้เคียงกับการสารภาพความไม่รู้มากกว่าความลุ่มลึก ท้ายที่สุดเลยให้ความรู้สึกว่าโพสต์เพื่อเรียกร้องความสนใจ

    • ผู้เขียนแค่ไม่ได้มองตัว fetcher สำหรับ page preview ว่าเป็น crawler และไม่ได้คิดจะบล็อกมันด้วย robots.txt ถึงจะไม่ใช่เรื่องลึกซึ้งอะไร แต่อย่างน้อยสำหรับเจ้าตัวก็มีเรื่องใหม่ให้เรียนรู้ ผมคิดว่าบล็อกโพสต์ที่มนุษย์เขียนจริง ๆ ช่วยยกระดับคุณภาพเฉลี่ยของเว็บได้

    • ที่เอาโพสต์มาลงที่นี่ (Hacker News) ก็เพราะมันไม่ถูก Google แสดงผล

    • สำหรับผมเองก็มีหลายส่วนที่รู้สึกใหม่จริง ได้เป็นโอกาสไปเรียนรู้เพิ่มทั้ง Open Graph Protocol และ Robots Exclusion Protocol ผมมักจะจดและแบ่งปันสิ่งที่ตัวเองได้เรียนรู้หรือรู้สึกสนใจ เพราะคิดว่ามันอาจน่าสนใจสำหรับคนอื่นด้วย

    • สงสัยเหมือนกันว่าบทความนี้ขึ้นหน้าแรกได้อย่างไร เหมือนเอาเรื่องที่ชัดเจนอยู่แล้วว่า "พอกั้นน้ำ คนดีจะหลบ แต่คนร้ายจะเมิน" มาเขียนยืดยาว สุดท้าย robots.txt ก็เป็นแค่การขอร้องอย่างสุภาพว่า "อย่าทำ" ไม่ใช่ไฟร์วอลล์ ซึ่งเป็นเรื่อง очевидent อยู่แล้ว

  • ปัญหาของ robots.txt คือสุดท้ายมันกรองตาม "ตัวตน" ของ crawler ไม่ใช่ตาม "วัตถุประสงค์" ของ crawler ผู้เขียนเองก็พยายามบล็อกบอตทั้งหมดเพื่อกันการเก็บข้อมูลไปใช้กับ AI แต่กลับอนุญาต crawler สำหรับ OpenGraph preview (เช่น LinkedIn) อีก แล้วถ้ามีการแชร์ใน Twitter หรือ Mastodon จะทำอย่างไรอีกล่ะ ก็ต้องไล่อนุญาต UA ของโซเชียลมีเดียทุกเจ้า ซึ่งสุดท้ายเป็นโครงสร้างที่เอื้อเฉพาะแพลตฟอร์มใหญ่ไม่กี่ราย โดยแก่นแล้วเราต้องการวิธีที่บอกได้ว่า "ห้ามใช้ฝึก AI แต่อนุญาตให้ทำ search indexing, preview, archive ฯลฯ" การบังคับใช้จริงคงต้องมีกรอบกฎหมายรองรับ แต่ก็ไม่ง่ายอยู่ดี

    • มีการถกเถียงเรื่องหน้าที่ดั้งเดิมของ robots.txt มาโดยตลอด ผมคิดว่าเดิมที (และตอนนี้ก็ยัง) มันมีไว้สำหรับ crawler ส่วนใหญ่ที่ทำงานแบบตามลิงก์ไปเรื่อย ๆ เพื่อค้นหาหน้าใหม่ เช่นเสิร์ชเอนจิน แต่ถ้าเป็นกรณีที่ผู้ใช้ร้องขอ URL เฉพาะโดยตรง (เช่น เบราว์เซอร์, การ subscribe iCal) ก็ไม่จำเป็นต้องทำตาม robots.txt ในความเป็นจริง บริการอย่าง Google Calendar เคยมีปัญหา subscribe ไม่ได้เพราะโดน robots.txt บล็อก ซึ่งผมคิดว่าเป็นพฤติกรรมที่ผิด ในกรณีของ URL preview ถ้าผู้ใช้ขอลิงก์เดียวก็น่าจะใกล้เคียงกับ specific request มากกว่าการ crawl แต่ถ้าเป็นข้อความยาวที่มีหลายลิงก์ มันก็เริ่มคล้ายการ crawl อีกรูปแบบหนึ่ง สรุปแล้วผมยังคิดไม่ตกว่าฟีเจอร์ URL preview ของโซเชียลมีเดียควรทำตาม robots.txt หรือไม่

    • ข้อมูลอย่าง Common Crawl สามารถถูกนำกลับไปใช้ได้ทั้งกับเสิร์ชเอนจินและการฝึก AI จึงแยกตามวัตถุประสงค์ได้ยาก

    • น่าจะแก้ได้ถ้าแยกการแชร์ข้อมูลเป็น out-of-band แทนที่จะเป็น in-band เช่นให้ metadata ของ Open Graph ผ่าน path/header แยกต่างหาก แบบนี้ก็อนุญาตเฉพาะ path นั้น (ข้อมูลที่ใช้ประโยชน์อื่นไม่ได้) แล้วปฏิเสธเนื้อหาหลักอย่างเข้มงวด กรอบกฎหมายอาจไม่จำเป็นเสมอไป

    • ผมชอบแนวคิดการสร้างมาตรฐานที่อนุญาต/บล็อกตามฟังก์ชันหรือตามวัตถุประสงค์ แต่หัวใจสำคัญคือการยืนยันฟังก์ชันและการป้องกันการ spoofing ซึ่งสุดท้ายก็โยงกับปัญหาทางกฎหมายอยู่ดี ในทางปฏิบัติก็คงต้องกลับไปอนุญาตหลายแพลตฟอร์มอีกครั้ง เช่น preview ของโซเชียลมีเดีย และผมก็กำลังได้เรียนรู้มากจากกระบวนการค่อย ๆ เลือกว่าจะอนุญาตหรือบล็อกอะไรบ้าง การได้ฟังหลายมุมมองแบบนี้ช่วยมากจริง ๆ

  • ถึง OP: 1) คุณอาจนึกถึงแค่ LinkedIn แต่จริง ๆ แล้วลิงก์ของคุณอาจถูกแชร์ในโซเชียลมีเดียอื่นด้วย เช่น Facebook, Bluesky ผมเองก็เคยเจอว่าใน ai.robots.txt ของ Facebook มันบล็อก crawler สำหรับ FB preview ไปด้วย (ตัวอย่าง ai.robots.txt).

  1. เรื่องอันดับ Google กับการบล็อก robots.txt นั้น แม้จะยังมีตัวแปรอื่นอย่างลิงก์ทางอ้อม แต่โดยพื้นฐานแล้วการยอมให้ crawl โดยตรงส่งผลดีกว่ามากต่อ SEO ของ Naver/Google หากคุณบล็อก ผลลัพธ์ค้นหาจะไม่แสดง thumbnail/description ทำให้คุณภาพลดลง ถ้าทราฟฟิกจากเสิร์ชเอนจินสำคัญ ก็ควรคิดให้ดีว่าจะบล็อกทั้งหมดด้วย robots.txt หรือไม่

  • ขอบคุณสำหรับฟีดแบ็ก! 1) ผมเองก็นึกถึงแค่ LinkedIn กับ HN เหมือนกัน ไม่ทันคิดว่าคนอื่นอาจแชร์ลิงก์บล็อกของผมบนแพลตฟอร์มหลากหลาย อาจต้องกลับมาทบทวนเรื่องการเปิดให้หลายแพลตฟอร์มเข้าถึง 2) พอเห็นแนวโน้มของเสิร์ชเอนจินที่เน้น AI summary มากขึ้น ผมคิดว่าในอนาคต organic traffic ที่ไหลเข้าสู่ตัวเว็บไซต์โดยตรงคงลดลง ดังนั้นผมเลยไม่ได้เสียดายการลดลงของทราฟฟิกจาก Google เท่าไร อนาคตความคิดผมอาจเปลี่ยน แต่ตอนนี้ผมมองว่าการบอกต่อผ่าน HN และการแชร์บนโซเชียลน่าจะสร้างทราฟฟิกที่มีความหมายกับบล็อกของผมมากกว่า ผมจะลองศึกษาเพิ่มว่าการตัดสินใจนี้จะย้อนมาทำร้ายตัวเองไหม ความเห็นที่หลากหลายช่วยการตัดสินใจได้มากจริง ๆ

  • ยังมีผลข้างเคียงอีกอย่างที่เกิดจากการสับสนระหว่าง "การ crawl" กับ "การทำดัชนี" ผ่าน robots.txt
    ถ้าต้องการกันไม่ให้หน้าใหม่เข้าสู่ดัชนีของ Google ตั้งแต่ต้น robots.txt ก็มีผล
    แต่ถ้าต้องการลบหน้าที่ถูกทำดัชนีไปแล้ว การเพิ่มลง robots.txt อย่างเดียวถือเป็นความผิดพลาด เพราะ Google จะ crawl ไม่ได้ จึงยังปล่อยผลลัพธ์ค้นหานั้นไว้โดยไม่มี metadata และก็ไม่สามารถตรวจ noindex meta tag ได้ สุดท้ายหน้าอาจค้างอยู่ในผลค้นหาเป็นเวลานาน กว่า Google จะเอาออกทั้งหมดทีหลัง ซึ่งกระบวนการนี้น่าหงุดหงิดมาก

    • Google สามารถรู้จัก URL ที่ถูกบล็อกโดย robots.txt ได้จากลิงก์ภายนอกและแหล่งอื่น ๆ และในกรณีนี้ถึงจะ crawl ไม่ได้ แต่ระเบียนที่ถูกทำดัชนีไว้อาจยังคงอยู่ในผลลัพธ์ (ดูคำเตือน: เอกสารทางการของ Google) หากต้องการลบออกจากผลค้นหาอย่างสมบูรณ์ ต้องใส่ noindex tag ในโค้ดด้วย และถ้าถูกบล็อกด้วย robots.txt ก็จะอ่านแท็กนี้ไม่ได้ จึงต้องระวัง

    • ในกรณีของผม ผมไม่ได้อยากให้ Google เอาออกจากดัชนีเป็นพิเศษ ผมเฉย ๆ กับการทำดัชนี แต่สนใจเรื่องการ crawl/scrape มากกว่า ยอมรับว่าบางครั้งผมใช้คำปะปนกัน

  • บทความนี้ให้ความรู้สึกว่าเป็นเรื่องที่ควรพูดแค่หนึ่งหรือสองประโยค แต่ถูกยืดออกมายาวเกินจำเป็น เหมือนสมัยเรียนที่พยายามเขียนให้ได้จำนวนหน้า

    • ปัญหานี้อธิบายได้ในย่อหน้าเดียวจริง ๆ เป้าหมายของบทความของผมคือบันทึกเส้นทางตั้งแต่ประสบการณ์ ปัญหา การค้นคว้า ไปจนถึงวิธีแก้ เพื่อให้คนที่ไม่ได้เชี่ยวชาญเทคนิคก็ยังตามได้ ผมเลยเขียนให้ละเอียดที่สุด

  • ข้อจำกัดพื้นฐานของ robots.txt คือบอตที่เป็นปัญหาไม่ใช่บอตที่เชื่อฟัง robots.txt แต่เป็นบอตที่ไม่เชื่อฟัง ทุกวันนี้ robots.txt ควบคุมบอตส่วนใหญ่ที่เป็นภาระทราฟฟิกไม่ได้เลย ยิ่งเป็นบอตอันตรายที่ทำร้ายเซิร์ฟเวอร์มากเท่าไร ก็ยิ่งไม่สนใจ robots.txt มากเท่านั้น

    • ถ้าจะจับบอตพวกนี้ การใช้ honeypot อาจมีประโยชน์ ใส่ path /honeypot ไว้ใน robots.txt แบบบล็อกอย่างชัดเจน แล้วเพิ่มลิงก์ <a href="/honeypot">ban me</a> ที่ซ่อนไว้ด้วย display:none ใน index.html จากนั้นถ้า IP ไหนเข้ามาที่ path นี้ก็แบนได้ทันที

    • ไม่รู้เหมือนกันว่าทำไมความเห็นนี้ถึงโดนโหวตลบ ไม่มีเหตุผลให้เชื่อว่า OpenAI, Anthropic และบริษัทใหญ่รายอื่นปฏิบัติตาม robots.txt ดีแค่ไหน บริษัทเหล่านี้ยังทำให้การตรวจจับยากด้วยการวิ่งทราฟฟิกผ่าน IP ของผู้ให้บริการอินเทอร์เน็ตตามบ้าน และกระจายความรับผิดชอบด้วยวิธีเลี่ยงการติดตามตรง ๆ ผ่าน “โฆษณาของบุคคลที่สาม”

  • เรื่องที่ทำให้ผมช็อกที่สุดคือแทบไม่มี parser library ที่จัดการทั้ง robots.txt และ meta robots tag พร้อมกติกาการตัดสินเมื่อตีกันได้อย่างเป็นระบบ parser อ้างอิงทางการของ Google ก็เป็น C++11 ซึ่งเป็นกรณีเฉพาะมาก ส่วนไลบรารี Python หรือ JS ที่นิยมใช้จริงกลับทำให้ผู้พัฒนาต้องไปลงมือเอง แม้แต่ meta robots เองก็ไม่ได้อยู่ในไฟล์ robots.txt แต่ซ่อนอยู่ใน index.html ปัญหาคือถึงผู้เขียนบอตจะอยากทำให้ถูกต้องตามจริยธรรมจริง ๆ ก็ยังยากเพราะภาระในการ implement

    • ใน Python standard library มี urllib.robotparser (เอกสารทางการ) ส่วน rel=nofollow มีจุดประสงค์ต่างจาก robots.txt โดยสิ้นเชิง แอตทริบิวต์นี้หมายถึงเสิร์ชเอนจินไม่ควร “ให้ความเชื่อถือ (link value)” กับลิงก์นั้น ไม่ได้แปลว่า “อย่าตามลิงก์นี้ไป” (คำอธิบายเพิ่มเติม) เจตนาเดิมคือป้องกันการสแปมในชุมชนที่คนแปะลิงก์เว็บตัวเองแบบไม่เลือกที่

    • นักพัฒนาบอต “สายดี” ที่มีทรัพยากรไม่มาก ปกติไม่ได้ยิงเซิร์ฟเวอร์แบบถล่มอยู่แล้ว ดังนั้นในทางปฏิบัติปัญหาการขาดไลบรารีจึงไม่ได้สร้างความลำบากมากนัก

    • ถ้าอยากทำบอตที่ดีอย่างจริงจัง ก็ยังสามารถนำ parser library ไปทำเป็นโอเพนซอร์สในภาษาอื่นแล้วปล่อยออกมาเองได้ ไม่มีอะไรยากมากนัก

  • ที่น่าสนใจคือ Apple จัดการปัญหานี้อีกแบบ เวลาแชร์ลิงก์ใน iMessage ตัว client ฝั่งผู้ส่งจะเป็นคนดึงข้อมูลมาสร้าง preview เอง ส่วนบริการอย่าง LinkedIn ใช้วิธีให้เซิร์ฟเวอร์ไปดึงข้อมูลลิงก์โดยตรงด้วยเหตุผลอย่างการกันสแปม การป้องกันฟิชชิง ฯลฯ ซึ่งก็เป็นวิธีที่ต่างออกไปชัดเจน

    • ผมเองก็คิดว่าการให้ client สร้าง preview เองหลังได้รับลิงก์ในข้อความเป็นแนวทางที่สมเหตุสมผล และก็หวังไว้อยู่แล้วว่าต้องมีคนชี้ประเด็นนี้ แต่ผมก็เข้าใจเหตุผลหลายอย่างที่ทำให้เซิร์ฟเวอร์ต้อง scrape เองเช่นกัน 1) เพื่อเตรียมพร้อมสำหรับอนาคตที่ทุกหน้าสามารถถูกดึงไปใช้งานได้ 2) ต่อให้หน้าเปลี่ยน, กลายเป็น 404, หรือฐานข้อมูลฝั่ง client สูญหาย เซิร์ฟเวอร์ก็ยังให้ข้อมูล preview ที่ดึงเก็บไว้ล่วงหน้าได้ 3) client ไม่ต้องสร้าง preview เองและมองเห็นตัวอย่างได้เร็วพร้อมข้อความ สุดท้ายถ้าให้ “ผู้ส่ง” เป็นคนสร้าง preview แบบ iMessage ก็จะเหลือแค่ข้อ 1 กับบางส่วนของข้อ 2 และในแง่ความเสถียร การที่เซิร์ฟเวอร์เป็นฝ่ายคอย retry เองต่อไปอาจเป็นตัวเลือกที่ดีกว่า