401 Unauthorized Hatası Nedir? Nedenleri ve Çözümü

401 Unauthorized hatası nedir?

401 Unauthorized hatası, sunucunun isteğinizi geçerli kimlik bilgisi bulamadığı için reddettiğini bildiren HTTP durum kodudur. Sunucu ya hiç kullanıcı adı ve parola görmemiştir ya da gönderdiğiniz bilgiyi tanımamıştır. Yanıt çoğu zaman bir WWW-Authenticate başlığı taşır ve istemciye hangi doğrulama yöntemini beklediğinizi söyler.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yazıdaki teknik anlatım RFC 9110, MDN, Google Search Central ve Apache gibi resmi belgelere dayanır. Amacımız, ekranda bu kodu gördüğünüzde kimin neyi düzelteceğini hızla ayırt etmenizi sağlamaktır.

Kod, MDN belgesindeki tanıma göre isteğin hedef kaynak için geçerli kimlik doğrulama bilgisinden yoksun olduğunu gösterir. Adı "Unauthorized" olsa da anlamı çoğunlukla "yetkisiz" değil, "kimliğinizi doğrulayamadım" demektir. Bu ayrım, 401 ile 403 arasındaki farkı anlamanın anahtarıdır.

401 ile 403 arasındaki fark nedir?

401, sunucunun sizi tanımadığı ya da kimlik bilgisini doğrulayamadığı durumdur. 403 ise sunucunun isteği anladığı, ancak yine de yerine getirmeyi reddettiği durumdur. Yani 401'de çözüm genellikle "giriş yapın ya da doğru bilgiyi gönderin", 403'te ise "yetkiniz yok, kural ya da izin değişmeli" olur.

Aşağıdaki tablo, hata kodlarını sorumlu tarafa göre ayırır. RFC 9110'a göre sunucu bir 401 yanıtına WWW-Authenticate başlığı eklemek zorundadır, 403 yanıtında ise böyle bir zorunluluk yoktur.

403 ile karşılaşıyorsanız sorun büyük olasılıkla güvenlik duvarı ya da izinlerdedir. Bu yazıda onu anlatmıyoruz; ModSecurity ve 403 hatası rehberimize bakın.

401 Unauthorized hatasını kim çözmeli: ziyaretçi, site sahibi mi, sunucu yöneticisi mi?

Önce sorumluyu belirlemek, saatlerce yanlış yerde aramanızı önler. Hatayı gören kişi çoğu zaman çözümü uygulayacak kişi değildir. Bu nedenle ilk soru her zaman şudur: birisi bu sayfaya bilerek mi şifre koydu?

• Ziyaretçi: Doğru kullanıcı adı ve parolayı girer, tarayıcıdaki eski oturumu ya da kayıtlı parolayı temizler.
• Site sahibi: Korumanın hangi dizinde, hangi uygulamada ya da hangi entegrasyonda olduğunu bulur ve gerekirse kaldırır.
• Sunucu yöneticisi: Apache ya da Nginx yapılandırmasındaki kimlik doğrulama kurallarını, parola dosyasını ve proxy ayarlarını inceler.

Örneğin müşteriniz "sitemiz şifre soruyor" derse, önce staging için konan bir korumanın canlı siteye taşınıp taşınmadığına bakın. Yeni bir kullanıcı açmadan önce bu tek kontrol çoğu vakayı bitirir.

Paylaşımlı hosting kullanıyorsanız sunucu düzeyindeki ayarlara erişemezsiniz. Bu durumda sorunu kanıtlarla birlikte sağlayıcınıza iletmeniz en hızlı yoldur.

WWW-Authenticate başlığı ne anlatır?

WWW-Authenticate, sunucunun 401 yanıtıyla birlikte gönderdiği ve "şu yöntemle kimliğini kanıtla" diyen başlıktır. Başlık doğrulama şemasını ve çoğu zaman bir realm adını içerir. Tarayıcı bu başlığı görünce kullanıcı adı ve parola penceresini açar.

Örnek bir yanıt şöyle görünür:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Staging"
Content-Type: text/html

Burada "Basic" şemayı, "Staging" ise ekranda gösterilen bölge adını belirtir. API tarafında aynı başlık "Bearer" gibi başka bir şemayı da bildirebilir. Nitekim MDN'nin örneği Bearer şemasını gösterir.

