SITE AUDIT • UNIFIED AUDIT MODULE

การวินิจฉัยปัญหา: บอทไม่เข้าเก็บ / Index หลุด / Crawled Currently Not Indexed

ผสานหลักการวิเคราะห์ (Why & Decision Logic) เข้ากับเช็คลิสต์ลงมือทำ (Step-by-Step Action & Tools) เป็นรายเรื่องอย่างสมบูรณ์

ความคืบหน้ารวม:
0/6
แนวทางสอน: อธิบายทีละขั้นตอนจาก STEP 01 ถึง STEP 06 โดยมีทั้งหลักวิเคราะห์ + จุดตรวจ + เครื่องมือ จบในแต่ละการ์ด
STEP 01 Protocol Level

ตรวจสอบ HTTP Status: หน้าเป้าหมายต้องตอบกลับด้วยสถานะ 200 OK เสมอ

การตรวจสอบสถานะด่านแรกสุด เพื่อป้องกันปัญหา Redirect Chain, Soft 404 และ 500 Internal Error

หลักการวิเคราะห์ (Why & Decision Logic)

Googlebot จะไม่นำหน้าเว็บเข้าดัชนี (Index) หากการร้องขอหน้าเว็บไม่สิ้นสุดที่รหัสสถานะ 200 OK:

  • ถ้าเจอ 301/302 Redirect Chain (ส่งต่อเกิน 1 ทอด เช่น A → B → C): บอทอาจหยุดเดินกลางคันเพื่อประหยัดทรัพยากร
  • ถ้าเจอ 404 / 410: บอทจะเข้าใจว่าหน้านี้ถูกลบอย่างถาวรและถอดออกจากดัชนี
  • ถ้าเจอ 500 / 502 / 503: บอทจะลดความถี่ในการเข้าเก็บ (Crawl Rate) ทันที เพราะมองว่าเซิร์ฟเวอร์รับโหลดไม่ไหว
จุดตรวจเช็ค & สิ่งที่ต้องยืนยัน (Checklist Action)
  • ยิงตรวจสอบ HTTP Response Header ของ URL เป้าหมาย ทั้งเวอร์ชัน Desktop และ Mobile User-Agent
  • ตรวจจับกรณี Soft 404 (หน้าว่างเปล่าหรือบอกว่าไม่พบสินค้า แต่เซิร์ฟเวอร์ดันตอบ 200 OK)
  • ยืนยันว่าไม่มีคำสั่ง Header X-Robots-Tag: noindex แฝงมากับ Response
เครื่องมือ & คำสั่งตรวจเช็คสด (Actionable Tooling)
Python CLI / cURL
# ตรวจสอบ Response Status, Headers และ Canonical ทันที:
python scripts/diagnose_url.py https://example.com/target-page
# หรือใช้ cURL ตรวจเฉพาะส่วนหัว:
curl -ILs "https://example.com/target-page" | grep -E "HTTP|x-robots|location"
เกณฑ์ผ่าน (QC Pass): URL เป้าหมายตอบกลับ HTTP/2 200 โดยตรง ไม่ผ่าน Redirect Loop และไม่มี noindex header พร้อมส่งมอบ
STEP 02 Crawl Gatekeeper

ตรวจสอบ robots.txt: ยืนยันว่าไม่มีคำสั่ง Disallow บล็อกหน้าสำคัญหรือพารามิเตอร์โฆษณา

ประตูหน้าด่านแรกสุดของเว็บไซต์ หากเขียนคำสั่ง Regex ผิดเพียงตัวเดียว อาจบล็อกบอททั้งระบบ

หลักการวิเคราะห์ (Why & Decision Logic)

ไฟล์ robots.txt คือคำสั่งแรกที่ Googlebot จะดาวน์โหลดมาอ่าน หาก URL ตรงกับเงื่อนไข Disallow บอทจะไม่แม้แต่ส่งคำขอ (Request) ไปยังหน้าเว็บนั้น ทำให้:

  • บอทไม่รู้ว่าในหน้าเว็บมีเนื้อหาอะไร ไม่เห็น Internal Links ที่จะส่งพลังต่อไปหน้าอื่น
  • ถ้าหน้านั้นเคยติด Index อยู่แล้ว จะแสดงผลแบบมีข้อความ "No information is available for this page"
จุดตรวจเช็ค & สิ่งที่ต้องยืนยัน (Checklist Action)
  • เปิดดูไฟล์ https://domain.com/robots.txt ว่าสามารถเข้าถึงได้และตอบ 200 OK
  • ตรวจสอบว่าไม่มีคำสั่งอันตราย เช่น Disallow: / หรือบล็อกโฟลเดอร์ CSS/JS ของ Elementor
  • ทดสอบ URL เป้าหมายใน Google Search Console Robots.txt Tester
เคสจริงจากหน้างาน (Battle-Tested Case Study): ระวังคำสั่ง Disallow เหมารวม

