Cloudflare เปิดฝั่งผู้ให้บริการบอทของ BotBase หลังยอดส่งโตเจ็ดเท่า

Cloudflare เผยแพร่โพสต์เมื่อวันที่ 28 สิงหาคม 2569 เปิดฝั่งผู้ให้บริการบอทของ BotBase ซึ่งเป็นไดเรกทอรีของบอทและเอเจนต์ที่บริษัทเปิดตัวไปก่อนหน้านั้นสองเดือน โดยเพิ่มการติดตามสถานะการส่งข้อมูล การแก้ไขรายการ และไปป์ไลน์ตรวจสอบอัตโนมัติ ตามรายงานของ PPC Land ซึ่งอ้างถึงประกาศที่เขียนโดย Julian Laxman บน Cloudflare Blog บริษัทสร้างไปป์ไลน์นี้ขึ้นหลังจากปริมาณการส่งบอทใหม่ต่อปีเพิ่มขึ้นราวเจ็ดเท่านับตั้งแต่ปี 2566 ข่าวนี้ดูเหมือนเป็นเรื่องของฝั่งผู้ให้บริการบอท แต่เจ้าของเว็บไซต์ควรอ่าน เพราะไปป์ไลน์ที่ถูกจัดระเบียบนี้คือสิ่งที่ตัดสินว่าครอว์เลอร์ตัวไหนจะมาถึงเว็บไซต์พร้อมตัวตนที่ผ่านการยืนยันแล้ว

อะไรเปลี่ยนไปในวันที่ 28 สิงหาคม

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

ส่วนที่สามคือเนื้อหาสำคัญของการอัปเดตครั้งนี้ ก่อนวันที่ 28 สิงหาคม 2569 บริษัทที่รันครอว์เลอร์กรอกฟอร์มแล้วต้องรอไปเรื่อย ๆ โดยไม่มีบันทึกใดบอกว่าเกิดอะไรขึ้นต่อจากนั้น ทางเดียวที่จะได้คำตอบคือการอีเมลไปหาฝ่ายสนับสนุน Cloudflare ระบุว่าได้ฟังเสียงสะท้อนจากผู้ให้บริการบอทจำนวนมากที่ตรงกันว่า การส่งบอทให้ความรู้สึกเหมือนกล่องดำ กรอกฟอร์ม กดส่ง แล้วไม่มีอะไรที่สังเกตเห็นได้เกิดขึ้นตามมา

ตำแหน่งของฟอร์มก็ย้ายด้วย เดิมฟอร์มอยู่ใต้ Manage Account แล้วเข้าไปที่ Configurations ซึ่งเป็นเส้นทางที่ผูกบอทเข้ากับบัญชีสำหรับเรียกเก็บเงิน ตอนนี้ฟอร์มย้ายไปอยู่ใต้ Protect and Connect แล้วเข้า Application Security และเข้า BotBase ซึ่งอยู่ติดกับเครื่องมือด้านความน่าเชื่อถือและเครื่องมือจัดการบอทที่ผู้ให้บริการใช้อยู่แล้ว การเข้าถึงเปิดให้ลูกค้าทุกรายผ่านแดชบอร์ดของ Cloudflare โดยตรง

ทำไมข่าวนี้จึงเป็นเรื่องของเจ้าของเว็บไซต์ ไม่ใช่แค่ผู้ให้บริการบอท

ตัว BotBase เองเปิดตัวเมื่อวันที่ 1 กรกฎาคม 2569 พร้อมกับการเปลี่ยนนโยบายชุดหนึ่งที่ Cloudflare เลิกมองบอท AI แบบสองขั้วคือใช่หรือไม่ใช่ แล้วเปลี่ยนมาใช้การจัดหมวดที่ตั้งอยู่บนพฤติกรรมแทนการติดป้ายชื่อ การเปิดตัวครั้งนั้นให้เจ้าของเว็บไซต์มีฐานข้อมูลครอว์เลอร์ที่ค้นหาได้ และมีแดชบอร์ดแยกต่างหากที่วัดว่าผู้ให้บริการแต่ละรายดึงหน้าเว็บไปกี่ครั้งเทียบกับจำนวนผู้อ่านที่ส่งกลับมา สิ่งที่ยังไม่มีในตอนนั้นคือการมองเห็นในทางกลับกันสำหรับบริษัทที่อยู่อีกฝั่งของการเชื่อมต่อ

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

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

