วิธีตรวจสอบ structured data โดยไม่ใช้เครื่องมือของ Google

การตรวจสอบ structured data กลายเป็นสิ่งที่พึ่งพาเครื่องมือที่มุ่งไปยัง Google อย่างน่าประหลาดใจ เรื่องนี้เข้าใจได้: หลายทีมเพิ่ม JSON-LD เพราะต้องการ rich results และเครื่องมือทดสอบของ Google ก็เป็นที่คุ้นเคย แต่ structured data ไม่ใช่รูปแบบของ Google โดยปกติมันคือ JSON-LD ที่ใช้คำศัพท์ของ Schema.org ฝังอยู่ใน HTML ถูกตีความโดยผู้ใช้งานข้อมูลหลายกลุ่ม และได้รับการดูแลผ่านเวิร์กโฟลว์การเผยแพร่ของคุณเอง

หากคุณตรวจสอบผ่านมุมมองของ search engine เท่านั้น คุณอาจพลาดปัญหาพื้นฐานได้: JSON ไม่ถูกต้อง, ข้อมูลที่หายไปหลังการเรนเดอร์, ราคาสินค้าที่ล้าสมัย, canonical URL ที่ขัดแย้งกัน หรือ markup ที่ถูกต้องทางเทคนิคแต่ไม่สมเหตุสมผลในเชิงความหมาย

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

คุณกำลังตรวจสอบอะไรกันแน่?

“Structured data” ไม่ใช่สิ่งเดียวโดด ๆ ในเว็บไซต์ส่วนใหญ่ มันมีอยู่สี่ชั้น:

1. ไวยากรณ์ JSON — โค้ด parse ได้หรือไม่?
2. โมเดล JSON-LD — มันขยายออกเป็น linked data ที่มีความหมายหรือไม่?
3. คำศัพท์ Schema.org — ประเภทและ properties สมเหตุสมผลหรือไม่?
4. ความจริงระดับหน้าเว็บ — markup ตรงกับสิ่งที่ผู้ใช้และ crawlers เห็นได้หรือไม่?

เครื่องมือของ Google ส่วนใหญ่เน้นชั้นที่สี่ร่วมกับเกณฑ์เฉพาะของ Google สำหรับการมีสิทธิ์แสดง rich results มีประโยชน์ใช่ แต่ครบถ้วนหรือไม่ ไม่ใช่

ตัวอย่างเช่น สิ่งนี้อาจเป็น JSON-LD ที่ถูกต้อง แต่ยังเป็น structured data ที่ไม่ดีได้:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

ตรงนี้ไม่มีอะไรเสีย แต่ถ้าหน้าเว็บที่มองเห็นมี headline คนละแบบ ไม่มีการระบุ author และมีวันที่ last-modified ที่ขัดแย้งกับ markup นั่นคือปัญหาคุณภาพ ไม่ใช่ปัญหาไวยากรณ์

ขั้นตอนที่ 1: Parse JSON ก่อนคิดเรื่อง SEO

เริ่มจากการตรวจเช็กที่น่าเบื่อ: JSON parse ได้หรือไม่?

JSON-LD ที่ฝังอยู่ใน HTML มักเสียเพราะความผิดพลาดเล็ก ๆ ใน template:

• trailing commas
• quotes ในชื่อสินค้าที่ไม่ได้ escape
• line breaks ที่ไม่ถูกต้องภายใน strings
• braces ที่หายไปหลัง conditional fields
• script blocks ซ้ำจาก layout inheritance
• CMS plugins ที่ส่งออก objects ไม่ครบ

สำหรับการตรวจเช็กภายในเครื่อง คุณไม่จำเป็นต้องใช้แพลตฟอร์ม SEO ใช้เครื่องมือที่มีอยู่แล้วใน development stack ของคุณ

ใน JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

ใน CI ให้ดึงเนื้อหา script จาก HTML ที่เรนเดอร์แล้ว และ parse เป็น JSON วิธีนี้จับปัญหาได้มากมายก่อนที่จะไปถึง production

ประเด็นสำคัญคือ: ทำขั้นตอนนี้ก่อนการตรวจสอบ Schema.org ใด ๆ ตัวตรวจสอบคำศัพท์ช่วยไม่ได้หากข้อมูลไม่ใช่ JSON ที่ถูกต้อง

