Structured data (JSON-LD): apa gunanya, dan cara menyemaknya dalam sepuluh minit

Structured data ialah blok kod yang menerangkan maksud kandungan sesuatu halaman kepada enjin carian, bukan sekadar membekalkan teksnya. Pada halaman resipi, markup menyatakan bahan, masa memasak dan suhu. Pada halaman blog, ia menyatakan tajuk artikel, penulis, tarikh terbit dan imej utama. Google menyokong tiga format penulisan iaitu JSON-LD, Microdata dan RDFa, tetapi hanya JSON-LD disyorkan secara rasmi. Sebabnya mudah: JSON-LD ditulis dalam satu blok skrip berasingan di dalam kepala halaman, jadi ia tidak berselirat dengan teks yang dilihat pembaca dan lebih mudah dikemas kini apabila templat berubah.

826 jenis lawan 25 ciri: dua angka yang menjelaskan segalanya

Halaman schema.org/docs/schemas.html menyatakan kosakata itu kini mengandungi 826 Types, 1,540 Properties, 19 Datatypes, 96 Enumerations dan 544 Enumeration members. Angka itu boleh menakutkan pemilik laman, tetapi ia tidak perlu dihabiskan. Halaman galeri carian Google yang dikemas kini pada 15 Jun 2026 menyenaraikan 25 ciri rich result yang benar-benar disokong, antaranya Article, Breadcrumb, Event, Local business, Product, Recipe, Review snippet dan Video. Daripada 826 jenis yang wujud, hanya 25 jenis, iaitu kira-kira 3 peratus, mempunyai kesan langsung pada cara halaman anda muncul dalam carian Google. Baki 801 jenis itu masih sah dan berguna untuk mesin lain, tetapi bukan keutamaan laman kecil.

Cara membaca angka itu ialah dengan berhenti mengejar kosakata penuh. Pilih jenis yang sepadan dengan kandungan yang benar-benar ada pada halaman anda, kemudian lengkapkan sifat wajibnya. Markup yang panjang tetapi tidak sepadan dengan kandungan lebih merugikan daripada markup pendek yang tepat, kerana garis panduan Google menganggap markup yang tidak mewakili halaman sebagai pelanggaran.

Empat kajian kes yang Google sendiri terbitkan

Dokumentasi pengenalan structured data memuatkan empat contoh yang disukat oleh syarikat sendiri. Rotten Tomatoes menanda 100,000 halaman dan mencatat kadar klik 25 peratus lebih tinggi pada halaman yang mempunyai structured data berbanding halaman tanpa markup. The Food Network menukar 80 peratus halamannya dan melihat kenaikan lawatan 35 peratus. Rakuten mendapati pengguna meluangkan masa 1.5 kali lebih lama dan kadar interaksi 3.6 kali lebih tinggi pada halaman bermarkup. Nestle mencatat kadar klik 82 peratus lebih tinggi pada halaman yang dipaparkan sebagai rich result.

Empat angka ini datang daripada halaman rasmi Google, bukan daripada penjual alat SEO. Namun ia bukan janji. Structured data membuka peluang untuk penampilan yang lebih menonjol, sementara keputusan untuk memaparkannya kekal pada algoritma Google. Dokumentasi pengesahan Google menulis dengan jelas bahawa kelayakan hanyalah siling yang diukur oleh alat, bukan jaminan paparan.

Empat jenis yang berbaloi untuk laman kecil

Kalau laman anda ada blog, halaman perkhidmatan dan halaman hubungan, empat jenis ini sudah memadai. Pertama, Person atau Organization untuk pemilik laman. Kedua, BlogPosting atau Article untuk setiap pos. Ketiga, BreadcrumbList untuk menunjukkan kedudukan halaman dalam hierarki. Keempat, LocalBusiness kalau anda mempunyai premis fizikal di Malaysia, dengan waktu operasi, nombor telefon dan koordinat.

• ▸ Person atau Organization: nama, jawatan, gambar dan alamat negara. Label @id yang stabil membolehkan entiti yang sama dirujuk daripada halaman lain di laman yang sama.
• ▸ BlogPosting atau Article: tajuk, imej utama, penulis dan tarikh terbit. Dokumentasi Google menyenaraikan headline, image, datePublished dan author sebagai sifat yang disyorkan.
• ▸ BreadcrumbList: susunan ListItem dengan position bermula daripada 1, setiap satu membawa nama dan URL.
• ▸ LocalBusiness atau Product: alamat, waktu operasi, harga dan mata wang, tetapi hanya jika maklumat itu benar-benar dipaparkan pada halaman.

Satu butiran teknikal yang sering tersalah ialah tarikh. Google menggunakan format ISO 8601, contohnya 2024-01-05T08:00:00+08:00. Offset +08:00 penting untuk laman Malaysia kerana ia memberitahu enjin carian masa terbit yang tepat, bukan sekadar tarikh. Markup yang menulis tarikh tanpa zon masa masih sah, tetapi zon masa menjadikan masa terbit tepat dan mengelakkan kekeliruan apabila pembaca berada di negara lain.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Tajuk pos anda",
  "image": ["https://thalhah.my/assets/img/blog/hero.webp"],
  "datePublished": "2026-10-01T18:00:00+08:00",
  "dateModified": "2026-10-01T18:00:00+08:00",
  "inLanguage": "ms",
  "author": { "@type": "Person", "name": "Nama Penulis", "url": "https://thalhah.my" },
  "mainEntityOfPage": { "@type": "WebPage", "@id": "https://thalhah.my/blog/slug-pos" }
}

Tiga blok JSON-LD pada halaman blog laman ini

