Haber Sitesinde Article İşaretlemesi: Tarih ve Yazar

Haber sayfasında Article işaretlemesi kurarken en sık takılınan yer tarih ve yazar alanlarıdır. Kısa cevap şu: Google'ın Article belgesinde zorunlu özellik yoktur, ama datePublished, dateModified, author ve headline önerilen alanlar arasındadır. Tarihler ISO 8601 biçiminde ve saat dilimiyle yazılmalı, yazar alanında yalnızca kişinin ya da kurumun adı bulunmalı, işaretlenen her bilgi de sayfada okura görünen bilgiyle örtüşmelidir. Bu rehber geliştiriciler ve editörler için. Genel Article ve FAQ kurulumu için makale schema işaretlemesi rehberine bakabilirsiniz; burada yalnızca haber akışının tarih ve yazar sorunları var.

Haber sitesinde bu alanlar bir editör kararı ile bir şablon kararının kesiştiği yerdedir. Şablonu yazan kişi alan adlarını bilir, haberi yöneten kişi ise bir düzeltmenin ne zaman yapıldığını bilir. İki bilginin buluşmadığı yerde hatalı tarih çıkar.

Article, NewsArticle ve BlogPosting: tür seçimi ve önerilen alanlar

İşe Google'ın Article yapılandırılmış veri belgesinin (yeni sekmede açılır) söylediklerini ayırarak başlayalım. Belge, Article nesnesinin schema.org'daki üç türden birine dayanması gerektiğini söyler: Article, NewsArticle ve BlogPosting. Zorunlu özellik yoktur; belge, içeriğinize uyan özellikleri eklemenizi ister. Önerilen alanlar author, author.name, author.url, dateModified, datePublished, headline ve image olarak sıralanır.

Hangi içerik hangi türe girer

Belgenin tür seçimi için kesin bir karar tablosu vermediğini görüyoruz. Bu yüzden aşağıdaki eşleme bizim önerimizdir, Google'ın kuralı değildir. Olayı aktaran, güncel gelişmeyi anlatan bir haber raporu için NewsArticle, imzalı görüş ya da kişisel yazı için BlogPosting, dosya ve rehber gibi daha kalıcı içerik için Article kullanmak okuması kolay bir düzen kurar. En önemli kural tutarlılıktır: aynı tür içerik her zaman aynı türle işaretlenmeli, şablon başına tek karar verilmelidir.

Önerilen alanlar neden zorunlu değil ama önemli

Belgede zorunlu alan olmaması, alanları boş bırakmanın serbest olduğu anlamına gelmez; yalnızca eksik bir alanın işaretlemeyi geçersiz kılmadığı anlamına gelir. Belge dateModified için şu mantığı kurar: daha doğru tarih bilgisini Google'a iletmek istiyorsanız ekleyin. Aynı koşullu ifade datePublished için de geçer. Haber sitesinde bu iki alanı boş bırakmak, okurun sayfada gördüğü tarihin makine tarafından okunmasını şansa bırakmak demektir. Zahmetsiz bir alan olduğu için eklenmesini öneriyoruz.

Belge ayrıca Rich Results Test aracının bu iki özellik için uyarı vermediğini belirtir. Araç sessiz kaldığında hata olmadığı sonucuna varmak yanlıştır. Eksik, boş ya da yanlış tarih aracı uyarmaz; doğru olup olmadığına yalnızca sizin kayıtlarınız karar verir.

Yayıncı alanı belgede nerede duruyor

Publisher özelliği, belgedeki önerilen alan listesinde yer almaz. Yalnızca yazar örneklerinde, ad ve URL taşıyan bir kurum nesnesi olarak görünür. Bu nedenle yayıncı bilgisini işaretlemeye eklemek isteyebilirsiniz, ama yayıncı şeffaflığının asıl yeri sayfadaki görünür künye ve iletişim bilgisidir. Bu konuyu haber sitesinde tarih ve yazar bilgisi kontrolü yazısında okur tarafından ele aldık.

