หลังจากส่งไฟล์ sitemap丨เหตุผลที่ Google จัดทำดัชนีเพียงบางหน้า

เมื่อเว็บมาสเตอร์ส่งแผนผังเว็บไซต์ผ่าน Google Search Console แล้วพบว่า จำนวนหน้าที่ถูกจัดทำดัชนีจริง ๆ น้อยกว่าที่คาดการณ์ไว้ พวกเขามักจะตกหลุมพรางของการเพิ่มจำนวนการส่งแบบ blind หรือการแก้ไขไฟล์ซ้ำแล้วซ้ำอีก

ตามข้อมูลทางการในปี 2023 มากกว่า 67% ของปัญหาการทำดัชนีเกิดจาก 3 สาเหตุหลัก ๆ ได้แก่ การตั้งค่าผิดพลาดของแผนผังเว็บไซต์ การบล็อกเส้นทางการค้นหา และข้อบกพร่องของคุณภาพของหน้า

ช่องโหว่ในไฟล์แผนผังเว็บไซต์เอง

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

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

▍ช่องโหว่ 1: ข้อผิดพลาดของฟอร์แมตที่ทำให้การแยกวิเคราะห์หยุดชะงัก

แหล่งข้อมูล: รายงานการตรวจสอบเว็บไซต์ของ Ahrefs ปี 2023

กรณีตัวอย่าง: เว็บไซต์ด้านการแพทย์ส่งแผนผังเว็บไซต์ที่ใช้การเข้ารหัส Windows-1252 ส่งผลให้ Google ไม่สามารถแยกวิเคราะห์ได้ 3,200 หน้า และตรวจพบเพียงหน้าแรกเท่านั้น (ใน Search Console แสดงคำเตือน “ไม่สามารถอ่านได้”)

ข้อผิดพลาดที่พบบ่อย：

✅ แท็ก XML ที่ไม่ได้ปิด (43% ของข้อผิดพลาดฟอร์แมต)
✅ ตัวอักษรพิเศษที่ไม่ได้ถูกเข้ารหัส (เช่น ใช้ & โดยตรงแทนที่จะเป็น &)
✅ ขาดการประกาศ namespace xmlns (<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> ขาดหายไป)

ทางออกฉุกเฉิน：

• ใช้ Sitemap Validator เพื่อบังคับการตรวจสอบโครงสร้าง
• ติดตั้งปลั๊กอิน XML Tools ใน VSCode เพื่อตรวจสอบไวยากรณ์แบบเรียลไทม์

▍ช่องโหว่ 2: ลิงก์เสียที่ก่อให้เกิดปัญหาความเชื่อถือ

การวิจัยในอุตสาหกรรม: ข้อมูลจากการเก็บข้อมูลของ Screaming Frog จาก 500,000 เว็บไซต์

ข้อมูลที่น่าสนใจ：

✖️ โดยเฉลี่ยแล้วแผนผังเว็บไซต์แต่ละแผนผังมีลิงก์ที่มีข้อผิดพลาด 404/410 ถึง 4.7%
✖️ หากแผนผังเว็บไซต์มีลิงก์เสียมากกว่า 5% จะเห็นอัตราการทำดัชนีลดลง 62%

กรณีตัวอย่างจริง: แผนผังเว็บไซต์ของแพลตฟอร์มการท่องเที่ยวมีหน้าผลิตภัณฑ์ที่ถูกลบ (ส่งกลับ 302 ไปยังหน้าแรก) ส่งผลให้ Google ถือว่าเป็นการพยายามบิดเบือนการทำดัชนี ทำให้การจัดทำดัชนีของหน้าหลักล่าช้าไป 117 วัน

ขั้นตอนการแก้ไขปัญหา：

1. ใช้เครื่องมือการค้นหาด้วยการตั้งค่า User-Agent เป็น “Googlebot” เพื่อจำลองการค้นหาลิงก์ทั้งหมดในแผนผังเว็บไซต์
2. ส่งออกลิงก์ที่มีสถานะไม่ใช่ 200 และเพิ่ม <robots noindex> หรือเอาลิงก์ออกจากแผนผังเว็บไซต์

