Sitemap'te Sadece 200 OK URL Kullanımı

Sitemap hijyeni, XML sitemap dosyasında yalnızca HTTP 200 durum kodu döndüren, indekslenebilir ve kanonik URL'lerin bulundurulması disiplinidir. 2026 verilerine göre sitemap'inde %20'den fazla non-200 URL barındıran siteler, Googlebot'un ortalama tarama verimliliğini %35 oranında düşürmektedir. Bu kaybı önlemenin ilk adımı, sitemap dosyasının bir "istek listesi" değil, "garanti edilmiş envanter" olarak yönetilmesidir.

HTTP Durum Kodlarının Sitemap Bağlamındaki Anlamı

HTTP durum kodları, sunucunun bir URL isteğine verdiği yanıtın kategorisini belirler. 200 kodu, sayfanın başarıyla sunulduğunu ifade eder. 301 ve 302 kodları yönlendirme, 404 bulunamadı, 410 kalıcı olarak kaldırıldı, 500 ise sunucu hatasını bildirir. Sitemap dosyası botlara "bu URL'leri tara" emri verdiğine göre, bu emirlerin karşılığında bot 200 dışında bir yanıt alırsa, tarama bütçesi boşa harcanmış olur.

Bu durum, yalnızca teknik bir israf değildir. Bot, sitemap'te listelenen URL'lerin tamamını güvenilir kabul ederek tarama kuyruğuna alır. Kuyruktaki her non-200 URL, 200 döndürecek bir başka sayfanın taranma şansını çalar. Dolayısıyla sitemap kirliliği, doğrudan fırsat maliyeti yaratır.

301 Yönlendirmesi İçeren URL'lerin Sitemap'teki Etkisi

Sitemap'te 301 yönlendirmesi döndüren bir URL bulunması, botun o URL için iki istek harcamasına neden olur. İlk istek 301 yanıtını alır, ikinci istek hedef URL'ye yönlendirilir. Bot her iki isteği de tarama bütçesinden düşer. Eğer hedef URL zaten sitemap'te ayrıca listeleniyorsa, aynı sayfa için toplamda üç istek harcanmış olur.

Bu senaryoyu somutlaştırmak gerekirse: /eski-sayfa URL'si /yeni-sayfa adresine 301 ile yönlendirilmiş olsun. Sitemap'te hem /eski-sayfa hem /yeni-sayfa varsa, bot /eski-sayfa için bir istek gönderir, 301 alır, /yeni-sayfaya yönlendirilir ve orayı tarar. Ardından sitemap'teki sırası geldiğinde /yeni-sayfa için tekrar istek gönderir. Çözüm açıktır: sitemap'te yalnızca /yeni-sayfa kalmalı, /eski-sayfa derhal çıkarılmalıdır.

302 Geçici Yönlendirmelerinin Yarattığı İndeksleme Kararsızlığı

302 durum kodu, geçici bir yönlendirmeyi ifade eder. Bot, 302 ile karşılaştığında kaynak URL'yi indekste tutmaya devam edebilir; çünkü yönlendirmenin geçici olduğunu varsayar. Sitemap'te 302 döndüren bir URL'nin bulunması, botu "bu URL'yi indekslemeli miyim, yoksa hedefi mi?" ikilemine sokar.

Bu kararsızlık, Search Console'da "Sayfaya yönlendirme ile ulaşıldı" veya "Alternate page with proper canonical tag" uyarıları olarak tezahür eder. Kalıcı olması gereken yönlendirmeler 301'e dönüştürülmeli, gerçekten geçici olan yönlendirmeler ise sitemap'ten tamamen çıkarılmalıdır. Sitemap'te geçici yönlendirme barındırmanın hiçbir senaryoda teknik gerekçesi yoktur.

404 Hata Döndüren URL'lerin Sitemap'te Kalma Maliyeti

404 durum kodu, istenen sayfanın sunucuda bulunmadığını bildirir. Sitemap'te 404 döndüren URL'lerin varlığı, botun en verimsiz senaryolarından birini oluşturur. Bot bu URL'ye istek gönderir, 404 alır, hiçbir içerik indeksleyemez ve tarama bütçesinden bir istek düşer. Search Console bu durumu "Bulunamadı (404)" hatası olarak raporlar ve sitemap kaynaklı sorunları ayrıca işaretler.

