วิธีเตรียมเว็บไซต์ที่คุณโฮสต์เองให้พร้อมรับเอเจนต์ AI

ในกระทู้ Hacker News เรื่องทราฟฟิกจากครอว์เลอร์ AI ผู้ดูแลระบบโฮสติ้งรายหนึ่งอธิบายภาระงานจากมุมของผู้ให้บริการว่า "บอต AI ที่ค่อนข้างดุราว 6 ตัว" ซึ่งเป็นระยะจะติดอยู่กับหน้าตัวเลือกสินค้าหรือหน้าหมวดหมู่ แล้วเริ่มยิงเข้ามาประมาณหนึ่งคำขอต่อวินาที บนเว็บไซต์ที่ "การโหลดแต่ละหน้าอาจกินเวลาไป-กลับเต็ม 1 วินาที (ส่วนใหญ่หมดไปกับ MySQL)" ผลสะสมตามความเห็นเดียวกันคือ "ใกล้เคียงกับการที่เว็บโดน Slashdot ทุกวัน"

การเตรียมเว็บไซต์ให้พร้อมรับเอเจนต์ AI เป็นเรื่องของกำลังเครื่องก่อนเรื่องอื่นใด งานส่วนใหญ่จึงเป็นการตั้งค่าเซิร์ฟเวอร์ และมีเพียงส่วนน้อยที่เป็นกลยุทธ์เนื้อหา ข้อดีของทราฟฟิกนี้คือส่วนใหญ่ไม่ได้ไร้ตัวตน บริษัทที่สร้างมันขึ้นมาประกาศชื่อครอว์เลอร์ของตน ระบุว่าแต่ละตัวมีไว้ทำอะไร และบอกวิธีปิดการทำงาน ต่อจากนี้คือสิ่งที่ต้องตั้งค่า สิ่งที่แต่ละกลไกบังคับใช้ได้จริง และสองขั้นตอนที่ผมจะข้าม นั่นคือการเผยแพร่ llms.txt และการเพิ่ม schema markup เพื่อ AI

TL;DR (สรุปย่อ)

• ทราฟฟิก AI มักแบ่งได้เป็นการเทรนโมเดล การทำดัชนีสำหรับการค้นหาด้วย AI และการดึงหน้าตามคำสั่งของผู้ใช้ OpenAI และ Anthropic เปิดโทเคนแยกสำหรับแต่ละวัตถุประสงค์ คุณจึงควบคุมได้อย่างอิสระ ขณะที่ครอว์เลอร์อเนกประสงค์บางตัวรวมหลายบทบาทไว้ในตัวตนเดียว
• OpenAI, Anthropic, Perplexity และ Common Crawl ต่างมีเอกสารระบุการควบคุมผ่าน robots.txt สำหรับครอว์เลอร์อัตโนมัติของตน ข้อยกเว้นคือตัวดึงหน้าที่ผู้ใช้เป็นคนสั่ง Anthropic บังคับใช้ robots.txt กับ Claude-User ด้วย ส่วน OpenAI ระบุว่ากฎอาจไม่มีผลกับ ChatGPT-User และ Perplexity-User มักจะเพิกเฉยต่อกฎเหล่านี้
• ไฟล์ robots.txt เป็นกลไกขอความยินยอม ไม่ใช่การควบคุมการเข้าถึง RFC 9309 ไม่ได้ให้อำนาจบังคับใช้ใด ๆ แก่มันเลย บอตที่ทำตามกฎช่วยลดภาระของคุณได้ด้วยการเคารพไฟล์นี้ แต่ตัวไฟล์เองหน่วงหรือหยุดทราฟฟิกที่ไม่ทำตามไม่ได้
• จากโดเมน 137,210 แห่งในฐานลูกค้าเครื่องมือวิเคราะห์ของ Ahrefs พบว่า 97% ของไฟล์ llms.txt ที่เผยแพร่ไว้ไม่ได้รับคำขอเลยแม้แต่ครั้งเดียวในเดือนพฤษภาคม 2026 จะเผยแพร่ก็ได้ถ้าชอบ แต่อย่าสร้างเครื่องมือรอบ ๆ มัน
• คงข้อมูลโครงสร้างไว้ตรงที่มันช่วยสนับสนุนฟีเจอร์ Search แบบเดิม แต่เอกสารของ Google ระบุว่าฟีเจอร์ AI ของตนไม่ต้องใช้สคีมาพิเศษหรือไฟล์ข้อความสำหรับ AI ใด ๆ
• ถ้าต้องการให้ OpenAI, ClaudeBot, PerplexityBot หรือ CCBot อ่านเนื้อหาสำคัญได้ ให้เรนเดอร์เนื้อหานั้นฝั่งเซิร์ฟเวอร์ Vercel พบว่าครอว์เลอร์เหล่านี้ไม่รัน JavaScript ยกเว้น Gemini ที่ผ่าน Googlebot และ AppleBot
• การบังคับใช้ที่เกินกว่ากฎแบบขอความร่วมมือใน robots.txt อยู่ที่รีเวิร์สพร็อกซี ใน WAF ที่คุณดูแลเอง หรือหลังด่านพิสูจน์การทำงาน เรียงตามลำดับต้นทุนจากน้อยไปมาก

