40. Bölüm: Marketplace, İlan ve Büyük Veritabanlı Sitelerde SEO

Uzaklara uzanan düzenli arşiv rafları ve ön planda masada laptop

Son güncelleme: 1 Kasım 2026.

500 sayfalık bir siteyi yönetmekle 10 milyon URL üretebilen bir siteyi yönetmek aynı şey değil.

Kurumsal veya B2B sitelerde birkaç yüz sayfa gayet normal olabilir. Ama marketplace, ilan, emlak, otomobil, haber, seyahat, sinema, ürün karşılaştırma veya büyük bir veri tabanından beslenen projelerde URL sayısı milyonlara çıkabilir.

Burada SEO’nun önemli bir kısmı artık “Nasıl daha fazla sayfa üretiriz?” değil. “Hangi sayfaları gerçekten üretmeli, hangilerini Google’a açmalı ve hangilerini hiç oluşturmamalıyız?” sorusuna dönüşüyor.

Büyük sitelerde bazen en iyi SEO çalışması yeni sayfa açmak değil, gereksiz milyonlarca URL’yi hiç üretmemek olabilir.

1. Büyük sitelerde asıl problem URL üretmek değil, URL’leri kontrol etmek

Bir kurumsal sitede şunlar gibi birkaç yüz URL olabilir:

  • Ana sayfa
  • Hizmetler
  • Ürünler
  • Blog
  • Hakkımızda
  • İletişim

Ama marketplace veya ilan sitesinde URL sayısı çok daha hızlı büyür. Örneğin şunlar birbiriyle kombinasyon oluşturmaya başladığında teorik olarak milyonlarca farklı URL ortaya çıkabilir:

  • 100 kategori
  • 81 şehir
  • Yüzlerce ilçe
  • Marka
  • Model
  • Renk
  • Fiyat
  • Yıl
  • Beden
  • Özellik
  • Sıralama

Bu yüzden büyük sitelerde ilk sorum “Kaç URL’niz var?” değil, “Kaç farklı URL üretebilirsiniz?” oluyor.

Çünkü ikisi aynı şey değil.

2. Her veritabanı kaydı Google’da sayfa olmak zorunda değil

Bunu Filmler.com tarafında çok net yaşadık. Veri tabanımızda yaklaşık 450.000 oyuncu ve ekip kaydı vardı.

Teorik olarak şöyle düşünebilirdik:

“450.000 kayıt varsa 450.000 kişi sayfasını sitemap’e atalım. Her sayfaya sadece 1 kişi gelse 450.000 ziyaretçi eder.”

Bu hesap kulağa güzel geliyor. Hatta büyük veri tabanlı projelerde bu hesap çok yapılır. Ama pratikte her zaman böyle çalışmıyor. Çünkü sayfa sayısı arttıkça trafik her zaman artmıyor.

Tam tersine:

  • Zayıf sayfalar çoğalabiliyor.
  • Tarama kaynakları dağılabiliyor.
  • Dizin şişebiliyor.
  • Güçlü sayfaların önemi azalabiliyor.
  • Google çok fazla düşük değerli URL ile karşılaşabiliyor.

Yani Daha fazla sayfa = daha fazla trafik gibi doğrusal bir denklem yok. Bazen daha az ama güçlü sayfa çok daha iyi sonuç verebilir.

Biz Filmler.com’da her kaydı indexletmek yerine yalnızca yeterli içeriğe sahip kişi sayfalarını indexlemeyi ve sitemap’e eklemeyi tercih ettik. Aynı yaklaşımı sitenin başka bölümlerinde de kullandık.

Google’a “Elimizde ne varsa indexle.” demek yerine “Bunlar bizim gerçekten değerli sayfalarımız.” demeye çalıştık.

3. Daha fazla indexlenen sayfa her zaman daha iyi değildir

Bir site 1 milyon URL indexletiyor. Rakibi 200.000 URL indexletiyor. Buradan ilk sitenin SEO açısından daha güçlü olduğunu söyleyemeyiz.

Belki ilk sitenin 800.000 sayfasında yeterli değer yok. Google:

  • Benzer sayfaları tekrar tekrar tarıyor.
  • Boş sayfalara ulaşıyor.
  • Gereksiz filtre kombinasyonları görüyor.
  • Çok zayıf içeriklerle karşılaşıyor.

İkinci site ise daha az ama daha güçlü sayfalar sunuyor.

