Search Console “Başka Bir 4xx Sorunu Nedeniyle Engellendi” Ne Demek?

“Başka bir 4xx sorunu nedeniyle engellendi” Search Console’da ne demek?

“Başka bir 4xx sorunu nedeniyle engellendi” (İngilizce arayüzde Blocked due to other 4xx issue), Search Console Sayfa dizine ekleme raporunda görünen bir durumdur. Google adresi istedi, sunucunuz da 401, 403 veya 404 gibi ayrı etiketi olmayan bir 4xx istemci hatası döndürdü. Google bu durumdaki adresi dizine eklemez.

Resmi yardım sayfası bu durumu bir “diğer” kutusu gibi tanımlar. Sayfa dizine ekleme raporu yardım sayfasına göre sunucu, orada açıklanan hiçbir sorun türünün kapsamına girmeyen bir 4xx hatasıyla karşılaşmıştır. Yani etiket bir teşhis değil, bir işarettir: bir 4xx yanıtı oluştu ve rapor bunun adını size söyleyemiyor.

Sonuç net. Google Search Central belgeleri, 4xx durum kodu döndüren adreslerin dizine eklenmediğini söyler. Üstelik dizinde olan bir adres 4xx döndürmeye başlarsa Google onu dizinden çıkarır. Dolayısıyla asıl soru şudur: bu adres var olmalı ve dizine girmeli mi?

Bu rehber yalnızca bu etiketi ele alıyor. Genel tabloyu görmek için dizine eklenmeyen sayfaları bulma rehberimizi okuyabilirsiniz. Ayrıca komşu etiketleri 401 hatası, 403 ve WAF kuralları ve soft 404 yazılarımızda anlattık, bu yüzden burada tekrar etmiyoruz.

Hangi 4xx yanıtları bu etiketin altına düşer?

Search Console bazı istemci hatalarını kendi adlarıyla listeler. Geriye kalanlar ise “diğer” kutusuna düşer. Yani 401, 403 ve 404 dışındaki 4xx yanıtları bu etiketi alır. Soft 404 sayfalarının da ayrı bir etiketi olduğunu unutmayın.

Yardım sayfası, bu “diğer” kutusu için kod kod bir liste yayımlamıyor. Resmi belgelerde açık bir ifade bulamadık; bu yüzden 400 ya da 405 gibi belirli bir kodun hep burada çıkacağını iddia etmiyoruz. Bunun yerine kendi adresinizin gerçek kodunu nasıl bulacağınızı gösteriyoruz.

Başka bir 4xx sorunu nedeniyle engellendi gerçek bir sorun mu, görmezden gelebilir misiniz?

Bu, adrese bağlıdır. Adres zaten ortadan kalkmalıysa durum doğrudur ve dokunmanız gerekmez. Adres arama sonuçlarında görünmesini istediğiniz bir sayfaysa gerçek bir sorun vardır ve düzeltmeniz gerekir.

Önce örnek adresleri iki gruba ayırın. Birinci grupta var olmaması gereken adresler yer alır: eski test sayfaları, kırık bağlantılar ve botların ürettiği çöp adresler. İkinci grupta ise sıralamak istediğiniz sayfalar yer alır.

• Birinci grup: yanıtın bilinçli olduğunu doğrulayın, sonra bu adreslere hâlâ giden iç bağlantıları ve site haritası kayıtlarını temizleyin.
• İkinci grup: gerçek durum kodunu bulun, nedeni düzeltin ve doğrulama isteyin.
• Karışık işaretler: normal bir sayfa burada görünüyorsa suçu Google’da değil, bir sunucu kuralında, güvenlik duvarında ya da eklentide arayın.

Raporda bir de Kaynak sütunu var. Sorunun sitenizden mi yoksa Google sistemlerinden mi geldiğini gösterir. Bu durumda neden neredeyse her zaman sizin tarafınızdadır, çünkü etiket sunucunuzun ne döndürdüğünü anlatır.

Google 4xx yanıtlarına genel olarak nasıl davranır?

