Erişim Yasak Olduğu İçin Engellendi (403)

TL;DR — Google Search Console’daki “Blocked due to access forbidden (403)”, Googlebot’un sayfanızı okumaya çalıştığı ancak sunucunuzun HTTP 403 ile “hayır, erişim izniniz yok” yanıtını verdiği anlamına gelir. Sayfa dizine eklenmez. Sayfanın herkese açık olması gerekiyorsa bu, düzeltilmesi gereken bir hatadır; çoğu zaman güvenlik duvarı, CDN veya güvenlik eklentisi Google’ı yanlışlıkla engeller. Bu nedenle sayfa sizin tarayıcınızda düzgün görünürken Google için engellenebilir. Sayfanın gizli kalması gerekiyorsa 403 tam olarak görevini yapıyor olabilir; bu durumda çözüm farklıdır.

Bu durum ne anlama geliyor?

Bu rapor etiketi, Google’ın URL’yi isterken HTTP 403 yanıtı aldığını belirtir. Google, 429 dışındaki kalıcı 4xx yanıtlarını dizine ekleme açısından kullanılamayan içerik olarak değerlendirir. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. 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

Search Console’da Page Indexing raporunu açıp “Blocked due to access forbidden (403)” durumunu gördüğünüzde bunun anlamı basittir: Googlebot sayfayı sunucunuzdan istedi ve sunucu 403 Forbidden hatasıyla isteği reddetti.

Google 403 aldığı için sayfanın içeriğini okuyamaz; dolayısıyla sayfayı dizine eklemez. Sayfa daha önce Google dizinindeyse sonuçlardan kaldırılır.

Bunu gerçekten düzeltmeli misiniz?

Bir kuralın peşine düşmeden önce URL’nin ne yapması gerektiğine karar verin:

• Herkese açık ve dizine eklenmesi amaçlanıyor — 403 bir hatadır. Okumaya devam edin; sayfanın geri kalanı çözümü anlatıyor.
• Herkese açık ancak dizine eklenmesi amaçlanmıyor — bunun için robots.txt’ye güvenmeyin. robots.txt içindeki bir disallow kuralı, kendine ait rapor nedeni bulunan ayrı bir erişim kapısıdır ve tek başına HTTP 403 oluşturamaz. Normal 200 yanıtını sunup bunun yerine bir noindex yönergesi kullanın.
• Gizli kalması amaçlanıyor — 403, doğru çalışan bir erişim denetimi olabilir. Çözüm güvenlik duvarı kuralını değiştirmek değil, Google’ın URL’yi sürekli bulmasına neden olan site haritası veya dahili bağlantılardan URL’yi kaldırmaktır.

Sayfa sizin için açılırken Google için neden açılmıyor?

“Herkese açık olması amaçlanan” sayfalar açısından kafa karıştırıcı bölüm budur. Tarayıcınızda URL’yi tıkladığınızda sayfa kusursuz yükleniyorsa Google nasıl engelleniyor olabilir?

Tarayıcınız bir tarayıcının göndermediği sinyalleri gönderir: çerezler, “normal” bir tarayıcı user-agent’ı ve JS doğrulaması veya CAPTCHA kapıları söz konusu olduğunda doğrulamayı geçebilme yeteneği. Googlebot’un isteği bunların çoğu bakımından genellikle farklı görünür: çerez yoktur ve bir tarayıcı user-agent’ı kullanılır. Bu farklılık, veri kazıyıcıları hedefleyen bir bot kuralının gerçek ziyaretçileri sorunsuzca geçirirken yalnızca tarayıcı için tetiklenmesine çoğu zaman yeter. Genellikle bozuk olan sayfa değildir; bir kural yanlış ziyaretçiyi engelliyordur. (Advanced sekmesi, tahminde bulunmak yerine kesin farkı nasıl doğrulayacağınızı gösterir.)

Güvenlik duvarı veya CDN sık bildirilen bir nedendir

Herkese açık olması gereken URL’lerde bir güvenlik duvarı, CDN veya güvenlik aracının (örneğin Cloudflare, bir WAF ya da WordPress güvenlik eklentisi) Googlebot’u yanlışlıkla engellemesi en sık bildirilen nedenlerden biridir; ancak bunun tam olarak ne sıklıkta gerçekleştiğine ilişkin bağımsız olarak doğrulanmış bir oran yoktur. Diğer nedenler arasında user-agent veya ülkeye göre engelleyen kurallar, hotlink koruması ya da herkese açık olması gereken içeriğin oturum açma zorunluluğu arkasına konması bulunur.

Düzeltmeye nasıl başlanır?

• Search Console’da etkilenen bir URL için URL Inspection aracını kullanın ve Google’ın gerçekten 403 aldığını doğrulamak üzere Test live URL seçeneğine tıklayın.
• CDN, güvenlik duvarı veya güvenlik eklentisi ayarlarınızda ve günlüklerinde Googlebot’u ya da IP aralıklarını engelleyen bir şey olup olmadığını kontrol edin.
• İzin vermeden önce isteğin gerçekten Googlebot’tan geldiğinden emin olun ve istisnayı dar kapsamlı tutun: genel bir izin yerine yalnızca belirli rota ve kuralı kapsasın. Birçok bot Googlebot adını taklit eder. (Advanced ve Scripts sekmeleri doğrulama yöntemini gösterir.)
• Kuralı düzelttiğinizde sayfa normal bir 200 yanıtı döndürmelidir. Ardından raporda Validate Fix seçeneğini kullanın. Google 200 yanıtını yeniden taradığında sayfa otomatik olarak yeniden dizine eklenir; ancak bunun için garantili bir süre yoktur.

Bilmeniz gereken ilişkili bir durum daha vardır: “Blocked due to unauthorized request (401)”, oturum açma duvarının arkasındaki sayfalar için aynı temel sorunu ifade eder. Mekanizma farklı, sonuç ve çözüm ise büyük ölçüde aynıdır.

Eksiksiz tanılama ve düzeltme döngüsünü, WAF ayrıntılarını ve Googlebot doğrulama komutlarını mı istiyorsunuz? Advanced sekmesine geçin.

TL;DR — Page Indexing raporundaki 403, Googlebot’un URL’den HTTP 403 aldığı anlamına gelir; bu nedenle Google URL’yi dizine eklemez ve daha önce eklenmişse kaldırır. Google’ın Page Indexing yardımında 403, kimlik bilgilerinin sunulduğu ancak erişimin reddedildiği bir durum olarak açıklanır. Bu, Google’ın rapor ifadesidir; HTTP’nin eksiksiz tanımı değildir. RFC 9110, 403’ü kimlik bilgileri olsun veya olmasın “anlaşılan ancak reddedilen” istek olarak daha geniş tanımlar. Bu nedenle Google’ın açıklamasını yanlış yapılandırmanın kanıtı değil, bir sezgisel işaret olarak değerlendirin. Öncelikle URL’nin herkese açık ve dizine eklenebilir olması gerekip gerekmediğine karar verin. Herkese açık olması gereken URL’lerde güvenlik duvarı/CDN/WAF’ın Googlebot’u istemeden engellemesi sık bildirilen bir nedendir; sayfanın sizin için açılırken Google’a 403 vermesinin nedeni çoğu zaman budur. Gizli kalması amaçlanan bir URL’deki 403 ise beklendiği gibi çalışıyor olabilir. Google, dizine ekleme açısından 401 ve 403’ü aynı şekilde ele alır ve tarama hızını sınırlamak için 401/403 kullanmayın der; 429 (veya 503) kullanın. İzin listesine almadan önce gerçek Googlebot’u (reverse DNS / yayımlanmış IP aralıkları / doğru istemci kategorisi) doğrulayın, istisnayı belirli rota ve kuralla sınırlandırın, ardından URL Inspection → Test live URL ile 200 yanıtını doğrulayıp Validate Fix’i çalıştırın.

