2026'da site indeksleme: crawl budget nasıl çalışır ve onu nasıl çarçur etmezsiniz

On bin mağazalı bir alışveriş merkezi inşa ettiğinizi ve çalışma izni veren denetçinin günde bir kez uğrayıp yalnızca beş yüz kapıyı kontrol edebildiğini hayal edin. Üstelik zamanının yarısını, kendi tabelalarınızın yanlışlıkla soktuğu depolarda, arka odalarda ve tuvaletlerde geçiriyor. Orta ve büyük ölçekli projelerin çoğunda site indeksleme tam olarak böyle görünüyor. Arama botu gelir, kaynağını çöpe harcar ve en iyi sayfalarınızı görmeden gider.

2026'da bu sorun daha da keskinleşti. Arama motorları belirgin biçimde seçici hale geldi: indeks artık her şeyin doldurulduğu sonsuz bir depo değil. Aynı zamanda sunuculara, yapay zeka modelleri için veri toplayan yeni tarayıcı botların dalgası düştü ve bunlar arama botlarıyla aynı bant genişliği için yarışıyor. Kaynağının nasıl tarandığını yönetmeyen site sahibi soyut puanlar değil, gerçek para kaybediyor: yeni ürünler haftalarca arama sonuçlarına giremiyor, güncellenen fiyatlar eski haliyle kalıyor ve kampanya açılış sayfaları görünmez olarak kalıyor.

Bu rehber tek bir konuya odaklanıyor: arama motorları sitenizde neyin ne zaman taranacağına nasıl karar veriyor ve bu kararı nasıl etkileyebilirsiniz. Sitemap'in nasıl oluşturulacağını veya botlar için direktiflerin nasıl yazılacağını bilinçli olarak tekrar anlatmayacağız. Blogumuzda bu konular ayrı ayrı ele alındı. Burada asıl mekanizmadan söz edeceğiz: botun bir URL'nin varlığını öğrendiği an ile sayfanın indekse girdiği an arasında ne oluyor.

Kime hitap ediyor? Yeni açılış sayfaları çok yavaş indekslenen pazarlamacılara. Sunucusu bot yükü altında inleyen ama önemli bölümleri taranmamış kalan geliştiricilere. Onlarca sitesi ve yüzlerce açılış sayfası olan, indekse girme hızının doğrudan geri dönüşü etkilediği arbitrajcılara. Fasetli navigasyonun milyonlarca adres ürettiği e-ticaret siteleri ve toplayıcı platform sahiplerine. Teoriyi anlaşılır bir dille açıklayacağız, adım adım talimatlarla dört pratik yöntem sunacağız, tipik hataları, araçları ve sayılarla gerçek vakaları göstereceğiz. Yazının sonunda, bu hafta uygulayabileceğiniz eksiksiz bir crawl budget yönetim çerçevesine sahip olacaksınız.

Temeller: site indeksleme nasıl işler ve crawl budget nedir

Temelden başlayalım, çünkü yanlış anlamaların çoğu tam burada saklı. Çoğu kişi site indekslemenin anında ve otomatik gerçekleştiğini sanır: sayfayı yayınlarsın, arama sonuçlarına girer. Gerçekte her URL birkaç aşamadan geçer ve herhangi birinde takılabilir.

Bir sayfanın indekse giden yolundaki beş aşama

1. Keşif. Arama motoru adresin varlığını öğrenir: dahili bir bağlantıdan, harici bir bağlantıdan, sitemap'ten, analitik sayacı üzerinden veya bir bildirimden. Keşfedilen URL kuyruğa girer.
2. Planlama. Sistem bu adresin ne zaman ve hatta taranıp taranmayacağına karar verir. Sayfanın tahmini değeri, değişiklik geçmişi, sunucu yükü ve kuyruğun güncel önceliği hesaba katılır.
3. Tarama (crawling). Bot bir HTTP isteği gönderir ve yanıt alır: HTML kodu, durum, başlıklar. Söz konusu bütçe tam burada harcanır.
4. İşleme ve render. Alınan kod ayrıştırılır, bağlantılar çıkarılır ve gerekirse sayfa JavaScript yürütme kuyruğuna gönderilir. Ardından sistem içeriği değerlendirir, kanonik adresi belirler ve kopya olup olmadığını kontrol eder.
5. İndeksleme. Sayfa ya indekse eklenir ve sıralamaya uygun hale gelir ya da reddedilir: kopya olarak, düşük değerli olarak, direktiflerle engellenmiş olarak.

Dikkat edin: tarama ve indeksleme farklı olaylardır. Sayfa taranabilir ama indekslenmeyebilir. Tersine, bir URL içerik tam olarak taranmadan harici sinyallerle indekslenebilir. Bu farkı anlamak, teşhis sırasındaki hataların yarısını ortadan kaldırır.

Crawl budget nedir

Crawl budget (tarama bütçesi), bir arama botunun sitenizde belirli bir dönemde taramaya hazır ve muktedir olduğu URL sayısıdır. İki bileşenden oluşur.

• Tarama hızı limiti (crawl capacity limit) - botun sunucunuzu aşırı yüklemeden açabileceği paralel bağlantı ve istek sayısı. Bu teknik tavandır. Sunucu hızlı ve istikrarlı yanıt verdiğinde dinamik olarak büyür, hatalar, zaman aşımları ve yavaş yanıtlarda düşer.
• Tarama talebi (crawl demand) - arama motorunun içeriğinize ne kadar ilgi duyduğu. Popüler, sık güncellenen, iyi alıntılanan sayfalar daha sık istenir. Düşük kaliteli yetim sayfalar, limit boş olsa bile aylarca istenmeyebilir.

Nihai bütçe, iki değerden küçük olanıdır. Sunucu saniyede bin isteği kaldırabilir, ancak bot talep görmüyorsa on sayfa için gelir. Tersi de geçerli: içerik talep görebilir, ancak sunucu hata verirse limit kısılır.

Bu kimleri ilgilendirir

Büyük arama motorlarının resmi tutumu şu: crawl budget, sık değişen birkaç on bin sayfalık siteler veya genel olarak bir milyon sayfalık siteler için gerçek bir sorun haline gelir. Bu doğru, ama bir uyarıyla. İki bin adresli küçük bir site de zarar görebilir: bu iki binin bin beş yüzü teknik çöpse ve alan adının gençliği ile zayıf bağlantı profili nedeniyle bütçe günde yüz URL ise. Oran, mutlak sayılardan daha önemlidir. Bu nedenle "ne kadar bütçem var" sorusu her zaman "neye harcanıyor" sorusuyla birlikte gelir.

Derinlemesine bakış: 2026'da botlar kararlarını nasıl veriyor

Şimdi mekanizmanın içine bakalım. Arama motorlarının kesin algoritmaları kapalıdır, ancak resmi dokümantasyon, patentler, deneyler ve büyük projelerin loglarıyla tablo yeterince netleşiyor.

Liste değil, öncelikli kuyruk

Bot siteyi "sırayla" dolaşmaz. Bilinen tüm URL'ler, her adresin bir öncelik puanı olduğu dev bir kuyrukta durur. Bu puan birkaç faktörden oluşur:

