"Tarandı, Şu Anda Dizine Eklenmedi" Ne Demek, Nasıl Çözülür?

Search Console'da "Sayfalar" raporunu açıyorsunuz ve karşınızda üç haneli, bazen dört haneli bir sayı duruyor: tarandı, şu anda dizine eklenmedi. Sitenizde teknik bir hata yok, sunucu 200 dönüyor, robots.txt engellemiyor, sayfa tarayıcıda sorunsuz açılıyor. Google botu gelmiş, sayfayı indirmiş, okumuş — ve sonra dizine eklememeye karar vermiş. Hiçbir hata mesajı, hiçbir gerekçe yok. Bu, Search Console'un en can sıkıcı durumudur, çünkü "düzeltilecek bir şey" göstermez; bir yargı bildirir.

Bu yazıda o yargının nereden geldiğini açacağız. "Tarandı, şu anda dizine eklenmedi" ile "keşfedildi, şu anda dizine eklenmedi" arasındaki farkı netleştirecek, Google'ın hangi sinyallere bakarak bir sayfayı dizin dışında bıraktığını sıralayacak, ve en önemlisi elinizdeki URL listesini üçe ayıracak bir karar çerçevesi vereceğiz: hangi sayfa silinmeli, hangisi başka bir sayfayla birleştirilmeli, hangisi olduğu gibi kalıp güçlendirilmeli. Türkçe kaynakların büyük kısmı bu durumda "normaldir, bekleyin" diyor. Bekleyerek çözülen vakalar var, ama azınlıkta. Çoğunda beklemek, aynı sayfanın altı ay sonra da aynı listede durmasıyla sonuçlanıyor.

"Tarandı, Şu Anda Dizine Eklenmedi" Tam Olarak Ne Anlama Geliyor#

Bu durum, Googlebot'un URL'yi gerçekten indirdiğini ama dizine alma kararını olumsuz verdiğini gösterir. Yani tarama başarılı olmuştur: sunucunuz 200 OK döndürmüş, HTML teslim edilmiş, gerekiyorsa JavaScript işlenmiştir. Ardından dizine alma aşamasında sayfa değerlendirilmiş ve "bu URL'yi dizine eklemenin arama sonuçlarına bir katkısı yok" sonucuna varılmıştır.

Bu bir hata kodu değil, bir kalite/öncelik kararıdır. Sunucu tarafında düzeltilecek bir şey aramak çoğu zaman zaman kaybıdır — ama tamamen değil, ilerleyen bölümde göreceğimiz gibi bazı barındırma kaynaklı senaryolar da bu kovaya düşer.

Şu üç şeyi baştan ayırmak lazım:

• Taranabilirlik: bot sayfaya erişebiliyor mu? Burada sorun yok, çünkü "tarandı" diyor.
• Dizine alınabilirlik: teknik olarak izin var mı (noindex, canonical, robots)? Genelde burada da sorun yok; olsaydı Search Console farklı bir kova gösterirdi.
• Dizine alınmaya değerlik: Google bu sayfayı dizinine koymak istiyor mu? Asıl kavga burada.

"Keşfedildi" ile Farkı Nedir#

İki durum karıştırılıyor ama tamamen farklı aşamalardır. Keşfedildi, şu anda dizine eklenmedi, Google'ın URL'yi bildiği ama henüz hiç taramadığı anlamına gelir; sayfa indirilmemiştir bile. Tarandı, şu anda dizine eklenmedi ise sayfanın indirildiğini ve değerlendirildiğini, sonucun olumsuz olduğunu söyler.

Yani "keşfedildi" bir erişim/kaynak sorunudur, "tarandı" bir değer sorunudur. Sunucunuzu iki kat hızlandırmanız "keşfedildi" listesini eritebilir; "tarandı" listesine dokunmaz. Bu ayrımı keşfedildi şu anda dizine eklenmedi hatası yazısında ayrıntısıyla ele alıyoruz.

Google Neden Bir Sayfayı Taradıktan Sonra Dizine Almaz#

Yıllardır bu tabloyu inceleyen biri olarak söyleyebilirim: vakaların büyük çoğunluğu şu altı başlıktan birine oturuyor.

