รายงาน | robots.txt กลายเป็นปัญหานโยบายของเว็บได้อย่างไร

สรุปสำหรับผู้บริหาร

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

รายงานฉบับต่อเนื่องนี้ตั้งคำถามเชิงปฏิบัติการที่อยู่เบื้องหลังคำถามนั้น: robots.txt มีความน่าเชื่อถือแค่ไหน ในฐานะโครงสร้างพื้นฐานที่ตอนนี้ถูกขอให้แบกรับนโยบายดังกล่าว?

คำตอบคือไม่สบายใจนัก robots.txt ยังใช้งานได้เพราะมันเปิดเผยต่อสาธารณะ ราคาถูก อ่านได้โดยเครื่อง และ crawler เข้าใจอยู่แล้ว แต่ในขณะเดียวกันมันก็ถูกขอให้ทำมากกว่าที่มันถูกออกแบบมาให้ทำ ในปี 2026 ไฟล์ข้อความธรรมดาไฟล์เดียวกันนี้อาจมีทั้งการควบคุมการ crawl เพื่อ SEO, ดัชนี sitemap, ส่วนขยายจากเสิร์ชเอ็นจินรุ่นเก่า, การยกเลิกสิทธิ์สำหรับการฝึก AI, ศัพท์นโยบายที่ Cloudflare แทรกเข้ามา, ข้อสงวนลิขสิทธิ์ และภาษากฎหมายที่เผื่อไว้สำหรับข้อพิพาทในอนาคต

นั่นคือหนี้ทางการตั้งค่า

ชุดข้อมูลที่อยู่เบื้องหลังรายงานนี้ใช้การ crawl Tranco Top 10,000 ชุดเดียวกับการศึกษาครั้งก่อนเกี่ยวกับ AI crawler จากโดเมน 10,000 แห่ง มี 6,638 โดเมนที่ส่งคืน robots.txt ที่อ่านได้ อีก 610 โดเมนส่งคืน 404 ซึ่งตามโปรโตคอลถือว่าอนุญาตโดยปริยาย ดังนั้นจึงมี 7,248 เว็บไซต์ที่นำมาวิเคราะห์เรื่องการเข้าถึงของบอท และมีไฟล์จริง 6,638 ไฟล์สำหรับวิเคราะห์ความซับซ้อนของการตั้งค่า

มี 6 ข้อค้นพบที่เด่นชัด:

1. ไฟล์ robots.txt ส่วนใหญ่มีขนาดเล็ก แต่หางด้านขวาซับซ้อนมาก ค่ามัธยฐานของไฟล์มีเพียง 834 ไบต์และ 31 บรรทัด แต่มี 1,005 ไฟล์ที่ใหญ่กว่า 5 KB, 273 ไฟล์ที่ใหญ่กว่า 20 KB และ 28 ไฟล์ที่ใหญ่กว่า 100 KB ไฟล์ที่ใหญ่ที่สุดในตัวอย่างมีขนาด 248 KB

2. เว็บไซต์ชั้นนำหลายร้อยแห่งใช้ไฟล์ที่ใกล้เคียงกับคอนฟิกระดับโปรดักชันมากกว่าบันทึกนโยบาย ค่ามัธยฐานของไฟล์มี Disallow 9 รายการ แต่มี 707 เว็บไซต์ที่มีอย่างน้อย 100 กฎ Disallow, 13 แห่งที่มีอย่างน้อย 1,000, 240 แห่งที่ระบุ user agent อย่างน้อย 50 ตัว และ 110 แห่งที่ระบุ user agent อย่างน้อย 100 ตัว

3. drift ของโปรโตคอลไม่ใช่เรื่องสมมติ ในบรรดาไฟล์ที่อ่านได้ 6,638 ไฟล์ มี 685 ไฟล์ที่มี Crawl-delay, 303 ไฟล์ที่มี Host, 200 ไฟล์ที่มี Clean-param, 9 ไฟล์ที่มี Request-rate, 5 ไฟล์ที่มี Visit-time และ 271 ไฟล์ที่มีภาษาแบบ Content-Signal ของ Cloudflare สิ่งเหล่านี้ไม่ใช่ส่วนหนึ่งของมาตรฐานเดียวกันทั้งหมด แต่เป็นภูมิปัญญาแบบ crawler ที่สะสมทับกันมา

4. Googlebot ถูกปฏิบัติราวกับเป็นพลเมืองพิเศษ โดเมนที่วิเคราะห์ได้ 562 แห่งบล็อก search crawler แบบดั้งเดิมอย่างน้อยหนึ่งตัว ใน 404 กรณีจากนั้น Googlebot ยังถูกอนุญาต ในขณะที่ search crawler ตัวอื่นอย่างน้อยหนึ่งตัวถูกบล็อก การเลือกปฏิบัติต่อ AI crawler ไม่ได้เกิดขึ้นในระบบนิเวศที่เป็นกลาง แต่ robots.txt ได้เข้ารหัสลำดับชั้นของเสิร์ชเอ็นจินไว้อยู่แล้ว

5. นโยบายด้าน AI ทำให้หนี้ก้อนนี้มองเห็นชัดขึ้น ไฟล์ที่อ่านได้ 1,377 ไฟล์มีภาษานโยบาย AI; 719 ไฟล์มีภาษาลิขสิทธิ์ ข้อกำหนด เงื่อนไข ใบอนุญาต หรือการสงวนสิทธิ์; และ 501 ไฟล์มีทั้งสองอย่าง ไฟล์นี้จึงกลายเป็นทั้งอินเทอร์เฟซสำหรับเครื่องและเอกสารเชิงกฎหมายไปพร้อมกัน ซึ่งมีประโยชน์ แต่ก็เปราะบาง

6. ไฟล์ที่เสี่ยงที่สุดไม่ใช่ไฟล์ที่ต่อต้าน AI เสมอไป อีคอมเมิร์ซ การท่องเที่ยว โซเชียล การเงิน วิชาการ และข่าว ล้วนสร้างไฟล์ที่ซับซ้อนด้วยเหตุผลต่างกัน: การควบคุม crawl budget, เส้นทางเก่า, เนื้อหาที่ผู้ใช้สร้าง, การสงวนสิทธิ์ และข้อยกเว้นเฉพาะบอท กฎสำหรับ AI กำลังถูกซ้อนทับลงบนฐานที่รกอยู่แล้ว