Büyük projelerde bazen:

Index sayısını azaltmak SEO başarısı olabilir.

4. Dizin Şişmesi (Index Bloat) büyük sitelerde çok daha tehlikeli

Dizin Şişmesini (Index Bloat) 25. bölümde konuşmuştuk. Büyük veri tabanlı projelerde konu çok daha kritik hale geliyor.

Örneğin otomobil ilan sitesinde /otomobil/ değerli. /otomobil/bmw/ değerli olabilir. /otomobil/bmw/3-serisi/ değerli olabilir.

Ama sonra /otomobil/bmw/3-serisi/siyah/otomatik/2019/100000-120000-km/ gibi giderek daha spesifik kombinasyonlar oluşmaya başlıyor.

Her kombinasyon için şu soruları sormak gerekiyor:

  • Arama talebi var mı?
  • Yeterli ilan var mı?
  • Kalıcı bir ihtiyaç mı?
  • Kullanıcıya farklı bir değer sunuyor mu?
  • Ana kategoriyle çakışıyor mu?

Sistem URL üretebiliyor diye her URL’yi indexlemek zorunda değiliz.

5. Filtreli Gezinme (Faceted Navigation) en kritik konulardan biri

Marketplace ve ilan sitelerinde kullanıcı filtre kullanmak ister. Bu tamamen normal.

Örneğin şu filtreler kullanıcı deneyimi için çok faydalı:

  • Marka
  • Model
  • Şehir
  • Fiyat
  • Renk
  • Beden
  • Cinsiyet
  • Yıl
  • Kilometre
  • Oda sayısı

SEO problemi filtre kullanılması değil. Problem:

Her filtre kombinasyonunun ayrı, crawl edilebilir ve indexlenebilir URL haline gelmesi.

Çünkü filtre sayısı arttıkça kombinasyon sayısı katlanarak büyüyor.

6. Hangi filtre sayfaları indexlenmeli?

Tek bir cevap yok. Ben şu sorulara bakarım:

  • Gerçek arama talebi var mı?
  • Sayfada yeterli sonuç var mı?
  • Kullanıcı için anlamlı mı?
  • Kalıcı bir kategori gibi çalışabilir mi?
  • Benzersiz değer ekleyebilir miyiz?
  • İç link verebilir miyiz?
  • Sürekli boş kalma ihtimali var mı?

Örneğin “İstanbul kiralık daire” çok anlamlı bir landing page. “İstanbul Kadıköy kiralık daire” yine anlamlı. “İstanbul Kadıköy 3+1 kiralık daire” için de ciddi arama talebi olabilir.

Ama “İstanbul Kadıköy 3+1 üçüncü kat güney cephe kombili 15-20 yıllık bina” sayfasını teknik olarak URL oluşturabiliyor diye indexlemek zorunda değiliz.

7. Her renk veya özellik için ayrı sayfa açmak mantıklı olmayabilir

Bunu e-ticarette de sık görüyoruz. Örneğin bir moda sitesinde şunlar gibi ayrı sayfalar oluşturulabilir:

  • kırmızı mezuniyet elbisesi
  • siyah mezuniyet elbisesi
  • beyaz mezuniyet elbisesi

Ama bu Her renk için mutlaka ayrı SEO sayfası açmalıyız. anlamına gelmiyor.

Kararı şu verilere göre vermek daha doğru:

  • Arama hacmi var mı?
  • Kullanıcı gerçekten bu kombinasyonu arıyor mu?
  • Elimizde yeterli ürün var mı?
  • Sayfa kalıcı olacak mı?
  • Ürün çeşitliliği yeterli mi?
  • Ana kategoriyle çakışıyor mu?

Örneğin “kırmızı mezuniyet elbisesi” ciddi arama alıyor ve elimizde yeterli ürün varsa ayrı sayfa anlamlı olabilir. Ama “mint yeşili mezuniyet elbisesi” neredeyse hiç aranmıyor ve elimizde yalnızca tek ürün varsa ayrıca sayfa açmak gereksiz olabilir.

Bazen stratejiyi arama hacmi belirler. Bazen elimizdeki ürün sayısı. Bazen de ikisi birlikte.

Büyük sitelerde önemli olan:

Sistemin URL üretebilmesi değil, o URL’nin gerçekten SEO sayfası olmaya değer olması.

8. Filtre kullanıcının hakkı, index Google’ın hakkı değil