Google 403 hakkında gerçekte ne söylüyor, HTTP ne söylüyor?

Etiket, buna neden olan belirli WAF, CDN veya erişim kuralını değil, gözlemlenen yanıtı bildirir. Dizine ekleme sonucu, Google’ın genel 4xx işleme politikasından kaynaklanır. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. 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’ın Page Indexing raporu belgeleri bunu şöyle açıklar: HTTP 403, user agent’ın kimlik bilgileri sunduğu ancak erişim izni alamadığı anlamına gelir. Ancak Googlebot hiçbir zaman kimlik bilgileri sunmaz; dolayısıyla Google’ın ifadesiyle sunucunuz bu hatayı yanlış biçimde döndürmektedir. Sayfa dizine eklenmez. Dizine eklenmesini istiyorsanız Google’ın önerdiği çözüm, oturum açmamış kullanıcıları kabul etmek veya Googlebot isteklerine kimlik doğrulaması olmadan açıkça izin vermektir.

Ancak bu, HTTP’nin eksiksiz tanımı değil, Google’ın yardım belgesindeki çerçevedir. Güncel HTTP anlam bilimi belirtimi RFC 9110, 403’ü daha geniş tanımlar: Sunucu isteği anlamış ancak yerine getirmeyi reddetmiştir. Kimlik bilgileri bunun bir parçası olabilir; fakat RFC, bir isteğin kimlik bilgileriyle hiçbir ilgisi olmayan nedenlerle de yasaklanabileceğini açıkça belirtir: politika, erişim denetimi kuralı, uç güvenlik kararı veya sunucu sahibinin belirlediği başka bir neden. Bu nedenle yararlı çıkarım, “Googlebot’a verilen 403 tanım gereği her zaman bozuk bir kuraldır” değil; “bu URL’nin erişilebilir olması gerekip gerekmediğini belirleyin, ardından 403 döndüren kesin kuralı bulun” olmalıdır. Herkese açık ve dizine eklenmesi gereken bir sayfanın Googlebot’a 403 vermesi neredeyse her zaman düzeltilmesi gereken bir sorundur. Bilerek gizli veya yasak tutulan bir sayfada ise 403 geçerli ve doğru çalışan bir erişim kararı olabilir. Buradaki sorun çoğunlukla güvenlik duvarının yanlış olması değil, Google’ın URL’yi en başta keşfetmemesi gerekmesidir (aşağıdaki amaç kontrolüne bakın).

Durum hangisi olursa olsun, Google’ın ayrı HTTP durum kodları belgesi dizine ekleme sonucu konusunda nettir: Google, 4xx kodu döndüren URL’lerin içeriğini kullanmaz; 429 dışındaki tüm 4xx hataları aynı şekilde ele alınır (tarayıcı bir sonraki sisteme içeriğin mevcut olmadığını bildirir) ve dizine ekleme işlem hattı, URL daha önce dizine eklenmişse URL’yi dizinden kaldırır. 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

Herhangi bir şeyi düzeltmeden önce URL’nin amacını belirleyin

Bu rapordaki her satır aynı çözümü gerektirmez. Önce URL’yi şu dört gruptan birine ayırın:

1. Herkese açık ve dizine eklenmesi amaçlanıyor. 403 istenmeyen bir durumdur; aşağıdaki tanıla → düzelt → doğrula döngüsünü uygulayın.
2. Herkese açık ancak dizine eklenmesi amaçlanmıyor. Bunu çözmek için robots.txt kullanmayın. robots.txt disallow, kendine ait Page Indexing nedeni (“blocked by robots.txt”) bulunan ayrı bir tarama kapısıdır; bu durumun bildirdiği HTTP 403’ü kendisi oluşturmaz. Normal 200 yanıtını sunun ve bunun yerine bir noindex yönergesi ya da uygun bir yönlendirme/kaldırma yöntemi kullanın.
3. Bilerek gizli veya yasak. 403, istekte bulunanın erişmemesi gereken bir kaynak için doğru ve amaçlanan sonuç olabilir. URL bu raporda görünüyorsa çözülebilir sorun genellikle erişim kuralının yanlış olması değil; URL’nin site haritanızdan, dahili bağlantılardan veya başka bir yerden keşfedilebilmesidir. Kapıyı açmak yerine keşif sinyalini temizleyin.
4. Var olmaması gereken veya varlığını doğrulamak istemediğiniz bir URL. Yanıtı bir SEO kestirmesine göre değil, uygulamanızın güvenlik politikasına göre seçin. Burada hem 403 hem de URL’nin varlığını hiç doğrulamak istemiyorsanız 404 meşru olabilir. Evidence for this claim A robots.txt disallow is a separate crawl gate and Page indexing reason; it does not itself generate the HTTP 403 response required for the Blocked due to access forbidden (403) reason. Scope: verified Search Console properties Confidence: high · Verified: 2026-07-16 Page indexing report

Bundan sonraki her şey 1. durumu, yani gerçekten taranmasını ve dizine eklenmesini istediğiniz bir URL’yi varsayar.

403 ve 401 birbirinden nasıl ayrılır?

Bu iki durum raporda birbiriyle ilişkilidir. Çoğu yazı bunları tek başına güvenilir olmayan bir pratik kuralla (“403 = kimlik bilgisi istenmedi, 401 = oturum açma duvarı”) geneller. Yanlış yapılandırılmış bir kimlik doğrulama katmanı da 403 döndürebilir ve yine bu satırda yer alabilir. Gerçek sinyal yanıtın kendisidir:

• 401 (unauthorized) — RFC 9110’a göre 401, özellikle geçerli kimlik doğrulama bilgilerinin eksik olduğu anlamına gelir ve yanıtın bir WWW-Authenticate doğrulama başlığı taşıması gerekir (HTTP auth, oturum açma duvarı). Google’a kimlik doğrulaması yapması gerektiği söylenmiş, ancak bunu yapamamıştır.
• 403 (access forbidden) — daha geniş kapsamlı bir ret yanıtıdır. RFC 9110 bunu “the server understood the request but refuses to fulfill it,” şeklinde tanımlar; kimlik bilgileri bulunabilir veya bulunmayabilir. Uygulamada bu satır çoğunlukla güvenlik duvarı/CDN/WAF veya güvenlik kuralı engelidir; ancak hatalı kimlik doğrulama kontrolünden 403 döndüren bir uygulama, hız sınırlayıcı ya da bilinçli erişim denetimi kararı da olabilir.