• Bağlantı önemi - URL'ye gelen dahili ve harici bağlantıların sayısı ve kalitesi. Ana sayfa ve üst düzey bölümler neredeyse her zaman kuyruğun tepesindedir.
• Tahmini değişiklik sıklığı. Sayfa son on taramada her seferinde değiştiyse bot daha erken gelir. Hiç değişmediyse aralık uzar.
• Tarihsel fayda. Arama sonuçlarından tıklama alan sayfalar daha sık taranır. Taranıp reddedilen sayfalar öncelik kaybeder.
• URL tipi ve kalıbı. Sistemler adres kalıplarından öğrenir. /catalog/?sort=price biçimindeki yüzlerce sayfa kopya çıktıysa, tüm kalıp düşük öncelik alır.
• Sunucu durumu. Her 5xx yanıtı, her zaman aşımı, tüm ana makine için yoğunluğu düşürme sinyalidir.

Buradan önemli bir sonuç çıkar: crawl budget yalnızca istek sayısı değil, aynı zamanda dağılımıdır. Cömert bir limite sahip olabilir ve yine de botun günde onuncu kez boş bir filtre sayfasını kontrol ederken yeni bir ürünü görmezden geldiğini izleyebilirsiniz.

İki işleme dalgası ve JavaScript'in bedeli

Modern botlar JavaScript yürütebilir, ancak bunu ayrı bir kuyrukta ve ayrı bir kaynakla yapar. Önce sistem kaynak HTML'i işler, bağlantıları ve içeriği çıkarır. Sayfa scriptlere bağımlıysa, saatler veya günler sonra gerçekleşebilecek render kuyruğuna gönderilir. Yalnızca JS çalıştırıldıktan sonra ortaya çıkan bağlantılar gecikmeyle keşfedilir. Script ile yüklenen içerik daha sonra değerlendirilir.

Sunucu tarafı render olmadan istemci tarafı çerçeveler kullanan siteler için bu çift maliyet anlamına gelir: tarama bütçesi HTML'e, render bütçesi kodun yürütülmesine harcanır ve aralarında zaman kaybolur. 2026'da bu, teknolojik olarak modern projelerde yavaş indekslemenin ana nedenlerinden biri olmaya devam ediyor. Paradoks, öyle değil mi?

Okumayı bilmeniz gereken durumlar

Web yöneticisi panellerinde, her biri sorunun belirli bir aşamasına işaret eden birkaç durum vardır.

• Keşfedildi, indekslenmedi. Bot adresi biliyor ama henüz taramadı. Bütçe açığının veya düşük önceliğin klasik belirtisi: kuyruk uzun, URL sonda duruyor.
• Tarandı, indekslenmedi. Bot içeriği aldı ve indekse eklememeye karar verdi. Bu artık bütçe değil, kalite, kopyalama veya yetersiz içerik sorunudur. Bütçe boşa harcandı.
• Sayfa kopyadır, kanonik adresi kullanıcı seçmedi. Sistem kopyayı buldu ve başka bir URL seçti. Her böyle sayfa, boşa giden bir taramadır.
• Sunucu hatası veya yönlendirme. Bütçenin çalışmayan adreslere gittiğine dair doğrudan sinyal.

Yandex'in özellikleri

Yandex botu benzer ilkelerle çalışır ama farklılıkları vardır. Günlük sınırlı, zorunlu yeniden tarama için ayrı bir kotası vardır. Yeni sayfaları keşfetmek için analitik sayacı verilerini aktif olarak kullanır. Bölgesel bağlantıya duyarlıdır ve aynı adresi farklı bölgeler bağlamında tarayabilir. Ayrıca siteyle tanışmanın başında oldukça agresiftir: yeni bir proje, sonradan dengelenen bir istek patlaması alabilir. Rus pazarında çalışırken bu nüansları görmezden gelmek olmaz.

2026'ya gelindiğinde neler değişti

Güncel tabloyu üç eğilim belirliyor. Birincisi: indeks katılaştı. Arama motorları, her şeyi indekslemek zorunda olmadıklarını açıkça söylüyor. Yetersiz, şablon, değer üretmeden oluşturulmuş sayfalar işleme aşamasında ayıklanıyor. İkincisi: yapay zeka tarayıcı botlarının artışı. Dil modelleri için veri toplayan botlar, arama botlarıyla karşılaştırılabilir, hatta bazen onu aşan yük üretebiliyor. Arama trafiği getirmiyorlar ama sunucu kaynağını yiyorlar ve gerçek arama botları için limiti dolaylı olarak düşürüyorlar. Üçüncüsü: içerik tazeliğinin talep sinyali olarak ağırlığı arttı. Sayfalarını gerçekten güncelleyen siteler daha fazla ilgi görüyor; içerik değiştirmeden tarih değiştirerek güncelleme taklit etmek ise fark ediliyor ve öncelik düşürülerek cezalandırılıyor.

Yöntem 1: Bütçe yönetiminin temeli olarak sunucu log analizi

Bir şeyi yönetmek istiyorsanız onu ölçmelisiniz. Web yöneticisi panelleri toplu tarama istatistikleri verir ama bunlar yumuşatılmış, gecikmeli ve eksiktir. Botun gerçekte nereye gittiğine dair tek gerçek kaynak sunucu loglarınızdır. Bu ilk ve en önemli yöntemdir.

Web yöneticisi paneli varken neden loglar

Tarama istatistikleri raporu toplam istek sayısını, ortalama yanıt boyutunu ve tür dağılımını gösterir. Ama botun zamanının yüzde 40'ını katalog sıralama sayfalarında geçirdiğini söylemez. Önemli bir bölümün üç haftadır ziyaret edilmediğini göstermez. Ürünlere yapılan isteklerin yarısının yönlendirme döndürdüğünü ortaya çıkarmaz. Loglar tüm bunları her bir URL için gösterir.

Adım adım log analizi talimatı

1. En az 30 günlük log toplayın. Seyrek taranan siteler için 60-90 gün daha iyidir. Tüm düğümlerin loglandığından emin olun: yük dengeleyiciler, CDN, ayrı sunucular. Bir düğümün atlanması tabloyu çarpıtır.
2. Arama botu isteklerini ayırın. User-Agent satırına göre filtreleyin, ancak mutlaka gerçekliğini doğrulayın: gerçek botlar arama motorlarının yayımladığı bilinen IP aralıklarından gelir ve ters DNS sorgusuyla doğrulanır. Loglarda kendini arama botu gibi gösteren sahte botlar, toplam sayının üçte birine kadar çıkabilir. Onları saymak, gürültüyü analiz etmek demektir.
3. URL'leri tiplere göre sınıflandırın. Adresleri kategorilere ayırın: ana sayfa, bölümler, ürün kartları veya makaleler, parametreli sayfalar, sayfalama, site içi arama, servis sayfaları, statik kaynaklar, var olmayanlar. Bunun için adres yapısına yönelik bir dizi düzenli ifade yeterlidir.
4. Özet tablo oluşturun. Her kategori için şunları hesaplayın: bot istek sayısı, toplam içindeki pay, durum kodu dağılımı, ortalama yanıt süresi, benzersiz URL sayısı. Kategorinin iş değeriyle karşılaştırın.
5. Boşlukları bulun. Botun taradığı URL listesini site yapınızdaki URL listesiyle eşleştirin. İki grup ortaya çıkar: taranan ama var olmaması gereken adresler ve taranması gereken ama ziyaret edilmeyen adresler.
6. Kilit sayfaların tarama sıklığını hesaplayın. En önemli yüz URL için botun ziyaretleri arasındaki aralığa bakın. Yeni ürünler iki haftada bir ziyaret ediliyorsa, işte gerçek site indeksleme hızınız.

