Yapılandırılmış Veri (Schema) ve Index Bloat

Son güncelleme: 1 Kasım 2026.

21. bölümde Yapılandırılmış Veri (Structured Data) konusuna Google sonuçlarını zenginleştirme açısından değinmiştik. Bu bölümde aynı konuya biraz daha teknik taraftan bakacağız.

Çünkü Google’a bir sayfanın ne olduğunu anlatmak kadar, hangi URL’lerin gerçekten önemli olduğunu anlatmak da gerekiyor.

Bir tarafta Schema ile “Bu bir ürün”, “Bu bir şirket”, “Bu bir etkinlik”, “Bu bilgi ürünün fiyatı” diyoruz. Diğer tarafta ise binlerce gereksiz veya zayıf URL’yi Google’ın dizinine açarsak arama motoruna çok daha karmaşık bir yapı sunuyoruz.

Bu nedenle bu bölümün iki ana başlığı var:

Yapılandırılmış Veri (Structured Data / Schema)
Dizin Şişmesi (Index Bloat)

Bence ikisinin ortak noktası şu:

Google’a daha fazla bilgi vermek değil, daha temiz ve daha tutarlı bilgi vermek önemli.

1. Yapılandırılmış Veri (Structured Data) nedir?

Google bir sayfayı taradığında HTML içerisindeki metinleri, bağlantıları, görselleri ve diğer öğeleri anlamaya çalışıyor. Biz de Yapılandırılmış Veri (Structured Data) kullanarak bazı bilgilerin ne anlama geldiğini makine tarafından daha kolay anlaşılabilecek şekilde tanımlayabiliyoruz.

Örneğin bir ürün sayfasında şunlar olabilir:

Ürün adı
Marka
Fiyat
Stok durumu
Puan
Yorum sayısı

İnsan sayfaya baktığında bunların ne olduğunu kolayca anlayabilir. Schema ile Google’a da “Bu 14.900 TL ürünün fiyatı”, “Bu ifade ürünün markası”, “Bu bilgi stok durumunu gösteriyor” diyebiliyoruz.

2. Schema.org nedir?

Schema.org, web üzerindeki varlıkları ve özelliklerini tanımlamak için kullanılan ortak bir sözlük. Bu sözlükte çok sayıda tür bulunuyor. Örneğin:

Product: Ürün
Article: Makale
Organization: Kuruluş
LocalBusiness: Yerel işletme
Event: Etkinlik
Recipe: Tarif
BreadcrumbList: Breadcrumb
Movie: Film
Person: Kişi

Ama burada önemli bir ayrım var:

Schema.org’da bulunması, Google’ın o Schema türü için özel bir arama özelliği desteklediği anlamına gelmez.

Schema.org çok daha geniş bir sözlük. Google ise bunların belirli bir bölümünü kendi arama sonuçlarında özel gösterimler için kullanıyor. Bu nedenle uygulama yaparken sadece “Schema.org’da var mı?” diye değil, “Google bunu nasıl kullanıyor?” diye de bakmak gerekiyor.

3. Bir sayfada birden fazla Schema olabilir mi?

Olabilir. Hatta çoğu zaman normal olan budur.

Örneğin bir ürün sayfasında şunlar aynı anda bulunabilir:

Organization
BreadcrumbList
Product

Bir haber veya blog sayfasında ise şunlar kullanılabilir:

Organization
BreadcrumbList
Article

Önemli olan bu yapıların gerçekten sayfayla ilişkili olması ve birbirleriyle çelişmemesi. Her bulduğumuz Schema türünü sayfaya eklemek bir optimizasyon yöntemi değil.

4. JSON-LD nedir?

Yapılandırılmış veri farklı formatlarla uygulanabilir. En sık karşılaştığımız yöntemlerden biri JSON-LD.

Çok basitleştirilmiş bir ürün tanımı şöyle görünebilir:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Espresso Makinesi"
}
</script>

SEO uzmanının bu kodları ezberlemesine gerek olduğunu düşünmüyorum. Ama şunları bilmesi gerekiyor:

Bu sayfa hangi tür?
Google’a hangi bilgiler anlatılmalı?
Hangi alanlar gerekli?
Kod gerçekten sayfadaki içeriği temsil ediyor mu?
Google bunu okuyabiliyor mu?