Güncellik notu

Google belgelerindeki alan listeleri ve örnekler değişebilir. Şablona dokunmadan önce Article sayfasının güncel hâlini açıp önerilen alanları kendi şablonunuzla karşılaştırın.

Tarih alanlarında sık yapılan hatalar

Tarih hataları çoğunlukla bilgi eksikliğinden değil, şablonun varsayılan davranışından çıkar. İçerik yönetim sistemi bir alanı otomatik doldurur, kimse bakmaz ve aylar sonra yanlış bir tarih binlerce sayfada yaşamaya devam eder. Bir haber şablonunu denetlerken şu noktalara tek tek bakın.

Biçim: ISO 8601 ve saat dilimi

Belge, tarihlerin ISO 8601 biçiminde verilmesini ister ve saat dilimi bilgisinin eklenmesini önerir. Saat dilimi yoksa Google'ın Googlebot'un kullandığı saat dilimini varsayacağı yazılıdır. Bu, Türkiye'de yayımlanan ve gece yarısına yakın saatlerde girilen haberlerde tarihin bir gün kaymasına yol açabilir. Çözüm basittir: saat farkını (örneğin +03:00) her zaman ekleyin ve sunucunun saat diliminin ayarını bir kez doğrulayın.

Yayın tarihi yerine kaydedilme tarihi yazmak

Bir haber taslak olarak bir gün önce kaydedilip ertesi gün yayımlanabilir. Şablon veritabanındaki oluşturulma tarihini datePublished'a yazarsa, işaretleme ile sayfada görünen yayın zamanı ayrışır. Alanın kaynağı, editörün yayına bastığı anı tutan alan olmalıdır; taslak oluşturma zamanı değil.

Aynı tarihin her yere yazılması

Bazı şablonlar datePublished ve dateModified için aynı değeri kullanır, düzeltme sonrası da ikisini birlikte günceller. İki alan aynı şey değildir: biri haberin ilk yayımlandığı anı, diğeri içeriğin anlamlı biçimde değiştiği anı anlatır. Birinci alanın bir haber boyunca sabit kalması beklenir.

Toplu yeniden kaydetme

Arşivdeki binlerce haber bir toplu işlemle yeniden kaydedildiğinde, dateModified alanı hepsinde aynı güne dönebilir. Bu, içeriğin değişmediği hâlde taze görünmesine yol açar. Toplu işlemden önce şablonun dateModified'ı yalnızca editoryal değişiklik olduğunda güncellediğinden emin olun.

Sık hataların kontrol listesi

• Tarihler ISO 8601 biçiminde mi ve saat farkı içeriyor mu?
• datePublished, editörün yayına bastığı zamanı mı gösteriyor?
• dateModified yalnızca anlamlı değişiklikte mi güncelleniyor?
• Sayfada görünen tarih ile işaretlemedeki tarih aynı zamanı mı anlatıyor?
• Toplu içe aktarma ve arşiv taşıma işlemleri dateModified'ı sıfırlıyor mu?
• Farklı dil sürümlerinde (TR ve EN) tarih biçimi ve saat farkı tutarlı mı?

Örnek senaryo: gece yarısı haberi

Örnek senaryo: Bir haber portalının editörü, olayı gece yarısına yakın bir saatte yayımlıyor. Şablon tarihi saat dilimi olmadan, yalnızca gün olarak yazıyor ve sunucu başka bir saat diliminde çalışıyor. İşaretlemedeki tarih sayfada görünen tarihten bir gün önceye ya da sonraya düşebiliyor. Haber aynı kalıyor, yalnızca makine tarafından okunan bilgi kayıyor. Düzeltme için şablona saat farkı eklenir, sunucu ayarı gözden geçirilir ve yayın saati sistemin kendi kaydından alınır.

Yazar ve yayıncı alanlarının doğru kurulumu

