Google เตือน: ย้ายเว็บไปใช้ CDN อาจทำให้ crawl พุ่งและบล็อก Googlebot

การย้ายเว็บไซต์ไปไว้หลัง CDN (Content Delivery Network) อาจทำให้ Google เข้ามาเก็บข้อมูลเว็บถี่ขึ้นในช่วงแรก ไม่ใช่น้อยลง Google อธิบายเรื่องนี้ในบล็อก Google Search Central ที่เผยแพร่เมื่อวันพุธที่ 11 พฤศจิกายน 2569 ว่าเมื่อเซิร์ฟเวอร์ปลายทาง (edge) ของ CDN ตอบสนองเร็ว ระบบ crawler ของ Google จะตีความว่าเว็บรับคำขอได้มากขึ้น แต่ CDN ที่เพิ่งเปิดใช้ยังไม่มีข้อมูลในแคช คำขอส่วนเกินจำนวนมากจึงวิ่งกลับไปที่เซิร์ฟเวอร์ต้นทาง (origin) อยู่ดี บทความเดียวกันยังเตือนว่าการเปิดระบบกันบอตแบบเหมารวมเพื่อหยุดทราฟฟิกที่พุ่งขึ้น อาจบล็อก Googlebot ไปด้วย และหน้าเว็บกับรายการสินค้าใน Shopping ที่ติดอยู่หลังหน้าท้าทายแบบ CAPTCHA จะเริ่มหลุดออกจาก Search

Google เผยแพร่อะไรเมื่อวันที่ 11 พฤศจิกายน 2569

บทความมีชื่อว่า "Moving to a CDN without overwhelming your origin (or blocking Googlebot)" โพสต์โดย Cherry และ Gary บน Google Search Central Blog เนื้อหานี้มาคู่กับตอนที่ 5 ของซีรีส์วิดีโอ The Non-Canonical Cabinet ซึ่ง Google ระบุว่าเป็นตอนจบของซีซัน 1 น้ำเสียงของบทความค่อนข้างขี้เล่น (ในวิดีโอใช้ไก่ยางแทนเซิร์ฟเวอร์ปลายทาง) แต่สาระคือคำอธิบายตรง ๆ ว่าระบบ crawl ของ Google ตอบสนองอย่างไรเมื่อเว็บเปลี่ยนโครงสร้างพื้นฐาน

Google เริ่มจากปัญหาที่บอกว่าได้ยินจากเจ้าของเว็บอยู่บ่อย ๆ คือ ทันทีที่ย้ายเว็บไปไว้หลัง CDN ทราฟฟิกจาก crawler ที่วิ่งเข้าเซิร์ฟเวอร์ของตัวเองกลับพุ่งขึ้นแทบจะทันที ซึ่งตรงข้ามกับสิ่งที่ตั้งใจแก้ จากนั้นบทความอธิบายว่าเกิดขึ้นเพราะอะไร ทำไมวิธีแก้ที่คนมักทำกลับทำให้แย่ลง และควรทำอะไรแทน โดยแนะนำให้อ่านเอกสารเดิมของ Google ประกอบสองชิ้น คือคู่มือเรื่อง crawl budget และคู่มือการลดอัตราการ crawl ของ Google ในกรณีฉุกเฉิน

ทำไมการ crawl จึงเร่งขึ้นหลังเปลี่ยนไปใช้ CDN

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

CDN เปลี่ยนสัญญาณเหล่านี้ได้ในทีเดียว เมื่อ DNS เริ่มชี้ไปที่เครือข่าย edge ที่เร็ว เวลาเชื่อมต่อและเวลาตอบสนองจะลดลงอย่างเห็นได้ชัด Google เปรียบว่าในสายตาของระบบ crawl มันดูเหมือนเซิร์ฟเวอร์เพิ่งได้อัปเกรดฮาร์ดแวร์ครั้งใหญ่ crawler จึงเริ่มเพิ่มจำนวนคำขอให้สอดคล้องกัน ทั้งที่เนื้อหาบนเว็บไม่ได้เปลี่ยนเลย สิ่งที่เปลี่ยนคือค่าที่ crawler ใช้ตัดสินใจ