Cara paling cepat untuk faham ialah melihat contoh yang sudah berjalan. Halaman utama laman ini mengeluarkan satu blok JSON-LD jenis Person dengan label @id https://thalhah.my/#orang, lengkap dengan nama penuh, jawatan, alamat negara MY dan 11 bidang kemahiran. Halaman pos blog pula mengeluarkan tiga blok: Person yang sama, BlogPosting untuk artikel, dan BreadcrumbList dengan tiga ListItem iaitu Utama, Blog dan tajuk pos.

Perhatikan bahawa setiap blok dirujuk melalui label @id yang sama. Tanpa label itu, enjin carian boleh menganggap maklumat penulis pada satu halaman sebagai orang yang berbeza daripada halaman lain, dan bukannya menguatkan entiti yang sama. Inilah perbezaan antara markup yang menyatukan entiti dan markup yang hanya lulus ujian sintaks.

curl -sS -A "Mozilla/5.0" https://thalhah.my/blog/semak-ssl-tls-laman-sendiri | grep -c application/ld+json

Jalankan arahan itu pada laman anda sendiri. Kalau jawapannya 0, halaman itu tidak mempunyai markup langsung. Kalau jawapannya 3, semak sama ada ketiga-tiga blok benar-benar sepadan dengan kandungan yang dilihat pembaca.

FAQ dan HowTo: apa yang Google buang pada 8 Ogos 2023

Pada 8 Ogos 2023, Google mengumumkan dua perubahan yang masih dikuatkuasakan. Rich result FAQ hanya dipaparkan untuk laman kerajaan dan kesihatan yang terkenal serta berwibawa, manakala rich result HowTo dihadkan kepada pengguna desktop sahaja. Google menyatakan perubahan itu selesai digulung ke seluruh dunia dalam masa seminggu.

Bukti terkini ada pada halaman galeri itu sendiri. Daripada 25 ciri yang disenaraikan dalam versi yang dikemas kini pada 15 Jun 2026, tiada satu pun bernama FAQ atau HowTo. URL dokumentasi faqpage juga tidak lagi memulangkan kod 200, sebaliknya kod HTTP 301 yang mengalihkan pembaca ke halaman kemas kini dokumentasi. Saya menyemak pautan itu pada 1 Oktober 2026 dan mendapat jawapan yang sama.

Kalau anda masih menyimpan markup FAQPage, anda tidak perlu panik. Google menulis dengan jelas bahawa markup yang tidak digunakan tidak menyebabkan masalah, cuma tiada kesan yang kelihatan dalam carian. Tetapi jangan bayar sesiapa untuk menambahnya dengan harapan mendapat menu lungsur dalam hasil carian, kerana harapan itu tidak lagi berpijak pada dasar Google semasa.

Cara menyemak markup dalam tiga langkah

• ▸ Rich Results Test di search.google.com/test/rich-results. Pilih mod URL, bukan mod kod, supaya alat itu merender halaman seperti Googlebot telefon dan bukan seperti pelayar meja anda.
• ▸ Schema Markup Validator di validator.schema.org. Gunakan alat ini untuk membandingkan markup dengan kosakata penuh 826 jenis, kerana Rich Results Test hanya menyemak 25 ciri yang disokong Google.
• ▸ Laporan Enhancements dalam Search Console. Ia menunjukkan apa yang Google sebenarnya indeks selepas merayau, bukan apa yang alat ujian lihat seminit tadi.

Bezakan ralat daripada amaran. Ralat bermakna sifat wajib tiada atau nilai @type tidak dikenali, dan item itu hilang kelayakan serta-merta. Amaran bermakna sifat yang disyorkan tiada; item itu masih layak, cuma paparannya lebih nipis. Bagi laman kecil, punca kegagalan yang paling kerap bukan koma yang tersalah, tetapi markup yang menanda kandungan yang tidak kelihatan kepada pembaca.

Lima kesilapan yang paling kerap

• ▸ Menanda kandungan yang tidak dipaparkan. Garis panduan Google menyatakan markup mesti benar-benar mewakili kandungan yang dilihat pada halaman.
• ▸ Mencipta sifat yang tidak wujud dalam kosakata, contohnya medan karangan pada jenis Article. Alat pengesahan mengabaikannya secara senyap, jadi markup kelihatan bersih tetapi tidak membawa apa-apa.
• ▸ Meletakkan beberapa blok bercanggah untuk entiti yang sama tanpa @id yang menghubungkannya.
• ▸ Menyekat halaman berstruktur data daripada Googlebot melalui robots.txt, noindex atau kawalan akses lain.
• ▸ Meletakkan URL imej yang tidak boleh diindeks, menyebabkan imej hilang daripada hasil carian walaupun markup betul.

Senarai semak sepuluh minit

• ▸ Pilih satu halaman penting, contohnya pos blog terbaik anda.
• ▸ Semak kod sumber halaman itu dan kira berapa blok application/ld+json yang ada.
• ▸ Pastikan setiap jenis markup sepadan dengan kandungan yang benar-benar kelihatan.
• ▸ Jalankan Rich Results Test dalam mod URL dan betulkan semua ralat.
• ▸ Jalankan validator.schema.org untuk mengesahkan sifat terhadap kosakata penuh.
• ▸ Catat tarikh semakan, kemudian ulang setiap kali templat laman berubah.

Structured data bukan projek besar. Ia satu blok kecil pada setiap templat, disemak sekali dengan alat percuma, dan dikemas kini apabila kandungan berubah. Yang lebih penting ialah kesediaan menyemak angka sebenar dalam markup anda sendiri, bukan mengandaikan ia betul kerana halaman masih muncul dalam carian.