ทดสอบและดีบักข้อมูล Structured Data: ตรวจสอบด้วย Rich Results Test และแก้ไขข้อผิดพลาด
1. หน้าที่ต่างกันของเครื่องมือทดสอบสองชุด
หลายทีมคิดว่าเขียน Schema ลงในหน้าเว็บแล้วก็จบ แต่ปรากฏว่าใน GSC แดงเต็มไปหมด การดีบัก Structured Data ต้องใช้เครื่องมือสองชุด แต่ละชุดดูแลคนละส่วน
Rich Results Test ใช้ทดสอบหน้าเดียว วาง URL หรือวางโค้ด เพื่อดูว่าหน้านี้สร้าง Rich Results ได้หรือไม่ Schema Markup Validator ใช้ตรวจว่า JSON-LD ถูกต้องตามไวยากรณ์หรือไม่
| เครื่องมือ | ทดสอบอะไร | ใช้เมื่อไหร่ | ข้อจำกัด |
|---|---|---|---|
| ทดสอบ Rich Results | คุณสมบัติ Rich Results ของหน้าเดียว | ทดสอบทีละหน้าก่อนเปิดใช้งาน | ทดสอบเฉพาะหน้าที่คุณวาง |
| ตัวตรวจสอบ Schema | ความถูกต้องตามไวยากรณ์ของ JSON-LD | ตรวจในเครื่องขณะเขียนโค้ด | ไม่ได้หมายความว่า Google จะแสดงจริง |
| รายงาน Rich Results ใน GSC | หน้าที่ตรวจสอบแล้วทั้งเว็บ | ดูทุกสัปดาห์หลังเปิดใช้งาน | ข้อมูลล่าช้า 2 ถึง 3 วัน |
วิธีเลือกประเภท Schema และมีฟิลด์อะไรบ้าง ดูที่structured data Schema และ รายการ Schema สำหรับ Structured Data ทั้งหมด บทความนี้อธิบายวิธีทดสอบหลังเขียนเสร็จ และวิธีแก้เมื่อผิดพลาด
ที่รายงานของเครื่องมือสามชุดไม่ตรงกันเป็นเรื่องปกติ: ทดสอบในเครื่องผ่านแล้ว GSC อาจต้องรออีก 2 ถึง 3 วันจึงจะสะท้อนผล อย่าด่วนสรุปเพียงเพราะในเครื่องผ่านแล้ว
2. ข้อผิดพลาดกับคำเตือน: ควรแก้ประเภทไหนก่อน
ทุกข้อความแจ้งในรายงานดีบักต้องจัดระดับก่อนจัดการ ถ้าแก้คำเตือนทีละข้อเหมือนเป็นข้อผิดพลาดจะเสียเวลาหลายวัน
| ระดับ | ความหมาย | กระทบ Rich Results หรือไม่ | ลำดับความสำคัญในการแก้ |
|---|---|---|---|
| ข้อผิดพลาด Error | ฟิลด์ที่จำเป็นหายไปหรือชนิดไม่ถูกต้อง | ใช่ ทำให้ Rich Results หายไปเลย | แก้ทันที |
| คำเตือน Warning | ฟิลด์ที่แนะนำหายไป | ไม่ ยังแสดงได้ | จัดคิวค่อยเติม |
| ข้อมูล Info | คำแนะนำฟิลด์ที่ไม่บังคับ | ไม่ | ว่างเมื่อไหร่ค่อยเติม |
ข้อสังเกตที่ขัดกับสัญชาตญาณ: ในรายงาน 80% ของข้อความแจ้งเป็นคำเตือน Google ตีสีเหลืองฟิลด์ที่แนะนำอย่างผู้เขียนหรือวันที่ที่หายไป แต่หน้าก็ยังมีคุณสมบัติแสดง Rich Results
สิ่งที่ทำให้ Rich Results หายไปจริงคือข้อผิดพลาด: เช่น ใช้ประเภท Article แต่ไม่ได้เขียน headline หรือเขียนวันที่เป็นสตริงแทนรูปแบบ ISO สองประเภทนี้ต้องแก้เป็นอันดับแรก
ตัวอย่างสถานการณ์: เว็บบล็อกแห่งหนึ่ง GSC รายงานว่ามีปัญหา 120 หน้า ตอนแรกคิดว่าเสียทั้งหมด แต่พอจัดระดับแล้วพบว่า 110 หน้าเป็นคำเตือนเรื่อง image หายไป มีเพียง 10 หน้าที่เป็นข้อผิดพลาดรูปแบบ datePublished แก้ข้อผิดพลาดร้ายแรง 10 หน้าก่อน หนึ่งสัปดาห์ต่อมา Rich Results กลับมา 80% ส่วนกลุ่มคำเตือนยังแสดงผลตามปกติ
ถ้าทีมของคุณใช้เทมเพลต CMS ข้อผิดพลาดประเภทหนึ่งจะเกิดพร้อมกันทั้งชุด แก้ฟิลด์ในเทมเพลตเดียว หน้าเว็บทั้งชุดจะกลับมาปกติอัตโนมัติหลังการเก็บข้อมูลครั้งถัดไป ไม่ต้องแก้ทีละหน้า นี่คือเหตุผลที่ควรแก้ข้อผิดพลาดก่อน เพราะแก้เทมเพลตหนึ่งครั้งเทียบเท่ากับแก้ด้วยมือหลายสิบหน้า
ในทางกลับกัน ปัญหาประเภทคำเตือนมักเกี่ยวข้องกับเนื้อหาแต่ละหน้า เช่น ขาดผู้เขียน ขาดภาพหลัก ซึ่งเป็นรายหน้า ต้องจัดคิวค่อยๆ เติมทีหลัง
วิธีตรวจสอบข้อผิดพลาดที่พบบ่อย 3 ประเภทและ 4 ประเภท
ข้อผิดพลาด structured data ที่พบบ่อยที่สุดในเว็บ B2B รวมอยู่ใน 4 ประเภท เรียงตามความถี่ที่พบดังนี้
| ประเภทความผิด | อาการที่พบ | วิธีตรวจสอบ | วิธีแก้ |
|---|---|---|---|
| ประเภทฟิลด์ผิด | วันที่เขียนเป็น 2026/10/08 | ดูว่าเป็น ISO 8601 หรือไม่ | แก้เป็น 2026-10-08 |
| ระดับการซ้อนผิด | Review แยกออกจาก Product | ดูโครงสร้าง @graph | ซ้อน Review เข้าใน Product |
| ขาดฟิลด์ที่จำเป็น | Article ไม่ได้เขียน headline | เทียบกับตารางฟิลด์ทางการ | เติมฟิลด์ที่จำเป็น |
| URL ซ้ำหลายรายการ | หน้าปัจจุบันทุกหน้าใส่ Article | ดูว่า canonical ชี้ไปที่ใด | ใส่เฉพาะบทความหลัก |
รูปแบบวันที่เป็นข้อผิดพลาดที่พบบ่อยที่สุด Google กำหนดให้ใช้ ISO 8601 คือ 2026-10-08 ไม่ใช่ 10/08/2026 และไม่ใช่ Oct 8, 2026 แค่เขียนด้วยเครื่องหมายทับแบบเดียวก็ทำให้หน้าเว็บทั้งชุดเสีย rich result ได้
ข้อผิดพลาดที่ซ่อนอยู่อีกอย่างคือการแบ่งหน้า ถ้าบทความชุดหน้าที่ 2 หน้าที่ 3 ใส่ Article ด้วย Google จะตัดสินว่าซ้ำ และเก็บไว้เฉพาะหน้าที่เป็น canonical หน้าที่เหลือต้องเอาป้ายออก หรือเปลี่ยนไปใช้ CollectionPage
วิธีรับและดูแล rich result ดูที่การปรับแต่ง rich result ส่วนการติดป้าย entity ดูที่การติดป้าย entity ใน knowledge graph。
4. ตรวจสอบหลังอัปโหลดว่าทำงานจริงหรือไม่
ทดสอบผ่านในเครื่องไม่ได้แปลว่าใช้งานจริงได้ structured data มีรอบการตรวจสอบ ต้องใช้วิธีที่ถูกต้องและรอ
| ระยะ | เวลา | สิ่งที่คุณเห็น | การดำเนินการ |
|---|---|---|---|
| ส่งการแก้ไข | วันที่ 0 | กดขอตรวจสอบใน GSC | อย่าแก้ซ้ำไปซ้ำมา |
| ให้ Google เก็บข้อมูลใหม่ | วันที่ 1 ถึง 7 | สถานะรายงานยังเป็นกำลังแก้ไข | รอ |
| ประเมินเสร็จ | สัปดาห์ที่ 1 ถึง 4 | จำนวนข้อผิดพลาดลดลง | เทียบกับ SERP ดู rich result |
| ติดตามระยะยาว | ทุกเดือน | หน้าใหม่ถูกเก็บอัตโนมัติหรือไม่ | รวมไว้ในการตรวจสอบทางเทคนิค |
หลังกดขอตรวจสอบแล้ว อย่าแก้โค้ดซ้ำไปซ้ำมา ทุกครั้งที่แก้จะรีเซ็ตหน้าต่างการประเมินของ Google การตรวจสอบที่ควรเสร็จใน 2 สัปดาห์จะยืดเป็น 6 สัปดาห์
หลังการตรวจสอบเสร็จ ให้ค้นหาใน Google ด้วยคำเป้าหมาย แล้วดูด้วยตาเปล่าว่า SERP มีดาว FAQ แบบพับ และ breadcrumb จริงหรือไม่ GSC บอกว่าใช้ได้ไม่ได้แปลว่าผู้ใช้จะเห็น บางประเภทแสดงเฉพาะบางคำค้นหา
ถ้า GSC แสดงว่าใช้ได้แต่ไม่เห็น rich result ใน SERP ให้ยืนยันก่อนว่าคำค้นหานั้นกระตุ้น rich result หรือไม่ บางประเภทปรากฏเฉพาะคำค้นหาแบบนำทางหรือแบบข้อมูล คำค้นหาแบบซื้อขายอาจไม่แสดง ลองเปลี่ยนคำที่เกี่ยวข้องแล้วค้นหาอีกครั้ง
ต้องติดตามระยะยาวด้วย ทุกครั้งที่เผยแพร่หน้าใหม่ หนึ่งสัปดาห์ต่อมาให้ไปดูใน GSC ว่าถูกตรวจพบอัตโนมัติหรือไม่ ถ้าไม่ ให้ใช้เครื่องมือตรวจสอบ URL ขอตรวจสอบด้วยมือหนึ่งครั้ง
ถ้าใช้เว็บสำเร็จรูปจากเทมเพลต แนะนำให้เพิ่มขั้นตอนตรวจสอบในกระบวนการเผยแพร่ ก่อนหน้าใหม่จะขึ้นจริงให้รัน Rich Results Test ก่อน ผ่านแล้วจึงอนุญาตให้เผยแพร่ ใช้เวลาแค่ 1 นาที แต่ช่วยเลี่ยงการแก้ซ้ำเป็นชุดหลังเว็บขึ้น
Rich Results ไม่ใช่เป้าหมาย แต่เป็นแค่สิ่งที่ทำให้หน้าเว็บโดดเด่นขึ้นใน SERP สิ่งที่ตัดสินอันดับจริง ๆ ยังเป็นเนื้อหาและลิงก์ภายนอก โครงสร้างข้อมูลแค่ขยายหน้าที่ดีอยู่แล้วให้ได้ CTR เพิ่มขึ้น 10% ถึง 20%
ดังนั้นอย่าสลับลำดับ ทำให้เนื้อหาติดอันดับท็อป 20 ได้ก่อน แล้วค่อยใส่โครงสร้างข้อมูลเพื่อชิงตำแหน่ง Rich Results ถ้าเนื้อหาติดอันดับไม่ได้เลย ติดมาร์กอัปถูกต้องแค่ไหนก็ไม่แสดงผลอะไร
ดูรายการตรวจสอบ SEO เชิงเทคนิคฉบับเต็มได้ที่เช็กลิสต์ตรวจสอบ Technical SEO โครงสร้างข้อมูลเป็นหนึ่งในนั้น ส่วนการตรวจก่อนเผยแพร่ดูได้ที่เช็กลิสต์ก่อนเปิดเว็บไซต์。
ห้า ข้อควรเลี่ยง: 3 การกระทำที่ผิดพลาดบ่อยที่สุดในขั้นตอนดีบัก
การดีบักโครงสร้างข้อมูลมี 3 กับดัก ถ้าเหยียบเข้าไปไม่เพียงไม่มีผล ยังอาจโดนลงโทษแบบ manual ได้
| การกระทำที่ผิด | ผลที่ตามมา | วิธีที่ถูกต้อง |
|---|---|---|
| ปั่นรีวิวเพื่อให้ได้ดาว | ผิดนโยบายโครงสร้างข้อมูล | ติดมาร์กอัปเฉพาะรีวิวจริง |
| แก้ทุกอย่างที่ขึ้นเตือนเหมือนเป็น error | เสียเวลาหลายวัน ไม่ได้อันดับเพิ่ม | แก้ error ก่อน ส่วน warning ค่อยจัดคิว |
| ผ่านในเครื่องแล้วก็แก้ทุกวัน | รีเซ็ตหน้าต่างการตรวจสอบ | ส่งแล้วรอ 1 ถึง 4 สัปดาห์ |
ที่ร้ายแรงที่สุดคือปั่นรีวิวให้ได้ดาว Google มีบทลงโทษแบบ manual สำหรับการให้คะแนนตัวเองและรีวิวปลอม หากโดนเข้า Rich Results ทั้งเว็บจะถูกถอด ต้องใช้เวลาหลายเดือนกว่าจะกลับมา ติดมาร์กอัปเฉพาะรีวิวที่มองเห็นจริงบนหน้าเว็บเท่านั้น
โครงสร้างข้อมูลยังช่วยเรื่องการดึงข้อมูลของ AI ด้วย ดูได้ที่การปรับแต่ง GEO เชิงเทคนิค ไม่ใช่เพื่อดาวไม่กี่ดวงนั้น แต่เพื่อให้ทั้งเสิร์ชเอนจินและ AI อ่านเอนทิตีของหน้าเว็บได้เข้าใจ
FAQ คำถามที่พบบ่อย
Rich Results Test ผ่านแล้ว ทำไมผลการค้นหายังไม่มี Rich Results?
error กับ warning ในรายงาน Rich Results ของ GSC ต่างกันอย่างไร?
error แบบฮาร์ดที่พบบ่อยที่สุดในโครงสร้างข้อมูลคืออะไร?
หลังแก้ structured data error แล้ว นานแค่ไหนถึงเห็นผล?
ถ้าอยากได้ดาวรีวิว เขียนรีวิวดีๆ ใส่เองได้ไหม?
เขียน JSON-LD ไว้ใน head หรือ body ต่างกันไหม?
ทิ้งท้าย
การดีบัก structured data ไม่ได้วัดกันที่ความสามารถเขียน Schema แต่วัดกันที่ความอดทน เวลารายงานขึ้นแดงเต็มไปหมด ให้แบ่งระดับก่อน 80% เป็น warning ที่ไม่ต้องรีบ หลังส่งแก้ไขแล้วให้รอ 1 ถึง 4 สัปดาห์ อย่าแก้โค้ดทุกวัน
ลงมือแค่ 3 ขั้น: หน้าเดียวลองผ่าน Rich Results Test ก่อน; ทั้งเว็บในรายงาน Rich Results ของ GSC ให้แก้เฉพาะรายการที่เป็น error ก่อน; แก้เสร็จกดขอตรวจสอบ แล้วรอ Google ประเมินใหม่ อย่ากลับมาแก้ซ้ำระหว่างนั้น
ประโยคเดียวที่จำได้: structured data ผ่านการทดสอบเป็นแค่ตั๋วเข้าประตู ต้องกดตรวจสอบใน GSC รอให้ครบสี่สัปดาห์ และเห็น rich results ด้วยตาบน SERP ครบสามขั้นนี้ถึงจะเรียกว่าได้ผลจริง