Belirli bir URL’de bunları gerçekten ayırmak için yalnızca rapor etiketinden mekanizma çıkarmak yerine döndürülen durumu ve başlıkları kontrol edin: Yanıtta WWW-Authenticate başlığı var mı? İkisinin sonucu (dizine eklenmeme) ve çoğu zaman çözümü (doğrulanmış Googlebot’a geçiş izni verme veya içeriği anonim kullanıcılara açma) aynıdır. Hangisiyle karşı karşıya olduğunuzu belirledikten sonra aşağıdaki aynı tanılama döngüsü her iki satıra da uygulanabilir.

403 dizine eklemeyi nasıl etkiler?

Googlebot 403 aldığında üç sonuç ortaya çıkar:

1. İçerik yok sayılır. Google 4xx URL’lerinin içeriğini kullanmaz; dolayısıyla sayfadaki hiçbir şey dizine eklenemez.
2. URL daha önce dizine eklenmişse kaldırılır. 403, daha önce sıralama alan bir sayfayı dizinden çıkarabilir. Bu yalnızca “eklenmeme” değil, “sonuçlardan düşme” sorunudur.
3. Tarama sıklığı azalır. Google zamanla 4xx URL’lerini giderek daha seyrek tarar. Bu nedenle uzun süredir 403 döndüren bir URL daha az ziyaret edilir ve düzeltildikten sonra daha yavaş toparlanır.

Tarayıcınız almazken Googlebot neden 403 alıyor?

İnsanları çıkmaza sokan soru budur. Sayfa tarayıcınızda açıldığı için içerik açıkça sağlam görünür; ancak Google 403 bildirir. Muhtemel açıklama, tarayıcınız ile Googlebot’un çok farklı görünen istekler göndermesi ve veri kazıyıcıları durdurmak için oluşturulmuş bir bot yönetimi kuralının insanlara normal hizmet verirken tarayıcı için tetiklenebilmesidir. Ancak bunu kaçınılmaz sonuç değil, doğrulanması gereken bir hipotez olarak değerlendirin; gerçekten önemli olan özellik siteden siteye değişir:

• Tarayıcınız çerezler ve gerçek bir tarayıcı user-agent’ı gönderir ve bir JS veya CAPTCHA doğrulamasını çözebilir; Googlebot’un isteği ise genellikle bunların hiçbirini taşımaz: çerez içermez, bir tarayıcı user-agent’ı kullanır ve etkileşimli bir doğrulamayı çözemez. Ancak Google-InspectionTool JavaScript’i işler ve işlenmiş çıktıyı bildirir; dolayısıyla “Googlebot has no JavaScript” ifadesi bunun her bölümü için doğru değildir.
• İstemci tarafındaki farklara ek olarak iki istek kaynak IP/kategorisi, coğrafya, yöntem, referrer, önbellek durumu ve fiilen tetiklenen kural bakımından da farklılık gösterebilir; gerçek tetikleyici bunlardan herhangi biri olabilir.

Buna hangi özelliğin neden olduğunu tahmin etmeyin. Gerçekten engellenen bir isteğin uç ve kaynak günlüklerini normal bir tarayıcı isteğiyle karşılaştırın: aynı kural ID’si, yanıt başlıkları, yöntem, UA, kaynak IP ve doğrulanmış kategorisi, coğrafya, çerezler, referrer, önbellek durumu ve doğrulama sonucu. Yanıtı değiştiren özelliği bulana kadar her seferinde tek bir özelliği değiştirin. 403’ün seçici olduğunu varsaymak yerine böyle doğrularsınız.

Yaygın nedenler

• CDN / WAF bot yönetimi. Cloudflare (Bot Fight Mode / Super Bot Fight Mode, Browser Integrity Check, Managed Challenge), Akamai, Imperva/Incapsula, Sucuri ve AWS WAF; Googlebot dahil tarayıcı olmayan istemcilere doğrulama uygulayabilir veya 403 döndürebilir. Herkese açık olması gereken URL’ler açısından bu, en sık bildirilen nedenlerden biridir ve neredeyse her zaman istenmeyen bir durumdur; ancak vakaların ne kadarını oluşturduğuna ilişkin bağımsız olarak doğrulanmış bir oran yoktur.
• Sunucu güvenlik duvarı / güvenlik kuralları. mod_security / OWASP CRS, fail2ban veya ana makine düzeyindeki güvenlik duvarları Googlebot’un davranış kalıbını kötüye kullanım olarak işaretleyebilir.
• User-agent / referrer / hotlink kuralları. Tarayıcı benzeri bir user-agent veya referrer içermeyen her isteğe 403 döndüren kurallar.
• Coğrafi / IP engelleme. Googlebot’un tarama yaptığı IP aralıklarının dışlanması. Googlebot çoğunlukla ABD IP’lerinden taradığı için ülke engeli onu fark ettirmeden yakalayabilir.
• Oturum açma / kimlik bilgisi duvarları. Herkese açık olması gereken içeriği görüntülemek için çerez veya oturum açma şartı konması; bu, 401 durumuyla örtüşür.
• N istekten sonra 403 döndüren hız sınırlama kuralları. Bunu yapmayın; aşağıya bakın.

Googlebot’u yavaşlatmak için 403 kullanmayın

Bu, adıyla belirtilmeye değer bir anti-pattern’dir. Bazı kişiler ve CDN’ler Googlebot’u yavaşlatmak ve sunucu yükünü azaltmak için 403 veya 404 döndürür. Google bunun işe yaramadığını ve yapılmaması gerektiğini açıkça belirtmiştir: Tarama hızını sınırlamak için 401 ve 403 durum kodlarını kullanmayın. Bunların tarama hızı üzerinde etkisi yoktur; yalnızca sayfayı dizinden çıkarırlar. Googlebot’un gerçekten geri çekilmesini istiyorsanız 429 veya 503 gibi bir 5xx döndürün. Google bu kodları “yavaşla” olarak yorumlar ve etkileri kalıcı değil, geçicidir.

Nasıl tanılanır?