Üzerinde çalışacağınız tipik bir log satırı şöyle görünür:

66.249.66.1 - - [12/Feb/2026:08:14:22 +0300] "GET /catalog/phones/?sort=price&page=17 HTTP/1.1" 200 48211 "-" "Mozilla/5.0 (compatible; Googlebot/2.1)"

Ona bir bakış çok şey anlatır: bot fiyata göre sıralanmış listenin on yedinci sayfası için gelmiş. Bu sayfanın indeks için değerli olma olasılığı sıfıra yakın. Büyük bir mağazanın loglarında bu tür satırlardan günde on binlerce var.

Dört kadran çerçevesi

Analiz sonuçlarını "taranıyor - taranmıyor" ile "değerli - değersiz" matrisinde düzenlemek pratiktir.

• Taranıyor ve değerli. Norm bölgesi. Görev, tarama sıklığının değişiklik sıklığına uygun olmasını izlemektir.
• Taranıyor ve değersiz. Sızıntı bölgesi. Bütçe tam burada yanıyor. Ortadan kaldırmak için ilk hedef.
• Taranmıyor ve değerli. Kaçırılan fırsat bölgesi. Boşalan kaynak buraya dahili bağlantılar ve öncelik sinyalleriyle yönlendirilmeli.
• Taranmıyor ve değersiz. Sükûnet bölgesi. Hiçbir şey yapmaya gerek yok, ancak bu sayfaların aniden keşfedilmeye başlamadığından emin olun.

Loglardaki alarm sinyalleri kontrol listesi

• Bot isteklerinin yüzde 20'sinden fazlası benzersiz içerik üretmeyen parametreli URL'lere gidiyor.
• Bota verilen yanıtların yüzde 10'undan fazlası yönlendirme veya 404 hatası.
• 5xx yanıtları var veya botun yanıt süresi isteklerin belirgin bir bölümünde iki saniyeyi aşıyor.
• Fiyat ve stoklar günlük değişirken kilit ticari sayfalar haftada birden az ziyaret ediliyor.
• Bot ne yapıda ne sitemap'te olan URL'leri istiyor: scriptler, eski bağlantılar veya hack yoluyla adres "sızıntısının" işareti.
• İsteklerin önemli bir kısmı, önbelleğe alınmayan ve her seferinde yeniden sunulan statik kaynaklara gidiyor.

Log analizi, teknik SEO'daki en hafife alınan iştir. Zaman gerektirir, ama sonrasında diğer tüm yöntemler tahmin olmaktan çıkıp nokta atışı cerrahiye dönüşür.

Yöntem 2: Crawl budget yiyicilerini ortadan kaldırmak

Sızıntı haritası çıkarıldığında tasfiyeye geçiyoruz. Burada ilke önemlidir: her şeyi birden düzeltmeye çalışmak değil, en büyük kaynaklara vurmak. Tipik yiyicileri ve her biriyle çalışma yöntemlerini inceleyelim.

Fasetli navigasyon ve URL parametreleri

Büyük sitelerin indekslenmesinin baş düşmanı. Her biri beş değerli on filtreye sahip bir katalog teorik olarak milyonlarca adres kombinasyonu üretir. Bot bunlara bağlantı bulur ve dürüstçe hepsini takip eder. Ne yapmalı:

• Hangi filtre kombinasyonlarının gerçek arama talebi olduğunu belirleyin. Genellikle bunlar tek filtreler ve nadir ikili olanlardır: "kırmızı spor ayakkabı", "16 inç dizüstü". Bunları benzersiz içerik, başlık ve açıklamalarla açık bırakıyoruz.
• Diğer tüm kombinasyonlar, sıralamalar, görünüm değiştiriciler ve sayfa başına adet, indekslenebilir URL üretmemeli. Seçenekler: temel kategorinin kanonik adresini belirtmek, filtrelemeyi URL değiştirmeden uygulamak, noindex direktifini kullanmak.
• Değersiz kombinasyonlara bağlantılar HTML'de normal bağlantı olmamalı. Bot onları görmezse onlara harcama yapmaz. Bu en ekonomik seçenektir.

Sayfalama ve sonsuz uzaylar

Yüzlerce sayfalık listeler, sonsuz ileri sayfalama içeren etkinlik takvimleri, güne göre arşivler - hepsi botun takılabileceği "sonsuz uzaylar"dır. Çözümler: sayfalama derinliğini makul bir sayıyla sınırlamak, boş tarihlere bağlantı oluşturmamak, bota derin öğelere yalnızca sıralı sayfalama yerine kategoriler ve etiketler üzerinden doğrudan bağlantılar vermek.

Teknik kökenli kopyalar

Aynı içerik, sonunda eğik çizgi olan ve olmayan adreslerden, büyük ve küçük harfli, index.php'li ve index.php'siz, http ve https, www'li ve www'siz, utm etiketli ve etiketsiz erişilebilir. Her varyant ayrı bir istektir. Kural basit: bir içerik - bir adres. Tüm varyantlar ana adrese 301 yönlendirmesi vermeli veya en azından kanonik adres içermeli. Bunu seçici olarak değil, tüm siteyi bir tarayıcıyla toplu olarak kontrol edin.

Yönlendirme zincirleri ve kırık bağlantılar

301 alan bot ikinci bir istek yapar. Orada da yönlendirme varsa üçüncü. Dört yönlendirmeli bir zincir, tek bir sayfa için beş istek harcar. Üstelik uzun zincirler tamamen kopabilir: bot birkaç atlamadan sonra takibi bırakabilir. Silinmiş sayfalara giden dahili bağlantılar için de benzer: her geçiş, 404 döndüren bir istek, yani boşa atılan bütçedir. Görev: tüm dahili bağlantılar doğrudan 200 yanıtlı nihai adrese yönlendirmeli.

Yumuşak 404'ler ve boş sayfalar

200 koduyla "ürün bulunamadı" sayfası, boş kategori, sonuçsuz arama - hepsi soft 404'tür. Bot tam bir yanıt alır, işlemeye kaynak harcar ve sonra içeriğin olmadığını anlar. Boş sayfalar dürüst bir 404 veya 410 vermeli ya da hiç var olmamalı.

Site içi arama ve servis bölümleri

Site içi arama sonuç sayfaları, sepet, kişisel hesap, ürün karşılaştırma sayfaları, yazdırma sürümleri - bot bunlara bağlantılar üzerinden girmemeli. Burada bot direktifleri işe yarar, ancak bu aracın blogdaki ayrı bir yazıda ayrıntılı ele alındığını unutmayın.