▍ช่องโหว่ 3: ขนาดไฟล์เกินขีดจำกัดทำให้ข้อมูลถูกตัดทอน

ขีดจำกัดคำเตือนจาก Google：

⚠️ หากแผนผังเว็บไซต์ไฟล์เดียวมีขนาดเกิน 50MB หรือมี URL มากกว่า 50,000 รายการ การประมวลผลจะหยุดโดยอัตโนมัติ

กรณีภัยพิบัติ: แผนผังเว็บไซต์ของเว็บไซต์ข่าวไม่ถูกแบ่งเป็นส่วน ๆ และมีลิงก์บทความ 82,000 รายการ ส่งผลให้ Google ทำการประมวลผลเพียง 48,572 รายการแรกเท่านั้น (ยืนยันจากการวิเคราะห์บันทึก)

กลยุทธ์การแบ่งแยก：
🔹 แบ่งตามประเภทเนื้อหา: /sitemap-articles.xml, /sitemap-products.xml
🔹 แบ่งตามวันที่: /sitemap-2023-08.xml (เหมาะสำหรับเว็บไซต์ที่มีการอัปเดตบ่อย)

การตรวจสอบขนาดไฟล์：

ใช้สคริปต์ Python ทุกสัปดาห์เพื่อคำนวณจำนวนบรรทัดในไฟล์ (wc -l sitemap.xml) และตั้งค่าการเตือนเมื่อมันถึง 45,000 บรรทัด

▍ช่องโหว่ 4: การปรับความถี่การอัปเดตที่ทำให้การทำดัชนีล่าช้า

มาตรการต่อต้านของ Crawler：

🚫 เว็บไซต์ที่ใช้ <lastmod> (เช่น การระบุวันที่ปัจจุบันในทุกหน้า) จะเห็นความเร็วในการทำดัชนีลดลง 40%

บทเรียนที่เรียนรู้: เว็บไซต์ฟอรัมได้อัปเดตวันที่ lastmod ในทุกหน้าเว็บไซต์ทุกวัน ภายในสามสัปดาห์การครอบคลุมการทำดัชนีของมันลดลงจาก 89% เป็น 17%

การดำเนินงานที่สอดคล้อง：

✅ อัปเดต <lastmod> เฉพาะในหน้าที่มีการเปลี่ยนแปลงจริง (แม่นยำถึงระดับนาที: 2023-08-20T15:03:22+00:00)
✅ ตั้งค่า <changefreq>monthly</changefreq> สำหรับหน้าประวัติศาสตร์เพื่อลดภาระการค้นหา

โครงสร้างเว็บไซต์บล็อกเส้นทางการค้นหา

ถึงแม้ว่าแผนผังเว็บไซต์จะสมบูรณ์แบบ โครงสร้างเว็บไซต์ก็ยังสามารถกลายเป็น “เขาวงกต” สำหรับ Google ในการค้นหาได้

หน้าที่สร้างขึ้นด้วย React หากไม่ได้ถูกแสดงล่วงหน้า จะถูกถือว่าเป็น “หน้าว่าง” โดย Google ถึง 60% ของเนื้อหาของมัน

หากการกระจายลิงก์ภายในไม่สมดุล (เช่น หน้าแรกมีลิงก์ภายนอกมากกว่า 150 ลิงก์) ความลึกในการค้นหาจะถูกจำกัดที่ 2 ชั้น ส่งผลให้หน้าผลิตภัณฑ์ที่ลึกกว่าจะยังคงอยู่นอกการทำดัชนีตลอดไป

▍

robots.txt บล็อกหน้าหลักที่สำคัญ

สถานการณ์ตัวอย่าง：

