วิธีสร้าง Codex Skill สำหรับ SEO Schema JSON-LD

คำตอบสั้น ๆ: Schema ควรเป็นสำเนาเชิงโครงสร้างของข้อเท็จจริงบนหน้าเว็บ

หากคุณมาที่นี่เพื่อหา prompt SKILL.md ของ Codex สำหรับ SEO Schema JSON-LD คุณสามารถคัดลอกได้จากด้านล่าง แต่กฎที่อยู่เบื้องหลังสำคัญกว่าโค้ด: structured data ต้องถ่ายทอดข้อเท็จจริงที่ผู้เข้าชมตรวจสอบได้อยู่แล้วบนหน้าเว็บ ไม่ใช่โอกาสในการเขียน JSON object ที่ซับซ้อนที่สุดเท่าที่ทำได้

Codex มีประโยชน์ในงานนี้ เพราะสามารถตรวจสอบหน้าเว็บ ข้อมูลเนื้อหา และ markup ที่มีอยู่ก่อนเสนอชนิดหรือเขียน JSON-LD ลำดับนี้สำคัญมาก คำขอคลุมเครืออย่าง "เพิ่ม schema ให้มากที่สุด" มักสร้าง aggregateRating ราคา ผู้เขียน หรือวันที่เผยแพร่ขึ้นมาเอง ฟิลด์เหล่านั้นอาจ parse ผ่าน แต่ยังทำให้หน้าเว็บถูกอธิบายผิดได้

Google แนะนำ JSON-LD เมื่อระบบของเว็บไซต์รองรับ เพราะมักติดตั้งและดูแลรักษาได้ง่ายกว่า แนวทางของ Google ก็ชัดเจนเช่นกันว่า markup ต้องอธิบายหน้าที่ markup นั้นอยู่ สะท้อนเนื้อหาที่ผู้ใช้มองเห็น และคงความถูกต้องไว้ การผ่าน Rich Results Test ไม่ได้รับประกันว่าจะได้ rich result

เลือกชนิดหลักของหน้าก่อนเพิ่มวัตถุสนับสนุน

เริ่มจากคำถามธรรมดา: ผู้เข้าชมกำลังดูอะไรเป็นหลัก คำตอบควรกำหนด Schema.org type หลัก Breadcrumb ข้อมูลองค์กร และวิดีโอสามารถสนับสนุนวัตถุหลักนั้นได้ เมื่อข้อมูลเหล่านั้นปรากฏให้ผู้เข้าชมเห็นบนหน้าเดียวกัน

Schema.org มีคำศัพท์กว้างกว่าฟีเจอร์ rich result ของ Google มาก สำหรับงาน Google Search คู่มือ Google Search Central ปัจจุบันสำหรับฟีเจอร์ที่ต้องการมีอำนาจมากกว่าข้อเท็จจริงที่ว่า property หนึ่งมีอยู่ใน Schema.org

เริ่มจากวัตถุประสงค์ของหน้า ชนิดต้องตามข้อเท็จจริงที่มองเห็น ไม่ใช่กลับกัน

workflow Codex ที่ปลอดภัยกว่ามีสี่ด่าน

1. บัญชีรายการข้อเท็จจริง ดึงข้อมูลเฉพาะจากข้อความที่มองเห็นบนหน้า ฟิลด์ CMS ที่เชื่อถือได้และ render บนหน้านั้น หรือข้อมูลที่ผู้ใช้ยืนยันอย่างชัดเจน ทำเครื่องหมายแต่ละฟิลด์ว่า confirmed, missing หรือ needs human confirmation
2. การตัดสินใจเรื่องชนิด เลือกชนิดหลักที่ตรงกับวัตถุประสงค์ศูนย์กลางของหน้า อธิบายทางเลือก แทนที่จะกองทุกชนิดที่เป็นไปได้ไว้ในคำตอบเดียว
3. โค้ดและการแมป สร้าง JSON-LD พร้อมแหล่งที่มาของทุกค่าที่ปล่อยออกมา ละเว้น property ที่ไม่ทราบแทนการใส่ placeholder
4. การตรวจสอบและเผยแพร่ ตรวจ syntax ของ JSON ข้อกำหนดเฉพาะฟีเจอร์ DOM ที่ render แล้ว URL Inspection และรายงาน Search Console ที่เหมาะสม

Skill ด้านล่างทำให้ด่านเหล่านี้ชัดเจน Skill นี้ขอให้ Codex audit ก่อนแล้วค่อยเปลี่ยนโค้ด ซึ่งเป็นวิธีที่ง่ายที่สุดในการป้องกัน markup ที่ดูเหมือนถูกต้องแต่ค่อย ๆ ห่างจากหน้าเว็บจริง

