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

ทำไมครอว์เลอร์ AI ได้รับ 403 ทั้งที่ robots.txt อนุญาตแล้ว

เพราะ robots.txt กับโครงสร้างพื้นฐานเป็นประตูคนละบาน และมีเพียงบานที่สองเท่านั้นที่ตัดสินการเข้าถึงจริง OpenAI ระบุเรื่องนี้ไว้ตรงไปตรงมาว่า บริการป้องกันเว็บอย่าง Cloudflare, Akamai และผู้ให้บริการลักษณะเดียวกัน อาจบล็อกครอว์เลอร์ที่ถูกต้องโดยผิดพลาด และมักส่งข้อผิดพลาด 403 Forbidden กลับมา ครอว์เลอร์ของ OpenAI มีรูปแบบคล้ายทราฟฟิกอัตโนมัติ ซึ่งก็เป็นเช่นนั้นจริง จึงอาจถูกปฏิเสธหากไม่ได้ถูกใส่ไว้ในรายการอนุญาตอย่างเจาะจง

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

เว็บไซต์หนึ่งจึงประกาศ User-agent: OAI-SearchBot ตามด้วย Allow: / ผ่านการตรวจสอบทุกข้อของการตรวจสอบทางเทคนิคแบบเดิม และยังคงเข้าถึงไม่ได้อยู่ดี

การอนุญาตที่ประกาศไว้กับการเข้าถึงได้จริงต่างกันอย่างไร

การอนุญาตที่ประกาศไว้คือสิ่งที่เว็บไซต์อนุญาต ส่วนการเข้าถึงได้จริงคือสิ่งที่ครอว์เลอร์ได้รับ อย่างแรกแสดงออกผ่าน robots.txt, meta robots และส่วนหัว HTTP อย่างที่สองสังเกตได้ที่ปลายทางของห่วงโซ่ทั้งหมด ได้แก่ DNS, CDN, ไฟร์วอลล์ระดับแอปพลิเคชัน, ระบบจัดการบอต, การยืนยันตัวตน, การท้าทายด้วย JavaScript, CAPTCHA, การจำกัดอัตรา, กฎตามภูมิภาค แล้วจึงถึงรหัสตอบกลับและเนื้อหาที่ถูกส่งกลับมาจริง

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

การทดสอบที่สำคัญจริง

การอ่านไฟล์ไม่ได้พิสูจน์อะไร การตรวจสอบที่ใช้ได้จริงคือการเล่นซ้ำเส้นทางทั้งหมด ได้แก่ การอนุญาตที่ประกาศไว้ → DNS/CDN → ไฟร์วอลล์และ WAF → ระบบจัดการบอต → ชั้นแอปพลิเคชัน → รหัส HTTP → เนื้อหาสุดท้าย นี่เป็นการตรวจสอบเดียวที่ตอบคำถามว่า «ครอว์เลอร์ได้อะไรกลับไปจริง ๆ»

ชั้นไหนบ้างที่บล็อกครอว์เลอร์ AI

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

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

ทำไม OAI-AdsBot ผ่านไปได้ในที่ที่ OAI-SearchBot ถูกบล็อก

เพราะครอว์เลอร์สองตัวของ OpenAI มีสถานะไม่เท่ากันในสายตาผู้ให้บริการป้องกัน OpenAI ระบุว่า OAI-AdsBot ได้รับการยืนยันและอยู่ในรายการอนุญาตอย่างเป็นทางการของ Cloudflare ส่วน OAI-SearchBot ไม่มีการยืนยันเช่นนั้น

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

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

ครอว์เลอร์ที่ถูกอนุญาตแล้วถูกปฏิเสธที่ไฟร์วอลล์ ไม่สร้างการแจ้งเตือนใด ๆ มันไม่สร้างอะไรเลย และนั่นคือปัญหา

403 และ 429 หมายความว่าอย่างไรต่อการมองเห็นใน AI

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

สาเหตุของ 403 มักเป็นกฎของ WAF นโยบายไฟร์วอลล์ การบล็อกบอตอัตโนมัติ ข้อจำกัดของ IP หรือกฎตามภูมิภาค ส่วนสาเหตุของ 429 มักเป็นกฎอัตราคำขอ เกณฑ์ของระบบป้องกัน หรือการกระตุ้นความปลอดภัยอัตโนมัติ

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

การเข้าถึงได้จริงเพียงพอต่อการถูกอ้างอิงหรือไม่

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

