สรุปสั้น ๆ (TL;DR)
- Cloudflare เผยแพร่ Bot Preference Sync เมื่อวันที่ 21 สิงหาคม 2569 ซึ่งสร้างไฟล์ robots.txt จากนโยบายบอท AI ที่ตั้งไว้ในแดชบอร์ด ใช้ได้ทุกแพ็กเกจตั้งแต่ฟรีถึง Enterprise
- บล็อกที่ระบบสร้างจะถูกวางไว้ด้านบนของ robots.txt เดิม คร่อมด้วยเครื่องหมาย BEGIN และ END และรายชื่อ user agent จะถูกปรับเป็นระยะจาก BotBase ของ Cloudflare
- ตัวเลือก Disallow ในหมวด Training จะเขียนความประสงค์ไม่ให้นำไปเทรน ในรูปแบบที่บอทลูกผสมซึ่งให้ความร่วมมือยังทำดัชนีการค้นหาได้ต่อไป
- ผู้ให้บริการที่บอททำทั้ง Search และ Training ต้องผ่านเงื่อนไขการเปิดเผยสี่ข้อ รวมถึงการรายงานระดับ URL ว่าหน้าไหนถูกใช้เทรน มิฉะนั้นจะยังถูกบล็อก
- โดเมนใหม่ที่ระบุว่าหารายได้จากโฆษณาจะได้ค่าตั้งต้นหมวด Training เป็น Disallow ส่วนโดเมนใหม่รายอื่นจะไม่มีการใช้การบล็อกใดตอนเริ่มต้น
Cloudflare เผยแพร่ฟีเจอร์ชื่อ Bot Preference Sync เมื่อวันที่ 21 สิงหาคม 2569 ซึ่งจะสร้างหรืออัปเดตไฟล์ robots.txt ของเว็บไซต์โดยตรงจากนโยบายบอท AI ที่ตั้งค่าไว้แล้วในแดชบอร์ดของ Cloudflare ระบุว่าใช้ได้กับทุกแพ็กเกจตั้งแต่ระดับฟรีไปจนถึง Enterprise เปิดหรือปิดเมื่อไรก็ได้ และช่วงเวลาที่จะพร้อมใช้งานถูกระบุไว้ว่าเป็นสัปดาห์ถัดไป โดยชี้ให้ไปดูการยืนยันการทยอยปล่อยฟีเจอร์ที่หน้า changelog ของบริษัท พร้อมกันนั้น ตัวเลือก Disallow ของหมวด Training จะเขียนความประสงค์ว่าไม่อนุญาตให้นำไปเทรน ในรูปแบบที่เปิดให้บอทลูกผสมซึ่งให้ความร่วมมือยังเข้าถึงเนื้อหาเพื่อทำดัชนีการค้นหาได้ต่อไป โดยมีเงื่อนไขว่าบอทเหล่านั้นต้องเปิดให้เจ้าของเว็บตรวจสอบได้ว่าข้อมูลถูกนำไปใช้อย่างไร
บทความต้นทางเขียนโดย Jin-Hee Lee และติดแท็กไว้ในหมวด AI Bots, Bot Management และ Product News โดย PPC Land รายงานเรื่องนี้เมื่อวันที่ 23 สิงหาคม 2569
ปัญหาที่ฟีเจอร์นี้ถูกสร้างมาแก้ คือคำประกาศกับกฎที่บังคับใช้จริงไม่ตรงกัน
มีไฟล์สองอย่างที่กำกับว่าเว็บไซต์หนึ่งประกาศจุดยืนต่อทราฟฟิกอัตโนมัติอย่างไร และตลอดหลายปีที่ผ่านมาทั้งสองอย่างถูกปล่อยให้ขัดแย้งกันเองได้ อย่างแรกคือ robots.txt ซึ่งเป็นคำประกาศแบบข้อความล้วนที่โปรแกรมรวบรวมข้อมูลจะอ่านก่อนดึงหน้าเว็บ อีกอย่างคือชั้นการบังคับใช้ อันหมายถึงกฎไฟร์วอลล์ การตั้งค่าจัดการบอท และการบล็อกที่ขอบเครือข่าย ซึ่งทำงานโดยไม่สนใจว่าโปรแกรมตัวไหนอ้างว่าจะเคารพกติกาหรือไม่ ข้อโต้แย้งของ Cloudflare คือช่องว่างระหว่างสองสิ่งนี้กลายเป็นความเสี่ยงของเจ้าของเว็บไซต์ ไม่ใช่ของผู้ที่มาเก็บข้อมูล
รูปแบบความล้มเหลวที่บทความอธิบายไว้มีความเฉพาะเจาะจง ไฟล์ robots.txt อาจระบุว่าไม่อนุญาตให้บอทตัวหนึ่งเข้ามา ในขณะที่กฎการบังคับใช้กลับปล่อยบอทตัวเดียวกันนั้นผ่านไปอย่างเงียบ ๆ เมื่อคำประกาศกับกฎที่บังคับใช้จริงไม่ตรงกัน Cloudflare ระบุว่าบอทบางตัวถือเอาความไม่สอดคล้องนั้นเป็นเหตุผลที่จะไม่สนใจคำประกาศ หรือเป็นเหตุผลในการพยายามหลบเลี่ยงกฎที่บังคับใช้อยู่ การทำให้ทั้งสองอย่างตรงกันจึงเป็นการตัดข้ออ้างนั้นทิ้ง นี่คือเจตนาการออกแบบทั้งหมด และควรแยกออกจากคำถามที่ว่าบอทตัวใดจะเชื่อฟัง robots.txt หรือไม่ ซึ่งเป็นเรื่องที่ฟีเจอร์นี้ไม่ได้เปลี่ยน
ไฟล์ถูกเขียนขึ้นมาอย่างไร
กลไกเป็นแบบเพิ่มเข้าไป ไม่ใช่แบบเขียนทับ ซึ่งเป็นเรื่องสำคัญถ้าคุณดูแลไฟล์ที่เขียนด้วยมืออยู่แล้ว ในกรณีที่เว็บไซต์มีไฟล์ robots.txt อยู่ก่อน เนื้อหาที่ Bot Preference Sync สร้างขึ้นจะถูกวางไว้ด้านบนของเนื้อหาเดิม คำสั่ง Disallow ที่มีอยู่แล้วจึงยังคงอยู่ครบ ส่วนที่ระบบสร้างขึ้นจะถูกคร่อมด้วยเครื่องหมายคอมเมนต์ ตัวอย่างที่เผยแพร่ในบทความซึ่ง Cloudflare ย่อและปิดบังชื่อจริงไว้ เริ่มต้นด้วยบรรทัดที่เขียนว่า BEGIN Cloudflare Bot Preference Sync ตามด้วยรายชื่อ user agent สี่ตัวคือ TrainingBot1, TrainingBot2, TrainingBot3 และ MixedUseBot-Extended แล้วใส่คำสั่ง Disallow ทั้งเว็บไซต์ ก่อนปิดท้ายด้วยเครื่องหมาย END ที่คู่กัน
รายชื่อ user agent ชุดนั้นไม่ได้ถูกตรึงไว้ ณ ตอนที่ตั้งค่า Cloudflare ระบุว่าจะดึงข้อมูลบอทที่ติดตามอยู่ใน BotBase มาปรับชุด user agent ที่เขียนลงใน robots.txt เป็นระยะ ทุกครั้งที่ลูกค้าเลือกบล็อกหรือไม่อนุญาตหมวดใดหมวดหนึ่ง ส่วนบอทที่ผ่านการยืนยันแล้วและถูกจัดอยู่ในหมวด Search, Agent และ Training สามารถเข้าไปตรวจดูได้ตลอดเวลาผ่านไดเรกทอรีบอทสาธารณะของบริษัท ผลในทางปฏิบัติคือความประสงค์ที่แสดงไว้ครั้งเดียวต่อหมวดหนึ่ง จะยังครอบคลุมบอทตัวใหม่ที่เข้ามาอยู่ในหมวดนั้นต่อไป โดยที่เจ้าของเว็บไม่ต้องแก้ไขอะไรเพิ่ม
สิ่งที่ฟีเจอร์นี้ตั้งใจไม่รองรับ
ข้อจำกัดที่ระบุไว้คือ Bot Preference Sync จัดการกับการตัดสินใจเชิงนโยบายในระดับหมวดทั้งหมวด ไม่ใช่การเจรจาเป็นรายบอท และจะไม่อ่านกฎที่ผู้ใช้ตั้งเองซึ่งมีตรรกะซับซ้อน ลูกค้าที่ทำข้อตกลงเฉพาะกับบริษัทใดบริษัทหนึ่งไว้ และต้องการเว้นข้อยกเว้นให้บริษัทนั้นโดยเฉพาะ ยังมีทางเลือกที่จะปิดการซิงก์แล้วแก้ไฟล์ด้วยมือให้ตรงกับนโยบายเฉพาะของตัวเอง
ประโยคนี้คือประโยคที่สำคัญที่สุดในประกาศฉบับนี้ สำหรับใครก็ตามที่มีดีลอนุญาตให้ใช้เนื้อหาหรือมีรายชื่ออนุญาตพิเศษอยู่ ตัวซิงก์เขียนไฟล์จากนโยบายระดับหมวดเท่านั้น ถ้านโยบายจริงของคุณอยู่ในกฎที่ตั้งเองพร้อมเงื่อนไขประกอบ ไฟล์ที่ระบบสร้างจะไม่สะท้อนนโยบายนั้น และการเปิดซิงก์ก็เท่ากับการประกาศจุดยืนที่เรียบง่ายกว่าข้อตกลงจริงที่คุณมีอยู่
สามหมวด และความหมายที่แคบลงของคำว่า Disallow
ระบบจำแนกที่อยู่ใต้ฟีเจอร์นี้คือชุดที่ Cloudflare เริ่มใช้เมื่อวันที่ 1 กรกฎาคม 2569 ตอนที่เปลี่ยนจากการมองบอท AI แบบสองขั้วมาเป็นสามหมวดตามพฤติกรรม ตารางด้านล่างสรุปว่าแต่ละหมวดครอบคลุมอะไร และบทความเดือนสิงหาคม 2569 บอกอะไรเกี่ยวกับการตั้งค่าของหมวดนั้น
| หมวด | ครอบคลุมอะไร | สถานะหลังบทความ 21 สิงหาคม 2569 |
|---|---|---|
| Search | การเก็บและทำดัชนีเนื้อหาเพื่อนำไปตอบคำถามเกี่ยวกับเนื้อหานั้นในภายหลัง | การตั้งค่าเหมือนเดิมจากเดือนกรกฎาคม 2569 คืออนุญาต บล็อกเฉพาะหน้าที่มีโฆษณา หรือบล็อกทั้งหมด |
| Agent | ระบบอัตโนมัติที่ทำงานแบบเรียลไทม์แทนบุคคลหนึ่ง | การตั้งค่าเหมือนเดิมจากเดือนกรกฎาคม 2569 คืออนุญาต บล็อกเฉพาะหน้าที่มีโฆษณา หรือบล็อกทั้งหมด |
| Training | บอทที่เก็บเนื้อหาไปใช้เทรนหรือปรับจูนโมเดล | ตัวเลือก Disallow เขียนความประสงค์ไม่ให้นำไปเทรนในรูปแบบที่บอทลูกผสมซึ่งให้ความร่วมมือยังทำดัชนีการค้นหาได้ |
หมวด Training คือจุดที่มีการเปลี่ยนแปลงเนื้อหาสาระ เหตุผลที่ Cloudflare ให้ไว้ว่าทำไมจึงยอมให้บอทกลุ่มนั้นผ่านนั้นเป็นเหตุผลแบบมีเงื่อนไข ไม่ใช่ความเมตตา คือบอทเหล่านั้นยังเข้าถึงได้เพราะเปิดให้เจ้าของเว็บตรวจสอบโดยตรงว่าข้อมูลถูกนำไปใช้อย่างไร Cloudflare ระบุว่าการมองเห็นในการค้นหาสำหรับบอทที่ให้ความร่วมมือจะไม่ได้รับผลกระทบ และจุดยืนของบริษัทต่อปัญหาต้นตอก็ไม่ได้อ่อนลง บทความเดือนกรกฎาคมของบริษัทเคยแย้งว่าบอทลูกผสม ซึ่งอธิบายว่าเป็นบอทที่ผสมการค้นหา การทำงานแทนผู้ใช้ และการเก็บข้อมูลไปเทรน ไว้ภายใต้ user agent เดียว ทำให้เจ้าของเว็บเสียเปรียบ เพราะแยกพฤติกรรมที่ต้องการออกจากพฤติกรรมที่ไม่ต้องการได้ยาก และข้อโต้แย้งนั้นถูกยืนยันว่ายังคงอยู่
เงื่อนไขการเปิดเผยข้อมูลสี่ข้อ
เพื่อวัตถุประสงค์ของการยืนยันตัวตนบอท ผู้ให้บริการที่บอทของตนทำทั้งงาน Search และ Training ต้องส่งข้อมูลเพิ่มเติมเพื่อไม่ให้ถูกบล็อกบนเว็บไซต์ที่ตั้งค่า Disallow Training ไว้ โดยมีข้อกำหนดสี่ข้อ
- บอทต้องเคารพความประสงค์ที่ไม่อนุญาตให้นำไปเทรนใน robots.txt ผ่านกลไกใดก็ได้
- ผู้ให้บริการต้องเปิดช่องทางให้เจ้าของเว็บไซต์เลือกไม่เข้าร่วมการสรุปเนื้อหาด้วย AI
- ผู้ให้บริการต้องให้ข้อมูลระดับ URL ว่าหน้าใดถูกนำไปใช้เพื่อการเทรน พร้อมกับตัวชี้วัดด้านผลการค้นหา เพื่อให้เจ้าของเว็บเห็นว่าเนื้อหาถูกใช้อย่างไรในทั้งสองด้าน
- ผู้ให้บริการต้องสามารถแสดงต่อสาธารณะได้ว่าการไม่อนุญาตให้นำไปเทรนไม่ทำให้ผลการค้นหาแบบเดิมเสียหาย
บอทของผู้พัฒนาโมเดล AI และผู้ให้บริการรายใหญ่ที่ผ่านเกณฑ์เหล่านั้นจะถูกติดตามอย่างเปิดเผยในส่วนความโปร่งใสของบอท AI บน Cloudflare Radar ซึ่งบริษัทระบุว่าจะรวมทั้งกรณีที่ปฏิบัติตามแนวทางที่ดีและกรณีที่ไม่ปฏิบัติตาม ส่วนบอทที่ไม่ยอมเปิดเผยข้อมูลจะไม่ได้รับการอนุมานให้เป็นคุณ และจะยังถูกบล็อกบนทุกเว็บไซต์ที่ไม่อนุญาตให้นำไปเทรน Cloudflare อธิบายข้อตกลงนี้ว่าเป็นการทำให้ความโปร่งใสกลายเป็นค่าผ่านประตู
ข้อที่สามคือข้อที่ยังไม่มีผู้ให้บริการรายใหญ่รายใดทำได้ในวันนี้ การรายงานระดับ URL ว่าหน้าไหนถูกนำไปใช้เทรน ควบคู่กับตัวชี้วัดผลการค้นหา จะทำให้ผู้เผยแพร่เนื้อหาเห็นบัญชีรายหน้าว่าอะไรถูกเก็บไป และอะไรกลับคืนมา ส่วนคำถามว่าจะมีผู้ให้บริการรายใหญ่รายใดทำตามหรือไม่นั้นยังเปิดอยู่ และส่วนความโปร่งใสของ Cloudflare Radar ถูกระบุว่าเป็นที่ที่คำตอบจะปรากฏต่อสาธารณะ
จุดตั้งต้นที่ต่างออกไปสำหรับเว็บที่หารายได้จากโฆษณา
บทความนี้ยังเปลี่ยนสิ่งที่โดเมนใหม่จะได้รับตั้งแต่วันแรก และแยกค่าตั้งต้นออกเป็นสองทาง ตอนเริ่มใช้งาน ลูกค้าสามารถเลือกตัวเลือกที่ระบุว่าโดเมนนั้นหารายได้จากหน้าที่มีโฆษณา การเลือกตัวเลือกนี้จะตั้งค่า Training เป็น Disallow เป็นค่าเริ่มต้น บนความคาดหมายที่ระบุไว้ว่าเว็บไซต์ที่พึ่งพารายได้โฆษณาย่อมสงวนหน้าเหล่านั้นไว้ให้ผู้เข้าชมที่เป็นมนุษย์ ค่านี้เปลี่ยนได้ในภายหลังตลอดเวลา และ Cloudflare สรุปผลลัพธ์ที่ตั้งใจไว้ว่าคือการยังอยู่ในผลการค้นหา ขณะที่กันเนื้อหาออกจากการเทรนโมเดล
สำหรับลูกค้าใหม่รายอื่นทั้งหมด จะไม่มีการใช้ค่าใดเลยตอนเริ่มต้น ไม่มีการเพิ่มการบล็อกและไม่มีการเพิ่มคำสั่งไม่อนุญาต โดยหมวด Search, Agent และ Training สามารถถูกบล็อกได้ในภายหลังตามที่ลูกค้าเลือกเอง ทั้งนี้สำหรับลูกค้าใหม่ทุกราย ตัว Bot Preference Sync เองจะถูกเปิดใช้งานเป็นค่าเริ่มต้น ส่วนลูกค้าเดิมที่ยังใช้ฟีเจอร์ managed robots.txt แบบเก่าจะได้รับการแจ้งให้ทบทวนและยืนยันค่าที่ตั้งไว้ เพื่อย้ายมาสู่ระบบใหม่เมื่อเปิดตัว
ความย้อนแย้งที่ต้องพูดตรง ๆ สำหรับคนทำ GEO
นี่คือส่วนที่ไม่มีคำตอบสวยงาม และการแกล้งทำเป็นว่ามีก็คงไม่ซื่อสัตย์ การบล็อกบอทที่เก็บข้อมูลไปเทรนเป็นการตัดสินใจทางธุรกิจที่มีเหตุผลรองรับ และในเวลาเดียวกันมันก็แลกมาด้วยการมองเห็นในคำตอบของ AI ได้ เพราะบอทลูกผสมที่ทำทั้งการค้นหาและการเทรนคือจุดที่การแลกเปลี่ยนนี้กัดเจ็บที่สุดพอดี นั่นคือสถานการณ์ที่การปรับนิยามของ Disallow พยายามจะแก้ คือพยายามทำให้การปฏิเสธการเทรนแยกออกจากบทลงโทษด้านการค้นหาได้ แต่แยกได้เฉพาะกับบอทที่ให้ความร่วมมือและยอมเปิดเผยข้อมูลเท่านั้น
ต้นทุนที่วัดได้ในอีกด้านหนึ่งของบัญชีก็มีบันทึกไว้แล้ว งานวิจัยจาก Rutgers Business School และ The Wharton School พบว่าสำนักข่าวที่บล็อกบอท AI ผ่าน robots.txt สูญเสียทราฟฟิกเว็บไซต์รายสัปดาห์ราว 7 เปอร์เซ็นต์ภายในหกสัปดาห์ ซึ่งงานชุดเดียวกันรายงานไว้อีกที่หนึ่งว่าเท่ากับ 23.1 เปอร์เซ็นต์ของการเข้าชมรายเดือน โดยไม่ได้รับการคุ้มครองในสัดส่วนที่สมน้ำสมเนื้อ เพราะโปรโตคอลนี้ยังเป็นเรื่องสมัครใจ การปฏิบัติตามในทิศทางกลับกันก็ไม่ครบถ้วนเช่นกัน การวัดของ TollBit ที่รายงานในเดือนสิงหาคม 2569 พบว่า 15 เปอร์เซ็นต์ของตัวดึงหน้าเว็บของ AI ในยุโรปเข้าถึง URL ที่ถูกสั่งห้ามไว้ และ Microsoft Clarity เพิ่มการติดธงการละเมิด robots.txt ไว้ในมุมมอง Bot Analytics เมื่อเดือนมิถุนายน 2569 ซึ่งให้หลักฐานแต่ไม่ได้บังคับใช้
จากตรงนี้มีสองข้อที่ตามมา และทั้งสองข้อไม่ใช่การคาดการณ์ ข้อแรก คำสั่งใน robots.txt คือการร้องขอ ส่วนการบล็อกที่ขอบเครือข่ายคือการลงมือ ทั้งสองอย่างจึงตอบคนละคำถาม และเจ้าของเว็บต้องรู้ว่าตัวเองกำลังพึ่งอันไหนอยู่ ข้อที่สอง การปฏิเสธการเทรนที่บอทซึ่งให้ความร่วมมือจะเคารพโดยไม่กระทบการค้นหานั้นเป็นจริงเฉพาะกับบอทที่ให้ความร่วมมือ ซึ่งเป็นช่องว่างที่เงื่อนไขการเปิดเผยสี่ข้อถูกออกแบบมาเพื่อปิด ส่วนคำถามว่าผู้ให้บริการจะยอมเปิดเผยข้อมูลนั้นหรือไม่ ไม่ใช่เรื่องที่ประกาศฉบับนี้ให้คำตอบได้ และไม่มีฐานใดในบทความนี้ที่จะใช้ทำนายการยอมรับของตลาดหรืออ้างว่าบริษัท AI รายใดจะตอบสนองอย่างไร
สิ่งที่เจ้าของเว็บไซต์ควรตรวจสอบ
- นโยบายในแดชบอร์ดกับไฟล์ robots.txt ที่ใช้งานอยู่จริงพูดตรงกันหรือไม่ เพราะฟีเจอร์นี้ถูกสร้างบนสมมติฐานว่าหลายเว็บไซต์จะพบว่ามันไม่ตรงกัน
- เว็บไซต์จะถูกจัดว่าหารายได้จากโฆษณาตอนเริ่มใช้งานหรือไม่ เพราะคำตอบนั้นทำให้ได้ค่าตั้งต้นของหมวด Training ต่างจากโดเมนใหม่รายอื่นทั้งหมด
- มีข้อตกลงพิเศษหรือข้อตกลงที่เจรจากับผู้ให้บริการรายใดอยู่หรือไม่ เพราะตัวซิงก์เขียนนโยบายระดับหมวดและไม่อ่านกฎที่ตั้งเองแบบซับซ้อน การเปิดใช้จึงอาจเขียนทับจุดยืนจริงด้วยเวอร์ชันที่ง่ายกว่า
- ไฟล์ robots.txt เดิมมีคำสั่ง Disallow ที่ต้องคงไว้หรือไม่ ซึ่งพฤติกรรมการวางไว้ด้านบนถูกออกแบบมาเพื่อรักษาไว้ และหลังซิงก์ครั้งแรกมีเครื่องหมาย BEGIN และ END Cloudflare Bot Preference Sync ปรากฏอยู่จริงหรือไม่
- ยังมีคนในทีมแก้ไฟล์ robots.txt ด้วยมืออยู่หรือไม่ เพราะเมื่อเปิดซิงก์แล้ว ไฟล์นี้จะกลายเป็นผลลัพธ์ของการตั้งค่าในแดชบอร์ด ไม่ใช่เอกสารที่คนดูแลเอง
เรื่องนี้มีความหมายอย่างไรกับนักการตลาดไทย
ย่อหน้าต่อจากนี้เป็นการวิเคราะห์ของ Relevant Audience ไม่ใช่ข้ออ้างจากแหล่งข่าว ซึ่งไม่ได้กล่าวถึงประเทศไทยเลย Cloudflare อยู่หน้าเว็บไซต์จำนวนมากทั่วโลก และฟีเจอร์นี้ปล่อยลงมาถึงแพ็กเกจฟรี การตัดสินใจนี้จึงไปถึงเว็บไซต์ไทยขนาดเล็กที่ไม่เคยคิดว่าตัวเองมีนโยบายเรื่องบอทด้วยซ้ำ ความเสี่ยงในทางปฏิบัติไม่ได้อยู่ที่การบล็อก แต่อยู่ที่การค้นพบว่าปุ่มในแดชบอร์ดที่ตั้งไว้เมื่อหลายเดือนก่อนกำลังจะถูกเผยแพร่เป็นคำประกาศสาธารณะในไฟล์ที่ผู้ให้บริการ AI ผู้ตรวจสอบ และคู่สัญญาด้านลิขสิทธิ์เนื้อหาอ่านได้
มีสามกลุ่มที่มีโจทย์ต่างกันตรงนี้ ผู้เผยแพร่เนื้อหาไทยที่ขายพื้นที่โฆษณาแบบโปรแกรมมาติกควรตัดสินใจอย่างตั้งใจว่าคำตอบเรื่องการหารายได้จากโฆษณาตอนเริ่มใช้งานตรงกับวิธีที่ตัวเองอยากให้ปฏิบัติต่อการเทรน AI จริงหรือไม่ แทนที่จะรับค่าตั้งต้นมาเฉย ๆ ส่วนเว็บไซต์แบรนด์หรืออีคอมเมิร์ซที่ต้องการปรากฏในคำตอบของ AI ควรระวังไม่ให้เผลอได้การปฏิเสธการเทรนแบบเหมารวมติดมา ทั้งที่เป้าหมายจริงคือการถูกดึงไปใช้ตอบ ซึ่งเป็นพื้นที่ที่งาน GEO หรือ Generative Engine Optimization ดูแลอยู่ และเว็บไซต์ใดที่เคยอาศัยความคลุมเครือระหว่าง robots.txt ที่เปิดกว้างกับกฎที่ขอบเครือข่ายที่เข้มงวด หรือสลับกัน จะเสียความคลุมเครือนั้นไป เว้นแต่จะตั้งใจปิดการซิงก์ การเข้าถึงของบอทจึงเป็นการตั้งค่าทางเทคนิคที่มีผลเชิงบรรณาธิการ และนั่นคือเหตุผลที่มันควรอยู่ในบทสนทนาเดียวกับงาน AI SEO มากกว่าจะปล่อยให้เป็นเรื่องของคนที่แตะไฟร์วอลล์เป็นคนสุดท้าย
คำถามที่พบบ่อย
Bot Preference Sync จะลบกฎเดิมใน robots.txt ของเราหรือไม่
ไม่ลบ เพราะบล็อกที่ระบบสร้างขึ้นจะถูกวางไว้ด้านบนของไฟล์เดิมแทนการเขียนทับ คำสั่ง Disallow ที่มีอยู่แล้วจึงยังคงอยู่ ส่วนที่ระบบสร้างจะถูกคร่อมด้วยเครื่องหมายคอมเมนต์ BEGIN และ END Cloudflare Bot Preference Sync เพื่อให้ระบุตำแหน่งในไฟล์ได้
ฟีเจอร์นี้จะเปิดให้ใช้เมื่อไรกันแน่
Cloudflare ระบุช่วงเวลาไว้ว่าเป็นสัปดาห์ถัดไป ไม่ได้ให้วันที่เจาะจง และชี้ให้ไปดูการยืนยันที่หน้า changelog ของบริษัท ส่วนตัวบทความเผยแพร่เมื่อวันที่ 21 สิงหาคม 2569
การตั้ง Disallow ที่หมวด Training จะทำให้เว็บหายจากผลการค้นหาของ AI หรือไม่
Cloudflare ระบุว่าการมองเห็นในการค้นหาสำหรับบอทที่ให้ความร่วมมือจะไม่ได้รับผลกระทบ เพราะตัวเลือก Disallow เขียนความประสงค์ไม่ให้นำไปเทรนในรูปแบบที่บอทเหล่านั้นเคารพได้ขณะยังทำดัชนีการค้นหาต่อไป การคุ้มครองนี้ใช้ได้เฉพาะกับบอทที่ผ่านเงื่อนไขการเปิดเผยข้อมูลสี่ข้อ ส่วนบอทที่ไม่ยอมเปิดเผยจะยังถูกบล็อกบนทุกเว็บไซต์ที่ไม่อนุญาตให้นำไปเทรน
ถ้าเรามีข้อตกลงเฉพาะกับบริษัท AI รายหนึ่งอยู่แล้วจะเป็นอย่างไร
ฟีเจอร์นี้จัดการนโยบายในระดับหมวดและจะไม่อ่านกฎที่ผู้ใช้ตั้งเองซึ่งมีตรรกะซับซ้อน ข้อตกลงเฉพาะจึงไม่ถูกสะท้อนในไฟล์ที่ระบบสร้าง คำตอบที่ Cloudflare ให้ไว้คือลูกค้ารายนั้นควรปิดการซิงก์แล้วแก้ไฟล์ robots.txt ด้วยมือให้ตรงกับนโยบายเฉพาะของตัวเอง
เว็บไซต์บนแพ็กเกจฟรีใช้ได้ด้วยหรือไม่
ได้ เพราะฟีเจอร์นี้ระบุว่าใช้ได้กับลูกค้าทุกรายตั้งแต่ระดับฟรีไปจนถึง Enterprise และเปิดหรือปิดได้ตลอดเวลา สำหรับลูกค้าใหม่ทุกราย Bot Preference Sync จะถูกเปิดใช้งานเป็นค่าเริ่มต้น ส่วนลูกค้าเดิมที่ใช้ฟีเจอร์ managed robots.txt แบบเก่าจะได้รับการแจ้งให้ทบทวนและยืนยันค่าที่ตั้งไว้เพื่อย้ายระบบ