İstemci doğru bilgiyle yeniden denerken Authorization başlığını kullanır. Sunucu bu başlığı kabul ederse 200 döner, etmezse yeniden 401 verir. Sorun giderirken bu iki başlığı birlikte okumak, hatanın hangi tarafta olduğunu hemen gösterir.

401 Unauthorized hatası neden oluşur?

Sebeplerin çoğu birkaç gruba girer. Hangi gruba girdiğinizi anlamak teşhis süresini kısaltır.

• Dizin ya da site Basic Auth ile korunuyordur ve kimlik bilgisi girilmemiştir.
• Kullanıcı adı ya da parola yanlış yazılmıştır veya parola dosyası güncellenmemiştir.
• API isteğinde token eksiktir, süresi dolmuştur ya da yanlış şemayla gönderilmiştir.
• Oturum çerezi kaybolmuş ya da sunucu oturumu bitmiştir.
• Ters vekil (reverse proxy) ya da CDN, Authorization başlığını arka sunucuya iletmiyordur.
• Staging korumasını canlıya taşımışsınızdır.

Ayrıca bir güvenlik eklentisi ya da hosting paneli, belirli yolları (örneğin yönetim ya da API yolu) ek bir parolayla koruyor olabilir. Bu tür korumaları genelde birisi bilerek açar, ancak aradan zaman geçince herkes unutur.

Kısacası 401 bir arıza değil, çoğu zaman bir kuralın çalıştığını gösterir. Asıl soru, o kuralın orada olması gerekip gerekmediğidir.

401 hatasını teşhis etmek için hangi sırayı izlemelisiniz?

Rastgele ayar değiştirmek yerine sabit bir sıra izleyin. Böylece her adım bir olasılığı eler.

1. Adresi gizli pencerede açın. Eski oturum ya da kayıtlı parola kaynaklıysa hata kaybolur.
2. Başlıkları görmek için komut satırından istek atın.
3. WWW-Authenticate değerine bakın ve şemayı not edin.
4. Aynı adresi farklı bir ağdan deneyin; kural yalnızca belirli IP adreslerini hedefliyor olabilir.
5. Sunucu hata günlüğünü okuyun ve kimlik doğrulama satırını bulun.
6. Son değişikliği düşünün: yeni eklenti, panel ayarı ya da dağıtım olmuş mu?

Başlıkları görmek için şu komutu kullanabilirsiniz:

curl -I https://example.com/korumali-sayfa/

Çıktıda ilk satır 401 ise ve WWW-Authenticate başlığı varsa, sorun bir kimlik doğrulama kuralındadır. Başlık yoksa istek büyük olasılıkla bir proxy ya da uygulama katmanında yeniden yazılıyordur.

Sunucu günlüklerine erişiminiz yoksa bu adımı sağlayıcınıza bırakın. Günlük satırı, hatanın hangi kuraldan geldiğini genellikle açıkça gösterir; bu yüzden sağlayıcıdan yalnızca ilgili saat aralığını istemeniz yeterlidir.

Site ziyaretçisiyseniz 401 Unauthorized hatasında ne yapmalısınız?

Ziyaretçi olarak yapabileceğiniz şeyler sınırlıdır, ama çoğu zaman yeterlidir. Önce adresi doğru yazdığınızdan emin olun, çünkü yanlış alt dizin bazen yönetim alanına götürür.

• Sayfa size özel bir alansa kullanıcı adı ve parolayı yeniden girin.
• Tarayıcının kayıtlı parolasını ve ilgili site verilerini silin, ardından yeniden deneyin.
• Başka bir tarayıcı ya da gizli pencere kullanın.
• Parolayı site sahibinden isteyin; tahmin etmeye çalışmayın.

Herkese açık olması gereken bir sayfada bu hatayı görüyorsanız sorun sizde değildir. Bu durumda site sahibine sayfa adresini ve hatanın saatini iletin, böylece teşhis kısalır.

Ayrıca halka açık bir sayfada 401 görmek, sitenin yanlış yapılandırıldığının işaretidir. Ziyaretçiler aynı hatayı gördüğünde siteyi terk eder, arama motorları da sayfayı okuyamaz.

Basic Auth ve .htpasswd nasıl çalışır?