Önemli nüans: noindex bütçeyi korumaz

Yaygın bir yanılgı: noindex koyduk, sorun çözüldü. Hayır. noindex'i görmek için bot sayfayı istemek zorundadır. Bunu indekslenebilir sayfalardan daha seyrek yapar ama yapar. Bütçeyi koruyan tek şey: URL'ye bağlantı olmaması veya taramanın yasaklanması. Zaten indekslenmiş çöpü kaldırmak için en hızlı yol 410 kodudur: sayfanın kalıcı olarak silindiğini kesin olarak bildirir ve bot 404'ten daha hızlı geri gelmeyi bırakır.

Düzeltmeleri önceliklendirme algoritması

1. Her sızıntı kaynağı için log analizinden bot isteklerinin payını yazın.
2. Düzeltmenin zorluğunu değerlendirin: sunucu yapılandırması - kolay, şablon değişikliği - orta, filtre mantığının yeniden işlenmesi - zor.
3. Riski değerlendirin: değişiklikler trafiğe veya kullanıcı senaryolarına dokunabilir mi.
4. "Büyük pay - basit düzeltme - düşük risk" kombinasyonuyla başlayın. Genellikle bunlar yönlendirmeler, kırık bağlantılar ve teknik kopyalardır. Sonra parametrelere ve fasetlere geçin.
5. Her aşamadan sonra bota iki-üç hafta verin ve logları yeniden inceleyin. Boşalan bütçe değerli sayfalara yeniden dağılmalı. Bu olmadıysa üçüncü yönteme geçin.

Yöntem 3: Site mimarisi ve bot için öncelik sinyalleri

Bütçeyi boşaltmak işin yarısı. Şimdi onu fayda getireceği yere yönlendirmek gerek. Bot sinyalleri takip eder ve bunların başlıcaları bağlantı yapısı ve tazeliktir.

Öncelik ölçüsü olarak tıklama derinliği

Sayfa ana sayfadan bağlantı zincirinde ne kadar uzaksa, tarama kuyruğundaki önceliği o kadar düşer. Pratik kural: trafik getirmesi gereken tüm sayfalar ana sayfadan en fazla üç-dört tıklamayla erişilebilir olmalı. Yirminci sayfalamadaki alt kategorideki ürün yedi-sekiz derinliktedir - bot için bu neredeyse görünmez bölgedir. Derinlik nasıl kısaltılır:

• Hub sayfaları: onlarca nihai sayfaya konuya göre bağlantı toplayan bölümler.
• Kart ve makalelerde çapraz bağlantı blokları: "benzer ürünler", "bunları da okuyun", "birlikte görüntülenenler". Hem kullanıcıları tutar hem bota ek yollar oluşturur.
• Yeni sayfalara ana sayfa ve bölümlerden bağlantılar: "yeniler" bloğu keşif ve taramayı doğrudan hızlandırır.
• Derin içeriğe alternatif rotalar olarak etiket ve tematik seçkiler.

Talep yakıtı olarak tazelik

Bot bir şeyin değiştiği yere daha sık gelir. Ancak değişiklik gerçek olmalı: güncellenmiş açıklama, yeni yorumlar, güncel fiyat, genişletilmiş makale bölümü. İçeriği değiştirmeden yayın tarihini değiştirmek hızla fark edilir ve aleyhinize çalışır. İyi bir pratik yöntem, önemli sayfalara dinamik ama anlamlı bloklar koymaktır: son yorumlar, güncel kampanyalar, ilgili yeniler. Sayfa yaşar ve bot bunu görür.

Dürüst Last-Modified başlıkları

Sunucu son değişiklik tarihini doğru veriyorsa ve koşullu istekleri destekliyorsa, bot sayfayı kontrol edip gövde indirmeden 304 Not Modified yanıtı alabilir. Bu çok ucuz bir istektir: limiti neredeyse hiç harcamaz ve güncellik bilgisini tazeler. Bunu tüm statik veya seyrek değişen sayfalar için yapılandırın. Ancak başlık dürüst olmalı: tarih her istekte değişirse bot ona güvenmeyi bırakır.

Yetersiz içeriğin birleştirilmesi

Yakın konularda yüz kelimelik on sayfa, bot için on istek ve muhtemelen on "indeksleme" kararıdır. Bin kelimelik tek tam sayfa, bir istek ve indekse girme olasılığı yüksektir. Zayıf sayfa kümelerini arayın: açıklamasız ürün kartları, kısa haberler, tek özellik sayfaları. Bunları birleştirin ve eski adreslerden yeni sayfaya yönlendirme yapın.

Yeni sayfaların kontrollü yayını

Sık yapılan hata, bir günde siteye yüz bin yeni adres koymaktır. Bot artışı görür ama bütçesi anında büyümez. Kuyruk aylara yayılır ve yeni sayfaların önceliği rastgele dağılır. Dalgalar halinde yayınlamak daha iyidir: önce en değerli bölümler, üst düzeylerden doğrudan bağlantılarla, sonra diğerleri. Ve birkaç hafta önceden sunucu altyapısını ve dahili çapraz bağlantıyı güçlendirin.

Sinyallerin tutarlılığı

Bot, sinyaller birbiriyle çeliştiğinde kaybolur. Kanonik adres, üçüncüye yönlendiren bir sayfaya işaret ediyor. Dil sürümleri birbirine yanlış bağlanıyor. Sitemap noindex'li adresler içeriyor. Her çelişki, açıklığa kavuşturmak için ekstra istek ve siteye genel güvenin düşmesi demektir. Üç ayda bir tutarlılık kontrolü yapın: tüm kanonik adresler 200 veriyor, hepsi kendine işaret ediyor, site içindeki tüm bağlantılar kanonik sürümlere gidiyor.

Mimari kontrol listesi

• Tüm değerli sayfalar ana sayfadan 3-4 tıklamayla erişilebilir.
• Yeni sayfalar ilk 24 saat içinde bölümlerden bağlantı alır.
• Ticari URL'ler arasında yetim sayfa yok.
• Last-Modified ve koşullu istek desteği yapılandırılmış ve doğru.
• Zayıf sayfa kümeleri birleştirilmiş veya silinmiş.
• Kanonik adresler, yönlendirmeler ve dil öznitelikleri birbiriyle çelişmiyor.
• Yeni bölümlerin yayını önceden hazırlıkla dalgalar halinde planlanıyor.

Yöntem 4: Performans, render ve sürekli indeksleme izleme

Dördüncü yöntem, bütçenin teknik tavanı ve kontrol sistemiyle ilgili. Burada geliştiricilerin rolü özellikle büyük ve pazarlamacıların tam olarak ne talep edeceklerini anlaması önemli.

Bot için yanıt hızı

