Bahasa

Nesting Markup Schema dengan @id dan @graph

Panduan mendalam untuk menghubungkan entitas JSON-LD dengan @id dan @graph, memakai dua pola node canonical, menghindari tiga kegagalan graph, dan memahami batas dokumentasi Google.

Pertama kali diterbitkan: 2 Jul 2026 · Terakhir diperbarui: 21 Agu 2026 · Advanced
Bahasa
AIDitulis olehAI v2

Nesting menghubungkan entitas JSON-LD melalui @id, yaitu URI stabil dan unik yang memungkinkan entitas lain merujuknya tanpa deklarasi ulang. @graph menyatukan entitas yang terhubung dalam satu blok skrip. Gunakan pola WebSite → WebPage → Article → Author untuk penerbitan dan Product → Offer → Organization untuk ecommerce. Hindari @id yang tidak konsisten atau tidak unik, referensi yatim, dan deklarasi lengkap duplikat. Google mengonfirmasi bahwa nesting dan item individual sama-sama berfungsi, tetapi tidak mengonfirmasi penguraian @id lintas halaman. Pilihan aman adalah mempertahankan @id yang konsisten sekaligus menyertakan graph lengkap pada setiap halaman yang memerlukannya. Nesting membantu pemahaman entitas; bukan faktor peringkat atau jaminan rich result.

TL;DR — Nesting menghubungkan entitas JSON-LD melalui @id—URI stabil dan unik, biasanya URL canonical ditambah #fragment—sehingga Anda merujuk entitas, bukan mendeklarasikannya ulang. @graph adalah kata kunci yang menyatukan entitas terhubung dalam satu blok skrip. Dokumentasi Google mengonfirmasi bahwa nesting dan item individual sama-sama berfungsi, serta @id digunakan untuk menautkan item terkait. Namun, dokumentasi itu tidak pernah mengonfirmasi apakah @id diurai lintas halaman. Karena itu, pilihan aman adalah nilai @id yang konsisten serta graph entitas lengkap pada setiap halaman yang memerlukannya. Pelajari dua pola: WebSite → WebPage → Article → Author untuk penerbitan dan Product → Offer → Organization/seller untuk ecommerce. Waspadai tiga mode kegagalan: nilai @id yang tidak konsisten atau tidak unik, referensi yatim—@id dirujuk tetapi tidak pernah dideklarasikan; tidak lengkap secara semantik, bukan JSON-LD yang tidak valid—serta deklarasi lengkap duplikat untuk entitas yang sama. Pengulangan entitas yang sama digabung menurut aturan node JSON-LD, tetapi penggunaan satu @id untuk entitas yang benar-benar berbeda menimbulkan konflik nyata. Nesting adalah alat untuk memahami entitas, disambiguasi, dan deduplikasi; bukan pengungkit peringkat atau rich result.

Evidence for this claim JSON-LD supports connected nodes via nesting or @id references, allowing multiple related entities to form one graph. Scope: JSON-LD graph model. Confidence: high · Verified: W3C JSON-LD 1.1 Evidence for this claim Google requires structured data to represent visible page content and follow each feature's specific nesting and property guidelines; extra valid nodes do not create eligibility by themselves. Scope: Current Google structured-data general guidelines. Confidence: high · Verified: Google Search Central: Structured data general guidelines

Cakupan: pembahasan mendalam, bukan pengantar

Artikel ini mengasumsikan Anda sudah memahami JSON-LD dan alasan format tersebut direkomendasikan. Hal itu dibahas di halaman markup schema, yang juga memperkenalkan @id dan @graph secara ringkas. Halaman ini adalah pembahasan lanjutannya: mekanisme sebenarnya, pola node standar, dan kesalahan tertentu yang diam-diam merusak graph. Jika Anda memerlukan dasar format atau lokasi blok <script>, lihat artikel pendamping tentang JSON-LD.

@id — pengenal stabil, bukan URL yang harus dapat diambil

@id menetapkan URI unik kepada entitas JSON-LD agar entitas lain dapat merujuknya. Konvensi yang konsisten di setiap sumber kredibel yang saya periksa ialah URL canonical absolut ditambah fragmen deskriptif:

"@id": "https://example.com/#organization"
"@id": "https://example.com/#website"
"@id": "https://example.com/team/jane-doe/#person"

