Schema.org สำหรับการปรากฏใน AI: มาร์กอัปใดที่สำคัญในตอนนี้

Schema.org สำหรับการปรากฏในปัญญาประดิษฐ์: มาร์กอัปใดที่สำคัญในตอนนี้

ณ วันที่ 5 กันยายน 2026 ข้อมูลที่มีโครงสร้างยังคงช่วยให้เครื่องมือค้นหาเข้าใจหน้าเว็บ ผู้เขียน องค์กร และข้อเท็จจริง อย่างไรก็ตาม มันไม่ใช่ปัจจัยการจัดอันดับโดยตรงสำหรับคำตอบจากปัญญาประดิษฐ์

Google ระบุว่าหน้าเว็บไม่จำเป็นต้องมีมาร์กอัป Schema.org พิเศษเพื่อปรากฏใน AI Overviews หรือ AI Mode หน้าเว็บต้องสามารถคลานได้ (crawlable) ถูกจัดทำดัชนี (indexed) มีสิทธิ์สำหรับส่วนย่อของผลการค้นหา (search snippet) และสนับสนุนด้วยเนื้อหาที่เป็นประโยชน์ Google ยังกล่าวอีกว่าข้อมูลที่มีโครงสร้างควรตรงกับเนื้อหาหน้าเว็บที่มองเห็นได้ (developers.google.com)

กลยุทธ์ที่ดีที่สุดในปัจจุบันคือ:

1. ใช้ข้อมูลที่มีโครงสร้างเพื่ออธิบายหน้าเว็บอย่างถูกต้อง
2. จับคู่มาร์กอัปกับวัตถุประสงค์ที่แท้จริงของหน้าเว็บ
3. สร้างความสัมพันธ์ที่ชัดเจนระหว่างบทความ ผู้เขียน องค์กร และหัวข้อ
4. เขียนคำตอบที่ตรงประเด็นและสมบูรณ์ใน HTML ที่มองเห็นได้
5. วัดการอ้างอิงจากปัญญาประดิษฐ์แยกต่างหากจากผลลัพธ์ที่สมบูรณ์แบบดั้งเดิม

ข้อสรุปของผู้บริหาร

ผลการวิจัยในวงกว้างมีความสำคัญ: การเพิ่มข้อมูลที่มีโครงสร้างทั่วไปเพียงอย่างเดียวไม่ได้ทำให้การอ้างอิงจากปัญญาประดิษฐ์เพิ่มขึ้นอย่างสม่ำเสมอ การศึกษาที่ควบคุมโดย Ahrefs ติดตามหน้าเว็บ 1,885 หน้าที่เพิ่ม JavaScript Object Notation for Linked Data และเปรียบเทียบกับหน้าควบคุม 4,000 หน้า พบว่าไม่มีการปรับปรุงที่มีความหมายในการอ้างอิงจาก Google AI Mode หรือ ChatGPT การอ้างอิงจาก Google AI Overview ลดลงเล็กน้อย แต่นักวิจัยเตือนว่าการเปลี่ยนแปลงนั้นเล็กน้อยและไม่สามารถตำหนิว่าเป็นผลมาจากมาร์กอัปได้อย่างชัดเจน (ahrefs.com)

รายงานก่อนตีพิมพ์ปี 2026 อีกฉบับพบว่าประเภททั่วไป เช่น Article, Organization, BreadcrumbList และ WebPage ไม่ได้คาดการณ์การอ้างอิงจากปัญญาประดิษฐ์ได้อย่างอิสระหลังจากควบคุมอันดับการค้นหาและอำนาจโดเมน สิ่งที่ค้นพบที่แข็งแกร่งที่สุดคือหน้าเว็บที่มี ข้อมูลที่เป็นรูปธรรมและมีคุณสมบัติที่หลากหลาย เช่น ราคา คะแนน และข้อกำหนด ทำงานได้ดีกว่าหน้าเว็บที่มีเพียงป้ายกำกับหน้าเว็บทั่วไป การค้นพบนั้นมุ่งเน้นไปที่หน้าผลิตภัณฑ์และหน้ารีวิวเป็นหลัก ดังนั้นจึงไม่ควรถือเป็นข้อพิสูจน์ว่าประเภทใดประเภทหนึ่งในบทความนี้สร้างข้อได้เปรียบในการอ้างอิง (aixiv.science)

สิ่งที่ข้อมูลที่มีโครงสร้างทำได้และทำไม่ได้

ข้อมูลที่มีโครงสร้างคือคำอธิบายหน้าเว็บที่เครื่องจักรสามารถอ่านได้ มันสามารถบอกเครื่องมือค้นหาว่า:

• หน้าเว็บเป็นประเภทใด
• ใครเป็นผู้เขียน
• องค์กรใดเป็นผู้เผยแพร่
• ตอบคำถามอะไร
• วันที่เผยแพร่หรืออัปเดตคือเมื่อใด
• หน้าเว็บอธิบายถึงบุคคล บริษัท คำ หรือชุดข้อมูลใด

Google กล่าวว่าข้อมูลที่มีโครงสร้างสามารถช่วยให้ระบบของตนเข้าใจเนื้อหาหน้าเว็บและทำให้หน้าเว็บมีสิทธิ์ได้รับฟีเจอร์การค้นหาที่สมบูรณ์ยิ่งขึ้น นอกจากนี้ยังกล่าวอีกว่า Google Search อาจใช้คุณสมบัติ Schema.org อื่นๆ เพื่อความเข้าใจ แม้ว่าคุณสมบัติเหล่านั้นจะไม่ทำให้เกิดผลการค้นหาที่มองเห็นได้ก็ตาม (developers.google.com)

ข้อมูลที่มีโครงสร้าง ไม่ รับประกัน:

• การจัดอันดับทั่วไปที่สูงขึ้น
• การอ้างอิงจากปัญญาประดิษฐ์
• ผลลัพธ์ที่สมบูรณ์แบบ
• Knowledge Panel
• การรวมอยู่ในคำตอบจากปัญญาประดิษฐ์
• การใช้ข้อความที่ตรงกันในมาร์กอัป