1. URL Inspection → Test live URL. Etkilenen URL’yi Search Console’da test ederek Google’ın eski bir rapora dayanmak yerine şu anda 403 aldığını doğrulayın. Bu testin belirli bir Google istemcisi olan Google-InspectionTool tarafından yapıldığını unutmayın. Canlı testin başarılı olması, InspectionTool’un o anda geçtiğini gösterir; planlanmış standart Googlebot’un sonraki taramada aynı WAF, coğrafya, önbellek veya hız sınırı yolunu izleyeceğini göstermez.
2. Googlebot olarak yeniden üretin. Normal tarayıcınızdan test etmeyin. Aynı kuralı tetiklemek için URL’yi Googlebot user-agent’ıyla, ideal olarak ağınızın dışından ve birden fazla bölgeden isteyin. Google çoğunlukla ABD IP’lerinden tarar ancak ABD istekleri engellenirse başka ülkelere geçebilir; dolayısıyla tek bir bölgedeki başarı küresel erişimi kanıtlamaz. (Komutlar Scripts sekmesindedir.)
3. CDN / WAF / güvenlik duvarı günlüklerini okuyun. Googlebot isteğinde tetiklenen kesin kuralı bulun. Hangi özelliğin neden olduğunu varsaymak yerine yanıt başlıklarını, kural ID’sini ve tetikleyiciyi (user-agent, IP, doğrulama, hız sınırı) normal bir tarayıcı isteğinin günlük kaydıyla karşılaştırın.
4. Gerçek Googlebot’u ve kategorisini doğrulayın. İzin listesine herhangi bir şey eklemeden önce isteklerin reverse + forward DNS veya Google’ın yayımladığı IP aralıkları aracılığıyla gerçekten Googlebot’tan geldiğini doğrulayın ve isteği hangi Google istemcisinin yaptığını kontrol edin. Standart Googlebot, özel durum tarayıcıları ve Google-InspectionTool gibi kullanıcı tarafından tetiklenen getiriciler farklı ana makine kalıpları ve IP listeleri kullanır; yanlış listeye göre doğrulama yapmak gerçek bir isteğin sahte görünmesine yol açabilir.

Nasıl düzeltilir?

• WAF veya güvenlik duvarınızda doğrulanmış Googlebot için dar kapsamlı bir istisna oluşturun. Yalnızca user-agent dizesine güvenmek yerine reverse + forward DNS ile doğrulanmış kimliği, doğru istemci kategorisiyle eşleşmeyi veya Google’ın güncel yayımlanmış tarayıcı IP aralıklarını kullanın. İstisnayı dar tutun: tüm Google trafiğine genel izin vermek yerine yalnızca gerekli belirli rotaları ve engelleyen belirli kuralı kapsasın. Diğer güvenlik kontrollerinizi, hız sınırlarınızı ve günlük kaydınızı koruyun; eski bir izin listesinin gerekçesinden daha uzun yaşamaması için sona erme/inceleme tarihi belirleyin. CDN/güvenlik duvarı sağlayıcınızdan Googlebot’a izin verildiğini doğrulamasını isteyin ve gelecekteki bir IP aralığı güncellemesinin sizi fark ettirmeden yeniden engellememesi için engelleme kurallarınızı Google’ın güncel yayımlanmış IP alt ağlarıyla karşılaştıran bir kontrolü otomatikleştirin.
• Herkese açık içeriği anonim kullanıcılara açın. 403, herkese açık olması gereken içerikteki oturum açma/çerez şartından kaynaklanıyorsa bu şartı kaldırın. Bu, ilişkili 401 durumuyla ortak çözümdür.
• 403 kullanan hız sınırlarını 429 ile değiştirin. Bir kural istek eşiğinden sonra 403 döndürüyorsa Googlebot’un bunu “git” yerine “yavaşla” olarak yorumlaması için 429 veya 503 döndürecek şekilde değiştirin.

Düzeltmeyi doğrulayın ve yeniden dizine eklenin

Kural düzeltildiğinde URL 200 döndürmelidir. Ardından:

1. Canlı yanıtın artık 200 olduğunu doğrulamak için URL Inspection → Test live URL kullanın.
2. Yüksek öncelikli URL’ler için Request indexing seçeneğini kullanın ve/veya Page Indexing raporundaki “Blocked due to access forbidden (403)” satırında Validate Fix seçeneğine tıklayın.
3. Google bir 200 yanıtını yeniden taradığında yeniden dizine ekleme otomatik olarak gerçekleşir. Bunun tam olarak ne kadar hızlı olacağına ilişkin resmî bir garanti yoktur ve URL’nin yeniden görünebilmesi için normal bir taramadan geçmesi gerekir. Engeli kaldırmak, sağlıklı yanıtı doğrulamak ve Google’a yeniden tarama için zaman vermek dışında manuel olarak başka bir işlem tetiklemeniz gerekmez. Evidence for this claim The Page Indexing report identifies URLs where Google encountered a forbidden-access response. 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

Burada hangi dizine eklenmeme nedenlerinin göründüğünü ve raporun bunları nasıl grupladığını daha geniş bağlamda görmek için Page Indexing raporunun genel açıklamasına bakın. İlişkili durum olan “Blocked due to unauthorized request (401)”, aynı sorunun 401 sürümüdür.

Yapay zekâ özeti

Advanced sürümünün özetlenmiş açıklaması:

• Nedir? GSC’nin Page Indexing raporundaki “Blocked due to access forbidden (403)” durumu, Googlebot’un URL’yi taradığı ve sunucunun HTTP 403 yanıtı verdiği anlamına gelir. Google URL’yi dizine eklemez ve daha önce dizine eklenmişse kaldırır.
• Google’ın çerçevesi ile HTTP’nin tanımı. Google’ın yardım belgesi 403’ü, kimlik bilgilerinin sunulduğu ancak reddedildiği bir durum olarak açıklar. Bu, HTTP’nin eksiksiz tanımı değil, Google’ın raporunda kullandığı ifadedir. RFC 9110, 403’ü daha geniş biçimde tanımlar: Sunucu, kimlik bilgileri olsun veya olmasın, herhangi bir nedenle bu ret yanıtını verebilir.
• Önce URL’nin amacını belirleyin. Herkese açık ve dizine eklenmesi amaçlanıyorsa → 403’ü düzeltin. Herkese açık ancak dizine eklenmesi amaçlanmıyorsa → robots.txt yerine noindex kullanın; robots.txt ayrı bir erişim kapısıdır ve tek başına 403 oluşturamaz. Bilerek gizli tutuluyorsa → 403 doğru olabilir; bunun yerine Google’ın URL’yi nasıl keşfettiğini düzenleyin.
• Sık bildirilen bir neden (herkese açık URL’lerde). Bir güvenlik duvarı / CDN / WAF (Cloudflare, Akamai, Imperva/Incapsula, Sucuri, AWS WAF) veya güvenlik eklentisi, Googlebot’u çoğunlukla istemeden engelliyor olabilir; ancak bu belirli nedenin ne sıklıkta geçerli olduğuna ilişkin doğrulanmış bir oran yoktur.
• Neden sizde açıldığı hâlde Google’da açılmayabilir? Tarayıcınız genellikle çerezler ve gerçek bir user-agent taşır ve Googlebot isteğinin çözemediği doğrulamaları geçebilir; yine de varsayımda bulunmayın, günlükleri karşılaştırarak gerçek tetikleyiciyi doğrulayın.
• 401 ile 403 arasındaki fark. Yanıtı kontrol edin: 401, bir WWW-Authenticate doğrulaması gerektirir; 403 ise kimlik bilgileriyle veya bunlar olmadan gerçekleşebilen daha geniş kapsamlı bir ret yanıtıdır. Google, dizine ekleme açısından ikisini aynı şekilde ele alır ve çözümler çoğu zaman örtüşür.
• Bununla tarama hızını sınırlamayın. Tarama hızını sınırlamak için 401/403 kullanmayın; bunlar yalnızca dizinden çıkarılmaya yol açar. “Yavaşla” sinyali için 429 veya 503 kullanın.
• Tanılama. URL Inspection → Test live URL adımını kullanın; bu test, planlanmış Googlebot’un izlediği yolu değil, Google-InspectionTool’un o andaki erişimini doğrular. İsteği birden fazla bölgeden Googlebot olarak yeniden oluşturun; WAF/güvenlik duvarı günlüklerini satır satır karşılaştırın; izin listesine almadan önce gerçek Googlebot’u ve istemci kategorisini doğrulayın.
• Düzeltme ve doğrulama. Kapsamı dar, doğrulanmış bir Googlebot istisnası oluşturun veya içeriği erişime açın; 403 kullanan hız sınırlarını 429 ile değiştirin; Test live URL sonucunda 200 yanıtını doğrulayın ve Validate Fix’i çalıştırın. Google bir 200 yanıtını yeniden taradığında dizine ekleme otomatik olarak gerçekleşir; bunun için garantili bir süre yoktur.

