Gary Illyes จาก Google: AI ทำให้ทราฟฟิก Googlebot ปลอมหนักขึ้น และวิธียืนยันตัวจริง

Gary Illyes จาก Google ระบุว่า AI ทำให้ปัญหาการปลอมตัวเป็น Googlebot หนักขึ้น เพราะบริษัทที่เก็บเนื้อหาไปฝึกโมเดลแอบอ้างเป็น Googlebot เพื่อเข้าเว็บไซต์ที่ปกติจะบล็อกพวกเขา เขาพูดเรื่องนี้ในการสัมภาษณ์กับ Aneta Samkoff ใน Odys Podcast ซึ่ง Search Engine Roundtable สรุปไว้เมื่อวันที่ 30 ตุลาคม 2569 คำแนะนำของเขาคืออย่าเชื่อ user-agent ที่บอกว่าเป็น Googlebot แต่ให้ตรวจ IP address และ reverse DNS ของคำขอแทน ซึ่งเป็นวิธีเดียวกับที่เอกสารของ Google กำหนดไว้สำหรับยืนยันตัวตนของ crawler

Gary Illyes พูดอะไรเรื่องการปลอมตัวเป็นบอต

การปลอมตัวเป็นบอต (bot impersonation) คือการที่ crawler อ้างว่าเป็นอีกรายหนึ่ง ส่วนใหญ่ทำโดยส่ง user-agent ของ Googlebot เมื่ออธิบายว่าทำไมปัญหานี้จึงเพิ่มขึ้น Illyes กล่าวว่า "I think it is AI." ตามรายงานของ Search Engine Roundtable โดย Barry Schwartz เขาอธิบายต่อว่า "more and more companies are looking for tokens for training their own models" คือมีบริษัทมากขึ้นเรื่อย ๆ ที่หาข้อมูลมาฝึกโมเดลของตัวเอง และสิ่งนั้นต้องใช้เนื้อหา เขาบอกว่าบริษัทเหล่านี้มองอินเทอร์เน็ตเป็น "a big farm where you can just go out and harvest whatever you need" หรือไร่ใหญ่ที่ออกไปเก็บเกี่ยวอะไรก็ได้ตามต้องการ

Illyes บอกว่าไฟร์วอลล์และ CDN ตรวจจับ crawler แบบนี้ได้ดีขึ้น แต่ "are not perfect" คือยังไม่สมบูรณ์ และยังปล่อยทราฟฟิกบางส่วนที่ตั้งใจจะกันไว้ให้ผ่านเข้ามา เขาอธิบายแรงจูงใจไว้ตรง ๆ ว่า เครื่องมือ AI รายเล็ก หรือใครก็ตามที่อยากดึงข้อมูลจากเว็บไซต์ สามารถอ้างว่าเป็น Googlebot และอาจได้รับอนุญาตให้เข้า ในขณะที่ถ้าไม่อ้างก็อาจถูกบล็อก เขาบอกว่าการรู้ว่าใครกำลัง crawl เว็บอยู่จริง ทำให้เจ้าของเว็บตัดสินใจเองได้ว่าใครควรเข้าถึงเว็บไซต์และใครไม่ควร

ประเด็นอื่นจากการสัมภาษณ์

Search Engine Roundtable สรุปประเด็นเพิ่มเติมจากวิดีโอไว้ ตารางด้านล่างสรุปตามที่สื่อนั้นรายงาน ข้อมูลมาจากบทสรุปของ Search Engine Roundtable ไม่ใช่จากบทถอดความฉบับเต็ม

Google บอกให้ยืนยัน Googlebot อย่างไร

หน้าเอกสาร "Verify requests from Google crawlers and fetchers" ของ Google ซึ่งอัปเดตล่าสุดเมื่อวันที่ 20 มีนาคม 2569 อธิบายไว้สองวิธี วิธีแบบทำเองใช้การค้น DNS ผ่าน command line และ Google เขียนว่า "is sufficient for most use cases" คือเพียงพอสำหรับกรณีส่วนใหญ่ ส่วนวิธีอัตโนมัติคือการเทียบ IP address ที่เข้ามากับรายการช่วง IP ที่ Google เผยแพร่เป็นไฟล์ JSON เหมาะกับการตรวจในปริมาณมาก

การตรวจแบบทำเองมีสองขั้นตอน

• ทำ reverse DNS lookup กับ IP address จาก log ของเซิร์ฟเวอร์ เช่น ใช้คำสั่ง host แล้วตรวจว่าชื่อโฮสต์ที่ได้กลับมาอยู่ใต้ googlebot.com, google.com หรือ googleusercontent.com
• ทำ forward DNS lookup กับชื่อโฮสต์นั้น แล้วตรวจว่าได้ IP address เดียวกับที่ปรากฏใน log