• เว็บไซต์ WordPress มีการตั้งค่าคำสั่ง Disallow: /wp-admin/ เป็นค่าตั้งต้น ซึ่งอาจบล็อกเส้นทางบทความที่เกี่ยวข้อง (เช่น /wp-admin/post.php?post=123)
• เว็บไซต์ที่สร้างด้วย Shopify จะมีการสร้างคำสั่ง Disallow: /a/ โดยอัตโนมัติที่ด้านหลัง ซึ่งจะบล็อกหน้าโปรไฟล์สมาชิก

ข้อมูลเชิงลึกจากข้อมูล：

✖️ 19% ของเว็บไซต์มีข้อผิดพลาดในการตั้งค่า robots.txt ทำให้สูญเสียการจัดทำดัชนีกว่า 30%
✖️ เมื่อ Googlebot พบกฎ Disallow จะใช้เวลาเฉลี่ย 14 วันในการพยายามสำรวจใหม่

วิธีแก้ไข：

1. ใช้เครื่องมือ การทดสอบ robots.txt เพื่อตรวจสอบขอบเขตผลกระทบของกฎ
2. ไม่บล็อก URL ที่มีพารามิเตอร์แบบไดนามิกเช่น ?ref=
3. หากหน้าเว็บถูกบล็อกโดยผิดพลาด ให้ลบข้อจำกัดจาก robots.txt แล้วขอให้ Googlebot สำรวจใหม่โดยใช้เครื่องมือ URL Inspection

▍ ปัญหาจากการเรนเดอร์ JS ทำให้เนื้อหาหายไป

ความเสี่ยงจาก Framework：

• React/Vue แอปพลิเคชันแบบ SPA: หากไม่มีการเรนเดอร์ล่วงหน้า Google จะสามารถเก็บข้อมูล DOM ได้เพียง 23%
• การโหลดภาพล่าช้า (Lazy Load): มีโอกาสที่ภาพจะไม่โหลดขึ้นในมือถือสูงถึง 51%

ตัวอย่างจริง：

เว็บไซต์อีคอมเมิร์ซแห่งหนึ่งใช้ Vue ในการเรนเดอร์ข้อมูลราคาและคุณสมบัติของสินค้าอย่างไดนามิก ผลที่ตามมาคือ ความยาวของเนื้อหาที่ Google จัดทำดัชนีเฉลี่ยเพียง 87 ตัวอักษร (ปกติจะต้องมากกว่า 1200 ตัวอักษร) และอัตราการแปลงลดลง 64%

มาตรการฉุกเฉิน：

1. ใช้เครื่องมือ การทดสอบความเข้ากันได้กับมือถือ เพื่อดูว่าเนื้อหาถูกเรนเดอร์ครบถ้วนหรือไม่
2. ใช้การเรนเดอร์ฝั่งเซิร์ฟเวอร์ (SSR) หรือใช้ Prerender.io เพื่อสร้างสแน็ปช็อตแบบคงที่สำหรับหน้า SEO สำคัญ
3. แทรกเนื้อหาหลักในแท็ก <noscript> (แนะนำให้รวม H1 และคำอธิบายอย่างน้อย 3 บรรทัด)

▍ การกระจายลิงก์ภายในไม่สมดุล

เกณฑ์ความลึกของการสำรวจ：

• ถ้ามีลิงก์ออกจากหน้าแรกมากกว่า 150 ลิงก์ ความลึกของการสำรวจเฉลี่ยจะลดลงเหลือ 2.1 ชั้น
• หากคลิกไปยังเนื้อหาหลักเกิน 3 ชั้น การทำดัชนีจะลดลง 38%

กลยุทธ์การปรับโครงสร้าง：

✅ ใช้การนำทางด้วยขนมปัง crumbs โดยรวมโครงสร้างหมวดหมู่ (ตัวอย่าง: หน้าแรก > อุปกรณ์อิเล็กทรอนิกส์ > โทรศัพท์มือถือ > Huawei P60)
✅ เพิ่มโมดูล "หน้าเพจสำคัญ" ในหน้ารายการเพื่อเพิ่มมูลค่าลิงก์ภายในไปยังหน้าเป้าหมาย
✅ ใช้ Screaming Frog เพื่อตรวจสอบหาหน้าที่ยังไม่ได้รับลิงก์เข้าและเพิ่มลิงก์ไปยังเนื้อหาที่เกี่ยวข้องที่ด้านล่างของบทความ

