Crawl Budget คืออะไร ทำไมเว็บใหญ่ต้องดูแล

Crawl Budget คืออะไร Google คำนวณงบคลานจากอะไร

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

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

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

Crawl Capacity Limit — เพดานที่เซิร์ฟเวอร์รับไหว

ปัจจัยแรกคือ crawl capacity limit หรือเพดานความเร็วในการยิงที่ Googlebot จะไม่ทำให้เว็บของเราล่ม Google จะค่อยๆ เพิ่มความถี่ขึ้นเรื่อยๆ ตราบใดที่เซิร์ฟเวอร์ยังตอบเร็วและไม่มี error แต่ทันทีที่เริ่มเจอ response time ที่ยืดออก หรือเจอสถานะ 5xx ติดกัน มันจะชะลอการเข้าเก็บลงทันทีเพื่อไม่ให้เว็บพัง

นี่คือเหตุผลว่าทำไมความเร็วเซิร์ฟเวอร์ถึงเกี่ยวกับ crawl budget โดยตรง หน้าที่โหลดเสร็จใน 200 มิลลิวินาที Googlebot เก็บได้หลายเท่าของหน้าที่ใช้เวลา 2 วินาทีในเวลาเท่ากัน โดยที่เราไม่ต้องไปขออะไรจาก Google เลย

Crawl Demand — Google อยากเก็บเว็บเรามากแค่ไหน

ปัจจัยที่สองคือ crawl demand หรือความต้องการฝั่ง Google ซึ่งดูจากความนิยมของ URL นั้น ความสดใหม่ของเนื้อหา และประวัติว่าหน้านั้นเคยเปลี่ยนบ่อยแค่ไหน หน้าที่มีลิงก์เข้าเยอะและอัปเดตสม่ำเสมอจะถูกกลับมาเก็บถี่กว่าหน้าที่ไม่เคยขยับมาหลายปี

ความต้องการนี้ยังลดลงได้ด้วยถ้า Google รู้สึกว่าเว็บมีคุณภาพต่ำโดยรวม เจอหน้าเนื้อหาบางหรือหน้าซ้ำจำนวนมาก มันจะเรียนรู้ว่าไล่เก็บไปก็ไม่ได้อะไรใหม่ แล้วลดความถี่ลงเองโดยไม่มีการแจ้งเตือนใดๆ ให้เราเห็น

ทำไมเว็บใหญ่ต้องดูแล Crawl Budget มากกว่าเว็บทั่วไป

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

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

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

รู้ได้ยังไงว่าเว็บมีปัญหา Crawl Budget

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

อีกจุดที่ควรดูคือรายงาน Crawl Stats ใน Search Console ซึ่งบอกจำนวนคำขอต่อวัน ขนาดข้อมูลที่ดาวน์โหลด และเวลาตอบสนองเฉลี่ยของเซิร์ฟเวอร์ ถ้าเห็นว่าจำนวนคำขอสูงมากแต่หน้าที่เข้า index กลับไม่ขยับ นั่นคือภาพชัดว่างบถูกใช้ไปแล้วแต่ใช้ไม่ตรงที่

รายงาน Pages ในส่วน Indexing ก็มีเบาะแสเยอะ ถ้าเห็นตัวเลขในกลุ่ม Discovered - currently not indexed พองขึ้นเรื่อยๆ แปลว่า Google รู้จัก URL เหล่านั้นแล้วแต่ตัดสินใจยังไม่เข้าไปเก็บ ซึ่งเป็นอาการคลาสสิกของเว็บที่มี URL มากเกินคุณภาพที่มีอยู่จริง

• หน้าใหม่ใช้เวลาหลายสัปดาห์กว่าจะขึ้น Google ทั้งที่เมื่อก่อนใช้เวลาไม่กี่วัน
• จำนวนหน้าใน index ห่างจากจำนวนหน้าจริงใน sitemap มาก และช่องว่างถ่างขึ้นเรื่อยๆ
• กลุ่ม Discovered - currently not indexed ใน Search Console โตต่อเนื่อง
• เวลาตอบสนองเฉลี่ยใน Crawl Stats ค่อยๆ สูงขึ้น สวนทางกับจำนวนคำขอที่ลดลง
• log เซิร์ฟเวอร์แสดงว่า Googlebot วนอยู่กับ URL ที่มี parameter หรือหน้าค้นหาภายในเว็บเป็นส่วนใหญ่
• เว็บมีหน้าที่ตอบ 404 หรือ 5xx จำนวนมากแต่ยังถูกบอทเข้าซ้ำเป็นประจำ

อ่าน Log เซิร์ฟเวอร์ยังไงให้เห็นว่า Googlebot เอางบไปลงที่ไหน

วิธีที่ตรงที่สุดคือดูจาก log ของเซิร์ฟเวอร์ เพราะมันบันทึกทุกคำขอที่เข้ามาจริง รวมถึงคำขอของ Googlebot ที่เครื่องมือ SEO ทั่วไปมองไม่เห็น การทำ log file analysis จะบอกได้ชัดว่าบอทเข้า URL ไหนบ้าง กี่ครั้ง และเจอสถานะอะไรกลับไป

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