ข้อสรุปหลักคือ: robots.txt ยังคงเป็นพื้นผิวนโยบายสำหรับ crawler ที่สำคัญที่สุดของเว็บสาธารณะ แต่เป็นฐานที่อ่อนแอสำหรับการกำกับ AI ที่มีเดิมพันสูง เว้นแต่ว่าระบบนิเวศจะมาตรฐานเรื่องตัวตนของ crawler, ศัพท์เกี่ยวกับการใช้งาน AI และความสามารถในการตรวจสอบนโยบาย

---

วิธีการศึกษา

รายงานนี้นำชุดข้อมูลจากการวิเคราะห์ดั้งเดิมของ Thunderbit เกี่ยวกับนโยบาย AI crawler บนโดเมน Tranco Top 10,000 กลับมาใช้อีกครั้ง

วัตถุดิบข้อมูลที่ใช้มีดังนี้:

• tranco_top10k.csv — รายชื่อโดเมน Tranco Top 10K ต้นฉบับ
• out/fetch_meta.csv — สถานะการดึงข้อมูล, จำนวนไบต์, scheme, ผลลัพธ์การ redirect และ metadata ของข้อผิดพลาด
• out/sites.csv — โดเมน, อันดับ, หมวดหมู่, ภาษา และสถานะ robots.txt
• out/site_meta.csv — แถวเชิงวิเคราะห์หนึ่งแถวต่อเว็บไซต์ รวมถึงคลาสเทมเพลต, flags การบล็อก AI, ขนาดไฟล์ และฟิลด์สรุปนโยบายบอท
• out/bot_status.csv — หนึ่งแถวต่อโดเมนและ crawler รวมถึงว่าบอทนั้นถูกบล็อกหรือไม่ และมีกฎเฉพาะนั้นอยู่หรือไม่
• raw_robots/ — เนื้อหา robots.txt ที่แคชไว้สำหรับ 6,638 เว็บไซต์ที่ส่งคืนสถานะ 200

สำหรับการต่อยอดครั้งนี้ ไฟล์ robots.txt ที่อ่านได้ทุกไฟล์ถูกสแกนหา:

• ขนาดไฟล์และจำนวนบรรทัด
• บรรทัดที่ใช้งานจริงซึ่งไม่ใช่คอมเมนต์
• จำนวน directive User-agent, Disallow, Allow และ Sitemap
• directive รุ่นเก่าหรือไม่ใช่แกนหลัก เช่น Crawl-delay, Host, Clean-param, Request-rate และ Visit-time
• คำศัพท์ยุค AI เช่น Content-Signal, llms.txt, AI, LLM, machine learning, TDM และ 2019/790
• ศัพท์ทางกฎหมาย เช่น copyright, terms of service, licensing, permission และภาษาที่เกี่ยวกับการสงวนสิทธิ์
• การปฏิบัติต่อ search crawler สำหรับ Googlebot, Bingbot, DuckDuckBot, Slurp, Baiduspider และ YandexBot

รายงานยังได้กำหนด คะแนนหนี้ด้านการตั้งค่า แบบง่าย ๆ สำหรับใช้คัดกรอง โดยรวมขนาดไฟล์, จำนวน user agent, จำนวน Disallow, จำนวน Allow, จำนวน directive ที่ไม่เป็นมาตรฐาน และการผสมกันของภาษานโยบาย AI กับภาษากฎหมาย คะแนนนี้ไม่ได้ตั้งใจให้เป็นตัวชี้วัดความถูกต้องสากล แต่เป็นวิธีระบุไฟล์ที่น่าจะดูแล ทบทวน หรือทำความเข้าใจได้ยาก

ตารางและแผนภูมิที่ได้มาทั้งหมดอยู่ในโฟลเดอร์ที่ส่งมอบ

---

ข้อค้นพบที่ 1: ค่าเฉลี่ยกลางเรียบง่าย แต่หางไม่ใช่

ไฟล์ robots.txt ทั่วไปบนเว็บขนาดใหญ่ยังคงเล็กอยู่

ในบรรดาไฟล์ที่อ่านได้ 6,638 ไฟล์:

ตัวชี้วัด	มัธยฐาน	P90	P95	P99	สูงสุด
ขนาดไฟล์	834 ไบต์	6.7 KB	15.8 KB	76.0 KB	248.3 KB
บรรทัด	31	238	332	1,008	4,998
บรรทัดที่ใช้งานจริง	23	198	282	837	4,998
directive User-agent	1	21	39	137	823
directive Disallow	9	103	176	422	4,997
directive Allow	1	17	33	69	890

การกระจายแบบนี้สำคัญ เพราะ robots.txt มักถูกพูดถึงราวกับว่าเป็นเพียงคำประกาศสั้น ๆ:

User-agent: *
Disallow: /private/

กรอบคิดแบบนั้นไม่ถูกต้องสำหรับเว็บปริมาณทราฟฟิกสูงจำนวนไม่น้อย

ในชุดข้อมูลนี้:

เกณฑ์ความซับซ้อน	เว็บไซต์
robots.txt มีขนาดตั้งแต่ 5 KB ขึ้นไป	1,005
มีขนาดตั้งแต่ 20 KB ขึ้นไป	273
มีขนาดตั้งแต่ 100 KB ขึ้นไป	28
มี directive User-agent อย่างน้อย 50 รายการ	240
มี directive User-agent อย่างน้อย 100 รายการ	110
มี directive Disallow อย่างน้อย 100 รายการ	707
มี directive Disallow อย่างน้อย 1,000 รายการ	13
มี directive Allow อย่างน้อย 100 รายการ	40

ไฟล์ที่ใหญ่และซับซ้อนที่สุดไม่ใช่แค่ของแปลกทางวิชาการ แต่เป็นของจริงบนเว็บไซต์ที่มีทราฟฟิกสูง:

โดเมน	อันดับ	หมวดหมู่	ไบต์	User-agent	Disallow	Allow
linkedin.com	17	โซเชียล	114,341	76	4,184	281
runescape.com	5,226	ไม่ทราบ	113,393	1	4,997	0
academia.edu	832	วิชาการ	57,384	63	2,044	227
etsy.com	286	อีคอมเมิร์ซ	51,320	3	1,621	120
thepaper.cn	9,395	ข่าว	56,867	1	1,496	0
opentable.com	4,137	ไม่ทราบ	70,494	32	1,683	176
alfabank.ru	2,625	การเงิน	73,158	2	1,566	133

ไฟล์เหล่านี้ใกล้เคียงกับตาราง routing ในโปรดักชันมากกว่าสโลแกนนโยบาย พวกมันบันทึกการเปิดตัวผลิตภัณฑ์เป็นปี ๆ, เส้นทางเก่า, รูปแบบพารามิเตอร์ที่ถูกบล็อก, ข้อยกเว้นของ crawler, การทดลอง SEO, การตัดสินใจของ CDN และตอนนี้รวมถึงกฎของ AI crawler ด้วย

