Structured data (yapısal veri) hataları Search Console’da nasıl okunur

Structured data (yapısal veri) hataları Search Console’da nerede görülür?

Search Console tarafında yapısal veri sorunlarını okurken ilk ayrım şudur: gördüğünüz rapor bir rich result durumu mu, yoksa ayrıştırılamayan yapılandırılmış veri raporu mu? Google, desteklenen her rich result tipi için ayrı rapor üretir; bu raporlar genelde Geliştirmeler altında, ürün odaklı bazı türler ise Shopping bölümünde görünür. Google’ın resmi açıklamasına göre bu raporlar ancak sitede geçerli ve Google tarafından desteklenen işaretleme bulunduğunda oluşur (Google Search Console Help, Rich result report overview).

Burada kritik nüans şu: schema.org ile Google’ın desteklediği rich result tipleri aynı şey değildir. Bir sayfada schema.org işaretlemesi bulunabilir ama bu işaretleme Google’ın desteklediği bir zengin sonuç türüne bağlanmıyorsa ayrı bir Search Console raporu oluşmayabilir. 2026 itibarıyla desteklenen tür listesi statik bir blog yazısında değil, Google’ın canlı Search Gallery dokümanında tutuluyor ve bu sayfa 2026-01-06 UTC tarihinde güncellendi; bu yüzden eski liste ekran görüntülerine değil canlı dokümana bakmak gerekir (Google Search Central, Structured data markup that Google Search supports, 2026-01-06).

Rapor hiç görünmüyorsa bunu otomatik olarak hata diye okumayın. En sık nedenler şunlardır:

• Sayfada Google’ın desteklediği bir rich result tipi yoktur.
• İşaretleme vardır ama geçerli değildir; Google türü güvenle eşleyememiştir.
• URL noindex, erişim engeli veya robots kaynaklı sorun yüzünden yeterince işlenemiyordur.
• Rapor örnekleme temellidir; yani bazı URL’ler listede görünmese bile işaretleme başka sayfalarda tespit edilmiş olabilir.

Google ayrıca rich result raporlarının kapsamlı envanter olmadığını, kaliteyi değerlendirmeye yarayan bir örnek küme sunduğunu açıkça belirtir. Bu yüzden “raporda yoksa sitede yok” veya “raporda iki URL var, sorun sadece iki URL’de” çıkarımı teknik olarak güvenli değildir (Google Search Console Help, Rich result report overview).

Hata, uyarı, geçerli ve ayrıştırılamayan veri durumları nasıl yorumlanır?

Search Console’daki dört temel durumu doğru okumak öncelik sırasını doğrudan belirler. Hata, öğenin rich result olarak kullanılmasını engelleyen kritik problem demektir. Geçerli ama uyarılı durumu, öğenin temel olarak uygun olduğunu ama görünümü zenginleştirecek önerilen alanların eksik kalabildiğini gösterir. Geçerli durumda kritik eksik yoktur. Ayrıştırılamayan yapılandırılmış veri ise daha aşağı seviye, yani sözdizimi veya parse katmanında bozulma olduğu anlamına gelir; Google öğenin türünü bile güvenle çıkaramaz (Google Search Console Help, Unparsable structured data report).

Önceliklendirme mantığı pratikte nettir: önce required property eksiklerini ve syntax hatalarını çözün, sonra görünümü iyileştiren recommended property uyarılarına geçin. Google’ın genel structured data politikaları da görünür içeriği doğru temsil eden, eksiksiz ve erişilebilir işaretlemeyi vurgular; ayrıca Google, doğru işaretleme olsa bile rich result görünümünü garanti etmez (Google Search Central, General Structured Data Guidelines, 2026-01-06).

• Missing field: Çoğu zaman eksik alanı gösterir; alanın required mı recommended mı olduğuna bakmadan öncelik vermeyin.
• Invalid object type: Verilen tip, beklenen şema tipiyle uyuşmuyor olabilir.
• Parse error veya benzeri syntax mesajları: JSON-LD yapısı, virgül, köşeli parantez, değer tipi veya kaçış karakteri seviyesinde kırılmış olabilir.
• Valid with warning: Görünüm iyileştirilebilir ama öğe tamamen kaybedilmiş değildir.

2026 tarafında dikkat edilmesi gereken bir başka nokta da şu: Google’ın desteklediği feature listesi özellikle ecommerce ve merchant odaklı alanlarda canlı dokümanda tutuluyor. Yani eski rehberlerde geçen “bu alan artık önemli değil” veya “şu tip artık rapor üretmiyor” gibi ifadeleri doğrulamadan kullanmayın. Canlı listede merchant listing, loyalty program, shipping policy ve return policy gibi alışveriş odaklı kapsam daha belirgin durumda (Google Search Central, Structured data markup that Google Search supports, 2026-01-06).