Basic Auth, HTTP'nin en basit kimlik doğrulama şemasıdır. İstemci kullanıcı adı ve parolayı birleştirir, base64 ile kodlar ve Authorization başlığında gönderir. Base64 şifreleme değildir; yalnızca bir kodlamadır.

Bu yüzden Apache belgeleri, Basic kimlik doğrulamanın parolayı şifrelemeden sunucuya yolladığını söyler ve çok hassas veri için mod_ssl ile birlikte kullanmanızı önerir. Yani Basic Auth için HTTPS şarttır; sertifika konusu için SSL sertifikası rehberimize göz atın.

.htpasswd dosyası, her satırında bir kullanıcı adı ve o kullanıcının parola özetini (hash) tutan düz metin dosyasıdır. Dosya parolanın kendisini değil, özetini tutar. Apache belgeleri bu dosyanın web üzerinden erişilemeyen bir dizinde durmasını önerir.

Pratik bir sonuç: dosyayı public_html içine koyarsanız, yanlış yapılandırmada herkes onu indirebilir. Bu nedenle ev dizininizde, web kökünün dışında tutun.

Apache'de .htpasswd ile dizin şifrelemeyi nasıl yaparsınız?

Önce parola dosyasını web kökünün dışında oluşturun. Komut parolayı sizden ister; parolayı komut satırına yazmanız gerekmez.

htpasswd -c /home/kullanici/.htpasswd ornek_kullanici

İkinci kullanıcıyı eklerken -c bayrağını kullanmayın; aksi halde dosya sıfırlanır. Ardından korumak istediğiniz dizindeki .htaccess dosyasına şu satırları ekleyin:

AuthType Basic
AuthName "Staging"
AuthUserFile "/home/kullanici/.htpasswd"
Require valid-user

Bu dört satır Apache 2.4 belgesindeki örneğin sadeleştirilmiş halidir. Bunun çalışması için sunucu yapılandırmasında AllowOverride AuthConfig açık olmalıdır. Belgeye göre .htaccess kullanımı bu izne bağlıdır; Apache kimlik doğrulama rehberinde ayrıntıları bulabilirsiniz.

Dosya yolunu mutlak yazın ve kullanıcı adının gerçek bir hesapla karışmadığından emin olun. Güçlü bir parola için şifre oluşturucu aracımızı kullanabilirsiniz.

Yapılandırma dosyasını bozmaktan çekiniyorsanız önce yedek alın. Değişiklikten sonra korumasız bir adresi ve korumalı adresi ayrı ayrı deneyin; böylece kuralın yalnızca hedeflediğiniz dizinde çalıştığını görürsünüz.

Nginx'te Basic Auth'u nasıl açarsınız?

Nginx'te aynı işi auth_basic ve auth_basic_user_file yönergeleri görür. Nginx belgesine göre auth_basic, HTTP Basic kimlik doğrulamayı açar ve verdiğiniz metni realm olarak kullanır. auth_basic_user_file ise kullanıcı adı ve parola özetlerini tutan dosyayı gösterir.

location /staging/ {
    auth_basic           "Staging";
    auth_basic_user_file /home/kullanici/.htpasswd;
}

Dosya biçimi Apache ile uyumludur. Belge, htpasswd ya da openssl passwd ile üretilen özetleri desteklediğini yazar. Aynı belge, düz SHA-1 biçiminin zayıf olduğunu da belirtir; bu yüzden modern bir özet algoritması seçin.

Ancak Nginx değişikliklerinde yapılandırmayı sınamadan yeniden yüklemeyin. Bir yazım hatası bütün siteyi düşürebilir.

Bu işi canlı bir sunucuda yapıyorsanız ve emin değilseniz, ya bir test ortamında deneyin ya da hosting sağlayıcınıza bırakın. Çünkü hatalı bir kural, sitenizin tamamını 401 ya da 500 ile kilitleyebilir.

cPanel Dizin Gizliliği ile klasöre nasıl şifre koyarsınız?

cPanel kullanıyorsanız dosya düzenlemeden aynı korumayı Dizin Gizliliği (Directory Privacy) arayüzünden kurabilirsiniz. cPanel belgesine göre arayüz, ilgili klasör için .htaccess ve .htpasswd dosyalarını sizin yerinize değiştirir.