สามสถานะมาแทนคิวที่ว่างเปล่า

แต่ละสถานะหมายความว่าอะไร

ประวัติการส่งข้อมูลตอนนี้กำหนดสถานะให้ทุกรายการเป็นหนึ่งในสามแบบ Waiting for review หมายความว่ารายการถูกรับเข้าระบบแล้วและอยู่ในคิว Accepted หมายความว่าบอทถูกติดตามอยู่ในไดเรกทอรีแล้ว และ Rejected หมายความว่ามีบางอย่างในรายการที่ต้องแก้ไข โดย Cloudflare ระบุว่าจะให้เหตุผลพร้อมขั้นตอนที่ลงมือทำได้ก่อนส่งใหม่

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

ขอบเขตเรื่องรายการที่ส่งไว้ก่อนหน้านี้

มีข้อจำกัดหนึ่งที่ระบุไว้ตรง ๆ ในประกาศ และคนที่กำลังตรวจสอบรายการเดิมควรสังเกต บันทึกครอบคลุมบอททุกตัวที่ส่งจากบัญชีนั้นโดยเริ่มนับจากวันเปิดตัวเป็นต้นไป รายการที่ส่งก่อนวันที่ 28 สิงหาคม 2569 ไม่ได้ถูกอธิบายว่าจะถูกดึงย้อนกลับเข้ามาในมุมมองประวัติ ผู้ให้บริการที่ส่งครอว์เลอร์ไว้เมื่อเดือนกรกฎาคมและยังรออยู่ ไม่ควรอ่านประวัติที่ว่างเปล่าว่าเป็นหลักฐานว่ารายการหายไป และก็ไม่ควรอ่านว่าเป็นหลักฐานว่ากำลังคืบหน้าเช่นกัน นอกจากนี้ยังมีตัวกรองชื่อ My bots จากหน้าจอไดเรกทอรีบอท ซึ่งแสดงบอททั้งหมดที่ส่งภายใต้บัญชีที่ล็อกอินอยู่

การแก้ไขรายการ และเหตุผลที่ไดเรกทอรีต้องมีฟีเจอร์นี้

รายละเอียดที่ใช้ระบุตัวตนเปลี่ยนไปตามเวลา ผู้ให้บริการครอว์เลอร์อาจย้ายลิสต์ IP ไปไว้ที่ endpoint ใหม่หลังปรับปรุงเว็บไซต์ หรืออาจย้ายจากการใช้ allowlist ของ IP ไปเป็นการเซ็นทราฟฟิกด้วย Web Bot Auth ก่อนการอัปเดตครั้งนี้ การสะท้อนการเปลี่ยนแปลงทั้งสองแบบหมายถึงการกรอกฟอร์มใหม่ทั้งชุดและสร้างรายการใหม่ขึ้นมาอีกอัน ซึ่งทำให้เกิดรายการซ้ำในไดเรกทอรีที่ตั้งใจให้เป็นแหล่งอ้างอิงที่เชื่อถือได้ ตอนนี้การแก้ไขรายการที่ส่งไปแล้วทำได้ และรายการที่ยังรอการตรวจสอบก็ยกเลิกได้

Web Bot Auth คือกลไกเชิงรหัสวิทยาที่ Cloudflare พัฒนามาตั้งแต่เดือนพฤษภาคม 2568 และทำให้เป็นทางการผ่านรูปแบบรีจิสทรีสำหรับการยืนยันตัวตนของบอทและเอเจนต์ที่เผยแพร่เมื่อวันที่ 30 ตุลาคม 2568 ร่วมกับ Amazon Bedrock AgentCore สำหรับเจ้าของเว็บไซต์ ความเกี่ยวข้องในทางปฏิบัติคือการอ้างตัวตนที่มีลายเซ็นรองรับปลอมแปลงได้ยากกว่าการอ้างตัวตนด้วยสตริง user agent ซึ่งเป็นจุดอ่อนที่นโยบายจัดการบอทของผู้เผยแพร่เนื้อหาส่วนใหญ่ถูกสร้างขึ้นรอบ ๆ มัน

สามคำประกาศมาแทนป้ายกำกับเดียว

