คู่มือ Schema แบบ Structured Data ฉบับครบ: วิธีเขียน Article/FAQ/Product/Breadcrumb

ฟิลด์บังคับและตำแหน่งวางของ Schema หลัก 4 ประเภท Article/FAQ/Product/Breadcrumb

คู่มือ Schema แบบ Structured Data ฉบับครบ: วิธีเขียน Article/FAQ/Product/Breadcrumb

สรุปก่อน: เว็บไซต์ B2B เขียน Schema ด้วยมือจริง ๆ แค่ 4 ประเภท: Article, FAQPage, Product, BreadcrumbList แต่ละประเภทมีฟิลด์บังคับชัดเจน เขียนด้วย JSON-LD ไว้ใน head และค่าฟิลด์ต้องตรงกับข้อความที่มองเห็นบนหน้าทีละคำ ข้อสังเกตที่ขัดกับสัญชาตญาณ: Schema ไม่ใช่ยิ่งใส่ฟิลด์มากยิ่งดี การใส่ฟิลด์ที่ซ่อนอยู่หรือตัวเลขที่ไม่ตรงกับหน้าเพิ่มเข้าไป กลับจะทำให้ Google ลงโทษด้วย structured data แบบสแปม บทความนี้ให้เทมเพลต JSON-LD 4 ประเภทที่นำไปใช้ซ้ำได้ทันที พร้อม 3 ขั้นตอนตรวจสอบที่ต้องรันก่อนขึ้นเว็บ

1. หลักการเขียน JSON-LD

Google แนะนำไวยากรณ์ JSON-LD ไม่ควรใช้ Microdata หรือ RDFa การเขียนมี 3 กฎเหล็ก

กฎ	วิธีที่ถูกต้อง	วิธีที่ผิด
ไวยากรณ์	<script type=”application/ld+json”>	ใช้ Microdata หรือ RDFa
ตำแหน่ง	head หรือท้าย body	รอให้เรนเดอร์เสร็จหลัง JS ฉีดแบบไดนามิก
ค่าฟิลด์	ตรงกับข้อความที่มองเห็นบนหน้าทีละคำ	Schema เขียน “999 ดอลลาร์” แต่หน้าเว็บเขียน “ขอใบเสนอราคา”
หลายประเภท	ใช้ @type เป็นอาร์เรย์หรือเชื่อมกันด้วย mainEntityOfPage	ยัดประเภทที่ไม่เกี่ยวข้องกัน 6-7 ประเภทในหน้าเดียว

ทำไมแนะนำ JSON-LD: เพราะมันแยกออกจากโครงสร้าง HTML การดูแลเทมเพลตจึงไม่ทำให้มาร์กอัปเสียหายจากการแก้ DOM ส่วน Microdata ฝังอยู่ในแอตทริบิวต์แท็ก แก้ class ตัวเดียวอาจพังไปด้วย

อีกสองข้อที่มักถูกมองข้าม: หนึ่ง ฟิลด์วันที่ทั้งหมดต้องใช้รูปแบบ ISO 8601 พร้อมออฟเซตเขตเวลา เช่น 2026-09-21T09:00:00+08:00 ห้ามเขียน “กันยายน 2026” สอง ฟิลด์ URL ต้องให้ Google ดึงได้โดยตรง ห้ามใส่ลิงก์หลังบ้านที่ต้องล็อกอินก่อนถึงจะเข้าถึงได้ ปัญหาสองประเภทนี้ใน Rich Results Test จะขึ้นแค่คำเตือน ไม่ขึ้น error จึงมักถูกมองข้าม

2. Article: หน้าบล็อกและไวท์เปเปอร์

Article เป็นมาร์กอัปพื้นฐานของหน้าบทความ กำหนดว่าจะมีรูปผู้เขียน เวลาเผยแพร่ หรือสลับภาพย่อบน SERP หรือไม่