มีเงื่อนไขสองข้อในบทความที่ควรจำไว้ ข้อแรก การเพิ่มขึ้นนี้ขึ้นกับ crawl demand การตอบเร็วขึ้นช่วยยกเพดาน แต่ไม่ได้ทำให้ Google อยากเก็บ URL ที่ไม่มีเหตุผลต้องเก็บ ข้อสอง Google บอกว่า crawler ไม่ได้เร่งอัตราการ crawl ขึ้นทันที และ CDN หลายรายมีระบบคุมจังหวะการเชื่อมต่อ (connection pacing) ในตัวที่ช่วยเกลี่ยทราฟฟิกที่พุ่งขึ้น ทราฟฟิกที่เพิ่มขึ้นจึงเกิดขึ้นจริง แต่ค่อยเป็นค่อยไป

ปัญหาแคชว่าง: เซิร์ฟเวอร์ต้นทางยังต้องทำงานหนัก

การ crawl ที่เร็วขึ้นจะไม่เป็นปัญหาเลยถ้า CDN ตอบทุกคำขอจาก edge ได้เอง แต่ช่วงแรกทำไม่ได้ Google ย้ำว่า CDN ที่เพิ่งเปิดใช้จะเริ่มต้นด้วยแคชที่ว่างเปล่า หรือที่เรียกว่า cold cache คำขอแรกสำหรับ URL ใด ๆ ที่ edge แต่ละจุดจะเป็น cache miss เซิร์ฟเวอร์ edge ต้องวิ่งกลับไปขอข้อมูลจากเซิร์ฟเวอร์ต้นทาง เก็บสำเนาที่แคชได้ไว้ แล้วจึงส่งให้ผู้ขอ ทั้งไฟล์ HTML, CSS, JavaScript และรูปภาพเป็นแบบนี้เหมือนกันหมด มีเพียงคำขอครั้งถัดไปสำหรับ URL เดิมเท่านั้นที่กลายเป็น cache hit และตอบจาก edge ได้โดยไม่ต้องรบกวนเซิร์ฟเวอร์ต้นทาง

ตรงนี้เองที่พฤติกรรมของคนกับ crawler ต่างกันมาก Google ชี้ว่าผู้เข้าชมที่เป็นคนมักกระจุกอยู่ที่หน้ายอดนิยมไม่กี่หน้า เช่น หน้าแรก บทความยอดนิยม หรือหน้าโปรโมชันที่กำลังจัดอยู่ หน้าเหล่านี้จึงเข้าแคชได้เร็ว แต่ crawler ทำตรงกันข้าม หน้าที่ของมันคือไล่สำรวจ URL ทั้งหมดของเว็บให้ครอบคลุม คำขอส่วนใหญ่ของ crawler จึงเป็น URL ที่ยังไม่เคยถูกแคชไว้ที่ edge นั้นเลย

เมื่อเอาสองพฤติกรรมนี้มารวมกัน ทราฟฟิกที่พุ่งขึ้นก็อธิบายได้ การตอบเร็วจาก edge บอก Google ว่า crawl เร็วขึ้นได้อย่างปลอดภัย และทุก URL ที่ยังไม่ถูกแคชซึ่ง crawler ไปถึงจะวิ่งทะลุไปที่เซิร์ฟเวอร์ต้นทางโดยตรง Google สรุปเองว่า ตราบใดที่แคชบน edge ยังไม่ถูกเติมให้พร้อม CDN ก็ยังไม่ได้ทำหน้าที่เป็นเกราะ และเซิร์ฟเวอร์ต้นทางยังต้องรับงานหนักอยู่ สำหรับเว็บที่มีแคตตาล็อกสินค้าขนาดใหญ่ หน้าหมวดหมู่ที่มีตัวกรองหลายแบบ หรือคลังบทความย้อนหลังจำนวนมาก ช่วงไม่กี่วันแรกหลังสลับระบบอาจมีทราฟฟิกวิ่งเข้าเซิร์ฟเวอร์ต้นทางสูงมาก