Bing ให้คำแนะนำที่คล้ายกัน คำแนะนำสำหรับผู้ดูแลเว็บในปัจจุบันกล่าวว่าข้อมูลที่มีโครงสร้างอาจสนับสนุนการให้เหตุผลที่ชัดเจนยิ่งขึ้น แต่ไม่รับประกันการมองเห็นหรือปริมาณการเข้าชมจากการอ้างอิง Bing ยังแนะนำให้ผู้เผยแพร่ระบุข้อเท็จจริงและคำจำกัดความอย่างชัดเจนในเนื้อหาหน้าเว็บที่มองเห็นได้ (bing.com)

ข้อจำกัดหลักของการวิจัย

โดยปกติแล้ว แผงคำตอบจากปัญญาประดิษฐ์จะแสดง หน้าต้นฉบับ ไม่ใช่ประเภท Schema.org ที่อาจมีอยู่ในหน้านั้น Google ไม่ได้เผยแพร่รายงานที่ระบุ เช่น ว่าหน้าเว็บถูกอ้างอิงเนื่องจากใช้ Article แทน WebPage

สิ่งนี้ทำให้เกิดคำถามสามข้อที่แตกต่างกัน:

1. หน้าเว็บถูกอ้างอิงหรือไม่?
2. หน้าเว็บมีข้อมูลที่มีโครงสร้างหรือไม่?
3. ข้อมูลที่มีโครงสร้างทำให้เกิดการอ้างอิงหรือไม่?

การศึกษาส่วนใหญ่สามารถตอบได้เพียงสองข้อแรกเท่านั้น ไม่สามารถพิสูจน์ข้อที่สามได้

นั่นคือเหตุผลที่หน้าเว็บที่มีมาร์กอัป FAQPage อาจปรากฏบ่อยครั้งในคำตอบจากปัญญาประดิษฐ์ โดยที่มาร์กอัปนั้นไม่ได้เป็นสาเหตุ หน้าเว็บนั้นอาจมีเนื้อหาที่แข็งแกร่ง มีอันดับการค้นหาสูง มีลิงก์จำนวนมาก หรือเป็นแบรนด์ที่เป็นที่รู้จักดี

ตรวจสอบตามประเภท Schema

1. Article

สิ่งที่ทำ

Article อธิบายบทความ ข่าว บล็อกโพสต์ หรือหน้าเนื้อหาบรรณาธิการที่คล้ายกัน Google รองรับ Article, NewsArticle และ BlogPosting เป็นประเภทบทความ Google ไม่ได้ระบุคุณสมบัติที่จำเป็นสำหรับมาร์กอัปบทความ แต่แนะนำให้เพิ่มคุณสมบัติที่เกี่ยวข้องกับหน้าเว็บ (developers.google.com)

คุณสมบัติที่สำคัญที่สุด

ใช้สิ่งเหล่านี้เมื่อมองเห็นได้และถูกต้อง:

• headline
• author
• author.name
• author.url หรือ author.sameAs
• datePublished
• dateModified
• image
• publisher
• mainEntityOfPage
• about
• inLanguage

Google แนะนำให้ใช้ Person หรือ Organization จริงสำหรับผู้เขียน นอกจากนี้ยังแนะนำให้รักษาวันที่ในข้อมูลที่มีโครงสร้างให้สอดคล้องกับวันที่เผยแพร่และอัปเดตที่มองเห็นได้ (developers.google.com)

ผลกระทบจากปัญญาประดิษฐ์

ระดับหลักฐาน: ทางอ้อม

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

รายการตรวจสอบ Article

• หน้าเว็บเป็นบทความจริง
• หัวข้อข่าวตรงกับชื่อเรื่องที่มองเห็นได้
• ผู้เขียนทุกคนที่มองเห็นได้ถูกรวมอยู่ด้วย
• ผู้เขียนแต่ละคนมีวัตถุ Person หรือ Organization แยกต่างหาก
• ชื่อผู้เขียนมีเฉพาะชื่อ ไม่ใช่ตำแหน่งงานหรือชื่อผู้เผยแพร่
• ลิงก์ผู้เขียนไปยังโปรไฟล์จริงหรือหน้าผู้เขียน
• วันที่เผยแพร่และอัปเดตมองเห็นได้บนหน้าเว็บ
• วันที่ใช้เขตเวลาที่ถูกต้องเมื่อมีการรวมเวลา
• รูปภาพแสดงถึงบทความ
• ผู้เผยแพร่ถูกระบุอย่างสม่ำเสมอทั่วทั้งเว็บไซต์
• บทความไม่ได้ถูกมาร์กอัปเป็นประเภทหลักอื่น เช่น HowTo เว้นแต่หน้าเว็บนั้นจะให้บริการทั้งสองวัตถุประสงค์จริงๆ

2. WebPage

สิ่งที่ทำ

WebPage เป็นประเภทหน้าเว็บทั่วไป Schema.org ระบุว่าหน้าเว็บทุกหน้าถูกถือว่าเป็น WebPage โดยปริยาย แต่การประกาศที่ชัดเจนสามารถช่วยได้เมื่อหน้าเว็บมีคุณสมบัติหรือความสัมพันธ์ระดับหน้าเว็บ (schema.org)

คุณสมบัติที่เป็นประโยชน์ได้แก่:

• url
• name
• description
• inLanguage
• dateModified
• breadcrumb
• mainEntity
• about
• isPartOf
• primaryImageOfPage

ผลกระทบจากปัญญาประดิษฐ์

ระดับหลักฐาน: ต่ำและทางอ้อม

WebPage เหมาะที่สุดที่จะใช้เป็นเลเยอร์หน้าเว็บภายนอกในกราฟที่เชื่อมโยงกัน มันสามารถเชื่อมโยงหน้าเว็บกับบทความหลัก คำจำกัดความ ชุดข้อมูล บุคคล หรือองค์กรหลัก

