Schema markup, bir web sayfasındaki bilgileri arama motorlarının daha açık anlaması için kullanılan yapılandırılmış veri işaretlemesidir. Blog yazısında başlığın, yazarın, yayımlanma tarihinin ve ana görselin hangi alanlara karşılık geldiğini tanımlayabilirsiniz. En yaygın yöntem JSON-LD biçimidir. Ancak işaretleme eklemek sıralama artışı veya Google’da özel bir görünüm garantisi vermez. İyi bir uygulamanın ilk adımı, sitenizin zaten hangi veriyi ürettiğini görmektir.
Bu rehberde Schema.org sözlüğüyle Google’ın desteklediği arama özellikleri arasındaki farkı, WordPress üzerinde çakışan kod oluşturmadan çalışma yöntemini ve yayımdan sonra doğrulamayı anlatıyoruz. Örnekler bir blog makalesini temel alıyor; ürün, tarif veya etkinlik sayfalarının ayrı kuralları olduğunu unutmayın.
Schema markup nedir, ne işe yarar?
Schema.org, internetteki içerikleri tanımlamak için ortak türler ve özellikler sunan bir sözlüktür. Article bir içerik türüdür; headline, author ve datePublished gibi özellikler o türün alanlarıdır. Yapılandırılmış veri ise bu alanların sayfanızdaki gerçek içerikle eşleştirilmiş makine tarafından okunabilir ifadesidir. Google bu bilgileri sayfayı anlamak ve desteklediği arama özelliklerine uygunluğunu değerlendirmek için kullanabilir.
Üç kavram sık karıştırılır. Schema.org bir sözlüktür; JSON-LD veriyi sayfaya yerleştirme biçimidir; zengin sonuç ise arama motorunun uygun gördüğünde gösterebileceği bir arama görünümüdür. Bir kodun Schema.org açısından geçerli olması, Google’ın o tür için zengin sonuç sunduğu anlamına gelmez. Google’ın Rich Results Test aracı ile Schema Markup Validator bu yüzden farklı soruları yanıtlar.
İşaretleme, sayfada olmayan bir bilgiyi yaratmaz. Örneğin kullanıcıya görünmeyen beş yıldızlı puanı JSON-LD içine yazmak, içeriği daha güvenilir göstermez; yanıltıcı işaretleme olur. Aynı şekilde doğru schema, zayıf bir makaleyi tek başına kaliteli hâle getirmez. Önce sayfanın kendisi açık, güncel ve yararlı olmalıdır.
Blog yazısı için hangi tür seçilmeli?
Bir blog yazısında genellikle BlogPosting uygun alt türdür. Daha genel içeriklerde Article kullanılabilir. NewsArticle ise gerçekten haber niteliği taşıyan yayınlar içindir; sırf haber kutusuna girmek amacıyla normal bir rehberi NewsArticle diye etiketlemeyin. Tür seçimini sitenin adına göre değil, o sayfanın esas içeriğine göre yapın. Kategori, etiket, ana sayfa ve tekil makale aynı şablon değildir.
Makale sayfasında başlık, yazar, tarih, görsel ve ana sayfa adresi birbirini tutmalıdır. Google’ın Article belgeleri headline, image, datePublished, dateModified ve author gibi alanlar için öneriler verir. Bunları evrensel bir “hepsi zorunlu” listesi olarak yorumlamayın. Hangi alanların yer alabileceği kullanılan tür ve arama özelliğine göre değişir. Eksik bir önerilen alan, otomatik olarak geçersiz kod anlamına gelmez; ancak zenginleştirmeyi ve açıklığı sınırlayabilir.
Önce okuyucunun gördüğü içeriği kontrol edin: sayfada gerçek bir yazar adı var mı, tarih doğru mu, öne çıkan görsel makaleyi temsil ediyor mu? Ardından işaretlemedeki değerlerin bunlarla aynı olduğunu doğrulayın. Görsel optimizasyonunun kendisi de önemlidir; dosya ve alternatif metin seçimi için görsel SEO rehberimize bakabilirsiniz.
JSON-LD örneği: alanlar nasıl görünür?
Aşağıdaki örnek, işaretlemenin mantığını göstermek içindir. Adresleri, tarihleri, başlığı ve yazarı kendi gerçek sayfanızdaki değerlerle değiştirmeden kullanmayın. WordPress’te bir SEO eklentisi zaten Article veya BlogPosting çıktısı oluşturuyorsa bu kodu ayrıca yapıştırmayın. Burada kodu bilerek metin olarak gösteriyoruz; makale içinde çalışan ikinci bir schema betiği değildir.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Örnek blog yazısının başlığı",
"image": ["https://ornek.com/gorseller/makale-kapagi.webp"],
"datePublished": "2026-10-07T10:00:00+03:00",
"dateModified": "2026-10-07T14:30:00+03:00",
"author": {
"@type": "Person",
"name": "Örnek Yazar",
"url": "https://ornek.com/yazar/ornek-yazar/"
},
"mainEntityOfPage": "https://ornek.com/ornek-makale/"
}
</script>headline yazının görünen başlığıyla uyumlu olmalı; arama sonuçlarına farklı ve yanıltıcı bir başlık vaat etmemelidir. image erişilebilir bir görselin tam adresini göstermelidir. Google’ın görsel önerilerinde yüksek çözünürlük ve desteklenen en boy oranları ayrıca açıklanır. Tek görsel kullanımı teknik olarak anlaşılır olsa da ilgili görselleri iyi seçmek arama görünümü için yararlıdır.
datePublished ilk yayın anını, dateModified gerçek ve anlamlı son güncellemeyi belirtir. Saat dilimi eklemek belirsizliği azaltır; Türkiye’deki örnekte +03:00 gösterilmiştir. Eski bir yazıya yalnızca tarih tazelemek için yüzeysel değişiklik yapmayın. author gerçek sorumluyu tanımlar. Yazar profilinin erişilebilir ve tutarlı olması, hem okura hem sisteme bağlam sağlar. mainEntityOfPage makalenin asıl adresini işaret eder; tercih edilen adresle çelişmemelidir.
JSON-LD sözdiziminde çift tırnak, virgül ve köşeli parantez önemlidir. Son alandan sonra yanlışlıkla virgül bırakmak veya akıllı tırnak kullanmak kodu bozabilir. Tarih formatının yanlış olması da alanı anlaşılmaz kılabilir. Kodun geçerli olup olmadığına gözle karar vermek yerine test araçlarını kullanın.
WordPress’te önce mevcut çıktıyı bulun
WordPress’te SEO eklentisi, tema ve bazı blok eklentileri yapılandırılmış veri üretebilir. Aynı makale için birkaç ayrı BlogPosting nesnesi oluşturulursa başlık, tarih, görsel veya yazar alanları birbirinden farklı kalabilir. Sorun yalnızca kod tekrarı değildir; arama motoruna hangi değerin doğru olduğuna ilişkin belirsiz bir sinyal gönderirsiniz. Bu nedenle uygulamaya yeni eklenti kurarak değil, mevcut HTML’i inceleyerek başlayın.
- Makalenin herkese açık URL’sini açın; düzenleyici önizlemesini değil, canlı sayfayı kullanın.
- Tarayıcıda sayfa kaynağını görüntüleyin ve
application/ld+jsonifadesini arayın. - Bulunan her betikteki
@typedeğerlerini inceleyin. Bir@graphiçinde WebSite, Organization, WebPage ve BlogPosting birlikte bulunabilir; bu normaldir. - Makalenin ana nesnesindeki başlık, yazar, tarih, görsel ve URL değerlerini sayfada gördüklerinizle karşılaştırın.
- Aynı tür için tema ve eklenti tarafından üretilmiş çelişkili çıktılar varsa hangi sistemin esas kaynağı olacağını belirleyin.
Bu sitedeki bu makalenin canlı kaynağında Rank Math tarafından oluşturulmuş bir BlogPosting nesnesi zaten bulunuyor. Dolayısıyla bu rehberi yayımlarken makale gövdesine ikinci bir çalışan BlogPosting betiği eklemiyoruz. Benzer bir sonuca kendi sitenizde ulaşırsanız, var olan eklentinin alanlarını düzeltmek daha sağlıklı bir yoldur. Kaynakta hiçbir uygun işaretleme bulunmuyorsa, tek bir yöntem seçip uygulayın ve sonuç sayfasını yeniden test edin.
HTML kaynağına bakmak hızlı bir ilk kontroldür; bazı sistemler kodu sonradan oluşturabilir. Bu nedenle ikinci aşamada Google Rich Results Test aracının canlı URL testini kullanın. Önbellek, CDN veya sayfa oluşturucu nedeniyle WordPress editöründe gördüğünüzle ziyaretçiye sunulan HTML farklıysa, canlı çıktı esas alınmalıdır.
SEO eklentisiyle güvenli uygulama akışı
Rank Math, Yoast SEO ve benzeri araçların arayüzü sürüme göre değişebilir. Menünün tam adına takılmak yerine şu alanların sonucuna odaklanın: tekil yazı türü, yazar bilgisi, tarih alanları, öne çıkan görsel ve canonical URL. Bir blog yazısının şablonunda Article veya BlogPosting seçiliyse yayımlanan çıktıyı test edin. SEO başlığı ile makalenin görünen başlığı farklı olabilir; ancak ikisi de aynı içeriği dürüstçe anlatmalıdır. Çok büyük bir anlam farkı, işaretlemeyi zayıflatır.
Yazar profili boşsa önce gerçek yazarın bilgilerini tamamlayın. Görsel alanı eksikse ilgili ve erişilebilir öne çıkan görseli kontrol edin. Tarih hatalıysa yayın ve değişiklik tarihlerini WordPress kayıtlarıyla karşılaştırın. Tüm yazılarda aynı varsayılan görselin kullanılması özellikle makale görseli alanını yanıltıcı kılabilir. Eklenti ayarını değiştirdikten sonra yalnızca ayar ekranına güvenmeyin; farklı kategorilerden birkaç canlı sayfayı örnekleyin.
HTML veya özel kodla JSON-LD eklemeniz gerçekten gerekiyorsa temanın ya da eklentinin aynı türü üretmediğinden emin olun. Kod, sayfanın HTML çıktısında application/ld+json türündeki bir betik olarak yer almalıdır. WordPress’in güvenlik filtreleri makale gövdesine yapıştırılan script öğesini kaldırabilir; bu yüzden yayın sonrası kaynağı yeniden inceleyin. Eklenti destekli bir site için çoğu zaman verinin tek yerden yönetilmesi bakımı kolaylaştırır.
BreadcrumbList ne zaman kullanılmalı?
BreadcrumbList, okurun sayfada gördüğü gezinme yolunu tanımlar. Örneğin “Ana sayfa → Teknik SEO → Schema Markup” dizisi hem sayfada kullanılabilir bir gezinme öğesi olmalı hem de yapılandırılmış verideki öğelerle tutarlı kalmalıdır. Google’ın belgelediği işaretlemede en az iki ListItem bulunur. Yalnızca URL’deki klasörlere bakıp kullanıcının görmediği hayalî bir yol üretmeyin.
Birçok WordPress teması veya SEO eklentisi breadcrumb oluşturur. Görünen navigasyon ve JSON-LD çıktısını birlikte kontrol edin. Kategori değiştiğinde menüde bir ad, JSON-LD içinde başka bir ad kalmışsa eşitleyin. Ana sayfa ve makale adresleri doğru olmalıdır. Sitenizde breadcrumb hiç görünmüyorsa yalnızca arama sonucu görünümü için işaretleme eklemeyi ilk çözüm olarak seçmeyin; önce gezinmenin kullanıcıya yararlı olup olmayacağına bakın.
BreadcrumbList, Article ile aynı görevi yapmaz. Biri sayfanın yerini, diğeri makalenin içeriğini tanımlar. Bir @graph içinde birden çok anlamlı nesnenin bulunması normal olabilir. Sorun, aynı görevi üstlenen birden çok nesnenin birbiriyle çelişmesidir. Örneğin iki BlogPosting nesnesinin farklı yazar bildirmesi veya breadcrumb yolunun canlı menüyle uyuşmaması inceleme gerektirir.
Canonical, site haritası ve schema ilişkisi
Canonical etiket, kopya veya yakın içerikli adresler arasında tercih edilen URL’yi bildirir. Yapılandırılmış verideki makale adresi de bu tercihle uyumlu olmalıdır. Parametreli bir önizleme URL’sini, yanlışlıkla makalenin asıl adresi gibi işaretlemeyin. Konunun ayrıntıları için canonical URL rehberine bakabilirsiniz.
XML site haritası ise keşif için URL listesi sağlar; makalenin yazar ve görsel alanlarını tanımlamaz. Sitemap göndermek, JSON-LD eklemenin yerini tutmaz; JSON-LD de taranması engellenmiş bir sayfayı kendi başına erişilebilir hâle getirmez. site haritası gönderme rehberimizde keşif adımlarını ayrıca anlatıyoruz. Önce URL’nin erişilebilir, dizine eklenebilir ve doğru canonical’a sahip olduğundan emin olun.
Noindex verilmiş, robots.txt ile engellenmiş veya giriş gerektiren bir sayfada zengin sonuç beklemek doğru değildir. Yapılandırılmış verinin görünür içerikle eşleşmesi, sayfanın teknik olarak da Google tarafından işlenebilmesiyle birlikte değerlendirilmelidir. WordPress’te taslak ya da önizleme adresi üzerinde aldığınız test sonucu, yayımlanan URL’nin sonucunu temsil etmeyebilir.
Yayımdan önce ve sonra nasıl doğrulanır?
Doğrulama tek bir yeşil onaydan ibaret değildir. Önce JSON-LD’nin sözdizimini ve türünü, sonra Google’ın desteklediği arama özelliğine uygunluğunu, son olarak canlı URL’nin gerçekten aynı çıktıyı verip vermediğini kontrol edin. Bu üç adım farklı hataları yakalar. Test ettiğiniz kaynak kod ile Google’a sunulan sayfa aynı değilse doğru görünen bir deneme sizi yanıltabilir.
- Google Rich Results Test aracına canlı URL’yi girin. Algılanan öğeleri, hata ve uyarıları okuyun.
- Schema Markup Validator ile genel Schema.org yapısını inceleyin. Burada geçerli görünen bir türün Google’da özel görünümü olmayabilir.
- Google Search Console’da URL Denetimi ile sayfanın dizin durumuna ve Google’ın gördüğü canonical’a bakın. İlgili zengin sonuç raporu varsa etkilenen URL’leri izleyin.
- Düzeltme yaptıktan sonra önbelleği temizleyin, canlı URL’yi yeniden test edin ve Search Console verisinin işlenmesi için zaman tanıyın.
Hata ilgili özelliğin uygulanmasını engelleyebilir. Uyarı ise çoğu zaman önerilen alanın eksikliğine işaret eder; bağlamını okumadan her uyarıyı “sıralama cezası” diye yorumlamayın. Rich Results Test’te “uygun” görünmek de sonuç sayfasında sürekli bir kart gösterileceği anlamına gelmez. Google, sorgu ve cihaz gibi etkenlere göre görünümü seçer.
En sık görülen hatalar ve çözümleri
Bir makalede çelişen iki BlogPosting nesnesi
SEO eklentisiyle tema aynı makale verisini ayrı ayrı üretiyorsa hangisinin yazar, tarih ve görsel için doğru değer verdiğine bakın. Mümkünse bir kaynağı kapatın; kapatamıyorsanız alanları uyumlu hâle getirin. Birden çok JSON-LD betiği olması kendi başına hata değildir. Asıl sorun, aynı sayfanın ana makalesi için çelişkili tanımlardır. Değişiklikten önce ve sonra örnek URL’lerin kaynaklarını karşılaştırın.
Görsel veya tarih alanı canlı içerikten kopuk
Öne çıkan görsel değiştirilmiş fakat önbellek eski adresi gösteriyor olabilir. Görsel URL’sini doğrudan açın; 404 veriyorsa işaretlemeyi güncelleyin. Tarih alanında ise yayımlanma ile son değişiklik zamanını ayırın. Gerçek bir güncellemenin ardından dateModified yenilenebilir. Yalnızca görünür tarihin değişmesi, kaynak kodda eski değerin kalması veya bunun tersi tutarsızlık yaratır.
Gerçek olmayan yorum, puan veya ürün bilgisi
Bir blog rehberini Product olarak işaretleyip fiyat eklemek veya görünmeyen değerlendirmeler üzerinden Review puanı üretmek yanıltıcıdır. Google’ın yapılandırılmış veri politikaları, işaretlemenin sayfadaki içeriği doğru temsil etmesini ister. FAQPage türünü de her yazıya otomatik eklemeyin. Soru ve yanıtların gerçekten sayfada bulunması gerekir; ayrıca Google’ın hangi zengin sonuç türlerini desteklediği değişebilir. Güncel belgeyi kontrol edin.
Yanlış sayfada doğru kod
Tekil makale için uygun BlogPosting kodunu kategori arşivine kopyalamak, arşivi makale yapmaz. Benzer şekilde bir ürün sayfasında Article işaretlemesi bulunması ana içeriği tam anlatmayabilir. Özellikle WooCommerce kurulumunda ürün şablonunu blog şablonundan ayrı ele alın. Her sayfa türünden örnek test etmek, tek bir yazıya bakarak “site tamam” demekten daha güvenilir sonuç verir.
Güncellenmeyen eklenti veya tema şablonu
Bir tema güncellemesi başlık ya da yazar alanını değiştirebilir. SEO eklentisi sürümüyle tema şablonu birlikte çalıştığında beklenmedik yeni nesneler oluşabilir. Güncelleme sonrasında makale, kategori ve ana sayfa örneklerinde kaynak kodu yeniden kontrol edin. Sorunun başladığı sürümü ve etkilenen URL örneklerini not almak, geri alma veya düzeltme sürecini hızlandırır.
Uygulanabilir kontrol listesi
- Sayfanın tekil makale mi, arşiv mi, ürün mü olduğunu belirleyin.
- Canlı sayfada üretilen JSON-LD ve
@typedeğerlerini bulun. - Bir makale için yazar, başlık, tarih, görsel ve asıl URL’yi görünür içerikle karşılaştırın.
- Birden fazla üretici varsa çelişen makale nesnelerini giderin.
- Breadcrumb varsa görünen gezinme yoluyla aynı sırayı ve bağlantıları kullandığını doğrulayın.
- Rich Results Test ve Schema Markup Validator sonuçlarını ayrı ayrı okuyun.
- Yayımdan sonra önbellekli canlı URL’yi yeniden test edin.
- Search Console’da dizin durumu ve ilgili raporları zaman içinde izleyin.
Sık sorulan sorular
Schema markup doğrudan sıralama yükseltir mi?
İşaretleme, arama motoruna içerik hakkında açık veri sunar ve desteklenen zengin sonuç türlerine uygunluk sağlayabilir. Her sorguda daha üst sıraya çıkma sözü vermez. Organik performansı değerlendirirken içerik kalitesi, taranabilirlik, sayfa deneyimi ve kullanıcı niyeti gibi başlıkları da ele alın. Test aracındaki başarılı sonuç ile arama trafiğindeki değişimi aynı metrik gibi okumayın.
Her yazı için ayrı JSON-LD kodu yazmalı mıyım?
WordPress’teki SEO eklentisi şablon üzerinden doğru BlogPosting verisi üretiyorsa her yazıya elle kod eklemeniz gerekmez. Asıl iş, şablondan gelen alanların her yazıda doğru dolduğunu denetlemektir. Farklı yazarların, eski makalelerin ve öne çıkan görseli olmayan içeriklerin örneklerini test edin. Elle ekleme, özel ihtiyaç ve tekil sorumluluk gerektirir; geniş bir sitede bakım yükünü artırır.
Google test aracı neden schema.org doğrulayıcısından farklı sonuç veriyor?
Schema Markup Validator genel Schema.org sözdizimini ve özelliklerini inceler. Google Rich Results Test ise Google’ın desteklediği belirli arama görünümlerine odaklanır. Bu nedenle bir tür genel olarak geçerli olduğu hâlde Rich Results Test’te zengin sonuç öğesi olarak görünmeyebilir. Tersi durumda aracın gösterdiği uyarılar da Google’a özgü tavsiyeler olabilir. İki aracı birbirinin yerine kullanmayın.
Bir sayfada Article ve BreadcrumbList beraber olabilir mi?
Evet, farklı bilgileri anlattıkları için beraber bulunabilirler. Makale nesnesi içeriği, breadcrumb nesnesi ise gezinme yolunu tanımlar. Ayrıca WebSite veya Organization gibi site düzeyindeki nesneler de grafikte görülebilir. Her nesnenin gerçek sayfa yapısını temsil etmesi ve ilişkili URL’lerin tutarlı olması gerekir. “Daha çok tür eklemek daha iyi SEO” şeklinde bir kural yoktur.
Yapılandırılmış veri değişikliğinden sonra sonuç ne zaman görünür?
Önce yeni HTML’in canlı URL’de sunulduğundan emin olun. Ardından Google sayfayı yeniden tarayıp değerlendirmelidir. Bunun için sabit bir süre veya zengin görünüm garantisi yoktur. Search Console’da URL incelemesi ve uygun raporlarla değişimi izleyin. Önbellek nedeniyle testte eski çıktı görünüyorsa önce sitenin kendi dağıtım zincirini kontrol edin; sırf beklemek yanlış veriyi düzeltmez.
Sonuç: doğru veriyi tek kaynaktan üretin
Schema markup için en verimli sıra şudur: sayfanın gerçek türünü belirleyin, mevcut çıktıyı görün, görünür içerikle karşılaştırın, gerekiyorsa tek kaynaktan düzeltin ve canlı URL’yi doğrulayın. Blog yazısında başlık, yazar, tarihler, görsel ve URL gibi alanlar başlangıç noktasıdır. Breadcrumb ve diğer türleri yalnızca sayfanın gerçekten sunduğu bilgiyi anlatıyorsa kullanın. Düzenli örnek denetimi, bir defalık kurulumdan daha değerlidir.
Kaynaklar: Google: Yapılandırılmış veriye giriş, Google: Article işaretlemesi, Google: Breadcrumb işaretlemesi, Google: Yapılandırılmış veri politikaları.