หางด้านขวาไม่ใช่แค่เรื่อง AI อย่างเดียว ในบรรดา 273 ไฟล์ที่มีขนาดตั้งแต่ 20 KB ขึ้นไป มี 131 ไฟล์ที่มีภาษานโยบาย AI และ 142 ไฟล์ที่ไม่มี ในบรรดา 707 ไฟล์ที่มี Disallow อย่างน้อย 100 รายการ มีเพียง 207 ไฟล์ที่มีภาษานโยบาย AI กล่าวอีกอย่างคือ AI ไม่ได้สร้างปัญหาไฟล์ขนาดใหญ่ มันเข้ามาหลังจากการปฏิบัติการเว็บตามปกติเป็นเวลาหลายปีที่ได้เติมไฟล์นี้ด้วยกฎของเส้นทาง, การอ้างอิง sitemap และข้อยกเว้นของ crawler ไปแล้ว

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

ความเสี่ยงเชิงปฏิบัติการนั้นตรงไปตรงมา: เมื่อ robots.txt โตขึ้น มันยิ่งยากขึ้นสำหรับผู้เผยแพร่, วิศวกรแพลตฟอร์ม, นักกฎหมาย หรือหัวหน้า SEO ที่จะตอบคำถามพื้นฐานว่า ไฟล์นี้อนุญาตอะไรจริง ๆ?

คำถามนั้นไม่ใช่เรื่องง่ายอีกต่อไป ภายใต้การ parse แบบ RFC crawler อาจเลือกกลุ่ม user agent ที่เฉพาะเจาะจงกว่ากลุ่ม User-agent: *; การจับคู่พาธที่ยาวกว่าสามารถทับกฎที่สั้นกว่า; Allow และ Disallow มีลำดับความสำคัญเมื่อทำงานร่วมกัน; และกฎ deny-all แบบทั่วไปอาจจับ crawler ใหม่ที่ยังไม่มีอยู่ตอนเขียนไฟล์ได้โดยไม่ตั้งใจ

สำหรับไฟล์ 30 บรรทัด มนุษย์ยังพอให้เหตุผลได้ แต่สำหรับไฟล์ 4,000 บรรทัดที่มีบอทชื่อเฉพาะหลายสิบตัว ไม่มีใครควรต้องทำแบบนั้น

---

ข้อค้นพบที่ 2: robots.txt กำลังแบกมากกว่ากฎการ crawl

การถกเถียงเรื่อง AI crawler ทำให้ robots.txt ถูกมองเห็นในทางการเมืองมากขึ้น แต่ไฟล์นี้ได้สะสมภารกิจที่ไม่เกี่ยวกันมานานแล้ว

robots.txt ของเว็บระดับท็อปในปัจจุบันอาจมี:

• การควบคุมเส้นทางของ crawler
• การค้นหา sitemap
• ส่วนขยายเฉพาะเสิร์ชเอ็นจิน
• คำใบ้เรื่องอัตราการ crawl
• คำใบ้เรื่อง canonical ของ host
• คำใบ้เรื่องการล้างพารามิเตอร์ URL
• ศัพท์นโยบายที่ CDN แทรกเข้ามา
• ข้อความสงวนลิขสิทธิ์
• การยกเว้นจากการฝึก AI
• คอมเมนต์เชิงกฎหมายที่มนุษย์อ่านได้

ชุดข้อมูลแสดงให้เห็นการซ้อนทับนี้อย่างชัดเจน

สัญญาณ	ไฟล์	สัดส่วนของไฟล์ที่อ่านได้
Crawl-delay	685	10.3%
Host	303	4.6%
Clean-param	200	3.0%
Content-Signal	271	4.1%
Request-rate	9	0.1%
Visit-time	5	0.1%
การกล่าวถึง llms.txt	83	1.3%
ภาษาลิขสิทธิ์, ข้อกำหนด, ใบอนุญาต หรือการอนุญาต	719	10.8%
ภาษานโยบาย AI	1,377	20.7%

บาง directive ได้รับการยอมรับอย่างกว้างขวางโดย crawler เฉพาะบางตัว บางอย่างเป็นธรรมเนียมเก่า บางอย่างผูกกับผู้ให้บริการ และบางอย่างไม่ใช่ directive ของ crawler จริง ๆ แต่เป็นภาษากฎหมายหรือข้อความผลิตภัณฑ์ที่ฝังอยู่ในคอมเมนต์

นั่นแหละคือหน้าตาของ protocol drift

Crawl-delay เป็นตัวอย่างที่ดี หลายผู้ดูแลเว็บไซต์คุ้นเคยกับมัน แต่การรองรับใน crawler หลัก ๆ ไม่สม่ำเสมอ Host และ Clean-param ในเชิงประวัติมักเชื่อมโยงกับพฤติกรรมของ Yandex Content-Signal เป็นส่วนหนึ่งของศัพท์นโยบายยุค AI ของ Cloudflare llms.txt เป็นฟอร์แมตการค้นพบใกล้เคียงที่ยังเป็นข้อเสนอ ไม่ใช่มาตรฐานที่ทุกฝ่ายยอมรับ แต่ทั้งหมดนี้กลับปรากฏอยู่ในไฟล์ชนิดเดียวกัน และมักอยู่ข้าง ๆ กฎ User-agent และ Disallow แบบคลาสสิก

ตัวเลขยังแสดงให้เห็นว่าธรรมเนียมเก่าและใหม่กำลังอยู่ร่วมกัน Crawl-delay ปรากฏใน 685 ไฟล์ มากกว่าจำนวน 271 ไฟล์ที่มี Content-Signal เกินสองเท่า Host ปรากฏใน 303 ไฟล์ และ Clean-param ใน 200 ไฟล์ ซึ่งส่วนใหญ่สะท้อนธรรมเนียมจากยุคเสิร์ชเอ็นจิน llms.txt แม้จะถูกพูดถึงมากในวงการ AI-search แต่กลับถูกกล่าวถึงในไฟล์ที่อ่านได้เพียง 83 ไฟล์ เว็บจริงไม่ได้กำลังมุ่งไปสู่ศัพท์ชุดเดียว แต่มันกำลังซ้อนศัพท์หลายชุดทับกัน

ปัญหาไม่ใช่ว่ามี extension ใด extension หนึ่งผิด แต่ปัญหาคือไฟล์นี้กลายเป็นภาชนะที่ไม่มีเวอร์ชันสำหรับระบบกำกับดูแลหลายชุดที่ทับซ้อนกัน