ไม่ควรถือว่าเป็นประเภทการเพิ่มประสิทธิภาพปัญญาประดิษฐ์พิเศษ หน้าเว็บที่มีเฉพาะวัตถุ WebPage ทั่วไปมักจะให้ข้อมูลที่เป็นประโยชน์น้อยกว่าหน้าเว็บที่ระบุเอนทิตีหลักอย่างชัดเจน

รายการตรวจสอบ WebPage

• ใช้ @id ที่เสถียรหนึ่งอันสำหรับหน้าเว็บ
• ใช้ URL ที่เป็น canonical เป็น URL ของหน้าเว็บ
• ระบุ mainEntity ที่แท้จริงของหน้าเว็บ
• เชื่อมโยงเอนทิตีหลักกลับไปยังหน้าเว็บด้วย mainEntityOfPage
• เพิ่ม inLanguage เมื่อทราบ
• รักษาชื่อและคำอธิบายหน้าเว็บให้สอดคล้องกับเนื้อหาที่มองเห็นได้
• อย่าใช้ WebPage เพื่อซ่อนความจริงที่ว่าหน้าเว็บนั้นเป็นบทความ โปรไฟล์ ชุดข้อมูล หรือหน้าคำถามจริงๆ

3. QAPage

สิ่งที่ทำ

QAPage ใช้สำหรับหน้าเว็บที่เน้น หนึ่งคำถามและคำตอบ Google กล่าวว่าใช้ข้อมูลที่มีโครงสร้าง Question จากหน้าเว็บที่ทำเครื่องหมายเป็น QAPage และควรมีเพียง QAPage เดียวและ Question หลักเดียวในหน้าเว็บ (developers.google.com)

คุณสมบัติที่จำเป็น

สำหรับการมีสิทธิ์สำหรับคำถาม-คำตอบของ Google ในปัจจุบัน:

• QAPage.mainEntity
• Question ที่ซ้อนอยู่
• Question.answerCount
• acceptedAnswer หรือ suggestedAnswer อย่างใดอย่างหนึ่ง
• Answer.text

คำถามที่ไม่มีคำตอบไม่มีสิทธิ์สำหรับผลลัพธ์ที่สมบูรณ์แบบ

กฎเนื้อหาที่สำคัญ

ห้ามใช้ QAPage สำหรับ:

• หน้าคำถามที่พบบ่อยปกติ
• บล็อกโพสต์ที่ตอบคำถาม
• บทความ How-to
• หน้าผลิตภัณฑ์ที่มีคำถามมากมาย
• คำตอบจากบรรณาธิการที่เขียนโดยเจ้าของเว็บไซต์เท่านั้น

Google กล่าวว่าผู้ใช้ต้องสามารถส่งคำตอบสำหรับ QAPage ปกติได้ ตัวอย่างที่ถูกต้องได้แก่ คำถามในฟอรัมหรือหน้าสนับสนุนที่ผู้ใช้สามารถให้คำตอบได้ (developers.google.com)

ผลกระทบจากปัญญาประดิษฐ์

ระดับหลักฐาน: การจับคู่เชิงความหมายปานกลาง ไม่มีหลักฐานการเพิ่มขึ้นเชิงสาเหตุ

หน้าคำถาม-คำตอบจริงนั้นง่ายสำหรับระบบการดึงข้อมูลที่จะเข้าใจ อย่างไรก็ตาม ไม่มีการศึกษาเชิงสาธารณะที่แข็งแกร่งใดที่พิสูจน์ว่ามาร์กอัป QAPage เพียงอย่างเดียวช่วยเพิ่มการอ้างอิงจากปัญญาประดิษฐ์

รายการตรวจสอบ QAPage

• หน้าเว็บเน้นที่คำถามเดียว
• ผู้ใช้สามารถส่งคำตอบได้ เว้นแต่หน้าเว็บจะมีคุณสมบัติสำหรับประสบการณ์คำถาม-คำตอบด้านการศึกษาพิเศษ
• คำถามเต็มมองเห็นได้
• ข้อความคำตอบเต็มมองเห็นได้
• answerCount ตรงกับจำนวนคำตอบจริง
• คำตอบที่ยอมรับและแนะนำถูกระบุอย่างถูกต้อง
• ความคิดเห็นถูกทำเครื่องหมายเป็นความคิดเห็น ไม่ใช่คำตอบ
• หน้าเว็บไม่ใช่เพียงหน้าคำถามที่พบบ่อยจากบรรณาธิการ
• หน้าเว็บไม่มีคำถามหลายข้อที่ไม่เกี่ยวข้องกัน

ตัวอย่าง QAPage

html

ใช้รูปแบบนี้เมื่อหน้าเว็บสนับสนุนการโต้ตอบคำถาม-คำตอบอย่างแท้จริงเท่านั้น

4. HowTo

สิ่งที่ทำ

HowTo อธิบายคำแนะนำแบบทีละขั้นตอน Google เคยรองรับผลลัพธ์ที่สมบูรณ์แบบ How-to แต่ได้ยกเลิกฟีเจอร์การค้นหานั้นในเดือนกันยายน 2023 Google กล่าวว่าผลลัพธ์ How-to จะไม่ปรากฏบนเดสก์ท็อปอีกต่อไปและถูกลบออกจากมือถือแล้ว (developers.google.com)

ผลกระทบจากปัญญาประดิษฐ์

ระดับหลักฐาน: ต่ำสำหรับ Google

ขั้นตอนที่มองเห็นได้ยังคงสามารถช่วยผู้ใช้และระบบการดึงข้อมูลได้ บทช่วยสอนที่ชัดเจนพร้อมหัวข้อ ขั้นตอนที่มีหมายเลข เครื่องมือ เวลา และคำเตือนนั้นอ่านและอ้างอิงได้ง่ายกว่า แต่หลักฐานปัจจุบันไม่แสดงว่ามาร์กอัป HowTo สร้างข้อได้เปรียบพิเศษใน Google AI Overviews หรือ AI Mode