อย่างที่สองคือดูสถานะที่บอทได้รับ ถ้าเจอ 301 เป็นสัดส่วนสูงแปลว่ามีลิงก์ภายในที่ยังชี้ไป URL เก่าอยู่ ถ้าเจอ 404 ซ้ำๆ ในหน้าเดิมแปลว่ายังมีลิงก์เสียค้างอยู่ในเว็บ และถ้าเจอ 5xx เป็นช่วงๆ ให้ตรวจภาระเซิร์ฟเวอร์ในช่วงเวลานั้นทันที เพราะ Google จะลดความถี่การเข้าเก็บให้เองหลังเจอแบบนี้

• ยืนยันตัวตน Googlebot ด้วยการ reverse DNS lookup ก่อนเสมอ เพราะมีบอทปลอมสวม user-agent จำนวนมาก
• เทียบ URL ที่บอทเข้าจริงกับ URL ใน sitemap เพื่อหาหน้าที่บอทไม่เคยแตะเลย
• แยกสถิติของ Googlebot Smartphone กับ Desktop ออกจากกัน เพราะเว็บส่วนใหญ่ถูกเก็บด้วยตัว Smartphone เป็นหลัก
• ดูช่วงเวลาที่บอทเข้าหนักที่สุดเทียบกับกราฟ response time เพื่อหาคอขวดของเซิร์ฟเวอร์
• ตั้งรอบตรวจเป็นรายเดือนสำหรับเว็บใหญ่ ไม่ใช่ตรวจครั้งเดียวตอนมีปัญหาแล้ว

วิธีดูแลและประหยัด Crawl Budget ที่ได้ผลจริง

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

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

และต้องยอมรับตั้งแต่ต้นว่างานนี้ไม่มีปุ่มเดียวจบ มันคือการไล่แก้หลายจุดที่ละจุดดูเล็กน้อย แต่รวมกันแล้วเปลี่ยนภาพการเก็บข้อมูลของทั้งเว็บได้จริง

• ตัดหรือรวมหน้าเนื้อหาบาง (thin page) ที่ไม่มีคนค้นและไม่มีคนเข้า แทนที่จะปล่อยค้างไว้เฉยๆ
• ทำ sitemap ให้สะอาด ใส่เฉพาะ URL ที่ตอบ 200 และตั้งใจให้ติดอันดับจริง ห้ามใส่หน้า redirect หรือ noindex ปนเข้าไป
• ตั้ง canonical ให้สอดคล้องกับ internal link และ sitemap ทั้งเว็บ ไม่ใช่ตั้งเฉพาะบรรทัดแท็ก
• ลดขนาดหน้าและจำนวนไฟล์ที่ต้องโหลด เพราะบอทต้องดาวน์โหลดทรัพยากรเหล่านั้นด้วย
• วาง internal link ให้หน้าสำคัญอยู่ห่างจากหน้าแรกไม่เกิน 3 คลิก หน้าที่ลึกกว่านั้นมักถูกเก็บช้ากว่ามาก
• ใช้ HTTP status ให้ถูกความหมาย หน้าที่เลิกใช้ถาวรควรตอบ 410 หรือ 404 จริงๆ ไม่ใช่เด้งกลับหน้าแรกทุกครั้ง

จัดการเนื้อหาซ้ำและ URL ที่มี parameter

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

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

ลด redirect chain และปิดทางเข้าหน้าที่ไม่จำเป็น

redirect chain คือการที่ URL หนึ่งเด้งไปอีก URL แล้วเด้งต่อไปอีกทอด แต่ละทอดกินคำขอของบอทหนึ่งครั้งเต็มๆ เว็บที่ผ่านการเปลี่ยนโครงสร้างมาหลายรอบมักมีเส้นทางเด้งสามสี่ทอดโดยไม่รู้ตัว วิธีแก้คือไล่แก้ปลายทางให้เหลือกระโดดเดียว และแก้ internal link ให้ชี้ไป URL ปลายทางสุดท้ายโดยตรง

ส่วน robots.txt ใช้กันบอทเข้าหน้าที่ไม่มีวันติดอันดับได้ เช่น หน้าค้นหาภายในเว็บ หน้าตะกร้าสินค้า หรือ URL ที่มี session id แต่ต้องเข้าใจให้ตรงว่า robots.txt กันการเข้าอ่าน ไม่ได้ทำให้หน้าหลุดจากผลค้นหา ถ้าต้องการให้หน้าหลุดออกจาก Google ต้องใช้ noindex และห้ามบล็อกหน้านั้นใน robots.txt พร้อมกัน เพราะบอทจะอ่านคำสั่ง noindex ไม่เจอ เรื่องนี้อธิบายละเอียดไว้ใน sitemap กับ robots.txt ต่างกันยังไง