สิ่งนี้สร้างหนี้ 3 แบบ:

1. หนี้เชิงความหมาย crawler ต่างชนิดอาจตีความไฟล์เดียวกันต่างกัน
2. หนี้เรื่องความเป็นเจ้าของ ทีม SEO, กฎหมาย, โครงสร้างพื้นฐาน, ความปลอดภัย และผลิตภัณฑ์อาจล้วนมีเหตุผลจะแก้ไฟล์นี้ แต่ไม่มีทีมเดียวที่เป็นเจ้าของนโยบายทั้งหมด
3. หนี้ด้านการตรวจสอบ เว็บไซต์สามารถเผยแพร่นโยบายที่ดูเหมือนตั้งใจดี ทั้งที่มีเพียง parser เท่านั้นที่จะบอกพฤติกรรมจริงได้

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

---

ข้อค้นพบที่ 3: ไฟล์นี้กลายเป็นทั้งอินเทอร์เฟซของเครื่องและเอกสารทางกฎหมาย

รายงาน AI crawler ฉบับแรกแสดงให้เห็นว่า 17.0% ของเว็บไซต์ที่วิเคราะห์ได้เขียนกฎเฉพาะสำหรับ AI อย่างชัดเจน รายงานต่อเนื่องนี้มองไปที่ภาระข้อความที่นโยบายเหล่านั้นเพิ่มเข้ามา

ในบรรดาไฟล์ robots.txt ที่อ่านได้ 6,638 ไฟล์:

• 1,377 ไฟล์มีภาษานโยบาย AI
• 719 ไฟล์มีภาษาลิขสิทธิ์, ข้อกำหนด, ใบอนุญาต, สิทธิ์ หรือการอนุญาต
• 271 ไฟล์มี Content-Signal
• 83 ไฟล์กล่าวถึง llms.txt

สิ่งที่น่าสนใจยิ่งกว่าคือส่วนที่ทับซ้อนกัน:

รูปแบบข้อความ	ไฟล์
ภาษานโยบาย AI และภาษากฎหมาย/สิทธิ์	501
ภาษานโยบาย AI โดยไม่มีภาษากฎหมาย/สิทธิ์	876
ภาษากฎหมาย/สิทธิ์โดยไม่มีภาษานโยบาย AI	218
Content-Signal พร้อมภาษากฎหมาย/สิทธิ์	242
การบล็อก AI แบบชัดเจนพร้อมภาษากฎหมาย/สิทธิ์	424

นี่คือไฟล์ชนิดใหม่

robots.txt แบบดั้งเดิมถูกเขียนถึง crawler โดยตรง แต่ robots.txt ที่มีคำนำหน้าทางกฎหมายถูกเขียนถึงผู้ชมอย่างน้อย 4 กลุ่มพร้อมกัน:

• ผู้ดูแล crawler ที่ต้องการคำสั่งแบบอ่านโดยเครื่อง
• ผู้ให้บริการ search และ AI ที่ต้องการสัญญาณนโยบาย
• นักกฎหมายที่ต้องการสงวนสิทธิ์อย่างชัดเจน
• ผู้ตรวจสอบในอนาคต ศาล หรือผู้สื่อข่าว ที่อาจอ่านข้อความเหล่านี้เป็นหลักฐานของเจตนา

การออกแบบให้ตอบสนองผู้ชมหลายกลุ่มเช่นนี้อธิบายได้ว่าทำไมบางไฟล์จึงอ่านเหมือนเอกสารนโยบาย แต่ก็ทำให้เส้นแบ่งที่ชัดเจนระหว่างสิ่งที่ crawler parse ได้กับสิ่งที่นักกฎหมายต้องการระบุให้พร่าเลือนลง

ไฟล์ 876 ไฟล์ที่มีภาษานโยบาย AI แต่ไม่มีศัพท์กฎหมาย ส่วนใหญ่เป็นไฟล์นโยบายเชิงเครื่อง: ชื่อบอท, บล็อก Disallow และภาษาจากเทมเพลต ไฟล์ 501 ไฟล์ที่มีทั้งภาษา AI และภาษากฎหมายแตกต่างออกไป พวกมันพยายามเป็นทั้งคำสั่งสำหรับ crawler และการสงวนสิทธิ์ไปพร้อมกัน ส่วนไฟล์ 218 ไฟล์ที่มีภาษากฎหมายแต่ไม่มีศัพท์ AI แสดงให้เห็นว่าแพตเทิร์นนี้ไม่ได้เริ่มจาก LLM robots.txt ถูกใช้เป็นที่ระบุข้อกำหนด, ขอบเขตการอนุญาต และการอ้างสิทธิ์มานานแล้ว

ตัวอย่างเช่น คอมเมนต์อาจบอกว่า machine learning ถูกห้าม แต่บล็อกคำสั่งจริงอาจแค่ปฏิเสธ user agent ที่รู้จักบางส่วน เว็บไซต์หนึ่งอาจอ้างสิทธิ์แบบครอบคลุมทั่วโลก แต่ตั้งชื่อ crawler แค่ไม่กี่ตัว เทมเพลตของ CDN อาจแทรกคำศัพท์เกี่ยวกับ AI ลงในไฟล์ที่ผู้ดูแลไม่เคยเขียนข้อความทางกฎหมายนั้นด้วยตนเอง เว็บไซต์หนึ่งอาจเขียนกฎ User-agent: * แบบกว้าง ๆ ที่บล็อก crawler ใหม่โดยไม่ตั้งใจ

ในมุมการกำกับดูแล robots.txt น่าสนใจเพราะมันเปิดเผยและอ่านได้โดยเครื่อง แต่ยิ่งมันแบกนโยบายมากขึ้น ข้อจำกัดของมันก็ยิ่งสำคัญ:

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

สิ่งนี้ไม่ได้ทำให้ไฟล์ไร้ประโยชน์ แต่มันทำให้เปราะบาง

การตีความที่ดีกว่าคือ robots.txt กำลังกลายเป็นเลเยอร์การแจ้งเตือน: คำประกาศความตั้งใจและความชอบแบบเปิดเผยต่อสาธารณะและตรวจสอบได้ มันไม่ใช่ระบบจัดการสิทธิ์แบบครบถ้วนด้วยตัวมันเอง

---

ข้อค้นพบที่ 4: การค้นหาไม่เคยเท่าเทียมอยู่แล้ว ก่อนที่ AI จะมาถึง