Yazar alanı, haber sitesinde hem okur güveni hem de makine okunabilirliği açısından tarihten daha hassastır; çünkü hata kişi adlarına dokunur. Google'ın yararlı içerik rehberi, okurun beklediği yerlerde doğru yazarlık bilgisi, örneğin imza satırı, eklenmesini kuvvetle önerir. Aynı sayfa, sahte yazar profili oluşturmayı (yapay zekâ ile üretilmiş portre, uydurma isim ve sahte yetki gibi) güveni zedeleyen bir aldatma biçimi olarak anar. Bu yüzden işaretleme, gerçekte var olan kişileri ve kurumları yansıtmalıdır. Ayrıntılar için Google'ın yararlı içerik rehberine (yeni sekmede açılır) bakabilirsiniz.

author.name alanına ne yazılır

Article belgesi, author.name özelliğine yalnızca yazarın adının yazılmasını ister. Yayıncı adı, unvan, hitap ya da “yazan” gibi tanıtıcı sözcükler bu alana konmaz; bunlar için ayrı özellikler (publisher, jobTitle, honorificPrefix, honorificSuffix) vardır. Haber şablonlarında en sık görülen hata, imza satırının olduğu gibi kopyalanmasıdır: “Haber Merkezi” ya da “Ad Soyad, Ankara” gibi içerikler alanı kirletir. Şehir bilgisi, ajans adı ve unvan alanın dışında kalmalıdır.

Birden çok yazar ve kurum yazarı

Belge, sayfada yazar olarak sunulan herkesin işaretlemeye de eklenmesini ister. Birden çok yazar varsa her biri ayrı bir author girdisi olmalıdır; adları tek alana birleştirmek önerilmez. Kişi için Person, kurum için Organization türü kullanılır. Haber sitesinde bir yazının editörü ve muhabiri ayrı kişilerse sayfada hangisi yazar olarak sunuluyorsa o işaretlenir. Ajans içeriğini aynen yayımlayan siteler, ajansın kurum olarak yazar gösterilip gösterilmeyeceğini sayfadaki imzaya göre kararlaştırmalıdır.

author.url ve sameAs

Belge, author.url alanının yazarı tekil olarak tanımlayan bir sayfaya işaret etmesini söyler. Yazar sayfası yoksa sameAs alternatif olarak kullanılabilir. Yazar sayfasını nasıl kuracağınız ayrı bir konudur; yazar sayfası hazırlama rehberinde adım adım anlatıyoruz. Önemli olan, bağlantının canlı, indekslenebilir ve gerçekten o yazarın işlerini listeleyen bir sayfaya gitmesidir.

Yayıncı bilgisi ve Google News tarafı

Google News içerik politikaları, haber kaynaklarından net tarih ve imza satırı beklediğini söyler. Aynı sayfa yazarlar, yayın ve yayıncı hakkında bilgi ile arkasındaki şirket ve iletişim bilgilerinin verilmesini ister. Politika sayfasında düzeltme ya da güncelleme konusu yazmıyor. Bu bilgilerin işaretlemeden önce sayfada görünür olması gerekir; işaretleme görünen bilgiyi tekrar eder, onun yerine geçmez. Ayrıntılar için Google News politikaları sayfasına (yeni sekmede açılır) bakın.

Yazar alanının sayfa ile uyumu

Yazar alanında da genel kural geçerlidir: işaretlenen bilgi okura görünen bilgiyle örtüşmelidir. Sayfada imza yoksa ve işaretlemede bir kişi adı varsa, bu uyumsuzluk hem okur güveni hem yapılandırılmış veri ilkeleri açısından sorundur. Tersi de geçerli: sayfada üç imza varsa işaretlemede yalnızca biri bulunması belgenin “hepsini ekleyin” talimatına uymaz.

dateModified ne zaman değişmeli: görünür metinle uyum