คัดลอก SEO Schema JSON-LD Codex Skill นี้ (SKILL.md)

บันทึกสิ่งต่อไปนี้เป็นการกำหนดค่า Skill ของคุณ เนื้อหานี้ไม่มี directory ของเครื่อง ชื่อผู้ใช้ access token ค่าตัวแปรสภาพแวดล้อม หรือ path ส่วนตัว และสั่ง Codex ให้ตัดบริบทอ่อนไหวออกจากผลลัพธ์ด้วย

---
name: seo-schema-jsonld
description: Audit visible page facts, recommend accurate Schema.org JSON-LD, implement it safely, and validate it against Google structured-data requirements.
---

# SEO Schema JSON-LD

Use this skill when a user asks to add, repair, review, or validate Schema.org JSON-LD / structured data for a website page, template, CMS entry, or component.

## Primary rule

Treat structured data as a structured representation of the page's user-visible facts. Never use it to invent, hide, exaggerate, or imply information that the page does not support.

## Privacy and output safety

- Never print absolute local paths, home directories, usernames, credentials, tokens, cookies, API keys, environment-variable values, private URLs, or repository-specific secrets.
- Refer to files with short, project-relative labels when needed, such as `src/pages/article.tsx` or `the page template`.
- Do not copy sensitive values into JSON-LD, examples, logs, commit messages, screenshots, or explanations.
- If input contains secrets or private identifiers, omit them and state that sensitive values were excluded.

## Required workflow

### 1. Inspect before generating

Read the relevant page, template, content data, and any existing structured data. Build a fact inventory using only:

- visible page text and user-visible UI;
- trusted CMS fields that are rendered on that page;
- verified product, organization, author, or breadcrumb data supplied by the user.

For every candidate property, label it `confirmed`, `missing`, or `needs human confirmation`. Do not infer missing values from brand names, URLs, conventions, or unrelated pages.

### 2. Choose the narrowest suitable type

Identify the page's primary purpose first. Recommend one primary Schema.org type that truthfully describes it. Add supporting objects only when they also describe user-visible information on the same page.

Explain the recommended primary type, supporting types, why each applies, and types deliberately rejected.

For Google rich-result eligibility, consult the current Google Search Central documentation for the target feature. Schema.org support alone does not establish Google feature support.

### 3. Apply strict data guardrails

Never generate these values unless they are confirmed and visible or otherwise explicitly verified by the user:

- `aggregateRating`, `review`, or review counts;
- price, currency, availability, offer dates, shipping, or return policy;
- author, publisher, logo, address, phone, social profile, or `sameAs`;
- publication dates, modification dates, images, video duration, or interaction counts;
- FAQ questions and answers that are not visibly present;
- event, job, medical, financial, legal, or local-business claims.

Never add misleading `FAQPage`, fake reviews, hidden content, keyword lists, or unrelated types. Prefer fewer complete and accurate properties over many uncertain ones.

### 4. Produce the implementation

Return these sections in order:

1. `Fact inventory` - property, value or status, and visible source.
2. `Schema decision` - primary type, supporting types, assumptions, and exclusions.
3. `JSON-LD` - valid JSON inside one `application/ld+json` script block. Use placeholders only in a clearly labeled illustrative example; never present placeholders as production-ready values.
4. `Implementation note` - the safe insertion point for the site's framework or CMS, without exposing private paths.
5. `Validation checklist` - syntax, rendered-page check, Google Rich Results Test when applicable, Schema Markup Validator, URL Inspection after deployment, and Search Console monitoring.
6. `Open questions` - every field that needs a human decision.

If editing code is requested, make the smallest scoped change. Preserve existing valid markup, avoid duplicate entities, and explain any conflict before replacing it.

## JSON-LD quality checks

Before finalizing, verify all of the following:

- JSON parses and uses `https://schema.org` as `@context`.
- The main type matches the page's main user-visible purpose.
- Every emitted value has a page-level source or explicit user confirmation.
- Required fields for the intended Google feature are present and accurate.
- URLs are canonical, publicly reachable URLs when the property requires a URL.
- Dates use ISO 8601 where required.
- Multiple entities are connected deliberately, not duplicated accidentally.
- The markup remains available to crawlers in the rendered response.
- The result contains no secrets, local paths, private identifiers, or fabricated claims.

## Limitations to state plainly

Valid structured data can help search engines understand a page and make it eligible for certain search appearances. It does not guarantee rich results, rankings, traffic, citations, or inclusion in AI answers.

