Tarama bütçesi optimizasyonu nasıl yapılır? Teknik SEO rehberi

Tarama bütçesi optimizasyonu tam olarak neyi değiştirir?

Tarama bütçesi optimizasyonu, botların sitenizdeki sınırlı dikkatini ticari ve editoryal değeri olan URL’lere yöneltir. Google bu bütçeyi, bir siteyi aşırı yüklemeden tarayabileceği kapasite ile o siteyi tarama isteğini birlikte değerlendirerek açıklar. Buradaki “site” çoğunlukla benzersiz ana makine adıdır; alt alan adlarının davranışı ayrı incelenebilir.

Tarama kapasitesi, sunucunun yanıt verme durumuyla ilgilidir. Googlebot erişilebilirlik sorunu veya sunucu yükü gördüğünde isteklerini azaltabilir. Kapasitenin yüksek olması ise bütün URL’lerin mutlaka taranacağı anlamına gelmez. İçeriğin yararı, benzersizliği, popülerliği ve güncellik ihtiyacı tarama talebini etkileyen unsurlar arasındadır.

Tarama talebi düşükse güçlü bir sunucu tek başına daha yoğun ziyaret sağlamaz. Tersi durumda, yeni ve değerli sayfalarınız bulunsa bile sürekli 5xx yanıtları veya uzun kesintiler botun erişimini sınırlar. Bu nedenle çalışma yalnız hosting yükseltmesi ya da yalnız içerik temizliği olarak ele alınmamalıdır; iki taraf aynı teşhis tablosunda buluşmalıdır.

Bir URL’nin taranması, dizine ekleneceğini garanti etmez. Google taradığı içeriği işleyebilir, benzer sayfalar arasında kanonik seçebilir ve dizine uygunluğunu ayrıca değerlendirebilir. Sayfa dizinde yoksa önce keşif, erişim, oluşturma, kanonikleştirme ve kalite olasılıklarını ayırın. Doğrudan “bütçe bitti” demek, yanlış çözümü seçmenize yol açar.

Çalışmanın iş hedefi de açık olmalıdır. Binlerce düşük değerli filtre URL’sinin daha az taranması bir amaç olabilir; fakat asıl sonuç yeni ürünlerin, güncel kategorilerin veya önemli içeriklerin daha düzenli keşfedilmesidir. Teknik rapor, yalnız istek sayısını değil hangi URL grubunun ne kadar sürede yeniden görüldüğünü açıklamalıdır.

Her sitenin tarama bütçesi optimizasyonuna ihtiyacı var mı?

Hayır; düzenli taranan küçük sitelerde ayrı bir tarama bütçesi projesi çoğu zaman gerekli değildir. Google’ın güncel rehberi, hızlı değişmeyen küçük siteler için site haritasını güncel tutmanın ve Sayfa Dizine Ekleme raporunu izlemenin genellikle yeterli olduğunu belirtir. Bu ayrım, teknik emeği gerçek darboğaza yöneltmek açısından önemlidir.

Google’ın verdiği kaba sınıflandırmada, orta sıklıkta değişen bir milyonun üzerindeki benzersiz sayfalara sahip büyük siteler ile her gün değişen on binin üzerindeki URL’lere sahip orta ve büyük siteler öncelikli adaylardır. Bunlar kesin eşik değil, teşhise başlama işaretidir. “Keşfedildi, şu anda dizine eklenmiş değil” kümesi belirgin olan siteler de inceleme gerektirebilir.

URL sayısı tek başına karar verdirmez. Yüz bin ürünün büyük bölümü aylarca değişmiyorsa ihtiyaç, her gün stok ve fiyat yenileyen daha küçük bir pazaryerinden farklıdır. Haber siteleri, ilan platformları, çok şubeli portallar ve filtreli e-ticaret yapıları, yeni URL üretme hızları nedeniyle tarama davranışını daha yakından izlemelidir.

Kurumsal bir sitede onay bekleyen birkaç hizmet sayfası görünmüyorsa sorun çoğu zaman başka yerdedir. Sayfa menüden bağlanmamış, `noindex` kalmış, yanlış kanoniğe işaret etmiş veya zayıf içerikle benzer kümeye girmiş olabilir. Bu durumda geniş kapsamlı bütçe projesi yerine URL düzeyinde teknik teşhis daha hızlı sonuç verir.