dateModified her kayıtta değişmeli mi? Hayır, değişmemelidir. Bu, belgeden okunan bir yasak değil, aşağıdaki iki Google ilkesinin birleşiminden çıkan bir sonuçtur. Birincisi yapılandırılmış veri ilkesi: işaretleme sayfa içeriğinin doğru bir temsili olmalı ve güncel bilgi vermelidir. İkincisi yararlı içerik rehberi: içerik anlamlı biçimde değişmemişken sayfa tarihini taze görünsün diye değiştirmek sakıncalı bir uygulama olarak anılır.

Anlamlı değişiklik nedir

Belge anlamlı değişikliğin tanımını vermez; bu tanımı editoryal politikanızda siz koymalısınız. Bizim önerimiz şu: okurun bilgisini, sonucu ya da yorumunu etkileyen her değişiklik anlamlıdır. Yazım hatası düzeltmek, bir bağlantıyı onarmak ya da biçim ayarı yapmak çoğunlukla anlamlı değişiklik sayılmaz. Bir olgunun, bir rakamın, bir ismin ya da bir sonucun değişmesi sayılır.

Karar kuralı

Kuralı üç soruya indirebiliriz. Birincisi: değişiklik okurun haberi anlayışını etkiliyor mu? Etkilemiyorsa dateModified'a dokunmayın. İkincisi: sayfada okura bu değişikliği gösteren bir ifade var mı? Yoksa önce görünür bir not ekleyin, çünkü makine tarihi okurun görmediği bir değişikliği taşıyamaz. Üçüncüsü: bu tarihi bir yıl sonra savunabilir miyim? Savunamıyorsanız değişikliği tarih olarak göstermeyin. Düzeltme ve güncelleme notlarının nasıl yazılacağı ayrı bir yazının konusudur.

Görünür tarih ile işaretleme tarihinin eşleşmesi

Google'ın Article belgesinde görünür tarih ile işaretleme tarihinin aynı olması gerektiğine dair açık bir cümle yer almaz. Yapılandırılmış veri ilkeleri ise işaretlemenin sayfada okura görünen içeriği yansıtmasını ve okurdan gizlenen içeriğin işaretlenmemesini ister. Bu iki bilgiyi birlikte okuyunca pratik kural nettir: sayfada “Güncelleme: 14.30” yazıyorsa dateModified da aynı anı göstermelidir; sayfada hiçbir güncelleme izi yokken dateModified yakın tarih taşıyorsa işaretleme sayfayı doğru temsil etmiyordur.

Görünür tarih biçimi

Okura görünen tarih yerel biçimde, makineye giden tarih ISO 8601 ile yazılır. İki biçim aynı zamanı anlatmalıdır; HTML'de zaman etiketinin makine okunur değeri de aynı değerle beslenmelidir. Şablonda iki ayrı kaynaktan tarih çekilmesi, uyumsuzluğun en yaygın nedenidir. Tek kaynak, iki gösterim kuralını uygulayın.

Arşiv haberlerinde tutarlılık

Eski haberler çoğu zaman düzeltme gerektirmez, ama şablon güncellemesi nedeniyle yeniden oluşturulur. Bu yeniden oluşturma dateModified'ı yenilememelidir. Arşiv sayfalarının tarihleri de görünür metinle aynı kaynaktan beslenmelidir.

Örnek senaryo: gelişen olay

Örnek senaryo: Bir yerel haber sitesi, bir yol kapanışını ilk saatlerde kısa bir haberle duyuruyor. Birkaç saat sonra yetkililer açıklama yapıyor ve haber güncelleniyor. Burada datePublished ilk yayın anında kalır, dateModified açıklamanın eklendiği ana taşınır ve sayfada “Güncelleme” notu görünür. Ertesi gün editör yalnızca başlıktaki bir yazım hatasını düzeltiyor; bu işlem dateModified'ı değiştirmez. Böylece tarih alanları okuru ve makineyi aynı gerçeğe götürür.

