AI RESEARCH
ทำไมบางเว็บถึง Block AI Bot? แล้ว Cloudflare Content Signals Policy สำคัญกว่า JSON-LD จริงไหม?
2 กันยายน 2569 · AI Research · อ่าน 11 นาที
มีงานวิจัยของ Search Engine Journal ที่ตรวจสอบเว็บไซต์ใหญ่ 50 แห่งเมื่อต้นเดือนกันยายนนี้ พบตัวเลขที่น่าสนใจ: เว็บเกือบ 2 ใน 3 (29 จาก 50) ไม่ได้ตัดสินใจอะไรเลยเรื่องการให้ AI Bot เข้าถึงเนื้อหา — ไม่ block ไม่อนุญาตชัดเจน ปล่อยตามยถากรรม ในขณะที่อีกกลุ่มหนึ่งเลือก block แบบตั้งใจชัดเจน วันนี้เลยอยากมาแกะให้ดูว่าทำไมเว็บใหญ่ๆ ถึงเลือก block และมันเกี่ยวอะไรกับที่ Cloudflare เคยคิดจะเก็บเงิน AI Bot ด้วย
สรุปสั้นๆ: การ block AI Bot ไม่ใช่เรื่องขี้เกียจหรือไม่รู้เรื่อง AI ส่วนใหญ่เป็นการตัดสินใจเชิงธุรกิจ — และ Cloudflare เคยลองให้เว็บไซต์เก็บค่าผ่านทางจาก AI Bot มาก่อนจริงๆ ก่อนจะเปลี่ยนโมเดลใหม่เมื่อไม่นานนี้ ส่วน Content Signals Policy ที่กำลังพูดถึงกันตอนนี้ ก็ทำงานคนละหน้าที่กับ JSON-LD Schema เลย ไม่ใช่ตัวแข่งกัน
ทำไมเว็บใหญ่บางแห่งถึงเลือก Block AI Bot
สื่ออย่าง BBC, CNN, The Guardian block AI bot เกือบทั้งหมดโดยตั้งใจ เพราะโมเดลธุรกิจพึ่งพา traffic คนเข้ามาอ่านบนเว็บจริงๆ ถ้า AI สรุปคำตอบให้จบในหน้าแชทโดยไม่ต้องคลิกเข้าเว็บ นั่นคือรายได้โฆษณา/subscription ที่หายไปตรงๆ เค้าก็เลยต้อง block
แต่ถ้าเป็นอย่างเว็บ e-commerce อย่าง Amazon.com ก็เป็นอีกเคสที่น่าสนใจ — คะแนน AI-readiness ต่ำสุดในกลุ่มที่สำรวจ (29.2%) แต่ไม่ใช่เพราะมองข้ามเรื่อง AI แค่ตั้งใจ block AI Crawler เกือบทั้งหมดเหมือนกัน เพราะไม่อยากให้ AI Chat ไปตอบแทนหน้าสินค้าของตัวเอง (ซึ่งมีระบบ ranking/sponsored/ราคาที่เปลี่ยนตลอดเวลา ให้ AI ไปสรุปแทนมีความเสี่ยงสูง)
ตรงข้ามกับฝั่งที่เปิดรับเต็มที่อย่าง Airbnb.com ซึ่งได้คะแนนสูงสุดในการสำรวจ (79.2%) — ธุรกิจแบบ retail/SaaS/ท่องเที่ยว/การเงิน มีแนวโน้มพึ่งพาการถูก AI แนะนำมากขึ้นเรื่อยๆ เพราะลูกค้าเริ่มถามตรงกับ AI แทนจะเข้าเว็บเอง ดังนั้นสำหรับกลุ่มนี้การเปิดให้ AI เข้าถึงคือการต่อยอดธุรกิจ ไม่ใช่ความเสี่ยง
ประเด็นสำคัญ
- ซึ่งถ้าให้เห็นภาพคือ บางเว็บไซต์มีการเปลี่ยนแปลงราคาตลอดเวลา การที่ให้ AI ไปสรุปราคาให้ อาจทำให้เสียหายตอนขายของได้ (หรืออาจโดนร้องเรียนในต่างประเทศ) แต่ อย่าง Airbnb ราคามักคงที่ (ยกเว้น seasonal) จึงสามารถเปิดให้ crawl ได้
- การเปิดให้ AI Crawl เว็บ อาจไม่เหมาะกับอะไรก็ตามที่มีการเปลี่ยนแปลงข้อมูลบ่อยๆ ยกตัวอย่างเช่น ราคาหุ้น ราคาทองคำ ฯลฯ
ที่สำคัญคือทั้งสองฝั่งต่างก็ “ตัดสินใจ” แล้วทั้งคู่ — ปัญหาจริงๆ อยู่ที่เว็บส่วนใหญ่ที่ไม่ได้ตัดสินใจอะไรเลยต่างหาก ซึ่งตรงนี้เชื่อมกับสิ่งที่เราเคยเขียนไว้เรื่อง ทำไม Google AI Overview แทบไม่อ้างอิง TikTok — โครงสร้างเนื้อหา/การเข้าถึงของแพลตฟอร์มมีผลต่อการถูกอ้างอิงโดยตรง ไม่ว่าจะตั้งใจหรือไม่ตั้งใจก็ตาม
Cloudflare เคยคิดเก็บเงิน AI Bot จริง — เรื่อง Pay Per Crawl
อันนี้ไม่ใช่เรื่องแต่ง Cloudflare เปิดตัว Pay Per Crawl แบบ private beta ตั้งแต่กรกฎาคม 2568 ภายใต้แคมเปญที่เรียกว่า “Content Independence Day” — ไอเดียคือให้เว็บไซต์เจ้าของเนื้อหาตั้งราคาเอง แล้ว AI Bot ที่จะเข้ามาดึงเนื้อหาต้องจ่ายเงินทุกครั้งที่ crawl ผ่านระบบ HTTP 402 (Payment Required) ซึ่งเป็นมาตรฐานเว็บเก่าแก่ที่แทบไม่มีใครใช้จริงมาก่อน
หลังจากนั้น Cloudflare ก็ขยายเป็น AI Crawl Control (เปิดใช้งานจริงสิงหาคม 2568) ให้เว็บไซต์เลือก block/allow/เก็บเงิน AI Bot เป็นรายตัวได้ พร้อมข้อความ 402 ที่กำหนดเองได้ เช่น “ติดต่อ [email protected]” หรือ “premium content ผ่าน API”
แต่ล่าสุด (กรกฎาคม 2569) Cloudflare ประกาศเปลี่ยนทิศทาง — เลิกโฟกัสที่การเก็บเงิน “ต่อการ crawl” แล้วหันไปทำโมเดล “Pay Per Use” หรือจ่ายเงินตาม “การถูกใช้ในคำตอบ” แทน เหตุผลหลักคือข้อมูลจาก Pew Research ที่ Cloudflare อ้างถึง พบว่าเวลา Google โชว์ AI Overview คนคลิกลิงก์ผลค้นหาปกติเหลือแค่ 8% (ลดลงเกือบครึ่งจากไม่มี AI summary) และคลิกลิงก์ในตัว AI Overview เองแค่ 1% เท่านั้น — พูดง่ายๆ คือการถูก “crawl” ไม่ได้แปลว่าเว็บไซต์จะได้ traffic กลับมาเลย การเก็บเงินแค่ตอน crawl จึงไม่ตรงกับมูลค่าที่เว็บไซต์เสียไปจริงๆ
ประเด็นนี้สำคัญเพราะมันแปลว่าเรื่อง “จ่ายเงินให้ AI เข้าเว็บ” ยังไม่นิ่ง โมเดลธุรกิจของ Cloudflare เองยังปรับตัวตามพฤติกรรม AI Search อยู่ตลอด — สิ่งที่เจ้าของเว็บควรจับตาไม่ใช่แค่ “จะ block หรือไม่ block” แต่คือ “จะควบคุมสิทธิ์การใช้เนื้อหาแบบไหนได้บ้าง” ซึ่งพาไปสู่เรื่องถัดไป
Content Signals Policy คืออะไร ทำไมงานวิจัยบอกว่ามีแค่ 5 จาก 50 เว็บที่ใช้
Content Signals Policy เป็นส่วนขยายของ robots.txt ที่ Cloudflare เปิดตัวและปล่อยเป็นมาตรฐานเปิด (CC0) ให้ใครก็เอาไปใช้ได้ แนวคิดคือ robots.txt แบบเดิมบอกได้แค่ “ใครเข้าหน้าไหนได้บ้าง” แต่ไม่เคยบอกว่า “เข้าไปแล้วเอาไปทำอะไรได้บ้าง” — Content-Signal เลยเพิ่ม 3 ค่าเข้ามาในไฟล์เดียวกัน:
| Signal | ความหมาย | ค่า Default |
|---|---|---|
| search | ใช้แสดงผลในผลค้นหา/citation ของ answer engine ได้ไหม | yes |
| ai-input | ใช้เป็น input ให้ AI ตอนตอบคำถามแบบ real-time ได้ไหม (เช่น RAG, AI Overview) | เป็นกลาง (ไม่กำหนด) |
| ai-train | เอาไปเทรน/fine-tune โมเดลได้ไหม | no |
Cloudflare เปิดใช้ default นี้อัตโนมัติให้เว็บกว่า 3.8 ล้านโดเมนที่ใช้ managed robots.txt ของตัวเอง แต่สิ่งที่ต้องเข้าใจตรงๆ คือ Content Signal เป็นแค่ “สัญญาณ” ไม่ใช่ “ตัวบล็อกจริง” — บอทที่เคารพมาตรฐานนี้ (GPTBot, ClaudeBot, Google-Extended, Applebot-Extended ส่วนใหญ่เคารพ) จะทำตาม แต่บอทที่ไม่แคร์ก็แค่เมินได้เหมือนเดิม ต้องใช้คู่กับ Firewall/Bot Management ถ้าอยากบังคับจริงๆ
ตัวเลขจากงานวิจัยของ SEJ ที่บอกว่ามีแค่ 5 จาก 50 เว็บใหญ่ที่ใช้ Content Signals Policy ไม่ได้แปลว่ามันไม่สำคัญ แต่เป็นเพราะมันยังใหม่มาก (เปิดตัวจริงราวปลายปี 2568) เทียบกับ JSON-LD ที่อยู่ในวงการมาเป็นสิบปีแล้ว
Content Signals Policy สำคัญกว่า JSON-LD หรือเปล่า?
คำตอบตรงๆ คือ “คนละงาน เทียบกันไม่ได้” มากกว่า “อันไหนสำคัญกว่า” — ลองแยกตามกรอบที่ SEJ ใช้ในงานวิจัยนี้:
- JSON-LD Schema อยู่ในชั้น “Attribution & Meaning” — หน้าที่คือบอก AI ว่าเนื้อหาบนหน้านั้น “หมายถึงอะไร” เช่น ตัวเลขไหนคือราคาสินค้า ตัวเลขไหนคือส่วนลดสมาชิก ใครคือเจ้าของแบรนด์จริง ถ้าไม่มี AI ก็จะเดาเอาเอง ซึ่งเดาผิดได้ (นำไปสู่ hallucination) — เรื่องนี้เชื่อมกับที่เราเคยเขียนเรื่อง Brand Mention vs Backlink ว่า AI ให้น้ำหนักกับสัญญาณที่บอกตัวตนแบรนด์มากแค่ไหน
- Content Signals Policy อยู่คนละชั้นเลย เป็นเรื่อง “สิทธิ์การใช้งาน” ไม่ใช่ “ความหมาย” — ต่อให้ schema สมบูรณ์แบบแค่ไหน แต่ไม่ได้ประกาศ intent ไว้ใน robots.txt เลย เว็บก็จะติดอยู่ในทางเลือกแบบไบนารี “block ทั้งหมด” หรือ “allow ทั้งหมด” ซึ่งเป็นปัญหาที่บทความต้นทางชี้ไว้ตรงๆ ว่าเว็บส่วนใหญ่ยังติดอยู่ในกับดักนี้
พูดอีกแบบ: JSON-LD ทำให้ AI “เข้าใจ” เนื้อหาถูกต้องขึ้น ส่วน Content Signals ทำให้เจ้าของเว็บ “คุมทิศทาง” ว่าอยากให้ความเข้าใจนั้นถูกเอาไปใช้ยังไง ถ้าทำแค่ JSON-LD แล้วปล่อย robots.txt ว่างเปล่า ก็เหมือนสอนให้ AI อ่านเนื้อหาถูกต้องเป๊ะ แต่ไม่เคยบอกเงื่อนไขการใช้เลย — ซึ่งพอเทียบกับที่เราเคยเขียนไว้เรื่อง Text-first vs Video-first ก็จะเห็นแพทเทิร์นคล้ายกัน คือ “AI เข้าถึงได้” กับ “AI เข้าใจถูก” เป็นคนละเงื่อนไขที่ต้องทำทั้งคู่ ขาดอันใดอันหนึ่งก็ไม่พอ
แล้ว Agent Transaction ล่ะ ทำไมยังไม่มีใครทำ
ชั้นที่ 3 ในกรอบวิจัยของ SEJ คือ “Agent Transaction & Discovery” — เรื่องนี้ได้คะแนนเฉลี่ยแค่ 2.1% เท่านั้น จาก 13 protocol ที่เกี่ยวข้อง มีแค่ 2 ตัวที่ถือว่าเป็นมาตรฐานจริงจัง (OAuth Discovery กับ OAuth Protected Resource Metadata) ซึ่งไม่แปลกเลย เพราะ agentic commerce เพิ่งเริ่มจริงจังปลายปี 2568 นี้เอง
ลองนึกภาพง่ายๆ: การให้ AI ไปสั่งซื้อของแทนเรา ตอนนี้ก็เหมือนให้คนที่บ้านไปซื้อของเซเว่นแทน — เป็นเรื่องที่ทำได้ในทางทฤษฎี มีเครื่องมือรองรับแล้วด้วยซ้ำ (Google มี Universal Commerce Protocol, OpenAI มี Agentic Commerce Protocol) แต่คนส่วนใหญ่ยังไม่มี “นิสัย” ทำแบบนั้นจริงๆ ยังไม่ใช่ Trend ที่คนสั่งให้ AI Agent ไปจ่ายเงินซื้อของแทนตัวเองในชีวิตประจำวัน
แต่ตรงนี้แหละที่น่าสนใจ — เว็บที่วันนี้เลือก block AI bot แบบ Amazon หรือสื่ออย่าง BBC/CNN ก็ไม่ได้แปลว่าจะ block ตลอดไป ถ้าวันหนึ่ง agentic commerce กลายเป็นช่องทางขายที่สร้างรายได้จริงจัง (ไม่ใช่แค่เสี่ยงเสีย traffic แต่คือโอกาสได้ยอดขายใหม่) เว็บพวกนี้ก็มีแรงจูงใจจะเปิดให้ AI Agent เข้ามาทำธุรกรรมแทน เพียงแต่ต้องรอให้มาตรฐานอย่าง OAuth Discovery, UCP, ACP นิ่งกว่านี้ก่อน และรอให้พฤติกรรมผู้บริโภคเปลี่ยนตามด้วย
สรุป — ทำอะไรได้บ้างตอนนี้
สำหรับเว็บที่ต้องพึ่งการถูก AI แนะนำ/อ้างอิงเป็นช่องทางธุรกิจ (retail, SaaS, ท่องเที่ยว, การเงิน) จุดที่ควรทำก่อนไม่ใช่แค่ JSON-LD schema อย่างเดียว แต่ควรเพิ่ม Content-Signal line ใน robots.txt ด้วย เพื่อประกาศจุดยืนชัดเจนแทนการปล่อยว่างซึ่งเท่ากับ “ไม่ได้ตัดสินใจอะไรเลย” — ทางเลือกพื้นฐานที่สุดคือ search=yes, ai-input=yes, ai-train=no ถ้าอยากถูกอ้างอิงในคำตอบ AI แต่ไม่อยากให้เนื้อหาถูกเอาไปเทรนโมเดลฟรีๆ
คำถามที่พบบ่อย
Content Signals Policy บังคับใช้ได้จริงไหม?
ไม่บังคับ เป็นสัญญาณแบบสมัครใจเหมือน robots.txt ทั่วไป บอทหลักที่มีชื่อเสียง (GPTBot, ClaudeBot, Google-Extended, Applebot-Extended) มักจะเคารพ แต่บอทอื่นอาจไม่สนใจเลย ต้องใช้ร่วมกับ Firewall/Bot Management ถ้าอยากบังคับจริง
ทำ JSON-LD แล้ว ยังต้องทำ Content Signals อีกไหม?
ต้อง ทำหน้าที่คนละอย่าง JSON-LD บอก “ความหมาย” ของเนื้อหา ส่วน Content Signals บอก “สิทธิ์การใช้งาน” ถ้าทำแค่อย่างเดียวจะยังไม่ครบ
Cloudflare ยังเก็บเงิน AI Bot แบบ Pay Per Crawl อยู่ไหม?
โมเดลกำลังเปลี่ยน จากเดิมเก็บเงินตาม “การ crawl” (HTTP 402 ต่อครั้ง) Cloudflare ประกาศเมื่อกรกฎาคม 2569 ว่าจะขยับไปทาง “Pay Per Use” คือจ่ายตามการถูกใช้ในคำตอบจริง แทนที่จะจ่ายแค่ตอนเข้ามาดึงข้อมูล
แหล่งอ้างอิง
Thanacharn J.
20+ ปีในสาย SEO / PPC / Social Marketing โฟกัสงานวิจัยด้าน GEO และ Zero-Click Threat