Öncelik kararı için üç soruyu yanıtlayın: Önemli sayfalar makul sürede keşfediliyor mu, bot isteklerinin büyük bölümü istemediğiniz URL örüntülerine mi gidiyor, sunucu tarama sırasında erişilebilirlik sorunu gösteriyor mu? Sorulardan hiçbiri kanıtlanmıyorsa kaynaklarınızı içerik kalitesi, site mimarisi veya kullanıcı deneyimi gibi başka çalışmalara ayırabilirsiniz.

Site tarama analizi hangi verilerle yapılır?

Site tarama analizi en az üç veri katmanını birleştirir: arama motorunun raporu, sunucunun gerçek istek kayıtları ve sitenin kendi URL envanteri. Search Console eğilimi gösterir; erişim logu hangi botun hangi URL’ye ne zaman ve hangi durum koduyla geldiğini kaydeder; tarama aracı ise iç bağlantılarla erişilebilen yapıyı çıkarır.

Search Console Tarama İstatistikleri raporunda toplam istekleri tek başına başarı göstergesi saymayın. Yanıt kodu, dosya türü, Googlebot türü, tarama amacı ve ortalama yanıt süresi kırılımlarını inceleyin. Ani değişimin yayın, site taşıma, sunucu kesintisi veya yapılandırma güncellemesiyle aynı döneme denk gelip gelmediğini bir değişiklik günlüğü üzerinden kontrol edin.

Loglarda kullanıcı aracısı metnine körü körüne güvenmeyin; kötü niyetli bir istemci kendini Googlebot gibi tanıtabilir. Google, bot kimliğini ters ve ileri DNS aramasıyla ya da yayımladığı IP aralıklarıyla doğrulamak için resmi yöntem sunar. Analize doğrulanmamış botları katmak, gerçek tarama talebini ve sunucu yükünü olduğundan farklı gösterebilir.

URL envanterini yalnız XML site haritasından oluşturmayın. İç tarama sonuçlarını, site haritalarını, analitik açılış sayfalarını, Search Console dışa aktarımlarını ve loglarda görülen URL’leri birleştirin. Bir kaynakta bulunup diğerinde bulunmayan kümeler özellikle değerlidir: logda var, iç taramada yoksa eski bağlantı veya dış kaynak; site haritasında var, logda yoksa keşif sorunu araştırılabilir.

Her URL’yi tek tek yorumlamak yerine şablon ve örüntü üretin. Ürün, kategori, filtre, arama, etiket, sayfalama, dosya ve API uç noktalarını ayırın. Büyük bir sitede kararın uygulanabilir birimi çoğu zaman tek sayfa değil URL sınıfıdır. Yine de örüntü içinden örnek URL’leri gerçek tarayıcı ve URL Denetleme aracıyla doğrulayın.

Bu ölçüler için “önemli” ve “gereksiz” tanımlarını rapor öncesinde yazın. Bugün stokta olmayan fakat yakında dönecek ürün, kalıcı biçimde kaldırılmış üründen farklı ele alınır. Tanım dönem içinde değişirse seriyi ayırın. Paydanın bilinmediği bir hesapta kesin oran vermek yerine kapsam eksikliğini açıkça belirtin.

Sunucu logları Googlebot davranışını nasıl gösterir?

Sunucu erişim kayıtları, gerçekleşen isteklerin en doğrudan kanıtıdır. Tipik bir satır zaman, istenen yol, HTTP yöntemi, durum kodu, aktarılan veri, kullanıcı aracısı ve bazen yanıt süresini içerir. Biçim Apache, Nginx, CDN veya bulut sağlayıcısına göre değişir; analize başlamadan alanların anlamını altyapı ekibiyle doğrulayın.

Önce saklama süresini ve saat dilimini belirleyin. Yayın kayıtları İstanbul saatiyle, sunucu kayıtları UTC ile tutuluyorsa keşif gecikmesini yanlış hesaplayabilirsiniz. CDN ve kaynak sunucu aynı isteği ayrı kaydedebilir. Tekilleştirme anahtarınız ile bot doğrulama yönteminiz belgelenmezse rapor tekrar üretilemez hale gelir.