เคยพบเว็บไซต์ตั้งใจบล็อก URL Parameter ของระบบกรองสินค้าด้วยคำสั่ง Disallow: /*?* แต่ผลกระทบกลับไปบล็อก Parameter โฆษณาของ Google Ads เช่น ?gclid= และ ?fbclid= ส่งผลให้บอทของ Google Ads เข้าตรวจสอบ Landing Page ไม่ได้จนโฆษณาเสี่ยงโดนระงับ!
วิธีแก้: ห้ามใช้คำสั่งกวาดรวม ให้เจาะจงเฉพาะชื่อ Parameter ระบบกรอง เช่น Disallow: /*?*filter=, Disallow: /*?*sort=

เครื่องมือ & คำสั่งตรวจเช็ค (Tooling)
cURL / Robots API
# ตรวจสอบเนื้อหา robots.txt ปัจจุบันบนเซิร์ฟเวอร์:
curl -s "https://example.com/robots.txt"
เกณฑ์ผ่าน (QC Pass): robots.txt ปลอดภัย อนุญาตให้ User-agent: * เข้าถึงหน้าหลักและ Resource ไฟล์ CSS/JS ได้อย่างอิสระ พร้อมส่งมอบ
STEP 03 Link Equity & Authority

ตรวจสอบ Canonical Tag: ต้องระบุ Absolute URL ชี้ตรงกับ URL ตัวเองที่ถูกต้อง

สัญญาณชี้ขาดว่าหน้าใดคือ "ต้นฉบับตัวจริง" ป้องกันปัญหา Duplicate Content และการโดนกูเกิลตัดทิ้ง

หลักการวิเคราะห์ (Why & Decision Logic)

ในสายตาของ Googlebot หน้าเว็บเหล่านี้คือ คนละหน้าทั้งหมด:

  • • http://example.com/page (HTTP ไม่ปลอดภัย)
  • • https://example.com/page (ไม่มี slash ท้าย)
  • • https://example.com/page/ (มี slash ท้าย)
  • • https://www.example.com/page/ (มี www)

หาก Canonical Tag ชี้ผิด หรือเป็น Relative URL (เช่น href="/page") บอทอาจสับสนและเลือก Index ผิดเวอร์ชัน หรือไม่ Index เลย

จุดตรวจเช็ค & สิ่งที่ต้องยืนยัน (Checklist Action)
  • ดูในซอร์สโค้ด <head> ว่ามีแท็ก <link rel="canonical" href="https://..."> เพียงชุดเดียว
  • URL ใน Canonical ต้องสะกดตรงกับ URL ที่ใช้งานจริง 100% (รวมตัวพิมพ์เล็ก-ใหญ่ และ Trailing Slash)
  • หากเป็นหน้า Pagination (เช่น /page/2/) Canonical ต้องชี้หาตัวเอง ไม่ใช่ชี้กลับไปหน้า 1
เครื่องมือตรวจสอบ (Tooling)
Inspect Element / CLI
# ดึง Canonical Tag สดจากหน้าเว็บผ่าน CLI:
curl -s "https://example.com/target-page" | grep -i 'rel="canonical"'
เกณฑ์ผ่าน (QC Pass): มี Self-Referencing Canonical แบบ Absolute URL ตรงเป๊ะเพียง 1 แท็กใน <head> พร้อมส่งมอบ
STEP 04 Discovery Map

ตรวจสอบ XML Sitemap: หน้านั้นต้องมีรายชื่ออยู่ใน Sitemap Index และไม่ใช่ไซท์แมปกลวง

สารบัญบอกทางให้เสิร์ชเอนจินรู้ว่ามีหน้าใดเกิดขึ้นใหม่ในระบบ และเวลาอัปเดตล่าสุดคือเมื่อใด

หลักการวิเคราะห์ (Why & Decision Logic)

เมื่อหน้าเว็บถูกสร้างขึ้นใหม่ หากไม่มี Internal Link เชื่อมโยงมาหา และไม่มีชื่อใน XML Sitemap บอทจะมองเป็น Orphan Page (หน้ากำพร้า) และอาจใช้เวลานานหลายสัปดาห์หรือหลายเดือนกว่าจะค้นพบ

หลุมพราง Empty Sitemap: ปลั๊กอินบางตัวสร้างไฟล์ย่อยขึ้นมา เช่น product-sitemap.xml ซึ่งตอบ 200 OK แต่ข้างในกลับมี 0 <loc> บอทจึงไม่ได้รับรายชื่อหน้าไปเก็บ

จุดตรวจเช็ค & สิ่งที่ต้องยืนยัน (Checklist Action)
  • เปิด /sitemap_index.xml ตรวจดูว่ามี Sub-sitemap แยกตาม Post, Page, Category ครบถ้วน
  • ค้นหา URL เป้าหมายในไฟล์ XML ว่าปรากฏอยู่จริง
  • ตรวจรายงาน Sitemaps ใน GSC ว่าสถานะเป็น "Success" และไม่มี Error
เครื่องมือตรวจสอบ (Tooling)
sitemap_auditor.py
# รันสคริปต์สแกน Sub-sitemaps และดักจับไซท์แมปกลวง:
python scripts/sitemap_auditor.py https://example.com/sitemap_index.xml
เกณฑ์ผ่าน (QC Pass): URL เป้าหมายปรากฏอยู่ใน XML Sitemap และ GSC แสดงสถานะ Success พร้อมส่งมอบ
STEP 05 Server Performance

ตรวจสอบ Server Cache / TTFB: Response Time ไม่ควรเกิน 1.2 วินาที

หากเซิร์ฟเวอร์ตอบสนองช้า บอทจะตัดเวลา Crawl Budget ทิ้ง และถอนตัวออกก่อนจะบันทึกเนื้อหา

หลักการวิเคราะห์ (Why & Decision Logic)

TTFB (Time to First Byte) คือความเร็วที่เซิร์ฟเวอร์ส่งข้อมูลไบต์แรกกลับมา:

  • ถ้า TTFB เกิน 1.5 - 2 วินาที กูเกิลจะมองว่าเซิร์ฟเวอร์อืด และจะจำกัดโควต้าการเข้าเก็บหน้าอื่นๆ ในเว็บ
  • ถ้าเกิด Timeout (เช่น เกิน 5 วินาที) หน้าเว็บจะขึ้นสถานะ "Crawl failed" ทันที
  • การมี Edge Caching (เช่น Cloudflare Cache) จะช่วยให้บอทได้รับหน้าเว็บในเวลาเสี้ยววินาที (≤ 200ms)
จุดตรวจเช็ค & สิ่งที่ต้องยืนยัน (Checklist Action)
  • ตรวจสอบค่า TTFB เฉลี่ย ไม่ควรเกิน 1,200 ms (1.2s) โดยเป้าหมายยอดเยี่ยมคือต่ำกว่า 500ms
  • ตรวจ Response Headers ว่ามี cf-cache-status: HIT หรือ x-cache: HIT หรือไม่
  • เปิดใช้งาน Page Cache ใน WordPress (WP Rocket, LiteSpeed Cache หรือ Super Cache)
เครื่องมือตรวจสอบ (Tooling)
diagnose_url.py / DevTools
# ตรวจสอบ Response Time และ Caching Status สด:
python scripts/diagnose_url.py https://example.com/target-page
เกณฑ์ผ่าน (QC Pass): TTFB ≤ 1.2 วินาที และมีแคชเซิร์ฟเวอร์หรือ Edge Cache รองรับ พร้อมส่งมอบ
STEP 06 Crawl Budget Architecture

ตรวจสอบ Index Bloat: ป้องกัน Faceted/Filter URLs ผลาญ Crawl Budget จนหน้าจริงไม่ติด Index

สาเหตุสำคัญที่สุดของสถานะ "Crawled - currently not indexed" บนเว็บ E-Commerce หรือระบบกรองขนาดใหญ่

หลักการวิเคราะห์ (Why & Decision Logic)

Index Bloat เกิดขึ้นเมื่อเว็บไซต์สร้าง URL ซ้ำซากหรือ URL ขยะออกมาเป็นจำนวนมาก เช่น ตัวกรองราคา, สี, ขนาด (Faceted Search):

  • เมื่อบอทเข้ามา มันจะวิ่งไล่เก็บ URL ขยะเหล่านั้นจนโควต้าหมด (Crawl Budget Exhaustion)
  • ทำให้หน้าบทความใหม่หรือหน้าสินค้าตัวจริงถูกค้างอยู่ในสถานะ "Crawled - currently not indexed" หรือ "Discovered - currently not indexed"
จุดตรวจเช็ค & สิ่งที่ต้องยืนยัน (Checklist Action)
  • เปิด Google Search Console เมนู Indexing → Pages ตรวจสอบสัดส่วนหน้ารวม
  • ใส่แท็ก <meta name="robots" content="noindex, follow"> ในหน้ากรอง Facet หรือค้นหาภายใน
  • ตรวจสอบว่า Internal Link ในเว็บไม่มีการเชื่อมโยงไปยัง URL ที่มีพารามิเตอร์ขยะโดยไม่จำเป็น
เครื่องมือตรวจสอบ (Tooling)
GSC Indexing Report
# ตรวจสอบใน GSC:
GSC → Indexing → Pages → "Crawled - currently not indexed"
เกณฑ์ผ่าน (QC Pass): หน้ากรอง Faceted ใส่ noindex ถูกต้อง และจำนวนหน้าใน GSC สะท้อนเนื้อหาจริงของเว็บ พร้อมส่งมอบ
กลับหน้าผังรวม (Decision Tree)
กลับหน้าสารบัญรวม (Workbench Hub)