Issue details ekranı ve hata mesajları satır satır nasıl okunur?

Issue details ekranında teknik ekiplerin en çok atladığı kısım, tablonun isimlerini ezberleyip pratik anlamını kaçırmasıdır. First detected, bu hata tipinin ilk kez ne zaman görüldüğünü gösterir; yani bugün tekrar görünmüş olsa bile ilk kök sorunun daha eskiye gittiğini anlatabilir. Last crawled, örnek URL’nin Google tarafından en son ne zaman tarandığını söyler. Validation state ise henüz doğrulama başlatılmadığını mı, sürecin devam ettiğini mi, yoksa başarısız olduğunu mu anlatır (Google Search Console Help, Fix structured data issues in Search Console).

Examples alanı ise çoğu kullanıcı tarafından yanlış okunur. Bu liste tam envanter değildir; Google örnekleme gösterir. Hatta resmi dokümana göre tabloda 1000 satır sınırı vardır ve son taramadan sonra oluşan veya çok geniş kapsama yayılan örnekler listede görünmeyebilir. Bu yüzden aynı issue adı yalnızca birkaç URL ile görünse de problem aslında yüzlerce sayfaya yayılmış olabilir (Google Search Console Help, Rich result report overview).

Pratikte şu ayrım çok işe yarar: örnek URL’lerin hepsi aynı şablondan mı geliyor, yoksa birbirinden tamamen farklı sayfalar mı? Eğer aynı template ailesine ait ürün, blog veya kategori sayfalarında aynı hata çıkıyorsa bu çoğu zaman template-level sorundur. Google da ayrıştırılamayan veri raporunda tek bir hatanın birçok sayfayı etkilemesinin en yaygın nedeninin temel şablon hatası olduğunu açıkça söyler (Google Search Console Help, Unparsable structured data report). Terminoloji tarafında ek bir referans gerekiyorsa SEO terimleri sözlüğü üzerinden ekip içi rapor dilini standardize etmek işinizi kolaylaştırır.

Issue adının içinde görülen bağlam etiketleri de önemlidir. Aynı “Missing field” mesajı farklı item tiplerinde farklı etki yaratabilir; örneğin bir üründeki eksik alanla bir tarifteki eksik alan aynı cümleyle görünüp farklı eligibility sonucu doğurabilir. Bu yüzden hata mesajını tek başına değil, hangi item type içinde ve hangi field beklentisiyle üretildiği bağlamında okuyun.

Aynı URL’de üçlü debug: Search Console, URL Inspection ve Rich Results Test

En hızlı teşhis akışı, aynı URL’yi üç araçta yan yana okumaktır. Bizim pratikte en güvenilir bulduğumuz sıralama şu oluyor: önce Search Console issue details ekranından örnek URL’yi seçmek, sonra URL Inspection ile indekslenmiş sürüm ve canlı URL farkını görmek, en son Rich Results Test ile kod seviyesinde item ve field kontrolü yapmak. Bu üç görünüm aynı yerde birleşmediği için tek ekrana bakarak karar vermek çoğu zaman yanıltıcıdır.

Buradaki temel soru şudur: sorun gerçekten kodda mı, yoksa Google’ın gördüğü sürümde mi? URL Inspection canlı testte hata düzelmiş görünürken indekslenmiş sürümde hâlâ eski hata varsa problem çoğu zaman tarama gecikmesi veya render farkı kaynaklıdır. Rich Results Test temiz sonuç veriyor ama Search Console hâlâ invalid gösteriyorsa, test edilen canlı kod ile Google’ın rapora aldığı tarihli veri aynı olmayabilir. Google, structured data’ya giriş dokümanında geliştirme aşamasında Rich Results Test’i, yayın sonrası doğrulamada ise raporlar ve URL Inspection kullanımını özellikle ayırıyor; bu doküman 2025-12-10 UTC tarihinde güncellendi (Google Search Central, Intro to How Structured Data Markup Works, 2025-12-10).

Rich Results Test tarafında doğrulamanız gereken üç şey vardır: bulunan item türü, required alan eksikleri ve crawl/render durumu. Google’ın resmi yardımına göre bu test JSON-LD, RDFa ve Microdata formatlarını destekler. Ayrıca anonim kullanıcı gibi eriştiği için robots, firewall veya oturum gerektiren kaynaklar yüzünden farklı sonuç üretebilir (Google Search Console Help, Rich Results Test). Kısacası Search Console size problem sinyalini verir, URL Inspection Google’ın hangi sürümü gördüğünü söyler, Rich Results Test ise işaretlemenin koda ve render edilmiş çıktıya göre gerçekten okunabilir olup olmadığını gösterir.