Doğrulama ve izleme

İşaretlemeyi kurmak işin yarısıdır. Kalan yarı, şablon her değiştiğinde doğruluğunu korumak ve sorunları erken yakalamaktır. Google'ın yapılandırılmış veri genel ilkeleri (yeni sekmede açılır) bu konuda üç şeyi öne çıkarır: işaretleme sayfa içeriğini doğru temsil etmeli, güncel bilgi vermeli ve JSON-LD tercih edilen biçim olmalıdır.

Hangi araçla, neye bakılır

Aynı belge, Rich Results Test ve URL Inspection araçlarının çoğu teknik hatayı yakaladığını, ancak bazı kalite sorunlarını otomatik araçların bulamayacağını belirtir. Yani araçtan geçmek, doğru tarih ve doğru yazar anlamına gelmez. Araçlar sözdizimini sınar; anlamı sizin kontrol listeniz sınar. Arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir.

Yayına almadan önce şablon kontrolü

1. Üç haber tipinden (gündem, köşe yazısı, dosya) birer örnek sayfa seçin.
2. Sayfada görünen tarih ve imzayı not edin.
3. İşaretlemedeki datePublished, dateModified ve author değerlerini yan yana koyun.
4. Rich Results Test ve URL Inspection ile aynı sayfaları sınayın.
5. Sonuçları kaydedin ve şablon sahibine geri bildirim verin.

Yayına aldıktan sonra izleme

Şablon değiştiğinde yapılandırılmış veri raporlarını izleyin. Manuel işlemler raporu da, yapılandırılmış veri sorununun manuel işleme yol açabileceği için kontrol listesinde yer almalıdır. Belge, bu tür bir işlemin zengin sonuç uygunluğunu etkilediğini ama sayfanın web aramasındaki sıralamasını doğrudan etkilemediğini söyler. Ayrıca Google, doğru işaretlemenin bile arama sonuçlarında gösterileceğini garanti etmez. Dolayısıyla amaç görünüm garantisi değil, doğru ve tutarlı bilgidir.

İki dilli sitelerde tutarlılık

TR ve EN sürümü olan bir haber sitesinde her dil sürümünün kendi işaretlemesi, kendi tarihi ve kendi yazar bilgisi olmalıdır. Bir sürümün çevirisi geç yapılıyorsa o sürümün datePublished değeri çevirinin yayın anını göstermelidir. Orijinal haberin tarihini çeviriye kopyalamak sayfada görünen tarihle uyumsuzluk yaratır.

Sorumluluk dağılımı

Alanların kalıcı olarak doğru kalması için görev paylaşımı yazılı olmalıdır. Geliştirici alan eşlemesinden ve biçimden, editör düzeltme ve güncelleme notlarının işlenmesinden, yayın yönetmeni tarih politikasından sorumludur. Üçünün tek sayfalık bir mutabakat notu, şablon değiştiğinde yeniden tartışmayı önler. Yapılandırılmış verinin genel kurgusu için JSON-LD rehberine bakabilirsiniz.

Ajans, konuk ve sponsorlu içerikte tarih ve yazar

Haber sitelerinin her sayfası kendi muhabirinden çıkmaz. Ajans haberi, konuk yazar metni ve sponsorlu içerik aynı şablondan geçer, ama her biri için yazar ve tarih sorusunun cevabı farklıdır. Şablon bu farkı bilmezse hepsini aynı varsayılan yazarla doldurur.

Ajans haberi

Ajansın metnini yayımlayan site, sayfada hangi imzayı gösteriyorsa işaretlemede de onu kullanmalıdır. Sayfada “Ajans” yazıyorsa kurum yazar olarak işaretlenebilir; sitenin editörünün adı yalnızca gerçekten metni düzenleyen ve imzası görünen kişi olduğunda eklenir. Ajansın verdiği ilk yayın saati ile sitenin yayına aldığı saat farklıysa, hangisinin datePublished'a gireceği editoryal politikada yazılı olmalıdır. Bizim önerimiz, sitede yayımlanma anını kullanmak ve ajansın saatini görünür metinde belirtmektir.

