Googlebot Doğrulama: WAF ve CDN Engellerini Giderme

Googlebot erişimi, bir sitenin Google arama sistemleri tarafından sorunsuz taranabilmesi için sunucunun, CDN katmanının ve güvenlik duvarının Google'ın tarayıcılarına yol vermesidir. Sorun şu ki Search Console'da "sunucu hatası" ya da "taranamadı" uyarısı görüp robots.txt dosyasını defalarca kontrol edebilir, yine de nedeni bulamayabilirsiniz. Çünkü engel çoğu zaman robots.txt'te değil, ondan daha önceki bir katmanda, yani WAF kuralında, CDN bot korumasında ya da hız sınırında bulunur.

Bu yazı teknik SEO uzmanı, geliştirici ve hosting ya da güvenlik yöneticisi için yazıldı. Önce Google'ın tarayıcı türlerini ayırır, sonra gerçek Googlebot'un nasıl doğrulanacağını anlatır. Ardından güvenlik katmanlarının meşru botu neden engelleyebildiğini, 403, 429 ve 503 yanıtlarının Google tarafında nasıl yorumlandığını ve bir erişim sorununda hangi sırayla ilerleyip hangi kanıtı saklayacağınızı ele alır. Belirli bir güvenlik ürününün arayüzü, fiyatı ya da ayar adı anlatılmaz; ilkeler ürün bağımsızdır.

Google Tarayıcıları ve Googlebot Türleri

Günlüklerde "Google" adını taşıyan her istek aynı şey değildir. Google'ın tarayıcılara genel bakış (yeni sekmede açılır) belgesi istekleri üç gruba ayırır. Bu ayrım hem hangi kuralın geçerli olacağını hem de güvenlik duvarında hangi izni vereceğinizi belirler.

Tablo, Google'ın belge sayfasındaki tanımlara dayanır. Pratik sonuç şudur: tek bir "Google" kuralı yazmak yerine, hangi istek grubunu açtığınızı bilmeniz gerekir. Kullanıcı tetiklemeli bir getiricinin robots.txt'yi yok saymasının nedeni bir kullanıcının kendi isteğiyle çalışmasıdır; bunu robots.txt engelinin çalışmadığı şeklinde yorumlamayın.

Googlebot iki tarayıcıdan oluşur

Google'ın Googlebot belgesine (yeni sekmede açılır) göre Googlebot, mobil kullanıcıyı taklit eden bir akıllı telefon tarayıcısı ile masaüstü kullanıcıyı taklit eden bir masaüstü tarayıcısının ortak adıdır. İkisi aynı robots.txt ürün belirtecini kullanır, bu yüzden robots.txt ile yalnızca birini hedefleyemezsiniz. Çoğu site mobil öncelikli dizinlemeye alındığı için istekler ağırlıklı olarak akıllı telefon tarayıcısından gelir. Güvenlik duvarınız "mobil kullanıcı aracısı" gören bir isteği yalnızca gerçek telefon sanıp farklı davranıyorsa, Googlebot'un mobil istekleri bu kurala takılabilir.

Taramanın teknik sınırları

Aynı belgeler Googlebot'un arama için desteklenen dosya türlerinde, HTML dahil, ilk 2 MB'ı getirdiğini, PDF için bu sınırın 64 MB olduğunu söyler. HTML içinde başvurulan CSS ve JavaScript dosyaları ayrı ayrı çekilir ve her biri aynı sınıra tabidir. Sınır sıkıştırılmamış veri için geçerlidir. Genel tarayıcı belgesi ise varsayılan olarak bir dosyanın ilk 15 MB'ının taranacağını yazar ve bireysel projelerin farklı sınır belirleyebileceğini ekler. Yani bir sayfanın HTML'i çok şişkinse, önemli içerik ve bağlantılar sınırın ötesinde kalabilir; bu bir bot engeli değil ama erişim sorunu gibi görünebilir.