Kullanıcının istediği kadar filtre uygulamasına izin verebiliriz. Ama:

Kullanıcıya sunduğumuz her filtre sonucunu Google’a sunmak zorunda değiliz.

Bu ikisi birbirinden farklı. Filtre URL’si:

  • noindex olabilir.
  • Canonical başka sayfaya gidebilir.
  • Crawl edilmesi sınırlandırılabilir.
  • Bazı filtreler kontrollü SEO landing page’e dönüştürülebilir.

Teknik çözüm sitenin mimarisine göre değişir. Önemli olan kararın bilinçli verilmesi.

9. Programatik sayfa üretmek kötü bir şey değil

Programatik SEO bazen kötü içerikle eş anlamlı kullanılıyor. Bence yanlış. Bir şablondan binlerce sayfa üretmek tek başına problem değil.

Örneğin “İstanbul hava durumu”, “Ankara hava durumu”, “Antalya hava durumu” gibi binlerce lokasyon sayfası otomatik üretilebilir.

Eğer her sayfa şunları sunuyorsa programatik üretim gayet anlamlı olabilir:

  • Gerçek veri
  • Doğru bilgi
  • Kullanıcı ihtiyacı
  • Yeterli içerik

Problem şurada başlıyor:

Elimizde veri var diye hiçbir kullanıcı ihtiyacını düşünmeden milyonlarca sayfa üretmek.

10. Veri tabanı sayfası ile içerik sayfası aynı şey değil

Bir sistemde kayıt bulunması sayfanın içerik açısından yeterli olduğu anlamına gelmiyor.

Örneğin oyuncu sayfasında sadece şunlar bulunabilir:

  • İsim
  • Fotoğraf
  • Doğum tarihi
  • Oynadığı birkaç film

Teknik olarak sayfa var. Ama kullanıcı için yeterince değerli mi?

Filmler.com’da “Kimdir?” sayfaları için sadece filmografiyi tekrar etmek istemiyoruz. Filmografi zaten sistemde var. Bunun üzerine şunlar gibi gerçekten yeni değer eklemek istiyoruz:

  • Kariyer
  • Özel hayat
  • İlginç bilgiler
  • Önemli yapımlar
  • Sık sorulan sorular

Veri tabanındaki bilgiyi HTML’e basmak ile faydalı sayfa oluşturmak aynı şey değil.

11. Boş kategori sayfaları büyük problem olabilir

Marketplace’lerde çok sık görülüyor. Örneğin “Antalya / Elektrikli Otomobil / 2025” sayfası oluşmuş. Ama ilan yok.

Google yine URL’ye ulaşabiliyor. Binlerce farklı kombinasyonda “Sonuç bulunamadı.” sayfaları oluşuyor. Bunların tamamının indexlenmesi gerekmiyor.

Özellikle veri sürekli değişiyorsa şunları tanımlamak faydalı olabilir:

  • Minimum sonuç sayısı
  • Indexleme kriteri
  • Sitemap kriteri

12. Minimum içerik veya sonuç eşiği belirlemek işe yarayabilir

Örneğin şöyle bir sistem kurulabilir:

  • 0 sonuç → indexleme
  • 1 sonuç → indexleme
  • Yeterli sonuç → indexlenebilir

Burada herkes için geçerli “En az 20 sonuç olmalı.” gibi bir sayı yok. Projenin yapısına göre 5 olabilir. 10 olabilir. 50 olabilir.

Asıl mesele:

Kararı kurala bağlamak.

Büyük sitelerde her URL’yi insanın tek tek incelemesi mümkün olmadığı için SEO kararlarını algoritmaya çevirmek gerekiyor.

13. SEO kuralları kodun bir parçası haline gelmeli

Küçük sitede SEO uzmanı “Bu sayfayı noindex yapalım.” diyebilir. Geliştirici uygular.

Büyük sitede milyonlarca URL varsa böyle çalışamazsınız. Şuna dönüşmesi gerekir:

“Şu koşulları sağlayan sayfalar indexlenebilir.”

Örneğin şu durumlarda sayfa indexlenebilir:

  • En az X sonuç varsa
  • Yeterli bilgi varsa
  • Kullanıcı talebi varsa
  • Belirli kategori tipindeyse
  • İç link alıyorsa

Bu noktadan sonra SEO kararı ürün ve yazılım sisteminin içine giriyor.

14. Sitemap’e her URL’yi koymak zorunda değiliz