Kod tarafını geliştirici yapabilir. SEO uzmanının görevi ne yapılması gerektiğini doğru tarif etmek ve sonucu kontrol etmek.

5. Schema sıralamamızı yükseltir mi?

Schema’yı doğrudan “Bunu ekledik, sıralamamız yükselir” şeklinde düşünmek doğru değil. Yapılandırılmış verinin temel amacı Google’ın içerik hakkında daha açık bilgi edinmesini sağlamak ve uygun durumlarda belirli arama özelliklerine uygunluk kazandırmak.

Örneğin Product Schema kullanılan bir ürün sayfası, uygun şartları sağlıyorsa fiyat, stok veya puan gibi bilgilerin daha zengin gösterimlerde kullanılmasına uygun hale gelebilir. Ama teknik olarak doğru Schema bulunması bile Google’ın bu görünümü göstereceği anlamına gelmez.

6. Sayfada olmayan bilgiyi Schema’ya yazmayın

Bence Schema tarafındaki en önemli kurallardan biri bu.

Örneğin sayfada kullanıcıya herhangi bir puan göstermiyorsunuz ama kodun içine 4.9 / 5 yazıyorsunuz. Ya da ürün stokta değil ama Schema içerisinde InStock tanımlıyorsunuz.

Bu durumda Google’a kullanıcıya sunduğunuzdan farklı bilgi vermiş oluyorsunuz. Schema’nın amacı sayfada bulunmayan bilgileri arama motoruna gizlice vermek değil.

Kullanıcıya sunduğunuz bilgiyi daha açık biçimde tanımlamak.

7. Schema’yı nasıl kontrol ediyoruz?

Google’ın Zengin Sonuçlar Testi (Rich Results Test) burada temel araçlardan biri.

Kontrol sırasında şunlara bakabiliriz:

Google yapılandırılmış veriyi görüyor mu?
Kritik hata var mı?
Önerilen alanlar eksik mi?
İlgili Rich Result türü için uygun mu?
URL gerçekten Google tarafından erişilebilir mi?

Sonrasında Search Console üzerinden de yapılandırılmış veri hatalarını ve ilgili raporları takip edebiliriz.

Burada sadece toplam hata sayısına bakmıyorum. Şu soru daha önemli:

Bu hata kaç sayfayı etkiliyor ve iş açısından hangi sayfalar bunlar?

10 tane çok önemli ürün sayfasındaki hata, 10.000 önemsiz URL’deki bir uyarıdan çok daha kritik olabilir. Teknik SEO’da adet kadar etki alanı da önemli.

Dizin Şişmesi (Index Bloat)

Şimdi işin diğer tarafına gelelim.

Bir sitede 10.000 gerçekten değerli sayfa olduğunu düşünelim. Ama Google yüz binlerce URL keşfetmiş veya dizine eklemiş. Bu URL’lerin hepsi gerçekten gerekli mi?

İşte burada Dizin Şişmesi (Index Bloat) konusu devreye giriyor.

8. Index Bloat nedir?

Basit anlatımla, Google’ın dizinine girmesine gerek olmayan veya çok düşük değer taşıyan URL’lerin büyük miktarda çoğalmasını Index Bloat olarak düşünebiliriz.

Örneğin şunlar kontrolsüz şekilde çoğalabilir:

Filtre URL’leri
Sıralama URL’leri
Parametreler
İç arama sonuçları
Boş etiket sayfaları
Yinelenen arşivler
UTM parametreleri
Yazdırma sürümleri
Çok benzer kategori sayfaları
Kullanıcıya yeterli değer sunmayan ince sayfalar

Buradaki mesele sadece “fazla URL var” değil. Asıl soru şu:

Bu URL’lerin gerçekten Google’da bulunmasının kullanıcıya bir faydası var mı?

9. “Google’da ne kadar çok sayfam varsa o kadar iyi” doğru mu?

Bence en tehlikeli düşüncelerden biri bu.

Bir sitenin 100.000 sayfasının indekslenmiş olması tek başına başarı değildir. Sitenin gerçekten güçlü 5.000 sayfası varsa diğer 95.000 URL zayıf, tekrarlı, eksik, anlamsız sayfalardan oluşuyorsa bu sayı bizi mutlu etmemeli.