Ada dua hal yang sering disalahpahami:

  • Nilainya tidak harus dapat diambil. Menurut spesifikasi JSON-LD, tugas @id adalah mengidentifikasi node—memberikan “nama” unik dan stabil untuk entitas—bukan memastikan URL dapat diambil. Penggunaan fragmen pada domain sendiri adalah praktik standar dan tidak mengharuskan URL fragmen itu memuat halaman tersendiri. Panduan pengenal node dari Sitebulb menjelaskannya dengan baik: “a unique ‘name’ for an entity, which is publicly accessible and can be looked up or linked to.” (terjemahan) “nama unik untuk sebuah entitas, yang dapat diakses publik serta dapat dicari atau ditautkan.”
  • @id bukan url. Keduanya merupakan properti berbeda dengan tugas berbeda. @id mengidentifikasi node dalam graph; url menjelaskan halaman nyata yang dapat diambil tentang entitas tersebut. Sebuah Organization dapat—dan sering kali sebaiknya—memiliki keduanya: @id berupa https://example.com/#organization dan url berupa https://example.com/.

Nilai @id juga peka huruf besar-kecil. #Organization dan #organization adalah dua entitas berbeda. Pilih satu konvensi dan jangan menyimpang darinya.

@graph — menyatukan entitas terhubung dalam satu blok

@graph adalah kata kunci JSON-LD yang memungkinkan Anda menempatkan beberapa entitas tingkat atas dalam satu array di dalam satu blok <script type="application/ld+json">, dengan entitas saling merujuk melalui @id:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "...": "..." },
    { "@type": "WebSite", "@id": "https://example.com/#website", "...": "..." },
    { "@type": "WebPage", "@id": "https://example.com/post/#webpage", "...": "..." }
  ]
}

@graph adalah wadah, bukan kewajiban. Anda tetap dapat menggunakan blok <script> terpisah untuk tiap item; dokumentasi Google mengonfirmasi bahwa kedua pendekatan berfungsi. Alasan memilih @graph adalah kemudahan pemeliharaan. Ketika ada tiga entitas atau lebih yang saling merujuk, Anda cukup menulis @context sekali di bagian atas dan seluruh hubungan berada di satu tempat. Inilah pola yang digunakan Yoast dalam produksi. Dokumentasi arsitektur schema mereka menjelaskan bahwa graph bersama memungkinkan mereka “avoid having to duplicate or repeat shared properties, and to reduce the amount of code/processing/overhead required.” (terjemahan) “menghindari duplikasi atau pengulangan properti bersama, serta mengurangi jumlah kode, pemrosesan, dan overhead yang diperlukan.”

Mengapa perlu nesting—dan apa yang sebenarnya dikatakan Google

Declare each entity once and connect the graph with stable `@id` references instead of repeating full blocks.

One Organization identified as hash organization is referenced as publisher by the WebSite and Article. The WebPage belongs to the WebSite and is connected to the Article. Each entity is declared once, and the same stable at-id string is reused for every reference.

Google mendokumentasikan dua opsi struktur dan mengonfirmasi bahwa keduanya dapat dipahami. Dalam Pedoman Umum Data Terstruktur: “Google Search understands multiple items on a page, whether you nest the items or specify each item individually.” (terjemahan) “Google Penelusuran memahami beberapa item pada sebuah halaman, baik Anda menempatkan item tersebut secara nested maupun menentukan setiap item secara terpisah.” Google menjelaskan keduanya secara langsung: nesting adalah “when there is one main item, and additional items are grouped under the main item” (terjemahan) “ketika ada satu item utama dan item tambahan dikelompokkan di bawah item utama”; sedangkan item individual adalah “when each item is a separate block on the same page.” (terjemahan) “ketika setiap item merupakan blok terpisah pada halaman yang sama.”

Paragraf yang paling mendekati alasan resmi penggunaan @id berbunyi: “If there are items that are more helpful when they are linked together (for example, a recipe and a video), use @id in both the recipe and the video items to specify that the video is about the recipe on the page. If you didn’t link the items together, Google Search may not know that it can show the video as a Recipe rich result.” (terjemahan) “Jika ada item yang lebih berguna ketika ditautkan bersama—misalnya resep dan video—gunakan @id pada item resep dan video untuk menentukan bahwa video tersebut membahas resep pada halaman. Jika item tidak ditautkan, Google Penelusuran mungkin tidak mengetahui bahwa video itu dapat ditampilkan sebagai rich result Resep.” Itulah mekanisme menurut kata-kata Google sendiri: @id memberi tahu Google bahwa dua item saling berkaitan.

Catatan yang perlu disampaikan secara jujur: dokumentasi Google menyatakan prinsip ini dalam prosa, tetapi tidak menyediakan contoh kode @graph + @id yang lengkap. Contoh mereka menampilkan Recipe yang di-nesting dan dua item tingkat atas yang terpisah; keduanya tidak saling merujuk melalui @id. Contoh berikut mengisi kekosongan tersebut.