คำแนะนำ

ใช้ HowTo เมื่อ:

• หน้าเว็บสอนงานอย่างแท้จริง
• ขั้นตอนต่างๆ มองเห็นได้ในเนื้อหาหน้าเว็บ
• เครื่องมือค้นหา แพลตฟอร์ม หรือระบบภายในอื่นๆ ได้รับประโยชน์จากมาร์กอัป
• ทีมของคุณสามารถดูแลได้โดยไม่สร้างข้อมูลที่ขัดแย้งกัน

สำหรับ Google Search ให้จัดลำดับความสำคัญของหัวข้อ HTML ที่แข็งแกร่ง รายการที่มีหมายเลข คำแนะนำที่ชัดเจน และรูปภาพหรือวิดีโอที่เป็นประโยชน์

รายการตรวจสอบบทช่วยสอน

• หน้าเว็บสอนงานจริง
• ผลลัพธ์ของงานชัดเจน
• แต่ละขั้นตอนมองเห็นได้และสมบูรณ์
• ชื่อขั้นตอนตรงกับหัวข้อที่มองเห็นได้
• เครื่องมือและอุปกรณ์เป็นของจริงและมองเห็นได้
• การประมาณเวลาถูกต้อง
• มีคำเตือนด้านความปลอดภัยเมื่อจำเป็น
• ส่วนแรกให้คำตอบสั้นๆ หรือผลลัพธ์
• หน้าเว็บไม่ได้อาศัยมาร์กอัปในการให้คำแนะนำ

5. ClaimReview

สิ่งที่ทำ

ClaimReview ได้รับการออกแบบมาสำหรับเนื้อหาการตรวจสอบข้อเท็จจริง Google ได้ยกเลิกการสนับสนุน Claim Review ใน Search ซึ่งเป็นส่วนหนึ่งของความพยายามในการทำให้ผลการค้นหาง่ายขึ้นในปี 2025 ประเภทนี้ถูกลบออกจากการรายงานของ Search Console และ Rich Results Test (developers.google.com)

ผลกระทบจากปัญญาประดิษฐ์

ระดับหลักฐาน: ไม่มีข้อได้เปรียบจาก Google ในปัจจุบัน

การตรวจสอบข้อเท็จจริงที่มีคุณภาพสูงยังคงสามารถอ้างอิงได้เนื่องจากระบุอย่างชัดเจนถึง:

• ข้ออ้าง
• คะแนน
• หลักฐาน
• วันที่
• องค์กรตรวจสอบข้อเท็จจริง
• เหตุผลเบื้องหลังข้อสรุป

ประโยชน์เหล่านั้นส่วนใหญ่มาจากเนื้อหาเอง ไม่ใช่จากฟีเจอร์การค้นหาของ Google ที่ถูกยกเลิกไปแล้ว

คำแนะนำ

สำหรับหน้าข้อเท็จจริง:

1. ใช้ Article หรือ NewsArticle เมื่อหน้าเว็บเป็นเนื้อหาบรรณาธิการ
2. ระบุข้ออ้างอย่างชัดเจนในข้อความที่มองเห็นได้
3. อ้างอิงหลักฐานหลัก
4. ระบุผู้เขียนและองค์กรผู้ตรวจทาน
5. เพิ่มวันที่เผยแพร่และวันที่ตรวจทาน
6. ใช้ ClaimReview เฉพาะในกรณีที่แพลตฟอร์มหรือระบบข้อมูลอื่นต้องการโดยเฉพาะเท่านั้น

อย่าเพิ่ม ClaimReview เพียงเพราะคุณคาดหวังว่าคำตอบจากปัญญาประดิษฐ์ของ Google จะชอบมัน

6. FAQPage

สิ่งที่ทำ

FAQPage อธิบายหน้าเว็บที่มีคำถามและคำตอบที่เป็นทางการ Google หยุดแสดงผลลัพธ์ที่สมบูรณ์แบบ FAQ ใน Search ตั้งแต่ 7 พฤษภาคม 2026 และได้ลบเอกสารที่เกี่ยวข้องในเดือนมิถุนายน 2026 (developers.google.com)

ผลกระทบจากปัญญาประดิษฐ์

ระดับหลักฐาน: อ่อนและผสมผสาน

การศึกษาจากผู้จำหน่าย 90 วันได้เพิ่มมาร์กอัป FAQPage ลงในหน้าเว็บ 120 หน้า พบว่าไม่มีการปรับปรุงที่น่าเชื่อถือในการอ้างอิงจาก ChatGPT, Gemini หรือ Google AI Overview Perplexity แสดงการเพิ่มขึ้นเล็กน้อย แต่การศึกษาเองกล่าวว่าผลลัพธ์นั้นเฉพาะแพลตฟอร์มและไม่ได้พิสูจน์สาเหตุ (authorityradar.com)

การศึกษาอีกชิ้นหนึ่งของหน้าเว็บ 615 หน้าที่ถูกอ้างอิงอยู่แล้วพบว่ามาร์กอัป FAQ ปรากฏบ่อยขึ้นบนหน้าเว็บที่ถูกอ้างอิงอย่างหนัก ความสัมพันธ์นั้นหายไปหลังจากควบคุมหน้าเว็บที่ซ้ำกันจากผู้เผยแพร่รายเดียวกัน นักวิจัยสรุปว่าหลักฐานไม่สามารถยืนยันผลกระทบจากมาร์กอัปเองได้ (getintel.ai)

คำแนะนำ

ใช้คำถามที่พบบ่อยเมื่อช่วยปรับปรุงหน้าเว็บสำหรับผู้อ่าน อย่าเพิ่มบล็อกคำถามทั่วไปขนาดใหญ่เพียงเพื่อมุ่งเป้าไปที่คำตอบจากปัญญาประดิษฐ์

หากคุณเก็บมาร์กอัป FAQPage ไว้สำหรับเครื่องมือค้นหาหรือระบบเนื้อหาอื่น:

