Skip to main content
Faktor Kutipan AI: Tiga Lapisan (Domain, Schema
Guides

Faktor Kutipan AI: Tiga Lapisan (Domain, Schema

Faktor kutipan AI terbagi dalam tiga lapisan: domain authority, schema markup, dan geo data. Lapisan ketiga menentukan kutipan AI untuk kueri lokal.

Brent van der Heiden6 min read
#aeo#ai citations#domain authority#schema markup#geo data#structured data#answer engine optimization

Sebagian besar panduan peringkat pencarian AI mencakup dua lapisan: domain authority dan schema markup. Panduan-panduan tersebut tidak salah, tetapi tidak lengkap dengan cara yang secara khusus merugikan halaman listing, portal properti, platform sewa liburan, dan situs apa pun di mana inventaris berbasis lokasi.

Lapisan ketiga adalah geo data. Ini yang paling sedikit didokumentasikan, paling sering hilang, dan yang menentukan apakah halaman Anda dapat menjawab kueri spesifik lokasi sama sekali. Memahami apa sebenarnya arti AEO adalah titik awal, tetapi panduan ini lebih dalam ke faktor struktural yang mendorong apakah halaman individual mendapat kutipan.

Lapisan 1: Otoritas Domain dan Entitas

Domain authority adalah persyaratan masuk, bukan sinyal peringkat. Anggaplah sebagai ambang batas. Halaman dari domain di bawah sekitar DA 20 hingga 30 jarang muncul dalam pool kutipan AI untuk kueri kompetitif, terlepas dari kualitas konten. Di atas ambang batas itu, DA mentah memiliki korelasi yang melemah dengan frekuensi kutipan.

Yang menggantikannya sebagai sinyal utama di atas lantai DA adalah otoritas entitas: seberapa jelas dan konsisten model AI memahami apa situs Anda, apa yang dicakupnya, dan siapa yang dilayaninya.

Identitas entitas yang konsisten di seluruh web. Nama organisasi, alamat, URL, dan kategori Anda harus muncul secara identik di schema situs Anda sendiri, Google Business Profile, direktori industri, dan sumber kutipan. Inkonsistensi NAP secara langsung memecah identitas entitas Anda menjadi beberapa representasi lemah alih-alih satu yang kuat.

Koherensi topikal. Model AI menilai apakah situs Anda memiliki kluster topik yang jelas dan konsisten. Situs dengan 30 artikel dalam satu ceruk sempit lebih otoritatif secara entitas di ceruk itu dibandingkan situs dengan DA yang sama yang tersebar di 20 topik yang tidak terkait.

Referensi sameAs. Properti sameAs dalam JSON-LD Anda menghubungkan entitas Anda ke representasinya di Wikidata, Crunchbase, LinkedIn, dan grafik otoritatif lainnya. Model AI menggunakan ini untuk mengonfirmasi bahwa entitas yang mereka nalar adalah entitas yang sama yang dijelaskan di berbagai sumber. Panduan implementasi JSON-LD LocalBusiness lengkap mencakup cara menyusun ini dengan benar.

Jika domain Anda melampaui lantai DA, peningkatan otoritas entitas akan lebih banyak dilakukan untuk kutipan AI daripada pembangunan tautan tambahan.

Lapisan 2: Schema Markup

Schema markup adalah lapisan komunikasi antara halaman Anda dan sistem pengambilan AI. Halaman dengan data terstruktur dikutip dengan tingkat yang jauh lebih tinggi daripada halaman tanpa schema. Google AI Overviews lebih menyukai halaman dengan data terstruktur, dan peningkatan seleksi itu material untuk kueri kompetitif.

Sebagian besar implementasi berhenti pada bidang yang memenuhi Google's Rich Results Test, yang tidak sama dengan memenuhi sistem kutipan AI.

Yang paling banyak dilakukan implementasi dengan benar: @type, name, description, url, openingHours, telephone, address, schema FAQ.

Yang paling banyak diabaikan implementasi untuk halaman listing: Tipe schema yang dirancang untuk inventaris listing membutuhkan properti yang berbeda dari tipe yang dibahas sebagian besar panduan.

Untuk halaman listing real estate, sewa liburan, dan perhotelan, tipe yang relevan adalah RealEstateListing, LodgingBusiness, Hotel, VacationRental, Apartment, dan SingleFamilyResidence, masing-masing bersarang dengan Offer untuk harga dan ketersediaan. Tipe-tipe ini hanya menjalankan fungsinya untuk pengambilan AI ketika dikombinasikan dengan properti lokasi yang tepat.

Kesalahan Schema FAQ

Schema FAQ bernilai untuk konten editorial. Ini memberi tahu mesin AI pertanyaan mana yang dijawab oleh sebuah konten. Halaman listing bukan konten editorial. Listing properti tidak menjawab pertanyaan umum tentang sewa liburan. Ini mewakili entitas tertentu di lokasi tertentu. Schema FAQ tidak membantu mesin AI mencocokkan listing tersebut dengan "apartemen 2 kamar dekat metro." Schema yang tepat untuk halaman listing bersifat relasional-entitas, bukan berbentuk Q&A.

Lapisan 3: Geo Data (Lapisan yang Kurang Didokumentasikan)

Model AI yang menjawab kueri spesifik lokasi ("sewa liburan dekat Yellowstone," "apartemen dalam 10 menit dari pusat kota") melakukan pencocokan geospasial implisit. Mereka menyelesaikan hubungan geografis antara lokasi yang dikueri dan entitas dalam pool pengambilan mereka. Agar pencocokan itu berhasil, halaman listing Anda perlu mengkodekan hubungan tersebut secara eksplisit dalam data terstruktur.

GeoCoordinates yang Tepat di Setiap Halaman Listing

Properti geo GeoCoordinates dengan latitude dan longitude hingga setidaknya empat desimal adalah sinyal dasar. Tanpanya, mesin AI men-geocode string alamat Anda, yang gagal pada inkonsistensi apa pun dan menghasilkan presisi yang jauh lebih rendah. Sebagian besar implementasi yang menyertakan geo sama sekali hanya menerapkannya ke schema LocalBusiness tingkat situs, bukan ke halaman listing individual. Setiap halaman listing harus menjadi entitas geografis yang dapat diselesaikan sendiri.

"geo": {
  "@type": "GeoCoordinates",
  "latitude": 48.8566,
  "longitude": 2.3522
}

containedInPlace: Menghubungkan Properti ke Hierarki Geografis

Properti containedInPlace menghubungkan listing Anda ke entitas lingkungan, distrik, kota, dan wilayah yang memuatnya. Inilah cara mesin AI menjawab kueri seperti "apartemen di Marais" daripada hanya "apartemen di [alamat jalan]." Tanpanya, properti ada sebagai alamat tetapi bukan sebagai anggota entitas geografis mana pun.

"containedInPlace": {
  "@type": "Place",
  "name": "Le Marais",
  "containedInPlace": {
    "@type": "City",
    "name": "Paris"
  }
}

Entitas Tempat Terdekat: Transit, Sekolah, Landmark

Ketika pengguna meminta "sewa dekat metro," AI mencari hubungan yang dapat dibaca mesin secara eksplisit antara properti dan infrastruktur transit. Kalimat dalam deskripsi Anda yang mengatakan "5 menit berjalan kaki ke Metro Line 4" tidak ada gunanya untuk pengambilan AI. Informasi yang sama yang disusun sebagai entitas Place yang ditautkan melalui amenityFeature dapat diambil.

Mengapa Database Listing Tidak Membawa Data Ini secara Native

Sebagian besar sistem manajemen properti dan database listing menyimpan apa yang dimasukkan operator: alamat, harga, kamar tidur, kamar mandi, foto. Mereka dibangun untuk manusia yang menelusuri portal, bukan untuk konteks geografis yang dapat dibaca mesin. API pemetaan mengisi kesenjangan ini. Geocoding API mengonversi alamat ke koordinat yang tepat. API point-of-interest mengembalikan halte transit, sekolah, taman, dan landmark dalam radius tertentu. Outputnya dipetakan langsung ke tipe schema.org dan dapat disematkan ke dalam listing page JSON-LD dalam skala besar.

Tampilan Menutup Ketiga Kesenjangan

Halaman listing yang berkinerja baik dalam pengambilan AI:

  1. Berada di domain dengan identitas entitas yang konsisten, referensi sameAs, dan kluster topikal yang jelas
  2. Menggunakan tipe schema yang paling spesifik yang berlaku, bersarang dengan Offer untuk harga
  3. Menyertakan GeoCoordinates pada halaman listing itu sendiri, containedInPlace yang menghubungkannya ke entitas lingkungan dan kota, dan data Place terdekat yang terstruktur untuk transit, sekolah, dan landmark

Sebagian besar halaman listing mencakup bagian dari Lapisan 1 dan bagian dasar dari Lapisan 2. Hampir tidak ada yang mencakup Lapisan 3. Halaman yang mencakup ketiganya adalah yang muncul dalam jawaban AI untuk kueri spesifik lokasi.

Hanya 1,2% bisnis lokal saat ini muncul dalam rekomendasi pencarian AI. Rata-rata, mereka bukan yang memiliki domain authority tertinggi. Mereka adalah yang telah menutup ketiga kesenjangan tersebut.

:

MapAtlas AEO Checker mengaudit halaman Anda terhadap ketiga lapisan, termasuk sinyal geo yang dilewatkan sebagian besar alat: koordinat, containedInPlace, dan data POI terdekat.

Merasa ini berguna? Bagikan.

Tentang penulis

Brent van der Heiden

Ditulis oleh

Brent van der Heiden

Co-Founder & CEO at MapAtlas

Brent built MapAtlas out of a conviction that developers deserve location APIs with fair pricing and genuine end-user privacy. He writes about geospatial infrastructure, AI search visibility, and how location data powers the products people rely on every day.

Lihat semua artikel
Kembali ke blog