เทคนิคอัปเดต Structured Data (Schema Markup) ฉบับสมบูรณ์สำหรับทำ AIO
คู่มือ Structured Data AIO ตั้งแต่เลือก schema type ตามประเภทเว็บ ติดตั้ง JSON-LD ให้ถูกครั้งแรก เชื่อม entity ด้วย @id ไปจนถึงวิธีตรวจ error และรอบการดูแล
ทีม NOAH · เผยแพร่ 20 กันยายน 2569 · อัปเดต 20 กันยายน 2569 · อ่าน 15 นาที
สรุปสั้น
- ✓Structured Data AIO คือการใส่ข้อมูลโครงสร้างแบบ JSON-LD เพื่อบอกระบบว่าข้อความบนหน้าคืออะไร โดยเน้นความถูกต้องของ entity และความตรงกับเนื้อหาที่ผู้ใช้เห็น ไม่ใช่การไล่ใส่ schema ให้ครบทุกชนิดเพื่อหวังการแสดงผลแบบพิเศษ
- ✓ลำดับที่คุ้มที่สุดสำหรับเว็บส่วนใหญ่คือ Organization หรือ LocalBusiness ระดับเว็บ แล้วตามด้วย BreadcrumbList ทุกหน้า จากนั้นจึงเป็น Article สำหรับบทความ Product สำหรับหน้าสินค้า และ FAQPage เฉพาะหน้าที่มีคำถามและคำตอบจริง
- ✓กฎที่ทำให้ schema ปลอดภัยที่สุดมีข้อเดียว คือข้อมูลใน markup ต้องตรงกับข้อความที่ผู้ใช้มองเห็นบนหน้า ถ้าใส่ข้อมูลที่ไม่ปรากฏบนหน้า นอกจากจะไม่ช่วยแล้วยังเสี่ยงถูกมองว่าเป็นการหลอกระบบ
- ✓การเชื่อม entity ด้วย @id ให้ทุกหน้าชี้กลับไปที่ Organization ก้อนเดียว ช่วยให้ระบบเข้าใจว่าทุกหน้ามาจากธุรกิจเดียวกัน ซึ่งมีผลกับ AIO มากกว่าการเพิ่มจำนวน schema type บนหน้าเดียว
- ✓Structured Data ไม่ได้รับประกันอันดับ ไม่ได้รับประกันว่าคำตอบของ AI จะอ้างถึงเว็บเรา และยังไม่มีข้อมูลสาธารณะที่ระบุน้ำหนักที่ระบบ AI ให้กับ schema แน่ชัด สิ่งที่ยืนยันได้คือมันลดโอกาสที่ระบบจะอ่านโครงหน้าผิด
เว็บไทยจำนวนมากติดตั้ง schema ไว้ตั้งแต่ตอนทำเว็บ แล้วไม่เคยเปิดดูอีกเลย พอเข้าสู่ยุคที่ AI สรุปคำตอบแทนหน้าผลการค้นหา ทีมการตลาดจึงเพิ่งมาเปิดเครื่องมือตรวจแล้วพบว่า schema ของตัวเองมีทั้งข้อมูลที่ล้าสมัย ชื่อบริษัทไม่ตรงกับหน้าเว็บ และ markup ที่ปลั๊กอินหลายตัวใส่ทับกันจนเกิดข้อมูลซ้ำในหน้าเดียว การทำ Structured Data AIO จึงมักเริ่มจากการไล่เก็บกวาดของเดิม ไม่ใช่การไล่เพิ่มของใหม่
บทความนี้ลงรายละเอียดว่า Structured Data ในบริบท AIO ต่างจากการทำ schema แบบเดิมตรงไหน ช่วยอะไรได้จริงและไม่ช่วยอะไร ควรเริ่มจาก schema ตัวไหนตามประเภทเว็บ ติดตั้ง JSON-LD อย่างไรให้ถูกตั้งแต่ครั้งแรก เชื่อมข้อมูลให้เป็น entity เดียวกันอย่างไร ตรวจ error ด้วยอะไร และควรทบทวนรอบไหน ถ้าต้องการภาพรวมการจัดโครงเนื้อหาทั้งหน้า อ่านคู่กับ โครงสร้างเนื้อหาสำหรับ AIO ได้
Structured Data AIO คืออะไร และต่างจากการทำ schema แบบเดิมอย่างไร
Structured Data AIO คืออะไร
Structured Data AIO คือการใส่ข้อมูลโครงสร้างในรูปแบบ JSON-LD ลงในหน้าเว็บ เพื่อบอกระบบค้นหาและระบบ AI ว่าข้อความแต่ละส่วนคืออะไร ใครเป็นเจ้าของ และเกี่ยวข้องกับอะไร จุดต่างจากการทำ schema แบบเดิมคือเป้าหมายเปลี่ยนจากการหวังผลการแสดงผลแบบพิเศษในหน้าผลการค้นหา มาเป็นการทำให้ข้อมูลของธุรกิจถูกเข้าใจเป็น entity เดียวที่สอดคล้องกันทั้งเว็บ ความถูกต้องและความสม่ำเสมอจึงสำคัญกว่าจำนวน schema ที่ใส่
สมัยก่อนคนทำ schema เพราะอยากได้ดาว ได้รูป หรือได้กล่องพิเศษในหน้าผลการค้นหา ซึ่งบางอย่างก็ถูกยกเลิกไปตามเวลา พอมาถึงยุคที่คำตอบถูกประกอบขึ้นจากหลายแหล่ง สิ่งที่มีค่ากว่าคือการที่ระบบรู้แน่ว่าเว็บนี้เป็นของธุรกิจชื่ออะไร อยู่ที่ไหน ขายอะไร และบทความนี้เขียนโดยใคร เพราะข้อมูลเหล่านี้คือสิ่งที่ใช้ตัดสินว่าจะเชื่อถือแหล่งไหน
- เดิมวัดผลที่การแสดงผลพิเศษในหน้าผลการค้นหา ตอนนี้วัดที่ความสอดคล้องของข้อมูลธุรกิจทั้งเว็บ
- เดิมใส่ schema เฉพาะหน้าสำคัญ ตอนนี้ควรมีข้อมูลระดับองค์กรและเส้นทางนำทางครบทุกหน้า
- เดิมเน้นจำนวน type ที่ใส่ ตอนนี้เน้นว่าแต่ละ type ชี้กลับไปหา entity เดียวกันหรือไม่
- เดิมตรวจครั้งเดียวตอนติดตั้ง ตอนนี้ต้องมีรอบทบทวนเพราะข้อมูลธุรกิจเปลี่ยนบ่อยกว่าโค้ด
Structured Data ช่วย AIO ได้แค่ไหน และไม่ช่วยอะไร
ตอบตรง ๆ คือ schema ช่วยให้ระบบอ่านหน้าเว็บผิดน้อยลง แต่ไม่ได้ทำให้เนื้อหาที่อ่อนกลายเป็นเนื้อหาที่ดี ถ้าหน้าไม่มีข้อมูลที่คนต้องการ การใส่ markup เพิ่มก็ไม่ได้สร้างข้อมูลขึ้นมา สิ่งที่ schema ทำได้คือลดความกำกวม เช่น บอกว่าตัวเลขบนหน้านี้คือราคา ไม่ใช่รหัสสินค้า
| ประเด็น | สถานะ | อธิบาย |
|---|---|---|
| ลดโอกาสที่ระบบอ่านโครงหน้าผิด | ทำได้ | ระบุชัดว่าข้อความไหนคือชื่อสินค้า ราคา วันที่เผยแพร่ หรือชื่อผู้เขียน |
| ทำให้ข้อมูลธุรกิจสอดคล้องกันทุกหน้า | ทำได้ | ทุกหน้าชี้กลับไปที่ Organization ก้อนเดียวด้วย @id ทำให้ไม่เกิดชื่อธุรกิจหลายเวอร์ชัน |
| เปิดโอกาสให้แสดงผลแบบพิเศษบางประเภท | ทำได้แต่ไม่รับประกัน | ระบบค้นหาเป็นผู้ตัดสินใจเอง การมี markup ถูกต้องเป็นเพียงเงื่อนไขขั้นต่ำ |
| รับประกันอันดับที่ดีขึ้น | ทำไม่ได้ | ไม่มีข้อมูลสาธารณะที่ระบุว่า schema เป็นปัจจัยจัดอันดับโดยตรง |
| บังคับให้ AI อ้างอิงเว็บเรา | ทำไม่ได้ | การถูกเลือกเป็นแหล่งอ้างอิงขึ้นกับหลายปัจจัย และยังไม่มีเครื่องมือมาตรฐานที่วัดได้แน่นอน |
| ทดแทนเนื้อหาที่ตื้นหรือไม่มีข้อมูลจริง | ทำไม่ได้ | markup อธิบายข้อมูลที่มีอยู่ ไม่ได้สร้างข้อมูลใหม่ให้หน้าเว็บ |
ระบุขอบเขตความแน่นอนไว้ก่อน
ผู้ให้บริการระบบ AI ส่วนใหญ่ยังไม่ได้เปิดเผยว่าใช้ structured data ในการประกอบคำตอบมากน้อยเพียงใด ข้อมูลที่ยืนยันได้ในตอนนี้มาจากเอกสารของระบบค้นหาซึ่งเน้นเรื่องการแสดงผลเป็นหลัก ดังนั้นควรทำ schema ในฐานะงานพื้นฐานที่ทำให้ข้อมูลถูกต้อง ไม่ใช่ในฐานะกลยุทธ์ที่คาดหวังผลลัพธ์เฉพาะเจาะจง
เริ่มจาก schema type ไหนก่อน ตามประเภทเว็บ
ถ้ามีเวลาจำกัด ให้เริ่มจากข้อมูลระดับเว็บก่อนเสมอ เพราะมันส่งผลกับทุกหน้าพร้อมกัน แล้วค่อยลงไปที่ schema ระดับหน้า ลำดับด้านล่างเรียงจากสิ่งที่ให้ผลกว้างที่สุดลงมา และใช้ได้กับเว็บไทยทั่วไปที่ไม่ได้มีโครงสร้างซับซ้อนเป็นพิเศษ
| ประเภทเว็บ | ติดตั้งลำดับแรก | ลำดับถัดไป | ข้อควรระวัง |
|---|---|---|---|
| เว็บบริษัทหรือเว็บบริการ | Organization ระดับเว็บ และ BreadcrumbList ทุกหน้า | Service หรือ WebPage ของหน้าบริการ แล้วจึง FAQPage เฉพาะหน้าที่มีคำถามจริง | ชื่อธุรกิจใน markup ต้องตรงกับที่แสดงบนหน้าและในเอกสารจดทะเบียน |
| เว็บขายของออนไลน์ | Organization และ BreadcrumbList | Product พร้อม Offer ของหน้าสินค้า แล้วจึง ItemList ของหน้าหมวดหมู่ | ราคาและสถานะสินค้าต้องอัปเดตอัตโนมัติจากระบบหลังบ้าน ไม่ใช่พิมพ์ค้างไว้ |
| เว็บบล็อกหรือสื่อ | Organization และ Article ทุกบทความ | BreadcrumbList, Person สำหรับผู้เขียน และ FAQPage เฉพาะหน้าที่มีคำถาม | วันที่เผยแพร่และวันที่แก้ไขต้องเป็นวันจริง ไม่ใช่วันที่ระบบเขียนทับทุกครั้งที่บิลด์ |
| ธุรกิจที่มีหน้าร้าน | LocalBusiness พร้อมที่อยู่และเวลาทำการ | BreadcrumbList, Service และหน้าแยกรายสาขาถ้ามีหลายสาขา | ที่อยู่และเวลาทำการต้องตรงกับข้อมูลในโปรไฟล์ธุรกิจของสาขานั้น |
| เว็บ B2B ที่เน้นสเปก | Organization และ BreadcrumbList | Product หรือ WebPage ของหน้าสเปก และ HowTo สำหรับขั้นตอนการใช้งาน | อย่าใส่ HowTo กับหน้าที่ไม่ได้มีลำดับขั้นตอนจริงบนหน้า |
สังเกตว่า BreadcrumbList โผล่ในทุกประเภทเว็บ เพราะมันเป็นตัวบอกลำดับชั้นของเนื้อหา ซึ่งช่วยให้ระบบเข้าใจว่าหน้านี้อยู่ใต้หมวดไหนและสัมพันธ์กับหน้าอื่นอย่างไร งานนี้เชื่อมกับการวางกลุ่มหัวข้อโดยตรง ถ้ายังไม่ได้จัดกลุ่มเนื้อหา อ่านวิธีวางได้ที่ Entity-Based SEO และ Topic Cluster
ติดตั้ง JSON-LD ให้ถูกตั้งแต่ครั้งแรก
รูปแบบที่แนะนำคือ JSON-LD วางไว้ในแท็ก script ของหน้า เพราะแยกออกจาก HTML ที่ใช้แสดงผล ทำให้แก้ง่ายและไม่พังเวลาปรับดีไซน์ ต่างจากการฝังแอตทริบิวต์ลงในแท็กเนื้อหาโดยตรงซึ่งมักหายไปตอนเปลี่ยนธีม
ขั้นตอนติดตั้งและตรวจ JSON-LD หนึ่งหน้า
- 1
ตัดสินใจว่าหน้านี้คือหน้าประเภทอะไร
เลือก type หลักเพียงหนึ่งตัวต่อหนึ่งหน้า เช่น หน้าบทความใช้ Article หน้าสินค้าใช้ Product หน้าบริการใช้ WebPage หรือ Service การใส่หลาย type หลักในหน้าเดียวมักทำให้ระบบตีความไม่ตรงกับที่ตั้งใจ
- 2
ไล่เก็บข้อมูลที่ต้องใส่จากหน้าจริง
เปิดหน้าเว็บแล้วคัดลอกชื่อเรื่อง ราคา วันที่ ชื่อผู้เขียน และรายละเอียดอื่นจากสิ่งที่ผู้ใช้เห็นจริง ห้ามหยิบจากไฟล์ภายในที่อาจไม่ตรงกับหน้า เพราะข้อมูลที่ไม่ปรากฏบนหน้าคือสาเหตุอันดับหนึ่งของการถูกตีความว่าเป็นการหลอกระบบ
- 3
เขียน JSON-LD โดยใส่ฟิลด์ที่จำเป็นให้ครบก่อน
ใส่ฟิลด์บังคับของ type นั้นให้ครบก่อนค่อยเพิ่มฟิลด์เสริม เช่น Article ต้องมีชื่อเรื่อง ผู้เขียน วันที่เผยแพร่ และผู้เผยแพร่ ถ้าฟิลด์บังคับยังไม่ครบ การเติมฟิลด์เสริมสิบตัวก็ไม่ช่วยอะไร
- 4
ใส่ @id ให้ entity หลักและอ้างอิงข้ามหน้า
กำหนด @id ให้ Organization หนึ่งค่าแล้วใช้ค่าเดิมในทุกหน้า เพื่อให้ระบบรู้ว่าเป็นองค์กรเดียวกัน ไม่ใช่สร้าง Organization ใหม่ทุกหน้าซึ่งทำให้เกิดข้อมูลธุรกิจหลายชุดที่ไม่เชื่อมกัน
- 5
ตรวจด้วยเครื่องมือทดสอบก่อนขึ้นจริง
รันเครื่องมือทดสอบ structured data ของระบบค้นหากับ URL จริงหลังดีพลอย แล้วแก้ทุกข้อที่ขึ้นเป็น error ก่อน ส่วนข้อที่เป็น warning ให้ไล่แก้ตามลำดับความสำคัญ ไม่จำเป็นต้องแก้ให้หมดในรอบเดียว
- 6
บันทึกไว้ว่าหน้าไหนใช้ type อะไร
ทำตารางกลางหนึ่งไฟล์ที่ระบุว่าเทมเพลตหน้าแต่ละแบบใช้ schema อะไรบ้าง เพื่อให้คนที่มาทำต่อไม่ใส่ซ้ำหรือใส่ขัดกัน ตารางนี้จะมีค่ามากเมื่อเปลี่ยนทีมหรือเปลี่ยนเอเจนซี
ระวัง markup ซ้อนจากปลั๊กอินหลายตัว
อาการที่พบบ่อยที่สุดในเว็บที่ใช้ระบบจัดการเนื้อหาสำเร็จรูปคือมีปลั๊กอินสองถึงสามตัวใส่ schema ให้พร้อมกัน ทำให้หน้าเดียวมีข้อมูลบทความสองก้อนที่ชื่อผู้เขียนไม่ตรงกัน วิธีตรวจคือเปิดซอร์สของหน้าแล้วค้นหาคำว่า application/ld+json ว่ามีกี่ก้อน ถ้าเกินความจำเป็น ให้ปิดของปลั๊กอินที่ไม่ได้ดูแลแล้วเหลือแหล่งเดียว
เชื่อมข้อมูลให้เป็น entity เดียวกันด้วย @id และ sameAs
ทำไมการเชื่อม entity ถึงสำคัญกว่าการเพิ่มจำนวน schema
เพราะระบบ AI ต้องตอบคำถามว่าใครคือผู้พูด ก่อนจะตัดสินใจว่าจะเชื่อข้อมูลนั้นหรือไม่ ถ้าแต่ละหน้าในเว็บประกาศชื่อธุรกิจคนละเวอร์ชัน มีที่อยู่ไม่ตรงกัน และไม่มีตัวระบุที่ผูกทุกหน้าเข้าด้วยกัน ระบบจะเห็นเป็นข้อมูลกระจัดกระจายแทนที่จะเป็นธุรกิจเดียว การกำหนด @id หนึ่งค่าให้ Organization แล้วให้ทุกหน้าอ้างกลับมาที่ค่าเดิม จึงให้ผลมากกว่าการไล่เพิ่ม schema type ใหม่ในหน้าเดียว
ในทางปฏิบัติ ให้มองว่าเว็บทั้งเว็บมี entity หลักอยู่ไม่กี่ตัว คือองค์กร ผู้เขียน สินค้าหรือบริการ และหน้าเนื้อหาแต่ละหน้า งานของเราคือทำให้ตัวเดียวกันมีตัวระบุเดียวกันเสมอ ไม่ใช่สร้างใหม่ทุกครั้งที่เขียนหน้าใหม่
| ฟิลด์ | ใส่อะไร | ผลที่ได้เมื่อใส่ถูก |
|---|---|---|
| @id | ตัวระบุถาวรของ entity นั้น ใช้ค่าเดิมทุกหน้า | ระบบรวมข้อมูลจากหลายหน้าเข้าเป็นธุรกิจหรือผู้เขียนคนเดียวได้ |
| name | ชื่อที่แสดงบนหน้าเว็บจริง ไม่ใช่ชื่อย่อภายใน | ชื่อที่ระบบใช้อ้างถึงตรงกับที่ลูกค้าเห็นและค้นหา |
| sameAs | ที่อยู่โปรไฟล์ทางการของธุรกิจบนแพลตฟอร์มอื่น | ช่วยยืนยันว่าองค์กรนี้คือองค์กรเดียวกับที่ปรากฏในที่อื่น |
| author และ publisher | ผู้เขียนจริงและองค์กรที่เผยแพร่ ผูกกลับด้วย @id | แยกได้ชัดว่าใครเขียนและใครรับผิดชอบเนื้อหา |
| datePublished และ dateModified | วันที่เผยแพร่ครั้งแรกและวันที่แก้ไขจริง | ระบบประเมินความสดของข้อมูลได้ถูก และไม่ถูกมองว่าแก้ไขปลอม |
| isPartOf และ mainEntityOfPage | ความสัมพันธ์ของหน้ากับเว็บและกับเนื้อหาหลักของหน้า | ลดความกำกวมเมื่อหน้าหนึ่งมีหลายส่วนประกอบ |
เริ่มจากไฟล์เดียวที่ประกาศ Organization
วิธีที่ทำให้ไม่พลาดคือสร้างที่เก็บข้อมูลองค์กรไว้ที่เดียวในโค้ด เช่น ไฟล์ค่าคงที่หนึ่งไฟล์ที่เก็บชื่อ ที่อยู่ โลโก้ และ @id แล้วให้ทุกเทมเพลตดึงจากไฟล์นั้น เวลาธุรกิจย้ายที่อยู่หรือเปลี่ยนโลโก้ จะได้แก้จุดเดียวแล้วถูกทั้งเว็บ แทนที่จะไล่แก้ทีละหน้าแล้วลืมบางหน้า
ตรวจและแก้ error ที่พบบ่อยในเว็บไทย
ขั้นตอนตรวจที่ใช้ได้จริงมีสองชั้น ชั้นแรกคือเครื่องมือทดสอบที่ยิงเข้า URL จริงเพื่อดูว่าระบบอ่านอะไรได้บ้าง ชั้นที่สองคือรายงานในเครื่องมือของเจ้าของเว็บที่รวมปัญหาของทั้งเว็บ ชั้นแรกใช้ตอนเพิ่งแก้ ส่วนชั้นที่สองใช้ดูภาพรวมรายเดือน
| อาการ | สาเหตุที่พบบ่อย | วิธีแก้ |
|---|---|---|
| ขึ้นว่าขาดฟิลด์ที่จำเป็น | เทมเพลตไม่ได้ส่งค่าบางตัวเมื่อฟิลด์นั้นว่างในระบบหลังบ้าน | ตั้งค่าให้ไม่ output ก้อน schema เลยถ้าข้อมูลไม่ครบ ดีกว่าปล่อยให้ออกแบบไม่สมบูรณ์ |
| ราคาใน markup ไม่ตรงกับราคาบนหน้า | หน้าเว็บแสดงราคาหลังส่วนลด แต่ markup ดึงราคาตั้งต้น | ให้ทั้งสองจุดดึงจากค่าเดียวกันในระบบ และตรวจหน้าที่มีโปรโมชันเป็นพิเศษ |
| มีข้อมูลบทความซ้ำสองก้อนในหน้าเดียว | ปลั๊กอินมากกว่าหนึ่งตัวใส่ schema พร้อมกัน | เลือกแหล่งเดียวแล้วปิดของอีกตัว จากนั้นตรวจซอร์สของหน้าซ้ำอีกครั้ง |
| วันที่แก้ไขเปลี่ยนทุกครั้งที่บิลด์เว็บ | ระบบใช้เวลาบิลด์เป็นวันที่แก้ไขแทนวันที่แก้เนื้อหา | ผูกวันที่แก้ไขกับฟิลด์ในเนื้อหา และอัปเดตเมื่อแก้สาระจริงเท่านั้น |
| ใส่ FAQPage แต่หน้าไม่มีคำถามให้ผู้ใช้เห็น | คัดลอก markup จากหน้าอื่นมาใช้กับเทมเพลตทั่วไป | ถอด FAQPage ออกจากเทมเพลต แล้วใส่เฉพาะหน้าที่มีคู่คำถามและคำตอบจริง |
| ชื่อธุรกิจในแต่ละหน้าไม่เหมือนกัน | แต่ละหน้าหรือแต่ละสาขาพิมพ์ชื่อเอง | ย้ายไปใช้ค่าคงที่กลางหนึ่งชุดที่ทุกเทมเพลตดึงไปใช้ |
หลังแก้แล้ว อย่าคาดหวังว่าผลจะเปลี่ยนทันที ระบบต้องเก็บข้อมูลหน้าใหม่อีกรอบซึ่งใช้เวลาไม่เท่ากันในแต่ละเว็บ สิ่งที่ควรทำระหว่างรอคือบันทึกวันที่แก้ไว้ เพื่อให้ตอนดูรายงานเดือนถัดไปรู้ว่าเทียบกับช่วงไหน เรื่องการอ่านข้อมูลหลังปรับเว็บมีรายละเอียดเพิ่มอยู่ใน ตารางและ Bullet Points สำหรับ AI Snippet ในส่วนที่พูดถึงการจัดรูปแบบข้อมูลให้ตรวจสอบย้อนกลับได้
สิ่งที่ไม่ควรทำกับ structured data
ความเสียหายจาก schema ที่ทำผิดวิธีมักไม่ใช่การถูกลงโทษทันที แต่เป็นการที่ข้อมูลผิดถูกกระจายต่อโดยที่เราไม่รู้ตัว เช่น ราคาเก่าที่ยังค้างอยู่ใน markup ถูกนำไปตอบลูกค้าอีกหลายเดือน ดังนั้นข้อห้ามด้านล่างจึงเป็นเรื่องความถูกต้องของข้อมูลเป็นหลัก
- ใส่ข้อมูลใน markup ที่ไม่ปรากฏบนหน้าเว็บ เช่น ใส่คำถามและคำตอบที่ผู้ใช้มองไม่เห็น
- ใส่ schema ประเภทที่ไม่ตรงกับหน้า เช่น ใส่ HowTo กับหน้าที่ไม่มีลำดับขั้นตอนอยู่จริง
- คัดลอก markup ของเว็บอื่นมาแก้เฉพาะชื่อ ซึ่งมักติดฟิลด์ที่ไม่เกี่ยวกับธุรกิจตัวเองมาด้วย
- ใส่ข้อมูลเกินจริงเพื่อให้ดูน่าเชื่อถือ เช่น ระบุรางวัลหรือการรับรองที่ไม่มีหลักฐานบนเว็บ
- ปล่อยให้ราคา สถานะสินค้า หรือเวลาทำการใน markup ค้างอยู่หลังข้อมูลจริงเปลี่ยนไปแล้ว
- ใส่ schema ให้ครบทุกชนิดที่นึกออกในหน้าเดียว ซึ่งทำให้ระบบไม่รู้ว่าหน้านี้คือหน้าอะไรกันแน่
เส้นแบ่งอยู่ที่สิ่งที่ผู้ใช้เห็น
กฎข้อเดียวที่ใช้ตัดสินได้เกือบทุกกรณีคือ ถ้าเปิดหน้าเว็บแล้วมองไม่เห็นข้อมูลนั้น ก็ไม่ควรมีข้อมูลนั้นใน markup ก่อนจะเถียงว่าใส่แล้วน่าจะได้เปรียบ ให้ถามกลับว่าถ้าลูกค้าอ่านเจอข้อความที่ระบบดึงไปตอบแล้วเปิดหน้าเว็บมาไม่เจอสิ่งเดียวกัน ธุรกิจจะอธิบายอย่างไร ความเสี่ยงด้านความน่าเชื่อถือมักแพงกว่าประโยชน์ที่หวังไว้
รอบการดูแลและทบทวน schema
schema เป็นงานที่ติดตั้งครั้งเดียวแต่ต้องดูแลต่อ เพราะข้อมูลธุรกิจเปลี่ยนเร็วกว่าโค้ด รอบที่ใช้ได้กับทีมเล็กคือตรวจสั้น ๆ ทุกเดือนและตรวจเต็มทุกไตรมาส บวกกับการตรวจทันทีเมื่อมีเหตุการณ์ที่กระทบข้อมูลหลัก
- 1ทุกเดือน เปิดรายงานข้อมูลโครงสร้างในเครื่องมือของเจ้าของเว็บ แล้วดูเฉพาะรายการที่เป็น error
- 2ทุกไตรมาส สุ่มตรวจหน้าตัวแทนของแต่ละเทมเพลตอย่างละหนึ่งหน้าด้วยเครื่องมือทดสอบ
- 3ตรวจทันทีเมื่อเปลี่ยนธีม เปลี่ยนปลั๊กอิน หรือย้ายระบบเว็บ เพราะ markup มักหายไปพร้อมเทมเพลตเดิม
- 4ตรวจทันทีเมื่อธุรกิจย้ายที่อยู่ เปลี่ยนชื่อ เปลี่ยนเวลาทำการ หรือปรับโครงสร้างราคา
- 5ทบทวนตารางกลางที่บันทึกว่าเทมเพลตไหนใช้ schema อะไร อย่างน้อยปีละครั้ง
ถ้าทีมมีเวลาจำกัดจริง ๆ ให้เลือกทำข้อแรกกับข้อสามเป็นอย่างน้อย เพราะสองข้อนี้จับปัญหาได้มากที่สุดต่อเวลาที่ลงไป ส่วนงานฝั่งเนื้อหาให้ไปลงแรงกับการทำโครงคำตอบที่ชัด ซึ่งมีผลกับ AIO มากกว่าการไล่เพิ่ม markup ดูแนวทางได้ที่ หน้าเว็บสไตล์ Q&A และ การเขียนสรุปท้ายบทความ
ถ้าเว็บใช้ระบบสำเร็จรูปที่ใส่ schema ให้อยู่แล้ว ต้องทำอะไรเพิ่มไหม+
ต้องตรวจก่อนว่าสิ่งที่ระบบใส่ให้ตรงกับข้อมูลจริงหรือไม่ โดยเฉพาะชื่อธุรกิจ ที่อยู่ และวันที่แก้ไข ระบบสำเร็จรูปมักใส่ค่าเริ่มต้นที่ไม่ตรงกับธุรกิจ เช่น ใช้ชื่อเว็บแทนชื่อบริษัท หรือใส่ผู้เขียนเป็นชื่อบัญชีผู้ดูแลระบบ ถ้าตรวจแล้วถูกต้องครบก็ไม่ต้องเพิ่มอะไร สิ่งที่ควรเพิ่มคือรอบทบทวน ไม่ใช่ markup ชุดใหม่
JSON-LD กับการฝังแอตทริบิวต์ลงใน HTML ควรเลือกแบบไหน+
เลือก JSON-LD สำหรับเว็บใหม่เกือบทุกกรณี เพราะแยกออกจากโครง HTML ทำให้แก้ง่ายและไม่หายตอนเปลี่ยนดีไซน์ ส่วนการฝังแอตทริบิวต์ลงในแท็กเนื้อหาโดยตรงเหมาะกับเว็บเก่าที่แก้เทมเพลตไม่ได้แล้ว ถ้าเว็บมีทั้งสองแบบปนกัน ให้ค่อย ๆ ย้ายมาเป็น JSON-LD ทีละเทมเพลตและอย่าให้ทั้งสองแบบประกาศข้อมูลเดียวกันพร้อมกัน
ต้องใส่ schema ให้หน้าที่ตั้ง noindex ไว้หรือไม่+
ไม่จำเป็น เพราะหน้าที่ไม่ต้องการให้เก็บเข้าระบบไม่ได้ถูกนำไปแสดงอยู่แล้ว การใส่ markup จึงไม่ได้ให้ประโยชน์เพิ่ม สิ่งที่ควรทำแทนคือตรวจว่าหน้าที่ตั้ง noindex ไว้ยังจำเป็นต้องมีอยู่จริงไหม และไม่มีลิงก์ภายในสำคัญชี้ไปที่หน้าเหล่านั้นโดยไม่ตั้งใจ
ควรใส่ schema เป็นภาษาไทยหรือภาษาอังกฤษ+
ค่าที่เป็นข้อความซึ่งผู้ใช้เห็นบนหน้า เช่น ชื่อสินค้า ชื่อบทความ และคำอธิบาย ให้ใส่เป็นภาษาเดียวกับหน้านั้น คือภาษาไทยสำหรับหน้าภาษาไทย ส่วนชื่อฟิลด์และชื่อ type เป็นคำเฉพาะของมาตรฐาน ต้องเป็นภาษาอังกฤษตามที่กำหนดเสมอ ถ้าเว็บมีหลายภาษา ให้แต่ละเวอร์ชันภาษามี markup ของตัวเองที่ตรงกับเนื้อหาบนหน้านั้น
แก้ schema แล้วนานแค่ไหนถึงจะเห็นผลในรายงาน+
ไม่มีตัวเลขแน่นอน ขึ้นกับความถี่ที่ระบบกลับมาเก็บข้อมูลหน้านั้น ซึ่งต่างกันมากระหว่างหน้าที่มีคนเข้าบ่อยกับหน้าที่เงียบ สิ่งที่ทำได้คือส่ง URL ที่แก้แล้วเข้าไปขอให้เก็บข้อมูลใหม่สำหรับหน้าสำคัญ แล้วบันทึกวันที่แก้ไว้เทียบกับรายงานรอบถัดไป อย่าสรุปผลจากรายงานที่ดูภายในไม่กี่วันหลังแก้
ธุรกิจเล็กที่มีแค่ห้าหน้า จำเป็นต้องทำ schema ไหม+
จำเป็นเฉพาะส่วนที่ใช้แรงน้อยและให้ผลกว้าง คือ Organization หรือ LocalBusiness หนึ่งชุด พร้อมข้อมูลติดต่อและเวลาทำการที่ถูกต้อง กับ BreadcrumbList ถ้าเว็บมีลำดับชั้น เท่านี้ก็เพียงพอสำหรับเว็บขนาดนั้น การทุ่มเวลาไปกับ schema ที่ซับซ้อนกว่านี้จะคุ้มน้อยกว่าการเอาเวลาไปเขียนหน้าที่ตอบคำถามลูกค้าให้ครบ
ทำโครงเนื้อหาให้พร้อมก่อน แล้ว schema จะทำงานได้เต็มที่
NOAH ช่วยวางโครงบทความ SEO ภาษาไทย ทั้งลำดับหัวข้อและชุดคำถามท้ายบทความ ซึ่งเป็นวัตถุดิบที่ทีมเว็บนำไปใส่ markup ต่อได้ ส่วนการติดตั้ง schema บนเว็บยังต้องทำในระบบเว็บของคุณเอง
เริ่มฟรี 3 บทความ