Taramanın taşıma tarafı da önemlidir. Tarayıcılar HTTP/1.1 ve HTTP/2 destekler, varsayılan HTTP/1.1'dir; gzip, deflate ve Brotli (br) sıkıştırmalarını kabul eder ve hangilerini desteklediğini Accept-Encoding başlığında bildirir. HTTP/2 üzerinden bir isteğe 421 yanıtı vermek HTTP/2'den çıkma yoludur, ancak belge bunu geçici bir çözüm olarak niteler. Bir CDN ya da sunucu bu başlıkları yanlış işliyorsa, tarama sorunu bot engeli gibi görünse de kökeninde protokol ayarı olabilir.

Gerçek Googlebot Nasıl Doğrulanır: Ters DNS ve Resmi IP Listeleri

Kullanıcı aracısı metni kimlik değil, bir iddiadır. Google'ın Googlebot belgesi, bu başlığın başka tarayıcılar tarafından sıkça taklit edildiğini ve tek başına güvenilmemesi gerektiğini belirtir. Bir isteğin gerçekten Google'dan geldiğini anlamanın iki yolu vardır; ikisi de Google'ın doğrulama belgesinde (yeni sekmede açılır) açıklanır.

Yöntem 1: Ters DNS ve ileri DNS

Belge bu yöntemi çoğu kullanım için yeterli ve tek tek bakışlar için uygun olarak tanımlar. Adımlar şöyledir:

1. Günlükteki erişim IP'si için host komutuyla ters DNS sorgusu yapın.
2. Dönen alan adının googlebot.com, google.com veya googleusercontent.com olduğunu doğrulayın.
3. Bu alan adı için host komutuyla ileri DNS sorgusu yapın.
4. Sonucun günlükteki özgün IP ile aynı olduğunu doğrulayın.

İleri sorgu atlanamaz. Ters sorguyu herkes kendi IP'si için istediği değerle yapılandırabilir; ileri sorgunun aynı IP'ye dönmesi zinciri kapatır. Belgenin verdiği örnek IP'ler 66.249.66.1, 35.247.243.240 ve 66.249.90.77'dir; kendi günlüğünüzdeki adresle denerken sonucu aynı sırayla okuyun.

Alan adı desenleri de ayırt edicidir. Yaygın tarayıcılar için ters DNS crawl-***-***-***-***.googlebot.com ya da geo-crawl-***-***-***-***.geo.googlebot.com biçimindedir. Özel amaçlı tarayıcılar rate-limited-proxy-***-***-***-***.google.com, Google kontrolündeki kullanıcı tetiklemeli getiriciler ise google-proxy-***-***-***-***.google.com desenini taşır. Diğer kullanıcı tetiklemeli getiricilerin IP'leri gae.googleusercontent.com altında çözülür. Bu desenler hangi gruba baktığınızı anlamanıza yardım eder.

Yöntem 2: Resmi IP aralığı dosyaları

Büyük ölçekli arama için belge ikinci yöntemi önerir: isteğin IP'sini Google'ın yayımladığı JSON dosyalarındaki CIDR aralıklarıyla eşleştirmek. Dosyalar tarayıcı grubuna göre ayrılmıştır: common-crawlers.json yaygın tarayıcılar, special-crawlers.json özel amaçlı tarayıcılar, user-triggered-fetchers.json ve user-triggered-fetchers-google.json kullanıcı tetiklemeli getiriciler, user-triggered-agents.json ise kullanıcı tetiklemeli ajanlar içindir. Apps Script gibi servislerin kullandığı diğer Google IP'leri için genel liste gstatic.com adresindeki goog.json dosyasıdır.

Belge dosyaların ne sıklıkla değiştiğini yazmaz. Bu yüzden listeyi bir kez kopyalayıp güvenlik duvarına gömmek yerine, otomatik güncellenen bir kaynak kullanmak daha sağlamdır. Güncelleme sıklığı ve kaynak adresi için belgenin güncel hâline bakın.

Hangi yöntem ne zaman?

Tek bir şüpheli IP için ters ve ileri sorgu birkaç saniyede sonuç verir ve günlük incelemesinde yeterlidir. Güvenlik duvarı kuralı ya da toplu günlük süzgeci gibi otomatik işlerde ise JSON aralıkları daha uygundur, çünkü her istek için DNS sorgusu yapmak yavaş ve maliyetlidir. İkisini birlikte kullanmak da mümkündür: otomasyon IP aralığına bakar, şüpheli kalan örnekleri bir kişi DNS ile doğrular.