Konuk yazar

Konuk yazarın adı ve varsa yazar sayfası işaretlemeye girer; sitenin kendi adı yazar olarak bırakılmaz. Konuk yazının kimliğini doğrulamak yayıncıya aittir. Sahte ya da doğrulanamayan bir kişi adı, yararlı içerik rehberinin uyardığı aldatma türüne girer. Bu nedenle kimliği teyit edilmemiş metinde yazar alanını doldurmak yerine editoryal imza kullanmak daha güvenlidir.

Sponsorlu içerik

Google News politikaları, ücretli tanıtım içeriğinin açıkça belirtilmesini ve bağımsız editoryal içerik gibi gösterilmemesini ister. Bu kural işaretleme açısından da bir sonuç doğurur: sponsorlu bir yazının yazarı sitenin editörü gibi gösterilmemeli, tarih de gerçek yayın anını yansıtmalıdır. Sponsorlu içerik için tarih ve yazar kontrolünü yukarıda anılan tanıtım yazısı kontrolü yazısında ele aldık.

Belirtiden nedene: tarih ve yazar sorunlarını teşhis etmek

Bir hata bildirildiğinde ilk iş, sorunun şablonda mı yoksa tek bir kayıtta mı olduğunu ayırmaktır. Aşağıdaki tablo en sık görülen belirtileri olası nedenleriyle eşleştirir. Bu eşleme bir kontrol sırası önerisidir, Google'ın bir sınıflandırması değildir.

Sorunu kök nedene indirmek

Her belirtide aynı dört adımı izleyin. Önce sorunlu sayfadan ve sorunsuz bir sayfadan işaretlemeyi kaydedin. Sonra iki işaretlemeyi karşılaştırıp farkın hangi alanda başladığını bulun. Ardından o alanın şablonda hangi veri kaynağından beslendiğini izleyin. Son olarak düzeltmeyi şablonda yapın ve yalnızca tek tek sayfayı elle düzeltmekle yetinmeyin; çünkü kök neden şablondaysa elle düzeltme ertesi gün bozulur.

Düzeltmeden sonra ne beklenir

Şablon düzeltildikten sonra Google'ın sayfaları yeniden işlemesi zaman alır ve ne kadar süreceği belgede yazmıyor. Bu yüzden düzeltme sonrası ilk iş, URL Inspection ile birkaç örnek sayfanın güncel hâlini sınamak, sonraki iş de raporları birkaç hafta boyunca izlemektir. Sonuçların hızına dair söz vermek doğru olmaz.

Haber akışında işaretlemeyi sürdürmek

Bir şablonu kurmak ile onu yıllarca doğru tutmak ayrı işlerdir. Haber siteleri sürekli değişir: yeni bir yazı biçimi, yeni bir yazar profili, yeni bir ortak içerik anlaşması. Her değişiklik işaretleme açısından küçük bir risk taşır.

Değişiklik yönetimi

Şablon değişikliği öncesinde yukarıdaki kontrol listesini yeniden çalıştırmak, sonradan fark edilen toplu hataların önüne geçer. Özellikle yeni bir yazar rolü (konuk yazar, ajans, yapay zekâ destekli taslak) eklendiğinde author alanının nasıl dolacağı yazılı olarak netleştirilmelidir.

Hata kaydı tutmak

Bulunan her tarih ya da yazar hatasını kısa bir kayda işleyin: ne zaman bulundu, kaç sayfayı etkiledi, kaynağı neydi, nasıl düzeltildi. Üç beş kayıttan sonra hataların çoğunun aynı iki nedenden çıktığı görülür ve önlem şablon düzeyine taşınır.

Ne zaman geri çekilmeli

