Schema Markup Kurulumu: Adım Adım Rehber
Schema sıralama kolu değil, makineye okutulan bir bilgi katmanı. Yerel işletmede en çok işe yarayan tip ve doğru kurulumu.
Schema markup — Türkçesiyle yapılandırılmış veri — sayfanızdaki bilgiyi makinenin kesin olarak okuyabileceği bir biçimde tekrar yazmak demek. İnsan "Pazar günü kapalıyız" cümlesini anlıyor; makine için bunu ayrıca `openingHours` alanına yazmak gerekiyor.
Beklentiyi baştan doğru kurmak gerekiyor: schema bir sıralama kolu değil. Google'ın kendi temsilcileri yapılandırılmış verinin çok hafif bir sinyal olduğunu ifade etti; işi sıralamayı yükseltmek değil, içeriğin ne olduğunu netleştirmek ve bazı durumlarda zengin sonuç uygunluğu sağlamak.
Yerel işletmede asıl görünürlük profil tarafında oluşuyor. Schema, siteyi profili destekleyen bir katman hâline getiriyor: Google Business Profile nedir.
Hangi tip: LocalBusiness ve alt tipleri Yerel işletme için temel tip LocalBusiness. Ama daha özgül bir alt tip varsa onu kullanmak daha doğru: restoran için `Restaurant`, diş kliniği için `Dentist`, kuaför için `HairSalon`, otel için `Hotel`, oto servis için `AutoRepair`.
Mantık kategori seçimindeki mantıkla aynı: en dar doğru olan kazanıyor. Genel tip kullanmak yanlış değil ama özgül tip, sayfanın ne olduğu konusunda daha az belirsizlik bırakıyor. Aynı yaklaşım profildeki kategori tarafında da geçerli: birincil kategori nasıl seçilir.
Birden çok şube varsa her şube sayfası kendi schema bloğunu taşıyor — tek bir sayfada beş adres listelemek yerine: çoklu şube yönetimi.
Hangi alanlar konur Zorunlu olanlar az, işe yarayanlar biraz daha fazla.
Olması şart: `name` (işletme adı), `address` (açık adres, ülke ve posta kodu dahil).
Olması gereken: `telephone`, `url`, `openingHoursSpecification` (gün ve saat aralıkları), `geo` (enlem-boylam), `image` (gerçek işletme görseli), `priceRange`.
Duruma göre: `sameAs` (profil ve sosyal hesap adresleri), `hasMap`, `areaServed` (hizmet bölgesiyle çalışıyorsanız), `department` (aynı adreste birden çok birim varsa).
Bir kural bütün alanların üstünde: schema'daki bilgi profildeki ve sitedeki bilgiyle birebir aynı olmalı. Çelişen adres ya da telefon, güven sinyalini zayıflatıyor ve schema'nın var olma sebebini ortadan kaldırıyor: NAP tutarlılığı.
JSON-LD: nereye ve nasıl Google'ın önerdiği biçim JSON-LD ve sayfanın `<head>` ya da `<body>` bölümüne `<script type="application/ld+json">` etiketiyle konuyor. Mikrodata ile HTML'in içine gömmek de mümkün ama JSON-LD hem daha okunur hem bakımı kolay: veri tek blokta duruyor, tasarım değişikliği onu bozmuyor.
Teknik bir uyarı: Googlebot'un JSON çıkarımı sıkılaştı. Standart dışı biçimlendirme — özellikle çift kaçırılmış HTML metni — artık otomatik düzeltilmiyor. Yani şablon motorunuz JSON içine kaçış karakteri basıyorsa blok sessizce geçersiz olabiliyor. Bu, elle yazılmış schema'da değil çoğunlukla dinamik üretilen schema'da çıkan bir hata.
Bir başka sık hata: schema'yı sayfada olmayan bilgiyle doldurmak. Yapılandırılmış veri, sayfada görünen içeriği tekrar etmeli; sayfada yazmayan bir çalışma saatini schema'ya yazmak politika dışı.
Yorum ve puan işaretlemesi: en yanlış bilinen konu Sitesine kendi hakkındaki yorumları koyup yıldızlı zengin sonuç almayı ummak, yerel SEO'nun en yaygın yanlışlarından biri. Google'ın yönergesi bu konuda net: işletmenin kendisi hakkında kendi sitesinde topladığı yorumlar bu amaçla kullanılamıyor. Yani "kendi kendine hizmet eden" değerlendirme işaretlemesi zengin sonuç üretmiyor.
Bunun pratik sonucu şu: yıldızlı görünürlük peşindeyseniz doğru yer siteniz değil profiliniz. Yorumlar orada birikiyor ve arama sonuçlarında orada görünüyor: yorumları artırma stratejileri.
Değişen zengin sonuçlar: beklentiyi güncel tutmak Zengin sonuç türleri sabit değil; Google zaman içinde bazılarını kaldırıyor ya da daraltıyor.
HowTo işaretlemesi için destek kaldırıldı — yani adım adım rehber şeması artık zengin sonuç üretmiyor.
FAQ işaretlemesinin görünürlüğü de zaman içinde daraldı. Ayrıca eskiden beri geçerli bir koşul var: schema'daki soru ve cevapların sayfada görünür olması gerekiyor; yalnız kodda duran FAQ bloğu uygun sayılmıyor.
Buradan çıkan davranış kuralı: schema'yı zengin sonuç garantisi olarak planlamamak. Bugün çalışan bir tür yarın daralabiliyor; kalıcı olan şey bilginin doğru ve tutarlı olması.
Eklenti mi elle mi Çoğu yerel işletmenin sitesi bir içerik yönetim sistemi üzerinde ve schema oraya iki yolla girebiliyor.
Eklenti ya da tema özelliği. Hızlı yol ve çoğu durumda yeterli. Riski şu: eklentiler sık sık birden çok schema bloğu üretiyor — tema bir tane, SEO eklentisi bir tane, sayfa oluşturucu bir tane. Aynı sayfada çelişen üç LocalBusiness bloğu, hiç olmamasından kötü çünkü hangisinin doğru olduğu belirsiz.
Kontrol yolu basit: sayfanın kaynağında `application/ld+json` aramak ve kaç blok çıktığını saymak. Birden fazla varsa fazlalıkları kapatmak gerekiyor.
Elle yazmak. Kontrolü tam veriyor ama bakım yükü sizde: adres değiştiğinde şablonu güncellemeyi hatırlamak zorundasınız. Pratik orta yol, bilgiyi tek bir yerde tutup şablona oradan basmak — böylece adres bir yerde değişiyor.
İki yoldan hangisi olursa olsun, aynı bilgi üç yerde tutulduğunda (profil, site metni, schema) üçünün senkron kalması bir süreç meselesi hâline geliyor. Bu yüzden taşınma ve numara değişimi gibi olaylarda schema'yı da kontrol listesine yazmak gerekiyor.
Nasıl test edilir Üç araç yeterli ve üçü de ücretsiz:
Zengin Sonuç Testi. Sayfanın hangi zengin sonuçlara uygun olduğunu gösteriyor. Kritik hataları düzeltmek şart; uyarılar iyileştirme önerisi.
Search Console'daki geliştirme raporları. Sitenin tamamındaki hataları toplu gösteriyor — tek sayfa testinden daha bilgilendirici.
Kendi gözünüz. Kaynağı açıp JSON bloğunu okumak. Dinamik üretilen schema'da en sık hata burada görünüyor: boş kalan alan, çift kaçış, eksik virgül.
Test etmeden yayına almamak gerekiyor, çünkü geçersiz bir blok sessizce yok sayılıyor; hata mesajı görmüyorsunuz.
Aynı varlığı tek varlık olarak göstermek Sık atlanan bir ayrım var: bir sitede genellikle iki farklı şeyden söz ediliyor. Kurum (marka, tüzel kişilik) ve fiziksel işletme yeri (adresi, saati, telefonu olan nokta). Schema'da bunlar `Organization` ve `LocalBusiness` olarak ayrışıyor.
Tek şubeli işletmede ikisini ayırmak çoğu zaman gereksiz; `LocalBusiness` (ya da alt tipi) hem kurumu hem yeri temsil ediyor. Ama çok şubeli yapıda ayrım işe yarıyor: bir `Organization` ve ona bağlı birden çok yer.
Burada `@id` alanı devreye giriyor. Her varlığa kalıcı bir kimlik verip (genellikle o varlığın kanonik adresi artı bir çapa) diğer bloklardan aynı kimliğe referans veriliyor. Böylece ana sayfadaki blokla şube sayfasındaki blok, iki ayrı işletme gibi değil aynı yapının parçaları gibi okunuyor.
`sameAs` alanı da aynı işi dışa doğru yapıyor: profil adresi ve doğrulanabilir sosyal hesaplar buraya yazıldığında, sitedeki varlıkla dışarıdaki varlık arasındaki bağ açık hâle geliyor. Buraya yalnız gerçekten size ait ve güncel hesapları yazmak gerekiyor; terk edilmiş bir hesabı bağlamak fayda getirmiyor.
Bu bağların pratik değeri şu: aynı işletmeden farklı adlarla söz eden bir yapı, hem makine hem kullanıcı için belirsizlik üretiyor. Adın her yüzeyde aynı yazılması, schema'dan bağımsız olarak da temel kural: NAP tutarlılığı.
Schema'nın yapmadıkları - Sıralamayı yükseltmiyor. Hafif bir sinyal; asıl iş içeriğin kendisinde ve yerel tarafta profilde. - Zengin sonuç garantisi vermiyor. Uygunluk sağlıyor, kararı Google veriyor. - Yanlış bilgiyi düzeltmiyor. Profil ve site çelişiyorsa schema bu çelişkiyi çözmüyor, tekrar ediyor. - Profilin yerini almıyor. Yerel pakette görünen şey profil; schema siteyi anlaşılır kılıyor: 3'lü paket nasıl çalışıyor.
Sektöre göre hangi alanlar öne çıkıyor Yeme-içme. `Restaurant` tipi, `servesCuisine`, `menu` ve rezervasyon bağlantısı. Saatlerin doğruluğu burada schema'dan da önce geliyor: restoranlar için Google Business rehberi.
Konaklama. `Hotel` tipi ve oda/olanak bilgisi; sezon değişimlerinde saat ve kapanış güncellemesi: otel ve konaklamada yerel SEO.
Sağlık. Branşa özgü tip (`Dentist`, `Physician`) ve randevu bağlantısı. Sağlıkta içerik ve tanıtım kuralları meslek mevzuatına tabi olabiliyor; kendi regülatörünüze bakmanız gerekiyor: diş kliniklerinde Google Maps SEO.
Hizmet bölgesiyle çalışanlar. `areaServed` alanı burada anlam kazanıyor — ama bölge tanımının sıralama yarıçapı olmadığını unutmamak gerekiyor: hizmet bölgesi işletmeleri.
Oto ve teknik hizmet. `AutoRepair` gibi özgül tipler ve hizmet listesi; rapor kapsamı gibi ayrıntılar sayfa içeriğinde: oto ekspertiz.
Sıkça sorulan sorular Schema sıralamamı yükseltir mi? Doğrudan bir kol değil; Google temsilcileri yapılandırılmış verinin hafif bir sinyal olduğunu ifade etti. İşi içeriği netleştirmek ve zengin sonuç uygunluğu sağlamak.
Hangi schema tipini kullanmalıyım? LocalBusiness temel tip, ama daha özgül bir alt tip varsa (Restaurant, Dentist, HairSalon) onu kullanın. En dar doğru olan kazanıyor.
Kendi sitemdeki yorumları işaretleyip yıldız alabilir miyim? Alamazsınız. İşletmenin kendi sitesinde kendisi hakkında topladığı değerlendirmeler bu amaçla kullanılamıyor. Yıldızlı görünürlük için doğru yer profiliniz.
JSON-LD mi mikrodata mı? JSON-LD öneriliyor: tek blokta duruyor, bakımı kolay ve tasarım değişikliği bozmuyor.
Schema'ya sayfada olmayan bilgi yazabilir miyim? Yazmamalısınız. Yapılandırılmış veri sayfada görünen içeriği tekrar etmeli; görünmeyen bilgiyi işaretlemek politika dışı.
Schema kurdum ama zengin sonuç görünmüyor, neden? Uygunluk garanti değil; karar Google'ın. Ayrıca blok geçersizse sessizce yok sayılıyor, o yüzden önce Zengin Sonuç Testi ile kontrol etmek gerekiyor.
