Yetkisiz İstek Nedeniyle Engellendi (401)

TL;DR — “Blocked due to unauthorized request (401)”, Googlebot’un sayfanızı okumaya çalıştığı ancak oturum açmasının istendiği anlamına gelir. Google’ın siteniz için bir parolası yoktur; bu nedenle vazgeçer ve sayfa dizine eklenemez. Bu sayfanın Google’da yer almasını istiyorsanız, normalde erişimi kısıtlamaması gereken bir şey sayfayı engelliyordur; bunun nedeni çoğunlukla kaldırılmamış oturum açma koruması, hazırlık sitesinin parolası veya Google’ı yanlışlıkla engelleyen bir güvenlik kuralıdır. Sayfanın özel olması amaçlanıyorsa bu normaldir ve düzeltilmesi gereken bir şey yoktur.

Bu durum ne anlama geliyor?

Bu rapor etiketi, Google’ın URL için HTTP 401 yetkilendirme yanıtı aldığını gösterir. Google, 429 dışındaki kalıcı 4xx yanıtlarını dizine eklenemeyen içerik olarak değerlendirir. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Google Search Console’un Sayfa Dizine Ekleme raporunda “Blocked due to unauthorized request (401)” durumunu gördüğünüzde bunun anlamı şudur: Googlebot URL’yi taramaya çalışmış ve sunucunuz, “kimlik doğrulaması gerekli” kodu olan HTTP 401 ile yanıt vermiştir; yani temelde “bunu görmek için oturum açmanız gerekiyor” demiştir. Evidence for this claim Google's Blocked due to unauthorized request (401) Page indexing reason means the page was blocked to Googlebot by an authorization request returning HTTP 401. Scope: verified Search Console properties Confidence: high · Verified: 2026-07-16 Page indexing report

Googlebot’un siteniz için bir kullanıcı adı ve parolası yoktur ve hiçbir zaman olmayacaktır. Bu nedenle bir sayfa oturum açılmasını istediğinde Googlebot içeri giremez, içeriği okuyamaz ve sayfayı dizine ekleyemez. Sayfa daha önce Google’da yer alıyorken sonradan 401 döndürmeye başladıysa Google zaman içinde sayfayı arama sonuçlarından çıkarır.

Bu bir sorun mu?

Bu, sayfanın Google’da yer almasını isteyip istemediğinize bağlıdır:

• Dizine eklenmesini istiyorsunuz → evet, bu bir sorundur. Herkese açık olması gereken bir sayfanın önüne bir oturum açma engeli konmuştur. Sayfayı neyin kısıtladığını bulup erişime açmanız gerekir.
• Sayfa özel veya hazırlık aşamasında → hayır, amaçlandığı gibi çalışıyordur. 401, özel bir alanı Google’ın dışında tutmanın tamamen geçerli bir yoludur; yalnızca bu satırı rapordan kaldırmak için korumayı zayıflatmamalısınız. Kontrol etmeniz gereken tek şey, bu URL’nin bağlantılarda veya site haritasında yer almasının ya da bu Search Console mülküne gönderilmesinin gerekip gerekmediğidir.

”Ama sayfa bende sorunsuz yükleniyor!”

En yaygın karışıklık budur. URL’yi tarayıcınızda açarsınız ve çalışır; öyleyse Google nasıl engellendiğini söyleyebilir? Çünkü siz oturum açmış durumdasınız (veya ofis IP adresiniz izin listesindedir), Googlebot ise değildir. Siz sayfayı erişim engelini geçtikten sonra görürsünüz; Googlebot doğrudan engele takılır. Google’ın gördüğünü görmek için sayfayı anonim bir ziyaretçi olarak test etmeniz gerekir; Gelişmiş sekmesi bunu nasıl yapacağınızı gösterir.

Genellikle buna ne sebep olur?

• Bir hazırlık veya test sitesinde parola korumasının açık bırakılması.
• Herkese açık olması gereken bir bölümde oturum açma korumasının yanlışlıkla açık bırakılması.
• Bir güvenlik aracının veya CDN’nin (Cloudflare gibi) Googlebot’u yanlışlıkla engellemesi.
• Kısıtlamayı amaçladığınız içerikte gerçek bir oturum açma engeli bulunması (yalnızca üyelere özel vb.).

Gerçek teşhis adımlarını, 401 ile 403 arasındaki farkı ve uygulanacak kesin düzeltmeleri mi istiyorsunuz? Gelişmiş sekmesine geçin.

TL;DR — “Blocked due to unauthorized request (401)”, Googlebot’un aşamadığı bir kimlik doğrulama engeli olan HTTP 401 (Unauthorized) yanıtını aldığı anlamına gelir. Google hiçbir zaman kimlik bilgileri sağlamadığından içeriği göremez: sayfa dizine eklenmez ve daha önce dizine eklenmiş bir URL 401 döndürürse zaman içinde dizinden çıkarılır. RFC 9110’a göre 401 ile 403 arasındaki kesin fark şöyledir: 401, istekte geçerli kimlik bilgilerinin bulunmadığını gösterir (hiç gönderilmemiş veya gönderilenler reddedilmiş olabilir); 403 ise sunucunun isteği anladığını ancak her zaman kimlik bilgileriyle ilgili olmayan nedenlerle reddettiğini gösterir. Google, 429 dışındaki tüm 4xx yanıtlarını dizine ekleme açısından aynı şekilde değerlendirir; dolayısıyla sonuç aynı noktaya varır, ancak neden ve çözüm farklıdır. Çözüm, sayfanın gerçekte ne olduğuna bağlıdır: yanlışlıkla kısıtlanmış herkese açık bir sayfadan kimlik doğrulama şartını kaldırın; bot güvenliği tarafından yanlışlıkla engellenen bir sayfada IP/reverse-DNS yoluyla doğrulanmış Googlebot’a izin verin (kolayca taklit edilebilen user-agent’a asla güvenmeyin); gerçekten özel veya hazırlık aşamasındaki içeriklerde kimlik doğrulamayı koruyun; dizine eklenebilir abonelik içeriğinde genel bir 401 yerine Google’ın ödeme duvarı yapılandırılmış verilerini kullanın. “Tarayıcımda sorunsuz yükleniyor” yanıltıcıdır; siz kimliğinizi doğruladınız, Googlebot doğrulamadı. Taramayı yavaşlatmak için 401/403 kullanmayın. Bot gibi teşhis edin (URL Denetimi Canlı Testi, curl -I); eksik bir WWW-Authenticate üstbilgisi, yanıtın hatalı biçimlendirildiğini gösterir, buna bir WAF’ın neden olduğunu değil. Canlı Test ve Düzeltmeyi Doğrula erişimi doğrular, dizine eklemeyi değil; ayrıca yayımlanmış bir yeniden deneme sıklığı yoktur.

Google gerçekte size ne söylüyor?