▍ การใช้แท็ก canonical หรือ pagination อย่างผิดพลาด

กรณีที่เกิดความเสียหาย：

• หน้าสินค้ากำหนด rel="canonical" ไปที่หน้าแรก: ทำให้ 63% ของหน้าเว็บถูกรวมและลบ
• การใช้แท็ก rel="next"/"prev" ในการแบ่งหน้าแสดงความคิดเห็นจะทำให้สูญเสียอำนาจการจัดทำดัชนีของหน้าเนื้อหาหลัก

กรองเนื้อหาจากปัญหาคุณภาพ

ตามรายงานอัลกอริธึมของ Google ปี 2023 หน้าเว็บที่มีดัชนีต่ำกว่า 61% เกิดจากปัญหาคุณภาพเนื้อหาของหน้า

เมื่อมีหน้าที่มีความคล้ายคลึงกันมากกว่า 32% การทำดัชนีจะลดลงเหลือ 41% และหากหน้าโหลดช้าเกิน 2.5 วินาทีในมือถือ ความสำคัญในการสำรวจจะลดลง

เนื้อหาซ้ำทำให้ความน่าเชื่อถือลดลง

มาตรฐานของอุตสาหกรรมที่มีรายชื่อดำ：

• หากหน้าที่สร้างขึ้นจากเทมเพลตเดียวกัน (เช่น หน้ารายการสินค้า) มีความคล้ายกันมากกว่า 32% จะทำให้การทำดัชนีลดลง 41%
• หากการซ้ำซ้อนของย่อหน้ามากกว่า 15% ตามการทดสอบ Copyscape การทำดัชนีจะถูกกระตุ้นให้รวมกัน

ตัวอย่าง：

เว็บไซต์ค้าส่งเสื้อผ้าแห่งหนึ่งสร้างหน้าสินค้า 5,200 หน้าโดยใช้คำอธิบายเดียวกัน แต่ Google จัดทำดัชนีเฉพาะหน้าแรกเท่านั้น (มีการแจ้งเตือนใน Search Console ว่า "มี canonical ที่ถูกต้อง") การเข้าชมลดลง 89% ภายในหนึ่งสัปดาห์

วิธีการแก้ไขพื้นฐาน：

1. ใช้ไลบรารี difflib ของ Python เพื่อคำนวณความคล้ายคลึงของหน้าเว็บ และลบหน้าที่มีความคล้ายคลึงเกิน 25%
2. สำหรับหน้าที่มีความคล้ายคลึงที่จำเป็น (เช่น หน้าแยกตามพื้นที่) ให้เพิ่มคำอธิบายพื้นที่ใน <meta name="description">
3. สำหรับหน้าเว็บที่มีเนื้อหาซ้ำ ให้นำ rel="canonical" ใส่ไว้เพื่อกำหนดเวอร์ชันหลัก

<link rel="canonical" href="https://example.com/product-a?color=red" />  

▍ ประสิทธิภาพการโหลดข้ามขีดจำกัดที่ยอมรับได้

Core Web Vitals เส้นตายชีวิต：

• FCP (First Contentful Paint) บนมือถือ ＞ 2.5 วินาที → ลำดับความสำคัญในการดึงข้อมูลลดลง
• CLS (Cumulative Layout Shift) ＞ 0.25 → การหน่วงดัชนีเพิ่มขึ้น 3 เท่า

บทเรียนที่ได้รับ：

เว็บไซต์ข่าวแห่งหนึ่งไม่บีบอัดภาพบนหน้าจอแรก (ขนาดเฉลี่ย 4.7MB) ส่งผลให้ LCP (Largest Contentful Paint) บนมือถือสูงถึง 8.3 วินาที ทำให้บทความจำนวน 12,000 บทความถูก Google ติดแท็กว่าเป็น "เนื้อหาคุณภาพต่ำ"

