Yönlendirme Döngüsü Hatası (ERR_TOO_MANY_REDIRECTS) Nasıl Çözülür?

Yönlendirme döngüsü hatası (ERR_TOO_MANY_REDIRECTS) nedir?

Yönlendirme döngüsü hatası, tarayıcının A adresinden B adresine, B adresinden yine A adresine gitmesiyle oluşan sonsuz halkadır. Tarayıcı belli bir denemeden sonra vazgeçer ve Chrome'da ERR_TOO_MANY_REDIRECTS kodunu gösterir. Kaynak çoğunlukla sitenin yönlendirme ayarlarıdır, ziyaretçinin cihazı değildir.

Bir yönlendirme, sunucunun "aradığınız içerik başka bir adreste" demesidir. Sunucu bunu 3xx durum koduyla ve Location başlığıyla bildirir. RFC 9110 bu kodları tanımlar ve istemcilerin döngüsel yönlendirmeleri algılayıp araya girmesini ister. Chrome'un hata ekranı tam olarak bu korumadır.

Döngü tek bir kuraldan doğmaz, iki kuralın birbirini bozmasından doğar. Örneğin bir kural HTTP adreslerini HTTPS'e taşır, başka bir katman ise HTTPS adresini yeniden HTTP'ye çevirir. Ziyaretçi ikisinin arasında gidip gelir. Bu yazıda halkayı hangi katmanın kurduğunu bulmayı ve kırmayı adım adım anlatıyoruz.

Zincir uzunluğunun SEO etkisini ayrı bir yazıda ele aldık: yönlendirme zinciri hatası nedir yazısı, bitmeyen döngü değil, fazla uzayan ama sonunda bir sayfaya ulaşan zincirleri konu alır.

Hatayı kim çözmeli: ziyaretçi mi, site sahibi mi, sunucu yöneticisi mi?

Hatanın sorumlusunu doğru belirlemek zaman kazandırır. Çünkü her rolün elinde farklı bir düğme vardır. Aşağıdaki tablo, yönlendirme döngüsü hatası karşısında kimin neye bakması gerektiğini özetler.

Yönlendirme döngüsü hatasında küçük bir işletmede bu dört rol çoğu zaman tek kişidir. Yine de sırayı korumak gerekir: önce ziyaretçi tarafını eleyin, ardından katmanları dıştan içe doğru kontrol edin. Aynı hata başka insanlarda da çıkıyorsa sorun sizin tarayıcınızda değildir.

Tarayıcılar bu hatayı nasıl gösterir?

Hatanın adı tarayıcıya göre değişir, ama anlamı aynıdır. Chrome ve Edge gibi Chromium tabanlı tarayıcılar sayfanın sizi çok kez yönlendirdiğini söyler ve ERR_TOO_MANY_REDIRECTS kodunu yazar. Ekranda genellikle çerezleri silmeyi öneren bir ipucu da görürsünüz.

Firefox benzer durumda sayfanın düzgün yönlendirilmediğini bildirir. Safari ise çok fazla yönlendirme oluştuğu için sayfayı açamadığını yazar. Mesajların birebir metni sürümle değişebilir, bu yüzden kelimelere değil davranışa bakın: sayfa hiç yüklenmez ve adres çubuğu aynı adresler arasında gidip gelir.

• Sayfa tamamen boş kalır, içerik hiç görünmez.
• Hata yalnızca belirli adreste çıkar, bazı alt sayfalar açılabilir.
• Gizli pencerede çıkmayan hata, çoğunlukla çerez ya da önbellek kaynaklıdır.
• Her tarayıcıda ve her cihazda çıkan hata, sunucu ya da CDN kaynaklıdır.

Bu dört ipucu, teşhisin ilk yarım saatini kısaltır. Çünkü ziyaretçi tarafı mı yoksa sunucu tarafı mı olduğunu daha komut yazmadan ayırt edersiniz.

Ziyaretçi olarak ERR_TOO_MANY_REDIRECTS hatasında ne denemelisiniz?

