İndeksleme Hatalarını Tespit Etme ve Search Console Yönetimi

Bir sayfayı yayınladınız, içerik açık, URL çalışıyor, sitemap içinde görünüyor fakat Google aramasında sayfa yok. Bu noktada çoğu kişinin ilk refleksi yeniden indeksleme talebi göndermek oluyor. Oysa İndeksleme Hatalarını Tespit Etme ve Search Console Yönetimi sürecinde asıl mesele düğmelere basmak değil, URL'nin hangi aşamada takıldığını belirlemektir. Google Search Console indeksleme hataları nasıl tespit edilir sorusunu doğru yanıtlayabilmek için discovery, crawling, HTTP yanıtı, rendering, indexability, canonicalization ve index selection katmanlarını ayrı ayrı incelemek gerekir. Bu rehberde Search Console sayfa dizine ekleme sorunları nasıl düzeltilir sorusundan noindex canonical robots.txt ve sitemap kaynaklı indeksleme sorunlarına kadar bütün süreci sistematik bir teşhis modeliyle ele alacağız.

Google İndeksleme Nedir?

Google indeksleme, bir URL'nin yalnız bulunması değil, içeriğinin işlenerek Google'ın arama indeksine alınabilecek hale gelmesi sürecidir. Bir sayfanın taranması, onun mutlaka indeksleneceği anlamına gelmez. Ben teknik audit çalışmalarında bu ayrımı ilk kontrol noktası olarak kullanıyorum çünkü ekipler çoğu zaman crawl başarısını index başarısı sanıyor. Google önce URL'yi keşfeder, erişmeye çalışır, sayfayı işler ve daha sonra indeks için uygun olup olmadığına karar verir. Bu zincirin herhangi bir aşamasındaki sorun farklı bir çözüm gerektirir.

Google Bir Web Sayfasını Nasıl Bulur?

Google bir URL'yi internal link, dış bağlantı, XML sitemap veya daha önce bildiği başka bir kaynak üzerinden keşfedebilir. Yeni sayfanın sitedeki hiçbir sayfadan link almaması discovery süresini uzatabilir. Sitemap yardımcıdır fakat güçlü bir site mimarisinin yerine geçmez. Önemli sayfalar kullanıcıların ve crawler'ların erişebildiği doğal bağlantılar almalıdır. Bir URL Google tarafından hiç bilinmiyorsa canonical veya içerik kalitesini analiz etmeden önce discovery sorununu çözmek gerekir.

Crawling Nedir?

Crawling, Googlebot'un bir URL'ye HTTP isteği göndererek sayfayı almaya çalışmasıdır. Robots.txt kuralları, sunucu sorunları veya erişim gereksinimleri bu aşamayı etkileyebilir. URL biliniyor olsa bile Google onu hemen taramak zorunda değildir. Büyük sitelerde URL üretim hacmi ve sunucu kapasitesi de tarama davranışını etkileyebilir. Bu nedenle Search Console mesajını tek başına değil, crawl stats ve gerekiyorsa server log verisiyle birlikte değerlendirmek yararlıdır.

Rendering Nedir?

Rendering, özellikle JavaScript kullanan sitelerde sayfanın çalıştırıldıktan sonraki halinin işlenmesidir. Kaynak HTML içinde ana içerik bulunmuyorsa Google'ın JavaScript sonucunu alması gerekebilir. API hataları veya client-side rendering problemleri Google'ın eksik içerik görmesine neden olabilir. Bu yüzden yalnız tarayıcı ekranında sayfayı görmek yeterli kontrol değildir. URL Denetleme aracındaki canlı test ve rendered HTML incelemesi gerçek teşhis için daha değerlidir.

Indexing Nedir?

Indexing, Google'ın taradığı ve işlediği içeriği kendi indeks sisteminde saklayıp arama sonuçlarına aday hale getirmesidir. Bu aşamada duplicate içerik, canonical seçimi, noindex direktifi ve içerik değeri gibi sinyaller etkili olabilir. Sayfa HTTP 200 dönse bile indekslenmek zorunda değildir. Google aynı içeriğin başka URL'sini temsilci olarak seçebilir. Bu nedenle indekslemeyi yalnız teknik erişim problemi şeklinde ele almak çoğu vakada eksik teşhis üretir.

Serving ve Ranking Nedir?

Serving, indekslenen içeriklerin bir kullanıcı sorgusunda arama sonuçlarına aday olarak sunulması aşamasıdır. Ranking ise uygun adayların sorguya göre hangi sırada gösterileceğiyle ilgilidir. Bir sayfanın indekslenmiş olması üst sıralarda görüneceği anlamına gelmez. Aynı şekilde belirli bir sorguda görünmemesi de mutlaka indeks dışı olduğu anlamına gelmez. İndeks durumunu sorgu sıralamasından bağımsız olarak URL Denetleme üzerinden kontrol etmek daha doğrudur.

Crawling, Indexing ve Ranking Arasındaki Fark Nedir?

Crawling, indexing ve ranking aynı zincirin parçalarıdır fakat aynı işi yapmaz. Taranmak Googlebot'un sayfaya ulaştığını, indekslenmek URL'nin Google indeksinde yer aldığını, sıralanmak ise belirli sorgularda sonuçlar arasında konum kazandığını ifade eder. Bir URL ilk iki aşamayı geçip üçüncü aşamada görünürlük kazanamayabilir. Başka bir URL taranmasına rağmen indeks için seçilmeyebilir. Teşhis sürecinin hızlanması için önce hangi aşamada sorun bulunduğunu tanımlamak gerekir.

Taranmak

Taranmak, Googlebot'un URL'den yanıt alabildiğini gösterir. Bu durum sayfanın indekslendiğini kanıtlamaz. HTTP 200 yanıtı başarılı erişimi gösterse de içerik daha sonra farklı nedenlerle indeks dışı kalabilir. Son crawl tarihi URL Denetleme ekranında teşhis için yararlı bir sinyaldir. Güncel değişikliklerden sonra eski crawl verisine bakıyorsanız canlı test ile mevcut durumu ayrıca kontrol etmelisiniz.

İndekslenmek

İndekslenmek, sayfanın Google'ın sisteminde arama sonuçlarında kullanılabilecek bir belge olarak seçilmiş olmasıdır. Google aynı içerikten birden fazla URL biliyorsa bunlardan yalnız tercih ettiği canonical sürümü indeksleyebilir. noindex bulunan sayfalar da normal koşullarda indeks için seçilmez. Sitemap içinde bulunmak bu kararı garanti etmez. Bu yüzden indekslenmesi beklenen URL setini önceden tanımlamak yönetimi kolaylaştırır.

Arama Sonuçlarında Sıralanmak

Sıralama, indeksleme tamamlandıktan sonraki farklı bir değerlendirme alanıdır. Kullanıcı sorgusu, içerik uygunluğu, bağlantılar ve çok sayıda başka sinyal burada rol oynayabilir. Search Console performans raporunda gösterim almamak doğrudan index hatası olarak yorumlanmamalıdır. Önce URL'nin indeks durumunu kontrol etmek gerekir. İndeksli sayfada sıralama sorunu varsa konu artık yalnız indexability değildir.

Neden Bir Sayfa Taranıp İndekslenmeyebilir?

Sayfa duplicate olabilir, başka URL canonical seçilmiş olabilir veya içerik indeks için yeterince farklı görülmeyebilir. Soft 404 benzeri yapılar da bu sonuçla karşılaşabilir. Programatik olarak üretilmiş çok sayıda birbirine yakın sayfa aynı template problemine sahip olabilir. Teknik olarak temiz bir sayfa da her zaman indeks garantisine sahip değildir. Bu nedenle tarandı şu anda dizine eklenmiş değil hatası nasıl çözülür sorusuna tek satırlık bir çözüm vermek doğru olmaz.

Google Search Console Nedir?

Google Search Console, Google'ın bir web sitesini nasıl gördüğü ve arama sonuçlarındaki görünürlüğünün nasıl geliştiği hakkında site sahiplerine veri sağlayan platformdur. İndeksleme, sitemap, URL denetimi ve tarama bilgileri teknik SEO çalışmalarında doğrudan kullanılabilir. Ben Search Console'u hata ekranı olarak değil, Google ile site arasındaki teknik geri bildirim kanalı olarak değerlendiriyorum. Buradaki mesajların çoğu kök neden değil, gözlenen durumun açıklamasıdır. Doğru kullanım, raporu crawler, sitemap, log ve CMS verisiyle birleştirmeyi gerektirir.

Search Console Hangi Verileri Gösterir?

Search Console indekslenmiş ve indekslenmemiş sayfalara ilişkin gruplar gösterebilir. Sitemap dosyalarının okunup okunmadığı ve çeşitli URL örnekleri incelenebilir. URL Denetleme aracı belirli bir adresin Google indeksindeki durumunu daha ayrıntılı gösterir. Performans raporları organik sorgular, sayfalar, tıklamalar ve gösterimler konusunda ayrı veri sağlar. Bu veri setlerinin her biri farklı soruyu yanıtladığı için doğru raporu doğru amaçla kullanmak gerekir.

SEO Uzmanları Search Console'u Neden Kullanır?

SEO uzmanları Search Console ile önemli landing page'lerin indeks durumunu takip edebilir. Template bazında indeks kaybı veya canonical sorunları daha hızlı fark edilebilir. Sitemap segmentleri yardımıyla gönderilen ve indekslenen URL grupları karşılaştırılabilir. Yeni bir deployment sonrasında beklenmeyen değişikliklerin Google tarafındaki etkisi izlenebilir. Ancak sorun çözümü için çoğu zaman site içi crawl ve teknik ekip verileriyle birlikte çalışmak gerekir.

Geliştiriciler İçin Search Console'un Önemi

Geliştiriciler Search Console üzerinden ürettikleri route, canonical ve robots davranışının Google tarafındaki sonucunu görebilir. Bir template değişikliğinin binlerce URL'yi noindex hale getirdiği vakalar bu araçla fark edilebilir. JavaScript rendering sorunları da URL Denetleme üzerinden incelenebilir. Server hatalarının Googlebot üzerindeki etkisi crawl verileriyle desteklenebilir. Bu nedenle Search Console yalnız pazarlama ekibinin kullandığı bir panel olarak görülmemelidir.

Search Console ile Google Analytics Arasındaki Fark

Search Console Google Search ile site arasındaki görünürlük ve teknik ilişkiye odaklanır. Analytics ise siteye gelen kullanıcıların davranışlarını ölçmeye odaklanır. Search Console bir URL'nin indeks sorununu gösterebilirken Analytics o sayfanın kullanıcı trafiğini anlatır. İki sistemde URL sayıları veya oturum metrikleri bire bir eşleşmek zorunda değildir. Teknik SEO teşhisinde hangi soruya yanıt aradığınızı belirleyip doğru veri kaynağını seçmelisiniz.

Google Search Console Nasıl Kurulur?

Search Console kurulumu mülk tipinin seçilmesi ve sahipliğin doğrulanmasıyla başlar. Domain Property tüm protokol ve alt alan adı sürümlerini geniş kapsamda ele almak için güçlü bir seçenektir. URL Prefix Property ise belirli bir protokol ve URL prefix'i için kullanılabilir. Kurulumdan sonra kullanıcı yetkilerini gereksiz geniş tutmamak önemlidir. Teknik ekip, SEO ekibi ve yöneticiler ihtiyaca uygun erişim seviyeleriyle sisteme dahil edilmelidir.

Domain Property

Domain Property alan adının farklı protokol ve alt alan adı sürümlerini tek mülk altında kapsayabilir. Büyük veya birden fazla subdomain kullanan sitelerde bu görünüm oldukça kullanışlıdır. Doğrulama genellikle DNS üzerinden yapılır. DNS erişimi olmadığı durumlarda süreç altyapı ekibiyle koordinasyon gerektirebilir. Kurum içinde domain sahipliğinin kimde olduğu önceden belgelenirse kurulum daha hızlı ilerler.

URL Prefix Property

URL Prefix Property yalnız tanımlanan URL başlangıcını kapsar. HTTP ve HTTPS veya farklı alt alan adları ayrı mülkler şeklinde değerlendirilebilir. Belirli bir klasörü veya host'u ayrı takip etmek istediğiniz durumlarda yararlı olabilir. Migration projelerinde eski ve yeni yapı için ayrı property'ler izlenebilir. Veri yorumlarken property kapsamının hangi URL'leri içerdiğini unutmamak gerekir.

DNS ile Doğrulama

DNS doğrulaması domain sahipliğini güvenilir biçimde kanıtlamanın yaygın yollarından biridir. Search Console tarafından verilen kayıt DNS sağlayıcısına eklenir. Değişikliklerin yayılması anlık olmayabilir. Kurumsal yapılarda DNS değişikliği kontrollü süreçten geçebilir. Doğrulama kaydını sonradan gereksiz yere kaldırmamak mülk erişiminin korunmasına yardımcı olur.

Kullanıcı ve Yetki Yönetimi

Search Console yetkileri görev ihtiyacına göre verilmelidir. Her ekip üyesinin tam yetkili olması gerekmez. Çalışan değişikliklerinde eski erişimlerin kaldırılması düzenli güvenlik pratiğinin parçasıdır. Ajans veya dış danışman erişimleri de belirli sahiplik politikasıyla yönetilebilir. Yönetim sürecinin yalnız tek kişinin kişisel hesabına bağlı kalmaması kurumsal süreklilik sağlar.

Search Console'da İndeksleme Sorunlarına Nereden Bakılır?

İndeksleme teşhisinde en çok kullanılan alanlar Sayfa Dizine Ekleme raporu, URL Denetleme aracı, Site Haritaları ve Tarama İstatistikleri bölümleridir. URL Kaldırmaları ise farklı bir amaç taşır ve kalıcı indexability yönetimi yerine kullanılmamalıdır. Sayfa Dizine Ekleme raporu toplu görünüm sunarken URL Denetleme tekil sayfayı analiz etmek için daha uygundur. Sitemap raporu discovery ve gönderim tarafını anlamaya yardımcı olur. Bu araçları birlikte okumak tek bir ekrana bakmaktan daha doğru sonuç verir.

Sayfa Dizine Ekleme Raporu

Sayfa Dizine Ekleme raporu Google'ın bildiği URL'leri indekslenmiş ve indekslenmemiş gruplarda gösterir. İndekslenmemiş URL'ler neden kategorilerine ayrılır. Bu kategorilerin tamamı problem değildir. Öncelikle etkilenen URL'lerin indekslenmesini isteyip istemediğinizi kontrol etmelisiniz. Daha sonra URL örneklerini template ve pattern bazında sınıflandırmak kök nedeni bulmayı kolaylaştırır.

URL Denetleme Aracı

URL Denetleme aracı belirli bir URL'nin Google indeksindeki mevcut durumunu kontrol etmek için kullanılır. Google'ın gördüğü canonical, son tarama ve indexability bilgileri burada incelenebilir. Canlı test ise şu anki sayfanın erişilebilir olup olmadığını değerlendirir. İndeks verisi ile canlı test aynı şey değildir. Bir düzeltmeden hemen sonra eski indeks durumu görünürken canlı sayfanın yeni ve doğru davranması mümkündür.

Site Haritaları

Site Haritaları bölümü gönderdiğiniz sitemap dosyalarının okunabilirliğini takip etmeye yardımcı olur. Sitemap dosyasının başarılı işlenmesi içindeki bütün URL'lerin indeksleneceği anlamına gelmez. Sitemap'e yalnız tercih edilen, canonical ve indekslenebilir URL'lerin eklenmesi gerekir. Büyük sitelerde segmentli sitemap kullanımı indeksleme sorunlarını kategori bazında anlamayı kolaylaştırabilir. Sitemap'i bir URL deposu haline getirmek yerine kontrollü index hedefleri listesi olarak görmek daha sağlıklıdır.

Tarama İstatistikleri

Tarama İstatistikleri Googlebot'un siteyle kurduğu crawl ilişkisine dair toplu göstergeler sunar. Yanıt kodları, dosya türleri ve host durumu gibi bilgiler sunucu kaynaklı problemleri anlamaya yardımcı olabilir. Ani 5xx artışları indeksleme sorunlarının öncüsü olabilir. Ancak bu rapor tekil URL debug aracı değildir. URL pattern analizi gerekiyorsa server log ve crawler verileriyle tamamlamak daha güçlü sonuç verir.

URL Kaldırmaları

URL Kaldırmaları aracı belirli sonuçları Google Search görünümünden geçici olarak kaldırmak için kullanılabilir. Bu işlem URL'nin temel indexability problemini çözmez. Sayfanın kalıcı olarak indeks dışı kalması gerekiyorsa uygun HTTP durumu, noindex veya erişim politikası ayrıca uygulanmalıdır. Yanlışlıkla indekslenen hassas bir sayfada yalnız kaldırma talebine güvenmek doğru değildir. Teknik erişim ve içerik güvenliği ayrıca çözülmelidir.

Sayfa Dizine Ekleme Raporu Nasıl Okunur?

Raporu okurken ilk amaç bütün indekslenmemiş URL'leri sıfırlamak olmamalıdır. Önce kaç URL'nin gerçekten indekslenmesini istediğinizi belirlemelisiniz. Daha sonra indekslenmeyen grupları expected ve unexpected olarak ayırmak gerekir. Trend grafiğinde deployment veya sitemap değişikliğiyle aynı tarihte oluşan hareketler ayrıca incelenmelidir. Tekil örneklerden genel sonuç çıkarmak yerine URL pattern ve template düzeyinde analiz yapmak daha verimlidir.

Dizine Eklenmiş Sayfalar

Dizine eklenmiş sayfalar Google indeksinde bulunan URL'leri temsil eder. Bu sayının yüksek olması tek başına başarı ölçütü değildir. Filtre URL'leri veya gereksiz parametreler indekslenmişse yüksek sayı index bloat göstergesi olabilir. Bu nedenle gerçek hedef URL setiyle karşılaştırma yapılmalıdır. Sağlıklı indeksleme doğru sayfaların indekslenmesiyle ölçülür.

Dizine Eklenmemiş Sayfalar

İndekslenmemiş URL'ler farklı nedenlerle rapora girebilir. Redirect, duplicate veya bilinçli noindex sayfaları normal olarak bu grupta bulunabilir. Kritik landing page aynı listede yer alıyorsa konu farklıdır. URL örneklerini iş değeri ve template'e göre ayırmak gerekir. Bu yaklaşım ekiplerin gereksiz URL'lerle zaman kaybetmesini önler.

Sorun Nedenleri

Search Console neden kategorisi teşhisin başlangıç noktasıdır. Mesaj doğrudan kök nedeni her zaman açıklamaz. Örneğin tarandı fakat indekslenmedi durumunda içerik benzerliği, internal linkler, canonical ve sayfa değeri birlikte incelenmelidir. Robots.txt engeli ise daha doğrudan teknik kontrol sunar. Her kategori için ayrı debug akışı oluşturmak ekip hızını artırır.

Etkilenen URL Örnekleri

Search Console genellikle etkilenen bütün URL'leri değil örnekleri gösterir. Bu nedenle listedeki sayfaları tek tek düzeltmek ölçekli çözüm değildir. Örnek URL'nin ait olduğu pattern'i veya template'i belirlemek gerekir. Aynı problem yüzlerce ürün sayfasında bulunuyorsa çözüm template seviyesinde yapılmalıdır. Sonrasında crawler veya veritabanı ile gerçek kapsam ölçülebilir.

Trend Grafikleri

Trend grafikleri indeks durumundaki değişimin ne zaman başladığını anlamaya yardımcı olur. Deployment tarihleriyle grafik hareketlerini yan yana koymak güçlü ipucu sağlar. Sitemap değişikliği, migration veya robots güncellemesi aynı dönemde yapıldıysa önce bu değişiklikler kontrol edilir. Tek günlük küçük dalgalanmalar her zaman incident anlamına gelmez. Kalıcı ve büyük sapmalar pattern bazlı analiz gerektirir.

Search Console'da Görülen Her “Dizine Eklenmedi” Durumu Hata mıdır?

Hayır, her indekslenmemiş URL hata değildir. Redirect sayfalarının, duplicate URL'lerin ve bilinçli noindex sayfalarının indekslenmemesi çoğu zaman beklenen davranıştır. Asıl problem indekslenmesini beklediğiniz kritik URL'nin yanlış nedenle dışarıda kalmasıdır. Bu nedenle her rapor satırının yanında expected davranış tanımlanmalıdır. İndeksleme yönetiminin amacı raporu sıfırlamak değil, istenen URL setinin doğru biçimde indekslenmesini sağlamaktır.

Beklenen Hariç Tutmalar

Login, sepet veya yönetim sayfalarının indekslenmemesi çoğu projede normaldir. Parametreli kopyalar da canonical politikası gereği indeks dışı kalabilir. Eski redirect URL'ler aynı şekilde yeni hedef lehine elenir. Bu URL'leri hata listesi olarak görmek yanlış öncelik üretir. Monitoring amacıyla takip edilebilir fakat aksiyon gerekmeyebilir.

Beklenmeyen Hariç Tutmalar

Organik trafik hedeflediğiniz kategori veya ürün sayfasının indekslenmemesi beklenmeyen durumdur. Burada discovery, crawling, noindex, canonical ve içerik seçimi sırasıyla kontrol edilmelidir. Tek URL değil aynı template'in diğer sayfaları da incelenmelidir. Eğer geniş bir segment etkileniyorsa problem kod veya veri katmanında olabilir. Aksiyon önceliği sayfanın iş değerine göre belirlenmelidir.

Intentional Exclusion

Intentional exclusion, URL'nin bilinçli olarak indeks dışında tutulduğu durumu ifade eder. noindex, redirect veya canonical stratejisi bunun parçası olabilir. Bu karar dokümante edilirse Search Console raporları daha kolay yorumlanır. SEO ekibi hangi segmentlerin indeks dışı olması gerektiğini önceden bilmelidir. Böylece yeni bir rapor görüldüğünde gereksiz incident açılmaz.

Accidental Exclusion

Accidental exclusion yanlışlıkla uygulanan robots veya canonical davranışından doğabilir. Template seviyesindeki tek kod değişikliği binlerce sayfayı etkileyebilir. Staging noindex ayarının production'a taşınması klasik örnektir. Deployment sonrası smoke test bu hatayı erken yakalayabilir. Kritik template'lerde otomatik indexability testleri bu nedenle çok değerlidir.

İlk Soru: Bu URL'nin Gerçekten İndekslenmesi Gerekiyor mu?

İndeks sorunu üzerinde çalışmaya başlamadan önce URL'nin organik arama için gerçek bir landing page olup olmadığını sormak gerekir. Her crawlable adresin indekslenmesi gerekli değildir. Filtre, parametre, hesap ve utility URL'leri çoğu projede farklı kurallara tabidir. İndekslenmesi beklenen URL setini açıkça tanımlamak ekiplerin gerçek sorunlara odaklanmasını sağlar. Bu model daha sonra index coverage ratio hesaplamasının da temelini oluşturur.

Organik Landing Page

Organik landing page arama yapan kullanıcı için bağımsız değer sunar. Belirli sorgu veya konuya yanıt vermesi beklenir. URL'nin internal link ve sitemap stratejisinde öncelikli olması normaldir. Böyle bir sayfanın indekslenmemesi yüksek öncelikli sorun olabilir. Özellikle gelir veya lead üreten sayfalar öncelikli olarak incelenmelidir.

Kullanıcı İçin Değerli Sayfa

Değerli sayfa yalnız uzun metin içeren sayfa demek değildir. Ürün bilgisi, araç, veri veya belirli ihtiyaca yanıt sunabilir. Kullanıcının doğrudan o URL'ye gelmesi anlamlı olmalıdır. Aynı değeri başka canonical URL zaten sunuyorsa ayrı indeks gerekmeyebilir. Index policy kullanıcı değerini URL mimarisiyle birlikte değerlendirmelidir.

Duplicate veya Utility URL

Duplicate URL aynı içeriğin başka teknik varyasyonu olabilir. Utility URL ise kullanıcı işlemi için gerekli fakat organik landing page olması gerekmeyen sayfadır. Bu iki kategori için indeks dışı kalmak çoğu zaman beklenen davranıştır. Canonical veya noindex stratejisi ihtiyaca göre seçilebilir. Sitemap'e eklenmeleri ise genellikle gerekli değildir.

Filtre ve Parametre URL'leri