ระบบกันบอตแบบเหมารวมทำให้หน้าเว็บหลุดจาก Search ได้อย่างไร

ครึ่งหลังของบทความพูดถึงปฏิกิริยาที่ Google คาดว่าผู้ดูแลระบบที่กังวลจะทำ เมื่อเห็นคำขออัตโนมัติพุ่งขึ้นในล็อกของเซิร์ฟเวอร์ต้นทางหลังย้ายระบบ หลายคนอยากเข้าแดชบอร์ด CDN แล้วเปิดระบบกันบอตแบบเหมารวมทันที ข้อโต้แย้งของ Google อยู่ที่คำว่า "เหมารวม" นี่เอง เพราะถ้าไม่มีข้อยกเว้น กฎแบบนี้จะปฏิบัติต่อทราฟฟิกอัตโนมัติทุกประเภทเหมือนกันหมด รวมถึง crawler ที่เว็บต้องพึ่งพาด้วย

เมื่อ CDN หรือ Web Application Firewall (WAF) ตรวจพบคำขออัตโนมัติแล้วตอบกลับด้วยหน้าท้าทาย เช่น CAPTCHA crawler ของ Google จะผ่านด่านนั้นไม่ได้ บทความระบุว่าสิ่งนี้ทำให้ crawler ติดอยู่ที่หน้า error ซึ่งไม่มีประโยชน์ต่อ Search หรือผลิตภัณฑ์อื่นที่ใช้ข้อมูลจากการ crawl และในมุมของ Google เว็บไซต์จะดูเหมือนถูกจำกัดการเข้าถึงโดยเจตนาหรือเสียอยู่ ถ้าปล่อยการตั้งค่านี้ไว้ Google บอกว่า crawler จะถอยออก และหน้าเว็บกับรายการสินค้าใน Shopping ของเว็บนั้นจะเริ่มหลุดออกจาก Search

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

คำแนะนำของ Google ทีละข้อ

Google ปิดท้ายด้วยแผนการรับมือสั้น ๆ ตารางด้านล่างสรุปคำแนะนำแต่ละข้อตามที่บทความเขียนไว้ คู่กับรายละเอียดที่ Google ให้มา

ลำดับของคำแนะนำมีความหมาย การอุ่นแคชล่วงหน้าแก้ที่ต้นเหตุ เพราะแคชที่พร้อมแล้วจะรับคำขอของ crawler ไว้แทนเซิร์ฟเวอร์ต้นทาง การยกเว้นบอตที่ยืนยันแล้วช่วยให้ระบบป้องกันที่ยังจำเป็นต้องมีไม่ไปดักจับ Googlebot ส่วนรหัส 429 และ 503 เป็นทางเลือกฉุกเฉิน ซึ่ง Google วางไว้เป็นเบรกระยะสั้นตามคู่มือการลดอัตราการ crawl เร่งด่วน ไม่ใช่การตั้งค่าถาวร ขณะที่หน้า 403 หรือหน้าท้าทายสื่อความหมายต่างออกไป สำหรับ crawler มันดูเหมือนการปฏิเสธการเข้าถึง

Google ยังเสนอทางเลือกที่เบากว่าการบล็อกแบบเหมารวมด้วย แทนที่จะหยุดไคลเอนต์อัตโนมัติทุกตัว เว็บสามารถตั้งค่า robots.txt หรือเขียนกฎที่มุ่งไปที่บอตที่สร้างปัญหาจริงเป็นรายตัว วิธีนี้เก็บ crawler ที่ธุรกิจต้องการไว้ และกรองตัวที่ไม่ต้องการออกไป

สิ่งที่บทความไม่ได้บอก

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

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