Tarama limiti, sunucunun bota ne kadar hızlı yanıt verdiğine doğrudan bağlıdır. Kilit metrik ilk bayta kadar geçen süredir. Pratik gösteriyor: 300-500 milisaniyeden hızlı istikrarlı yanıtlarda bot yoğunluğu kademeli olarak artırır, bir-iki saniyeden uzun yanıtlarda düşürür. Dikkat: önemli olan bot için hız, tarayıcı önbelleği ısınmış kullanıcı için değil. Bot sıklıkla soğuk sayfaları ister, bu nedenle yetkisiz istekler için sunucu tarafında HTML önbellekleme en büyük etkiyi verir. Yanıt süresini genel analitikten değil, bot filtresiyle loglardan kontrol edin.

Sunucu hataları ve aşırı yük kodları

5xx yanıtları bütçeyi çökertmenin en hızlı yoludur. Bir saatte birkaç yüz hata, botun yoğunluğu günlerce düşürmesine neden olabilir. Sunucu gerçekten aşırı yüklüyse, 503 veya 429'u Retry-After başlığıyla vermek daha doğrudur: bu "sonra gel" anlamına gelen ve site arızası olarak algılanmayan açık bir sinyaldir. Ancak yalnızca geçici olarak kullanılmalı. Ayrı ve sinsi bir sorun: botu engellemeye veya ona doğrulama sayfası göstermeye başlayan aşırı yük ve şüpheli etkinlik koruma sistemleri. Loglarda bu, içerik yerine 403 yanıtları veya captcha kodlu 200 olarak görünür. Arama botlarının resmi IP aralıklarını mutlaka koruma sistemlerinin istisnalarına ekleyin ve botun tam olarak sizin içeriğinizi gördüğünü düzenli olarak kontrol edin.

Sürprizsiz render

JavaScript çerçeveleri kullanan siteler için 2026 standardı sunucu tarafı render veya HTML'nin önceden oluşturulmasıdır. Bot, kritik içeriğin ve tüm bağlantıların tamamını kaynak kodda almalı. Bunu web yöneticisi panelindeki URL kontrol aracıyla doğrulayın: render edilmiş HTML'i kullanıcının gördüğüyle karşılaştırın. Ürün bağlantıları yalnızca script çalıştırıldıktan sonra ortaya çıkıyorsa, yeni sayfaların keşfi haftalarca gecikecektir. HTML boyutunu da izleyin: botlar indirilen belgenin hacmini sınırlar ve megabaytlarca gömülü veri içeren ağır sayfalar eksik işlenebilir.

Yapay zeka tarayıcıları ve kaynak rekabeti

Yeni gerçeklik: dil modelleri için veri toplayan botlar, tüm otomatik yükün yüzde onlarcasını üretebilir. Doğrudan arama trafiği getirmezler ama sunucuyu yavaşlatır ve bu nedenle arama botları için limit düşer. Çözüm, loglarda bu tür botların payını değerlendirmek ve hangilerine hangi yoğunlukta erişim izni verileceğine bilinçli karar vermektir. Bir kısmı standart direktiflere saygı duyar, geri kalanlar için sunucu düzeyinde istek hızı sınırlaması kullanılır. Bu, faydalı etkinliği engellemek değil, altyapınızın kaynaklarını yönetmektir.

İndeksleme izleme sistemi

Tek seferlik analiz bir ay sonra eskir. Bir sisteme ihtiyaç var. Adım adım nasıl kurulur.

1. Loglardan günlük metrik toplama. Bot istek sayısı, URL kategorilerine göre dağılım, hata payı, ortalama yanıt süresi. Bir tabloya veya veritabanına aktaran bir scriptle otomatikleştirilir.
2. Web yöneticisi panellerinde haftalık durum kontrolü. İndekslenen sayfa sayısının dinamiği, hariç tutulanların artışı, yeni hata türlerinin ortaya çıkışı.
3. İndekste gerçek varlığın kontrolü. Paneller verileri gecikmeyle gösterir ve her zaman tam değildir. Kritik sayfalar - yeni açılış sayfaları, ürünler, makaleler - için tam URL veya benzersiz metin parçasıyla doğrudan arama sonuçlarında varlığını kontrol etmek faydalıdır. Toplu kontrollerde arama motorları tek bir IP adresinden hızla captcha göstermeye başlar. Burada rotasyonlu mobil proxy'ler yardıma gelir: istekler gerçek mobil operatörlerin adreslerine dağıtılır, bu da verileri istikrarlı ve sitenizin boyutuna uygun hacimde toplamanızı sağlar. Ayrıca belirli bir bölgenin proxy'si üzerinden arama sonuçlarını o bölgenin kullanıcılarının gördüğü gibi görebilirsiniz; bu, bölgesel bağlantısı olan siteler için kritiktir.
4. Botlar için site erişilebilirliğini farklı ağlardan kontrol etme. Koruma sistemlerinin içerik yerine captcha veya engelleme vermediğinden emin olmak için kilit sayfaları harici IP adreslerinden, mobil ağlar dahil, periyodik olarak isteyin. Bu, tarama istatistiklerine yansımadan önce sorunları ortaya çıkaran proxy üzerinden basit bir kontrol.
5. Bildirimler. Bota yönelik hatalarda keskin artış, istek sayısında gün içinde yüzde 30'dan fazla düşüş, loglarda yeni URL kalıplarının ortaya çıkışı için uyarılar kurun. Erken tepki, haftalarca süren toparlanma kazandırır.

Böyle bir izleme konturu, crawl budget yönetimini tek seferlik bir eylemden sürekli bir sürece dönüştürür. Ve sonucu korumanın tek yolu budur.

Crawl budget'ı yakan tipik hatalar

Yapılmaması gerekenleri tek yerde toplayalım. Bu maddelerin her biriyle gerçek projelerde karşılaştık ve neredeyse her biri sahiplerine aylarca kaybedilmiş görünürlüğe mal oldu.

• Toplu zorunlu yeniden tarama gönderimleri. İndeksleme isteği araçları tek tek önemli sayfalar için tasarlanmıştır. Scriptlerle günlük binlerce URL göndermek bütçeyi artırmaz, sistemin isteklerinizi görmezden gelmeyi öğrenmesine neden olur. Yalnızca gerçekten değişen ve önemli olanı gönderin.
• Bütçe koruma yöntemi olarak noindex'e güvenmek. Zaten söyledik: bot yine gelir. Görev istek harcamamaksa, indekslemeyi yasaklamak değil, bağlantıları kaldırmak veya taramayı yasaklamak gerekir.
• Analizde sahte botları görmezden gelmek. IP kontrolü olmadan gerçek bot ile rakip parser'ların karışımını analiz edersiniz. Sonuçlar yanlış olur.
• "Ne olur ne olmaz" diye açık bırakılan filtre sayfaları. "Belki bu sorguyu biri arar" argümanı milyonlarca taranan kombinasyona yol açar. Yalnızca talebin kanıtlandığı yerleri açın.
• Plansız ani URL yapısı değişikliği. Tüm siteyi aynı anda yeni adreslere taşımak kuyruğu ikiye katlar: bot hem eski yönlendirmeleri hem yeni sayfaları taramak zorundadır. Bölüm bölüm planlayın.
• "Yalnızca botlar için" yavaş sunucu. Kullanıcılar önbelleğe alınmış sayfalar alır, bot ise veritabanı sorgularıyla soğuk üretim alır. Yavaş bir site görür ve limiti düşürür.
• Arama botlarını engelleyen DDoS koruması. Klasik: koruma hizmeti bağlandıktan sonra indeksleme durdu ve loglarda bot için baştan sona 403 var. Bot aralıkları beyaz listede olmalı.
• İçerik ve bağlantılar yalnızca JavaScript üzerinden. Bot onları gecikmeyle görür veya hiç görmez. Kritik öğeler kaynak HTML'de olmalı.
• "Sorgular için" binlerce sayfanın otomatik üretimi. Benzersiz değeri olmayan şablon sayfalar yalnızca indekslenmez değil, tüm sitenin değerlendirmesini de aşağı çeker. Bütçe harcanır, sonuç olumsuz olur.
• Düzeltmelerden sonra izlemenin olmaması. Analiz yapıldı, düzeltildi, unutuldu. Altı ay sonra yeni sürüm URL'ye parametre ekledi ve her şey tekrarlandı. Kontrol sürekli olmalı.
• Gerçek güncellemenin sahte olanla değiştirilmesi. "Tazelik" için tarih değiştirme, paragrafları yeniden düzenleme, boş bloklar ekleme. Sistem bunu fark eder ve önceliği artırmak yerine düşürür.