Sayfa Dizine Ekleme etiketi, Google’ın gözlemlediği yanıtı bildirir; bu yanıtı hangi kimlik doğrulama, CDN veya uygulama kuralının ürettiğini belirtmez. Altta yatan dizine ekleme davranışı, Google’ın belgelenmiş 4xx yanıtı işleme yönteminden kaynaklanır. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Bu durum doğrudan sunucunun yanıt kodundan gelir. Googlebot URL’yi istemiş ve HTTP 401, yani “Unauthorized” durumunu almıştır; sayfa bir kimlik doğrulama engelinin (HTTP Basic Auth, oturum açma duvarı veya erişim denetimi kuralı) arkasındadır. Google’ın Sayfa Dizine Ekleme raporundaki kendi tanımına göre sayfa, yetkilendirme isteği nedeniyle Googlebot’a engellenmiştir. Dizine eklenmesini istiyorsanız yetkilendirme şartını kaldırmanız veya kimliğini doğrulayarak Googlebot’un geçmesine izin vermeniz gerekir.

Kendi HTTP Status Codes & Their SEO Impact yazımda 401’i, gerektiğinde istemcinin kendisini tanıtmamış veya doğrulamamış olması şeklinde açıklıyorum. Bu yararlı bir zihinsel modeldir, ancak protokolün tam tanımı değildir. RFC 9110’daki kesin kurala göre 401, istekte kaynak için geçerli kimlik doğrulama bilgilerinin bulunmadığı anlamına gelir ve sunucunun reddettiği kimlik bilgileri gönderildikten sonra da döndürülebilir. Dolayısıyla 401 her zaman Googlebot’un (veya bir tarayıcının) hiçbir şey göndermediği anlamına gelmez; yalnızca sunulan bilgilerin geçerli olmadığını belirtir. Her iki durumda da Googlebot açısından pratik sonuç aynıdır: sunabileceği kimlik bilgileri olmadığından engeli hiçbir zaman aşamaz.

Google 401 yanıtıyla ne yapar?

Sayfanın dizine eklenmesini istiyorsanız sonuç iyi değildir. Google’ın HTTP durum belgeleri, 429 dışındaki tüm 4xx hatalarının aynı şekilde ele alındığını açıkça belirtir: tarayıcılar sonraki işleme sistemine içeriğin mevcut olmadığını bildirir. Bu nedenle 401, Google’a fiilen “burada hiçbir şey yok” der. Sonuçları şunlardır:

• Sayfa dizine eklenmez. Google içeriği hiç görmediği için dizine eklenecek bir şey yoktur.
• Daha önce dizine eklenmiş bir sayfa dizinden çıkarılır. Bu yalnızca 401’e özgü değildir; 4xx ailesinin genel davranışıdır. Ahrefs HTTP durum kodları yazısında belirttiğim gibi 4xx yanıtları sayfaların dizinden çıkarılmasına neden olur. Google’ın daha önce dizine eklediği bir sayfa 401 döndürmeye başlarsa tekrarlanan taramalardan sonra URL dizinden düşer.
• Taramayı yavaşlatmaz. Google açıkça 401 ve 403 durum kodlarının tarama hızını sınırlamak için kullanılmaması gerektiğini söyler. 4xx’in (429 dışında) tarama hızına etkisi yoktur; dolayısıyla 401’i “yavaşla” komutu olarak kullanamazsınız. Bunun için 503/429 vardır.

Size vermeyeceğim şeylerden biri belirli bir yeniden deneme sıklığıdır. Google zaman içinde yeniden tarar, ancak belgelerde “Googlebot 401 yanıtını her N günde bir yeniden dener” gibi garantili bir program yayımlanmamıştır. Bu nedenle böyle bir program varmış gibi davranmayacağım. Yeniden taramayı kronometreyle ölçülecek bir süreç olarak değil, “Googlebot eninde sonunda yeniden gelecektir” şeklinde değerlendirin.

401, 403 ve diğer 4xx yanıtları — önemli olan fark

Çoğu yazının bulanıklaştırdığı ayrım budur ve asıl değer de burada yatar. Google, dizine ekleme açısından 401 ve 403’ü aynı şekilde işler (429 dışındaki 4xx kuralı). Ancak kodlar farklı anlamlara geldiği için neden ve çözüm farklıdır:

• RFC 9110 tanımına göre 401 Unauthorized, istekte hedef kaynak için geçerli kimlik doğrulama bilgilerinin bulunmadığı anlamına gelir. Bu iki durumu kapsar: hiçbir kimlik bilgisi gönderilmemiştir veya gönderilen kimlik bilgileri sunucu tarafından reddedilmiştir. Standarda uygun bir 401 yanıtı, en az bir doğrulama sınamasını belirten WWW-Authenticate üstbilgisini içermelidir. Benim kısa tanımım olan “the client hasn’t identified or verified itself when needed”, yaygın durumu anlamak için yararlı bir kısaltmadır; ancak bunu kapsamlı kural olarak değil, zihinsel bir model olarak ele alın.
• Aynı RFC’ye göre 403 Forbidden, sunucunun isteği anladığı ancak yerine getirmeyi reddettiği anlamına gelir. Kimlik bilgileri olası nedenlerden biridir; fakat standart, bir isteğin “might be forbidden for reasons unrelated to the credentials” olduğunu açıkça belirtir. Dolayısıyla 403 her zaman “istemci biliniyor/kimliği doğrulanmış ancak erişim hakkı yok” anlamına gelmez; bu yaygın bir gerçek dünya örüntüsüdür, garanti değildir. Özellikle Google’ın Sayfa Dizine Ekleme raporunda Googlebot’a (hiçbir zaman kimlik bilgisi göndermez) verilen 403, genellikle sunucunun bu hatayı yanlışlıkla döndürdüğü anlamına gelir; çoğu zaman yanlış yapılandırılmış bir güvenlik duvarı, WAF veya bot kuralı söz konusudur. (Bu durum için Blocked due to access forbidden (403) adlı kardeş bir durum vardır; teşhis akışları büyük ölçüde örtüşür.)

Pratik zihinsel kısayol, ön inceleme için hâlâ geçerlidir: 401 ≈ “kaldırmayı unuttuğum bir kimlik doğrulama engeli” (hazırlık sitesi, kaldırılmamış HTTP auth); 403 ≈ “Googlebot’u yanlışlıkla engelleyen bir güvenlik kuralı.” Dizine ekleme sonucu aynı, temel neden farklıdır. Ancak bu kısaltmalardan hiçbirini protokolün gerçek sınırı olarak değerlendirmeyin. Karar tablosu Kopya Kağıtları sekmesindedir.

Bunu neden görüyorsunuz? Yaygın nedenler

Gerçekten dizine eklenmesini istediğiniz bir sayfadaki 401’in nedeni neredeyse her zaman şunlardan biridir:

• Basic Auth arkasındaki bir hazırlık veya geliştirme sitesi. Hazırlık ortamını parolayla korudunuz (doğru bir yaklaşım), ancak Google URL’yi bir şekilde keşfetti; dahili bağlantı, site haritası veya sızmış bir referans buna yol açmış olabilir. Google artık 401’i bildiriyordur. Hazırlık URL’sinin gerçekten herkese açık olmaması gerekiyorsa bu beklenen bir durumdur (kasıtlı 401 bölümüne bakın).
• Herkese açık bir bölümde yanlışlıkla etkinleştirilmiş HTTP auth. Yayında olması gereken bir dizinde açık bırakılmış .htpasswd kuralı, “coming soon” eklentisi veya bakım modu engeli.
• Googlebot’u engelleyen bir WAF / CDN / IP izin listesi. Sinsi olan budur. Cloudflare, Akamai, Sucuri veya coğrafi/IP tabanlı bir izin listesi insanlara normal sayfa sunarken Googlebot’un IP’lerine 401 (veya 403) döndürür. Sayfa “herkes için çalışır” çünkü test eden herkes izin verilen bir IP’den bağlanıyordur.
• Dizine eklenmesini istediğiniz abonelik veya ödeme duvarlı içerikte oturum açma engeli. Genel bir 401, Googlebot’u tamamen dışarıda tutar. Çözüm engeli zayıflatmak değil, Google’ın desteklediği ödeme duvarı yapılandırılmış verilerini kullanmaktır (aşağıdaki dördüncü dala bakın).

Nasıl teşhis edilir? Tarayıcı gibi değil, bot gibi test edin

Buradaki en büyük tuzak “bende çalışıyor” düşüncesidir. Elbette çalışır; kimliğinizi doğrulamış, IP adresinizi izin listesine eklemiş olabilirsiniz veya tarayıcınızda bir oturum çerezi bulunabilir. Googlebot’ta bunların hiçbiri yoktur. Bu nedenle bot gibi teşhis edin:

• URL Denetimi → Canlı Test (GSC). Googlebot’un aldığı gerçek yanıtı görmeye en çok yaklaştığınız test budur. Etkilenen URL üzerinde çalıştırın. Yetkilendirme nedeniyle getirilemiyorsa 401’in gerçek ve yeniden üretilebilir olduğunu doğrulamış olursunuz.

• Kimlik doğrulanmamış bir ortamdan curl -I. URL’yi çerez veya kimlik bilgisi göndermeden isteyin ve durum satırını okuyun:

  curl -I https://www.example.com/page/
  # Look for:  HTTP/1.1 401 Unauthorized
  # and a WWW-Authenticate: header confirming an auth gate

  curl (oturum veya kimlik doğrulama bilgisi göndermez) 401 alırken tarayıcınız 200 alıyorsa sorun tam olarak bu farktır: tarayıcınızda kimliğiniz doğrulanmıştır, Googlebot’ta doğrulanmamıştır. RFC 9110, standarda uygun bir 401’in WWW-Authenticate üstbilgisi taşımasını şart koşar; bu üstbilginin varlığı gerçek bir kimlik doğrulama sınamasını doğrular. Ancak yokluğu doğrudan nedeni göstermez: yalnızca yanıtın hatalı veya eksik olduğunu belirtir, yanıtı hangi katmanın ürettiğini değil. Yalnızca eksik üstbilgiye dayanarak “bunun nedeni WAF olmalı” sonucuna atlamayın.

• Kısıtlamanın IP’ye bağlı olup olmadığını kontrol edin. Kendi makinenizdeki curl 200 döndürürken GSC Canlı Testi başarısız oluyorsa bu, bir şeyin kaynak IP veya istek yönlendirmesine bağlı olduğuna dair gerçek bir işarettir. Ancak nedeni WAF olarak adlandırmadan önce uç/CDN, kaynak ve uygulama günlükleriyle tüm kimlik sağlayıcılarını karşılaştırarak doğrulayın. HEAD isteği (curl -I bunu gönderir), GET isteğinden farklı yönlendirilebilir veya önbelleğe alınabilir; bu nedenle anonim bir GET ile de kontrol edin.

Nasıl düzeltilir? Sayfanın gerçekte ne olduğuna göre dört dal

Tek bir çözüm yoktur; dört çözüm vardır. Yanlış olanı seçmek, korumak istediğiniz içeriği açığa çıkarabilir veya dizine eklenebilir bir sayfayı kalıcı olarak kısıtlayabilir. Herhangi bir yapılandırmaya dokunmadan önce URL’yi şu gruplardan birine yerleştirin:

1. Gerçekten özel veya hazırlık aşamasındaki içerik → kimlik doğrulamayı koruyun, dokunmayın. URL gerçekten herkese açık olmamalıysa 401 tasarlandığı gibi çalışıyordur. Sunucu tarafı kimlik doğrulaması, içeriği Googlebot dâhil herkesten uzak tutmanın geçerli ve Google tarafından önerilen bir yoludur. John Mueller, hazırlık siteleri için bunu açıkça belirtmiştir: bir siteyi gizlemenin doğru yolu IP, çerez veya normal sunucu kimlik doğrulaması kullanarak sunucu tarafında erişimi kısıtlamak ve böylece Googlebot dâhil normal kullanıcıların içeriği görmesini engellemektir. Yalnızca bu rapor satırını temizlemek için gerçekten özel içeriği koruyan bir engelden Googlebot’u geçirmeyin; bu, engelin amacını ortadan kaldırır. Buradaki çözüm erişimi değiştirmek değil, keşif temizliğidir: URL’nin bağlantılarda veya site haritasında bulunmadığını ve bu Search Console mülküne gönderilmediğini doğrulayın; kimlik doğrulamayı yerinde bırakın.

2. Yanlışlıkla kısıtlanmış herkese açık bir sayfa → yetkilendirme şartını kaldırın. Sayfanın dizine eklenmesi gerekiyorsa ve engel Basic Auth, oturum açma duvarı veya bakım modu eklentisi gibi bir kalıntıysa ilgili yol için bunu kapatın. Bu basit durumdur: anonim istek 200 almaya başladığında sayfa Googlebot’a açılmış olur.

3. Bot güvenliği tarafından yanlışlıkla engellenmiş herkese açık bir sayfa → düz user-agent dizesine değil, doğrulanmış Googlebot’a izin verin. Bir WAF, CDN veya IP izin listesi gerçekten herkese açık olmasını istediğiniz bir sayfada Googlebot’u reddediyorsa IP / reverse-DNS yoluyla doğrulanmış Googlebot’u izin listesine ekleyin. User-agent kolayca taklit edilebilir; herkes Googlebot olduğunu iddia edebilir. Google’ın önerdiği yöntem, yayımlanmış IP aralıklarıyla veya ters ve ardından ileri DNS denetimiyle tarayıcıyı doğrulamak ve yalnızca bu belirli isteklerin engeli geçmesine izin vermektir. Güvenlik kuralını kaldırmaz, ona doğrulanmış bir istisna eklersiniz. Yanlış pozitif sonucu düzeltmek için:

• Googlebot’a 401/403 döndüren kuralı belirleyin (Cloudflare Firewall Events, Akamai/Sucuri günlükleri veya kendi uç/kaynak/uygulama günlükleriniz).
• Korumayı tamamen devre dışı bırakmak yerine Google’ın doğrulanmış IP aralıklarını (veya bot kategorisini) izin listesine ekleyin.
• Google sayfayı getirebilene kadar URL Denetimi Canlı Testiyle yeniden test edin.