สิ่งที่บทความนี้ไม่ครอบคลุม

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

• การค้าที่ขับเคลื่อนด้วยเอเจนต์และขั้นตอนชำระเงิน เป็นปัญหาคนละแบบสำหรับเว็บไซต์คนละประเภท
• ข้อถกเถียงด้านกฎหมายและลิขสิทธิ์เรื่องข้อมูลเทรน ซึ่งเป็นการตัดสินใจเชิงธุรกิจ ไม่ใช่การตั้งค่าเซิร์ฟเวอร์
• คู่มือการอิมพลีเมนต์ WebMCP แบบทีละขั้น เพราะมาตรฐานนี้ยังอยู่ในสถานะ origin trial
• การตั้งค่าเฉพาะของแต่ละ CDN นอกเหนือจากหัวข้อ Cloudflare หัวข้อเดียวด้านล่าง

ครอว์เลอร์ AI ตัวไหนบ้างที่กำลังถล่มเว็บของคุณ

GPTBot และ ClaudeBot เก็บเนื้อหาที่อาจถูกนำไปใช้เทรนโมเดล ส่วน OAI-SearchBot และ Claude-SearchBot รองรับการค้นหาและการดึงข้อมูลด้วย AI ขณะที่ ChatGPT-User และ Claude-User จะดึงหน้าเว็บเมื่อผู้ใช้สั่ง งานเหล่านี้แยกกันในผู้ให้บริการบางราย แต่ไม่ใช่ครอว์เลอร์ทุกตัวบนเว็บที่จะจับคู่กับวัตถุประสงค์เดียวได้อย่างเรียบร้อย

ภาพของการปฏิบัติตามกฎนั้นละเอียดกว่าที่คำพูดสั้น ๆ ทั่วไปทำให้เข้าใจ เอกสารครอว์เลอร์ของ Anthropic ระบุว่า ClaudeBot, Claude-User และ Claude-SearchBot ปฏิบัติตาม robots.txt เอกสารบอตของ OpenAI ระบุว่าครอว์เลอร์อัตโนมัติของตนใช้การควบคุมแยกต่างหาก แต่กฎใน robots.txt อาจไม่มีผลกับ ChatGPT-User เพราะคำขอเหล่านั้นเริ่มต้นโดยคน เอกสารครอว์เลอร์ของ Perplexity ก็แยกแยะในทำนองเดียวกัน: PerplexityBot ปฏิบัติตามการควบคุมของผู้ดูแลเว็บ ขณะที่ Perplexity-User มักเพิกเฉยต่อ robots.txt ดังนั้นคำกล่าวเหมารวมว่าบอต AI ไม่สนใจ robots.txt จึงเป็นการเอาครอว์เลอร์ที่มีเอกสารกำกับและเคารพไฟล์นี้ มาปนกับตัวดึงหน้าที่ผู้ใช้สั่งซึ่งพฤติกรรมต่างกันไปตามผู้ให้บริการ รวมถึงสแครปเปอร์ที่ไม่เคยแสดงตัวเลย