Başka bir sitenin hatasıyla karşılaştıysanız yapabileceğiniz şeyler sınırlıdır, ama deneme değer. Önce sayfayı gizli pencerede açın. Gizli pencere mevcut çerezleri kullanmaz, bu yüzden bozuk bir oturum çerezi döngüye neden oluyorsa hata kaybolur.

1. Adresi gizli pencerede açın ve sonucu not edin.
2. Yalnızca o sitenin çerezlerini silin, tüm tarayıcı geçmişini silmeyin.
3. Önbelleği temizleyin, çünkü tarayıcılar bazı yönlendirmeleri saklar.
4. Başka bir tarayıcıda ya da telefonda mobil veriyle deneyin.
5. Tarayıcı eklentilerini, özellikle gizlilik ve yönlendirme eklentilerini kapatın.

Bu adımlardan sonra yönlendirme döngüsü hatası sürüyorsa sorun büyük olasılıkla sitenin kendisindedir. Bu durumda site sahibine ya da destek ekibine hangi adreste, hangi tarayıcıda ve ne zaman hata aldığınızı yazın. Böyle bir not, teşhis süresini ciddi biçimde kısaltır.

curl -I ile yönlendirme zinciri nasıl izlenir?

Yönlendirme döngüsü hatasını anlamak için zinciri görmeniz gerekir, oysa tarayıcı yönlendirmeleri sizin yerinize gizler. curl ise her adımı gösterir. Komut satırında aşağıdaki komut, adresi izleyerek her cevabın durum satırını ve Location başlığını yazdırır. Sınırlı sayıda adım izlemek için --max-redirs seçeneğini kullanırız, böylece komut sonsuza dek sürmez.

curl -sIL --max-redirs 8 https://example.com/ | grep -iE '^(HTTP|location)'

Çıktıda aynı iki adresin tekrar tekrar sıralandığını görüyorsanız döngüyü yakalamışsınız demektir. Hangi adresten hangisine gidildiğine bakın. Sonra HTTP ve HTTPS sürümlerini, www ve www'suz sürümlerini ayrı ayrı deneyin.

curl -sI http://example.com/ | grep -iE '^(HTTP|location)'
curl -sI https://www.example.com/ | grep -iE '^(HTTP|location)'
curl -sL -o /dev/null --max-redirs 8 -w '%{num_redirects} %{url_effective}\n' https://example.com/

Üçüncü komut yalnızca yönlendirme sayısını ve son adresi yazar. Döngüde curl, izin verilen sayıya ulaşınca hata verir. Komut örnektir, kendi alan adınızla değiştirmeniz gerekir. Tarayıcı yerine komut satırı kullanmanın bir faydası daha var: çerez ve önbellek karışmaz.

Komut satırına alışık değilseniz kendi tarayıcınızdan çalışan yönlendirme denetleyici aracımız aynı zinciri adım adım gösterir.

Tarayıcı geliştirici araçlarıyla yönlendirme döngüsü nasıl görülür?

Komut satırı yerine tarayıcıyı kullanmak istiyorsanız geliştirici araçları da yeterlidir. Chrome'da F12 tuşuyla araçları açın ve Network sekmesine geçin. Sayfayı yenilemeden önce Preserve log seçeneğini işaretleyin. Aksi halde her yönlendirmede kayıt silinir ve zinciri göremezsiniz.

1. Network sekmesini açın ve Preserve log kutusunu işaretleyin.
2. Gizli pencerede adresi yeniden yükleyin.
3. Listede aynı iki adresin tekrar ettiğini ve durum sütununda 3xx kodları olduğunu doğrulayın.
4. Bir satıra tıklayın ve Response Headers bölümünde Location başlığını okuyun.

Location başlığı, o adımda sunucunun sizi nereye gönderdiğini söyler. Aynı başlığı veren iki satır, yönlendirme döngüsü hatasının tam fotoğrafıdır. Başlıkta HTTP yazıyorsa HTTPS kuralı eksiktir, www farkı görüyorsanız kanonik adres tutarsızdır. Bu bilgiyi destek ekibine ekran görüntüsü olarak da gönderebilirsiniz.

Döngünün hangi katmanda olduğunu hangi sırayla bulursunuz?