4. Dizine eklenmesini istediğiniz abonelik veya ödeme duvarlı içerik → genel bir 401 kullanmayın. Sayfa kayıt veya abonelik gerektiriyor ancak Arama’da keşfedilmesini istiyorsanız, nedeni ne olursa olsun katı bir 401 yanlış araçtır; Googlebot yine sayfayı getiremez. Google bunun yerine desteklenen bir ödeme duvarı uygulaması belgeler: sayfayı, uygun ödeme duvarlı içerik yapılandırılmış verileriyle (isAccessibleForFree, hasPart ve ilgili özellikler) sunun. Böylece tüm sayfayı açmanız gerekmeden Google ücretsiz önizleme bölümünü dizine ekleyebilir. Bu, kimlik doğrulama engelinde değil işaretlemede ve sunucu yanıtında yapılan bir değişikliktir.

Düzeltmeyi doğrulayın ve beklentileri belirleyin

Sayfayı gerçekten açtıktan ve kimliği doğrulanmamış bir isteğin artık 200 döndürdüğünü curl/Canlı Test ile doğruladıktan sonra her adımın gerçekte neyi doğruladığı konusunda kesin olun:

• Canlı Test erişimi doğrular, dizine eklemeyi değil. Google’ın URL Denetimi belgelerine göre canlı test yalnızca Google-InspectionTool’un sayfaya o anda erişip sayfayı ayrıştırabildiğini doğrular. Sayfanın dizine gireceğini veya Arama sonuçlarında görüneceğini garanti eden bir test yoktur. Başarılı Canlı Test, engelin açık olduğunu gösterir; sonrasında ne olacağına dair söz vermez.
• Düzeltmeyi Doğrula isteğe bağlıdır, zorunlu değildir. Düzeltmeyi Doğrula’ya tıklamış olsanız da olmasanız da Google bir sayfayı yeniden taradığında sorun sayısını günceller. Gerçek bir düzeltmeyi takip etmek için kullanın; özel kalması gereken bir URL’yi doğrulamayın ve doğrulamanın yeniden dizine eklemeyi hızlandırdığını varsaymayın.
• Anında yeniden dizine ekleme beklemeyin. Yeniden tarama ve dizine ekleme zaman alır; yukarıda belirtildiği gibi alıntılayabileceğim yayımlanmış bir yeniden deneme sıklığı yoktur. Gerçek dizin durumunu ve arama performansını rapor durumundan ayrı izleyin. Ne Canlı Test ne de Düzeltmeyi Doğrula, kanonik seçimi veya arama sonuçlarında görünmeyi garanti eder.
• Son olarak şu efsaneyi bırakın: GSC’deki 401 bir ceza veya manuel işlem değildir. Bu bir tarama erişimi durumudur. Diğer sayfalarınızın sıralamalarını etkilemez ve sitenizi “kara listeye” almaz; yalnızca kısıtlanan sayfayı dizinin dışında tutar.

Bu durum sistemde nerede yer alır?

Bu, Sayfa Dizine Ekleme raporundaki HTTP durumlarından biridir. Kardeş durumlar arasında Blocked due to access forbidden (403), diğer 4xx ve 404 durumları ile 5xx sunucu hatası durumu bulunur. Raporun kendisi ve “Sayfalar neden dizine eklenmiyor?” tablosunun nasıl okunacağı için Sayfa Dizine Ekleme raporu merkezine bakın. Googlebot’un nasıl getirme yaptığı ve durum kodlarının onun için ne anlama geldiği gibi temel mekanikler tarama ve dizine ekleme konularında ele alınır.

AI özeti

Gelişmiş sürümün kısa özeti:

• Nedir? Googlebot’un aşamadığı bir kimlik doğrulama engeli olan HTTP 401 (Unauthorized) yanıtını aldığını belirten GSC Sayfa Dizine Ekleme durumudur. Google kimlik bilgisi sağlamaz; bu nedenle içeriği hiçbir zaman göremez.
• Google ne yapar? Sayfa dizine eklenmez; daha önce dizine eklenmiş ve 401 döndüren bir URL zaman içinde dizinden çıkarılır. 429 dışındaki tüm 4xx yanıtları aynı şekilde ele alınır: Google’a “içerik mevcut değil” denir. 4xx’in tarama hızına etkisi yoktur; Googlebot’u yavaşlatmak için 401/403 kullanmayın.
• 401 ve 403 arasındaki kesin fark. RFC 9110’a göre 401, istekte geçerli kimlik bilgilerinin bulunmadığını (hiç gönderilmemiş veya gönderilenlerin reddedilmiş olabileceğini); 403 ise sunucunun isteği anladığını ancak her zaman kimlik bilgileriyle ilgili olmayan nedenlerle reddettiğini gösterir. “401 = kimlik doğrulama engeli, 403 = Googlebot’u yanlışlıkla engelleyen güvenlik kuralı” yararlı bir ön inceleme kısayoludur, protokolün kapsamlı kuralı değildir.
• Yaygın nedenler (dizine eklenmesini istediğiniz sayfalarda): Basic Auth arkasındaki hazırlık sitesi, herkese açık bir bölümde yanlışlıkla etkinleştirilmiş HTTP auth, Googlebot’u hariç tutan WAF/CDN/IP izin listesi veya abonelik/ödeme duvarlı içerikte oturum açma engeli.
• “Bende yükleniyor” bir tuzaktır. Kimliğiniz doğrulanmıştır veya IP’niz izin listesindedir; Googlebot için bunlar geçerli değildir. Bot gibi teşhis edin: URL Denetimi Canlı Testi ve curl -I (çerez ve kimlik doğrulama olmadan). Burada alınan 401 durumu doğrular. WWW-Authenticate üstbilgisi gerçek bir kimlik doğrulama engelini doğrular (RFC 9110, standarda uygun 401’de bunu şart koşar); yokluğu yalnızca yanıtın hatalı olduğunu gösterir. WAF’ı suçlamadan önce uç, kaynak, uygulama ve kimlik sağlayıcısı günlüklerini kontrol edin.
• Tek bir evrensel çözüm yerine sayfanın ne olduğuna göre düzeltin. Yanlışlıkla kısıtlanmış herkese açık sayfa → yetkilendirme şartını kaldırın. Bot güvenliği tarafından yanlışlıkla engellenen herkese açık sayfa → kuralı tamamen kapatmadan, IP/reverse-DNS yoluyla doğrulanmış Googlebot’u izin listesine ekleyin (taklit edilebilir user-agent dizesini asla kullanmayın). Gerçekten özel/hazırlık içeriği → kimlik doğrulamayı koruyun; yalnızca rapor satırını temizlemek için açmayın, sadece keşif kaynaklarını (site haritaları/bağlantılar/mülk) temizleyin. Dizine eklenebilir abonelik/ödeme duvarlı içerik → genel 401 yerine Google’ın ödeme duvarı yapılandırılmış verilerini kullanın.
• Doğrulayın ve abartılı vaatlerde bulunmadan bekleyin. Canlı Test yalnızca mevcut erişimi doğrular, dizine eklemeyi değil. Düzeltmeyi Doğrula isteğe bağlıdır; Google sonraki taramada sayıyı her hâlükârda günceller. Yeniden dizine ekleme zaman alır, yayımlanmış bir yeniden deneme sıklığı yoktur ve iki adım da dizine eklemeyi, kanonik seçimi veya arama sonuçlarında görünmeyi garanti etmez. 401 bir ceza değildir.