Sitemap bir URL çöplüğü olmamalı. Ben sitemap’i Google’a önemli URL’lerimizi gösterdiğimiz kontrollü liste olarak görmeyi tercih ediyorum.

Büyük projelerde şöyle ayrımlar yapılabilir:

  • Ürün sitemap
  • Kategori sitemap
  • İlan sitemap
  • Profil sitemap
  • İçerik sitemap

Bu yapı sorun tespit etmeyi de kolaylaştırır. Örneğin “İlan sayfalarının indexlenme oranı neden düşük?” diye ayrıca inceleyebiliriz.

15. Sitemap aynı zamanda kalite filtresi olabilir

Filmler.com’da yaptığımız gibi. Bir kişi sayfası yeterli kriterleri karşılamıyorsa sitemap’e girmiyor. Yeterli içerik oluştuğunda sisteme otomatik olarak eklenebilir.

Böylece sitemap “Veritabanında bulunan her şey” değil, “Indexlenmesini istediğimiz şeyler” haline geliyor.

Büyük sitelerde bence çok önemli bir ayrım.

16. Haber sitelerinde sayfanın ne zaman indexleneceği de stratejidir

Haber sitelerinde bazı sayfalar yalnızca belli dönemlerde ciddi trafik getirir. En net örneklerden biri seçim dönemleri.

Seçim yaklaşınca hemen herkes şunları hazırlamaya başlar:

  • İl sonuçları
  • İlçe sonuçları
  • Aday sayfaları
  • Parti sayfaları
  • Oy oranları
  • Canlı sonuç sayfaları

Burada önemli konu yalnızca sayfayı üretmek değil.

Ne zaman indexleteceğiniz de stratejinin parçası olabilir.

Çünkü bütün sayfa yapınızı aylar önceden açarsanız rakipler şunları görebilir:

  • Hangi sayfaları hazırladığınızı
  • URL yapınızı
  • Hangi il ve ilçelere odaklandığınızı
  • Hangi sorguları hedeflediğinizi

Bir anlamda stratejinizi de paylaşmış olursunuz.

Bu nedenle bazı projelerde şu yaklaşım daha doğru olabilir:

  • Bazı sayfaları erkenden indexletmek
  • Bazılarını hazır tutmak
  • Bazılarını ise rakiplerin pozisyon almakta zorlanacağı zamana kadar bekletmek

Özellikle dönemsel trafikte sadece teknik hazırlık değil, yayına alma ve indexleme zamanı da SEO kararına dönüşüyor.

Bu, 36. bölümde haber SEO’da anlattığımız hazırlık ve zamanlama mantığının başka bir versiyonu.

17. Tarama Bütçesi (Crawl Budget) ne zaman gerçekten önem kazanıyor?

Küçük bir sitenin “Crawl budget problemim var.” demesi çoğu zaman öncelikli konu değil. Ama milyonlarca URL üretebilen bir marketplace’te konu gerçekten anlamlı hale gelebilir. Tarama bütçesini 23. bölümde anlatmıştım.

Googlebot zamanını şunlarda harcıyorsa önemli sayfalara daha verimli yönlendirmek isteyebiliriz:

  • UTM URL’lerde
  • Sonsuz filtrelerde
  • Boş sayfalarda
  • Parametrelerde
  • Duplicate URL’lerde

Burada amaç “Google günde sadece X sayfa tarar.” gibi sabit bir sayı düşünmek değil.

Googlebot’un gereksiz URL’lerle uğraşmasını azaltmak.

Siteye yeni bir ilan eklendi. URL oluştu. Peki Google o URL’yi nasıl bulacak? Sadece sitemap yeterli mi?

Bence önemli sayfaların site mimarisi içerisinde de yer bulması gerekir. Örneğin Ana sayfa → Ana kategori → Alt kategori → Şehir → İlan gibi bir yapı Google’a ve kullanıcıya mantıklı yol sunar.

Sadece veri tabanında duran ve hiçbir yerden link almayan milyonlarca sayfa üretmek iyi bir strateji değil.

19. Yetim Sayfalar (Orphan Pages) büyük sitelerde sessizce çoğalabilir

Bir sayfa sitemap’te var, Google tarafından biliniyor ama sitenin hiçbir yerinden iç link almıyor. Büyük veri tabanlarında bu çok kolay oluşabilir.

Özellikle şunlar yetim kalabilir:

  • Eski ilanlar
  • Eski ürünler
  • Profil sayfaları
  • Programatik sayfalar