Bir isteğin yolu şöyledir: tarayıcı, DNS, CDN ya da proxy, web sunucusu, uygulama. Döngüyü bu katmanlardan birinin kurduğunu bilirsiniz, ama hangisinin kurduğunu sırayla elemeniz gerekir. Rastgele ayar değiştirmek, sorunu bulmayı zorlaştırır.

1. Tarayıcı katmanını eleyin: gizli pencere ve başka cihazla deneyin.
2. CDN ya da proxy kullanıyorsanız geçici olarak yalnızca DNS moduna alın ve sonucu karşılaştırın.
3. Sunucuya doğrudan sorun: curl ile --resolve seçeneğini kullanarak CDN'i atlayın.
4. Web sunucusu kurallarını inceleyin: .htaccess ya da Nginx yapılandırması.
5. Uygulama ayarlarını inceleyin: WordPress adresleri, eklentiler, önbellek.

Üçüncü adımdaki komut, alan adını belirli bir sunucu adresine zorlar. Örnek adres dokümantasyon bloğundandır, kendi sunucunuzun adresiyle değiştirin.

curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | grep -iE '^(HTTP|location)'

Doğrudan sunucuya sorduğunuzda döngü yoksa, sorunu CDN katmanı ekliyor demektir. Döngü orada da sürüyorsa kuralı sunucuda ya da uygulamada arayın. Alan adının hangi adrese baktığını doğrulamak için DNS sorgulama aracı işinize yarar.

301, 302, 307 ve 308 yönlendirme kodları döngüde ne fark eder?

Yönlendirme durum kodları, RFC 9110'a göre iki aileye ayrılır. 301 ve 308 kalıcı taşımayı, 302 ve 307 geçici taşımayı bildirir. 307 ile 308, istek yöntemini korur; 301 ile 302 ise yöntemin değişmesine izin verir. Hepsinde yeni adres Location başlığında gelir.

Döngü teşhisinde kod türü kadar sırası da önemlidir. Çıktıda 301 koduyla başlayan ve yine aynı 301 koduyla biten bir halka görüyorsanız, kalıcı kuralı bulmanız gerekir. Bu kural genellikle sunucu ya da CDN düzeyinde yazılmıştır.

HTTP-HTTPS çakışması neden yönlendirme döngüsü yapar?

En sık görülen neden, iki katmanın HTTPS konusunda farklı şey bilmesidir. Bir CDN ya da yük dengeleyici ziyaretçiyle HTTPS konuşur, sunucuyla ise düz HTTP konuşabilir. Sunucu gelen isteği HTTP görür ve "HTTPS'e git" der. CDN yine HTTP ile sorar. Böylece halka kapanır.

Apache dokümantasyonu bu durumu açıkça anlatır. %{HTTPS} değişkeni doğrudan mod_ssl'e sorar. SSL sonlandırması bir yük dengeleyicide ya da ters proxy'de yapılıyorsa bu değişken, istemci HTTPS ile bağlanmış olsa bile kapalı görünür. Çözüm, proxy'nin eklediği X-Forwarded-Proto başlığına bakmaktır.

• Sunucu yalnızca kendi bağlantısına bakıyorsa, arkasındaki proxy gerçeği saklıyor demektir.
• Proxy başlığına güveneceksiniz, ama yalnızca başlığı her istekte kendi yazan proxy'ye.
• Sertifika sunucuda da varsa, CDN'i tam şifreleme moduna alıp sunucudaki yönlendirmeyi koruyabilirsiniz.

Apache dokümantasyonu, başlığa yalnızca yukarı akıştaki proxy'yi kontrol ediyorsanız güvenmenizi söyler. Çünkü saldırgan sunucuya doğrudan bağlanıp bu başlığı sahte yazabilir. SSL ve sertifika temellerini SSL sertifikası nedir yazımızda anlattık, burada tekrar etmiyoruz.

www ve www'suz adres çakışması döngüyü nasıl kurar?

Bir sitenin iki kanonik adresi olamaz. Birini seçip diğerini ona yönlendirirsiniz. Döngü, farklı iki katman farklı adresi seçtiğinde çıkar. Hosting paneli "www'suz adrese git" derken, uygulamanın ayarı "www'li adrese git" diyebilir. İki taraf birbirini sonsuza kadar karşılar.