• ทำให้ทุกคำถามมองเห็นได้
• ทำให้ทุกคำตอบสมบูรณ์
• รักษามาร์กอัปให้เหมือนกับหน้าเว็บ
• อย่าทำซ้ำคำถามเดียวกันในบล็อก Schema หลายบล็อก
• อย่าคาดหวังผลลัพธ์ที่สมบูรณ์แบบ Google FAQ

ตัวอย่าง FAQPage สำหรับผู้บริโภคที่ไม่ใช่ Google

html

นี่คือคำอธิบายเชิงความหมาย ไม่ใช่คำสัญญาของฟีเจอร์การค้นหาของ Google

7. Organization

สิ่งที่ทำ

Organization ช่วยให้ Google เข้าใจและแยกแยะบริษัท องค์กรไม่แสวงหากำไร ผู้เผยแพร่ โรงเรียน หรือองค์กรอื่นๆ Google กล่าวว่ามาร์กอัปองค์กรสามารถส่งผลต่อองค์ประกอบภาพ เช่น โลโก้ที่แสดงใน Search และข้อมูลใน Knowledge Panel บางส่วน ไม่มีคุณสมบัติที่จำเป็นในคู่มือองค์กรปัจจุบันของ Google (developers.google.com)

คุณสมบัติที่แนะนำ

ใช้คุณสมบัติที่เป็นจริงและมองเห็นได้:

• name
• alternateName
• url
• logo
• sameAs
• description
• telephone
• email
• address
• identifier
• foundingDate
• parentOrganization

ผลกระทบจากปัญญาประดิษฐ์

ระดับหลักฐาน: ทางอ้อมแต่มีประโยชน์

Organization สามารถเชื่อมโยง:

• ผู้เผยแพร่กับบทความ
• บริษัทกับผลิตภัณฑ์หรือบริการ
• แบรนด์กับโปรไฟล์อย่างเป็นทางการ
• องค์กรกับอัตลักษณ์เว็บที่เป็นที่รู้จัก

สิ่งนี้มีประโยชน์สำหรับการแยกแยะเอนทิตี มันไม่ได้พิสูจน์ว่าระบบปัญญาประดิษฐ์จะอ้างอิงหน้าเว็บนั้น

รายการตรวจสอบ Organization

• วางวัตถุองค์กรแบบเต็มบนหน้าแรกหรือหน้าองค์กร
• ใช้ @id ที่เสถียร เช่น https://www.example.com/#organization
• ใช้ชื่อองค์กรสาธารณะที่ถูกต้องแม่นยำ
• เชื่อมโยงไปยังโปรไฟล์อย่างเป็นทางการจริงด้วย sameAs
• ใช้ประเภทย่อยขององค์กรที่ถูกต้องเมื่อเหมาะสม
• ใช้โลโก้จริงที่แสดงถึงองค์กร
• รักษาข้อมูลติดต่อให้เป็นปัจจุบัน
• อ้างอิงองค์กรจากบทความแทนที่จะสร้างเวอร์ชันที่ขัดแย้งกันในทุกหน้า

8. Person

สิ่งที่ทำ

Person ระบุบุคคลที่เขียน ตรวจสอบ เป็นเจ้าของ จัดการ หรือปรากฏบนหน้าเว็บ มักมีประโยชน์มากที่สุดเมื่อเชื่อมโยงกับ:

• Article.author
• ผู้เขียนคำถามหรือคำตอบของ QAPage
• ProfilePage.mainEntity
• Organization.employee
• Review.author

คำแนะนำโปรไฟล์ของ Google ระบุว่าหน้าโปรไฟล์ต้องเน้นที่บุคคลหรือองค์กรหนึ่ง ProfilePage ต้องมี mainEntity และเอนทิตีนั้นต้องเป็น Person หรือ Organization บุคคลหรือองค์กรต้องมี name หรือ alternateName เมื่อไม่มีชื่อที่ใช้ได้ (developers.google.com)

คุณสมบัติที่แนะนำ

• name
• url
• sameAs
• image
• description
• jobTitle
• worksFor
• knowsAbout
• affiliation
• identifier

ผลกระทบจากปัญญาประดิษฐ์

ระดับหลักฐาน: ทางอ้อม

มาร์กอัป Person สามารถช่วยเชื่อมโยงชื่อผู้เขียนกับ:

• ชีวประวัติ
• ตำแหน่งงานหรือบทบาท
• องค์กร
• บทความที่เผยแพร่
• โปรไฟล์ภายนอก
• สาขาความเชี่ยวชาญ

ใช้เพื่อให้อัตลักษณ์ชัดเจน ไม่ใช่เพื่ออ้างความเชี่ยวชาญที่หน้าเว็บไม่สนับสนุน

รายการตรวจสอบ Person

• ใช้ Person สำหรับบุคคลจริงเท่านั้น
• ใช้ Organization สำหรับบริษัทหรือสิ่งพิมพ์
• เชื่อมโยงบุคคลไปยังหน้าผู้เขียนที่มองเห็นได้
• ใช้ sameAs สำหรับโปรไฟล์อย่างเป็นทางการที่ถูกต้องเท่านั้น
• รักษาตำแหน่งงานและคุณวุฒิให้เป็นปัจจุบัน
• เพิ่มผู้เขียนที่มองเห็นได้ทั้งหมด ไม่ใช่แค่ผู้เขียนหลัก
• ใช้ @id บุคคลเดียวกันทั่วทั้งบทความและหน้าโปรไฟล์

เมทริกซ์คุณสมบัติที่จำเป็น

คำแนะนำทั่วไปของ Google ชื่นชอบ ข้อมูลที่สมบูรณ์และถูกต้องมากกว่ามาร์กอัปที่ไม่สมบูรณ์จำนวนมาก นอกจากนี้ยังเตือนว่าข้อมูลที่มีโครงสร้างต้องแสดงถึงเนื้อหาที่มองเห็นได้ และมาร์กอัปที่ถูกต้องยังคงไม่รับประกันผลลัพธ์ที่สมบูรณ์แบบ (developers.google.com)

