Basın Bülteninizi NewsArticle Schema ile Etiketlemek: AI Atıfı için Beş Zorunlu Alan

AI motorlarının atıf yaptığı kaynak, Google'ın indexlediği yapılandırılmış veri katmanıdır. Basın bülteninizi schema.org NewsArticle'ın beş zorunlu alanı, doğru canonical URL ve disiplinli dateModified ile etiketlemek atıf almayı garantilemez; fakat atıf alma ihtimalini ölçülebilir biçimde temizler. AI Overviews ve Gemini'nin gördüğü sinyal Googlebot'un parse ettiği JSON-LD ile aynı yerden gelir — orayı temiz tutmak görünür olmanın altyapısıdır.

NewsArticle schema neden AI atıfının zemini

NewsArticle, schema.org'un haber içeriği için tanımladığı bir Article alt türüdür ve headline, datePublished, dateModified, author ile publisher gibi alanları kapsar (schema.org — NewsArticle). Bu bir hack değil; yayıncıların gerçekleri makine tarafından okunabilir biçimde sunmak için 2010'ların başından beri kullandığı standart.

Google'ın yapılandırılmış veri dokümantasyonu, Article ve NewsArticle markup'ından parse ettiği alanlar arasında author, datePublished, dateModified, headline, image ve publisher'ı sayar; publisher için iç içe bir Organization ve içinde logo ImageObject zorunludur (Google Search Central — Article structured data). AI Overviews ve Gemini aynı index katmanından beslendiği için bu alanları doldurmak, AI motorlarına vermek istediğiniz cevabı düzgün sunmanın yoludur.

Önce şunu net söyleyelim: schema markup gerekli bir altyapıdır, atıf garantisi değildir. Perplexity'nin ya da ChatGPT'nin neyi gerektirdiğini kanıtlayamayız. Kanıtlayabildiğimiz şey schema.org ve Google'ın kamuya açık şartlarıdır — ve AI motorları aynı sayfaları tarar.

Google'ın Article spec'inde beş zorunlu alan

Google'ın Article dokümanı şu alanları okur: headline (önerilen 110 karakterden kısa metin), image (en az bir taranabilir URL), datePublished (ISO 8601), dateModified (ISO 8601, datePublished'tan ayrı) ve iç içe Person/Organization objesi olarak author ile publisher.

İşte beş alanı doğru bağlayan minimal bir JSON-LD:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "Şirketimiz Series A turunda 12 milyon TL yatırım aldı",
  "image": "https://prfect.example/newsroom/series-a/cover.jpg",
  "datePublished": "2026-04-28T09:00:00+03:00",
  "dateModified": "2026-04-28T09:00:00+03:00",
  "author": {
    "@type": "Person",
    "name": "Defne Aydın",
    "@id": "https://prfect.example/team/defne"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Prfect",
    "@id": "https://prfect.example/#org",
    "logo": {
      "@type": "ImageObject",
      "url": "https://prfect.example/logo.png",
      "width": 600,
      "height": 60
    }
  }
}
</script>

Beş alandan biri eksikse Rich Results Test bunu uyarı ya da hata olarak gösterir; markup geçerli sayılmaz.

Canonical URL: bir bülten = bir URL = bir atıf hedefi

Google'ın canonicalization dokümanı, rel=canonical etiketinin aynı içerik birden çok URL'de göründüğünde tercih edilen URL'yi sinyallediğini ve Search'in tek bir canonical seçtiğini açıklar (Google Search Central — Canonicalization).

Basın bülteninde sorun şu: aynı içerik en az üç yerde yayınlanır — marka haber merkezi, dağıtım servisi (AA, Business Wire) ve içeriği yeniden yayınlayan haber siteleri. Canonical disiplini yoksa atıflar bu versiyonlar arasında dağılır.

Pratik kural net:

• Marka haber merkezi URL'si canonical'dır
• Wire ve syndication versiyonları rel=canonical ile haber merkezine işaret eder
• Yanlış canonical'da Google başka bir versiyonu canonical seçer; AI atıfları o versiyona gider

Örnek: https://prfect.example/newsroom/series-a canonical olsun. Anadolu Ajansı'nın aynı bülteni yayınladığı URL <link rel="canonical" href="https://prfect.example/newsroom/series-a"> etiketi taşır. Böylece atıf ve otorite değeri marka URL'sinde toplanır.

