คู่มือลงมือทำ Structured Data ของ Schema.org (JSON-LD): ทำให้ AI และ Google เข้าใจเว็บไซต์ของคุณ
เอนจิน AI และ Google ไม่ได้ "อ่าน" หน้าเว็บของคุณ แต่ "แยกวิเคราะห์" (parse) มัน Structured Data แบบ JSON-LD ที่จัดรูปแบบถูกต้องสักก้อนหนึ่ง เปรียบเหมือนการบอกพวกมันตรง ๆ ด้วยภาษาที่เครื่องเข้าใจว่า นี่คือบริษัทประเภทไหน บทความนี้ใครเขียน สินค้านี้ราคาเท่าไหร่ หน้านี้มีคำถามที่พบบ่อยอะไรบ้าง ถ้าขาดมันไป AI ก็ได้แต่เดา แต่ถ้ามีมัน โอกาสที่คุณจะถูกระบุตัวตนและถูกอ้างอิงอย่างถูกต้องก็เพิ่มขึ้นอย่างมาก บทความนี้จะพาคุณลงมือทำประเภทที่ใช้บ่อยตั้งแต่ศูนย์ วางให้ถูกที่ และตรวจสอบให้แน่ใจว่าไม่มีข้อผิดพลาด
Structured Data คืออะไร? ทำไมต้องใช้ JSON-LD
Structured Data คือมาร์กอัปที่เขียนตามคำศัพท์ร่วมของ Schema.org โดยใช้คู่คีย์-ค่าที่เครื่องอ่านได้ เพื่อบอกเครื่องมือค้นหาและเอนจิน AI ว่า "เนื้อหาของหน้านี้หมายถึงอะไร" ข้อความเดียวกันอย่าง "สมชาย, 0912-345-678" คนอ่านก็เข้าใจว่าเป็นชื่อผู้ติดต่อและเบอร์โทร แต่เครื่องต้องการให้คุณระบุ name และ telephone อย่างชัดเจน จึงจะไม่ตีความผิด
รูปแบบการลงมือทำมีสามแบบ (JSON-LD, Microdata, RDFa) แต่ทั้ง Google และแนวทางหลักในปัจจุบันต่างแนะนำให้ใช้ JSON-LD เหตุผลคือมันรวบมาร์กอัปทั้งหมดไว้ในบล็อก <script> อิสระเพียงบล็อกเดียว ไม่ต้องไปพันอยู่กับแท็ก HTML ดูแลรักษาง่ายที่สุด เกิดการขัดแย้งกับเลย์เอาต์ได้ยากที่สุด และเป็นมิตรกับการแยกวิเคราะห์อย่างเสถียรของบ็อต AI มากที่สุด
JSON-LD ควรวางไว้ตรงไหนของหน้า?
ห่อมาร์กอัปไว้ในบล็อก <script type="application/ld+json"> จะวางไว้ใน <head> หรือ <body> ของหน้าก็ถูกรับรู้ได้ทั้งคู่ แต่โดยธรรมเนียมจะวางไว้ใน <head> หนึ่งหน้าสามารถมีบล็อก JSON-LD ได้หลายบล็อก และยังใช้อาเรย์ @graph เดียวมาห่อหลายเอนทิตีไว้ด้วยกันก็ได้ ทั้งสองวิธีถูกต้องตามกฎ
หลักการสำคัญคือ Structured Data ต้องถูกส่งออกจากฝั่งเซิร์ฟเวอร์และมีอยู่ใน HTML ดั้งเดิม บ็อตเก็บข้อมูลของ AI ส่วนใหญ่ไม่รัน JavaScript ดังนั้นถ้า JSON-LD ของคุณถูกแทรกแบบไดนามิกด้วย JS หลังจากฝั่งหน้าบ้านโหลดเสร็จแล้ว บ็อต AI ก็มีแนวโน้มสูงที่จะอ่านได้แต่เปลือกเปล่า ๆ ที่ไม่มีมาร์กอัป ให้ใช้ "ดูซอร์สโค้ด" (View Source) แทนแผง Elements ของเครื่องมือนักพัฒนา เพื่อยืนยันว่ามันอยู่ในการตอบกลับดั้งเดิมจริง ๆ
Organization กับ LocalBusiness: นิยามว่าคุณคือใคร
นี่คือส่วนที่ควรทำก่อนที่สุดของทั้งเว็บไซต์ มักวางไว้ที่หน้าแรก มันนิยามเอนทิตีแบรนด์ของคุณ และเป็นพื้นฐานหลักเมื่อ AI ตอบว่า "บริษัทนี้คือใคร เชื่อถือได้หรือไม่" ถ้ามีหน้าร้านจริงหรือพื้นที่ให้บริการ ให้ใช้ LocalBusiness ที่แม่นยำกว่า (หรือชนิดย่อยอย่าง Restaurant, Store) แทน Organization และเพิ่มที่อยู่กับเวลาทำการเข้าไปด้วย
- ฟิลด์ที่จำเป็นของ Organization: name (ชื่อแบรนด์), url (เว็บไซต์ทางการ), logo (URL ของรูปโลโก้)
- sameAs: ใส่อาเรย์ของลิงก์ทางการของคุณ เช่น Facebook, Instagram, LinkedIn, Wikipedia ฯลฯ นี่คือกุญแจสำคัญในการ "มัดรวม" ตัวตนแบรนด์ที่กระจัดกระจายให้เป็นเอนทิตีเดียวกัน ช่วยลดโอกาสที่ AI จะระบุตัวตนผิดได้อย่างมาก
- LocalBusiness เพิ่มเติม: address (ใช้โครงสร้าง PostalAddress แยกเป็นถนน/เมือง/รหัสไปรษณีย์), telephone, openingHours, geo (พิกัดละติจูดและลองจิจูด), priceRange
- contactPoint: ระบุเบอร์โทรฝ่ายบริการลูกค้า อีเมล และภาษาที่ให้บริการ เพื่อให้ AI หาคุณเจอเมื่อต้องตอบคำถามเกี่ยวกับการติดต่อ
Article, Product, BreadcrumbList: เลือก schema ให้ถูกตามประเภทหน้า
หน้าที่ต่างกันใช้ประเภทที่ต่างกัน หลักการคือ "หน้านี้พูดถึงอะไรเป็นหลัก ก็มาร์กอัปสิ่งนั้น" บล็อกและข่าวใช้ Article (หรือ BlogPosting/NewsArticle) หน้าสินค้าใช้ Product ส่วนหน้าใดก็ตามที่มีลำดับชั้น ควรเพิ่ม BreadcrumbList
- Article/BlogPosting: headline, author (ใช้ Person หรือ Organization อย่าใส่แค่ข้อความล้วน), datePublished, dateModified, image, publisher ผู้เขียนและวันที่เป็นสัญญาณสำคัญที่ AI ใช้ตัดสินความสดใหม่และความน่าเชื่อถือของเนื้อหา
- Product: name, image, description, brand, offers (ภายในมี price, priceCurrency, availability) ถ้ามีการให้คะแนนค่อยเพิ่ม aggregateRating และ review แต่คะแนนต้องตรงกับรีวิวที่แสดงจริงบนหน้านั้น
- BreadcrumbList: ใช้ itemListElement ไล่ลำดับเส้นทางเบรดครัมบ์ (หน้าแรก › หมวดหมู่ › หน้านี้) ช่วยให้เอนจินเข้าใจโครงสร้างเว็บไซต์และตำแหน่งของหน้านี้ภายในเว็บไซต์
- เคล็ดลับเลือกประเภท: หนึ่งหน้ามีหลายประเภทพร้อมกันได้ (เช่น บทรีวิวสินค้าที่เป็นทั้ง Article และ Product) แค่ใช้ @graph ห่อรวมกันก็พอ
อยากรู้ไหมว่าเว็บไซต์ของคุณได้คะแนนเท่าไรในสายตา AI?
สแกนฟรี — รับคะแนนความพร้อมต่อ AI 0–100 และโค้ดแก้ไขที่คัดลอกวางได้ทันที
ตรวจ GEO ฟรี →FAQPage: ไม้เด็ดที่ใช้ได้ผลตรงที่สุดสำหรับ GEO
ถ้าอยากเริ่มทำแค่ประเภทเดียวที่ส่งผลต่อการอ้างอิงของ AI ได้ทันที ให้เลือก FAQPage มันจับคู่ "คำถาม-คำตอบ" ให้เป็นรูปแบบที่เครื่องอ่านได้ ซึ่งสอดคล้องพอดีกับตรรกะการดึงเนื้อหาของเอนจิน AI ที่ "มองหาเนื้อหาสักท่อนที่ใช้เป็นคำตอบได้ทันที" จึงเป็นก้าวที่ให้ผลตอบแทนต่อการลงทุนสูงมาก
วิธีทำคือใช้ mainEntity ไล่รายการ Question หลายชุด โดยแต่ละชุดมี acceptedAnswer หนึ่งอันอยู่ข้างใต้ (ชนิด Answer ใส่คำตอบในฟิลด์ text) กฎเหล็ก: คำถาม-คำตอบในมาร์กอัปต้องเป็นเนื้อหาที่ผู้ใช้มองเห็นบนหน้าได้จริง จะอยู่แค่ใน JSON-LD ไม่ได้ นโยบายของ Google กำหนดชัดเจนว่าเนื้อหา FAQ ต้องมองเห็นได้บนหน้า ไม่เช่นนั้นถือเป็นเนื้อหาที่ซ่อนไว้อันละเมิดกฎ
ตรวจสอบอย่างไร? สามขั้นที่ต้องทำให้ครบ
เขียนเสร็จต้องตรวจสอบเสมอ เพราะแค่ชื่อฟิลด์สะกดผิดตัวเดียวหรือลืมเครื่องหมายจุลภาคไปอันเดียว มาร์กอัปทั้งก้อนก็อาจถูกเพิกเฉย การตรวจสอบมีสองระดับ คือไวยากรณ์ถูกต้องหรือไม่ และมีคุณสมบัติพอที่จะทริกเกอร์ Rich Results หรือไม่
- Schema Markup Validator (validator.schema.org): ตรวจว่าไวยากรณ์ของ Schema.org เองถูกต้องหรือไม่ ใช้ได้กับทุกประเภท ไม่จำกัดเฉพาะที่ Google รองรับ
- Google Rich Results Test (search.google.com/test/rich-results): วางURLหรือโค้ดลงไป เพื่อดูว่า Google รับรองหรือไม่ มีสิทธิ์ได้ผลการค้นหาแบบ rich result หรือไม่ พร้อมแสดงรายการข้อผิดพลาดและคำเตือน
- รายงาน "ผลการค้นหาที่มีการจัดรูปแบบ" ใน Search Console: หลังขึ้นไลฟ์ ให้คอยติดตามสถานะและข้อผิดพลาดที่ Google ดึงไปได้จริงอย่างต่อเนื่อง ซึ่งสะท้อนสถานการณ์จริงได้ดีกว่าการทดสอบครั้งเดียวจบ
- อย่าลืมใช้ "ดูซอร์สโค้ด" ยืนยันว่ามาร์กอัปปรากฏใน HTML ที่เซิร์ฟเวอร์ส่งกลับมาจริง ไม่ใช่แค่อาศัยการแทรกด้วย JS
ห้าข้อผิดพลาดที่พบบ่อยที่สุด (โดยเฉพาะข้อแรกจะถูกมองเป็นสแปม)
การทำ Structured Data ผิด แย่กว่าการไม่ทำเสียอีก เบาะ ๆ ก็ถูกเพิกเฉย หนักหน่อยก็ถูกตัดสินว่าจงใจหลอกล่อ ห้าข้อต่อไปนี้คือกับดักที่พลาดกันบ่อยที่สุด
- มาร์กอัปไม่ตรงกับเนื้อหา: JSON-LD เขียนคะแนนห้าดาวไว้ แต่บนหน้าไม่มีเลย หรือคำตอบ FAQ มองไม่เห็นบนหน้า สิ่งเหล่านี้ Google จะมองเป็นสแปม อาจทำให้ Structured Data ทั้งเว็บไซต์เสียคุณสมบัติ มาร์กอัปต้องสะท้อนเนื้อหาจริงบนหน้าอย่างซื่อตรง
- ใช้ประเภทหรือฟิลด์ผิด: มาร์กสินค้าเป็น Article ใส่ author เป็นสตริงข้อความล้วนแทนที่จะเป็น Person/Organization ใส่ price โดยไม่มี priceCurrency ฯลฯ ล้วนทำให้เอนจินแยกวิเคราะห์ไม่ถูกต้อง
- พึ่งการแทรกแบบไดนามิกด้วย JavaScript: บ็อต AI และในบางสถานการณ์อ่านไม่ได้ เท่ากับเสียเปล่า ต้องส่งออกจากฝั่งเซิร์ฟเวอร์เสมอ
- เอนทิตีไม่สอดคล้องกัน: หน้าแรกเรียก "KKpower" หน้าอื่นเรียก "KK Power" ลิงก์โซเชียลก็ไม่ตรงกันอีก ทำให้ AI ยากที่จะมัดรวมให้เป็นแบรนด์เดียวกัน ให้คง name, url และ sameAs ให้สอดคล้องตรงกันเสมอ
- มาร์กอัปเกินจำเป็นและยัดเยียด: ยัดทุกอย่างบนหน้าให้เป็น schema ทั้งหมด หรือประกาศเอนทิตีเดิมซ้ำ ๆ กลับยิ่งเพิ่มความเสี่ยงที่จะผิดพลาดและถูกตัดสินว่าจงใจหลอกล่อ มาร์กแค่สิ่งที่สำคัญและเป็นจริงก็พอ
คำถามที่พบบ่อย
Q. Structured Data ต้องใช้ JSON-LD เท่านั้นไหม? ใช้ Microdata ได้หรือเปล่า?
Microdata และ RDFa ยังคงถูกต้องตามไวยากรณ์ แต่ทั้ง Google และแนวปฏิบัติหลักในปัจจุบันต่างแนะนำให้ใช้ JSON-LD มันรวบมาร์กอัปไว้ในบล็อก <script> อิสระ ไม่ต้องไปพันอยู่กับแท็ก HTML ดูแลรักษาง่ายที่สุด เกิดการขัดแย้งกับเลย์เอาต์ได้ยากที่สุด และเป็นมิตรกับการแยกวิเคราะห์อย่างเสถียรของบ็อต AI มากที่สุด เว็บไซต์ที่ทำใหม่ เลือก JSON-LD ไปเลยถูกต้องที่สุด
Q. พอเพิ่ม Structured Data แล้ว Google จะให้ Rich Results (ดาว, FAQ ที่กางได้) แน่นอนเลยไหม?
ไม่รับประกัน มาร์กอัปที่ถูกต้องแค่ "ได้คุณสมบัติ" เท่านั้น ส่วนจะแสดงผลการค้นหาแบบ rich result จริงหรือไม่ อัลกอริทึมของ Google เป็นคนตัดสิน โดยดูจากคุณภาพเนื้อหา การปฏิบัติตามนโยบาย บริบทของคำค้น ฯลฯ แต่ถึงจะไม่ทริกเกอร์ Rich Results ที่เห็นเป็นภาพ Structured Data ที่ถูกต้องก็ยังช่วยให้เครื่องมือค้นหาและเอนจิน AI เข้าใจและอ้างอิงเนื้อหาของคุณ คุณค่าจึงไม่สูญเปล่า
Q. คำถาม-คำตอบในมาร์กอัป FAQPage จำเป็นต้องมองเห็นบนหน้าด้วยไหม?
ใช่ นี่เป็นข้อกำหนดบังคับ นโยบายของ Google กำหนดว่าคำถามและคำตอบของ FAQ ต้องเป็นเนื้อหาที่ผู้ใช้มองเห็นได้จริงบนหน้า ถ้าเขียนไว้แค่ใน JSON-LD แต่หน้าไม่เห็น ถือเป็นเนื้อหาที่ซ่อนไว้อันละเมิดกฎ ซึ่งอาจทำให้ Structured Data ของคุณเสียคุณสมบัติ หรือกระทบทั้งเว็บไซต์ มาร์กอัปต้องสอดคล้องกับสิ่งที่หน้าแสดงจริงอย่างซื่อตรง
Q. ถ้าเขียน Structured Data ผิด จะเป็นอันตรายต่อเว็บไซต์ของฉันไหม?
เป็น ที่ร้ายแรงที่สุดคือ "มาร์กอัปไม่ตรงกับเนื้อหา" (เช่น รีวิวปลอม หรือ FAQ ที่มองไม่เห็นบนหน้า) ซึ่งจะถูกมองว่าจงใจหลอกล่อ อาจทำให้ Structured Data ของเว็บไซต์ถูกเพิกถอนคุณสมบัติ ส่วนปัญหาที่พบบ่อยอื่น ๆ เช่น ใช้ประเภทผิด สะกดฟิลด์ผิด หรือพึ่งการแทรกด้วย JS จนบ็อตอ่านไม่ได้ ส่วนใหญ่เป็น "ใช้ไม่ได้แต่ไม่เป็นอันตราย" เอนจินก็แค่เพิกเฉยไป หลักการคือ ยอมมาร์กน้อยแต่ถูกต้อง ดีกว่ามาร์กมากแต่ปลอม
Q. ฉันควรทำ schema ประเภทไหนก่อน?
เริ่มสองอันก่อน อันแรกคือ Organization ที่หน้าแรก (ถ้ามีหน้าร้านหรือพื้นที่ให้บริการก็ใช้ LocalBusiness) เพื่อนิยามเอนทิตีแบรนด์และข้อมูลติดต่อ อันที่สองคือ FAQPage ที่หน้าเนื้อหา เพราะรูปแบบคำถาม-คำตอบของมันใกล้เคียงกับวิธีที่เอนจิน AI ดึงคำตอบมากที่สุด จึงได้ผลตรงที่สุดต่อการถูกอ้างอิง หลังจากนั้นค่อยเพิ่ม Article, Product และ BreadcrumbList ตามประเภทของหน้า
Q. จะยืนยันได้อย่างไรว่า Structured Data ของฉันถูกอ่านจริง ๆ?
สามขั้นตอน: ขั้นแรกใช้ Schema Markup Validator (validator.schema.org) ยืนยันว่าไวยากรณ์ถูกต้อง จากนั้นใช้ Google Rich Results Test ยืนยันว่า Google รับรองและตรวจว่าทริกเกอร์ rich result ได้หรือไม่ หลังขึ้นไลฟ์ใช้รายงานผลการค้นหาที่มีการจัดรูปแบบใน Search Console ติดตามอย่างต่อเนื่อง สุดท้ายต้องใช้ "ดูซอร์สโค้ด" ของเบราว์เซอร์ยืนยันว่า JSON-LD ปรากฏใน HTML ดั้งเดิมที่เซิร์ฟเวอร์ส่งกลับมา ไม่ใช่แค่ถูกแทรกโดย JavaScript ฝั่งหน้าบ้าน
นำสิ่งที่เรียนรู้ไปทดสอบกับเว็บไซต์ของคุณใน 10 วินาที
สแกนฟรี — รับคะแนนความพร้อมต่อ AI 0–100 และโค้ดแก้ไขที่คัดลอกวางได้ทันที
ตรวจ GEO ฟรี →