ฟิลด์	จำเป็น	ค่าตัวอย่าง	คำอธิบาย
@type	แปล	Article	ข่าวใช้ NewsArticle
headline	แปล	ไม่เกิน 110 ตัวอักษร	ตรงกับ <title>
author	แปล	{“@type”:”Person”,”name”:”ชุย ลี่ซู”}	แนะนำให้ชี้ไปที่หน้าผู้เขียนด้วย
datePublished	แปล	2026-09-21T09:00:00+08:00	รูปแบบ ISO 8601
dateModified	แนะนำ	เหมือน datePublished หรือเวลาที่อัปเดต	อัปเดตเมื่อปรับปรุงบทความ
รูปภาพ	แปล	อย่างน้อย 1200×675 พิกเซล	มีผลกับภาพย่อในสลับภาพ
publisher	แนะนำ	เชื่อมกับ Organization	มีฟิลด์ logo

ตัวอย่างสถานการณ์: บล็อก B2B ใส่ Article แต่ image ใช้รูปเล็ก 600×300 Rich Results Test ขึ้น “image too small” เปลี่ยนเป็นภาพปก 1200×675 ภายในหนึ่งสัปดาห์ก็ไปอยู่ในสลับภาพบทความบน SERP ดูข้อกำหนดขนาดรูปได้ที่การจัดการสินทรัพย์สื่อ。

author 字段不要只写公司名，要写具体作者名并指向作者页。Google 在知识面板和作者头像轮播里会读这个字段；只写”环形山”三个字，既不构成 Person，也不构成 Organization，标记会被忽略。作者页本身要在站内可访问，并在 SameAs 里挂上领英、GitHub 等外部档案。

สาม FAQPage: ช่องทางหลักที่ AI ใช้ดึงคำตอบ

แม้ตั้งแต่ปี 2023 เป็นต้นมา FAQPage จะไม่แสดง rich media บน SERP สำหรับบล็อกธุรกิจทั่วไปอีกต่อไป แต่ยังคงเป็นช่องทางหลักที่ ChatGPT, Gemini และ Google AI Overviews ใช้ดึงข้อมูลถามตอบ

ฟิลด์	จำเป็น	คำอธิบาย
@type	แปล	FAQPage
mainEntity[]	แปล	อาร์เรย์ Question จำนวน 5 ถึง 6 ข้อ
name	แปล	ข้อความคำถามต้นฉบับ ให้ตรงกับ summary บนหน้าเว็บ
acceptedAnswer.text	แปล	คำตอบแบบข้อความล้วน ให้ตรงกับคำตอบที่มองเห็นบนหน้าเว็บ

จุดที่ขัดกับสัญชาตญาณ: บล็อกพับบน SERP ของ FAQPage ตั้งแต่เดือนสิงหาคม 2023 แสดงเฉพาะในฟอรัมที่เชื่อถือได้และเว็บภาครัฐเท่านั้น บล็อก B2B ทั่วไปใส่ไปก็ไม่แสดง แต่ก็ยังแนะนำให้ใส่ เพราะช่องทางหลักที่ AI engine ใช้ดึง FAQ คืออาร์เรย์ mainEntity ดูระเบียบวิธีเขียนเนื้อหา FAQ ได้ที่FAQ 与 People Also Ask。

เส้นแดง: คำถามคำตอบใน mainEntity ต้องตรงกับ FAQ ที่มองเห็นบนหน้าเว็บทั้งหมด ห้ามใส่คำถามคำตอบที่ไม่มีอยู่บนหน้าเว็บ การดำเนินการด้วยมือของ Google เรื่อง FAQ spam markup ก็มาจากจุดนี้

ความยาวของคำถามและคำตอบก็ต้องระวัง: คำถามควรอยู่ที่ 20 ถึง 40 ตัวอักษร คำตอบควรอยู่ที่ 80 ถึง 150 ตัวอักษร คำถามสั้นเกินไปดูเหมือนยัดคีย์เวิร์ด ยาวเกินไปก็เกินขอบเขตที่บล็อกพับบน SERP จะแสดงได้ คำตอบสั้นเกินไปความหนาแน่นของข้อมูลไม่พอ AI จะไม่อ้างอิง ยาวเกินไปก็จะถูกตัด