1. İçerik, dizindeki mevcut sayfaların üzerine hiçbir şey koymuyor. 400 kelimelik, "X nedir" diye başlayıp genel geçer üç paragrafla biten bir sayfa, aynı sorunun on binlerce yanıtı olan bir dizine giremiyor. Bu "kötü içerik" demek değil; "gereksiz içerik" demek.

2. Site içinde neredeyse aynı sayfalar var. E-ticarette renk/beden varyantları, filtre URL'leri, ?sort=fiyat gibi parametreli listeler; blogda etiket ve kategori arşivleri; kurumsal sitelerde "İstanbul web tasarım", "Ankara web tasarım" gibi şehir sayfaları. Google bunlardan birini seçip diğerlerini elemiştir.

3. Sayfaya site içinden neredeyse hiç link yok. Sadece sitemap'te var, menüde yok, hiçbir yazıdan bahsedilmiyor. Google iç linki bir "bu sayfa önemli" oyu olarak okur; oy yoksa sayfa şablon kalabalığından ayrışamaz.

4. Sayfa şablonu içeriği boğuyor. Header, mega menü, yan sütun, ilgili yazılar, footer... toplam 3.000 kelimelik HTML'in 250 kelimesi asıl içerik. Boilerplate oranı yüksek sayfalar bu kovaya çok düşer.

5. Site genelinde kalite algısı düşük. Google sayfaları tek tek değil, site şablonları düzeyinde de değerlendirir. 2.000 zayıf sayfa üretmiş bir sitede, iyi yazılmış yeni bir sayfa da başlangıçta şüpheyle karşılanır.

6. Sayfa yeni ve sıraya girmiş. Bu, "bekleyin" tavsiyesinin geçerli olduğu tek senaryodur ve genellikle birkaç günden birkaç haftaya kadar sürer. Aynı URL 60 günü aşkın süredir bu durumdaysa artık "yeni" değildir.

Sayfanın Gerçekten Dizinde Olup Olmadığını Nasıl Kontrol Edersiniz#

Search Console raporları toplu veridir ve gecikmelidir. Tek bir URL için kesin cevabı URL Denetleme aracı verir. Ama komut satırından da hızlı bir ön kontrol yapabilirsiniz — özellikle sayfanın bot gözüyle nasıl döndüğünü görmek için:

# Googlebot user-agent'ı ile başlıkları ve durum kodunu kontrol edin
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://ornek.com/blog/yazi-adresi | head -20

# X-Robots-Tag başlığı var mı? (HTML'de görünmez, çok gözden kaçar)
curl -sI https://ornek.com/blog/yazi-adresi | grep -i "x-robots-tag"

# Canonical başka bir sayfayı mı gösteriyor?
curl -s https://ornek.com/blog/yazi-adresi | grep -i "rel=\"canonical\""

# Sayfanın gerçek metin hacmi ne kadar? (etiketleri söküp kelime say)
curl -s https://ornek.com/blog/yazi-adresi | sed 's/<[^>]*>//g' | wc -w

Son komut sandığınızdan çok daha öğreticidir. "Uzun yazı" diye bildiğiniz bir sayfanın toplam metninin 300 kelime çıktığını, geri kalanının menü ve footer olduğunu görmek genellikle ilk gerçek uyarıdır.

X-Robots-Tag kontrolünü atlamayın. Bir sunucu yapılandırmasında şuna benzer bir satırın unutulması, HTML'de hiçbir iz bırakmadan bütün bir dizini dizin dışı bırakabilir:

<FilesMatch "\.(html|php)$">
    Header set X-Robots-Tag "noindex, nofollow"
</FilesMatch>

Bu satır çoğunlukla test/staging ortamından canlıya kopyalanan bir .htaccess ile taşınır. Aynı şekilde parola korumalı bir dizin de botu içeri almaz; cPanel dizin parola koruma ayarını canlıda açık unutmak, klasik bir "sayfam neden yok" nedenidir.

İnce İçerik ve Neredeyse Kopya Sayfalar: En Yaygın Neden#

Türkçe içerikte en sık gördüğüm iki desen var.

Kanibalizasyon. Aynı konuyu üç ayrı yazıda anlatmışsınız: "SSL nedir", "SSL sertifikası ne işe yarar", "Neden SSL kullanmalıyım". Üçü de aynı soruya cevap veriyor. Google birini seçer, diğer ikisi "tarandı, dizine eklenmedi" olur. Bu bir ceza değil, bir tercih.

