Büyük sitelerde indekslenmeyen sayfalar nasıl sınıflandırılır?

Büyük sitelerde indekslenmeyen sayfalar topluca nasıl sınıflandırılır?: önce veri setini kurun

10.000 URL’yi aşan projelerde ilk hata, indekslenmeyen sayfaları tek tek URL inceleyerek çözmeye çalışmaktır. Ölçek büyüdüğünde doğru yaklaşım, her URL’yi bir neden kümesine, bir klasöre, bir şablona ve bir iş değeri seviyesine bağlayan tek çalışma tablosu kurmaktır. Bu tabloya en az şu kolonlar girer: URL, GSC nedeni, son bilinen HTTP durum kodu, canonical hedefi, sitemap içinde olup olmadığı, noindex durumu, robots.txt erişimi, klasör, şablon, iç link derinliği ve varsa gelir ya da dönüşüm değeri.

Google’ın Page Indexing raporu dokümanında da vurgulandığı gibi, “Not indexed” tek başına hata değildir. Bu yüzden veri setinin ilk ayrımı şudur: gerçekten indekslenmesi gereken ama dışarıda kalanlar ve bilerek indeks dışında tutulanlar. Giriş, sepet, filtre, sıralama, arama sonucu veya varyant türevi sayfaları ilk günden ayrı işaretlemezseniz, rapor gürültüsü karar kalitesini düşürür.

• Temel veri kaynakları: GSC Page Indexing exportu, sitemap listesi, crawl verisi, CMS şablon bilgisi.
• Mutlaka eklenmesi gereken kolonlar: canonical hedefi, status code, klasör, şablon, iş değeri.
• Karar kolonları: düzelt, izle, birleştir, canonicalize et, bilinçli hariç bırak.

GSC nedenlerini klasör, şablon ve URL pattern ile eşleyin

İkinci adımda GSC nedenlerini tek tek URL açıklaması gibi değil, bulk segment gibi okumak gerekir. Crawled – currently not indexed, Discovered – currently not indexed, Duplicate, Alternate canonical, Soft 404 ve Excluded by noindex kümeleri ayrı etiketler olmalıdır. Buradaki asıl amaç, örneğin 2.400 URL’nin aynı ürün varyant şablonundan mı, 1.300 URL’nin aynı filtre klasöründen mi, yoksa 800 URL’nin parametreli arama sonuçlarından mı geldiğini görmektir.

Google’ın eksik sayfa sorun giderme rehberi tekil URL teşhisi için yararlıdır; ancak büyük sitelerde karar farkını yaratan şey, nedeni pattern ile eşlemektir. Pratikte Crawled – currently not indexed çoğu zaman taranmış ama yeterli kalite, benzersizlik veya talep sinyali üretmeyen sayfalarda yoğunlaşır. Discovered – currently not indexed ise daha sık biçimde zayıf keşif, iç link eksikliği, aşırı URL envanteri veya crawl budget baskısı tarafına işaret eder. Bu ayrımı yapmadan iki kümeye aynı çözümü uygulamak çoğu zaman yanlıştır.

Pattern eşleme mantığı

Regex, klasör kırılımı ve şablon ID’leri burada işinizi hızlandırır. /arama/, ?sort=, ?color=, /amp/, varyant ekleri, pagination dizileri ve şehir-ilçe gibi yakın kopya üretim yapan kalıplar ayrı segmentler olarak etiketlenmelidir. Google’ın canonical belgesine göre sitemap dahil edilmesi zayıf, rel=canonical ve yönlendirme daha güçlü sinyallerdir; dolayısıyla duplicate kümelerinde yalnızca GSC etiketine değil, bildirilen canonical ile Google’ın seçtiği canonical farkına da bakılmalıdır.

• Crawled kümesi: kalite, benzersizlik, render ve canonical tutarlılığı kontrol edilir.
• Discovered kümesi: iç link, orphan durum, log hit ve URL envanteri kontrol edilir.
• Duplicate kümeleri: şablon farkı değil, kanonik temsil sorunu olarak ele alınır.

Sitemap, canonical, noindex ve robots.txt çakışmalarını ayrıştırın

Büyük sitelerde en çok vakit kaybettiren durum, aynı URL’nin bir yandan sitemap’te yer alırken diğer yandan noindex taşıması veya canonical ile başka yere işaret etmesidir. Google’ın sitemap belgesi sitemap gönderiminin keşfi kolaylaştırdığını ama indeks garantisi vermediğini açıkça söyler. Bu nedenle sitemap-to-index farkı, doğrudan “Google hata yaptı” diye yorumlanmamalıdır; önce URL’nin gerçekten indeks adayı olup olmadığı netleştirilmelidir.