Google 4xx kodlarının neredeyse hepsine aynı davranır. HTTP durum kodu belgesi, 429 dışındaki her 4xx hatasının, içeriğin var olmadığını bir sonraki işleme sistemine bildirdiğini söyler. Yani kodun tam numarası dizine ekleme sonucunu pek değiştirmez.

Yine de rapor etiketi önemlidir. Çünkü hangi tür yanıtı aramanız gerektiğini söyler. Örneğin 403 erişim kurallarına, 404 eksik sayfaya, bu “diğer” etiketi ise daha seyrek bir şeye işaret eder.

429 kodu istisnadır. Google bu kodu sunucunun aşırı yüklendiği sinyali sayar ve sunucu hatası gibi ele alır. Dolayısıyla 429 normalde raporun başka bir bölümüne düşer, bu etikete değil.

Bu ayrım size önceliklendirme konusunda yardım eder. Örneklerde yalnızca tuhaf adresler görüyorsanız neden büyük olasılıkla zararsızdır. En iyi açılış sayfalarınızı görüyorsanız, taramayı ve dizine eklemeyi engelleyen bir erişim ya da yapılandırma sorununuz var demektir.

Başka bir 4xx sorunu nedeniyle engellendi durumuna ne yol açar?

Nedenleri birkaç aileye ayırabiliriz. Bazıları zararsızdır, bazıları ise trafik kaybettirir. Aşağıdaki tablo ilk kontrol ettiğimiz noktaları gösteriyor; sonraki bölümler her aileyi ayrıca açıyor.

Orta sütunun yaygın davranışı anlattığını, bir söz vermediğini unutmayın. Hangi yanıtın döneceğine sizin yazılım yığınınız karar verir. Bu nedenle bir şeyi değiştirmeden önce gerçek kodu doğrulayın.

Bozuk ya da parametreli adresler bu durumu tetikler mi?

Evet, tetikleyebilir. Sunucular bir istek geçersiz göründüğü için istemci hatası döndürür. Örneğin bozuk kodlama, bağlantının sonuna yapışmış fazladan karakterler ya da alışılmadık sorgu dizeleri tipik tetikleyicilerdir. Sonuçta Googlebot, hiçbir insanın ziyaret etmediği bir adres için 4xx alabilir.

Bu adresler nereden gelir? Genellikle dört yerden:

• Yazım hatası içeren ya da izleme parçalarını taşıyan iç bağlantılardan.
• Hiç elden geçirmediğiniz eski site haritası kayıtlarından.
• Adresinizi kesen ya da uzatan dış sitelerin bağlantılarından.
• Sonsuz parametre birleşimi üreten filtrelerden ya da arama sayfalarından.

Her kaynağın çaresi farklıdır. İç bağlantıları kendiniz düzeltirsiniz. Dış bağlantılarda ise temiz adrese yönlendirme çoğu zaman yeter. Sonsuz parametre birleşimleri için faceted navigation, canonical ve robots.txt rehberimiz tarayıcıları nasıl odakta tutacağınızı anlatıyor.

Örnekler rastgele çöp gibi görünüyorsa tanınmayan spam URL’lerin 404 olarak görünmesi yazımıza bakın. Mantık aynıdır: her çöp adresin peşine düşmeyin, ama hiçbirinin site haritanızda ya da iç bağlantılarınızda yer almadığından emin olun.

Güvenlik duvarı ya da sunucu kuralı yalnızca Googlebot’a 4xx döndürebilir mi?

Evet. Güvenlik eklentileri, WAF (web uygulaması güvenlik duvarı) ve CDN kuralları tarayıcı robotlarına ziyaretçilerden farklı davranabilir. Sonuçta sayfa sizin tarayıcınızda sorunsuz açılırken Googlebot hata alır. Önemli sayfaların bu etikette görünmesinin en sık nedenlerinden biri budur.