Tipik senaryo şöyledir. Alan adını yeni bir hosting hesabına taşıdınız. Panelde yönlendirme kuralı eski tercihle kaldı. WordPress ise yeni tercihle kuruldu. İlk kural www'yi atar, ikinci kural www'yi geri ekler.

Çözüm, tek bir kanonik adres seçmek ve yalnızca tek yerde zorlamaktır. Apache dokümantasyonu, alan adı yönlendirmesi için mod_rewrite yerine sanal sunucuda Redirect yönergesini önerir. Alan adının temelleri için www nedir yazısına bakabilirsiniz.

WordPress'te yönlendirme döngüsü hatası nasıl çözülür?

WordPress'te döngünün ilk şüphelisi, Ayarlar altındaki Genel sayfasında yazan WordPress Adresi ve Site Adresi alanlarıdır. Biri HTTP, diğeri HTTPS yazıyorsa ya da www ile www'suz birbirinden farklıysa WordPress kendi içinde sürekli yönlendirir. Bu iki alan aynı biçimde ve doğru olmalıdır.

Panele giremiyorsanız değerleri wp-config.php dosyasına yazabilirsiniz. WordPress resmi dokümantasyonu bunun için WP_HOME ve WP_SITEURL sabitlerini gösterir. Dokümantasyon, bu yöntemin yalnızca değerleri koda sabitlediğini ve Genel ayarlar sayfasından düzenlemeyi kapattığını da hatırlatır.

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

WP-CLI erişiminiz varsa aynı kontrolü komutla yaparsınız. İlk iki komut değeri okur, son ikisi günceller. Bu yüzden önce yedek alın.

wp option get home
wp option get siteurl
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Ters proxy ya da CDN arkasındaki WordPress için ayrı bir ayrıntı vardır. Resmi HTTPS dokümantasyonu, SSL'i proxy sağlıyorsa ve WordPress kendi başına SSL'siz çalışıyorsa bazı SSL ayarlarının ilk anda sonsuz döngüye yol açabileceğini yazar. Bu durumda X-Forwarded-Proto başlığına göre HTTPS'i tanıtan küçük bir kod parçası eklenir. Sabit kodlamadan önce yedek aldığınızdan emin olun; yedeklemeyi web sitesi yedekleme stratejisi yazısında ele aldık.

.htaccess kural çakışması nasıl bulunur ve düzeltilir?

Apache kullanan sitelerde yönlendirme kuralları çoğunlukla .htaccess dosyasında yaşar. Bu dosyaya hosting paneli, güvenlik eklentisi, önbellek eklentisi ve WordPress'in kendisi kural ekleyebilir. Aynı işi yapan iki kural, ya da birbirinin tersini yapan iki kural döngü üretir.

Önce dosyanın yedeğini alın, sonra sadeleştirin. WordPress'in standart bloğu şu şekildedir ve yönlendirme içermez. Bu bloğun dışındaki her kuralı tek tek devre dışı bırakıp siteyi test edin.

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

HTTPS zorlaması gerekiyorsa Apache dokümantasyonundaki tarifi izleyin. Yalnızca .htaccess erişiminiz varsa mod_rewrite uygun araçtır; sunucu yapılandırmasına erişiminiz varsa ayrı bir HTTP sanal sunucusunda Redirect daha temizdir.

RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]

Yük dengeleyici ya da CDN arkasındaysanız koşulu X-Forwarded-Proto başlığına çevirin. Aksi halde koşul her zaman doğru çıkar ve döngü başlar. Ardından aynı HTTPS kuralını eklenti, panel ya da CDN ayarında ikinci kez açmayın. Kuralı tek yerde tutmak, hata ayıklamayı kolaylaştırır.

Nginx'te yönlendirme döngüsü nasıl oluşur?