Analizde URL grubu başına istek sayısı, son tarama zamanı, durum kodu dağılımı ve yanıt süresi okunabilir. Ancak log, Google’ın sayfayı dizine eklediğini söylemez; yalnız isteği ve sunucu yanıtını gösterir. İndeks durumu için Search Console URL Denetleme veya Sayfa Dizine Ekleme verisiyle eşleştirme gerekir.

Çok taranan URL otomatik olarak değerlidir, az taranan URL de otomatik olarak sorunlu değildir. Değişmeyen yasal metnin seyrek taranması normal olabilir. Buna karşılık saatlik güncellenen kategori günlerdir ziyaret almıyorsa iş ihtiyacıyla uyumsuzluk vardır. Yorumu URL’nin değişim sıklığı ve ticari rolüyle birlikte yapın.

Gizlilik ve güvenlik sınırlarını baştan kurun. Loglar IP adresi, sorgu parametresi veya kullanıcıya ait olabilecek başka veriler içerebilir. Gereksiz alanları maskeleyin, erişimi görevle sınırlayın ve saklama politikasına uyun. SEO incelemesi, kişisel veriyi süresiz çoğaltmak için gerekçe oluşturmaz.

Bir teknik SEO danışmanlığı kapsamında log teslimi isteniyorsa veri dönemi, bot doğrulaması, saat dilimi, URL normalizasyonu ve hariç tutulan kaynaklar raporda bulunmalıdır. Böylece ajansın bulgusu, ekran görüntüsüne değil tekrar çalıştırılabilir bir sorguya dayanır.

Hangi URL’ler taranmalı, hangileri sınırlandırılmalıdır?

Taranması gereken URL, kullanıcıya benzersiz bir değer sunan ve arama sonuçlarında bulunmasını istediğiniz kalıcı adrestir. Ürün, kategori, rehber veya hizmet sayfası bu tanıma girebilir. Sepet, hesap, oturum, dahili arama sonucu ve sonsuz kombinasyon üreten sıralama sayfaları ise çoğu projede ayrı bir değerlendirme ister.

Kararı URL’nin adına bakarak vermeyin. `?color=red` parametresi bazı mağazalarda yalnız aynı ürünleri süzerken, başka bir mağazada gerçek arama talebini karşılayan farklı bir kategori deneyimi oluşturabilir. İçerik, talep, stok devamlılığı ve yönetim kapasitesi incelenmeden bütün filtreleri kapatmak değerli uzun kuyruklu sayfaları erişilemez bırakabilir.

Her sınıfa bir hedef durum verin: indekslenebilir ve taranabilir; taranabilir fakat `noindex`; yinelenen ve kanoniğe bağlanan; taranması engellenen; kaldırılan; yönlendirilen. Aynı URL’ye çelişkili talimat vermeyin. Site haritasında yer alan, robots.txt ile engellenen ve başka sayfaya kanonik veren bir adres, niyetinizi açık biçimde anlatmaz.

Google, yinelenen içerikleri tek tercih edilen URL altında birleştirmek için `rel="canonical"` işaretini kullanabilir. Bu bir yönlendirme değildir ve mutlak komut sayılmaz. Kanonik hedefi iç bağlantılarda ve site haritasında da tercih etmek sinyalleri tutarlı kılar. Robots.txt, kanonikleştirme aracı olarak kullanılmamalıdır.

`noindex` kuralının görülebilmesi için botun sayfayı tarayabilmesi gerekir. URL’yi aynı anda robots.txt ile engellerseniz Google meta etiketi veya HTTP başlığını okuyamaz; adres başka bağlantılar nedeniyle içeriksiz biçimde sonuçlarda görünebilir. İndeksten çıkarma ile taramayı azaltma hedeflerini aynı işlem sanmayın.

Kaldırılmış içerik için eşdeğer bir karşılık varsa kalıcı yönlendirme düşünün. Karşılık yoksa anlamlı bir kullanıcı sayfasıyla birlikte 404 veya 410 durum kodu döndürmek doğrudur. Her eski ürünü ilgisiz kategoriye yönlendirmek, kullanıcıyı yanıltır ve soft 404 değerlendirmesine yol açabilir.

URL sınıflandırması, kurumsal SEO hizmeti satın alırken talep edeceğiniz en somut teslimlerden biridir. Liste yalnız hata adını değil önerilen durumu, örnek adresi, iş gerekçesini, uygulama sahibini ve test yöntemini içermelidir. Bu ayrıntı, geliştirici ekibin yoruma açık bir raporla vakit kaybetmesini önler.

