Bu makalede7 bölüm
- Teknoloji
- Schema.org, JSON-LD, Google Rich Results Test, Schema Markup Validator, Yoast SEO, Rank Math
- Konu
- Kurumsal hizmet sitesinde yapılandırılmış veri kurgusu
- Seviye
- Orta
- Ön koşullar
- Temel HTML ve JSON bilgisi
- Sitenin şablon yapısına (header, tekil yazı, sayfa) erişim
- Google Search Console erişimi
Bir kurumsal sitenin kaynağını açıp JSON-LD bloklarını saydığımızda çoğu zaman aynı tabloyu görürüz: tema bir Organization basmış, SEO eklentisi ikincisini, sayfa oluşturucu da üçüncüsünü. Article düğümleri hiçbir yayıncıya bağlanmıyor, yazar alanında “admin” yazıyor. Arama motoru bu çıktıdan şirketin kim olduğunu çıkaramaz. Bu rehber, B2B bir hizmet sitesinde JSON-LD ile tek ve tutarlı bir şema haritasını nasıl kuracağınızı, hangi türün bugün gerçekten zengin sonuç ürettiğini ve çıktıyı nasıl doğrulayacağınızı anlatır.
Yapılandırılmış veri ne sağlar, ne sağlamaz
Beklentiyi baştan doğru kurun. Google, yapılandırılmış verinin genel bir sıralama faktörü olmadığını açıkça yazar. Sağladığı üç şey vardır: içerik türünün ve varlıkların (şirket, yazar, hizmet) belirsizlik olmadan tanımlanması, belirli türlerde zengin sonuç uygunluğu ve bilgi paneli gibi alanlarda kullanılabilecek kimlik sinyalleri.
Zengin sonuç tarafı zamanla daraldı. Google 2023’te SSS (FAQ) zengin sonuçlarını yalnız yetkili resmi kurum ve sağlık sitelerine sınırladı, HowTo zengin sonuçlarını kaldırdı. Sitelinks arama kutusu da sonradan sonuç sayfasından çıktı. Kurumsal bir hizmet sitesinde şemanın asıl getirisi yıldızlı snippet değil, tutarlı bir varlık kimliğidir. Hangi türün güncel olarak desteklendiğini her seferinde Google’ın yapılandırılmış veri galerisinden kontrol edin. Bu liste değişir.
Şemanın yapmadığı işler de nettir: indeksleme sorununu çözmez, zayıf içeriği güçlendirmez, sayfada görünmeyen bilgiyi “eklemenin” yolu değildir. Google yönergelerine göre işaretleme, kullanıcının sayfada gördüğü içeriği temsil etmelidir; gizli içerik için yazılmış şema manuel işleme konu olabilir. Hangi sayfanın dizine girip hangisinin dışarıda kalacağı ise ayrı bir iştir ve canonical, noindex ve sitemap sinyalleri ile yönetilir. Şema bu sinyallerin yerine geçmez.
Kurumsal site için şema haritası
Tek satır JSON-LD yazmadan önce haritayı çıkarın: hangi şablon hangi türü üretecek, hangi varlıklar tüm sitede ortak kalacak. Tipik bir kurumsal B2B hizmet sitesi için başlangıç noktası şu tablodur:
| Sayfa türü | Ana tür | Bağlı düğümler | Google zengin sonucu |
|---|---|---|---|
| Ana sayfa | WebPage | Organization, WebSite | Logo/kimlik sinyali |
| Hizmet sayfası | WebPage + Service | provider → Organization | Yok |
| Blog/rehber yazısı | BlogPosting veya Article | author, publisher, BreadcrumbList | Article özellikleri |
| İletişim sayfası | ContactPage | Organization (contactPoint, address) | Yok |
| Tüm iç sayfalar | BreadcrumbList | WebPage | Breadcrumb gösterimi (Google 2025’ten bu yana mobilde göstermiyor; masaüstünde sürüyor) |
Ürün satmayan bir hizmet şirketinde sahada en sık gördüğümüz hata, Product, Offer veya AggregateRating türlerini yalnızca “arama sonucunda yıldız çıksın” diye eklemektir. Kendi hizmetiniz hakkında kendi sitenizde yayımladığınız değerlendirmeler (self-serving review), Google’ın inceleme snippet’i politikası gereği yıldız göstermeye uygun değildir. Yıldız çıkmaz. Risk kalır.
Organization ve WebSite işaretlemesi
Organization düğümü sitenin kimlik kartıdır; bir kez ve sabit bir @id ile tanımlanır. Genellikle ana sayfada tam haliyle basılır, diğer sayfalar aynı @id ile ona referans verir. Alt markalar ya da bir ağdaki alt alan adları varsa her biri için ayrı Organization üretmek yerine ana kuruluşu tek tutun, alt siteleri WebSite olarak tanımlayın. Çoğu yapıda doğru model budur.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Örnek Bilişim A.Ş.",
"url": "https://www.example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.com/assets/logo-512.png"
},
"sameAs": [
"https://www.linkedin.com/company/ornek-bilisim"
],
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer support",
"telephone": "+90-212-000-00-00",
"availableLanguage": ["tr", "en"]
}
},
{
"@type": "WebSite",
"@id": "https://www.example.com/#website",
"url": "https://www.example.com/",
"name": "Örnek Bilişim",
"inLanguage": "tr-TR",
"publisher": { "@id": "https://www.example.com/#organization" }
}
]
}
Bu blokta en çok şu üç noktada sorun çıkar:
logotaranabilir bir URL olmalı, robots.txt ile engellenmemelidir. Google dokümantasyonuna göre en az 112×112 piksel olmalı ve düz beyaz arka planda doğru görünmelidir.sameAsyalnız kuruluşa ait resmi profilleri içerir. Çalışanların kişisel hesapları buraya girmez.- Adres, vergi numarası, telefon gibi alanlar sitedeki iletişim bilgileriyle birebir aynı olmalıdır. Telefon numarası değiştiğinde iletişim sayfası güncellenir, şema unutulur; tutarsızlık en sık burada başlar.
Service ve Article sayfaları
Hizmet sayfaları
Service türü Google’da zengin sonuç üretmez. Yine de sayfanın bir ürün tanıtımı ya da blog yazısı değil, belirli bir kuruluşun sunduğu hizmet olduğunu netleştirir. provider alanını Organization’a @id ile bağlamak, areaServed ile hizmet bölgesini ve serviceType ile kategoriyi vermek yeterlidir. Fiyat listesi yayımlamıyorsanız offers eklemeyin.
{
"@context": "https://schema.org",
"@type": "Service",
"@id": "https://www.example.com/hizmetler/teknik-seo/#service",
"name": "Teknik SEO ve Site Mimarisi",
"serviceType": "Teknik SEO danışmanlığı",
"provider": { "@id": "https://www.example.com/#organization" },
"areaServed": { "@type": "Country", "name": "Türkiye" },
"mainEntityOfPage": { "@id": "https://www.example.com/hizmetler/teknik-seo/#webpage" }
}
Rehber ve blog yazıları
Yazılarda BlogPosting (Article’ın alt türü) kullanılabilir. Google’ın Article dokümantasyonunda zorunlu alan yoktur; önerilen alanlar headline, image, datePublished, dateModified ve author’dır. Denetimlerde iki alan sürekli sorun çıkarır:
- author: Yazar bir kişiyse
Persontüründe, adı ve yazar sayfasıurl’si ile verilir. Kurum adını Person olarak yazmak ya da alanı “Admin” bırakmak sık görülen hatadır. İçerik kurum adına yayımlanıyorsaauthorolarak Organization kullanılabilir. - dateModified: Yalnız içerikte anlamlı bir değişiklik olduğunda güncellenir. Her önbellek temizliğinde veya şablon değişikliğinde tarihi yenileyen eklenti ayarları güvenilirliği düşürür.
BreadcrumbList, sayfadaki görünür ekmek kırıntısıyla aynı olmalıdır. Her ListItem için position, name ve son öğe dışında item URL’si verilir. Kırıntının kaynağı sitenin kategori yapısıdır. Bu yapı bozuksa şema da bozuk çıkar; bu yüzden kurumsal site bilgi mimarisi çalışması şemadan önce gelir.
@id ile varlık grafiği kurmak
Birbirinden kopuk JSON-LD blokları yerine düğümleri tek bir @graph içinde @id ile bağladığınızda arama motoru “bu yazının yayıncısı, ana sayfadaki kuruluşla aynı varlık” sonucunu tahmin etmek zorunda kalmaz. Yerleşik kural, @id’yi ilgili URL’ye parça tanımlayıcısı ekleyerek üretmektir: /#organization, /#website, <sayfa-url>#webpage, <sayfa-url>#breadcrumb.
Tek bir yazı sayfasındaki grafik şu ilişkileri taşır:
WebPage→isPartOf→WebSiteWebPage→breadcrumb→BreadcrumbListBlogPosting→mainEntityOfPage→WebPageBlogPosting→publisher→Organization(yalnızca@idreferansı)BlogPosting→author→Person(kendi@id’si ile)
@id URL biçiminde olsa da tarayıcıda açılması gerekmez; bir tanımlayıcıdır. Kural tek: aynı varlık için sitenin her yerinde aynı değer. http/https, www’li/www’siz ya da sondaki eğik çizgi farkı ayrı varlık gibi okunur. Tek karakter yeter. Bir site ağında, örneğin multisite yapısındaki alt alan adlarında, tüm siteler ana kuruluşa aynı @id ile referans vermelidir.
JavaScript ile üretilen sitelerde şemanın ilk HTML yanıtında bulunması tercih edilir. İstemci tarafında sonradan eklenen JSON-LD’yi de Google işleyebilir, ancak render’a bağımlılık gecikme ve yeni bir hata noktası ekler. Bu konunun genel çerçevesi React, SSR, SSG ve teknik SEO yazısında.
Doğrulama ve eklenti çakışmaları
Doğrulama iki ayrı soruya cevap verir ve iki ayrı araç ister:
| Araç | Cevapladığı soru | Sınırı |
|---|---|---|
| Rich Results Test | Sayfa Google’ın desteklediği bir zengin sonuca uygun mu? | Desteklenmeyen türleri (Service gibi) raporlamaz |
| Schema Markup Validator (validator.schema.org) | İşaretleme schema.org sözlüğüne göre geçerli mi? | Google uygunluğu hakkında bilgi vermez |
| Search Console geliştirme raporları | Site genelinde hangi şablonlarda hata/uyarı var? | Yalnız Google’ın raporladığı türler, gecikmeli |
WordPress’te eklenti çakışmaları
Yoast SEO ve Rank Math gibi eklentiler WordPress sitelerinde sayfa başına bir @graph üretir. Sorun, tema, sayfa oluşturucu veya ikinci bir eklenti aynı sayfaya kendi Organization ya da Article bloğunu eklediğinde başlar. Konsolda ilk yapılacak iş, sayfa kaynağındaki JSON-LD türlerini saymaktır:
curl -s https://www.example.com/rehberler/ornek-yazi/ \
| grep -o '"@type":"[A-Za-z]*"' | sort | uniq -c
Bu komut yalnızca boşluksuz (minify edilmiş) JSON çıktısında çalışır; girintili çıktıda grep desenini '"@type": *"[A-Za-z]*"' olarak genişletin. Aynı sayfada iki Organization veya iki Article görüyorsanız kaynağını bulun. Pratik çözüm sırası şudur: temanın ya da sayfa oluşturucunun şema çıktısını kapatın, eksik alanları SEO eklentisinin ayarları veya filtreleriyle aynı grafiğe ekleyin, ek blok şartsa onu eklentinin @id değerlerine referans verecek şekilde yazın.
Kontrol listesi
- Organization tek, sabit
@id’li ve iletişim bilgileri sayfadakiyle aynı. - Her yazıda
authorgerçek bir kişi veya kurum; “admin” değil. datePublishedvedateModifiedISO 8601 biçiminde ve saat dilimi içeriyor.- BreadcrumbList görünür kırıntıyla birebir aynı.
- Görünmeyen içerik veya kendi hakkınızda yazılmış değerlendirme işaretlenmemiş.
- Sayfa başına aynı türden çift düğüm yok.
- Search Console geliştirme raporları ayda bir gözden geçiriliyor.
Şema haritası tek başına kurulmaz; site mimarisi ve indeksleme sinyalleriyle aynı masada tasarlanır. Biz bu işi teknik SEO ve site mimarisi çalışmasının bir parçası olarak ele alıyoruz.
Sık sorulan sorular
Schema markup sıralamayı doğrudan yükseltir mi?
Hayır. Google yapılandırılmış veriyi genel bir sıralama sinyali olarak kullanmadığını belirtir. Katkısı, içeriğin doğru anlaşılması ve uygun türlerde zengin sonuç uygunluğu üzerindendir; tıklama oranını dolaylı olarak etkileyebilir.
FAQPage işaretlemesini kaldırmalı mıyım?
Zorunlu değil. Geçerli ve sayfadaki görünür içerikle birebir uyumlu FAQPage işaretlemesi zarar vermez. Ancak Google 2023’ten bu yana SSS zengin sonucunu yalnız yetkili resmi kurum ve sağlık sitelerinde gösterdiği için kurumsal bir hizmet sitesinde görsel bir kazanç beklemeyin.
Service türü için Google’da zengin sonuç var mı?
Hayır, Google’ın desteklediği zengin sonuç türleri arasında Service yok. Yine de geçerli bir schema.org türüdür; hizmetin kim tarafından ve hangi bölgede sunulduğunu makine tarafından okunabilir kılar ve varlık grafiğinin tutarlılığına katkı verir.
SEO eklentisi zaten şema üretiyorsa ayrıca JSON-LD eklemek gerekir mi?
Önce eklentinin ürettiği grafiğe bakın. Eksik alanları eklentinin filtreleri veya ayarlarıyla aynı grafiğe eklemek, ikinci bağımsız bir JSON-LD bloğu basmaktan daha temizdir. İki ayrı Organization düğümü oluşmuşsa @id değerlerini eşitleyin ya da birini kaldırın.
- Teknoloji
- Schema.org, JSON-LD, Google Rich Results Test, Schema Markup Validator, Yoast SEO, Rank Math
- Konu
- Kurumsal hizmet sitesinde yapılandırılmış veri kurgusu
- Seviye
- Orta
- Ön koşullar
- Temel HTML ve JSON bilgisi
- Sitenin şablon yapısına (header, tekil yazı, sayfa) erişim
- Google Search Console erişimi
Performans ve SEO