Çakışma ayrıştırmasında her URL için şu dört soruya aynı satırda cevap vermelisiniz: taranabiliyor mu, indekslenebilir mi, canonical olarak kendini mi gösteriyor, sitemap’te bulunması mantıklı mı? Google’ın noindex dokümanına göre noindex’in çalışması için sayfanın robots.txt ile engellenmemesi gerekir. Buna ek olarak robots meta tag spesifikasyonu, indeksleme ve sunum kurallarının tarama sırasında görülmesi gerektiğini netleştirir. 2026’da bu dokümanda AI Overviews ve AI Mode bağlamı da açık biçimde yer aldığı için, noindex ve nosnippet kararları artık yalnızca klasik sonuç sayfası açısından değil, içerik kullanım izinleri açısından da düşünülmelidir.

Hızlı çakışma matrisi

• Sitemap’te var + noindex var: genelde sinyal uyumsuzluğu; çoğu durumda düzeltin.
• Robots.txt engelli + noindex var: noindex görülmez; blok mantığını yeniden kurun.
• Canonical başka yere gidiyor + sayfa indeks bekleniyor: şablon veya head hatası arayın.
• 200 dönen ince içerik + soft 404 etiketi: kalite ve şablon zayıflığını ölçün.
• Redirect veren URL sitemap’te duruyor: sitemap temizliği yapın.

Canonical rehberinde belirtildiği üzere Google, farklı sinyalleri birlikte değerlendirir. Bu yüzden tek başına rel=canonical yazmak yetmez; iç link, sitemap ve yönlendirme sinyalleri de aynı tercihi desteklemelidir.

Log, internal link derinliği ve JavaScript render verisiyle doğrulayın

GSC size sonucu gösterir; nedeni kesinleştirmek için ikinci katman veriye ihtiyaç vardır. Burada en kritik üç alan log hit, iç link derinliği ve render görünürlüğü olur. Üç tıklamadan daha derinde kalan, kategori akışında zayıf bağlanan veya hiç dahili link almayan orphan URL’ler, özellikle Discovered – currently not indexed kümelerinde sık görünür. Eğer bir klasörde çok sayıda URL sitemap’te var ama log’da neredeyse hiç Googlebot hit’i yoksa, sorun çoğu zaman keşif ve önceliklendirme tarafındadır.

Google’ın crawl budget rehberi 2025-12-19 güncellemesinde, düşük değerli veya mükerrer URL envanterinin tarama verimliliğini bozduğunu yeniden netleştiriyor. Aynı rehber, 10.000+ çok hızlı güncellenen siteler ile 1 milyon+ URL içeren büyük yapılar için bu analizin daha anlamlı olduğunu da açıkça söylüyor. 2026 itibarıyla büyük site analizinde soru artık “Google neden bunu indekslemedi” değil, “Google’a hangi URL setini önemli gösteriyorum” sorusudur.

JavaScript tarafında ise sorun çoğu zaman görünmez kalır. Ana içerik sadece client-side render ile geç yükleniyorsa, lazy-load yüzünden metin ilk render’da boş geliyorsa veya canonical etiketi JavaScript tarafından sonradan değişiyorsa, taranmış sayfa ile gerçek kullanıcı sayfası arasında fark oluşur. Canonical dokümanı büyük sitelerde canonical bilgisinin HTML kaynakta net olmasını özellikle önerir. Bu nedenle render parity kontrolü, özellikle ürün varyantı, şehir sayfası ve faceted navigation şablonlarında zorunludur.

10.000+ URL vakası: hangi segment düzeltilir, hangisi bilinçli hariç kalır?

Büyük proje denetimlerinde pratikte en çok işe yarayan yöntem, 10.000+ indeks dışı URL’yi önce GSC nedeni + klasör + şablon + canonical durumu + log hit seviyesi ile yan yana koymaktır. Bu çalışma yapıldığında, sorun genellikle 10.000 farklı URL değil, 7-10 yönetilebilir segment olarak görünür. Operasyonel açıdan asıl fark burada çıkar: ekip tek tek URL kovalamak yerine, örneğin filtre klasörü, varyant şablonu, arama sonucu sayfası, düşük metinli ürün kümesi ve yetim landing page segmentleri üzerinden karar alır.

Bu noktada teknik sinyal yetmez; iş değeri skoru eklemeniz gerekir. Aynı index dışı segmentin içinde yüksek talep gören, gelir üreten veya link alan sayfalar varsa onları önce alırsınız. Örneğin kategoriye yakın ürün kümelerinde güçlü bir backlink sinyali varsa, bu segment yanlışlıkla indeks dışında kalmış olabilir ve önceliği yükselir. Buna karşılık login, cart, filtre, sıralama, dahili arama, yazdırılabilir sürüm veya parametreli türev sayfalar iş değeri taşımıyorsa, bunları sorun listesine değil bilinçli hariç bırakma listesine yazmak daha doğrudur.