ขั้นตอนที่ 2: ตรวจสอบพฤติกรรมของ JSON-LD ไม่ใช่แค่ไวยากรณ์ JSON

JSON ที่ถูกต้องไม่ได้หมายความว่าเป็น JSON-LD ที่ถูกต้องโดยอัตโนมัติ JSON-LD ใช้แนวคิดอย่าง @context, @type, @id และความสัมพันธ์แบบ graph หากสิ่งเหล่านี้ผิดรูป parsers อาจตีความข้อมูลของคุณต่างจากที่คุณตั้งใจ

อย่างน้อย ให้ยืนยันว่า:

• ทุก block มี @context ที่เหมาะสม
• entities หลักมีค่า @type ที่ชัดเจน
• entities ที่ซ้ำกันใช้ค่า @id ที่เสถียรเมื่อมีประโยชน์
• nested entities เชื่อมโยงกันอย่างสมเหตุสมผล
• ใช้ arrays เมื่อมีค่าหลายรายการได้

สำหรับเว็บไซต์ขนาดใหญ่ identifiers ที่เสถียรมีประโยชน์เป็นพิเศษ หากองค์กรของคุณปรากฏในข้อมูล Article, Product, BreadcrumbList และ FAQPage การใช้ @id เดียวกันช่วยให้ผู้ใช้ข้อมูลเข้าใจว่าสิ่งเหล่านี้คือการอ้างอิงถึง entity เดียวกัน ไม่ใช่องค์กรสี่แห่งที่ไม่เกี่ยวข้องกันแต่มีชื่อเดียวกัน

รูปแบบทั่วไปมีหน้าตาแบบนี้:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

คุณไม่ได้พยายามทำให้ตัวตรวจสอบประทับใจในขั้นตอนนี้ คุณกำลังทำให้ข้อมูลของคุณคลุมเครือน้อยลง

ขั้นตอนที่ 3: ตรวจสอบกับคำศัพท์ Schema.org

เมื่อ JSON และโครงสร้าง JSON-LD อยู่ในสภาพดีแล้ว ให้ตรวจสอบคำศัพท์

Schema.org validator มีประโยชน์เพราะทดสอบกับ terms ของ Schema.org แทนที่จะทดสอบตามกฎ rich-result ของ search engine เพียงรายเดียว มันแสดงได้ว่า properties ได้รับการรู้จักหรือไม่ ประเภทถูกตีความตามที่คาดไว้หรือไม่ และ nested structures ของคุณสมเหตุสมผลหรือไม่

นี่คือจุดที่คุณจะพบความผิดพลาดอย่างเช่น:

• publishingDate แทนที่จะเป็น datePublished
• imageUrl ในที่ที่ควรเป็น image
• markup แบบ Product บนหน้ารายการหมวดหมู่ที่ไม่ใช่สินค้า
• AggregateRating ที่ไม่มีรายการที่ถูกรีวิวอย่างมีความหมาย
• ใช้ Person สำหรับบัญชีแบรนด์

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

กฎเชิงปฏิบัติคือ: หาก property ช่วยให้เครื่องเข้าใจหน้าเว็บได้แม่นยำขึ้น ให้เก็บไว้ หากมันมีอยู่เพียงเพราะมีคนคัดลอกมาจาก snippet generator ให้ตั้งคำถามกับมัน

ขั้นตอนที่ 4: เปรียบเทียบ markup กับเนื้อหาที่มองเห็นได้

Search engines และผู้ใช้ข้อมูลรายอื่น ๆ มักไม่ไว้วางใจ markup ที่ไม่ตรงกับหน้าเว็บ ที่สำคัญกว่านั้น ผู้ใช้สมควรได้รับความสอดคล้อง

สำหรับ structured data แต่ละประเภท ให้เปรียบเทียบ markup กับหน้าเว็บที่มองเห็นได้:

Article และ BlogPosting