หนึ่งในข้อค้นพบที่แข็งแรงที่สุดในรายงานฉบับเดิมคือ ผู้เผยแพร่จำนวนมากแยกความแตกต่างระหว่าง crawler สำหรับฝึก AI กับ crawler สำหรับค้นหา พวกเขาบล็อก CCBot, GPTBot หรือ Google-Extended แต่ยังคงรักษาการมองเห็นบน Google Search เอาไว้

รายงานต่อเนื่องนี้เพิ่มอีกประเด็น: crawler สำหรับเสิร์ชเอ็นจินแบบดั้งเดิมก็ไม่ได้ถูกปฏิบัติเท่าเทียมกันเช่นกัน

เราตรวจสอบ search crawler 6 ตัว:

• Googlebot
• Bingbot
• DuckDuckBot
• Slurp
• Baiduspider
• YandexBot

ในบรรดาเว็บไซต์ที่วิเคราะห์ได้ 7,248 แห่ง:

การปฏิบัติต่อ search crawler	เว็บไซต์
บล็อก search crawler อย่างน้อยหนึ่งตัว	562
อนุญาต Googlebot แต่บล็อก search crawler ตัวอื่นอย่างน้อยหนึ่งตัว	404
บล็อก search crawler ทั้ง 6 ตัวที่ตรวจสอบ	152

จำนวนบอทที่ถูกบล็อกไม่ได้กระจายอย่างเท่าเทียม:

search crawler	เว็บไซต์ที่บล็อก
Baiduspider	424
YandexBot	393
Slurp	255
DuckDuckBot	231
Bingbot	204
Googlebot	158

Googlebot เป็น crawler ที่ถูกบล็อกน้อยที่สุดในชุดนี้ Baiduspider และ YandexBot ถูกบล็อกบ่อยกว่ามาก และในกรณีส่วนใหญ่ Googlebot ยังถูกอนุญาต ในบรรดา 404 เว็บไซต์ที่อนุญาต Googlebot แต่บล็อก search crawler ตัวอื่น 269 แห่งบล็อก Baiduspider และ 240 แห่งบล็อก YandexBot

ตัวอย่างที่เป็นแบรนด์ดัง:

โดเมน	search crawler ที่ถูกบล็อกในขณะที่ Googlebot ยังถูกอนุญาต
facebook.com	Baiduspider, YandexBot
apple.com	Baiduspider
twitter.com	DuckDuckBot, Slurp, Baiduspider, YandexBot
netflix.com	DuckDuckBot, Slurp
x.com	DuckDuckBot, Slurp, Baiduspider, YandexBot
tiktok.com	Baiduspider
baidu.com	Bingbot, DuckDuckBot, Slurp, YandexBot
washingtonpost.com	YandexBot
wsj.com	YandexBot
bilibili.com	DuckDuckBot, Slurp, YandexBot
temu.com	Slurp
t-mobile.com	Baiduspider, YandexBot

เรื่องนี้สำคัญต่อการถกเถียงเรื่อง AI เพราะมันแสดงว่า robots.txt ไม่เคยเป็นโปรโตคอลการเข้าถึงแบบเป็นกลางและสากล แม้ก่อนที่ LLM crawler จะมาถึง เว็บสาธารณะก็มีลำดับชั้นอยู่แล้ว:

• Googlebot มักถูกเก็บไว้ เพราะทราฟฟิกจาก Google Search มีค่ามากเกินกว่าจะเสี่ยงเสียไป
• crawler ของภูมิภาคหรือคู่แข่งบล็อกได้ง่ายกว่า
• บางเว็บไซต์มองการเข้าถึงของ search crawler เป็นการตัดสินใจรายตลาดหรือรายผู้ให้บริการ

AI crawler เข้ามาในระบบนิเวศที่การเข้าถึงแบบแบ่งระดับเป็นเรื่องปกติอยู่แล้ว

นั่นทำให้การเปลี่ยนนโยบายเข้าใจได้ง่ายขึ้น ผู้เผยแพร่ที่เขียนว่า "บล็อก Google-Extended, อนุญาต Googlebot" ไม่ได้กำลังประดิษฐ์การเลือกปฏิบัติรูปแบบใหม่ แต่กำลังนำแพตเทิร์นเก่ามาใช้กับ crawler ประเภทใหม่: รักษาช่องทางกระจายเนื้อหาไว้ จำกัดการดึงข้อมูล

คำถามที่ยังไม่จบคือ แพตเทิร์นเก่านี้จะขยายตัวได้แค่ไหน เมื่อเป็น search มี crawler ที่สำคัญทางเศรษฐกิจแค่ไม่กี่ตัว แต่เมื่อเป็น AI ตัวตนของ crawler แตกกระจายไปตาม vendor ของโมเดล, retrieval bot, data broker, academic crawler, synthetic browser agents และตัวดึงข้อมูลระดับโครงสร้างพื้นฐาน จำนวน user agent ที่มีชื่อจะยังเพิ่มต่อไป เว้นแต่ระบบนิเวศจะรวมตัวกันรอบสัญญาณเชิงวัตถุประสงค์ที่มีจำนวนน้อยกว่า

นั่นคือวิธีที่หนี้ด้านการตั้งค่าทบต้นขึ้น

---

ข้อค้นพบที่ 5: ความซับซ้อนต่างกันตามอุตสาหกรรม แต่ไม่เหมือนอัตราการบล็อก AI

รายงานฉบับเดิมแสดงให้เห็นช่องว่างขนาดใหญ่ระหว่างอุตสาหกรรมในเรื่องการบล็อก AI: ข่าวบล็อกในอัตราสูง ส่วนโทรคมนาคม รัฐบาล และ SaaS บล็อกในอัตราต่ำ

ความซับซ้อนของการตั้งค่ากลับแบ่งเว็บออกอีกแบบหนึ่ง

ในหมวดหมู่ที่เลือกมาและมีไฟล์ robots.txt ที่อ่านได้เพียงพอสำหรับการเปรียบเทียบเชิงความหมาย:

หมวดหมู่	n	ขนาดมัธยฐาน (ไบต์)	P90 (ไบต์)	มัธยฐาน Disallow	P90 Disallow	มัธยฐาน User-agent	P90 User-agent
อีคอมเมิร์ซ	215	1,738	10,388	37	164	3	49
การท่องเที่ยว	63	2,074	27,368	41	779	5	34
ข่าว	647	1,534	7,039	19	114	6	68
การเงิน	121	1,002	8,337	17	132	2	23
วิชาการ	253	839	3,959	14	75	1	11
รัฐบาล	151	1,227	3,263	13	46	1	4
SaaS	368	485	12,606	4	56	1	10
เครื่องมือสำหรับนักพัฒนา	119	273	9,255	3	58	1	10