1. cPanel'de Dizin Gizliliği aracını açın.
2. Korumak istediğiniz klasöre gidin.
3. "Bu dizini parola ile koru" seçeneğini işaretleyin ve bir etiket yazın.
4. Yetkili kullanıcıyı ve parolasını ekleyin, ardından kaydedin.

Etiket yalnızca .htaccess içinde bir ad olarak yer alır; klasörün adını değiştirmez. Alt dizinler üst dizinin korumasını devralır.

Önemli bir sınır var: cPanel belgesi bu korumanın FTP, SFTP ve Web Disk üzerinden erişilen dizinleri korumadığını açıkça yazar. Yani bu yalnızca web erişimini kilitler.

Dolayısıyla gizli veriyi yalnızca bu yöntemle kilitlediğiniz bir klasörde tutmayın. Hassas dosyaları web kökünün dışına almak daha güvenlidir.

Basic Auth penceresi neden tekrar tekrar açılıyor?

Doğru parolayı girmenize rağmen pencere geri geliyorsa, sunucu bilgiyi kabul etmiyordur. Bunun birkaç tipik nedeni vardır ve hepsini birkaç dakikada eleyebilirsiniz.

• Parola dosyasındaki özet, girdiğiniz parolayla eşleşmiyor.
• AuthUserFile yolu yanlış ya da sunucu o dosyayı okuyamıyor.
• Ters vekil ya da CDN, Authorization başlığını arka sunucuya iletmiyor.
• Adres www ve www olmayan sürüm ya da http ve https arasında yönleniyor.

Son madde şaşırtıcıdır. Tarayıcı kimlik bilgisini genellikle belirli bir kaynak ve realm için hatırlar. Yönlendirme kaynağı değiştirirse, tarayıcı yeniden sorar. Bu yüzden tek bir kanonik adres kullanmak, hem SEO hem de kullanıcı deneyimi için iyidir.

Ayrıca parolada Türkçe karakter ya da özel simge varsa kodlama farkı yaşanabilir. Teşhis için önce basit bir parolayla deneyin, sonra güçlü parolaya geçin.

Hata günlüğünde "kullanıcı bulunamadı" ile "parola uyuşmuyor" mesajları ayrı satırlar olarak yer alır. Hangisini gördüğünüz, sorunun dosyada mı yoksa parolada mı olduğunu söyler.

WordPress sitenizde 401 hatası neden çıkar?

WordPress'te 401 çoğunlukla çekirdekten değil, çevresindeki katmanlardan gelir. En sık üç kaynak vardır: sunucu düzeyindeki Basic Auth, REST API kimlik doğrulaması ve güvenlik ya da önbellek eklentileri.

Staging sitesini .htpasswd ile koruduysanız, WordPress'in kendi kendine yaptığı istekler de bu duvara çarpabilir. Zamanlanmış görevler ve site sağlığı denetimleri bu istekler arasında yer alır. Bu yüzden korumalı bir staging sitesinde sağlık denetimi uyarısı görmeniz şaşırtıcı değildir.

REST API için WordPress geliştirici belgesi üç yol sayar: nonce ile çerez doğrulaması, Uygulama Parolaları ve eklentiler. Nonce göndermezseniz istek, oturum açmış olsanız bile kimliksiz kalır. Uygulama Parolaları WordPress 5.6'dan beri vardır ve HTTPS üzerinde Basic Auth ile çalışır.

Örneğin bir mobil uygulama ya da otomasyon aracı içerik yayınlayamıyorsa, önce Uygulama Parolasının doğru kullanıcıya ait olup olmadığına bakın. Sonra proxy'nin Authorization başlığını iletip iletmediğini kontrol edin.

Eklenti kaynaklı sorunlarda eklentileri tek tek kapatmak işe yarar. Bunu canlı sitede yapmadan önce yedekleme stratejinizi hazırlayın.

Geliştiriciyseniz 401, 403 ve 404 yanıtlarını nasıl seçersiniz?

Kendi uygulamanızda doğru kodu seçmek, istemci geliştiricilerin ve arama motorlarının sizi doğru anlamasını sağlar. Temel kural, kimliğin eksik olması ile iznin eksik olmasını ayırmaktır.

• İstek hiç kimlik göndermemişse ya da geçersiz kimlik göndermişse 401 verin ve WWW-Authenticate ekleyin.
• Kimlik geçerli ama yetki yetmiyorsa 403 verin.
• Kaynağın varlığını bile gizlemek istiyorsanız 404 verebilirsiniz.