Resmî belgeler

Arama motorlarının birincil kaynak belgeleri.

Google

• Page Indexing report — “Blocked due to access forbidden (403)” ve “Blocked due to unauthorized request (401)” girişleri ile her birinin anlamı dahil olmak üzere raporun kendisi.
• How HTTP status codes, and network and DNS errors affect Google Search — Google’ın 4xx yanıtlarını nasıl ele aldığı (içeriğin yok sayılması, URL’nin dizinden kaldırılması) ve tarama hızını sınırlamak için 401/403 kullanmama kuralı.
• Verifying Googlebot and other Google crawlers — izin listesine bir taklitçiyi değil gerçek Googlebot’u ekleyebilmeniz için reverse + forward DNS ve yayımlanmış tarayıcı IP aralıkları.
• Overview of Google crawlers and fetchers — tüm Google user-agent’ları ve karşılaştırılacak IP aralığı JSON dosyaları.
• Don’t 404 my yum (Search Central Blog, 2023) — Google’ın site sahipleri ve CDN’lerden Googlebot’u yavaşlatmak için 403/404 kullanmayı bırakmalarını istemesi ve bunun yerine ne kullanılacağı.

Bing / Microsoft

• Bing Webmaster Tools — Crawl Control — Googlebot gibi Bingbot da 403 aldığı bir sayfayı dizine ekleyemez. Güvenlik duvarı/CDN kurallarının Bingbot’u engellemediğini doğrulayın; ana makine adları *.search.msn.com olarak çözümlenir. Hızı engelleme yoluyla değil Crawl Control ile yönetin.

HTTP standardı

• RFC 9110 — HTTP Semantics, §15.5.2 (401) and §15.5.4 (403) — bu sayfanın Google’ın daha dar, kimlik bilgisi temelli yardım belgesi ifadesini düzeltmek için kullandığı protokol tanımları: 401 bir WWW-Authenticate doğrulaması gerektirirken 403, kimlik bilgileriyle veya bunlar olmadan gerçekleşebilen daha geniş kapsamlı bir ret yanıtıdır.

Kaynaktan alıntılar

Google’ın kayda geçmiş açıklamaları. Her bağlantı, kaynak sayfadaki alıntılanan bölüme doğrudan gider.

Google — 403’ün dizine ekleme açısından anlamı (Page Indexing raporu)

• “HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” — Google Search Console Yardım, “Page Indexing report.” Alıntıya git

Google — 4xx (403 dahil) nasıl ele alınır?

• “Google doesn’t use the content from URLs that return 4xx status codes.” — Google Search Central belgeleri. Alıntıya git
• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” Alıntıya git

Google — tarama hızını sınırlamak için 401/403 kullanmayın

• “Don’t use 401 and 403 status codes for limiting the crawl rate.” — Google Search Central belgeleri. Alıntıya git

403 tanıla → düzelt → doğrula kontrol listesi

“Blocked due to access forbidden (403)” gösteren her URL için bu listeyi uygulayın:

• URL’nin amacını belirleyin — herkese açık/dizine eklenebilir, herkese açık/dizine eklenemez, bilerek gizli veya hiç keşfedilmemesi gereken. Kontrol listesinin geri kalanı yalnızca herkese açık ve dizine eklenebilir durum için gereklidir.
• Durumun güncel olduğunu doğrulayın — URL Inspection → Test live URL güncel bir 403 göstermelidir. Bu, planlanmış Googlebot’un kesin yolunu değil, Google-InspectionTool erişimini doğrular.
• Googlebot olarak yeniden üretin — URL’yi normal tarayıcınızla değil, Googlebot user-agent’ıyla; ağınızın dışından ve ideal olarak birden fazla bölgeden isteyin.
• Kuralı bulun — nedeni varsaymak yerine engellenen isteğin CDN / WAF / güvenlik duvarı / eklenti günlüklerini normal bir tarayıcı isteğiyle karşılaştırın: kural ID’si ve tetikleyici (user-agent, IP, doğrulama veya hız sınırı).
• Gerçek Googlebot’u ve istemci kategorisini doğrulayın — herhangi bir şeyi izin listesine almadan önce reverse + forward DNS kullanın (ana makine googlebot.com / google.com / googleusercontent.com ile bitmelidir) veya IP’yi doğru kategoriye ait IP aralığı listesiyle eşleştirin.
• Doğrulanmış Googlebot için dar kapsamlı istisna oluşturun — yalnızca belirli rota ve kuralı kimlik/IP aralığına göre, günlük kaydı ve sona erme/inceleme tarihiyle kapsayın. Genel izin vermeyin ve yalnızca user-agent dizesine asla güvenmeyin.
• Herkese açık içeriği açın — 403, herkese açık olması gereken içerikteki oturum açma/çerez şartından kaynaklanıyorsa bu şartı kaldırın.
• 403 kullanan tüm hız sınırlarını 429 ile değiştirin (veya 503) — taramayı yavaşlatmak için asla 401/403 kullanmayın.
• 200 yanıtını doğrulayın — URL Inspection → Test live URL artık 200 döndürmelidir.
• Doğrulayın — 403 satırında Validate Fix seçeneğine ve/veya öncelikli URL’ler için Request indexing seçeneğine tıklayın; yeniden taramada dizine ekleme otomatik gerçekleşir.
• Geleceğe hazırlayın — bir IP aralığı güncellemesinin sizi fark ettirmeden yeniden engellememesi için engelleme kurallarınızı Google’ın yayımlanmış IP alt ağlarıyla karşılaştıran bir kontrolü otomatikleştirin.

Zihinsel modeller