Crawl araçlarıyla bu yapı ayrıca kontrol edilmeli.

20. Sayfalama (Pagination) hâlâ önemli

Bir kategoride 50.000 ürün var. Hepsini tek sayfaya koyamayız. Sayfalama gerekir. Örneğin ?page=2, ?page=3 gibi.

Burada önemli olan Googlebot’un daha derindeki ürünlere ulaşabilmesi. Sadece “Daha fazla yükle” butonuna basıldığında JavaScript ile ürün getiren ama crawl edilebilir link sunmayan yapı problem yaratabilir.

Kullanıcı için sonsuz kaydırma kullanılabilir. Ama arka tarafta crawl edilebilir bir sayfalama sisteminin bulunması faydalı.

21. Sonsuz Kaydırma (Infinite Scroll) tasarım kararı gibi görünür ama SEO’yu etkileyebilir

Kullanıcı aşağı indikçe yeni ilanlar geliyor. Güzel deneyim. Ama Googlebot insan gibi davranmak zorunda değil.

Bu nedenle JavaScript’le sonradan gelen içeriklerin ayrı crawl edilebilir URL veya link yapısına sahip olup olmadığı kontrol edilmeli.

Yine aynı prensip:

Kullanıcı deneyimi ile arama motoru erişilebilirliği birlikte düşünülmeli.

22. İç arama sayfaları indexlenmeli mi?

Marketplace’lerde kullanıcı site içinde arama yapar. Örneğin ?q=iphone. Binlerce farklı kullanıcı araması oluşabilir. Bunların tamamını indexletmek genellikle sağlıklı değil.

Çünkü kötü niyetli kişiler bile şunları üreterek sitenizde indexlenebilir URL oluşturabilir:

  • Spam sorgular
  • Marka isimleri
  • Uygunsuz kelimeler

Ama gerçek arama talebi olan bazı sorgular kontrollü kategori veya landing page haline getirilebilir.

Yani kullanıcı aramasından SEO sayfası üretmek mümkün. Ama otomatik olmamalı.

23. Marketplace’te duplicate içerik kaçınılmaz olabilir

Aynı ürün 10 farklı satıcı tarafından satılıyor. Her satıcı üreticinin aynı açıklamasını kullanıyor. Sonuçta aynı metne sahip 10 sayfa oluşuyor.

Google’ın sıradan duplicate içerik için otomatik bir “duplicate content cezası” uyguladığını düşünmek doğru değil. Ama bizim açımızdan başka soru var:

Neden kullanıcı bu sayfalardan birini tercih etsin?

Marketplace’in ekleyebileceği değer şunlar olabilir:

  • Fiyat
  • Stok
  • Satıcı puanı
  • Teslimat
  • Yorumlar
  • Soru-cevap
  • Karşılaştırma
  • Ürün özellikleri

24. Kullanıcı tarafından oluşturulan içerik büyük avantaj olabilir

İlan ve marketplace sitelerinde içerik yalnızca editör tarafından üretilmiyor. Kullanıcılar şunları üretiyor:

  • İlan açıklaması
  • Yorum
  • Soru
  • Cevap
  • Değerlendirme

Bu çok güçlü olabilir. Ama kalite kontrolü gerekiyor. Çünkü kullanıcı “ACİL SATILIKKK!!!” diye başlık yazabilir. Veya açıklamaya telefon numarası dışında hiçbir şey eklemeyebilir.

Sistem şunlarla kullanıcıyı daha kaliteli içerik üretmeye yönlendirebilir:

  • Zorunlu alanlar
  • Minimum açıklama
  • Yapılandırılmış özellikler
  • Moderasyon

25. Yapılandırılmış Veri (Schema) büyük projelerde çok değerli

Marketplace veya ilan türüne göre farklı Schema türleri kullanılabilir:

  • Product
  • Offer
  • Review
  • AggregateRating
  • JobPosting
  • Event
  • BreadcrumbList

Ama milyonlarca sayfada Schema varsa hata da milyonlarca sayfaya yayılabilir. Küçük sitede bir template hatası 20 sayfayı etkiler. Büyük sitede 2 milyon sayfayı.

Bu yüzden template değişikliklerini çok daha dikkatli test etmek gerekiyor.

26. Büyük sitede küçük hata diye bir şey yok

Bir geliştirici template’te canonical değiştiriyor. Tek satır kod. Ama bu kod 5 milyon URL’yi etkiliyor.