ตรวจสอบว่า headline, author, published date, modified date, image และ publisher มองเห็นได้หรืออนุมานได้อย่างสมเหตุสมผล หากคุณเผยแพร่เนื้อหาที่มี AI ช่วย structured data ของคุณไม่ควรถูกใช้เพื่อฟอกความไม่ชัดเจนเรื่อง authorship เราได้เขียนแยกไว้เกี่ยวกับ การเปิดเผยการใช้ AI อย่างตรงไปตรงมาบนเว็บไซต์ขนาดเล็ก และหลักการเดียวกันใช้ได้ที่นี่: metadata ควรช่วยชี้แจง ไม่ใช่ทำให้คลุมเครือ

Product

ตรวจสอบ name, price, availability, currency, variants, ratings และ review counts structured data ของ Product มีแนวโน้มล้าสมัยเป็นพิเศษ เพราะราคาและสถานะสต็อกเปลี่ยนแปลงนอก CMS

LocalBusiness

ตรวจสอบ name, address, phone number, opening hours และ service area หาก footer ของคุณบอกอย่างหนึ่ง แต่ JSON-LD บอกอีกอย่าง JSON-LD ไม่ได้ “ดีกว่า” มันกำลังขัดแย้งกัน

BreadcrumbList

ตรวจสอบว่า breadcrumb positions ตรงกับ breadcrumb trail ที่มองเห็นได้ และ URLs เป็น canonical, crawlable และไม่ redirect โดยไม่จำเป็น

งานนี้ไม่หวือหวา แต่นี่ก็เป็นจุดที่พบปัญหา structured data จำนวนมาก

ขั้นตอนที่ 5: ตรวจสอบหน้าเว็บที่เรนเดอร์แล้ว ไม่ใช่ template ของคุณ

หลายเว็บไซต์สร้าง JSON-LD ผ่าน JavaScript, tag managers, personalization layers หรือ component hydration นั่นหมายความว่าไฟล์ template อาจไม่ได้แทนสิ่งที่ crawler หรือ browser เห็นจริง

ตรวจสอบ HTML ที่เรนเดอร์แล้วอย่างน้อยในสามสถานะ:

• local development build
• staging หรือ preview URL
• production URL

ใช้ browser DevTools เพื่อตรวจสอบ DOM สุดท้าย ค้นหา application/ld+json และคัดลอกเนื้อหา script ที่มีอยู่จริงหลังการเรนเดอร์ หาก server-rendered markup แตกต่างจาก hydrated markup ให้ตัดสินใจว่าคุณคาดหวังให้ผู้ใช้ข้อมูลอ่านเวอร์ชันใด

ตรวจสอบด้วยว่า structured data ถูกทำซ้ำหรือไม่ Article หรือ Product blocks ที่ซ้ำกันพบได้บ่อยเมื่อ CMS plugin และ custom component ต่างก็ส่ง schema ออกมา การทำซ้ำไม่ถึงกับเป็นปัญหาร้ายแรงเสมอไป แต่การทำซ้ำที่ขัดแย้งกันเป็นปัญหา: ราคาสองค่า, authors สองคน, publication dates สองค่า หรือ canonical URLs สองรายการ

เรื่องนี้คล้ายกับการอ่านรายงาน performance และ diagnostics: งานแรกไม่ใช่การตื่นตระหนก แต่คือการแยกสัญญาณออกจาก noise นิสัยเดียวกันนี้ช่วยได้เมื่อคุณอ่านรายงาน Lighthouse โดยไม่ตื่นตระหนก — แม้ว่า structured data เองไม่ควรถูกลดทอนให้เหลือเพียงคะแนนเดียว

ขั้นตอนที่ 6: ตรวจสอบรายละเอียดการส่งผ่านบน production

Structured data อาจสมบูรณ์แบบใน source ของคุณ แต่ยังล้มเหลวบน production ได้ เพราะหน้าเว็บไม่ได้เข้าถึงได้ในแบบที่คุณสมมติ

ตรวจสอบว่า:

• status code สุดท้ายคือ 200 ไม่ใช่ soft 404
• canonical URL ตรงกับหน้าเว็บที่คุณกำลังตรวจสอบ
• redirects มีเจตนาและเสถียร
• robots directives ไม่บล็อก indexing ในที่ที่คาดว่าจะให้ index
• HTML ไม่ถูกแทนที่ด้วยหน้า error สำหรับ user agents บางกลุ่ม
• cached pages ไม่ได้ให้บริการ JSON-LD ที่ล้าสมัย