1. “Kim yanlış yapılandırdı?” sorusundan önce “Bu herkese açık olmalı mı?” diye sorun. Google’ın yardım ifadesi 403’ü kimlik bilgilerinin gönderildiği ve reddedildiği durum olarak çerçeveler; ancak RFC 9110 bunu daha geniş biçimde, sunucunun anladığı ve kimlik bilgileri olsun veya olmasın herhangi bir nedenle reddettiği istek olarak tanımlar. Herkese açık ve dizine eklenmesi gereken bir sayfanın Googlebot’a 403 vermesi neredeyse her zaman bir kuralın yanlış ziyaretçi için tetiklendiği anlamına gelir. Bunu “sayfayı yargıla” değil, “kuralı bul” sorunu olarak değerlendirin. Bilerek gizli tutulan bir sayfada ise 403 görevini yapıyor olabilir; çözüm güvenlik duvarını açmak değil, URL’yi Google’ın keşif yolundan kaldırmaktır.

2. Aynı kural, farklı görünen ziyaretçi: Hangi farkın önemli olduğunu doğrulayın. Tarayıcınız Googlebot isteğinde bulunmayan çerezler ve gerçek bir user-agent gönderdiği ve doğrulamaları çözebildiği için sayfa sizin için açılıp Google’a 403 verebilir. Ancak kuralı hangi özelliğin tetiklediğini varsaymayın; günlükleri karşılaştırın ve her seferinde tek bir özelliği değiştirin. Hata ayıklamayı kendi isteğinizi değil, Googlebot isteğini oluşturarak yapın ve nedeni tahminin değil günlüklerin göstermesine izin verin.

3. Kimliği doğrulayın, ardından istisnayı dar kapsamlı tutun. Googlebot user-agent’ını herkes taklit edebilir. Sıra her zaman şöyledir: kimliği ve istemci kategorisini doğrulayın (reverse DNS / eşleşen IP aralığı listesi) → ardından izin verin. Bu durumda bile genel bir Google izin listesi yerine istisnayı belirli rota ve kuralla sınırlandırın, günlük tutun ve sona erme/inceleme tarihi belirleyin. Yalnızca user-agent’a dayanarak veya aşırı geniş kapsamda izin listesi oluşturmak, Google gibi davranan veri kazıyıcılara açık oluşturur.

4. 403 yanlış hız sınırlama aracıdır. Amacınız Googlebot’u yavaşlatmaksa 401/403 bunu yapmaz; sayfayı dizinden çıkarır. “Yavaşla” kodları 429 ve 5xx/503’tür. Amacınıza uyan kodu seçin: “bir daha gelme” (dizinden çıkarma) veya “daha sonra gel” (hız sınırlama).

5. 403 ve 401 yakın akrabadır; yanıt üzerinden ayrılır. 401, gerçek bir yetkilendirme duvarını belirten WWW-Authenticate doğrulamasını gerektirir. 403 ise kimlik bilgileriyle veya bunlar olmadan ortaya çıkabilen daha geniş bir ret yanıtıdır. Bu nedenle yalnızca etiketten mekanizma çıkarmayın; gerçek yanıtı kontrol edin. Hangisiyle karşı karşıya olduğunuzu belirlediğinizde aynı sonucu (dizine eklenmeme) ve çoğu zaman aynı çözümü (doğrulanmış Googlebot’a izin verme / içeriği açma) paylaşırlar; ikisini de aynı döngüyle tanılayın.

403 hızlı başvuru

Page Indexing’deki ilişkili durumlar

Durum kodları ve tarama: Doğru olanı seçin

403, dizine eklenmesi amaçlanan bir sayfayı nasıl etkiler?

• İçerik yok sayılır (Google 4xx içeriğini kullanmaz).
• URL daha önce dizine eklenmişse dizinden kaldırılır.
• 403 devam ettiği sürece tarama sıklığı azalır.

Googlebot doğrulama hızlı başvurusu

• IP için Reverse-DNS sorgusu yapın → ana makine googlebot.com, google.com veya googleusercontent.com ile bitmelidir.
• Bu ana makine için Forward-DNS sorgusu yapın → aynı IP’ye geri çözümlenmelidir.
• Alternatif olarak IP’yi doğru istemci kategorisine ait Google’ın güncel yayımlanmış tarayıcı IP aralığı JSON dosyalarıyla eşleştirin. Standart Googlebot, özel durum tarayıcıları ve Google-InspectionTool gibi kullanıcı tarafından tetiklenen getiriciler ayrı listeler yayımlar.

403’ü Googlebot olarak yeniden üretin

Normal tarayıcınızdan test etmeyin; bot kuralını tetiklemeyebilir. Google’ın gördüğü yanıtı görmek için URL’yi Googlebot user-agent’ıyla isteyin.

macOS / Linux

# Fetch headers only, as Googlebot's user-agent — look at the status line
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -I https://www.example.com/page/
# A "HTTP/1.1 403 Forbidden" here reproduces what Googlebot is getting.

Windows (PowerShell)

# -SkipHttpErrorCheck so PowerShell shows the 403 instead of throwing
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
  -UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescription

Bu istek 403, normal tarayıcı isteği ise 200 döndürüyorsa bota özgü bir engeli doğrulamış olursunuz. Not: Gelişmiş bir WAF, IP’yi de ölçüt olarak kullanabilir; eksiksiz bir yeniden üretim için kendi ağınızın dışından test yapın.

Bir botun gerçekten Googlebot olduğunu doğrulayın (izin listesine almadan önce)

Birçok trafik kaynağı Googlebot user-agent’ını taklit eder. Bir IP’yi güvenlik duvarınızdan geçirmeden önce reverse + forward DNS kontrolüyle kimliği doğrulayın.

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

Reverse lookup bir Google alan adıyla bitmiyorsa veya forward lookup özgün IP’yle eşleşmiyorsa bu Googlebot değildir; izin listesine almayın. IP’yi Google’ın yayımlanmış aralıklarıyla da eşleştirebilirsiniz (googlebot.json). googlebot.json yalnızca standart Googlebot’u kapsar. Özel durum tarayıcıları ve Google-InspectionTool gibi kullanıcı tarafından tetiklenen getiriciler ayrı IP aralığı dosyaları yayımlar; dolayısıyla doğrulamaya çalıştığınız gerçek istemciye ait listeyle karşılaştırın. Önce kimliği doğrulayın, ardından istisnayı belirli rota ve kuralla sınırlandırın. Yalnızca user-agent dizesine göre asla izin listesine almayın veya genel bir istisna açmayın.

403 tanısı: WAF engeli, oturum açma duvarı veya hız sınırının yanlış kullanımı mı?

İlk ayrım yanıtın kendisini kontrol eder: WWW-Authenticate başlığı veya oturum açma istemi bulunmayan bir 403, ilişkili 401 durumundan uzaklaşıp güvenlik kuralı ya da erişim denetimi reddine işaret eder. Buradan sonraki dallar Advanced sekmesindeki tanıla-sonra-düzelt döngüsünü izler. Her sonucu kesinlik değil, günlüklerinizde doğrulanması gereken bir hipotez olarak değerlendirin. Seçenekler arasında ilerleyin.

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

