Search Console robots.txt Raporu Nasıl Okunur? Hataları Bulup Düzeltme

Robots.txt dosyanızın Google tarafından nasıl görüldüğünü merak ediyorsanız, ilk bakacağınız yer Search Console robots raporu, yani robots.txt raporu olmalı. Bu rehberde Talha Aslan ve ekibi olarak raporu satır satır okuyor, durum etiketlerinin ne anlama geldiğini açıklıyor ve hata gördüğünüzde hangi sırayla ilerleyeceğinizi anlatıyoruz. Dosyanız henüz yoksa önce ücretsiz robots.txt oluşturucu ile temiz bir taslak hazırlayabilirsiniz.

Bu rapor bir yazma aracı değildir. Dosyayı düzenlemez, yalnız Google'ın gördüğünü size aktarır. Bu nedenle değişikliği her zaman sunucudaki dosyada yaparsınız; rapor ise değişikliğin Google tarafına ulaşıp ulaşmadığını doğrulamanızı sağlar.

Robots.txt kavramına yeni başlıyorsanız, temel söz dizimini ayrı bir yazıda anlattık: robots.txt nedir rehberi. Burada yalnız raporu okumaya odaklanıyoruz.

Raporu düzenli açmanın asıl faydası erken uyarıdır. Bir tema güncellemesi, güvenlik eklentisi ya da sunucu değişikliği robots.txt yanıtını sessizce bozabilir. Siz bunu trafik düşmeden önce görürseniz, düzeltme birkaç dakikalık bir iştir.

Eski robots.txt test aracı nereye gitti?

Search Console'un eski sürümünde, kuralları elle deneyip bir URL'nin engellenip engellenmediğini gösteren ayrı bir test aracı vardı. Bugün Google'ın resmi robots.txt oluşturma belgesi, söz dizimi sorunlarını düzeltmek için iki seçenek gösteriyor: Search Console'daki robots.txt raporu ve Google'ın açık kaynak robots.txt kütüphanesi.

Belgedeki önemli bir ayrıntıyı atlamayın: rapor yalnız sitenizde zaten erişilebilir olan dosyalar için çalışır. Dolayısıyla yayına almadan önce bir taslağı denemek istiyorsanız, raporu değil, yerel test yöntemlerini ya da dikkatli bir hazırlık sürecini kullanırsınız.

Örneğin geliştirici ekibiniz varsa açık kaynak kütüphaneyi kendi bilgisayarında derleyip kuralları yerelde sınayabilir. Geliştirici desteğiniz yoksa kuralları sade tutmak, en güvenli yoldur.

Bizim önerimiz, her değişikliği önce küçük bir kural setiyle yapmanız ve yayından sonra raporu açıp sonucu doğrulamanızdır. Böylece bir hata çıkarsa hangi satırın sorumlu olduğunu hemen anlarsınız. Ayrıca eski sürümün bir kopyasını saklarsanız, sorun anında önceki duruma dönmek dakikalar sürer.

Rapor Search Console'da nerede yer alır?

Rapor, Search Console içinde ayarlar bölümünde yer alır. Menü adları zamanla değişebildiği için kesin buton metnine yaslanmanızı önermiyoruz; panelde ayarlar alanını açtığınızda tarama ile ilgili kısımda robots.txt satırını görürsünüz.

1. Search Console'a girin ve doğru mülkü seçin.
2. Sol menüden ayarlar bölümünü açın.
3. Tarama başlığı altındaki robots.txt kaydına tıklayın.
4. Açılan tabloda her ana makine için ayrı bir satır görün.

Burada mülk türü de önemlidir. Alan adı mülkünde birden çok ana makine (örneğin www ve www olmayan sürüm, alt alan adları) aynı raporda listelenebilir. URL ön eki mülkünde ise görünüm o ön ekle sınırlıdır. Search Console'u ilk kez kuruyorsanız Google Search Console kullanım rehberimiz başlangıç için yeterli olur.

Raporda hangi sütunlar var ve ne anlatırlar?