Filtre URL'leri çok büyük URL kombinasyonları oluşturabilir. Bazı facet sayfalarının gerçek arama talebi bulunurken diğerleri yalnız kullanıcı arayüzü işlevi görür. Tüm kombinasyonları indekslemek index bloat ve crawl waste sorunlarına yol açabilir. Hangi filtrelerin landing page olacağı önceden belirlenmelidir. Canonical, noindex ve internal link politikası bu karara göre uygulanmalıdır.

Admin ve Kullanıcı Hesabı Sayfaları

Admin ve hesap sayfalarının arama sonuçlarında görünmesi çoğu zaman istenmez. Bu sayfalar erişim kontrolüyle korunmalıdır. Yalnız robots.txt gizlilik mekanizması olarak kullanılmamalıdır. Oturum gerektiren alanlar zaten crawler erişimine kapalı olabilir. Sitemap ve organik navigasyonda bu URL'lere gereksiz keşif sinyali verilmemelidir.

Expected Indexation Model Nasıl Oluşturulur?

Expected Indexation Model, sitenin hangi URL gruplarının indekslenmesini beklediğinizi sayısal ve mantıksal olarak tanımlar. Toplam crawlable URL sayısı ile hedef indeks URL sayısı aynı olmak zorunda değildir. Bilinçli noindex, redirect ve 404 URL'ler ayrı sınıflara ayrılır. Bu model Search Console raporlarının iyi mi kötü mü olduğunu anlamayı kolaylaştırır. Özellikle büyük e-ticaret ve programatik SEO sitelerinde index başarı oranını gerçek hedef set üzerinden ölçmek gerekir.

Toplam Crawlable URL

Crawlable URL, crawler'ın teknik olarak erişebildiği adres sayısını ifade eder. Bu set sitemap sayısından çok daha büyük olabilir. Filtreler ve parametreler crawlable URL hacmini artırabilir. Amaç bütün crawlable URL'leri indekslemek değildir. Önce bu envanteri pattern bazında anlamak gerekir.

Indexlenmesi Beklenen URL

Bu grup organik arama için tercih edilen canonical landing page'lerden oluşur. Kategoriler, ürünler, makaleler veya hizmet sayfaları örnek verilebilir. Sitemap çoğunlukla bu seti temsil etmelidir. KPI hesaplamalarında payda olarak bu sayı kullanılabilir. Böylece intentional exclusions başarı oranını yapay biçimde düşürmez.

Bilinçli Noindex URL

Bilinçli noindex sayfalar ayrıca kayıt altına alınmalıdır. Site içi arama veya düşük değerli filtreler bu grupta olabilir. Bu URL'lerin Search Console'da indekslenmemesi beklenen davranıştır. Sitemap'te yer almamaları gerekir. Template değişikliklerinde noindex politikasının yanlış segmente taşınmadığı kontrol edilmelidir.

Redirect URL

Redirect URL'ler aktif canonical envanterin parçası değildir. Migration ve URL değişikliklerinden sonra eski adresler bu grupta bulunabilir. İç linkler ve sitemap doğrudan final URL'ye güncellenmelidir. Redirect'lerin varlığı geçiş için normaldir. Fakat indeks hedefi olarak sayılmamalıdır.

404/410 URL

Silinen ve yerine anlamlı karşılık bulunmayan URL'ler 404 veya 410 dönebilir. Bu durum otomatik olarak SEO hatası değildir. İç link veya sitemap bu URL'yi göstermeye devam ediyorsa ayrıca düzeltilmelidir. Backlink alan eski URL'lerde uygun alternatif varsa 301 düşünülebilir. Her 404'ü ana sayfaya yönlendirmek doğru yaklaşım değildir.

Index Coverage Ratio Nasıl Hesaplanır?

Index Coverage Ratio, indekslenmesini beklediğiniz URL setinin ne kadarının gerçekten indekslendiğini ölçmek için kullanılabilir. Basit formül, indekslenen hedef URL sayısının indekslenmesi beklenen toplam URL sayısına bölünmesidir. Ancak tek bir site geneli oran çoğu zaman yeterli değildir. Ürün, kategori, blog ve landing page template'leri ayrı ölçülmelidir. Böylece genel ortalamanın altında gizlenen kritik segment problemleri ortaya çıkar.

Indexlenen Hedef URL Sayısı

Bu değer yalnız doğru canonical hedef URL'leri içermelidir. Parametre veya duplicate URL'lerin indekslenmesi başarı olarak sayılmamalıdır. Search Console ve gerektiğinde URL Inspection sampling ile gerçek durum ölçülebilir. Sitemap segmentleri karşılaştırmayı kolaylaştırır. Verinin belirli tarih aralığında takip edilmesi trend analizi sağlar.

Indexlenmesi Beklenen URL Sayısı

Payda, CMS veya URL inventory üzerinden belirlenebilir. Yayında olmayan ve bilinçli noindex URL'ler dışarıda bırakılmalıdır. Bu sayı deployment ve içerik üretimiyle zaman içinde değişir. Dashboard güncel beklenen URL setini kullanmalıdır. Aksi halde coverage oranı yanlış yorumlanabilir.

Kategori Bazında Oran

Kategori sayfaları ürün sayfalarından farklı indeks davranışı gösterebilir. Bu nedenle ayrı oran izlemek daha anlamlıdır. Kritik ticari kategoriler düşük coverage gösteriyorsa P0 veya P1 önceliği verilebilir. Aynı sorunun yalnız belirli alt kategorilerde olup olmadığı incelenmelidir. URL pattern segmentasyonu teşhisi hızlandırır.

Template Bazında Oran

Template bazlı coverage teknik sorunları hızlı bulmanın güçlü yöntemidir. Yeni release sonrasında bütün ürün template'i indeks kaybı yaşıyorsa tek tek URL incelemeye gerek kalmaz. Canonical, robots veya rendering değişikliği ortak kök neden olabilir. Template KPI'ları deployment monitoring ile ilişkilendirilebilir. Böylece SEO regression erken fark edilir.

İndeks Sorunu Teşhisinde 7 Katmanlı Model

İndeksleme sorunlarını rastgele kontrol etmek yerine yedi katmanlı bir teşhis modeli kullanmak zaman kazandırır. Sıra discovery, crawling, HTTP response, rendering, indexability, canonicalization ve index selection şeklinde ilerler. Önceki katman başarısızken sonraki aşamayı tartışmak çoğu zaman gereksizdir. Örneğin Google URL'yi hiç bilmiyorsa içerik kalitesi analizine başlamak erken olur. Bu model Search Console indeksleme hataları ve teknik SEO optimizasyon hizmeti kapsamında ekiplerin ortak debug dilini oluşturabilir.

Katman 1 - Discovery

İlk soru Google'ın URL'yi bilip bilmediğidir. Sitemap, internal link veya dış bağlantı discovery sinyali sağlayabilir. URL Denetleme sonucu Google'ın adres hakkında verisi olmadığını gösterebilir. Bu durumda orphan page ve sitemap durumu incelenir. URL keşfedilmeden crawling ve index selection gerçekleşemez.

Katman 2 - Crawling

URL biliniyorsa ikinci soru Googlebot'un sayfaya erişip erişemediğidir. Robots.txt, DNS ve server availability burada kontrol edilir. Crawl Stats ve log verisi yardımcı olabilir. Discovered not indexed durumu özellikle crawl aşamasına dikkat çekebilir. Çok büyük URL alanlarında crawl demand ve capacity ayrıca değerlendirilir.

Katman 3 - HTTP Response

HTTP status sayfanın temel teknik durumunu açıklar. İndeks hedefi olan URL'nin çoğunlukla 200 dönmesi beklenir. Redirect, 404 veya 5xx başka davranış anlamına gelir. Soft 404 durumunda teknik olarak 200 alınsa bile içerik boş veya hata benzeri olabilir. Bu yüzden status code ile sayfa içeriği birlikte incelenmelidir.

Katman 4 - Rendering

Kaynak HTML ile render sonucu karşılaştırılmalıdır. Ana içerik JavaScript sonrası geliyorsa API veya hydration problemi Google'ın gördüğü sayfayı değiştirebilir. Canonical ve robots etiketlerinin render sonrası değişmesi ayrıca risktir. İç linklerin gerçek anchor elementleri olarak oluşturulması önemlidir. URL Denetleme canlı testi bu katmanda güçlü araçtır.

Katman 5 - Indexability

Sayfada meta robots noindex veya X-Robots-Tag bulunup bulunmadığı kontrol edilir. Robots.txt ise crawl erişimiyle ilgilidir ve noindex ile aynı şey değildir. CMS ayarları template bazında yanlış noindex üretebilir. Authentication veya access restriction da indekslemeyi engelleyebilir. İndekslenmesi beklenen URL için bu katman temiz olmalıdır.

Katman 6 - Canonicalization

HTML canonical, sitemap URL'si, internal links ve redirect hedeflerinin aynı tercih edilen URL'yi desteklemesi gerekir. Google başka canonical seçtiyse sinyal çatışmaları araştırılmalıdır. Trailing slash veya parametre farklılıkları duplicate kümeler oluşturabilir. Site genelinde canonical policy açık olmalıdır. Tek URL düzeltmek yerine pattern bazında normalization yapılmalıdır.

Katman 7 - Index Selection

Teknik olarak erişilebilir ve indexable sayfa yine de indeks için seçilmeyebilir. Duplicate, near-duplicate, soft 404 benzeri yapı veya düşük özgün değer incelenmelidir. İç linklerin sayfanın önemini nasıl gösterdiği değerlendirilmelidir. Programatik sayfalarda template benzerliği özellikle kontrol edilmelidir. Bu aşamada teknik ve içerik analizi birlikte yürütülür.

Discovery Problemleri Nasıl Tespit Edilir?

Discovery problemi, Google'ın URL'den haberdar olmaması veya onu yeterince güçlü biçimde keşfedememesi durumudur. İlk olarak URL'nin sitemap içinde bulunup bulunmadığına bakılır. Daha sonra internal crawl ile sayfanın herhangi bir indekslenebilir sayfadan link alıp almadığı kontrol edilir. URL Denetleme aracı Google'ın adres hakkında bildiği durumu anlamaya yardımcı olur. Orphan page problemi bulunuyorsa yalnız sitemap eklemek yerine site mimarisindeki bağlantı açığı da düzeltilmelidir.

URL Sitemap'te Var mı?

İndekslenmesi beklenen canonical URL sitemap içinde yer almalıdır. Sitemap'te olması discovery için yararlı sinyal sağlayabilir. Ancak yanlış veya non-canonical URL eklemek problemi artırabilir. Dosyada noindex ve redirect adresler bulunmamalıdır. Sitemap kalite audit'i düzenli yapılmalıdır.

URL İç Link Alıyor mu?

İç linkler crawler'ın siteyi doğal biçimde dolaşmasını sağlar. Kritik URL yalnız sitemap'te bulunuyor fakat hiç iç link almıyorsa orphan yapı oluşabilir. Navigation, kategori ve related content bağlantıları değerlendirilebilir. İç link sayısı kadar bağlantının bağlamı ve click depth de önemlidir. Kullanıcının site içinde erişemediği sayfa genellikle mimari sorun işaretidir.

Google URL'yi Biliyor mu?

URL Denetleme aracı Google'ın belirli URL hakkında indeks bilgisi olup olmadığını gösterebilir. Hiç veri yoksa discovery yollarını incelemek gerekir. Yeni sayfalarda kısa gecikme normal olabilir. Büyük URL hacminde her sayfa anında taranmaz. Sitemap ve internal linking birlikte sağlıklı keşif altyapısı oluşturmalıdır.

Orphan Page Olabilir mi?

Orphan page, site içindeki normal crawl yollarından link almayan sayfadır. Sitemap nedeniyle Google yine de URL'yi bilebilir. Fakat site mimarisindeki önem sinyalleri zayıf kalabilir. Analytics, sitemap ve crawler verilerini birleştirmek orphan tespitini kolaylaştırır. Değerli sayfa ise uygun navigasyon veya içerik bağlantısına dahil edilmelidir.

Orphan Page Nedir?

Orphan page, sitenin crawl edilebilir iç link ağı içinde bulunmayan ancak başka kaynaklardan bilinen sayfadır. Böyle URL'ler sitemap, analytics veya backlink verisinde görünebilir. Yalnız sitemap'te bulunması teknik olarak keşif sağlayabilir fakat kullanıcı navigasyonundaki kopukluğu çözmez. Özellikle organik landing page olması beklenen URL'lerde bu durum önemlidir. Crawler ile sitemap ve analytics karşılaştırması yaparak orphan listesi çıkarılabilir.

Sitemap'te Olup İç Link Almayan Sayfalar

Sitemap URL'si crawler envanterinde yoksa orphan adayıdır. Önce crawler'ın erişim ayarlarının doğru olduğundan emin olmak gerekir. JavaScript linkleri görünmüyorsa render crawl gerekebilir. Gerçek orphan URL'ler business value açısından sınıflandırılmalıdır. Kritik olanlar site navigasyonuna uygun biçimde bağlanmalıdır.

Crawler ile Orphan Page Tespiti

Internal crawler sitenin bağlantı graph'ını çıkarabilir. Sitemap URL listesi daha sonra crawl edilmiş URL listesiyle karşılaştırılır. Sitemap'te olup crawl sırasında keşfedilmeyen sayfalar incelenir. Yanlış sitemap URL'leri ayrıca bu süreçte bulunabilir. Sonuç tek tek URL değil template ve kategori kırılımında değerlendirilmelidir.

Analytics ve Sitemap Karşılaştırması

Analytics'te ziyaret alan fakat crawler tarafından bulunmayan sayfalar da orphan adayı olabilir. Kullanıcı bu URL'ye reklam, dış bağlantı veya eski bookmark üzerinden geliyor olabilir. Sitemap listesi üçüncü veri kaynağı olarak eklenebilir. Üç envanter arasındaki farklar URL mimarisi problemlerini gösterebilir. Bu yöntem yalnız Search Console'a bakmaktan daha kapsamlıdır.

Orphan Page Nasıl Düzeltilir?

Sayfa gerçekten indekslenmesi ve kullanıcı tarafından bulunması gereken bir içerikse uygun internal link eklenmelidir. Bağlantı yalnız footer'a rastgele eklenmemelidir. Kategori, breadcrumb veya ilgili içerik bağlamı tercih edilebilir. Sayfa artık değerli değilse sitemap'ten çıkarmak ve URL lifecycle kararını vermek daha doğru olabilir. Her orphan URL'nin çözümü link eklemek değildir.

İç Linkleme İndekslemeyi Nasıl Etkiler?

İç linkleme Google'ın URL discovery sürecini ve sitenin önem hiyerarşisini anlamasına yardımcı olur. Navigation, breadcrumb, related content ve kategori ürün bağlantıları crawl yollarını oluşturur. Kritik sayfaların çok derinde kalması keşif ve yeniden tarama hızını etkileyebilir. Linkler gerçek ve takip edilebilir URL hedeflerine gitmelidir. Site mimarisi kullanıcıların önemli sayfalara birkaç mantıklı adımda erişmesini desteklemelidir.

Navigation Linkleri

Ana navigasyon sitenin en önemli bölümlerine güçlü erişim sağlar. Her URL'yi ana menüye eklemek gerekmez. Öncelikli kategori ve hizmet sayfaları burada mantıklı şekilde temsil edilebilir. Mobil ve masaüstü navigasyonun önemli URL'lerde büyük fark göstermemesi yararlıdır. Menü linkleri gerçek anchor URL olarak render edilmelidir.

Breadcrumb

Breadcrumb hiyerarşik ilişkiyi hem kullanıcıya hem crawler'a açık biçimde gösterir. Ürün veya makalenin üst kategoriye bağlanmasını sağlar. URL'ler canonical hedeflere gitmelidir. Structured data ile görsel breadcrumb aynı mantığı destekleyebilir. Bu yapı click depth yönetiminde de yardımcıdır.

Related Content

İlgili içerik bağlantıları aynı konu kümesindeki sayfaların keşfini destekler. Linkler rastgele değil, gerçek içerik ilişkisine göre seçilmelidir. Eski makaleler yeni içeriklere ve yeni içerikler değerli eski sayfalara bağlanabilir. Programatik recommendation sistemi canonical URL'leri kullanmalıdır. Broken link kontrolü düzenli yapılmalıdır.

Category–Product Linkleri

E-ticarette kategori sayfaları ürün discovery için ana kanallardan biridir. Pagination veya lazy loading hataları bazı ürünlerin crawler tarafından bulunmasını engelleyebilir. Ürün linklerinin yalnız JavaScript event ile oluşturulması risk yaratabilir. Gerçek href hedefleri kullanılmalıdır. Stok durumuna göre link silme politikası da indexation davranışını etkileyebilir.

Click Depth

Click depth bir sayfaya ana sayfadan kaç bağlantı adımıyla ulaşılabildiğini gösterir. Kritik URL'lerin gereksiz yere çok derinde olması mimari zayıflık gösterebilir. Her sayfanın bir tıklamada olması gerekmez. Mantıklı kategori hiyerarşisi çoğu durumda yeterlidir. Depth verisi business value ile birlikte değerlendirilmelidir.

Crawling Problemleri Nasıl Teşhis Edilir?

Crawling problemi teşhisinde Googlebot'un URL'ye gerçekten erişip erişemediği kontrol edilir. Robots.txt, HTTP response, DNS ve network durumu temel katmanlardır. Büyük sitelerde crawl capacity ve URL üretim hacmi ayrıca ele alınmalıdır. Search Console Crawl Stats toplu sinyaller sunarken server log gerçek istekleri görmeye yardımcı olur. Tek bir hata mesajına odaklanmak yerine URL pattern ve zaman aralığı üzerinden analiz yapmak daha sağlıklıdır.

Googlebot URL'ye Ulaşabiliyor mu?

URL Denetleme canlı testi sayfanın şu anda erişilebilir olup olmadığını gösterebilir. Server log geçmiş Googlebot isteklerini doğrulamaya yardımcı olur. Authentication veya WAF kuralları bot erişimini yanlışlıkla engelleyebilir. Mobil Googlebot davranışı ayrıca test edilmelidir. Kullanıcı tarayıcısında çalışan sayfa bot için aynı sonucu vermeyebilir.

Robots.txt

Robots.txt crawler'ın hangi yolları tarayabileceğini yönetir. Yanlış wildcard kuralı büyük URL segmentini engelleyebilir. Deployment sonrası robots dosyasının production ortamında beklenen içerikte olduğu kontrol edilmelidir. Staging disallow kuralının production'a taşınması ciddi incident oluşturabilir. Sitemap tanımı da robots.txt içinde bulunabilir.

Sunucu Yanıtı

Googlebot'un aldığı HTTP durum kodu crawl başarısını doğrudan etkiler. 5xx oranındaki artış sunucu kapasitesi veya uygulama sorununa işaret edebilir. Response time yükselmesi de büyük sitelerde crawl kapasitesini etkileyebilir. CDN ile origin logları birlikte incelenebilir. Sorun yalnız Googlebot'a özgüyse bot doğrulaması ve güvenlik katmanları kontrol edilmelidir.

DNS ve Network Problemleri

DNS hataları crawler'ın host'a ulaşmasını engelleyebilir. SSL veya edge network problemleri de erişimi kesebilir. Search Console host durumundaki değişimler erken uyarı sağlayabilir. DevOps ekibi DNS ve CDN kayıtlarını incelemelidir. Özellikle migration sonrasında eski ve yeni altyapı arasında yanlış yönlendirme bulunabilir.

Crawl Capacity

Crawl capacity sunucunun Googlebot isteklerini güvenli biçimde karşılayabildiği kapasiteyle ilişkilidir. Sürekli 5xx veya yavaş yanıt kapasiteyi olumsuz etkileyebilir. Büyük URL alanlarında gereksiz filtre sayfaları crawler kaynaklarını tüketebilir. Küçük sitelerde crawl budget konusu genellikle ilk öncelik değildir. Önce temel indexability ve içerik sorunlarını çözmek daha değerlidir.

Robots.txt Nedir?

Robots.txt sitenin kök dizininde yer alan ve crawler erişim kurallarını belirten metin dosyasıdır. Dosya crawl kontrolü sağlar, doğrudan bir gizlilik veya erişim güvenliği mekanizması değildir. Disallow ve Allow kuralları URL pattern'lerine göre davranışı şekillendirir. Sitemap konumu da bu dosyada belirtilebilir. Robots kararlarını noindex veya canonical kararlarıyla karıştırmamak indeksleme yönetiminde çok önemlidir.

Robots.txt Ne İşe Yarar?

Robots.txt crawler'a belirli yolları taramaması gerektiğini söyleyebilir. Büyük sitelerde gereksiz crawl alanlarını sınırlandırmak için kullanılabilir. Ancak URL başka kaynaklardan biliniyorsa yalnız robots engeli onun arama sonuçlarında hiç görünmeyeceğini garanti etmez. Gizli içerik erişim kontrolüyle korunmalıdır. İndeksten çıkarma için uygun indexability yöntemi seçilmelidir.

Disallow Nedir?

Disallow belirli URL pattern'lerinin crawler tarafından taranmamasını ister. Pattern yazımı geniş etki oluşturabileceği için dikkatle test edilmelidir. Tek slash hatası önemli site bölümünü kapatabilir. Kurallar deployment öncesinde staging testinden geçmelidir. Production smoke test robots dosyasını ayrıca doğrulamalıdır.

Allow Nedir?

Allow daha geniş bir engelleme kuralı içindeki belirli yolu crawler'a açık bırakmak için kullanılabilir. Özellikle karmaşık path yapılarında yararlı olabilir. Pattern'lerin birlikte nasıl eşleştiği test edilmelidir. Robots policy kod review sürecine dahil edilebilir. Kritik değişikliklerin SEO ve geliştirme ekipleri tarafından ortak incelenmesi faydalıdır.

Sitemap Direktifi

Robots.txt içinde Sitemap satırı sitemap adresini crawler'a bildirebilir. Sitemap yine Search Console üzerinden ayrıca gönderilebilir. Sitemap URL'si erişilebilir ve production host üzerinde olmalıdır. Eski domain veya staging sitemap referansları migration sırasında temizlenmelidir. Sitemap bildirimi kötü URL envanterini düzeltmez.

Robots.txt İndekslemeyi Engeller mi?

Robots.txt'nin temel görevi crawling kontrolüdür, noindex direktifi gibi çalışmaz. Google bazı durumlarda tarayamadığı URL'yi başka sinyaller üzerinden bilebilir. Bu nedenle bir URL'yi kesin biçimde arama sonuçlarından çıkarmak için robots engeli tek başına doğru yöntem olmayabilir. Sayfanın noindex direktifinin görülebilmesi için crawler'ın sayfayı okuyabilmesi gerekir. Bu ayrım noindex canonical robots.txt ve sitemap kaynaklı indeksleme sorunları teşhis edilirken temel kuraldır.

Crawl ile Index Arasındaki Fark

Crawl sayfanın alınması, index ise içeriğin Google sisteminde seçilmesi aşamasıdır. Robots.txt ilk aşamayı etkiler. noindex ikinci aşama için sayfa düzeyinde direktif sunar. Aynı URL'de iki kuralı düşünmeden kullanmak amaçla çelişebilir. Önce URL'nin hedef durumunu tanımlamak gerekir.

Robots.txt'nin Gerçek Rolü

Robots.txt crawler kaynaklarını hangi URL alanlarına harcamaması gerektiğini belirtmek için kullanılabilir. Filtre parametreleri veya teknik endpoint'ler bazı sitelerde bu kapsama girebilir. Ancak kullanıcıya özel veriyi korumaz. Security kontrolü authentication üzerinden yapılmalıdır. İndeks dışı tutma politikası da ayrıca belirlenmelidir.

Bir URL'yi Arama Sonuçlarından Çıkarmanın Doğru Yolları

URL mevcut kalacak fakat indekslenmemesi isteniyorsa noindex uygun seçenek olabilir. İçerik kalıcı olarak kaldırıldıysa 404 veya 410 kullanılabilir. URL başka eşdeğer adrese taşındıysa 301 değerlendirilebilir. Search Console kaldırma aracı geçici görünürlük kontrolü sağlar. Her senaryoda iş amacına uygun teknik yöntem seçilmelidir.

Robots.txt Tarafından Engellendi Sorunu Nasıl Çözülür?

Search Console robots engeli gösterdiğinde ilk soru engellemenin bilinçli olup olmadığıdır. İndekslenmesi istenmeyen teknik URL için durum normal olabilir. Organik landing page yanlışlıkla engellendiyse pattern ve deployment değişikliği incelenmelidir. Sitemap'te engellenmiş URL bulunması ayrıca sinyal çatışması yaratır. Düzeltme sonrasında canlı URL testiyle crawler erişiminin açıldığı doğrulanabilir.

