วิธีเขียน robots.txt ให้บล็อก AI scrapers ได้จริง

ความจริงที่ไม่ค่อยน่าสบายใจเกี่ยวกับ robots.txt

ไฟล์ robots.txt ไม่ใช่กุญแจล็อก แต่เป็นป้ายที่ติดไว้หน้าประตู

ความแตกต่างนี้สำคัญเมื่อทีมถามว่าพวกเขาสามารถ “บล็อก AI scrapers” ด้วยไฟล์ข้อความเล็ก ๆ ไฟล์เดียวได้หรือไม่ สำหรับ crawler ที่น่าเชื่อถือและปฏิบัติตาม Robots Exclusion Protocol คำตอบคือได้: robots.txt ที่เขียนอย่างถูกต้องสามารถบอกให้พวกมันไม่ crawl หน้าเว็บของคุณได้ แต่สำหรับ scraper ที่ไม่รู้ที่มา ตัวปลอมแปลงตัวตน ระบบอัตโนมัติผ่านเบราว์เซอร์ และบอตที่ไม่สนใจกติกาเลย ไฟล์นี้จะไม่ช่วยอะไรได้ด้วยตัวมันเอง

ดังนั้นเป้าหมายเชิงปฏิบัติไม่ใช่ “ทำให้การ scrape เป็นไปไม่ได้” แต่คือ:

• บอก AI crawlers ที่ปฏิบัติตามกติกาว่าอย่าใช้เว็บไซต์ของคุณ
• หลีกเลี่ยงการบล็อก search engines หรือบริการที่มีประโยชน์โดยไม่ตั้งใจ
• เพิ่มการควบคุมฝั่งเซิร์ฟเวอร์ที่แข็งแรงขึ้นสำหรับการใช้งานในทางที่ผิด
• ทำให้นโยบายดูแลต่อได้เมื่อชื่อ crawler เปลี่ยนไป

นี่คือเวอร์ชันที่ฟังดูน่าเบื่อ และก็เป็นเวอร์ชันที่ใช้งานได้จริง

robots.txt ทำอะไรได้และทำอะไรไม่ได้

ไฟล์ robots.txt อยู่ที่ root ของเว็บไซต์:

https://example.com/robots.txt

Crawlers จะร้องขอไฟล์นี้ก่อนเริ่ม crawl ไฟล์ประกอบด้วยกลุ่มของกฎ แต่ละกลุ่มเริ่มด้วยบรรทัด User-agent หนึ่งบรรทัดหรือมากกว่า ตามด้วย directive Allow หรือ Disallow

ตัวอย่างการบล็อกทั้งเว็บไซต์แบบง่าย ๆ มีหน้าตาแบบนี้:

User-agent: GPTBot
Disallow: /

ความหมายคือ: ถ้าคุณคือ GPTBot อย่า crawl สิ่งใดในเว็บไซต์นี้

แต่ robots.txt มีข้อจำกัดที่ชัดเจน:

1. เป็นการสมัครใจ ผู้ไม่หวังดีสามารถเพิกเฉยได้
2. ไม่ได้ป้องกันไม่ให้ URL ถูกเรียกโดยเบราว์เซอร์หรือสคริปต์ทั่วไป
3. ไม่ได้ลบเนื้อหาที่ถูกเก็บไปแล้วจากที่อื่น
4. ไม่ได้กำหนดลิขสิทธิ์ การอนุญาตใช้งาน หรือสิทธิ์ในการฝึกโมเดลด้วยตัวมันเอง
5. อาจตั้งค่าผิดจนบล็อกบอตผิดตัวได้

หากคุณต้องการการควบคุมการเข้าถึงอย่างแท้จริง ให้ใช้ authentication, authorization, rate limiting, การควบคุมตาม IP, bot management หรือมาตรการทางกฎหมาย Robots.txt ยังมีประโยชน์ แต่ควรเป็นส่วนหนึ่งของกลยุทธ์ปกป้องเนื้อหาที่กว้างกว่า