ตารางด้านล่างเป็นข้อมูล ณ เวลาที่เขียน โทเคนใหม่ ๆ ปรากฏขึ้นเร็วกว่าที่บทความใดจะตามทัน จึงควรมองว่าเป็นแผนที่ตั้งต้นที่มีอายุสั้น

การเขียนกฎ robots.txt สำหรับครอว์เลอร์ AI

RFC 9309 ระบุว่ากฎใน robots.txt ไม่ใช่รูปแบบหนึ่งของการอนุญาตเข้าถึง IETF กำหนดมาตรฐานไวยากรณ์ การแยกวิเคราะห์ และการแคชไว้เมื่อเดือนกันยายน 2022 แต่ไม่ได้ทำให้ไฟล์นี้กลายเป็นกลไกบังคับใช้ รายละเอียดที่กัดจริงในทางปฏิบัติอยู่ใต้ชั้นไวยากรณ์ ไฟล์ต้องเข้ารหัสแบบ UTF-8 ตัวแยกวิเคราะห์ต้องประมวลผลได้อย่างน้อย 500 กิบิไบต์ และเมื่อคำสั่งขัดแย้งกัน การจับคู่เส้นทางที่เจาะจงที่สุดจะชนะ ส่วนตำแหน่งของกฎในไฟล์นั้นไม่มีผลใด ๆ

robots.txt สำหรับบอต AI ใช้ไฟล์เดิมและไวยากรณ์เดิมที่คุณมีอยู่แล้ว สิ่งที่เปลี่ยนคือรายชื่อโทเคน จัดกฎตามเจตนา แล้วมันจะอยู่ได้นานกว่ารายชื่อผู้ให้บริการ ถ้าคุณติดใจเรื่องการเทรนโมเดล ให้บล็อกโทเคนสำหรับเทรน แล้วปล่อยตัวทำดัชนีไว้ตามเดิม:

# Block training, keep AI search indexing
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

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

# Send a site-wide opt-out signal to named AI tokens
User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: OAI-AdsBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: CCBot
Disallow: /

นั่นก็ยังไม่ใช่การบล็อกแบบครอบจักรวาล Anthropic บังคับใช้ robots.txt กับ Claude-User แต่ OpenAI ระบุว่ากฎอาจไม่มีผลกับ ChatGPT-User และ Perplexity-User มักเพิกเฉย หากการดึงหน้าที่ผู้ใช้สั่งเหล่านั้นต้องถูกหยุดจริง ไม่ใช่แค่ถูกกีดกัน ให้บังคับใช้การตัดสินใจนั้นที่พร็อกซีหรือ WAF

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

การไล่อัปเดตรายชื่อโทเคนด้วยมือไม่ใช่วิธีใช้เวลาบ่ายที่ดีนัก คลังโค้ด ai.robots.txt ที่ดูแลโดยชุมชน คอยติดตาม user agent ของ AI และสร้างไฟล์คอนฟิกให้ทั้ง robots.txt, nginx, Caddy, HAProxy, Lighttpd และ Apache ผู้ดูแล Apache สามารถวางบล็อกที่สร้างขึ้นไว้ข้าง ๆ กฎ .htaccess ระดับไดเรกทอรี.

