Hızlı Cevap
Yapısal veri geçerli olduğu hâlde Search Console’daki öğe sayısı azalabilir; çünkü rapor teknik doğrulamayı değil, Google’ın gördüğü, indekslediği ve rapora dahil ettiği öğeleri sayar. Canonical değişimi, noindex, robots engeli, şablon kaybı, render farkı ve örnekleme sınırlamaları aynı anda düşüş yaratabilir.
Önemli Noktalar
- Geçerli işaretleme tek başına rich result görünürlüğü garantisi vermez.
- Öğe sayısı düşüşü çoğu zaman indeksleme, erişim veya canonical kaynaklıdır.
- Rich Results Test ile rapor aynı veri kaynağını kullanmaz.
- 20 URL’lik sabit örneklem gerçek kaybı rapor farkından ayırır.
Yapısal veri geçerli olduğu hâlde rapordaki öğe sayısı neden azalır: rapor neyi sayar?
İlk ayrım şu: Search Console zengin sonuç raporu çoğu zaman URL sayısını değil, öğe sayısını gösterir. Google’ın resmi açıklamasına göre raporlardaki toplamlar, sitenizde algılanan tüm öğelerin eksiksiz envanteri değildir; kalite değerlendirmesi için örneklenmiş bir görünüm sunar (Google Search Console Yardımı). Bu yüzden grafikteki düşüş, tek başına markup’ın bozulduğu anlamına gelmez.
İkinci ayrım da geçerlilik ile uygunluk arasındadır. Bir JSON-LD bloğu teknik olarak geçerli olabilir; ama bu, o sayfanın mutlaka zengin sonuç almaya uygun olduğu anlamına gelmez. Google’ın genel structured data yönergeleri, teknik hatası olmayan işaretlemenin bile içerik politikaları, görünürlük ve sayfa amacı açısından ayrıca değerlendirildiğini açıkça söyler (Google for Developers). Kısacası geçerli ile gösterilebilir aynı şey değildir.
- Bir URL birden fazla yapılandırılmış veri öğesi içerebilir; bu yüzden URL ve öğe toplamı eşit değildir.
- Geçerli ve geçersiz öğe sayılarının toplamı, rapora giren tüm tespitleri temsil etmeyebilir.
- Rapor, trend okumak için çok değerlidir; ancak tam sayfa envanteri için tek kaynak değildir.
Pratikte bu farkı netleştirmek için raporu bir sayaç gibi değil, bir kapsam göstergesi gibi okumak gerekir. Terimlerin birbirine karıştığı noktada kısa bir SEO terim sözlüğü kontrolü ekip içi iletişimi de temizler. Özellikle büyük sitelerde örnekleme, yeniden tarama gecikmesi ve canonical kümelenmesi aynı grafikte üst üste bindiğinde, düşüşün nedeni markup değil rapor mantığı olabilir.
Öğe düşüşünün en sık nedenleri: indeksleme, erişim ve şablon değişiklikleri
Google’ın kendi hata ayıklama kılavuzu, düşen yapılandırılmış veri öğeleri için önce dizine ekleme ve erişim tarafına bakılmasını önerir. Bunun nedeni basit: Search Console raporlarında çoğunlukla yalnızca dizine eklenen sayfalar görünür. Bir URL noindex aldıysa, robots.txt ile engellendiyse, giriş gerektirmeye başladıysa ya da canonical başka bir URL’ye kaydıysa markup yerinde kalsa bile rapordaki sayı azalabilir (Google Search Console Yardımı).
İkinci büyük grup, deploy sonrası ortaya çıkan şablon farklarıdır. Kod deposunda JSON-LD hâlâ duruyor olabilir; ama belirli kategori şablonunda render edilmiyor, JavaScript sonrası geç yükleniyor ya da gerekli property’lerden biri boş dönüyor olabilir. Bu durumda Rich Results Test bazen canlı sürümde bir şey görür, bazen de indekslenen sürüm eski olduğu için rapor başka bir tablo çizer. Özellikle rendered HTML ile kaynak kod farklıysa, düşüşün kökü çoğunlukla şablon katmanındadır.
- Noindex, robots.txt ve erişim engelleri rapor kapsamını hızla daraltır.
- Canonical değişimi aynı içeriği başka URL kümesine taşıdığı için sayımı oynatır.
- Şablondan silinen veya boş dönen kritik alanlar geçerli öğe düşüşü yaratabilir.
2026 itibarıyla okunması gereken üçüncü başlık, Google’ın desteklediği görünüm tiplerindeki değişikliklerdir. Google, 12 Haziran 2025 tarihli duyurusunda bazı daha az kullanılan structured data görünümlerini aşamalı olarak kaldıracağını açıkladı; 8 Eylül 2025 güncellemesinde de bu türlerin Search Console raporlarından ve Rich Results Test’ten çıkarılacağını belirtti (Google Search Central Blog). Bu nedenle bazen düşen sayı, hatalı markup değil artık raporlanmayan bir görünüm türü anlamına gelebilir.
Rich Results Test, URL Denetleme ve rapor aynı URL için neden farklı konuşur?
Bu üç araç farklı veri kaynaklarıyla çalışır. Rich Results Test, o anda çağrılan canlı HTML’yi ve işaretlemenin teknik olarak okunup okunmadığını test eder. URL Denetleme Aracı, Google’ın son gördüğü dizine eklenen sürümü, seçilen canonical’ı ve canlı test ile indekslenen sürüm farkını karşılaştırmanıza izin verir. Search Console raporu ise tekil URL ekranı değil, gecikmeli ve toplulaştırılmış eğilim görünümüdür (URL Denetleme Aracı).
- Rich Results Test: İşaretleme şu anda sayfada var mı, teknik olarak okunuyor mu?
- URL Denetleme: Google hangi sürümü gördü, hangi canonical’ı seçti, canlı ve indeks farkı ne?
- Search Console raporu: Bu durum site ölçeğinde ve zaman içinde nasıl yansıdı?
Canlı testin geçerli çıkması tek başına yeterli değildir. URL Denetleme ekranında indekslenen sürüm eskiyse, sayfa Google tarafından başka canonical altında toplanmışsa veya noindex kaldırılmış ama henüz yeniden işlenmemişse, rapor birkaç gün hatta daha uzun süre düşüş göstermeye devam edebilir. Google’ın yardım dokümanı, canlı test ile dizine eklenen sürüm arasında fark olabileceğini ve canlı testin tüm indeksleme koşullarını yansıtmayabileceğini açıkça belirtir (Google Search Console Yardımı).
Bu yüzden aynı URL için üç farklı cevap duymanız normaldir. Doğru okuma sırası şudur: önce Rich Results Test ile markup’ın canlıda varlığını doğrulayın, sonra URL Denetleme ile indekslenen sürüm, rendered HTML ve Google tarafından seçilen canonical’ı kontrol edin, en son rapora dönüp bunun kaç URL’ye yayıldığını ölçün. Araçların sırası ters kurulursa, teknik olarak geçerli bir işaretlemeyi gereksiz yere sorun gibi yorumlayabilirsiniz.
| Kontrol noktası | Rich Results Test | URL Denetleme Aracı | Search Console raporu |
|---|---|---|---|
| Veri kaynağı | Canlı istekle çekilen güncel HTML | Google'ın son indekslenen sürümü ve canlı test | Toplulaştırılmış rapor verisi |
| Canlı HTML mi indekslenen sürüm mü | Canlı HTML | İndekslenen sürüm ile canlı sürüm birlikte | Raporlanan kapsam; canlıyla birebir değildir |
| Örnekleme ve kapsam | Tek URL odaklı, örnekleme yok | Tek URL odaklı, örnekleme yok | Örnekleme ve rapor kapsamı sınırlıdır |
| Canonical etkisi | Canlı URL'yi test eder | Google'ın seçtiği canonical'ı gösterir | Canonical kümelenmesi sayımı etkileyebilir |
| Zaman gecikmesi | Anlık | Tarama ve indeks gününe bağlı | Gecikmeli ve dönemsel güncellenir |
| En doğru kullanım amacı | Markup şu an sayfada var mı kontrolü | Google hangi sürümü gördü sorusunun cevabı | Trend ve site ölçekli düşüşü izlemek |
20 URL’lik saha testi: düşüş markup sorunu mu, rapor kapsamı mı?
Bu tip düşüşlerde sahada en temiz yöntem, aynı tarih aralığında 20 URL’lik sabit bir kontrol listesi kurmaktır. Tek tek URL bakmak yerine aynı şablondan, aynı kategori ağacından ve aynı deploy penceresinden seçilmiş sayfaları birlikte inceleriz. Bu yaklaşım, rapor kapsamı daralması ile gerçek markup kaybını ayırmada daha güvenilir olur; çünkü araç farklarını rastgele değil, aynı örneklem üzerinde görürsünüz. Deneyim tarafında en faydalı içgörü, tek bir ekran görüntüsüne değil aynı URL setinin üç araçtaki durumuna bakmaktır.
Örneklem içinde her URL için dört sütun yeterlidir: Rich Results Test sonucu, URL Denetleme’de indekslenen sürüm durumu, seçilen canonical ve erişim sinyalleri. Buna bir de önce ve sonra deploy tarihi eklendiğinde, düşüşün şablon kaynaklı mı yoksa indeksleme kaynaklı mı olduğu çok daha net ayrışır. Eğer canlı test geçerli, indekslenen sürüm eski ve rapor düşüyorsa sorun çoğu zaman yeniden işleme gecikmesidir. Canlı test geçerli ama canonical başka URL’ye gidiyorsa, düşüşü markup değil kümeleme açıklıyordur.
Tersi senaryoda hem canlı hem indekslenen sürümde gerekli alanlar eksikse, deploy veya render zinciri incelenmelidir. Özellikle kategori, ürün ve içerik şablonları aynı kod tabanını paylaşırken belirli bir parça yanlış koşulla gizlenmiş olabilir. Bu yüzden 20 URL’lik saha testi sadece hata bulmak için değil, yanlış teşhisi önlemek için de değerlidir. Rapor düşmüş olsa bile bütün URL’lerde aynı kırılma yoksa, önce ortak desenleri aramak gerekir.
2026 için teşhis ve izleme akışı: SEOYEN + Search Console
2026’da bu konuyu yorumlarken 2025’teki ürün değişikliklerini arka plana almak hatalı olur. Google’ın 12 Haziran 2025 duyurusu bazı daha az kullanılan structured data görünümlerinin Search sonuçlarından kaldırılacağını açıkladı; 8 Eylül 2025 güncellemesi ise bu tiplerin Search Console rich result raporlarından ve Rich Results Test’ten kaldırılacağını, API desteğinin Aralık 2025’e kadar süreceğini ekledi. Aynı notta, bulk export tarafında bazı deprecated search appearance alanlarının 1 Ekim 2025 itibarıyla NULL raporlanacağı da belirtildi (Google Search Central Blog). Bu yüzden tarihsel trendlerde araç değişikliği ile gerçek görünürlük kaybını birbirinden ayırmak gerekir.
Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer farklı modüllerle teknik izleme tarafına katkı sağlar; SEOYEN’in farkı ise bu ihtiyacı Türkiye pazarı için tek platformda, Türkçe arayüz ve yerel destekle toparlamasıdır. Search Console’dan gelen düşüşü tek başına okumak yerine site sağlığı panosu içinde taranabilirlik, canonical kalıpları ve şablon bazlı bozulmaları birlikte izlemek daha hızlı aksiyon üretir. Buna sıralama takibi görünümü eklendiğinde, rapordaki öğe düşüşünün organik görünürlükte gerçekten iz bırakıp bırakmadığı da netleşir.
Operasyon akışında ideal sıra şudur: önce Search Console’da kırılma tarihini bulun, sonra URL bazlı doğrulama yapın, ardından şablon ve erişim sinyallerini gruplandırın, en son görünürlük etkisini izleyin. SEOYEN’in Türkçe arayüzü ve güncel TL paket seçenekleri, bu süreci yerel ekipler için daha yönetilebilir hâle getirir. Buradaki amaç raporu süslemek değil; aynı düşüşü teknik, tarama ve sıralama katmanlarında aynı anda okumak olmalıdır.
Adım Adım: Search Console’da düşen yapılandırılmış veri öğelerini teşhis etme
Tek bir ekrana bakarak karar vermek yerine, aşağıdaki akışla ilerlemek daha güvenilir sonuç verir. Sıra önemlidir; çünkü rapor, canlı test ve indekslenen sürüm aynı soruya cevap vermez.
- Düşüşün başladığı tarih aralığını sabitle: Grafikte ilk kırılmanın görüldüğü günü belirleyin ve aynı pencereye denk gelen deploy, robots, noindex, canonical veya CDN değişikliklerini not edin.
- Canlı test ile indekslenen sürümü karşılaştır: Aynı URL’yi Rich Results Test ve URL Denetleme’de açın; canlı HTML ile Google’ın son indekslediği sürüm aynı değilse yorumunuzu canlı sonuca göre değil farkın yönüne göre kurun.
- İndeksleme, canonical ve robots sinyallerini kontrol et: URL’nin dizine eklenip eklenmediğini, Google’ın hangi canonical’ı seçtiğini ve tarama ya da noindex engeli olup olmadığını tek ekranda doğrulayın.
- Şablon ve rendered HTML farkını doğrula: Kaynak kodda görünen JSON-LD’nin rendered HTML’de gerçekten kalıp kalmadığını, alanların boş dönüp dönmediğini ve deploy sonrası belirli şablonlarda kayıp yaşanıp yaşanmadığını inceleyin.
- Uygunluk ve desteklenen sonuç tipini gözden geçir: İşaretleme geçerli olsa bile sayfanın amacı, görünür içeriği ve Google’ın hâlâ desteklediği zengin sonuç tipi açısından uygunluk kontrolü yapın.
- Düzeltme sonrası yeniden tarama ve izleme başlat: URL bazlı düzeltmeden sonra yeniden tarama isteyin; ardından rapor toparlanmasını, site sağlığı sinyallerini ve sıralama etkisini birlikte izleyin.
Bu akış, özellikle ekip içinde görev paylaşımı yaparken faydalıdır: geliştirici render ve şablon tarafını, SEO uzmanı indeksleme ve canonical tarafını, içerik ekibi ise sayfa uygunluğunu ayrı ayrı doğrulayabilir. Konuya görsel bir destek eklemek isterseniz Google Search Console eğitim videolarındaki URL Denetleme anlatımları bu bölüm için iyi bir tamamlayıcı olur.
Kaynaklar
Sıkça Sorulan Sorular
Çünkü Search Console yalnızca işaretlemenin sözdizimsel olarak geçerli olup olmadığını değil, Google'ın gerçekten gördüğü, indekslediği ve rapora dahil ettiği öğeleri yansıtır. Bir sayfa noindex alırsa, robots.txt ile engellenirse, canonical başka URL'ye kayarsa veya Google henüz yeni sürümü işlemediyse, markup duruyor olsa bile öğe sayısı düşebilir. Google'ın resmi yardım dokümanı ayrıca örnekleme sınırlamalarının da toplamları etkileyebildiğini söylüyor. Bu nedenle düşüşü yalnızca schema hatası gibi okumak yerine indeksleme, erişim ve şablon geçmişini birlikte kontrol etmek gerekir.
Geçerlilik, kodun teknik olarak okunabildiğini gösterir. görünürlük ise ayrı bir uygunluk katmanıdır. Google, sayfanın amacı, işaretlemenin sayfadaki görünür içerikle uyumu, gerekli alanların tamlığı ve ilgili rich result tipinin hâlâ desteklenip desteklenmediği gibi noktaları ayrıca değerlendirir. Bu yüzden Rich Results Test geçerli dese bile sayfa zengin sonuç üretmeyebilir. Özellikle görünür olmayan içeriklerin işaretlenmesi, eksik required property'ler veya artık desteklenmeyen görünüm tipleri bu farkı yaratır.
Çünkü raporun birimi çoğu zaman URL değil öğedir. Tek bir URL içinde birden fazla yapılandırılmış veri öğesi bulunabilir. ayrıca Search Console raporları algılanan tüm öğelerin tam listesini vermez, örneklenmiş bir görünüm sunar. Bu iki nedenle rapordaki geçerli ya da geçersiz öğe toplamları, sitenizdeki gerçek URL sayısıyla birebir örtüşmez. Büyük sitelerde canonical kümeleri ve indeks dışı kalan sayfalar da bu farkı büyütür. URL bazında net kontrol gerekiyorsa raporu tek başına değil, URL Denetleme ile birlikte okumak gerekir.
Dizine eklenmeyen sayfalardaki yapılandırılmış veri, Search Console raporlarında görünmeyebilir veya daha az görünür hâle gelir. Bu yüzden indeks kaybı, çoğu zaman rich result raporundaki düşüşün doğrudan açıklamasıdır. Örneğin noindex eklenen, robots ile taraması engellenen ya da Google tarafından başka canonical altında değerlendirilen sayfaların markup'ı teknik olarak geçerli kalsa bile rapor sayısı azalabilir. Bu nedenle öğe düşüşü gördüğünüzde ilk kontrol, etkilenen URL'lerin gerçekten indeks içinde olup olmadığıdır.
Evet. Google, zengin sonuç raporlarının algılanan tüm öğelerin kapsamlı listesini içermediğini ve kalite değerlendirmesi için örnek sunduğunu açıkça belirtiyor. Bu, özellikle büyük sitelerde ve sık değişen URL kümelerinde raporlanan öğe toplamlarının dönemsel olarak oynamasına neden olabilir. Yani grafikteki düşüş her zaman gerçek bir markup kaybı olmayabilir. bazen rapor kapsamı veya örnek boyutu değişmiştir. Bu yüzden aynı dönemde URL Denetleme ve canlı test temiz görünüyorsa, rapor düşüşünü hemen kritik hata gibi yorumlamamak gerekir.
Önce etkilenen URL'yi URL Denetleme Aracı'na girin ve dizine eklenen sürümü inceleyin. Burada indeks durumu, Google'ın seçtiği canonical, rendered HTML ve yapısal veri tespitleri size Google'ın gerçekten ne gördüğünü söyler. Ardından aynı URL için canlı testi açıp güncel sayfa ile indekslenen sürüm arasındaki farkı karşılaştırın. Eğer canlıda markup var ama indekslenen sürümde yoksa sorun çoğu zaman tarama gecikmesi, render farkı veya şablon dağıtımıdır. Eğer her iki sürümde de eksikse, işaretleme veya sayfa uygunluğu tarafına dönmek gerekir.