Bence daha doğru soru şu:

Kaç URL dizinde? değil, Hangi URL’ler dizinde?

10. Filmler.com’da bunu özellikle uyguladık

Filmler.com tarafında bunun çok net bir örneğini yaşadık. Sitede oyuncular ve ekip bilgileriyle birlikte yaklaşık 450.000 kişi kaydı bulunuyor.

Teknik olarak bu 450.000 kişinin tamamı için ayrı URL oluşturup sitemap’e eklemek ve Google’ın dizinine açmak mümkündü. Ama şu soruyu sorduk:

Bu 450.000 sayfanın tamamı gerçekten kullanıcıya yeterli değer sunuyor mu?

Cevap hayırdı. Bazı kişi sayfalarında içerik, biyografi veya yeterli bilgi bulunuyordu. Bazılarında ise yalnızca temel veri vardı.

Bu yüzden bütün sayfaları Google’a açmak yerine içerik girilmiş, kullanıcıya gerçekten bir şey sunan sayfaları indekslemeye ve sitemap’e eklemeye karar verdik. Aynı yaklaşımı sitenin başka bölümlerinde de uyguladık.

Sonuçta daha az sayfa indekslettik ama Google’a gönderdiğimiz sayfaların ortalama kalitesini yükselttik. Ve bunun karşılığını da aldık.

Daha az indeks, daha başarılı sayfalar.

Bence Index Bloat konusunu bundan daha iyi anlatan örneklerden biri zor bulunur. SEO’da amaç Google’a mümkün olan en fazla URL’yi göndermek değil.

Google’a gerçekten değerli URL’leri göndermek.

11. Her düşük içerikli sayfayı kapatmalı mıyız?

Hayır. Filmler.com örneğinde de karar sadece kelime sayısına göre verilmedi. Bir sayfada az metin bulunması o sayfanın değersiz olduğu anlamına gelmez.

Örneğin bir oyuncu sayfasında şunlar varsa metin miktarı çok yüksek olmasa bile sayfa kullanıcı için değerli olabilir:

Filmografi
Oyuncunun rol aldığı yapımlar
Görseller
Kariyer bilgileri
Biyografi
İlgili kişiler
Sık sorulan sorular

Asıl mesele sayfanın bir görevinin olup olmadığı.

İçerik uzunluğu ile sayfa değeri aynı şey değil.

12. E-ticaret sitelerinde Index Bloat nasıl oluşuyor?

En güzel örneklerden biri filtreler. Bir ayakkabı kategorisi düşünelim: /ayakkabi

Sonra filtreler geliyor:

?renk=siyah
?renk=beyaz
?beden=42
?marka=x
?sirala=fiyat

Bunlar birbirleriyle birleştiğinde ?renk=siyah&beden=42&marka=x&sirala=fiyat gibi çok sayıda URL oluşabilir. Birkaç filtre bile matematiksel olarak binlerce kombinasyon yaratabiliyor.

Bu sayfaların bazıları SEO açısından değerli olabilir. Örneğin gerçekten aranan “siyah erkek spor ayakkabı” gibi bir kombinasyon ayrı landing page olarak değerlendirilebilir. Ama her kombinasyonun Google’da yer alması gerektiği sonucuna varamayız.

Filtrelerin hepsi değersiz değildir ama filtrelerin hepsi de SEO sayfası değildir.

13. Site içi arama sayfaları

Bir başka klasik örnek:

site.com/arama?q=kahve
site.com/arama?q=kirmizi
site.com/arama?q=abc123

Kullanıcı site içerisindeki arama kutusunu kullandıkça sonsuz sayıda URL üretilebiliyorsa bunların Google tarafından keşfedilmesi ciddi bir URL havuzu oluşturabilir. Çoğu projede site içi arama sonuçlarını organik arama için landing page olarak kullanmak istemeyiz.

Burada ana soru yine aynı:

Bu URL Google kullanıcısına gerçekten bağımsız bir değer sunuyor mu?

14. Etiket sayfaları her zaman kötü mü?

Hayır. WordPress projelerinde bu konu çok karşımıza çıkıyor.

Bir sitede 500 yazı ve 3.000 etiket olabilir. Etiket sayfasında tek bir yazı bulunuyor. Bazılarında hiçbir şey yok. Bazıları diğer kategori sayfalarının neredeyse aynısı.