İzlemeye değer sayı, satırın yalnızca var olup olmadığı değil, Page Indexing raporundaki “Blocked due to access forbidden (403)” satırında zaman içinde kaç URL bulunduğudur. Tek bir anlık görüntü, düzeltmenin gerçekten işe yarayıp yaramadığını veya yeni 403’lerin birikip birikmediğini gösteremez.

Zaman içinde 403 grubu sayısı

• Metrik — GSC Page Indexing raporunda “Blocked due to access forbidden (403)” altında bulunan URL sayısının haftadan haftaya izlenmesi.
• Size ne anlatır? — İzin listesi veya güvenlik duvarı kuralı düzeltmesinin gerçekten işe yarayıp yaramadığını ve yeni 403’lerin ortaya çıkıp çıkmadığını gösterir. Doğrulanmış Googlebot’u izin listesine aldıktan veya herkese açık bir yolu açtıktan sonra bu sayı düzelttiğiniz URL’ler için sıfıra doğru düşmelidir. Sayının sabit kalması, yalnızca bu URL’lerin hiçbir zaman taranmaması gerektiğine bilinçli olarak karar verdiyseniz sorun değildir. Artan sayı genellikle bir WAF/CDN kuralının veya IP aralığı güncellemesinin Googlebot’u yeni engellemeye başladığını gösterir.
• Nasıl alınır? — GSC Page Indexing raporunu 403 satırına göre filtreleyin; eski bir anlık görüntü olmadıklarını doğrulamak için URL’leri URL Inspection → Test live URL ile örneklemeli olarak kontrol edin.
• Karşılaştırma noktası / gerçekçi aralık — Evrensel bir hedef yoktur; gerçekten kaç URL’yi dizine ekletmek istediğinize bağlıdır. Dürüst ölçüt, dizine eklenmesini istediğiniz URL’lerde sıfır 403 ve diğerlerinde sabit, artmayan bir sayıdır. Eğilimi değerlendirmeden önce kendi temel sayınızı belirleyin.
• Sıklık — Düzeltmeden hemen sonra sayı dengelenene kadar haftalık; ardından bir regresyon kontrolü olarak aylık. CDN veya Googlebot IP aralığı güncellemesi engeli fark ettirmeden yeniden ortaya çıkarabilir.

Çalıştırma kılavuzu: Tanıla, düzelt, doğrula

403 iş akışı kısa ve sıralı bir döngüdür. Engeli Googlebot olarak yeniden üretmeden ve geçiş izni vermek üzere olduğunuz isteğin kimliğini doğrulamadan izin listesine alma adımına atlamayın.

1. Durumun eski değil, güncel olduğunu doğrulayın. Google’ın önbelleğe alınmış bir rapor yerine şu anda 403 aldığını doğrulamak için etkilenen URL üzerinde GSC’de URL Inspection → Test live URL çalıştırın.

2. Kendiniz olarak değil, Googlebot olarak yeniden üretin. URL’yi Googlebot user-agent’ıyla, ideal olarak kendi ağınızın dışından ve birden fazla bölgeden isteyin. Normal tarayıcınız çerezler ve gerçek bir user-agent gönderir ve Googlebot isteğinin genellikle geçemediği JS/CAPTCHA doğrulamalarını geçebilir; dolayısıyla aynı kuralı tetiklemeyebilir. Engelin hangi farktan kaynaklandığını varsaymak yerine ortaya çıkan günlük kayıtlarını yan yana karşılaştırın.

3. Kuralı bulun. Googlebot isteğinde tetiklenen kesin kural için CDN/WAF/güvenlik duvarı günlüklerini okuyun. Kural ID’si ve tetikleyici (user-agent, IP, doğrulama veya hız sınırı) neyi değiştirmeniz gerektiğini gösterir.

4. İzin listesine almadan önce gerçek Googlebot’u ve kategorisini doğrulayın. İzin vermek üzere olduğunuz isteklerin reverse + forward DNS veya ilgili istemci kategorisiyle eşleşen IP aralığı listesi aracılığıyla gerçekten Googlebot’tan geldiğini doğrulayın. Standart Googlebot, özel durum tarayıcıları ve kullanıcı tarafından tetiklenen getiriciler ayrı listeler yayımlar. Aksi halde taklitçiler için açık oluşturabilir veya yanlış listeye göre doğrulama yapabilirsiniz.

5. Nedene göre düzeltin. WAF/CDN kuralı → belirli rota ve kural için kimlik/IP aralığına dayalı, dar kapsamlı bir doğrulanmış Googlebot istisnası oluşturun. Herkese açık içerikteki oturum açma/çerez şartı → kaldırın. 403 döndüren hız sınırı kuralı → 429 veya 503 ile değiştirin.

6. Doğrulayın. URL Inspection → Test live URL seçeneğinin artık 200 döndürdüğünü doğrulayın, ardından 403 satırında Validate Fix ve/veya öncelikli URL’ler için Request indexing seçeneğine tıklayın. Google bir 200 yanıtını yeniden taradığında dizine ekleme otomatik gerçekleşir. 403 grubu sayısı birkaç hafta sonra düşme eğiliminde değilse yeni bir neden tahmin etmek yerine 2. adıma dönüp sorunu yeniden üretin.

Kullanıma hazır yapay zekâ istemleri

Ham tanılama çıktısından bir 403’ü sınıflandırmak için kopyalayıp yapıştırabileceğiniz istemler. Bunlar olası nedeni hızla önceliklendirmenize 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 olası nedeni sınıflandırın

I'm diagnosing a "Blocked due to access forbidden (403)" status in Google
Search Console. Below is the raw output of a request made with Googlebot's
user-agent (curl -A "...Googlebot..." -I). Based on this output alone,
classify the most likely cause as one of: (1) CDN/WAF bot-management
challenging or blocking non-browser clients, (2) server firewall / mod_security
rule flagging the crawl pattern as abuse, (3) user-agent or referrer/hotlink
rule, (4) geo/IP blocking excluding Googlebot's IP ranges, (5) a login/cookie
requirement on content that should be public, (6) a rate-limit rule misusing
403 instead of 429. 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 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 challenge/CAPTCHA rule, or a rate-limit rule misusing 403, 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 düzeltmenin sağlamasını yapın

I'm about to allowlist a set of IPs as "Googlebot" in my WAF, because a page
I want indexed is currently returning 403 to the crawler. Here's the evidence
I have that these requests are genuinely Googlebot: [describe reverse-DNS or
IP-range check]. Point out anything I might be missing — e.g. whether I should
verify by both reverse and forward DNS, whether I should match Google's
published IP-range JSON instead, or whether allowlisting by user-agent alone
would leave a hole for spoofers.

Kendinizi sınayın: “Blocked due to access forbidden (403)”

403’ün ne anlama geldiği, 401’den nasıl ayrıldığı ve nasıl tanılanıp düzeltileceği hakkında beş soru. Her biri için bir yanıt seçin, ardından kontrol edin.

