เช็กลิสต์ SEO เชิงเทคนิค: 20 จุดตรวจด้านการ crawl, index, render และ performance
1. ทำไมการตรวจสอบเชิงเทคนิคต้องแบ่งเป็น 4 ด้าน
หลายคนทำการตรวจสอบเชิงเทคนิคแค่รัน PageSpeed Insights แล้วดูจำนวนข้อผิดพลาดใน GSC จริง ๆ แล้ว SEO เชิงเทคนิคมี 4 ระดับ: Google crawl ได้ไหม (crawl), crawl แล้วจัดเก็บไหม (index), เนื้อหาถูกต้องไหม (render), ทำงานเร็วไหม (performance) ถ้าด้านใดมีปัญหา งานชั้นบนก็เสียเปล่าทั้งหมด
ข้อสรุปที่ขัดกับสัญชาตญาณ: อัตราการจัดเก็บ 100% ไม่ใช่เป้าหมาย เว็บไซต์ 1,000 หน้า ถ้า 900 หน้าเป็นเนื้อหาบาง หน้าพารามิเตอร์ หน้าผลการค้นหา แล้ว Google จัดเก็บทั้งหมด กลับจะฉุดคะแนนคุณภาพโดยรวมลง วิธีที่ถูกต้องคือตั้ง noindex หน้าไร้คุณภาพด้วยตัวเอง แล้วรวมงบประมาณการ crawl ไปที่ 100 หน้าที่มีคุณค่าจริง ๆ
| 象限 | ปัญหาหลัก | ถ้าเกิดปัญหา | น้ำหนักสัดส่วน |
|---|---|---|---|
| การ crawl (Crawling) | Googlebot เข้าถึงหน้าของคุณได้ไหม | หน้าไม่ถูกเข้าถึงเลย | ชั้นพื้นฐาน ถ้าไม่ผ่านถือว่าตกทั้งหมด |
| การ index (Indexing) | crawl แล้วจัดเก็บเข้า index ไหม | หน้าไม่เข้าไปในฐานข้อมูล Google | ชั้นพื้นฐาน ถ้าไม่ผ่านถือว่าตกทั้งหมด |
| การ render (Rendering) | HTML ที่ crawl ได้มีเนื้อหาครบถ้วนไหม | เนื้อหาถูกต้องแต่ Google อ่านไม่เข้าใจ | จุดที่เว็บสมัยใหม่เจอบ่อย |
| ประสิทธิภาพ (Performance) | หน้าโหลดเร็วไหม | อันดับถูกลงโทษหรือผู้ใช้หายไป | หนึ่งในปัจจัยด้านอันดับ |
ความสัมพันธ์ของ 4 ด้านเป็นลำดับขั้น: เริ่มจากให้ crawl ได้ก่อน แล้วให้ index ได้ จากนั้นให้ render ถูกต้อง สุดท้ายค่อยปรับ performance ลำดับห้ามสลับ ถ้า robots.txt บล็อกหน้าสำคัญไว้ ต่อให้ปรับ LCP ยังไงก็ไม่มีประโยชน์ และ Google SEO ความสัมพันธ์กับโมดูลอื่น: การตรวจสอบเชิงเทคนิคเป็นรากฐาน structured data Schema คือการสร้างบ้านบนรากฐาน การปรับแต่ง Core Web Vitals คือการขยายเชิงลึกของด้าน performance
2. ด้านการ crawl: 5 จุดตรวจ
ปัญหาที่รากที่สุดคือการเก็บข้อมูล (Crawl) ถ้า Googlebot เข้าหน้าเว็บของคุณไม่ได้ ทุกอย่างที่เหลือก็ไม่มีความหมาย
| # | รายการตรวจสอบ | เกณฑ์ผ่าน | เครื่องมือ | ปัญหาที่พบบ่อย |
|---|---|---|---|---|
| 1 | robots.txt ไม่บล็อกโดยไม่มีเหตุผล | หน้าสำคัญไม่ถูก Disallow | เครื่องมือทดสอบ robots ใน GSC | ตอนเปลี่ยนเว็บเขียน Disallow: / ผิดพลาด |
| 2 | เข้าถึง XML Sitemap ได้ | ตอบกลับ 200 ไม่มีข้อผิดพลาด | รายงาน Sitemap ใน GSC | เขียน path ของ Sitemap ผิดหรือยังไม่ได้ส่ง |
| 3 | ข้อผิดพลาดการเก็บข้อมูล 4xx/5xx < 1% | สัดส่วนข้อผิดพลาด 404/500 ต่ำกว่า 1% | สถิติการเก็บข้อมูลใน GSC | หลังเปลี่ยนเว็บมี 404 เยอะแต่ไม่ได้ทำ 301 |
| 4 | งบประมาณการเก็บข้อมูล (Crawl Budget) ไม่ถูกใช้เปล่า | หน้า parameter/หน้าซ้ำไม่กิน crawl budget | สถิติการเก็บข้อมูลใน GSC + วิเคราะห์ log | หน้าผลการค้นหาถูกเก็บข้อมูลไม่จำกัด |
| 5 | ลิงก์ภายในไม่มีลิงก์เสีย | ลิงก์ภายในทั้งหมดตอบกลับ 200 | การ crawl ด้วย Screaming Frog | บทความเก่าลิงก์ไปยังหน้าที่ถูกลบแล้ว |
ตัวอย่างที่ 1: หลังเปลี่ยนเว็บ ทีมเทคนิคเขียน robots.txt เป็น Disallow: / แล้วลืมแก้กลับ สามสัปดาห์ต่อมา หน้า “เก็บข้อมูลแล้วแต่ยังไม่จัดทำดัชนี” ใน GSC เพิ่มจาก 200 เป็น 2,000 วิธีตรวจพบ: เมื่อรายงานความครอบคลุมมีหน้า “เก็บข้อมูลแล้วแต่ยังไม่จัดทำดัชนี” เพิ่มขึ้นผิดปกติ ให้ตรวจ robots.txt เป็นอันดับแรก หลังแก้ไขแล้วใช้เครื่องมือตรวจสอบ URL ขอจัดทำดัชนีด้วยตนเอง จะกลับมาปกติภายใน 1 ถึง 3 วัน
Crawl Budget: Google จำกัดความถี่ในการเก็บข้อมูลของแต่ละเว็บไซต์ ถ้าเว็บมี URL ที่มี parameter เยอะ (เช่น /products?sort=price&filter=red) Googlebot จะใช้เวลาไปกับการ crawl หน้าซ้ำเหล่านี้จำนวนมาก หน้าสินค้าที่สำคัญจริงกลับไม่ได้คิว วิธีแก้คือใช้ robots.txt บล็อก URL ที่มี parameter หรือใช้ canonical ชี้ไปยังเวอร์ชันหลัก
สาม ควอดรันต์การจัดทำดัชนี: 5 รายการตรวจสอบ
Google เก็บข้อมูลหน้าเว็บของคุณได้ ไม่ได้หมายความว่าจะนำหน้าเว็บเข้าสู่ฐานข้อมูลดัชนี ควอดรันต์การจัดทำดัชนีตรวจสอบว่า: หน้าที่ควรถูกจัดทำดัชนีถูกจัดทำแล้วหรือยัง และหน้าที่ไม่ควรถูกจัดทำดัชนีกลับถูกจัดทำหรือไม่
| # | รายการตรวจสอบ | เกณฑ์ผ่าน | เครื่องมือ | ปัญหาที่พบบ่อย |
|---|---|---|---|---|
| 6 | หน้าสำคัญทั้งหมดถูกจัดทำดัชนี | อัตราการจัดทำดัชนีหน้าสินค้าหลัก/หน้าบทความ > 95% | รายงานความครอบคลุมใน GSC | หน้าสินค้าใหม่ยังไม่ได้ส่ง Sitemap |
| 7 | ไม่มีการตั้งค่า noindex ผิดพลาด | หน้าเว็บจริงไม่มีแท็ก noindex | Screaming Frog + GSC | ลืมลบ noindex ในสภาพแวดล้อมพัฒนา |
| 8 | ไม่มีเนื้อหาซ้ำ | เนื้อหาเดียวกันมีหลายเวอร์ชัน URL < 5% | Siteliner + Screaming Frog | HTTP/HTTPS ซ้ำกันแบบมีและไม่มี www |
| 9 | แท็ก canonical ถูกต้อง | ทุกหน้ามี canonical อ้างอิงตัวเอง | GSC + เครื่องมือตรวจสอบ URL | canonical ชี้ไปยังหน้าผิด |
| 10 | อัตราการจัดทำดัชนีสมเหตุสมผล | จำนวนหน้าที่จัดทำดัชนีสอดคล้องกับจำนวนหน้าที่มีคุณค่า | รายงานความครอบคลุมใน GSC | หน้าเนื้อหาบางถูกจัดทำดัชนีจำนวนมาก |
ตัวอย่างที่ 2: หน้าลิสต์สินค้าของเว็บ B2B มีตัวกรอง 50 ชุด แต่ละชุดสร้าง URL หนึ่งอัน (/products?category=valve&material=steel) Google จัดทำดัชนีทั้งหมด จำนวนดัชนีรวมเพิ่มจาก 200 เป็น 2,000 ผลลัพธ์คือ: เว็บถูกตัดสินว่ามีเนื้อหาซ้ำและเนื้อหาบางจำนวนมาก คะแนนคุณภาพโดยรวมลดลง อันดับหน้าสินค้าแบบละเอียดกลับตกลง วิธีแก้: ใส่ noindex ให้ URL ตัวกรองที่มี parameter หรือใช้ robots.txt บล็อกโดยตรง
การตั้งค่า noindex ผิดเป็นปัญหาที่พบบ่อยและร้ายแรงที่สุด ในช่วงพัฒนาทีมใส่ noindex ไว้ใน head ทั่วทั้งเว็บเพื่อไม่ให้ Google เห็นเว็บทดสอบ แต่พอขึ้นจริงกลับลืมลบ ผ่านไป 3 เดือน ค้นหาแบรนด์ใน Google ก็ยังหาหน้าเว็บทางการไม่เจอ วิธีตรวจสอบ: ใช้ Screaming Frog ครอวล์แล้วกรองหา «Meta robots contains noindex» หน้าจริงควรได้ผลลัพธ์ 0 รายการ
สี่ ควอดรันต์การเรนเดอร์: ตรวจ 5 ข้อ
เว็บสมัยใหม่ใช้ JS เรนเดอร์กันมาก (React, Vue, Next.js แบบ client-side rendering) Googlebot รัน JS ได้ แต่ไม่ใช่แบบเรียลไทม์ — จะครอวล์ HTML ดิบเข้า คิว ก่อน แล้วค่อยใช้ Chrome เรนเดอร์ในคิวอีกทีในอีกหลายวันต่อมา ความล่าช้าและความล้มเหลวในการเรนเดอร์นี้คือหลุมพรางที่ใหญ่ที่สุดของ SEO เว็บ SPA
| # | รายการตรวจสอบ | เกณฑ์ผ่าน | เครื่องมือ | ปัญหาที่พบบ่อย |
|---|---|---|---|---|
| 11 | Googlebot เรนเดอร์ JS ได้ | เครื่องมือตรวจสอบ URL แสดง «เรนเดอร์แล้ว» | เครื่องมือตรวจสอบ URL ใน GSC | JS error ทำให้เรนเดอร์ล้มเหลว |
| 12 | เนื้อหาหลักอยู่ในโค้ด HTML | title, H1, ย่อหน้าแรกของเนื้อหาอยู่ใน HTML ดิบ | ดูซอร์สโค้ดหน้าเว็บ (ไม่ใช่ F12) | เรนเดอร์ฝั่ง client ล้วน ซอร์สโค้ดว่างเปล่า |
| 13 | ไม่มี error เรื่องการเรนเดอร์ในคอนโซล | Chrome DevTools Console 无 Error | Chrome DevTools | เรียก API ไม่สำเร็จทำให้เนื้อหาว่างเปล่า |
| 14 | โครงสร้างข้อมูลถูก parse ได้ | Rich Results Test ไม่มี error | ทดสอบ Rich Results | JSON-LD ถูก inject แบบไดนามิกใน JS |
| 15 | แท็ก hreflang ถูกต้อง | หน้าหลายภาษาชี้หากันถูกต้อง | GSC + เครื่องมือตรวจ hreflang | hreflang วนลูปหรือชี้ไปภาษาที่ผิด |
จุดตัดสินสำคัญ: ใช้ «ดูซอร์สโค้ดหน้าเว็บ» (Ctrl+U ไม่ใช่ F12) ดู HTML ดิบ ถ้าเห็น title, H1, ย่อหน้าแรกของเนื้อหาใน HTML ดิบ แปลว่าเป็น SSR หรือ SSG Google อ่านเนื้อหาได้ตั้งแต่ครอว์ลรอบแรก แต่ถ้า HTML ดิบมีแค่ div#app กับแท็ก script เต็มไปหมด แปลว่าเป็น client-side rendering ล้วน (CSR) Google ต้องรอคิวเรนเดอร์ด้วย Chrome ก่อนจึงจะอ่านได้
เว็บหลายภาษามักตั้งค่า hreflang ผิดบ่อยมาก: หน้าภาษาเยอรมันชี้ไปหน้าภาษาอังกฤษ หน้าภาษาอังกฤษชี้มาที่ตัวเอง หรือขาด x-default วิธีตั้งค่าดูที่Hreflang การรองรับหลายภาษา การ inject โครงสร้างข้อมูลผ่าน JS แบบไดนามิก แม้สุดท้าย Google จะเรนเดอร์เจอ แต่คิวครอว์ลมักตกหล่น JSON-LD ควรเขียนไว้ใน HTML ดิบจะดีที่สุด structured data Schema ขั้นตอนการตรวจสอบของ ตรงกับส่วนนี้
ห้า ควอดรันต์ประสิทธิภาพ: ตรวจ 5 ข้อ
ประสิทธิภาพคือตัวชี้วัดหลักสามตัวของ Core Web Vitals บวกกับความใช้งานได้บนมือถือและ HTTPS ประสิทธิภาพไม่ใช่แค่ «โหลดเร็ว» แต่เป็นปัจจัยจัดอันดับของ Google — ตั้งแต่ปี 2021 Core Web Vitals กลายเป็นสัญญาณจัดอันดับอย่างเป็นทางการ
| # | รายการตรวจสอบ | เกณฑ์ผ่าน | เครื่องมือ | ปัญหาที่พบบ่อย |
|---|---|---|---|---|
| 16 | LCP (การวาดเนื้อหาที่ใหญ่ที่สุด) | ≤ 2.5 วินาที | PageSpeed Insights + CrUX | รูปภาพแรกไม่ถูกบีบอัด ฟอนต์บล็อกการโหลด |
| 17 | INP (Interaction to Next Paint) | ≤ 200 มิลลิวินาที | PageSpeed Insights + CrUX | สคริปต์บุคคลที่สามบล็อก main thread |
| 18 | CLS (Cumulative Layout Shift) | ≤ 0.1 | PageSpeed Insights + CrUX | รูปไม่มีขนาดกำหนด พื้นที่โฆษณาไม่ได้จองไว้ |
| 19 | ใช้งานได้บนมือถือ | ไม่มีข้อผิดพลาดด้านเลย์เอาต์ที่ทำให้ใช้งานไม่ได้ | รายงานความใช้งานได้บนมือถือใน GSC | องค์ประกอบที่แตะเล็กเกินไป เลื่อนแนวนอน |
| 20 | HTTPS ทั่วทั้งเว็บไม่มี mixed content | ทรัพยากรทั้งหมดโหลดผ่าน HTTPS | คอนโซลเบราว์เซอร์ + GSC | รูปภาพ/CSS ยังอ้างอิงลิงก์ HTTP |
ตัวอย่างที่ 3: เว็บ B2B วัด PageSpeed ได้ LCP 4.2 วินาที และ INP 350 มิลลิวินาที ตรวจสอบพบว่าแบนเนอร์หน้าแรกเป็น PNG ขนาด 3MB ที่ยังไม่ได้บีบอัด และหน้าแรกโหลดสคริปต์ติดตามจากบุคคลที่สามถึง 8 ตัว แนวทางแก้ไข: แปลงรูปเป็น WebP แล้วบีบอัดเหลือ 200KB และใช้ Tag Manager หน่วงการโหลดสคริปต์ สองสัปดาห์ต่อมา LCP ลดเหลือ 1.8 วินาที และ INP ลดเหลือ 120 มิลลิวินาที ดูวิธีทำได้ที่การปรับแต่ง Core Web Vitals。
ลำดับความสำคัญด้านประสิทธิภาพ: LCP มาก่อน INP และ INP มาก่อน CLS ถ้า LCP ไม่ผ่าน ให้ตรวจรูปภาพหน้าแรกก่อน (บีบอัด, lazy load, preload) และตรวจ TTFB จากนั้นค่อยตรวจทรัพยากรที่บล็อกการเรนเดอร์CDN เร่งความเร็วทั่วโลก ช่วยให้ TTFB และ LCP ของเว็บที่ให้บริการต่างประเทศดีขึ้นโดยตรง
FAQ คำถามที่พบบ่อย
ควรทำ Technical SEO Audit บ่อยแค่ไหน?
ยิ่งอัตราการ index สูงยิ่งดีหรือไม่?
ทำ SEO กับเว็บ React/Vue SPA อย่างไร?
Crawl budget คืออะไร? รู้ได้อย่างไรว่าถูกใช้ไปอย่างเปล่าประโยชน์?
LCP ไม่ผ่าน จะปรับปรุงเร็ว ๆ ได้อย่างไร?
จะรู้ได้อย่างไรว่า noindex ถูกตั้งค่าผิด และแก้อย่างไร?
ทิ้งท้าย
Technical SEO Audit คือรากฐานของงาน SEO ทั้งหมด: เนื้อหาเขียนดีแค่ไหน สร้าง backlink แพงแค่ไหน ถ้า Google ครอว์ลหน้าไม่ได้หรือครอว์ลได้แต่เจอ JS เปล่า ๆ ทุกอย่างก็เสียเปล่า การตรวจ 20 ข้อไม่ใช่งานทำครั้งเดียว แต่ต้องทำทุกไตรมาส
ลงมือสามขั้นตอน: สัปดาห์นี้ดึงข้อมูลจากรายงาน Coverage และ Crawl Stats ของ GSC มาเทียบกับรายการตรวจ 20 ข้อแล้วติ๊กทีละข้อ สัปดาห์หน้าจัดลำดับความสำคัญของข้อที่ไม่ผ่าน — แก้เรื่องการครอว์ลและจัดทำดัชนีก่อน (เป็นเงื่อนไขตัดสิทธิ์) จากนั้นแก้การเรนเดอร์ สุดท้ายปรับปรุงประสิทธิภาพ สัปดาห์ที่สามหลังแก้เสร็จ ใช้เครื่องมือตรวจสอบ URL และ PageSpeed ทดสอบซ้ำ
ประโยคที่จำง่าย ๆ: Technical SEO ไม่ใช่ยิ่งซับซ้อนยิ่งดี แต่ยิ่งสะอาดยิ่งดี — Googlebot ครอว์ลเร็ว จัดเก็บแม่น เรนเดอร์ถูก รันเสถียร ทำครบสี่ข้อนี้ ที่เหลือปล่อยให้เป็นเรื่องของเนื้อหาและ backlink