บอทที่มาเยอะที่สุดบนเว็บไซต์หนึ่ง กำลังสแกนหารหัสผ่าน ไม่ได้อ่านเนื้อหา

Search Engine Journal เผยแพร่บทวิเคราะห์ไฟล์ล็อกเซิร์ฟเวอร์เมื่อวันที่ 14 สิงหาคม 2026 ซึ่งชี้ว่าบอทที่เรียกกันว่า AI crawler และมีปริมาณการเข้าถึงเว็บไซต์แห่งหนึ่งสูงที่สุด ไม่ได้อ่านเนื้อหาของเว็บไซต์นั้นแม้แต่หน้าเดียว แต่ใช้คำขอทั้งหมดไปกับการไล่หาไฟล์ที่เก็บรหัสผ่านและคีย์แทน บทวิเคราะห์ดูล็อก 24 ชั่วโมงของเว็บไซต์ nohacks.co ที่สิ้นสุดวันที่ 7 สิงหาคม 2026 มีคำขอรวมราว 3,000 ครั้ง และประมาณหนึ่งในสามของคำขอทั้งหมดไม่สำเร็จ

User agent ที่มีปริมาณสูงสุดคือ CCBot ที่ 1,510 คำขอ ซึ่งเป็นสตริงที่ระบุว่าเป็นของ Common Crawl นำหน้า ChatGPT-User ที่ 375 คำขอ ClaudeBot ที่ 296 คำขอ และ Googlebot ที่ 245 คำขอ แต่ประเด็นที่สำคัญกว่าคือมันขออะไร ในพาธที่ใช้สแกนหาไฟล์ credential รวม 100 พาธ เว็บไซต์บันทึกคำขอไว้ 1,028 ครั้ง กินแบนด์วิดท์ 6.7 MB โดยไม่มีการเข้าถึงเนื้อหาใดเลย พาธที่ถูกขอรวมถึง /.ssh/known_hosts 42 ครั้ง /.boto 30 ครั้ง และ /.env.production 29 ครั้ง รวมถึงคีย์ของ Firebase ไฟล์คอนฟิกของ AWS และไฟล์ private key ที่สำคัญคือมีพาธใหม่สองรายการ ได้แก่ /.mcp.json 30 คำขอ และ /.continue/config.json 24 คำขอ ซึ่งทั้งคู่เป็นไฟล์ที่อาจเก็บ API key และโทเคนสำหรับยืนยันตัวตนของเอเจนต์เอาไว้

คำทำนายของ Cloudflare ที่เป็นจุดตั้งต้นของการตรวจล็อก

บทวิเคราะห์ชิ้นนี้เขียนขึ้นเพื่อทดสอบคำกล่าวของ Thomas Seifert ประธานเจ้าหน้าที่ฝ่ายการเงินของ Cloudflare ในการประชุมแจ้งผลประกอบการไตรมาสที่สอง Seifert ระบุว่าภายในห้าปี ทราฟฟิกที่ไม่ได้มาจากมนุษย์จะมากถึง 1,000 เท่าของทราฟฟิกจากมนุษย์ และมนุษย์จะกลายเป็นเศษที่ปัดทิ้งได้บนอินเทอร์เน็ต เขายังยอมรับด้วยว่าคำทำนายก่อนหน้านี้ของตัวเองประเมินการเติบโตต่ำเกินไป เพราะทราฟฟิกจากเครื่องแซงทราฟฟิกจากมนุษย์บนเครือข่ายของ Cloudflare ไปแล้วตั้งแต่เดือนพฤษภาคม 2026 เร็วกว่าจุดตัดปี 2027 ที่เขาเคยคาดไว้

คำทำนายระดับนั้นพูดต่อได้ง่ายแต่ตรวจสอบได้ยาก สิ่งที่ Search Engine Journal ทำจึงเป็นการตั้งคำถามที่แคบลงและตรวจสอบได้จริงกับไฟล์ล็อกจริงหนึ่งไฟล์ นั่นคือ ในบรรดาทราฟฟิกที่เข้ามาพร้อม user agent ของบอท มีสัดส่วนเท่าไรที่เป็นการไล่เก็บเนื้อหาแบบที่ crawler ควรทำ อ่านบทวิเคราะห์ฉบับเต็มได้ที่ Search Engine Journal คำตอบสำหรับเว็บไซต์นี้ในวันนั้นคือ บอทที่มีจำนวนคำขอสูงสุดไม่ได้กำลังไล่อ่านเนื้อหาเลย

บอทอันดับหนึ่งขออะไรบ้าง

ตารางด้านล่างคือปริมาณคำขอแยกตามสตริง user agent ในช่วง 24 ชั่วโมงที่สิ้นสุดวันที่ 7 สิงหาคม 2026 ตามที่ Search Engine Journal รายงานไว้ ขอให้อ่านมันในฐานะการจัดอันดับของ ตัวตนที่ผู้ส่งคำขอประกาศเอง ไม่ใช่ crawler ที่ผ่านการยืนยันแล้ว เพราะความต่างตรงจุดนี้คือแก่นของเรื่องทั้งหมด