เช็กลิสต์ก่อนและหลังสลับระบบ

ขั้นตอนด้านล่างแปลงคำแนะนำของ Google ให้เป็นสิ่งที่ทีมดูแลเว็บตรวจสอบได้จริง ทั้งหมดมาจากบทความและฟีเจอร์มาตรฐานของ Google Search Console ไม่ได้มาจากข้อมูลใหม่ใด ๆ

• ก่อนเปลี่ยน DNS ให้ทำรายการ URL ที่ต้องอุ่นแคช ได้แก่ หน้า landing ยอดนิยม หน้าสำหรับแคมเปญลดราคาหรือการเปิดตัวตามฤดูกาลครั้งถัดไป และ URL ที่ Googlebot ขอบ่อยที่สุด ซึ่งดูได้จากล็อกเซิร์ฟเวอร์หรือรายงาน Crawl Stats ใน Search Console
• ดึง URL ในรายการผ่าน CDN ด้วยจังหวะที่ควบคุมได้ เพื่อให้ cache miss รอบแรกเกิดขึ้นตามตารางเวลาของทีมเอง ไม่ใช่ตามจังหวะของ crawler
• ตรวจกฎจัดการบอต กฎจำกัดอัตรา และกฎหน้าท้าทายทุกข้อ ยืนยันว่าอนุญาตบอตที่ยืนยันแล้ว และตรวจเทียบกับช่วง IP ที่ Google เผยแพร่ แทนที่จะเชื่อแค่ user-agent ซึ่งใครก็ปลอมได้
• ในช่วงไม่กี่วันแรกหลังสลับระบบ ให้ดูล็อกของเซิร์ฟเวอร์ต้นทาง รวมถึงสถานะโฮสต์และเวลาตอบสนองเฉลี่ยในรายงาน Crawl Stats
• ถ้าเซิร์ฟเวอร์ต้นทางรับไม่ไหวจริง ให้ส่ง 429 หรือ 503 ให้ crawler เป็นหลักชั่วโมง ไม่ใช่หลักสัปดาห์ และถอดกฎออกเมื่อแคชพร้อมแล้ว
• สุ่มตรวจ URL สำคัญ รวมถึงหน้าสินค้า ด้วยเครื่องมือ URL Inspection เพื่อยืนยันว่า Google ได้รับหน้าเว็บจริง ไม่ใช่หน้าท้าทาย

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

สิ่งที่นักการตลาดไทยควรรู้

สำหรับร้านค้าออนไลน์และเว็บแบรนด์ในไทยที่ติดตั้ง CDN หรือไฟร์วอลล์ไม่นานก่อนช่วงขายใหญ่ เช่น 11.11, 12.12 หรือโปรโมชันปลายปี บทความของ Google อธิบายความเสี่ยงของการทำแบบรีบร้อนไว้ชัดเจน แคชยังว่างอยู่ในช่วงที่หน้าโปรโมชันต้องการมันที่สุด และการรีบเปิดระบบกันบอตแบบเข้มงวดอาจซ่อนหน้าสินค้าและรายการใน Shopping จาก Google ในสัปดาห์ที่สำคัญที่สุด ควรอุ่นแคชหน้าโปรโมชันไว้ก่อน ยกเว้น crawler ที่ยืนยันแล้วไว้เสมอ และใช้ 429 หรือ 503 เป็นมาตรการฉุกเฉินระยะสั้นเท่านั้น สำหรับร้านที่รายได้พึ่งพาการมองเห็นทั้งแบบออร์แกนิกและ Shopping เรื่องนี้ควรอยู่ในแผนเปิดแคมเปญควบคู่กับงานการตลาดอีคอมเมิร์ซ และอยู่ในการติดตามผลSEO ในประเทศไทยอย่างต่อเนื่องหลัง CDN เริ่มใช้งาน

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

ทำไม Googlebot ถึง crawl มากขึ้นหลังย้ายไปใช้ CDN