เช็คลิสต์การปรับแต่งความเร็ว：

✅ ใช้ WebP แทน PNG/JPG และบีบอัดเป็นกลุ่มด้วย Squoosh ให้ขนาดไม่เกิน 150KB
✅ ใช้ CSS แบบอินไลน์สำหรับหน้าจอแรก และโหลด JS ที่ไม่สำคัญแบบอะซิงโครนัส (เพิ่มแอตทริบิวต์ async หรือ defer)
✅ โฮสต์สคริปต์ของบุคคลที่สามใน localStorage เพื่อลดการร้องขอจากภายนอก (เช่น ใช้ GTM โฮสต์ Google Analytics)

▍ ขาดข้อมูลที่มีโครงสร้างทำให้ลำดับความสำคัญลดลง

กฎการจับข้อมูลของโปรแกรมค้นหา：

• หน้าที่มี FAQ Schema → ความเร็วในการดึงข้อมูลเพิ่มขึ้น 37%
• ไม่มีการทำเครื่องหมายข้อมูลโครงสร้างเลย → เวลารอในคิวสำหรับดัชนีเพิ่มขึ้นถึง 14 วัน

กรณีศึกษา：

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

โค้ดที่ใช้จริง：

<script type="application/ld+json">  
{  
  "@context": "https://schema.org",  
  "@type": "FAQPage",  
  "mainEntity": [{  
    "@type": "Question",  
    "name": "วิธีการปรับปรุงการจัดทำดัชนีของ Google?",  
    "acceptedAnswer": {
"@type": "Answer",  
"text": "ปรับโครงสร้าง sitemap และความเร็วในการโหลดหน้าเว็บให้ดีขึ้น"  
}  
}]  
}  
</script>  

การตั้งค่าเซิร์ฟเวอร์ทำให้ประสิทธิภาพการครอว์ลลดลง

การใช้พารามิเตอร์ Crawl-delay มากเกินไป

กลไกการตอบโต้ของ Googlebot：

• ตั้งค่า Crawl-delay: 10 → จำนวนการครอว์ลสูงสุดต่อวันลดลงจาก 5000 หน้าเหลือเพียง 288 หน้า
• ในกรณีที่ไม่มีการจำกัด → Googlebot จะครอว์ลเฉลี่ย 0.8 หน้า/วินาที (ปรับโดยอัตโนมัติตามการโหลดของเซิร์ฟเวอร์)

กรณีตัวอย่างจริง：

ฟอรัมแห่งหนึ่งได้ตั้งค่า Crawl-delay: 5 ในไฟล์ robots.txt เพื่อป้องกันการโอเวอร์โหลดของเซิร์ฟเวอร์ ส่งผลให้ปริมาณการครอว์ลของ Google ลดลงจาก 820,000 ครั้งต่อเดือนเหลือเพียง 43,000 ครั้ง และการดัชนีเนื้อหาใหม่ล่าช้าไปถึง 23 วัน

กลยุทธ์การแก้ไข：

1. ลบคำสั่ง Crawl-delay (Google จะไม่สนใจพารามิเตอร์นี้อยู่ดี)
2. ใช้การจำกัดการครอว์ลสำหรับบ็อตเฉพาะ เช่น Googlebot-News
3. ตั้งค่าการจำกัดอัตราใน Nginx อย่างชาญฉลาด:

# อนุญาตให้ Googlebot และ Bingbot เข้าถึงเฉพาะ
limit_req_zone $anti_bot zone=googlerate:10m rate=10r/s;  

location / {  
    if ($http_user_agent ~* (Googlebot|bingbot)) {  
        limit_req zone=googlerate burst=20 nodelay;  
    }  
}  

การบล็อกช่วง IP โดยไม่ตั้งใจ

ลักษณะของช่วง IP ของ Googlebot：