Tablo yapısı basittir, ancak her sütun ayrı bir soruya cevap verir. Aşağıdaki tabloyu raporu açtığınızda yanınızda tutabilirsiniz.

Bir satıra tıkladığınızda, Google'ın son getirdiği dosya içeriğini görürsünüz. Ayrıca rapor yakın geçmişte getirilen sürümleri de listeler; böylece bir değişikliğin hangi gün Google'a ulaştığını izleyebilirsiniz.

Getirme durumu etiketleri ne anlama gelir?

Raporda üç ana durumla karşılaşırsınız. Panel dilinize göre etiketlerin metni küçük farklar gösterebilir; bu yüzden aşağıda anlamlarını anlatıyoruz, birebir buton metnini değil.

• Başarılı getirme: Google dosyayı başarıyla aldı. Varsa sorunlar sütununa ayrıca bakarsınız.
• Dosya yok (404): Sunucu dosya yok dedi. Google bu durumda tarama kısıtlaması olmadığını varsayar.
• Başka bir nedenle getirme hatası: Sunucu hatası, zaman aşımı ya da ağ sorunu gibi bir engel oldu. En kritik durum budur.

Örneğin bir 404 sonucu çoğu zaman panik gerektirmez. Ancak siteniz bilerek bazı bölümleri kapatmak istiyorsa, 404 o kuralların hiç uygulanmadığı anlamına gelir. Böylece istemediğiniz klasörler de taramaya açık kalır.

Üstelik 404 sonucu bazen yanlış konumdan kaynaklanır. Dosya bir alt klasöre yüklendiyse Google onu aramaz; Google yalnız kök dizindeki dosyayı okur. Bu yüzden adresin alan adından hemen sonra geldiğinden emin olursunuz.

Durum 404 olduğunda Google sitenizi nasıl tarar?

Google'ın robots.txt teknik belgesine göre Google 4xx yanıtlarını, robots.txt dosyası hiç yokmuş gibi ele alır. Yani Google tarama kısıtlaması olmadığını kabul eder. Belge 429 kodunu bu kuralın dışında bırakır.

Ayrıca belge, tarama hızını sınırlamak için 401 ya da 403 yanıtı kullanmamanızı söyler. Dolayısıyla güvenlik eklentiniz Googlebot'a 403 döndürüyorsa, bunu bir kısıtlama yöntemi olarak görmeyin; Google o yanıtı dosya yokmuş gibi okur.

Pratikte şunu yaparsınız: dosyanın adresini tarayıcının gizli penceresinde açarsınız. İçerik görünüyorsa sorun büyük ihtimalle önbellekte ya da yönlendirmededir. Hiç açılmıyorsa dosyayı kök dizine yeniden yüklersiniz.

Sunucu hatası (5xx) gördüğünüzde Google ne yapar?

Bu bölüm raporun en önemli kısmıdır, çünkü 5xx durumu taramayı doğrudan etkiler. Google'ın resmi belgesine göre süreç aşamalıdır.

1. İlk 12 saat boyunca Google siteyi taramayı durdurur, ancak dosyayı tekrar istemeyi sürdürür.
2. Ardından 30 güne kadar, elinde varsa son başarılı önbellek sürümünü kullanır. Önbellek yoksa kısıtlama olmadığını varsayar.
3. 30 günden sonra site genel olarak erişilebilirse Google dosya yokmuş gibi hareket eder; site erişilemezse taramayı durdurup dosyayı aralıklarla ister.

Kısacası robots.txt adresindeki kalıcı bir sunucu hatası, sayfalarınız sağlam olsa bile taramayı yavaşlatabilir. Böyle bir tabloda tarama grafiğinde belirgin bir düşüş görüyorsanız Googlebot neden daha az tarar yazımızdaki teşhis adımları da işinize yarar.

Yönlendirme yapan robots.txt dosyasını rapor nasıl gösterir?

Google belgesine göre Googlebot robots.txt için en az beş yönlendirme adımını izler. Bu adımlardan sonra dosyaya ulaşamazsa sonucu 404 gibi değerlendirir. Ayrıca JavaScript ya da meta yenileme gibi mantıksal yönlendirmeleri izlemez.