Engelleme Bilinçli mi?

Her robots engeli sorun değildir. Admin, search veya belirli teknik alanlar bilinçli kapatılmış olabilir. Index policy bu kararları dokümante etmelidir. Search Console raporu beklenen davranışla karşılaştırılmalıdır. İstenmeyen engeller yalnız bu ayrımdan sonra aksiyona dönüştürülmelidir.

Pattern Kontrolü

Robots pattern'i tek URL yerine büyük URL kümesini etkileyebilir. Wildcard ve path kuralları örnek URL'lerle test edilmelidir. Yeni route eski disallow pattern'ine yanlışlıkla eşleşebilir. Migration sırasında path yapısı değiştiyse robots kuralları yeniden değerlendirilmelidir. Tek dosya değişikliği büyük index incident oluşturabileceği için review önemlidir.

Önemli URL Yanlışlıkla Engellenmiş mi?

Kritik landing page engelleniyorsa problem yüksek önceliklidir. Aynı template veya klasördeki diğer URL'ler de kontrol edilmelidir. Engeli kaldırmak tekil URL için değil pattern seviyesinde yapılmalıdır. Production sonrası canlı test kullanılmalıdır. Sonraki crawl ve index durumunun Search Console'da güncellenmesi zaman alabilir.

Sitemap Çakışması

Sitemap içinde bulunan URL'nin robots ile engellenmesi iki farklı amaç sinyali oluşturabilir. Sitemap indekslenmesini istediğiniz preferred URL setini taşımaya odaklanmalıdır. Bilinçli crawl-blocked URL'leri dosyadan çıkarmak daha temizdir. Audit sırasında sitemap ve robots pattern'leri karşılaştırılabilir. Bu kontrol otomatik regression testine dönüştürülebilir.

Noindex Nedir?

Noindex, arama motoruna belirli sayfanın indekslenmemesi gerektiğini bildiren direktiftir. HTML meta robots etiketi veya HTTP response üzerinden X-Robots-Tag ile uygulanabilir. CMS sistemleri çoğu zaman bu davranışı ayar veya template üzerinden üretir. JavaScript ile sonradan değiştirmek daha fazla test gerektirir çünkü kaynak ve render çıktısı ayrışabilir. İndekslenmesi gereken URL'de noindex bulunması Search Console'daki en doğrudan teknik sorunlardan biridir.

Meta Robots Noindex

HTML head içindeki meta robots etiketi sayfanın indexability davranışını belirtebilir. Template seviyesinde üretildiğinde binlerce URL'yi etkileyebilir. Production HTML kaynağında gerçekten hangi değer çıktığı kontrol edilmelidir. CMS arayüzündeki ayara tek başına güvenmek yeterli değildir. Canlı URL testi Google'ın direktifi görüp görmediğini anlamaya yardımcı olur.

X-Robots-Tag

X-Robots-Tag HTTP response header üzerinden index direktifi vermeye yarar. PDF ve HTML dışı dosyalarda da kullanılabilir. HTML kaynağında noindex görünmüyorsa response header ayrıca kontrol edilmelidir. CDN veya web server katmanı yanlışlıkla global header ekleyebilir. Bu tür problem template kodundan değil altyapı konfigürasyonundan kaynaklanabilir.

CMS Üzerinden Noindex

CMS sistemlerinde sayfa, kategori veya içerik tipi bazında noindex seçeneği bulunabilir. Yanlış varsayılan ayar yeni içeriklerin tamamını indeks dışı bırakabilir. Migration sırasında eski SEO metadata'sı yeni sisteme hatalı taşınabilir. CMS verisi final HTML çıktısıyla karşılaştırılmalıdır. Acceptance criteria yalnız panel ayarını değil production davranışını tanımlamalıdır.

JavaScript ile Noindex

JavaScript sayfa render edilirken robots meta etiketini değiştirebilir. Bu model debug sürecini daha zor hale getirir. Source HTML ile rendered HTML farklı sonuç verebilir. Kritik indexability kararlarını mümkün olduğunca server response seviyesinde deterministik üretmek daha güvenlidir. Client-side değişiklik kullanılıyorsa URL Denetleme render sonucu düzenli test edilmelidir.

Noindex Etiketi Tarafından Hariç Tutuldu Ne Demektir?

Bu durum Google sayfayı işlerken noindex direktifi gördüğünü ve URL'yi indeks için seçmediğini ifade eder. Sayfanın indekslenmesini istemiyorsanız bu beklenen davranış olabilir. Kritik landing page'de görülüyorsa noindex'in nereden geldiği bulunmalıdır. Meta robots, X-Robots-Tag ve CMS template'i birlikte kontrol edilir. Düzeltmeden sonra canlı URL testi noindex'in kalktığını doğrulamak için kullanılabilir.

Bilinçli Noindex

Bilinçli noindex utility veya düşük değerli sayfalarda normal olabilir. Bu URL'ler sitemap'e eklenmemelidir. Internal link davranışı kullanım amacına göre devam edebilir. Search Console'daki sayı tek başına alarm değildir. Beklenen noindex URL seti dokümante edilmelidir.

Yanlışlıkla Eklenen Noindex

Yanlış noindex kritik URL'nin indeks kaybına neden olabilir. Son deployment veya CMS değişikliği ilk kontrol noktasıdır. Aynı template'teki diğer URL'ler toplu olarak test edilmelidir. Fix sonrasında noindex kaldırılır ve örnek URL'ler doğrulanır. Gerekirse kritik birkaç URL için indeksleme talebi gönderilebilir.

Template Bazlı Noindex Hatası

Template hatası tek bir kod değişikliğiyle geniş URL setini etkiler. Bu nedenle Search Console örneklerini pattern bazında gruplayın. Crawler tüm template'in meta robots değerini ölçebilir. Root cause düzeltildikten sonra staging ve production regression test eklenmelidir. URL'leri tek tek düzenlemek kalıcı çözüm değildir.

HTTP Header Kontrolü

HTML meta doğru görünse bile HTTP header noindex taşıyabilir. Curl veya browser network araçları response header'ı gösterebilir. CDN rule veya server middleware kaynaklı problem olabilir. Mobil ve masaüstü user-agent davranışı farklıysa ayrıca test yapılmalıdır. Final response her zaman gerçek doğrulama kaynağıdır.

Robots.txt ile Noindex Birlikte Kullanılırsa Ne Olur?

Bir URL robots.txt tarafından engellenirken aynı sayfada noindex bulunması hedeflenen sonucu garanti etmeyebilir. Crawler sayfayı alamıyorsa meta noindex direktifini göremeyebilir. Bu nedenle indeks dışı tutmak için noindex kullanacaksanız crawler'ın direktifi okuyabilmesi gerekir. Robots engeli farklı crawl kontrolü amacı taşımalıdır. İki mekanizma ayrı problemlere çözüm sunduğu için bilinçli bir sıra ve politika kullanılmalıdır.

Google Noindex'i Görebiliyor mu?

Google noindex direktifini uygulayabilmek için sayfa içeriğine veya response header'a erişebilmelidir. Robots engeli bunu önleyebilir. Daha önce bilinen URL bazı sinyallerle sistemde kalabilir. Bu yüzden noindex uygulanan URL'yi aynı anda crawl erişimine kapatmak çoğu durumda gereksizdir. Hedef davranış açıkça test edilmelidir.

Crawl Engeli ve Meta Direktif Çakışması

Crawl engeli Google'ın sayfayı almasını durdurur. Meta direktif ise alınan sayfanın indekslenmemesini ister. Aynı URL'de iki farklı katmanı karıştırmak teşhisi zorlaştırır. Index policy hangi URL'lerde hangi yöntemin kullanılacağını tanımlamalıdır. Otomatik audit sitemap, robots ve noindex davranışını birlikte karşılaştırabilir.

Doğru Uygulama Sırası

Önce URL'nin indeks hedefi belirlenmelidir. Sayfa mevcut kalacak fakat indeksten çıkacaksa erişilebilir noindex davranışı uygulanabilir. Tamamen kaldırılan içerik için HTTP status kararı ayrıca verilir. Crawl kaynaklarını yönetmek gerekiyorsa robots policy ikinci ayrı konu olarak ele alınır. Böylece her mekanizma kendi görevini yerine getirir.

HTTP Status Kodları İndekslemeyi Nasıl Etkiler?

HTTP status kodları URL'nin teknik durumunu Googlebot'a en açık biçimde bildirir. 200 içerik sunulduğunu, 3xx yönlendirme bulunduğunu, 4xx kaynağın erişilemediğini ve 5xx sunucu hatasını ifade eder. İndeks hedefi olan canonical sayfalarda kararlı 200 yanıtı beklenir. Hatalı status kodu soft 404 veya redirect sorunları oluşturabilir. Search Console sorunlarını incelerken HTTP kontrolü robots ve canonical analizinden önce yapılmalıdır.

200

HTTP 200 isteğin başarılı işlendiğini gösterir. Ancak bu status tek başına sayfanın indeksleneceğini garanti etmez. Sayfa noindex, duplicate veya düşük değerli olabilir. Soft 404 benzeri içerik de yanlışlıkla 200 dönebilir. Bu nedenle status ile render edilmiş içerik birlikte değerlendirilmelidir.

301 / 308

301 ve 308 kalıcı yönlendirme davranışı için kullanılabilir. Eski URL yeni canonical adrese taşındığında bu model uygundur. Sitemap ve internal linkler doğrudan yeni URL'yi göstermelidir. Uzun redirect chain'lerinden kaçınılmalıdır. Final URL'nin 200 ve indexable olduğu kontrol edilmelidir.

302 / 307

302 ve 307 geçici yönlendirme senaryolarında kullanılabilir. Kalıcı site migration için yanlış kullanım sinyalleri belirsizleştirebilir. İş amacı geçici değilse uygun redirect tipi seçilmelidir. Search Console'da redirect URL'nin indekslenmemesi normal olabilir. Asıl hedef final URL'nin durumudur.

404

404 belirtilen kaynağın bulunmadığını ifade eder. Gerçekten silinen URL için normal davranıştır. Sitemap veya iç link hâlâ 404'e gidiyorsa bu kısımlar düzeltilmelidir. Aynı içeriğin yeni URL'si varsa 301 daha uygun olabilir. Bütün 404 adreslerini ana sayfaya yönlendirmek kullanıcı ve arama motoru açısından anlamlı değildir.

410

410 kaynağın kaldırıldığını daha açık biçimde ifade eder. Kalıcı olarak emekli edilmiş URL'lerde kullanılabilir. Sitemap'ten çıkarılması gerekir. İç linkler temizlenmelidir. Uygun alternatif içerik varsa redirect kararı yine ayrıca değerlendirilir.

401 / 403

401 ve 403 erişim kısıtlamasını ifade eder. İndekslenmesi gereken public sayfalarda bu kodlar problem oluşturur. WAF veya bot güvenlik kuralları Googlebot'u yanlışlıkla engelliyor olabilir. Gerçek Googlebot doğrulaması yapılmalıdır. Kullanıcı hesabı gibi private alanlarda ise erişim kısıtlaması beklenen davranıştır.

5xx

5xx sunucu veya uygulama hatasını gösterir. Sürekli veya geniş kapsamlı 5xx Google'ın crawl davranışını olumsuz etkileyebilir. Log analizi hangi URL pattern'lerinin sorun yaşadığını gösterebilir. DevOps ve uygulama ekipleri response time ve error rate verilerini incelemelidir. Geçici bakımda doğru 503 kullanımı bazı durumlarda daha anlamlıdır.

Bulunamadı (404) Search Console'da Her Zaman Hata mıdır?

Hayır, gerçekten kaldırılmış bir URL'nin 404 dönmesi normaldir. Problem site hâlâ bu URL'ye iç link veriyorsa veya sitemap'e ekliyorsa ortaya çıkar. Backlink alan eski adreslerde kullanıcıyı karşılayacak anlamlı yeni içerik varsa redirect düşünülebilir. URL yanlış yazım veya routing hatası nedeniyle 404 oluyorsa teknik düzeltme gerekir. Search Console'daki 404 listesini iş amacı ve URL geçmişine göre sınıflandırmak en doğru yaklaşımdır.

Gerçekten Silinmiş URL

İçeriğin artık var olmaması ve eşdeğer alternatif bulunmaması durumunda 404 normaldir. URL sitemap'ten çıkarılmalıdır. İç linkler temizlenmelidir. Google zaman içinde adresi yeniden kontrol edebilir. Burada rapordaki satırı sıfırlamak için anlamsız redirect yapmak gerekmez.

Yanlış İç Link

Sitedeki link typo veya eski route nedeniyle 404'e gidiyorsa düzeltilmelidir. Crawler broken internal link listesini çıkarabilir. Link doğrudan geçerli canonical adrese verilmelidir. Redirect'i kalıcı yama olarak kullanmak yerine kaynak bağlantı düzeltilir. Böylece crawl yolu temiz kalır.

Sitemap'te 404

Sitemap'te 404 bulunması kalite problemidir. Sitemap yalnız tercih edilen aktif URL'leri göstermelidir. Silinen içerik publish sisteminden sitemap generator'a doğru biçimde yansıtılmalıdır. Otomatik validation 200 dışı URL'leri yakalayabilir. Böylece eski adresler production sitemap'e geri dönmez.

Backlink Alan 404

Eski URL dış bağlantı alıyorsa uygun yeni içerik bulunup bulunmadığı değerlendirilmelidir. Gerçekten eşdeğer sayfa varsa 301 kullanıcı deneyimi açısından anlamlıdır. İlgisiz ana sayfaya yönlendirme yapılmamalıdır. Backlink varlığı tek başına redirect zorunluluğu oluşturmaz. Kullanıcı niyetini karşılayan hedef aranmalıdır.

301 Gereken Durumlar

İçerik yeni URL'ye taşınmışsa 301 doğru tercih olabilir. Migration mapping bire bir veya en yakın anlamlı eşdeğere yapılmalıdır. Eski URL sitemap'ten çıkarılır. Canonical ve iç linkler yeni URL'ye güncellenir. Redirect chain oluşmaması için doğrudan final hedef kullanılmalıdır.

Soft 404 Nedir?

Soft 404, sunucunun teknik olarak 200 döndürmesine rağmen sayfanın kullanıcı açısından bulunamayan veya anlamlı içeriği olmayan bir sonuç sunmasıdır. Örneğin “Ürün bulunamadı” mesajını 200 ile döndüren boş ürün sayfası buna aday olabilir. Google böyle URL'leri gerçek içerik sayfası gibi indekslemek istemeyebilir. Doğru HTTP status kullanmak ve mevcut sayfalara yeterli içerik sunmak gerekir. Soft 404 sorunu özellikle e-ticaret ve programatik URL üretiminde sık görülür.

200 Dönen Boş Sayfa

Routing sistemi her URL için 200 döndürüyorsa olmayan path'ler de başarılı sayfa gibi görünebilir. Bu durum soft 404 problemine yol açabilir. Uygulama gerçekten bulunmayan kaynak için 404 veya uygun status üretmelidir. Error boundary yalnız görsel mesajla yetinmemelidir. Server response davranışı test edilmelidir.

“Ürün Bulunamadı” Sayfaları

Ürün artık yoksa sayfanın lifecycle politikası devreye girmelidir. Geçici stok yokluğu ile kalıcı kaldırma aynı durum değildir. Kalıcı kaldırmada 404, 410 veya anlamlı redirect seçenekleri değerlendirilir. 200 dönüp yalnız hata mesajı göstermek doğru sinyal değildir. E-ticaret platformu ürün durumunu routing katmanına doğru iletmelidir.

Çok Zayıf Sayfalar

Teknik olarak geçerli fakat neredeyse hiç anlamlı içerik sunmayan sayfalar soft 404 benzeri algılanabilir. Kelime sayısı tek ölçüt değildir. Kullanıcının sorgusunu gerçekten karşılayan benzersiz bilgi önemlidir. Programatik sayfalarda yalnız başlık değiştirip aynı template'i çoğaltmak risklidir. URL üretimi gerçek değer kriterine bağlanmalıdır.

Gerçek HTTP Status Kullanımı

HTTP status sayfanın gerçek durumunu yansıtmalıdır. Bulunmayan içerik için 404 kullanmak crawler'a açık bilgi verir. Taşınan içerik için redirect seçilir. Geçici sunucu problemi için 5xx uygun olabilir. Status kodlarını SEO mesajı üretmek için değil web protokolünün anlamına uygun biçimde kullanmak gerekir.

5xx Sunucu Hataları İndekslemeyi Nasıl Etkiler?

5xx hataları Googlebot'un içeriği güvenilir biçimde alamadığını gösterir. Kısa süreli tekil hata her zaman büyük indeks kaybı yaratmaz fakat sürekli ve geniş kapsamlı sorunlar crawl davranışını etkileyebilir. Search Console Crawl Stats ile server log aynı zaman aralığında incelenmelidir. Error rate, response time ve deployment değişiklikleri birlikte değerlendirilmelidir. Site genelinde 5xx artışı SEO ekibinden önce DevOps ve engineering incident sürecini gerektirebilir.

500

500 genel sunucu tarafı uygulama hatasıdır. Stack trace ve application log root cause için incelenmelidir. Belirli template veya query pattern'i hatayı tetikliyor olabilir. Googlebot ile normal kullanıcı aynı sonucu alıyorsa sorun genel uygulama problemidir. Düzeltme sonrası örnek URL'ler yeniden test edilmelidir.

502

502 çoğunlukla gateway veya upstream servis problemine işaret eder. CDN, load balancer veya reverse proxy logları incelenebilir. API servisi yanıt vermiyorsa render ve crawl başarısız olabilir. Hata zamanları deployment ile karşılaştırılmalıdır. Tekrar eden 502 için altyapı kapasitesi ve timeout ayarları değerlendirilmelidir.

503

503 servis geçici olarak kullanılamadığında anlamlı olabilir. Planlı bakım sırasında doğru kullanım crawler'a durumun geçici olduğunu anlatır. Ancak uzun süre devam eden 503 ciddi erişim problemidir. Retry-After gibi uygun header davranışları altyapı politikası kapsamında değerlendirilebilir. Monitoring süreyi ve URL kapsamını takip etmelidir.

504

504 gateway timeout genellikle upstream yanıtının süresi aştığını gösterir. Yavaş database sorgusu veya API sorunu buna neden olabilir. Googlebot isteklerinde tekrar ediyorsa crawl verimliliğini düşürebilir. Server log response time dağılımı incelenmelidir. Performans iyileştirmesi yalnız kullanıcı deneyimi değil crawl sağlığı için de önemlidir.

Server Log Analizi

Server log Googlebot'un hangi URL'ye ne zaman ve hangi status ile istek gönderdiğini gösterir. 5xx sorunlarında gerçek kapsam buradan ölçülebilir. URL pattern ve bot türü bazında segmentasyon yapılabilir. Ortalama ve yüksek percentile response time değerleri izlenebilir. Log verisi Search Console'daki toplu raporu somutlaştırır.

DevOps Eskalasyonu

5xx problemi geniş kapsamlıysa SEO ticket'ı olarak bekletilmemelidir. Incident severity iş etkisine göre belirlenir. DevOps, backend ve SEO ekipleri aynı zaman çizelgesini paylaşmalıdır. Düzeltmeden sonra server health ve Googlebot erişimi yeniden doğrulanmalıdır. Postmortem sonucunda regression ve monitoring kontrolleri eklenmelidir.

Redirect Hataları Nasıl Tespit Edilir?

Redirect hataları Search Console'da zincir, loop veya geçersiz final hedef nedeniyle görülebilir. İlk adım başlangıç URL'sinden final URL'ye kadar bütün HTTP hop'larını izlemektir. Her iç linkin mümkünse doğrudan canonical final URL'ye gitmesi gerekir. Migration sonrasında eski kural setlerinin üst üste binmesi redirect chain üretebilir. Otomatik crawler redirect graph çıkararak problemli pattern'leri toplu biçimde gösterebilir.

Redirect Chain

Redirect chain bir URL'nin birden fazla ara yönlendirmeden geçerek finale ulaşmasıdır. Örneğin HTTP'den HTTPS'ye, sonra eski slug'dan yeni slug'a iki ayrı adım oluşabilir. Kurallar birleştirilerek doğrudan final URL'ye gidilebilir. Internal links ara adreslere bağlanmamalıdır. Migration mapping düzenli olarak chain kontrolünden geçmelidir.

Redirect Loop

Redirect loop URL'lerin birbirine döngüsel biçimde yönlendirilmesiyle oluşur. Kullanıcı ve crawler final içeriğe ulaşamaz. Slash veya locale normalization kuralları birbirini tetikleyebilir. Middleware sırası bu hataya neden olabilir. Automated integration test bilinen URL pattern'lerinde loop kontrolü yapmalıdır.

Broken Redirect

Redirect hedefi 404 veya 5xx dönerse yönlendirme kullanıcı sorununu çözmez. Final URL sağlık kontrolü yapılmalıdır. Migration spreadsheet'inde typo bulunabilir. Target canonical ve indexable olmalıdır. Crawler redirect final status raporu bu problemi hızlı bulur.

Gereksiz Çoklu Yönlendirme

Eski kurallar yıllar içinde üst üste eklenebilir. Her yeni migration bir önceki adrese bağlanırsa chain büyür. Redirect registry son canonical hedefi saklamalıdır. Yeni kural mümkün olduğunca doğrudan finale gitmelidir. Periyodik redirect cleanup altyapıyı sade tutar.

Final URL Kontrolü

Final URL'nin HTTP 200 vermesi beklenir. Sayfa noindex veya yanlış canonical taşıyorsa redirect amacı tam karşılanmaz. Sitemap ve internal links final URL'yi göstermelidir. Hreflang varsa yeni canonical hedeflere güncellenmelidir. Migration Definition of Done bu kontrolleri içermelidir.

Rendering Problemleri İndekslemeyi Nasıl Etkiler?

Modern JavaScript sitelerde HTTP 200 almak sayfanın Google tarafından doğru içerikle işlendiğini kanıtlamaz. Kaynak HTML boş shell olabilir ve ana içerik client-side API üzerinden gelebilir. API hata verirse kullanıcı tarayıcısında bile gecikmeli veya eksik sonuç oluşabilir. Googlebot render sırasında aynı kaynaklara erişemiyorsa sayfanın değeri yanlış değerlendirilebilir. Source HTML, rendered HTML ve network kaynaklarını birlikte test etmek gerekir.

JavaScript Rendering

JavaScript rendering sayfanın scriptler çalıştıktan sonraki DOM halini oluşturur. Kritik içerik yalnız bu aşamada geliyorsa rendering başarısı önemlidir. Script hatası ana metni tamamen kaldırabilir. Server-side veya static render kritik SEO içeriğinde daha öngörülebilir olabilir. Mimari seçim uygulamanın ihtiyaçlarına göre yapılmalıdır.

Boş HTML

Kaynak HTML yalnız root div içeriyorsa crawler render sonucuna daha fazla bağımlı hale gelir. Bu tek başına otomatik hata değildir. Ancak API veya JavaScript başarısız olduğunda indekslenebilir içerik kalmayabilir. Testlerde JavaScript kapalı source ve rendered output karşılaştırılmalıdır. Kritik metadata server tarafında güvenilir üretilmelidir.

Client-Side Content

Client-side içerik kullanıcı cihazında API çağrısı sonrası üretilebilir. Googlebot'un ilgili endpoint'e erişebilmesi gerekir. Authentication veya CORS benzeri konfigürasyonlar render'ı etkileyebilir. İçerik gecikmeli yükleniyorsa test araçlarında gerçek sonuç kontrol edilmelidir. Ana içerik için yalnız kullanıcı etkileşimine bağlı yükleme kullanılmamalıdır.

API Hatası

Frontend 200 dönerken içerik API'si 500 verebilir. Bu durumda sayfa shell'i başarılı fakat içerik boştur. Monitoring frontend status ile backend content availability'yi birlikte ölçmelidir. Googlebot rendering logları doğrudan erişilemese de URL Inspection ve uygulama logları ipucu sağlar. Fallback içerik veya server rendering mimarisi dayanıklılığı artırabilir.

Googlebot'a Eksik İçerik Sunulması

Googlebot'a farklı ve eksik içerik sunmak çoğu zaman istemsiz render probleminden kaynaklanır. User-agent bazlı optimizasyonlar dikkatle yapılmalıdır. Gerçek Googlebot doğrulanmadan güvenlik kuralı uygulanmamalıdır. Rendered HTML ana içerik ve linkler açısından karşılaştırılmalıdır. Kullanıcı ile crawler deneyiminin temel olarak aynı olması hedeflenmelidir.