P90 Disallow by category chart here<<<<<<<<<<<<<<<<<<<<<<<<<

ข่าวมีความซับซ้อนทางการเมือง เพราะมันเขียนกฎ AI แบบชัดเจนและมีภาษากฎหมาย แต่อีคอมเมิร์ซและการท่องเที่ยวมีความซับซ้อนเชิงปฏิบัติการ เพราะมีแคตตาล็อกขนาดใหญ่, faceted navigation, หน้าผลการค้นหา, ฟิลเตอร์, เส้นทางบัญชีผู้ใช้ และ URL ที่มีพารามิเตอร์

ความแตกต่างนี้สำคัญ

การท่องเที่ยวเป็นตัวอย่างที่ชัดที่สุด มันมีไฟล์ที่อ่านได้เพียง 63 ไฟล์ในเซ็กชันหมวดหมู่นี้ แต่ไฟล์ robots.txt ใน P90 มีขนาด 27.4 KB และจำนวน Disallow ใน P90 เท่ากับ 779 สูงกว่าข่าวมาก นั่นไม่ได้แปลว่าเว็บไซต์ท่องเที่ยวมีนโยบาย AI ที่พัฒนากว่า แต่แปลว่าเว็บไซต์ท่องเที่ยวมีพื้นผิวจำนวนมากที่ผู้ดูแล crawler อาจสิ้นเปลืองงบ crawl โดยไม่ตั้งใจ: การค้นหาตามวันที่, หน้าแสดงสถานะว่าง, การแบ่งหน้าของรีวิว, ขั้นตอนการจอง, ชุดตัวกรอง และเส้นทางสินค้าคงคลังที่แปลเป็นท้องถิ่น

SaaS คือความประหลาดใจอีกแบบหนึ่ง ไฟล์มัธยฐานมีเพียง 485 ไบต์ แต่ไฟล์ P90 กระโดดไป 12.6 KB เว็บไซต์ SaaS ส่วนใหญ่เปิดกว้างและเบา แต่มีส่วนหนึ่งที่มีไฟล์ควบคุมเส้นทางยาวมาก มักเป็นเพราะเอกสาร, หน้าล็อกอิน, เส้นทางแอป และหน้า marketing อยู่ภายใต้โดเมนเดียวกัน

ข่าวอยู่ระดับกลางในเชิงปฏิบัติการ แต่เกือบสูงสุดในเชิงการเมือง จำนวน user agent ใน P90 เท่ากับ 68 ซึ่งสูงกว่าอีคอมเมิร์ซ, การท่องเที่ยว, การเงิน, วิชาการ, รัฐบาล, SaaS และเครื่องมือสำหรับนักพัฒนาในตารางนี้ นั่นเป็นสัญญาณของนโยบายเฉพาะบอท ไม่ใช่แค่ความสะอาดของเส้นทาง

robots.txt ของผู้เผยแพร่อาจซับซ้อนเพราะนโยบายสิทธิ์ ไฟล์ของตลาดกลางอาจซับซ้อนเพราะการจัดการ crawl budget ไฟล์ของมหาวิทยาลัยอาจซับซ้อนเพราะมีเส้นทางเก่าหลายพันเส้นทางสะสมอยู่ภายใต้โดเมนเดียว ไฟล์ของแพลตฟอร์มโซเชียลอาจซับซ้อนเพราะต้องเปิดบางพื้นผิวและปิดบางอย่างในสเกลมหาศาล

นโยบาย AI ถูกซ้อนลงบนทั้งหมดนั้น มันไม่ได้แทนเหตุผลเดิมที่ทำให้ไฟล์ซับซ้อน

สิ่งนี้ช่วยอธิบายว่าทำไมการกำกับดูแล robots.txt ในยุค AI จึงไม่สามารถแก้ได้ด้วย block list แบบสากล ไฟล์พื้นฐานเหล่านี้มีงานต่างกัน:

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

กฎ AI crawler เดียวกันจึงมีความหมายต่างกันในแต่ละสภาพแวดล้อม

---

ข้อค้นพบที่ 6: ดัชนีหนี้ด้านการตั้งค่าช่วยระบุความเสี่ยงในการทบทวน ไม่ใช่ความล้มเหลวเชิงศีลธรรม

การวิเคราะห์นี้สร้างคะแนนหนี้ด้านการตั้งค่าแบบง่ายเพื่อระบุไฟล์ robots.txt ที่น่าจะทบทวนได้ยาก

คะแนนจะให้น้ำหนักกับ:

• ขนาดไฟล์
• จำนวน directive User-agent
• จำนวน directive Disallow
• จำนวน directive Allow
• จำนวน directive ที่ไม่ใช่แกนหลัก
• การมีภาษานโยบาย AI
• การผสมระหว่างการบล็อก AI แบบชัดเจนกับภาษากฎหมายหรือลิขสิทธิ์

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

การกระจายคะแนนชันมาก ไฟล์ที่อ่านได้ค่ามัธยฐานได้ 1.74 คะแนน ค่า P90 คือ 13.29, P95 คือ 15.00 และ P99 คือ 27.57 มีเพียง 366 ไฟล์ที่ได้อย่างน้อย 15 คะแนน, 80 ไฟล์ที่ได้อย่างน้อย 25 คะแนน และ 41 ไฟล์ที่ได้อย่างน้อย 30 คะแนน นั่นคือคิวตรวจทานในทางปฏิบัติ: ไม่ใช่ทุกเว็บไซต์ที่ต้องมีโปรเจ็กต์ด้านการกำกับดูแล แต่หางบนสุดต้องมี

มุมมองตามหมวดหมู่ยังแสดงให้เห็นว่าป้าย "ตัวบล็อก AI" เพียงอย่างเดียวสื่อความหมายไม่พอ:

หมวดหมู่	คะแนนมัธยฐาน	คะแนน P90
การท่องเที่ยว	4.92	28.94
การค้นหา	2.97	24.23
โซเชียล	2.25	15.00
ข่าว	4.91	14.92
การเงิน	1.67	12.61
SaaS	0.98	11.85
อีคอมเมิร์ซ	3.88	10.87
รัฐบาล	1.57	6.38