เรื่องนี้คล้ายกับปัญหาด้านธรรมาภิบาลเว็บอื่น ๆ: การควบคุมที่มองเห็นได้มักไม่ใช่การควบคุมทั้งหมด หากองค์กรของคุณมีการใช้ AI ภายในที่ไม่ได้รับการจัดการอยู่แล้ว หลักการเดียวกันก็ใช้ได้เช่นกัน การทำ shadow AI audit แบบรวดเร็วมักมีประโยชน์กว่าการทำเหมือนว่าเอกสารนโยบายฉบับเดียวแก้ปัญหาได้

เริ่มจากการตัดสินใจเชิงนโยบาย

ก่อนแก้ไขไฟล์ ให้ตัดสินใจก่อนว่าคุณต้องการบล็อกอะไรจริง ๆ

อย่างน้อยมีสี่สิ่งที่คนมักหมายถึงเมื่อพูดว่า “AI scraper”:

• Crawlers ที่ใช้เก็บข้อมูลสำหรับการฝึกโมเดล
• AI search หรือ answer-engine crawlers
• Fetchers ที่ถูกเรียกโดยผู้ใช้ เช่น เมื่อมีคนขอให้ผลิตภัณฑ์ AI สรุป URL
• Scrapers ทั่วไปที่ปลอมตัวเป็นเบราว์เซอร์ธรรมดา

คุณอาจต้องการบล็อกทั้งหมด หรืออาจต้องการให้ค้นพบผ่าน search ได้ ขณะเดียวกันก็ opt out จากการฝึกโมเดล สิ่งเหล่านี้ไม่ใช่นโยบายเดียวกัน

ตัวอย่างเช่น OpenAI มีเอกสารระบุ user agents แยกกันสำหรับวัตถุประสงค์ต่าง ๆ รวมถึง GPTBot, ChatGPT-User และ OAI-SearchBot ส่วน Google ใช้ Google-Extended เป็น control token สำหรับ use cases บางอย่างของ Gemini และ Vertex AI ขณะที่การ crawl สำหรับ Google Search ปกติถูกจัดการโดย user agents ของ Googlebot ตัวอื่น

การแยกแยะนี้สำคัญ หากคุณบล็อก user agents แบบกว้าง ๆ โดยไม่ระวัง คุณอาจทำให้การมองเห็นใน search ตามปกติเสียหายในขณะที่พยายามบล็อกการฝึก AI

เทมเพลต robots.txt สำหรับบล็อก AI ที่สมเหตุสมผล

นี่คือจุดเริ่มต้นแบบระมัดระวังสำหรับการบล็อก AI-related crawlers หลายตัวที่มีเอกสารระบุไว้โดยทั่วไป ขณะยังปล่อยให้ search crawlers ทั่วไปทำงานได้:

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

นี่ไม่ใช่รายชื่อวิเศษที่ครอบคลุมทุกอย่าง แต่เป็นรูปแบบที่ดูแลต่อได้

ข้อสังเกตบางประการ:

• Disallow: / หมายถึง “อย่า crawl path ใด ๆ”
• User-agent: * ใช้กับ crawlers ที่ไม่ตรงกับกลุ่มที่เฉพาะเจาะจงกว่า
• Allow: / ไม่จำเป็นอย่างเคร่งครัดสำหรับกลุ่มเริ่มต้น แต่ช่วยทำให้เจตนาของคุณชัดเจน
• เขียน comment ให้สั้น บาง parser อาจยืดหยุ่น แต่ robots.txt ควรเรียบง่ายที่สุด
• อย่าใส่ URL ส่วนตัวไว้ใน robots.txt ไฟล์นี้เป็นสาธารณะ และการระบุ path ที่อ่อนไหวอาจเท่ากับโฆษณาให้คนรู้

ประเด็นสุดท้ายควรย้ำอีกครั้ง Robots.txt ไม่ใช่กลไกสำหรับเก็บความลับ หาก /client-contracts/ ไม่ควรเป็นสาธารณะ ให้ป้องกันด้วย authentication อย่าเพียงแค่ disallow ไว้

ระวัง Google-Extended