Şablon kaynaklı hataları düzeltme, Validate fix ve etkiyi izleme akışı

Şablon kaynaklı structured data sorunlarında en büyük hata, tek bir örnek URL’yi düzeltip iş bitti sanmaktır. Eğer hata bir kart bileşeninden, ürün şablonundan veya CMS eklentisinin ortak JSON-LD çıktısından geliyorsa önce kaynak şablonu düzeltin. Öncelik sırası yine değişmez: önce öğeyi geçersiz yapan required alanlar ve syntax sorunları, sonra görünümü zenginleştiren warnings. Bu yaklaşım, özellikle aynı hatanın onlarca kategori veya ürün sayfasına kopyalandığı sitelerde gereksiz tekrar işini keser.

Validate fix düğmesini ancak iki kontrol tamamlandıktan sonra kullanın: örnek URL canlı testte temiz görünmeli ve aynı şablonu kullanan birkaç farklı URL’de aynı doğrulama tekrarlanmalı. Google’ın resmi akışına göre doğrulama örnek bir sayfa grubuyla başlar, başarılıysa diğer etkilenen sayfalara yayılır. Validation süreci iki hafta veya daha uzun sürebilir; durumlar ise Not started, Started, Looking good, Passed ve Failed gibi aşamalarla ilerler (Google Search Console Help, Fix structured data issues in Search Console).

Düzeltme sonrası etkiyi yalnızca Search Console grafiğinden okumak eksik kalır. Görünürlükte toparlanma, tarama yenilenmesi ve ilgili sayfa grubunun pozisyon hareketi birlikte izlenmelidir. Ahrefs, SEMrush, Moz, SE Ranking veya SEOptimer gibi araçlar bu takibi farklı ekranlarda yapabilir; SEOYEN ise bu operasyonu Türkiye pazarına daha yakın bir akışla, tek platformda tüm SEO araçları, Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek çerçevesinde toplar. Özellikle düzeltme sonrası site sağlığı taraması ile teknik durumun tekrar bozulup bozulmadığını, sıralama takibi ile görünürlük etkisini düzenli izlemek daha okunabilir bir süreç oluşturur. Operasyonel çerçeveyi değerlendirmek isteyen ekipler için güncel paket detayları sayfası yeterlidir; içerik içinde sabit fiyat okumak yerine canlı sayfaya bakmak daha sağlıklıdır.

Adım Adım: Search Console’da structured data hatalarını okuma ve doğrulama

Aşağıdaki akış, ekip içinde tekrar eden structured data hatalarını daha hızlı sınıflandırmak için kullanılabilir. Amaç tek bir URL’yi değil, aynı kök sorunun hangi sayfa grubuna yayıldığını görmek ve doğrulamayı doğru sırayla başlatmaktır.

1. İlgili raporu ve issue tipini açın. Önce gördüğünüz ekranın rich result raporu mu yoksa ayrıştırılamayan veri raporu mu olduğunu netleştirin. Parse seviyesindeki rapor, daha alt seviye bir kırılmaya işaret eder.
2. Durum etiketini ve etki seviyesini sınıflandırın. Hata mı, geçerli ama uyarılı mı, yoksa syntax problemi mi? Bu ayrım çözüm sırasını belirler; eligibility kaybı yaratan sorunlar ilk sıradadır.
3. Örnek URL’yi URL Inspection ile test edin. Canlı URL ve indekslenmiş sürüm farklıysa kök neden sadece kod değil, render veya tarama zamanlaması da olabilir.
4. Rich Results Test ile kodu doğrulayın. Item type, required alan eksikleri ve erişim problemlerini aynı anda kontrol edin. Test temizse, Search Console verisinin henüz güncellenmemiş olması mümkündür.
5. Şablonu düzeltip Validate fix başlatın. Tek URL yerine kaynağı düzeltin. Aynı şablonu kullanan birkaç URL’de sonuç tutarlıysa doğrulama başlatmak daha güvenlidir.
6. Etkiyi görünürlük ve tarama bazında izleyin. Validation state, son tarama tarihi ve sıralama değişimini birlikte okuyun. Aksi halde teknik düzeltme yapılmış olsa bile iş etkisini kaçırabilirsiniz.

Sıkça Sorulan Sorular