Nginx'te de mantık aynıdır: iki blok ya da bir blokla uygulama birbirini tersine yönlendirir. En temiz yapı, 80 numaralı portu dinleyen ayrı bir server bloğunda kalıcı yönlendirme yapmak ve 443 bloğunda yönlendirme koymamaktır.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Bu örnekte tüm HTTP istekleri tek kanonik HTTPS adresine gider. HTTPS bloğunda ise yalnızca www adresini kanonik adrese taşıyan bir kural gerekebilir. HTTPS bloğunda yeniden HTTP'ye atan bir kural varsa döngü kaçınılmazdır.

Bir de karıştırılmaması gereken bir hata var. Nginx'in kendi iç yeniden yazma döngüsü, tarayıcıya yönlendirme göndermez. Bu durumda günlükte "rewrite or internal redirection cycle" ifadesini görürsünüz ve sunucu 500 hatası verir. Bu ERR_TOO_MANY_REDIRECTS değildir, ama teşhis için günlüğe bakmak yine ilk adımdır.

Nginx yapılandırmasını değiştirdikten sonra önce sözdizimini test edin, ardından yeniden yükleyin. Üretim sunucusunda deneme yapmak istemiyorsanız bu işi sunucu yöneticinize bırakın.

Cloudflare'de Flexible SSL yönlendirme döngüsü hatası neden olur?

Cloudflare arkasındaki sitelerde döngünün en bilinen nedeni Flexible SSL modudur. Cloudflare dokümantasyonuna göre bu mod, sunucunuz HTTP'yi HTTPS'e yönlendirirken Cloudflare sunucuya şifresiz istek gönderdiğinde döngü yaratır. Sonra Cloudflare HTTPS ister, sunucu yine HTTPS'e gönderir, istek tekrar HTTP gider.

Dokümantasyon iki çözüm yolu sunar: ya sunucudaki HTTPS yönlendirmesini kaldırırsınız, ya da sunucuya sertifika kurup Full moduna geçersiniz. Güvenlik açısından ikincisi daha sağlıklıdır, çünkü Flexible modda Cloudflare ile sunucu arasındaki bağlantı şifresiz kalır.

Cloudflare ayrıca HSTS'nin, şifreleme modu Off iken ya da sunucu HTTPS'i HTTP'ye çevirirken sorun çıkardığını belirtir. Sertifikanız ve zincir durumu için SSL sorgulama aracını kullanabilirsiniz.

Site taşıma sonrası yönlendirme döngüsü neden çıkar?

Alan adı ya da hosting değişikliği, döngülerin en sık görüldüğü andır. Çünkü eski ortamın kuralları yeni ortama kopyalanır, ama yeni ortamın varsayılanları farklıdır. Örneğin eski sunucuda sertifika vardı, yeni sunucuda henüz yok. Ya da eski ortamda CDN yoktu, yeni ortamda var.

Taşıma öncesi bir kontrol listesi hazırlayın. Veritabanındaki home ve siteurl değerlerinin yeni adresi gösterdiğinden emin olun. Eski .htaccess dosyasını olduğu gibi kopyalamak yerine, yalnızca gerekli kuralları taşıyın. Sertifikanın yeni ortamda aktif olduğunu doğrulayın ve DNS değişikliğini ancak sonra yapın.

• Taşımadan önce eski ve yeni ortamın SSL durumunu karşılaştırın.
• Veritabanında eski alan adı kalmadığından emin olun.
• Önce geçici bir adreste test edin, sonra canlıya alın.
• Taşıma günü yönlendirme kurallarını tek yerde toplayın.

Taşıma sırasında sunucu yapılandırması size ait değilse bu adımları hosting sağlayıcınızla birlikte yürütün. Böylece sağlayıcı kendi katmanındaki yönlendirmeleri önceden bildirir.

Yalnızca yönetim panelinde yönlendirme döngüsü varsa ne yapmalısınız?

Bazen ana sayfa açılır, ama yönetim paneli girişi döngüye girer. WordPress'te bunun tipik nedeni, panel için HTTPS zorunlu kılınmasıdır. Resmi dokümantasyon FORCE_SSL_ADMIN sabitini anlatır ve SSL'i proxy sağlıyorsa, bu sabitin proxy başlığı tanıtılmadan sonsuz döngüye yol açabileceğini söyler.

