Penjelasan JSON-LD untuk situs web pribadi

 (hawksley.dev)
2 poin oleh GN⁺ 8 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Bahkan situs web pribadi pun dapat ditambahkan data terstruktur agar crawler lebih memahami hubungan antara halaman, orang, dan tulisan, serta meningkatkan kualitas pratinjau tautan dan visibilitas di hasil pencarian
  • Implementasinya dilakukan dengan menempatkan @context sebagai Schema.org di dalam <script type="application/ld+json"> pada <head>, lalu menyusun node seperti WebSite, Person, dan BlogPosting di @graph
  • Jika menggunakan @id yang sama, crawler web dapat menggabungkan properti node dari banyak halaman, tetapi scraper atau LLM yang hanya membaca satu halaman tidak akan melakukannya
  • Pada halaman root, letakkan WebSite, ProfilePage, dan Person sebagai dasar; pada halaman blog, proyek, atau daftar, tambahkan Blog, BlogPosting, SoftwareApplication, CollectionPage, dan BreadcrumbList sesuai karakter halamannya
  • Field sameAs pada Person, breadcrumb pada halaman, serta image, license, dan tanggal pada tulisan digunakan langsung untuk identifikasi orang, jalur hasil pencarian, pratinjau artikel, syarat penggunaan, dan penilaian kebaruan

Peran dan struktur dasar JSON-LD

  • JSON-LD adalah singkatan dari JSON Linked Data, yaitu format untuk menambahkan data terstruktur ke halaman web
  • Ini membantu crawler memahami struktur semantik sebuah situs, dan dapat berkontribusi pada pratinjau tautan yang lebih kaya serta potensi peningkatan peringkat pencarian
  • Saat menambahkannya ke halaman, sertakan skrip berikut di dalam bagian <head>
    • <script type="application/ld+json"> mendeklarasikan MIME type sebagai application/ld+json
    • Jika tipe ini ditentukan, mesin JavaScript browser tidak akan mengeksekusinya
    • Crawler khusus seperti Googlebot akan menemukan elemen tersebut dan mem-parsing isinya

@context, @graph, dan ID node

  • @context menentukan konteks yang diikuti data JSON-LD, dan crawler web menggunakan Schema.org sebagai standar
  • Schema.org mendefinisikan pasangan key-value yang valid untuk digunakan dalam JSON
  • Dokumen JSON-LD dapat dipandang sebagai graf berarah berlabel, dan datanya disimpan di bawah @graph
  • Graf dapat berisi banyak node, dan node-node tersebut terhubung dengan relasi berarah
  • Setiap node terdiri dari elemen berikut
    • @type: menunjukkan node tersebut apa. Contoh: WebSite, SoftwareApplication
    • @id: biasanya pengenal node dengan hash unik yang ditambahkan di akhir URL
    • Properti: pasangan key-value yang menunjukkan karakteristik node
  • Crawler web dapat menggabungkan properti node yang berbagi @id yang sama di beberapa halaman
  • Namun, scraper atau LLM yang hanya membaca satu halaman tidak menggabungkan properti, jadi perbedaan ini perlu diperhatikan saat memakai ulang JSON-LD di beberapa halaman
  • Untuk @id, disarankan menggunakan hash di belakang URL untuk mengidentifikasi node secara unik, seperti #website

Node untuk menjelaskan situs dan halaman

  • WebSite

    • WebSite menyimpan metadata situs dan memberi petunjuk kepada crawler tentang bagaimana situs sebaiknya ditampilkan
    • Pada halaman root, Anda dapat menempatkan versi lengkap yang memuat properti seperti url, name, alternateName, description, inLanguage, publisher, dan image
    • Tidak perlu memasukkan seluruh node WebSite di semua halaman
    • Halaman root domain sebaiknya ditulis lebih rinci, sedangkan halaman lain cukup memakai versi ringkas yang hanya berisi @type, @id, url, dan name
    • Versi ringkas memberi konteks yang dibutuhkan crawler yang hanya membaca satu halaman agar dapat mengenali nama situs dengan benar

  • WebPage

    • WebPage merepresentasikan halaman saat ini itu sendiri, yaitu halaman fisik HTML
    • Ini perlu dibedakan dari tipe konten seperti BlogPosting; WebPage menunjuk ke halaman yang memuat konten tersebut
    • Contoh properti mencakup url, isPartOf, name, inLanguage, dan breadcrumb
    • ProfilePage dan CollectionPage adalah subtype yang lebih spesifik dari WebPage
    • Subtype lain yang kurang umum dapat dilihat di definisi WebPage Schema.org