E-ticaret filtreleri tarama alanını neden büyütür?

Filtreli gezinme, renk, beden, marka, fiyat ve sıralama seçeneklerini birleştirerek çok sayıda URL üretebilir. Kullanıcı için yararlı olan arayüz, her seçim sırası ayrı adres oluşturduğunda aynı listeyi farklı parametre dizilimleriyle tekrar sunabilir. Tarama alanı ürün sayısından daha hızlı büyüdüğü için kontrol URL üretim katmanında başlamalıdır.

Önce bütün filtreleri ve birleşim kurallarını çıkarın. Hangi kombinasyonun aranma talebi, benzersiz ürün kümesi ve açıklayıcı içeriği var? Hangi birleşim boş sonuç, tek ürün veya yalnız sıralama değişikliği üretiyor? Arama görünürlüğü hedeflenen sayfalar için temiz, kalıcı ve bağlantı verilebilir adresler tasarlamak genellikle rastgele parametreleri indeksletmekten daha yönetilebilirdir.

Filtre bağlantılarının gerçek HTML bağlantısı olup olmadığı keşfi etkiler. Google, `href` taşıyan `` öğelerini güvenilir biçimde ayrıştırır. JavaScript olayını bağlantı gibi kullanan öğeler aynı güveni sağlamaz. Fakat botun bağlantıyı bulamaması bilinçsizce uygulanan bir çözüm olmamalıdır; erişilebilirlik ve kullanıcıların klavye kullanımı da korunmalıdır.

Bir e-ticaret SEO danışmanlığı değerlendirmesinde ürün ekibi de masada olmalıdır. SEO açısından gereksiz görünen filtre, müşterinin stok bulmasını sağlayan temel özellik olabilir. Amaç filtreyi ortadan kaldırmak değil, kullanıcı işlevini korurken botun erişeceği kalıcı URL kümesini bilinçli biçimde sınırlamaktır.

Robots.txt, canonical ve XML site haritası nasıl birlikte kullanılır?

Bu üç araç farklı soruları yanıtlar. Robots.txt botun bir yolu isteyip isteyemeyeceğini düzenler; kanonik işareti benzer sayfalar arasındaki tercih edilen adresi bildirir; XML site haritası ise taranmasını ve aramada görünmesini istediğiniz URL’leri keşif için sunar. Birini diğerinin yerine kullanmak çelişkili sonuç üretir.

Site haritasına yalnız mutlak, doğru ve tercih edilen URL’leri ekleyin. Yönlendiren, 404 döndüren, robots.txt ile engellenen veya `noindex` taşıyan adresleri listeden çıkarın. Büyük yapılarda ürün, kategori ve içerik gibi mantıksal gruplara ayrılan site haritaları, hangi bölümün sorun yaşadığını Search Console üzerinden karşılaştırmayı kolaylaştırır.

`lastmod` değeri, sayfanın son önemli değişikliğini doğru yansıtmalıdır. Google, bu alanı sürekli ve doğrulanabilir biçimde doğru olduğunda kullanır; telif yılının değişmesi önemli güncelleme sayılmaz. Google ayrıca site haritasındaki `priority` ve `changefreq` değerlerini yok saydığını belirtir. Bu alanlarla bütçe yönettiğinizi varsaymayın.

Site haritası bir ipucudur; URL’nin indirileceğini, hemen taranacağını veya dizine ekleneceğini garanti etmez. Aynı değişmemiş haritayı gün içinde tekrar tekrar göndermek hız kazandırmaz. Yayın sistemi yeni veya anlamlı biçimde güncellenmiş URL’yi doğru `lastmod` ile eklemeli, kaldırılan URL’yi de envanter kararına göre listeden çıkarmalıdır.

Robots.txt dosyanızın ana makinenin kökünde erişilebilir ve geçerli olduğunu kontrol edin. Geniş joker kuralları, CSS veya JavaScript kaynaklarını yanlışlıkla engelleyebilir. Google engellenen bir sayfayı oluşturmaz; gerekli kaynakları göremezse sayfanın görünür içeriğini anlamakta zorlanabilir. Değişikliği canlıya almadan test aracı ve örnek isteklerle sınayın.