แดชบอร์ดที่สร้างจากตารางนี้เพียงอย่างเดียวจะเล่าเรื่องที่ฟังดูเรียบร้อยมาก คือ AI crawler ครองทราฟฟิกของเว็บไซต์นี้ไปแล้ว และ Common Crawl คือรายที่กินแบนด์วิดท์มากที่สุด แต่ไฟล์ล็อกบอกอีกอย่าง คำขอ 1,028 ครั้งที่วิ่งเข้าพาธ credential ไม่ได้เนื้อหากลับไปเลย เพราะไม่มีเนื้อหาอยู่ที่พาธเหล่านั้นตั้งแต่แรก นั่นคือการโอนข้อมูล 6.7 MB ที่หมดไปกับการตอบ 404 และการเคาะประตูไปเรื่อย และเป็นเหตุผลว่าทำไมคำขอราวหนึ่งในสามของทั้งวันจึงไม่สำเร็จ

การสแกนหาไฟล์ credential ที่แต่งตัวเป็น crawler

พาธที่ถูกร้องขอคือหลักฐานที่ชัดที่สุด crawler ที่ต้องการเนื้อหาจะขอหน้า HTML ไฟล์ sitemap ฟีด และรูปภาพ ส่วนตัวสแกนจะขอไฟล์ที่ไม่ควรถูกเสิร์ฟผ่าน HTTP ตั้งแต่ต้น เช่น /.ssh/known_hosts ที่บอกว่าเซิร์ฟเวอร์เคยเชื่อมต่อไปยังโฮสต์ใดบ้าง /.boto ที่เก็บ credential ของไคลเอนต์คลาวด์สตอเรจ และ /.env.production ซึ่งในแอปที่ deploy ผิดวิธีจะเก็บรหัสผ่านฐานข้อมูล คีย์ระบบชำระเงิน และ API secret ไว้เป็นข้อความธรรมดา Search Engine Journal ยังบันทึกคำขอที่พุ่งไปยังคีย์ Firebase ไฟล์คอนฟิก AWS และ private key ภายในชุด 100 พาธเดียวกันนี้ด้วย

ไม่มีอะไรในพฤติกรรมชุดนี้ที่บังคับว่าผู้ส่งคำขอต้องเป็น Common Crawl จริง และหลักฐานในบทความก็ชี้ไปคนละทาง สตริง user agent เป็นเฮดเดอร์ที่ไคลเอนต์เขียนบรรยายตัวเอง ใครจะส่งข้อความอะไรก็ได้ และตัวสแกนที่อยากให้ทราฟฟิกของตัวเองดูน่าเบื่อในไฟล์ล็อกก็มีแรงจูงใจชัดเจนที่จะยืมชื่อของ crawler ที่เจ้าของเว็บคุ้นเคยและคาดว่าจะเห็นอยู่แล้ว

ไฟล์คอนฟิกของเอเจนต์เข้ามาอยู่ในรายการสแกนแล้ว

รายการที่ใหม่จริงในล็อกชุดนี้คือพาธคอนฟิกของเครื่องมือเอเจนต์สองรายการ /.mcp.json ได้รับ 30 คำขอ และ /.continue/config.json ได้รับ 24 คำขอ ในช่วง 24 ชั่วโมงเดียวกัน ทั้งสองเป็นไฟล์ที่เครื่องมือฝั่งพัฒนาเขียนลงในไดเรกทอรีของโปรเจกต์ และทั้งสองสามารถบรรจุ API key กับโทเคนยืนยันตัวตนของเอเจนต์ได้ ขึ้นอยู่กับว่าตั้งค่ากันไว้อย่างไร

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

ทำไมรายงานล็อกที่จัดกลุ่มด้วย user agent อย่างเดียวจึงพาคุณหลงทาง

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

• ยืนยันตัวตนก่อนจะยกทราฟฟิกให้ใคร วิธีมาตรฐานคือทำ reverse DNS กับ IP ที่ส่งคำขอ แล้วทำ forward lookup กับชื่อที่ได้กลับมาเพื่อดูว่ามันวนกลับมาที่ IP เดิมหรือไม่ และผู้ให้บริการ crawler รายใหญ่ก็ประกาศช่วง IP ของตัวเองไว้ให้เทียบ
• รายงานด้วยพาธ ไม่ใช่แค่จำนวนครั้ง บอทที่ขอ URL ไป 1,500 รายการโดยไม่มีรายการไหนเป็นเนื้อหาเลย ไม่ใช่ crawler และมีแต่คอลัมน์พาธเท่านั้นที่จะเผยเรื่องนี้ออกมา
• แยกคำขอที่สำเร็จออกจากคำขอที่ล้มเหลว สัดส่วนการตอบ 404 ที่สูงผิดปกติในทราฟฟิกของบอทตัวหนึ่ง เป็นสัญญาณในตัวมันเอง
• อย่ากำหนดนโยบาย crawl budget การจำกัดอัตรา หรือกฎใน robots.txt จากชื่อที่อาจถูกปลอม เพราะการบล็อกสตริง user agent จะไปโดนไคลเอนต์ที่รายงานชื่อตัวเองตามจริง ส่วนตัวสแกนไม่กระทบเลย เพราะมันแค่เปลี่ยนสตริงที่ส่งมา

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