Bu listede projenizden en az üç madde tanıdıysanız yalnız değilsiniz. Gözlemlerimize göre ortalama bir e-ticaret sitesinde bu sorunlardan beş-altısı aynı anda bulunur. İyi haber şu ki hepsi çözülebilir.

İndeksleme ile çalışmak için araçlar ve kaynaklar

Doğru araç seti, analizi haftalardan günlere indirir. Görevlere göre ayıralım.

Web yöneticisi panelleri

Google Search Console ve Yandex Webmaster zorunlu temeldir. İlkinde, hariç tutma nedenlerine göre ayrılmış sayfa indeksleme raporu, ana makine, yanıt kodları ve dosya türlerine göre verilerle tarama istatistikleri raporu ve render edilmiş HTML'i görme imkânı sunan URL kontrol aracı kritik önemdedir. İkincisinde, tarama geçmişiyle indeksleme bölümleri, tarama istatistikleri, site teşhisi ve günlük kotalı yeniden tarama aracı. Her iki kaynak da gecikmeli toplu veri verir, bu nedenle tek kaynak olarak değil, pusula olarak kullanılır.

Log analizörleri

• Screaming Frog Log File Analyser - orta hacimler için kullanışlı masaüstü aracı: log içe aktarma, bot doğrulama, tarayıcı verileriyle eşleştirme.
• GoAccess - sunucuda hızlı özet için hafif analizör.
• ClickHouse veya Elasticsearch tabanlı görselleştirmeli yığın - günde milyonlarca satır içeren büyük projeler için çözüm. Gerçek zamanlı dashboard ve uyarılar oluşturmaya olanak tanır.
• Python ile kendi scriptleriniz, log ayrıştırma kütüphaneleri ve toplama için pandas ile - geliştiriciler için en esnek seçenek.

Yapı denetimi için tarayıcılar

Screaming Frog SEO Spider, Sitebulb, Netpeak Spider ve büyük siteler için bulut çözümleri. Görev, site URL'lerinin tam listesini tıklama derinliği, durum kodları, kanonik adresler, yönlendirmeler ve dahili bağlantılarla elde etmektir. Bu listenin loglarla eşleştirilmesi dört kadran matrisini verir. Önemli bir seçenek: normal modla karşılaştırmak için JavaScript yürütmeli tarama modu. Fark, botun gecikmeyle ne göreceğini gösterir.

Performans kontrolü

Genel tablo için Lighthouse ve PageSpeed Insights, ancak crawl budget için sunucu metrikleri daha önemli: bot filtresiyle loglardan ilk bayta kadar süre, birkaç noktadan erişilebilirlik izleme, büyük yayınlar öncesi yük testi.

İndekste varlık ve bölgesel arama sonuçlarının izlenmesi

Toplu indeksleme ve sıralama kontrolü için kendi scriptleriniz veya SERP servisleri kullanılır. Her iki durumda da arama motorlarına yönelik istek hacmi önemlidir ve tek bir adresten hızla captcha'ya takılırlar. Rotasyonlu mobil proxy'ler bu görevi çözer: istekler gerçek mobil operatörlerin adreslerinden gider, bir havuza dağıtılır ve bölge hedeflemesi, arama sonuçlarını istediğiniz şehirden bir kullanıcının gözüyle görmenizi sağlar. Bu özellikle bölgesel alt alan adlarına sahip projeler ve aynı anda onlarca açılış sayfasının indekslenmesini izleyen arbitrajcılar için önemlidir. Aynı araç, sitenin mobil ağ kullanıcılarına nasıl yanıt verdiğini ve korumanın meşru trafiği engelleyip engellemediğini kontrol etmeye de yardımcı olur.

Arama motoru bildirimleri

IndexNow protokolü, yeni ve değişen sayfaları destekleyen sistemlere, Yandex dahil, anında bildirmenizi sağlar. Bu bütçeyi artırmaz ama botun öncelikleri belirlemesine ve değişmeyen sayfaları yeniden kontrol etmek için istek harcamamasına yardımcı olur. Bunu tüm siteyi toplu göndermek için değil, gerçek değişiklikler için kullanın.

Vaka çalışmaları: bütçe yönetimi indekslemeyi pratikte nasıl değiştiriyor

Teori ikna eder, sayılar kanıtlar. Uygulamadan, anonimleştirilmiş verilerle üç vaka.

Vaka 1: elektronik e-ticaret sitesi, 180 bin ürün

Sorun. Yeni ürünler yayınlandıktan 18-25 gün sonra indekse giriyordu. 180 bin ürün varken indekste yaklaşık 70 bin sayfa bulunuyordu. Web yöneticisi paneli "keşfedildi, indekslenmedi" durumunda 2,3 milyon URL gösteriyordu.

Teşhis. 45 günlük log analizi şunu gösterdi: bot günde yaklaşık 95 bin istek yapıyordu. Bunun yüzde 61'i sıralama ve filtre parametreli URL'lere, yüzde 12'si onuncu sayfadan sonraki sayfalamaya, yüzde 8'i iki yıl önceki taşınmadan kalan eski adreslerin yönlendirmelerine gidiyordu. Ürün kartlarına isteklerin yüzde 14'ü düşüyordu.

Eylemler. Sıralama ve görünüm değiştiricilere bağlantılar URL'siz öğelerle değiştirildi. Talebi kanıtlanmış 340 filtre sayfası açık bırakıldı, geri kalanı kategori kanonik adresi aldı. Sayfalama 30 sayfayla sınırlandı ve derin ürünlere erişim için etiket seçkileri eklendi. Yönlendirme zincirleri tek adıma indirildi, dahili bağlantılar nihai adreslere güncellendi. Değişmeyen sayfalar için 304 verilmesi açıldı.