Bu nedenle HTTP'den HTTPS'e ya da www'den www olmayan sürüme giden tek bir yönlendirme sorun çıkarmaz. Öte yandan birbirine zincirlenen eklenti, CDN ve sunucu yönlendirmeleri sayıyı hızla artırabilir.

Raporda beklemediğiniz bir 404 görüyorsanız, dosya adresini bir başlık kontrol aracıyla açıp yönlendirme zincirini sayın. Zincir uzunsa yönlendirmeyi doğrudan son adrese çevirin. Böylece hem robots.txt hem de genel tarama verimliliği rahatlar.

Sorunlar sütunundaki uyarıları nasıl yorumlamalısınız?

Dosya getirildiği halde sorunlar sütununda sayı görüyorsanız, Google bazı satırları anlayamamış demektir. Resmi belgeye göre Google geçersiz satırları yok sayar; dosya başındaki bayt sırası işareti (BOM) de bu kapsamdadır.

En sık rastladığımız nedenler şunlardır:

• Yanlış yazım içeren yönerge adları, örneğin iki noktası eksik bir Disallow satırı.
• Bir User-agent satırı olmadan başlayan kural grupları.
• Kelime işlemciden gelen görünmez karakterler.
• UTF-8 dışında bir kodlamaya sahip dosya.

Uyarılar dosyanın tamamını geçersiz kılmaz, ancak beklediğiniz bir engelin çalışmadığı anlamına gelebilir. Bu yüzden her uyarı satırını tek tek açıp ilgili satırı düzeltirsiniz. Sık yapılan söz dizimi hatalarının ayrıntılı listesi robots.txt hataları yazımızda var.

Dosya boyutu sınırı raporda neden önemlidir?

Google'ın belgesi robots.txt için 500 KiB boyut sınırı belirtir ve bu sınırın ötesindeki içeriğin yok sayıldığını söyler. Raporun boyut sütunu tam da bu yüzden işe yarar.

Çoğu kurumsal sitenin dosyası birkaç satırdan oluşur ve sınıra yaklaşmaz. Ancak büyük e-ticaret sitelerinde, her filtre kombinasyonu için ayrı satır eklendiğinde dosya kontrolsüz büyüyebilir. Sınırı aşan bir dosyada en alttaki kurallar sessizce devre dışı kalır.

Çözüm genellikle kuralları birleştirmektir. Örneğin onlarca benzer satır yerine joker karakter kullanan tek bir desen yazarsınız. Bu sayede dosyanız hem kısa kalır hem de okunması kolaylaşır. Filtreli adresleri yönetmeye dair stratejiyi faceted navigation yazımızda ayrıca ele aldık.

Yeniden tarama isteği ne zaman göndermelisiniz?

Google, robots.txt içeriğini genellikle 24 saate kadar önbellekte tutar. Yani bir düzeltme yaptığınızda Google'ın yeni sürümü görmesi bir gün sürebilir. Google'ın robots.txt güncelleme belgesi, önbelleği daha hızlı güncellemek için raporun yeniden tarama isteği işlevini önerir.

Bu işlevi her küçük değişiklikte kullanmanız gerekmez. Biz şu durumlarda kullanıyoruz:

• Yanlışlıkla bütün siteyi kapatan bir kural düzelttiğinizde.
• Önemli bir bölümü taramaya açtığınızda.
• Uzun süren bir sunucu hatası çözüldükten sonra.

Bu işlevi bir sihirli düğme gibi görmeyin; Google isteği değerlendirir ve kendi tarama düzenine göre hareket eder. Rutin, acil olmayan güncellemelerde ise önbelleğin kendiliğinden yenilenmesini beklemek yeterlidir.

Ayrıca isteği göndermeden önce yeni dosyanın gerçekten yayında olduğunu doğrulayın. Aksi halde Google eski içeriği yeniden alır ve siz düzeltmenin işe yaramadığını sanırsınız. Kısacası sıra her zaman önce dosya, sonra tarayıcı kontrolü, en son istektir.

Tek bir URL'nin engellenip engellenmediğini nasıl kontrol edersiniz?

