การติดแท็กเอนทิตีใน Knowledge Graph: Schema และการตรวจสอบสำหรับ Organization/Product/Person
1. ทำไม AI ถึงมักมองบริษัทของคุณเป็น “กลุ่มคำที่คลุมเครือ”
เมื่อผู้ใช้ถาม ChatGPT ว่า “บริษัท crater ที่ทำเว็บไซต์อิสระสำหรับตลาดต่างประเทศในหางโจวเป็นอย่างไรบ้าง” ถ้า AI ตอบไม่ได้หรือตอบผิดคน สาเหตุรากมักอยู่ที่มันไม่ได้ระบุว่า “crater” เป็นเอนทิตีที่มีคุณสมบัติชัดเจน มันเคยอ่านคำนี้ แต่ไม่รู้ว่าชื่อเต็มของบริษัทคืออะไร ทำธุรกิจอะไร เว็บไซต์ทางการคือที่ไหน ใครเป็นผู้ก่อตั้ง
การระบุเอนทิตีต่างจากการดึงคำค้นทั่วไป การจับคู่คำค้นเพียงต้องการให้คำปรากฏตามตัวอักษร แต่การระบุเอนทิตีต้องอาศัยกลุ่มคุณสมบัติที่ยืนยันซึ่งกันและกัน ทั้งชื่อเต็มบริษัท เว็บไซต์ทางการ โลโก้ ปีที่ก่อตั้ง คนที่เกี่ยวข้อง และผลิตภัณฑ์ที่เกี่ยวข้อง ยิ่งคุณสมบัติกลุ่มนี้ครบถ้วนและสอดคล้องกันข้ามเว็บไซต์มากเท่าไร โมเดลก็ยิ่งมั่นใจว่ามันคือ “สิ่งหนึ่ง” ไม่ใช่แค่ตัวอักษรไม่กี่ตัว ดูวิธีที่เอนทิตีถูกสร้างในคำตอบ AI ได้ที่Knowledge Graph และ Entity Markup。
| สถานะการระบุ | พฤติกรรม AI | สาเหตุราก |
|---|---|---|
| ไม่ระบุเลย | ตอบไม่ตรงคำถามหรือมองข้าม | ไม่มีแท็กเอนทิตีในเว็บ ไม่มีแหล่งอ้างอิงภายนอก |
| มองเป็นกลุ่มคำทั่วไป | ถูกกล่าวถึงตามตัวอักษรแต่คุณสมบัติผิด | คุณสมบัติไม่ครบ ไม่สอดคล้องข้ามเว็บ |
| ระบุเป็นเอนทิตี | เชื่อมโยงเว็บไซต์ทางการและธุรกิจได้ถูกต้อง | คุณสมบัติสอดคล้องกัน 3 เว็บไซต์ + แหล่งอ้างอิงที่น่าเชื่อถือ |
2. รายการคุณสมบัติบังคับของเอนทิตี 3 ประเภท
เอนทิตีสามประเภท แต่ละประเภทมีชุดคุณสมบัติที่ต้องกรอก Organization ดูแลตัวบริษัท Product ดูแลสินค้าแต่ละชิ้น Person ดูแลคนที่Representบริษัทได้ อย่าใส่เยอะเกินไป เริ่มจากกรอกเฉพาะช่องบังคับให้ถูกก่อน แล้วค่อยคิดถึงคุณสมบัติเสริม
Organization อย่างน้อยต้องมี name, legalName, url, logo, sameAs, foundingDate ส่วน Product อย่างน้อยต้องมี name, image, description, brand, sku และ Person อย่างน้อยต้องมี name, jobTitle, affiliation, sameAs ฟิลด์ sameAs คือหัวใจที่สุด เพราะเชื่อมเอนทิตีในเว็บของคุณกับหน้าโปรไฟล์ที่น่าเชื่อถือภายนอก โมเดลจึงกล้ายืนยันว่าเป็นบริษัทเดียวกัน
| ประเภทเอนทิตี | คุณสมบัติบังคับ | คุณสมบัติที่แนะนำให้เพิ่ม | ตำแหน่งติดตั้ง |
|---|---|---|---|
| Organization | name, legalName, url, logo, sameAs | foundingDate, address, description | หน้าแรกทั้งเว็บ + หน้า About |
| Product | name, image, description, brand | sku, category, material, ข้อมูลจำเพาะ | ทุกหน้าสินค้า |
| Person | name, jobTitle, affiliation, sameAs | alumniOf, knowsAbout | หน้าทีม/ผู้เชี่ยวชาญ |
ตัวอย่างสถานการณ์จริง: สมมติคุณเป็นบริษัท B2B ที่ผลิตเซนเซอร์อุตสาหกรรม หน้าแรกของเว็บไซต์ให้ใส่ Organization markup พร้อมระบุ sameAs สามรายการ ได้แก่ เว็บไซต์ทางการ หน้า LinkedIn และหน้า Crunchbase ทุกหน้าสินค้าให้ใส่ Product markup แล้วกรอกข้อมูลรุ่น ช่วงการวัด ความแม่นยำ และวัสดุลงไป หน้าทีมให้ใส่ Person markup ให้ผู้ก่อตั้งและหัวหน้าวิศวกร ทำครบสามขั้นนี้แล้วลองถาม AI ว่า “เซนเซอร์วัดอุณหภูมิของบริษัท X มีความแม่นยำเท่าไหร่” โอกาสที่ AI จะตอบถูกจะสูงขึ้นอย่างชัดเจน
สาม วิธีเขียน Schema และตำแหน่งที่ติดตั้ง
ใช้รูปแบบ JSON-LD ฝังใน head ของหน้าเว็บ ดูแลรักษาง่ายกว่า microdata หรือ RDFa วาง Organization ไว้ที่หน้าแรกและหน้า About วาง Product ไว้ที่ทุกหน้าสินค้า วาง Person ไว้ที่หน้าทีม สิ่งสำคัญคือชื่อย่อ ชื่อเต็ม และชื่อภาษาอังกฤษของบริษัทต้องตรงกันทุกตัวอักษรในทั้งสามประเภท markup ถ้าชื่อย่อไม่ตรงกับชื่อเต็ม โมเดลจะมองว่าเป็นสองเอนทิตีที่แยกกัน
อย่าใช้เทมเพลตทั้งเว็บไซต์ยัดคุณสมบัติว่างๆ ลงไปเป็นชุด คุณสมบัติที่เว้นว่างไว้ยังดีกว่าไม่กรอก ส่วนคุณสมบัติที่กรอกมั่วจะปนเปื้อนเอนทิตี ทุกครั้งที่เพิ่มคุณสมบัติ ต้องมั่นใจว่ามันปรากฏอยู่ในเนื้อหาที่มองเห็นบนหน้าเว็บด้วย นั่นคือ “เครื่องอ่านได้” กับ “คนอ่านได้” ต้องตรงกัน วาง JSON-LD ไว้ใน head ของหน้า หนึ่งหน้าให้มี markup หลักเพียงชุดเดียวตามประเภทที่ตรงกัน อย่าเอา Organization, Product และ Person ทั้งสามชุดยัดใส่หน้าสินค้าหน้าเดียวกัน เพราะโมเดลจะตัดสินเอนทิตีหลักผิด ดูรายการ markup ที่ B2B ทำได้จริงได้ที่ข้อมูลแบบมีโครงสร้าง Schema: รายการ markup สำหรับเว็บไซต์ B2B。
| องค์ประกอบ | จุดสำคัญในการเขียน | ข้อผิดพลาดที่พบบ่อย |
|---|---|---|
| name | ตรงกับชื่อเรื่องของหน้า | ใช้ชื่อย่อปนกับชื่อเต็ม |
| sameAs | ระบุหน้าเว็บทางการที่น่าเชื่อถือจริง | ใส่บัญชีโซเชียลของตัวเองเล่นๆ |
| logo | สี่เหลี่ยมจัตุรัสหรือสัดส่วนชัดเจน | ใช้ไอคอนเล็กแบบโปร่งใส |
| url | https จะมีหรือไม่มีสแลชปิดท้ายก็ให้เหมือนกันทั้งเว็บ | ใช้ http ปนกับ https |
| brand | ชี้ไปที่ Organization | เขียน brand ใน Product เป็นข้อความธรรมดา |
สี่ การตรวจสอบ: ไวยากรณ์ การจัดเก็บ และการจดจำของ AI สามขั้นตอน
ขั้นแรกใช้ Google Rich Results Test ตรวจไวยากรณ์ ดูว่าไม่มีข้อผิดพลาดในการแยกวิเคราะห์ ขั้นที่สองใช้ Google Search Console ดูรายงานข้อมูลแบบมีโครงสร้าง ดูว่า markup ถูกจัดเก็บและไม่มีข้อผิดพลาด ขั้นที่สามคือเป้าหมายจริง: เอาชุดคำถามคงที่ไปถาม ChatGPT และ Gemini ดูว่ามันตอบชื่อเต็ม ธุรกิจ และสินค้าของบริษัทคุณได้ถูกต้องหรือไม่
ห้ามข้ามขั้นแรกไปทำขั้นที่สามเลย ถ้าไวยากรณ์ไม่ผ่าน ข้างหลังก็เสียเปล่าทั้งหมด ต่อให้ไวยากรณ์ผ่านก็อย่าหวังว่าจะเห็นผลในวันรุ่งขึ้น เอนจินใช้เวลากว่าจะนำข้อมูลแบบมีโครงสร้างไปใช้ ปกติ 2 ถึง 8 สัปดาห์ ระหว่างนี้อย่าแก้ markup ซ้ำไปซ้ำมา แก้ทีหนึ่งก็รบกวนช่วงเวลาสังเกตทีหนึ่ง ดูว่าเอนทิตีที่ตรวจสอบแล้วจะทำงานร่วมกับสัญญาณความน่าเชื่อถืออย่างไรได้ที่หน้าความน่าเชื่อถือและความน่าเชื่อถือต่อ AI。
| ขั้นตอนการตรวจสอบ | เครื่องมือ | เกณฑ์ผ่าน | เวลาที่คาดว่าจะใช้ |
|---|---|---|---|
| ตรวจไวยากรณ์ | ทดสอบ Rich Results | ไม่มีข้อผิดพลาดไม่มีคำเตือน | วันเดียวกัน |
| การจัดเก็บ | Search Console | markup ถูกจดจำและนับจำนวน | 1 ถึง 4 สัปดาห์ |
| การจดจำของ AI | ถาม AI ด้วยชุดคำถามคงที่ | ตอบชื่อเต็มและธุรกิจได้ถูกต้อง | 2 ถึง 8 สัปดาห์ |
| สอดคล้องกันทุกเว็บไซต์ | ตรวจสอบด้วยคนทั้งสามเว็บ | ชื่อและคุณสมบัติตรงกัน | ครั้งเดียว |
ห้า ข้อควรระวัง: 3 ความผิดพลาดเรื่อง entity markup ที่พบบ่อยที่สุด
ความผิดพลาดข้อแรกคือใส่ Organization แค่ในหน้าแรก ส่วนหน้าสินค้าเว้นว่างทั้งหมด ผลคือ AI รู้จักบริษัทคุณ แต่บอกไม่ได้ว่าคุณขายอะไร ความผิดพลาดข้อที่สองคือใส่ sameAs แค่ Weibo กับบัญชีทางการของตัวเอง ซึ่งไม่นับเป็นแหล่งอ้างอิงที่น่าเชื่อถือ โมเดลไม่รับรู้ ความผิดพลาดข้อที่สามคือใส่ Person markup ให้พนักงานทุกคน ซึ่งเจือจางน้ำหนักของบุคคลหลัก
อีกอย่างที่ต้องระวัง entity markup ไม่ใช่ทำครั้งเดียวจบ บริษัทย้ายที่ เปลี่ยนโลโก้ ปรับไลน์สินค้า ผู้ก่อตั้งเปลี่ยน Schema ต้องอัปเดตตามให้ทัน ไม่งั้นโมเดลจะตอบผู้ใช้ด้วยข้อมูลเก่า โดยเฉพาะรุ่นสินค้าและค่าความแม่นยำ พอแก้หน้าสินค้าแล้วควรรีเฟรช Product markup ทันที ห่างกันไม่เกินสองสัปดาห์ ในรายการดูแลเว็บไซต์รายเดือนควรมีข้อ “ตรวจสอบ entity markup” ดูที่งาน 6 อย่างที่ต้องทำทุกเดือนในช่วงดูแลเว็บไซต์。
| ข้อผิดพลาด | ผลที่ตามมา | วิธีที่ถูกต้อง |
|---|---|---|
| ใส่แค่ Organization | รู้จักบริษัทแต่ไม่รู้จักสินค้า | หน้าสินค้าใส่ Product ด้วย |
| sameAs ใส่โซเชียลของตัวเอง | โมเดลไม่เชื่อถือ | ใส่ LinkedIn / Wikipedia / Crunchbase |
| ใส่ Person ให้ทุกคน | เจือจางบุคคลหลัก | ใส่เฉพาะผู้ก่อตั้งและผู้เชี่ยวชาญ |
| คุณสมบัติไม่ตรงกับเนื้อหาที่มองเห็น | ถูกตัดสินว่าขัดแย้งกัน | เครื่องกับคนอ่านต้องตรงกัน |
| เปลี่ยนธุรกิจแต่ไม่เปลี่ยน markup | โมเดลใช้ข้อมูลเก่า | ตรวจสอบตอนดูแลรายเดือน |
FAQ คำถามที่พบบ่อย
ใส่ Schema แค่บนเว็บตัวเอง AI จะรู้จักบริษัทผมไหม?
ฟิลด์ sameAs ควรใส่ลิงก์อะไรบ้าง?
markup สามแบบ Organization, Product, Person ใส่ในหน้าไหนบ้าง?
เขียน Schema เสร็จแล้วตรวจสอบได้ยังไงว่าใช้งานได้จริง?
ชื่อย่อกับชื่อเต็มของบริษัทไม่ตรงกันจะมีปัญหาอะไร?
ต้องดูแล entity markup บ่อยแค่ไหน
ทิ้งท้าย
เรื่อง entity markup ทางเทคนิคไม่ยาก ยากตรง “ความสม่ำเสมอระยะยาว” การเขียน JSON-LD ครั้งเดียวใช้เวลาแค่ครึ่งวัน แต่การทำให้ชื่อย่อ ชื่อเต็ม ชื่อภาษาอังกฤษ เว็บไซต์ LinkedIn และ Wikipedia ของบริษัทคงเดิมทุกช่องทางเป็นเวลาสามปีต้องมีวินัย สิ่งที่ AI ใช้จดจำเอนทิตีคือความเสถียรข้ามเวลาข้ามแหล่งแบบนี้ เร่งไม่ได้และลดขั้นตอนไม่ได้
ลงมือ 3 ขั้น: สัปดาห์แรกเติมฟิลด์บังคับของ Organization ให้ครบในหน้าแรกและหน้า About พร้อมใส่ sameAs 3 ถึง 5 โปรไฟล์ทางการ เดือนที่สองเพิ่ม Product markup ให้หน้าสินค้าทุกหน้า เดือนที่สามเพิ่ม Person markup ให้ผู้ก่อตั้งในหน้าทีม จากนั้นตรวจไวยากรณ์ด้วย Rich Results Test และตรวจการจดจำของ AI ด้วยชุดคำถามคงที่ ส่วนการวางแหล่งข้อมูลภายนอกเว็บดูที่แหล่งข้อเท็จจริงภายนอกเว็บไซต์ ส่วนวิธีภาพรวมดูที่การปฏิบัติ GEO。
ประโยคที่จำง่าย ๆ: Schema ไม่ได้เขียนให้ search engine อ่าน แต่เป็นบัตรประชาชนที่เขียนให้โมเดลจดจำคน — ติดป้ายครบแค่เว็บเดียวคือแค่สมัคร แต่ต้องตรงกันสามที่ถึงจะได้ทะเบียนเอนทิตี