Bu durumda binlerce düşük değerli sayfa üretmiş olabiliriz. Ama iyi planlanmış bir etiket sistemi farklıdır.

Örneğin bir sinema sitesinde “Christopher Nolan” sayfası altında ilgili filmler, yazılar, haberler ve bilgiler düzgün şekilde toplanıyorsa bu kullanıcı açısından anlamlı olabilir.

Yani mesele URL türü değil.

Sayfanın amacı ve değeri.

15. Tarih, yazar ve arşiv sayfaları

Bazı CMS sistemleri otomatik olarak şunları oluşturuyor:

Günlük arşiv
Aylık arşiv
Yıllık arşiv
Yazar arşivi
Etiket arşivi
Kategori arşivi

Örneğin tek yazarlı kurumsal bir blogda /author/hasan sayfası ana blog sayfasıyla neredeyse aynı içeriği gösterebilir. Burada “yazar sayfası kötüdür” demiyoruz.

Eğer yazar profili, uzmanlık bilgileri ve tüm içerikleriyle anlamlı bir sayfaysa çok faydalı olabilir. Ama CMS’nin otomatik oluşturduğu her sayfanın Google’da yer alması gerekmiyor.

16. UTM parametreleri ve takip URL’leri

Şöyle bir URL düşünelim: site.com/urun

Aynı sayfa sosyal medya kampanyasında site.com/urun?utm_source=instagram, e-postada site.com/urun?utm_source=newsletter, reklamda site.com/urun?utm_source=google şeklinde kullanılabilir.

Bunlar ölçümleme için faydalı. Ama içerik aynı. Burada Google’ın bu URL’leri aynı içerik kümesinin varyasyonları olarak anlaması ve doğru canonical sinyallerini alması önemli.

17. Canonical Index Bloat’u çözer mi?

Bazen yardımcı olur ama tek başına bütün problemleri çözmez.

Örneğin /ayakkabi?renk=siyah sayfasında şunu kullanabilirsiniz:

<link rel="canonical" href="https://site.com/ayakkabi">

Google’a ana URL tercihimizin /ayakkabi olduğunu söylüyorsunuz. Ama milyonlarca gereksiz URL üretip “Nasıl olsa canonical var.” demek iyi bir teknik mimari değil. Mümkün olduğunda gereksiz URL üretimini de kontrol etmek gerekiyor.

Canonical bir temizlik aracı değil. Benzer URL’ler arasında hangi sürümü tercih ettiğimizi anlatan bir sinyal.

18. Noindex ne zaman kullanılabilir?

Bazı sayfalar kullanıcı açısından gerekli olabilir ama Google sonuçlarında yer almasını istemeyebilirsiniz. Örneğin projeye göre şunlar noindex ile ele alınabilir:

Hesap sayfaları
Belirli filtre sonuçları
Bazı arşiv sayfaları
İnce dahili listeler

Burada 23. bölümde anlattığımız konu tekrar önemli. Google noindex etiketini görebilmek için sayfayı tarayabilmeli. Dolayısıyla robots.txt ile engelleyip aynı zamanda noindex vererek Google’ın etiketi göreceğini varsaymak doğru değil.

19. robots.txt Index Bloat çözümü mü?

Tek başına değil. robots.txt taramayı kontrol eder. Bir URL’yi robots.txt ile engellemek “Bunu dizinden çıkar.” demek değildir.

Bu nedenle problemi doğru tanımlamadan “Filtrelerin tamamını robots.txt ile kapatalım.” demek riskli olabilir.

Önce şu soruları cevaplamak gerekiyor:

URL oluşmalı mı?
Taranmalı mı?
Dizine girmeli mi?
Canonical başka yere mi gitmeli?
Kullanıcı için erişilebilir kalmalı mı?

Teknik araç problemi belirledikten sonra seçilmeli.

20. 301 ne zaman kullanılmalı?

İki URL gerçekten aynı amacı karşılıyorsa ve eski URL artık kullanılmayacaksa 301 mantıklı olabilir.

Örneğin /eski-kategori artık yok ve yerine /yeni-kategori geldiyse kalıcı yönlendirme kullanılabilir.

