Robots.txt Hataları: En Sık Yapılan Hatalar ve Doğru Kullanım

Robots txt hataları nelerdir ve sitenize nasıl zarar verir?
Robots txt hataları, arama motoru tarayıcılarına verdiğiniz tarama talimatlarındaki yanlışlıklardır: gereksiz yere engellenen CSS ve JavaScript, fazla geniş bir Disallow satırı, noindex yerine robots.txt kullanmak, harf duyarlılığını atlamak, hatalı Sitemap satırı ve 500 KiB sınırı. Sonuç çoğu zaman sessiz bir trafik kaybıdır.
Bu dosya birkaç satırdan oluşur; bu yüzden çoğu ekip onu bir kez yazıp unutur. Ancak tek bir eğik çizgi, sitenin tamamını Googlebot için kapatabilir. 2012'den beri yürüttüğüm teknik denetimlerde en pahalı hataların bir kısmını tam da bu küçük dosyada buldum.
Bu yazıda yapay zeka tarayıcılarını engelleme konusuna girmiyorum; o başlığı AI crawler ve llms.txt rehberinde ayrıca anlattım. Burada Googlebot ile klasik arama taramasını bozan hatalara odaklanıyorum. Her maddeyi Google'ın resmi belgesine ve RFC 9309 standardına dayandırıyorum.
Robots.txt dosyası tam olarak ne yapar, ne yapmaz?
Robots.txt, sitenizin kök dizininde duran düz bir metin dosyasıdır. Tarayıcılara hangi yolları tarayabileceklerini söyler. Yani görevi taramayı yönetmektir, dizine eklemeyi değil. Bu ayrımı kaçırdığınız anda hataların yarısı kendiliğinden gelir.
Google'ın robots.txt giriş belgesi bunu açıkça yazıyor: robots.txt, bir sayfayı Google dışında tutma mekanizması değildir. Ayrıca dosyadaki kurallar bir zorunluluk da taşımaz. Kurallara uyup uymamak tarayıcının kendi kararıdır; kötü niyetli botlar bu dosyayı hiç okumaz.
- Yaptığı şey: uyumlu tarayıcılara hangi URL yollarını istememeleri gerektiğini bildirir.
- Yaptığı şey: Sitemap satırıyla site haritanızın adresini duyurur.
- Yapmadığı şey: bir sayfayı arama sonuçlarından kaldırmaz.
- Yapmadığı şey: gizli bir dizini korumaz; tersine, dosyayı okuyan herkese o dizinin adresini gösterir.
Bir de standart meselesi var. Robots.txt uzun yıllar gayriresmi bir gelenek olarak yaşadı. Eylül 2022'de yayımlanan RFC 9309 ile Robots Exclusion Protocol resmi bir standart haline geldi. Google'ın ayrıştırıcısı da bu standarda dayanıyor; bu yüzden aşağıdaki kuralların çoğu diğer büyük arama motorlarında da benzer şekilde geçerli.
Dolayısıyla robots.txt bir güvenlik aracı değildir. Yönetim paneli ya da test ortamı gibi alanları parola ile korumanız gerekir. Bu temel çerçeve netleştiğinde aşağıdaki hataların neden bu kadar sık tekrarlandığını daha kolay görürsünüz.
CSS ve JavaScript dosyalarını engellemek neden ciddi bir hatadır?
Googlebot bir sayfayı yalnız HTML olarak okumaz; sayfayı bir tarayıcı gibi işler ve görünümünü çıkarır. Bu nedenle tema dosyalarını, stil dosyalarını ya da kritik JavaScript paketlerini engellerseniz Google sayfanın gerçek halini göremez.
Eski alışkanlıklar burada hâlâ sorun çıkarıyor. Örneğin bazı hazır temalar ve eski rehberler, eklenti ya da içerik klasörlerini toptan kapatmayı önerirdi. Oysa o klasörlerde sayfanın menüsünü, ürün listesini veya fiyat alanını üreten dosyalar durur. Sonuç olarak Google boş ya da bozuk bir sayfa görür.
Google bu konuda dengeli bir tavır alıyor. Resmi belgeye göre önemsiz görsel, betik ya da stil dosyalarını engelleyebilirsiniz; ancak bu dosyaların yokluğu sayfayı anlamayı zorlaştırıyorsa engellememelisiniz. Pratikte ayrımı yapmak zordur, bu yüzden varsayılan tercihim kaynak dosyalarını açık bırakmaktır.
Görseller için de aynı mantık geçerli. Ürün fotoğraflarınızın görsel aramada yer almasını istiyorsanız görsel klasörlerini kapatmayın. Öte yandan gerçekten değersiz dosyaları, örneğin eski yedek klasörlerini veya geçici indirme alanlarını engellemek makul bir tercihtir. Önemli olan her engelin bilinçli bir karar olmasıdır.
Kontrol için Search Console'daki URL Denetimi aracında canlı testi çalıştırın ve işlenmiş ekran görüntüsüne bakın. Sayfa çıplak görünüyorsa engellenen kaynakları listeleyin. JavaScript yükünün hıza etkisini merak ediyorsanız JavaScript ve site hızı yazısı iyi bir tamamlayıcıdır.
Tek karakterlik yanlış Disallow satırı siteyi nasıl kapatır?
Disallow satırı bir yol öneki olarak çalışır. Yani Disallow: / yazdığınızda kök ile başlayan her adresi, yani sitenin tamamını kapatırsınız. Boş bir Disallow satırı ise tam tersini söyler: hiçbir şey engelli değildir. Aradaki fark tek bir karakterdir.
Bu hatayı en sık yayına geçiş günlerinde görüyorum. Geliştirme ortamında taramayı kapatmak için yazdığınız Disallow: / satırı, dosyayla birlikte canlı siteye taşınır. Kimse fark etmez; çünkü site ziyaretçiler için normal çalışır. Birkaç hafta sonra Search Console grafiği düşmeye başlar.
Önek mantığı daha ince hatalar da üretir. Örneğin Disallow: /blog satırı yalnız blog klasörünü değil, /blog-haberleri ya da /blogger gibi aynı harflerle başlayan her yolu da kapatır. Klasörü hedefliyorsanız sonuna eğik çizgi ekleyin: Disallow: /blog/ yazmak niyetinizi daha doğru anlatır.
- Her Disallow satırını tek tek okuyun ve hangi yolları kapattığını yazın.
- Klasör hedefliyorsanız satırı eğik çizgiyle bitirin.
- Joker karakter (*) ve satır sonu işareti ($) kullandıysanız birkaç örnek URL ile deneyin.
- Yayın öncesi kontrol listenize "robots.txt kök satırı" maddesini ekleyin.
Robots.txt ile bir sayfayı Google dizininden çıkarabilir misiniz?
Hayır. Bu, en yaygın yanlış inançtır. Robots.txt ile bir sayfayı engellediğinizde Google o sayfayı taramaz; ama başka sayfalardan o adrese bağlantı geliyorsa URL'yi yine de dizine ekleyebilir. Bu durumda sonuçta açıklamasız, çıplak bir URL görürsünüz.
Google'ın giriş belgesi bu senaryoyu açıkça anlatıyor: engellenmiş bir sayfa, diğer sitelerden bağlantı alıyorsa dizine girebilir. Search Console'da bu durum "robots.txt tarafından engellenmesine rağmen dizine eklendi" gibi bir uyarıyla karşınıza çıkar.
Robots.txt içine noindex satırı yazmak da işe yaramaz. Google, bu resmi olmayan kurala verdiği desteği 1 Eylül 2019 itibarıyla bitirdi ve bunu Search Central blogunda duyurdu. Bugün desteklenen alanlar yalnız user-agent, allow, disallow ve sitemap.
Bir sayfayı sonuçlardan uzak tutmak istiyorsanız üç yolunuz var:
- Sayfaya noindex meta etiketi ekleyin ve taramayı açık bırakın.
- HTML dışı dosyalar için X-Robots-Tag yanıt başlığını kullanın.
- Özel alanları parola ile koruyun ya da sayfayı tamamen kaldırın.
Noindex ile Disallow'u birlikte kullanmak neden ters teper?
Çünkü Google noindex etiketini görebilmek için sayfayı taramak zorundadır. Sayfayı hem noindex ile işaretleyip hem de robots.txt ile engellerseniz Googlebot sayfaya giremez, dolayısıyla etiketi de okuyamaz. Sayfa, tam da istemediğiniz biçimde dizinde kalabilir.
Bu hata genellikle iyi niyetle başlar. Ekip bir grup sayfayı temizlemek ister ve "iki önlem bir önlemden iyidir" diye düşünür. Oysa buradaki iki önlem birbirini iptal eder. Önce noindex etiketini ekleyin, Google sayfaları yeniden tarasın ve dizinden düşürsün.
Dizinden çıkış tamamlandıktan sonra tarama bütçesini korumak için isterseniz robots.txt kuralını ekleyebilirsiniz. Ancak bu sıralama önemlidir: önce noindex, sonra gözlem, en son engel. Sırayı tersine çevirdiğinizde aylarca bekleyen "hayalet" URL'ler üretirsiniz.
Filtre ve sıralama parametreleri bu hatanın en sık görüldüğü alandır. E-ticaret sitelerinde binlerce parametreli adresi aynı anda hem engelleyip hem noindex ile işaretlemek sık bir refleks. Parametre yönetimini planlarken parametreli URL rehberindeki karar akışını kullanabilirsiniz.
Büyük küçük harf duyarlılığı hangi robots txt hatalarına yol açar?
Robots.txt içinde iki farklı kural geçerlidir. Alan adları, yani user-agent, allow ve disallow gibi anahtar kelimeler büyük küçük harfe duyarsızdır. Ancak yol değerleri harfe duyarlıdır. Disallow: /Urunler/ satırı /urunler/ klasörünü kapatmaz.
Bu ayrım özellikle eski ve yeni URL yapılarının karıştığı sitelerde sorun çıkarır. Örneğin bir sitenin eski sürümünde klasör adları büyük harfle başlıyordu, yeni sürümde küçük harfe geçildi. Robots.txt dosyası ise eski yazımla kaldı. Sonuçta kapatmak istediğiniz alan tamamen açık kalır.
Tersi de mümkündür. Bir CMS aynı içeriği hem büyük hem küçük harfli adreste sunuyorsa yalnız birini engellediğinizde öteki taranmaya devam eder. Bu durumda asıl çözüm robots.txt değil, tek bir kanonik yazıma yönlendirmedir.
Kontrol yöntemim basit: sunucu kayıtlarından Googlebot'un gerçekte istediği yolları çıkarıyor, robots.txt satırlarıyla harf harf karşılaştırıyorum. Bunun için log analizi aracını kullanabilirsiniz. Böylece robots txt hatalarını tahminle değil, gerçek tarama verisiyle görürsünüz.
Kurallar çakıştığında Google hangisini uygular?
Google, bir URL'ye uyan allow ve disallow kuralları arasında en uzun yol eşleşmesini seçer. Yani en özel kural kazanır. İki kural eşit uzunluktaysa Google daha az kısıtlayıcı olanı, yani allow kuralını uygular.
Bu mantık, sıralamaya dayalı düşünen ekipleri şaşırtır. Birçok kişi dosyada önce gelen satırın geçerli olduğunu sanır. Ancak Google için satır sırası önemli değildir; belirleyici olan eşleşmenin uzunluğudur.
Örneğin Disallow: /hesap/ ve Allow: /hesap/giris satırlarını birlikte yazdığınızda giriş sayfası taranabilir kalır. Çünkü Allow kuralı daha uzun bir yolla eşleşir. Bu yapı bilinçli kullanıldığında faydalıdır: bir klasörü kapatıp içindeki tek bir sayfayı açabilirsiniz.
Tersine bir örnek de verelim. Disallow: /*?siralama= gibi bir kuralla sıralama parametresini kapatıp Allow: /*?sayfa= ile sayfalama adreslerini açık bırakmak isteyebilirsiniz. Bir URL iki parametreyi birden taşıyorsa hangi kuralın daha uzun eşleştiğini hesaplamanız gerekir. Bu hesap, göründüğünden daha kolay şaşar.
Joker karakterler hesabı zorlaştırır. Bu yüzden çakışan kurallar yazdıysanız birkaç gerçek URL üzerinde sonucu tek tek deneyin. Sitenizin yeni kural setini sıfırdan kurmak istiyorsanız robots.txt oluşturucu temiz bir başlangıç verir; ardından çakışmaları elle gözden geçirin.
User-agent grupları neden yanlış birleşir?
Robots.txt kuralları gruplar halinde çalışır. Her grup bir ya da daha fazla user-agent satırıyla başlar, altındaki kurallar o tarayıcılara uygulanır. Bir tarayıcı yalnız kendisine en özel biçimde uyan grubu dikkate alır; diğer grupları yok sayar.
İşte sık görülen tuzak: dosyada hem genel yıldız grubu hem de Googlebot için ayrı bir grup varsa Googlebot yalnız kendi grubunu okur. Yıldız grubuna yazdığınız önemli engeller Googlebot için geçersiz kalır. Birçok ekip bunu fark etmeden özel bir Googlebot grubu ekler ve genel kuralları kaybeder.
Öte yandan aynı user-agent için dosyada iki ayrı grup varsa Google bunları tek grupta birleştirir. Bu davranış karmaşık dosyalarda beklenmedik sonuçlar doğurur. Özellikle birden çok eklentinin ya da ekibin aynı dosyaya satır eklediği sitelerde gruplar dağınık hale gelir.
- Her tarayıcı için tek bir grup tutun.
- Özel bir Googlebot grubu açıyorsanız genel kuralları o gruba da kopyalayın.
- Grupların arasına açıklama satırı ekleyerek kimin neyi neden eklediğini yazın.
Sitemap satırında en sık hangi robots txt hataları görülür?
Sitemap satırı, site haritanızı tarayıcılara duyurmanın en basit yoludur. Ancak burada da tekrar eden robots txt hataları var. En yaygını göreli adres yazmaktır. Google, Sitemap değerinin protokolü de içeren tam bir URL olmasını ister.
İkinci hata, taşınmış ya da silinmiş bir haritayı göstermektir. Site yenilendiğinde harita adresi değişir ama robots.txt eski adreste kalır. Üçüncüsü, HTTP ile HTTPS ya da www ile www'suz sürüm arasında karışıklıktır. Harita adresi, sitenizin kanonik sürümüyle uyumlu olmalı.
Birkaç iyi haber de var. Resmi belgeye göre birden fazla Sitemap satırı yazabilirsiniz ve bu satırlar herhangi bir user-agent grubuna bağlı değildir. Ayrıca harita, robots.txt ile aynı alan adında durmak zorunda değildir.
- Sitemap satırının tam URL olduğunu kontrol edin.
- Adresi tarayıcıda açın; 200 yanıtı ve geçerli XML görmelisiniz.
- Haritada robots.txt ile engellediğiniz URL'ler olmasın; iki sinyal birbiriyle çelişir.
Haritayı yeniden üretmeniz gerekirse XML sitemap oluşturucu işinizi hızlandırır. Tarih alanını doğru doldurmak için lastmod etiketi yazısına da bakın.
500 KiB sınırı ve dosya biçimi hangi sorunları doğurur?
Google robots.txt dosyasının ilk 500 kibibaytını okur; bu sınırın ötesindeki içeriği yok sayar. RFC 9309 standardı da tarayıcıların en az 500 KiB okumasını şart koşar. Küçük bir site için bu sınır uzak görünür, ancak otomatik üretilen dosyalar kolayca şişer.
Bu sorunu en çok binlerce tekil URL'yi tek tek Disallow satırına döken sitelerde görüyorum. Örneğin her silinen ürün için ayrı satır ekleyen bir eklenti, dosyayı zamanla büyütür. Sınır aşıldığında sondaki kurallar sessizce devre dışı kalır ve hangi satırın okunmadığını kimse bilmez.
Çözüm, tek tek URL yerine desen yazmaktır. Ortak bir klasör ya da parametre varsa tek bir kural yüzlerce satırın yerini tutar. Ayrıca silinen sayfaları robots.txt ile değil, 404 ya da 410 yanıtıyla yönetmek daha doğrudur.
Biçim tarafında da iki kural var. Dosya UTF-8 kodlamasıyla kaydedilmeli ve satırlar CR, CR/LF veya LF ile ayrılmalı. Kelime işlemciden kopyalanan akıllı tırnaklar, görünmez karakterler ya da farklı kodlamalar satırların yanlış ayrıştırılmasına yol açabilir. Standardın ayrıntısını merak ederseniz RFC 9309 metnini okuyabilirsiniz.
Sunucunun yanıt kodu robots.txt dosyasını nasıl etkiler?
Google, robots.txt dosyasının içeriği kadar sunucunun bu dosyaya verdiği HTTP yanıtına da bakar. 2xx yanıtında dosyayı olduğu gibi işler. 4xx yanıtlarında, 429 hariç, dosya yokmuş gibi davranır ve siteyi kısıtlamasız tarar.
Asıl tehlike 5xx hatalarındadır. Resmi belgeye göre Google, robots.txt isteği sunucu hatası döndürdüğünde ilk 12 saat boyunca taramayı durdurur. Sonraki 30 gün boyunca önbellekteki son geçerli sürümü kullanır. 30 günün sonunda site erişilebilirse kısıtlama yokmuş gibi davranır.
Yani robots.txt adresinde kısa süreli bir sunucu hatası bile tüm sitenin taranmasını yavaşlatabilir. Bunu en çok güvenlik duvarı, CDN ya da bakım modu ayarlarının robots.txt isteğini engellediği durumlarda görüyorum. Googlebot tarama sıklığınız açıklanamayan biçimde düştüyse tarama sıklığı düşüşü yazısındaki adımlarla birlikte bu yanıt kodunu da kontrol edin.
Bir ayrıntıyı da ekleyeyim: 429 yanıtı diğer 4xx kodlarından farklıdır. Google bunu "dosya yok" diye değil, "yavaşla" diye yorumlar ve tarama hızını düşürür. Bu yüzden hız sınırlama kuralı yazarken robots.txt adresini ve Googlebot isteklerini ayrıca düşünün.
Yönlendirmeler için de bir sınır var. Google en az beş yönlendirme adımını izler, sonrasında dosyayı 404 gibi değerlendirir. Ayrıca Google dosyayı genellikle 24 saate kadar önbellekte tutar; yaptığınız değişiklik bu yüzden anında etkili olmayabilir.
Alt alan adı, protokol ve port farkı neden gözden kaçar?
Robots.txt dosyası yalnız bulunduğu ana makine, protokol ve port için geçerlidir. Yani ornek.com adresindeki dosya, blog.ornek.com alt alan adını kapsamaz. Her alt alan adı kendi kök dizininde ayrı bir robots.txt dosyasına ihtiyaç duyar.
Bu kural özellikle mağaza, blog ya da yardım merkezini ayrı alt alan adında çalıştıran şirketlerde unutulur. Ana sitenin dosyası özenle hazırlanır; alt alan adında ise ya hiç dosya yoktur ya da platformun varsayılan dosyası kalır. Varsayılan dosya bazen gereksiz alanları açık bırakır, bazen de önemli sayfaları kapatır.
Dosyanın yeri de önemlidir. Robots.txt yalnız kök dizinde çalışır; bir alt klasöre koyduğunuz dosyayı tarayıcılar aramaz. Ayrıca standart dışı bir portta yayın yapan bir hizmet için ayrı dosya gerekir. HTTP ile HTTPS de ayrı kökler sayılır, bu yüzden yönlendirme zincirinizin robots.txt isteğini de doğru adrese taşıdığından emin olun.
Pratik bir alışkanlık önereyim: sahip olduğunuz tüm alan adlarını ve alt alan adlarını bir listede toplayın. Her birinin robots.txt adresini ayrı ayrı açın ve içeriğini not edin. Bu küçük envanter, unutulmuş bir test alt alan adının dizine girmesini ya da önemli bir mağaza alanının kapalı kalmasını erkenden gösterir.
Site yapınızı yeniden kurarken bu ayrıntıları kaybetmemek için site taşıma kontrol listesini kullanmanızı öneririm.
Crawl-delay ve desteklenmeyen satırlar neden işe yaramaz?
Google robots.txt içinde yalnız dört alanı destekler: user-agent, allow, disallow ve sitemap. Crawl-delay, noindex, nofollow ya da host gibi satırları Google yok sayar. Bu satırlar dosyada durabilir ama Googlebot üzerinde hiçbir etkileri olmaz.
Sorun, ekiplerin bu satırlara güvenmesidir. Örneğin sunucu yükü arttığında dosyaya Crawl-delay ekleyip sorunu çözdüğünü düşünen bir ekip, Googlebot'un tarama hızını hiç değiştirmemiş olur. Başka bazı arama motorları bu satırı dikkate alabilir; ancak Google için geçerli değildir.
Googlebot'un sunucunuzu zorladığını düşünüyorsanız geçici olarak 500, 503 ya da 429 yanıtları Google'a yavaşlaması gerektiğini söyler. Uzun süreli bir çözüm ise sunucu kapasitesi, önbellek ve gereksiz URL üretimini azaltmaktır. Bu tür teknik temel sorunlar için teknik SEO ipuçları yazısına da göz atabilirsiniz.
En sık robots txt hataları ve doğru kullanım karşılaştırması
Aşağıdaki tablo, bu yazıda anlattığım hataları tek bakışta karşılaştırmanızı sağlar. Kendi dosyanızı açıp her satırı bu tabloyla eşleştirebilirsiniz.
| Hata | Ne olur? | Doğru yaklaşım |
|---|---|---|
| CSS ve JS klasörlerini engellemek | Google sayfanın işlenmiş halini göremez | Kaynak dosyalarını açık bırakın |
| Canlıda Disallow: / kalması | Tüm site taranmaz | Yayın öncesi kontrol listesine ekleyin |
| Robots.txt ile dizinden çıkarmaya çalışmak | URL açıklamasız biçimde dizinde kalabilir | Noindex veya X-Robots-Tag kullanın |
| Noindex ile Disallow'u birlikte kullanmak | Google etiketi okuyamaz | Önce noindex, sonra gerekirse engel |
| Yolda yanlış harf kullanmak | Kural hedef klasörü kapsamaz | Sunucudaki gerçek yazımla eşleştirin |
| Göreli Sitemap adresi | Harita duyurusu geçersiz kalır | Protokollü tam URL yazın |
| 500 KiB sınırını aşmak | Sondaki kurallar okunmaz | Tek tek URL yerine desen yazın |
| Robots.txt adresinde 5xx | Tarama durur ya da eski sürüm kullanılır | Yanıt kodunu izleyin |
Tabloyu bir denetim şablonu gibi kullanabilirsiniz. Her satır için dosyanızda karşılığı olan bir kural var mı, yok mu diye bakın. Karşılığı olan satırları işaretleyin, ardından bu yazının ilgili bölümüne dönüp çözümü uygulayın. Böylece tek oturumda dosyanın tamamını gözden geçirirsiniz.
Tablodaki her satırın ortak noktası şudur: hata çoğu zaman görünür bir arıza üretmez. Site çalışır, sayfalar açılır, ama tarama sessizce bozulur. Bu nedenle düzenli kontrol, tek seferlik düzeltmeden daha değerlidir.
Robots txt hatalarını hangi araçlarla bulursunuz?
İlk durak Search Console'dur. Ayarlar bölümündeki robots.txt raporu, Google'ın dosyanızı en son ne zaman aldığını, hangi yanıtı gördüğünü ve ayrıştırma sırasında hangi uyarıları bulduğunu gösterir. URL Denetimi aracı ise tek bir adresin robots.txt ile engelli olup olmadığını söyler.
Search Console'u yeni kullanıyorsanız Search Console kullanım rehberi temel raporları anlatıyor. Ancak Search Console size Google'ın gördüğü özeti verir; tarayıcının gerçekte ne istediğini görmek için sunucu kayıtlarına inmeniz gerekir.
- Sunucu kayıtları: Googlebot'un robots.txt isteğine hangi yanıtı aldığını ve engelli alanlara istek atıp atmadığını gösterir.
- Tarama araçları: sitenizi robots.txt kurallarına uyarak tarar ve engellenen URL listesini çıkarır.
- Genel SEO denetimi: SEO analiz aracı ile sayfa bazında hızlı bir kontrol yapabilirsiniz.
Kayıt dosyalarında özellikle iki şeye bakın. Birincisi, Googlebot'un robots.txt adresine düzenli istek atıp atmadığı ve hangi yanıt kodunu aldığıdır. İkincisi, engellemeyi düşündüğünüz alanlara ne sıklıkla gittiğidir. Hiç ziyaret edilmeyen bir alanı engellemek size tarama açısından bir şey kazandırmaz; yalnız dosyayı kalabalıklaştırır.
Benim yöntemim bu üç kaynağı birlikte okumaktır. Örneğin Search Console bir sayfanın engelli olduğunu söylüyorsa kayıtlarda Googlebot'un o yolu en son ne zaman istediğine bakarım. Böylece robots txt hatalarının ne kadar süredir etkili olduğunu tahmin edebilirim.
Site taşıma ve yayın öncesinde neleri kontrol etmelisiniz?
Robots txt hatalarının büyük kısmı yeni bir sürümün canlıya çıktığı gün doğar. Tasarım değişir, CMS değişir, sunucu değişir; dosya ise ya eski halinde kalır ya da test ortamının kopyası olarak taşınır. Bu yüzden yayın günü kısa bir kontrol listesi uygulayın.
- Canlı sitede robots.txt adresini açın ve Disallow: / satırı olmadığını görün.
- Dosyanın 200 yanıtı döndürdüğünü ve yönlendirme zincirine girmediğini doğrulayın.
- Sitemap satırının yeni harita adresini gösterdiğini kontrol edin.
- Yeni URL yapısındaki klasör adlarını robots.txt satırlarıyla harf harf karşılaştırın.
- Önemli şablonlarda URL Denetimi ile canlı test yapıp işlenmiş görünüme bakın.
- İlk hafta sunucu kayıtlarında Googlebot isteklerini izleyin.
Bu liste on dakikanızı alır ama haftalarca sürebilecek bir görünürlük kaybını önler. Yenileme projesinin bütününde SEO'yu korumak için site yenilerken SEO rehberindeki adımları da bu listeyle birlikte uygulayabilirsiniz.
Robots txt hatalarını önlemek için nasıl bir süreç kurmalısınız?
Tek seferlik düzeltme yetmez; robots.txt dosyası yaşayan bir dosyadır. Eklentiler satır ekler, ekipler değişir, yeni alt alan adları açılır. Bu nedenle dosyanın bir sahibi olmalı ve her değişiklik kayıt altına girmeli.
Önerdiğim süreç üç parçadan oluşur. İlk olarak dosyayı sürüm kontrolünde tutun ve her değişikliğe kısa bir açıklama yazın. İkinci olarak her ay Search Console robots.txt raporuna ve engellenen sayfa sayısına bakın. Son olarak her büyük yayında yukarıdaki kontrol listesini uygulayın.
Ekibimle yürüttüğümüz SEO danışmanlığı çalışmalarında robots.txt dosyası her teknik denetimin ilk maddelerinden biridir. Çünkü bu dosyadaki bir hata, içerik ya da bağlantı çalışmalarının etkisini tamamen gölgeleyebilir. Önce taramanın sağlıklı olduğundan emin oluyor, ardından diğer işlere geçiyoruz.
Değişikliklerin sonucunu da ölçün. Dosyada bir kural ekledikten ya da kaldırdıktan sonra birkaç hafta boyunca Search Console'daki sayfa dizine ekleme raporunu ve tarama istatistiklerini izleyin. Engellenen URL sayısı beklediğiniz yönde değişmiyorsa kuralın yazımına geri dönün. Ölçmediğiniz bir düzeltmenin işe yarayıp yaramadığını bilemezsiniz.
Kısacası robots txt hataları nadiren gürültü çıkarır ama sonuçları uzun sürer. Dosyanızı bugün açın, bu yazıdaki tabloyla karşılaştırın ve her satırın neden orada olduğunu bir cümleyle açıklayabildiğinizden emin olun. Açıklayamadığınız satır, büyük olasılıkla gereksizdir.