URL Denetleme Aracında Canlı URL Testi Nasıl Kullanılır?

URL Denetleme aracında mevcut indeks verisi ile canlı test farklı bilgi sunar. Mevcut durum Google'ın son işlediği sürümü anlatırken canlı test sayfanın şu anda nasıl erişildiğini kontrol eder. Teknik düzeltmeden hemen sonra bu ayrım özellikle önemlidir. HTTP response, indexability ve render edilmiş sayfa incelenebilir. Canlı testin başarılı olması URL'nin hemen indeksleneceği anlamına gelmez.

Current Index Status

Current Index Status Google'ın indeks sistemindeki bilinen durumu gösterir. Son crawl tarihi eski olabilir. Yakın zamanda yaptığınız düzeltme henüz bu bölümde görünmeyebilir. Declared ve Google-selected canonical bilgileri önemli teşhis sinyalleridir. Güncel sayfa davranışı için live test ayrıca çalıştırılmalıdır.

Live Test

Live Test sayfanın mevcut erişilebilirliğini kontrol eder. noindex kaldırıldıysa yeni durum burada görülebilir. Ancak canonical selection gibi bütün indeks kararlarını canlı test yeniden hesaplamaz. Bu yüzden başarılı live test nihai index sonucu değildir. Fix validation için teknik kontrol olarak kullanılmalıdır.

HTTP Response

Live test URL'nin erişilebilir olup olmadığını anlamaya yardımcı olur. Redirect veya access problemi varsa burada görülebilir. Response davranışı gerektiğinde bağımsız HTTP araçlarıyla da doğrulanmalıdır. CDN farklı user-agent'e özel davranıyorsa ayrıca kontrol yapılır. Teknik sonuç tek kaynaktan doğrulanmamalıdır.

Rendered HTML

Rendered HTML Google'ın işlediği sayfa sonucunu anlamaya yardımcı olur. Ana içerik, canonical ve robots meta kontrol edilir. JavaScript üretilen linklerin mevcut olup olmadığı incelenir. Sayfa source ile render sonucu arasında beklenmeyen farklar bulunabilir. Bu farklar JavaScript SEO ticket'ına dönüştürülebilir.

Loaded Resources

Render sırasında yüklenemeyen kaynaklar sayfanın görünümünü veya içeriğini etkileyebilir. Kritik API veya JavaScript dosyasının başarısız olması önemlidir. Her üçüncü taraf resource hatası SEO problemi değildir. Ana içerik için gerekli kaynaklar önceliklendirilmelidir. Network hataları uygulama monitoring ile karşılaştırılabilir.

Canonical URL Nedir?

Canonical URL aynı veya çok benzer içerik sunan URL'ler arasından tercih edilen temsilci adresi ifade eder. Site sahibi canonical etiketiyle tercih bildirebilir fakat Google farklı URL seçebilir. Sitemap, internal links ve redirect davranışının declared canonical ile tutarlı olması seçim sinyalini güçlendirir. Self-canonical tercih edilen sayfanın kendisini canonical göstermesidir. Canonical yanlış yapılandırıldığında indekslenmesi beklenen URL başka adres lehine elenebilir.

Canonicalization Ne Anlama Gelir?

Canonicalization duplicate veya benzer URL kümesinde temsilci URL belirleme sürecidir. Parametreler, slash farkları veya ürün varyasyonları bu kümeleri oluşturabilir. Amaç aynı içeriği gereksiz farklı URL'lerle indeksletmemektir. Site genelinde normalization politikası açık olmalıdır. Sitemap ve internal linkler bu politikayı desteklemelidir.

Self-Canonical

Self-canonical sayfanın canonical etiketinin kendi tercih edilen URL'sini göstermesidir. Organik landing page'lerde yaygın ve anlaşılır modeldir. URL'nin tracking parametresiz temiz sürümü tercih edilebilir. Sitemap aynı adresi içermelidir. Internal navigation da doğrudan bu URL'yi kullanmalıdır.

Duplicate URL

Duplicate URL aynı veya çok benzer içeriğin farklı adresidir. Filtre parametreleri veya print sürümleri örnek olabilir. Her duplicate'ın indekslenmesi gerekmez. Canonical veya başka URL politikasıyla tercih edilen sürüm tanımlanabilir. Duplicate envanteri crawler ile pattern bazında analiz edilmelidir.

Google-Selected Canonical

Google-Selected Canonical Google'ın küme için seçtiği temsilci URL'dir. Bu değer declared canonical ile farklı olabilir. İç linkler, sitemap ve içerik benzerliği gibi sinyaller birlikte değerlendirilmelidir. Farklılık kritik URL'de görülüyorsa canonical conflict matrix hazırlanabilir. Tek etiketi değiştirmek yerine bütün sinyaller tutarlı hale getirilmelidir.

Doğru Canonical Etikete Sahip Alternatif Sayfa Ne Demektir?

Bu durum genellikle URL'nin başka canonical sayfanın alternatifi olarak doğru biçimde tanındığını ifade eder. Eğer bu davranış sizin URL politikanızla uyumluysa sorun değildir. Örneğin tracking parametreli URL temiz canonical sürüme bağlanabilir. Problem yanlış hedef seçilmişse veya indekslenmesini istediğiniz bağımsız sayfa başka URL'ye canonical veriyorsa ortaya çıkar. Bu nedenle Search Console durumunu expected canonical modelinizle karşılaştırmalısınız.

Beklenen Davranış

Duplicate alternatif sayfanın indekslenmemesi çoğu durumda normaldir. Canonical hedef gerçek tercih edilen URL olmalıdır. Sitemap yalnız canonical sürümü listelemelidir. Internal links mümkünse alternate yerine canonical adrese gitmelidir. Böylece Google'a tutarlı sinyaller sunulur.

Ne Zaman Sorun Değildir?

Tracking parametresi, sort URL veya baskı sürümü canonical alternatifi olabilir. Bu URL'lerin ayrı indekslenmesi beklenmez. Search Console raporundaki sayı tek başına alarm değildir. Pattern'in iş amacına uygun olup olmadığı kontrol edilir. Beklenen exclusion olarak dashboard'da izlenebilir.

Yanlış Canonical Hedefi Nasıl Tespit Edilir?

URL Inspection declared ve Google-selected canonical verileriyle başlanabilir. HTML source canonical etiketi ayrıca kontrol edilir. Sitemap, internal links ve redirect target karşılaştırılır. Aynı template'teki örnek URL'ler incelenir. Problem pattern bazlıysa template veya URL builder seviyesinde düzeltilir.

“Kopya, Google Kullanıcıdan Farklı Bir Canonical Seçti” Ne Demektir?

Bu durum site sahibinin belirttiği canonical ile Google'ın seçtiği canonical URL'nin farklı olduğunu gösterir. İçerik benzerliği, internal link hedefleri, sitemap ve URL normalization sinyalleri birbiriyle çelişiyor olabilir. Sorun her zaman canonical tag'in yanlış olması değildir. Site farklı yerlerde başka URL'yi daha güçlü tercih ediyor olabilir. Canonical conflict matrix bu sinyalleri tek tabloda incelemeyi kolaylaştırır.

Declared Canonical

Declared Canonical site tarafından belirtilen tercih edilen URL'dir. HTML link etiketi en yaygın uygulamadır. Header üzerinden canonical kullanılan özel senaryolar da olabilir. Bu değer final ve indekslenebilir URL'ye gitmelidir. Redirect veya hata sayfası canonical hedef olmamalıdır.

Google-Selected Canonical

Google site sahibinin tercihini dikkate alır fakat kendi canonical seçimini yapabilir. Farklı URL seçimi sinyal tutarsızlığına işaret edebilir. Aynı içerik birden çok host veya path altında bulunuyor olabilir. Internal links seçilen diğer URL'ye yoğunlaşıyor olabilir. Sorun URL kümesi olarak analiz edilmelidir.

Neden Farklı Olabilir?

Farkın tek sebebi yoktur. İçerik benzerliği, internal links, sitemap ve redirect davranışı birlikte rol oynayabilir. URL'nin farklı trailing slash sürümleri de karışıklık oluşturabilir. Hedef URL'nin daha kararlı ve yaygın kullanılan sürüm olduğu görülebilir. Bütün canonical sinyalleri aynı preferred URL üzerinde birleştirilmelidir.

İçerik benzerliği

İki URL neredeyse aynı içerik taşıyorsa Google bunları duplicate kümesinde değerlendirebilir. Sayfaların gerçekten bağımsız olması bekleniyorsa içerik amacının farklı olması gerekir. Yalnız title değişikliği yeterli olmayabilir. Programatik sayfalarda bu sorun sık görülür. İçerik stratejisi URL üretim modeliyle birlikte gözden geçirilmelidir.

İç linkler

Canonical A'yı gösterirken sitenin bütün linkleri B'ye gidiyorsa sinyaller ayrışır. Internal links doğrudan tercih edilen URL'ye yönelmelidir. Navigation, breadcrumb ve related content ayrı ayrı kontrol edilir. Template link builder ortak canonical fonksiyonunu kullanabilir. Redirect üzerinden link vermek gereksizdir.

Sitemap

Sitemap tercih edilen canonical URL'yi listelemelidir. Duplicate alternatiflerin dosyada bulunması gereksiz sinyal üretir. Sitemap generator canonical policy ile aynı veri kaynağını kullanmalıdır. Migration sonrasında eski URL'ler temizlenmelidir. Sitemap quality audit bunu düzenli doğrulayabilir.

Redirect

Canonical bir URL'yi tercih ederken aynı URL başka adrese redirect oluyorsa açık çatışma vardır. Canonical target doğrudan 200 URL olmalıdır. Redirect mapping ve canonical builder birlikte güncellenmelidir. Crawler bu uyuşmazlığı otomatik bulabilir. Final target tek tercih olarak desteklenmelidir.

URL tutarsızlığı

HTTP ve HTTPS, www ve non-www veya slash farkları duplicate URL seti oluşturabilir. Tek normalization policy belirlenmelidir. Redirect, canonical, sitemap ve links aynı formatı kullanmalıdır. Uygulamanın farklı servisleri farklı URL üretmemelidir. Merkezi URL builder bu sorunu azaltır.

Canonical Conflict Matrix Nasıl Hazırlanır?

Canonical Conflict Matrix bir URL için bütün tercih sinyallerini yan yana getirir. HTML canonical, HTTP canonical, sitemap URL'si, internal link target, redirect target ve Google-selected canonical ayrı sütunlarda tutulabilir. Amaç hangi katmanın başka URL'yi desteklediğini açık biçimde görmektir. Büyük sitelerde bu çalışma crawler ve Search Console örnekleriyle otomatikleştirilebilir. Aynı pattern'de tekrar eden farklar template seviyesinde çözülmelidir.

HTML Canonical

HTML canonical sayfa source veya rendered HTML'den alınabilir. Client-side değişiyorsa iki sürüm ayrıca kaydedilebilir. Hedef absolute URL olmalıdır. Non-200 target hata olarak işaretlenebilir. Duplicate canonical tag durumları ayrıca raporlanmalıdır.

HTTP Canonical

Bazı dosya türleri canonical bilgisini HTTP Link header üzerinden taşıyabilir. HTML sayfalarda gereksiz çift kaynak kullanımı çatışma oluşturabilir. Header ve HTML farklı hedef veriyorsa issue açılmalıdır. CDN veya server config bu değeri ekliyor olabilir. Source of truth belirlenmelidir.

Sitemap URL

URL sitemap içindeyse preferred sürüm olması beklenir. Duplicate URL'nin sitemap'e girmesi kalite oranını düşürür. Matrix bu uyumsuzluğu görünür kılar. Sitemap segmenti ayrıca kaydedilebilir. Böylece hangi generator'ın problem ürettiği bulunabilir.

Internal Link Target

Internal link hedefleri crawler graph üzerinden sayılabilir. Site canonical A derken linklerin çoğu B'ye gidiyorsa tutarsızlık vardır. Template düzeyindeki link builder incelenmelidir. Anchor kaynakları kategori veya navigation bazında ayrılabilir. Fix sonrası crawl ile değişiklik doğrulanır.

Redirect Target

URL redirect oluyorsa final hedef matrix'e eklenmelidir. Canonical target ile final redirect aynı URL olmalıdır. Chain varsa bütün hop'lar ayrıca incelenebilir. Redirect kuralı eski migration'dan kalmış olabilir. URL normalization politikası sadeleştirilmelidir.

Google-Selected Canonical

Search Console URL Inspection örnekleri Google'ın gerçek seçimini gösterir. Bütün site için tek tek veri almak yerine sampling kullanılabilir. Template bazında temsili URL'ler seçilir. Fark oranı KPI olarak izlenebilir. Yüksek mismatch oranı sistemik canonical sorununa işaret eder.

Keşfedildi - Şu Anda Dizine Eklenmiş Değil Ne Demektir?

Bu durum Google'ın URL'yi bildiğini fakat henüz taramadığını gösterir. Tek yeni URL'de kısa süre görülmesi normal olabilir. Binlerce önemli URL'nin aynı durumda birikmesi discovery kalitesi, crawl demand, URL explosion veya server capacity konularını incelemeyi gerektirir. Sitemap ve internal links ilk kontrol noktalarıdır. Faceted navigation gibi gereksiz URL üretimi gerçek önemli sayfaların crawl önceliğini etkileyebilir.

URL Keşfedilmiş Ancak Henüz Taranmamış

URL Google'ın sisteminde bilinir ancak crawl tarihi oluşmamış olabilir. Bu durum sayfanın noindex olduğunu kanıtlamaz çünkü sayfa henüz alınmamıştır. Yeni yayınlarda zaman tanımak gerekebilir. Büyük ölçekte kalıcıysa URL pattern analizi yapılmalıdır. Server log Googlebot'un gerçekten istek gönderip göndermediğini doğrulayabilir.

Tekil URL mi Toplu Problem mi?

Tek bir URL ile binlerce URL aynı şekilde önceliklendirilmemelidir. Search Console örnekleri template ve sitemap segmentine göre gruplanmalıdır. Toplu problem varsa root cause site mimarisi veya URL üretiminde olabilir. Tekil kritik URL için iç link ve sitemap sinyali kontrol edilir. Ölçek karar modelini değiştirir.

İç Linkleri Kontrol Etmek

Keşfedilen URL güçlü internal links almıyorsa site mimarisinde düşük öncelikli olabilir. Click depth ve inlink sayıları crawler ile ölçülebilir. Kritik sayfa uygun kategori veya navigation yapısına bağlanmalıdır. Sitemap tek discovery sinyali olarak bırakılmamalıdır. Orphan URL'ler ayrı raporlanmalıdır.

Sitemap'i Kontrol Etmek

URL'nin canonical sürümü sitemap içinde bulunmalıdır. lastmod gerçek güncellemeyi yansıtmalıdır. Redirect veya noindex URL'lerle dolu sitemap kaliteyi düşürür. Segment bazlı dosyalar problemi daha rahat ölçmeye yardımcı olur. Sitemap gönderimi crawl garantisi vermez.

URL Explosion Kontrolü

Filtre, takvim veya parametre sistemleri milyonlarca URL üretebilir. Google'ın keşfettiği URL alanı gerçek değerli sayfalardan çok daha büyük hale gelebilir. Internal link ve crawler verisi pattern'leri ortaya çıkarır. Gereksiz kombinasyonlar URL policy ile sınırlandırılmalıdır. Crawl kontrolü yalnız robots üzerinden değil üretim ve linkleme seviyesinde düşünülmelidir.

Sunucu Kapasitesini Kontrol Etmek

Yavaş veya sık hata veren sunucu crawl davranışını etkileyebilir. Crawl Stats ve server response time birlikte incelenmelidir. Googlebot isteklerinde 5xx artışı varsa önce altyapı düzeltilir. CDN cache ve backend kapasitesi değerlendirilebilir. Sağlıklı server tek başına indeks garantisi vermez fakat crawl için temel koşuldur.

Tarandı - Şu Anda Dizine Eklenmiş Değil Ne Demektir?

Bu durum Google'ın sayfayı taradığını fakat şu anda indeks için seçmediğini ifade eder. Yeniden indeksleme talebini sürekli göndermek kök nedeni çözmez. Sayfanın thin, duplicate, near-duplicate veya soft 404 benzeri olup olmadığı incelenmelidir. Canonical ve internal value sinyalleri de kontrol edilmelidir. tarandı şu anda dizine eklenmiş değil hatası nasıl çözülür sorusunun cevabı çoğu zaman teknik ve içerik analizini birlikte gerektirir.

Google Sayfayı Taradı mı?

Bu statüde temel olarak sayfanın tarandığını biliyoruz. Son crawl tarihi Search Console'dan incelenebilir. Düzeltme son crawl'dan sonra yapıldıysa mevcut indeks verisi eski olabilir. Live test şimdiki teknik durumu kontrol eder. Bir sonraki crawl sonrası değerlendirme değişebilir.

İçerik İndeks İçin Seçilmedi mi?

Google taradığı her URL'yi indekslemek zorunda değildir. Duplicate veya çok benzer içerik başka canonical altında değerlendirilebilir. Sayfa kullanıcı için yeterli bağımsız değer sunmuyor olabilir. Programatik template'lerde geniş indeks dışı gruplar görülebilir. İçeriğin arama niyetini gerçekten karşılayıp karşılamadığı incelenmelidir.

Durum Neden Her Zaman Teknik Hata Değildir?

HTTP 200, indexable ve doğru canonical olan sayfa yine de seçilmeyebilir. İndeksleme bir kalite ve seçim aşaması da içerir. Bu nedenle yalnız kod hatası aramak eksik kalabilir. Site içindeki benzer URL kümeleri incelenmelidir. Kullanıcıya sunulan benzersiz değer ve içerik amacı değerlendirilmelidir.

“Tarandı - Dizine Eklenmedi” Sorunu Nasıl Analiz Edilir?

Analiz thin content, duplicate content, near-duplicate template, soft 404 benzeri sayfa, site içi değer sinyalleri ve canonical çakışması üzerinden yürütülebilir. İlk olarak URL'nin teknik olarak indexable olduğu doğrulanır. Daha sonra aynı template'in indekslenme oranı ölçülür. İndeksli ve indeks dışı örnekler karşılaştırılarak hangi özelliklerin farklı olduğu aranır. Bu cohort yaklaşımı tek bir URL üzerinde tahmin yürütmekten daha güçlüdür.

Thin Content

Thin content yalnız kelime sayısının düşük olması değildir. Sayfanın kullanıcıya benzersiz ve yeterli bilgi sunmaması daha önemli ölçüttür. İki yüz kelimelik güçlü araç sayfası değerli olabilir. Bin kelimelik tekrar içerik ise zayıf olabilir. Bu nedenle kalite analizi sorgu niyeti üzerinden yapılmalıdır.

Duplicate Content

Duplicate içerik aynı veya çok benzer sayfaların farklı URL'lerde bulunmasıdır. Canonical policy doğru çalışmıyorsa Google başka URL seçebilir. Parametreler ve ürün varyasyonları sık kaynaklardır. Content similarity analizi template bazında yapılabilir. Gereksiz duplicate URL üretimi azaltılmalıdır.

Near-Duplicate Template

Programatik sayfalarda yalnız şehir veya ürün adı değişip geri kalan içerik aynı kalabilir. Bu yapı büyük near-duplicate küme oluşturur. Her URL gerçek arama ihtiyacına ve benzersiz bilgiye sahip olmalıdır. Template içeriği veriyle anlamlı şekilde farklılaşmalıdır. Yalnız URL sayısını büyütmek indeksleme başarısı sağlamaz.

Soft 404 Benzeri Sayfa

Sayfa 200 dönebilir fakat gerçek içerik sunmayabilir. Boş kategori veya sonuçsuz ürün sayfası buna örnektir. Render edilmiş görünüm kontrol edilmelidir. Kullanıcıya gerçek alternatif veya bilgi sunuluyorsa sayfanın amacı netleşir. Kalıcı boş içerikte doğru HTTP lifecycle kararı verilmelidir.

Site İçindeki Değer Sinyalleri

Kritik URL hiç internal link almıyorsa site mimarisi onu önemsiz gösteriyor olabilir. Sitemap ve navigation davranışı birlikte incelenmelidir. Click depth ve inlink sayıları destekleyici sinyaldir. Bu metrikler tek başına indeks kararını açıklamaz. Ancak indeksli ve indeks dışı cohort farklarını anlamaya yardımcı olabilir.

Canonical Çakışması

Declared canonical başka URL'yi gösteriyorsa indeks dışı kalmak normal olabilir. Google farklı canonical seçmişse conflict matrix hazırlanmalıdır. Sitemap ve internal links aynı preferred URL'yi desteklemelidir. Parametre veya slash normalization sorunları temizlenmelidir. Fix site genelindeki pattern'e uygulanmalıdır.

İçerik Kalitesi ile İndekslenme Arasındaki İlişki

İndeksleme yalnız teknik olarak açık URL sayısıyla ilgili değildir. Google'ın taradığı içerikler arasında hangi URL'lerin arama sonuçlarında anlamlı temsil sunduğu önem taşır. Benzersiz içerik, search intent karşılığı ve kullanıcı değeri bu yüzden analiz edilmelidir. Tekrarlanan template ve programatik sayfa üretimi büyük URL setlerinde özellikle risklidir. Teknik SEO ile içerik stratejisi bu noktada aynı problem üzerinde çalışır.

Benzersiz İçerik

Benzersiz içerik yalnız farklı kelime dizimi anlamına gelmez. Sayfanın başka URL'de bulunmayan bilgi veya fayda sunması gerekir. Ürün detayları, özgün veri veya gerçek uzmanlık katkı sağlayabilir. Template alanları birbirinden anlamlı şekilde ayrılmalıdır. Duplicate detector destekleyici araç olarak kullanılabilir.

Search Intent

Sayfa belirli arama niyetini karşılamalıdır. Kullanıcı bilgi, ürün, kategori veya işlem arıyor olabilir. URL'nin amacı belirsizse içerik diğer sayfalarla yarışabilir. Keyword cannibalization ve duplicate intent birlikte incelenebilir. Her landing page'in net görevi olmalıdır.

Kullanıcı Değeri

Kullanıcı değeri içerik uzunluğundan daha geniş kavramdır. Hesaplama aracı, karşılaştırma, ürün verisi veya net rehber değer sağlayabilir. Sayfa ziyaret edildiğinde bağımsız fayda sunmalıdır. Sırf arama motoru için üretilmiş boş kombinasyonlar uzun vadeli değer taşımaz. URL üretim kriteri bu nedenle işlevsel olmalıdır.

Tekrarlanan Template İçerikleri

Header ve footer tekrarları normaldir. Sorun ana içerik alanının URL'ler arasında çok az değişmesidir. Programatik template'lerde unique data block oranı ölçülebilir. Aynı metnin binlerce sayfada kullanılması kullanıcı değerini düşürebilir. Template tasarımında her sayfanın gerçek farklılığını öne çıkarmak gerekir.

Programatik Oluşturulan Sayfalar

Programatik SEO otomatik olarak kötü değildir. Gerçek arama talebi ve benzersiz veri bulunan sayfalar faydalı olabilir. Ancak sınırsız kombinasyon üretimi index bloat ve düşük coverage yaratabilir. Yayın gate'i kalite kriterlerine bağlanmalıdır. Cohort analysis hangi template'lerin gerçekten indekslendiğini göstermelidir.

Site Haritası (XML Sitemap) İndekslemede Ne İşe Yarar?

XML sitemap Google'ın tercih ettiğiniz URL'leri keşfetmesine yardımcı olan yapılandırılmış listedir. Sitemap indeksleme garantisi vermez. Dosyada yalnız 200 dönen, indekslenebilir ve canonical URL'lerin bulunması güçlü bir kalite kuralıdır. lastmod gerçek anlamlı değişiklikleri ifade etmelidir. Büyük sitelerde sitemap index ve segmentasyon Search Console teşhisini önemli ölçüde kolaylaştırabilir.

URL Discovery

Sitemap yeni veya derin URL'lerin keşfine yardımcı olabilir. Ancak internal link mimarisinin yerine geçmez. Orphan page yalnız sitemap sayesinde bulunuyor olabilir. Kritik landing page'ler normal site navigasyonunda da erişilebilir olmalıdır. Discovery kaynakları birbirini desteklemelidir.

lastmod

lastmod sayfanın son anlamlı güncellenme zamanını ifade etmelidir. Her generator çalışmasında bütün tarihleri bugüne çekmek faydalı değildir. CMS revision verisi kullanılabilir. Template deploy'u her zaman içerik değişikliği sayılmamalıdır. Güvenilir lastmod crawler'a daha kaliteli metadata sunar.