• Düzeltilmesi gerekenler: talep gören kategori ve landing page’ler, benzersiz ürün kümeleri, link alan içerikler.
• Bilinçli hariç kalabilecekler: sepet, giriş, filtre kombinasyonları, dahili arama, yakın kopya varyantlar.
• Yönetici özeti için gerekli kolonlar: segment adı, URL sayısı, beklenen iş değeri, önerilen aksiyon, efor seviyesi.

Bu bölümde en sık yapılan hata, indekslenmeyen her sayfayı kazanılabilir trafik gibi sunmaktır. Oysa büyük sitelerde sağlık, daha çok URL indeksletmekten çok, doğru URL setini indeksletmekle ilgilidir.

SEOYEN ile segment önceliği, raporlama ve tekrar izleme

Toplu sınıflandırma bittiğinde iş sadece teknik teşhis değildir; tekrar izlenebilir bir iş akışına dönüşmesi gerekir. Bu aşamada aynı klasör ve şablonlarda yoğunlaşan teknik sinyalleri görmek için site sağlığı raporu doğal bir merkez görevi görür. GSC’den gelen reason kümelerini tek başına okumak yerine, teknik yoğunluğu klasör bazında takip etmek raporu daha aksiyon odaklı hale getirir.

Önceliklendirme tarafında teknik veri ile iş değeri verisini birleştirmek gerekir. Bir segmentin düzeltilmeye değip değmeyeceğini anlamak için anahtar kelime aracı ile talep kontrolü yapılabilir; canlı görünürlük etkisini izlemek için de sıralama takibi aynı akışa bağlanabilir. Bu yaklaşım, farklı araçlar arasında veri taşıma yükünü azaltır. SEOYEN’in Türkçe arayüzü, TL bazlı fiyatlandırması ve yerel Türkçe desteği özellikle küçük ekiplerin bu süreci daha düzenli işletmesine yardımcı olur.

Raporlama aşamasında yönetime her URL’yi değil, segment bazlı değişimi göstermek daha doğrudur: kaç URL sitemap’te kaldı, kaç URL canonicalize edildi, hangi klasörde crawl hit arttı, hangi segmentte indekslenme geri geldi. Ekip içi operasyonu sade tutmak isteyenler için paket karşılaştırması sayfası üzerinden uygun kurgu ayrıca incelenebilir. Buradaki amaç araç övmek değil, teknik teşhisi düzenli ölçüm ve karar takibine bağlamaktır.

Adım Adım İndekslenmeyen URL’leri toplu sınıflandırma workflow’u

Uygulanabilir bir sistem kurmak istiyorsanız aşağıdaki beş adım yeterlidir. Bu akış, büyük sitelerde tek seferlik temizlikten çok, tekrar eden bir teknik SEO rutini oluşturur.

1. Veri kaynaklarını tek tabloda birleştir. GSC Page Indexing exportunu, sitemap listesini, HTTP durum kodlarını, canonical hedeflerini, klasör ve şablon bilgisini aynı dosyada toplayın. İş değeri kolonları olmadan teknik doğruluk tek başına öncelik üretmez.
2. Neden kümelerini segment et. GSC reason değerlerini klasör, pattern ve şablon bazında gruplayın. Tek tek URL saymak yerine hangi kümenin büyüdüğünü görün; böylece template kaynaklı sorunları daha hızlı fark edersiniz.
3. Çakışan teknik sinyalleri ayıkla. Noindex, robots.txt, redirect, canonical ve sitemap işaretlerini karşılaştırın. Aynı URL üzerinde iki zıt sinyal varsa önce bu çelişkiyi giderin; aksi halde indekslenme teşhisi bulanık kalır.
4. Keşif ve tarama verisiyle doğrula. Log hit, iç link derinliği, orphan durumu ve render görünürlüğünü kontrol edin. Özellikle Discovered kümelerinde keşif; Crawled kümelerinde kalite ve render sorunları daha sık öne çıkar.
5. İş değerine göre önceliklendir. Trafik potansiyeli, dönüşüm etkisi, gelir katkısı ve harici otorite sinyallerine bakın. Her indeks dışı URL’nin düzeltilmesi gerekmez; doğru karar, doğru segmenti seçmektir.

Bu workflow düzenli uygulandığında indekslenmeyen sayfalar bir belirsizlik alanı olmaktan çıkar, yönetilebilir segmentlere dönüşür. Büyük sitelerde hız kazandıran şey daha fazla export almak değil, aynı veriyi daha iyi sınıflandırmaktır.

Sıkça Sorulan Sorular