Hal ini langsung berkaitan dengan dua tugas schema—kerangka dari halaman markup schema. Nesting yang baik merupakan langkah untuk memahami entitas: melakukan disambiguasi serta menghindari data yang bertentangan atau duplikat. Nesting bukan pemicu rich result tersendiri. Menautkan Article dengan rapi ke Author tidak membuka fitur SERP baru; hubungan tersebut hanya menjadi tidak ambigu.

Pola 1 — WebSite → WebPage → Article → Author

Ini adalah pola canonical untuk penerbitan: satu Organization sebagai penerbit, satu WebSite, lalu sebuah WebPage dan Article untuk tiap halaman. author dan publisher dihubungkan melalui @id, bukan dideklarasikan ulang:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Media",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/example-media/",
        "https://en.wikipedia.org/wiki/Example_Media"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Media",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/nesting-schema/#webpage",
      "url": "https://example.com/nesting-schema/",
      "name": "Nesting Schema Markup",
      "isPartOf": { "@id": "https://example.com/#website" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/jane-doe/#person",
      "name": "Jane Doe",
      "url": "https://example.com/team/jane-doe/",
      "sameAs": ["https://www.linkedin.com/in/jane-doe/"]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/nesting-schema/#article",
      "mainEntityOfPage": { "@id": "https://example.com/nesting-schema/#webpage" },
      "headline": "Nesting Schema Markup",
      "author": { "@id": "https://example.com/team/jane-doe/#person" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

Perhatikan prosesnya: author dan publisher berupa referensi satu baris. Person dan Organization masing-masing dideklarasikan sekali. Article terhubung ke WebPage melalui mainEntityOfPage; WebPage menjadi bagian dari WebSite melalui isPartOf; dan WebSite diterbitkan oleh Organization. Inilah graph yang terhubung, bukan lima pulau terpisah.

Pola 2 — Product → Offer → Organization (penjual)

Ini adalah pola setara untuk ecommerce, sekaligus tempat nesting sangat berguna dalam skala besar. Alih-alih mendeklarasikan ulang Organization milik merchant pada ribuan halaman produk, deklarasikan sekali lalu rujuk sebagai seller:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://shop.example.com/#organization",
      "name": "Example Shop",
      "url": "https://shop.example.com/",
      "logo": "https://shop.example.com/logo.png"
    },
    {
      "@type": "Product",
      "@id": "https://shop.example.com/widget/#product",
      "name": "Deluxe Widget",
      "sku": "WIDGET-001",
      "brand": { "@type": "Brand", "name": "Example" },
      "offers": {
        "@type": "Offer",
        "price": "29.99",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "seller": { "@id": "https://shop.example.com/#organization" }
      }
    }
  ]
}

seller pada Offer menunjuk ke node Organization bersama. Entitas penjual yang sama dideklarasikan sekali, lalu dirujuk dari setiap produk. Untuk kumpulan varian yang sangat besar, gagasan @id bersama ini juga berlaku pada ProductGroup dengan varian Product. Itu adalah spesialisasi pola yang sama, bukan mekanisme berbeda.

Tiga kesalahan yang merusak graph

Inilah inti praktis sebuah audit. Ketika nesting “tidak berfungsi”, penyebabnya hampir selalu salah satu dari tiga hal berikut.

1. Nilai @id yang tidak konsisten atau tidak unik

Entitas yang sama diberi string @id berbeda pada halaman yang berbeda—atau selama perpindahan platform maupun migrasi—sehingga mesin pencari dan validator melihatnya sebagai entitas yang tidak berkaitan. Kebalikannya juga bermasalah: satu @id digunakan untuk dua entitas yang benar-benar berbeda. Solusinya adalah konvensi yang ketat dan terdokumentasi, misalnya {base-url}/#organization, {page-url}/#webpage, dan {profile-url}/#person, lalu diterapkan secara mekanis. Huruf besar-kecil berpengaruh: #author ≠ #Author.

2. Referensi yatim