Doğrulamanın sınırı

Doğrulama yalnızca isteğin Google altyapısından geldiğini söyler; hangi Google ürününden geldiğini ve robots.txt'ye uyup uymayacağını, yukarıdaki grup ayrımı belirler. Ayrıca doğrulanmış bir IP'den gelen isteği sınırsız hızda sunmak zorunda değilsiniz; sunucu kapasitesi yetmiyorsa Google'ın belirttiği yanıt kodlarıyla hızı kontrollü düşürebilirsiniz. Bu konu aşağıda 429 ve 503 bölümünde ele alınıyor.

WAF, CDN ve Bot Koruması Meşru Botu Neden Engeller?

Güvenlik katmanları bir isteğe bakıp "insan mı, otomasyon mu, saldırı mı" kararı vermeye çalışır. Googlebot ise bir otomasyondur. Bu yüzden bot korumasının sert ayarları meşru tarayıcıyı da yakalayabilir. Aşağıdaki nedenler belirli bir ürüne bağlı değildir; ürün bağımsız mantıksal örüntülerdir ve sitenizde hangisinin geçerli olduğunu günlükler gösterecektir.

İstek hızı ve ani sıçrama

Hız sınırı kuralları belirli bir IP'den belirli sürede gelen istek sayısını sayar. Googlebot bir site bölümünü kısa sürede yoğun tarayabilir. Kural "dakikada şu kadar isteği aşan IP'yi engelle" gibiyse, gerçek bot da eşiğe takılabilir. Belirti çoğunlukla belirli saatlerde birikmiş 429 ya da 403 yanıtlarıdır.

Kullanıcı aracısı ve başlık denetimi

Bazı kurallar, kendini bot olarak tanıtan ama beklenen başlık düzenine uymayan istekleri engeller. Bir kural "tarayıcı gibi görünmeyen isteği reddet" diyorsa, kendini şeffaf biçimde bot olarak tanıtan Googlebot da bu kurala takılabilir. Tersi de doğrudur: yalnızca "Googlebot" metnini taşıyan her isteği izinli saymak, sahte botlara serbest geçiş verir.

IP itibarı ve ülke kuralları

Coğrafi engeller ve IP itibar listeleri de Googlebot'un IP'lerini kapsayabilir. Google tarayıcılarının hangi ülkelerden çıktığına dair kesin bir varsayımda bulunmayın; Googlebot belgesi yalnızca ABD IP'lerinden tarama yapıldığında saat diliminin Pasifik saati olduğunu belirtir. Dolayısıyla "yalnızca belirli ülkelerden trafiğe izin ver" kuralı arama botlarını dışarıda bırakabilir.

JavaScript meydan okuması ve CAPTCHA

Bot koruması şüpheli isteğe doğrulama sayfası, JavaScript sınavı ya da CAPTCHA gösterebilir. Bir insan bu adımı geçer; arama botu ise sayfa yerine sınav ekranını görür. Bu durumda yanıt kodu 200 olabilir ama içerik boştur. En zor yakalanan senaryo budur, çünkü sunucu günlüğü başarılı bir istek gösterir. Böyle bir durumda Search Console'daki URL denetimi aracı ile bir sayfanın nasıl getirildiğine bakmak ve ekran görüntüsünü gerçek içerikle karşılaştırmak yararlıdır.

CDN ve "doğrulanmış bot" kategorileri