Başka bir geliştirici kategori sayfalarına yanlışlıkla noindex ekliyor. Bir gecede yüz binlerce URL etkileniyor.

Bu nedenle büyük sitelerde değişikliğin büyüklüğünü “Kaç satır kod değişti?” ile değil, “Kaç URL etkilendi?” ile değerlendirmek gerekiyor.

27. Deploy öncesi SEO testi burada çok daha önemli

Büyük sitelerde SEO ekibi geliştirme tamamlandıktan sonra haberdar olmamalı. Örneğin:

  • URL değişiyor.
  • Filtre sistemi değişiyor.
  • Pagination değişiyor.
  • Canonical değişiyor.
  • Yeni kategori açılıyor.
  • Eski ilan davranışı değişiyor.

SEO daha geliştirme başlamadan sürece dahil olmalı.

34. bölümde anlattığım kontrol listesi ve çalışma talimatı (Standard Operating Procedure / SOP) burada doğrudan devreye giriyor.

28. Eski ilan ne olacak?

İlan sitesinde önemli kararlardan biri. Ev satıldı. Araba satıldı. İş ilanı kapandı. Peki URL ne olacak?

Tek bir cevap yok. Bazı durumlarda sayfa bir süre “Bu ilan artık aktif değil.” şeklinde kalabilir. Ve kullanıcıya şunlar gösterilebilir:

  • Benzer ilanlar
  • Aynı bölgedeki ilanlar
  • Aynı marka / model

Bazı durumlarda URL kaldırılabilir. Bazı durumlarda gerçekten eşdeğer bir sayfaya yönlendirme yapılabilir.

Ama her kapanan ilanı ana sayfaya 301 ile göndermek iyi çözüm değil.

29. Eski ürünlerde de aynı mantık var

Bunu 35. bölümde, E-ticaret SEO’da konuşmuştuk.

Örneğin eski model “AyPhone 8” artık satılmıyor. Yeni model “AyPhone 9” geldi.

Bazı projelerde eski ürünü yeni ürüne yönlendirmek mantıklı olabilir. Bazılarında eski ürün sayfasını “Bu ürün artık satılmıyor, yeni modeli burada.” şeklinde tutmak daha faydalı olabilir.

Marketplace’lerde bu karar ürün sayısı ve kullanıcı talebine göre sistemleştirilmek zorunda. Tek tek manuel yapamazsınız.

30. Stok dışı ürün ile kaldırılmış ürün aynı şey değil

Ürün bugün stokta olmayabilir. Yarın tekrar gelecek. Bu durumda sayfayı silmek veya noindex yapmak çoğu zaman gereksiz olabilir.

Kullanıcıya şu seçenekler sunulabilir:

  • Stokta yok
  • Gelince haber ver
  • Benzer ürünleri gör

Ama ürün tamamen üretimden kalkmışsa başka karar gerekebilir.

Büyük sitelerde ürün yaşam döngüsü SEO stratejisinin parçası olmalı.

31. Yeni ilanların keşfedilmesi çok önemli olabilir

Emlak veya otomobil gibi alanlarda yeni ilan önemli. İlan bugün yayınlandı. Google 10 gün sonra keşfetti. Bu noktada ilan belki satılmış bile olabilir.

Bu yüzden şunlar önem kazanıyor:

  • Sitemap güncellemesi
  • Kategori iç linkleri
  • Ana sayfa / yeni ilan alanları
  • Crawl erişimi

Haber sitelerinde anlattığımız hızlı keşif mantığının benzeri burada da var.

32. Marketplace’in kendi sıralama algoritması SEO’yu etkileyebilir

Kategori sayfasında hangi ürünler yukarıda? Sistem nasıl çalışıyor?

  • En yeni
  • En popüler
  • Sponsorlu
  • En ucuz
  • En çok satan

Eğer Google her crawl yaptığında tamamen farklı ürün sıralaması görüyorsa sayfanın yapısı sürekli değişebilir. Veya önemli ürünler hiçbir zaman ilk sayfalara çıkmıyorsa iç link gücü alamayabilir.

Site içi sıralama sistemi sadece ürün ekibinin konusu değil. SEO açısından da düşünülmeli.

33. Sponsorlu ilanlar SEO içeriğini boğmamalı

Marketplace’in para kazanması gerekiyor. Sponsorlu ilanlar doğal.