Kural matrisi hazırlamak uygulamayı güvenli kılar. Satırda URL sınıfı, sütunlarda HTTP durumu, robots izni, meta robots, kanonik, site haritası ve iç bağlantı yer alsın. Her satır tek bir hedef durumu anlatsın. Böylece “indekslenmesin ama kanonik okunsun” gibi bir ihtiyaçta taramayı açık bırakmanız gerektiği görünür olur.

İç linkler ve yönlendirmeler tarama verimliliğini nasıl etkiler?

Googlebot yeni URL’leri bağlantılardan, site haritalarından ve yönlendirmelerden keşfeder. Önemli sayfaların başka bir bulunabilir sayfadan standart `` bağlantısı alması gerekir. Yalnız site haritasında bulunan fakat kategori, menü veya ilgili içerikten bağlanmayan sayfa, mimarideki önemini açık biçimde göstermez.

JavaScript kullanan sitelerde bot neyi görebilir?

Google, JavaScript uygulamalarını tarama, oluşturma ve dizine ekleme aşamalarında işler. İlk HTTP yanıtındaki HTML bağlantıları çıkarılır; uygun sayfalar oluşturma kuyruğuna girebilir; oluşturulan HTML yeniden işlenir. Sayfanın tarayıcıda çalışması, Google’ın aynı anda bütün içeriği ve bağlantıları gördüğünü kanıtlamaz.

URL Denetleme ve Zengin Sonuçlar Testi ile oluşturulan HTML’yi, yüklenen kaynakları ve JavaScript hatalarını inceleyin. Kritik ürün adı, fiyat, açıklama, kanonik ve bağlantıların oluşturulan DOM’da bulunduğunu doğrulayın. Yalnız ekran görüntüsüne bakmak yeterli değildir; görünmeyen meta veriler ile bağlantı hedefleri kaynakta ayrıca kontrol edilmelidir.

Google bütün 200 yanıtlarını oluşturma için kuyruğa alabileceğini açıklar; süre birkaç saniyeden uzun olabilir. Bu bilgi, her JavaScript sitesinde haftalarca gecikme olacağı anlamına gelmez. Gerçek gecikmeyi yayın zamanı, logdaki tarama isteği, oluşturulan sonuç ve indeks durumu üzerinden kendi sitenizde ölçün.

Sunucu tarafı veya statik oluşturma, içeriği ilk yanıtta sunarak kullanıcılar ve botlar için dayanıklı bir temel oluşturabilir. Google dinamik oluşturmayı uzun vadeli çözüm olarak önermiyor; sunucu tarafı oluşturma, statik oluşturma veya hydration yaklaşımını öneriyor. Mimari seçimi yalnız SEO’ya değil geliştirme, önbellek ve kişiselleştirme ihtiyacına göre yapılmalıdır.

Sonsuz kaydırma kullanıyorsanız her içerik parçasına paylaşılabilir, kalıcı bir URL ve sıralı bağlantı yolu verin. Kullanıcının kaydırmasına veya butona basmasına bağlı içerik, bot etkileşim gerçekleştirmediğinde keşfedilmeyebilir. Sayfalama adresleri doğrudan istekle aynı içeriği döndürmeli ve önceki-sonraki yolları standart bağlantılarla sunmalıdır.

CSS ve JavaScript dosyalarını gelişigüzel engellemek oluşturmayı bozabilir. Aynı ortak kaynağı sayfalarda aynı URL’den sunmak önbellek kullanımına yardımcı olur. Kritik kaynak yüklenemediğinde sayfanın boş ya da hata mesajlı görünmesi soft 404 değerlendirmesine kadar uzanabilir. Üretim izleme sistemi, bot ve kullanıcı tarafındaki kaynak hatalarını birlikte takip etmelidir.

Sunucu sağlığı tarama kapasitesini nasıl korur?

Sunucu sağlığı, tarama kapasitesinin üst sınırını etkiler; fakat tek başına tarama talebi yaratmaz. Googlebot, sunucuyu zorlamamak için davranışını ayarlar. DNS, bağlantı ve 5xx sorunları önemli sayfaların alınmasını engelliyorsa önce erişilebilirliği düzeltin. Sırf istek sayısını artırmak amacıyla pahalı altyapı yatırımı yapmak doğru başlangıç olmayabilir.