8 hafta sonra sonuç. Botun toplam istek sayısı neredeyse değişmedi - günde yaklaşık 100 bin. Ancak ürün kartlarının payı yüzde 14'ten yüzde 58'e çıktı. Yeni ürünler 2-4 günde indekse girmeye başladı. İndekslenen sayfa sayısı 152 bine yükseldi. Ürün kartlarında organik trafik, tek bir yeni harici bağlantı olmadan çeyrekte yüzde 34 arttı. Şaşırtıcı olan şu: sunucu yükü de azaldı, çünkü bot veritabanına ağır filtre sorguları üretmeyi bıraktı.

Vaka 2: trafik arbitrajı için 40 sitelik ağ

Sorun. Sahip, birkaç düzine alan adında kampanyalar için açılış sayfaları yayınlıyordu. Açılış sayfalarının bir kısmı bir günde indeksleniyor, bir kısmı haftalarca indekslenmiyordu ve bunu öngörmek imkânsızdı. İndekslemeyi manuel kontrol etmek saatler alıyor ve sürekli captcha'ya takılıyordu.

Teşhis. Loglar, genç alan adlarında botun günde 20-40 istek yaptığını ve bunun yarısının şablonun servis sayfalarına gittiğini gösterdi: politikalar, formlar, her açılış sayfasında kopyalanan teşekkür sayfaları. Ayrıca alan adlarının üçte birinde koruma hizmeti bota içerik yerine doğrulama sayfası gösteriyordu.

Eylemler. Şablonun servis sayfaları navigasyondan çıkarıldı ve taramaya kapatıldı. Bot aralıkları korumanın istisnalarına eklendi. Yeni açılış sayfaları yayınlandığı anda alan adının ana sayfasından bağlantı almaya başladı ve yeni sayfa bildirimi IndexNow ile gönderildi. İndeksleme izleme otomatikleştirildi: günlük bir script, her açılış sayfasının arama sonuçlarındaki varlığını rotasyonlu mobil proxy havuzu üzerinden, captcha olmadan ve her kampanya için bölgesel kontrolle doğruluyor.

Sonuç. Açılış sayfasının indekse girmesinin medyan süresi 9 günden 1,5 güne düştü. Bir haftada indekslenmeyen sayfaların oranı yüzde 38'den yüzde 4'e indi. İndeksleme kontrolüne harcanan süre günde birkaç saatten sıfır manuel işe düştü: rapor otomatik geliyor.

Vaka 3: JavaScript çerçevesinde medya portalı, 400 bin makale

Sorun. İstemci tarafı render'a geçtikten sonra yeni makaleler indekste 3-7 gün gecikmeyle görünüyordu ve bir haber kaynağı için bu felakettir. Panel, "tarandı, indekslenmedi" durumundaki sayfa sayısının arttığını gösteriyordu.

Teşhis. URL kontrolü, kaynak HTML'in yalnızca iskelet içerdiğini, tüm metin ve ilgili materyal bağlantılarının script ile yüklendiğini gösterdi. Bot sayfayı alıyor, render kuyruğuna koyuyor ve içeriği ancak günler sonra görüyordu. Akıştan yeni makalelere bağlantılar da yalnızca render sonrası ortaya çıkıyordu, bu yüzden keşif gecikiyordu. Ayrıca loglar, yapay zeka tarayıcılarının tüm otomatik yükün yüzde 44'ünü ürettiğini ve yoğun saatlerde arama botuna yanıt süresinin 2,5 saniyeyi aştığını gösterdi.

Eylemler. Makale ve akış sayfaları için sunucu tarafı render uygulandı, kritik içerik ve bağlantılar kaynak HTML'e taşındı. Yapay zeka tarayıcıları için sunucu düzeyinde istek hızı sınırlaması getirildi. Yetkisiz istekler için ayrı bir HTML önbellekleme katmanı yapılandırıldı. Ana sayfaya doğrudan bağlantılarla son materyaller bloğu eklendi.

6 hafta sonra sonuç. Bota yanıt süresi ortalama 280 milisaniyeye düştü. Arama botunun istek sayısı 2,1 kat arttı - limit hızın ardından yükseldi. Yeni makaleler 20-60 dakikada indekslenmeye başladı. "Tarandı, indekslenmedi" sayfa sayısı yüzde 71 azaldı. Teknik olarak bu kadar basit bir çözümün - içeriği HTML'de vermenin - bu etkiyi yaratması hayranlık verici.

SSS: site indeksleme ve crawl budget hakkında zor sorular

Gerçekten crawl budget sorunum mu var, yoksa içerik kalitesi sorunu mu, nasıl anlarım?

Durumlara bakın. "Keşfedildi, indekslenmedi" ağırlıklıysa bot sayfalara ulaşmıyor, bu bütçe ve öncelik sorunudur. "Tarandı, indekslenmedi" ağırlıklıysa bot ulaştı ama reddetti, bu kalite veya kopyalama sorunudur. Genellikle her iki sorun da mevcuttur ve o zaman birincisini çözmek ikincisini keskinleştirir: boşalan bütçe, yine de indekslenmeyecek sayfalara harcanır. Paralel çalışın: sızıntıları temizleyin ve aynı zamanda zayıf içeriği iyileştirin veya birleştirin.

Crawl budget'ı arama motorundan rica ederek doğrudan artırabilir miyim?

Hayır. Limitin manuel yükseltilmesi için araç yok ve daha önce mevcut olan tarama hızı ayarları kaldırıldı. Bütçe yalnızca iki kanaldan büyür: hızlı ve istikrarlı sunucu teknik limiti yükseltir, içeriğin değerinin ve güncelliğinin artması bağlantı profiliyle birlikte talebi yükseltir. Geri kalan her şey, mevcut kaynağın dağılımını yönetmektir.

Düzeltmeler ile botun davranışının değişmesi arasında ne kadar zaman geçer?

Loglarda ilk hareketler 7-14 gün içinde görülür: bot silinen kalıpları daha seyrek istemeye başlar. Kalıcı yeniden dağılım 4-8 hafta alır. Eski URL yığınlarının tamamen unutulması aylar, bazen bir yıldan fazla sürer: bot periyodik olarak geri dönüp tekrar ortaya çıkıp çıkmadıklarını kontrol eder. Anında etki beklemeyin ve bir hafta sonra değişiklikleri geri almayın.

Yapay zeka tarayıcıları arama motorlarındaki indekslemeyi etkiliyor mu?

Doğrudan - hayır, arama botlarının kendi bağımsız bütçesi vardır. Dolaylı olarak - evet. Yapay zeka botları, sunucunun arama botuna daha yavaş yanıt vermesine neden olan yük üretiyorsa tarama limiti düşer. Çözüm topyekûn engellemede değil, yönetimde: her botun loglardaki payını değerlendirin, değer getirmeyenler için istek hızını sınırlayın ve arama botuna yanıt süresini ayrıca izleyin.

Bütçeyi boşaltmak için düşük trafikli sayfaları indeksten kaldırmalı mıyım?

