Web sitenizde hizmetleriniz, ürünleriniz ve işletme bilgileriniz bulunabilir. Ancak bu bilgilerin sayfada yer alması, aralarındaki ilişkinin arama motorlarına açık biçimde anlatıldığı anlamına gelmez.
Bir sayfa bir hizmeti mi tanıtıyor, bir ürünü mü satıyor, yoksa bilgilendirici bir makale mi sunuyor? Hizmeti sağlayan kuruluş kim? İçeriğin yazarı ile yayıncısı aynı mı?
Schema ve yapılandırılmış veri, bu sorulara makinelerin okuyabileceği standart bir formatta cevap vermenizi sağlar. Doğru uygulama, sayfanın anlamını açıklamaya ve uygun içeriklerin desteklenen arama özellikleri için değerlendirilmesine yardımcı olur. Kaynak: Google yapılandırılmış veri rehberi
Bu rehberde işletmeler için tür seçimini, JSON-LD uygulamasını, doğrulama sürecini ve sürdürülebilir bir yapılandırılmış veri yönetimini ele alacağız.
Schema ve Yapılandırılmış Veri Arasındaki Fark Nedir?
Bu kavramlar birlikte kullanılsa da farklı işlevleri ifade eder:
| Kavram | İşlevi |
|---|---|
| Yapılandırılmış veri | Bilgiyi tanımlı alanlar ve ilişkiler üzerinden düzenleme yaklaşımıdır. |
| Schema.org | Kuruluş, hizmet ve ürün gibi varlıkları tanımlamak için kullanılan ortak sözlüktür. |
| JSON-LD | Bu tanımları web sayfasına eklemek için kullanılabilen veri formatıdır. |
Örneğin bir danışmanlık sayfasında Service hizmeti, Organization hizmeti sağlayan kuruluşu tanımlayabilir. provider özelliği, hizmet ile sağlayıcı arasındaki ilişkiyi kurar. Kaynak: Schema.org Service tanımı
Google; JSON-LD, Microdata ve RDFa formatlarını destekler. Uygulama ve bakım kolaylığı nedeniyle çoğu durumda JSON-LD kullanılmasını önerir. Kaynak: Desteklenen yapılandırılmış veri formatları
Yapılandırılmış Veri SEO İçin Neden Önemlidir?
Yapılandırılmış veri, işletmenizin sunduğu bilgilerin daha açık yorumlanmasını destekler. Uygun sayfalarda zengin sonuçlara katılım imkânı da sağlayabilir.
Ancak üç farklı durumu birbirinden ayırmak gerekir:
- İşaretlemenin teknik olarak geçerli olması.
- Google’ın belirli bir arama özelliğinin koşullarını karşılaması.
- Bu özelliğin arama sonuçlarında gerçekten gösterilmesi.
İlk iki koşul sağlansa bile Google zengin sonuç gösterimini garanti etmez. Yapılandırılmış veri, tek başına sıralama artışı taahhüdü olarak değerlendirilmemelidir. Kaynak: Google yapılandırılmış veri politikaları
İşletmeler açısından sağlıklı hedef; doğru içerikleri doğru türlerle tanımlamak, teknik hataları azaltmak ve uygun arama görünümlerinin performansını ölçmektir.
Hangi Sayfada Hangi Schema Türü Kullanılmalı?
Tür seçimine “En fazla hangi işaretlemeyi ekleyebiliriz?” sorusuyla başlanmamalıdır. Önce sayfanın ana amacı belirlenmelidir.
| Sayfa veya varlık | Değerlendirilebilecek tür | Uygulama amacı |
|---|---|---|
| Kuruluş bilgileri | Organization | İşletmenin kimliğini tanımlamak |
| Fiziksel işletme veya şube | Uygun LocalBusiness alt türü | Yerel işletme bilgilerini açıklamak |
| Hizmet detay sayfası | Service | Hizmeti ve sağlayıcısını ilişkilendirmek |
| Ürün detay sayfası | Product | Ürün bilgilerini tanımlamak |
| Blog yazısı | BlogPosting veya Article | Makaleyi, yazarı ve yayıncıyı açıklamak |
| Sayfa hiyerarşisi | BreadcrumbList | Sayfanın site içindeki konumunu belirtmek |
Tablodaki türler için Google desteği ve gerekli alanlar aynı değildir. Schema.org’da bir türün bulunması, o tür için Google’da özel bir zengin sonuç bulunduğu anlamına gelmez. Hedeflenen arama özelliği, Google’ın güncel destek listesinden kontrol edilmelidir. Kaynak: Google yapılandırılmış veri galerisi
Örneğin Service, hizmeti tanımlamak için kullanılabilir; bu kullanım özel bir “hizmet kartı” gösterimi vaadi oluşturmaz.
İleri Seviye Uygulama: Sayfaları Değil, Varlıkları da Modelleyin
Büyük sitelerde her sayfaya bağımsız bir kod parçası eklemek zamanla tutarsızlık oluşturabilir. Aynı kuruluş farklı sayfalarda farklı isimlerle tanımlanabilir veya eklentiler birbiriyle çelişen bilgiler üretebilir.
Bu nedenle uygulama öncesinde bir varlık modeli hazırlanması yararlıdır:
- Kuruluş hangi bilgilerle tanımlanacak?
- Her hizmetin ayrı bir kimliği olacak mı?
- Blog içerikleri hangi yayıncıya bağlanacak?
- Bu bilgilerin yönetildiği asıl veri kaynağı neresi olacak?
Kuruluş bilgilerinde ad, URL ve diğer kimlik bilgilerinin doğru olması önemlidir. Google’ın Organization dokümantasyonu, bu işaretlemenin kuruluşu anlamaya ve benzer kuruluşlardan ayırt etmeye yardımcı olabileceğini açıklar. Kaynak: Organization yapılandırılmış verisi
Teknik tasarımda kararlı @id değerleri kullanmak, aynı varlığı farklı tanımlarda ilişkilendirmeyi kolaylaştırır. Buradaki amaç, site genelinde yönetilebilir bir kimlik düzeni kurmaktır.
JSON-LD ile Hizmet İşaretleme Örneği
Aşağıdaki örnek, bir hizmeti sağlayıcı kuruluşla ilişkilendirir. example.com adresleri temsilidir; uygulamadan önce gerçek, kalıcı adreslerle değiştirilmelidir. Açıklama da ilgili sayfada sunulan hizmeti doğru yansıtmalıdır.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "SEO Performans",
"url": "https://example.com/"
},
{
"@type": "Service",
"@id": "https://example.com/schema-hizmeti/#service",
"name": "Schema ve Yapılandırılmış Veri",
"serviceType": "Yapılandırılmış veri optimizasyonu",
"url": "https://example.com/schema-hizmeti/",
"description": "Web sayfalarındaki yapılandırılmış verilerin analizi ve optimizasyonu.",
"provider": {
"@id": "https://example.com/#organization"
}
}
]
}
</script>Bu örnekte @graph ilişkili tanımları bir arada tutar. provider, hizmeti kuruluşun @id değeriyle ilişkilendirir. Service için kullanılan alanlar, Schema.org’un hizmet modeline dayanır. Kaynak: Service özellikleri
Bu, hizmet detay sayfası için başlangıç örneğidir. Şu anda okuduğunuz gibi bilgilendirici bir blog yazısının ana içeriği ise makale olarak modellenmelidir. Her sayfaya aynı hizmet kodunu kopyalamak, sayfanın gerçek amacını açıklamaz.
Dinamik Sitelerde Yapılandırılmış Veri Nasıl Yönetilmeli?
İleri seviye uygulamanın asıl zorluğu, kodu ilk kez eklemekten çok veriyi güncel tutmaktır.
Ürün fiyatı değiştiğinde görünür içerik güncelleniyor ama JSON-LD eski fiyatı gösteriyorsa iki ayrı bilgi oluşur. Benzer sorunlar hizmet açıklamaları, işletme adresleri ve yayın tarihleri için de yaşanabilir.
Bakımı kolaylaştırmak için şu yaklaşım kullanılabilir:
- Ortak veri kaynağı belirleyin. Görünür içerik ve işaretleme mümkün olduğunca aynı kayıttan beslensin.
- Şablon düzeyinde üretin. Sayfa türüne uygun alanlar merkezi kurallarla oluşturulsun.
- Eksik veri davranışını tanımlayın. Bilinmeyen alanlara uydurma değerler eklenmesin.
- Önbelleği birlikte yenileyin. İçerik değişikliği yapılandırılmış veriye de yansısın.
- Çıktıyı test edin. Yönetim panelindeki veri kadar, ziyaretçiye sunulan son sayfa da kontrol edilsin.
CMS girdilerinden JSON-LD üretirken güvenli bir JSON serileştirme yöntemi kullanılmalıdır. Metinleri elle birleştirmek, tırnak işaretleri ve özel karakterler nedeniyle hatalı çıktı oluşturabilir.
Yapılandırılmış Veri Nasıl Test Edilir?
Doğrulama, yalnızca JSON sözdiziminin doğru olup olmadığını kontrol etmekten ibaret değildir.
1. Schema Modelini Kontrol Edin
Schema Markup Validator ile türlerin, özelliklerin ve veri ilişkilerinin kontrolü yapılabilir. Bu kontrol, Google’da zengin sonuç uygunluğuyla aynı şey değildir.
2. Google Özelliğine Uygunluğu Kontrol Edin
Rich Results Test, Google’ın desteklediği zengin sonuç türlerini incelemek için kullanılır. Bir Service tanımının araçta zengin sonuç olarak görünmemesi, tek başına Schema.org açısından geçersiz olduğu anlamına gelmez. Google’ın desteklediği özelliklerle sözlük kapsamı farklıdır. Kaynak: Google yapılandırılmış veri açıklamaları
3. İçerikle Eşleşmeyi İnceleyin
İşaretleme, sayfanın sunduğu içeriği doğru temsil etmelidir. Yanıltıcı, güncelliğini yitirmiş veya kullanıcıya sunulmayan iddialar eklenmemelidir. Otomatik testin hata vermemesi, bütün kalite kurallarının karşılandığını kanıtlamaz. Kaynak: Yapılandırılmış veri kalite kuralları
4. Yayın Sonrası Takip Yapın
Desteklenen türler için Search Console raporları izlenmeli; şablon, tema veya eklenti güncellemelerinden sonra örnek sayfalar tekrar doğrulanmalıdır. Geliştirme ortamında çalışan işaretleme, yayın sırasında değişebilir. Kaynak: Google uygulama ve izleme önerileri
Örnek Uygulama Senaryosu: Çok Hizmetli Bir İşletme Sitesi
Bu senaryo, yöntemi açıklamak için hazırlanmıştır; gerçek müşteri sonucu içermez.
Bir danışmanlık işletmesinin 25 hizmet sayfası ve düzenli yayın yaptığı bir blogu olduğunu düşünelim. Tema, SEO eklentisi ve özel kodlar ayrı ayrı yapılandırılmış veri üretmektedir.
İlk incelemede kuruluş adının farklı biçimlerde yazıldığı, bazı blog sayfalarının hizmet olarak tanımlandığı ve kaldırılan hizmetlerin açıklamalarının kodda kaldığı görülür.
Bu durumda uygulama planı şöyle oluşturulabilir:
| Aşama | Yapılacak çalışma | Beklenen çıktı |
|---|---|---|
| Envanter | İşaretleme üreten bileşenleri bulmak | Kaynak ve sayfa türü listesi |
| Modelleme | Kuruluş, hizmet ve makale ilişkilerini tanımlamak | Tutarlı veri modeli |
| Düzenleme | Çelişen üretimleri ve eski bilgileri düzeltmek | Güncel şablonlar |
| Pilot | Seçilmiş hizmet ve blog sayfalarını test etmek | Doğrulanmış örnekler |
| Yaygınlaştırma | Kuralları ilgili şablonlara uygulamak | Yönetilebilir site geneli uygulama |
Başarı yalnızca “kaç sayfaya schema eklendi?” sorusuyla ölçülmez. Hatalı tanımların azalması, bilgilerin güncel kalması ve uygun arama görünümlerinin performansı da değerlendirilir.
SEO Performans’ın Schema ve Yapılandırılmış Veri Hizmeti
SEO Performans’ın Schema ve Yapılandırılmış Veri hizmetinin odağında, işletmenin içeriğine uygun ve sürdürülebilir bir uygulama planı bulunur.
Çalışma; mevcut işaretlemelerin incelenmesi, sayfa türlerine uygun modelin belirlenmesi, teknik düzenlemelerin planlanması ve sonuçların doğrulanması üzerinden ele alınır.
İşletmeniz açısından bu süreç şu soruları netleştirir:
- Hangi sayfalarda eksik veya hatalı işaretleme var?
- Hangi türler içeriğinizle gerçekten uyumlu?
- Tema ve eklentiler çelişen veri üretiyor mu?
- Hangi düzenlemeler öncelikli?
- İçerik güncellendiğinde doğruluk nasıl korunacak?
Böylece yapılandırılmış veri çalışması, tek seferlik kod ekleme işleminin ötesinde teknik SEO yönetiminin bir parçasına dönüşür.
Sıkça Sorulan Sorular
Her Sayfaya Schema Eklemek Gerekir mi?
Her sayfaya aynı işaretlemeyi eklemek doğru bir yaklaşım değildir. Öncelik, sayfanın içeriğini doğru tanımlayan ve işletme açısından anlamlı olan uygulamalara verilmelidir.
SEO Eklentisi Kullanmak Yeterli mi?
Eklenti, işaretleme üretimini kolaylaştırabilir. Ancak seçilen türlerin, alanların ve çıktıların doğru olduğunu ayrıca kontrol etmek gerekir. Özel şablonlar ve birden fazla veri üreticisi ek inceleme gerektirebilir.
Daha Fazla Schema Türü Daha İyi Sonuç Verir mi?
Amaç tür sayısını artırmak değildir. Sayfadaki varlıkları ve ilişkileri doğru, tutarlı ve güncel biçimde açıklamaktır.
Sonuçlar Ne Zaman Görülür?
Teknik düzeltmeler yayın sonrası test edilebilir. Arama sonuçlarına yansıma ise yeniden tarama, indeksleme ve Google’ın gösterim kararına bağlıdır. Sabit süre veya zengin sonuç garantisi verilmemelidir.
Web Sitenizin Yapılandırılmış Veri İhtiyaçlarını Öğrenin
Sitenizde schema kodu bulunması, doğru türlerin kullanıldığı veya bilgilerin güncel kaldığı anlamına gelmez. Eksikleri ve öncelikleri belirlemek için sayfa içeriği ile teknik çıktının birlikte incelenmesi gerekir.
SEO Performans ile web sitenizin Schema ve Yapılandırılmış Veri ihtiyaçlarını değerlendirin, uygulanabilir iyileştirme adımlarını belirleyin.
Ücretsiz SEO Analizi Talep Et