Silinen bir sayfanın sitemap'ten çıkarılması, CMS yapılandırmasına bağlı olarak otomatik veya manuel gerçekleşir. WordPress'te Yoast SEO ve Rank Math eklentileri, bir sayfa çöp kutusuna taşındığında veya kalıcı olarak silindiğinde sitemap'i otomatik günceller. Özel CMS'lerde ise silme işlemi sitemap oluşturma sürecine bağlanmamışsa, 404 döndüren URL'ler sitemap'te aylarca kalabilir. Bu nedenle CMS'in silme hook'unda sitemap yeniden oluşturma fonksiyonunu tetiklemek zorunludur.

410 Gone Kodu ve Sitemap'ten Kalıcı Çıkarma Sinyali

410 durum kodu, sayfanın kalıcı olarak kaldırıldığını ve geri gelmeyeceğini bildirir. 404'ten farkı, botun o URL'yi tarama kuyruğundan kalıcı olarak çıkarması için daha güçlü bir sinyal vermesidir. 404 gören bot, URL'yi bir süre sonra tekrar deneyebilir. 410 gören bot ise o URL'yi daha hızlı terk eder.

Sitemap'te 410 döndüren URL'lerin bulunması, 404'ten daha çelişkili bir durumdur. Sitemap dosyası "bu URL'yi tara" derken, sunucu "bu URL kalıcı olarak yok" yanıtı verir. Bu çelişki, botun sitemap dosyasının güvenilirliğine dair genel değerlendirmesini olumsuz etkiler. Stoktan kalıcı olarak kaldırılan ürünler, kapatılan kampanya sayfaları ve birleştirilen kategoriler bu durumun en yaygın kaynağıdır.

Soft 404 Hatalarının Tespiti ve Sitemap Etkisi

Soft 404, sunucunun 200 durum kodu döndürdüğü ancak sayfa içeriğinin fiilen "bulunamadı" mesajı taşıdığı durumdur. Bot, HTTP yanıtına bakarak sayfanın başarıyla sunulduğunu düşünür, ancak içeriği analiz ettiğinde bunun bir hata sayfası olduğunu anlar. Search Console bu sayfaları "Soft 404" olarak raporlar.

Bu durum sitemap hijyeni açısından özellikle tehlikelidir; çünkü HTTP durum kodu kontrolüne dayalı filtreleme mekanizmaları soft 404'ü yakalayamaz. URL, teknik olarak 200 döndürdüğü için sitemap'te kalmaya devam eder. Soft 404 tespiti, yalnızca HTTP kodu kontrolüyle değil, içerik analizi ile yapılmalıdır. Screaming Frog'da "Content" sekmesindeki "Word Count" sütununu kullanarak 50 kelimenin altındaki sayfaları filtrelemek, soft 404 adaylarını tespit etmenin en pratik ilk adımıdır.

Noindex Etiketli Sayfaların Sitemap'teki Çelişkisi

Meta robots noindex etiketi, bota "bu sayfayı indeksleme" emri verir. Sitemap dosyası ise "bu sayfayı tara ve indeksle" mesajı taşır. Aynı URL için bu iki sinyalin bir arada bulunması doğrudan çelişkidir. Google bu senaryoda genellikle noindex sinyalini öncelikli kabul eder, ancak bot yine de sayfayı tarar, noindex etiketini okur ve indekslemez. Tarama bütçesi harcanmış olur, indeksleme gerçekleşmez.

Çözüm nettir: noindex etiketi taşıyan hiçbir URL sitemap dosyasında yer almamalıdır. WordPress eklentileri bu filtrelemeyi otomatik yapar, ancak özel CMS'lerde sitemap oluşturma scriptine <meta name="robots" content="noindex"> kontrolü eklenmesi gerekir. Sayfanın HTTP yanıt header'larında X-Robots-Tag: noindex kullanılıyorsa, bu kontrolün header seviyesinde de yapılması zorunludur.