Ortalama yanıt süresi yararlı bir eğilimdir, ancak uç değerleri gizleyebilir. URL şablonuna ve durum koduna göre yüzdelik dağılımlar, yavaş veritabanı sorgularını daha iyi gösterir. Ürün filtresi yüksek süre üretirken statik sayfalar hızlıysa genel ortalama sorunu küçültebilir. Uygulama izleme verisini loglarla aynı zaman çizelgesinde karşılaştırın.

HTTP önbellekleme, değişmeyen içerik için sunucu yükünü azaltabilir. Google, uygun koşullarda `If-Modified-Since` ve `If-None-Match` başlıklarını destekler; içerik değişmemişse gövdesiz 304 yanıtı kaynak tasarrufu sağlar. Başlıkların her istekte geleceğini varsaymayın. ETag ve son değiştirilme zamanının uygulama katmanında doğru üretildiğini test edin.

Geçici aşırı yükte 503 veya 429 yanıtları kullanılabilir; fakat bu bir kapasite stratejisi değil acil durum davranışıdır. Google, bu kodların uzun süre sürmesinin taramayı yavaşlatabileceğini ve URL’lerin dizinden düşmesine yol açabileceğini belirtir. Planlı bakımda kısa süreli doğru durum kodu, hata sayfasını 200 olarak sunmaktan daha açıklayıcıdır.

CDN, sayfa önbelleği ve veritabanı iyileştirmeleri ancak ölçülen darboğaza uygulanmalıdır. Bot trafiğini engellemeden önce gerçekten Googlebot olduğunu doğrulayın. Güvenlik duvarı kuralının önemli kaynakları veya Google’ın yayımladığı güncel IP aralıklarını yanlışlıkla kapsamadığını izleyin. Sabit IP listesini elle kopyalayıp süresiz bırakmak bakım riski doğurur.

Sunucu çalışmasıyla içerik kalitesini birbirine karıştırmayın. Düşük değerli binlerce sayfayı daha hızlı sunmak, Google’ın onları daha çok taramasını garanti etmez. Kapasite iyileştirmesini URL envanteri ve yayın ihtiyacıyla eşleştirin; hedef, değerli sayfaların güvenilir biçimde alınmasıdır.

Tarama sorunu ile indeks sorununu nasıl ayırabilirsiniz?

Tarama sorunu ile indeks sorununu ayırmanın en kısa yolu, aynı URL için keşif, istek, oluşturma ve kanonik kanıtlarını sıraya koymaktır. URL iç bağlantıda ve site haritasında yoksa keşif aşamasında kalabilir. Doğrulanmış logda Googlebot isteği varsa keşfedilmiş ve en az bir kez alınmıştır; bundan sonraki görünmeme nedeni farklı olabilir.

İlk olarak sunucunun Googlebot’a verdiği gerçek yanıtı kontrol edin. Tarayıcınız 200 görürken bot, güvenlik duvarı nedeniyle 403 veya geçici sunucu hatası alabilir. Yönlendirme hedefi, mobil görünüm ve gerekli kaynaklar da ayrı sınanmalıdır. URL Denetleme aracındaki canlı test ile kayıtlı indeks bilgisi aynı şey değildir; tarihlerini not ederek yorumlayın.

İkinci adımda robots yönergelerini ve kanonik seçimini inceleyin. Google’ın belirlediği kanonik, sizin bildirdiğiniz adresten farklıysa sayfa taranmış olsa bile tercih edilen sonuç olmayabilir. İç bağlantılar, site haritası ve `rel="canonical"` farklı adresleri işaret ediyorsa önce bu tutarsızlığı düzeltin. Kanonik seçimini zorlamak için robots.txt kullanmayın.

Üçüncü adım içerik değeridir. Benzer açıklamalara sahip binlerce ürün varyasyonu veya ana içeriği bulunmayan kategori, teknik olarak erişilebilir olsa da bağımsız dizin değeri taşımayabilir. Bu durumda daha çok tarama talep etmek temel sorunu çözmez. Birleştirme, varyant sunumu, özgün ürün bilgisi ve kategori kapsamı üzerine karar gerekir.

“Keşfedildi, şu anda dizine eklenmiş değil” durumu bütçe ihtimalini düşündürebilir, ancak tek başına kesin teşhis değildir. Örnek URL’lerin ne zamandır bu durumda olduğu, site genelindeki payı, iç bağlantı gücü, sunucu kayıtları ve benzer içerik kümeleri incelenmelidir. Rapor etiketini nedenin kendisi gibi değil, araştırmayı başlatan belirti gibi kullanın.