Resmî belgeler

Arama motorlarının birincil kaynak belgeleri.

Google

• Sayfa Dizine Ekleme raporu — raporun kendisi ve “Blocked due to unauthorized request (401)” durumunun tanımı (403 kardeş durumu ve diğer HTTP durumlarıyla birlikte).
• HTTP durum kodları ile ağ ve DNS hatalarının Google Arama’yı nasıl etkilediği — Googlebot’un 401 yanıtıyla ne yaptığı: 429 dışındaki 4xx yanıtlarının işlenmesi ve “tarama hızını sınırlamak için 401/403 kullanmayın” kuralı.
• Googlebot’u ve diğer Google tarayıcılarını doğrulama — Googlebot’u izin listesine eklemenin önerilen yolu: user-agent dizesiyle değil, IP / reverse-DNS ile doğrulama.
• Googlebot IP aralıkları (googlebot.json) — WAF/CDN engelinden geçirilmek üzere izin listesine eklenecek yayımlanmış IP aralıkları.

Bing / Microsoft

• Bing Webmaster Tools Help — Bing aynı durum metnini göstermese de 401/403 döndüren bir URL erişilemez kabul edilir ve dizine eklenmez. bingbot’un da sayfaya anonim olarak ulaşması gerekir; aynı izin listesi çözümü için doğrulanmış IP aralıkları / reverse-DNS doğrulaması yayımlanır.

Kaynaktan alıntılar

Kamuya açık kayıtlardaki açıklamalar. Her bağlantı, kaynak sayfadaki alıntılanan bölüme doğrudan gider.

Google — 401 durumunun anlamı (Sayfa Dizine Ekleme raporu)

• “The page was blocked to Googlebot by a request for authorization (401 response). If you do want Googlebot to be able to index this page, either remove authorization requirements for this page, or else allow Googlebot to access your pages by verifying its identity.” — Google Search Console Yardım, Page Indexing report. Alıntıya git

Google — Googlebot’un 401 yanıtıyla ne yaptığı (HTTP durum kodları belgesi)

• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” — Google Search Central belgeleri. Alıntıya git
• “Don’t use 401 and 403 status codes for limiting the crawl rate.” Alıntıya git

Patrick Stox — kendi 401/403 tanımlarım ve 4xx’in dizine etkisi

• “The client hasn’t identified or verified itself when needed.” (401) — Patrick Stox, HTTP Status Codes & Their SEO Impact, Ahrefs. Alıntıya git
• “The client is known but doesn’t have access rights.” (403) Alıntıya git
• “4xxs will cause pages to drop from the index.” Alıntıya git

John Mueller, Google — sunucu tarafı kimlik doğrulaması bir siteyi kısıtlamanın doğru yoludur

• “Ideally, what you would want to do is provide some kind of server side authentication on the server so that normal users when they go there they would get blocked from being able to see the content; that would include GoogleBot.” (Webmaster Hangout, 25 Eylül 2019; Search Engine Journal tarafından aktarılmıştır.) Haberi okuyun

401 teşhis ve düzeltme kontrol listesi

GSC “Blocked due to unauthorized request (401)” uyarısı verdiğinde bu listeyi uygulayın:

• Önce amacı belirleyin — bu URL’nin dizine eklenmesini gerçekten istiyor musunuz? URL gerçekten özel veya hazırlık ortamına aitse 401 doğrudur; son maddeye geçin. Dizine eklenmesini istediğiniz abonelik ya da ödeme duvarlı içerikse kimlik doğrulamayı kaldırma adımlarını atlayıp ödeme duvarı yapılandırılmış veri çözümünü kullanın.
• Bot olarak yeniden üretin — URL için URL Denetimi → Canlı Test çalıştırın ve yetkilendirme hatasını doğrulayın (oturum açtığınız tarayıcıya güvenmeyin).
• Çerez veya kimlik bilgisi olmadan curl -I çalıştırın — 401 döndüğünü doğrulayın ve WWW-Authenticate üstbilgisini arayın. Tarayıcınız 200 alırken bu isteğin 401 alması sorunun kendisidir. Üstbilgi gerçek bir kimlik doğrulama kapısını doğrular; olmaması ise yanıtı üreten katmanı değil, hatalı biçimlendirilmiş bir yanıtı gösterir.
• Engelin kaynağını belirleyin — olası nedeni daraltmak için uç/CDN, kaynak sunucu, uygulama ve kimlik sistemi günlüklerini inceleyin: Basic Auth (.htpasswd), bakım/ “coming soon” eklentisi, oturum açma duvarı veya WAF/CDN/IP izin listesi kuralı.
• Neden WAF/CDN ise — Google’ı engelleyen kuralı güvenlik duvarı olaylarından bulun; korumayı bütünüyle devre dışı bırakmak yerine doğrulanmış Googlebot IP aralıklarını izin listesine ekleyin.
• Uygun yöntemle düzeltin — yanlışlıkla kısıtlanmış herkese açık sayfadaki kimlik doğrulama zorunluluğunu kaldırın veya bot güvenliğinin yanlış pozitif verdiği durumda doğrulanmış Googlebot’a IP / reverse-DNS üzerinden izin verin (taklit edilebilen user-agent dizesini asla ölçüt almayın). Gerçekten özel içeriği koruyan bir kapıda Googlebot için izin listesi istisnası oluşturmayın.
• Yeniden test edin — curl -I (yine kimlik doğrulaması olmadan) artık 200 döndürmeli ve URL Denetimi Canlı Testi sayfayı getirebilmelidir.
• Sayfa Dizine Ekleme raporunda Düzeltmeyi Doğrula (isteğe bağlı) seçeneğini kullanın ve örnek bir URL’yi yeniden denetleyin — Google sayıyı her iki durumda da sonraki taramasında günceller; başarılı Canlı Test erişimi doğrular, dizine eklemeyi değil.
• Beklentileri doğru belirleyin — yeniden tarama ve dizine ekleme zaman alır; garantili bir yeniden deneme sıklığı olmadığı gibi dizine eklenme veya arama sonuçlarında görünme garantisi de yoktur. Bu bir ceza değildir.
• Engel kasıtlıysa — hazırlık/özel URL’sinin bu mülkte yer almaması gerektiğini doğrulayın (URL’ye bağlantı vermeyi ve URL’yi göndermeyi bırakın) ve engeli koruyun.

401, 403 ve diğer 4xx yanıtları — kopya kağıdı