Search Console robots raporu dosyanın kendisini gösterir; belirli bir sayfanın engellenip engellenmediğini ise URL Denetleme aracında görürsünüz. İki araç birbirini tamamlar.

1. Search Console'un üstündeki arama kutusuna kontrol etmek istediğiniz tam adresi yazın.
2. Sonuçta tarama ile ilgili ayrıntıları açın.
3. Taramaya izin verilip verilmediğini belirten satırı okuyun.
4. Engel görüyorsanız, robots.txt raporunda ilgili ana makinenin dosyasını açıp eşleşen kuralı bulun.

Kural eşleşmesini ararken Google'ın öncelik mantığını hatırlayın: en uzun eşleşen yol kazanır. Aynı uzunlukta çakışan bir Allow ve Disallow varsa Google daha az kısıtlayıcı olanı uygular. Ayrıca yol eşleşmesi büyük ve küçük harfe duyarlıdır.

Engellenen sayfa neden yine de Google sonuçlarında yer alıyor?

Bu soru raporu okuyanların en sık şaşırdığı noktadır. Google'ın robots.txt giriş belgesi açıkça şunu söyler: robots.txt bir sayfayı Google dışında tutma yöntemi değildir. Başka sitelerden link alan, taraması engelli bir sayfa yine dizine girebilir.

Böyle bir sayfa sonuçlarda açıklamasız biçimde görünebilir. Dolayısıyla amacınız sayfayı arama sonuçlarından çıkarmaksa robots.txt yerine noindex kullanırsınız ya da sayfayı parolayla korursunuz.

Burada bir tuzak var: noindex etiketini görebilmesi için Google'ın sayfayı tarayabilmesi gerekir. Yani aynı sayfayı hem engelleyip hem noindex verirseniz, Google etiketi hiç okuyamaz. İki yöntemin farkını noindex, nofollow ve robots.txt karşılaştırması yazımızda tabloyla anlattık.

Alt alan adları ve farklı protokoller raporda nasıl yer alır?

Google belgesine göre robots.txt kuralları yalnız dosyanın bulunduğu ana makine, protokol ve port için geçerlidir. Yani blog.example.com için yazdığınız dosya example.com'u etkilemez; Google HTTP ve HTTPS sürümlerini de ayrı ele alır.

Bu nedenle rapordaki her satırı ayrı bir dosya olarak okursunuz. Örneğin ana sitenin satırı temiz görünürken, eski bir hazırlık alt alan adının satırında 404 ya da sunucu hatası görebilirsiniz.

Böyle bir alt alan adı herkese açık kalmışsa, onu korumanın doğru yolu parola ya da erişim kısıtlamasıdır. Robots.txt tek başına yeterli değildir, çünkü az önce anlattığımız gibi engellenen adresler yine dizine girebilir.

Kurallar raporda gördüğünüz dosyada nasıl eşleşir?

Raporda dosya içeriğini açtığınızda, hangi satırın hangi adresi etkilediğini kendiniz çözmeniz gerekir. Google'ın resmi belgesi eşleşme için birkaç basit ilke tanımlar ve bu ilkeler çoğu karışıklığı çözer.

• Yıldız işareti (*) sıfır ya da daha fazla karakterle eşleşir.
• Dolar işareti ($) adresin sonunu belirtir.
• Yolun sonundaki yıldız işaretini Google yok sayar.
• Yol eşleşmesi büyük ve küçük harfe duyarlıdır.

Örnek senaryo: dosyanızda Disallow: /arama ve Allow: /arama/rehber satırları var. Bu durumda /arama/rehber adresi için daha uzun eşleşme Allow satırıdır; dolayısıyla Google o adresi tarayabilir. Öte yandan /Arama adresi büyük harfle başladığı için hiçbir kuralla eşleşmez.

Bu küçük ayrıntılar, raporda her şey yolunda görünürken bazı sayfaların neden taranmadığını açıklar. Kuralları sade tutarsanız eşleşmeyi tahmin etmek de kolaylaşır.

Önbellek ile kontrol tarihi arasındaki ilişki nedir?