ใช้ Skill พร้อมด่านอนุมัติ

อย่าหยุดเพียงแค่ "เพิ่ม schema ในหน้านี้" ให้ Codex ได้รับหน้าดังกล่าวและเกณฑ์การยอมรับ นี่คือ prompt เริ่มต้นที่ใช้ได้:

Use the SEO Schema JSON-LD skill to review this article page.

Goal: add accurate Article and BreadcrumbList JSON-LD if the visible content supports them.
First return the fact inventory and schema decision. Do not edit code until I approve the decision.
Do not create ratings, reviews, author details, dates, images, or organization fields that are absent from the page.
After approval, make the smallest implementation change and provide the validation checklist.

สำหรับ template ขนาดใหญ่ ให้คงด่าน "บัญชีรายการข้อเท็จจริงและการตัดสินใจก่อน" ไว้ ขั้นตอนนี้เพิ่มการตรวจทานสั้น ๆ แต่สามารถหยุดข้อสมมติที่ผิดเพียงข้อเดียวไม่ให้กระจายไปยัง URL หลายพันรายการได้

เส้นทาง 30 นาทีจาก audit สู่การ deploy

หลังเผยแพร่ ใช้ URL Inspection เพื่อยืนยันว่า Google ดึงและ parse หน้าได้ จากนั้นใช้รายงาน enhancement ที่เกี่ยวข้องใน Search Console เพื่อค้นหาปัญหา template การ deploy หรือแหล่งข้อมูลในระดับขนาดใหญ่ แบบแรกตรวจ URL เดียว ส่วนแบบหลังเหมาะกับการค้นหาความเสียหายเชิงระบบมากกว่า

แต่ละชั้นจับความล้มเหลวคนละแบบ วัตถุที่ syntax ถูกต้องยังอาจไม่ผ่านการตรวจข้อเท็จจริงของหน้าหรือการ deploy

ตัวอย่างหน้า article ที่ตั้งใจให้มีน้อยที่สุด

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

ตัวอย่างนี้ตั้งใจไม่ใส่ rating ผู้เขียน วันที่เผยแพร่ รูปภาพ หรือ publisher สิ่งเหล่านี้ไม่ใช่ของตกแต่ง SEO ที่เลือกใส่ได้ แต่เป็นคำกล่าวอ้างที่ต้องมีแหล่งที่มาเชื่อถือได้

ห้าวิธีที่ markup ถูกต้องทางเทคนิคแต่ยังผิดพลาดได้

JSON parse ได้ไม่ได้แปลว่าจริง

JSON validator บอกได้ว่า syntax parse ได้หรือไม่ แต่บอกไม่ได้ว่าหน้ามีรีวิว ราคา หรือผู้เขียนตามที่คุณประกาศจริงหรือไม่ หรือ Product เป็นผลิตภัณฑ์จริงแทนที่จะเป็นหน้าคำอธิบายบริการหรือไม่ บัญชีรายการข้อเท็จจริงจับปัญหาส่วนใหญ่ได้ตั้งแต่ต้น

วัตถุมากกว่าไม่ได้หมายถึง markup ที่ดีกว่า

หน้า recipe ที่มีวิดีโอให้เห็นสามารถมี Recipe, VideoObject และ breadcrumb ได้อย่างถูกต้อง แต่จุดประสงค์หลักต้องชัดเจน การเพิ่ม Article, Product, FAQPage และ HowTo ในหน้าคอนเทนต์ทั่วไปมักสร้างภาระดูแลและความเสี่ยงเรื่องความไม่สอดคล้อง

ความมองเห็นและความสดใหม่ต้องมีเจ้าของเดียวกัน

แนวทางทั่วไปของ Google กำหนดให้ structured data แทนหน้าจริงและข้อมูลที่เปลี่ยนตามเวลาต้องเป็นปัจจุบัน ราคา สต็อก วันที่จัดงาน ตำแหน่งงาน และ rating ไม่ควรเป็นค่าที่วางครั้งเดียว ให้เชื่อมข้อเท็จจริงที่เปลี่ยนแปลงกับแหล่งข้อมูลที่ควบคุมได้ และทดสอบใหม่เมื่อ template เปลี่ยน

FAQPage ไม่ใช่ของตกแต่งคำถาม-คำตอบทั่วไป

เฉพาะคำถามและคำตอบที่ผู้ใช้เห็นได้จริงเท่านั้นที่อยู่ใน FAQ markup และฟีเจอร์ Google อาจมีเงื่อนไข eligibility เพิ่มเติม เผยแพร่ FAQ ที่แท้จริงและครบถ้วนก่อน แล้วตรวจคู่มือฟีเจอร์ปัจจุบัน อย่าออกแบบรายการคำถามเพียงเพื่อไล่หาการแสดงผลแบบใดแบบหนึ่ง