Canonical Etiketi Farklı URL'ye İşaret Eden Sayfalar

Bir sayfanın canonical etiketi kendi URL'si yerine başka bir URL'ye işaret ediyorsa, o sayfa kanonik değildir. Bot, bu sayfayı tarasa bile canonical hedefi indeksler, kaynağı indekslemez. Sitemap'te kanonik olmayan URL'lerin bulunması, botun gereksiz tarama yapmasına ve canonical çözümleme sürecine ek yük binmesine neden olur.

Özellikle e-ticaret sitelerinde ürün varyasyonları (renk, beden) ayrı URL'lere sahip olup canonical etiketleri ana ürün sayfasına işaret eder. Bu varyasyon URL'lerinin tamamını sitemap'e eklemek yaygın bir hatadır. Sitemap'te yalnızca canonical etiketi kendi URL'sine (self-referencing canonical) işaret eden sayfalar bulunmalıdır. Bu kontrol, sitemap oluşturma sürecinde her URL'nin canonical değerinin sorgulanmasıyla sağlanır.

Robots.txt ile Engellenen URL'lerin Sitemap Paradoksu

Robots.txt dosyasında Disallow kuralıyla engellenen bir URL'nin sitemap'te yer alması, teknik SEO'nun en paradoksal senaryolarından biridir. Sitemap "tara" der, robots.txt "tarama" der. Bot bu durumda genellikle robots.txt'yi öncelikli kabul eder ve sayfayı taramaz. Ancak Search Console'da "Robots.txt tarafından engellendi" uyarısı üretilir.