Raporu okurken en çok kafa karıştıran sütun, kontrol tarihidir. Google'ın belgesine göre robots.txt içeriğini genellikle 24 saate kadar önbellekte tutar; zaman aşımı ya da sunucu hatası gibi durumlarda bu süre uzayabilir. Ayrıca sunucunuzun gönderdiği Cache-Control başlığındaki max-age değeri de önbellek ömrünü etkileyebilir.

Bu nedenle kontrol tarihi, Google'ın elindeki sürümün yaşını gösterir. Düzeltmeyi sabah yaptıysanız ve kontrol tarihi önceki güne aitse, Google henüz eski kurallarla tarıyor demektir.

Pratikte şu sırayı izlersiniz: önce dosyayı düzeltirsiniz, sonra tarayıcıda yeni içeriği görürsünüz, ardından kontrol tarihinin değişmesini beklersiniz. Acil durumda yeniden tarama isteği bu bekleme süresini kısaltabilir. Kısacası tarih değişmeden rapordaki içerik size eski bir fotoğraf sunar.

Örneğin CDN kullanıyorsanız, CDN'in de dosyanın eski sürümünü önbellekte tutabileceğini unutmayın. Böyle bir durumda CDN önbelleğini de temizlemeniz gerekir; aksi halde Google yine eski sürümü alır.

Search Console robots raporunu sunucu günlükleriyle nasıl birlikte okursunuz?

Search Console robots raporu Google'ın son getirme sonucunu özetler; sunucu günlükleri ise her isteği tek tek gösterir. İki kaynağı birlikte okumak, aralıklı hataları yakalamanın en güvenilir yoludur.

Örneğin rapor tek bir sunucu hatası gösteriyorsa, bu tek seferlik bir aksaklık olabilir. Ancak günlüklerde Googlebot'un robots.txt isteklerine sık sık 5xx ya da zaman aşımı döndüğünü görürseniz, sorun kalıcıdır. Böylece raporu tek başına yorumlamaktan doğan yanılgıdan kurtulursunuz.

1. Barındırma panelinizden ya da teknik ekibinizden erişim günlüklerini alın.
2. robots.txt adresine gelen istekleri filtreleyin.
3. Yanıt kodlarını ve yanıt sürelerini karşılaştırın.
4. Hata saatlerini sunucu yoğunluğu ya da bakım saatleriyle eşleştirin.

Ayrıca güvenlik duvarınızın Googlebot'u yanlışlıkla engelleyip engellemediğini de bu yolla anlarsınız. Barındırma firmanızla konuşurken günlükteki somut saatleri paylaşmak, çözümü hızlandırır.

Günlük analizine yeni başlıyorsanız tüm istekleri incelemeniz gerekmez. Yalnız robots.txt satırlarını ve Googlebot kullanıcı aracısını filtrelemek, ilk teşhis için çoğu zaman yeterlidir. Ancak kullanıcı aracısı adının taklit edilebildiğini unutmayın; bu yüzden şüpheli bir trafikte Google'ın resmi doğrulama yöntemini kullanırsınız.

Hazır altyapılarda robots.txt dosyası nereden gelir?

Raporda gördüğünüz içerik, sunucunuzda elle yüklediğiniz dosyayla aynı olmayabilir. Bazı içerik yönetim sistemleri, kökte fiziksel bir dosya yoksa robots.txt içeriğini kendileri üretir. Örneğin WordPress bu durumda sanal bir dosya sunar ve SEO eklentileri bu içeriği değiştirebilir.

Bu yüzden rapordaki içerik beklediğinizden farklıysa, önce kaynağı bulursunuz. Kökte fiziksel bir dosya var mı, yoksa sistem mi üretiyor? Eklenti ayarı ile fiziksel dosya çakışıyor mu?

Öte yandan hazır e-ticaret altyapıları ve site kurucular genellikle varsayılan bir dosya sunar ve düzenleme alanını sınırlar. Böyle bir altyapıda yalnız platformun izin verdiği alanı düzenleyebilirsiniz. Dolayısıyla her değişiklikten sonra raporu açıp Google'ın gerçekten hangi içeriği aldığını kontrol etmeniz önemlidir.

