"Keşfedildi, Şu Anda Dizine Eklenmedi" Nedir, Nasıl Çözülür?

Search Console'da bir URL'yi denetliyorsunuz ve şu satırı görüyorsunuz: keşfedildi, şu anda dizine eklenmedi. Sayfanın "son tarama" bilgisi boş. Yani Google bu adresi biliyor — sitemap'ten, bir iç linkten, belki bir dış bağlantıdan — ama henüz bir kez bile indirmemiş. Sunucunuzun erişim kayıtlarına baksanız o URL için Googlebot'tan gelen tek bir satır bulamazsınız. Sayfa var, adres biliniyor, ama tarama sırası bir türlü gelmiyor.

Bu durum, "tarandı, şu anda dizine eklenmedi" ile sürekli karıştırılıyor ve bu karışıklık yanlış çözümlere yol açıyor: insanlar içeriği yeniden yazıyor, oysa Google o içeriği hiç görmemiştir. Bu yazıda ikisinin farkını net biçimde ayıracak, "keşfedildi" durumunun arkasındaki asıl nedenleri — sunucu yanıt süresi, tarama bütçesi dağılımı, zayıf iç link keşfi ve devasa tek parça sitemap'ler — tek tek açacağız. Ardından erişim loglarından tarama davranışını okumayı, sunucu tarafında ne ölçüleceğini ve sitemap'i nasıl bölerek taramayı yeniden yönlendireceğinizi adım adım göstereceğiz.

"Keşfedildi, Şu Anda Dizine Eklenmedi" Ne Anlama Geliyor#

Bu durum, Google'ın URL'yi tarama kuyruğuna aldığını ama henüz indirmediğini gösterir. Sayfanın içeriği hakkında hiçbir bilgi yoktur; başlığı, metni, canonical'ı, hiçbiri okunmamıştır. Dolayısıyla bu bir içerik kalitesi kararı değildir — bir sıraya girme ve kaynak dağıtımı meselesidir.

Google, her siteye sınırlı bir tarama kapasitesi ayırır. Bu kapasite iki şeyin kesişimidir: sitenin ne kadar hızlı yanıt verdiği (tarama hızı sınırı) ve Google'ın o siteyi taramaya ne kadar istekli olduğu (tarama talebi). URL keşfedildiği hâlde taranmıyorsa, bu iki değişkenden biri ya da ikisi birden yetersiz demektir.

Şu ayrımı en baştan yerleştirin:

• Sunucu yavaşsa Google, siteyi yormamak için istek sıklığını kendisi düşürür.
• Site içinde çok sayıda düşük değerli URL varsa, kapasite onlara harcanır ve önemli sayfalara sıra gelmez.
• Bir URL'ye site içinden hiç link yoksa, Google onu düşük öncelikli sayar ve kuyruğun sonuna atar.

Tarandı ve Keşfedildi Durumlarının Farkı#

En pratik ayırt edici, sayfanın indirilip indirilmediğidir: "keşfedildi"de sunucunuza o URL için hiç istek gelmemiştir, "tarandı"da gelmiştir.

Bu tabloyu yanlış okuyup içerik üzerinde çalışmaya başlamak, en sık yapılan zaman kaybıdır. İçerik tarafındaki asıl mücadeleyi tarandı şu anda dizine eklenmedi hatası yazısında ayrıca ele alıyoruz.

Sunucu Yanıt Süresinin Tarama Hızına Etkisi#

Google, bir siteyi tararken yanıt sürelerini ölçer ve bunu bir geri bildirim döngüsü olarak kullanır. Yanıt süreleri kısaldıkça istek sıklığını yavaş yavaş artırır; uzadıkça ya da hata oranı yükseldikçe hızla düşürür. Bu simetrik değildir: hız kazanmak yavaş, kaybetmek hızlıdır.

Pratikte gördüğüm eşikler şöyle: sayfa üretimi ortalama 200-400 ms bandındaki bir sitede tarama akıcı ilerler. 1 saniyeye yaklaştığında yeni içeriğin taranma gecikmesi belirginleşir. 2 saniyenin üstünde, binlerce URL'li sitelerde "keşfedildi" listesi büyümeye başlar. 5xx hataları ya da zaman aşımları görülmeye başladığında ise Google istek sıklığını agresif biçimde kısar.

Kendi sunucunuzu ölçmenin en dürüst yolu, tarayıcı değil komut satırıdır:

# Tek bir URL için ayrıntılı zamanlama
curl -o /dev/null -s -w "dns: %{time_namelookup}s\nbaglanti: %{time_connect}s\ntls: %{time_appconnect}s\nilk bayt: %{time_starttransfer}s\ntoplam: %{time_total}s\nkod: %{http_code}\n" \
  https://ornek.com/urun/ornek-urun