ฟอร์มรับข้อมูลถูกสร้างใหม่บนโมเดลพฤติกรรมและการใช้เนื้อหาที่ Cloudflare เปิดตัวเมื่อวันที่ 1 กรกฎาคม 2569 แทนที่จะบีบครอว์เลอร์ตัวหนึ่งให้เหลือหมวดเดียว ผู้ให้บริการต้องประกาศสามเรื่องแยกจากกัน

พฤติกรรม

บอทตัวหนึ่งอาจทำดัชนีหน้าเว็บสำหรับการค้นหา ทำหน้าที่เป็นเอเจนต์แทนบุคคล เก็บรวบรวมข้อมูล ฝึกโมเดล หรือรองรับเครื่องมือด้าน SEO และเลือกได้หลายพฤติกรรมพร้อมกัน แทนที่จะเลือกได้เพียงข้อที่ใกล้เคียงที่สุดข้อเดียว ซึ่งตอบปัญหาครอว์เลอร์ที่มีวัตถุประสงค์ผสมโดยตรง ปัญหานี้ไม่ใช่เรื่องสมมติ PPC Land รายงานเมื่อวันที่ 21 สิงหาคม 2569 ว่า Cloudflare กำหนดข้อกำหนดการเปิดเผยข้อมูลสี่ข้อ ซึ่งเป็นตัวชี้ว่าครอว์เลอร์ที่มีวัตถุประสงค์ผสมจะรอดจากการถูกบล็อกบนเว็บไซต์ที่ไม่อนุญาตการฝึกโมเดลหรือไม่

การใช้เนื้อหา

คำประกาศที่สองครอบคลุมว่าครอว์เลอร์เก็บอะไรไว้และนำอะไรไปเผยแพร่ต่อหลังจากเข้าถึงหน้าเว็บแล้ว Cloudflare แยกความต่างระหว่างบอทที่กวาดหน้าเว็บเพื่อทำสนิปเป็ตสำหรับการค้นหา กับบอทที่เก็บหน้าเดียวกันไว้เพื่อฝึกโมเดล และขอให้ผู้ให้บริการประกาศระดับการใช้งานด้วยคำศัพท์ชุด Content Signals เดียวกับที่เจ้าของเว็บไซต์ใช้ในไฟล์ของตัวเองอยู่แล้ว โพสต์ยกตัวอย่างสิ่งที่เว็บไซต์อาจประกาศไว้ใน robots.txt คือ Content-Signal: search=yes, ai-train=no, use=reference ซึ่งอนุญาตการทำดัชนีและการเก็บไว้เป็นแหล่งอ้างอิง แต่ปฏิเสธการนำไปฝึกโมเดล คำประกาศของผู้ให้บริการจะถูกตรวจเทียบกับความต้องการลักษณะนี้

ใครเป็นคนรันบอท

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

สรุปสามคำประกาศเทียบกัน

ตารางด้านล่างสรุปว่าผู้ให้บริการบอทต้องประกาศอะไรในแต่ละช่องตามที่ Cloudflare อธิบายไว้ และเจ้าของเว็บไซต์ใช้ข้อมูลนั้นทำอะไรได้

ทำไมพฤติกรรมบวกการใช้เนื้อหาจึงดีกว่าป้ายกำกับเดียว

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

การแยกพฤติกรรมออกจากการใช้เนื้อหาทำให้สองการตัดสินใจนี้เป็นอิสระต่อกัน การทำดัชนีและการใช้เป็นแหล่งอ้างอิงคือสิ่งที่ทำให้หน้าเว็บถูกอ้างอิงในคำตอบของ AI ส่วนการนำไปฝึกโมเดลเป็นคนละคำถาม และการปฏิเสธข้อหลังไม่ได้ทำให้หน้าเว็บหายไปจากระบบที่อ้างอิงถึงมัน ถ้ามองสองเรื่องนี้เป็นสวิตช์เปิดปิดตัวเดียว มันจะยุบรวมกลายเป็นการเลือกระหว่างการมองเห็นกับการควบคุม แต่ถ้ามองเป็นสองคำประกาศ เจ้าของเว็บไซต์อนุญาตข้อแรกและปฏิเสธข้อที่สองได้ ซึ่งตรงกับตัวอย่างที่โพสต์ยกไว้ คือ search=yes และ use=reference ควบคู่กับ ai-train=no