Üçüncü seçenek RFC 9110'da tarif edilen bir yaklaşımdır; bu kodlar arasındaki ayrım için RFC 9110 birincil kaynaktır. Ancak 404 kullanmak hata ayıklamayı zorlaştırır, o yüzden yalnızca gerçekten gizlilik gerekiyorsa seçin.

Bir de tuzak var: giriş sayfasını 200 ile döndürüp içinde "yetkiniz yok" yazmak, arama motorlarına yanlış sinyal verir. Bu hata türü için soft 404 rehberimize göz atın.

Yanıt gövdesine parola, token ya da iç yol bilgisi yazmayın. Hata mesajı kısa ve nötr olsun.

API ve token kaynaklı 401 hatasını nasıl çözersiniz?

API'lerde 401 hemen her zaman "token geçersiz" anlamına gelir. Yazılımcıların en sık karşılaştığı durumlar şunlardır:

• Token süresi dolmuştur ve yenileme akışı çalışmamıştır.
• Authorization başlığı yanlış biçimdedir; örneğin "Bearer" kelimesi unutulmuştur.
• İstek yanlış ortama gitmiştir; test anahtarı canlı uca gönderilmiştir.
• Saat farkı yüzünden imzalı token geçersiz sayılmıştır.
• Ara katman başlığı silmiştir.

Bu durumda yanıtın WWW-Authenticate başlığını okuyun. Birçok API burada hatanın nedenini kısa bir kodla bildirir. Başlık sizi doğru yöne yönlendirir ve tahmin etme ihtiyacını azaltır.

Bununla birlikte 401 ile 403 birbirine karışmasın: token geçerli ama ilgili kaynağa yetkisi yoksa doğru yanıt 403'tür. Kendi API'nizi yazıyorsanız ikisini ayrı tutmak, istemci geliştiricilerin işini çok kolaylaştırır.

Anahtarları kodun içine ya da herkese açık depoya yazmayın. Bunun yerine ortam değişkenleri ya da gizli yönetim aracı kullanın. Genel güvenlik riskleri için OWASP Top 10 yazımıza bakabilirsiniz.

Staging sitesini şifrelemek SEO'yu nasıl etkiler?

Staging sitesine parola koymak, onu arama motorlarından saklamanın en güvenilir yoludur. Google, 401 yanıtı alan sayfanın içeriğini okuyamaz. Search Central belgesine göre Google 429 dışındaki tüm 4xx hatalarına aynı davranır ve içeriğin var olmadığını sonraki sisteme bildirir.

Bu, noindex etiketinden farklı bir mantıktır. Google'ın noindex kuralını görmesi için sayfanın taranabilir olması gerekir; robots.txt ile engellerseniz ya da sayfaya erişemezse kuralı hiç okumaz. Fark için noindex ve robots.txt karşılaştırmamıza bakın.

Pratikte staging için en sağlam düzen şudur: parola ya da IP kısıtı koyun, sitemap'i yayınlamayın ve canlıya geçerken korumayı kaldırmayı kontrol listesine yazın. Çünkü unutulan bir şifre, canlı sitenizi Googlebot'a kapatır.

Tersi de geçerlidir: canlıya taşınan bir noindex etiketi ya da robots.txt kuralı sayfalarınızı arama sonuçlarından düşürebilir. Bu yüzden her yayından sonra ana sayfanın durum kodunu ve etiketlerini kontrol edin. Teknik SEO denetimi için SEO danışmanlığı hizmetimize göz atabilirsiniz.

Staging için Basic Auth mı, IP kısıtı mı, VPN mi seçmelisiniz?

Doğru yöntem, ekibinizin büyüklüğüne ve test akışına bağlıdır. Hiçbiri tek başına mükemmel değildir, bu yüzden kısa bir karşılaştırma işinizi kolaylaştırır.

Küçük bir ekip için Basic Auth ve HTTPS çoğu zaman yeterlidir. Ancak müşteri onayına sunacağınız bir tasarımı paylaşıyorsanız, parolayı e-postayla göndermek yerine ayrı bir kanaldan iletin.

Parola dosyasını ve erişim bilgisini kod deposuna eklemeyin. Test sitesine gerçek müşteri verisi kopyalamak da ayrı bir risktir; mümkünse örnek veriyle çalışın.