การท่องเที่ยวและการค้นหามีคะแนน P90 สูงที่สุด เพราะส่วนน้อยของไฟล์มีขนาดใหญ่มากและมีกฎจำนวนมาก ข่าวมีคะแนนมัธยฐานสูงที่สุดกลุ่มหนึ่ง เพราะภาษานโยบายและการปฏิบัติต่อบอทแบบเฉพาะเจาะจงพบได้บ่อยทั่วทั้งหมวด อีคอมเมิร์ซมีจำนวน Disallow มัธยฐานสูง แต่คะแนนหนี้ P90 ต่ำกว่าการท่องเที่ยว เพราะความซับซ้อนกระจุกตัวอยู่ในกฎของเส้นทางมากกว่าสัญญาณนโยบาย/กฎหมายที่ปะปนกัน

ไฟล์ที่ได้คะแนนสูงที่สุดในชุดข้อมูลนี้ ได้แก่:

โดเมน	เหตุผลที่ได้คะแนนสูง
linkedin.com	ไฟล์ใหญ่มาก, มีกฎเส้นทางนับพัน, มี user agent ที่ระบุชื่อจำนวนมาก, มีภาษานโยบาย AI แบบชัดเจน
lnkd.in	พื้นผิวนโยบายเดียวกับโครงสร้าง shortlink ของ LinkedIn
fragrantica.com	บล็อก user agent ที่ระบุชื่อหลายร้อยตัว พร้อมภาษานโยบาย AI
sovcombank.ru	บล็อก user agent หลายร้อยรายการและมีภาษากฎหมาย/นโยบาย
academia.edu	เมทริกซ์ allow/disallow ขนาดใหญ่และมีนโยบายบล็อก AI แบบชัดเจน
opentable.com	ชุดกฎเส้นทางขนาดใหญ่, directive sitemap จำนวนมาก, พื้นผิวนโยบายที่เกี่ยวกับ AI
etsy.com	ไฟล์ควบคุมเส้นทางของอีคอมเมิร์ซขนาดใหญ่ที่มีกฎ Disallow มากกว่า 1,600 รายการ
runescape.com	มี directive Disallow เกือบ 5,000 รายการภายใต้กลุ่ม user agent เดียว

ไม่ควรเย้ยหยันไฟล์เหล่านี้ว่า “ซับซ้อนเกินไป” ความซับซ้อนมักสะท้อนความต้องการทางธุรกิจจริง แต่ไฟล์เหล่านี้แสดงให้เห็นว่า policy ของ robots.txt สมควรถูกดูแลด้วยวินัยทางวิศวกรรมเช่นเดียวกับคอนฟิกโปรดักชันอื่น ๆ:

• ต้องระบุเจ้าของอย่างชัดเจน
• ต้องมีการรีวิวเมื่อมีการเปลี่ยนแปลง
• ส่วนที่สร้างอัตโนมัติต้องติดป้ายกำกับ
• คอมเมนต์ทางกฎหมายควรถูกแยกจาก directive ของเครื่องเท่าที่ทำได้
• ควรมี test case ยืนยันการเข้าถึงของบอทสำคัญ
• ควรเก็บประวัติเวอร์ชันไว้
• ควรยกเลิกหรือบันทึกชื่อบอทเก่า
• การฝึก AI, การค้นคืนโดย AI, การจัดทำดัชนีค้นหา และการเก็บถาวร ควรถูกมองเป็นวัตถุประสงค์คนละแบบ

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

สองอย่างนี้ไม่เหมือนกัน

ความไม่ตรงกันนี้คือเหตุผลที่ block list ที่ยาวขึ้นเรื่อย ๆ จะไม่คงทน ผู้เผยแพร่สามารถเพิ่ม GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider, Applebot-Extended และ PerplexityBot ได้ในวันนี้ แต่ชื่อ crawler ถัดไป, retrieval agent หรือ dataset broker อาจโผล่มาในวันพรุ่งนี้ นโยบายที่ตั้งบนวัตถุประสงค์จะทำให้เว็บไซต์พูดได้ว่า “อนุญาตการทำดัชนีเพื่อค้นหา, ไม่อนุญาตการฝึก AI, การค้นคืนที่ผู้ใช้ร้องขออาจได้” โดยไม่ต้องแปลง robots.txt ให้กลายเป็นสมุดรายชื่อบอท

---

ความหมายต่อการกำกับดูแล AI

การถกเถียงสาธารณะมักวางกรอบ robots.txt ว่าเป็นสิ่งที่ “มีความหมาย” หรือ “ล้าสมัย” ข้อมูลบอกคำตอบที่ใช้งานได้จริงกว่านั้น:

robots.txt มีความหมาย แต่ถูกแบกภาระมากเกินไป

มันมีความหมาย เพราะเว็บไซต์ใหญ่ ๆ ใช้มัน crawler parse ได้ และการตัดสินใจเชิงนโยบายมองเห็นได้ทั้งโดยนักวิจัย, ผู้สื่อข่าว, ผู้ให้บริการ และศาล รายงานฉบับเดิมพบว่า 17.0% ของเว็บไซต์ชั้นนำที่วิเคราะห์ได้มีกฎเฉพาะสำหรับ AI อย่างตั้งใจ นั่นไม่ใช่สัญญาณรบกวน

มันถูกแบกเกินไป เพราะตอนนี้ไฟล์นี้ต้องสื่อมากกว่าแค่การเข้าถึงของบอท:

• “ห้ามนำเนื้อหานี้ไปฝึก”
• “คุณใช้เนื้อหานี้เพื่อจัดทำดัชนีค้นหาได้”
• “คุณใช้เนื้อหานี้เพื่อการค้นคืนแบบสดได้”
• “คุณไม่อาจสร้างชุดข้อมูลแคชได้”
• “การสงวนสิทธินี้มีผลภายใต้กฎหมาย EU เรื่อง text-and-data-mining”
• “เว็บไซต์ที่จัดการโดย CDN นี้ส่ง Content-Signal: ai-train=no”
• “เว็บไซต์นี้ต้องการ Googlebot แต่ไม่ต้องการ YandexBot”
• “เว็บไซต์นี้มีเส้นทาง URL เก่า 1,000 เส้นทางที่ไม่ควรถูก crawl”

ไวยากรณ์เดิมไม่ได้ออกแบบมาสำหรับงานมากขนาดนั้น

มี 3 การเปลี่ยนแปลงที่จะลดหนี้นี้ได้:

1. ตัวตนของ crawler ต้องมีทะเบียนกลาง ผู้ดูแลเว็บไซต์ไม่ควรต้องคอยดูแลรายชื่อ GPTBot, ClaudeBot, anthropic-ai, CCBot, Google-Extended, Applebot-Extended, Bytespider, OAI-SearchBot, ChatGPT-User และอื่น ๆ ที่เพิ่มขึ้นเรื่อย ๆ หากไม่มีทะเบียนกลาง นโยบายจะตามพฤติกรรมของ crawler ไม่ทันเสมอ