สี่ Product: พื้นที่ผลตอบแทนสูงของหน้าโปรดักต์ B2B

Product markup เป็นตัวกำหนดว่าการ์ดสินค้า ราคา และสถานะสต็อกจะปรากฏบน SERP หรือไม่ สินค้า B2B แบบกึ่งสั่งทำต้องใช้อย่างระมัดระวัง

ฟิลด์	จำเป็น	ข้อควรระวังสำหรับ B2B
name	แปล	ชื่อเต็มของรุ่นสินค้า ให้ตรงกับ H1
รูปภาพ	แปล	ภาพหลัก มีภาพสินค้าอย่างน้อย 3 ภาพจะมั่นคงกว่า
description	แนะนำ	ให้ตรงกับ meta description ของหน้าโปรดักต์
brand	แนะนำ	{“@type”:”Brand”,”name”:”…”}
offers.price	เมื่อมีราคาชัดเจน	สินค้าที่ต้องสอบถามราคาไม่ต้องใส่ price
offers.availability	แนะนำ	InStock / PreOrder ห้ามติดป้ายมั่ว
aggregateRating	เมื่อมีรีวิวจริง	ใส่ดาวโดยไม่มีรีวิวจริงเสี่ยงโดนดำเนินการด้วยมือแน่นอน

ตัวอย่างสถานการณ์ที่สอง: หน้าโปรดักต์ของโรงงานอุปกรณ์ B2B แห่งหนึ่งใส่ offers.price=5000 แต่บนหน้าเว็บเขียนแค่ “สอบถามราคา” Rich Results Test รายงานคำเตือนว่าฟิลด์ไม่สอดคล้องกัน สองสัปดาห์ต่อมาในรายงาน rich media ของ GSC จำนวนการแสดง rich media ของหน้าโปรดักต์นั้นกลายเป็นศูนย์ หลังจากลบฟิลด์ price ออกและเปลี่ยน availability เป็น PreOrder จำนวนการแสดงก็กลับมา

การใส่ฟิลด์ราคาผิดเป็นสาเหตุอุบัติเหตุที่พบบ่อยที่สุดของ Product markup เมื่อหน้าโปรดักต์ B2B แบบกึ่งสั่งทำไม่เปิดเผยราคา อย่าฝืนใส่ราคาเพียงเพื่อให้ได้การ์ดบน SERP

ห้า BreadcrumbList: ต้องใส่ทั้งเว็บไซต์

BreadcrumbList ทำให้ Google ใช้ breadcrumb แทน URL ยาวๆ ในการแสดงบน SERP เป็น Schema ที่ต้นทุนต่ำที่สุดสำหรับทั้งเว็บไซต์

ฟิลด์	จำเป็น	คำอธิบาย
@type	แปล	BreadcrumbList
itemListElement[]	แปล	เส้นทางเต็มจากหน้าแรกถึงหน้าปัจจุบัน
position	แปล	เริ่มนับจาก 1
name	แปล	ข้อความที่แสดงใน breadcrumb
item	แนะนำ	URL แบบ absolute ของระดับนั้น

ฟิลด์ item ต้องใช้ URL แบบ absolute ห้ามใช้ path แบบ relative ลำดับชั้นต้องตรงกับ breadcrumb ที่มองเห็นบนหน้าเว็บ: หน้าแรก → หมวดหมู่ → หมวดหมู่ย่อย → หน้าปัจจุบัน ห้ามข้ามระดับ และต้องใส่หน้าปัจจุบันลงใน itemListElement ด้วย ไม่อย่างนั้น Google จะยืนยันไม่ได้ว่า breadcrumb ชี้ไปที่หน้าไหน