Identitas pribadi dan halaman profil

  • Person

    • Disarankan untuk menempatkan node Person di semua halaman situs web pribadi
    • Person menunjukkan siapa pemilik situs, dan digunakan sebagai bagian dari beberapa metrik kualitas konten Google
    • Crawler LLM juga semakin sering menggunakan informasi Person untuk menentukan siapa yang akan dikutip dalam jawaban
    • Berbeda dari WebSite, Person adalah konteks yang cukup penting untuk disertakan di semua halaman
    • Properti pentingnya adalah sebagai berikut
      • url: menunjuk ke halaman root untuk menambatkan node
      • name, givenName, familyName: menyatakan nama dengan jelas
      • image: jika memungkinkan, gunakan foto diri atau logo terkait untuk menautkan gambar resmi
      • sameAs: memberi tahu crawler tentang profil lain untuk membantu identifikasi orang
    • sameAs sangat berguna terutama untuk membedakan orang dengan nama yang sama, dan dipakai untuk membentuk representasi knowledge graph lintas halaman
    • Properti Person lainnya berguna untuk menambah detail tetapi tidak wajib, dan pengaruhnya kecil bila dikurangi

  • ProfilePage

    • ProfilePage merepresentasikan halaman tentang orang tertentu di dalam situs
    • Jika Anda memperkenalkan diri di beranda, tipe ini bisa dipakai di sana; jika ada halaman about terpisah, mungkin lebih tepat diletakkan di sana
    • Penting untuk menghubungkannya dengan node WebSite yang lebih luas melalui isPartOf
    • mainEntity memberi tahu crawler tentang siapa halaman tersebut
    • dateCreated dan dateModified berguna sebagai sinyal kebaruan bagi crawler, tetapi tidak perlu terlalu dikhawatirkan bila situs tidak dapat menyediakannya dengan mudah

Proyek dan penanda jalur

  • SoftwareApplication

    • Jika sebuah halaman memperkenalkan perangkat lunak, sebaiknya sertakan metadata perangkat lunak tersebut dengan node SoftwareApplication
    • Untuk tipe yang lebih spesifik, Anda bisa memakai MobileApplication, WebApplication, atau VideoGame
    • Properti url harus menunjuk ke lokasi distribusi proyek
    • Contohnya adalah halaman distribusi seperti crates.io
    • sameAs digunakan untuk halaman lain yang terkait dengan proyek, seperti repositori source code
    • Nilai yang valid untuk applicationCategory dapat dilihat di definisi SoftwareApplication Google
    • Bahkan untuk proyek FOSS, offers tetap harus disertakan dan harga diatur ke 0

  • BreadcrumbList

    • BreadcrumbList sangat berguna secara luas pada semua halaman selain halaman root
    • Ini merepresentasikan jalur kategori halaman, dan tidak harus selalu sama dengan jalur URL sebenarnya
    • Ini dapat digunakan untuk mengontrol bagaimana mesin pencari menampilkan jalur halaman tertentu
    • Jika jalur situs sudah pendek, manfaat node ini kecil sehingga boleh dihilangkan
    • Pada situs dengan jalur yang panjang, BreadcrumbList berguna untuk memendekkan jalur pada hasil pencarian