# 20 farklı URL'yi sırayla ölçüp ortalamayı görün
while read url; do
  printf "%s " "$(curl -o /dev/null -s -w '%{time_starttransfer}' "$url")"
  echo "$url"
done < /tmp/urls.txt | sort -rn | head -20

Son komut, sitenizin en yavaş 20 URL'sini verir. Genellikle bunlar filtreli listeler, arama sonuç sayfaları veya ağır sorgu çalıştıran kategori sayfalarıdır — ve tarama bütçesinin çoğunu yiyen de tam olarak onlardır.

time_starttransfer değeri ilk bayta kadar geçen süredir; bu metriğin ne anlama geldiğini ve nasıl düşürüleceğini TTFB nedir nasıl düşürülür yazısında ayrıntılı anlatıyoruz. Sitenin genelinde yavaşlık varsa site neden yavaş açılıyor yazısındaki tanı sırasını izleyin.

Erişim Loglarından Tarama Davranışını Okumak#

Search Console'un "Tarama istatistikleri" raporu özet verir; asıl ayrıntı sunucu loglarındadır. Paylaşımlı barındırmada bu dosyalar genellikle hesabınızın kök dizinindeki bir klasörde bulunur, kendi sunucunuzda ise /var/log/nginx/ ya da /var/log/apache2/ altındadır.

# Googlebot günde kaç istek atıyor?
grep -ci "googlebot" /var/log/nginx/ornek.com.access.log

# Hangi dizinlere gidiyor? (bütçenin nereye harcandığı)
grep -i "googlebot" /var/log/nginx/ornek.com.access.log \
  | awk '{print $7}' | cut -d'/' -f2 | sort | uniq -c | sort -rn | head -15

# Bot hangi durum kodlarını alıyor?
grep -i "googlebot" /var/log/nginx/ornek.com.access.log \
  | awk '{print $9}' | sort | uniq -c | sort -rn

# Bota dönen yanıtların ortalama süresi (log formatında $request_time varsa)
grep -i "googlebot" /var/log/nginx/ornek.com.access.log \
  | awk '{sum+=$NF; n++} END {print "ortalama:", sum/n, "saniye"}'

Nginx kullanıyorsanız süre alanını loga eklemek için:

log_format zamanli '$remote_addr - $remote_user [$time_local] '
                   '"$request" $status $body_bytes_sent '
                   '"$http_referer" "$http_user_agent" $request_time';

access_log /var/log/nginx/ornek.com.access.log zamanli;

Bu çıktıları okurken üç şeye bakın:

1. Toplam istek sayısı sitenin büyüklüğüne göre makul mü? 5.000 URL'li bir sitede günde 50 istek görüyorsanız, yeni içeriğin sıraya girmesi aylar sürer.
2. Bütçe nereye gidiyor? Parametreli URL'ler, sayfalama, etiket arşivleri toplamın büyük kısmını yiyorsa asıl sayfalarınıza sıra kalmıyordur.
3. Hata oranı ne? 5xx ve 429 yanıtları toplamın %1'ini geçiyorsa Google hız sınırını düşürüyordur. 429 too many requests hatası ve 503 service unavailable hatası yazıları bu iki kodun kaynaklarını ayrıntılandırıyor.

Tarama Bütçesini Boşa Harcayan URL Kalıpları#

Bir sitede tarama kapasitesinin nereye gittiğini görmek genellikle şok edicidir. En sık gördüğüm israf kaynakları:

Son satır özellikle önemlidir ve gözden kaçar: aynı public_html klasörüne bağlanmış ikinci bir alan adı, sitenin tamamının ikinci bir kopyasını oluşturur ve tarama bütçesini ikiye böler. Bu yapının doğru kurulumu için addon ve parked domain cPanel yazısına bakın; tek adrese toplama işini de 301 mi 302 mi yönlendirme yazısındaki kurallara göre yapın.

Robots.txt tarafında tipik bir temizlik şöyle görünür:

User-agent: *
Disallow: /*?replytocom=
Disallow: /*?s=
Disallow: /*?orderby=
Disallow: /*?filter_
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://ornek.com/sitemap-index.xml

Dikkat: robots.txt ile engellemek, dizinde zaten bulunan bir sayfayı çıkarmaz. Amaç burada dizin temizliği değil, tarama kapasitesini boşa harcayan yolları kapatmaktır. Kural yazarken kendinizi kilitlememek için robots.txt nasıl yazılır yazısına ve robots.txt üretici aracına başvurabilirsiniz.

İç Linkle Keşfi Güçlendirmek#

Google için iç link iki iş yapar: URL'yi bulmayı sağlar ve önem sinyali taşır. "Keşfedildi ama taranmadı" durumundaki URL'lerin ortak özelliği, çoğunlukla yalnızca sitemap'te bulunmalarıdır. Sitemap zayıf bir sinyaldir; iç link güçlü bir sinyaldir.

Uygulanabilir bir öncelik sırası:

1. Hub sayfası kurun. Aynı konudaki sayfaları toplayan bir kategori/rehber sayfası oluşturun ve buradan hepsine link verin. Böylece tıklama derinliği bir anda düşer.
2. En çok taranan sayfalardan link verin. Log analizinden Googlebot'un en sık uğradığı 10 sayfayı çıkarın; keşfedilmeyen URL'lere link'i oradan verin. Bot zaten oraya geliyorsa yeni linki hızlı bulur.
3. Ana sayfayı kullanın. "Son eklenenler" bloğu, yeni URL'ler için en hızlı keşif yoludur; ana sayfa çoğu sitede en sık taranan adrestir.
4. Link metnini hedef ifadeyle yazın. "Detaylar" yerine sayfanın konusunu içeren bir metin kullanın.
5. Yönlendirme zincirinden kaçının. İç linkler doğrudan nihai URL'yi göstersin; her aracı adım hem bütçe hem sinyal kaybıdır.

Yetim sayfaları bulmak için sitemap ile gerçekte link verilen URL'leri karşılaştırın:

curl -s https://ornek.com/sitemap.xml | grep -oP '(?<=<loc>)[^<]+' | sort -u > /tmp/harita.txt
grep -rhoP 'href="\Khttps://ornek\.com[^"]*' /home/kullanici/public_html/ | sort -u > /tmp/linkler.txt
comm -23 /tmp/harita.txt /tmp/linkler.txt | head -50

Çıkan liste, "keşfedildi" kovasındaki URL listesiyle büyük ölçüde örtüşüyorsa teşhis nettir: sorun sunucu değil, site mimarisidir.

Sitemap'i Bölmek ve Öncelik Sinyali Vermek#

Tek bir devasa sitemap dosyası, Google'a "hepsi aynı derecede önemli" der — yani hiçbir öncelik bilgisi vermez. Sitemap'i bölmek, hem tarama önceliğini yönlendirir hem de teşhis için ölçüm noktası yaratır.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://ornek.com/sitemap-yeni.xml</loc></sitemap>
  <sitemap><loc>https://ornek.com/sitemap-urunler-aktif.xml</loc></sitemap>
  <sitemap><loc>https://ornek.com/sitemap-urunler-arsiv.xml</loc></sitemap>
  <sitemap><loc>https://ornek.com/sitemap-yazilar.xml</loc></sitemap>
  <sitemap><loc>https://ornek.com/sitemap-kategoriler.xml</loc></sitemap>
</sitemapindex>

Bu yapının üç somut faydası var:

• Search Console'da her dosya için ayrı "gönderilen / dizine eklenen" sayısı görürsünüz. Hangi içerik türünün taranmadığını bir bakışta anlarsınız.
• Yeni içerikleri ayrı bir dosyada toplarsanız (sitemap-yeni.xml), o dosya sık değişeceği için daha sık kontrol edilir.
• Arşiv/pasif ürünleri ayırdığınızda, onların taranmaması sizi yanıltmaz.

Kurallar: her dosyada en fazla 50.000 URL ve 50 MB sıkıştırılmamış boyut sınırına uyun; lastmod alanını yalnızca içerik gerçekten değiştiğinde güncelleyin. Her gece bütün URL'lere bugünün tarihini basan bir üretici, kısa sürede güvenilirliğini yitirir ve alan yok sayılır. Kendi dosyanızı üretmek için sitemap üretici aracını, gönderim adımları için site haritası Google'a nasıl gönderilir yazısını kullanabilirsiniz.

Barındırma Tarafında Somut Kontrol Listesi#

"Keşfedildi" durumunun en çok sunucuya bakan durum olduğunu söyledik. Şu kontrolleri sırayla yapın:

1. Ortalama yanıt süresini ölçün. Yukarıdaki curl komutuyla en az 20 farklı URL için time_starttransfer değerine bakın. Ortalama 800 ms üstündeyse öncelik burasıdır.
2. Eşzamanlılık limitine takılıyor musunuz? Paylaşımlı barındırmada eşzamanlı işlem limiti dolduğunda istekler kuyruğa girer ya da 508 döner. Kaynak kullanımını panelden izleyin; sürekli tavan yapıyorsa paket yükseltmek tarama hızını doğrudan artırır.
3. Önbellek katmanı bota çalışıyor mu? Bazı yapılandırmalar bot user-agent'ını önbellekten muaf tutar; bu, botun her istekte en pahalı yolu çalıştırması demektir. Önbelleğin bot için de devrede olduğunu doğrulayın.
4. Bot IP'lerini engelleyen bir kural var mı? Güvenlik duvarı, hız sınırlayıcı ya da bot koruma kuralları Googlebot'a 403/429 dönebiliyor. Loglardan bota giden 4xx yanıtlarını arayın.
5. DNS ve TLS süresi normal mi? time_namelookup ve time_appconnect değerleri toplamda 200 ms'yi aşıyorsa ağ tarafında bir sorun var demektir.
6. Sunucu saati ve Last-Modified başlıkları tutarlı mı? Yanlış tarih dönen bir sunucu, koşullu isteklerde gereksiz tam indirmeye yol açar.

Kendi sunucusunu yöneten kullanıcılar için ek bir kontrol: yük ortalamasına bakın. Sürekli çekirdek sayısının üzerinde seyreden bir yük, yanıt sürelerini doğrudan uzatır. Tanı sırası için sunucu yükü yüksek nedeni bulma yazısı işinizi görür.

# Anlık yük ve bekleyen istek göstergesi
uptime
# PHP-FPM havuzunda kuyruk oluşuyor mu?
grep -E "listen queue|max children" /var/log/php*-fpm.log | tail -20

max children reached satırı görüyorsanız, sunucu istekleri sıraya alıyor demektir; bu doğrudan tarama hızına yansır.

Ne Kadar Beklemeli, Ne Zaman Müdahale Etmeli#

Yeni yayımlanmış bir URL için birkaç gün ile birkaç hafta arası bekleme normaldir. Ama şu üç durumda beklemeyi bırakıp müdahale edin:

• URL 30 günden uzun süredir "keşfedildi" durumunda ve site içinden en az bir link alıyorsa.
• Aynı durumdaki URL sayısı, sitenin toplam URL sayısının %20'sini aşıyorsa.
• Loglarda Googlebot'un günlük istek sayısı düşüş eğilimindeyse.

Müdahale sırası şudur: önce sunucu hızını ve hata oranını düzeltin, sonra bütçe israfını kesin, sonra iç linkle keşfi güçlendirin, en son sitemap'i bölüp yeniden gönderin. Bu sıra önemlidir çünkü hızlı olmayan bir sunucuda iç link eklemek işe yaramaz; sıralamayı ters çevirirseniz emeğin karşılığını göremezsiniz.

Tek tek URL'ler için dizine ekleme isteği göndermek de bir araçtır ama sınırlıdır; kotası ve gerçekçi beklentileri için Google'a sayfa nasıl indexlettirilir yazısına bakın.

Sıkça Sorulan Sorular#

Keşfedildi şu anda dizine eklenmedi ne kadar sürer#

Yeni bir URL için birkaç gün ile üç hafta arası normal kabul edilir. Süre, sitenin sunucu yanıt hızına, toplam URL sayısına ve o URL'nin site içinden aldığı link sayısına göre değişir. Günlük içerik yayımlayan hızlı bir sitede saatler içinde tarama gelirken, on binlerce URL'li ve yavaş bir sitede aylar sürebilir. Aynı URL 30 günü geçtiyse ve site içinden link alıyorsa artık sıra beklemiyordur; sunucu hızı ve iç link tarafında müdahale gerekir.

İçeriği yeniden yazmak bu durumu düzeltir mi#

Hayır, çünkü Google o içeriği henüz hiç görmemiştir. "Keşfedildi" durumu sayfanın indirilmediğini gösterir; dolayısıyla metni geliştirmek, başlığı değiştirmek ya da kelime sayısını artırmak tarama sırasını etkilemez. İçerik çalışması, sayfa taranıp da dizine alınmadığında anlamlıdır. Bu aşamada emeğinizi sunucu yanıt süresine, iç link yapısına ve tarama bütçesi israfını kesmeye harcayın.

Sunucumu hızlandırırsam Google daha çok sayfa tarar mı#

Evet, doğrudan etkisi olan az sayıdaki müdahaleden biridir. Google tarama sıklığını sunucunun yanıt süresine ve hata oranına göre ayarlar; süreler kısaldıkça istek sayısını kademeli olarak artırır. Bu artış anında olmaz, genellikle birkaç hafta içinde kademeli biçimde görülür. Buna karşılık yavaşlama ya da 5xx hataları görüldüğünde düşüş çok daha hızlı gerçekleşir, yani kazanmak yavaş kaybetmek hızlıdır.

Sitemap göndermek taramayı garanti eder mi#

Hayır, sitemap yalnızca URL'lerin varlığını bildirir, taranmalarını garanti etmez. Sitemap zayıf bir keşif sinyalidir; güçlü sinyal, site içinden verilen linktir. Sadece sitemap'te bulunan ve hiçbir sayfadan link almayan URL'ler kuyruğun sonunda kalır. Sitemap'i yine de doğru tutun ve bölün, ama esas kazancı iç link mimarisinde arayın.

Tarama bütçesi küçük siteleri de ilgilendirir mi#

Birkaç yüz URL'li sitelerde tarama bütçesi genellikle bir sorun değildir. Bu ölçekte "keşfedildi" durumu görüyorsanız neden büyük ihtimalle sunucu yavaşlığı, bota dönen hata yanıtları veya URL'nin hiçbir sayfadan link almamasıdır. Bütçe, on binlerce URL üreten e-ticaret siteleri ve büyük içerik sitelerinde gerçek bir kısıt hâline gelir. Yine de parametreli URL üretimini kontrol altında tutmak her ölçekte iyi bir alışkanlıktır.

Bot loglarında Googlebot'u nasıl doğrularım#

Kullanıcı aracısı taklit edilebildiği için doğrulama ters DNS sorgusuyla yapılır. Log'daki IP adresi için ters DNS sorguladığınızda sonuç googlebot.com veya google.com alan adıyla bitmeli, ardından o ana bilgisayar adını ileri yönde çözdüğünüzde aynı IP'ye dönmelidir. İki adımı da geçmeyen istekler sahte bottur ve bunları güvenlik duvarında sınırlamak, gerçek botun kapasitesini artırır. host ya da dig -x komutlarıyla bu kontrolü saniyeler içinde yapabilirsiniz.

Aynı içeriğe ikinci bir alan adı bağlamak zarar verir mi#

Evet, doğrudan tarama bütçesini böler ve kopya içerik üretir. Aynı dizine bağlanmış park edilmiş ya da addon alan adları, sitenin tamamının ikinci bir kopyası olarak görünür; Google her iki adresi de taramaya çalışır ve asıl adresinize ayrılan kapasite azalır. Doğru kurulum, ikincil alan adlarını kalıcı yönlendirmeyle asıl adrese toplamaktır. Böylece bütçe tek adreste yoğunlaşır ve kopya sinyali ortadan kalkar.

Search Console'daki tarama istatistikleri raporunda neye bakmalıyım#

Öncelikle "Toplam tarama isteği" grafiğinin eğilimine bakın; düşüş varsa sunucu tarafında bir sorun aramak gerekir. Ardından "Ortalama yanıt süresi" grafiğini aynı zaman aralığında karşılaştırın; iki grafiğin ters yönde hareket etmesi klasik bir hız kaynaklı kısıtlama işaretidir. "Yanıta göre" dökümünde 5xx ve 429 oranlarının toplam içindeki payını kontrol edin. Son olarak "Dosya türüne göre" bölümünde görsel ve betik dosyalarının payı çok yüksekse, bütçenin HTML dışına aktığını görürsünüz.

Kapanış#

"Keşfedildi, şu anda dizine eklenmedi", içeriğinizle ilgili bir yargı değil, sitenizin taranabilirliğiyle ilgili bir kısıt bildirimidir. Bu yüzden çözüm de içerikte değil altyapıda ve mimaride aranır: önce sunucu yanıt sürelerini ve bota dönen hata oranını ölçün, sonra parametreli URL'ler ve gereksiz arşivlerle harcanan tarama kapasitesini kesin, ardından keşfedilmeyen sayfalara gerçek iç linkler kazandırın, en son sitemap'i mantıklı parçalara bölüp yeniden gönderin. Bu sırayı bozmayın; yavaş bir sunucuda iç link eklemek sonucu değiştirmez.

Bu işin büyük kısmı barındırma kalitesiyle ilgilidir. Kaynak limitlerine sürekli takılan bir hesapta tarama hızını artırmak zordur; büyüyen içerik ve ürün katalogları için hosting paketlerimize veya kaynakların tamamen size ayrıldığı VDS sunucu çözümlerine bakabilirsiniz. Sunucu tarafındaki hız ayarlarını, önbellek ve güvenlik duvarı kurallarını kendiniz yönetmek istemiyorsanız sunucu yönetimi hizmetimiz bu yükü üstlenir. İç link mimarisi ve sitemap stratejisinin birlikte planlanması içinse SEO hizmetlerimiz sayfasına göz atabilirsiniz.