รายการตรวจสอบการนำไปใช้ตามกรณีการใช้งาน

หน้าข้อเท็จจริง

การผสมผสานที่ดีที่สุด:

• WebPage
• Article หรือ NewsArticle
• Person
• Organization
• ClaimReview (ทางเลือก) สำหรับผู้บริโภคอื่นที่รองรับเท่านั้น

รายการตรวจสอบ:

• ระบุข้อเท็จจริงหลักใกล้ด้านบนของหน้าเว็บ
• ระบุแหล่งที่มาของข้อเท็จจริง
• เชื่อมโยงไปยังหลักฐานหลัก
• รวมถึงวันที่เผยแพร่และวันที่ตรวจทานล่าสุด
• ระบุผู้เขียนและผู้ตรวจทาน
• แยกข้อเท็จจริงออกจากความคิดเห็น
• ใช้ Article เมื่อหน้าเว็บเป็นเนื้อหาบรรณาธิการ
• ห้ามใช้ ClaimReview เป็นกลยุทธ์ Google Search ในปัจจุบัน

หน้าคำจำกัดความ

การผสมผสานที่ดีที่สุด:

• WebPage
• DefinedTerm
• Article (ทางเลือก) หากหน้าเว็บเป็นการอธิบายเนื้อหาบรรณาธิการยาวๆ
• Organization หรือ Person เมื่อมีผู้เชี่ยวชาญหรือผู้เผยแพร่รับผิดชอบ

DefinedTerm มีไว้สำหรับคำ วลี รหัส หรือแนวคิดที่มีคำจำกัดความอย่างเป็นทางการ คุณสมบัติหลักได้แก่ name, description, termCode, inDefinedTermSet และ sameAs (schema.org)

รายการตรวจสอบ:

• ให้คำจำกัดความในย่อหน้าแรก
• ใช้คำที่ชัดเจนหนึ่งคำเป็นเอนทิตีหลัก
• เพิ่มชื่อสำรองเมื่อเป็นชื่อจริงเท่านั้น
• เชื่อมโยงไปยังคำจำกัดความภายนอกที่น่าเชื่อถือเมื่อเหมาะสม
• อธิบายคำศัพท์ด้วยภาษาที่เข้าใจง่าย
• ใช้ตัวอย่างและขอบเขต
• หลีกเลี่ยงการทำเครื่องหมายรายการคำศัพท์ที่ไม่เกี่ยวข้องกันเป็น DefinedTerm เดียว

บทช่วยสอน

การผสมผสานที่ดีที่สุด:

• WebPage
• HowTo เฉพาะเมื่อผู้บริโภคอื่นต้องการเท่านั้น
• Article เมื่อบทช่วยสอนเป็นบทความบรรณาธิการด้วย
• Person และ Organization สำหรับการระบุผู้เขียน

รายการตรวจสอบ:

• ระบุผลลัพธ์ก่อนขั้นตอน
• ใช้หัวข้อที่มองเห็นได้แบบมีหมายเลข
• ให้แต่ละขั้นตอนเน้นที่การกระทำเดียว
• รวมถึงเครื่องมือ อุปกรณ์ เวลา และคำเตือนเมื่อจำเป็น
• เพิ่มรูปภาพหรือวิดีโอเมื่อช่วยได้
• อย่าซ่อนขั้นตอนไว้ใน JSON-LD เท่านั้น
• อย่าคาดหวังผลลัพธ์ที่สมบูรณ์แบบ How-to ใน Google Search

แคตตาล็อกข้อมูล

การผสมผสานที่ดีที่สุด:

• WebPage
• DataCatalog
• Dataset
• DataDownload
• Organization

Schema.org กำหนด Dataset ว่าเป็นแหล่งข้อมูลที่มีโครงสร้างและรองรับความสัมพันธ์ เช่น includedInDataCatalog และ distribution (schema.org)

Google ชี้แจงในปลายปี 2025 ว่าข้อมูลที่มีโครงสร้าง Dataset ถูกใช้โดย Dataset Search และไม่ใช่ฟีเจอร์ผลการค้นหาทั่วไปของ Google Search ดังนั้นจึงควรถือเป็นเลเยอร์การค้นหาข้อมูลและการทำงานร่วมกัน ไม่ใช่ทางลัดในการอ้างอิงจากปัญญาประดิษฐ์ (developers.google.com)

รายการตรวจสอบ:

• ให้แต่ละชุดข้อมูลมีตัวระบุที่เสถียร
• ระบุหัวข้อและขอบเขต
• รวมถึงผู้เผยแพร่หรือผู้สร้าง
• เพิ่มช่วงวันที่ที่ข้อมูลครอบคลุม
• ระบุพื้นที่ทางภูมิศาสตร์เมื่อเกี่ยวข้อง
• อธิบายใบอนุญาตและเงื่อนไขการเข้าถึง
• เพิ่มไฟล์ที่ดาวน์โหลดได้แต่ละไฟล์เป็น DataDownload
• รวมถึงรูปแบบไฟล์และ URL ดาวน์โหลด
• รักษาเมตาดาตาแคตตาล็อกให้ซิงโครไนซ์กับไฟล์จริง
• บันทึกความถี่ในการอัปเดตและวันที่อัปเดตล่าสุด

ตัวอย่าง JSON-LD: หน้าข้อเท็จจริง

ตัวอย่างนี้เชื่อมโยงหน้าเว็บ บทความ ผู้เขียน ผู้เผยแพร่ และหัวข้อ แทนที่ทุกค่าด้วยข้อมูลที่ปรากฏบนหน้าจริง

html

ตัวอย่าง JSON-LD: หน้าคำจำกัดความ

html

คำจำกัดความต้องปรากฏเป็นข้อความหน้าเว็บปกติด้วย อย่าใส่คำจำกัดความไว้ในข้อมูลที่มีโครงสร้างเท่านั้น

ตัวอย่าง JSON-LD: บทช่วยสอน