หก、ตรวจสอบ 3 ขั้นตอนก่อนขึ้นระบบ

ขั้นตอน	เครื่องมือ	กรอบเวลา	เกณฑ์ผ่าน
ตรวจสอบทีละ URL	Rich Results Test	วันก่อน deploy	ไม่มีข้อผิดพลาด มีเพียงคำเตือนที่ยอมรับได้
สุ่มตรวจหลังขึ้นระบบ	รัน URL บนระบบจริงอีกครั้ง	วันเปิดใช้งาน	ผลลัพธ์ที่ render ตรงกับในเครื่อง
รายงาน Rich Media	Search Console	วันที่ 7, 14, 30	จำนวนการแสดงผลไม่เป็นศูนย์ ข้อผิดพลาดเป็น 0

Schema 4 ประเภทนี้เป็นพื้นฐานของเว็บไซต์ B2B ส่วน Organization และ WebSite เป็นอีก 2 ประเภทที่ต้องใส่ใน head ทุกหน้าของทั้งเว็บ ดูเกณฑ์การจัดลำดับความสำคัญฉบับเต็มได้ที่structured data Schema。เว็บหลายภาษาต้องตรวจสอบให้แน่ใจว่าช่อง Schema และ การแปลตัวเลขและตารางให้เป็นภาษาท้องถิ่น เว็บหลายภาษาต้องตรวจสอบด้วยว่าฟิลด์ Schema ตรงกับ

สาเหตุอุบัติเหตุที่พบบ่อยที่สุดอีกอย่างคือ Schema ซ้ำที่ปลั๊กอินสร้างขึ้นอัตโนมัติ เว็บ WordPress ที่ติดตั้ง Yoast หรือ Rank Math ปลั๊กอินจะส่งออก Article และ Organization โดยค่าเริ่มต้น ถ้าคุณเขียน JSON-LD เองอีกชุด ก็จะเกิดคำเตือน duplicate field ก่อนขึ้นระบบให้รัน Rich Results Test กับหน้าสินค้าและหน้าบทความ ถ้าเห็นฟิลด์ซ้ำให้ปิดโมดูลที่เกี่ยวข้องของปลั๊กอิน แล้วเก็บชุดที่เขียนเองไว้

เจ็ด、ตรวจสอบ Schema รายเดือนหลังขึ้นระบบ

Schema ไม่ใช่เขียนเสร็จแล้วปล่อยทิ้งไว้ การแก้ไขเทมเพลต การขึ้นลงสินค้า และการปรับราคา ล้วนทำให้ฟิลด์กับเนื้อหาที่มองเห็นบนหน้าเว็บไม่ตรงกันอีกครั้ง ใช้เวลาครึ่งวันตรวจสอบเดือนละครั้ง ประหยัดแรงกว่ามาคอยแก้หลังเกิดปัญหา

รายการตรวจสอบ	วิธีตรวจสอบ	ความถี่	เกณฑ์ผ่าน
ข้อผิดพลาดในรายงาน Rich Media ของ GSC	รายงานประสบการณ์ใน Search Console	ทุกเดือน	จำนวนข้อผิดพลาดเป็น 0 คำเตือนยอมรับได้
ฟิลด์ตรงกับข้อความที่มองเห็น	สุ่ม 10 หน้า รัน Rich Results Test	ทุกเดือน	ไม่มีคำเตือนฟิลด์ไม่ตรงกัน
การซิงค์ราคาของ Product	เทียบฟิลด์ price ในหน้าสินค้ากับราคาที่แสดงบนหน้า	หลังปรับราคา	สินค้าที่ให้สอบถามราคา ไม่ใส่ฟิลด์ price
เส้นทาง Breadcrumb	สุ่มหน้าลำดับที่สอง เทียบกับ breadcrumb	หลังปรับดีไซน์	ไม่ข้ามระดับ item เป็น URL แบบ absolute
Schema ซ้ำ	ดูจำนวนบล็อก ld+json ในซอร์สโค้ดหน้าเว็บ	หลังติดตั้งปลั๊กอินใหม่	ไม่มีเอาต์พุตซ้ำระหว่างปลั๊กอินกับชุดที่เขียนเอง