Sebuah @id dirujuk tetapi tidak pernah dideklarasikan. Misalnya, Anda menulis "author": {"@id": "https://example.com/#person-jane"}, tetapi tidak ada node dalam dokumen yang diuji yang mendeklarasikan @id tersebut beserta @type dan propertinya. Perlu dibedakan dengan tepat: objek polos {"@id": "..."}—yang dalam spesifikasi JSON-LD disebut node reference, yakni “a node object used to reference a node having only the @id key” (terjemahan) “objek node untuk merujuk node yang hanya memiliki kunci @id”— merupakan sintaks JSON-LD yang valid. Objek itu bukan kesalahan parsing. Masalahnya bersifat semantik dan bergantung pada konsumennya: hubungan yang dimaksud—“penulis Article ini adalah Person tersebut”—tidak pernah mengarah ke informasi berguna. Fitur atau pembaca yang memerlukan nama, URL, atau data sameAs penulis tidak mendapat apa pun. Ini sulit terdeteksi karena validator sering tetap mengurai setiap item yang dideklarasikan tanpa kesalahan. Anda dapat menerbitkan graph yang tidak lengkap tanpa menyadarinya. Panduan @id Momentic mencatatnya sebagai salah satu kegagalan nesting yang paling umum.

3. Deklarasi lengkap duplikat untuk entitas yang sama

Ini kebalikan dari referensi yatim: objek Organization atau Person lengkap dideklarasikan ulang secara inline di setiap halaman, bukan dideklarasikan sekali dan dirujuk. Dua hal berbeda dapat terjadi dan perlu dibedakan:

  • Deklarasi berulang untuk entitas yang benar-benar sama. Menurut spesifikasi JSON-LD, “the properties of a node in a graph may be spread among different node objects within a document. When that happens, the keys of the different node objects need to be merged to create the properties of the resulting node.” (terjemahan) “Properti sebuah node dalam graph dapat tersebar di beberapa objek node dalam satu dokumen. Dalam keadaan itu, kunci dari objek node yang berbeda perlu digabungkan untuk membentuk properti node hasil.” Jadi, pengulangan @id yang sama dengan data sama atau kompatibel bukan kegagalan parsing; pemroses akan menggabungkannya. Namun, itu tetap bukan praktik yang baik. Nesting justru dibuat untuk mencegahnya. Markup menjadi bengkak dan berubah menjadi perangkap pemeliharaan: perbarui alamat atau logo di satu templat, lupakan empat puluh templat lain, lalu entitas Anda saling bertentangan di seluruh situs. Panduan Ahrefs dan Schema App sama-sama menyoroti risiko “mengubah satu dan melupakan yang lain” ini.
  • Satu @id digunakan untuk dua entitas yang sebenarnya berbeda. Inilah kerusakan yang nyata: dua objek node berbagi pengenal, tetapi menjelaskan hal yang bertentangan—nama, logo, atau @type yang berbeda. Itu merupakan konflik semantik, bukan penggabungan yang aman. Gunakan @id berbeda untuk setiap entitas yang benar-benar terpisah.

Deklarasikan sekali dan rujuk di mana pun. Alasan pemeliharaan tetap berlaku, meskipun pengulangan entitas yang sama secara teknis tidak merusak graph seperti referensi yatim atau @id yang benar-benar bertentangan.

Pertanyaan yang belum terjawab: apakah @id diurai lintas halaman?

Inilah batas jujur yang membedakan jawaban nyata dari jawaban yang terdengar yakin tetapi keliru. Dokumentasi Google tidak pernah menyatakan secara eksplisit apakah referensi @id diurai lintas halaman. Contohnya, apakah Offer.seller pada halaman produk dapat menunjuk ke node Organization yang hanya dideklarasikan di beranda? Tidak ada dokumen Google Search Central yang menggunakan istilah “cross-page” atau “across pages” dalam kaitannya dengan @id.

Satu sinyal terdekat justru mengarah pada halaman yang mandiri. Untuk konten duplikat, Google merekomendasikan “placing the same structured data on all page duplicates, not just on the canonical page” (terjemahan) “menempatkan data terstruktur yang sama pada semua halaman duplikat, bukan hanya pada halaman canonical”. Ini menyiratkan bahwa data terstruktur dievaluasi per halaman, bukan diambil dari tempat lain. Saya juga tidak dapat memverifikasi pernyataan resmi dari perwakilan Google atau Bing bernama—Mueller, Illyes, atau Splitt—yang secara khusus menjawab pertanyaan @id lintas halaman. Bing memiliki validasi JSON-LD di Webmaster Tools, tetapi tidak menerbitkan panduan khusus @id atau @graph. Itu adalah celah dokumentasi yang nyata, bukan posisi yang akan saya karang untuk mereka.