Bazı CDN sağlayıcıları bilinen botları "doğrulanmış" olarak sınıflandırır. Cloudflare'in doğrulanmış botlar belgesi (yeni sekmede açılır) tanımı şöyle yapar: Cloudflare'in kim olduğu ve ne yaptığı konusunda şeffaf olduğunu onayladığı bot ya da ajan. Doğrulama için botun kendini deterministik biçimde, örneğin Web Bot Auth imzası ya da yayımlanmış IP listesi ve sabit kullanıcı aracısı ile tanıtması ve kötüye kullanım davranışı göstermemesi beklenir. Belge ayrıca doğrulanmış botların tüm planlardaki varsayılan bot yapılandırmalarının dışında bırakıldığını söyler. Yine de bu, sitenizdeki özel kuralların bu botu yakalamayacağı anlamına gelmez; özel kural yazdıysanız o kuralın doğrulanmış botları da kapsayıp kapsamadığını kontrol edin. Bu yazı yalnızca Cloudflare belgesini temel alır; başka CDN ve WAF ürünlerinin kategori adları ve varsayılanları farklı olabilir, kendi sağlayıcınızın belgesine bakın.

Kurgusal örnek: Yalnızca bir bölümün düşmesi

Kurgusal örnek: bir e-ticaret sitesinde, kategori sayfaları normal taranırken filtreli liste URL'lerinde Search Console'da sunucu hatası artıyor. Günlüğe bakıldığında filtreli URL'lere gelen isteklerin tek bir WAF kuralına takıldığı ve 403 aldığı görülüyor. Kural, parametre sayısı yüksek isteklerin otomatik bot olduğunu varsayıyor. Doğrulanmış Googlebot IP'leri bu kuraldan muaf tutulduğunda hata düşüyor. Bu örnek, sorunun sitenin tamamını değil belirli bir URL desenini etkileyebileceğini ve hata dağılımına URL grubu üzerinden bakmanın gerekli olduğunu göstermek içindir; rakam ya da gerçek bir site sonucu içermez.

robots.txt, 403, 429 ve 503 Yanıtları: Erişim Çakışmaları

Bir URL'nin neden alınamadığını anlamak için hangi katmanın ne söylediğini ayırmak gerekir. robots.txt tarayıcıya "bu URL'yi isteme" der; HTTP durum kodu ise isteğin sonunda sunucunun ne cevap verdiğini söyler. İkisi çakıştığında teşhis zorlaşır. robots.txt kurallarını sınamak için robots.txt testi rehberi, durum kodlarının dizinleme etkisini görmek için HTTP durum kodları rehberi yararlıdır; burada yalnızca erişim katmanıyla ilgili kesişimlere bakılır.

4xx yanıtları: 401 ve 403

Google'ın HTTP durum kodları belgesi (yeni sekmede açılır), 429 dışındaki 4xx kodlarından gelen içeriğin yok sayıldığını belirtir. Tarayıcılar sonraki işleme sistemine içeriğin olmadığını bildirir, dizinde zaten bulunan URL'ler dizinden çıkarılır, yeni karşılaşılan 404 sayfaları işlenmez ve tarama sıklığı kademeli olarak düşer. Belge açıkça uyarır: tarama hızını sınırlamak için 401 ve 403 kullanmayın. 4xx kodlarının (429 hariç) tarama hızı üzerinde etkisi yoktur.

Bunun pratik sonucu: bir WAF kuralı Googlebot'a 403 döndürüyorsa, bu botun hızını yavaşlatmaz; yalnızca o URL'lerin içeriğini Google için erişilmez kılar. İçerik erişilmezse dizinden çıkma riski doğar.

429 ve 5xx yanıtları

Aynı belgeye göre Google 429'u sunucunun aşırı yüklendiği sinyali sayar ve sunucu hatası gibi ele alır. 5xx ve 429 hataları Google'ın taramayı geçici olarak yavaşlatmasına neden olur; dizindeki URL'ler önce dizinde kalır ama sonunda düşürülür. 500 için tarama hızı düşüşü hata veren URL sayısıyla orantılıdır; 502 ve 503 için kalıcı hata veren URL'ler dizinden çıkarılır. Sunucu yeniden 2xx dönmeye başlarsa Google tarama hızını kademeli olarak artırır. Belge, bu hata türlerinin robots.txt davranışı ile ağ ve DNS hatalarının ayrıntısını başka sayfalara bırakır.

503 ve 429'u bilinçli kullanmak