Ama ilk 30 sonucun 25’i sponsorlu ve aynı ilanlar sürekli tekrar ediyorsa kullanıcı deneyimi düşebilir. SEO trafik getiriyor ama kullanıcı aradığını bulamıyorsa sistemin tamamı zarar görüyor.

Burada SEO ile ticari model arasında denge gerekiyor.

34. Kategori sayfası sadece liste olmak zorunda değil

Örneğin “İstanbul kiralık daire” sayfasında sadece ilan listesi olabilir. Ama kullanıcı için faydalıysa şunlar gibi gerçek veri de sunulabilir:

  • Bölgesel fiyat bilgileri
  • Ortalama metrekare fiyatı
  • İlan sayısı
  • Popüler ilçeler
  • Güncel trendler

Büyük veri tabanlı sitelerin önemli avantajlarından biri bu.

Başkalarının yazamayacağı içeriği kendi verinizden üretebilirsiniz.

35. Birinci taraf veri büyük avantaj

Marketplace’in elinde çok güçlü veri olabilir. Örneğin:

  • En çok aranan otomobil modeli
  • Şehir bazında kira değişimi
  • Ortalama ikinci el fiyatı
  • En hızlı satılan ürünler
  • İş ilanlarında en çok aranan pozisyonlar

Bunlardan şunlar üretilebilir:

  • Rapor
  • Haber
  • Araştırma
  • Grafik
  • İçerik

Bu sadece kullanıcı için değerli değil. Backlink ve Digital PR açısından da güçlü.

Büyük veri tabanınız varsa SEO içeriği sadece internette bulunan bilgileri yeniden yazmak olmamalı.

Kendi veriniz de içeriğe dönüşmeli.

36. Kullanıcı talebi yeni kategori oluşturabilir

Sitedeki iç aramalar çok değerli veri. Örneğin kullanıcılar sürekli “elektrikli SUV” arıyor. Ama sitede böyle bir kategori yok.

Bu veri bize “Belki Elektrikli SUV landing page’i oluşturmalıyız.” diyebilir.

Yani site içi arama verisi şunlar için kullanılabilir:

  • Ürün geliştirme
  • Kategori mimarisi
  • SEO

37. Arama hacmi tek karar kriteri olmamalı

Bir filtre kombinasyonunun SEO araçlarında arama hacmi görünmeyebilir. Ama site içinde her ay 20.000 kişi aynı filtreyi kullanıyor olabilir.

Bu durumda elimizde Google dışındaki araçlardan çok daha güçlü bir veri var:

Gerçek kullanıcı davranışı.

Özellikle büyük marketplace’lerde kendi kullanıcı veriniz bazen keyword research aracından daha değerli olabilir.

38. Çok büyük projelerde Log Analizi ciddi değer sağlar

Screaming Frog bize sitede ne olduğunu gösterebilir. Search Console Google’ın bazı davranışlarını gösterir. Ama sunucu logları Googlebot gerçekte nereye gidiyor? sorusuna cevap verebilir.

Örneğin Googlebot’un taramalarının büyük bölümü şunlara gidiyorsa bunu loglarda görebiliriz:

  • Parametre URL’lerine
  • Eski filtrelere
  • Boş sayfalara
  • Değersiz kombinasyonlara

Milyonlarca URL’lik sitelerde Log Analizi (Log File Analysis) çok daha anlamlı hale geliyor. Log analizine 24. bölümde de değinmiştim.

39. Search Console verisini URL tiplerine ayırmak gerekiyor

Toplam site performansı “10 milyon gösterim.” Güzel. Ama hangi alan?

  • Kategoriler
  • Ürünler
  • İlanlar
  • Şehir sayfaları
  • Marka sayfaları
  • Blog
  • Profil sayfaları

Her URL tipini ayrı analiz etmek çok daha faydalı. Bir template yükselirken başka bir template düşüyor olabilir. Toplam grafik bunu gizleyebilir.

40. Index oranını toplam URL sayısına göre değerlendirmek yanıltıcı olabilir

Örneğin 500.000 ürün URL’si var. 400.000 indexli. İlk bakışta “%80 index oranımız var.” diyoruz.

Ama bu tek başına iyi veya kötü değil. Belki indexlenmeyen 100.000 sayfanın tamamı boş ve zaten indexlenmesini istemiyoruz.

Daha doğru soru:

“Indexlenmesini istediğimiz URL’lerin kaçı gerçekten indexlenmiş?”