Halaman daftar, blog, dan artikel

  • CollectionPage

    • CollectionPage adalah subtype WebPage yang terutama dipakai untuk halaman yang berisi daftar
    • Contohnya adalah halaman /elsewhere/ yang mengumpulkan profil lain, atau halaman /blog/ yang berisi daftar tulisan blog
    • Dengan about, Anda dapat menghubungkan node Person yang relevan
    • breadcrumb harus selalu dihubungkan ke BreadcrumbList yang benar untuk halaman saat ini

  • Blog

    • Node Blog ditambahkan ke indeks blog atau halaman utama blog
    • Ini berfungsi sebagai node perantara yang menghubungkan WebSite dengan masing-masing BlogPosting
    • dateModified berguna sebagai sinyal kebaruan, tetapi boleh dihilangkan jika tidak mudah disediakan
    • license memberi tahu crawler dalam kondisi apa tulisan boleh digunakan
    • Pada situs web pribadi, publisher boleh diatur ke Person alih-alih Organization
    • Dokumentasi Google, tidak seperti sebelumnya, kini juga mengizinkan Person secara valid, dan ini bisa lebih akurat untuk situs web pribadi

  • BlogPosting

    • BlogPosting harus disertakan pada semua tulisan blog yang dipublikasikan
    • Ini memberikan informasi tambahan agar crawler dapat merepresentasikan tulisan dengan lebih akurat
    • Ini dapat digunakan untuk penempatan yang lebih tepat dan detail yang lebih kaya di hasil pencarian
    • Pada situs pribadi, author dan publisher boleh menunjuk ke node Person yang sama
    • Properti image sebaiknya diselaraskan dengan gambar OG yang sudah dipakai untuk pratinjau tautan tulisan
    • license dapat digunakan untuk menunjukkan syarat penggunaan tulisan

Implementasi minimum dan kriteria penerapan

  • JSON-LD yang dibutuhkan untuk situs pribadi dapat disusun secara selektif sesuai karakter halaman
  • Bahkan untuk situs statis tanpa tahap build, Anda tetap bisa memperoleh manfaat dengan menambahkan setidaknya node berikut pada halaman root
    • WebSite
    • ProfilePage
    • Person
  • Jika memiliki blog, tambahkan Blog dan BlogPosting, dan untuk halaman daftar tulisan atau daftar profil eksternal, Anda dapat memakai CollectionPage
  • Untuk halaman pengenalan proyek, pertimbangkan SoftwareApplication, dan untuk halaman selain root, Anda dapat mempertimbangkan BreadcrumbList

Bacaan terkait