Şablonlanmış sayfa üretimi. Bir tablo veya veritabanından üretilmiş, sadece bir kelimesi değişen yüzlerce sayfa. "Adana nöbetçi eczane", "Adıyaman nöbetçi eczane"... İçerik gövdesi birebir aynıysa, Google tek bir örneği dizine alıp gerisini bırakır.

Kanibalizasyonu tespit etmenin en pratik yolu, hedef ifadeyi site içinde aratmaktır. Yazılarınızın kaynak dosyalarına erişiminiz varsa (statik site, WordPress dışa aktarımı, yerel kopya) komut satırından da bakabilirsiniz:

# Aynı ifadeyi başlık düzeyinde kullanan kaç dosya var?
grep -rIl --include="*.md" -i "ssl sertifikası nedir" ./content/ | wc -l

# Hangi dosyalar olduğunu listeleyin
grep -rIn --include="*.md" -i "^title:.*ssl" ./content/

WordPress kullanıyorsanız aynı kontrolü veritabanı üzerinden yapabilirsiniz:

SELECT ID, post_title, post_name
FROM wp_posts
WHERE post_status = 'publish'
  AND post_type = 'post'
  AND post_title LIKE '%ssl%'
ORDER BY post_date DESC;

Çıkan liste üç-dört satırsa ve başlıklar birbirine benziyorsa, sorunun kaynağını buldunuz demektir.

Hangi Sayfayı Silmeli, Hangisini Birleştirmeli, Hangisini İyileştirmeli#

Bu, Türkçe kaynaklarda neredeyse hiç işlenmeyen kısım ve işin asıl karar noktası. Elinizdeki "tarandı, dizine eklenmedi" listesini üç kovaya ayırın. Karar için üç veriye bakın: sayfanın aldığı organik tıklama (Search Console Performans), gelen iç link sayısı ve konu benzerliği (aynı niyeti karşılayan başka bir sayfa var mı).

Silme kararında 410 Gone, 404'ten daha net bir sinyaldir: "bu sayfa kalıcı olarak yok". Apache tarafında:

# Kalıcı olarak kaldırılan içerik için 410
RewriteEngine On
RewriteRule ^blog/eski-kampanya-2019/?$ - [G,L]

Nginx kullanıyorsanız:

location = /blog/eski-kampanya-2019 {
    return 410;
}

Birleştirme kararında kalıcı yönlendirme kullanın; hangi durumda hangi kodun doğru olduğunu 301 mi 302 mi yönlendirme yazısında ayrıntılandırıyoruz. Yönlendirmeyi kurduktan sonra eski URL'ye giden iç linkleri de güncelleyin — zincir yönlendirme, dizine alma sinyalini zayıflatır.

Dizin dışı bırakma kararında robots.txt ile noindex karıştırılmasın. Robots.txt taramayı engeller; engellenen bir sayfa noindex etiketini okuyamaz, dolayısıyla dizinden çıkması gerekenden uzun sürer. Doğru sıra: önce noindex ile dizinden düşür, düştükten sonra istersen robots.txt'e ekle. Bu konudaki tipik hatayı robots.txt tarafından engellendi hatası yazısında ayrıca anlatıyoruz.

İç Link Derinliği ve Yetim Sayfalar#

Bir sayfa ana sayfadan kaç tıklamayla ulaşılabiliyorsa, o sayfanın "derinliği" odur. Deneyimime göre 4 tıklamadan derinde kalan sayfalarda "tarandı, dizine eklenmedi" oranı belirgin biçimde artar. Sadece sitemap'te bulunan, hiçbir sayfadan link almayan yetim sayfalar ise en kötü durumdadır: Google onları görür ama sitenin kendisi bile onlara değer vermediğini söylemiş olur.

Sunucudaki HTML dosyalarına erişiminiz varsa yetim sayfa avını basitçe yapabilirsiniz:

# Sitemap'teki URL'leri çıkar
curl -s https://ornek.com/sitemap.xml | grep -oP '(?<=<loc>)[^<]+' | sort -u > /tmp/sitemap.txt

# Site içinde geçen iç linkleri topla (statik çıktı için)
grep -rhoP 'href="\Khttps://ornek\.com[^"]*' /home/kullanici/public_html/ | sort -u > /tmp/iclink.txt

# Sitemap'te olup hiçbir yerden link almayanlar
comm -23 /tmp/sitemap.txt /tmp/iclink.txt