เมื่อตรวจสอบแล้วพบปัญหา อย่ารีบแก้ทั้งเว็บ ให้จำลองในสภาพแวดล้อมทดสอบก่อน เพื่อยืนยันว่าเป็นปัญหาเทมเพลตหรือปัญหาเฉพาะหน้า ปัญหาเทมเพลตกระทบทุกหน้า แก้เทมเพลตครั้งเดียวก็จบ ส่วนปัญหาเฉพาะหน้ามักเกิดจากคนแก้เนื้อหาเผลอเปลี่ยนราคาหรือวันที่ผิด แก้ทีละหน้าก็พอ บันทึกผลการตรวจสอบรายเดือนเป็นตารางหนึ่งหน้า ผ่านไปสามเดือนคุณจะเห็นว่าข้อผิดพลาดประเภทไหนเกิดซ้ำ ก็เขียนลงในคู่มือแก้ไขเนื้อหา เพื่อลดอุบัติเหตุซ้ำจากต้นทาง

ข้อสุดท้าย: Schema มีไว้ให้เสิร์ชเอนจินและ AI อ่าน ไม่ใช่ให้ผู้เข้าชมดู ค่าฟิลด์ต้องสะท้อนเนื้อหาจริงบนหน้าอย่างซื่อสัตย์ อย่าปลอมราคาหรือปั่นคะแนนดาวเพื่อให้ได้ผลลัพธ์ Rich Media หากถูก Google ลงโทษด้วยการดำเนินการด้วยมือกับ structured data ที่เป็นสแปม ระยะเวลาฟื้นตัวนับเป็นไตรมาส ไม่คุ้มกันเลย

เว็บไซต์หลายภาษาต้องระวังความสอดคล้องของภาษในฟิลด์ Schema ด้วย หน้าเว็บภาษาอังกฤษต้องกรอกฟิลด์ JSON-LD เป็นภาษาอังกฤษ หน้าเว็บภาษาจีนก็กรอกเป็นภาษาจีน อย่าเขียนปนกัน ฟิลด์สกุลเงินต้องตรงกับสกุลเงินที่แสดงบนหน้าเว็บภาษานั้น หน้าที่เจาะกลุ่มลูกค้ายุโรปอย่ากรอกดอลลาร์สหรัฐ รูปแบบวันที่ให้ใช้ ISO 8601 เป็นมาตรฐาน อย่าเขียนแบบตามท้องถิ่นอย่าง “9/21/2026” ที่กำกวม รายละเอียดพวกนี้ Rich Results Test จะไม่ฟ้อง error แต่มีผลต่อความแม่นยำในการดึงข้อมูลของ AI

FAQ คำถามที่พบบ่อย

ฟิลด์ headline ของ Article เขียนยาวกว่านี้ได้ไหม

แนะนำไม่เกิน 110 ตัวอักษร และให้ตรงกับ title ของหน้าเว็บ เกิน 110 ตัวอักษรจะถูกตัดบน SERP และ Google ก็มักเลือกใช้เวอร์ชันที่ตัวเองตัด อย่ายัดคีย์เวิร์ดลงใน headline มันต้องเป็นชื่อบทความจริง

คำถามคำตอบใน FAQPage ใส่เยอะกว่าบนหน้าเว็บได้ไหม

ไม่ได้ ทุกคู่คำถามคำตอบใน mainEntity ต้องปรากฏบนหน้าเว็บและข้อความต้องตรงกันทุกตัวอักษร การเขียนคำถามคำตอบที่ไม่มีบนหน้าเว็บถือเป็น structured data ขยะ จะโดน manual action แนะนำ 5 ถึง 6 ข้อ ไม่ต้องฝืนยัดให้ครบ 20 ข้อ