Tipik kural türleri arasında istek sınırları, kullanıcı aracısı filtreleri, ülke filtreleri ve doğrulama sayfaları var. Örneğin bilinmeyen botları engelleyen bir kural, listesi eskidiyse Googlebot’u da yakalayabilir. Aynı şekilde barındırma sağlayıcınız size haber vermeden koruyucu bir kural seti açmış olabilir.

1. Barındırma sağlayıcınıza ya da güvenlik eklentisinin üreticisine etkilenen adreslerde hangi kuralların çalıştığını sorun.
2. Sunucu kayıtlarında Googlebot isteklerini bulun ve her birinin aldığı durum kodunu not edin.
3. Bu satırları aynı adreslere gelen normal ziyaretçi istekleriyle karşılaştırın.
4. Gerçek Googlebot isteklerinin geçmesi için kuralı düzeltin.

Doğrulama adımında dikkatli olun. Googlebot kullanıcı aracısını herkes taklit edebilir, bu yüzden yalnızca ada bakarak izin vermeyin. Google tarayıcılarını doğrulama yöntemini belgelemiştir; bir kuralı gevşetmeden önce o yöntemi kullanın. Bu kuralların işleyişini ModSecurity ve WAF rehberimizde bulabilirsiniz.

İstek yöntemi sayfa dizine ekleme raporundaki 4xx için önemli mi?

Önemli olabilir. Tarayıcı robotları sayfaları normalde düz bir okuma isteğiyle alır. Form işleyicileri ya da uygulama arayüzleri gibi bazı uç noktalar ise yalnızca başka istek türlerini kabul eder. Böyle bir uç nokta normal bir sayfa isteğine istemci hatasıyla yanıt verebilir ve bu yanıt burada raporlanabilir.

Bu sanıldığından sık olur. Bir form eylemine, sepet yardımcısına ya da geri çağırma adresine giden bağlantı bazen bir şablona kaçar. Ardından Googlebot bu bağlantıyı izler, ret alır ve durumu raporlar.

• Önce bağlantıyı üreten şablonu ya da menüyü bulun.
• Ardından bağlantıyı gerçek bir sayfa adresiyle değiştirin ya da kaldırın.
• Uç nokta kalmak zorundaysa onu gezinme alanından ve site haritasından uzak tutun.

Belirli bir yöntem hatasını bu etikete bağlayan resmi bir Google ifadesi gösteremiyoruz. Bu yüzden bu bölümü pratik bir ipucu sayın ve her zaman aşağıda anlattığımız canlı testle doğrulayın.

Bilinçli bir 410 “gitti” yanıtı bu etikette çıkar mı?

Resmi belgelerde 410’u bu kutuya ya da 404 kutusuna yerleştiren açık bir cümle bulamadık. Bu yüzden ikisinden birini kesin diye yazmıyoruz. Söyleyebileceğimiz şey Google’ın 4xx kodlarına genel tutumudur: belgeye göre 429 dışındakilerin hepsi aynı işlenir ve içeriğin var olmadığı sinyali olarak ele alınır.

Dolayısıyla pratik tavsiye etikete bağlı değildir. İçeriği bilerek kaldırdıysanız ve yerine geçecek bir sayfa yoksa “gitti” ya da “bulunamadı” yanıtı meşru bir cevaptır. Bırakın, ama o adrese giden tüm bağlantıları kaldırın.

Yerine geçen bir sayfa varsa eski adresi en yakın eşleşmeye yönlendirin. Stokta olmayan ürün sayfaları ve 404, 410, 301 kararı yazımız bu kararı mağazalar için adım adım anlatıyor; aynı mantık her sayfa türünde işler.

Bir şeyi de aklınızda tutun: silinen bir sayfa site haritanızda kalmamalıdır. Aksi halde hata döndüren adresleri listeleyen bir harita çelişkili sinyaller verir ve raporu kalabalıklaştırır.

Etiketin ardındaki gerçek durum kodunu nasıl bulursunuz?