Search Console'da 401 sayfa uyarısı ne anlama gelir?

Search Console, Googlebot'un bir sayfada kimlik doğrulama istemiyle karşılaştığını Sayfa Dizine Ekleme raporunda gösterir. Google yardım sayfasına göre "Gönderilen URL yetkisiz istek (401) döndürüyor" uyarısı, sayfanın Googlebot'a bir yetkilendirme isteğiyle kapalı olduğu anlamına gelir.

Çözüm, sayfanın amacına bağlıdır:

• Sayfa herkese açık olmalıysa kimlik doğrulamayı kaldırın.
• Sayfa gerçekten özelse sitemap'ten çıkarın; Search Console'a göndermeyin.
• Googlebot'un girmesini istiyorsanız kimliğini doğrulayarak erişim verin.

Düzeltmeyi yaptıktan sonra URL Denetleme aracında canlı testi çalıştırın ve doğrulama isteği gönderin. Raporu okumayı bilmiyorsanız Search Console rehberimiz ve indekslenmeyen sayfalar yazımız işinizi görür.

Bir noktayı atlamayın: sayfa listede yalnızca "özel olduğu için" görünüyorsa sorun yoktur. Asıl tehlike, indekslenmesini istediğiniz sayfaların bu listede çıkmasıdır.

robots.txt dosyası 401 döndürürse ne olur?

Beklenmedik bir sonuçla karşılaşabilirsiniz. Google belgesine göre Google tarayıcıları, 429 dışındaki tüm 4xx hatalarını geçerli bir robots.txt dosyası yokmuş gibi değerlendirir. Yani robots.txt'niz 401 verirse, Google tarama kısıtı olmadığını varsayar.

Bu, korunması gereken alanları robots.txt ile "gizleme" fikrini tehlikeli kılar. Dosyaya erişemeyen bir tarayıcı bütün kuralları yok sayar. Bu yüzden gizliliği robots.txt'e değil, gerçek bir erişim kontrolüne bırakın.

Ayrıca tersi durumda da yanlış anlama oluşur: robots.txt 5xx döndürürse Google ilk 12 saat taramayı durdurur, sonra son iyi sürümü kullanır. İki durum aynı değildir, o yüzden dosyanın her zaman 200 ile açıldığını doğrulayın.

Dosyayı güvenle hazırlamak için robots.txt oluşturucu aracımızı kullanabilirsiniz. Yaygın hatalar için robots.txt hataları yazımıza bakın.

401 veren sayfalar izleme ve kırık link araçlarını nasıl etkiler?

Korunan bir adres, otomatik araçlar için bir hata gibi görünür. Uptime izleyicileri çoğu zaman 200 dışındaki yanıtları arıza sayar. Sonuç olarak her gece "site çöktü" bildirimi alabilirsiniz, oysa sunucu tam da tasarlandığı gibi çalışıyordur.

Aynı durum kırık link taramasında da yaşanır. Tarayıcı araç, 401 veren bağlantıyı bozuk olarak işaretleyebilir. Bu nedenle sonuçları okurken önce sayfanın bilerek korunup korunmadığını sorun. Kırık link kontrol aracımız bu tür adresleri de listeler.

Siteniz çökmüş gibi görünüyorsa, önce gerçek bir kesinti olup olmadığına bakın. Bunun için site çöktü mü aracını kullanabilirsiniz; araç, adresin dışarıdan nasıl yanıt verdiğini gösterir.

Çözüm basittir: izleme aracına kimlik bilgisi tanımlayın ya da korumalı alanı izleme dışında bırakın. Bu karar, ekibinizin gereksiz alarm yorgunluğuna girmesini önler.

Googlebot'u kimlik doğrulamadan geçirmek güvenli midir?

Bazen gerçekten korunan ama taranması gereken sayfalar olur. Bu durumda Googlebot'a özel erişim vermek mümkündür, fakat dikkatli olmalısınız. Kullanıcı aracısı (user agent) metnine güvenmeyin, çünkü başkası da aynı metni taklit edebilir.