Ama 50.000 düşük kaliteli filtre URL’sini ana sayfaya 301 yapmak Index Bloat çözümü değildir. Yönlendirme ancak anlamlı bir hedef varsa kullanılmalı.

21. Sitemap bize Index Bloat konusunda fikir verebilir

Sitemap içerisinde genellikle Google’da görmek istediğimiz esas URL’lerin bulunmasını tercih ediyoruz. Örneğin sitemap’te 12.000 URL var. Ama Search Console tarafında Google çok daha fazla URL keşfetmiş.

Bu fark tek başına “problem var” anlamına gelmez ama kesinlikle araştırılması gereken bir sinyal olabilir. Şunu sorabiliriz:

Bu fazladan URL’ler nereden geliyor?

Parametre mi?
Filtre mi?
Eski URL mi?
HTTP / HTTPS varyasyonu mu?
www / non-www mi?
Arşiv mi?
UTM mi?
Yinelenen sayfa mı?

Bazen büyük teknik problemleri böyle basit karşılaştırmalarla fark edebilirsiniz.

22. Filmler.com örneğinde sitemap neden önemliydi?

450.000 oyuncu ve ekip sayfasının tamamını sitemap’e ekleseydik Google’a aslında şu mesajı veriyor olacaktık: “Bunların tamamı bizim için önemli.” Ama gerçekte hepsi aynı değerde değildi.

İçeriği geliştirilmiş kişi sayfalarını sitemap’e aldığımızda başka bir mesaj vermiş olduk:

“Google’da özellikle görmek istediğimiz sayfalar bunlar.”

Bu bence sitemap mantığını da güzel anlatıyor. Sitemap sitenin bütün URL’lerinin dökümü olmak zorunda değil. SEO açısından öne çıkarmak istediğimiz, esas ve değerli URL’leri Google’a bildiren bir araç olarak düşünmek daha doğru.

23. Search Console Sayfa dizine ekleme (Page indexing) raporunu nasıl okumalıyız?

Bence rapora sadece “Kaç sayfa indexed?” diye bakmak yanlış. Şunlara ayrı ayrı bakmak gerekiyor:

Dizine eklenen URL’ler
Dizine eklenmeyen URL’ler
Google’ın seçtiği canonical
Tarandı: Şu anda dizine eklenmiş değil (Crawled – currently not indexed)
Bulundu: Şu anda dizine eklenmiş değil (Discovered – currently not indexed)
‘noindex’ etiketi tarafından hariç tutuldu (Excluded by ‘noindex’ tag)
404
Yönlendirmeler

Burada “Dizine eklenmedi (Not indexed)” listesindeki her URL hata değildir. Örneğin bilinçli olarak noindex verdiğimiz bir sayfanın dizinde olmaması zaten istediğimiz davranıştır. 301 ile yönlendirdiğimiz eski URL’nin dizinden çıkması da problem değildir.

Teknik SEO’da raporun kırmızı görünmesi otomatik olarak hata olduğu anlamına gelmez. Önce şu soruya bakıyoruz:

Beklediğimiz davranış ile gerçekleşen davranış aynı mı?

24. Index Bloat neden büyük sitelerde daha önemli?

500 URL’lik bir sitede 100 gereksiz URL genellikle yönetilebilir. Ama milyonlarca URL’si olan e-ticaret, ilan, haber veya veri tabanı ağırlıklı projelerde aynı oran devasa bir URL havuzu oluşturabilir.

Örneğin 100.000 ürün var. Filtreler nedeniyle 8 milyon URL oluşuyor. Google’ın keşfetmesi, taraması, canonical değerlendirmesi ve güncellemeleri takip etmesi gereken alan çok daha büyük hale geliyor.

Bu nedenle Index Bloat, daha önce konuştuğumuz Tarama Bütçesi (Crawl Budget) konusu ile de bağlantılı.

25. “İnce içerik” gördüğümüz her sayfayı noindex yapmalı mıyız?

Hayır. Bu da SEO’da tehlikeli olabilecek otomatik reflekslerden biri. Bir sayfada 100 kelime olması o sayfayı değersiz yapmaz.

Örneğin bir ürün sayfasında şunlar varsa metin miktarı az olabilir ama kullanıcı için çok değerli olabilir:

Ürün görselleri
Teknik özellikler
Fiyat
Stok
Kullanıcı yorumları
Video
Dokümanlar

Yine aynı noktaya geliyoruz.

Kelime sayısına değil, sayfanın görevine bakıyoruz.

26. Index Bloat analizi yaparken neye bakıyorum?

Genel olarak şunları kontrol edebiliriz:

Sitemap’te kaç URL var?
Google kaç URL biliyor?
Kaçı dizinde?
Parametre URL’leri var mı?
Filtre URL’leri kaç farklı kombinasyon üretiyor?
Site içi arama sayfaları taranabiliyor mu?
Etiket ve arşiv sayfaları ne durumda?
HTTP / HTTPS veya www varyasyonları kalmış mı?
Canonical sinyalleri tutarlı mı?
UTM URL’leri indeksleniyor mu?
Eski site URL’leri hâlâ bulunuyor mu?
Boş veya çok düşük değerli sayfalar var mı?
Site haritasında gereksiz URL bulunuyor mu?

Bunları Search Console, Screaming Frog, sunucu logları ve gerektiğinde başka crawler araçlarıyla birlikte inceleyebiliriz.

27. Burada SEO uzmanının görevi “URL azaltmak” değil

Bu ayrım bence önemli. Index Bloat çalışmasının amacı “Ne kadar az URL, o kadar iyi.” değil. Amaç:

Google’ın gerçekten anlamlı URL’lerle karşılaşmasını sağlamak.

Bir filtre sayfası ciddi trafik getiriyorsa kaldırmak hata olabilir. Bir etiket sayfası güçlü bir konu merkezi haline geldiyse noindex yapmak hata olabilir. Bir oyuncu sayfası içerik, filmografi ve biyografi açısından güçlü hale geldiyse Filmler.com’da olduğu gibi dizine açmak doğru olabilir.

Teknik SEO’da sayı azaltmaya değil, kaliteyi ve mimariyi iyileştirmeye çalışıyoruz.

28. Schema ve Index Bloat neden aynı bölümün konusu?

İlk bakışta birbirinden farklı görünebilir. Ama bence ikisi de aynı probleme cevap veriyor:

Google sitemizi doğru anlayabiliyor mu?

Schema ile “Bu sayfada ne var?” sorusunu cevaplıyoruz. Index Bloat kontrolüyle “Hangi URL’ler gerçekten önemli?” sorusunu cevaplıyoruz.

Birinci tarafta içeriğin anlamını temizliyoruz. İkinci tarafta URL yapısını temizliyoruz.

Sonuç olarak

Google’a daha fazla sayfa göndermek her zaman daha iyi değil. Daha fazla Schema eklemek de her zaman daha iyi değil.

Filmler.com’da yaklaşık 450.000 oyuncu ve ekip sayfasının tamamını dizine açmak yerine içerik girilmiş ve kullanıcıya gerçek değer sunan sayfaları seçmemiz bunun güzel bir örneği oldu. Daha az sayfa gönderdik. Ama Google’a gönderdiğimiz sayfaların kalitesini yükselttik. Sonuç da daha başarılı sayfalar olarak geri döndü.

Bence teknik SEO’nun önemli bir kısmını şu cümle özetliyor:

Google’ın tahmin etmek zorunda kaldığı şeyleri mümkün olduğunca azaltmak.

Hangi URL önemli? Hangi URL esas? Bu sayfa neyi temsil ediyor? Bu bilgi ürünün fiyatı mı? Bu sayfa dizine girmeli mi? Bu sayfanın başka bir sürümü var mı?

Bu soruların cevaplarını mümkün olduğunca açık verirsek hem Google için hem bizim için daha yönetilebilir bir site ortaya çıkıyor.

Teknik SEO’da amaç Google’a daha çok şey göstermek değil.

Doğru şeyi, doğru URL’de, doğru sinyallerle göstermek.

Önceki: 24. Bölüm, Site Neden Yavaş Açılıyor? · İçindekiler · Sonraki: 26. Bölüm, Birden Fazla Ülkeye SEO Nasıl Yapılır?

Bu bölümün ilk hali X’te yayınlandı (29 Eylül 2026).

25. Bölüm: Google Sayfanızı Daha İyi Nasıl Anlıyor?