Sitemap Index

Sitemap index birden fazla child sitemap dosyasını gruplar. Büyük sitelerde ürün, kategori veya dil bazlı segmentler oluşturulabilir. Bu yapı Search Console'da hangi URL grubunun sorun yaşadığını görmeyi kolaylaştırır. Child sitemap health ayrıca izlenmelidir. Index dosyası stale referans taşımamalıdır.

Search Console'a Sitemap Gönderme

Sitemap Search Console Sitemaps bölümünden gönderilebilir. Gönderim Google'a dosyayı izlemesi için açık giriş noktası sağlar. Ancak URL'lerin taranma veya indekslenme zamanını garanti etmez. Dosya güncellendiğinde aynı kalıcı URL üzerinden sunulabilir. Sitemap durumundaki hatalar düzenli kontrol edilmelidir.

Sitemap'te Hangi URL'ler Bulunmalıdır?

Sitemap site sahibinin arama sonuçlarında tercih ettiği URL setini temsil etmelidir. Bu yüzden URL'lerin HTTP 200, indexable ve canonical olması güçlü temel kuraldır. Parametreli duplicate veya redirect adresleri dosyada tutmak gerekmez. Sitemap kalite oranı otomatik olarak ölçülebilir. Böyle bir dosya Search Console indexation segmentlerinin de daha anlamlı olmasını sağlar.

200 Status

Aktif sitemap URL'lerinin 200 dönmesi beklenir. 3xx veya 4xx adresler generator hatasına işaret edebilir. Büyük sitemap'lerde sampling veya batch status kontrolü yapılabilir. Farklı hostlar varsa her biri ayrıca izlenmelidir. Production health kontrolü release gate'e eklenebilir.

Indexlenebilir

noindex URL sitemap içinde bulunmamalıdır. Authentication gerektiren sayfalar da organik sitemap hedefi değildir. Robots ve indexability politikası generator'a veri sağlamalıdır. Crawler ile dosya düzenli karşılaştırılabilir. Böylece accidental exclusions erken bulunur.

Canonical

Sitemap'teki URL preferred canonical sürüm olmalıdır. Tracking parametresi veya alternate host kullanılmamalıdır. HTML canonical ile sitemap URL'si karşılaştırılabilir. Mismatch rate dashboard KPI'sı yapılabilir. Migration sonrası eski canonical adresler dosyadan çıkarılmalıdır.

Tercih Edilen URL

Tercih edilen URL internal link ve redirect politikasıyla uyumlu olmalıdır. Tek bir source of truth URL builder kullanmak tutarlılığı artırır. Slash veya host farkı sistemler arasında değişmemelidir. Search Console Google-selected canonical ile örneklem karşılaştırması yapılabilir. Sitemap yalnız bu tercih setini göstermelidir.

Sitemap'te Hangi URL'ler Bulunmamalıdır?

Noindex, redirect, 404, canonical olmayan duplicate ve utility parametre URL'leri normal organik sitemap'te yer almamalıdır. Bu URL'lerin dosyada bulunması Search Console raporlarında gereksiz gönderim sayısını artırır. Sitemap generator URL lifecycle ve index policy bilgisini kullanmalıdır. Büyük sitelerde düzenli Sitemap Quality Audit yapılması yararlıdır. Kalite yüksek olduğunda submitted but not indexed analizi çok daha anlamlı hale gelir.

Noindex URL

Noindex URL arama indeksinde bulunmaması istenen sayfadır. Sitemap ise tercih edilen indeks hedeflerini bildirir. İki sinyali aynı URL'de kullanmak gereksizdir. Generator noindex durumunu filtrelemelidir. Bu kontrol CI testine eklenebilir.

Redirect URL

Redirect URL aktif içerik değildir. Sitemap doğrudan final canonical hedefi göstermelidir. Migration sırasında eski URL'ler yeni dosyadan çıkarılır. Redirect kuralları geçmiş adreslerin geçişini yönetmeye devam eder. Internal links de doğrudan final URL'ye güncellenmelidir.

404 URL

404 sitemap kalitesini düşüren açık problemdir. İçerik silindiğinde generator envanteri güncellenmelidir. URL yanlışlıkla silindiyse routing problemi düzeltilir. Her iki durumda da sitemap gerçek production durumunu yansıtmalıdır. Automated status checker bu sorunu yakalayabilir.

Canonical Olmayan Duplicate URL

Duplicate alternatif sitemap içinde bulunmamalıdır. Preferred canonical adres listelenir. Parametre veya farklı slash sürümü dosyadan çıkarılır. Canonical conflict audit bunu doğrulayabilir. URL builder merkezi hale getirilirse problem azalır.

Parametreli Utility URL

Sort, session veya tracking parametreleri çoğu zaman ayrı organik landing page değildir. Bunları sitemap'e koymak URL envanterini gereksiz büyütür. Arama talebi taşıyan facet'ler ayrı politika kapsamında değerlendirilebilir. Utility ile landing page ayrımı açık tanımlanmalıdır. Generator bu sınıflandırmaya göre filtreleme yapmalıdır.

URL Denetleme Aracı Ne İçin Kullanılır?

URL Denetleme aracı tek bir URL'nin Google indeksindeki durumunu teşhis etmek için kullanılır. Current Google Index Data ve Live URL Test birbirinden farklı bilgiler sunar. Canonical, indexability ve crawl bilgileri incelenebilir. Düzeltme sonrası kritik birkaç URL için indexing request kullanılabilir. Aracı binlerce URL'yi manuel yönetmek için kullanmak yerine pattern teşhisi için örnekleme aracı olarak görmek daha verimlidir.

Tekil URL Teşhisi

Toplu raporda görülen sorundan örnek URL seçilir. URL Inspection ayrıntılı mevcut index durumunu gösterir. Aynı template'ten birkaç farklı örnek karşılaştırılmalıdır. Böylece tekil anomali ile sistemik problem ayrılır. Sonuç teknik ticket'a kanıt olarak eklenebilir.

Current Google Index Data

Bu veri Google'ın son bilinen işlenmiş sürümüne dayanır. Yakın zamanda fix yaptıysanız eski durumu gösteriyor olabilir. Last crawl zamanı bu nedenle önemlidir. Declared ve selected canonical kontrol edilir. Mevcut production davranışı için canlı test ayrıca çalıştırılır.

Live URL Test

Live test sayfanın şu anda crawler tarafından erişilip erişilemediğini kontrol eder. robots ve noindex düzeltmelerinde yararlıdır. JavaScript render sonucu incelenebilir. Ancak test bütün index selection sürecini tekrar gerçekleştirmez. Başarılı sonuç indeks garantisi değildir.

Canonical Kontrolü

Current index ekranı Google-selected canonical bilgisini gösterebilir. Site tarafından declared canonical ayrıca görülür. İki değer farklıysa sinyal audit'i yapılmalıdır. Sitemap ve internal links kontrol edilir. Canonical sorunu pattern bazında çözülmelidir.

Indexing Request

Yeni veya önemli ölçüde düzeltilmiş birkaç URL için indeksleme talebi gönderilebilir. Bu işlem crawl isteğidir, indeks garantisi değildir. Aynı URL'yi tekrar tekrar göndermek kök nedeni çözmez. Büyük URL grupları sitemap ve site mimarisi üzerinden yönetilmelidir. Request işlemi normal yayın pipeline'ının yerine geçmemelidir.

“Dizine Eklemeyi İste” Ne Zaman Kullanılmalıdır?

İndeksleme isteği yeni önemli sayfa, büyük içerik güncellemesi veya teknik sorun düzeltmesi sonrasında birkaç kritik URL için kullanılabilir. Bu özellik URL'yi Google'ın yeniden tarama sürecine aday eder. Binlerce URL'nin elle gönderimi için tasarlanmış bir yayın sistemi değildir. Kök neden devam ederken istek göndermek kalıcı sonuç üretmez. Büyük ölçekli discovery ve refresh sitemap, internal links ve crawlable architecture ile yönetilmelidir.

Yeni Önemli Sayfa

Yeni kritik landing page yayınlandığında istek kullanılabilir. URL sitemap'te ve internal navigation'da doğru şekilde bulunmalıdır. Sayfa canonical ve indexable olmalıdır. İstek bu temel koşulların yerine geçmez. Sonraki günlerde gerçek index durumu takip edilir.

Büyük İçerik Güncellemesi

Sayfa önemli ölçüde yenilendiyse recrawl talebi yararlı olabilir. lastmod da gerçek güncellemeyi yansıtabilir. İç linkler aynı URL'yi desteklemeye devam etmelidir. Canonical değiştiyse migration etkileri ayrıca kontrol edilir. Talep sonrasında indeksleme garantisi beklenmemelidir.

Teknik Sorun Düzeltmesi

Yanlış noindex veya robots problemi düzeltildikten sonra canlı test yapılmalıdır. Teknik sonuç doğruysa birkaç kritik URL için request gönderilebilir. Template'teki bütün URL'leri manuel göndermek gerekmez. Search Console validation süreci toplu sorunu izleyebilir. Sitemap ve crawler kontrolleri bütün kapsamı doğrulamalıdır.

Birkaç Kritik URL

Manuel request sınırlı ve önemli URL'lerde anlamlıdır. Gelir üreten kategori veya ana landing page örnek olabilir. Öncelik iş değerine göre verilmelidir. Her düşük değerli URL için aynı işlem yapılmamalıdır. Sistemik problemde engineer fix'i önceliklidir.

Dizine Eklemeyi İste Ne Zaman Kullanılmamalıdır?

Binlerce URL için manuel request göndermek sürdürülebilir bir indeksleme stratejisi değildir. Kök neden çözülmeden aynı adresi tekrar göndermek de sonuç üretmez. Sitemap yerine bu özelliği kullanmak doğru değildir. Search Console yönetiminin amacı manuel buton operasyonu değil sistemik indexability sağlığıdır. Eğer ekip sürekli aynı URL'ler için request gönderiyorsa yayın mimarisinde başka bir sorun aranmalıdır.

Binlerce URL İçin Manuel Gönderim

Büyük envanter sitemap ve internal links üzerinden keşfedilmelidir. Manuel request operasyonel olarak ölçeklenmez. Her URL'nin indekslenmesi zaten garanti değildir. Template sorunları tek seferde düzeltilmelidir. Automation buton kullanımını taklit etmek yerine URL kalitesini geliştirmelidir.

Kök Neden Düzeltilmeden

Sayfa noindex taşıyorsa request problemi çözmez. Canonical başka URL'yi gösteriyorsa aynı durum geçerlidir. 5xx veya soft 404 da önce düzeltilmelidir. Live test teknik fix'i doğrulamalıdır. Sonra gerektiğinde request kullanılabilir.

Aynı URL'yi Sürekli Tekrar Göndermek

Tekrarlı request indeks seçimini zorlayamaz. Crawled not indexed durumda içerik veya duplicate problemi devam edebilir. Bu nedenle statü değişmiyorsa debug modeline dönülmelidir. Search Console mesajı root cause analiziyle desteklenmelidir. Manuel tekrar yalnız zaman kaybettirir.

Sitemap Yerine Kullanmak

Sitemap büyük URL gruplarının keşif mekanizmasıdır. Index request birkaç tekil URL için yardımcı araçtır. İki sistemin görevleri farklıdır. Site yeni içerik yayınladığında sitemap otomatik güncellenmelidir. Internal linking de yeni sayfayı doğal biçimde sisteme bağlamalıdır.

Indexing Request İndeks Garantisi Verir mi?

Hayır, request yalnız Google'ın URL'yi taramasını veya yeniden değerlendirmesini istemenize yardımcı olur. Google'ın URL'yi indeks için seçmesi ayrı aşamadır. Duplicate, canonical veya içerik değeri problemi devam ediyorsa sonuç değişmeyebilir. Aynı URL'yi sürekli göndermek seçim mekanizmasını geçersiz kılmaz. Kalıcı çözüm teknik ve içerik kök nedenlerini düzeltmektir.

Crawl Request ve Index Selection Farkı

Crawl request yeniden tarama sürecini hedefler. Index selection taramadan sonra gerçekleşen ayrı karardır. Sayfa alınsa bile indekslenmeyebilir. Bu ayrım özellikle crawled not indexed sorununda önemlidir. Request yerine sayfanın neden seçilmediği araştırılmalıdır.

Google'ın Nihai Seçimi

Google kendi indeks sisteminde hangi URL'yi temsilci olarak kullanacağını belirler. Canonical tercihiniz güçlü sinyaldir fakat garanti değildir. İçerik benzerliği ve site sinyalleri birlikte değerlendirilir. İndeks request bu seçim mantığını değiştirmez. Site mimarisi tutarlı hale getirilmelidir.

Neden Kalıcı Çözüm Değildir?

Kök neden template veya URL policy seviyesindeyse yeni sayfalarda sorun yeniden oluşur. Manuel request yalnız mevcut örneğe dokunur. Regression test olmadan bir sonraki deployment aynı hatayı geri getirebilir. Bu nedenle Definition of Done sistemik düzeltme içermelidir. Monitoring sonuçların kalıcı olup olmadığını izlemelidir.

“Düzeltmeyi Doğrula” Nasıl Kullanılmalıdır?

Düzeltmeyi Doğrula süreci kodu veya siteyi sizin yerinize değiştirmez. Önce kök neden production ortamında çözülmelidir. Ardından örnek URL'ler canlı test ve crawler ile kontrol edilir. Teknik sonuçlar doğruysa validation başlatılabilir. Search Console daha sonra ilgili sorun grubunu yeniden değerlendirir ve sonucu takip etmenize yardımcı olur.

Önce Kök Nedeni Düzeltmek

Validation düğmesine basmadan önce gerçek sorunu gidermek gerekir. noindex ise kaldırılmalı, redirect ise düzeltilmelidir. Sitemap ve canonical uyumu kontrol edilmelidir. Template probleminde bütün etkilenen URL grubu dikkate alınmalıdır. Aksi halde validation başarısız olur.

Örnek URL'leri Test Etmek

Farklı template ve segmentlerden birkaç URL seçilir. Live test ve normal HTTP kontrolü yapılır. Crawler tüm kapsamı ölçebilir. Örneklerin yalnız kolay URL'lerden seçilmemesi gerekir. Stratified sampling daha güvenilir sonuç verir.

Validation Başlatmak

Teknik kontroller tamamlandıktan sonra Search Console validation başlatılabilir. Bu işlem Google'ın ilgili issue grubunu tekrar değerlendirmesini sağlar. Sonuç anlık olmayabilir. Ekip ticket'ında validation başlangıç tarihi kaydedilebilir. Monitoring aynı dönemde devam etmelidir.

Validation Sonucunu Takip Etmek

Validation sonucu fix'in gerçekten Google tarafında görüldüğünü anlamaya yardımcı olur. Başarısız olursa kalan URL örnekleri incelenir. Problem aynı root cause mu yoksa yeni pattern mi kontrol edilir. Kapatılan ticket sonradan regression dashboard'da izlenebilir. Böylece issue tekrarında geçmiş çözüm bulunabilir.

Search Console Verisi Tek Başına Yeterli midir?

Search Console Google'ın gördüğü sonuç hakkında değerli bilgi verir fakat site içindeki bütün teknik gerçeği sunmaz. Crawler internal link graph'ını, server log gerçek bot isteklerini, CMS beklenen URL envanterini gösterir. Sitemap index hedeflerini, Analytics ise kullanıcı tarafındaki trafik davranışını destekler. Güçlü indeksleme analizi bu kaynakları tek modelde birleştirir. Yalnız Search Console örnek URL'lerine bakmak büyük sitelerde kapsamı yanlış tahmin etmenize neden olabilir.

Search Console

Google tarafındaki index ve crawl sinyallerini sağlar. Issue kategorileri ve URL Inspection özellikle değerlidir. Ancak bütün URL listesine her zaman erişemezsiniz. Örnekleme mantığıyla çalışmak gerekir. Başka veri kaynaklarıyla kapsam genişletilir.

SEO Crawler

Crawler sitenin kendi internal architecture gerçeğini çıkarır. Status, robots, canonical, depth ve inlinks birlikte görülebilir. JavaScript sitelerde render seçeneği gerekebilir. Search Console sorunları URL pattern'leriyle eşleştirilebilir. Böylece template root cause daha hızlı bulunur.

Server Log

Server log Googlebot'un gerçekten hangi URL'leri taradığını gösterir. Crawl frequency ve response status analiz edilebilir. Bot kimliği doğrulanmalıdır. Response time ve URL pattern birlikte incelenebilir. Büyük sitelerde crawl waste analizi için güçlü kaynaktır.

Sitemap

Sitemap sizin indekslenmesini tercih ettiğiniz URL envanterini temsil etmelidir. Search Console'daki indeks sonuçları bu setle karşılaştırılabilir. Submitted but not indexed cohort çıkarılabilir. Sitemap kalite sorunları ayrıca ölçülmelidir. Segmentasyon teşhisi kolaylaştırır.

CMS / Database

CMS gerçek yayınlanmış içerik envanterini sağlar. Hangi URL'nin indexable olması gerektiği burada modellenebilir. Sitemap generator da aynı veri kaynağını kullanabilir. Search Console ile beklenen ve gerçekleşen durum karşılaştırılır. Böylece Expected Indexation Model dinamik tutulur.

Analytics

Analytics kullanıcıların hangi landing page'lere geldiğini gösterir. Orphan page tespitinde crawler ile birlikte kullanılabilir. İndeks kaybının trafik etkisi ölçülebilir. Ancak Analytics bir URL'nin Google indeksinde olup olmadığını doğrudan göstermez. Veri kaynaklarının görevleri karıştırılmamalıdır.

Server Log Analizi İndeks Sorunlarında Nasıl Kullanılır?

Server log analizi Googlebot'un gerçek crawl davranışını görmenizi sağlar. Hangi URL pattern'lerinin ne sıklıkta tarandığı, hangi status kodlarının döndüğü ve response time değerleri ölçülebilir. Search Console toplu raporlarını doğrulamak için güçlü kaynaktır. Özellikle büyük e-ticaret ve programatik sitelerde crawl waste alanları log ile açık biçimde görünür. User-Agent tek başına gerçek Googlebot doğrulaması için yeterli görülmemelidir.

Googlebot İstekleri

Log kayıtları bot user-agent ve IP bilgisi taşıyabilir. Googlebot istekleri URL pattern'e göre gruplanabilir. Mobil crawler ve diğer Google botları ayrıştırılabilir. Sahte user-agent riski nedeniyle doğrulama gerekir. Veriler günlük veya haftalık cohort'larda analiz edilebilir.

Crawl Frequency

Hangi URL gruplarının daha sık tarandığı ölçülebilir. Kritik güncel sayfaların çok seyrek taranması dikkat çekebilir. Gereksiz filtre URL'lerinin yüksek crawl payı crawl waste göstergesi olabilir. Sitemap ve internal links bu dağılımla karşılaştırılabilir. Tek başına frekans ranking metriği değildir.

HTTP Status

Googlebot isteklerinin status dağılımı önemlidir. 5xx artışı teknik incident gösterebilir. Çok yüksek 3xx oranı eski internal links veya URL transition sorununa işaret edebilir. 404 pattern'leri stale link kaynaklarını gösterebilir. Bu veriler URL inventory temizliği için kullanılır.

Response Time

Response time crawl capacity ile ilişkili teknik gösterge olabilir. P50 yanında yüksek percentile değerleri de incelenmelidir. Belirli endpoint'ler çok yavaşsa backend sorguları optimize edilebilir. CDN hit ve miss davranışı ayrıca karşılaştırılabilir. Kullanıcı performansı ile bot performansı aynı altyapı probleminden etkilenebilir.

URL Pattern

Log verisini tekil URL yerine pattern bazında analiz etmek ölçekli sonuç verir. /products/, ?filter= veya calendar path'leri ayrı cohort yapılabilir. Crawl payı ile indeks değeri karşılaştırılabilir. Gereksiz pattern çok kaynak tüketiyorsa URL üretim politikası gözden geçirilir. Bu yaklaşım crawl budget tartışmasını somut veriye bağlar.

Crawl Budget Nedir?

Crawl budget büyük sitelerde Google'ın siteyi ne kadar ve hangi verimlilikte tarayabildiğini anlamaya yardımcı olan kavramdır. Crawl demand ve crawl capacity birlikte değerlendirilir. Küçük birkaç yüz URL'lik sitede çoğu indeks problemi crawl budget kaynaklı değildir. Buna rağmen milyonlarca filtre ve parametre üreten platformlarda gereksiz crawl alanı önemli olabilir. Öncelik her zaman değerli URL'lerin kolay keşfedilmesi ve sunucunun güvenilir yanıt vermesidir.

Crawl Demand

Crawl demand Google'ın belirli URL'leri yeniden tarama isteğiyle ilişkilidir. Popülerlik ve değişim sıklığı gibi faktörler etkili olabilir. Site sahibi bunu tek düğmeyle kontrol etmez. Internal linking ve kaliteli sitemap discovery'yi destekler. Gereksiz URL üretimi değerli URL alanını seyreltebilir.

Crawl Capacity

Crawl capacity sitenin bot isteklerini karşılayabildiği teknik kapasiteyle ilişkilidir. Yüksek hata oranı ve yavaş response problem oluşturabilir. CDN ve cache kapasiteyi destekleyebilir. Googlebot'a özel bloklama yapılmamalıdır. Server log ve Crawl Stats birlikte izlenebilir.

Büyük Sitelerde Crawl Verimliliği

Milyonlarca URL bulunan sitelerde her crawl isteğinin değerli olması önem kazanır. Faceted navigation ve tracking parametreleri gereksiz alan oluşturabilir. Internal links canonical URL'lere yönelmelidir. Sitemap yalnız index hedeflerini taşımalıdır. Log analizi gerçek crawl dağılımını gösterir.

Küçük Sitelerde Ne Kadar Önemlidir?

Küçük sitelerde önce noindex, robots, canonical ve içerik sorunları kontrol edilmelidir. Crawl budget çoğu zaman ilk problem değildir. Yeni sayfanın hiç iç link almaması daha olası neden olabilir. Sitemap ve site mimarisini düzeltmek genellikle yeterlidir. Büyük site tekniklerini gereksiz yere küçük projeye taşımamak gerekir.

Index Bloat Nedir?

Index bloat arama indeksinde gerçek organik değeri olmayan çok sayıda URL'nin bulunması durumudur. Filtreler, parametreler, internal search veya duplicate sayfalar buna neden olabilir. Crawl waste ile aynı kavram değildir fakat iki problem birlikte görülebilir. Gereksiz indeks URL'leri site mimarisini ve Search Console raporlarını zorlaştırır. Çözüm URL üretim politikası, canonical, noindex ve internal linking kararlarını birlikte ele almalıdır.

Gereksiz URL'lerin Google İndeksine Girmesi

Tracking veya sort URL'lerinin indekslenmesi tipik örnektir. Bu adresler sitemap'te bulunmasa bile internal link veya dış kaynaklardan keşfedilebilir. Canonical doğru uygulanmalıdır. Parametre üretimi mümkünse kontrol edilmelidir. Index policy her URL class için açık olmalıdır.

Index Bloat ile Crawl Waste Farkı

Index bloat gereksiz URL'nin indekste bulunmasını ifade eder. Crawl waste ise crawler'ın düşük değerli URL'lere kaynak harcamasıdır. Bir URL taranıp indekslenmeyerek crawl waste oluşturabilir. Başka URL indekslenerek iki soruna birden yol açabilir. KPI'lar ayrı tutulmalıdır.

Site Kalite Sinyallerine Etkisi

Çok sayıda düşük değerli sayfa sitenin yönetimini ve kullanıcı deneyimini zayıflatabilir. Ancak basit bir indeks URL sayısı ile kalite arasında doğrusal formül kurmak doğru değildir. Asıl amaç gereksiz sayfa üretmemektir. Organik landing page stratejisi gerçek arama talebine dayanmalıdır. Index bloat temizliği URL amacını netleştirir.

Faceted Navigation İndeksleme Sorunları

Faceted navigation kullanıcıların ürünleri filtrelemesini kolaylaştırırken çok büyük URL kombinasyonları oluşturabilir. Her kombinasyonun organik landing page olması gerekmez. Search demand taşıyan belirli facet'ler indekslenebilirken düşük değerli kombinasyonlar farklı şekilde yönetilebilir. Canonical, noindex, crawl control ve internal link policy birlikte tasarlanmalıdır. En iyi çözüm bütün filtreleri tek kuralla kapatmak değil, URL sınıflarını iş değerine göre ayırmaktır.