1 komentar

 
GN⁺ 8 jam lalu
Komentar Hacker News

  • Meminjam analogi, ini terasa seperti mengulang perang yang lalu
    Dari sudut pandang situs WWW milik saya, Google sekarang menampilkan ringkasan buatan LLM yang panjang dan bercampur kesalahan di bagian atas, alih-alih mengirim orang ke tulisan asli saya
    Mendapatkan nama tampilan yang cantik alih-alih breadcrumb atau domain tidak menyelesaikan kenyataan bahwa Google memprioritaskan rendah hal-hal itu, entah mereka mempercantiknya atau tidak
    Jadinya kita menghabiskan terlalu banyak usaha untuk sesuatu yang tidak akan pernah dilihat oleh orang yang datang langsung ke situs asli, dan bagi pengguna Google pun terdorong ke bawah versi Google yang sudah di-LLM-kan sehingga sulit ditemukan

    • Jika ingin dunia di mana data seperti ini bermakna, kita harus menabur benihnya terlebih dahulu
      Meski Google tidak memakainya, jika seluruh internet menerapkan metadata seperti ini, itu akan menjadi tanah yang subur agar para pesaing yang bukan mengandalkan scraping LLM bisa menawarkan alternatif
      Menyerah pada Google hanya akan memperkuat dominasinya, menaikkan hambatan masuk bagi pesaing, dan mendorong mereka ikut memakai teknik yang sama
    • Memang begitu. Perusahaan kami sekarang juga muncul seperti ini di pencarian Google:
      Perusahaan TI berbasis $STATE yang mengkhususkan diri dalam membangun workflow AI praktis dan solusi manajemen informasi untuk perusahaan-perusahaan di Midwest. Beroperasi dengan model kontrak fixed-price yang lincah, dengan fokus memberikan hasil konkret sambil menghindari pembengkakan ala enterprise.
      Saya bahkan tidak tahu kalau sekarang kami menyediakan workflow AI praktis
      Lalu Google juga mencampur nama pesaing yang mirip tapi jelas berbeda, dan menampilkan saya sebagai eksekutif. Satu-satunya sisi baiknya, pesaing itu menyembunyikan info kontak mereka di balik formulir “jadwalkan konsultasi”, jadi yang tampil hanya kontak kami
    • Sekarang saya juga tidak lagi mengizinkan Google merayapi dan mengindeks situs saya
    • Sekarang Google juga termasuk pihak yang kalau bot-nya masuk ke situs akan mendapat 10GB zipbomb
      Saat ini mereka tidak menambah nilai apa pun, hanya menambah masalah
    • Betul. Selama bertahun-tahun saya menjejalkan banyak sekali tag dan atribut microdata ke situs web dengan harapan mendapat trafik
      Hasil akhirnya cuma melatih AI Google agar orang tidak perlu meninggalkan Google

  • Jika Anda cenderung pragmatis, saya sarankan membaca dokumentasi Google untuk situs web tentang JSON-LD
    https://developers.google.com/search/docs/appearance/structu...
    Anda juga akan melihat bahwa banyak informasinya hanya relevan untuk sebagian situs. Rotten Tomatoes bisa menerbitkan rating kritikus film dengan JSON-LD, tetapi meskipun saya menulis ulasan film, itu tidak terlalu relevan bagi saya
    JSON-LD itu mudah dan memang benar-benar dipakai mesin pencari, jadi cukup bagus. Memang bisa menduplikasi informasi yang ada di halaman web, tetapi impian untuk memberi anotasi sempurna sehingga informasi hanya muncul tepat satu kali dalam dokumen terasa seperti idealisasi ala sapi bulat dan tali tanpa massa
    Membuat halaman web memang butuh usaha manusia, dan tidak masalah jika hasil akhirnya mengandung sedikit duplikasi

    • Anda bisa memakai JSON-LD untuk ulasan film meskipun situsnya bukan situs besar
      Di situs saya, saya memakainya untuk ulasan buku, game, dan film, dan tampaknya di sebagian besar mesin pencari informasi seperti rating bintang ditampilkan
    • 403. That’s an error.
      Katanya klien tidak punya izin untuk mengambil URL /search/docs/appearance/structured-data/intro-structured-data di server ini
    • Tapi kalau datanya diduplikasi, bukankah penggunaan air akan meningkat. /s

  • Untuk pratinjau tautan yang kaya, OpenGraph jauh lebih sering didukung daripada JSON-LD
    Jika tujuannya optimasi mesin pencari, jenis JSON-LD yang didukung mesin pencari sangat spesifik dan terbatas. Jauh lebih baik melihat dokumentasi mesin pencari yang dituju, yaitu Google[1] atau Bing[2], lalu mengikutinya apa adanya; selain itu nyaris buang-buang waktu
    Di luar mesin pencari, kalau tidak ada tujuan khusus, JSON-LD umumnya tidak terlalu berguna. Jika ada kebutuhan spesifik yang memang memerlukan JSON-LD, masukkan data yang akan berguna untuk itu; selain itu, memasukkan data lain rasanya seperti berteriak ke ruang hampa
    IndieWeb[3] memang menggunakan data terstruktur, tetapi menganggap JSON-LD sebagai pelanggaran DRY dan sebagai gantinya memakai Microformats[4]
    0: https://ogp.me
    1: https://developers.google.com/search/docs/appearance/structu...
    2: https://www.bing.com/webmasters/help/marking-up-your-site-wi...
    3: https://indieweb.org/
    4: https://microformats.org/

  • Yang sebenarnya ingin diterapkan di semua situs web adalah data terstruktur yang menggunakan kosakata Schema.org
    JSON-LD adalah salah satu caranya, dan ada juga RDFa serta Microdata
    Saat pertama kali mempelajarinya saya merujuk ke tulisan ini, dan cukup layak direkomendasikan: https://neilpatel.com/blog/get-started-using-schema/
    Data apa yang bisa ditambahkan dapat dilihat dengan alat ini: https://technicalseo.com/tools/schema-markup-generator/
    Daftar lengkapnya bisa dilihat di situs schema.org: https://schema.org/docs/schemas.html

  • Beberapa tahun lalu saya mengetahui bahwa fitur email canggih seperti tiket pesawat yang disematkan atau info pelacakan pengiriman yang ditampilkan semuanya diimplementasikan dengan JSON-LD di dalam email
    Tapi setahu saya hanya Gmail yang mendukungnya
    Info tambahan: https://www.emailonacid.com/blog/article/email-development/s...

    • Outlook dan iCloud juga mendukung sebagian fitur seperti tiket atau reservasi

  • Saya penasaran apakah atribut seperti ini benar-benar membantu visibilitas di pencarian, atau justru memudahkan mesin pencari menahan pengguna tetap di halaman hasil pencarian

    • Setelah menambahkan JSON-LD, Google mulai menampilkan tautan bawahan yang masuk ke dalam situs saya. Itu lumayan bagus
    • Untuk situs bisnis, JSON-LD bisa dipakai untuk memasok data ke platform peta
      Seperti alamat, jam operasional, nomor telepon, dan menu

  • Kita sudah punya HTML semantik, tetapi anehnya kita tetap harus mengekspresikan makna situs web sekali lagi dengan JSON kustom yang ganjil di dalam tag script, yang bahkan tidak diproses browser

    • Saya pernah memakai JSON-LD di situs saya, dan menurut saya itu memenuhi kebutuhan yang terpisah dari HTML semantik
      HTML semantik menentukan hal-hal yang diproses browser seperti judul dan heading. Data JSON-LD adalah metadata seperti tanggal dibuat, tanggal diubah, tag, dan penulis
      Hal-hal ini juga bisa diekspresikan sebagai microdata di dalam HTML, tetapi JSON-LD lebih mudah sehingga saya berhenti memakai microdata
      JSON-LD diisi dari data yang sama yang dipakai untuk membangun situs, dan dengan metadata ini saya juga membuat halaman indeks seperti daftar tulisan blog tahun 2024 atau semua tulisan tentang topik X. Konsumen utama JSON-LD adalah mesin pencari
      Kalau ingin lebih kesal, pikirkan saja bahwa kita juga menyisipkan metadata OpenGraph di halaman yang sama. Artinya ada dua format metadata berbeda di halaman yang sama
    • Ada juga Microdata, dan kalau saya tidak salah, itu mendukung kosakata yang sama seperti JSON-LD. schema.org adalah referensi yang bagus
      Hanya saja JSON-LD sudah lama menjadi default, mirip seperti bagaimana kita sebagian besar meninggalkan REST dan beralih ke RPC. Saya juga kurang tahu apakah parser penting saat ini masih mendukung microdata sepenuhnya, dan terutama saat membuat situs klien seperti situs e-commerce yang ingin mendapat visibilitas di pencarian Google, saya pada dasarnya selalu memakai LD
      Dibandingkan dengan HTML semantik, ada hal lain yang perlu diperhatikan. HTML semantik membantu mendefinisikan struktur markup, tetapi tidak sampai mengekspresikan konteks dunia nyata seperti “ini adalah produk yang dijual” atau “ini adalah jadwal kereta”
    • Sepertinya saya belum cukup memahami tulisannya
      Tanpa JSON-LD dan tag script pun, kita bisa memakai ontologi seperti Schema.org/FOAF/WikiData di dalam HTML
    • Menurut saya dunia yang ideal adalah server dan browser bisa melakukan negosiasi konten, lalu browser terlebih dahulu hanya meminta JSON-LD dari situs web dan kemudian memakai format renderer internalnya sendiri
    • HTML semantik tidak mencakup cakupan yang ditangani JSON-LD dan berbagai microformat lainnya
      Bahkan hanya dari yang disebut di tulisan itu saja, orang bisa bertanya elemen semantik apa yang mewakili orang, daftar breadcrumb, aplikasi perangkat lunak, blog, dan posting blog
      HTML semantik dimaksudkan untuk membantu orang yang memakai screen reader menavigasi elemen umum seperti “navigasi” atau “artikel”

  • Bukankah ini cuma OpenGraph yang ditulis dalam JSON? Apa kelebihannya?

  • Sejak 2024, traffic ke halaman pemasaran berbasis konten kami turun sekitar 85%
    Yang sulit dipahami adalah, jika halaman hasil pencarian tanpa klik makin banyak, apakah Google juga tidak terkena dampak besar?
    Pendapatan iklan di halaman hasil pencarian yang berbasis klik seharusnya juga turun sangat tajam dengan cara yang serupa, tetapi saya belum menemukan angka publik yang bisa membantah atau mengonfirmasi hipotesis ini

  • Ada keseimbangan yang halus di mana pada titik tertentu simbiosis berubah menjadi eksploitasi
    Hubungan di mana situs web ingin mendapat eksposur dengan bantuan mesin pencari pada dasarnya cukup saling menguntungkan
    Tetapi sekarang arahnya sudah sepenuhnya menuju situasi di mana pemilik situs web tidak mendapat apa-apa dari kerja keras yang mereka buat