Google belgesi iki doğrulama yolu sunar: ters DNS sorgusuyla alan adını teyit etmek ya da Google'ın yayımladığı IP aralıklarıyla eşleştirmek. Belge, Googlebot'u kimlik doğrulamadan geçirme kararını sizin yerinize vermez; yalnızca isteğin gerçekten Google'dan geldiğini nasıl anlayacağınızı anlatır.

Üstelik çoğu işletme için bu gereksizdir. Kimlik doğrulamanın arkasındaki içerik zaten arama sonuçlarında olmamalıdır. İçeriğin aranabilir olmasını istiyorsanız en temiz çözüm, onu herkese açık bir sayfaya taşımaktır.

Bu tür özel erişim kuralları hatalı yazıldığında siteyi kilitleyebilir ya da yanlış kişilere açabilir. Dolayısıyla emin değilseniz ayarı kendiniz yapmayın.

Ekibiniz ya da müşteriniz 401 bildirdiğinde hangi bilgiyi toplamalısınız?

"Siteye giremiyorum" mesajı tek başına teşhis için yetmez. Birkaç satırlık doğru bilgi, saatler süren yazışmayı önler. Bu yüzden bildirim formunuza ya da destek şablonunuza aşağıdaki alanları ekleyin.

• Tam adres: Hangi sayfada, hangi alt alan adında hata çıktığını gösterir.
• Saat ve tarih: Sunucu günlüğünde ilgili satırı bulmanızı sağlar.
• Ekran görüntüsü: Pencerenin sitenizden mi tarayıcıdan mı geldiğini gösterir.
• Ağ bilgisi: Ofis, ev ya da mobil bağlantı olduğunu söyler.
• Son değişiklik: Yeni eklenti, panel ayarı ya da dağıtım olup olmadığını gösterir.

Teknik biriyle çalışıyorsanız komut satırı çıktısını da isteyin. Yukarıdaki curl komutunun ilk birkaç satırı, durum kodunu ve başlıkları tek seferde verir.

Böylece destek süreci "deneyip görelim" yerine, kanıta dayalı ilerler. Bu alışkanlık ekip içinde de, hosting sağlayıcınızla yazışırken de zaman kazandırır.

Hangi durumda işi hosting sağlayıcınıza bırakmalısınız?

Her 401 sorununu kendiniz çözmek zorunda değilsiniz. Bazı durumlarda doğru karar, destek talebi açmaktır.

• Paylaşımlı hostingdesiniz ve sunucu yapılandırmasına erişiminiz yok.
• Sorun tüm sitede başladı ve son değişikliğin ne olduğunu bilmiyorsunuz.
• Kuralı bir WAF, CDN ya da yük dengeleyici dayatıyor.
• Canlı sunucuda Apache ya da Nginx dosyasını düzenlemekten emin değilsiniz.
• Bir saldırı ya da yetkisiz erişim şüphesi var.

Destek talebinde adresi, hatanın saatini, aldığınız durum kodunu ve WWW-Authenticate başlığını paylaşın. Böylece sağlayıcı sorunu tekrar üretmeden teşhis eder. Hosting seçerken destek kalitesine bakmak için hosting seçimi rehberimizden yararlanın.

Sunucu tarafında bir ayarı bozmak, hatadan daha pahalıya gelir. Bu yüzden emin olmadığınız komutu canlıda denemeyin.

401 Unauthorized hatasını önlemek için kontrol listesi nedir?

Aşağıdaki liste, her yayın öncesinde beş dakikanızı alır ve çoğu sürpriz 401'i engeller.

1. Staging korumasının canlı ortama kopyalanmadığını doğrulayın.
2. Ana sayfa, robots.txt ve sitemap adreslerinin 200 döndürdüğünü test edin.
3. Basic Auth kullanan her yolu bir yerde listeleyin.
4. Parola dosyalarını web kökünün dışında tutun ve yalnızca HTTPS kullanın.
5. API token sürelerini ve yenileme akışını belgeleyin.
6. Search Console raporunu haftalık gözden geçirin.

Ayrıca site hızı ve erişilebilirlik gibi konular da aynı yayın akışında kontrol edilmelidir. Örneğin SSL sorgulama aracımızla sertifikanızı hızlıca sınayabilirsiniz.

Sitenizin teknik altyapısını bir bütün olarak kurmak istiyorsanız web tasarım hizmetimize göz atın. Biz hosting işletmiyoruz; ancak doğru altyapı kararını almanıza yardım edebiliriz.