URL Denetleme aracını kullanın. Raporu açın, bir örnek adresin yanındaki inceleme simgesine tıklayın ve tarama ile dizine ekleme ayrıntılarını okuyun. URL Denetleme yardım sayfası, aracın dizine eklenmiş sürümü gösterdiğini ve canlı test çalıştırmanıza izin verdiğini anlatır.

1. Önce Sayfa dizine ekleme raporunu açın ve “Blocked due to other 4xx issue” satırını seçin.
2. Ardından listeden bir örnek adres seçin ve inceleme ayrıntılarını açın.
3. Sayfa getirme durumuna ve son tarama tarihine bakın.
4. Sonra canlı testi çalıştırın; adresin şu anda nasıl davrandığını görürsünüz.
5. Son olarak taranan sayfa görünümünü ve “daha fazla bilgi” bölümünü açıp HTTP üstbilgilerini okuyun.

Ancak bir sınır var. Yardım sayfası üstbilgi görünümünü belgeliyor, ama ana raporun sayısal kodu tam olarak nasıl gösterdiğini anlatmıyor. Bu yüzden kodu ikinci bir yöntemle doğrulamanızı öneriyoruz; sonraki bölüm bunu gösteriyor.

Ayrıca menü adları zamanla değişebilir. Arayüzünüz farklı görünüyorsa belirli bir düğme metni aramak yerine, benzer inceleme ve canlı test seçeneklerini arayın.

Adresi Search Console dışında nasıl test edersiniz?

İkinci bir görüş ucuz ve hızlıdır. Rapor gerçeğin gerisinde kalabildiği için yeni bir kontrol, sunucunuzun bugün ne yaptığını gösterir. Aşağıdaki yöntemlerden en az ikisini kullanın.

• Yönlendirme denetleyicimiz, herhangi bir adresin durum kodunu ve yönlendirme zincirini gösterir.
• Tarayıcınızın geliştirici araçları, ağ sekmesinde her isteğin durumunu gösterir.
• Sunucu ya da CDN kayıtları Googlebot’un ne aldığını gösterir. Log analizi aracımız bunları okumanıza yardım eder.

Sonuçları karşılaştırın. Yönlendirme denetleyici normal bir sayfa döndürüyor ama kayıtlar Googlebot için hata gösteriyorsa, bir kural tarayıcılara farklı davranıyordur. Tüm yöntemler aynı 4xx kodunu gösteriyorsa neden sayfanın kendisi ya da adresidir.

Raporda geçen adresi birebir test edin; protokolü, www önekini, sondaki eğik çizgiyi ve parametreleri de dahil edin. Adreste küçük bir fark bile yanıtı değiştirebilir.

Başka bir 4xx sorunu nedeniyle engellendi hatasını adım adım nasıl düzeltirsiniz?

Her seferinde aynı sırayı izleyin. Aksi halde nedeni bilmeden kuralları değiştirebilirsiniz.

1. Örnek adresleri alın ve “var olmalı” ile “var olmamalı” diye ayırın.
2. Her grup için gerçek durum kodunu canlı testle ve ikinci bir araçla bulun.
3. Var olması gereken sayfalarda nedeni düzeltin: bir kural, bir eklenti, bozuk bir şablon ya da yanlış bir adres olabilir.
4. Var olmaması gereken sayfalarda iç bağlantıları ve site haritası kayıtlarını kaldırın, sonra hatayı bırakın ya da yerine geçen sayfaya yönlendirin.
5. Düzelttiğiniz birkaç adreste canlı testi yeniden çalıştırın ve normal yanıtı doğrulayın.
6. Raporda doğrulamayı başlatın ve sonucu izleyin.

Beşinci adımı atlamayın. Doğrulama yalnızca Google’ın görebildiğini kontrol eder; yani sizde çalışan ama Googlebot’ta çalışmayan bir düzeltme yine başarısız olur. Bu nedenle canlı test ve kayıtlar sizin güvenlik ağınızdır.

Çok sayfa yönetiyorsanız her değişikliği belgeleyin. Tarih, kural ve etkilenen kalıp içeren kısa bir not, benzer bir durum sonra çıktığında saatler kazandırır.