Sunucu gerçekten zorlanıyorsa Google'ın tarama hızını düşürme belgesi (yeni sekmede açılır) acil durum için şunu önerir: tarama isteklerine kısa bir süre 200 yerine 500, 503 veya 429 döndürün. Belirtilen süre birkaç saat ya da 1-2 gündür. Etki, içerik döndüren URL'ler dahil, tüm ana makine adında tarama hızını düşürür ve hata azaldıkça otomatik olarak toparlanır. 503 ve 429 ile Retry-After başlığı eklenebilir; bu başlık saniye cinsinden gecikme ya da mutlak bir UTC tarih ve saat olabilir.

Belge sürenin riskini de açıkça yazar: Googlebot aynı URL'de bu kodları birkaç gün gözlemlerse URL Google dizininden çıkarılabilir. Ayrıca yeni sayfaların keşfi azalır, mevcut sayfaların yenilenmesi seyrekleşir ve kaldırılan sayfalar dizinde daha uzun kalabilir; Google Ads kampanyaları durdurulabilir ya da iptal edilebilir. Tarama hızını artırma talebi ise mümkün değildir: belgeye göre hızı artırma isteğinde bulunamazsınız; olağan dışı yüksek tarama için Search Console üzerinden özel bir bildirim formu bulunur.

robots.txt dosyası 5xx dönerse

En az fark edilen çakışma budur. Google'ın robots.txt belgesi (yeni sekmede açılır) iki durumu ayırır. 429 dışındaki 4xx yanıtlarında robots.txt yokmuş gibi davranılır, yani tarama kısıtı uygulanmaz. 5xx yanıtında ise Google önce siteyi taramayı 12 saat durdurur ve dosyayı yeniden almayı dener. Yeni kopya alınamazsa son geçerli önbellek kopyası en fazla 30 gün kullanılır; önbellekte kopya yoksa kısıt yokmuş gibi davranılır. 30 günden uzun süren hatalarda site genel olarak erişilebilirse robots.txt yokmuş gibi davranılır ve kontrol sürer; site genel erişilebilirlik sorunu yaşıyorsa tarama durur ve robots.txt periyodik olarak istenir. Dosya genellikle 24 saate kadar önbelleğe alınır ve en çok 500 KiB'lık kısmı işlenir.

Bunun güvenlik tarafındaki yansıması şudur: WAF yalnızca robots.txt adresine rate limit uygular ya da onu 403 ile kapatırsa, Google dosyayı yokmuş gibi sayar ve tarama kısıtlarınız devre dışı kalır. robots.txt'nin her koşulda 200 ve düz metin döndürdüğünü izleyin.

Kısa karşılaştırma tablosu

Erişim Sorunu İçin Tanı Akışı ve Kayıt Tutma

Erişim sorunlarını tahmine dayalı çözmek, bir kuralı kapatıp açmaya dönüşür. Aşağıdaki sıra, her adımda kanıt üretmek için tasarlandı. Sunucu günlüklerini nasıl okuyacağınızı SEO sunucu günlüğü analizi yazısında bulabilirsiniz; burada günlük yöntemi tekrar edilmez, yalnızca erişim sorununa uyarlanır.

Adım 1: Belirtiyi tanımlayın

Önce şu sorulara yazılı yanıt verin: Sorun hangi URL grubunda? Sitenin tamamında mı, bir klasörde mi, bir parametre desenindedir? Ne zaman başladı? Search Console'daki hata türü nedir ve hangi tarih aralığında görünüyor? Burada tahmin yerine ekran görüntüsü ve tarih saklayın.

Adım 2: Günlükte Google adlı istekleri süzün

Sunucu veya CDN günlüğünde sorunlu URL grubuna Google adıyla gelen istekleri bulun. Her istek için tarih, IP, kullanıcı aracısı, URL, yanıt kodu ve mümkünse yanıtı veren katmanı (kaynak sunucu mu, CDN mi, WAF mı) not edin. Sonuçta "hiç istek yok", "istek var ama 4xx/5xx" ve "istek var, 200 ama boş" gibi üç farklı tablo çıkabilir; her biri farklı sonuca götürür.

Adım 3: IP'leri doğrulayın