Kaynağı netleştirdikten sonra tek bir yerden yönetmeye karar verin. İki ayrı kaynak, her güncellemede yeni bir sürpriz demektir.

Örneğin bir SEO eklentisi sanal dosyaya kendi kurallarını eklerken, sonradan biri kök dizine fiziksel bir dosya yüklerse eklenti ayarları etkisiz kalır. Bu durumda panelde gördüğünüz ayar ile Google'ın okuduğu içerik birbirinden ayrılır. Raporu açtığınızda bu farkı hemen fark edersiniz.

Site taşımasından sonra raporda neye bakmalısınız?

Alan adı değişikliği, HTTPS geçişi ya da altyapı taşıması, robots.txt hatalarının en sık ortaya çıktığı anlardır. Taşıma günü raporu açıp şu soruların cevabını ararsınız.

• Yeni ana makinenin dosyası başarıyla getiriliyor mu, yoksa 404 ya da sunucu hatası mı veriyor?
• Hazırlık ortamındaki her şeyi kapatan kural canlıya taşındı mı?
• Sitemap satırı yeni alan adını gösteriyor mu?
• Eski alan adındaki dosya yönlendirmeyi engellemeden erişilebilir mi?

Örnek senaryo: taşıma sonrası tüm siteyi kapatan tek bir Disallow: / satırı canlıda kalırsa, Google yeni sayfaları tarayamaz. Raporu ilk gün kontrol eden ekip bunu saatler içinde düzeltir. Ayrıca taşıma sonrası trafik düşüşünü teşhis etmek için Search Console ile trafik düşüşü tespiti yazımızdaki adımları da izleyebilirsiniz.

Raporda gördüğünüz hatayı adım adım nasıl düzeltirsiniz?

Teşhisten sonra düzeltme sırası çoğu sitede aynıdır. Aşağıdaki akışı ekibimizle teknik denetimlerde kullanıyoruz.

1. Raporda sorunlu ana makineyi ve getirme durumunu not edin.
2. Dosya adresini gizli pencerede açıp sunucunun ne döndürdüğünü görün.
3. Gerekirse dosyayı robots.txt oluşturucu ile yeniden üretin; yalnız gerçekten kapatmak istediğiniz yolları ekleyin.
4. Dosyayı UTF-8 düz metin olarak kök dizine yükleyin.
5. Yeni içeriğin tarayıcıda göründüğünü doğrulayın.
6. Acil bir düzeltmeyse rapordan yeniden tarama isteği gönderin.
7. Birkaç önemli adresi URL Denetleme aracıyla kontrol edin.

Dosyaya bir Sitemap satırı ekliyorsanız, site haritasının da sorunsuz okunduğundan emin olun. Haritayla ilgili bir hata görürseniz site haritası okunamadı hatası yazımız devamında size yol gösterir.

Robots.txt değişikliğinin etkisini raporda nasıl doğrularsınız?

Dosyayı düzeltmek işin yarısıdır; diğer yarısı etkinin gerçekten gerçekleştiğini görmektir. Raporun kendisi yalnız dosyanın durumunu gösterir. Dolayısıyla etkiyi ölçmek için birkaç farklı ekrana birlikte bakarsınız.

1. Raporda kontrol tarihinin değişikliğinizden sonraki bir tarihe geçtiğini görün.
2. Dosya içeriğini açıp yeni kuralların Google'daki sürümde yer aldığını doğrulayın.
3. Daha önce engelli olan birkaç önemli adresi URL Denetleme aracında yeniden kontrol edin.
4. Sonraki günlerde tarama istatistiklerinde istek sayısındaki değişimi izleyin.

Örnek senaryo: kategori sayfalarını yanlışlıkla kapatan bir kuralı kaldırdınız. Kontrol tarihi yenilendikten sonra URL Denetleme aracı bu sayfalar için taramaya izin verdiğini gösterir. Ardından dizine ekleme raporunda bu sayfaların durumu zamanla değişir; ancak bu süreç Google'ın tarama sırasına bağlıdır ve kesin bir süre yoktur.