Karena itu, per Juli 2026, perlakukan pernyataan “Google mengikuti tautan @id lintas halaman” sebagai inferensi industri, bukan perilaku yang dikonfirmasi. Pilihan aman—yang secara independen digunakan atau disarankan oleh Yoast, Momentic, dan Schema App—adalah: pertahankan nilai @id yang konsisten untuk entitas yang sama di mana pun, tetapi tetap keluarkan graph entitas lengkap pada setiap halaman yang memerlukannya. Jangan berasumsi Google akan mengambil entitas yang dirujuk dari URL lain. Pilihan produksi Yoast persis demikian: mereka mengeluarkan graph lengkap pada setiap halaman, bukan mengandalkan penguraian lintas halaman.

Cara memvalidasi nested schema

Gunakan dua alat:

  • Rich Results Test — dalam pengujian praktisi per Juli 2026, alat ini mengurai array @graph dan menyelesaikan referensi @id di dalam dokumen yang diuji. Jika entitas A merujuk B melalui @id dan B dideklarasikan dalam graph yang sama, keduanya tampil terhubung. Jika @id yang dirujuk tidak pernah dideklarasikan dalam markup yang diuji, alat ini tetap mengurai item yang dideklarasikan secara terpisah tanpa kesalahan, tetapi tidak dapat menampilkan hubungannya. Google tidak mendokumentasikan perilaku UI ini secara eksplisit, jadi perlakukan sebagai perilaku alat yang diamati dan dapat direproduksi, bukan spesifikasi resmi. Periksa kembali jika UI alat berubah. Inilah alasan referensi yatim dapat lolos: tidak ada kesalahan, hanya hubungan yang hilang.
  • Schema Markup Validator — validator kosakata milik schema.org, yang tidak terlalu terikat pada jenis rich result yang didukung Google.

Uji halaman hasil render, bukan hanya sumber templat. Jika JSON-LD disisipkan melalui JavaScript, pastikan markup benar-benar tersedia. Google mendokumentasikan pembacaan JSON-LD yang disisipkan secara dinamis oleh JavaScript, tetapi hal itu khusus untuk Google. Perilaku eksekusi JavaScript berbeda menurut crawler dan produk; tidak ada aturan umum bahwa setiap crawler AI merender JS dengan cara yang sama, atau merendernya sama sekali. Menyertakan JSON-LD dalam HTML awal lebih konservatif daripada mengasumsikan kode akan dieksekusi. Ini berkaitan dengan markup schema untuk AI.

Mitos yang perlu dihentikan

  • “@id harus berupa URL nyata, aktif, dan dapat diambil.” Tidak. Menurut konvensi, nilainya adalah URL canonical ditambah fragmen, tetapi fungsinya ialah identifikasi, bukan pengambilan. Fragmen tidak harus memiliki halaman tersendiri.
  • “@id yang sama pada halaman berbeda otomatis menggabungkan entitas itu di indeks Google, seperti tag canonical mengonsolidasikan halaman.” Tidak pernah dikonfirmasi dalam dokumentasi Google. @id yang konsisten adalah praktik rapi, bukan mekanisme konsolidasi lintas halaman yang terbukti.
  • “Anda wajib menggunakan @graph; blok skrip terpisah itu salah.” Keliru. Google memahami keduanya. @graph adalah pilihan pemeliharaan.
  • “Semakin banyak nesting, semakin baik pemahaman entitas.” Hanya jika entitas benar-benar berkaitan. Menaruh item yang tidak berkaitan—contoh Schema App adalah Event yang tidak berkaitan di bawah Recipe—tidak membantu dan dapat mengaburkan sinyal.
  • “Struktur @id atau @graph adalah faktor peringkat atau rich result.” Tidak. Nilainya adalah disambiguasi dan pengurangan duplikasi, sejalan dengan fakta bahwa schema bukan faktor peringkat.
  • “@id yang tidak dideklarasikan tidak berbahaya; mesin akan mengabaikannya.” Itulah kegagalan referensi yatim. Hubungan yang dimaksud tidak pernah terbentuk, sementara alat sering tidak menampilkan kesalahan sehingga masalah lolos tanpa disadari.

Posisi artikel ini dalam topik

Artikel ini adalah lapisan panduan praktis di bawah hub data terstruktur, sekaligus pendamping yang lebih mendalam bagi markup schema, yang memperkenalkan @id dan @graph, serta JSON-LD, yang membahas formatnya. Artikel ini memakai cara berpikir tentang pemahaman entitas yang sama seperti entitas dan markup schema untuk AI. Graph yang dibangun dengan baik adalah infrastruktur entitas, baik konsumennya Knowledge Graph Google maupun LLM. Seluruh subklaster ini berada dalam SEO on-page.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.