Filtre URL Explosion

Renk, beden, fiyat ve marka kombinasyonları URL sayısını katlayabilir. Crawler bütün kombinasyonları keşfedebilir. Aynı veya çok benzer içerik tekrarları oluşabilir. Hangi filtrelerin URL oluşturacağı kontrol edilmelidir. Infinite combination üretimi engellenmelidir.

Canonical

Düşük değerli filtreler ana kategoriye canonical verilebilir fakat bu karar kullanıcı deneyimi ve içerik farkına göre verilmelidir. İndekslenmesi hedeflenen facet kendi canonical'ını taşımalıdır. Canonical ile internal link policy çelişmemelidir. Sitemap yalnız indeks hedeflerini listelemelidir. Template bazında doğrulama yapılmalıdır.

Noindex

Noindex belirli filtre URL'lerini indeks dışında tutabilir. Ancak crawler erişimi devam edebilir. Çok büyük URL alanında yalnız noindex crawl waste'i çözmez. URL üretimi ve internal links ayrıca ele alınmalıdır. Kullanıcı için gerekli fakat organik değeri olmayan sayfalarda uygun olabilir.

Crawl Control

Robots.txt bazı geniş teknik alanların crawl kontrolünde kullanılabilir. Ancak noindex'in görülmesini engelleyebileceği unutulmamalıdır. Parametre URL'lerinin hiç linklenmemesi daha temel çözüm olabilir. Canonical URL builder tutarlı çalışmalıdır. Crawl policy veri ve UI davranışıyla birlikte tasarlanmalıdır.

Search Demand Taşıyan Facet'ler

Bazı filtre kombinasyonları gerçek kullanıcı aramasına karşılık gelir. Örneğin belirli kategori artı özellik kombinasyonu değerli landing page olabilir. Bu URL benzersiz title, içerik ve ürün seti sunmalıdır. Kendi canonical'ına sahip olabilir. Sitemap'e kontrollü şekilde dahil edilebilir.

E-Ticaret Sitelerinde İndeks Sorunları

E-ticaret sitelerinde ürün, kategori, marka, filtre, stok ve varyasyon davranışları aynı indeksleme sistemini etkiler. Tek tip URL policy bütün bu sayfa sınıflarına uygun olmayabilir. Ürün lifecycle ile sitemap ve canonical üretiminin senkron olması gerekir. Stokta olmayan ürünlerin davranışı geçici veya kalıcı duruma göre değişmelidir. Template bazlı index coverage e-ticaret sitelerinde en değerli KPI'lardan biridir.

Ürün Sayfaları

Ürün sayfası aktif ve kullanıcı için değerliyse indexable olmalıdır. SKU varyasyonları canonical stratejisiyle yönetilebilir. Stok durumu sayfanın lifecycle kararını etkiler. Product structured data indeksleme garantisi vermez fakat sayfa bilgilerini destekler. Sitemap aktif preferred ürün URL'lerini taşımalıdır.

Kategori Sayfaları

Kategori sayfaları güçlü organik landing page olabilir. Filtre ve pagination davranışıyla birlikte değerlendirilmelidir. Empty category soft 404 benzeri probleme yol açabilir. İç link hiyerarşisi ürün discovery için önemlidir. Kategori sitemap'i ayrı segment olarak izlenebilir.

Marka Sayfaları

Marka sayfaları gerçek arama talebi varsa değerli olabilir. Aynı ürün listesini yalnız başlık değiştirerek sunmak yeterli farklılık sağlamayabilir. Marka bilgisi ve benzersiz içerik eklenebilir. Canonical bağımsız landing page stratejisine göre seçilir. Sitemap segmentasyonu marka coverage oranını gösterebilir.

Filtre URL'leri

Filtre URL'leri e-ticaret index bloat'ın sık kaynağıdır. Search demand olmayan kombinasyonlar kontrollü tutulmalıdır. Canonical ve noindex politikası birlikte düşünülür. UI link generation crawler davranışını etkiler. Log analizi en çok taranan filter pattern'lerini gösterebilir.

Stokta Olmayan Ürünler

Geçici stok yokluğu sayfanın hemen kaldırılmasını gerektirmez. Kullanıcıya stok durumu ve alternatifler sunulabilir. Kalıcı kaldırılan ürün için redirect, 404 veya 410 kararı verilir. Her ürün ana kategoriye otomatik yönlendirilmemelidir. Sitemap lifecycle bu kararı takip etmelidir.

Ürün Varyasyonları

Renk veya beden varyasyonları ayrı URL oluşturabilir. Eğer içerik ve arama değeri farklı değilse parent canonical stratejisi uygulanabilir. Ayrı indeks hedefi olan varyasyonlar bağımsız içerik sunmalıdır. Structured data ve URL mapping tutarlı olmalıdır. Duplicate URL kümeleri düzenli audit edilmelidir.

International SEO ve İndeksleme

Çok dilli ve çok bölgeli sitelerde hreflang, canonical ve dil URL'leri indeksleme davranışını birlikte etkiler. Türkçe sayfayı İngilizce sayfaya yanlış canonical etmek locale sürümünün indekslenmesini engelleyebilir. Her gerçek dil sayfasının kendi canonical adresine sahip olması çoğu standart yapıda daha anlaşılırdır. Hreflang indeksleme sorunlarını tek başına çözmez. Dil ve ülke URL'lerinin sitemap, internal linking ve Search Console property yapısıyla uyumlu olması gerekir.

Hreflang

Hreflang locale alternatiflerini ilişkilendirir. Indexability veya canonical problemini çözmez. Target URL'ler canonical ve erişilebilir olmalıdır. Return links tutarlı kurulmalıdır. Yanlış pairing farklı dil sayfalarının ilişkilendirilmesini bozabilir.

Canonical

Her bağımsız locale çoğunlukla kendisini canonical gösterebilir. Cross-language canonical yanlış kullanıldığında bir dil sürümü elenebilir. Sitemap canonical URL'leri içermelidir. Hreflang da bu hedeflere bağlanmalıdır. Search Console selected canonical örnekleri izlenmelidir.

Dil URL'leri

Her dil için ayrı ve kalıcı URL kullanmak crawler discovery'yi kolaylaştırır. Cookie ile aynı URL'de dil değiştirmek indeks mimarisini zorlaştırabilir. Alt klasör, subdomain veya domain modelleri kullanılabilir. URL slug'ları yerelleştirilebilir. Locale mapping merkezi tutulmalıdır.

Ülke URL'leri

Aynı dil farklı pazarlarda ayrı URL'lere sahip olabilir. Fiyat, ürün ve hukuki içerik değişebilir. Hreflang language-region kodları kullanılabilir. Her pazar URL'si bağımsız indexability kontrolünden geçmelidir. Sitemap market bazında segmentlenebilir.

Yanlış Cross-Language Canonical

Türkçe sayfanın İngilizce URL'ye canonical vermesi çelişkili sinyal oluşturabilir. Türkçe hreflang alternatifi olsa bile canonical başka temsilciyi işaret eder. Search Console Google-selected canonical farkı gösterebilir. Locale template canonical builder düzeltilmelidir. Regression test farklı diller için self-canonical kontrolü yapmalıdır.

Site Migration Sonrası İndeksleme Nasıl Takip Edilir?

Migration sonrası eski ve yeni URL setleri birlikte izlenmelidir. Redirect coverage, yeni sitemap, canonical ve index transfer trendleri düzenli ölçülür. Eski URL'lerin indeks sayısı zamanla azalırken yeni canonical URL'lerin görünürlüğü artmalıdır. Tek bir günlük sayı üzerinden başarı kararı verilmemelidir. Organik trafik ve kritik landing page indeks durumu migration KPI'larıyla birlikte değerlendirilmelidir.

Eski URL'ler

Eski URL envanteri migration öncesinde eksiksiz çıkarılmalıdır. Her adresin yeni karşılığı belirlenir. Sitemap'ten eski URL'ler kaldırılır. Internal links yeni target'lara güncellenir. Search Console eski property verisi izlenmeye devam edilebilir.

Yeni URL'ler

Yeni URL'ler 200, indexable ve self-canonical olmalıdır. Sitemap bunları doğrudan göstermelidir. Internal navigation da yeni adresleri kullanmalıdır. Eski URL'den redirect final URL'ye tek hop olmalıdır. Critical sample URL Inspection ile test edilir.

Redirect Coverage

Eski URL'lerin ne kadarının doğru final hedefe yönlendiği ölçülmelidir. 404 veya yanlış kategori redirect'leri ayrı raporlanır. Chain ve loop testleri yapılır. Backlink alan URL'lere öncelik verilebilir. Redirect mapping migration'ın temel acceptance kriteridir.

Sitemap Değişimi

Migration sırasında yeni sitemap yayınlanmalıdır. Eski URL'ler yeni aktif sitemap içinde tutulmamalıdır. Segment sayıları eski envanterle karşılaştırılabilir. Search Console Sitemaps raporu işleme durumunu gösterir. Sitemap generator yeni URL mapping'i kullanmalıdır.

Canonical

Yeni sayfaların canonical adresi yeni URL olmalıdır. Eski domain'e canonical kalması migration'ı zayıflatır. Template seviyesinde full crawl yapılmalıdır. hreflang bulunan sitelerde locale mapping de güncellenir. Structured data URL'leri ayrıca kontrol edilir.

Index Transfer

Index transfer tek anda tamamlanmayabilir. Eski ve yeni URL sayılarının trendi birlikte izlenir. Kritik sorgulardaki landing page değişimleri kontrol edilir. Canonical selected farkları örneklenebilir. Time-to-recovery site büyüklüğü ve migration kapsamına göre değerlendirilir.

SEO Regression Testing Nedir?

SEO regression testing kod yayına çıkmadan önce robots, canonical, HTTP status, sitemap ve rendering davranışında beklenmeyen değişiklikleri yakalamayı amaçlar. Staging crawl ve automated assertions birlikte kullanılabilir. Production smoke test deployment sonrasındaki gerçek davranışı doğrular. Kritik template'lerde indexability testleri yazılım testleri kadar normal hale gelmelidir. Böylece Search Console sorunu haftalar sonra göstermeden önce hata release aşamasında bulunabilir.

Kod Yayına Çıkmadan Önce SEO Testleri

Pull request veya staging aşamasında örnek URL'ler test edilebilir. Status, robots ve canonical beklentileri assertion olarak yazılır. Route değişikliği sitemap fixture'ını güncelleyebilir. Hatalı output merge öncesinde görülür. SEO ekibi acceptance criteria tanımlamalıdır.

Staging Crawl

Staging crawl production'a çıkacak template'leri toplu kontrol eder. Staging ortamı authentication arkasındaysa crawler erişimi kontrollü sağlanır. Production noindex politikasını yanlışlıkla kopyalamamak gerekir. URL parity karşılaştırması yapılabilir. Büyük değişikliklerde migration QA için değerlidir.

Automated Assertions

Automated assertion beklenen teknik davranışı kodla test eder. Ürün URL'si 200 ve indexable olmalı gibi kurallar yazılabilir. Canonical kendi URL'siyle eşleşebilir. Sitemap'te noindex URL olmaması test edilebilir. Bu testler CI pipeline içinde hızlı çalışmalıdır.

Production Smoke Test

Deployment sonrası gerçek production URL'leri test edilir. Robots.txt, canonical, status ve ana içerik render'ı kontrol edilir. Sitemap endpoint'in 200 olduğu doğrulanır. Birkaç kritik template örneği alınır. Sorun bulunursa hızlı rollback veya fix kararı verilir.

Search Console Sorunları Nasıl Önceliklendirilmelidir?

Öncelik yalnız etkilenen URL sayısına göre verilmemelidir. İş değeri, organik trafik potansiyeli, gelir etkisi ve template kapsamı birlikte değerlendirilmelidir. Tek bir checkout dışı kritik kategori URL'sinin kaybı bin düşük değerli filtre URL'sinden daha önemli olabilir. Buna karşılık site genelindeki template hatası hızla P0 seviyesine çıkabilir. Indexation Priority Matrix ekiplerin aynı önceliklendirme dilini kullanmasını sağlar.

URL Sayısına Göre mi?

URL sayısı etki genişliğini anlamak için önemlidir. Ancak tek başına severity belirlemez. Düşük değerli parametre URL'leri milyonlarca olabilir. Kritik landing page sayısı az olabilir. İş değeriyle birlikte okunmalıdır.

İş Değerine Göre mi?

Gelir, lead veya temel kullanıcı ihtiyacına hizmet eden URL'ler önceliklidir. SEO ekipleri URL sınıflarına business value etiketi ekleyebilir. Product ve Analytics verileri karar destek sağlar. Yüksek değerli tekil hata bile hızlı aksiyon gerektirebilir. Bu model teknik backlog'u daha anlamlı hale getirir.

Organik Trafik Potansiyeli

Search demand ve geçmiş performans sorun önceliğini etkiler. Çok gösterim alan kategori indeks dışı kalıyorsa etki büyüktür. Yeni sayfalarda tahmini potansiyel kullanılabilir. Yalnız mevcut trafik üzerinden karar vermek yeni fırsatları gözden kaçırabilir. Segment bazlı SEO forecast yardımcı olabilir.

Gelir Etkisi

E-ticaret ve lead sitelerinde organik landing page'lerin gelir katkısı ölçülebilir. Index loss sonrası revenue trend karşılaştırılabilir. Ancak korelasyon doğrudan neden olarak yorumlanmamalıdır. Analytics ve Search Console verileri birlikte kullanılır. Incident severity iş etkisini içermelidir.

Template Etkisi

Template hatası yeni ve mevcut binlerce URL'yi etkileyebilir. Tek örnek URL'den geniş problem fark edilebilir. Crawler gerçek kapsamı ölçer. Fix template seviyesinde yapılır. Regression test daha sonra aynı kuralı korur.

Indexation Priority Matrix

Priority Matrix teknik indeksleme sorunlarını URL sayısı ve iş değeri ekseninde sınıflandırmak için kullanılabilir. Yüksek değerli ve çok URL etkileyen problem P0 olabilir. Yüksek değerli fakat az URL'li sorun P1 seviyesinde ele alınabilir. Düşük değerli geniş URL grubu P2 veya planlı backlog olarak değerlendirilebilir. Bilinçli exclusion ise hata değil monitoring konusu olabilir.

Yüksek Değer + Çok URL

Bu kategori site için en riskli indexation problemidir. Ürün veya kategori template'inin tamamı etkilenebilir. Teknik ekip hızla incident sürecine geçmelidir. Son deployment ve sitewide ayarlar kontrol edilir. Fix sonrası Search Console ve crawler birlikte izlenir.

P0

P0 acil müdahale gerektiren kritik durumdur. Sitewide noindex veya robots engeli buna örnek olabilir. Named incident owner atanmalıdır. Rollback seçeneği hemen değerlendirilir. İş çözülene kadar sık monitoring yapılır.

Yüksek Değer + Az URL

Az sayıda URL etkilenmesine rağmen ticari etkisi büyük olabilir. Ana kategori veya kampanya landing page örnek verilebilir. Tekil URL Inspection hızla yapılır. Root cause benzer sayfalar için kontrol edilir. Fix geciktirilmeden uygulanır.

P1

P1 yüksek öncelikli ancak site geneli olmayan sorundur. Aynı iş günü içinde teknik analiz yapılabilir. Acceptance criteria net yazılır. Fix ve validation takip edilir. Regression riski varsa test eklenir.

Düşük Değer + Çok URL

Filtre veya utility URL grupları bu kategoriye girebilir. İndekslenmemeleri zaten hedef olabilir. Eğer crawl waste oluşturuyorsa URL policy projesi açılır. Acil incident olmayabilir. Ölçek nedeniyle sistemsel temizlik yine değerlidir.

P2

P2 planlı teknik SEO backlog'una alınabilir. İş değeri ve engineering maliyeti birlikte değerlendirilir. Sorun trend halinde büyüyorsa priority yükseltilebilir. Monitoring metriği tanımlanır. Çözüm URL pattern seviyesinde uygulanır.

Bilinçli Hariç Tutma

Intentional noindex, redirect veya canonical alternatifler bu gruptadır. Search Console'da görünmeleri normal olabilir. Issue açmadan önce index policy kontrol edilir. Beklenen URL seti dokümante edilir. Yalnız davranış değişirse aksiyon gerekir.

Aksiyon yok / monitor

Beklenen exclusion için teknik değişiklik yapılmaz. Trend veya pattern değişimi izlenir. URL sayısındaki beklenmeyen artış araştırılabilir. Sitemap'te görünmedikleri doğrulanır. Dashboard bu grubu hata oranından ayrı gösterebilir.

Search Console Haftalık Yönetim Rutini

Haftalık rutin Page Indexing trendi, yeni sorunlar, sitemap durumu, Crawl Stats, kritik URL örnekleri ve açık validation süreçlerini kapsayabilir. Amaç her raporu saatlerce manuel incelemek değildir. Önceden belirlenmiş KPI ve alert eşikleri üzerinden değişim aranmalıdır. Büyük değişiklik görüldüğünde template ve URL pattern analizi başlatılır. Böylece Search Console ve indeksleme sorunu danışmanlığı yakınımda gibi hizmet ihtiyacında bile çalışma reaktif değil düzenli bir operasyon modeline dönüşür.

Page Indexing Trend

Indexed ve non-indexed URL trendleri haftalık karşılaştırılır. Beklenen içerik üretim hacmiyle uyum kontrol edilir. Ani düşüş deployment tarihiyle eşleştirilir. Segment bazlı sitemap varsa kırılım incelenir. Küçük doğal dalgalanmalara gereksiz incident açılmaz.

Yeni Sorunlar

Yeni reason kategorileri veya büyük URL artışları not edilir. Hangi template'lerin etkilendiği örnek URL'lerden çıkarılır. Crawler ile kapsam ölçülebilir. Expected exclusion olup olmadığı kontrol edilir. Gerekirse issue ticket oluşturulur.

Sitemap Durumu

Sitemap dosyalarının okunup okunmadığı kontrol edilir. URL sayısı beklenen inventory ile karşılaştırılır. Yeni sitemap segmentleri takip edilir. 404 veya noindex oranı otomatik audit edilebilir. Stale lastmod davranışı ayrıca incelenir.

Crawl Stats

5xx ve host availability değişimleri gözden geçirilir. Crawl request trendleri büyük deployment sonrası anlamlı olabilir. Tek başına crawl sayısı başarı KPI'sı değildir. Server log ile kritik sapmalar doğrulanabilir. DevOps issue gerekiyorsa erken açılır.

Critical URL Samples

Ana sayfa, kritik kategoriler ve birkaç ürün veya içerik URL'si örneklenebilir. URL Inspection veya otomatik health check kullanılır. Canonical ve indexability doğrulanır. Yeni template release'i varsa ilgili URL eklenir. Sampling listesi zamanla rotasyonlu tutulabilir.

Açık Validation'lar

Başlatılan fix validation süreçleri takip edilir. Başarısız olanlarda kalan URL örnekleri incelenir. Issue ticket ile Search Console durumu ilişkilendirilir. Kapatılan sorun için monitoring devam eder. Aynı problem tekrar oluşursa regression kaydı açılır.

Search Console Dashboard'unda Hangi KPI'lar Olmalı?

İyi dashboard yalnız toplam indexed sayısını göstermemelidir. Expected Indexed URLs, Actual Indexed URLs, Index Coverage Ratio, Non-Indexed Critical URLs, Canonical Mismatch Rate, Sitemap Quality Rate ve Time-to-Index birlikte izlenebilir. Segment kırılımları template ve business value açısından eklenmelidir. KPI'lar aksiyon üretmeyen süs grafikleri olmamalıdır. Her metriğin normal aralığı ve alarm eşiği tanımlanmalıdır.

Expected Indexed URLs

CMS ve index policy üzerinden hesaplanan hedef URL sayısıdır. Bilinçli noindex ve redirect URL'ler dahil edilmez. Segment bazında tutulmalıdır. Yeni içerik yayınlandıkça dinamik değişir. Coverage hesaplamasının temel paydasıdır.

Actual Indexed URLs

Google'ın indekslediği hedef URL'lerin tahmini veya raporlanan sayısıdır. Search Console segmentleri kullanılabilir. Küçük farklılıklar normal olabilir. Kritik template trendi daha önemlidir. Expected değerle birlikte yorumlanmalıdır.

Index Coverage Ratio

Actual indexed hedeflerin expected hedeflere oranıdır. Tek site geneli oran yanıltıcı olabilir. Ürün, kategori ve blog için ayrı hesaplanmalıdır. Ani düşüş alert oluşturabilir. Tarihsel trend deployment etkisini gösterir.

Non-Indexed Critical URLs

İş değeri yüksek fakat indekslenmeyen URL sayısıdır. Bu metrik toplam non-indexed sayısından daha önemlidir. URL listesi issue management sistemine bağlanabilir. Reason kategorisi ayrıca tutulur. P0 ve P1 kararları bu veriyle desteklenebilir.

Canonical Mismatch Rate

Declared ve Google-selected canonical farklarının örneklem oranıdır. Bütün URL'leri sürekli inspection etmek gerekmez. Template bazlı sampling yapılabilir. Yüksek oran URL normalization problemine işaret edebilir. Migration döneminde özel olarak izlenmelidir.

Sitemap Quality Rate

Sitemap içindeki URL'lerin kaçının 200, indexable ve canonical olduğunu ölçebilir. Hedef oran mümkün olduğunca yüksek olmalıdır. noindex veya redirect URL görünmesi generator issue'sudur. Segmentler ayrı raporlanabilir. Release sonrası otomatik kontrol yapılabilir.

Time-to-Index

Publish ile ilk indekslenme arasındaki süreyi ölçer. Median değer normal davranışı gösterir. 90th percentile geciken sayfaları anlamaya yardımcı olur. Template ve içerik tipleri karşılaştırılabilir. Yeni site veya büyük değişikliklerde dönemsel farklılıklar beklenebilir.

AI ile İndeksleme Sorunları Tespit Edilebilir mi?

AI destekli analiz URL pattern clustering, anomaly detection ve issue summary hazırlamada yardımcı olabilir. Ancak canonical, robots veya URL silme kararlarını otomatik biçimde production'a uygulamak doğru değildir. Model kök neden adaylarını sıralayabilir fakat gerçek HTTP, crawler ve Search Console verileriyle doğrulama gerekir. İnsan onayı özellikle site genelini etkileyen değişikliklerde zorunlu tutulmalıdır. İndeksleme yönetiminde otomasyonun amacı karar sahibini kaldırmak değil, veri hacmini daha hızlı anlamlandırmaktır.

URL Pattern Clustering

Binlerce URL path ve query yapılarına göre gruplanabilir. Benzer Search Console durumları aynı cluster'da toplanabilir. Bu sayede tekil URL gürültüsü azalır. Pattern sonucu crawler verisiyle doğrulanmalıdır. Cluster adı insan tarafından anlaşılır şekilde verilmelidir.

Anomaly Detection

Index coverage veya 5xx trendindeki beklenmeyen sapmalar otomatik bulunabilir. Tarihsel normal aralık referans alınabilir. Sezonluk içerik değişimleri hesaba katılmalıdır. Her anomaly incident değildir. İnsan analisti business context ile sonucu değerlendirmelidir.

Error Classification

Issue ticket'ları robots, canonical, rendering veya content gibi sınıflara ayrılabilir. Search Console reason tek başına kök neden olarak kullanılmamalıdır. Crawler ve log sinyalleri classification'a eklenebilir. Confidence düşükse manuel review istenir. Bu yöntem backlog yönetimini hızlandırabilir.

Root Cause Adayları

Sistem benzer geçmiş incident'lara göre olası nedenler önerebilir. Örneğin ani noindex artışı son deployment ile eşleştirilebilir. Öneri kanıt değildir. Teknik ekip source code ve production output'u doğrular. Değişiklik insan onayından sonra uygulanır.

Issue Summary

Uzun crawler ve Search Console verisi ticket formatına özetlenebilir. Etkilenen pattern, örnek URL ve beklenen davranış açıkça yazılabilir. Acceptance criteria yine ekip tarafından doğrulanmalıdır. Hassas veya özel veriler modele aktarılırken kurum politikaları dikkate alınmalıdır. Otomatik özet teknik kanıtın yerine geçmez.

Open Source ve İş Birliği Teknik SEO'ya Nasıl Katkı Sağlar?