Var olmaması gereken adreslerle ne yapmalısınız?

Önce kaldırmayı temiz yapın. Bilinçli bir hata sorun değildir, ama yalnızca hiçbir şey hâlâ ona işaret etmiyorsa. Adresi gezinmenizde, içeriğinizde, site haritanızda ve yapılandırılmış verinizde arayın.

• Eski adrese giden iç bağlantıları kaldırın.
• Adresi tüm XML site haritalarından silin.
• Yakın bir karşılığı varsa kalıcı yönlendirme yapın.
• Karşılığı yoksa hata yanıtını olduğu gibi bırakın.

Yönlendirmeler yeni bir soru doğurur: ne kadar süre kalmalı? 301 yönlendirme ne kadar süre kalmalı yazımız bunu yanıtlıyor. Ayrıca çok sayıda sayfayı aynı anda kaldırıyorsanız 404 yönlendirme eşleştiricimiz eski ve yeni adresleri eşlemenize yardım eder.

Son olarak durumun anında kaybolmasını beklemeyin. Rapor değişmeden önce Google adresi yeniden taramalıdır ve bu, sitenizi ne sıklıkla ziyaret ettiğine bağlıdır.

Düzeltmeyi sayfa dizine ekleme raporunda nasıl doğrularsınız?

Nedeni düzelttikten sonra raporda sorunu açın ve “Düzeltmeyi doğrula” düğmesine tıklayın. Yardım sayfası sonrasında olanları anlatır. Google önce örnek sayfaları kontrol eder. Hata orada sürerse doğrulama durur. Aksi halde “başladı” durumuna geçer ve etkilenen adresleri sıraya alır.

Tek tek adresler şu durumlardan geçer:

• Beklemede: Google adresi henüz kontrol etmedi.
• Geçti: sorun sayfada artık algılanmıyor.
• Başarısız: sorun hâlâ var.
• Diğer: adrese ulaşılamadı ya da öğe artık yok.

Doğrulama başarısız olursa kalan adresleri düzeltin ve yeni bir doğrulama başlatın. Belgeye göre bu, beklemede ya da başarısız işaretli adresleri yeniden kontrol eder. Ayrıca son tarama sütununa bakın: o tarihten sonra yaptığınız düzeltme henüz görünmeyebilir.

Örnek listesi bir örneklemdir, etkilenen her adresi içermeyebilir. Bu yüzden temizlediğiniz bir örnek tüm adreslerin düzeldiğini kanıtlamaz. Gerisini doğrulamak için kayıtları kullanın.

Düzelttikten sonra durum neden raporda kalıyor?

Genellikle Google adresi henüz yeniden taramadığı için. Rapor sunucunuzun şu anki halini değil, son taramayı yansıtır. Bu nedenle doğru bir düzeltme bir süre değişmemiş gibi görünebilir.

Güvenilir bir süre veremiyoruz; resmi belgeler de süre vaat etmiyor. Körü körüne beklemek yerine üç şeyi kontrol edin.

1. Canlı test şu anda normal bir yanıt gösteriyor mu?
2. Siz hâlâ bu adrese site haritanızdan ya da gezinmenizden bağlantı veriyor musunuz, yani Google eski sorunla karşılaşmaya devam ediyor mu?
3. Kayıtlar düzeltmenizden sonra Googlebot ziyaretlerini ve aldıkları durumu gösteriyor mu?

Üçü de sağlıklıysa rapor yetişecektir. Kayıtlar Googlebot için hâlâ hata gösteriyorsa düzeltme eksiktir. Bu durumda güvenlik duvarı ve eklenti kontrollerine geri dönün.

Raporu “sıfırlamak” için yeni mülk açmaktan ya da adresleri çoğaltmaktan kaçının. Bu nedeni çözmez, üstelik verilerinizi okumayı zorlaştırır.

Özel karakterler, alan adları ve yönlendirmeler 4xx üretir mi?

