Aynı blog yazısını iki kopya halinde düşünün. Birincisinde sayfada hiçbir yapılandırılmış veri yok, ikincisine Article işaretlemesi eklenmiş. Google iki kopyayı da tarar, ikisini de dizine ekler ve ikisi de aynı sorgularda aynı şekilde yarışır. Aradaki fark, Google'ın sayfa hakkındaki bilgiyi nereden aldığıdır: şemasız kopyada başlığı title etiketinden çıkarmak, tarihi metnin içinden veya URL kalıbından tahmin etmek, yazarı da imza satırından anlamaya çalışmak zorundadır. Şemalı kopyada bu dört bilgi tahmin edilmez, beyan edilir.
Bu ayrım kulağa küçük geliyorsa doğru duymuşsunuz demektir. Article işaretlemesi bir sıralama sinyali değildir ve Google, yapılandırılmış veri kullanan özelliklerin arama sonuçlarında görüneceğine dair garanti vermez. Kazandırdığı şey daha dar ve daha somut: arama sonucunda gösterilen başlık metninin, görselin ve tarih bilgisinin daha doğru olma ihtimali, bir de yazar ile yayıncı ilişkisinin makine tarafında tartışmaya kapanması. Sıradan bir blog için bu şema teknik hijyendir, görünürlük kaldıracı değildir. Bu yazı da onu hijyen düzeyinde doğru kurmakla ilgili.
Article NewsArticle ve BlogPosting hangi hiyerarşide durur
Üç tür de aynı soydan gelir ama zincirdeki yerleri farklıdır. Schema.org sözlüğünde Article, CreativeWork sınıfının altındadır. NewsArticle doğrudan Article'ın alt türüdür. BlogPosting ise yaygın olarak anlatıldığı gibi Article'ın doğrudan çocuğu değildir: araya SocialMediaPosting girer.
| Tür | Schema.org zinciri | Tipik kullanım |
|---|---|---|
| Article | Thing > CreativeWork > Article | Tür ayrımına ihtiyaç duymayan her makale, rehber ve inceleme |
| NewsArticle | Thing > CreativeWork > Article > NewsArticle | Haber niteliğinde, yayın anı bilginin parçası olan içerik |
| BlogPosting | Thing > CreativeWork > Article > SocialMediaPosting > BlogPosting | Bir blogun parçası olarak yayımlanan yazı |
Pratik sonuç ilk bakışta göründüğünden sadedir. Google'ın makale dokümanı bu üç türü eşit kabul eder: makale nesnesinin Article, NewsArticle veya BlogPosting türlerinden birine dayanması yeterlidir. Yani BlogPosting seçtiğiniz için bir görünüm hakkı kaybetmezsiniz, Article seçtiğiniz için de fazladan bir şey kazanmazsınız.
Seçim yine de önemlidir, çünkü şema yalnız Google'ın makale özelliği için okunmaz. Tür bildirimi, sayfanın ne olduğuna dair kalıcı bir beyandır ve varlık ilişkileri, dahili sınıflandırma, arşiv devri gibi işlerde sonradan işinize yarar. Karar kuralı basit tutulabilir: yazı bir blogun parçası olarak yayımlanıyorsa BlogPosting, yayın anı ve olay güncelliği içeriğin özüyse NewsArticle, ikisi de tam oturmuyorsa Article. Yanlış tür seçmenin cezası yoktur, ama gereksiz spesifik tür seçmenin de ödülü yoktur.
Kullanım yaygınlığı da bu sıralamayı doğruluyor. Schema.org'un kendi kullanım paneline göre Article on milyondan fazla alan adında, BlogPosting bir ila on milyon alan adında, NewsArticle ise yüz binle bir milyon arasında alan adında görülüyor. Genel tür en çok tercih edilen, en spesifik tür en az tercih edilen tür.
Google bu şemada hangi alanları istiyor
Buradaki en yaygın yanlış bilgi zorunlu alan listeleridir. Google'ın makale dokümanının açık ifadesi şudur: zorunlu özellik yoktur. İçeriğiniz için geçerli olan önerilen özellikleri eklemeniz yeterlidir. Yani "şu alanları koymazsanız hata alırsınız" diye aktarılan listeler bu şema için doğru değildir.
Google'ın desteklediği ve önerdiği alanlar yedi tanedir.
| Alan | Tip | Ne işe yarar |
|---|---|---|
| author | Person veya Organization | Makalenin yazarını bildirir, kişi ile kurum ayrımını netleştirir |
| author.name | Text | Yalnızca yazarın adı |
| author.url | URL | Yazarı benzersiz biçimde tanımlayan sayfa: profil, biyografi veya hakkında sayfası |
| headline | Text | Makalenin başlığı, kısa ve öz olması önerilir |
| image | ImageObject veya URL, tekrarlanabilir | Makaleyi temsil eden görsel |
| datePublished | DateTime | İlk yayın tarihi ve saati, ISO 8601 biçiminde |
| dateModified | DateTime | Son değişiklik tarihi ve saati, ISO 8601 biçiminde |
Listede olmayanlara da bakmak gerekiyor. Google'ın makale dokümanı geçmişte AMP sayfalar için ayrı bir gereksinim seti tutuyor ve o sette yayıncı logosunun koşulları tanımlanıyordu. Bugünkü dokümanda AMP ile AMP olmayan sayfa ayrımı yer almıyor, çünkü ayrı bir zorunlu alan seti de kalmadı. Hâlâ dolaşımda olan "publisher logosu şu piksel ölçüsünde olmalı" tipi koşullar bu eski ayrımın kalıntısıdır ve bugün bir uygunluk şartı değildir.
Bunun tersi de doğru. Bir alanın Google'ın önerilen listesinde olmaması onu yanlış yapmaz. publisher, mainEntityOfPage, articleSection, inLanguage gibi alanlar geçerli Schema.org özellikleridir ve varlık tutarlılığı açısından değer taşırlar; sadece bu özellik için gerekli değildirler. Ayrım şudur: bunları eklemek zararsızdır, eklemediniz diye eksik kurulum yapmış olmazsınız.
Bir blog yazısı için JSON-LD nasıl görünür
Google üç biçimi de destekler (JSON-LD, mikro veri, RDFa) ve işaretleme geçerliyse üçü de aynı sayılır. Yine de önerilen biçim JSON-LD'dir, çünkü uygulaması ve bakımı en kolay olanıdır: işaretleme kullanıcının gördüğü metnin arasına serpiştirilmez, tek bir blok halinde durur ve iç içe veri yapılarını taşımak kolaylaşır.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Article ve BlogPosting Şemaları Nasıl Uygulanır",
"image": [
"https://ornek.com/gorsel/1x1/article-sema.jpg",
"https://ornek.com/gorsel/4x3/article-sema.jpg",
"https://ornek.com/gorsel/16x9/article-sema.jpg"
],
"datePublished": "2026-03-04T09:00:00+03:00",
"dateModified": "2026-05-19T14:30:00+03:00",
"author": [
{
"@type": "Person",
"name": "Ada Yılmaz",
"url": "https://ornek.com/yazar/ada-yilmaz",
"jobTitle": "Teknik SEO Editörü"
},
{
"@type": "Person",
"name": "Kerem Aydın",
"url": "https://ornek.com/yazar/kerem-aydin"
}
],
"publisher": {
"@type": "Organization",
"name": "Örnek Yayın",
"url": "https://ornek.com"
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://ornek.com/blog/article-semasi"
}
}
</script>Bu blok sayfanın head veya body bölümüne konabilir. İki yazarın ayrı ayrı listelenmesi, saatlerin saat dilimiyle yazılması ve üç farklı en boy oranında görsel verilmesi tesadüf değil; üçü de aşağıda tek tek açılıyor.
author alanı E-E-A-T ile nasıl ilişkilidir
Yazar işaretlemesi hakkında en çok abartılan iddia şudur: author alanı eklemek sayfaya uzmanlık puanı kazandırır. Böyle çalışmıyor. Şema, olmayan bir uzmanlığı yaratmaz; var olan bir kimliği makine tarafında belirsizlikten kurtarır. Sayfada zaten görünen bir yazar imzası, o imzanın arkasında gerçek bir kişi ve o kişinin doğrulanabilir bir geçmişi varsa author alanı bu bağı açık hale getirir. Bunların hiçbiri yoksa alanı doldurmak hiçbir şeyi değiştirmez.
Buradaki gerçek katkı ayrıştırmadır. author.url, yazarı benzersiz biçimde tanımlayan bir sayfaya işaret eder: sosyal medya profili, hakkında sayfası veya biyografi sayfası. URL sitenizin kendi profil sayfasıysa Google o sayfayı ProfilePage yapılandırılmış verisiyle işaretlemenizi öneriyor. Alternatif olarak sameAs kullanılabilir; Google yazarları belirlerken hem url hem sameAs alanını anlayabiliyor. Bu, aynı adı taşıyan başka kişilerden ayrılmak için elinizdeki tek net yöntemdir ve yazar biyografisi sayfalarının asıl teknik gerekçesi de budur.
Google'ın yazar işaretlemesi için verdiği en iyi uygulamalar da bu ayrıştırma mantığından çıkıyor. author.name alanında yalnızca yazarın adı bulunmalı; yayıncının adı publisher alanına, iş unvanı jobTitle alanına, saygı ifade eden önek ve sonekler honorificPrefix ile honorificSuffix alanlarına yazılır. "Yazan" gibi tanıtım kelimeleri isim alanına girmez. Yayıncı tarafını ayrı kurmak isteyenler için Organization ve sameAs profillerinin nasıl bağlandığı ayrı bir konudur.
Tarih alanları ne zaman gerçekten işe yarar
datePublished ve dateModified alanlarının ikisi de ISO 8601 biçiminde yazılır ve Google saat dilimi bilgisini vermenizi öneriyor. Vermezseniz varsayılan olarak Googlebot'un kullandığı saat dilimi kabul edilir, yani yayın saatiniz kaymış olarak okunur. Bu, günlük yayın yapan sitelerde sıralama değil doğruluk sorunudur: sabah yayımladığınız yazının bir önceki gün yayımlanmış gibi anlaşılması mümkündür.
Bu iki alan hakkında dikkat edilecek küçük bir davranış detayı var. Zengin Sonuçlar Testi bu alanlar için uyarı göstermez, çünkü bunlar yalnızca sitenize uygun olduğuna karar verdiğinizde önerilen alanlardır. Yani aracın sessiz kalması alanların gereksiz olduğu anlamına gelmiyor; aracın onları isteğe bağlı sayması anlamına geliyor.
Asıl risk dateModified'ın yanlış kullanımıdır. İçeriğe dokunmadan güncelleme tarihini ileri almak, sayfayı taze göstermenin yolu değildir; şemadaki beyanla sayfadaki içeriğin çeliştiği bir durum yaratır. Tarih alanı, gerçekten yapılan bir değişikliği bildirdiğinde işe yarar. Sadece tarihi değiştirmek, hiçbir şeyi değiştirmemektir.
image alanının çoğu blogda atlanan gereksinimleri
Görsel alanı, listedeki alanlar içinde en çok koşulu olan alan. Google'ın yönergeleri şunları istiyor: görsel URL'leri taranabilir ve dizine eklenebilir olmalı, görseller işaretlenen içeriği göstermeli, Google Görseller tarafından desteklenen bir dosya biçiminde olmalı. Bunlara ek bir öneri de var: en iyi sonuç için 16x9, 4x3 ve 1x1 en boy oranlarında, genişlik ile yükseklik çarpımı en az 50 bin piksel olan yüksek çözünürlüklü birden fazla görsel sağlanması.
Bu son madde pratikte en sık atlanan yerdir. Çoğu blog tek bir yatay kapak görselini image alanına yazar ve bırakır. Üç oranın birden verilmesi, farklı yüzeylerde farklı kırpma ihtiyaçlarının karşılanmasını sağlar; tek oran verdiğinizde kırpma kararı size değil sisteme kalır.
Bir diğer sık hata da görselin ne olduğuyla ilgili. Google açıkça logo veya başlık şablonu yerine makaleyle alakalı görsel kullanılmasını söylüyor. Her yazıya aynı marka kapağını basan otomasyonlar bu koşulu teknik olarak geçerli görünse de anlam olarak boş bir işaretleme üretir: görsel, işaretlenen içeriği göstermiyordur.
Bu şema neyi getirir neyi getirmez
Article işaretlemesinin somut karşılığı, Google'ın makaleyi daha iyi anlaması ve Arama ile diğer Google yüzeylerinde daha iyi başlık metni, görsel ve tarih bilgisi gösterebilmesidir. Doğrudan söylenmesi gereken bir sınır da var: Google Haberler'in "en çok okunan haberler" gibi özelliklerinden yararlanmak için bu işaretlemenin bulunması şart değildir. İşaretleme oraya girmenin bileti değil, içeriğinizin ne olduğunu daha açık anlatmanın yoludur.
Bunun üstüne Google'ın genel kuralı geliyor: yapılandırılmış veri kullanan özelliklerin arama sonuçlarında görüneceği garanti edilmez. Şema uygunluk üretir, sonuç üretmez. Sayfanıza yapılandırılmış veriyle ilgili manuel bir işlem uygulanmışsa şema büsbütün dikkate alınmaz, üstelik sayfa arama sonuçlarında görünmeye devam edebilir. Yani işaretleme kaybedilebilir bir ayrıcalıktır, kazanılmış bir hak değildir.
Bu çerçeveyi tersinden okumak daha yararlı olabilir. Article şeması sayfanızın sıralamasını yükseltmez, dizine girmesini sağlamaz, içeriğinizi iyileştirmez. Yaptığı tek şey, Google'ın zaten yapmaya çalıştığı çıkarımı tahmin olmaktan çıkarmaktır. Bu, küçük ama sürekli bir kazançtır ve tam olarak bu yüzden hijyen sayılır.
Şema yapay zeka alıntısını artırır mı
Son dönemde en çok tekrarlanan iddia, yapılandırılmış verinin yapay zeka cevaplarında alıntılanma şansını artırdığıdır. Bu iddianın kaynağı genellikle bir korelasyondur ve korelasyonun kendisi gerçektir: milyonlarca URL üzerinde yapılan bir incelemede yapay zeka tarafından alıntılanan sayfaların JSON-LD taşıma ihtimali, alıntılanmayanların yaklaşık üç katı çıkmış, alıntılanan sayfaların yarısından fazlasında şema bulunmuş.
Sorun, bu korelasyonun nedensellik gibi okunmasıdır. Aynı araştırma ekibi işi bir adım ileri götürüp JSON-LD ekleyen 1.885 sayfayı, eşleştirilmiş yaklaşık dört bin kontrol sayfasıyla karşılaştırmış. Sonuç, en güvendikleri eşleştirilmiş fark-içinde-fark testine göre şöyle: AI Overviews tarafında yüzde 4,6'lık küçük bir düşüş (iki grup da düşüyordu, şema ekleyenler biraz daha hızlı düştü), AI Mode tarafında yüzde 2,4, ChatGPT tarafında yüzde 2,2 artış. Son ikisi istatistiksel olarak sıfırdan ayırt edilemiyor.
Bu çalışmanın en öğretici yanı sayıların kendisi değil, ham veriyle düzeltilmiş veri arasındaki farktır. Aynı sayfaların AI Mode alıntılarındaki ham öncesi ve sonrası büyümesi yüzde 43 çıkmış. Kontrol grubu da neredeyse aynı oranda büyüdüğü için, yani platformun tamamı büyüdüğü için, bu yüzde 43 düzeltildiğinde yüzde 2,4'e iniyor. "Şema ekledik ve alıntılarımız arttı" biçimindeki vaka anlatılarının çoğu tam olarak bu düzeltmeyi yapmıyor.
Bulgunun kapsamını olduğu gibi bırakmak gerekiyor. İncelenen sayfaların hepsi çalışma öncesinde zaten yoğun biçimde alıntılanan, yani değerlendirme havuzunun içindeki sayfalardı; hiç görülmeyen bir sayfa için şemanın ne yaptığı bu veriyle cevaplanmıyor. Ayrıca JSON-LD ekleyen sayfalar genelde aynı anda başka şeyleri de değiştiriyor ve tüm şema türleri tek havuzda toplanmış. Bu yüzden bulgu bir yasa değil, güçlü bir yön göstergesidir.
Buna ilişkin ikinci bir gözlem, gerçek zamanlı çekim tarafından geliyor. Beş yapay zeka sisteminin (ChatGPT, Claude, Perplexity, Gemini ve Google AI Mode) bir sayfayı canlı çekerken şemayı kullanıp kullanmadığını sınayan bir deneyde hiçbiri kullanmamış; hepsi yalnızca görünür HTML metnini çıkarmış, JSON-LD ile gizli mikro veri ve RDFa yok sayılmış. Bu, alıntılanma tarafında işi yapan şeyin sayfada okunabilir biçimde duran içerik olduğu fikriyle uyumlu. Yapay zeka cevaplarında alıntılanan içeriğin nasıl yazıldığı ayrı bir konu ve şema o konunun cevabı değil.
Sonuç dengeli olmalı. JSON-LD kullanmak için hâlâ iyi gerekçeler var: zengin sonuçlar, sesli asistanlar, bilgi grafiği ve aşağı akıştaki varlık tanıma. Ama zaten görünür durumdaki sayfalarda yapay zeka alıntısı artsın diye şema eklemek, eldeki veriyle desteklenen bir bahis değil.
En sık yapılan yedi işaretleme hatası
- Sayfada görünmeyen bilgiyi işaretlemek. Şema, kullanıcıya gösterilen içeriği yansıtmalıdır. Bunun ikinci bir gerekçesi de var: canlı çekim deneyinde yapay zeka sistemleri gizli işaretlemeyi tamamen yok saydı. Görünmeyen içeriği işaretlemek iki tarafta da karşılık bulmuyor.
- dateModified'ı içerik değişmeden ileri almak. Yapay tazelik üretmez, şema ile sayfa arasında çelişki üretir.
- Tarihlere saat dilimi yazmamak. Saat dilimi yoksa Googlebot'un saat dilimi varsayılır ve yayın anı kayar.
- author.name alanını unvan ve kurum adıyla doldurmak. Bu alan yalnızca adı taşır; unvan jobTitle, yayıncı publisher, önek ve sonek honorificPrefix ile honorificSuffix alanlarına gider.
- Birden çok yazarı tek dizede birleştirmek. Her yazar kendi author girdisinde listelenir; iki ismi virgülle tek bir name değerine sıkıştırmak Google'ın açıkça uyardığı kalıptır.
- image alanına logo veya sabit şablon kapağı vermek. Görsel makaleyle alakalı olmalı ve işaretlenen içeriği göstermelidir.
- Tema ve eklentinin aynı sayfaya iki ayrı makale nesnesi basması. İçerik yönetim sistemlerinde en sık görülen çakışma budur; iki farklı kaynak aynı sayfa için birbiriyle uyuşmayan headline veya tarih beyan eder.
Bu yedi maddenin altısı aynı ilkeye çıkıyor: şema sayfanın kendisiyle aynı şeyi söylemelidir. Yapılandırılmış veri bir pazarlama alanı değil, sayfanın makine tarafındaki kopyasıdır ve kopyanın aslından farklı olması onu değersizleştirir.
Doğrulama ve bakım döngüsü
Kurulumun ardından doğrulama iki araca dayanır ve ikisi farklı soruları cevaplar. Zengin Sonuçlar Testi işaretlemenin geçerliliğini gösterir; buradaki kritik hatalar düzeltilmelidir. Aracın işaretlediği kritik olmayan sorunları düzeltmek de verinin kalitesini artırır ama zengin sonuç uygunluğu için gerekli değildir, yani her uyarıyı kapatmak zorunda değilsiniz. Bu ayrımın pratikteki karşılığı Rich Results Test doğrulama akışında daha ayrıntılı işleniyor.
İkinci araç URL Denetleme aracıdır ve daha temel bir soruyu cevaplar: Google sayfaya gerçekten erişebiliyor mu? Sayfanın robots.txt tarafından engellenmediğinden, noindex etiketi taşımadığından ve giriş şartı arkasında olmadığından emin olmak gerekir. Erişilemeyen bir sayfadaki kusursuz şema hiçbir işe yaramaz.
Bakım tarafında beklenti yönetimi de gerekiyor. Google'ın yayımlanmış bir sayfayı bulup taraması birkaç gün sürebilir, dolayısıyla şema eklendikten sonraki ilk günlerde sonuç aramak yanıltıcıdır. Sağlıklı döngü şudur: şablon değiştiğinde, yazar yapısı değiştiğinde veya eklenti güncellendiğinde birkaç örnek sayfayı yeniden test etmek. Her yazıyı tek tek denetlemeye gerek yok; şema şablondan geldiği için hatalar da şablondan gelir ve bir sayfada görülen hata büyük olasılıkla bütün arşivdedir.
Sık sorulan sorular
Article yerine BlogPosting kullanırsam zengin sonuç şansımı kaybeder miyim?
Hayır. Google makale nesnesinin Article, NewsArticle veya BlogPosting türlerinden birine dayanmasını yeterli görüyor; üçü de aynı özellik için geçerli. Tür seçimi anlamsal doğrulukla ilgilidir, uygunlukla değil.
Aynı sayfada hem BlogPosting hem başka bir şema türü kullanabilir miyim?
Evet, farklı türler farklı özellikleri hedefler ve aynı sayfada birlikte bulunabilirler. Yaygın örnek, bir rehber yazısının hem makale hem de soru cevap bölümü taşımasıdır; FAQPage şemasının nasıl kurulduğu bu durumda ayrıca ele alınması gereken bir konudur. Dikkat edilecek tek şey, iki bloğun birbiriyle çelişen bilgi beyan etmemesidir.
İçerik yönetim sistemim şemayı otomatik üretiyorsa elle JSON-LD eklemeli miyim?
Önce eklentinin ne ürettiğine bakın. Çoğu durumda eklenti çıktısı yeterlidir ve üstüne elle blok eklemek çakışan iki makale nesnesi doğurur. Elle müdahale, eklentinin üretmediği alanları (örneğin çoklu görsel oranları veya yazar profil bağlantısı) tamamlamak için anlamlıdır.
Şemayı kaldırırsam sıralamam düşer mi?
Şema bir sıralama sinyali olmadığı için sıralamanızın doğrudan düşmesi beklenmez. Kaybedeceğiniz şey uygunluktur: Google'ın başlık, görsel ve tarih bilgisini beyandan değil tahminden üretmeye dönmesi ve şemaya bağlı görünüm özelliklerinin devre dışı kalmasıdır.