Açık kaynak çalışmalar crawler, sitemap validator, log parser ve canonical checker gibi araçların birlikte geliştirilmesini sağlar. Teknik SEO problemleri web protokolü, veri işleme ve otomasyon bilgilerini tek projede buluşturur. Diyarbakır Yazılım Topluluğu gibi yapılarda gerçek URL envanterleri yerine güvenli test fixture'ları kullanılarak eğitim projeleri hazırlanabilir. Topluluğun mevcut proje yaklaşımını https://www.diyarbakiryazilim.com.tr/projects üzerinden incelemek mümkündür. Bu tür iş birlikleri geliştiricilerin yalnız teori değil gerçek debugging alışkanlığı kazanmasına yardımcı olur.

Ortak Audit Script'leri

Basit script sitemap ve status code karşılaştırmasıyla başlayabilir. Daha sonra robots, canonical ve indexability testleri eklenebilir. Test verileri repository içinde tutulabilir. Pull request süreci kod kalitesini geliştirir. Dokümantasyon yeni katkıcıların projeye katılmasını kolaylaştırır.

URL Validation Araçları

Validator URL'nin 200, canonical ve indexable olup olmadığını kontrol edebilir. Büyük listelerde concurrency dikkatle yönetilmelidir. Rate limiting hedef siteyi korur. Sonuçlar CSV veya HTML rapora dönüştürülebilir. Tool gerçek production değişikliği yapmamalıdır.

Search Console Veri Analizi

API üzerinden izin verilen rapor verileri analiz pipeline'ına alınabilir. URL pattern segmentasyonu yapılabilir. Anomaly detection eklenebilir. Kullanıcı erişim ve veri gizliliği kuralları korunmalıdır. Dashboard yalnız gerekli veriyi göstermelidir.

Topluluk Tarafından Geliştirilen Crawler'lar

Öğretici crawler projesi HTTP ve HTML parsing bilgisi kazandırır. Robots kurallarına saygı göstermelidir. Concurrency sınırlı ve güvenli olmalıdır. Canonical ve link graph çıkarılabilir. Kendi test sitelerinde geliştirmek iyi başlangıçtır.

GitHub Üzerinden Teknik SEO Otomasyonu

CI workflow sitemap fixture'larını otomatik test edebilir. Pull request sırasında canonical assertion çalıştırılabilir. Regression sonucu artifact olarak saklanabilir. Açık issue'lar yeni geliştiricilere görev sağlar. Proje kapsamı küçük modüller halinde büyütülebilir.

Diyarbakır Yazılım Topluluğu Gibi Yapılarda Teknik SEO Çalışmaları

Teknik SEO geliştiricilerin HTTP, rendering, API ve log analizi bilgilerini gerçek kullanım senaryosuna taşıyabileceği iyi bir çalışma alanıdır. Search Console workshop, audit etkinliği ve açık kaynak crawler projesi farklı deneyim seviyelerindeki katılımcılara görev sunabilir. Yapılandırılmış veri testleri de indeksleme sonrası arama görünümü konusunu tamamlayan başka bir teknik alan sağlar. Bu konuda https://www.diyarbakiryazilim.com.tr/posts/zengin-sonuclar-rich-snippets-icin-yapilandirilmis-veri-testleri içeriği incelenebilir. Topluluğun genel yaklaşımı için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir.

Search Console Workshop

Workshop örnek property verileri veya güvenli demo ortamıyla yapılabilir. Page Indexing ve URL Inspection farkı gösterilebilir. Katılımcılar issue reason'larını expected ve unexpected olarak ayırabilir. Basit index coverage hesabı yapılabilir. Teknik ticket yazımıyla çalışma tamamlanabilir.

Teknik SEO Audit Etkinlikleri

Audit etkinliğinde crawler ve sitemap karşılaştırması yapılabilir. Test sitesi üzerinde robots ve canonical hataları hazırlanabilir. Katılımcılar root cause bulmaya çalışabilir. Sonuçlar ortak raporda toplanabilir. Gerçek sitelerde çalışma yapılacaksa izin ve yük sınırları korunmalıdır.

Open Source Crawler Projeleri

Crawler projesi HTTP request ve HTML parsing öğretir. Link graph oluşturma ikinci aşama olabilir. Status ve canonical raporu üretilebilir. JavaScript render daha ileri modül olarak eklenebilir. Güvenli crawl sınırları açıkça belgelenmelidir.

Sitemap Validator Projesi

Sitemap parser URL listesini çıkarabilir. Status, noindex ve canonical kontrolü eklenebilir. Sitemap quality rate hesaplanabilir. CI entegrasyonu örneklenebilir. Bu proje küçük başlayıp gerçek teknik araca dönüşebilir.

Log Analyzer Projesi

Log parser Googlebot satırlarını filtreleyebilir. Status ve response time dağılımları hesaplanabilir. URL pattern clustering yapılabilir. Bot doğrulama konusu ayrıca öğretilmelidir. Büyük dosyalar streaming yöntemle işlenebilir.

Gerçek Web Projeleri Üzerinde Uygulama

Gerçek projede izinli ve kontrollü çalışma yapılmalıdır. Önce URL inventory çıkarılır. Ardından Search Console ve crawler sonuçları karşılaştırılır. Teknik değişiklikler proje sahibinin onayıyla yapılır. Sonuçlar ölçülerek öğrenme döngüsü tamamlanır.

30 Günlük Search Console İndeksleme Audit Planı

Otuz günlük plan ilk beş günde URL envanteri, sonraki beş günde indexability, ardından Search Console segmentleri, crawl ve log analizi, fix ve validation aşamalarıyla ilerleyebilir. Amaç her gün rastgele URL kontrol etmek değildir. Her dönem bir sonraki aşamanın veri temelini oluşturur. Kritik incident varsa plan takviminden bağımsız olarak hemen ele alınmalıdır. Normal audit sürecinde ise bu sıralama kapsamlı bir baseline oluşturur.

Gün 1-5 - URL Envanteri

İlk aşamada bütün önemli URL kaynakları toplanır. Sitemap, crawler ve CMS envanteri karşılaştırılır. Template sınıfları belirlenir. Indexlenmesi beklenen URL seti tanımlanır. Orphan ve duplicate adayları işaretlenir.

URL sayısı

Toplam URL sayısı kaynak bazında çıkarılır. Crawler ve CMS farkları incelenir. Parametre URL hacmi ayrıca ölçülür. Sitemap URL sayısı karşılaştırılır. Bu sayılar sonraki KPI hesaplarının temelidir.

template

URL'ler ürün, kategori, blog veya landing page gibi template'lere ayrılır. Her template için index policy tanımlanır. Aynı route farklı amaçta kullanılıyorsa alt segment oluşturulur. İş değeri eklenir. Coverage daha sonra bu sınıflara göre ölçülür.

sitemap

Sitemap dosyaları ve child index yapısı çıkarılır. Her dosyanın URL sayısı kaydedilir. 200 dışı URL oranı test edilir. Canonical ve noindex örnekleri incelenir. Segment yapısı raporlama ihtiyacına göre değerlendirilir.

Gün 6-10 - Indexability

İkinci aşamada robots, noindex, canonical ve status verileri toplanır. Template bazlı hata oranları hesaplanır. Search Console'a geçmeden önce sitenin kendi teknik gerçeği anlaşılır. Çelişkili sinyaller issue listesine alınır. Kritik sitewide problem varsa hemen fix süreci başlatılır.

robots

robots.txt kuralları URL pattern'leriyle test edilir. Kritik landing page engeli aranır. Sitemap reference kontrol edilir. Staging ve production dosyaları karşılaştırılabilir. Değişiklik geçmişi incelenir.

noindex

Meta robots ve X-Robots-Tag toplanır. Bilinçli ve accidental noindex ayrılır. Template oranları çıkarılır. Sitemap ile noindex karşılaştırılır. Yanlış varsayılan CMS ayarı aranır.

canonical

Self-canonical oranı ölçülür. Non-200 canonical targets raporlanır. Duplicate canonical kümeleri incelenir. Sitemap URL'leriyle karşılaştırma yapılır. Google-selected canonical daha sonra örneklemde eklenecektir.

status

200, 3xx, 4xx ve 5xx dağılımı çıkarılır. Redirect chains ölçülür. Soft 404 adayları ayrı işaretlenir. Kritik 5xx pattern DevOps'a aktarılır. Sitemap içindeki non-200 URL'ler düzeltilir.

Gün 11-15 - Search Console

Üçüncü aşamada teknik inventory Google'ın gördüğü index durumuyla karşılaştırılır. Reason kategorileri template bazında segmentlenir. Kritik URL samples URL Inspection ile incelenir. Expected exclusions listeden ayrılır. İlk gerçek index coverage baseline'ı oluşturulur.

index raporu

Page Indexing trendi son dönemle birlikte incelenir. Ani kırılmalar deployment tarihleriyle eşleştirilir. Indexed ve non-indexed sayıları tek başına yorumlanmaz. Template segmentleri kullanılır. Kritik düşüşler issue'ya dönüştürülür.

issue segmentleri

Robots, noindex, crawled ve discovered gibi gruplar ayrılır. Her grup expected veya unexpected olarak etiketlenir. URL pattern çıkarılır. İş değeri eklenir. Priority matrix uygulanır.

URL samples

Her issue'dan birkaç temsilci URL seçilir. Current Index ve Live Test sonuçları kaydedilir. Canonical farkları kontrol edilir. Düzeltmeden önce kanıt toplanır. Ticket örnekleri bu veriyi kullanır.

Gün 16-20 - Crawl ve Log

Dördüncü aşamada internal crawl ve server log analizi Search Console sonuçlarına bağlanır. Click depth ve inlinks değerleri kritik non-indexed URL'lerde karşılaştırılır. Googlebot crawl dağılımı log üzerinden incelenir. URL explosion ve crawl waste pattern'leri belirlenir. Böylece Search Console mesajının arkasındaki site davranışı daha açık hale gelir.

internal crawl

Full crawl canonical URL envanterini çıkarır. Broken links ve redirect targets görülür. Indexability alanları toplanır. Template bazında rapor hazırlanır. Search Console issue URL'leri crawl verisiyle eşleştirilir.

click depth

Kritik sayfaların ana sayfadan uzaklığı ölçülür. Çok derin önemli URL'ler işaretlenir. Orphan page listesi çıkarılır. Kategori hiyerarşisi gözden geçirilir. Internal linking fix planı hazırlanır.

Googlebot logs

Googlebot istekleri doğrulanarak ayrılır. Status ve response time dağılımları ölçülür. Crawl edilmeyen kritik pattern'ler bulunur. Gereksiz filtre crawl payı hesaplanır. Sonuç Crawl Stats ile karşılaştırılır.

Gün 21-25 - Fix

Beşinci aşamada önceliklendirilmiş teknik sorunlar gerçek kod veya konfigürasyon değişikliklerine dönüşür. Her ticket etkilenen pattern ve acceptance criteria içermelidir. Staging QA yapılmadan production'a geçilmemelidir. Sitewide değişikliklerde rollback planı hazırlanır. Fix'in yalnız örnek URL'yi değil bütün pattern'i çözdüğü doğrulanmalıdır.

teknik ticket

Problem net bir URL pattern'iyle tanımlanır. Expected ve actual behaviour yazılır. Örnek URL eklenir. Root cause biliniyorsa belirtilir. Acceptance criteria ölçülebilir olmalıdır.

deployment

Fix staging testinden sonra production'a alınır. SEO ve engineering release bilgisini paylaşır. Sitemap veya cache invalidation gerekiyorsa aynı süreçte yapılır. Deployment timestamp'i kaydedilir. Search Console trendleri bu tarihle karşılaştırılır.

QA

Production smoke test kritik URL'leri kontrol eder. Status, robots ve canonical doğrulanır. Rendered content test edilir. Sitemap güncellemesi incelenir. Regression bulunursa hızlı aksiyon alınır.

Gün 26-30 - Validation

Son aşamada canlı URL testleri, Search Console validation ve KPI baseline birlikte ele alınır. Fix'in teknik olarak doğru olması ilk başarı ölçütüdür. Google'ın raporlarının güncellenmesi daha uzun sürebilir. Coverage ve time-to-index için yeni baseline kaydedilir. Audit sonunda devam eden monitoring ve backlog sahipleri belirlenir.

live URL test

Kritik örneklerde mevcut production davranışı test edilir. noindex ve robots düzeltmeleri doğrulanır. Rendered content kontrol edilir. Teknik sonuçlar ticket'a eklenir. Successful test indeks garantisi olarak yorumlanmaz.

Search Console validation

İlgili issue için validation başlatılabilir. Başlangıç tarihi kaydedilir. Durum haftalık takip edilir. Başarısız örnekler yeniden analiz edilir. Root cause tamamlanmadan issue kapatılmaz.

KPI baseline

Expected ve actual indexed sayılar kaydedilir. Coverage ratio template bazında oluşturulur. Canonical mismatch ve sitemap quality ölçülür. Time-to-index cohort başlangıcı belirlenir. Sonraki aylık audit bu baseline ile karşılaştırılır.

İlk 60 Dakikada İndeksleme Sorunu Nasıl Teşhis Edilir?

Acil bir indexation probleminde ilk saat bütün siteyi taramaya çalışmak yerine kapsamı ve root cause adaylarını hızla daraltmak için kullanılmalıdır. İlk on dakika problemin site geneli mi tekil mi olduğu belirlenir. Ardından Search Console segmenti, URL Inspection, HTTP crawl, canonical, robots ve sitemap kontrolleri yapılır. Son on dakikada bulgular kök neden adayına ve teknik aksiyona dönüştürülür. Kritik incident ise named owner ve rollback seçeneği aynı saat içinde belirlenmelidir.

İlk 10 Dakika - Problemin Kapsamı

Kaç URL'nin etkilendiği tahmin edilir. Kritik template olup olmadığı kontrol edilir. Son deployment zamanı not edilir. Trafik veya gelir etkisi hızlıca değerlendirilir. Sitewide problem şüphesinde SEV seviyesi yükseltilir.

10-20 Dakika - Search Console Segmenti

Page Indexing reason kategorisi incelenir. URL örnekleri pattern'e ayrılır. Trend başlangıç tarihi belirlenir. Expected exclusion olup olmadığı kontrol edilir. Aynı sitemap segmenti etkileniyor mu bakılır.

20-30 Dakika - URL Inspection

İki veya üç kritik URL incelenir. Last crawl, indexability ve canonical bilgileri alınır. Live test çalıştırılır. Current ve live farkı kaydedilir. Tekil anomali olup olmadığı anlaşılmaya çalışılır.

30-40 Dakika - Crawl ve HTTP

URL'ler bağımsız HTTP isteğiyle kontrol edilir. Redirect chain ve response header incelenir. Crawler aynı template'ten küçük sample tarar. Meta robots ve inlinks toplanır. Server error varsa DevOps bilgisi istenir.

40-50 Dakika - Canonical / Robots / Sitemap

Canonical target ve robots pattern'i karşılaştırılır. Sitemap'te URL'nin doğru sürümü aranır. noindex veya X-Robots-Tag kontrol edilir. URL normalization farkları incelenir. Sitewide konfigürasyon problemi belirginleşir.

50-60 Dakika - Kök Neden ve Aksiyon

Bulgular tek teknik hipotez halinde özetlenir. Etkilenen URL pattern'i ticket'a yazılır. Fix owner atanır. Acceptance criteria oluşturulur. Kanıt yetersizse sonraki veri ihtiyacı açıkça belirtilir.

Örnek İndeksleme Sorunu Teşhis Akışı

Basit karar ağacı ekiplerin farklı indeks sorunlarını aynı sırayla incelemesini sağlar. Önce Google URL'yi biliyor mu sorusuyla başlanır. Ardından crawling, HTTP, indexability, canonical ve index selection katmanları kontrol edilir. Her “hayır” yanıtı farklı bir root cause alanına yönlendirir. Bu akış özellikle yeni ekip üyelerinin rastgele kontrol yapmasını önlemek için faydalıdır.

URL Google Tarafından Biliniyor mu?

URL Inspection ilk işaretlerden birini verir. Google URL hakkında veri taşımıyorsa discovery kontrolüne geçilir. Sitemap ve internal links incelenir. Yeni URL ise makul süre değerlendirilir. Orphan problemi varsa mimari düzeltilir.

Hayır → Discovery problemi

URL sitemap'te yoksa eklenmesi gereken bir hedef mi kontrol edilir. Internal link alınmıyorsa uygun bağlantı oluşturulur. Canonical URL'nin gerçekten production'da bulunduğu doğrulanır. Link yalnız kullanıcı için anlamlı konumdan verilmelidir. Sonrasında crawl süreci izlenir.

Evet → sonraki kontrol

Google URL'yi biliyorsa crawling aşamasına geçilir. Last crawl veya discovered statüsü incelenir. Robots ve server erişimi kontrol edilir. Tekil URL yerine pattern düşünülür. Gereksiz discovery kontrollerinde zaman kaybedilmez.

Google URL'yi Tarayabiliyor mu?

Live Test ve robots kontrolü kullanılır. Server access ve security rule değerlendirilir. Discovered not indexed durumda henüz crawl yapılmamış olabilir. Log veri varsa Googlebot isteği aranır. Erişim sorunu bulunursa önce bu katman çözülür.

Hayır → Crawl problemi

Robots, DNS, WAF ve HTTP erişim engelleri incelenir. İndeks hedefi olan URL yanlışlıkla block edilmişse düzeltilir. Server 5xx veriyorsa altyapı incident açılır. Live test fix sonrası tekrar çalıştırılır. Sonraki katmana ancak erişim sağlandığında geçilir.

Evet → sonraki kontrol

Googlebot sayfaya ulaşabiliyorsa HTTP ve content response değerlendirilir. Status code kaydedilir. Redirect varsa final URL kontrol edilir. 200 alınması indexability testine geçiş sağlar. Soft 404 ihtimali unutulmamalıdır.

HTTP 200 mü?

Organik landing page hedefi için 200 beklenir. 3xx başka URL'yi hedefler. 4xx veya 5xx kendi çözüm akışını gerektirir. Response header ayrıca kontrol edilir. Status doğruysa indexability incelenir.

Hayır → HTTP problemi

Status kodunun iş amacıyla uyumlu olup olmadığı belirlenir. Redirect beklenen davranışsa hedef URL değerlendirilir. 404 yanlış routing ise düzeltilir. 5xx server tarafına eskale edilir. Sitemap'teki URL gerçek preferred target ile değiştirilir.

Evet → sonraki kontrol

200 başarılı response alınmıştır. Meta robots ve X-Robots-Tag incelenir. Render edilmiş içeriğin mevcut olduğu kontrol edilir. Sayfa boş shell ise rendering analizine geçilir. Teknik erişim başarıyla tamamlanmıştır.

Sayfa Indexable mı?

noindex veya access restriction bulunup bulunmadığı kontrol edilir. Robots crawl engeli ayrıca değerlendirilir. CMS ve live output karşılaştırılır. İndekslenmesi istenen sayfa açık olmalıdır. Doğruysa canonical katmanına geçilir.

Hayır → robots/noindex problemi

Engelin bilinçli olup olmadığı belirlenir. Accidental noindex ise template fix yapılır. robots pattern yanlışsa düzeltilir. Sitemap çakışması temizlenir. Live test ile yeni durum doğrulanır.

Evet → sonraki kontrol

Sayfa indekslenebilir durumdadır. Canonical declared ve selected verileri incelenir. Sitemap ve internal links aynı URL'yi destekliyor mu kontrol edilir. Duplicate kümeleri aranır. Canonical doğruysa index selection analizi başlar.

Canonical Doğru mu?

Self-canonical veya hedeflenen canonical policy ile karşılaştırma yapılır. Redirect target ve sitemap URL'si aynı tercih edilen adrese bağlanmalıdır. Google-selected farklıysa conflict matrix kullanılır. Duplicate URL patterns incelenir. Sinyal çatışması yoksa içerik seçim aşamasına geçilir.

Hayır → canonical problemi

HTML tag tek başına değil bütün URL sinyalleri düzeltilir. Internal links canonical adrese çevrilir. Sitemap non-canonical URL'lerden temizlenir. Redirect final hedefi sadeleştirilir. Regression test canonical policy'yi korur.

Evet → sonraki kontrol

Teknik canonical davranışı doğrudur. Crawled not indexed veya benzer seçim statüsü incelenir. İçerik benzerliği ve değer sinyalleri analiz edilir. Template cohort karşılaştırması yapılır. Sorun artık yalnız teknik erişim değildir.

Google Sayfayı İndeks İçin Seçiyor mu?

URL indekslenmişse süreç tamamlanır. İndekslenmiyorsa içerik, duplicate ve site value sinyalleri değerlendirilir. Programatik sayfalarda cohort analizi güçlüdür. İndeksli örneklerle indeks dışı örnekler karşılaştırılır. Yeni request göndermek yerine gerçek fark bulunmalıdır.

Hayır → içerik/değer/duplicate analizi

Ana içerik gerçekten benzersiz mi incelenir. Search intent karşılanıyor mu değerlendirilir. Duplicate template oranı ölçülür. Internal linking ve content depth karşılaştırılır. Gerekirse düşük değerli URL üretim politikası değiştirilir.

İndeksleme Sorunlarında En Sık Yapılan Hatalar

En yaygın hata her non-indexed URL'yi sorun kabul etmektir. Robots ve noindex kavramlarını karıştırmak, bütün 404'leri ana sayfaya yönlendirmek ve request indexing düğmesine tekrar tekrar basmak da sık görülür. Sitemap'i URL çöplüğüne çevirmek ve canonical çatışmalarını görmezden gelmek rapor kalitesini bozar. JavaScript render test edilmediğinde teknik olarak 200 görünen boş sayfalar gözden kaçabilir. En önemli hata ise aynı pattern'deki yüzlerce URL'yi tek tek düzeltmek yerine template kök nedenini çözmemektir.

Her Non-Indexed URL'yi Hata Sanmak

Redirect ve duplicate URL'lerin indekslenmemesi normal olabilir. noindex sayfalar da bilinçli exclusion olabilir. Önce expected model kontrol edilir. Kritik landing page'ler ayrı tutulur. Aksiyon yalnız beklenmeyen durumlara verilir.

Robots.txt ile Noindex'i Karıştırmak

Robots crawl kontrolüdür. noindex index directive görevi görür. Birini diğerinin yerine kullanmak sorun çıkarabilir. Site policy bu farkı dokümante etmelidir. Ekip eğitiminde gerçek örnekler kullanılmalıdır.

Bütün Noindex Etiketlerini Kaldırmak

Search Console'da noindex sayısı yüksek diye global kaldırma yapılmamalıdır. Utility URL'ler bilinçli olarak noindex olabilir. Önce URL class belirlenir. Accidental template hatası ayrı düzeltilir. Değişiklik production öncesi test edilir.

404'lerin Tamamını Ana Sayfaya Yönlendirmek

İlgisiz redirect kullanıcı niyetini karşılamaz. Gerçekten silinen URL 404 kalabilir. Eşdeğer yeni içerik varsa 301 kullanılır. Mapping sayfa bağlamına göre yapılmalıdır. Homepage varsayılan çöp hedef olmamalıdır.

Dizine Eklemeyi İste Düğmesine Sürekli Basmak

Tekrarlı request kök nedeni çözmez. Crawled not indexed sayfa kalite veya duplicate problemi taşıyabilir. noindex URL de request ile indekslenmez. Önce teknik debug yapılmalıdır. Manuel istek yalnız yardımcı araçtır.

Sitemap'i URL Çöplüğüne Dönüştürmek

Sitemap yalnız preferred index URL'lerini taşımalıdır. Redirect, 404 ve noindex adresler çıkarılmalıdır. Generator publication ve canonical bilgisini kullanmalıdır. Quality rate ölçülmelidir. Temiz sitemap Search Console analizini kolaylaştırır.

Canonical Çakışmalarını Kontrol Etmemek

Canonical tag doğru görünse bile diğer sinyaller farklı olabilir. Sitemap ve internal links ayrıca kontrol edilir. Google-selected canonical sample alınır. URL normalization policy merkezi olmalıdır. Migration sonrasında özel audit yapılmalıdır.

JavaScript Render'ı Test Etmemek

Tarayıcıda çalışan sayfa Google render'ında eksik olabilir. Source ve rendered HTML karşılaştırılmalıdır. API resource hataları incelenir. Client-side canonical değişikliği risklidir. Critical content server rendering ile daha güvenilir hale getirilebilir.

Search Console Verisini Tek Başına Kullanmak

Search Console bütün site gerçeğini göstermez. Crawler, log ve CMS verisi gerekir. URL examples tam envanter değildir. Kapsam başka kaynaklarla ölçülmelidir. Teşhis çoklu veri modeline dayanmalıdır.

