การปรับแต่งทางเทคนิคสำหรับ GEO: โครงสร้างหน้า ความเร็วในการโหลด และ structured data ที่ส่งผลต่อการดึงข้อมูลของ AI
หนึ่ง、L1 ประตูเข้า: bot อ่านหน้าเว็บคุณได้หรือไม่
ชั้นแรกของการปรับแต่งทางเทคนิคไม่ใช่การปรับแต่ง แต่คือการเก็บกวาดกับดัก ปัญหาทางเทคนิค GEO ที่พบบ่อยที่สุดในเว็บไซต์ B2B คือ bot เข้ามาไม่ได้เลย สาเหตุมีสามข้อ: robots.txt บล็อกผิดพลาด, ไฟร์วอลล์สกัดตาม UA, เรนเดอร์ด้วย JS ล้วนแล้วได้เปลือกเปล่า
| คำถาม | วิธีตรวจสอบ | การแก้ไข |
|---|---|---|
| robots บล็อก AI bot ผิดพลาด | ตรวจสอบ robots.txt และสถานะโค้ดของ bot | Allow GPTBot, OAI-SearchBot, PerplexityBot อย่างชัดเจน |
| WAF สกัด UA ที่ไม่รู้จัก | ทดสอบด้วย curl พร้อมใส่ UA ของ bot | ใส่ UA ของ bot เหล่านี้ใน whitelist |
| เรนเดอร์ด้วย JS ล้วน หน้าจอแรกว่างเปล่า | curl ดึง HTML แล้ว grep เนื้อหา | ใช้ SSR หรือ SSG |
| หน้าเวอร์ชันจีน/อังกฤษไม่ตรงกัน | curl ทั้งสองเวอร์ชันแยกกัน | ให้ทั้งสองเวอร์ชันแสดงเนื้อหาทันที |
วิธีตรวจสอบค่อนข้างเจาะจง กรอง UA ของ bot เหล่านี้ใน log ของเซิร์ฟเวอร์ย้อนหลัง 30 วัน: GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Googlebot ถ้าสถานะโค้ดเป็น 4xx ทั้งหมด แปลว่าถูกสกัด; ถ้ามี 200 แต่เข้าถึงแค่หน้าแรก แปลว่าลิงก์ภายในหรือ sitemap ไม่ได้พา bot ไปถึงหน้าชั้นลึก วิธีเขียน sitemap ดูได้ที่การปรับโครงสร้างเว็บและการเปลี่ยนโดเมน ในส่วนโครงสร้างลิงก์
ตัวอย่างจากสถานการณ์จริง: ลูกค้ารายหนึ่งที่ทำเว็บไซต์ WordPress แบบ standalone ติดตั้งปลั๊กอินความปลอดภัยที่บล็อก bot ที่ไม่รู้จักทั้งหมดโดยค่าเริ่มต้น ผ่านไปครึ่งปีเราตรวจ log พบว่า PerplexityBot ไม่เคยเข้ามาเลยสักครั้ง หลังจากเพิ่มเข้า whitelist สัปดาห์ที่สอง bot เริ่มเข้าถึงหน้าสินค้า ผ่านไป 4 สัปดาห์คำตอบของ Perplexity เริ่มมีการอ้างอิงถึงบริษัทนี้ ปัญหานี้ไม่ต้องแก้เนื้อหา แก้แค่บรรทัดเดียวในการตั้งค่า
สอง、L2 ความเร็ว: TTFB และ LCP กำหนดว่า bot จะมาบ่อยแค่ไหน
SEO แบบเดิมมองความเร็วหน้าเว็บเป็นปัญหาประสบการณ์ผู้ใช้ Core Web Vitals ก็ออกแบบมาสำหรับคนจริง แต่สำหรับ AI bot ความเร็วกำหนดลำดับความสำคัญและความถี่ในการดึงข้อมูล bot เรียงลำดับในคิวตามเวลาตอบสนอง หน้าที่มี TTFB เกิน 2 วินาทีจะถูกจัดไปอยู่ท้าย ความถี่ในการกลับมาดึงใหม่จะยืดจาก 3 วันเป็น 2 สัปดาห์
| ตัวชี้วัด | เกณฑ์ผ่าน | ผลกระทบเมื่อไม่ผ่านเกณฑ์ | แนวทางปรับปรุง |
|---|---|---|---|
| TTFB | ≤ 1.5 วินาที | ลดความสำคัญในการดึงข้อมูล | แคช CDN, อัปเกรด PHP |
| LCP | ≤ 2.5 วินาที | chunk หน้าแรกไม่ครบ | บีบอัดรูปภาพ, inline critical CSS |
| INP | ≤ 200 มิลลิวินาที | กระทบ bot น้อย แต่กระทบคนจริงมาก | เลื่อนโหลดสคริปต์บุคคลที่สาม |
| CLS | ≤ 0.1 | กระทบ GEO น้อย | กำหนดอัตราส่วนกว้างสูงรูปภาพ |
สำหรับ GEO แล้ว TTFB และ LCP สำคัญที่สุด ส่วน INP และ CLS เน้นตอบโจทย์ผู้ใช้จริง กระทบการดึงข้อมูลของ bot ไม่มาก ไม่จำเป็นต้องปรับแต่งมากเกินไป ดูค่า threshold และลำดับความสำคัญในการปรับแต่งได้ที่Core Web Vitals การเลือกโหนด CDN มีผลต่อ TTFB มากที่สุด เว็บ B2B ที่ออกตลาดต่างประเทศแนะนำให้ตั้งโหนดอเมริกาเหนือและยุโรปไว้ด้วย ดูได้ที่CDN เร่งความเร็วทั่วโลก。
ข้อสังเกตที่ขัดกับสัญชาตญาณ: หน้าที่โหลดช้าไม่ใช่ “ปัญหาประสบการณ์ผู้ใช้” แต่เป็นปัญหาความถี่ในการดึงข้อมูลของ GEO หน้าสินค้าที่มี TTFB 3 วินาที เนื้อหาดีเท่าคู่แข่ง แต่ bot มาสองสัปดาห์ครั้ง เนื้อหาที่คุณอัปเดตต้องรอสองสัปดาห์กว่าโมเดลจะเห็น อัตราการอ้างอิงจึงตามหลัง ถ้าลด TTFB ให้ต่ำกว่า 1.5 วินาที เท่ากับทำให้ bot มาเยี่ยมบ่อยขึ้น 4 ถึง 5 เท่า
สาม L3 เข้าใจ: โครงสร้างหน้าเว็บทำให้โมเดลไม่ต้องเดา
เมื่อ bot อ่านได้และอ่านเร็วแล้ว ยังต้องอ่านเข้าใจด้วย เลเวลนี้พึ่งโครงสร้างหน้าเว็บและ structured data โมเดลใช้ลำดับหัวข้อ ตาราง และ anchor ของลิงก์ใน HTML ตัดสินว่าเนื้อหาพูดถึงอะไร เมื่อโครงสร้างสับสน มันต้องเดาจากบริบท โอกาสเดาผิดก็สูงขึ้น
| รายการโครงสร้าง | วิธีเขียนที่ผ่าน | วิธีเขียนที่ไม่ผ่าน |
|---|---|---|
| H1 | ไม่ซ้ำกันในแต่ละหน้า มีคีย์เวิร์ดหลัก | มี H1 หลายอันหรือไม่มี H1 |
| ลำดับชั้น H2/H3 | ไล่ตามตรรกะเนื้อหา | ข้ามระดับ ใช้ H4 เป็นหัวข้อย่อย |
| ตาราง | มี thead แถวแรกคือค่า threshold | ใช้รูปภาพประกอบเป็นตาราง |
| จุดยึด | ทุก H2 มี id | ไม่มี id โมเดลชี้ไปยังย่อหน้าไม่ได้ |
| ลิงก์ภายใน | anchor text เป็นคีย์เวิร์ด | anchor text เป็น “คลิกที่นี่” |
structured data สามชุด (Organization, WebSite, BreadcrumbList) ต้องใส่ทั้งเว็บ นี่คือบัตรประชาชนเอนทิตีที่ส่งให้โมเดล หน้าสินค้าและหน้า article เพิ่ม Product, Article, FAQPage ฟิลด์ต้องตรงกับเนื้อหาที่มองเห็น จับคู่ผิดจะกระตุ้น manual action ของ Google ดูรายการ markup ได้ที่structured data Schema วิธีที่เอนทิตีถูกจดจำในคำตอบ AI ดูได้ที่Knowledge Graph และ Entity Markup。
ตัวอย่างตามสถานการณ์: ตารางสเปกสินค้าถ้าประกอบจากรูปภาพ bot จะเห็นเป็นรูปภาพ OCR อาจอ่านตัวเลขในตารางไม่ออก แต่ถ้าใช้ HTML table จริง เขียนใน thead ว่า “อุณหภูมิสูงสุดในการทำงานของวาล์วผีเสื้อ PN16” โมเดลก็หยิบแถวนี้เป็นข้อเท็จจริงได้เลย ขอบเขตของการแปลเป็นภาษาท้องถิ่นของรูปภาพดูได้ที่การจัดการแผนภูมิของเว็บหลายภาษา。
สี่ ลำดับการตรวจสอบและกำหนดเวลาขึ้นไลน์
อย่าแก้ทั้งสามเลเวลพร้อมกัน ทำตามลำดับ แต่ละเลเวลมีเครื่องมือตรวจสอบและกำหนดเวลาชัดเจน
| ขั้นตอน | เครื่องมือ | กรอบเวลา | เกณฑ์ผ่าน |
|---|---|---|---|
| 1 ตรวจ log ของ robots | กรอง UA ของ bot ใน log เซิร์ฟเวอร์ | วันเดียวกัน | AI bot ทั้ง 5 ตัวได้สถานะ 200 |
| 2 ทดสอบ TTFB/LCP | Lighthouse、PageSpeed | แก้ภายใน 3 วัน | TTFB ≤ 1.5s，LCP ≤ 2.5s |
| 3 ตรวจ Schema | Rich Results Test | วันเดียวกัน | สามชุดไม่มีข้อผิดพลาด |
| 4 ตรวจลำดับชั้น H | ปลั๊กอินเบราว์เซอร์ outline | วันเดียวกัน | H1 ไม่ซ้ำ ลำดับชั้นไม่ข้ามระดับ |
| 5 รอ bot ดึงข้อมูลใหม่ | เฝ้าดู log เซิร์ฟเวอร์ต่อเนื่อง | 1 ถึง 2 สัปดาห์ | ความถี่ที่ bot เข้าถึงเพิ่มขึ้น |
แก้เสร็จแล้วอย่าหวังว่าวันรุ่งขึ้นจะมีการอ้างอิงเพิ่มขึ้นทันที บอทต้องกลับมาเก็บข้อมูลใหม่ใช้เวลา 1 ถึง 2 สัปดาห์ และการอัปเดตดัชนีของโมเดลต้องใช้เวลาอีก 1 ถึง 2 สัปดาห์ ดังนั้นหลังปรับแต่งทางเทคนิคแล้วควรรออย่างน้อย 4 สัปดาห์ก่อนรันชุดคำถามเดิมเพื่อดูว่าอัตราการอ้างอิงเปลี่ยนไปแค่ไหน ช่องว่างของเวลานี้เป็นสิ่งที่ต้องคำนึงถึงในการออกแบบการทดลอง GEO ดูได้ที่การออกแบบการทดลอง GEO。
ความเข้าใจผิดที่พบบ่อยคือเริ่มเขียนเนื้อหาใหม่ตั้งแต่แรก ถ้า L1 กับ L2 ยังไม่ผ่าน เนื้อหาใหม่ก็ไปไม่ถึงโมเดลเหมือนเนื้อหาเก่า ต้องเคลียร์ปัญหาก่อน เร่งความเร็วเป็นลำดับถัดไป แล้วค่อยพูดถึงเนื้อหา ถ้าสลับลำดับสามชั้นนี้ ผลตอบแทนของแต่ละขั้นจะลดลง
ยังมีอีกจุดที่มักถูกมองข้าม คือชั้นเทคนิคของเว็บไซต์หลายภาษาต้องตรวจแยกต่างหาก ถ้าเวอร์ชันภาษาเยอรมัน สเปน และอาหรับใช้ robots ชุดเดียวกัน แต่โหนด CDN ตั้งค่าไว้แค่สหรัฐอเมริกา TTFB ของตลาดที่ไม่ใช่ภาษาอังกฤษจะสูง และอัตราการอ้างอิงโดย AI ในภาษานั้นก็จะไม่ขึ้น GEO หลายภาษา ที่พูดถึงตลาดภาษาเยอรมัน สเปน และอาหรับ ในทางเทคนิคคือต้องทำสามอย่างให้เสร็จก่อน คือโหนดในพื้นที่ ป้าย hreflang ท้องถิ่น และแคชท้องถิ่น แล้วค่อยพูดถึงเนื้อหา
ตัวอย่างตามสถานการณ์: ลูกค้ารายหนึ่งที่ทำธุรกิจหลายภาษาสำหรับตลาดต่างประเทศ เวอร์ชันภาษาอังกฤษมีอัตราการอ้างอิงปกติ แต่เวอร์ชันภาษาเยอรมันแทบเป็นศูนย์ใน Gemini ตรวจดูบันทึกพบว่าเมื่อ Googlebot เข้าถึงเวอร์ชันภาษาเยอรมันจากโหนดในยุโรป TTFB อยู่ที่ 3.2 วินาที จึงถูกจัดไปต่อท้ายคิว หลังจากเพิ่มโหนด CDR ในยุโรปและแคชหน้าเวอร์ชันภาษาเยอรมันที่แฟรงก์เฟิร์ต TTFB ลดลงเหลือ 1.1 วินาที สามสัปดาห์ต่อมาอัตราการอ้างอิงของเวอร์ชันภาษาเยอรมันก็เริ่มไต่ขึ้น ปัญหานี้ไม่เกี่ยวกับเนื้อหาเลย เป็นเพียงชั้นเทคนิคที่ตกหล่นไปหนึ่งภูมิภาค
ขอเตือนเป็นข้อสุดท้าย: หลังทำ SEO เชิงเทคนิคเสร็จแล้ว อย่าเปลี่ยน URL บ่อย ทุกครั้งที่ปรับโครงสร้างเว็บต้องทำ 301 โยกเส้นทางให้ครบ ไม่งั้นลิงก์เก่าที่บอทเพิ่งคลานจนคุ้นจะขาด และลิงก์ใหม่ต้องต่อคิวเริ่มนับหนึ่งใหม่ วิธีวางแผน 301 ตอนย้ายเว็บดูได้ที่การปรับโครงสร้างเว็บและการเปลี่ยนโดเมน งานเทคนิคเป็นงานที่ต้องใช้เวลา พอลงตัวแล้วก็อย่าไปยุ่งกับมันบ่อย
ทำการตรวจสอบทางเทคนิคสามชั้นให้เป็นกิจวัตรประจำเดือน วางไว้รวมกับรายการประจำอื่นๆ ใน ช่วงดูแลเว็บไซต์ รันบันทึกบอทหนึ่งครั้ง Lighthouse หนึ่งครั้ง และ Rich Results Test หนึ่งครั้งต่อเดือน หนี้ทางเทคนิคไม่เหมือนหนี้เนื้อหาที่มองเห็นได้ด้วยตาเปล่า แต่มันกำหนดว่าเนื้อหาของคุณจะถูกโมเดลอ่านได้หรือไม่ เว็บไซต์ที่มั่นคง รวดเร็ว และมีโครงสร้างชัดเจนคือพื้นฐานของงานเนื้อหา GEO ทั้งหมด
FAQ คำถามที่พบบ่อย
การปรับแต่งทางเทคนิค GEO ควรเริ่มจากชั้นไหนก่อน?
ทำไม TTFB ช้าจึงส่งผลต่อการอ้างอิงโดย AI?
เว็บที่เรนเดอร์ด้วย JS ล้วนส่งผลต่อ GEO อย่างไร?
ข้อมูลโครงสร้าง Schema ช่วยเรื่องการอ้างอิงของ AI มากแค่ไหน?
หลังแก้ไขการปรับแต่งทางเทคนิค ต้องรอนานแค่ไหนจึงจะเห็นการอ้างอิงเพิ่มขึ้น?
ตารางพารามิเตอร์ในหน้าเว็บควรใช้รูปภาพหรือ HTML table?
ทิ้งท้าย
ทีมเนื้อหามักมองข้ามชั้นเทคนิคของ GEO กันบ่อย ๆ ทุกคนต่างเขียนบทความให้ดีขึ้น แต่ต่อให้บทความดีแค่ไหน ถ้า bot เข้ามาไม่ได้ มา ช้า หรืออ่านไม่เข้าใจ ทุกอย่างก็เปล่าประโยชน์ การปรับแต่งทางเทคนิคสามชั้นก็คือการสร้างถนนให้โมเดลนั่นเอง เริ่มจากเปิดประตูใหญ่ก่อน จากนั้นปรับพื้นถนนให้เรียบ แล้วสุดท้ายวาดป้ายบอกทางให้ชัดเจน
ลงมือทำสามขั้นตอน: สัปดาห์นี้ใช้ log ของเซิร์ฟเวอร์ตรวจสถานะของ AI bot 5 ตัว แล้วเพิ่มตัวที่ถูกบล็อกเข้า whitelist สัปดาห์หน้าใช้ Lighthouse วัด TTFB และ LCP กด TTFB ให้ต่ำกว่า 1.5 วินาที สัปดาห์ที่สามใช้ Rich Results Test ตรวจ Schema ชุดสามอย่าง แล้วเติม markup ให้ครบทั้งเว็บ ทำสามอย่างนี้เสร็จ รอ 4 สัปดาห์แล้วรันชุดคำถาม คุณจะเห็นอัตราการอ้างอิงกระโดดขึ้นเป็นครั้งแรก
ประโยคเดียวที่จำง่าย: การทำ GEO ให้เทคโนโลยีไม่ใช่เรื่องที่ทำให้คนดู แต่เป็นการปูทางให้บอท — เปิดประตู ปูถนนให้เรียบ ปักป้ายบอกทางให้ชัด เนื้อหาถึงจะไปถึงหน้ากำลังของโมเดลได้