“Tarandı, şu anda dizine eklenmiş değil” ifadesi ise isteğin gerçekleştiğini gösterir. Aynı URL için tekrar tarama sıklığını artırmaya çalışmadan önce kalite, yinelenme ve kanonik sinyalleri değerlendirin. Teknik SEO planı, her Search Console sınıfına otomatik bir çözüm atamak yerine URL örneklerini ve şablon davranışını doğrulamalıdır.

Eski ve değişen sayfalar için yaşam döngüsü nasıl yönetilir?

URL yaşam döngüsü, sayfa oluşturulmadan önce başlar ve kaldırıldıktan sonra da devam eder. Ürün, ilan veya haber şablonunun hangi durumda yayınlanacağını, iç bağlantı alacağını, site haritasına gireceğini ve ne zaman kaldırılacağını yazılı hale getirin. Bu kurallar yoksa her ekip başka bir durum kodu veya yönlendirme davranışı üretebilir.

Geçici olarak stokta olmayan ürün ile kalıcı biçimde satışı biten ürünü ayırın. Yakında dönecek sayfada kullanıcıya durum, alternatif ve bildirim seçeneği sunmak adresi koruyabilir. Kalıcı kaldırmada eşdeğer yeni ürün varsa yönlendirme düşünülebilir; yalnızca benzer görünmesi, kullanıcı niyetinin gerçekten karşılandığı anlamına gelmez.

Süresi dolan ilanlar, kullanıcıya geçmiş kayıt bilgisiyle değer sunabilir veya tamamen işlevsiz kalabilir. Kararı sektör mevzuatı, kullanıcı ihtiyacı ve içerik niteliğine göre verin. Boş şablonu 200 durumuyla açık bırakmak yerine gerçekten yararlı arşiv içeriği sunun; değer yoksa doğru kaldırma yanıtını kullanın.

Etiket ve yazar arşivleri içerik yönetim sistemi tarafından otomatik üretilebilir. Birkaç yazıyı tekrar listeleyen yüzlerce ince arşiv, ayrı arama amacı karşılamıyorsa envanteri büyütür. Hepsini koşulsuz silmek yerine trafik, bağlantı, içerik kapsamı ve gezinme rolünü inceleyin. Değerli kümeleri geliştirin, gereksiz taksonomilerin yeni URL üretmesini durdurun.

İçerik budaması toplu URL silme yarışı değildir. Sayfanın trafik almaması tek başına değersiz olduğunu kanıtlamaz; satış yolunda, destek sürecinde veya iç bağlantı mimarisinde rolü olabilir. Birleştirme kararında hedef sayfanın aynı ihtiyacı karşılayıp karşılamadığını test edin. Yönlendirme sonrasında iç bağlantıları ve site haritasını da yeni hedefe güncelleyin.

Yayın kaydında URL kimliği, içerik türü, oluşturulma zamanı, son anlamlı güncelleme, hedef durum ve sorumlu ekip tutulursa tarama analizi daha güvenilir olur. Böylece sahte `lastmod` tarihleri yerine gerçek değişiklikleri site haritasına aktarabilir, log verisini içerik yaşıyla karşılaştırabilir ve eskimiş kümeleri toplu biçimde değerlendirebilirsiniz.

Optimizasyonun etkisi nasıl izlenir ve raporlanır?

Etki ölçümü, değişiklik öncesi karşılaştırılabilir bir başlangıç kaydı gerektirir. Önemli URL listesi, gereksiz örüntüler, durum kodları, ilk ve son tarama zamanları ile sunucu hatalarını aynı tanımla kaydedin. Sezon, büyük içerik yayını, site taşıma ve altyapı kesintisi gibi dış etkileri zaman çizelgesine ekleyin.

Toplam istek sayısının düşmesi başarısızlık olmayabilir. Gereksiz parametre istekleri azalırken önemli kategorilerin kapsaması yükseliyorsa sistem daha verimli çalışıyor olabilir. Tersine toplam istek artışı, sonsuz takvim URL’lerinin keşfedilmesinden kaynaklanabilir. Hacmi her zaman URL sınıfı ve iş önceliğiyle birlikte okuyun.