ตัวอย่างแรกของ Google แสดงผลที่ถือว่าผ่าน คือ IP 66.249.66.1 ชี้กลับไปที่ crawl-66-249-66-1.googlebot.com และชื่อโฮสต์นั้นชี้กลับมาที่ 66.249.66.1 ต้องทำทั้งสองขั้นตอน หน้าเอกสารของ Google ไม่ได้อธิบายเหตุผลไว้ แต่เหตุผลมาจากการทำงานของ DNS ผู้ที่ควบคุมช่วง IP ใดก็ควบคุม reverse DNS ของช่วงนั้นได้ และตั้งให้คืนชื่อที่ดูเหมือนของ Google ได้ มีเพียงการค้นแบบ forward บนโดเมนของ Google เองที่ยืนยันได้ว่าชื่อและ IP เป็นของคู่กันจริง

สำหรับวิธีอัตโนมัติ Google เผยแพร่ช่วง IP ในรูปแบบ CIDR ส่วน IP อื่นของ Google ที่อาจเข้ามายังเว็บไซต์ เช่น Apps Script หน้าเอกสารให้ไปเทียบกับรายการ IP ทั่วไปของ Google เครื่องมืออ่าน log หรือกฎ WAF ที่ดึงไฟล์เหล่านี้มาอัปเดตเป็นระยะ แล้วตรวจทุกคำขอที่อ้างว่าเป็น Googlebot จะทำงานแบบเดียวกับคำสั่ง host แต่ทำได้ในปริมาณมาก

crawler ของ Google สามประเภทและชื่อโฮสต์ของแต่ละประเภท

หน้าเอกสารของ Google แบ่ง crawler ออกเป็นสามกลุ่ม แต่ละกลุ่มชี้ไปที่รูปแบบชื่อโฮสต์ต่างกัน อยู่ในไฟล์ JSON คนละไฟล์ และปฏิบัติต่อ robots.txt ต่างกัน เรื่องนี้สำคัญเวลาอ่าน log เพราะไม่ใช่ทุก IP ของ Google ที่ยืนยันแล้วจะเป็น Googlebot ที่ crawl เพื่อ Search

มีรายละเอียดหนึ่งที่มองข้ามได้ง่าย Google ระบุว่า IP ใน user-triggered-fetchers.json ชี้ไปที่ชื่อโฮสต์ gae.googleusercontent.com และใช้ในกรณีเช่น เว็บไซต์ที่รันบน Google Cloud ดึง RSS feed จากภายนอกตามคำขอของผู้ใช้เว็บนั้นเอง คำขอแบบนี้ผ่านการตรวจโดเมน googleusercontent.com แต่ไม่ใช่ Googlebot Relevant Audience อ่านตารางของ Google แล้วเห็นว่า log ที่ส่ง user-agent ของ Googlebot มาจากโฮสต์ gae.googleusercontent.com ควรถูกตรวจละเอียดขึ้น แทนที่จะอนุญาตโดยอัตโนมัติ หน้าเอกสารของ Google ไม่ได้พูดถึงกรณีนี้โดยตรง

ทำไม user-agent จึงพิสูจน์อะไรไม่ได้

หน้าภาพรวมของ Googlebot เตือนไว้อยู่แล้วว่า "the HTTP user-agent request header used by Googlebot is often spoofed by other crawlers" คือ header user-agent ของ Googlebot มักถูก crawler อื่นปลอมแปลง หน้าเดียวกันบอกว่าวิธีที่ดีที่สุดในการยืนยันคือทำ reverse DNS lookup กับ IP ต้นทาง หรือเทียบกับช่วง IP ของ Googlebot และยังระบุว่า Googlebot Smartphone กับ Googlebot Desktop ใช้ product token เดียวกันใน robots.txt รวมถึงบอกว่าสำหรับเว็บไซต์ส่วนใหญ่ Googlebot "shouldn't access your site more than once every few seconds on average" คือโดยเฉลี่ยไม่ควรเข้าเว็บบ่อยกว่าหนึ่งครั้งในทุกไม่กี่วินาที

ประโยคสุดท้ายนี้ใช้เป็นเกณฑ์คร่าว ๆ ได้ Googlebot ที่อ้างตัวเองแล้วยิงคำขอเข้าเว็บไซต์เล็กหลายครั้งต่อวินาทีไม่ตรงกับคำอธิบายของ Google เอง นี่เป็นเหตุผลให้ตรวจ DNS แต่ยังไม่ใช่หลักฐานในตัวเอง เพราะ Google ระบุด้วยว่าอัตราการเข้าอาจดูสูงขึ้นเล็กน้อยในช่วงเวลาสั้น ๆ