หน้า Product ไม่เปิดเผยราคา จะเขียน offers ยังไง

อย่ากรอกฟิลด์ price และอย่าติด InStock เขียน offers.priceCurrency เป็นค่าว่าง หรือเขียนแค่ offers.availability เป็น PreOrder ก็ได้ ข้อผิดพลาดที่พบบ่อยที่สุดคือเอาราคาแนะนำไปใส่ใน price ซึ่งไม่ตรงกับ “สอบถามราคา” บนหน้าเว็บ นี่คือ error ที่เจอบ่อยที่สุดในรายงาน rich media

ฟิลด์ item ของ BreadcrumbList ใช้ relative path ได้ไหม

ไม่ได้ ต้องใช้ absolute URL ที่มี https และโดเมน ครบ ถ้าใช้ relative path ตอน Google render จะตีความผิด ทำให้ breadcrumb ชี้ไปหน้าผิด ต้องเขียนครบทั้งสามชั้นคือ หน้าแรก หน้าหมวด และหน้าปัจจุบัน อย่าข้ามชั้น

หน้าเดียวกันใส่ Article กับ BreadcrumbList พร้อมกันได้ไหม

ได้ นี่คือชุดมาตรฐาน วิธีที่นิยมคือแยกเป็นสองบล็อก ld+json ต่างหาก บล็อกหนึ่งเป็น Article อีกบล็อกเป็น BreadcrumbList หน้า Product ก็ใส่ Product + BreadcrumbList + Organization พร้อมกันได้ (เชื่อมผ่านฟิลด์ publisher) อย่ารวมเป็นออบเจกต์เดียว

หลัง Schema ขึ้นแล้ว นานแค่ไหนถึงเห็น rich media

ไม่มีเวลาการันตี ปกติหลัง Google เก็บข้อมูลใหม่ 7 ถึง 14 วัน รายงาน rich media ใน Search Console ถึงจะแสดงประเภทนั้น แม้ markup จะถูกต้อง การจะแสดง rich media หรือไม่ Google เป็นคนตัดสินเอง ขึ้นอยู่กับคุณภาพหน้าเว็บ แบ็กลิงก์ และความน่าเชื่อถือของเนื้อหา อย่าเพิ่งแก้โค้ดเพียงเพราะ 3 วันแล้วยังไม่แสดง

ทิ้งท้าย

Schema หลักสี่ประเภทคือชุดขั้นต่ำที่ใช้ได้สำหรับเว็บไซต์ B2B: Article สำหรับบล็อก, FAQPage สำหรับคำตอบ AI, Product สำหรับหน้าสินค้า, BreadcrumbList ใช้ทั่วทั้งเว็บ เขียนถูกไม่รับประกันว่าจะได้ rich media แต่เขียนผิดรับรองว่าหมดสิทธิ์

ลงมือ 3 ขั้นตอน: สัปดาห์นี้ใช้ Rich Results Test ตรวจสอบหน้าเทมเพลต 5 หน้า แล้วจดประเภทที่ขาดไป; สัปดาห์หน้าเติมเทมเพลต JSON-LD ทั้ง 4 ประเภทเข้าไปใน head โดยให้ค่าฟิลด์ตรงกับข้อความที่มองเห็นบนหน้าทีละคำ; วันที่ 30 เช็กในรายงาน Rich Media ของ Search Console ว่าศูนย์ข้อผิดพลาด

ประโยคเดียวที่จำง่าย: Schema ไม่ใช่ยิ่งมากยิ่งดี แต่ยิ่งแม่นยิ่งดี — ฟิลด์ตรงกับหน้า ตัวเลขตรงกับราคาที่เสนอ และคำถามคำตอบตรงกับ FAQ เมื่อนั้น Rich Media ถึงจะมีโอกาสมา