Çıkan listeyi doğrudan bir yapılacaklar listesi olarak kullanabilirsiniz. Her URL için şu üç bağı kurmayı hedefleyin:

1. Konu olarak en yakın iki yazının gövdesinden tanımlayıcı bir metinle link.
2. İlgili kategori/hub sayfasından link.
3. Mümkünse ana sayfadan ya da menüden ulaşılabilen bir yoldan link.

Link metnini "buraya tıklayın" değil, sayfanın hedef ifadesiyle yazın. İç linkin işi hem yönlendirmek hem de hedef sayfanın ne hakkında olduğunu söylemektir.

Sitemap, Canonical ve Teknik Sinyaller#

Sitemap dizine alma garantisi vermez ama sinyal netliği sağlar. Üç kural:

Sitemap'e sadece dizine girmesini istediğiniz URL'leri koyun. İçinde noindex olan, canonical'ı başka sayfayı gösteren veya yönlendirilen URL'ler varsa, Google'a çelişkili sinyal göndermiş olursunuz. Kendi sitemap'inizi elle üretmek isterseniz sitemap üretici aracımız işi kolaylaştırır; sürecin tamamı için site haritası Google'a nasıl gönderilir yazısına bakın.

Sitemap'i bölün. Tek bir devasa dosya yerine sitemap-yazilar.xml, sitemap-urunler.xml, sitemap-kategoriler.xml gibi mantıksal parçalara ayırın ve bir sitemap index ile bağlayın. Bunun büyük faydası şudur: Search Console'da her sitemap dosyası için ayrı ayrı "gönderilen / dizine eklenen" sayısını görürsünüz. Hangi içerik türünün elendiğini böylece net görürsünüz.

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

lastmod alanını dürüst tutun. Her gece bütün URL'lere bugünün tarihini yazan bir sitemap üreticisi, kısa sürede güven kaybeder ve alan tamamen yok sayılır. Sadece içerik gerçekten değiştiğinde güncelleyin.

Canonical tarafında en sık gördüğüm hata, sayfanın kendini değil de kategori sayfasını canonical göstermesidir. Bu, "beni dizine alma, şunu al" demektir ve sayfa doğal olarak "tarandı, dizine eklenmedi" listesine düşer. Canonical mantığının tamamı için canonical etiketi nedir yazısına bakabilirsiniz.

Sunucu Tarafında Yapabilecekleriniz#

"Tarandı" durumu esas olarak içerik kararıdır, ama barındırma tarafının hiç etkisi yok demek de yanlış olur. Şu üç senaryoda sunucu doğrudan sorumludur:

Bot için farklı içerik dönüyorsanız. Agresif bir önbellek katmanı, bot user-agent'ına eski ya da eksik HTML dönebilir. Yukarıdaki Googlebot user-agent'lı curl testini, normal bir tarayıcı user-agent'lı istekle karşılaştırın; iki çıktının kelime sayısı belirgin farklıysa sorun buradadır.

Sayfa yavaş üretiliyorsa. İlk bayta kadar geçen süre saniyeler seviyesine çıktığında Google tarama hızını kısar, bu da yeni içeriğin değerlendirilmesini geciktirir. Ölçüm ve düşürme yöntemleri için TTFB nedir nasıl düşürülür yazısına bakın.

Kaynak limitine takılıyorsanız. Paylaşımlı barındırmada eşzamanlı işlem veya bellek limiti dolduğunda sunucu 503/508 döndürür. Botun ısrarla 503 aldığı bir sitede, sağlıklı yanıt alınan az sayıdaki istekte de dizine alma önceliği düşer. 508 resource limit is reached hatası yazısı bu tabloyu ayrıntısıyla ele alıyor.

Erişim loglarından botun sitenizde ne yaptığını görebilirsiniz:

# Son 24 saatte Googlebot hangi URL'leri, hangi kodla aldı?
grep -i "googlebot" /home/kullanici/access-logs/ornek.com \
  | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head -30

# Sadece hatalı yanıtları göster
grep -i "googlebot" /home/kullanici/access-logs/ornek.com \
  | awk '$9 ~ /^(4|5)/ {print $9, $7}' | sort | uniq -c | sort -rn

Bu çıktı bazen çok şey anlatır: botun zamanının %70'ini ?replytocom= parametreli yorum linklerinde harcadığını görmek, öncelik sıralamanızı bir anda değiştirir.

