Cara membuat Skill Codex untuk SEO Schema JSON-LD

Jawaban singkat: Schema harus menjadi salinan terstruktur dari fakta halaman

Jika Anda datang untuk mencari prompt Codex SKILL.md bagi SEO Schema JSON-LD, Anda dapat menyalinnya di bawah ini. Aturan di baliknya lebih penting daripada kodenya: data terstruktur harus menyatakan fakta yang sudah dapat diverifikasi pengunjung di halaman. Data terstruktur bukan kesempatan untuk menulis objek JSON paling rumit yang mungkin.

Codex berguna di sini karena dapat memeriksa halaman, data kontennya, dan markup yang ada sebelum menyarankan tipe atau menulis JSON-LD. Urutan ini penting. Permintaan yang samar seperti "tambahkan semua schema yang bisa" sering menghasilkan aggregateRating, harga, penulis, atau tanggal publikasi yang dibuat-buat. Bidang itu mungkin lolos parsing tetapi tetap salah menggambarkan halaman.

Google merekomendasikan JSON-LD jika penyiapan situs memungkinkan karena biasanya lebih mudah diterapkan dan dipelihara. Panduannya juga jelas: markup harus menggambarkan halaman tempat markup berada, mencerminkan konten yang terlihat oleh pengguna, dan tetap akurat. Lulus Rich Results Test tidak menjamin hasil kaya.

Pilih tipe utama halaman sebelum menambahkan objek pendukung

Mulailah dengan pertanyaan sederhana: apa yang terutama dilihat pengunjung? Jawabannya harus menentukan tipe Schema.org utama. Breadcrumb, detail organisasi, dan video dapat mendukung objek utama itu jika semuanya menggambarkan informasi yang dapat dilihat pengunjung pada halaman yang sama.

Schema.org memiliki kosakata yang jauh lebih luas daripada fitur hasil kaya Google. Untuk pekerjaan Google Search, panduan Google Search Central terkini bagi fitur yang dituju lebih berwenang daripada sekadar fakta bahwa suatu properti ada di Schema.org.

Mulailah dari tujuan halaman. Tipe mengikuti fakta yang terlihat, bukan sebaliknya.

Workflow Codex yang lebih aman memiliki empat gerbang

1. Inventaris fakta. Ambil hanya dari salinan halaman yang terlihat, bidang CMS tepercaya yang dirender pada halaman, atau data yang telah diverifikasi pengguna secara eksplisit. Tandai setiap bidang kandidat sebagai dikonfirmasi, hilang, atau perlu konfirmasi.
2. Keputusan tipe. Pilih tipe utama yang cocok dengan tujuan inti halaman. Jelaskan alternatif apa pun, alih-alih menumpuk semua tipe yang mungkin dalam satu respons.
3. Kode dan pemetaan. Buat JSON-LD dengan sumber untuk setiap nilai yang dikeluarkan. Hilangkan properti yang tidak diketahui alih-alih mengisinya dengan placeholder.
4. Validasi dan rilis. Periksa sintaks JSON, persyaratan fitur tertentu, DOM yang dirender, Inspeksi URL, dan laporan Search Console yang tepat.

Skill di bawah ini membuat gerbang tersebut eksplisit. Skill meminta Codex mengaudit terlebih dahulu dan mengubah kode kemudian; itulah cara paling sederhana untuk mencegah markup yang tampak valid menjauh dari halaman sebenarnya.

Salin Skill Codex SEO Schema JSON-LD ini (SKILL.md)

Simpan isi berikut sebagai konfigurasi Skill Anda sendiri. Isinya tidak memuat direktori mesin, nama pengguna, token akses, nilai variabel lingkungan, atau jalur privat. Isi tersebut juga meminta Codex menghapus konteks sensitif dari outputnya.

---
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.

Gunakan Skill dengan gerbang persetujuan

Jangan berhenti pada "tambahkan schema ke halaman ini." Berikan halaman dan kriteria penerimaan kepada Codex. Berikut prompt awal yang berguna:

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.

Untuk template besar, pertahankan gerbang "inventaris fakta dan keputusan terlebih dahulu". Gerbang ini menambahkan tahap peninjauan singkat, tetapi dapat mencegah satu asumsi buruk menyebar ke ribuan URL.

Jalur 30 menit dari audit ke penerapan

Setelah rilis, gunakan Inspeksi URL untuk memastikan Google dapat mengambil dan mengurai halaman. Kemudian gunakan laporan peningkatan yang relevan di Search Console untuk menemukan kegagalan template, penerapan, atau sumber data dalam skala besar. Yang pertama memeriksa satu URL; yang kedua lebih baik untuk menemukan kerusakan sistemik.

Setiap lapisan menangkap kegagalan yang berbeda. Objek yang sintaksnya valid masih dapat gagal pada pemeriksaan fakta halaman atau penerapan.

Contoh minimal yang disengaja untuk halaman artikel

Ini adalah kode ilustratif, bukan objek produksi siap-tempel. Contoh ini menunjukkan bentuk BlogPosting dan BreadcrumbList. Gunakan nilai nyata yang dikonfirmasi halaman untuk judul, deskripsi, URL, penulis, tanggal, dan gambar. Jika halaman tidak memiliki salah satu fakta itu, jangan menambahkannya hanya agar objek tampak lebih lengkap.