Google-Extended เป็นสิ่งที่ถูกเข้าใจผิดกันมาก มันไม่เหมือนกับการบล็อก Google Search

ตามเอกสารของ Google, Google-Extended เป็น product token แบบแยกต่างหากที่ผู้เผยแพร่สามารถใช้จัดการว่าเนื้อหาของเว็บไซต์อาจช่วยปรับปรุงความสามารถบางอย่างของ Gemini และ Vertex AI ได้หรือไม่ การบล็อกสิ่งนี้โดยตัวมันเองไม่ควรบล็อก Googlebot จากการ crawl เพื่อ Search

อย่างไรก็ตาม อย่าแทนที่ directive ของ Google ทั้งหมดด้วยการบล็อกแบบกว้างเช่นนี้ เว้นแต่คุณตั้งใจเช่นนั้นจริง ๆ:

User-agent: Googlebot
Disallow: /

นั่นจะบอก crawler หลักของ Google Search ว่าอย่า crawl เว็บไซต์ของคุณ สำหรับเว็บไซต์สาธารณะส่วนใหญ่ นั่นไม่ใช่สิ่งที่คุณต้องการ

ความแตกต่างเดียวกันนี้ใช้กับที่อื่นด้วย ผู้ให้บริการบางรายแยก training crawlers ออกจากการ browse ที่ผู้ใช้เรียกใช้หรือ AI search crawlers บางรายไม่แยก คุณต้องอ่านเอกสารของบอตที่คุณสนใจ และปฏิบัติต่อ robots.txt ของคุณเหมือนไฟล์ที่มีชีวิต ไม่ใช่ checkbox ที่ทำครั้งเดียวจบ

ทดสอบไฟล์เหมือน production code

Robots.txt ดูเรียบง่าย และนั่นคือเหตุผลที่มันพังได้ง่าย

ข้อผิดพลาดที่พบบ่อย ได้แก่:

• อัปโหลดไปผิดที่ เช่น /assets/robots.txt แทนที่จะเป็น /robots.txt
• ใช้ smart quotes ที่คัดลอกจาก document editor
• บล็อก crawlers ทั้งหมดด้วย User-agent: * และ Disallow: / โดยไม่ตั้งใจ
• คิดว่าไฟล์ของโดเมนหนึ่งมีผลกับ subdomain อื่น
• ลืมว่า host แบบ http://, https://, www และ non-www อาจถูกจัดการต่างกันขึ้นอยู่กับการตั้งค่าของคุณ

สำหรับเว็บไซต์หลายโดเมน ให้ตรวจสอบทุก canonical host ไฟล์ robots ที่ https://www.example.com/robots.txt ไม่ได้ควบคุม https://app.example.com/robots.txt โดยอัตโนมัติ

เมื่อตรวจแก้ปัญหา ให้ดู HTTP response จริง ไม่ใช่แค่สิ่งที่ CMS preview แสดง คุณต้องการ response 200 OK, content type เป็น text/plain หากเป็นไปได้ และไฟล์ตรงตามที่คาดหวัง หากมี redirects, caching หรือกฎ CDN เกี่ยวข้อง การตรวจ raw header จะช่วยได้ workflow ใน การดีบัก redirects และ HTTP headers ใน production ใช้กับกรณีนี้ได้โดยตรง

เพิ่มการควบคุมฝั่งเซิร์ฟเวอร์สำหรับบอตที่เพิกเฉยต่อกฎ

หาก crawler ปฏิบัติตามกติกา robots.txt คือสัญญาณที่สะอาดที่สุด หาก crawler มีพฤติกรรมละเมิด คุณต้องมีการบังคับใช้

การควบคุมที่ใช้ได้จริง ได้แก่:

Rate limiting

กำหนด threshold สำหรับรูปแบบคำขอที่ผิดปกติ: จำนวนหน้ามากเกินไปต่อนาที การไล่ pagination ลึก ๆ การเกิด 404 ซ้ำ ๆ หรือปริมาณคำขอสูงจาก IP กลุ่มเล็ก ๆ Rate limits ควรกว้างพอที่จะไม่ลงโทษผู้ใช้จริง และเข้มงวดพอที่จะทำให้การดึงข้อมูลจำนวนมากมีต้นทุนสูง