เนื่องจากผลลัพธ์ที่สมบูรณ์แบบ How-to ของ Google ถูกยกเลิกไปแล้ว ให้ถือว่านี่เป็นมาร์กอัปทางเลือกสำหรับระบบอื่น หน้าที่มองเห็นได้ยังคงควรมีคำแนะนำฉบับเต็ม

html

ตัวอย่าง JSON-LD: แคตตาล็อกข้อมูล

html

ข้อผิดพลาดทั่วไปในการนำไปใช้

Schema ที่ไม่ตรงกัน

ข้อผิดพลาดที่ร้ายแรงที่สุดคือการทำมาร์กอัปเนื้อหาที่ผู้ใช้มองไม่เห็น Google กล่าวว่าข้อมูลที่มีโครงสร้างต้องเป็นตัวแทนที่แท้จริงของหน้าเว็บ และเนื้อหาที่ทำให้เข้าใจผิดหรือซ่อนอยู่อาจทำให้หน้าเว็บไม่มีสิทธิ์ได้รับผลลัพธ์ที่สมบูรณ์แบบ (developers.google.com)

ตัวอย่างทั่วไป:

• การทำเครื่องหมายบทความเป็น HowTo ทั้งที่ไม่มีขั้นตอนจริง
• การทำเครื่องหมายบริษัทเป็นผู้เขียน ทั้งที่บทความเขียนโดยบุคคล
• การเพิ่มคำตอบ FAQ ที่ไม่ปรากฏบนหน้าเว็บ
• การใช้ วันที่เผยแพร่ในอนาคต
• การทำเครื่องหมายบล็อกโพสต์ทั่วไปเป็น QAPage
• การเพิ่ม ClaimReview ในบทความแสดงความคิดเห็น

คำตอบที่เบาบาง

ข้อมูลที่มีโครงสร้างไม่สามารถเติมเต็มหน้าว่างเปล่าได้

คำตอบที่สั้นและคลุมเครือภายใน Answer.text หรือ acceptedAnswer ไม่ได้สร้างแหล่งข้อมูลที่แข็งแกร่ง เนื้อหาที่มองเห็นได้ควร:

• ตอบคำถามโดยตรง
• อธิบายข้อจำกัดและข้อยกเว้นที่สำคัญ
• ระบุแหล่งที่มา
• รวมถึงวันที่ ตัวอย่าง หรือการวัดผลเมื่อมีประโยชน์
• สามารถยืนอยู่ได้ด้วยตัวเองเมื่อคัดลอกออกไปจากบริบท

คำแนะนำด้านปัญญาประดิษฐ์ของ Google กล่าวว่าไม่มีความยาวหน้าเว็บที่เหมาะสม และไม่จำเป็นต้องแบ่งเนื้อหาออกเป็นชิ้นเล็กๆ สำหรับระบบปัญญาประดิษฐ์ เป้าหมายที่ดีกว่าคือเนื้อหาที่เป็นประโยชน์ สมบูรณ์ และเน้นผู้คนเป็นอันดับแรก (developers.google.com)

เอนทิตีซ้ำกัน

หลีกเลี่ยงการเผยแพร่หลายเวอร์ชันที่ขัดแย้งกันขององค์กร ผู้เขียน หรือหน้าเว็บเดียวกัน

การนำไปใช้ที่อ่อนแอ:

• วัตถุ Organization หนึ่งอันที่มีหนึ่งชื่อบนหน้าแรก
• วัตถุที่สองที่มีชื่อต่างกันในทุกบทความ
• วัตถุที่สามที่ไม่มี @id บนหน้าผู้เขียน

การนำไปใช้ที่ดีขึ้น:

• ให้ @id ที่เสถียรหนึ่งอันแก่องค์กร
• ให้ @id ที่เสถียรหนึ่งอันแก่ผู้เขียนแต่ละคน
• อ้างอิงวัตถุเหล่านั้นจากบทความ โปรไฟล์ และหน้าคำถาม
• รักษาชื่อ โลโก้ URL และลิงก์อัตลักษณ์ภายนอกให้สอดคล้องกัน

คำถามซ้ำกัน

อย่าทำซ้ำคำถามเดียวกันใน:

• FAQPage
• QAPage
• มาร์กอัปบทความ
• หลายส่วนของหน้าเว็บที่มองเห็นได้
• บล็อก JSON-LD หลายบล็อก

ใช้ประเภท Schema ที่ตรงกับวัตถุประสงค์หลักของหน้าเว็บ คำตอบที่ชัดเจนเพียงคำตอบเดียวดีกว่าบล็อกมาร์กอัปที่ทับซ้อนกันหลายบล็อก

วันที่ไม่ถูกต้อง

Google ใช้แหล่งข้อมูลหลายแหล่งเพื่อประมาณวันที่เผยแพร่และอัปเดต ขอแนะนำให้วันที่ที่มองเห็นได้และวันที่ที่มีโครงสร้างตรงกัน และเตือนไม่ให้ใช้วันที่ในอนาคตหรือวันที่ที่เกี่ยวข้องกับเหตุการณ์ที่กล่าวถึงในบทความ แทนที่จะเป็นวันที่ที่เกี่ยวข้องกับหน้าเว็บเอง (developers.google.com)

การใช้ sameAs มากเกินไป

ลิงก์ sameAs ควรสื่อถึงบุคคลหรือองค์กรในโลกแห่งความจริงเดียวกัน ห้ามเชื่อมโยงไปยัง:

• โปรไฟล์โซเชียลที่ไม่เกี่ยวข้อง
• หน้าผลการค้นหา
• รายการไดเรกทอรีทั่วไป
• หน้าที่มีการสะกดหรืออัตลักษณ์ที่แตกต่างกัน
• โปรไฟล์ที่องค์กรไม่ได้ควบคุม

มาร์กอัปเฉพาะ JavaScript