Yalnızca analizden sonra. Trafiksiz bir sayfa bir kümenin parçası olabilir, diğer sayfaları bağlantılarla destekleyebilir veya doğrudan ziyaretlerle dönüşüm değeri taşıyabilir. Kaldırma kriteri trafiğin kendisi değil, benzersiz değerin yokluğudur: kopyalar, eski boş kartlar, zayıf şablon sayfalar. Bunları yönlendirmeyle birleştirmek veya 410 koduyla silmek daha iyidir. "Trafik getirmeyen her şeyi" toplu silmek çoğu zaman yardımcı olmaktan çok zarar verir.

Captcha bloğu almadan binlerce sayfanın indekslemesini nasıl doğru kontrol ederim?

İstekleri zaman ve IP adresleri arasında dağıtın. Tek bir adresten kontrol, birkaç düzine istekten sonra captcha'ya takılır. Rotasyonlu mobil proxy'ler bu görevi teknik olarak doğru çözer: her istek gerçek bir mobil operatör adresinden gider, bu da normal kullanıcı davranışına karşılık gelir. İstekler arasına duraklamalar ekleyin, başlık rotasyonu yapın ve tüm siteyi her gün değil, yalnızca gerçekten önemli sayfaları kontrol edin. Tam tablo için doğrudan kontrolleri web yöneticisi panellerinin verileriyle birleştirin.

Web yöneticisi panelinde taranan sayfa sayısı artarken indekslenen neden düşüyor?

Klasik sızıntı belirtisi: bot yeni bir çöp URL kaynağı keşfetti ve aktif olarak tarıyor, ancak bu sayfalar indekslemeye geçmiyor. Loglarda son haftalarda ortaya çıkan yeni adres kalıplarını arayın: sıklıkla bu, yeni parametreli bir sürümün, yeni bir widget'ın etkinleştirilmesinin veya bağlantı şablonundaki bir hatanın sonucudur. Kaynağı ne kadar hızlı bulursanız o kadar az temizleme gerekir.

500 sayfalık küçük bir site bir şey yapmalı mı?

Mutlak bütçe sorunları sizi tehdit etmez ama oranlar burada da önemlidir. 500 sayfanın 300'ü teknik kopya ve servis adresiyse, genç bir alan adında günde birkaç düzine isteklik bütçesi olan bot, büyük kısmını onlara harcayacaktır. Temel bir kontrol yapın: bir içerik - bir adres, yönlendirme zinciri yok, 404'e bağlantı yok, hızlı sunucu, ana sayfadan yeni sayfalara bağlantılar. Bu, site indekslemenin öngörülebilir çalışması için yeterlidir.

Botun içeriğimi gördüğünü, koruma hizmetinin doğrulama sayfasını görmediğini nasıl anlarım?

Üç yol. Birincisi - web yöneticisi panelindeki URL kontrol aracı: botun tam olarak ne aldığını gösterir. İkincisi - loglar: bota verilen yanıt kodlarına ve yanıt boyutuna bakın. Farklı sayfalar için boyut şüpheli biçimde aynı ve küçükse muhtemelen bir yedek sayfa sunuluyor. Üçüncüsü - sayfalarınızı farklı ağlardan, mobil dahil, harici adreslerden proxy üzerinden isteyin: koruma onlarda tetikleniyorsa botta da tetiklenme riski vardır. Arama botlarının aralıkları her koruma sisteminin beyaz listesinde olmalıdır.

Sonuç: yönetilebilir bir kaynak olarak crawl budget

Özetleyelim. Site indeksleme bir olay değil, sınırlı kaynağa sahip bir süreçtir. Arama botu size belirli bir istek limitiyle gelir ve bunları neye harcayacağı, hangi sayfaların arama sonuçlarına gireceğini ve ne kadar hızlı gireceğini belirler. Bu limit, sunucunun teknik gücü ile arama motorunun içeriğinize olan ilgisinden oluşur. Her iki bileşen de ölçülebilir ve geliştirilebilir.

Birlikte eksiksiz bir döngü oluşturan dört yöntemi inceledik. Log analizi nesnel tabloyu verir: bot gerçekte nereye gidiyor ve bütçe nerede sızıyor. Yiyicileri ortadan kaldırmak - fasetler, parametreler, kopyalar, yönlendirmeler, yumuşak 404'ler - kaynağı boşaltır. Mimari ve öncelik sinyalleri, boşalan kaynağı tıklama derinliği, çapraz bağlantı ve dürüst tazelik yoluyla değerli sayfalara yönlendirir. Performans ve izleme teknik tavanı yükseltir ve sorunların geri dönmesini engeller. Vakalar, botun istek sayısı değişmeden faydalı taramaların payının dört kat artırılabileceğini ve yeni sayfaların indekslenme süresinin haftalardan saatlere düşürülebileceğini gösterdi.

Sırada ne var? İlk ay için somut bir plan öneriyoruz.

1. 1. hafta. 30-60 günlük logları indirin, doğrulanmış botları filtreleyin, URL'leri sınıflandırın ve dört kadran matrisini oluşturun. Paralel olarak web yöneticisi panellerinden mevcut metrikleri başlangıç noktası olarak alın.
2. 2. hafta. Basit sızıntıları giderin: yönlendirme zincirleri, kırık dahili bağlantılar, teknik adres kopyaları. Bot aralıklarını korumanın beyaz listesine ekleyin. Bota yanıt süresini kontrol edin ve HTML önbelleklemeyi yapılandırın.
3. 3. hafta. Parametreler ve fasetlerle ilgilenin: değerli kombinasyonları belirleyin, geri kalanı bağlantılarda görünmekten kapatın. Sayfalamayı ve sonsuz uzayları sınırlayın. Kritik içeriğin ve bağlantıların kaynak HTML'de olduğunu doğrulayın.
4. 4. hafta. Mimariyi güçlendirin: değerli sayfalar için tıklama derinliğini kısaltın, çapraz bağlantı ve yeniler blokları ekleyin, Last-Modified ve 304 yanıtlarını yapılandırın. Otomatik izlemeyi başlatın: loglardan günlük metrikler, panellerden haftalık durumlar, bölgesel hedeflemeli mobil proxy havuzu üzerinden kilit sayfaların indekste varlığının kontrolü.

Başlangıçtan sekiz hafta sonra logları başlangıç noktasıyla karşılaştırın. Bot isteklerinde değerli sayfaların payı arttıysa ve yeni sayfaların indekse girme süresi kısaldıysa sistem çalışıyor demektir. Değilse kadran matrisine dönün: neredeyse her zaman hesaba katılmamış bir sızıntı kaynağı bulunur.

Crawl budget, SEO'da tamamen sizin kontrolünüzde olan nadir bir kaynak örneğidir. Arama motorunu sitenizi sevmeye zorlayamazsınız. Ama her ziyaretinin maksimum faydayla harcanmasını sağlayabilirsiniz. İndeksin seçici hale geldiği ve botun dikkati için rekabetin arttığı 2026'da bu artık teknik hijyen değil, rekabet avantajıdır. Bu rehberi kaydedin, çeyrek sonra kontrol listelerine dönün ve denetçinizin arka odalarda değil, satış salonlarında zaman geçirdiğinden emin olun.