• ช่วง IPv4: 66.249.64.0/19, 34.64.0.0/10 (เพิ่มในปี 2023)
• ช่วง IPv6: 2001:4860:4801::/48

กรณีที่เกิดความผิดพลาด：

เว็บไซต์อีคอมเมิร์ซแห่งหนึ่งได้บล็อกช่วง IP 66.249.70.* ด้วยการใช้ไฟร์วอลล์ของ Cloudflare (เข้าใจผิดว่าเป็นการโจมตีจากบ็อต) ส่งผลให้ Googlebot ไม่สามารถครอว์ลได้ติดต่อกันเป็นเวลา 17 วัน และจำนวนหน้าที่ถูกดัชนีหายไปถึง 62%
เพิ่มกฎในไฟร์วอลล์ของ Cloudflare: (ip.src in {66.249.64.0/19 34.64.0.0/10} and http.request.uri contains "/*") → Allow

การบล็อกทรัพยากรที่สำคัญในการเรนเดอร์

รายการที่ถูกบล็อก：

• บล็อก *.cloudflare.com → ทำให้ CSS/JS 67% ไม่สามารถโหลดได้
• บล็อก Google Fonts → อัตราการล้มเหลวของเลย์เอาต์บนมือถือสูงถึง 89%

กรณีศึกษา：

แพลตฟอร์ม SAAS แห่งหนึ่งได้บล็อกโดเมน jquery.com ส่งผลให้เกิดข้อผิดพลาดของ JS ขณะ Googlebot เรนเดอร์หน้า ทำให้เปอร์เซ็นต์การแยกวิเคราะห์ HTML ของหน้าผลิตภัณฑ์ลดลงเหลือเพียง 12%

วิธีการปลดบล็อก：

1. เพิ่มโดเมนในรายการไวท์ลิสต์ในการตั้งค่า Nginx:

location ~* (jquery|bootstrapcdn|cloudflare)\.(com|net) {
allow all;
add_header X-Static-Resource "Unblocked";
}  

2. เพิ่มคุณสมบัติ crossorigin="anonymous" สำหรับทรัพยากรที่โหลดแบบอะซิงโครนัส:

<script src="https://example.com/analytics.js" crossorigin="anonymous">script> 

หมดเวลาในการตอบสนองของเซิร์ฟเวอร์

เกณฑ์การยอมรับของ Google：

• เวลาตอบสนอง > 2000ms → ความน่าจะเป็นที่เซสชันจะถูกยกเลิกเพิ่มขึ้น 80%
• จำนวนคำขอที่ประมวลผลต่อวินาที < 50 → งบประมาณการครอว์ลจะลดลง 30%

กรณีล้มเหลว：

เว็บไซต์ WordPress แห่งหนึ่งไม่ได้เปิดใช้งาน OPcache ทำให้เวลาคิวรีฐานข้อมูลสูงถึง 4.7 วินาที ส่งผลให้ Googlebot เกิดปัญหาหมดเวลาในการตอบสนองถึง 91% และการจัดทำดัชนีหยุดชะงัก

การปรับปรุงประสิทธิภาพ：
1. การตั้งค่า PHP-FPM สำหรับการเพิ่มประสิทธิภาพ (เพิ่มจำนวนการเชื่อมต่อ 3 เท่า):

pm = dynamic
pm. max_children = 50
pm. start_servers = 12
pm. min_spare_servers = 8
pm. max_spare_servers = 30

2. การบังคับให้ MySQL ใช้ดัชนีที่เหมาะสม:

ALTER TABLE wp_posts FORCE INDEX (type_status_date);

ด้วยวิธีข้างต้นนี้ คุณสามารถควบคุมความแตกต่างของดัชนีให้อยู่ในขอบเขต 5% ได้อย่างสม่ำเสมอ
หากต้องการเพิ่มจำนวนการค้นหาของ Google ให้มากขึ้น ลองดูคู่มือ GPC Crawler Pool ของเรา