30 Günlük Uygulama Planı#

Sıralama önemlidir; hepsini aynı anda yapmak, neyin işe yaradığını ölçmenizi engeller.

1. Gün 1-2 — Envanter. Search Console'dan "tarandı, dizine eklenmedi" URL listesini dışa aktarın. Performans raporundaki tıklama verisiyle birleştirin.
2. Gün 3-4 — Teknik eleme. X-Robots-Tag, canonical, parola koruması, bot'a farklı içerik dönme durumlarını kontrol edin. Buradan çıkan URL'ler zaten kalite sorunu değildir.
3. Gün 5-7 — Sınıflandırma. Kalan URL'leri yukarıdaki karar tablosuna göre sil / birleştir / iyileştir / dizin dışı bırak olarak işaretleyin.
4. Gün 8-12 — Temizlik. Silinecekleri 410'a alın, birleştirilecekleri 301'leyin, otomatik sayfaları noindex'e çekin. Sitemap'i bu karara göre yeniden üretin.
5. Gün 13-20 — İçerik. "İyileştir" kovasındaki sayfaları elden geçirin. Her birine en az üç iç link kazandırın.
6. Gün 21 — Yeniden gönderim. Sitemap'i tekrar gönderin, en önemli 10-15 URL için URL Denetleme aracından dizine ekleme isteği bırakın. Yöntemin sınırları için Google'a sayfa nasıl indexlettirilir yazısına bakın.
7. Gün 22-30 — Bekleme ve ölçüm. Bu süre içinde başka değişiklik yapmayın. Sonuçları "tarandı, dizine eklenmedi" sayısının mutlak değeriyle değil, dizine eklenen sayfa sayısındaki artışla ölçün.

Gerçekçi beklenti: iyileştirilen sayfaların bir kısmı 2-6 hafta içinde dizine girer, bir kısmı hiç girmez. Girmeyenler size, o konuda dizinde zaten yeterince iyi bir cevap olduğunu söylüyordur.

Sıkça Sorulan Sorular#

Tarandı şu anda dizine eklenmedi bir ceza mı#

Hayır, ceza değildir. Bu durum manuel bir işlem ya da algoritmik bir yaptırım değil, dizine alma sırasında verilen rutin bir önceliklendirme kararıdır. Google her taradığı URL'yi dizine almak zorunda değildir ve büyük sitelerde bu listenin hiç boşalmaması normaldir. Ceza durumunda Search Console'un "Manuel işlemler" bölümünde açık bir bildirim görürsünüz. Orada bir şey yoksa, elinizdeki tablo bir kalite ve öncelik meselesidir.

Sayfa kaç gün sonra dizine girer#

Yeni yayımlanan bir sayfa için birkaç gün ile üç hafta arası normal kabul edilir. Bu süre sitenin genel otoritesine, yayın sıklığına ve sunucu yanıt hızına göre değişir; günlük içerik yayımlayan yerleşik bir sitede saatler, yeni açılmış bir sitede haftalar sürebilir. Aynı URL 60 günden uzun süredir bu listedeyse artık "sıra bekliyor" durumunda değildir ve içerik/iç link tarafında müdahale gerekir. Bu noktadan sonra beklemek, sonucu değiştirmez.

Aynı sayfa için tekrar tekrar dizine ekleme isteği göndermek işe yarar mı#

Hayır, tekrar istek göndermek sıra atlatmaz ve önceliği artırmaz. URL Denetleme aracındaki istek, URL'yi tarama kuyruğuna alır; sayfa zaten taranmış ve dizine alınmamışsa aynı içerik için yapılan yeni istek genellikle aynı sonucu üretir. Doğru yaklaşım, önce sayfada gerçek bir değişiklik yapmak, sonra tek bir istek göndermektir. Günlük istek kotanız da sınırlıdır; bunu değişiklik yaptığınız sayfalar için saklayın.

İnce içerikli sayfaları silmek siteye zarar verir mi#

Doğru sayfaları silmek genellikle zarar vermez, çoğu zaman fayda sağlar. Zarar, trafik alan veya iç/dış link toplamış bir sayfayı yönlendirmeden silmekten gelir. Silmeden önce Search Console Performans raporunda son 6 ayın tıklama ve gösterim verisine bakın; ikisi de sıfıra yakınsa ve konunun daha güçlü bir karşılığı yoksa kaldırmak güvenlidir. Değerli bir sayfayı kaldırıyorsanız 410 yerine en yakın alternatife 301 verin.