Değişiklik sonrası ilk kontrol, teknik kabul testidir. Robots kuralı hedeflenen örnekleri engelliyor mu, değerli istisnalar açık mı, kanonik doğru hedefe mi gidiyor, site haritası yalnız tercih edilen URL’leri mi içeriyor? HTTP yanıtını komut satırı, tarayıcı ve Google araçlarıyla sınayın. Yalnız CMS ayar ekranındaki seçeneğe güvenmeyin.

İkinci kontrol, bot davranışındaki değişimdir. Aynı uzunluktaki dönemlerde URL grubu dağılımını karşılaştırın; fakat Google’ın tarama talebinin kendiliğinden dalgalanabileceğini unutmayın. Değişiklik ile sonuç arasındaki beraberlik tek başına nedensellik kanıtlamaz. Kontrollü bir dizin veya açık bir sürüm tarihi yorumu güçlendirir.

Üçüncü kontrol, iş sonucuna uzanan görünürlüktür. Önemli URL daha hızlı taransa bile arama gösterimi artmayabilir; içerik talebi veya rekabet ayrı konudur. Teknik ekip keşif ve erişimi, içerik ekibi sorgu karşılığını, yönetim ise nitelikli organik talebi izlemelidir. Her katmanın sorumluluğunu tek metriğe yüklemeyin.

Aylık rapor, yapılan işleri sıralamakla yetinmemelidir. Hangi varsayımın sınandığını, hangi URL grubunun değiştiğini, kabul testinin sonucunu ve sonraki karar koşulunu göstermelidir. Veri henüz olgunlaşmadıysa bunu açıkça yazın. Erken olumlu sonucu kalıcı kazanım, geçici dalgalanmayı da kesin kayıp gibi sunmayın.

Tarama bütçesi optimizasyonu için eylem planı nasıl kurulur?

Eylem planı, önce belirtinin gerçekten tarama kaynaklı olduğunu doğrulayarak başlar. Önemli URL listesini ve beklenen güncellenme hızını tanımlayın. Search Console, log ve envanter verilerini aynı dönem için birleştirin. Ardından sorunu erişim, keşif, yinelenme, oluşturma, kanonikleştirme veya kalite başlığına yerleştirin.

İşleri etki ve geri döndürülebilirliğe göre sıralayın. Yanlış robots.txt kuralı geniş bir alanı bir anda kapatabilir; önce örnek kümede test gerekir. Site içi bağlantıyı nihai hedefe güncellemek ise genellikle anlaşılır ve geri alınabilir bir düzeltmedir. Her görevde uygulama sahibi, kabul ölçütü ve geri alma koşulu bulunsun.

Değişiklikleri topluca canlıya almak nedenselliği bulanıklaştırır. Önce ölçüm hatasını düzeltin, sonra URL üretimini, ardından yönlendirme ve bağlantı yapısını ele alın. Bir kuralın etkisini değerlendirmek için sitenin normal tarama döngüsünü gözetin; evrensel bir gün veya sonuç garantisi vermeyin.

Ajans seçerken yalnız araç listesini değil, karar mekanizmasını sorun. SEO ajansı desteğinin log erişimi olmadan hangi çıkarımları yapacağını, geliştirme teslimini nasıl tarif edeceğini ve uygulama sonrasını hangi ölçüyle izleyeceğini netleştirin. “Bütçeyi artırırız” vaadi yerine kanıtlanabilir kapsam arayın.

SEO danışmanlığı fiyatları, sitenin URL hacmi, veri erişimi, log işleme ihtiyacı, JavaScript mimarisi ve geliştirme koordinasyonuna göre farklılaşabilir. Güvenilir teklif; incelenecek ana makineleri, veri dönemini, teslimleri ve hariç işleri yazar. Kesin sıralama, indekslenme süresi veya tarama artışı taahhüdü gerçekçi bir kabul ölçütü değildir.

Çalışma sonunda bir defalık temizlikten fazlasını hedefleyin. Yeni filtre eklenirken URL kuralını, yeni içerik yayınlanırken site haritası ve iç bağlantıyı, site taşınırken yönlendirme haritasını kontrol eden yayın standartları oluşturun. En ucuz tarama hatası, üretime hiç çıkmayan hatadır.

Tarama bütçesi hakkında en sık hangi sorular sorulur?