Üretebilir. Latin olmayan harf içeren adresler doğru kodlanmalıdır. Kodlaması bozuk bir bağlantı geçersiz istek yanıtı verebilirken doğru biçimi çalışır. Türkçe karakterli alan adı, IDN ve Punycode rehberimiz bu adreslerin nasıl çalıştığını ve neye bakacağınızı anlatıyor.

Yönlendirmeler de sorun çıkarabilir. Tarayıcıları farklı bir ana makineye, korumalı bir alana ya da silinen bir sayfaya gönderen yönlendirme hatayla biter. Dolayısıyla siz son adrese hiç bağlantı vermemiş olsanız bile ilk adres raporlanabilir.

• Her yönlendirmenin normal yanıt veren bir sayfada bittiğini kontrol edin.
• Uzun yönlendirme zincirlerinden kaçının; doğrudan yönlendirme daha temizdir.
• Sondaki eğik çizgili ve çizgisiz sürümleri ayrı ayrı test edin.

Bu küçük ayrıntılar, bir adresin tarayıcıda sorunsuz görünmesinin birçok örneğini açıklar. Tarayıcı yönlendirmeleri izler ve bazı hataları sessizce düzeltir. Googlebot ise aldığını olduğu gibi raporlar.

Bu durumu düzeltirken nelerden kaçınmalısınız?

Bazı kestirme yollar işleri kötüleştirir. Tablo en yaygın olanları ve her birinin neden işe yaramadığını listeliyor.

Bunun yerine temiz ve dürüst yanıtları hedefleyin. Var olan sayfa normal yanıt döndürür. Kalkmış sayfa hata ya da yönlendirme döndürür. robots.txt tarafında yardım için sık yapılan robots.txt hataları yazımıza göz atın.

Hangi adresleri önce ele almalısınız?

Her örnek adres aynı önceliği taşımaz. Bu yüzden önce işe etkisi yüksek olanlara bakın. Süre kısıtlıysa gereksiz zaman harcamamak için bir sıralama yapın.

1. Site haritanızda yer alan adresler: bunları Google’a kendiniz önerdiniz, dolayısıyla hata döndürmeleri çelişkilidir.
2. Menüden, alt bilgiden ya da ana sayfadan bağlantı alan adresler: çok sayıda sayfa bunlara link verir.
3. Satış, form ya da iletişim gibi dönüşüm sayfaları: bir hata doğrudan gelir kaybına yol açar.
4. Dış sitelerden bağlantı alan adresler: değer taşıyan bağlantıları boşa harcamamak için yönlendirme düşünün.
5. Geriye kalan çöp adresler: bunları en sona bırakın ve yalnızca kaynaklarını temizleyin.

Bu sıralama, yüzlerce adresli bir listede bile net bir plan çıkarmanızı sağlar. Üstelik önce küçük ama önemli bir grubu düzelttiğiniz için doğrulama isteğiniz de daha hızlı sonuç verir.

Örnek senaryo: güvenlik eklentisi Googlebot’u yavaşlatırsa ne olur?

Aşağıdaki, gerçek bir müşteri vakası değil, örnek bir senaryodur. Bir kurumsal sitede güvenlik eklentisi, kısa sürede çok istek gönderen ziyaretçileri geçici olarak engelliyor. Tarama yoğun olduğu bir günde Googlebot da bu sınıra takılıyor.

Sonuçta ürün kategori sayfaları Google tarafında bir istemci hatasıyla karşılaşıyor. Siz sayfayı tarayıcıda sorunsuz açıyorsunuz, çünkü sizin istek hızınız düşük. Birkaç gün sonra Search Console’da etkilenen adresler bu etikette birikiyor.

• Belirti: önemli sayfalar raporda çıkıyor, ama tarayıcıda normal açılıyor.
• İpucu: sunucu kayıtlarında Googlebot isteklerinin bir kısmı hata alıyor, ziyaretçi istekleri almıyor.
• Çözüm yönü: eklentinin istek sınırını ve istisna listesini gözden geçirmek, gerçek Googlebot için sınırı gevşetmek.