Robots.txt ile engellersem bu sayfalar listeden çıkar mı#

Çıkar ama sorunu çözmez, sadece raporu değiştirir. Robots.txt ile engellenen URL'ler "tarandı, dizine eklenmedi" kovasından çıkıp "robots.txt tarafından engellendi" kovasına geçer; ayrıca engellenen sayfa üzerindeki noindex etiketi okunamayacağı için, daha önce dizine girmiş bir URL dizinde kalmaya devam edebilir. Kalıcı olarak dizin dışında tutmak istediğiniz sayfalar için doğru araç noindex'tir, robots.txt değil.

Yapay zekâ ile üretilmiş içerik bu yüzden mi dizine alınmıyor#

Üretim yöntemi tek başına belirleyici değildir; belirleyici olan, sayfanın dizindeki mevcut cevaplara ne kattığıdır. Konuyu tekrar eden, kendi deneyimi, verisi veya örneği olmayan metinler kaynağı ne olursa olsun bu listeye düşer. Aynı şekilde, insan yazmış ama yüzeysel kalmış bir sayfa da elenir. Pratik ölçüt şudur: sayfada, aynı konudaki ilk on sonuçta bulunmayan somut bir bilgi var mı? Yoksa üretim yöntemini tartışmak yerine içeriği derinleştirin.

E-ticarette varyant ve filtre sayfaları için ne yapmalıyım#

Varyant ve filtre URL'lerinin büyük kısmının dizine girmemesi hedeflenen durumdur. Renk/beden gibi varyantlarda ana ürün sayfasına canonical verin; sıralama, sayfalama ve filtre parametreleriyle üretilen listelerde ise noindex, follow kullanın, böylece bot linkleri takip etmeye devam eder ama sayfa dizine girmez. Yalnızca gerçekten arama hacmi olan filtre kombinasyonlarını (örneğin bir kategori + belirgin bir özellik) dizine açın ve bunlara özgün açıklama metni ekleyin.

Sunucumu hızlandırmak bu sorunu çözer mi#

Doğrudan çözmez, ama zemini iyileştirir. "Tarandı, dizine eklenmedi" bir değer kararı olduğu için, aynı içerik daha hızlı bir sunucuda da aynı kararla karşılaşır. Buna karşılık yavaş sunucu tarama hızını düşürür; düzelttiğiniz sayfaların yeniden değerlendirilmesi gecikir ve iyileştirmelerin etkisini görmeniz uzar. Yani hız, çözümün kendisi değil, çözümün ne kadar çabuk ölçülebileceğini belirleyen etkendir.

Kapanış#

"Tarandı, şu anda dizine eklenmedi", bozuk bir şeyin işareti değil; Google'ın sayfanız hakkında verdiği bir yargının raporudur. Bu yüzden çözüm de teknik bir düzeltmeden çok bir envanter çalışmasıdır: önce teknik nedenleri (X-Robots-Tag, canonical, parola koruması, bota farklı içerik) eleyin, kalan URL'leri sil / birleştir / iyileştir / dizin dışı bırak diye dört kovaya ayırın, sonra en değerli kovaya iç link ve içerik yatırımı yapın. Ölçmeyi de doğru yapın: hedef, listedeki sayının sıfırlanması değil, dizine eklenen değerli sayfa sayısının artmasıdır.

Bu işin bir kısmı içerik kararı, bir kısmı da altyapı işidir. Botun sitenizi hızlı ve tutarlı tarayabilmesi için sağlam bir barındırma zemini gerekir; ölçeklendikçe kaynak limitine takılmayan bir yapı için hosting paketlerimize ya da tam kaynak izolasyonu isteyen projelerde VDS sunucu seçeneklerine bakabilirsiniz. WordPress tabanlı bir sitede dizine alma sorunlarının önemli kısmı eklenti ve şablon kaynaklıdır; bu tarafı kendiniz takip etmek istemiyorsanız WordPress bakım hizmetimiz güncelleme, hız ve teknik SEO kontrollerini üstlenir. İçerik ve iç link mimarisinin planlanması için SEO hizmetlerimiz sayfasına göz atabilirsiniz.