Her kodun gerçek anlamı (ve tipik nedeni)

Google bunları dizine ekleme açısından nasıl değerlendirir?

Çözüm haritası

Yanlışlıkla kısıtlanan herkese açık bir sayfa için iki resmî çözüm (Google’ın ifadesiyle)

1. Sayfanın yetkilendirme şartını kaldırın.
2. Kimliğini doğrulayarak Googlebot’un geçmesine izin verin; (taklit edilebilir) user-agent dizesiyle değil, IP / reverse-DNS ile izin listesine ekleyin.

Bunların hiçbiri gerçekten özel/hazırlık içeriği (engeli koruyun) veya dizine eklenebilir ödeme duvarlı içerik (engeli açmak yerine ödeme duvarı işaretlemesini kullanın) için geçerli değildir.

Zihinsel modeller

1. Engel ve içerik. 401 bir içerik sorunu değildir; Googlebot içeriğe hiç ulaşmamıştır. Bu bir engel sorunudur. Dolayısıyla sayfayı düzenlemezsiniz; engelin kimliği doğrulanmamış bir bota nasıl davrandığını değiştirirsiniz. “Sayfa iyi mi?” ile “Googlebot kapıdan geçebiliyor mu?” sorularını her zaman birbirinden ayırın.

2. Her şeyi amaç belirler. Herhangi bir düzeltmeden önce tek bir soruyu yanıtlayın: Bu URL dizine eklenmeli mi? Evetse 401, kaldırılması gereken yanlış bir yapılandırmadır. Hayırsa 401 tasarlandığı gibi çalışıyordur ve asıl soru bu URL’nin neden bu Search Console mülkünde bulunduğudur. Görevini yapan bir 401’i düzeltmeyin.

3. Kendiniz gibi değil, bot gibi test edin. “Bende çalışıyor” düşüncesi buradaki varsayılan değerlendirme hatasıdır. Sizde oturum, çerez veya izin listesine alınmış IP bulunur; Googlebot bunların hiçbirine sahip değildir. Her teşhis bunları ortadan kaldırarak başlar: kimlik bilgisi olmadan curl -I veya URL Denetimi Canlı Testi.

4. 401 ve 403 — aynı sonuç, farklı kapı. Dizine ekleme açısından aynıdırlar (429 dışındaki 4xx). RFC’ye göre 401, istekte geçerli kimlik bilgilerinin bulunmadığını (hiç gönderilmemiş veya gönderilenlerin reddedilmiş olabileceğini); 403 ise sunucunun isteği anladığını ancak kimlik bilgileriyle ilgili olabilecek veya olmayabilecek nedenlerle reddettiğini gösterir. “401 = denetimimdeki kimlik doğrulama engeli, 403 = hatalı çalışan güvenlik kuralı” ifadesini protokolün gerçek sınırı olarak değil, pratik bir ön inceleme kısayolu olarak kullanın. Yararlı olacak kadar sık doğrudur; ancak gerçekte doğru olan RFC’nin ifadesidir. Teşhisi kapıya yöneltin: 401 → auth/hazırlık ortamına bakın; 403 → WAF/güvenlik duvarına bakın.

5. Ada güvenmeyin, botu doğrulayın. İnsanların daha sonra başını ağrıtan çözüm “Googlebot user-agent’ını izin listesine eklemek”tir. Bu dizeyi herkes kullanabilir. Kalıcı çözüm, IP / reverse-DNS yoluyla kimlik doğrulamaktır: yalnızca Googlebot olduğunu söyleyen bota değil, Googlebot olduğunu kanıtlayabildiğiniz bota izin verin.

401’i teşhis etme: kasıtlı engel mi, yanlış yapılandırma mı?

İlk ayrım teknoloji değil amaçtır: herhangi bir yapılandırmaya dokunmadan önce URL’nin dizine eklenmesi gerekip gerekmediğine karar verin. Bunun gerçek bir yanlış yapılandırma olduğunu öğrendikten sonraki ayrım, kaldırmayı unuttuğunuz bir oturum açma duvarıyla mı yoksa Googlebot’u yanlışlıkla engelleyen bir WAF/CDN kuralıyla mı karşı karşıya olduğunuzdur. Adımları izleyin.

Yalnızca varlığını değil, 401 grubunu izleyin

İzlemeye değer sayı, Sayfa Dizine Ekleme raporundaki “Blocked due to unauthorized request (401)” satırında zaman içinde kaç URL bulunduğudur; yalnızca satırın var olup olmadığı değil. Tek bir anlık görüntü, sorunu çözüp çözmediğinizi veya daha fazla kısıtlanmış URL biriktirip biriktirmediğinizi gösteremez.

Zaman içinde 401 grubu sayısı

• Metrik — GSC Sayfa Dizine Ekleme raporunda “Blocked due to unauthorized request (401)” altında bulunan URL sayısının haftadan haftaya izlenmesi.
• Size ne söyler — Bir düzeltmenin gerçekten işe yarayıp yaramadığını ve yeni 401’lerin ortaya çıkıp çıkmadığını gösterir. Kimlik doğrulama şartını kaldırdıktan veya doğrulanmış Googlebot’u izin listesine ekledikten sonra bu sayı, düzelttiğiniz URL’ler için sıfıra doğru düşmelidir. Kasıtlı olarak kısıtlanan URL’lerde (hazırlık, özel bölümler) sayı sabit kalmalıdır. Buradaki artış genellikle yeni hazırlık/özel URL’lerinin yanlışlıkla bağlantılara veya bu mülkün site haritasına eklendiğini gösterir.
• Nasıl alınır — GSC Sayfa Dizine Ekleme raporunu 401 satırına göre filtreleyin; eski bir anlık görüntü olmadığını doğrulamak için tek tek URL’leri URL Denetimi → Canlı Test ile örnekleyerek kontrol edin.
• Karşılaştırma ölçütü / gerçekçi aralık — Evrensel bir hedef yoktur; tamamen kasıtlı olarak kaç sayfayı kısıtladığınıza bağlıdır. Dürüst ölçüt şudur: dizine eklenmesini istediğiniz URL’ler arasında sıfır 401 ve bilerek kimlik doğrulama arkasında tuttuğunuz URL’ler için sabit (artmayan) sayı. Eğilim yönünü değerlendirmeden önce kendi başlangıç sayınızı belirleyin.
• Sıklık — Düzeltmeden hemen sonra sayı istikrar kazanana kadar haftalık; sonrasında gerileme kontrolü için aylık.

İşletim kılavuzu: teşhis edin, düzeltin, doğrulayın

401 iş akışı kısa ve sıralı bir döngüdür. Amacı doğrulamadan ve engeli bot olarak yeniden üretmeden doğrudan “düzeltme” adımına atlamayın.

1. Önce amacı belirleyin. Bu URL gerçekten dizine eklenmeli mi? Gerçekten özel veya hazırlık aşamasındaysa burada durun: 401 doğrudur. Tek takip işlemi, URL’nin bu mülkte bağlantılara veya site haritasına eklenmediğinden emin olmaktır; engeli zayıflatmayın. Dizine eklenmesini istediğiniz abonelik/ödeme duvarlı içerikse kimlik doğrulama engeline dokunmak yerine ödeme duvarı yapılandırılmış veri çözümüne geçin.