2. การใช้งาน AI ต้องมีศัพท์โครงสร้าง การฝึก, การค้นคืน, การจัดทำดัชนี, การสรุป, การขายต่อชุดข้อมูล, การประเมินโมเดล และการท่องเว็บที่ผู้ใช้เป็นผู้เริ่มเอง ล้วนเป็นการใช้งานต่างกัน การระบุสิ่งเหล่านี้ผ่านชื่อ user-agent เฉพาะ vendor เป็นสิ่งเปราะบาง

3. นโยบายต้องตรวจสอบย้อนกลับได้ เว็บต้องมีวิธีแยกแยะระหว่างการสงวนสิทธิ์ที่เขียนโดยผู้ถือสิทธิ์จริง กับค่า default จาก CDN, เทมเพลต CMS ที่สร้างอัตโนมัติ, กฎเก่าที่ตกค้าง และกฎเหมารวมที่ใส่มาโดยไม่ตั้งใจ ความแตกต่างนี้สำคัญต่อความเชื่อมั่นและคดีความ

ทั้งหมดนี้ไม่ได้หมายความว่าต้องแทน robots.txt ทันที ทางที่ดีกว่าคือการวางซ้อน: ใช้ robots.txt เป็นเลเยอร์สำหรับการค้นพบและความเข้ากันได้ แต่ทำให้นโยบายแบบอ่านได้โดยเครื่องสำหรับการใช้งาน AI เฉพาะทางเป็นมาตรฐานคู่ขนาน

llms.txt เป็นหนึ่งในความพยายามนั้น แต่ในชุดข้อมูลนี้การใช้งานยังน้อยมาก: มีเพียง 83 ไฟล์ที่อ่านได้กล่าวถึงมัน Content-Signal มองเห็นได้ชัดกว่าเพราะ Cloudflare สามารถส่งผ่านโครงสร้างพื้นฐานได้ และไฟล์ Content-Signal ทั้ง 271 ไฟล์ในการสแกนครั้งนี้ก็ตรงกับภาษานโยบาย AI ด้วย อย่างไรก็ตาม การกระจายไม่เท่ากับฉันทามติ ทางออกที่ยั่งยืนอาจต้องอาศัยกลไกการมาตรฐานที่น่าเบื่อแต่จำเป็น: ฟิลด์ที่ชัดเจน, ความหมายที่ชัดเจน, ข้อตกลงของ crawler และชุดทดสอบสาธารณะ

---

บทสรุป

การต่อสู้เรื่อง AI crawler ทำให้ robots.txt กลายเป็นเอกสารด้านการกำกับดูแล ซึ่งทั้งมีประโยชน์และมีความเสี่ยง

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

มีความเสี่ยง เพราะมันแบกมากเกินไป

ไฟล์ robots.txt ค่ามัธยฐานใน Tranco Top 10K ยังเล็กพอที่จะเข้าใจได้ แต่หางยาวของเว็บที่มีทราฟฟิกสูงเต็มไปด้วยไฟล์ขนาดใหญ่, เก่า, หลายชั้น, ผูกกับ vendor และเต็มไปด้วยภาระทางกฎหมาย หลายร้อยเว็บไซต์ตอนนี้ดูแลคอนฟิก robots.txt ในฐานะระบบนโยบายระดับโปรดักชัน มากกว่าคำใบ้สำหรับ crawler แบบง่าย ๆ

บทเรียนสำคัญไม่ใช่ว่า robots.txt ล้มเหลว แต่คือเว็บได้ยกสถานะมันขึ้นมาโดยยังไม่ได้ refactor มัน

หากนโยบายการเข้าถึง AI จะต้องพึ่งพาคำประกาศสาธารณะที่อ่านได้โดยเครื่อง ขั้นตอนถัดไปไม่ใช่ block list ที่ยาวขึ้นอีก แต่คือโครงสร้างพื้นฐานด้านนโยบายที่ดีกว่า: สิทธิ์ที่ตั้งบนวัตถุประสงค์, ตัวตนของ crawler ที่เสถียร, เทมเพลตที่ตรวจทานได้ และร่องรอยการตรวจสอบ

จนกว่าจะถึงวันนั้น เลเยอร์การกำกับดูแล AI ของเว็บสาธารณะก็จะยังคงพึ่งพาไฟล์ข้อความที่ไม่เคยถูกออกแบบมาให้แบกภาระมากขนาดนี้

---

หมายเหตุเพื่อการทำซ้ำผล

โฟลเดอร์ที่ส่งมอบมี:

• source_data/analysis.json — metrics รวมต้นฉบับ
• source_data/site_meta.csv — ตารางวิเคราะห์รายเว็บไซต์ต้นฉบับ
• source_data/bot_status.csv — ตารางนโยบายรายโดเมนต่อบอทต้นฉบับ
• source_data/fetch_meta.csv — metadata การดึงข้อมูลต้นฉบับ
• source_data/sites.csv — ตารางโดเมน/หมวดหมู่/สถานะต้นฉบับ
• derived_data/robots_complexity_by_site.csv — metrics ความซับซ้อนรายเว็บไซต์ที่สร้างสำหรับรายงานนี้
• derived_data/search_bot_treatment.csv — เมทริกซ์การปฏิบัติต่อ search crawler
• derived_data/category_complexity_summary.csv — สรุปความซับซ้อนระดับหมวดหมู่
• derived_data/top_config_debt_sites.csv — เว็บไซต์อันดับต้น ๆ ตามคะแนนคัดกรองที่อธิบายไว้ข้างต้น
• derived_data/summary_metrics.json — metrics หัวข้อทั้งหมดที่อ้างในรายงานนี้

ดาวน์โหลดสคริปต์และชุดข้อมูลทั้งหมด

---

ยินดีรับข้อแก้ไขด้านวิธีการ, ปัญหาของชุดข้อมูล และการวิเคราะห์ต่อเนื่องที่ support@thunderbit.com รายงานนี้เผยแพร่โดยเป็นอิสระจากจุดยืนเชิงพาณิชย์ใด ๆ ที่ Thunderbit อาจมี เราสร้าง AI-powered web scraper และเรามีความสนใจเชิงโครงสร้างให้ robots.txt ยังคงเป็นสัญญาที่อ่านได้โดยเครื่องและมีความหมายบนเว็บสาธารณะ ข้อมูลในรายงานนี้ยืนอยู่ได้ด้วยตัวเอง — ทีมวิจัย Thunderbit, พฤษภาคม 2026.

ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บด้วย AI Get Started Free