Bu çelişki, botun sitemap dosyasına olan güvenini aşındırır. Daha da kötüsü, bot sayfayı taramasa bile URL'yi keşfeder ve harici linkler aracılığıyla snippet olmadan indeksleyebilir. Dolayısıyla indekslenmesini istemediğiniz sayfalar için robots.txt engeli tek başına yeterli değildir; noindex etiketi kullanılmalı ve URL sitemap'ten çıkarılmalıdır. Bu üçlü tutarlılık (robots.txt izni, noindex yokluğu, sitemap'te bulunma) sağlıklı bir sitemap'in temel koşuludur.

Parametre Bazlı Duplicate URL'lerin Sitemap Kirliliği

Sıralama, filtreleme, session ID ve izleme parametreleri içeren URL'ler, ana sayfanın teknik kopyalarıdır. /urunler?sort=price, /urunler?color=red&size=m, /urunler?sessionid=abc123 gibi URL'lerin her biri bot için ayrı bir sayfa olarak görünür. Bu URL'lerin sitemap'e dahil edilmesi, botun aynı içeriği onlarca kez taramasına neden olur.

E-ticaret sitelerinde filtre kombinasyonlarının oluşturduğu URL çeşitliliği, gerçek ürün sayısının yüzlerce katına ulaşabilir. 5.000 ürünlük bir katalog, filtre parametreleriyle 500.000 benzersiz URL üretebilir. Bu URL'lerin sitemap'e sızması, dosyanın boyutunu ve bot üzerindeki yükü kontrol edilemez hale getirir. Sitemap oluşturma sürecinde URL query string'lerini parse edip, yalnızca parametresiz (clean) URL'leri dahil etmek, bu kirliliğin en temel çözümüdür.

Pagination URL'lerinin Sitemap Stratejisi

Sayfalama (pagination) URL'leri (/blog/page/2/, /kategori/page/3/) sitemap yönetiminde sıklıkla yanlış değerlendirilen bir alandır. Bu sayfaların sitemap'e dahil edilip edilmeyeceği, site mimarisine göre değişir. Eğer sayfalama sayfaları benzersiz içerik barındırıyorsa (her sayfada farklı ürünler veya yazılar) ve canonical etiketleri kendi URL'lerine işaret ediyorsa, teknik olarak sitemap'te yer alabilirler.

Ancak pratikte sayfalama sayfalarının bireysel olarak indekslenmesi nadiren değer üretir. Kullanıcılar arama sonuçlarından /blog/page/7/ adresine gelmek istemez. Dolayısıyla önerilen yaklaşım, sayfalama URL'lerini sitemap'ten çıkarmak ve her bir içerik parçasını (blog yazısı, ürün) kendi bireysel URL'siyle sitemap'te listelemektir. Böylece bot, sayfalama ara yüzünü taramak yerine doğrudan hedef içeriklere ulaşır.

Tag ve Taksonomi Sayfalarının Sitemap Değerlendirmesi

WordPress ve benzeri CMS'lerde tag sayfaları, yazar arşivleri ve tarih bazlı arşivler otomatik olarak oluşturulur. Bu sayfaların büyük çoğunluğu ince içerik barındırır; yalnızca başlık listesi ve kısa açıklamalardan oluşur. Benzersiz değer üretmeyen bu sayfaların sitemap'te yer alması, botun dikkatini gerçek içerik sayfalarından uzaklaştırır.

LinkedIn üzerindeki SEO mühendislik topluluklarında paylaşılan site denetim raporları gösteriyor ki, WordPress sitelerinde sitemap URL'lerinin ortalama %25-30'u tag, yazar ve tarih arşivi sayfalarından oluşuyor. Bu sayfaları sitemap'ten çıkarmak, botun tarama enerjisini yüksek değerli sayfalara yönlendirmenin en hızlı yoludur. Yoast SEO'da SEO > Görünüm > Taksonomiler yolundan tag ve format arşivlerini "Arama sonuçlarında göster: Hayır" olarak ayarlamak, hem noindex hem de sitemap'ten çıkarma işlemini otomatik gerçekleştirir.

Hreflang Kaynaklı Sitemap Şişkinliği ve Kontrol Mekanizması

Çok dilli sitelerde hreflang etiketlerinin sitemap içinde bildirilmesi, dosya boyutunu katlanarak artırır. 10 dilli bir sitede her URL kaydı, 10 adet <xhtml:link> satırı içerir. 10.000 sayfalık bir site, hreflang satırlarıyla birlikte 100.000 satırlık bir sitemap dosyası üretir. Bu büyüklük, 50 MB sınırına hızla yaklaştırır.

Kontrol mekanizması, hreflang sitemap'lerini dil veya bölge bazında segmentlere ayırmaktır. Her dil versiyonu kendi sitemap dosyasını barındırır: sitemap-tr.xml, sitemap-en.xml, sitemap-de.xml. Her dosyada yalnızca o dilin URL'leri ana kayıt olarak yer alır, ancak her kaydın altında tüm dil alternatifleri <xhtml:link> ile bildirilir. Bu yaklaşım dosya başına URL sayısını düşürür ve segment bazında indeksleme takibini mümkün kılar.

Stoktan Kalkan Ürünlerin Sitemap Yaşam Döngüsü

E-ticaret sitelerinde stoktan kalkan ürünlerin URL'leri, sitemap yönetiminin en dinamik alanıdır. Bir ürün geçici olarak stoktan çıktığında URL'yi sitemap'ten çıkarmak doğru değildir; çünkü sayfa hâlâ 200 kodu döndürür ve "stokta yok" bilgisi sunar. Ancak ürün kalıcı olarak kaldırılıyorsa, URL'nin sitemap'ten çıkarılması ve 301 veya 410 ile yönetilmesi gerekir.

Doğru yaşam döngüsü şöyledir: ürün stoktayken sitemap'te kalır ve <lastmod> stok değişikliğinde güncellenir. Geçici stok yokluğunda sayfa hâlâ 200 döndürüyorsa sitemap'te kalır, ancak structured data'daki availability değeri OutOfStock olarak güncellenir. Kalıcı kaldırmada ise URL, en alakalı kategori veya alternatif ürün sayfasına 301 ile yönlendirilir ve sitemap'ten çıkarılır. Bu üç aşamalı yaklaşım, hem kullanıcı deneyimini hem de botun tarama verimliliğini korur.

HTTP Durum Kodu Doğrulama Otomasyonu

Sitemap'teki URL'lerin tamamının 200 kodu döndürdüğünü manuel kontrol etmek, binlerce URL'ye sahip sitelerde mümkün değildir. Bu doğrulama, otomasyon gerektiren bir süreçtir. En basit yaklaşım, sitemap'ten tüm URL'leri çekip toplu HTTP HEAD isteği göndermektir.

Linux ortamında bu otomasyon şu komutlarla gerçekleştirilir:

    
# Sitemap'ten URL'leri çek
curl -s https://www.example.com/sitemap.xml | grep -oP '<loc>\K[^<]+' > urls.txt

# Her URL için HTTP durum kodunu kontrol et
while read url; do
  code=$(curl -o /dev/null -s -w "%{http_code}" "$url")
  if [ "$code" != "200" ]; then
    echo "$code $url"
  fi
done < urls.txt > non200.txt       
    

Bu script, 200 dışında durum kodu döndüren tüm URL'leri non200.txt dosyasına yazar. Büyük sitelerde xargs -P 10 ile paralel istek göndererek süreci hızlandırabilirsiniz. Bu kontrolü haftalık cron job olarak çalıştırmak, non-200 URL'lerin sitemap'e sızmasını erken aşamada tespit eder.

Search Console Kapsam Raporunun Sitemap Hijyeniyle Çaprazlanması

Search Console'daki Kapsam raporu, indekslenen ve hariç tutulan URL'lerin detaylı dökümünü sunar. Bu raporun "Sitemap'te gönderildi" filtresiyle daraltılması, sitemap kaynaklı sorunları izole etmenin en doğrudan yoludur. Filtre uygulandığında yalnızca sitemap'te bildirilen URL'lerin indeksleme durumu görüntülenir.

"Gönderildi ancak indekslenmedi" kategorisi, sitemap hijyen sorunlarının çekirdek göstergesidir. Bu kategori altında "Bulunamadı (404)", "Sayfaya yönlendirme ile ulaşıldı", "Duplicate, canonical olarak seçilmedi" ve "Noindex tarafından hariç tutuldu" gibi alt nedenler listelenir. Her bir alt neden, sitemap'ten çıkarılması gereken URL tipine doğrudan işaret eder. Bu raporu aylık teknik denetim döngüsünde inceleyip, her döngüde yeni eklenen sorunlu URL'leri temizlemek, sitemap kalitesini sürdürülebilir kılar.

CMS Bazlı Otomatik Sitemap Filtreleme Mekanizmaları

Modern CMS eklentileri, sitemap oluşturma sürecinde temel filtreleme kurallarını otomatik uygular. Yoast SEO, noindex olarak işaretlenen sayfaları sitemap'ten otomatik çıkarır. Rank Math, benzer filtrelemenin yanı sıra 301 yönlendirmesi tanımlanan URL'leri de sitemap'ten otomatik kaldırır. Ancak bu otomasyonların kapsamı sınırlıdır.

Hiçbir CMS eklentisi, soft 404 tespiti, parametre bazlı duplicate filtreleme veya canonical çapraz kontrol gibi ileri düzey doğrulamaları otomatik yapmaz. Bu kontroller, eklenti otomasyonunun üzerine inşa edilecek manuel veya script bazlı bir doğrulama katmanı gerektirir. Dolayısıyla CMS eklentisinin sitemap'i "otomatik yönettiğini" varsayarak kontrolü bırakmak, en sık karşılaşılan sitemap hijyen hatasıdır.

Headless ve Statik Site Mimarilerinde Sitemap Doğrulama

Next.js, Nuxt.js ve Gatsby gibi framework'lerde sitemap, build aşamasında statik olarak üretilir. Build sırasında tüm sayfalar render edilir ve URL listesi oluşturulur. Ancak build sonrasında silinen, yönlendirilen veya noindex eklenen sayfalar, bir sonraki build'e kadar sitemap'te kalmaya devam eder. Bu gecikme, non-200 URL'lerin sitemap'e sızmasının başlıca nedenidir.

ISR (Incremental Static Regeneration) kullanan Next.js sitelerinde durum daha karmaşıktır. ISR ile oluşturulan yeni sayfalar, build-time sitemap'inde yer almaz. Bu sayfaların sitemap'e dahil edilmesi için ya her ISR tetiklemesinde sitemap'in güncellenmesi ya da ayrı bir server-side sitemap endpoint'inin oluşturulması gerekir. next-sitemap paketinin serverSitemapIndex özelliği bu senaryoya çözüm sunar, ancak yapılandırması dikkatli yapılmalıdır.

Sitemap Audit Kontrol Listesi ve Operasyonel Standartlar

Kapsamlı bir sitemap denetimi, sistematik bir kontrol süreci gerektirir. Aşağıdaki maddeler, her teknik SEO denetiminde uygulanması gereken sitemap hijyen kontrolleridir:

• Tüm URL'lerin 200 durum kodu döndürdüğünü doğrulayın: Toplu HTTP status kontrolü ile non-200 URL'leri tespit edip sitemap'ten çıkarın.
• Noindex etiketli sayfaları filtreleyin: Hem meta robots hem X-Robots-Tag header kontrolüyle noindex taşıyan URL'leri sitemap'ten temizleyin.
• Canonical çapraz kontrolü uygulayın: Self-referencing canonical'ı olmayan URL'leri tespit edip sitemap'ten kaldırın.
• Parametre bazlı URL'leri eleyin: Query string içeren URL'lerin sitemap'e sızıp sızmadığını kontrol edin ve yalnızca clean URL'leri bırakın.
• Robots.txt tutarlılığını sağlayın: Sitemap'teki hiçbir URL'nin robots.txt ile engellenmiş olmadığını doğrulayın.
• Lastmod doğruluğunu kontrol edin: Tüm URL'lerin aynı lastmod tarihini taşımadığından emin olun; bu durum botun sinyale güvenini sıfırlar.

Sitemap Hijyeninin İndeksleme Hızına Doğrudan Etkisi

Temiz bir sitemap dosyası, botun tarama kuyruğu önceliklendirmesini doğrudan etkiler. Bot, sitemap'teki her URL'nin 200 döndürdüğünü öğrendiğinde, bu dosyaya olan güveni artar ve sitemap üzerinden keşfettiği yeni URL'leri daha hızlı tarama kuyruğuna alır. Aksine, non-200 URL'lerle dolu bir sitemap, botun dosyayı güvenilmez olarak değerlendirmesine ve keşif sinyallerini görmezden gelmesine yol açar.

Bu ilişki, özellikle yeni yayınlanan içeriklerin indekslenme hızında kendini gösterir. Sitemap hijyeni yüksek olan sitelerde, yeni eklenen bir URL'nin indekslenme süresi ortalama 24-48 saat iken, hijyeni düşük sitelerde bu süre 7-14 güne uzayabilir. Dolayısıyla sitemap temizliği, yalnızca mevcut sayfaların durumunu değil, gelecekte yayınlanacak içeriklerin performansını da belirler.

Periyodik Denetim Döngüsü ve Teknik Borç Önleme Stratejisi

Teoride doğru görünen ama pratikte patlayan nokta şudur: sitemap'i bir kez temizleyip bırakmak, birkaç ay içinde aynı sorunların yeniden birikmesine yol açar. Her yeni içerik yayını, her URL değişikliği ve her ürün kaldırma işlemi potansiyel bir kirlilik kaynağıdır. Sitemap hijyeni, sürekli bakım gerektiren bir operasyonel disiplindir.

Bu disiplini kurmak için üç katmanlı bir yaklaşım önerilir. Birinci katman, CMS'in yayın ve silme hook'larına bağlı otomatik sitemap güncellemesidir. İkinci katman, haftalık çalışan otomatik HTTP durum kodu doğrulama scriptidir. Üçüncü katman, aylık teknik SEO denetiminde Search Console Kapsam raporu ile sitemap verisinin çapraz kontrol edilmesidir. Bu üç katman birlikte çalıştığında, sitemap dosyası botun güvendiği bir envanter olmaya devam eder ve tarama bütçesi yalnızca değerli sayfalara harcanır.