นี่คือการตีความในทางปฏิบัติสำหรับคนที่กลยุทธ์ทราฟฟิกตอนนี้รวมถึงการถูกหยิบไปแสดงในคำตอบที่ระบบสร้างขึ้น ไม่ใช่แค่การอยู่ในลิสต์ลิงก์สีน้ำเงินอีกต่อไป กลไกส่วนนี้มีรายละเอียดมากกว่าในเนื้อหาเรื่อง generative engine optimization และเรื่อง SEO ในยุค AI แต่ตัวการตัดสินใจเชิงนโยบายเองสั้นและชัด คือแยกคำถามเรื่องการเก็บข้อมูลออกจากคำถามเรื่องการถูกอ้างอิง แล้วเขียนไฟล์ตามนั้น

direct กับ intermediary คือคนละปัญหากัน

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

ส่วนการดึงหน้าเว็บแบบ intermediary ต่างกันในเชิงประเภท มันเกิดขึ้นเพราะมีคนถามคำถามที่อื่น ในแอปพลิเคชันที่สร้างบน API ของอีกบริษัทหนึ่ง และการดึงหน้าเว็บครั้งนั้นเป็นขั้นตอนหนึ่งของการตอบคำถามคนคนนั้น มันไม่ได้กำลังสร้างดัชนี และอาจไม่มีวันย้อนกลับมาอีก การบล็อกมันไม่ได้ปกป้องเนื้อหาจากดัชนี แต่คือการถอดหน้าเว็บออกจากคำตอบที่คนจริง ๆ กำลังรออยู่ ส่วนการอนุญาตก็ไม่ได้รับประกันว่าจะมีการส่งต่อผู้อ่านกลับมา ผลลัพธ์ทั้งสองทางไม่มีทางไหนถูกต้องชัดเจน และประเด็นคือเจ้าของเว็บไซต์ชั่งน้ำหนักมันไม่ได้เลยจนกว่าการดึงหน้าเว็บนั้นจะประกาศว่าตัวเองเป็นแบบไหน ก่อนจะมีการจัดหมวดแบบนี้ ทั้งสองแบบมาถึงในรูปของหมายเลข IP กับสตริง user agent เหมือนกันหมด

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

เรื่องนี้มีความหมายอย่างไรกับนักการตลาดไทย

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

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

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

สิ่งที่แหล่งข่าวไม่ได้บอก

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

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

คำถามที่พบบ่อย

รายการที่ส่งไว้ก่อนวันที่ 28 สิงหาคม 2569 จะปรากฏในแท็บประวัติใหม่หรือไม่

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

สถานะทั้งสามแบบหมายความว่าอะไร

Waiting for review หมายถึงรายการถูกรับเข้าระบบและอยู่ในคิว Accepted หมายถึงบอทถูกติดตามอยู่ในไดเรกทอรีแล้ว ส่วน Rejected หมายถึงมีบางอย่างต้องแก้ก่อนส่งใหม่ โดย Cloudflare ระบุว่าการปฏิเสธจะมาพร้อมเหตุผลและขั้นตอนที่ลงมือทำได้ และรายการที่ผ่านแต่ถูกจัดหมวดใหม่ระหว่างตรวจสอบจะแสดงว่ามีอะไรถูกเปลี่ยน

การปฏิเสธการนำไปฝึกโมเดลทำให้หน้าเว็บหายจากคำตอบของ AI หรือไม่

ไม่ ตามโครงสร้างของคำศัพท์ชุด Content Signals เพราะการเก็บไว้เพื่อฝึกโมเดลกับการใช้เป็นแหล่งอ้างอิงเป็นคำประกาศคนละตัวกัน ตัวอย่างที่โพสต์ของ Cloudflare ยกไว้คือ Content-Signal: search=yes, ai-train=no, use=reference ซึ่งอนุญาตการทำดัชนีและการเก็บไว้เป็นแหล่งอ้างอิง ขณะที่ปฏิเสธการนำไปฝึกโมเดล

Cloudflare เป็นคนตัดสินว่าบอทตัวไหนเข้าถึงเว็บไซต์ได้ใช่หรือไม่

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

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