Büyük sitelerde bu ayrım çok önemli.

41. Kalite kriterlerini veriye dönüştürmek gerekiyor

Filmler.com örneğine geri dönelim. Bir kişinin indexlenmeye değer olup olmadığına kriter koyabiliriz. Örneğin:

  • Fotoğraf var mı?
  • Biyografi var mı?
  • Yeterli yapım bağlantısı var mı?
  • Ek bilgi var mı?
  • Arama talebi var mı?

Belirli kalite seviyesini geçen sayfa:

  • Sitemap’e girer.
  • Indexlenebilir olur.
  • İç link sistemine dahil edilir.

Büyük sitelerde SEO uzmanlığının önemli kısmı:

SEO kararını ölçeklenebilir kurala dönüştürmek.

42. Büyük sitelerde SEO ekip işi

Marketplace SEO’yu SEO uzmanı tek başına yapamaz. İhtiyaç duyabileceğiniz ekipler:

  • Yazılım
  • Ürün
  • UX
  • Veri
  • İçerik
  • Analitik
  • Pazarlama
  • Operasyon

Örneğin filtrelerin indexlenmesi SEO konusu gibi görünebilir. Ama uygulanması şu ekiplerin ortak kararı olabilir:

  • Backend
  • Frontend
  • Product
  • SEO

Bu yüzden büyük projelerde SEO’nun teknik bilgi kadar iletişim gücü de önemli.

43. Kontrol listeleri ve otomasyon burada zorunluluğa dönüşüyor

Bir sitede 5 milyon URL varsa her sabah manuel kontrol edemezsiniz.

Sistemlerin şu durumlarda uyarı üretmesi çok değerli:

  • Sitemap hata verirse
  • Indexlenebilir sayfa sayısı aniden artarsa
  • Canonical değişirse
  • noindex yayılırsa
  • 404 sayısı artarsa
  • Sunucu cevap süreleri bozulursa

Küçük sitede kontrol listesi kolaylık. Büyük sitede:

Operasyonun çalışabilmesi için zorunluluk.

44. Büyük veritabanlı SEO’nun özeti aslında “seçmek”

Bence bütün konunun özeti burada.

Elimizde 450.000 kişi kaydı var. Hepsini indexlemek zorunda değiliz.

5 milyon filtre kombinasyonu var. Hepsini landing page yapmak zorunda değiliz.

10 milyon URL üretebiliyoruz. Bu 10 milyon URL’yi Google’a göstermek zorunda değiliz.

SEO bazen daha fazla içerik üretmek değil.

Doğru sayfaları seçmek.

Ve bazı sektörlerde sadece hangi sayfayı seçeceğimiz değil:

Ne zaman indexleteceğimiz de stratejinin parçası.

Sonuç olarak

Marketplace, ilan ve büyük veritabanlı sitelerde SEO yaptıkça şu soru giderek daha önemli hale geliyor: “Google’a daha ne gösterebiliriz?” değil, “Google’a gerçekten ne göstermeliyiz?”

Küçük sitelerde sayfa üretmek için uğraşıyoruz. Büyük sitelerde ise sayfa üretimini kontrol etmek için uğraşıyoruz.

Filmler.com’da yaklaşık 450.000 oyuncu ve ekip kaydımız olması, 450.000 sayfanın tamamını indexletmemiz gerektiği anlamına gelmiyordu.

Aynı şekilde bir moda sitesinin 30 rengi olması, 30 renk için ayrı kategori açması gerektiği anlamına gelmiyor.

Bir haber sitesinin seçim için binlerce sayfa hazırlayabiliyor olması da bunların tamamını aylar önceden indexletmesi gerektiği anlamına gelmiyor.

Büyük sitelerde en tehlikeli düşüncelerden biri:

“Ne kadar çok sayfa, o kadar çok trafik.”

Bazen doğru olabilir. Ama bazen tam tersi.

Bu yüzden büyük sitelerde SEO biraz da şu iki soruyu sorma işi:

“Bu sayfa gerçekten var olmalı mı?”

ve

“Varsa, ne zaman Google’a göstermeliyim?”

Bence büyük ölçekli SEO’nun önemli kısmı tam olarak burada başlıyor.

Önceki: 39. Bölüm, WordPress Sitelerde SEO Nasıl Yapılır? · İçindekiler · Sonraki: 41. Bölüm, SEO Çalışması Nasıl Yönetilir?

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