User-agent filtering

คุณสามารถบล็อก user agents ของ AI crawler ที่มีเอกสารระบุไว้ได้ที่เว็บเซิร์ฟเวอร์ reverse proxy, CDN หรือชั้นแอปพลิเคชัน วิธีนี้แข็งแรงกว่า robots.txt เพราะส่ง response ปฏิเสธจริง

ตัวอย่างเช่น Nginx สามารถบล็อกรูปแบบ user agent ได้ แม้กฎใน production ควรถูกทดสอบอย่างระมัดระวัง:

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

วิธีนี้ไม่สมบูรณ์แบบ User-agent strings ปลอมได้ง่าย แต่ช่วยหยุด traffic ที่ซื่อตรงหรือขี้เกียจ และลด load ได้

การควบคุม IP และ ASN

ผู้ให้บริการบางรายเผยแพร่ IP ranges แต่ระบบนิเวศของ scraper จำนวนมากไม่ทำเช่นนั้น การบล็อกตาม IP ใช้ได้กับการใช้งานในทางที่ผิดที่เห็นชัด โดยเฉพาะจาก cloud hosting ranges ที่ไม่มี traffic ผู้ใช้ปกติ แต่ก็อาจสร้าง false positives ได้เช่นกัน ใช้ logs ก่อนตั้งกฎ

Authentication และ paywalls

หากเนื้อหาต้องไม่ถูกคัดลอกในปริมาณมาก อย่าวางเนื้อหาเต็มไว้บน URL สาธารณะ Robots.txt ไม่เหมาะกับข้อมูลลับ ฐานข้อมูลที่มี license ชุมชนส่วนตัว หรือคลังเนื้อหาแบบชำระเงิน

Content minimization

บางครั้งการป้องกันที่ดีที่สุดคือสถาปัตยกรรม อย่าเปิดเผย APIs ที่ไม่จำเป็น JSON payload ขนาดใหญ่ metadata ที่ซ่อนอยู่ draft endpoints หรือคลังเนื้อหาเต็ม หากหน้าสาธารณะต้องการเพียงบางส่วน เว็บไซต์ที่มีรูปภาพจำนวนมากควรคิดด้วยว่า metadata ใดที่เผยแพร่ออกไป ตรรกะด้าน privacy ใน การลบ EXIF metadata ก่อนแชร์ภาพถ่ายออนไลน์ ใช้กับงาน content operations ได้เช่นกัน

ใช้ robots meta tags สำหรับกฎระดับหน้า

Robots.txt ควบคุมการ crawling ส่วน robots meta tags และ headers X-Robots-Tag ควบคุมพฤติกรรมการ indexing และ snippet สำหรับ search engines และ crawlers ที่ปฏิบัติตามกติกา

ตัวอย่างเช่น:

<meta name="robots" content="noindex, noarchive">

หรือเป็น HTTP header:

X-Robots-Tag: noindex, noarchive

สิ่งเหล่านี้ไม่ใช่เกราะป้องกันเฉพาะ AI แต่มีประโยชน์เมื่อคุณต้องการให้หน้าเข้าถึงได้แต่ไม่ถูก index อย่างไรก็ตาม หากคุณบล็อก crawler ไม่ให้ fetch หน้าหนึ่งใน robots.txt มันอาจไม่มีวันเห็น meta tag ระดับหน้านั้น อย่าพึ่งพา tag noindex บน URL ที่ crawler ถูกห้ามไม่ให้ crawl

กฎคร่าว ๆ คือ:

• ใช้ robots.txt เพื่อลดหรือป้องกันการ crawling
• ใช้ meta robots หรือ X-Robots-Tag เพื่อควบคุมพฤติกรรมการ indexing
• ใช้การควบคุมฝั่งเซิร์ฟเวอร์เพื่อบังคับใช้การเข้าถึง

ตรวจสอบ logs หลังเผยแพร่