Schema ไม่ได้ข้ามการ crawl การ index หรือคุณภาพของหน้า

หน้าสำคัญที่ถูกบล็อกด้วย noindex access control หรือกฎ crawl จะไม่กลายเป็นหน้าที่มีสิทธิ์ในผลการค้นหาเพราะมี JSON-LD Schema เป็นเพียงชั้นหนึ่งของ technical SEO ไม่ใช่สิ่งทดแทน crawlability เนื้อหาที่มีประโยชน์ หรือประสบการณ์หน้าเว็บ สำหรับการตรวจเว็บไซต์ที่กว้างขึ้น ใช้ ไดเรกทอรีเครื่องมือ SEO ของ Auspia เพื่อเลือก workflow audit ที่เหมาะสม

Checklist ก่อนเผยแพร่

• [ ] มีการระบุชนิดหลักของหน้า และอธิบายเหตุผลได้ในหนึ่งประโยค
• [ ] ทุกค่า JSON-LD มีแหล่งที่มาที่มองเห็นบนหน้า หรือแหล่งข้อมูลที่เชื่อถือได้และ render แล้ว
• [ ] ไม่มี rating รีวิว ราคา สต็อก ผู้เขียน วันที่ รูปภาพ หรือรายละเอียดองค์กรที่สร้างขึ้นเอง
• [ ] การเปลี่ยนแปลงไม่สร้าง entity ซ้ำกับที่ CMS plugin หรือ component อื่นส่งออกแล้ว
• [ ] JSON parse ได้ และ markup ปรากฏใน DOM ที่ render แล้วคล้ายระบบจริง
• [ ] ตรวจ property ที่จำเป็นสำหรับฟีเจอร์ Google เป้าหมายกับเอกสารทางการปัจจุบันแล้ว
• [ ] ใช้ Rich Results Test เมื่อเกี่ยวข้อง และ Schema Markup Validator แล้ว
• [ ] วางแผน URL Inspection และการทบทวน Search Console หลังเผยแพร่แล้ว
• [ ] ทีมเข้าใจว่า markup ที่ถูกต้องให้ eligibility และความชัดเจน ไม่ใช่คำสัญญาเรื่อง rich result หรืออันดับ

คำถามที่พบบ่อย

SKILL.md ตัดสินใจได้ไหมว่าเว็บไซต์ฉันต้องใช้ schema ใด

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

JSON-LD ควรอยู่ใน <head> หรือ <body>

Google รองรับ JSON-LD ทั้งใน HTML <head> และ <body> ใช้ตำแหน่งที่เสถียรซึ่ง framework หรือ CMS ของคุณรักษาให้สอดคล้องกับหน้าได้ การทดสอบที่สำคัญคือ Google crawl markup ที่ถูกต้องซึ่งตรงกับหน้าที่ render แล้วได้หรือไม่

ทำไมไม่มีอะไรเปลี่ยนหลัง Rich Results Test ผ่าน

การทดสอบสำเร็จยืนยันสัญญาณ eligibility ทางเทคนิค ไม่ได้บังคับให้ Google แสดง rich result Google เลือกการแสดงผลด้วยหลายสัญญาณ เช่น query อุปกรณ์ ตำแหน่ง และตัวหน้าเอง ตรวจความสอดคล้องของเนื้อหาและความสามารถในการ index แทนการเพิ่ม property ที่ไม่มีหลักฐานรองรับ

Codex ควรกรอกทุก property ของ Schema.org ที่หาเจอหรือไม่

ไม่ควร เอกสาร Google สนับสนุน property ที่แนะนำจำนวนน้อยกว่าแต่ครบถ้วนและถูกต้อง มากกว่า property จำนวนมากที่ไม่ครบหรือไม่แม่นยำ ข้อจำกัดนี้ควรอยู่ใน Skill ไม่ใช่แค่ prompt ครั้งเดียว

แหล่งอ้างอิงทางการ

• Google Search Central: Introduction to structured data markup
• Google Search Central: General structured data guidelines
• Google Rich Results Test
• Schema.org

ผู้เขียน: Julian Mercer นักปฏิบัติการ SEO เชิงเทคนิคที่มีประสบการณ์ 14 ปีที่ Auspia Julian เขียนเรื่อง crawlability, rendering, structured data และระบบเชิงเทคนิคที่ทีมดำเนินงานได้อย่างน่าเชื่อถือ