robots.txt, WAF และการบล็อกบอตให้ถูกตัว

การที่ Illyes เรียก robots.txt ว่าเป็นเพียงคำขอ ตรงกับวิธีที่เอกสารของ Google อธิบายไฟล์นี้ หน้า Googlebot ของ Google แนะนำให้ใช้ robots.txt เพื่อกันการ crawl ใช้ noindex เพื่อกันการทำดัชนี และใช้ "another method, such as password protection" หรือวิธีอื่นอย่างการตั้งรหัสผ่าน เพื่อกันไม่ให้ทั้ง crawler และผู้ใช้เข้าถึงหน้าได้ บอตที่ดึงข้อมูลโดยไม่สนใจ robots.txt และปลอม user-agent เป็น Googlebot จะไม่ถูกหยุดด้วยสองวิธีแรก การบังคับใช้จริงต้องทำที่เซิร์ฟเวอร์ CDN หรือไฟร์วอลล์

ความเสี่ยงอีกด้านคือการบล็อก Googlebot ตัวจริงโดยไม่ตั้งใจ หน้าเอกสารของ Google ระบุว่าการบล็อก Googlebot มีผลกับ Google Search รวมถึง Discover และฟีเจอร์ทั้งหมดของ Search รวมถึงผลิตภัณฑ์อื่นอย่าง Google Images, Google Video และ Google News กฎไฟร์วอลล์ที่บล็อกจาก user-agent อย่างเดียว หรือใช้รายการ IP ของ Google ฉบับเก่า อาจทำให้เว็บไซต์หลุดจาก Search ได้ กฎที่ปลอดภัยกว่าคือการอนุญาตช่วง IP ของ Google ที่ยืนยันแล้ว และตรวจสอบเพิ่มหรือบล็อกเฉพาะคำขอที่ยืนยันไม่ผ่าน

สิ่งที่แหล่งข่าวไม่ได้บอก

• บทสรุปของ Search Engine Roundtable ไม่มีตัวเลขว่าทราฟฟิก Googlebot ปลอมมีมากเท่าใด หรือเพิ่มขึ้นเร็วแค่ไหน
• ตามบทสรุป Illyes ไม่ได้ระบุชื่อบริษัทใดที่ปลอมตัวเป็น Googlebot
• ไม่มีการรายงานวันที่หรือผลิตภัณฑ์ที่ Google จะรองรับ Web Bot Auth หรือคะแนนชื่อเสียงของ crawler และ Search Engine Roundtable ระบุว่าแนวคิดเรื่องคะแนนชื่อเสียงยังอยู่ในระยะแรก
• หน้าเอกสารยืนยันตัวตนของ Google ไม่ได้พูดถึงการดึงข้อมูลไปใช้กับ AI และอัปเดตล่าสุดเมื่อวันที่ 20 มีนาคม 2569 หลายเดือนก่อนที่ Search Engine Roundtable จะรายงานการสัมภาษณ์นี้

ความหมายสำหรับนักการตลาดไทย

ส่วนนี้เป็นบทวิเคราะห์ของ Relevant Audience ไม่ใช่คำแนะนำจาก Google สำหรับเว็บไซต์ธุรกิจไทยที่ใช้ shared hosting โฮสต์ WordPress แบบมีผู้ดูแล หรือแพลตฟอร์มอย่าง Shopify คำแนะนำของ Illyes ชี้ไปที่คำถามแรกข้อเดียว คือทราฟฟิกบอตสร้างปัญหาที่วัดได้จริงหรือไม่ สัญญาณที่ควรดูคือหน้าเว็บช้า แบนด์วิดท์เกินแพ็กเกจ หรือเซิร์ฟเวอร์ error ในช่วงเวลาเดียวกับที่ log แสดงการ crawl พุ่งสูง หากไม่มีปัญหาเหล่านี้ ระบบป้องกันที่แพลตฟอร์มมีให้อาจเพียงพอไปก่อน

สำหรับเว็บไซต์ที่เจอปัญหาโหลดจริง รายการที่ควรทำมีดังนี้