นี่คือจุดที่การตรวจสอบ HTTP มีความสำคัญ หากหน้าสินค้า redirect ผ่านสาม URLs ก่อนถึง canonical destination ให้ตรวจสอบหน้าสุดท้าย ไม่ใช่ URL แรกที่คัดลอกจาก CMS สำหรับกลไกดิบ ๆ คู่มือของเราเรื่อง การ debug redirects และ HTTP headers บน production เป็นเอกสารประกอบที่มีประโยชน์

Structured data ไม่ได้อยู่ในสุญญากาศ มันเดินทางไปพร้อมกับ headers, redirects, caching, canonical tags และ robots directives

ขั้นตอนที่ 7: เพิ่มการทดสอบ structured data เข้าไปในกระบวนการ release

การตรวจสอบด้วยมือใช้ได้สำหรับหนึ่งหน้า แต่มันไม่ scale ไปยัง URLs หลักร้อยหรือหลักพัน

ชุด automated tests แบบง่าย ๆ สามารถจับความผิดพลาดที่มีต้นทุนสูงที่สุดได้:

• fetch URLs ตัวแทนจากแต่ละ template type
• extract JSON-LD blocks ทั้งหมด
• parse ด้วย JSON.parse
• assert required fields สำหรับแต่ละ page type
• ตรวจสอบว่า dates เป็น ISO 8601 strings ที่ถูกต้อง
• ตรวจสอบว่า URLs เป็น absolute และ canonical
• ตรวจสอบว่ามี prices และ availability สำหรับ product pages
• ตรวจสอบว่า duplicate entities ไม่ขัดแย้งกัน

คุณสามารถรันสิ่งนี้ใน CI สำหรับ templates และรันตามตารางเวลาสำหรับ production URLs เป้าหมายไม่ใช่การพิสูจน์ว่า rich-result feature ทุกอย่างจะปรากฏ ไม่มีใครนอก search engine รับประกันเรื่องนั้นได้ เป้าหมายคือการรักษาข้อมูลของคุณเองให้ถูกต้อง, parse ได้ และสอดคล้องกัน

<!-- tool-cta:start -->

💡 ลองทำสิ่งนี้: ก่อนตรวจสอบความถูกต้องของตรรกะของสคีมา ให้นำ JSON-LD ของคุณผ่าน JSON Formatter เพื่อตรวจจับข้อผิดพลาดทางไวยากรณ์ที่มิฉะนั้นจะทำให้การตรวจสอบขั้นต่อ ๆ ไปทั้งหมดล้มเหลว

<!-- tool-cta:end -->

Checklist การตรวจสอบที่ยึดมาตรฐานเป็นหลัก

ใช้ checklist สั้น ๆ นี้ก่อนถามว่า search engine ชอบหน้าเว็บนี้หรือไม่:

• JSON-LD ทุก block เป็น JSON ที่ถูกต้องหรือไม่?
• แต่ละ block มี @context และ @type ที่ถูกต้องหรือไม่?
• Properties ของ Schema.org สะกดถูกต้องหรือไม่?
• Markup ตรงกับเนื้อหาที่มองเห็นได้หรือไม่?
• Dates, prices, ratings และ availability เป็นปัจจุบันหรือไม่?
• URLs เป็น absolute, canonical และเข้าถึงได้หรือไม่?
• หน้า production ที่เรนเดอร์แล้วเป็นหน้าเดียวกับที่คุณทดสอบหรือไม่?
• Duplicate entities มีเจตนาและไม่ขัดแย้งกันหรือไม่?

หากคุณตอบว่าใช่กับคำถามเหล่านี้ได้ คุณได้ทำส่วนที่ทนทานของงาน structured data แล้ว การทดสอบเฉพาะ search engine ยังมีประโยชน์ในภายหลัง แต่ควรเป็นการตรวจสอบความเข้ากันได้ขั้นสุดท้าย ไม่ใช่รากฐานของกระบวนการตรวจสอบของคุณ