Değişikliği bir not defterine tarihiyle kaydetmenizi de öneririz. Böylece haftalar sonra bir dalgalanma gördüğünüzde, hangi kuralın ne zaman değiştiğini tahmin etmek yerine kesin olarak bilirsiniz.

Bu aşamada sabırlı olmak önemlidir. Özellikle büyük sitelerde, açılan bölümlerin tamamının yeniden taranması günler hatta haftalar sürebilir; bu durum bir hata işareti değildir. Bu arada yeni bir değişiklik yapmazsanız, hangi adımın hangi sonucu doğurduğunu net biçimde izlersiniz.

Rapordaki sonucu yorumlarken hangi hatalara düşmemelisiniz?

Rapor sade bir ekran; ancak yanlış yorumlar sık yaşanır. Sahada en çok gördüğümüz yanılgılar şunlardır.

Birincisi, başarılı getirme durumunu her şeyin yolunda olduğu sanmak. Google dosyayı almış olabilir; fakat içindeki tek bir Disallow satırı önemli bir klasörü kapatıyor olabilir. Bu yüzden durumla birlikte içeriği de okursunuz.

İkincisi, değişikliği yaptıktan dakikalar sonra raporun güncellenmesini beklemek. Önbellek nedeniyle kontrol tarihi değişmeden Google yeni içeriği göstermez.

Üçüncüsü, raporun yalnız bir ana makineyi gösterdiğini düşünmek. Mülkünüz alan adı türündeyse birden çok satırı tek tek açmanız gerekir. Son olarak, sayfaların dizine girmeme nedenini her zaman robots.txt'de aramayın; diğer nedenler için indexlenmeyen sayfaları tespit etme rehberine bakabilirsiniz.

Search Console robots raporunu ne sıklıkla kontrol etmelisiniz?

Search Console robots raporu, günlük takip gerektiren bir ekran değildir. Bizim önerimiz, her site yayını, tema değişikliği, CDN ya da güvenlik eklentisi güncellemesi sonrasında raporu bir kez açmanızdır.

Ayrıca aylık teknik kontrol listenize bu raporu ekleyebilirsiniz. Böylece fark edilmeyen bir sunucu hatası ya da yanlışlıkla canlıya çıkan bir test dosyası uzun süre etkisini sürdürmez.

Örnek senaryo: bir site taşıması sonrası hazırlık ortamındaki "her şeyi kapat" dosyası canlıya geçer. Raporu taşıma günü açan ekip bunu birkaç saat içinde görür; açmayan ekip ise tarama düşüşünü haftalar sonra fark eder.

Robots.txt ve tarama sorunlarında ne zaman uzman desteği almalısınız?

Basit bir dosya için çoğu zaman uzman gerekmez. Ancak rapor sürekli sunucu hatası gösteriyorsa, büyük bir e-ticaret sitesinde filtre adresleri taramayı tüketiyorsa ya da taşıma sonrası trafik düşüyorsa, sorun robots.txt'in ötesine geçmiş olabilir.

Böyle durumlarda tarama, dizine ekleme ve site mimarisini birlikte ele almak gerekir. SEO danışmanlığı kapsamında bu üçünü tek bir teknik denetimde inceliyoruz. Sonuç garantisi vermiyoruz; ancak sorunun nerede olduğunu kanıtla göstermeyi hedefliyoruz.

Bir uzmana başvurmadan önce raporun ekran görüntüsünü, dosyanın güncel içeriğini ve sorunun başladığı tarihi hazırlamanızı öneririz. Bu üç bilgi, ilk görüşmede teşhisi ciddi ölçüde hızlandırır. Ayrıca son haftalarda sitede yaptığınız teknik değişiklikleri listelemek de çoğu zaman sorunun kaynağını gösterir.

Kendiniz ilerlemek isterseniz, robots.txt'e ek olarak XML sitemap oluşturucu ile site haritanızı da güncel tutmanız, Google'ın sitenizi doğru anlamasına yardım eder.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.