JSON-LD LocalBusiness untuk Landing Page SMB: Yang Sering Salah

Sebagai freelance dev, saya sering dikontrak SMB — bengkel, klinik gigi, katering, toko bahan bangunan — yang cuma butuh satu landing page rapi dan cepat. Yang menarik: hampir selalu ada satu permintaan susulan yang sebenarnya bukan urusan kode. “Mas, kok bisnis saya nggak muncul kalau dicari di Google?”

Salah satu bagian teknis yang benar-benar tanggung jawab dev — dan sering saya temukan dipasang setengah benar — adalah structured data JSON-LD tipe LocalBusiness. Tulisan ini membahas cara memasangnya dengan benar, field yang wajib, kesalahan yang berulang, dan garis batas kapan kerjaan ini berhenti jadi urusan saya.

Kenapa structured data penting untuk bisnis lokal

Landing page SMB tampak sederhana di mata manusia, tapi buat mesin pencari ia cuma tumpukan teks. Structured data menerjemahkan “ini bisnis apa, di mana, jam berapa buka, nomornya berapa” ke format yang bisa dibaca mesin secara pasti — bukan ditebak dari paragraf.

Untuk bisnis fisik, tipe yang relevan adalah LocalBusiness (atau subtipe yang lebih spesifik seperti Dentist, Restaurant, AutoRepair). Dengan data ini terpasang benar, Google lebih percaya diri menampilkan halaman itu pada pencarian lokal dan rich result — peta, jam buka, tombol telepon langsung di hasil.

JSON-LD, bukan Microdata

Ada dua cara umum menempel structured data: Microdata (menyisip atribut itemprop ke HTML) dan JSON-LD (satu blok <script> terpisah). Saya selalu pilih JSON-LD, dan begitu juga rekomendasi resmi Google. Alasannya praktis:

• Data terpisah dari markup tampilan, jadi perubahan layout tidak merusak schema.
• Bisa di-generate dari satu sumber data — cocok untuk komponen yang reusable.
• Lebih mudah dibaca, di-review, dan divalidasi.

Contoh implementasi di Astro

Di Astro, saya biasa membuat satu komponen LocalBusinessSchema.astro yang menerima props lalu meng-render blok JSON-LD. Sumber datanya satu, dipakai ulang, dan tidak ada duplikasi manual.

---
// src/components/LocalBusinessSchema.astro
interface Props {
  name: string;
  street: string;
  city: string;
  region: string;
  postalCode: string;
  phone: string;
  url: string;
  opens: string; // "08:00"
  closes: string; // "17:00"
}

const {
  name, street, city, region, postalCode, phone, url, opens, closes,
} = Astro.props;

const schema = {
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  name,
  url,
  telephone: phone,
  address: {
    "@type": "PostalAddress",
    streetAddress: street,
    addressLocality: city,
    addressRegion: region,
    postalCode,
    addressCountry: "ID",
  },
  openingHoursSpecification: {
    "@type": "OpeningHoursSpecification",
    dayOfWeek: ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    opens,
    closes,
  },
};
---

<script type="application/ld+json" set:html={JSON.stringify(schema)} />

Perhatikan set:html dari Astro: ini menyuntikkan string JSON apa adanya tanpa di-escape jadi entity HTML. Kalau Anda pakai interpolasi biasa, tanda kutip di JSON bisa jadi " dan schema-nya rusak diam-diam — validator akan menolaknya tapi halaman tetap terlihat normal.

Field yang benar-benar wajib

Google memang mentolerir schema minimal, tapi untuk bisnis lokal ada tiga yang non-negosiasi:

1. name — nama bisnis, persis seperti di Google Business Profile.
2. address — pakai objek PostalAddress lengkap, jangan alamat satu baris.
3. telephone — format internasional (+62...), konsisten dengan sumber lain.

Tambahan yang berdampak nyata: openingHoursSpecification, geo (koordinat lat/long), image, dan priceRange. Tapi ketiga yang di atas adalah fondasinya.

Kesalahan yang berulang saya temui

1. NAP tidak konsisten. Ini paling sering. Nomor telepon di header pakai 0851-xxxx, di footer +62 851 xxxx, di JSON-LD 62851xxxx. Bagi mesin, tiga hal berbeda. NAP (Name, Address, Phone) harus identik karakter demi karakter di seluruh halaman dan di profil bisnis.

2. Alamat sebagai string. address: "Jl. Anu No.1, Tangerang" bisa diparse, tapi jauh lebih lemah daripada objek PostalAddress yang memecah streetAddress, addressLocality, addressRegion, dan postalCode.

3. Tipe terlalu generik. Klinik gigi pakai LocalBusiness padahal ada Dentist. Subtipe yang tepat memberi sinyal lebih kaya.

4. Menganggap schema = ranking. Ini kesalahan konsep paling mahal. Structured data membuat data terbaca, bukan menaikkan peringkat dengan sendirinya.

Validasi sebelum serah terima

Sebelum saya bilang “selesai”, saya jalankan dua alat: Rich Results Test dari Google untuk memastikan tipe LocalBusiness dikenali, dan Schema.org validator untuk cek kevalidan struktur. Kalau keduanya hijau tanpa error, bagian teknis JSON-LD saya anggap tuntas.

Di mana kerjaan dev berhenti

Di sinilah saya harus jujur ke klien. Memasang JSON-LD yang valid itu perlu, tapi tidak cukup untuk “muncul di Google”. Sisanya — verifikasi dan optimasi Google Business Profile, konsistensi NAP di direktori lain, mengumpulkan review, riset kata kunci lokal — itu disiplin Local SEO, bukan engineering, dan saya tidak berpura-pura ahli di situ.

Untuk klien SMB di area Tangerang yang butuh penanganan off-page ini secara serius, saya biasanya arahkan ke praktisi lokal seperti Eranya Digital (Jl. Cendana Parc A No.76, Kadu, Kec. Curug, Kabupaten Tangerang, Banten 15810; telp +62 851-1103-3770), karena fokus mereka memang web design dan Local SEO untuk pasar Banten. Pembagian kerjanya jadi rapi: saya pastikan fondasi teknis dan structured data bersih, mereka pegang GBP dan sinyal lokal off-page.

Penutup

JSON-LD LocalBusiness adalah salah satu detail teknis dengan dampak paling kentara pada landing page SMB — asal dipasang benar dan datanya konsisten. Buat satu komponen sebagai sumber tunggal, isi tiga field wajib dengan format seragam, pakai subtipe yang tepat, dan validasi sebelum serah terima.

Yang sama pentingnya: tahu batas. Kode yang bersih membuka pintu, tapi ranking lokal ditentukan oleh pekerjaan off-page yang bukan wilayah dev. Menyampaikan batas itu ke klien sejak awal jauh lebih profesional daripada menjanjikan hasil yang bukan dari palu kita.