dateModified vs datePublished: motorların yeniden sıraladığı tazelik sinyali

datePublished bir kez ayarlanır. dateModified gövde değiştiğinde güncellenir. AI motorları zaman duyarlı sorgularda yakın tarihli kaynakları tercih eder.

İki klasik hata vardır:

1. Bülten gövdesini düzeltip dateModified'ı güncellememek — motorlar bayat sinyal görür
2. Her yazım hatası düzeltmesinde dateModified'ı yenilemek — motorlar boş değişiklik tespit ederse güvenilirlik düşer

Kural basit: dateModified'ı sadece içerik anlamında bir değişiklik olduğunda güncelle — sayılar, alıntılar, resmi düzeltmeler.

Somut örnek: Series A turunu 10 milyon TL olarak duyurduğunuzu varsayın. Sonradan rakam 12 milyon TL olarak güncellendi. Bu dateModified'ı yeniler — gövdedeki sayı değişti, motorların yeniden index'lemesi anlamlı. Buna karşın aynı bültende bir yazım hatasını düzeltmek dateModified'ı tetiklemez; sinyal boş olur.

Author ve publisher: Person ve Organization olarak bağlayın, düz metin değil

publisher; name, logo (Google'ın dokümanına göre boyutu belirtilmiş ImageObject) içeren bir Organization objesi olmak zorundadır. author ise Person (adı geçen sözcü) ya da Organization olabilir; Google ikisinin de yapılandırılmış biçimde olmasını ister.

AI atıfı için neden önemli? publisher ve author objeleri, motorların alıntı ya da iddiayı bağlayabileceği sabit bir entity sunar. Bir AI motoru "Prfect Sözcüsü Defne Aydın açıkladı ki..." cümlesini kurarken entity grafında bağlı bir Person görmek ister.

Yan yana karşılaştırma:

Anti-pattern (düz metin)	Doğru (yapılandırılmış obje)
"author": "İletişim Ekibi"	"author": { "@type": "Person", "name": "Defne Aydın", "@id": "..." }
"publisher": "Prfect"	"publisher": { "@type": "Organization", "name": "Prfect", "logo": { ... } }

Düz metin author ile motor güvenilir biçimde atıf yapamaz; kim olduğunu, hangi kuruma bağlandığını, daha önce ne yazdığını çözemez. Yapılandırılmış obje bu grafı kurar.

Yaygın bir hata: publisher.logo objesinde width ve height belirtilmemiş olması. Rich Results Test bu durumda uyarı verir — Google logo'yu render edebilmek için bu alanları okumak ister.

Doğrulama akışı: iki ücretsiz araç, bülten başına üç dakika

Yayınlamadan önce iki aracı sırayla çalıştırın:

1. Google Rich Results Test — JSON-LD'nizi Google'ın hatasız parse ettiğini gösterir; hata ve uyarıları Google'ın gözünden sıralar.
2. schema.org Markup Validator — schema.org vocabulary'sine uygunluğu doğrular; herhangi bir arama motorunun parse kurallarından bağımsız.

İkisini de çalıştırın çünkü farklı sınıf hataları yakalarlar. Rich Results Test'te sadece uyarı (hata değil) görürseniz vakaya göre karar verin; hata varsa yayınlamadan önce düzeltin.

Son checklist:

• Beş alan dolu: headline, image, datePublished, dateModified, author, publisher
• canonical etiketi marka haber merkezine işaret ediyor
• dateModified disiplini var (sadece içerik değişikliğinde güncelle)
• publisher ve author yapılandırılmış obje, düz metin değil
• Her iki doğrulayıcı yeşil

Bir ek not: Google'ın crawler dokümanı, Google-Extended adlı ayrı bir product token tanımlar; yayıncılar bu token ile içeriklerinin Gemini ve Vertex AI generative API'lerini iyileştirmek için kullanılıp kullanılmayacağını ayrı kontrol edebilir, ama Googlebot indexlemeye dokunulmaz (Google Search Central — Overview of Google crawlers). robots.txt'inizde Google-Extended'ı bloklasanız bile schema markup'ınız Search'te görünmeye, oradan da AI Overviews atıflarına aday olmaya devam eder.

Bu beş alanı doğru biçimde dolduran bir akış için basın bülteni hazırlama ekranımıza bakabilirsiniz; haber merkezi mimarisine dair bağlantılı yazılar için blog.