İlk adım, bağlantının sunucuya HTTP olarak ulaşıp ulaşmadığını anlamaktır. CDN ya da yük dengeleyici varsa sunucu isteği HTTP görüyor olabilir. Bu durumda WordPress panelin HTTPS olması gerektiğine karar verir ve yönlendirir, proxy yine HTTP ile iletir. Çözüm, X-Forwarded-Proto başlığına göre HTTPS'i tanıtmaktır.

Çerez alan adı da ikinci şüphelidir. Panel www adresinde, çerez ise www'suz adreste kurulduysa oturum sürekli kaybolur. Bu durumda giriş sayfası sizi tekrar giriş sayfasına yönlendirir. Bu yüzden önce WordPress adreslerinizi tutarlı hale getirin ve tarayıcı çerezlerini temizleyin.

Eklenti, CDN ve önbellek çakışması nasıl bulunur?

Birden fazla katman aynı işi yapıyorsa çakışma ihtimali yükselir. Örneğin HTTPS zorlamasını bir SSL eklentisi, bir önbellek eklentisi, .htaccess ve CDN aynı anda yapabilir. Her biri tek başına doğru çalışır, ama birlikte kullanıldıklarında birbirlerinin sonucunu yeniden yönlendirir.

1. Wp-content klasöründeki plugins klasörünün adını geçici olarak değiştirin; böylece tüm eklentiler devre dışı kalır.
2. Hata kaybolduysa klasörü geri adlandırın ve eklentileri tek tek açın.
3. Yönlendirme, SSL, güvenlik ve önbellek eklentilerine öncelik verin.
4. CDN önbelleğini temizleyin ve sayfayı yeniden deneyin.

WP-CLI varsa wp plugin deactivate --all komutu aynı işi daha temiz yapar. Yine de bu komut canlı sitede tüm eklentileri kapatır, yani mağaza ya da form çalışmazsa bu durum ziyaretçiyi etkiler. Bu yüzden bakım penceresinde deneyin.

Önbellek tarafında da dikkatli olun. Önbellek eklentisi bozuk bir yönlendirme cevabını saklayıp ziyaretçilere sunmaya devam edebilir. Düzeltmeyi yaptıktan sonra eklentinin ve CDN'in önbelleğini temizleyin, yoksa sorunun çözülmediğini sanırsınız.

Düzelttim ama hata sürüyor: tarayıcı neden eski yönlendirmeyi hatırlıyor?

RFC 9110, 301 cevabını varsayılan olarak önbelleğe alınabilir sayar. Yani tarayıcı kalıcı bir yönlendirmeyi saklayabilir ve sunucuya hiç sormadan eski hedefe gidebilir. Siz sunucuyu düzeltseniz bile kendi tarayıcınızda hata görmeye devam edebilirsiniz.

Bu yüzden doğrulamayı tarayıcıyla değil curl ile yapın. Tarayıcıda ise gizli pencere kullanın ya da o siteye ait önbelleği ve çerezleri silin. Test sırasında geçici yönlendirme (302 ya da 307) kullanmak, yanlış kuralın tarayıcıda kalıcı iz bırakmasını önler. Doğru kural netleşince 301 ya da 308'e geçersiniz.

HSTS ayrı bir önbelleklenen kuraldır. Bir site HSTS gönderdiyse tarayıcı belirli süre boyunca o alan adı için HTTP'yi doğrudan HTTPS'e çevirir. Sunucunuz HTTPS'i HTTP'ye atıyorsa döngü ancak sunucu kuralını düzelttiğinizde sona erer. HSTS'yi açmadan önce HTTPS'in her alt alan adında sağlıklı çalıştığından emin olun.

Yönlendirme döngüsü SEO'yu ve sıralamayı etkiler mi?

Evet, etkileyebilir. Döngüdeki bir adres hiçbir zaman içerik döndürmez. Arama motoru botu da tarayıcı gibi sonsuza dek takip etmez. Google, tarama dokümantasyonunda tarayıcılarının varsayılan olarak en fazla 10 yönlendirme adımı izlediğini yazar. Döngü bu sınıra ulaşır ve içeriğe hiç varılamaz.

