สรุปสั้น ๆ (TL;DR)
- Google นิยามเว็บไซต์ว่าเป็นโฮสต์เนมหนึ่งชื่อ ซับโดเมนอย่าง th.example.com หรือ shop.example.com จึงมี crawl budget แยกเป็นของตัวเอง
- เกณฑ์คร่าวๆ ของ Google: crawl budget สำคัญกับเว็บที่มีเกิน 1 ล้านหน้าและเปลี่ยนรายสัปดาห์ เว็บเกิน 10,000 หน้าที่เปลี่ยนทุกวัน หรือเว็บที่มี URL สถานะ 'Discovered - currently not indexed' จำนวนมาก
- noindex ไม่ได้ช่วยประหยัดการ crawl เพราะ Google ต้องดึงหน้าก่อนจึงจะอ่านแท็กได้ robots.txt ป้องกันการดึง ส่วน 404 หรือ 410 คือสัญญาณสำหรับหน้าที่ลบถาวร
- การตอบ 500, 503 หรือ 429 ทำให้ Googlebot ชะลอทั้งโฮสต์ แต่ Google แนะนำให้ทำแค่ไม่กี่ชั่วโมงหรือ 1-2 วัน ไม่อย่างนั้น URL อาจหลุดจาก index
- รายงาน Crawl Stats อยู่ใต้ Settings ใน Search Console และใช้ได้เฉพาะ Domain property หรือ URL-prefix property ระดับ root
Crawl budget คือชุด URL บนโฮสต์เนมหนึ่งที่ Googlebot สามารถ crawl ได้และต้องการ crawl ในช่วงเวลาหนึ่ง โดยถูกกำหนดจากสองส่วน คือ crawl capacity limit (เซิร์ฟเวอร์ของคุณรับการดึงข้อมูลได้มากแค่ไหน) และ crawl demand (Google อยากดึงข้อมูลมากแค่ไหน) เว็บไซต์ส่วนใหญ่ไม่เคยใช้ crawl budget จนหมด คำแนะนำของ Google เองมุ่งไปที่เว็บไซต์ขนาดใหญ่มาก เว็บไซต์ที่เนื้อหาเปลี่ยนทุกวัน และเว็บไซต์ที่มี URL จำนวนมากค้างอยู่ในสถานะ "Discovered - currently not indexed" ใน Search Console
บทความนี้อธิบายว่า Google นิยามสองส่วนของ crawl budget อย่างไร วิธีดูว่าเว็บไซต์ของคุณเป็นหนึ่งในกลุ่มเล็กๆ ที่ต้องใส่ใจหรือไม่ วิธีอ่านรายงาน Crawl Stats สิ่งที่ทำให้การ crawl สูญเปล่าโดยไม่รู้ตัว และเครื่องมือควบคุมแบบไหน (robots.txt, noindex, status code, sitemap) ที่เปลี่ยนพฤติกรรมของ Googlebot ได้จริง ทุกอย่างอิงตามเอกสารเรื่องการ crawl ของ Google ณ เดือนตุลาคม 2569
Crawl budget คืออะไรกันแน่
Google มองว่า "เว็บไซต์" หนึ่งเว็บคือโฮสต์เนมหนึ่งชื่อ ผลคือ www.example.com, shop.example.com และ blog.example.com ต่างก็มี crawl budget ของตัวเอง การย้ายส่วนหนึ่งของเว็บไปไว้บนซับโดเมนจึงไม่ได้ยืม budget จากโฮสต์หลัก
ภายในโฮสต์เนมเดียว crawl budget มาจากสองเรื่องที่แยกกัน
Crawl capacity limit
Crawl capacity limit (Google เรียกอีกชื่อว่า hostload) เป็นเรื่องของเซิร์ฟเวอร์ของคุณ ค่านี้จำกัดเวลารวมที่เซิร์ฟเวอร์ของคุณต้องเปิดการเชื่อมต่อค้างไว้ให้ Google เพื่อไม่ให้การ crawl ทำให้เว็บล่ม มีสองปัจจัยที่ทำให้ค่านี้ขยับ
- สุขภาพการ crawl ถ้าเวลาตอบสนองคงที่หรือดีขึ้น รวมถึง latency ลิมิตจะสูงขึ้น ถ้าเว็บช้าลง ตอบกลับด้วย server error กลุ่ม 5xx หรือส่งสัญญาณจำกัดอัตราอย่าง HTTP 429 ลิมิตจะลดลง
- ขีดจำกัดของ Google เอง Google มีทรัพยากรในการ crawl จำกัดและต้องแบ่งให้ทั้งเว็บ จึงมีเพดานอยู่เสมอไม่ว่าเซิร์ฟเวอร์ของคุณจะเร็วแค่ไหน
ปัจจุบันเอกสารของ Google ระบุว่าทุกเว็บไซต์เริ่มต้นที่ capacity limit ค่าเริ่มต้นเดียวกันแบบระมัดระวัง และลิมิตจะเพิ่มขึ้นเองเมื่อเวลาผ่านไปก็ต่อเมื่อมีความต้องการจะ crawl มากขึ้นและเว็บยังตอบสนองได้ดี เอกสารยังบอกว่า capacity นี้ใช้ร่วมกันโดย crawler ทุกตัวของ Google บนโฮสต์นั้น ดังนั้นถ้า crawler ตัวหนึ่งดึงข้อมูลหนัก (เอกสารยกตัวอย่าง AdsBot) พื้นที่ที่เหลือให้ตัวอื่นก็จะน้อยลง
Crawl demand
Crawl demand คือ Google อยากดึงข้อมูลมากแค่ไหน สำหรับ Googlebot ขึ้นอยู่กับขนาดเว็บ ความถี่ที่เนื้อหาเปลี่ยน คุณภาพของหน้า และความเกี่ยวข้อง ส่วนที่คุณมีอิทธิพลได้มากที่สุดคือ
- Perceived inventory คือ URL ทั้งหมดที่ Google รู้จัก รวมถึง URL ซ้ำและ URL ที่คุณไม่เคยตั้งใจเปิดให้เห็น ถ้า Google คิดว่าเว็บของคุณมีสิบล้าน URL ทั้งที่มีแค่สองแสน URL ที่มีความหมาย Google ก็จะเสียเวลากับ URL ที่ไม่สำคัญ
- ความนิยม URL ที่ได้รับความนิยมมากกว่ามักถูก crawl บ่อยกว่า
- ความเก่าของข้อมูล Google กลับมา crawl ซ้ำเพื่อเก็บการเปลี่ยนแปลง หน้าที่เปลี่ยนบ่อยจึงถูกกลับมาเยี่ยมบ่อย
เหตุการณ์ระดับทั้งเว็บ เช่น การย้ายโดเมน อาจทำให้ demand สูงขึ้นชั่วคราว เพราะ Google ต้องดึงข้อมูลทุกอย่างใหม่ที่ที่อยู่ใหม่
เมื่อรวมกันแล้ว crawl budget คือส่วนที่ซ้อนทับกัน ได้แก่ URL ที่ Google crawl ได้ภายใต้ capacity limit และอยากจะ crawl ตาม demand เซิร์ฟเวอร์ที่เร็วไม่ได้สร้างการ crawl ขึ้นมาเอง ถ้า demand ต่ำ Google ก็จะ crawl น้อยลงแม้ capacity limit ยังห่างไกลจากเพดาน
เว็บไซต์แบบไหนที่ต้องใส่ใจจริงๆ
คู่มือ crawl budget ของ Google ระบุว่าเขียนขึ้นสำหรับกรณีขั้นสูง และให้ตัวเลขขนาดคร่าวๆ โดยย้ำว่าเป็นการประมาณ ไม่ใช่เกณฑ์ตายตัว
- เว็บไซต์ขนาดใหญ่ที่มีหน้าไม่ซ้ำกันมากกว่า 1 ล้านหน้า และเนื้อหาเปลี่ยนในระดับปานกลาง ประมาณสัปดาห์ละครั้ง
- เว็บไซต์ขนาดกลางขึ้นไปที่มีหน้าไม่ซ้ำกันมากกว่า 10,000 หน้า และเนื้อหาเปลี่ยนเร็วมาก ทุกวัน
- เว็บไซต์ที่ URL สัดส่วนใหญ่อยู่ในรายงาน Page Indexing ด้วยสถานะ "Discovered - currently not indexed"
ถ้าไม่มีข้อไหนตรงกับคุณ หรือหน้าใหม่ของคุณมักถูก crawl ในวันเดียวกับที่เผยแพร่ คำแนะนำของ Google คือแค่ดูแล sitemap ให้เป็นปัจจุบันและเปิดดูรายงาน Page Indexing เป็นระยะ เว็บไซต์บริษัท 300 หน้า หรือร้านค้าออนไลน์ 2,000 สินค้าที่มีโครงสร้าง URL สมเหตุสมผล จะไม่ใช้ crawl budget จนหมด เวลาที่ใช้ "ปรับแต่ง" มันควรเอาไปทำเนื้อหาและลิงก์จะคุ้มกว่า
เว็บไซต์ที่ชนเพดานจริงมักมีรูปแบบเดียวกัน คือมีหน้าจริงจำนวนไม่มาก แต่ถูกคูณเป็น URL ที่ crawl ได้จำนวนมหาศาลผ่านตัวกรอง ลำดับการเรียง พารามิเตอร์ session ผลการค้นหาภายในเว็บ หรือหน้าปฏิทิน ร้านค้าออนไลน์ที่มี 40,000 สินค้าอาจเปิด URL ได้หลายล้าน URL ถ้าทุกการผสมของสี ไซซ์ แบรนด์ ช่วงราคา และลำดับการเรียง มีลิงก์ที่ crawl ได้เป็นของตัวเอง
วิธีอ่านรายงาน Crawl Stats
รายงาน Crawl Stats อยู่ใต้ Settings (ไอคอนรูปเฟือง) ใน Search Console ไม่ได้อยู่ในเมนูหลัก และใช้ได้เฉพาะ property ระดับ root คือ Domain property หรือ URL-prefix property ที่ระดับ root เช่น https://example.com ถ้าเป็น property ของโฟลเดอร์ย่อยจะไม่เห็นรายงานนี้
กราฟด้านบนมีสามเส้น
- Total crawl requests คือทุกคำขอที่ Google ส่งมายัง URL บนเว็บของคุณในช่วงเวลานั้น ทั้งที่สำเร็จและไม่สำเร็จ
- Total download size คือจำนวนไบต์ที่ดาวน์โหลดระหว่างการ crawl
- Average response time คือเวลาตอบสนองเฉลี่ยของทุกอย่างที่ดึงไป โดยนับ resource ของแต่ละหน้าแยกกัน
ด้านล่างมีการแยกย่อยสี่แบบ ควรอ่านตามลำดับนี้
- ตาม response คำตอบส่วนใหญ่ควรเป็น 200 ถ้าสัดส่วนของ 301/302, 404 หรือ 5xx เพิ่มขึ้น แปลว่าคำขอกำลังไปลงที่สิ่งที่ไม่ได้ให้เนื้อหาที่ index ได้
- ตามวัตถุประสงค์ "Discovery" คือ URL ที่ Google ไม่เคย crawl มาก่อน ส่วน "Refresh" คือการ crawl ซ้ำ URL ที่รู้จักแล้ว ในเว็บที่เผยแพร่หน้าใหม่ทุกวัน ถ้าสัดส่วน discovery ต่ำมาก อาจหมายความว่า Google ยุ่งอยู่กับการ crawl URL เก่าแทนที่จะไปหา URL ใหม่
- ตามประเภทไฟล์ เช่น HTML, รูปภาพ, JavaScript, CSS, PDF และอื่นๆ วัดเป็นสัดส่วนของ response เว็บที่คำขอ JavaScript และ JSON มีมากกว่า HTML หลายเท่า อาจกำลังใช้ capacity ไปกับ resource มากกว่าตัวหน้า
- ตามประเภท Googlebot เช่น Smartphone, Desktop, Image, Video, Page resource load, AdsBot, StoreBot และ agent อื่นๆ เพราะ capacity ใช้ร่วมกัน ร้านค้าที่ลงโฆษณาจำนวนมากแล้วเห็นสัดส่วน AdsBot สูงจึงควรสังเกตไว้
แผง host status ครอบคลุมการดึง robots.txt, การ resolve DNS และการเชื่อมต่อเซิร์ฟเวอร์ ย้อนหลัง 90 วัน มีสามสถานะ ได้แก่ ไม่มีปัญหาการเข้าถึงที่สำคัญ, มีปัญหาบ้างแต่ไม่ใช่ช่วงหลัง และมีปัญหาเมื่อเร็วๆ นี้ (ภายในสัปดาห์ที่ผ่านมา) กราฟของแต่ละหมวดมีเส้นเกณฑ์สีแดง ตัวอย่างของ Google คือ DNS ล้มเหลวเกิน 5% ของคำขอในวันหนึ่ง เป้าหมายคือสถานะสีเขียว ถ้าดึง robots.txt ไม่ได้ (ได้ response 429 หรือ 5xx) Google จะชะลอหรือหยุด crawl จนกว่าจะดึง robots.txt ได้ตามปกติ robots.txt ที่ไม่เสถียรจึงเป็นวิธีที่เร็วที่สุดวิธีหนึ่งในการเสียการ crawl ทั้งโฮสต์
ลองคลิกเข้าไปในแถวใดก็ได้ของการแยกย่อยเพื่อดูตัวอย่าง URL ตัวอย่างเหล่านี้คือที่ที่คุณจะเจอรูปแบบพารามิเตอร์ การ redirect หลายทอด และ soft 404 ที่อธิบายไว้ด้านล่าง
อะไรทำให้ crawl budget สูญเปล่า
ความสูญเปล่าคืออะไรก็ตามที่ทำให้ Google ไปดึง URL ที่จะไม่มีวันกลายเป็นผลการค้นหาที่มีประโยชน์ ตัวการที่พบบ่อยมีดังนี้
Faceted navigation และพารามิเตอร์ใน URL
ลิงก์ตัวกรองและลิงก์เรียงลำดับสร้าง URL ได้แทบไม่สิ้นสุด ซึ่งแสดงสินค้าชุดเดิมในลำดับต่างกัน ทุก URL คือการดึงข้อมูลหนึ่งครั้ง คำแนะนำของ Google คือรวมเนื้อหาซ้ำเข้าด้วยกัน และบล็อก URL ที่คุณไม่ต้องการให้ crawl เลย สำหรับ facet มักหมายถึงการตัดสินใจว่าการผสมตัวกรองแบบไหนควรเป็น landing page จริง (เช่น "รองเท้าวิ่ง / ผู้หญิง / Nike") แล้วไม่สร้างลิงก์ที่ crawl ได้สำหรับส่วนที่เหลือ หรือบล็อกไว้ใน robots.txt
Redirect chain
Google ระบุว่า redirect chain ที่ยาวส่งผลเสียต่อการ crawl ลิงก์ที่วิ่งจาก http ไป https แล้วไป www แล้วไปเวอร์ชันที่มี trailing slash แล้วไป URL ที่เปลี่ยนชื่อ ต้องใช้สี่ครั้งเพื่อไปถึงหน้าเดียว ควรแก้ลิงก์ภายในให้ชี้ไปที่ URL สุดท้ายโดยตรง และยุบ chain ให้เหลือทอดเดียว
Soft 404
Soft 404 คือหน้าที่บอกว่า "ไม่พบ" หรือ "สินค้าหมด ไม่มีอะไรตรงนี้" แต่ตอบกลับเป็น HTTP 200 Google บอกว่าหน้าแบบนี้ถูก crawl ซ้ำเรื่อยๆ และทำให้ budget สูญเปล่า รายงาน Page Indexing จะแสดงรายการเหล่านี้ ควรตอบกลับเป็น 404 หรือ 410 จริงสำหรับหน้าที่ไม่มีแล้ว และตรวจให้แน่ใจว่าหน้าหมวดหมู่หรือหน้าผลค้นหาที่ว่างเปล่าไม่ได้ตอบ 200 พร้อมเทมเพลตเปล่า
หน้าซ้ำและหน้าที่เกือบซ้ำ
เวอร์ชันสำหรับพิมพ์ พารามิเตอร์ติดตาม URL ที่ตัวพิมพ์เล็กใหญ่ปนกัน และสินค้าชิ้นเดียวกันที่เข้าถึงได้จากหลายเส้นทางหมวดหมู่ ล้วนทำให้ perceived inventory พองขึ้น แท็ก canonical ช่วยให้ Google เลือกเวอร์ชันที่จะ index ได้ แต่ Google อาจยัง crawl หน้าซ้ำที่หาเจอ วิธีแก้ที่สะอาดกว่าคือเลิกลิงก์ไปหาหน้าเหล่านั้น
หน้าที่ช้าและ resource ที่หนัก
เพราะ capacity limit วัดจากเวลาการเชื่อมต่อ response ที่ช้าจึงหมายถึงการดึงข้อมูลที่น้อยลงในช่วงเวลาเท่าเดิม Google แนะนำให้ปรับเวลาตอบสนองของเซิร์ฟเวอร์ และรองรับ response 304 (Not Modified) เพื่อไม่ต้องดาวน์โหลดเนื้อหาที่ไม่เปลี่ยนซ้ำอีก
Robots.txt กับ noindex ในการควบคุมการ crawl
เครื่องมือสองตัวนี้ทำงานต่างกัน
- robots.txt หยุดไม่ให้ Google crawl URL นั้น Google ระบุว่าการบล็อกยังลดโอกาสที่ URL จะถูกประมวลผลโดยระบบอื่นของ Google ลงมาก นี่คือเครื่องมือที่ถูกต้องสำหรับ URL ที่คุณไม่ต้องการให้ crawl เลย เช่น หน้าผลค้นหาภายในเว็บ หรือการผสมตัวกรองที่ไม่สิ้นสุด
- noindex ไม่ได้ช่วยประหยัดการ crawl Google ต้องขอหน้านั้นก่อนจึงจะเห็นแท็ก แล้วค่อยเอาออกจาก index การใช้ noindex เพื่อจัดการ crawl budget จึงเปลืองการดึงข้อมูลที่คุณพยายามประหยัดอยู่
คู่มือของ Google ยังมีอีกสองจุดที่มักถูกมองข้าม ข้อแรก อย่าใช้ robots.txt เพื่อ "ปลดปล่อย" budget ชั่วคราวให้หน้าอื่น เพราะ Google จะย้าย budget แบบนั้นก็ต่อเมื่อเว็บชนเพดาน capacity อยู่แล้วเท่านั้น ข้อสอง อย่าใช้ robots.txt กับหน้าที่ถูกลบถาวร URL ที่ถูกบล็อกจะค้างอยู่ในคิว crawl นานกว่า และจะถูก crawl อีกครั้งเมื่อยกเลิกการบล็อก สัญญาณที่สะอาดคือ 404 หรือ 410
และถ้าเซิร์ฟเวอร์กำลังรับภาระไม่ไหวในตอนนี้ คำแนะนำแยกของ Google เรื่องการลดอัตราการ crawl บอกให้ตอบกลับด้วย 500, 503 หรือ 429 ในช่วงสั้นๆ (สองสามชั่วโมง หรือหนึ่งถึงสองวันเป็นอย่างมาก) ถ้าใช้ 503 หรือ 429 จะใส่ header Retry-After ด้วยก็ได้ ถ้าปล่อยไว้นานกว่านั้น URL ที่ตอบด้วยโค้ดเหล่านี้ต่อเนื่องอาจหลุดออกจาก index การชะลอนี้มีผลกับทั้งโฮสต์เนม และจะกลับมาเองเมื่อ error หยุด
Sitemap และ lastmod
XML sitemap ไม่ได้เพิ่ม capacity limit ของคุณ แต่มีผลต่อ demand Google ขอให้เจ้าของเว็บดูแล sitemap ให้เป็นปัจจุบัน ใส่เนื้อหาทั้งหมดที่ต้องการให้ crawl และใส่แท็ก lastmod สำหรับเนื้อหาที่อัปเดต มีสองกฎที่ทำให้ lastmod น่าเชื่อถือ
- ตั้งค่าเฉพาะเมื่อเนื้อหาหลักเปลี่ยน ไม่ใช่ทุกครั้งที่ build หน้า หรือเมื่อ widget ข้างหน้ารีเฟรช lastmod ที่เปลี่ยนทุกวันในทุก URL จะทำให้ Google เลิกเชื่อค่านี้
- อย่าให้มี URL ที่ redirect, ติด noindex, ถูกบล็อก หรือ 404 อยู่ใน sitemap sitemap คือรายการหน้า canonical ที่ index ได้ อย่างอื่นคือเสียงรบกวนในคิว
สำหรับเว็บขนาดใหญ่ ให้แยก sitemap ตามส่วนหรือประเภทเนื้อหา (สินค้า หมวดหมู่ บทความ) Search Console จะรายงานการ index แยกตามไฟล์ ทำให้เห็นว่าส่วนไหนมีปัญหา "Discovered - currently not indexed"
สรุปปัญหา crawl budget และวิธีแก้
| อาการ | สาเหตุที่น่าจะเป็น | วิธีแก้ตามคำแนะนำของ Google |
|---|---|---|
| ตัวอย่าง URL ใน Crawl Stats เต็มไปด้วยพารามิเตอร์นับล้าน | Faceted navigation และลิงก์เรียงลำดับ | รวมหน้าซ้ำ บล็อก URL ที่ไม่ต้องการเลยใน robots.txt |
| response 301/302 จำนวนมาก | Redirect chain ในลิงก์ภายใน | ลิงก์ไปที่ URL สุดท้าย ยุบ chain ให้เหลือทอดเดียว |
| มีรายการ soft 404 ใน Page Indexing | หน้าว่างที่ตอบ 200 | ตอบ 404 หรือ 410 สำหรับเนื้อหาที่ลบแล้ว |
| คำขอ crawl ลดลง เวลาตอบสนองเพิ่มขึ้น | เซิร์ฟเวอร์รับภาระหนักจน capacity limit ลด | response เร็วขึ้น เพิ่มทรัพยากรเซิร์ฟเวอร์ รองรับ 304 |
| ใส่ noindex "เพื่อประหยัด budget" | noindex ยังต้องดึงหน้าก่อน | ใช้ robots.txt กับ URL ที่ไม่ควรถูก crawl เลย |
ตัวอย่างการคำนวณ (ตัวเลขสมมติ)
ลองนึกถึงร้านแฟชั่นออนไลน์ที่มีสินค้าที่ขายอยู่ 25,000 ชิ้นและหน้าหมวดหมู่ 600 หน้า แต่ละหมวดมีตัวกรองไซซ์ สี แบรนด์ และราคา บวกการเรียงลำดับอีกสี่แบบ ทั้งหมดเป็นลิงก์ที่ crawl ได้ บนกระดาษร้านนี้มีราว 26,000 หน้าที่ควร index แต่ในทางปฏิบัติ Googlebot อาจค้นพบ URL ตัวกรองได้หลายแสน URL Crawl Stats แสดงว่าคำขอส่วนใหญ่เป็น "Refresh" ตัวอย่าง URL เต็มไปด้วย ?sort= และ &color= ส่วนรายงาน Page Indexing แสดงว่าสินค้าใหม่ค้างอยู่ใน "Discovered - currently not indexed" เป็นสัปดาห์
ลำดับการแก้คือ ตัดสินใจว่าหน้าตัวกรองไหนเป็น landing page จริงแล้วให้ URL แบบ static ที่สะอาด เลิกสร้างลิงก์ที่ crawl ได้สำหรับส่วนที่เหลือและบล็อกรูปแบบพารามิเตอร์ใน robots.txt ทำให้สินค้าที่หมดและเลิกขายถาวรตอบ 404 หรือ 410 แทนหน้าว่างที่ตอบ 200 แก้ลิงก์ภายในที่ผ่าน redirect และดูแล sitemap สินค้าที่ lastmod เปลี่ยนเฉพาะเมื่อตัวสินค้าเปลี่ยน จากนั้นติดตามสัดส่วน discovery และระยะเวลาจากการเผยแพร่ถึงการ crawl ครั้งแรกในสัปดาห์ถัดๆ ไป ไม่มีขั้นตอนไหนรับประกันผล ทั้งหมดคือการตัดความสูญเปล่า เพื่อให้ demand และ capacity ไปลงที่หน้าที่คุณสนใจ
ความหมายสำหรับเว็บไซต์ในประเทศไทย
crawl budget เป็นเรื่องสำคัญหลักๆ กับเว็บไทยที่มีขนาดถึงเกณฑ์คร่าวๆ ของ Google ได้ คือแคตตาล็อกอีคอมเมิร์ซขนาดใหญ่ มาร์เก็ตเพลส เว็บประกาศซื้อขาย พอร์ทัลอสังหาริมทรัพย์ และสำนักข่าวที่อัปเดตทุกวัน
มีสองรูปแบบในตลาดไทยที่ควรตรวจ ถ้าเว็บสองภาษาแยกเวอร์ชันไทยและอังกฤษไว้บนซับโดเมนต่างกัน (th.example.com และ en.example.com) เพราะแต่ละโฮสต์เนมมี budget ของตัวเอง จึงควรเช็ก Crawl Stats ของแต่ละ property แยกกัน แทนที่จะคิดว่ารายงานเดียวครอบคลุมทั้งสอง อีกเรื่องคือ URL ภาษาไทยถูก percent-encode เมื่อส่งผ่านเครือข่าย หน้าเดียวกันจึงอาจถูกลิงก์ด้วยตัวอักษรไทยในที่หนึ่ง และด้วยรูปแบบที่ encode แล้วในอีกที่หนึ่ง ถ้าสองรูปแบบนี้วิ่งผ่าน redirect หรือกลายเป็น URL แยกกัน คุณก็สร้างหน้าซ้ำขึ้นมาเอง ควรเลือกรูปแบบเดียวแล้วลิงก์แบบนั้นสม่ำเสมอ
โฮสติ้งก็มีผลเช่นกัน ร้านค้าบนเซิร์ฟเวอร์แชร์ที่แน่นเกินไปจะเห็น response ช้าลงและ capacity limit ต่ำลง ไม่ว่าเนื้อหาจะดีแค่ไหน ถ้าปัญหา crawl budget กลายเป็นปัญหาเซิร์ฟเวอร์ ทางแก้อยู่ที่โฮสติ้ง ไม่ใช่การตั้งค่า SEO การทำ technical SEO audit มักเป็นวิธีที่เร็วที่สุดในการดูว่ากรณีไหนเกิดขึ้นกับเว็บของคุณ
คำถามที่พบบ่อย (FAQ)
Crawl budget มีผลต่ออันดับหรือไม่?
ไม่มี crawl budget ไม่ใช่ปัจจัยการจัดอันดับ แค่กำหนดว่า Google จะดึง URL ไหนและบ่อยแค่ไหน หน้าที่ไม่เคยถูก crawl จะไม่ถูก index และไม่ได้อันดับ ดังนั้นในเว็บที่ใหญ่มาก การ crawl ที่สูญเปล่าอาจทำให้หน้าใหม่หรือหน้าที่อัปเดตปรากฏช้าลง แต่การถูก crawl มากขึ้นไม่ได้ทำให้หน้าติดอันดับสูงขึ้น
จะรู้ได้อย่างไรว่าเว็บมีปัญหา crawl budget?
ให้ดูรายงาน Page Indexing ว่ามี URL ในสถานะ "Discovered - currently not indexed" จำนวนมากและเพิ่มขึ้นเรื่อยๆ หรือไม่ จากนั้นเปิด Crawl Stats แล้วดูตัวอย่าง URL ถ้าหน้าใหม่ถูก crawl ในวันเดียวกับที่เผยแพร่ แปลว่าคุณไม่มีปัญหา crawl budget
ควรใช้ noindex หรือ robots.txt เพื่อประหยัด crawl budget?
ใช้ robots.txt เพราะ noindex ไม่ได้ช่วยประหยัดการ crawl Google ต้องดึงหน้านั้นก่อนจึงจะเห็นแท็ก noindex จึงยังเสียคำขอไปหนึ่งครั้ง ขณะที่ robots.txt ป้องกันการดึงตั้งแต่ต้น ใช้ robots.txt เฉพาะกับ URL ที่ไม่ต้องการให้ crawl เลย และใช้ 404 หรือ 410 กับหน้าที่ลบถาวร
ขอให้ Google crawl เว็บมากขึ้นได้ไหม?
ไม่มีการตั้งค่าใดที่เพิ่ม crawl budget ได้โดยตรง Google เพิ่ม capacity limit เองเมื่อเซิร์ฟเวอร์ตอบสนองเร็วและเสถียร และมี demand สิ่งที่คุณปรับได้คือ response ที่เร็วขึ้น ทรัพยากรเซิร์ฟเวอร์ที่มากขึ้น และเนื้อหาที่คนลิงก์มาหาและเข้ามาดู
ซับโดเมนใช้ crawl budget ร่วมกันหรือไม่?
ไม่ แต่ละโฮสต์เนมมี crawl budget ของตัวเอง เพราะ Google นิยามเว็บไซต์ว่าเป็นโฮสต์เนมที่ไม่ซ้ำกัน ซับโดเมนภาษาไทยและภาษาอังกฤษจึงมี budget แยกกัน และต้องเช็กแยกกันใน Search Console
ถ้าแคตตาล็อกหรือปริมาณการเผยแพร่ของคุณอยู่ในกลุ่มที่ Google พูดถึง ให้เริ่มจากสำรวจ URL ทุกรูปแบบที่ crawl ได้ บริการ SEO สำหรับ e-commerce ครอบคลุมเรื่อง faceted navigation และการจัดการวงจรชีวิตสินค้า ส่วน บริการ SEO ในประเทศไทย ครอบคลุมด้านเนื้อหาและความน่าเชื่อถือที่ทำให้ crawl demand สูงขึ้น