2. Kendiniz gibi değil, bot gibi yeniden üretin. GSC’de URL Denetimi → Canlı Test çalıştırın ve ayrıca URL’yi çerez veya kimlik bilgisi kullanmadan curl -I ile isteyin. Oturum açtığınız tarayıcı 200 alırken curl 401 alıyorsa sorun tam olarak bu farktır: kimliğiniz doğrulanmıştır veya IP’niz izin listesindedir; Googlebot için bunlar geçerli değildir.

3. Engeli belirleyin. Anonim yanıtın WWW-Authenticate üstbilgisi taşıyıp taşımadığını kontrol edin. Standarda uygun bir 401 bunu içermelidir; dolayısıyla varlığı gerçek bir kimlik doğrulama engelini (Basic Auth, oturum açma duvarı, bakım modu) doğrular. Yokluğu nedeni doğrudan göstermez; yanıtın hatalı biçimlendirildiğini belirtir. Bunun bir WAF/CDN/izin listesi kuralı olduğu sonucuna varmadan önce uç/CDN, kaynak, uygulama ve kimlik sağlayıcısı günlüklerini karşılaştırın.

4. Nedene uygun çözümü uygulayın. Yanlışlıkla herkese açık hâle gelmiş bir sayfanın önünde kimlik doğrulama kapısı varsa → o yol üzerindeki yetkilendirme zorunluluğunu kaldırın. Bir WAF/CDN kuralı herkese açık sayfayı yanlışlıkla engelliyorsa → güvenlik duvarında doğrulanmış Googlebot’u IP veya reverse-DNS temelinde izin listesine alın; yalnızca taklit edilebilen user-agent dizesine asla dayanmayın. Gerçekten özel içeriği koruyan bir kapıdan Googlebot’un geçmesine hiçbir zaman izin vermeyin.

5. Doğrulayın. Aynı anonim curl -I isteğini yeniden çalıştırın ve artık 200 döndürdüğünü doğrulayın. Sayfa Dizine Ekleme raporundaki Düzeltmeyi Doğrula isteğe bağlı bir izleme aracıdır; Google sonraki taramada sorun sayısını her hâlükârda günceller. URL Denetimi Canlı Testi ise yalnızca Google-InspectionTool’un sayfaya o anda erişebildiğini doğrular, dizine ekleneceğini değil.

6. Beklentileri belirleyin ve durun. Yeniden tarama ve dizine ekleme zaman alır; yayımlanmış bir yeniden deneme sıklığı yoktur. Ne Canlı Test ne de Düzeltmeyi Doğrula, dizine eklemeyi veya arama sonuçlarında görünmeyi garanti eder. Beklerken aynı URL’yi iki kez “düzeltmeyin”. GSC’deki 401 grubu sayısı birkaç hafta sonra düşüş eğilimi göstermiyorsa yeni bir neden tahmin etmek yerine 2. adıma dönüp sorunu yeniden üretin.

Kullanıma hazır AI istemleri

Ham teşhis çıktısından 401’i sınıflandırmak için kopyalayıp yapıştırabileceğiniz istemler. Bunlar muhtemel nedeni hızla ön incelemenize yardımcı olur; herhangi bir değişiklik yapmadan önce sonucu her zaman gerçek sunucu/güvenlik duvarı yapılandırmasıyla doğrulayın.

curl çıktısından muhtemel nedeni sınıflandırın

I'm diagnosing a "Blocked due to unauthorized request (401)" status in Google
Search Console. Below is the raw output of an unauthenticated request to the
URL (curl -I, no cookies, no credentials). Based on this output alone,
classify the most likely cause as one of: (1) staging/dev site behind Basic
Auth, (2) accidental HTTP auth or maintenance-mode gate left on a public
section, (3) WAF/CDN/IP-allowlist blocking Googlebot, (4) a login wall on
content that's meant to be gated. Explain which specific header or detail in
the output pointed you to that answer, and tell me what's missing if you
can't tell for sure.

CURL OUTPUT:
[paste]

Bir WAF/güvenlik duvarı günlük satırından nedeni sınıflandırın

I'm investigating why Googlebot is getting a 401 or 403 on a page I want
indexed. Below is a log line (or a few) from my WAF/CDN showing a blocked
request. Tell me whether this looks like a bot-identity rule (blocking by
user-agent or IP range), a rate-limit/challenge rule, or something else, and
what I'd need to allowlist — by IP range or reverse-DNS — to let verified
Googlebot through without disabling the rule entirely.

LOG LINE(S):
[paste]

Yayımlamadan önce bir düzeltmenin doğruluğunu kontrol edin

I'm about to remove an authorization requirement from a URL that's currently
returning 401 to Googlebot, because I want it indexed. Here's a short
description of the current gate and what I'm about to change: [describe].
Point out anything I might be missing — e.g. whether this could accidentally
expose a section I meant to keep private, or whether I should allowlist
verified Googlebot instead of removing the auth requirement outright.

Kendinizi test edin: “Blocked due to unauthorized request (401)”

401’in ne anlama geldiği, 403’ten nasıl farklı olduğu ve nasıl teşhis edilip düzeltileceği hakkında beş soru. Her biri için bir yanıt seçin, ardından kontrol edin.

401’i anonim bir istek olarak yeniden üretin

Bu kontrollerin amacı, Gelişmiş sekmesindeki temel noktayla aynıdır: tarayıcınızda kimliğiniz doğrulanmıştır, Googlebot’ta doğrulanmamıştır. Çerezleri ve kimlik bilgilerini tamamen kaldırıp anonim bir istemcinin gerçekte ne aldığını görün.

macOS / Linux

# Fetch headers only, with no cookies and no credentials
curl -sI https://www.example.com/page/
# Look for:
#   HTTP/1.1 401 Unauthorized
#   WWW-Authenticate: Basic realm="..."   <- confirms a real auth gate

Windows (PowerShell)

# -SkipHttpErrorCheck so PowerShell shows the 401 instead of throwing
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
  -SkipHttpErrorCheck | Select-Object StatusCode, Headers
# Check the Headers output for WWW-Authenticate

Bu işlem WWW-Authenticate üstbilgisiyle birlikte 401 döndürürse gerçek bir kimlik doğrulama engelini (Basic Auth, oturum açma duvarı) doğrulamış olursunuz; RFC 9110, standarda uygun 401’in bu üstbilgiyi göndermesini şart koşar. WWW-Authenticate üstbilgisi olmadan 401/403 döndürürse bu, yanıtın hatalı veya eksik olduğunu gösterir; yanıtı hangi katmanın ürettiğini değil. Üstbilginin yokluğu tek başına WAF veya CDN’yi kanıtlamaz. Engel yalnızca kendi ağınızın dışından bağlanıldığında ortaya çıkıyorsa IP kapsamı, WAF/CDN/IP izin listesi kuralına işaret eden daha güçlü bulgudur. Güvenlik duvarı/CDN günlüklerinde doğrulayın, farklı bir ağdan yeniden test edin veya doğrudan Googlebot olarak istek gönderen GSC URL Denetimi Canlı Testini kullanın.