Contoh ini sengaja tidak memiliki rating, penulis, tanggal publikasi, gambar, atau publisher. Semua itu bukan hiasan SEO opsional. Semua itu adalah klaim yang membutuhkan sumber tepercaya.

Lima cara markup yang valid secara teknis tetap bisa salah

Parsing JSON bukan uji kebenaran

Validator JSON dapat memberi tahu apakah sintaks dapat diurai. Validator tidak dapat memberi tahu apakah halaman memiliki ulasan, harga, atau penulis yang Anda nyatakan, atau apakah sebuah Product sebenarnya hanya halaman deskripsi layanan. Inventaris fakta menangkap sebagian besar kegagalan ini sejak awal.

Lebih banyak objek tidak berarti markup lebih baik

Halaman resep dengan video yang terlihat dapat secara sah menyertakan Recipe, VideoObject, dan breadcrumb. Tujuan utamanya tetap harus jelas. Menambahkan Article, Product, FAQPage, dan HowTo ke halaman konten umum biasanya menciptakan pekerjaan pemeliharaan dan risiko inkonsistensi.

Visibilitas dan kebaruan memerlukan pemilik yang sama

Panduan umum Google mengharuskan data terstruktur merepresentasikan halaman dan informasi yang sensitif terhadap waktu tetap terkini. Harga, stok, tanggal acara, lowongan kerja, dan rating tidak seharusnya hidup sebagai nilai yang ditempel sekali. Hubungkan fakta dinamis ke sumber yang terkontrol dan uji ulang saat template berubah.

FAQPage bukan hiasan tanya-jawab umum

Hanya pertanyaan dan jawaban yang benar-benar dapat dilihat pengguna yang termasuk dalam markup FAQ, dan fitur Google dapat memiliki syarat kelayakan tambahan. Terbitkan FAQ asli yang lengkap terlebih dahulu, lalu periksa panduan fitur terkini. Jangan merekayasa daftar pertanyaan hanya untuk mengejar perlakuan hasil tertentu.

Schema tidak melewati crawling, pengindeksan, atau kualitas halaman

Halaman penting yang diblokir oleh noindex, kontrol akses, atau aturan crawling tidak menjadi layak untuk hasil penelusuran hanya karena berisi JSON-LD. Schema adalah satu lapisan SEO teknis. Schema tidak menggantikan crawlability, konten bermanfaat, atau pengalaman halaman. Untuk pemeriksaan situs yang lebih luas, gunakan direktori alat SEO Auspia untuk memilih workflow audit yang tepat.

Checklist sebelum publikasi

• [ ] Tipe utama halaman dinyatakan dan dapat dibenarkan dalam satu kalimat.
• [ ] Setiap nilai JSON-LD memiliki sumber halaman yang terlihat atau sumber data tepercaya yang dirender.
• [ ] Tidak ada rating, ulasan, harga, stok, penulis, tanggal, gambar, atau detail organisasi yang dibuat-buat.
• [ ] Perubahan tidak menduplikasi entitas yang sudah dikeluarkan CMS, plugin, atau komponen lain.
• [ ] JSON dapat diurai dan markup tampil di DOM yang dirender menyerupai produksi.
• [ ] Properti yang diperlukan untuk fitur Google yang dituju telah diperiksa terhadap dokumentasi resmi terkini.
• [ ] Rich Results Test, bila relevan, dan Schema Markup Validator telah digunakan.
• [ ] Inspeksi URL dan tinjauan Search Console pascarilis telah dijadwalkan.
• [ ] Tim memahami bahwa markup valid menghasilkan kelayakan dan kejelasan, bukan janji hasil kaya atau peringkat.

Pertanyaan umum

Dapatkah SKILL.md memutuskan schema yang dibutuhkan situs saya?

Skill dapat memberi rekomendasi dari fakta halaman dan mengenali hal yang belum diketahui, tetapi tidak boleh menggantikan konfirmasi fakta. Harga produk, ulasan, detail organisasi, penulis, dan tanggal publikasi harus berasal dari sumber data halaman tepercaya atau pemilik informasi yang bertanggung jawab.

JSON-LD sebaiknya ditempatkan di <head> atau <body>?

Google mendukung JSON-LD di <head> maupun <body> HTML. Gunakan lokasi stabil yang dapat dijaga sinkron oleh framework atau CMS Anda dengan halaman. Uji yang bermakna adalah apakah Google dapat melakukan crawling markup valid yang cocok dengan halaman yang dirender.

Mengapa tidak ada yang berubah setelah Rich Results Test lulus?

Tes yang berhasil mengonfirmasi sinyal kelayakan teknis; tes itu tidak mewajibkan Google menampilkan hasil kaya. Google memilih perlakuan hasil dengan banyak sinyal, termasuk kueri, perangkat, lokasi, dan halaman itu sendiri. Periksa konsistensi konten dan kemampuan indeks alih-alih menambahkan properti yang tidak didukung.

Haruskah Codex mengisi setiap properti Schema.org yang ditemukannya?

Tidak. Dokumentasi Google menyukai lebih sedikit properti yang direkomendasikan tetapi lengkap dan akurat daripada banyak properti yang tidak lengkap atau tidak akurat. Batasan ini harus ada di Skill, bukan hanya pada prompt sekali pakai.

Referensi resmi

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

Penulis: Julian Mercer, praktisi SEO teknis dengan pengalaman 14 tahun di Auspia. Julian menulis tentang crawlability, rendering, data terstruktur, dan sistem teknis yang dapat dijalankan tim secara andal.