เร่ง server response time ให้บอทเก็บได้มากขึ้นในเวลาเท่าเดิม

เพราะเพดานฝั่งความสามารถวัดจากเวลาที่เซิร์ฟเวอร์ตอบกลับเป็นหลัก การลด time to first byte จึงเป็นวิธีเพิ่มปริมาณการเก็บที่ตรงที่สุด แนวทางพื้นฐานคือใส่ระบบแคชฝั่งเซิร์ฟเวอร์ ใช้ CDN สำหรับไฟล์ static ปรับ query ฐานข้อมูลที่ช้า และตรวจว่าไม่มีปลั๊กอินตัวไหนถ่วงทุกคำขอ

ข้อควรระวังคืออย่าสับสนระหว่างความเร็วฝั่งผู้ใช้กับความเร็วที่บอทเจอ คะแนนความเร็วหน้าเว็บที่ดีไม่ได้แปลว่า response time ของเซิร์ฟเวอร์ดีเสมอไป ให้ดูตัวเลข Average response time ใน Crawl Stats ควบคู่กันด้วย เพราะนั่นคือค่าที่ Googlebot เจอจริง

Crawl Budget สำคัญกับเว็บเล็กไหม ต้องกังวลแค่ไหน

ตอบตรงๆ คือ เว็บที่มี URL ไม่กี่พันหน้าแทบไม่ต้องกังวลเรื่อง crawl budget เลย Google เองก็ระบุไว้ว่าเว็บส่วนใหญ่ไม่จำเป็นต้องจัดการเรื่องนี้ เพราะถ้าเว็บมีหน้าไม่กี่ร้อยหน้า Googlebot เก็บครบได้สบายภายในเวลาไม่นานอยู่แล้ว

ถ้าเว็บเล็กแล้วหน้าไม่เข้า index สาเหตุมักไม่ใช่งบคลาน แต่เป็นเรื่องคุณภาพหรือการตั้งค่า เช่น เนื้อหาบางเกินไป ซ้ำกับหน้าอื่นในเว็บเอง ไม่มี internal link ชี้เข้าเลย ตั้ง noindex ค้างไว้ตั้งแต่ตอนทำเว็บ หรือถูกบล็อกใน robots.txt โดยไม่ตั้งใจ การไปไล่ปรับ crawl budget ในสถานการณ์แบบนี้คือแก้ผิดจุดและเสียเวลาเปล่า

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

ความเข้าใจผิดเรื่อง Crawl Budget ที่เจอบ่อย

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

อีกเรื่องที่เข้าใจผิดกันบ่อยคือคิดว่าใส่ค่า crawl-delay ใน robots.txt แล้ว Google จะทำตาม ความจริงคือ Googlebot ไม่รองรับคำสั่งนี้ (บอทของเสิร์ชเอนจินอื่นบางตัวรองรับ) ถ้าอยากให้ Google เข้าเบาลงจริงๆ ต้องปรับที่ฝั่งเซิร์ฟเวอร์หรือใช้ช่องทางรายงานปัญหาของ Search Console ไม่ใช่ตั้งค่าในไฟล์ robots.txt

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

• งบคลานสูงไม่ได้แปลว่าอันดับจะดี และงบคลานต่ำก็ไม่ได้แปลว่าเว็บถูกลงโทษ
• Googlebot ไม่รองรับ crawl-delay ใน robots.txt
• การส่ง URL ผ่าน URL Inspection ทีละหน้าเป็นทางลัดชั่วคราว ไม่ใช่วิธีแก้ปัญหาเชิงโครงสร้าง
• การบล็อกหน้าใน robots.txt ทำให้ประหยัดงบคลานได้ก็จริง แต่ไม่ได้ลบหน้านั้นออกจากผลค้นหา
• เพิ่มความถี่โพสต์บทความโดยไม่ปรับพื้นฐานทางเทคนิค มักทำให้ URL ค้างคิวมากขึ้นแทนที่จะดีขึ้น

สรุปและลำดับงานที่ควรทำก่อน

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

ถ้าจะเริ่มวันนี้ ให้ไล่ตามลำดับนี้ เช็กก่อนว่าเว็บใหญ่พอที่จะมีปัญหาจริงไหม แล้วดู Crawl Stats กับรายงาน Pages ใน Search Console ต่อด้วยการหาว่า URL ประเภทไหนกินคำขอมากที่สุด ปิดต้นทางที่ผลิต URL ซ้ำ ล้าง sitemap ให้เหลือแต่ของจริง แก้ redirect chain แล้วค่อยไปเร่งความเร็วเซิร์ฟเวอร์เป็นงานต่อเนื่อง

ถ้าเว็บมีหน้าเยอะจนไล่ดูเองไม่ไหว หรือดูแล้วยังไม่แน่ใจว่าคอขวดอยู่ตรงไหน การทำ SEO Audit เพื่อไล่ดู log และโครงสร้าง URL ทั้งระบบก่อนลงมือแก้ จะช่วยให้แก้ถูกจุดกว่าการเดาทีละอย่าง