เคล็ดลับ: อย่าเชื่อสตริง user-agent มันเป็นแค่เฮดเดอร์ และเฮดเดอร์นั้นปลอมได้ฟรี ๆ เอกสาร CCBot ของ Common Crawl เตือนว่ามีครอว์เลอร์แอบอ้างตัวเป็น CCBot สำหรับ IPv4 ให้ตรวจสอบด้วย reverse DNS ที่ยืนยันย้อนกลับได้ ภายใต้โดเมน *.crawl.commoncrawl.orgส่วน IPv6 ให้ใช้ช่วง IP ที่ Common Crawl เผยแพร่ไว้ เพราะที่นั่นยังไม่รองรับ reverse DNS หน้าเอกสารของผู้ให้บริการที่กล่าวถึงข้างต้นก็เผยแพร่ช่วง IP ปัจจุบันของครอว์เลอร์รายอื่นที่ระบุชื่อไว้เช่นกัน นี่คือเส้นทางการตรวจสอบที่มีเอกสารรองรับสำหรับผู้ให้บริการเหล่านี้ ไม่ใช่คุณสมบัติของครอว์เลอร์ AI โดยทั่วไป

llms.txt มีผลอะไรบ้างไหม?

จากหลักฐานเท่าที่มีตอนนี้ แทบไม่มีผลอะไรเลย llms.txt คือไฟล์ข้อความที่มีผู้เสนอให้วางไว้ที่รากของเว็บไซต์ เพื่อเสนอบทสรุปเนื้อหาที่คัดสรรแล้วให้กับโมเดลภาษา การเผยแพร่มันมีต้นทุนต่ำ แต่หลักฐานปัจจุบันแทบไม่ให้เหตุผลที่จะลงแรงกับมัน และเอกสารของ Google ก็ระบุว่าคุณไม่จำเป็นต้องมีมันสำหรับฟีเจอร์ AI Search ของตน

รูปแบบไฟล์เรียบง่ายมาก ข้อเสนอ llms.txt มีมาตั้งแต่เดือนกันยายน 2024 อยู่ที่ /llms.txtและกำหนดให้หัวข้อ H1 ที่ระบุชื่อเว็บไซต์หรือชื่อโปรเจกต์เป็นส่วนเดียวที่จำเป็นต้องมี

คำตัดสินมาจากตัวเลขที่วัดได้ งานศึกษาของ Ahrefs ที่ครอบคลุม 137,210 โดเมน พบว่า 28% ของโดเมนที่วัดผลมีการเผยแพร่ไฟล์ llms.txt และ 97% ของไฟล์เหล่านั้นไม่ได้รับคำขอเลยในเดือนพฤษภาคม 2026 ส่วนคำขอที่เข้ามาจริง มี 19.5% ที่มาจากเครื่องมือ AI ที่ระบุชื่อได้ Ahrefs ยังเตือนด้วยว่า การที่ไฟล์ถูกดึงไปไม่ได้พิสูจน์ว่ามันถูกนำไปใช้จริง

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

ประเด็นสำคัญ: ในงานศึกษาของ Ahrefs ไฟล์ llms.txt ที่เผยแพร่ไว้ 97% ไม่ได้รับคำขอเลยแม้แต่ครั้งเดียวในเดือนพฤษภาคม 2026

ทำให้หน้าเว็บของคุณอ่านได้ด้วยเครื่อง

การวัดพฤติกรรมครอว์เลอร์ของ Vercel พบว่าครอว์เลอร์ของ OpenAI, ClaudeBot, PerplexityBot, Meta-ExternalAgent, Bytespider และ CCBot ไม่รัน JavaScript ส่วน Gemini ที่ผ่าน Googlebot และ AppleBot นั้นรัน สำหรับครอว์เลอร์ที่ไม่เรนเดอร์ เนื้อหาที่โผล่มาหลังไฮเดรชันฝั่งไคลเอนต์เท่านั้นจะมองไม่เห็นเลย ดังนั้นให้เรนเดอร์สิ่งสำคัญทั้งหมดฝั่งเซิร์ฟเวอร์ ส่วนเรื่องมาร์กอัปนั้นตอบง่ายกว่า และคำแนะนำของ Google เองในเรื่องนี้ก็ตรงไปตรงมาผิดปกติ:

"คุณไม่จำเป็นต้องสร้างไฟล์ที่เครื่องอ่านได้ ไฟล์ข้อความสำหรับ AI หรือมาร์กอัปใหม่ใด ๆ เพื่อให้ปรากฏในฟีเจอร์เหล่านี้ และไม่มีข้อมูลโครงสร้าง schema.org แบบพิเศษที่คุณต้องเพิ่มเข้าไปด้วย"

แนวทางด้าน AI ของ Google Search Central

ตัวเลขการมองเห็นที่เพิ่มขึ้น 40% ซึ่งมักถูกยกมาอ้างเพื่อสนับสนุน FAQ schema นั้นมาจาก งานวิจัย GEO ซึ่งได้รับตอบรับใน KDD 2024 งานวิจัยรายงานว่าได้ผลเพิ่มขึ้นสูงสุดถึง 40% แต่สิ่งที่งานนี้ทดสอบคือการเปลี่ยนแปลงเนื้อหา เช่น การอ้างอิงแหล่งที่มา การยกข้อความ สถิติ ศัพท์เทคนิค และการเรียบเรียงที่ลื่นไหล ไม่ใช่ FAQPage หรือมาร์กอัป Schema.org ใด ๆ ตัวเลขนั้นถูกต้อง แต่การเอาไปผูกกับ schema markup นั้นไม่ถูก

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

เมื่อ robots.txt ไม่พอ: การจำกัดอัตราและ WAF ที่ระดับเซิร์ฟเวอร์

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

ก่อนจะไต่บันไดนั้น ยังมีวิธีที่ถูกกว่าสำหรับทราฟฟิกที่ยังให้ความร่วมมืออยู่ นั่นคือทำให้มันช้าลง:

User-agent: ClaudeBot
Crawl-delay: 1

เคล็ดลับ: จำกัดความเร็วก่อนแล้วค่อยบล็อก เอกสารของ Anthropic รองรับ Crawl-delay สำหรับ ClaudeBot คุณจึงชะลอครอว์เลอร์ที่กินทรัพยากรแต่มารยาทดีให้ช้าลงและยังเก็บมันไว้ได้ หน้าเดียวกันนี้ยังระบุว่าการบล็อกด้วย IP ไม่ใช่กลไกปฏิเสธที่คงทน ทั้งสองประเด็นเป็นเรื่องเฉพาะของ Anthropic Crawl-delay ไม่ใช่คำสั่งที่ใช้ได้ทั่วไป จึงควรอ่านเอกสารของผู้ให้บริการแต่ละรายก่อน

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

ขั้นที่ 1: คำสั่งบนรีเวิร์สพร็อกซีและการจำกัดอัตรา

การจำกัดอัตราของครอว์เลอร์ AI เริ่มที่รีเวิร์สพร็อกซี ซึ่งเป็นสิ่งแรกในสแตกของคุณที่เห็นคำขอ และสามารถหน่วงมันไว้ก่อนที่แอปพลิเคชันหรือฐานข้อมูลจะเริ่มทำงานใด ๆ เอกสารเรื่องการจำกัดอัตราของ NGINX ระบุว่าคำขอที่มีคีย์ว่างจะไม่ถูกนับ ดังนั้น map จะให้คีย์จำกัดอัตราเฉพาะกับโทเคนครอว์เลอร์ที่คุณต้องการหน่วงเท่านั้น และปล่อยคำขอที่ไม่ตรงเงื่อนไขไว้นอก limit_req_zone.

# /etc/nginx/nginx.conf, inside the http block
map $http_user_agent $ai_rate_key {
    default              "";
    ~*GPTBot             $binary_remote_addr;
    ~*OAI-SearchBot      $binary_remote_addr;
    ~*ClaudeBot          $binary_remote_addr;
    ~*Claude-SearchBot   $binary_remote_addr;
    ~*PerplexityBot      $binary_remote_addr;
    ~*CCBot              $binary_remote_addr;
}

limit_req_zone $ai_rate_key zone=ai_slowlane:10m rate=20r/m;