Elde edilen IP'lerden bir örnek grubu seçin ve ters DNS ile ileri DNS sorgusu ile doğrulayın, yüksek hacim varsa JSON aralıklarıyla eşleştirin. Böylece hata alan isteklerin gerçek Googlebot olup olmadığını ayırırsınız. Doğrulanmayan istekler büyük olasılıkla sahte bottur; bunların engellenmesi sorun değil, hatta amaçtır. Doğrulanan isteklerin engellenmesi ise düzeltilecek bir sorundur.

Adım 4: Katmanı bulun

Yanıtı hangi katmanın verdiğini ayırmak için şu karşılaştırmaları yapın: kaynak sunucuya doğrudan (CDN'i atlayarak, yetkiniz varsa) aynı URL'yi isteyin; CDN üzerinden normal bir istemciyle aynı URL'yi isteyin; WAF günlüğünde ilgili kuralı arayın. Hata yalnızca CDN üzerinden geliyorsa suçlu CDN ya da WAF kuralıdır; kaynak sunucuda da varsa uygulama ya da sunucu yapılandırmasına bakın. Bir katmanı atlayarak test yaparken üretim sistemlerinde dikkatli olun ve yalnızca yetkili olduğunuz araçları kullanın.

Adım 5: Kuralı daraltarak düzeltin

En az müdahaleli çözüm, doğrulanmış Googlebot IP aralıklarını ilgili hız ve bot kurallarından muaf tutmaktır; kullanıcı aracısı metnine göre geniş izin vermek yerine IP aralığı ve DNS doğrulamasına dayanın. Muafiyetin hangi yolları ve hangi kuralları kapsadığını yazılı olarak kaydedin. Bu değişikliği önce bir test ortamında ya da sınırlı bir URL grubunda deneyin ve sonuçları günlükte izleyin.

Adım 6: İyileşmeyi doğrulayın

Düzeltmeden sonra Search Console'da sorunlu URL'ler için URL denetimi aracını kullanın, günlükte aynı URL grubuna gelen Google isteklerinin yanıt kodlarının 200'e döndüğünü kontrol edin ve birkaç gün boyunca izleyin. Search Console raporları gecikmeli güncellenir; günlük bu yüzden daha hızlı kanıttır. Düzeltme sonrası da robots.txt'nin 200 döndürdüğünü ve yanıt gövdesinin gerçek içerik olduğunu doğrulayın.

Kayıt tutma şablonu

Her olay için aşağıdaki alanları bir tabloya yazmak, sonraki sorunlarda hızlı karşılaştırma yapmayı sağlar:

• Olay tarihi ve fark edilme biçimi (Search Console uyarısı, günlük, kullanıcı bildirimi).
• Etkilenen URL grubu ve örnek üç URL.
• Günlükten alınan örnek istekler: tarih, IP, kullanıcı aracısı, yanıt kodu.
• IP doğrulama sonucu ve kullanılan yöntem (ters ve ileri DNS ya da JSON aralığı).
• Yanıtı veren katman ve ilgili kural adı ya da kimliği.
• Yapılan değişiklik, tarih, değişikliği yapan kişi ve geri alma notu.
• Düzeltme sonrası kontrol sonucu ve sonraki izleme tarihi.

Bu kayıt, güvenlik ve SEO ekipleri arasında ortak bir dil kurar. "Bot engellendi" demek yerine "şu kural şu URL grubuna şu tarihte şu kod döndürdü" demek, kuralın düzeltilmesini çok kolaylaştırır.

Yapay Zekâ Botları, Bot Politikası ve Google'ın Ayrımı

Bot korumasını sıkılaştırırken çoğu site yapay zekâ eğitim ve arama botlarını da hedefler. Burada iki ayrı karar vardır ve karıştırılmamalıdır: arama görünürlüğü için gerekli botlar ile kullanım amacı farklı botlar. Yapay zekâ botlarının robots.txt ile yönetimini yapay zekâ botları ve robots.txt rehberinde bulabilirsiniz; bu yazı yalnızca güvenlik katmanında yapılacak bir toptan "tüm botları engelle" kuralının Googlebot'u da kapsayabileceği riskine dikkat çeker.

Toptan kural yazmadan önce şu kontrolleri yapın: kural kullanıcı aracısına göre mi IP'ye göre mi çalışıyor, kapsamında Googlebot IP aralıkları var mı, kural robots.txt ve sitemap adreslerini de kapsıyor mu, istisna listesi nasıl güncelleniyor? Sorunun çözümü tüm botlara izin vermek değil, hangi botun hangi amaçla geldiğini ayırt etmektir. Politikayı yazıya dökmek de yararlıdır: hangi botlar neden izinli, hangileri neden kapalı.

Sitemap, kaynak dosyalar ve sunum

Googlebot'a yalnızca HTML değil, sayfanın işlenmesi için gereken CSS, JavaScript ve görsel dosyaları da açık olmalıdır. Googlebot belgesi bu kaynakların ayrı ayrı çekildiğini söyler. Statik dosyaları sunan ayrı bir alan adı ya da CDN alt alan adı varsa, bot korumasının orada farklı çalışıp çalışmadığını kontrol edin. Bu kaynaklar engellenirse sayfa işlenirken eksik görünebilir.

Sık Yapılan Hatalar

• Kullanıcı aracısına güvenmek: "Googlebot" yazan her isteği izinli saymak, taklit eden botlara kapı açar; tersi olarak mobil kullanıcı aracısını yanlış sınıflandırmak gerçek botu kapatabilir.
• Yalnızca ters DNS yapmak: İleri sorgu atlanırsa doğrulama tamamlanmaz.
• 403 ile hız ayarı yapmak: Google'ın belgesi bunu açıkça önermez; 403 içerik erişimini kapatır, hızı düzenlemez.
• Uzun süre 503 vermek: Birkaç günü aşan 503 ve 429 dizinden çıkma riskini artırır.
• robots.txt adresini WAF kuralına dahil etmek: Dosya alınamazsa tarama kısıtları beklenmedik biçimde değişir.
• IP listesini bir kez kopyalayıp unutmak: Aralıkların değişme sıklığı belgede yazmaz; listeyi güncel kaynaktan okuyun.
• Yalnızca Search Console'a bakmak: Raporlar gecikmeli güncellenir; günlük ve doğrulanmış IP kayıtları daha hızlı kanıt verir.
• Tüm botlara aynı kuralı uygulamak: Arama botları, yapay zekâ botları ve izleme araçları farklı amaçlarla gelir.

Kontrol Listesi: Yayın Öncesi ve Sonrası

Yeni bir WAF, CDN ya da bot koruması kuralı devreye almadan önce aşağıdaki kısa listeyi uygulamak, sorunun yayın sonrasında Search Console'da görünmesini beklemekten daha ucuzdur:

1. Kuralın kapsamı yazılı mı: hangi yollar, hangi IP'ler, hangi istek özellikleri?
2. Doğrulanmış Googlebot IP aralıkları için ayrı bir muafiyet tanımlı mı?
3. robots.txt ve sitemap adresleri kuraldan muaf mı ya da ayrı mı korunuyor?
4. Kural önce izleme (yalnızca kaydet) modunda çalıştırıldı mı ve kayıtlar incelendi mi?
5. Hız sınırı eşikleri Googlebot'un geçmiş istek yoğunluğuna göre değerlendirildi mi?
6. Doğrulama sayfası ya da JavaScript sınavı gösterildiğinde yanıt kodu ve gövdenin ne olduğu test edildi mi?
7. Değişiklik sonrası URL denetimi ile birkaç kritik sayfa kontrol edildi mi?
8. Geri alma adımı ve sorumlu kişi belli mi?

Bu liste bir güvenlik denetimi yerine geçmez; amacı SEO açısından erişimin kaybedilmemesini sağlamaktır. Güvenlik kararlarını sitenin risk profiline göre güvenlik sorumlusu verir.

Sıkça Sorulan Sorular

Googlebot gerçek mi sahte mi nasıl anlaşılır?

Kullanıcı aracısı (user agent) metnine tek başına güvenilmez, çünkü başka tarayıcılar onu taklit edebilir. Günlükteki IP için ters DNS sorgusu yapın, dönen alan adının googlebot.com, google.com veya googleusercontent.com olduğunu doğrulayın, ardından bu alan adının ileri DNS sorgusunun aynı IP'yi verdiğini kontrol edin. Çok sayıda kayıt için IP'yi Google'ın yayımladığı JSON aralık dosyalarıyla eşleştirin.

WAF veya CDN Googlebot'u neden engeller?

Bot koruması çoğunlukla istek hızına, IP itibarına, kullanıcı aracısına ve davranış desenlerine bakar. Gerçek Googlebot da kısa sürede çok sayıda sayfa isteyebildiği için bu kurallara takılabilir. Ayrıca sahte Googlebot trafiği yüzünden kurulan sert kurallar, doğrulanmamış biçimde gerçek botu da kapsayabilir. Çözüm kullanıcı aracısına göre toptan izin vermek değil, doğrulanmış botu ayırt edecek bir kural kurmaktır.

403 yanıtı Googlebot'un tarama hızını düşürür mü?

Google'ın belgelerine göre 401 ve 403 gibi 4xx kodları tarama hızını sınırlamak için kullanılmamalıdır; 429 hariç 4xx kodlarının tarama hızına etkisi yoktur. 4xx yanıtı veren URL'lerin içeriği yok sayılır ve dizinde olan URL'ler zamanla dizinden çıkarılır. Yani 403 hız ayarı değil, içerik erişimini kapatma anlamına gelir.

Sunucu aşırı yüklendiğinde Googlebot için hangi yanıt kullanılmalı?

Google, acil durumda kısa süreliğine 500, 503 veya 429 döndürmeyi önerir; süre birkaç saat ile 1-2 gün arasında tutulmalıdır. 503 ve 429 ile Retry-After başlığı eklenebilir. Aynı URL'de bu kodlar birkaç gün sürerse URL dizinden çıkarılabilir, bu yüzden uzun süreli çözüm sunucu kapasitesini veya önbelleği düzeltmektir.

robots.txt dosyası 5xx dönerse ne olur?

Google'ın robots.txt belgesine göre 5xx durumunda siteyi tarama önce 12 saat durdurulur ve dosya yeniden denenir. Yeni kopya alınamazsa son geçerli önbellek kopyası en fazla 30 gün kullanılır. Önbellekte kopya yoksa tarama kısıtı yokmuş gibi davranılır. 30 günden uzun süren hatalarda davranış, sitenin genel erişilebilirliğine göre değişir.

Googlebot için kullanıcı aracısına göre izin listesi yazmak yeterli mi?

Hayır. Kullanıcı aracısı kolayca taklit edilebildiği için izin listesi yalnızca bu alana dayanırsa kötü niyetli botlara kapı açar. Doğrulama yöntemi olarak ters ve ileri DNS veya resmi IP aralıkları kullanılmalı, bot koruması hizmetinin doğrulanmış bot kategorisi varsa o da hesaba katılmalıdır.

Sonuç ve Sonraki Adım

Googlebot erişimi sorunlarında üç ilke öne çıkar. İlki, kullanıcı aracısı yerine ters ve ileri DNS ya da resmi IP aralıklarıyla doğrulama yapmaktır. İkincisi, robots.txt'nin tek engel olmadığını, WAF, CDN ve hız sınırı katmanlarının da erişimi kapatabildiğini bilmektir. Üçüncüsü, 403, 429 ve 503 gibi yanıtların Google tarafında farklı sonuçlar doğurduğunu, bunları bilinçli ve kısa süreli kullanmak gerektiğini hatırlamaktır. Her olayda günlük, IP doğrulaması ve kural kaydı birlikte tutulduğunda tahmine dayalı değil kanıta dayalı çözüm üretirsiniz.

Erişim düzeldikten sonra Google'ın taradığı sayfaların içeriği de sonuç belirler. Taranabilir ve güvenilir içerik için Akua Adforce'ta SEO içerik yazımı hizmetini inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır. Bu yazıdaki öneriler genel teknik rehberdir ve belirli bir sıralama, tarama sıklığı ya da dizinleme sonucu garanti etmez.