Google สามารถประมวลผลข้อมูลที่มีโครงสร้างที่เพิ่มลงในหน้าเว็บที่แสดงผล แต่การนำไปใช้เฉพาะ JavaScript อาจตรวจจับได้ยากขึ้นสำหรับผู้รวบรวมข้อมูลและเครื่องมือตรวจสอบอื่นๆ บล็อก JSON-LD ที่แสดงผลโดยเซิร์ฟเวอร์มักจะทดสอบและดูแลรักษาง่ายกว่า (developers.google.com)

แผนการทดสอบเชิงปฏิบัติ

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

ก่อนการเปลี่ยนแปลง

บันทึก:

• คำค้นหาเป้าหมาย
• อันดับทั่วไปปัจจุบัน
• มีคำตอบจากปัญญาประดิษฐ์ปรากฏหรือไม่
• หน้าใดที่ถูกอ้างอิง
• ตำแหน่งการอ้างอิงเมื่อมี
• ปริมาณการเข้าชมจากการค้นหา
• การเปลี่ยนใจลูกค้า
• ข้อมูลที่มีโครงสร้างปัจจุบัน
• การเปลี่ยนแปลงเนื้อหาที่ทำขึ้นระหว่างช่วงการทดสอบ

ระหว่างการทดสอบ

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

Ahrefs ใช้การควบคุมที่ตรงกันและวิธีความแตกต่างในความแตกต่างก่อนและหลัง แนวทางนี้เป็นแบบจำลองที่เป็นประโยชน์สำหรับองค์กรที่ต้องการทดสอบข้อมูลที่มีโครงสร้างแทนที่จะสมมติว่าความสัมพันธ์พิสูจน์สาเหตุ (ahrefs.com)

หลังการเปลี่ยนแปลง

ติดตาม:

• ข้อมูลประสิทธิภาพปัญญาประดิษฐ์ของ Google Search Console
• การอ้างอิงจาก Google AI Overview
• การอ้างอิงจาก Google AI Mode
• การอ้างอิงจากปัญญาประดิษฐ์ของ Bing Webmaster Tools
• การอ้างอิงจาก ChatGPT, Gemini หรือ Perplexity เมื่อเกี่ยวข้อง
• อันดับทั่วไป
• การคลิกจากการค้นหา
• การเปลี่ยนใจลูกค้าที่ได้รับการสนับสนุน

Google รายงานปริมาณการเข้าชมจากการค้นหาด้วยปัญญาประดิษฐ์ผ่านการรายงานประสิทธิภาพของ Search Console การรายงานประสิทธิภาพปัญญาประดิษฐ์ของ Bing แสดงหน้าเว็บที่ถูกอ้างอิงและคำค้นหาที่ใช้ในการสร้างพื้นฐาน แต่ไม่ได้แสดงเหตุผลที่เลือกหน้าเว็บหรือความสำคัญของหน้าเว็บนั้นในคำตอบ (developers.google.com)

ลำดับการนำไปใช้ที่แนะนำ

สำหรับผู้เผยแพร่ส่วนใหญ่ ลำดับที่ดีที่สุดคือ:

1. แก้ไขเนื้อหาที่มองเห็นได้ก่อน
2. ทำให้การรวบรวมข้อมูลและการจัดทำดัชนีมีความน่าเชื่อถือ
3. นำ Article ไปใช้กับหน้าเนื้อหาบรรณาธิการจริง
4. เชื่อมโยงผู้เขียนเข้ากับ Person และหน้าโปรไฟล์
5. เชื่อมโยงผู้เผยแพร่เข้ากับ Organization
6. ใช้ WebPage เป็นเลเยอร์กราฟระดับหน้าที่สะอาด
7. ใช้ QAPage สำหรับคำถามของชุมชนที่แท้จริงเท่านั้น
8. ใช้ DefinedTerm สำหรับหน้าอภิธานศัพท์และคำจำกัดความ
9. ใช้ Dataset และ DataCatalog สำหรับแหล่งข้อมูล
10. ถือว่า FAQPage, HowTo และ ClaimReview เป็นมาร์กอัปสำรองหรือไม่ใช่ของ Google เนื่องจากฟีเจอร์การค้นหาของ Google สำหรับสิ่งเหล่านี้ถูกลบหรือยกเลิกแล้ว

สรุป

บทเรียนที่แข็งแกร่งที่สุดในปัจจุบันนั้นเรียบง่าย: มาร์กอัป Schema.org ช่วยให้เครื่องจักรเข้าใจเนื้อหา แต่ไม่ได้รับประกันว่าจะปรากฏในคำตอบจากปัญญาประดิษฐ์

การนำไปใช้ที่ยั่งยืนที่สุดไม่ใช่การรวบรวมประเภท Schema จำนวนมาก แต่เป็นกราฟเอนทิตีขนาดเล็กที่ถูกต้องแม่นยำ:

• Article อธิบายหน้าเนื้อหาบรรณาธิการ
• Person ระบุผู้เขียน
• Organization ระบุผู้เผยแพร่
• WebPage เชื่อมโยงหน้าเว็บกับเอนทิตีหลัก
• QAPage อธิบายคำถามของผู้ใช้ที่แท้จริงและคำตอบ
• DefinedTerm ชี้แจงคำจำกัดความ
• Dataset และ DataCatalog อธิบายแหล่งข้อมูลที่มีโครงสร้าง

ใช้ข้อมูลที่มีโครงสร้างในส่วนที่เพิ่มความหมายที่ชัดเจน อย่าใช้เพื่อปกปิดเนื้อหาที่เบาบาง ทำซ้ำข้อความที่มองเห็นได้ หรือเลียนแบบฟีเจอร์การค้นหาที่ Google ไม่รองรับอีกต่อไป สำหรับการปรากฏในปัญญาประดิษฐ์ งานที่มีมูลค่าสูงสุดยังคงเป็น **คำตอบที่ชัดเจน หลักฐานที่แข็งแกร่ง เอนทิตีที่ถูกต้อง ข้อมูลที่เป็นปัจจุบัน และเนื้อหาที่สามารถยืนอยู่ได้ด้วยตัวเอง