ห่วงโซ่การมองเห็นใน AI ของ KAIS แยกขั้นตอนออกจากกันเพื่อป้องกันความสับสนนี้โดยเฉพาะ

ห่วงโซ่การมองเห็นใน AI ของ KAIS

ถูกค้นพบ → ถูกดึงมาใช้ → ถูกเข้าใจ → ถูกเชื่อถือ → ถูกอ้างอิง → มีอิทธิพลต่อคำตอบ → ถูกแนะนำ

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

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

จะตรวจสอบการเข้าถึงได้จริงของเว็บไซต์อย่างไร

ด้วยการเล่นซ้ำเส้นทางทั้งหมดโดยใช้ user agent ของครอว์เลอร์ตัวนั้น แทนการอ่านไฟล์ การตรวจสอบแปดข้อเพียงพอต่อการสร้างข้อสรุปที่ปกป้องได้

  1. ยืนยันว่าครอว์เลอร์ AI ที่ต้องการถูกอนุญาตไว้อย่างตั้งใจใน robots.txt
  2. ตรวจสอบว่าหน้าเว็บส่งรหัส HTTP ที่สำเร็จกลับมาเมื่อคำขอมาพร้อม user agent ของครอว์เลอร์
  3. ตรวจกฎของ CDN และ WAF เพื่อหาผลบวกลวงต่อทราฟฟิกบอต
  4. ตรวจการท้าทายด้วย JavaScript, CAPTCHA และข้อกำหนดการยืนยันตัวตนหรือเซสชัน
  5. ดูเหตุการณ์ 403 และ 429 รอบ ๆ คำขอของครอว์เลอร์
  6. ตรวจข้อจำกัดการเข้าถึงตามภูมิภาค
  7. ตรวจสอบเนื้อหาสุดท้ายที่ถูกส่งกลับมาจริงหลังการเปลี่ยนเส้นทาง โดยไม่รัน JavaScript
  8. แยกข้อสรุปเรื่องการเข้าถึงนี้ออกจากการวัดการดึงมาใช้และการถูกอ้างอิงในภายหลัง

ข้อที่เจ็ดสมควรได้รับการเน้นเป็นพิเศษ ครอว์เลอร์ไม่เรนเดอร์ JavaScript หน้าเว็บที่เนื้อหาหลักมีอยู่ได้ก็ต่อเมื่อรันฝั่งไคลเอนต์แล้ว จะส่ง 200 ที่ถูกต้องสมบูรณ์กลับมาพร้อมเนื้อความว่างเปล่า นี่คือกรณีที่หลอกตามากที่สุด คือรหัสตอบกลับดูดี แต่ไม่มีอะไรให้ดึงเลย

ต้องลดความปลอดภัยลงหรือไม่

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

OpenAI เผยแพร่ user agent ของครอว์เลอร์และที่อยู่ IP ของ searchbot ไว้เพื่อให้การทำรายการอนุญาตแบบเจาะจงเป็นไปได้ คำแนะนำของ OpenAI คือให้ตรวจสอบทั้งตัวตนของบอตและกฎการบล็อกในระดับโครงสร้างพื้นฐาน แทนที่จะพึ่ง robots.txt เพียงอย่างเดียว Google ระบุข้อกำหนดเดียวกันในเอกสารเรื่องฟีเจอร์ AI ของตนว่า การรวบรวมข้อมูลต้องได้รับอนุญาตทั้งใน robots.txt และ จาก CDN หรือโครงสร้างพื้นฐานของโฮสต์

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

จุดเริ่มต้นไม่ได้อยู่ตรงที่คิดกัน

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

robots.txt ของคุณบอกได้ว่าใช่ HTML ของคุณบอกได้ว่าใช่ ทีมการตลาดของคุณบอกได้ว่าหน้านั้นเป็นสาธารณะ ในขณะที่ตรงขอบของโครงสร้างพื้นฐานของคุณ ไฟร์วอลล์บอกว่าไม่

นี่ไม่ใช่ปัญหาเรื่องเนื้อหา ไม่ใช่ปัญหาเรื่องความน่าเชื่อถือ และไม่ใช่แม้แต่ปัญหาเรื่องการถูกอ้างอิง มันคือช่องว่างของการถูกค้นพบ และตราบใดที่ยังไม่ถูกปิด ทุกอย่างที่เหลือก็เป็นเพียงการสนทนาทางทฤษฎี

แหล่งข้อมูล