Sonuç olarak yönlendirme döngüsü hatası veren sayfalar taranamaz. Yönlendirme döngüsü hatası kısa sürede düzelirse genellikle kalıcı bir zarar beklemezsiniz. Ancak günlerce süren döngü, o sayfaların güncellenmesini ve yeni içeriğin keşfedilmesini geciktirebilir. Bu bir garanti ya da sayısal tahmin değil, mantıksal sonuçtur.

• Search Console'da tarama ve sayfa dizine ekleme raporlarında yönlendirme hatası arayın.
• Hatanın hangi adreslerde çıktığını listeleyin, çünkü çoğu zaman bir şablon ya da klasör etkilenir.
• Düzelttikten sonra örnek adresleri curl ile yeniden doğrulayın.

Sayfa hızı ve tarama bütçesi konularına site hızı SEO'yu nasıl etkiler yazısından devam edebilirsiniz. Teknik SEO denetiminde yönlendirme tutarlılığı ekibimizin her zaman kontrol ettiği maddelerden biridir; bu konuda SEO danışmanlığı hizmetimize göz atabilirsiniz.

Yönlendirme döngüsü hatasını tekrar etmemesi için nasıl önlersiniz?

Bir yönlendirme döngüsü hatası çoğu zaman bir değişiklikten hemen sonra çıkar: alan adı taşıma, SSL kurulumu, CDN ekleme, tema ya da eklenti güncellemesi. Bu yüzden önlemin kendisi, değişiklik öncesi ve sonrası küçük bir kontrol listesidir.

1. Tek bir kanonik adres seçin: HTTPS ve www ya da www'suz.
2. Bu seçimi yalnızca tek yerde zorlayın ve diğer katmanlarda kapatın.
3. Değişiklikten önce .htaccess ya da Nginx dosyasının, wp-config.php'nin ve veritabanının yedeğini alın.
4. Değişiklikten sonra HTTP, HTTPS, www ve www'suz dört adresi curl ile deneyin.
5. CDN SSL modunu, sunucunun gerçek durumuyla uyumlu seçin.

Yönlendirme haritasını önceden çıkarmak da işe yarar. Yeni bir site yayına alırken eski ve yeni adresleri bir tabloya yazın. Böylece hangi kuralın hangi adresi nereye taşıdığını görürsünüz. Alan adı kayıtlarını doğrulamak için WHOIS sorgulama da kullanışlıdır.

Sitenizin hosting altyapısını ilk kurarken sağlayıcıdan hangi bilgileri istemeniz gerektiğini web sitesi için hosting nasıl seçilir yazımızda anlattık.

Bu işi ne zaman kendiniz yapmamalı, hosting sağlayıcınıza bırakmalısınız?

Dürüst olmak gerekirse biz bir hosting firması değiliz. Dijital pazarlama ve web ekibiyiz; bu yazıdaki anlatım resmi dokümantasyona ve standartlara dayanır. Bu yüzden riskli gördüğümüz yerde sizi hosting sağlayıcınıza yönlendiririz.

• Paylaşımlı hostingte SSH ve sunucu yapılandırması size açık değilse, kuralları sağlayıcının destek ekibi düzeltmelidir.
• Yedeğiniz yoksa .htaccess, wp-config.php ya da veritabanı değiştirmeyin; önce yedek alın.
• Yönetilen hosting kullanıyorsanız sağlayıcı yönlendirmeleri kendi katmanında yapıyor olabilir ve sizin kuralınız onunla çakışır.
• Canlı bir e-ticaret sitesinde saat başı satış kaybediyorsanız, deneme yanılma yerine sağlayıcıdan öncelikli destek isteyin.
• DNS kayıtlarını ya da e-posta ayarlarını bozma ihtimali olan bir değişikliği tek başınıza yapmayın.

Sağlayıcınıza giderken size en çok yardımı, curl çıktısı ve hatanın başladığı zaman verir. Elinizde bunlar varsa destek ekibi çoğunlukla ilk cevapta halkayı bulur. Site yenileme ya da taşıma projelerinde yönlendirme planını baştan çıkarmak istiyorsanız web tasarım hizmetimiz bu planı da kapsar.