• ดึง log ของเซิร์ฟเวอร์ย้อนหลังหนึ่งสัปดาห์ แล้วรวบรวม IP address ที่ส่ง user-agent ของ Googlebot มา
• ยืนยันบางส่วนด้วยขั้นตอน reverse DNS และ forward DNS หรือเทียบทั้งหมดกับ common-crawlers.json
• บล็อกหรือจำกัดอัตราของ IP ที่ยืนยันไม่ผ่าน โดยทำที่ CDN หรือ WAF ไม่ใช่ใน robots.txt
• อนุญาตช่วง IP ของ Google ที่ยืนยันแล้วไว้เสมอ และอัปเดตไฟล์ JSON ตามรอบเวลา เพื่อให้กฎตรงกับรายการปัจจุบันของ Google
• หากกังวลเรื่องการนำเนื้อหาไปฝึก AI ให้ใช้ token Google-Extended สำหรับการใช้งาน AI ของ Google และจำไว้ว่า token นี้ไม่มีผลกับ crawler ที่ไม่สนใจ robots.txt

การเข้าถึงของ crawler ยังเกี่ยวกับการมองเห็นใน AI search ด้วย เว็บไซต์ที่บล็อก crawler ตัวจริงของ Google โดยไม่ตั้งใจจะเสียทั้ง Search และฟีเจอร์ที่สร้างอยู่บน Search ส่วน crawler ปลอมก็กินทรัพยากรเซิร์ฟเวอร์ที่ควรใช้รองรับลูกค้า บริการตรวจ SEO เชิงเทคนิคของ Relevant Audience ครอบคลุมการตรวจ log และการ crawl ส่วนบริการ GEOดูแลเรื่องที่ crawler ของ AI และคำตอบจาก AI ใช้เนื้อหาของเว็บไซต์อย่างไร และสำหรับงาน SEO ในภาพรวม ดูได้ที่บริการ SEO ในประเทศไทย

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

ทำไมทราฟฟิก Googlebot ปลอมจึงเพิ่มขึ้น

Gary Illyes บอกว่าเป็นเพราะ AI ในการพูดใน Odys Podcast ซึ่ง Search Engine Roundtable รายงานเมื่อวันที่ 30 ตุลาคม 2569 เขาบอกว่าบริษัทที่เก็บเนื้อหาไปฝึกโมเดลอ้างตัวเป็น Googlebot เพื่อให้เว็บไซต์ที่ปกติจะบล็อกยอมให้เข้า

จะตรวจได้อย่างไรว่าคำขอมาจาก Googlebot จริง

ทำ reverse DNS lookup กับ IP address แล้วตรวจว่าชื่อโฮสต์อยู่ใต้ googlebot.com, google.com หรือ googleusercontent.com จากนั้นทำ forward lookup กับชื่อโฮสต์นั้นและตรวจว่าได้ IP เดิม หากต้องตรวจจำนวนมาก Google แนะนำให้เทียบ IP กับไฟล์ JSON ที่เผยแพร่ไว้ เช่น common-crawlers.json สำหรับ Googlebot

robots.txt บล็อก Googlebot ปลอมได้ไหม

ไม่ได้ Illyes เรียก robots.txt ว่าเป็นคำขอที่ crawler ที่ถูกต้องมักทำตาม แต่บอตอื่นเพิกเฉยได้ หากต้องการบล็อกบอตที่ไม่ต้องการ เขาแนะนำการป้องกันระดับเครือข่าย เช่น web application firewall

เว็บไซต์ขนาดเล็กต้องทำอะไรหรือไม่

ไม่จำเป็น เว้นแต่ทราฟฟิกบอตสร้างปัญหาที่วัดได้จริง ตามคำแนะนำของ Illyes ที่ Search Engine Roundtable สรุปไว้ เขาเสนอให้เริ่มจาก CDN ที่มีระบบจัดการบอต และบอกว่าแพลตฟอร์มแบบโฮสต์ให้อย่าง Shopify มีระบบป้องกันอยู่แล้ว

Google รองรับ Web Bot Auth แล้วหรือยัง

แหล่งข่าวไม่ได้บอกว่ารองรับแล้ว Illyes พูดถึง Web Bot Auth ซึ่งใช้คำขอ HTTP ที่ลงลายเซ็นแบบเข้ารหัสและตรวจกับ public key ว่าเป็นทางหนึ่งที่จะทำให้การยืนยันตัวตนน่าเชื่อถือขึ้น แต่ไม่มีการรายงานวันเปิดใช้จาก Google

ข้อสรุปเชิงปฏิบัติมีข้อเดียว: user-agent เป็นเพียงคำกล่าวอ้าง ส่วน DNS และรายการ IP ที่ Google เผยแพร่คือวิธีตรวจว่าคำกล่าวอ้างนั้นจริงหรือไม่