# /etc/nginx/sites-available/example.conf, inside the server block
location / {
    limit_req zone=ai_slowlane burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

คู่ค่าที่ต้องปรับจูนคือ burst=10 nodelayโดยคำขอที่เกินอัตราเฉลี่ยจะกินโควตาเบิร์สต์ได้ทันที ส่วนคำขอที่เกินไปกว่านั้นจะได้รับ 503 เป็นค่าเริ่มต้น ถ้าตั้งแน่นเกินไป คุณจะเด้งครอว์เลอร์ที่ถูกต้องออกกลางคัน ซึ่งเป็นปัญหาที่วินิจฉัยได้ช้ากว่าเหตุเว็บล่มเสียอีก Caddy แสดงแนวคิดสองอย่างเดียวกันนี้ด้วย matcher และ handler ถ้าคุณกำลังเลือกระหว่างสองตัวนี้ ไฟล์คอนฟิกที่วางเทียบกัน มีประโยชน์กว่าตัวเลขทรูพุตจากการทดสอบสังเคราะห์

ข้อจำกัดของขั้นนี้คือ ช่องทางช้ายังต้องพึ่ง user agent ที่ประกาศมาอยู่ดี สแครปเปอร์ที่สวมรอยเป็น Chrome จึงเลี่ยงคีย์เฉพาะครอว์เลอร์นี้ไปได้ทั้งหมด การจับทราฟฟิกแบบนั้นต้องใช้การจำกัดอัตราที่กว้างขึ้นโดยอิงพฤติกรรมของ IP หรือเส้นทาง หรือไม่ก็ต้องขึ้นไปที่ขั้น WAF ข้างล่างนี้

ขั้นที่ 2: ไฟร์วอลล์แอปพลิเคชันเว็บที่คุณดูแลเอง

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

นั่นก็คือต้นทุนของขั้นนี้เช่นกัน กฎต้องมีการดูแล และกฎที่ปรับแน่นพอจะจับสแครปเปอร์ที่ตั้งใจจริงได้ สุดท้ายก็จะจับคนธรรมดาไปด้วย โหมด Monitor, Balanced และ Strict ของ SafeLine ทำให้การแลกได้แลกเสียนี้ชัดเจน เริ่มจากเฝ้าดูทราฟฟิกให้นานพอจะเจอผลบวกลวงเสียก่อน แล้วค่อยปล่อยให้ WAF ตอบ 403 อัตโนมัติ

ขั้นที่ 3: ด่านพิสูจน์การทำงาน

Anubis ข้ามปัญหาการระบุตัวตนไปเลย สำหรับทราฟฟิกที่คุณเลือกจะตั้งด่าน มันจะบังคับให้คำขอนั้นจ่ายต้นทุนการคำนวณเล็กน้อยก่อนที่เซิร์ฟเวอร์ต้นทางจะให้บริการ ระบบนโยบายของมัน ยังสามารถอนุญาต ปฏิเสธ หรือตั้งด่านคำขอตามกฎการจับคู่ได้ด้วย ส่วน README ของโครงการ เรียกมันว่า Web AI Firewall Utility ที่สร้างขึ้นรอบแนวคิดการตั้งด่าน เพื่อปกป้องทรัพยากรต้นทางจากบอตสแครปเปอร์ มันทำงานได้โดยไม่ต้องพึ่งให้บอตทุกตัวแสดงตัวอย่างถูกต้อง

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

การกำหนดขนาดเครื่องรับช่วงพีก

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

เรื่องนี้จึงกลายเป็นคำถามเรื่องการจัดสรร และเป็นคำถามที่ชวนอึดอัด คุณจ่ายค่าเผื่อไว้ตลอดเวลา แต่มันคุ้มค่าเฉพาะตอนที่เกิดพีกซึ่งคุณควบคุมไม่ได้ ถึงอย่างนั้นก็ควรเผื่อไว้สำหรับพีกอยู่ดี ถ้า BunkerWeb ใช้เครื่องร่วมกับแอปพลิเคชันและฐานข้อมูล อย่าเข้าใจว่า 8 GB คือคำแนะนำสำหรับทั้งสแตก คู่มือเริ่มต้นใช้งานอย่างเร็วของ BunkerWeb แนะนำ 2 vCPU และแรม 8 GB สำหรับการทดสอบหรือการติดตั้งที่มีบริการน้อยมาก และอย่างน้อย 4 vCPU กับแรม 16 GB สำหรับสภาพแวดล้อมโปรดักชันที่ปกป้องบริการจำนวนมาก แล้วบวกเพิ่มด้วยพีก CPU ของตัวแอปเอง หน่วยความจำของฐานข้อมูล และส่วนเผื่อด้าน I/O

คอร์ที่สัญญาณนาฬิกาสูงกว่าช่วยได้เมื่อการจัดการคำขอหรือการรันคิวรีติดที่ CPU ส่วนจำนวนคอร์ที่มากขึ้นช่วยเมื่อคุณต้องรันงานพร้อมกันมากขึ้น จงกำหนดขนาดจากค่าคอนเคอร์เรนซีสูงสุด เวลาตอบสนอง p95 การใช้ CPU และเวลารอ I/O ของฐานข้อมูล และอัตราแคชพลาด มากกว่าจะดูแค่ทราฟฟิกจากครอว์เลอร์อย่างเดียว

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

พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC

ดูแพ็กเกจ Linux

ค่าเริ่มต้นใหม่ของ Cloudflare สำหรับทราฟฟิก AI

Cloudflare แบ่งทราฟฟิก AI ออกเป็นหมวด Search, Agent และ Training ไว้ใน ประกาศเรื่องทราฟฟิก AI เมื่อเดือนกรกฎาคม 2026ตั้งแต่วันที่ 15 กันยายน 2026 โดเมนใหม่ที่เข้ามาใช้ Cloudflare จะถูกบล็อกหมวด Training และ Agent เป็นค่าเริ่มต้นบนหน้าที่มีการแสดงโฆษณา ขณะที่ Search ยังคงอนุญาตอยู่ ลูกค้าเดิมสามารถเปลี่ยนค่านี้ล่วงหน้าได้ และตัวควบคุมเหล่านี้มีให้ใช้ในทุกแพ็กเกจ

ส่วนที่ควรหยิบมาใช้คือความยุ่งยากที่ Cloudflare ระบุไว้ในประกาศของตนเอง ในการจัดหมวดของ Cloudflare นั้น Googlebot, Applebot และ Bingbot ต่างก็ทำงานทั้งด้าน Search และ Training รวมกัน ลูกค้าที่บล็อกหมวด Training จึงบล็อกครอว์เลอร์เหล่านั้นไปด้วย รวมถึงพฤติกรรมการค้นหาที่ตั้งใจจะเก็บไว้ นี่คือกับดักเดียวกันที่รออยู่ในทุกการควบคุมระดับหมวดหมู่ ซึ่งปฏิบัติกับครอว์เลอร์อเนกประสงค์ราวกับว่ามันมีหน้าที่เดียว

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

WebMCP: ควรจับตา แต่ยังไม่ควรสร้างระบบรองรับ

WebMCP คือคู่ขนานฝั่งเบราว์เซอร์ของ Model Context Protocol ซึ่งเป็นข้อตกลงที่เอเจนต์ใช้เรียกเครื่องมือแบบมีโครงสร้างแทนการเดา ส่วน ประกาศ origin trial ของ WebMCP จาก Chrome วางเป้าหมายไว้ตรง ๆ ว่า แทนที่จะให้เอเจนต์เดาว่าปุ่มหรือช่องกรอกฟอร์มทำหน้าที่อะไร เว็บไซต์สามารถเปิดเผยฟังก์ชันแบบมีโครงสร้างและตัวควบคุมที่มีคำอธิบายกำกับ ให้เอเจนต์เรียกใช้ได้โดยตรง

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

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

User-agent: GPTBot
Disallow: /

grep -ohE 'GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|ChatGPT-User' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn