เราเอาเว็บตัวเองไปตรวจว่า AI agent ใช้งานได้ไหม แล้วปฏิเสธไป 3 ข้อ

ไม่นานมานี้เราเอา productize.life ไปลองกับเครื่องมือชื่อ isitagentready.com มันสแกนว่าเว็บเรา "พร้อมให้ AI agent ใช้งาน" แค่ไหน ผลที่ได้ตรงและเจ็บดี endpoint มาตรฐานที่ agent ใช้ค้นว่าเว็บมีอะไรให้ทำได้บ้าง (พวก /.well-known/...) ของเราตอบ 401 หมด เพราะติดด่านรหัสผ่าน พูดง่าย ๆ คือ agent มองมาที่เว็บแล้วไม่เห็นอะไรเลย

เราไล่แก้อยู่หลายชั่วโมง แต่สิ่งที่อยากเล่าจริง ๆ ไม่ใช่ "ทำครบทุกข้อแล้ว" รายการของ isitagentready มีหลายข้อที่ ไม่ควรทำ สำหรับเว็บแบบบล็อก พอแยกออกว่าข้อไหนของจริงข้อไหนของปลอม สุดท้ายเราทำ 8 ปฏิเสธ 3 ข้ามอีก 1 โพสต์นี้คือเหตุผลของแต่ละกอง

ช่วงที่ 1เครื่องมือที่ชี้ช่องโหว่ให้เห็นจริง

ก่อนอื่นขอแนะนำ isitagentready.com ตรง ๆ มันเป็น radar ที่ดี ยิงคำขอแบบที่ agent ยิงจริง แล้วบอกว่าเว็บเราขาดอะไร ของเรามันจับได้ทันทีว่าหน้าแรกกับ endpoint มาตรฐานโดนด่านรหัสผ่านบัง agent เลยมองไม่เห็น นี่คือของจริงที่เราไม่เคยรู้มาก่อนว่าพลาด

แต่เครื่องมือสแกนทุกตัวมีนิสัยเดียวกัน มันให้ checklist กลาง ๆ ที่ใช้วัดทั้ง SaaS platform ใหญ่และบล็อกส่วนตัวด้วยเกณฑ์เดียว พอเป็นแบบนั้น บางข้อในรายการก็ไม่ได้เหมาะกับเว็บเรา การไล่ติ๊กให้ครบเลยไม่ใช่เป้าหมาย เป้าหมายคือทำข้อที่ "จริง" สำหรับเว็บนี้ แล้วรู้ว่าข้อไหนควรข้าม

ช่วงที่ 28 ข้อที่ทำ หลักการเดียว ชี้ไปหาของจริง

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

• Link headers (RFC 8288) บอก agent ตั้งแต่ header ว่าไปอ่านรายการทรัพยากรต่อได้ที่ไหน
• MCP server card + endpoint ประกาศว่าเว็บนี้มี MCP server อ่านอย่างเดียว เปิด tool จริงสองตัว: list บทความ กับ ดึงบทความเป็นข้อความ
• Agent Skills index รายการบทความทั้งหมดพร้อม digest ให้ agent หยิบไปใช้
• WebMCP เปิด tool ชุดเดียวกันให้ agent ในเบราว์เซอร์เรียกได้
• API catalog (RFC 9727) ชี้ไปที่ endpoint MCP ที่มีจริง
• Web Bot Auth เผยกุญแจสาธารณะจริง (สร้างเอง) ให้เว็บอื่นตรวจสอบคำขอที่เซ็นจากเราได้
• DNS-AID ประกาศ record ระดับ DNS ชี้ทางมาที่ endpoint เหล่านี้
• Markdown for Agents ถ้า agent ขอ markdown ก็ได้ markdown ของบทความไป ถ้าเบราว์เซอร์เข้าก็ได้ HTML ตามเดิม

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

ช่วงที่ 33 ข้อที่ปฏิเสธ อย่าโฆษณาความสามารถที่ไม่มี

ตรงนี้แหละคือหัวใจ รายการสแกนดันให้เราประกาศของพวกนี้: OAuth/OIDC discovery, OAuth Protected Resource, และ auth.md สำหรับ agent registration ทั้งสามข้อบอกให้เผยไฟล์ที่ประกาศว่าเว็บนี้มี "เซิร์ฟเวอร์ยืนยันตัวตน" ให้ agent มาลงทะเบียน ขอ token แล้วเข้าระบบ

แต่บล็อกนี้ไม่มีระบบนั้นเลย endpoint MCP ที่เราเปิด ตั้งใจให้อ่านสาธารณะ ไม่มีการล็อกอิน ถ้าเราประกาศไฟล์พวกนั้นออกไป agent ที่เชื่อจะพยายาม authenticate กับเซิร์ฟเวอร์ที่ไม่มีอยู่จริง แล้วก็พังตรงนั้น

นี่คือจุดที่ checklist หลอกได้ง่ายสุด ติ๊กครบดูเหมือน agent-ready กว่า แต่จริง ๆ มันทำให้ agent-ready น้อยลง เพราะการโฆษณาความสามารถที่ไม่มีจริง ทำให้ agent ที่เชื่อใจเราเสียเวลาและล้มเหลว การปฏิเสธสามข้อนี้คือการทำให้เว็บซื่อสัตย์ ไม่ใช่การขี้เกียจ

ช่วงที่ 41 ข้อที่ข้ามโดยตั้งใจ

ข้อที่ข้ามคือ DNSSEC รายการแนะนำให้เซ็นโซน DNS เพื่อความปลอดภัย เราลองเปิดแล้ว แต่ติดกำแพงจริง โดเมน productize.life จดทะเบียนที่หนึ่ง แต่ DNS ย้ายมาอยู่อีกที่ (เพราะทั้งระบบหลังบ้านรันบนนั้น) ผู้รับจดทะเบียนของเรารองรับ DNSSEC เฉพาะตอนใช้ name server ของเขาเองเท่านั้น เลยใส่ลายเซ็นของผู้ให้บริการ DNS ปัจจุบันไม่ได้

ทางออกเดียวที่จะได้ checkmark นี้คือย้ายการจดทะเบียนโดเมนทั้งก้อน ซึ่งมีค่าใช้จ่ายและความยุ่งยากของมัน สำหรับบล็อกที่ DNS-AID record ทำงานได้อยู่แล้ว การย้ายโดเมนเพื่อ tick ช่องเดียวไม่คุ้ม เราเลยจดไว้ว่าจะกลับมาดูก็ต่อเมื่อย้ายโดเมนด้วยเหตุผลอื่น นี่คือ "no" ที่มีเงื่อนไขปลุก ไม่ใช่ veto ถาวร

ช่วงที่ 5บทเรียน deploy ผ่าน ไม่ได้แปลว่าขึ้นจริง

ระหว่างทางเจอกับดักที่อยากเตือนไว้ ตอน deploy ระบบขึ้นว่า "READY" เขียวสวย แต่หน้าเว็บจริงยังเป็นของเก่า สาเหตุคือ host ที่หลังบ้านดึงไปแสดง ค้างชี้อยู่ที่ build เก่าเมื่อ 11 ชั่วโมงก่อน deploy ใหม่ไปอยู่คนละชื่อ ไม่ได้ย้ายตามมา

บทเรียนก็คือ "deploy สำเร็จ" กับ "ขึ้นจริง" เป็นคนละเรื่อง สิ่งที่เชื่อได้คือ ground truth ยิงคำขอไปที่ URL จริงแล้วดูไบต์ที่ออกมา ไม่ใช่สถานะเขียวบนหน้าจอ ที่เหลือก็เป็นเรื่องเล็ก ๆ แบบส่ง markdown แล้วลืมว่ามันยังพ่วง header บอกว่า "ถูกบีบอัดอยู่" ทั้งที่ไม่ได้บีบ ตรงนี้จับได้เพราะทดสอบบนเครื่องก่อนขึ้นจริง

เอาไปใช้ได้เลย

1. ใช้เครื่องสแกนอย่าง isitagentready เป็น radar มันชี้ของจริงที่เราพลาดได้
2. ทุกอย่างที่ประกาศ ต้องชี้ไปหาของที่มีอยู่จริงบนเว็บ
3. อย่าประกาศไฟล์ที่บอกว่ามีระบบ (auth, registration) ที่เว็บไม่มี checkmark ปลอมทำให้ agent-ready น้อยลง
4. ข้อที่ข้าม ให้ข้ามแบบมีเงื่อนไขปลุก ไม่ใช่ veto ถาวร
5. ยืนยันด้วย ground truth จริง ไม่ใช่สถานะ "สำเร็จ" ของเครื่องมือ

เริ่มตรงไหน เอาเว็บคุณไปลองที่ isitagentready.com แล้วก่อนทำตามทุกข้อ ถามข้อเดียว: ข้อนี้ชี้ไปหาของที่ฉันมีจริงไหม ถ้าไม่ ข้ามมันไป