Googlebot crawl มากขึ้นเพราะการตอบสนองที่เร็วและสม่ำเสมอจาก edge ของ CDN ช่วยยก crawl capacity limit หรือ hostload ของ Google ให้สูงขึ้น Google บอกว่าการตอบที่เร็วขึ้นดูเหมือนเซิร์ฟเวอร์ได้อัปเกรดฮาร์ดแวร์ครั้งใหญ่ และถ้ามี crawl demand อยู่ crawler จะค่อย ๆ เพิ่มจำนวนคำขอให้สอดคล้องกัน

การเปิดระบบกันบอตใน CDN หรือไฟร์วอลล์ทำให้ SEO เสียหายได้ไหม

ได้ ระบบกันบอตแบบเหมารวมทำให้การมองเห็นใน Search ลดลงได้ถ้ามันส่งหน้าท้าทายให้ crawler ของ Google Google บอกว่า crawler ผ่านหน้าท้าทายแบบ CAPTCHA ไม่ได้ จะถอยออกถ้าการบล็อกยังอยู่ แล้วหน้าเว็บและรายการสินค้าใน Shopping จะเริ่มหลุดจาก Search Google จึงแนะนำให้อนุญาตบอตที่ยืนยันแล้วแทน

ควรส่ง 429 หรือ 503 เพื่อชะลอ Google ระหว่างย้ายระบบหรือไม่

ส่งได้เฉพาะช่วงสั้น ๆ และเฉพาะเมื่อเซิร์ฟเวอร์ต้นทางรับภาระหนักจนวิกฤตจริง บทความของ Google ระบุว่าไม่กี่ชั่วโมง หรืออย่างมาก 1-2 วัน ตามคู่มือการลดอัตราการ crawl เร่งด่วน และเตือนไม่ให้ใช้กำแพง 403 หรือหน้าท้าทายเพื่อจุดประสงค์เดียวกัน

ทำไมล็อกเซิร์ฟเวอร์ต้นทางยังยุ่ง ทั้งที่ CDN ควรช่วยปกป้องเซิร์ฟเวอร์

เพราะ CDN ที่เพิ่งเปิดใช้เริ่มต้นด้วยแคชว่าง คำขอแรกของทุก URL จึงเป็น cache miss ที่ต้องวิ่งกลับไปที่เซิร์ฟเวอร์ต้นทาง คนส่วนใหญ่เข้าชมแค่หน้ายอดนิยมไม่กี่หน้าที่เข้าแคชเร็ว แต่ crawler ขอ URL ทั้งเว็บ เซิร์ฟเวอร์ต้นทางจึงต้องรับภาระจนกว่าแคชจะเต็ม

คำแนะนำนี้ใช้กับเว็บไซต์ในประเทศไทยด้วยหรือไม่

ใช้ได้ บทความอธิบายพฤติกรรมของระบบ crawl ของ Google โดยทั่วไป ไม่ได้จำกัดเฉพาะประเทศใด และไม่ได้กล่าวถึงตลาด ผู้ให้บริการ หรือวันเปิดตัวใด ๆ เพราะเป็นการอธิบายพฤติกรรมที่มีอยู่แล้วของ crawler ไม่ใช่การประกาศฟีเจอร์ใหม่

CDN ยังเป็นการอัปเกรดที่สมเหตุสมผลสำหรับเว็บที่กำลังเติบโตส่วนใหญ่ สิ่งที่ควรนำไปใช้จากบทความของ Google วันที่ 11 พฤศจิกายน 2569 คือการวางแผนก่อนสลับระบบ อุ่นแคชก่อน ยกเว้น crawler ที่ยืนยันแล้ว และใช้เบรกฉุกเฉินให้สั้นที่สุด ถ้ามีกำหนดย้ายระบบก่อนช่วงขายใหญ่ Relevant Audience ช่วยทีมของคุณตรวจความเสี่ยงด้านการ crawl และการจัดทำดัชนีได้ก่อนเปลี่ยน DNS