URL'leri Tek Tek Düzeltmek

Bin URL aynı template hatasını taşıyorsa tek tek fix verimsizdir. Pattern belirlenmelidir. Code veya data layer root cause düzeltilir. Regression test bütün sınıfı korur. Sampling fix'in kapsamını doğrular.

Deployment Sonrası Kontrol Yapmamak

Staging test tek başına yeterli değildir. Production config farklı olabilir. robots, canonical ve sitemap smoke test yapılmalıdır. Critical template sample kontrol edilir. Incident detection süresi böylece kısalır.

Başarılı Bir İndeksleme Yönetim Sisteminin 10 İlkesi

İyi indeksleme yönetimi her URL'yi Google indeksine sokmaya çalışmaz. Crawl ve index arasındaki fark anlaşılır, Search Console mesajı kök neden yerine başlangıç verisi olarak görülür ve URL pattern'leri analiz edilir. Sitemap yalnız tercih edilen URL'leri taşır ve canonical sinyalleri aynı hedefte birleşir. Kritik template'ler otomatik test edilir ve indexation KPI'ları düzenli ölçülür. SEO ile engineering ekipleri aynı incident ve release sürecinin parçası olduğunda sorunlar daha erken bulunur.

1. Her URL'nin Indexlenmesi Gerekmez

Utility ve duplicate URL'ler indeks dışı kalabilir. Index policy bunu açıkça tanımlamalıdır. Başarı toplam indexed sayısıyla ölçülmez. Organik landing page seti temel alınır. Expected exclusions ayrı izlenir.

2. Crawl ve Index Aynı Şey Değildir

Taranan sayfa indekslenmeyebilir. İndekslenen URL sıralamada görünmeyebilir. Her aşama farklı teşhis gerektirir. Search Console statüsü doğru katmanda yorumlanmalıdır. Debug sırası bu ayrımı izlemelidir.

3. Search Console Mesajı Kök Neden Değildir

Reason kategorisi başlangıç sinyalidir. Crawled not indexed birçok farklı nedenden oluşabilir. Crawler ve canonical verisi eklenmelidir. İçerik değerlendirmesi gerekebilir. Tek mesaj üzerinden kesin hüküm verilmemelidir.

4. URL Yerine Pattern Analiz Edilmelidir

Büyük sitelerde tekil URL düzeltmesi ölçeklenmez. Path ve template segmentleri çıkarılır. Root cause shared code'da aranır. Fix bütün pattern'e uygulanır. Sampling sonuç doğrulaması için kullanılır.

5. Sitemap Yalnız Tercih Edilen URL'leri İçermelidir

200, indexable ve canonical URL temel kriterdir. Redirect ve 404 adresler çıkarılır. noindex sitemap'e girmez. Generator merkezi index policy kullanır. Quality audit düzenli çalışır.

6. Canonical Sinyalleri Tutarlı Olmalıdır

HTML canonical tek başına yeterli değildir. Internal links ve sitemap aynı URL'yi desteklemelidir. Redirect final target tutarlı olmalıdır. URL normalization bir standarda bağlanır. Google-selected canonical örneklenir.

7. Manuel Index Talebi Kök Nedenin Yerini Alamaz

Request indexing yardımcı araçtır. Teknik problem devam ediyorsa sonuç değişmez. Büyük URL gruplarında sitemap kullanılmalıdır. Recrawl ile index selection ayrıdır. Root cause fix önceliklidir.

8. Kritik Template'ler Otomatik Test Edilmelidir

Product ve category template'leri regression test alabilir. Status, canonical ve noindex assertion yazılabilir. Rendering testleri gerektiğinde eklenir. CI hatalı release'i durdurabilir. Production smoke test ikinci koruma katmanıdır.

9. Indexation Ölçülmelidir

Expected ve actual indexed sayılar izlenir. Coverage ratio template bazında tutulur. Time-to-index cohort analizi eklenebilir. Canonical mismatch ayrıca ölçülür. KPI trends teknik backlog'u yönlendirir.

10. SEO ve Yazılım Ekipleri Aynı Süreci Yönetmelidir

SEO expected behaviour tanımlar. Developer implementation yapar. DevOps server ve log tarafını destekler. Product URL üretim politikasına katkı verir. Ortak Definition of Done kalıcı çözüm sağlar.

Sonuç - Search Console'da Amaç Bütün Hataları Sıfırlamak Değil, Doğru URL'lerin İndekslenmesini Sağlamaktır

İndeksleme Hatalarını Tespit Etme ve Search Console Yönetimi çalışmasının gerçek hedefi panelde sıfır uyarı görmek değildir. Redirect, duplicate ve bilinçli noindex URL'ler doğal olarak indeks dışında bulunabilir. Başarı, kullanıcı ve organik arama için değerli canonical URL'lerin keşfedilmesi, taranması ve indekslenmesiyle ölçülmelidir. Search Console teşhisin başlangıç noktasıdır fakat crawler, sitemap, log ve CMS verisiyle birlikte okunmalıdır. Bu yaklaşım teknik SEO'yu tekil hata düzeltme işinden çıkarıp ölçülebilir bir web platformu sürecine dönüştürür.

Her Hariç Tutma Problem Değildir

Önce URL'nin indeks hedefi belirlenmelidir. Expected exclusions rapordan ayrılır. Kritik landing page dışarıdaysa analiz başlar. Bilinçli noindex için gereksiz fix yapılmaz. Monitoring davranış değişikliğini takip eder.

Önce Indexlenmesi Gereken URL Seti Tanımlanmalıdır

Expected Indexation Model temel veri kaynağıdır. CMS ve index policy bu seti üretir. Sitemap mümkün olduğunca aynı listeyi temsil eder. Coverage oranı bu hedef üzerinden hesaplanır. Böylece yanlış KPI'lar önlenir.

Search Console Teşhisin Başlangıç Noktasıdır

Reason kategorileri problem alanını daraltır. URL Inspection tekil örneklerde ayrıntı sağlar. Bununla birlikte root cause için başka veri gerekir. Crawler ve server log tamamlayıcıdır. Ekip yalnız panel mesajına göre değişiklik yapmamalıdır.

Crawler, Sitemap, Log ve Canonical Sinyalleri Birlikte Okunmalıdır

Crawler site mimarisini gösterir. Sitemap preferred URL setini anlatır. Log gerçek bot crawl davranışını sunar. Canonical URL kümelerinin temsilcisini tanımlar. Bu kaynaklar birleştiğinde teknik neden daha net görünür.

Teknik Problemler Template Seviyesinde Çözülmelidir

Binlerce benzer URL tek tek düzeltilmemelidir. Etkilenen template bulunur. Code veya data source root cause değiştirilir. Regression test aynı problemi geri dönmekten korur. Production sample fix'i doğrular.

Başarı Index Coverage ve Time-to-Index Gibi KPI'larla Ölçülmelidir

Toplam index sayısı tek başına yeterli değildir. Expected target set ile gerçek indexed set karşılaştırılır. Template coverage farkları görülür. Time-to-index yeni içeriklerin hızını ölçer. Trendler teknik iyileştirmelerin sonucunu gösterir.

Sıkça Sorulan Sorular

Search Console'daki indeksleme durumları teknik kavramlar birbirine karıştırıldığında gereğinden zor görünebilir. En önemli ayrım discovery, crawl, indexability ve index selection aşamalarını ayrı değerlendirmektir. Sitemap ve indexing request keşif sürecine yardımcı olabilir fakat indeks garantisi sağlamaz. Robots.txt crawl kontrolü, noindex ise indeksleme direktifi olarak farklı rollere sahiptir. Aşağıdaki kısa yanıtlar İndeksleme Hatalarını Tespit Etme ve Search Console Yönetimi sürecinde en sık karşılaşılan sorular için pratik bir referans sunar.

Google Search Console nedir?

Search Console Google Search ile siteniz arasındaki teknik ve performans verilerini görmenize yardımcı olan platformdur. Page Indexing, URL Inspection ve Sitemap raporları teknik SEO için özellikle değerlidir. Performans verileri organik sorgu ve landing page görünürlüğünü gösterir. Araç web sitenizi sizin yerinize düzeltmez. Veriyi doğru yorumlamak site mimarisini bilmenizi gerektirir.

Search Console'da indeksleme hataları nerede görülür?

Toplu görünüm için Sayfa Dizine Ekleme raporu kullanılabilir. Belirli URL için URL Denetleme aracı daha uygundur. Sitemap sorunları ayrı raporda görülür. Crawl davranışı Tarama İstatistikleriyle desteklenebilir. Her non-indexed durumun hata olmadığını unutmamak gerekir.

Sayfa dizine ekleme raporu nedir?

Rapor Google'ın bildiği URL'lerin indeks durumunu toplu olarak gösterir. Indexed ve not indexed grupları bulunur. İndekslenmeyen URL'ler nedenlere göre ayrılır. URL örnekleri pattern analizi için kullanılabilir. Tekil URL debug için URL Inspection tercih edilir.

URL Denetleme aracı nasıl kullanılır?

Property içinde tam URL girilir. Current Google Index durumuna bakılır. Gerekirse canlı test çalıştırılır. Canonical, indexability ve crawl bilgileri incelenir. Teknik fix sonrası birkaç kritik URL için indexing request kullanılabilir.

Google sayfamı neden indekslemiyor?

Neden discovery, crawl, HTTP, rendering, noindex, canonical veya index selection katmanlarından biri olabilir. Önce URL'nin gerçekten indekslenmesi gerekip gerekmediği kontrol edilir. Ardından yedi katmanlı debug sırası uygulanır. Tek bir Search Console mesajı bütün cevabı vermeyebilir. Crawler ve server log gerektiğinde analize eklenmelidir.

Keşfedildi - şu anda dizine eklenmiş değil ne demektir?

Google URL'yi biliyor fakat henüz taramamış demektir. Yeni URL'de geçici durum olabilir. Toplu problemde internal linking, sitemap ve URL explosion incelenir. Server capacity ve crawl pattern değerlendirilir. İndeks request'i tek başına kalıcı çözüm değildir.

Tarandı - şu anda dizine eklenmiş değil ne demektir?

Google sayfayı taramış ancak şu anda indeks için seçmemiştir. Duplicate, thin veya near-duplicate içerik incelenebilir. Canonical ve internal value sinyalleri kontrol edilir. Durum her zaman kod hatası değildir. Aynı template'teki indeksli ve indeks dışı URL'ler karşılaştırılmalıdır.

Robots.txt tarafından engellendi hatası nasıl çözülür?

Önce block bilinçli mi kontrol edilir. Kritik landing page yanlışlıkla engelliyse robots pattern düzeltilir. Sitemap aynı URL'yi gösteriyorsa çakışma temizlenir. Live URL test ile erişim doğrulanır. Büyük pattern değişikliği production sonrası smoke test edilmelidir.

Robots.txt indekslemeyi engeller mi?

Robots.txt temel olarak crawling kontrol eder. noindex ile aynı değildir. Crawler sayfaya ulaşamazsa meta noindex'i okuyamayabilir. İndeks dışı tutma için iş amacına uygun yöntem seçilmelidir. Gizlilik için erişim kontrolü kullanılmalıdır.

Noindex tarafından hariç tutuldu ne demektir?

Google sayfada noindex direktifi görmüştür. Bilinçli ise sorun değildir. İndekslenmesi gereken URL'de yanlış noindex varsa kaldırılmalıdır. Meta robots ve X-Robots-Tag birlikte kontrol edilir. Düzeltmeden sonra canlı test yapılabilir.

Noindex ile robots.txt arasındaki fark nedir?

Noindex sayfanın indekslenmemesini ister. Robots.txt crawler'ın URL'yi taramasını kontrol eder. İki araç farklı katmanda çalışır. Yanlış kombinasyon noindex'in görülmesini engelleyebilir. Index policy her URL grubu için hangi yöntemin kullanılacağını açıklamalıdır.

Soft 404 nedir?

Soft 404 sayfa 200 dönmesine rağmen bulunamayan veya çok zayıf bir sonuç sunması durumudur. Boş ürün sayfası tipik örnektir. Gerçekten olmayan içerikte doğru 404 kullanılmalıdır. Mevcut sayfa yeterli kullanıcı değeri sunmalıdır. Rendered HTML kontrolü teşhise yardımcı olur.

Search Console 404 hataları düzeltilmeli midir?

Her 404 düzeltilmek zorunda değildir. Gerçekten kaldırılmış URL normal olarak 404 kalabilir. Sitemap veya internal links adresi gösteriyorsa bu kaynaklar temizlenmelidir. Taşınmış içerik varsa 301 kullanılabilir. İlgisiz ana sayfaya toplu redirect yapılmamalıdır.

5xx hataları Google indeksini etkiler mi?

Sürekli 5xx Googlebot'un sayfayı güvenilir biçimde almasını engeller. Geniş kapsamlı sorun crawl davranışını etkileyebilir. Server log ve Crawl Stats birlikte incelenmelidir. DevOps root cause'u çözmelidir. Düzeltme sonrası kritik URL'ler yeniden test edilir.

Canonical URL nedir?

Canonical aynı veya benzer URL grubundaki tercih edilen temsilci adrestir. Site sahibi tercih bildirir. Google yine kendi canonical seçimini yapabilir. Sitemap ve internal links declared canonical'ı desteklemelidir. Non-canonical duplicate'ların ayrı indekslenmesi çoğu zaman gerekmez.

Google neden benim belirlediğim canonical'dan farklı bir URL seçiyor?

Sinyaller birbirine uymuyor olabilir. Internal links başka URL'yi destekleyebilir. Sitemap alternate sürümü içeriyor olabilir. İçerik çok benzer veya redirect davranışı farklı olabilir. Canonical conflict matrix bütün sinyalleri birlikte gösterir.

Sitemap indekslemeyi garanti eder mi?

Hayır, sitemap URL discovery için yardımcıdır. URL'nin crawl edilmesini veya indekslenmesini garanti etmez. Sayfa indexable ve canonical olmalıdır. İçerik de indeks için seçilmelidir. Sitemap kalite envanteri olarak yönetilmelidir.

XML sitemap'te hangi URL'ler bulunmalıdır?

200 dönen preferred canonical URL'ler bulunmalıdır. Sayfalar indexable olmalıdır. Redirect ve 404 URL'ler dosyada tutulmamalıdır. noindex sayfalar çıkarılmalıdır. Sitemap generator index policy ile aynı veri kaynağını kullanmalıdır.

Dizine eklemeyi iste düğmesi indekslemeyi hızlandırır mı?

İstek Google'dan URL'yi yeniden taramasını istemenize yardımcı olabilir. Ancak indeks garantisi vermez. Kritik birkaç URL'de kullanılabilir. Binlerce sayfa için sitemap tercih edilmelidir. Kök neden düzeltilmeden request göndermek fayda sağlamaz.

Aynı URL için tekrar tekrar index talebi göndermek gerekir mi?

Hayır, sürekli tekrar gerekli değildir. Sayfa indekslenmiyorsa reason analiz edilmelidir. noindex veya canonical problemi önce çözülür. Crawled not indexed durumda içerik ve duplicate analizi gerekebilir. Manuel request sistemik çözüm değildir.

Düzeltmeyi doğrula ne işe yarar?

Search Console'un belirli issue grubundaki düzeltmeyi yeniden değerlendirmesini başlatır. Kodunuzu değiştirmez. noindex veya canonical sorununu kendi başına çözmez. Önce production fix tamamlanmalıdır. Validation sonucu daha sonra takip edilir.

Search Console verileri ne kadar sık kontrol edilmelidir?

Küçük ve stabil sitelerde aylık kontrol yeterli olabilir. Büyük veya sık deployment yapan sitelerde haftalık rutin daha uygundur. Kritik migration döneminde daha sık monitoring gerekebilir. Alert sistemi ani değişimleri yakalayabilir. Kontrol sıklığı site riskine göre belirlenmelidir.

JavaScript sitelerde indeksleme sorunu nasıl tespit edilir?

Source HTML ve rendered HTML karşılaştırılır. Ana içerik ve links render sonucunda var mı kontrol edilir. API hataları incelenir. URL Inspection Live Test kullanılabilir. Server-side veya static rendering seçenekleri kritik içerikte değerlendirilebilir.

E-ticaret sitelerinde index bloat nasıl önlenir?

Filtre ve parametre URL üretimi kontrol edilmelidir. Search demand taşıyan facet'ler bilinçli seçilir. Utility URL'ler uygun canonical veya noindex politikasıyla yönetilir. Sitemap yalnız preferred landing page'leri içerir. Log ve Search Console pattern analizi düzenli yapılır.

Orphan page nedir ve nasıl bulunur?

Orphan page site içinden link almayan URL'dir. Sitemap veya Analytics'te bulunabilir. Crawler URL'yi normal link graph içinde keşfedemez. Veri kaynakları karşılaştırılarak adaylar bulunur. Değerli sayfa uygun internal linking yapısına eklenir.

Server log ile indeks sorunları nasıl analiz edilir?

Googlebot istekleri doğrulanarak logdan ayrılır. Crawl frequency, status ve response time ölçülür. URL pattern bazında gruplama yapılır. Search Console reason gruplarıyla karşılaştırılır. Büyük sitelerde crawl waste böylece somutlaşır.

Index coverage ratio nedir?

İndekslenmesi beklenen hedef URL'lerin ne kadarının gerçekten indekslendiğini ölçer. Bilinçli noindex sayfalar paydaya eklenmez. Template bazında hesaplamak daha değerlidir. Trend zaman içinde izlenir. Ani düşüş teknik incident gösterebilir.

Time-to-index nasıl ölçülür?

Publish tarihi başlangıç noktasıdır. İlk crawl tarihi kaydedilebilir. İlk indexed tarih ile fark hesaplanır. Median ve yüksek percentile değerleri izlenebilir. Template cohort'ları karşılaştırılabilir.

Open source araçlarla indeksleme audit'i yapılabilir mi?

Evet, crawler, sitemap parser ve canonical validator geliştirilebilir. Log parser gerçek bot isteklerini analiz edebilir. CI regression testleri eklenebilir. Güvenli crawl ve rate limit kurallarına uyulmalıdır. Açık kaynak proje eğitim için de değerlidir.

Teknik SEO için hangi programlama dili öğrenilmelidir?

Tek bir zorunlu dil yoktur. Python veri ve log analizi için kullanışlıdır. JavaScript veya TypeScript rendering ve web otomasyonunda yararlı olabilir. Go yüksek hacimli ağ ve log işlerinde tercih edilebilir. Dilden daha önemli konu HTTP ve web mimarisini anlamaktır.

Yazılımcılar Search Console kullanmalı mı?

Evet, özellikle web platformu geliştiren ekipler için faydalıdır. Canonical, robots ve rendering değişikliklerinin Google tarafındaki sonucunu görürler. SEO ticket'larını daha iyi anlayabilirler. Deployment sonrası regression monitoring'e katkı sağlarlar. Search Console yalnız SEO ekibinin kapalı aracı olmamalıdır.

Diyarbakır'daki yazılımcılar teknik SEO projelerine nasıl katkı sağlayabilir?

Crawler, sitemap validator ve log analyzer gibi açık kaynak araçlar geliştirilebilir. Teknik workshop'larda HTTP ve Search Console örnekleri üzerinde çalışılabilir. Mevcut topluluk projelerine https://www.diyarbakiryazilim.com.tr/projects adresinden göz atılabilir. Topluluğun yapısı hakkında https://www.diyarbakiryazilim.com.tr/about üzerinden bilgi alınabilir. Gerçek projelerde çalışırken izin, veri güvenliği ve sistem yükü kurallarına uyulmalıdır.

Ek Sık Sorulan Sorular

İndeksleme problemleri çoğu zaman birbirine benzeyen Search Console mesajlarından başlasa da çözüm URL'nin gerçek teknik durumuna göre değişir. Google Search Console indeksleme hataları nasıl tespit edilir sorusunda tek bir buton veya rapor yeterli değildir. Search Console sayfa dizine ekleme sorunları nasıl düzeltilir sorusunun cevabı çoğunlukla URL pattern, template ve expected index model üzerinden bulunur. Search Console ve indeksleme sorunu danışmanlığı yakınımda şeklinde destek arayan ekiplerin de yalnız rapor ekranına değil URL mimarisi ve deployment süreçlerine odaklanması yararlıdır. Aşağıdaki beş soru karar sürecinin kısa özetini sunar.

Google Search Console’da indeksleme hataları nasıl tespit edilir?

Önce Sayfa Dizine Ekleme raporunda hangi reason grubunun arttığı kontrol edilir. Etkilenen örnek URL'ler template veya URL pattern'e göre sınıflandırılır. Ardından URL Denetleme aracında current index ve live test sonuçları incelenir. Crawler ile status, robots ve canonical verisi karşılaştırılır. Sorun tekil değilse fix URL seviyesinde değil ortak template veya veri kaynağında yapılır.

“Tarandı ancak şu anda dizine eklenmedi” ve “Keşfedildi ancak şu anda dizine eklenmedi” sorunları nasıl çözülür?

Keşfedildi durumunda Google URL'yi biliyor fakat henüz crawl etmemiştir. Internal linking, sitemap, URL explosion ve server kapasitesi değerlendirilir. Tarandı durumunda sayfa alınmış fakat indeks için seçilmemiştir. Bu kez duplicate, canonical, thin content, soft 404 ve site value sinyalleri daha önemlidir. İki statüye aynı çözümü uygulamak doğru değildir.

URL Denetleme aracı ile bir sayfanın indeks durumu nasıl kontrol edilir ve yeniden indeksleme nasıl istenir?

Search Console property içinde tam URL URL Denetleme alanına girilir. Önce Google'ın mevcut indeks verisi ve canonical bilgisi incelenir. Gerekirse Canlı URL Testi çalıştırılarak güncel teknik durum doğrulanır. Düzeltme tamamlandıysa birkaç kritik URL için “Dizine Eklemeyi İste” kullanılabilir. Bu talep yeniden crawl sürecine yardımcı olur fakat indeks garantisi sağlamaz.

robots.txt, noindex, canonical, yönlendirme ve sunucu hataları indekslemeyi nasıl etkiler?

Robots.txt crawling'i kontrol ederken noindex sayfanın indekslenmemesini ister. Canonical duplicate URL kümesindeki tercih edilen temsilciyi bildirir. Redirect eski veya alternatif URL'yi başka hedefe taşır. 5xx hataları Googlebot'un içeriği güvenilir biçimde almasını engelleyebilir. Bu sinyaller birbirinden bağımsız düşünülmemeli ve sitemap ile internal links aynı URL politikasını desteklemelidir.

Search Console indeksleme hataları analizi ve teknik SEO danışmanlığını yakınımda nerede bulabilirim?

Teknik SEO desteği alırken yalnız Search Console ekranının yorumlanmasına değil crawler, sitemap, canonical, rendering ve log analizine birlikte bakılmasına dikkat etmek yararlıdır. Diyarbakır ve çevresinde yazılım topluluğu çalışmalarıyla ilgileniyorsanız Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilirsiniz. Teknik ve açık kaynak proje örnekleri için https://www.diyarbakiryazilim.com.tr/projects sayfası incelenebilir. Yapılandırılmış veri ve arama görünümü çalışmalarına dair ilgili teknik içerik https://www.diyarbakiryazilim.com.tr/posts/zengin-sonuclar-rich-snippets-icin-yapilandirilmis-veri-testleri adresinde bulunur. İndeksleme Hatalarını Tespit Etme ve Search Console Yönetimi konusunda sürdürülebilir sonuç için en iyi yaklaşım, problemi tek URL yerine sistem ve template seviyesinde ele almaktır.

Sonuç ve Çağrı

İndeksleme problemlerinde en güçlü alışkanlık, Search Console mesajını gördüğünüz anda rastgele değişiklik yapmak yerine sorunu doğru katmana yerleştirmektir. Discovery, crawling, HTTP, rendering, indexability, canonicalization ve index selection sırası büyük problemlerde dahi teşhisi sadeleştirir. Sitemap, crawler, log ve CMS verileri aynı modele bağlandığında hangi URL'nin neden indeks dışı kaldığı çok daha hızlı anlaşılır. Diyarbakır Yazılım Topluluğu'nun teknik çalışmalarını, projelerini ve web geliştirme odaklı içeriklerini takip etmek için https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz. Teknik SEO'yu yalnız rapor okuma işi değil, ölçülebilir ve test edilebilir bir web mühendisliği süreci olarak ele aldığınızda indeksleme sorunlarını düzeltmek kadar tekrar oluşmalarını önlemek de mümkün hale gelir.