Google ปรับเนื้อหาเอกสาร 'Optimize your crawl budget' ใหม่ การอัปเดตนี้จัดระเบียบถ้อยคำและคำศัพท์ให้ตรงกัน แต่ก็เพิ่มคำอธิบายที่เป็นสาระสำคัญหลายจุดเกี่ยวกับวิธีที่ Googlebot ตัดสินใจว่าจะเก็บข้อมูลมากแค่ไหน จุดที่เด่นที่สุดคือ ทุกเว็บไซต์ตอนนี้เริ่มต้นที่ลิมิตความจุการเก็บข้อมูล (crawl-capacity limit) แบบระมัดระวังที่เป็นค่าเริ่มต้นเหมือนกัน และระบบของ Google จะค่อยขยับลิมิตนี้ขึ้นเมื่อมีความต้องการเก็บข้อมูลและเว็บยังตอบสนองได้ดี Search Engine Roundtable เป็นผู้รายงานการแก้ไขนี้หลัง Google ปรับหน้าเอกสาร
ถ้าคุณดูแลเว็บขนาดใหญ่และกังวลว่า Google เก็บข้อมูลครบทุกหน้าหรือไม่ เรื่องนี้ควรอ่าน แต่ถ้าเป็นเว็บเล็ก คำตอบสั้นๆ คือ crawl budget ยังไม่ใช่สิ่งที่ต้องมานั่งจัดการ
ทุกเว็บเริ่มที่ลิมิตแบบระมัดระวังเท่ากัน
รายละเอียดใหม่ที่ชัดที่สุดคือเรื่องจุดเริ่มต้นของความจุ Google บอกว่าทุกเว็บเริ่มต้นที่ลิมิตความจุแบบระมัดระวังที่เป็นค่าเริ่มต้นเหมือนกัน จากนั้นระบบจะขยับลิมิตขึ้นเองเมื่อเข้าเงื่อนไขสองข้อ คือมีความต้องการเก็บข้อมูลเพิ่ม และเว็บยังตอบสนองได้ดีโดยไม่มีสัญญาณว่ารับภาระไม่ไหว
ในทางปฏิบัติแปลว่าเว็บใหม่หรือเว็บที่เพิ่งขยายหน้าจำนวนมากจะยังไม่ถูกเก็บข้อมูลเต็มที่ตั้งแต่วันแรก ความจุเป็นสิ่งที่ต้องสะสม เซิร์ฟเวอร์ที่ตอบเร็วและเสถียรทำให้ Google ยกเพดานขึ้น ส่วนเซิร์ฟเวอร์ที่ช้าลงหรือมี error จะทำให้เพดานอยู่ต่ำต่อไป
ความจุการเก็บข้อมูลแชร์ร่วมกันระหว่างบอตทุกตัวของ Google
อีกจุดที่มีน้ำหนักคือ ความจุการเก็บข้อมูลถูกแชร์ร่วมกันระหว่างบอตทุกตัวของ Google ไม่ได้แบ่งแยกเป็นรายบอต ดังนั้นถ้าบอตตัวหนึ่งดึงข้อมูลจากเว็บของคุณหนักมาก ความต้องการนั้นจะลดความจุที่เหลือให้บอตตัวอื่น
เรื่องนี้สำคัญกว่าที่ฟังครั้งแรก Google มีบอตหลายตัวนอกเหนือจาก Googlebot มาตรฐานสำหรับการค้นหา และทุกตัวดึงจากแหล่งเดียวกัน ยิ่งไปกว่านั้น หลักการเดียวกันใช้กับเซิร์ฟเวอร์ของคุณทั้งก้อน อะไรก็ตามที่ถล่มเซิร์ฟเวอร์อยู่ รวมถึงบอต AI และบอตของบุคคลที่สามที่ดึงข้อมูลหนัก ก็แย่งพื้นที่ตอบสนองก้อนเดียวกัน ถ้าเซิร์ฟเวอร์ต้นทางกำลังยุ่งกับการเสิร์ฟบอตอื่น Googlebot จะเห็นเซิร์ฟเวอร์ที่ช้าและยุ่ง แล้วกดอัตราการเก็บข้อมูลของตัวเองลง
ตอบเร็วขึ้นและ 304 caching ช่วยเรื่องประสิทธิภาพ
เอกสารที่ปรับใหม่ย้ำสองปัจจัยด้านประสิทธิภาพที่คุณควบคุมได้อยู่แล้ว
ความเร็วในการตอบของเซิร์ฟเวอร์
เซิร์ฟเวอร์ที่ตอบเร็วช่วยให้ Google ดึงข้อมูลได้มากขึ้นในช่วงเวลาเท่าเดิม การตอบช้าถูกอ่านว่าเป็นสัญญาณให้ถอย ซึ่งจำกัดว่าเว็บขนาดใหญ่จะถูกเก็บข้อมูลได้มากแค่ไหนในแต่ละช่วง
HTTP caching ด้วย 304
Google แนะนำให้ตั้ง HTTP caching ให้ถูกต้อง เพื่อให้หน้าที่ไม่มีการเปลี่ยนแปลงตอบกลับด้วย 304 Not Modified แทนที่จะส่งทั้งหน้า เมื่อ Googlebot ส่งคำขอแบบมีเงื่อนไขและเซิร์ฟเวอร์ตอบ 304 มันจะข้ามการดาวน์โหลดเนื้อหาที่ไม่เปลี่ยนซ้ำ ซึ่งช่วยปลดปล่อยความจุไปเก็บหน้าที่เปลี่ยนแปลงจริง สำหรับเว็บที่มีหน้าจำนวนมากและส่วนใหญ่นิ่ง การจัดการ 304 ให้ถูกต้องเป็นวิธีตรงๆ ที่ยืดงบ crawl เท่าเดิมให้ครอบคลุมมากขึ้น
เรื่องนี้กระทบใครจริงๆ
Crawl budget เป็นเรื่องของเว็บขนาดใหญ่ Google บอกมาหลายปีแล้วว่าเว็บส่วนใหญ่ไม่ต้องคิดเรื่องนี้ การอัปเดตครั้งนี้ก็ไม่ได้เปลี่ยนหลักนั้น
- เว็บขนาดใหญ่ ที่มี URL หลักแสนหลักล้าน หรือเว็บที่สร้างหน้าจำนวนมาก คือจุดที่ crawl budget จำกัดได้จริงว่ามีหน้าถูกค้นพบและอัปเดตมากแค่ไหน
- เว็บที่เปลี่ยนแปลงบ่อย เช่นสำนักข่าวใหญ่และมาร์เก็ตเพลส ที่การเก็บข้อมูลสดสำคัญต่อการทำให้หน้าใหม่เข้า index เร็ว
- เว็บเล็กถึงกลาง โดยทั่วไปจะไม่ชนลิมิต แค่เผยแพร่หน้าที่ดี ดูแลเซิร์ฟเวอร์ให้แข็งแรง และมี sitemap ที่สะอาดก็เพียงพอ
| สัญญาณ | ผลต่อความจุการเก็บข้อมูล |
|---|---|
| เซิร์ฟเวอร์ตอบเร็วและเสถียร | Google ขยับลิมิตขึ้นตามเวลา |
| ตอบช้าหรือมี error | ลิมิตอยู่ต่ำหรือลดลง |
| โหลดหนักจากบอตตัวอื่น | เหลือความจุให้ Googlebot น้อยลง |
| ตอบ 304 ถูกต้องบนหน้าที่ไม่เปลี่ยน | ใช้งบ crawl ไปกับหน้าที่เปลี่ยนจริง |
สิ่งที่นักการตลาดไทยควรรู้
สำหรับเว็บธุรกิจไทยส่วนใหญ่ เรื่องนี้ไม่ใช่เรื่องด่วน หน้าที่สำคัญก็ถูกเก็บข้อมูลอยู่แล้ว และควรทุ่มแรงไปที่เนื้อหาและลิงก์มากกว่ากลไกการ crawl
ภาพจะต่างออกไปสำหรับแคตตาล็อกอีคอมเมิร์ซไทยขนาดใหญ่ เว็บประกาศ และสำนักข่าวที่มีหน้าจำนวนมาก เว็บที่มี URL สินค้าหรือบทความหลายหมื่นถึงหลักแสน คือจุดที่ลิมิตเริ่มต้นแบบระมัดระวังและการแชร์ความจุอาจทำให้การ index ครบล่าช้า จุดที่ต้องจับตาคือเรื่องความจุที่แชร์กัน ถ้าบอต AI และบอตบุคคลที่สามถล่มเซิร์ฟเวอร์หนัก ก็จะกินพื้นที่ที่ Googlebot ต้องใช้ สำหรับเว็บกลุ่มนี้ ความเร็วเซิร์ฟเวอร์และ 304 caching ที่ถูกต้องไม่ใช่แค่ของแถม แต่เป็นส่วนหนึ่งของการทำให้แคตตาล็อกเข้า index ครบ เรื่องนี้ควรตรวจตอนทำ ตรวจสอบ SEO เชิงเทคนิค และควรคิดไว้ในการตัดสินใจเรื่องโฮสติ้งและ โครงสร้างเว็บไซต์ ก่อนที่แคตตาล็อกจะขยาย
คำถามที่พบบ่อย
นี่เป็นการอัปเดตอันดับหรือไม่
ไม่ใช่ เป็นการปรับเอกสารพร้อมคำอธิบายเรื่องการเก็บข้อมูล crawl budget มีผลต่อว่าเว็บถูกดึงข้อมูลมากแค่ไหน ไม่ใช่ว่าแต่ละหน้าติดอันดับอย่างไร
เว็บเล็กต้องทำอะไรไหม
ไม่ต้อง crawl budget เป็นเรื่องของเว็บขนาดใหญ่ เซิร์ฟเวอร์ที่แข็งแรงและ sitemap ที่สะอาดก็ครอบคลุมแล้ว
เว็บใหญ่ได้ผลเร็วสุดจากอะไร
ทำให้เซิร์ฟเวอร์ตอบเร็วขึ้นและตั้ง HTTP caching ให้หน้าที่ไม่เปลี่ยนตอบ 304 ทั้งสองอย่างช่วยให้งบ crawl เท่าเดิมครอบคลุมหน้าที่เปลี่ยนแปลงได้มากขึ้น
การแก้ไขครั้งนี้ไม่ได้ยื่นเครื่องมือใหม่ให้เว็บใหญ่ แต่อธิบายเครื่องมือที่มีอยู่แล้วให้ชัดขึ้น ถ้าเว็บของคุณใหญ่พอที่ crawl budget จะกัด สิ่งที่ต้องแก้คือประสิทธิภาพเซิร์ฟเวอร์และวินัยเรื่อง caching ถ้าอยากเห็นภาพชัดว่าประสิทธิภาพการ crawl รั่วตรงไหนบนแคตตาล็อกขนาดใหญ่ ทีมของเราช่วยได้ผ่าน บริการ SEO ในประเทศไทย