สิ่งที่ควรตรวจบนเว็บไซต์ของคุณเอง

งานที่ต้องลงมือทำจริงนั้นสั้นมาก และคุ้มที่จะทำไม่ว่าล็อกของคุณจะหน้าตาเหมือนในบทวิเคราะห์นี้หรือไม่

1. ลองยิงคำขอไปยังพาธเหล่านี้ด้วยตัวเองผ่าน HTTPS บนเว็บไซต์จริง ได้แก่ /.env, /.env.production, /.boto, /.ssh/known_hosts, /.mcp.json และ /.continue/config.json อะไรก็ตามที่ไม่ใช่ 404 หรือ 403 ถือเป็นสิ่งที่ต้องตามต่อ
2. ถ้าพาธใดตอบกลับมาเป็น 200 ให้ถือว่าเป็นเหตุการณ์ด้านความปลอดภัย ไม่ใช่งานที่รอสปรินต์หน้า ลำดับที่ถูกต้องคือเปลี่ยนคีย์และรหัสที่หลุดก่อน ลบไฟล์เป็นอันดับสอง แล้วค่อยไปหาว่ามันขึ้นไปอยู่บนนั้นได้อย่างไร
3. ตรวจว่า web root ของคุณมีเฉพาะสิ่งที่ตั้งใจจะเสิร์ฟจริง ๆ ไฟล์ที่เหลือจากกระบวนการ deploy ไฟล์ environment คอนฟิกของเอดิเตอร์ ไดเรกทอรีของระบบควบคุมเวอร์ชัน และไฟล์สำรอง ไม่ควรอยู่ในไดเรกทอรีสาธารณะ
4. บล็อกไฟล์ที่ขึ้นต้นด้วยจุดที่ระดับเซิร์ฟเวอร์หรือที่ edge เพื่อให้ความผิดพลาดในอนาคตล้มเหลวในทางที่ปลอดภัย กฎที่ปฏิเสธคำขอทุกพาธที่ขึ้นต้นด้วยจุดแทบไม่มีต้นทุน และครอบคลุมไฟล์ที่ยังไม่มีอยู่ในวันนี้ด้วย
5. รันรายงานบอทใหม่โดยใส่มิติของพาธเข้าไปด้วย และยืนยัน user agent อันดับต้น ๆ ด้วย reverse DNS ก่อนจะเขียนข้อสรุปใด ๆ เกี่ยวกับปริมาณ AI crawler

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

ข้อจำกัดของข้อมูลชุดนี้ตามความเป็นจริง

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

บทความยังไม่ได้ยืนยันว่า Common Crawl เป็นผู้กระทำผิดแต่อย่างใด สิ่งที่มันแสดงคือทราฟฟิกที่ประกาศตัวเองว่าเป็น CCBot และมีพฤติกรรมแบบตัวสแกนหา credential การชี้ว่าทราฟฟิกนั้นเป็นของผู้ให้บริการรายใดต้องผ่านขั้นตอนการยืนยันที่อธิบายไว้ข้างต้น ซึ่งก็คือข้อโต้แย้งหลักของบทความนั่นเอง แหล่งข่าวไม่ได้รายงานคำตอบจาก Common Crawl, Cloudflare หรือผู้ให้บริการ crawler รายใดต่อข้อค้นพบนี้

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

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

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

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

แปลว่าทราฟฟิกจาก AI crawler ไม่ได้โตจริงหรือ

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

ถ้าทีมของเราไม่เคยใช้เครื่องมือเอเจนต์เลย เว็บไซต์ยังเสี่ยงอยู่ไหม

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

จะแยก crawler ตัวจริงออกจากตัวปลอมได้อย่างไร

ทำ reverse DNS กับ IP ที่ส่งคำขอ แล้วทำ forward lookup เพื่อยืนยันว่าชื่อนั้นวนกลับมาที่ IP เดิม จากนั้นเทียบกับช่วง IP ที่ผู้ให้บริการ crawler ประกาศไว้ สตริง user agent เพียงอย่างเดียวไม่พิสูจน์อะไรเลย เพราะไคลเอนต์เป็นคนเขียนมันขึ้นมาเอง สัญญาณรองคือพฤติกรรมของพาธ crawler จริงจะขอเนื้อหา ส่วนตัวสแกนจะขอไฟล์คอนฟิก

ควรบล็อก CCBot เพราะเรื่องนี้หรือไม่

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

เรื่องนี้เกิดขึ้นในไทยแล้วหรือยัง หรือจำกัดอยู่แค่บางภูมิภาค

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

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