403’ü tanılamak ve düzeltmek için araçlar

• HTTP Status Checker — 403 durum kodunu doğrulamak, yanıt zincirinin tamamını görmek ve engele ulaşmadan önce gerçekleşen yönlendirmeleri yakalamak için etkilenen URL’yi veya bir URL grubunu yapıştırın.
• Googlebot Verifier — Googlebot olduğunu iddia eden bir IP’yi WAF veya güvenlik duvarı kuralında izin listesine almadan önce gerçekten Googlebot olup olmadığını kontrol edin (yayımlanmış IP aralıkları ve reverse-DNS doğrulaması).
• Google Search Console — URL Inspection → Test live URL — Googlebot’un şu anda aldığı kesin yanıtı görmeye en yakın yöntemdir.
• curl -A "...Googlebot..." — bir URL’yi Googlebot user-agent’ıyla istemenin ve ham durum satırını okumanın en hızlı yoludur.
• WAF/CDN güvenlik duvarı olay günlüğünüz (Cloudflare, Akamai, Sucuri vb.) — Googlebot IP aralıklarına 403 döndüren belirli kuralı bulun.

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

Doğrulanmış Googlebot’u izin listesine aldıktan, herkese açık içeriği açtıktan veya hız sınırı kuralını 429 ile değiştirdikten sonra aşağıdaki kontroller, “yapılandırma değişti” ile “Google artık sayfaya gerçekten erişebiliyor” durumlarını birbirinden ayırır. Bunları sırayla uygulayın.

Test 1 — Googlebot user-agent isteği artık 200 döndürüyor

• Çalıştırılacak test — Etkilenen URL’yi Googlebot user-agent’ıyla isteyin veya HTTP Status Checker ile kontrol edin.
• Beklenen sonuç — Durum satırında HTTP/1.1 200 OK yazmalıdır.
• Başarısızlık yorumu — Hâlâ 403 alınması, güvenlik duvarı/WAF kuralının gerçekten güncellenmediği veya yanlış IP aralığını izin listesine aldığınız anlamına gelir. 403 yerine 401 alınması, engeli bir kimlik doğrulama duvarıyla değiştirdiğiniz anlamına gelir; bu yolu ayrıca kontrol edin.
• İzleme aralığı — Anında; kural değişikliği etkinleşir etkinleşmez sunucu yanıt verir.
• Geri alma tetikleyicisi — Yolu açmak gizli tutmayı amaçladığınız içeriği açığa çıkarıyorsa engeli geri koyun ve bunun yerine doğrulanmış Googlebot’u daha dar kapsamlı bir kuralda IP/reverse-DNS aracılığıyla izin listesine alın.

Test 2 — Google artık sayfaya erişebildiğini doğruluyor

• Çalıştırılacak test — Etkilenen URL üzerinde Google Search Console’da URL Inspection → Test live URL çalıştırın.
• Beklenen sonuç — Canlı test başarılı olmalı, sayfa içeriğini göstermeli ve erişim yasağı hatası bildirmemelidir.
• Başarısızlık yorumu — Googlebot user-agent isteği başarılı olduğu hâlde Test live URL hâlâ 403 bildiriyorsa user-agent dizesi yerine özellikle Google’ın yayımlanmış IP aralıklarına uygulanmış bir kuraldan şüphelenin; ikinci bir kural için güvenlik duvarı günlüğünü kontrol edin.
• İzleme aralığı — Düzeltmeden hemen sonra ile birkaç dakika arası.
• Geri alma tetikleyicisi — Yok; bu salt okunur bir testtir. Test 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 — Page Indexing raporundaki 403 durumu temizleniyor

• Çalıştırılacak test — Page Indexing raporundaki “Blocked due to access forbidden (403)” sorunu için Validate Fix kullanın ve sonraki haftalarda grup sayısını izleyin (bkz. How to Measure sekmesi).
• Beklenen sonuç — URL 403 grubundan çıkar ve daha önce dizine eklenmişse Google artık 200 döndüren sayfayı yeniden taradıkça zamanla dizinde yeniden görünür.
• Başarısızlık yorumu — Yeniden dizine ekleme otomatik ancak anlık değildir; yavaş doğrulamayı yeni bir hata olarak yorumlamayın. 403 grubundaki sayı birkaç hafta sonra düşme eğiliminde değilse düzeltmenin hâlâ etkin olduğunu doğrulamak için Test 1’i yeniden çalıştırın. CDN önbelleği veya Googlebot IP aralığı güncellemesi engeli fark ettirmeden yeniden ortaya çıkarabilir.
• İzleme aralığı — 403 grubu sayısıyla izlenen birkaç gün ile birkaç hafta arası.
• Geri alma tetikleyicisi — Kuralın kendisini yalnızca Test 1 yeniden başarısız olmaya başlarsa gözden geçirin; Page Indexing raporunun zamanlamasının peşine düşmeyin.

Zaman ayırmaya değer kaynaklar

Resmî

• Page Indexing report (Google) — 403 ve 401 girişlerinin kelimesi kelimesine metni.
• How HTTP status codes affect Google Search (Google) — 4xx yanıtlarının nasıl ele alındığı ve hız sınırlaması için 401/403 kullanmama kuralı.
• Verifying Googlebot (Google) — reverse DNS ve yayımlanmış IP aralıkları.
• Don’t 404 my yum (Google, 2023) — Googlebot’u yavaşlatmak için 403/404 kullanmayın.

İlgili yazılarım

• The Beginner’s Guide to Technical SEO — bunun gibi tarama erişimi sorunlarının genel çerçevedeki yeri.
• Robots.txt and SEO: Everything You Need to Know — sayfaların taramaya istemeden kapatılmasının diğer yaygın yolu.

Başkalarından

• r/TechSEO — Googlebot’un CDN tarafından engellendiği konular dahil tarama/dizin hata ayıklama topluluğu.
• Google warns against using 403 or 404 status codes for Googlebot crawl-rate limiting (Search Engine Land) — Gary Illyes’in “Don’t 404 my yum” yönlendirmesi ve bunun yerine ne kullanılacağına (429/503) ilişkin haber.
• Google: Don’t use 403/400 error responses for rate-limiting Googlebot (Search Engine Journal) — aynı Illyes gönderisinin ek bağlamla SEJ tarafından aktarılması.
• Most common reason for blocking Googlebot is firewalls/CDNs (Search Engine Roundtable) — Google Search Relations’ın Googlebot engellerinin büyük çoğunluğunun istenmeyen CDN/güvenlik duvarı kurallarından kaynaklandığını açıklaması.
• Bots that impersonate Googlebot (johnmu.com) — John Mueller’in yalnızca user-agent dizesine güvenmek yerine izin listesine almadan önce Googlebot’u reverse DNS ile doğrulamanız gerektiğine ilişkin açıklaması.
• How to fix “Blocked due to access forbidden (403)” (Onely) — WAF/CDN ayrıntıları ve tanıla → düzelt döngüsünü kapsayan uygulayıcı rehberi.

Değişiklik günlüğü