Bir alanın doğru doldurulacağından emin değilseniz, onu boş bırakmak yanlış doldurmaktan iyidir. Belge hiçbir alanı zorunlu kılmaz; yanlış bir yazar adı ya da uydurma bir tarih, eksik alandan daha çok zarar verir. Güvenemediğiniz alanı kaldırın, kaynağı düzelince geri ekleyin.

Sık Sorulan Sorular

datePublished ile dateModified aynı değerde olabilir mi?

Olabilir; haber hiç değişmediyse iki alan aynı anı gösterebilir. Ancak haber güncellendikten sonra dateModified ilk yayın tarihinde kalıyorsa işaretleme sayfayı güncel göstermez. Her iki alan da zorunlu değil, önerilen alanlardandır.

Her düzeltmede dateModified değişmeli mi?

Belgede böyle bir kural yok. Yazım hatası gibi anlamlı olmayan düzeltmelerde değiştirmemenizi, olguyu etkileyen düzeltmelerde değiştirip sayfada görünür not eklemenizi öneriyoruz. Google, içerik anlamlı biçimde değişmemişken tarihi değiştirmeyi sakıncalı bir uygulama olarak anar.

Haberde NewsArticle kullanmak zorunlu mu?

Hayır. Belge Article, NewsArticle ve BlogPosting türlerini destekler ve zorunlu özellik koymaz. Hangi türün ne zaman seçileceğine dair kesin kural belgede yok; tür eşlemesini kendi içerik sınıflandırmanıza göre yapıp tutarlı kullanmanız yeterlidir.

author.name alanına kurum adı yazılabilir mi?

Sayfada yazar olarak kurum sunuluyorsa, kurum için Organization türüyle işaretleyebilirsiniz. Alana yalnızca ad yazılır, unvan ya da açıklama eklenmez. Sayfada kişi imzası varken kurum adını yazar olarak göstermek görünen bilgiyle uyuşmaz.

Saat dilimini yazmazsam ne olur?

Belgeye göre Google, Googlebot'un kullandığı saat dilimini varsayar. Bu, tarihin gerçek yayın anından farklı yorumlanmasına yol açabilir. Saat farkını ISO 8601 değerine eklemek bu belirsizliği ortadan kaldırır.

Rich Results Test geçtiyse işaretleme doğru mudur?

Hayır. Araç sözdizimi ve alan hatalarını yakalar; tarihin gerçekten doğru olup olmadığını ya da yazarın sayfadakiyle aynı kişi olup olmadığını denetleyemez. Belge de bazı kalite sorunlarının otomatik araçlarla bulunamayacağını belirtir.

İlgili rehberler: Haber Sitesi SEO Kontrol Listesi, Haber Sitesi Düzeltme ve Güncelleme Politikası Nasıl Yazılır?, Sonsuz Kaydırma mı, Numaralı Sayfalama mı? Haber Arşivi Rehberi.

Sonuç

Haber sitesinde Article işaretlemesi iki kuralla özetlenebilir. Birincisi, alanlar sayfada okura görünen bilgiyi doğru yansıtmalıdır: datePublished ilk yayın anını, dateModified anlamlı bir değişikliğin anını, author ise sayfada imzası bulunan gerçek kişi ya da kurumu göstermelidir. İkincisi, tarihler ISO 8601 biçiminde ve saat farkıyla yazılmalı, güncelleme notu olmayan değişiklik tarihe dönüştürülmemelidir. Belgede zorunlu alan yok, Rich Results Test de anlamı sınamıyor; bu yüzden kontrol listesi ve düzenli örnekleme işin asıl güvencesidir. Tek karar kuralı yeterli: değişiklik okurun haberi anlayışını etkilemiyorsa dateModified'a dokunmayın.

Haberlerinizin görünürlüğünü artırmak istiyorsanız Akua Adforce'ta reklam alanlarını inceleyebilirsiniz; kapsam ve koşullar ilgili sayfada yazılıdır.