Burada hızlı hareket etmek önemlidir. Ancak her engeli kaldırmak da çözüm değildir; çünkü eklenti gerçek saldırılara karşı da sizi korur. Doğru yaklaşım, kuralı daraltmak ve gerçek Googlebot’a yer açmaktır.

401, 403, 404 ve soft 404 ile bu etiketi nasıl ayırt edersiniz?

Karışıklığı önlemek için kısa bir karar yolu işe yarar. Önce URL Denetleme ile yanıtı okuyun, sonra aşağıdaki sıraya bakın.

• Kimlik doğrulama istiyorsa konu 401’dir; ayrı etiketi vardır.
• Sunucu isteği anlayıp reddediyorsa konu 403’tür; ayrı etiketi vardır.
• Sayfa bulunamıyorsa konu 404’tür; ayrı etiketi vardır.
• Sayfa hata gibi görünüp normal yanıt veriyorsa konu soft 404’tür; ayrı etiketi vardır.
• Bunların hiçbiri değilse etiket çoğunlukla “diğer” kutusunu işaret eder.

Ancak raporun etiketi ile sunucunun anlık yanıtı her zaman aynı olmayabilir. Rapor son taramayı gösterir, canlı test ise şu anı. Bu yüzden ikisi arasında fark görürseniz sunucunuzun yanıtı bu arada değişmiş olabilir; yeni yanıtı esas alın.

Bu durumun geri gelmesini nasıl önlersiniz?

Önleme çoğunlukla rutindir. Sayfa dizine ekleme raporunu düzenli aralıklarla kontrol edin ve bir kural değişikliği çok sayıda sayfayı etkilemeden önce bu “diğer” etiketine erken bakın.

• Her güncellemeden sonra güvenlik duvarı ve güvenlik eklentisi kurallarını gözden geçirin.
• Kendi sitenizi tarayın ve yanıt kodlarını site haritanızla karşılaştırın.
• Hata alan Googlebot istekleri için log analizi yapın.
• Sayfa kaldırdığınızda ya da yeniden adlandırdığınızda bir yönlendirme haritası tutun.

Ayrıca yeni şablonları yayından önce test edin. Alışılmadık bir uç noktaya bağlanan menü ya da alt bilgi sorunu her sayfaya çoğaltır. Bu yüzden test kopyasında yapılan tek bir kontrol sonradan çok temizlik işi kazandırır.

Son olarak ani artışları bir sinyal sayın. Etkilenen adres sayısındaki ani sıçrama genellikle bir yayından, eklenti güncellemesinden ya da barındırma değişikliğinden sonra gelir. Sıçramanın tarihini değişiklik geçmişinizle karşılaştırın.

Ne zaman bir uzmandan destek almalısınız?

Etkilenen adresler arasında önemli sayfalar varsa ve nedeni bir iki saatte bulamıyorsanız destek alın. Sunucu kuralları, CDN ayarları ve uygulama kodu çoğu zaman birbiriyle etkileşir. İkinci bir göz zaman kazandırır.

Talha Aslan ve ekibi olarak 2012’den beri sahadayız ve Google Partner’ız. Kayıtları okuyor, canlı yanıtları test ediyor ve kuralları geliştiricinizle ya da barındırma sağlayıcınızla birlikte kontrol ediyoruz. SEO danışmanlığı hizmetimiz tam olarak bu tür teknik teşhisi kapsar.

Bir durumun belirli bir tarihte kaybolacağını vaat etmiyoruz, çünkü yeniden tarama Google’ın elindedir. Bizim yapabileceğimiz, nedeni bulmak, temiz biçimde düzeltmek ve sunucunun artık doğru yanıt verdiğine dair kanıt sunmaktır.

Bu yazı genel bilgi içindir, sitenizi kapsayan bir garanti değildir. Search Console’daki etiketler ve menüler değişebilir; güncel ifadeler için bağlantı verdiğimiz resmi sayfalara bakın.