การเผยแพร่ไฟล์เป็นเพียงขั้นตอนแรก หลังจากนั้น ให้ตรวจ logs ของคุณ

มองหาสิ่งต่อไปนี้:

• คำขอไปยัง /robots.txt จาก user agents ที่คุณระบุชื่อไว้
• การ crawl ต่อเนื่องหลังจากมีการส่งกฎ disallow แล้ว
• User agents ที่น่าสงสัยและมี volume สูง
• User agents ที่ดูเหมือนเบราว์เซอร์แต่ร้องขอหลายพันหน้าต่อเนื่องกัน
• การเข้าถึง feeds, sitemaps, search pages และ pagination ซ้ำ ๆ

หากบอตร้องขอ robots.txt เห็น full disallow แล้วหยุด แสดงว่า robots.txt ทำหน้าที่ของมันแล้ว หากยังดำเนินต่อ ให้ย้ายบอตนั้นไปสู่การบังคับใช้: rate limits, blocks หรือ authentication

ควรทบทวนการเปิดเผย sitemap ของคุณด้วย Sitemaps มีประโยชน์สำหรับ search engines แต่ก็เป็นแผนที่ที่สะดวกสำหรับ scrapers เช่นกัน นั่นไม่ได้หมายความว่าคุณควรลบออกจากเว็บไซต์ทั่วไป แต่หมายความว่าคุณไม่ควรใส่ URL ที่ไม่ต้องการให้ระบบสาธารณะค้นพบ

ทำให้ไฟล์เล็กและมีการทบทวน

Robots.txt มีแนวโน้มเสื่อมสภาพตามเวลา ทีม marketing เพิ่ม campaign microsite นักพัฒนาเพิ่ม staging path ผู้ให้บริการเปลี่ยนชื่อ crawler สองปีต่อมาไม่มีใครรู้ว่ากฎครึ่งหนึ่งมีไว้ทำไม

ปฏิบัติกับมันเหมือน configuration:

• เก็บไว้ใน version control เมื่อเป็นไปได้
• เพิ่ม comment สั้น ๆ สำหรับแต่ละกลุ่ม AI crawler
• ทบทวนทุกไตรมาส
• ตรวจเอกสารของผู้ให้บริการก่อนเพิ่มกฎแบบกว้าง
• ทดสอบหลังมีการเปลี่ยนแปลง CDN, CMS หรือ hosting

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

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: หลังจากเพิ่มกฎสำหรับ AI crawler แล้ว ให้ยืนยันไวยากรณ์ด้วย Robots.txt Tester เพื่อไม่ให้คุณเผลอบล็อกบอตที่ถูกต้องด้วย

<!-- tool-cta:end -->

สรุปสำคัญ

ไฟล์ robots.txt ที่ดีจะบล็อก AI crawlers ที่ปฏิบัติตามกติกาได้ แต่จะไม่หยุดการ scraping ที่ตั้งใจจริง user-agent strings ที่ถูกคัดลอก เบราว์เซอร์ที่ถูก compromise หรือคนที่คัดลอกเนื้อหาของคุณไปวางในระบบ AI ด้วยตนเอง

นั่นไม่ได้ทำให้มันไร้ประโยชน์ แต่มันทำให้มันเป็นเพียงชั้นหนึ่งของการป้องกัน

เขียนกฎให้ชัดเจนสำหรับ AI crawlers ที่มีเอกสารระบุไว้ หลีกเลี่ยงการบล็อกแบบกว้างที่ทำลายการมองเห็นใน search ทดสอบไฟล์ที่ถูก serve จริง ไม่ใช่ draft ดู logs และบังคับใช้ด้วยการควบคุมฝั่งเซิร์ฟเวอร์เมื่อพฤติกรรมข้ามจากไม่พึงประสงค์ไปสู่การละเมิด

เว็บดำเนินมาโดยอาศัยส่วนผสมของ protocol, บรรทัดฐาน และการบังคับใช้เสมอมา Robots.txt คือชั้นของบรรทัดฐาน ใช้มัน แต่อย่าสับสนว่ามันคือกำแพง