İzin listesine eklemeden önce botun gerçekten Googlebot olduğunu doğrulayın

Bir “Googlebot” isteğinin geçmesi için WAF kuralını açmadan önce IP’nin gerçekten Google’a ait olduğunu doğrulayın; çok sayıda trafik user-agent dizesini taklit eder.

macOS / Linux

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Ters sorgu bir Google alan adıyla bitmiyorsa veya ileri sorgu özgün IP’yle eşleşmiyorsa izin listesine eklemeyin; bu Googlebot değildir. IP’yi Google’ın yayımlanmış aralıklarıyla da karşılaştırabilir (googlebot.json) veya doğrudan Googlebot Verifier aracıyla doğrulayabilirsiniz. Yalnızca user-agent dizesine göre değil, doğrulanmış kimliğe göre izin listesine ekleyin.

401’i teşhis etme ve düzeltme araçları

• HTTP Status Checker — durum kodunu doğrulamak, yanıt zincirinin tamamını görmek ve kimlik doğrulama engeline ulaşmadan önce gerçekleşen yönlendirmeleri yakalamak için etkilenen URL’yi (veya URL grubunu) yapıştırın.
• Googlebot Verifier — bir IP’yi WAF veya güvenlik duvarı kuralından geçirmek üzere izin listesine eklemeden önce Googlebot olduğunu iddia eden IP’nin gerçek olup olmadığını kontrol edin (yayımlanmış IP aralıkları ve reverse-DNS doğrulaması).
• Google Search Console — URL Denetimi → Canlı Test — yetkilendirme tarafından o anda engellenip engellenmediği dâhil, Googlebot’un aldığı kesin yanıtı görmeye en çok yaklaşabileceğiniz testtir.
• curl -I — URL’yi çerez veya kimlik bilgisi olmadan istemenin ve WWW-Authenticate dâhil ham durum satırıyla üstbilgileri okumanın en hızlı yoludur.
• WAF/CDN’nizin güvenlik duvarı olay günlüğü (Cloudflare, Akamai, Sucuri vb.) — Googlebot’un IP aralıklarına 401/403 döndüren belirli kuralı bulun.

Düzeltmenin gerçekten işe yaradığını kanıtlayın

Kimlik doğrulama şartını kaldırdıktan veya doğrulanmış Googlebot’u izin listesine ekledikten sonra aşağıdaki kontroller, “yapılandırma değişti” ile “Google artık sayfaya gerçekten ulaşabiliyor” durumlarını birbirinden ayırır. Bunları sırayla çalıştırın.

Test 1 — Anonim istek artık 200 döndürüyor

• Çalıştırılacak test — Etkilenen URL’de çerez veya kimlik bilgisi olmadan curl -I çalıştırın (veya HTTP Status Checker ile kontrol edin).
• Beklenen sonuç — Durum satırı HTTP/1.1 200 OK göstermeli ve WWW-Authenticate üstbilgisi bulunmamalıdır.
• Başarısızlık yorumu — Hâlâ 401 alınması, ilgili yolun kimlik doğrulama şartının gerçekte kaldırılmadığını veya yanlış URL’yi/ortamı test ettiğinizi gösterir. 401 yerine 403 alınması, bir engeli başka bir engelle değiştirdiğiniz anlamına gelir; WAF/CDN kuralını kontrol edin.
• İzleme aralığı — Anında; değişiklik yayına girdiği anda sunucu yanıt verir.
• Geri alma koşulu — Engeli kaldırmak özel tutmayı amaçladığınız içeriği açığa çıkarırsa kimlik doğrulama şartını hemen geri koyun ve bunun yerine IP/reverse-DNS yoluyla doğrulanmış Googlebot’u izin listesine ekleyin.

Test 2 — Google artık sayfaya ulaşabildiğini doğruluyor

• Çalıştırılacak test — Etkilenen URL için Google Search Console’da URL Denetimi → Canlı URL’yi Test Et işlemini çalıştırın.
• Beklenen sonuç — Canlı test başarılı olmalı, sayfa içeriğini göstermeli ve yetkilendirme hatası bildirmemelidir. Bu, Google-InspectionTool’un sayfaya o anda erişip sayfayı ayrıştırabildiğini doğrular; bir erişim sonucudur, dizine ekleme garantisi değildir. Google’ın belgelerine göre canlı test tüm dizine ekleme koşullarını sınamaz ve başarılı olması dizine alınmayı garanti etmez.
• Başarısızlık yorumu — Anonim curl testi geçmesine rağmen Canlı Test hâlâ yetkilendirme engeli bildiriyorsa genel kimlik doğrulama engeli yerine özellikle Googlebot’un IP aralıklarını hedefleyen bir kuraldan (WAF/CDN izin listesi sorunu) şüphelenin.
• İzleme aralığı — Düzeltmeden hemen sonra veya birkaç dakika içinde.
• Geri alma koşulu — Yok; bu salt okunur bir testtir. Hâlâ başarısızsa herhangi bir şeyi geri almak yerine Test 1’in başarısızlık dalına dönün.

Test 3 — Sayfa Dizine Ekleme raporundaki 401 durumu temizleniyor

• Çalıştırılacak test — Sayfa Dizine Ekleme raporundaki “Blocked due to unauthorized request (401)” sorunu için Düzeltmeyi Doğrula seçeneğini kullanın (isteğe bağlıdır; Google sonraki taramada sayıyı her hâlükârda günceller) ve sonraki haftalarda grup sayısını izleyin (Nasıl Ölçülür sekmesine bakın).
• Beklenen sonuç — URL 401 grubundan çıkar ve daha önce dizine eklenmişse zaman içinde yeniden dizinde görünür. Ne Düzeltmeyi Doğrula ne de başarılı Canlı Test; dizine eklemeyi, kanonik seçimi veya arama sonuçlarında görünmeyi garanti eder. Gerçek dizin durumunu ve arama performansını ayrı izleyin.
• Başarısızlık yorumu — Yayımlanmış bir yeniden deneme sıklığı yoktur; bu nedenle yavaş doğrulamayı yeni bir hata olarak yorumlamayın. 401 grubundaki sayı birkaç hafta sonra düşüş eğilimi göstermiyorsa düzeltmenin hâlâ yürürlükte olduğunu doğrulamak için Test 1’i yeniden çalıştırın. Yeniden dağıtım veya CDN önbelleği, engeli sessizce geri getirebilir.
• İzleme aralığı — 401 grubu sayısı üzerinden izlenen birkaç gün ile birkaç hafta arası.
• Geri alma koşulu — Engeli yalnızca Test 1 yeniden başarısız olmaya başlarsa tekrar ele alın; Sayfa Dizine Ekleme raporunun zamanlamasının peşine düşmeyin.

Değişiklik günlüğü