301 mi 302 mi? Yönlendirme Türleri Arasındaki Fark ve Seçimi

Hosting panelinde "Yönlendirmeler" ekranını açtığınızda karşınıza iki seçenek çıkar: Kalıcı (301) ve Geçici (302). Kutunun yanında hiçbir açıklama yoktur, varsayılan çoğu panelde 302'dir ve insanların büyük bölümü "nasılsa çalışıyor" diyip devam eder. Sonra üç ay geçer, eski sayfanın Google'daki sırası yeni sayfaya taşınmaz, arama sonucunda hâlâ eski URL görünür ve "301 mi 302 mi kullanmalıydım" sorusu ancak o zaman sorulur. Bu yazının çıkış noktası tam olarak bu an: kalıcı ve geçici yönlendirme farkı teknik olarak tek bir sayı, sonuçları açısından ise tamamen farklı iki karar.

Aşağıda önce yönlendirmenin tarayıcı tarafında ne demek olduğunu, sonra 301, 302, 307, 308 kodlarının hangi senaryoya ait olduğunu, Google'ın 302'yi zamanla nasıl yorumladığını, HSTS'in ürettiği ve sunucudan hiç gelmeyen "307 Internal Redirect" satırını, yönlendirme zincirinin kaç adımdan sonra gerçekten sorun hâline geldiğini ve meta refresh ile JavaScript yönlendirmesinin neden son çare olduğunu tek tek ele alacağım. Her bölümde .htaccess, nginx ve cPanel karşılıklarını da vereceğim, çünkü doğru kodu seçmek yetmiyor — onu doğru yere yazmak gerekiyor.

Yönlendirme Nedir ve Tarayıcı Ne Yapar#

Yönlendirme, sunucunun bir isteğe içerik yerine "bu adres burada değil, şuraya git" cevabı vermesidir. Tarayıcı /eski-sayfa ister, sunucu gövde göndermez; bunun yerine 3xx sınıfından bir durum kodu ve Location başlığı döner. Tarayıcı bu başlığı okur ve ikinci bir istek atar. Yani kullanıcı bir sayfa görene kadar en az iki tur atılmıştır.

Ham hâlini görmek için tek komut yeter:

curl -sIL https://ornek.com/eski-sayfa | grep -Ei '^(HTTP|location)'

Tipik bir çıktı şöyledir:

HTTP/2 301
location: https://ornek.com/yeni-sayfa
HTTP/2 200

Buradaki 301 sunucunun verdiği sözdür: "bu taşınma kalıcıdır". 302 ise "şu an başka yere bakıyorum ama asıl adres burası" demektir. Fark bir sayıdan ibaret görünse de tarayıcı önbelleği, arama motoru indeksi ve hatta form gönderimleri bu sayıya göre davranır. Durum kodlarının tam listesi ve sınıf mantığı için http durum kodları listesi yazısındaki tabloyu yanınızda bulundurmanızı öneririm.

301 Kalıcı Yönlendirme Ne Zaman Kullanılır#

301, taşınmanın geri dönüşü olmadığı her durumda kullanılır. Ölçüt basittir: eski URL'yi bir daha yayına almayacaksanız 301 kullanın.

Gerçek hayatta 301'in yeri olan senaryolar:

1. Alan adı değişikliği. eskifirma.com → yenifirma.com geçişi. Tüm yollar birebir eşleşiyorsa kural tek satırdır.
2. HTTP'den HTTPS'e geçiş. SSL kurduktan sonra http:// isteklerini https://e taşımak. Sertifika yüklendiği anda yapılması gereken ilk iştir; yönlendirme kurulmazsa site iki ayrı adresten aynı anda yayınlanmaya devam eder.
3. www tekilleştirme. Sitenin hem www hem wwwsuz açılması içerik kopyası üretir; birini seçip diğerini 301 ile ona bağlamak gerekir. Belirtileri ve çözümü www ve wwwsuz aynı anda açılıyor yazısında adım adım anlatılıyor.
4. URL yapısı değişimi. /urun.php?id=12 → /urun/kablosuz-kulaklik gibi kalıcı bir mimari değişiklik.
5. Sayfa birleştirme. İki zayıf içeriği tek güçlü sayfada toplamak.

Apache tarafında karşılığı:

#.htaccess — kalıcı alan adı taşıması
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?eskifirma\.com$ [NC]
RewriteRule ^(.*)$ https://yenifirma.com/$1 [R=301,L]

nginx tarafında:

server {
    listen 443 ssl;
    server_name eskifirma.com www.eskifirma.com;
    return 301 https://yenifirma.com$request_uri;
}

Buradaki $request_uri kritik: onu yazmayıp sadece return 301 https://yenifirma.com; derseniz sitedeki her sayfa ana sayfaya düşer. Google bunu "alakasız yönlendirme" (soft 404 benzeri) olarak değerlendirir ve o sayfaların birikmiş sinyalleri aktarılmaz. Yıllardır gördüğüm en pahalı taşıma hatası budur: teknik olarak 301 verilmiştir ama hedef yanlıştır.

302 Geçici Yönlendirme Ne Zaman Kullanılır#

302, orijinal URL'nin yakında geri döneceği durumlarda kullanılır. Ölçüt yine tek cümle: eski URL'yi tekrar yayına alacaksanız 302 kullanın.

Uygun senaryolar:

• Bakım modu. Site güncellenirken ziyaretçiyi bir bilgilendirme sayfasına almak. (Aslında burada daha doğrusu 503 + Retry-After başlığıdır; yönlendirmeye hiç gerek yoktur.)
• Kampanya sayfası. /indirim adresini kampanya süresince /yaz-kampanyasi-2026 sayfasına taşımak, kampanya bitince geri almak.
• A/B testi. Ziyaretçinin bir kısmını alternatif tasarıma göndermek.
• Coğrafi/dil tespiti sonrası geçici sürükleme. / adresinden /tr/ veya /en/ sayfasına atmak — burada asıl adres kök olarak kalmalıdır.
• Stokta olmayan ürünü kategoriye almak. Ürün geri gelecekse 302, hiç gelmeyecekse 404 veya 410 daha doğrudur.

Apache karşılığı, tek fark R=302:

RewriteEngine On
RewriteRule ^indirim/?$ /yaz-kampanyasi-2026 [R=302,L]

Dikkat edilmesi gereken nokta: .htaccess içinde sadece [R] yazarsanız Apache varsayılan olarak 302 üretir. Kalıcı taşıma yaptığını sanıp [R,L] yazan çok kişi gördüm; çıktıyı curl -I ile doğrulamadan emin olmayın.

Kod Karşılaştırma Tablosu#

Tablodaki "istek yöntemi korunur mu" sütunu web uygulamaları için en kritik olanıdır. Bir form POST ile /odeme adresine gider ve sunucu 301 döndürürse tarayıcı ikinci isteği GET olarak atar; form verisi kaybolur ve kullanıcı boş bir sayfaya bakar. Bu yüzden API uçlarında ve form işleyen adreslerde 307/308 tercih edilir.

307 ve 308 Neden Var#

307 ve 308, 302 ve 301'in "yöntem koruyan" sürümleridir. Sebebi tarihseldir: HTTP/1.0 döneminde tarayıcılar 302 aldıklarında POST isteğini GETe çevirmeye başladı; standart bunu yasaklıyordu ama uygulama yerleşti. Geriye dönük uyumluluğu bozmamak için standart, davranışı kesin olarak tanımlayan iki yeni kod ekledi.

Pratikte ne zaman lazım olur:

• Ödeme adımında POST ile gelen isteği başka bir yola taşıyorsanız → 307.
• API'nizin /v1/ uçlarını kalıcı olarak /v2/ altına aldıysanız ve istemciler POST/PUT kullanıyorsa → 308.
• Sıradan bir içerik sayfası taşıması → 301 yeterli, 308'e gerek yok.

nginx'te 307/308 açıkça yazılabilir:

location = /v1/siparis {
    return 308 /v2/siparis;
}

Apache'de ise [R=308,L] şeklinde belirtilir.

HSTS ve 307 Internal Redirect: Sunucudan Gelmeyen Yönlendirme#

Tarayıcının geliştirici araçlarında 307 Internal Redirect satırı görüp "ben böyle bir kural yazmadım" diyorsanız haklısınız — bu yönlendirmeyi sunucunuz üretmedi, tarayıcının kendisi üretti. Sebebi HSTS'tir.

HSTS (HTTP Strict Transport Security), sunucunun Strict-Transport-Security başlığıyla tarayıcıya "bu alan adına bir daha asla şifresiz bağlanma" demesidir. Tarayıcı bu bilgiyi kaydettikten sonra http://ornek.com yazsanız bile ağa hiç çıkmaz; isteği yerel olarak https://ye çevirir ve bunu ağ panelinde 307 Internal Redirect olarak gösterir. Mekanizmanın tamamı ve başlık parametreleri için hsts nedir yazısına bakın.

Bunun üç pratik sonucu vardır:

1. Yönlendirme sayınız düşer. HSTS aktifken tekrar eden ziyaretçi için HTTP→HTTPS turu ağda hiç gerçekleşmez.
2. Hata ayıklamada yanıltır. .htaccess'teki HTTPS kuralını silip test ettiğinizde site hâlâ HTTPS'e gidiyorsa kural silinmemiş değildir; tarayıcınız HSTS kaydını hatırlıyordur. Chrome'da chrome://net-internals/#hsts ekranından alan adını sorgulayıp silebilirsiniz.
3. Sunucu tarafı kuralı yine de gerekir. HSTS ancak siteye bir kez HTTPS ile girmiş tarayıcılarda çalışır. İlk ziyaretçi ve arama motoru botları için 301 kuralınız yerinde durmalıdır.

Google 302'yi Nasıl Yorumluyor#

Google, uzun süreli 302 yönlendirmelerini pratikte 301 gibi işlemeye başlar. Ama bu bir güvence değil, bir toparlama davranışıdır ve arada geçen sürede kaybınız olur.

Süreç kabaca şöyle işler: 302 gören tarama sistemi başlangıçta kaynak URL'yi kanonik kabul eder, yani arama sonuçlarında eski adresi göstermeye devam eder. Yönlendirme aylarca yerinde kalır ve hedef URL bağımsız sinyaller toplarsa, sistem zamanla hedefi kanonik seçmeye kayar. Yani sonuç aynı yere varabilir; sorun yol boyunca yaşananlardır:

• Eski URL indekste kaldığı sürece arama sonucunda görünen başlık ve açıklama eski sayfaya aittir; yeni sayfanın başlığı görünmez.
• Yeni sayfanın kanonikleşmesi haftalar sürer, bu sürede iki URL arasında sinyal bölünmesi olur.
• Search Console'da "Sayfa yönlendirmeli" ve "Google, kullanıcının belirttiğinden farklı bir kanonik seçti" uyarıları birikir; gerçek sorunların arasında kaybolur.

Kısacası: 302 yanlış seçildiğinde site batmaz, sadece geçiş gereksiz yere uzar ve ölçülemez hâle gelir. Doğru refleks, taşımanın kalıcı olup olmadığını baştan cevaplamaktır. Ayrıca 302 ile yönlendirilen sayfaya rel="canonical" etiketiyle kendi kendini gösteren farklı bir sinyal koyarsanız çelişkili mesaj vermiş olursunuz: yönlendirme "oraya git" derken kanonik "asıl sayfa benim" der ve arama motoru hangisini dinleyeceğine kendi karar verir.

Yönlendirme Zinciri Kaç Adımda Sorun Olur#

Zincir, bir isteğin son adrese ulaşana kadar birden fazla yönlendirmeden geçmesidir. Klasik örnek şudur:

http://ornek.com/urun
  → 301 → http://www.ornek.com/urun
  → 301 → https://www.ornek.com/urun
  → 301 → https://www.ornek.com/urun/
  → 200

Üç ayrı kural birbirini tetiklemiş, ziyaretçi dört tur atmıştır. Pratik eşikler şöyledir:

• 1 adım: İdeal. Tek kuralda hedefe varılır.
• 2 adım: Kabul edilebilir, ama birleştirilebiliyorsa birleştirin.
• 3-4 adım: Mobil bağlantıda hissedilir gecikme; her tur DNS/TLS maliyeti olmasa da ek bir gidiş-dönüş demektir.
• 5 adım ve üzeri: Tarama bütçesi israfı; bazı tarayıcılar ve botlar zinciri takip etmeyi bırakır.
• 20 adım: Chrome'un sert sınırı. Bunun aşıldığı en yaygın hâl ise zincir değil döngüdür: A → B → A. Tarayıcı ERR_TOO_MANY_REDIRECTS verir; teşhis adımları için err too many redirects hatası yazısına bakın.

Zinciri tek komutla görmek için:

curl -sIL -o /dev/null -w '%{num_connects} bağlantı, %{num_redirects} yönlendirme, %{time_total}s\n' https://ornek.com/urun

Zinciri kısaltmanın yolu, kuralları doğru sırayla ve tek adımda hedefe atacak şekilde yazmaktır. Örneğin www + HTTPS + eski alan adı üçlüsü tek kuralda bitirilebilir:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.ornek.com/$1 [R=301,L]

Bu kural şifresiz gelen veya wwwsuz gelen her isteği tek seferde https://www. hedefine götürür.

meta refresh ve JavaScript Yönlendirmesi Neden Son Çare#

meta refresh ve window.location, HTTP katmanında hiçbir yönlendirme üretmez; sunucu 200 OK döner, yönlendirme HTML yüklendikten sonra tarayıcı tarafında olur.

<!-- Kaçınılması gereken kalıp -->
<meta http-equiv="refresh" content="5;url=https://ornek.com/yeni">

Sorunlar somuttur:

• Sinyal aktarımı zayıftır. Arama motorları sıfır saniyelik meta refresh'i genellikle 301 benzeri işler, ama gecikmeli olanı (yukarıdaki gibi 5;) yönlendirme saymaz; sayfa kendi başına indekslenmeye devam eder.
• Erişilebilirlik sorunu üretir. Ekran okuyucu kullanıcısı ve klavyeyle gezen ziyaretçi, sayfa altından kayarken beklenmedik biçimde başka adrese atılır.
• Geri tuşunu bozar. Kullanıcı geri bastığında yönlendiren sayfaya döner, o da yeniden ileri atar; kullanıcı sitede kapana kısılır.
• JavaScript kapalıysa veya hata verirse hiç çalışmaz. Bir JS hatası tüm dosyayı düşürürse yönlendirme de düşer.

Bunları sadece sunucu yapılandırmasına erişiminizin hiç olmadığı durumlarda (kapalı bir site kurucusunda, salt HTML barındırma alanında) kullanın. Bir hosting hesabınız varsa .htaccess her zaman elinizin altındadır ve yukarıdaki üç satırlık kural aynı işi doğru durum koduyla yapar.

Yönlendirmeyi Nerede Tanımlamalı#

Aynı yönlendirme birden çok katmanda tanımlanabilir ve her katmanın maliyeti farklıdır. Kural şudur: isteği en erken karşılayan katmanda yönlendirin.

cPanel tarafında adımlar nettir: cPanel → Alan Adları → Yönlendirmeler ekranını açın, tür olarak Kalıcı (301) veya Geçici (302) seçin, kaynak alan adını ve hedef URL'yi girin, "www ile ve www olmadan yönlendir" seçeneğini işaretleyin, kaydedin. Panel bu kaydı arka planda public_html/.htaccess dosyasına yazar; dosyayı Dosya Yöneticisi'nden açıp doğrulayabilirsiniz. Aynı ekranda alan adı bazlı e-posta yönlendirmeleriyle karıştırmayın — onlar MX tarafına aittir ve cPanel MX kaydı ve e-posta yönlendirme yazısının konusudur.

WordPress kullanıyorsanız yönlendirmeyi PHP katmanında tutmanın bir bedeli olduğunu bilin: her istek WordPress'i başlatır. Onlarca kural için sorun değil, binlerce kural için .htaccesse taşımak gözle görülür fark yaratır.

Yönlendirmeyi Test Etme ve Yaygın Hatalar#

Kuralı yazdıktan sonra tarayıcıda değil, komut satırında doğrulayın. Tarayıcı önbelleği ve HSTS, yanlış kuralı çalışıyormuş gibi gösterebilir.

#Zinciri adım adım, kodlarıyla birlikte görmek
curl -sIL https://ornek.com/eski-yol | grep -Ei '^(HTTP/|location:)'

#Önbelleği devre dışı bırakarak tek adımı görmek
curl -sI -H 'Cache-Control: no-cache' https://ornek.com/eski-yol

Sık karşılaştığım hatalar ve belirtileri:

• Sondaki eğik çizgi tutarsızlığı. /sayfa ve /sayfa/ ayrı URL'dir. Biri diğerine yönlenirken ters kural da varsa döngü doğar.
• Yakalanmayan sorgu dizesi. RewriteRule ile hedef yazarken ? koymazsanız Apache eski sorgu dizesini ekler; kasıtlı olarak temizlemek isterseniz hedefin sonuna ? ekleyip [R=301,L] verin.
• Kural sırası. .htaccess'te WordPress'in kendi blokunun üstüne yazılmayan kurallar hiç çalışmaz, çünkü WordPress bloku isteği yakalayıp bitirir.
• Yönlendirmenin 200 dönmesi. Sunucu içi (internal) rewrite ile dış yönlendirme karışmış demektir; [R] bayrağı yoksa Apache adresi değiştirmeden içeriği başka dosyadan sunar. SEO açısından bu bir yönlendirme değildir.
• Toplu kural sonrası hedefin 404 vermesi. Zinciri test ederken son satırın 200 olduğundan emin olun; 301 → 404 en sık gözden kaçan kalıptır.

Sıkça Sorulan Sorular#

301 mi 302 mi kullanmalıyım#

Eski URL'yi bir daha yayına almayacaksanız 301, geri alacaksanız 302 kullanın. Bu tek soru vakaların yaklaşık tamamını çözer: alan adı değişimi, HTTPS geçişi, www tekilleştirmesi ve kalıcı URL yapısı değişikliği 301'dir; kampanya sayfası, bakım yönlendirmesi ve A/B testi 302'dir. Emin değilseniz ve taşıma kalıcı görünüyorsa 301 seçin, çünkü 302'yi 301'e çevirmek kolaydır ama yanlışlıkla 301 verilmiş bir URL tarayıcılarda kalıcı önbelleklendiği için geri almak zordur. Kararı ertelemek yerine yazılı olarak "bu URL geri gelecek mi" sorusuna cevap verin.

301 verdikten sonra geri almak neden zor#

Çünkü tarayıcılar 301 yanıtını süresiz önbellekleyebilir ve bir daha sunucuya sormaz. Kuralı sunucudan silseniz bile daha önce o sayfayı ziyaret etmiş kullanıcı hâlâ yeni adrese gider; kendi tarayıcı önbelleğini temizlemesi gerekir. Bu yüzden test aşamasında asla 301 kullanmayın, denemelerinizi 302 ile yapıp kesinleştiğinde 301'e çevirin. Zorunlu kaldığınızda geçici çözüm, eski URL'yi tekrar yayına alıp uzun süre beklemek ve Cache-Control başlığıyla kısa ömürlü yanıt vermektir.

302 kullanırsam SEO değerim kaybolur mu#

Kalıcı olarak kaybolmaz ama geçiş gereksiz yere uzar. Google, uzun süre yerinde duran 302'leri zamanla 301 gibi işlemeye başlar; ne var ki bu süre boyunca arama sonuçlarında eski URL gösterilmeye devam eder, yeni sayfanın başlığı ve açıklaması görünmez ve sinyaller iki adres arasında bölünür. Kalıcı bir taşımada 302 kullanmak, doğru sonuca haftalar sonra ve ölçüsüz biçimde varmak demektir. Taşıma kalıcıysa baştan 301 verip Search Console'da yeni URL'nin taranmasını izlemek çok daha temiz bir yoldur.

307 yönlendirme nedir ve ne zaman gerekir#

307, geçici yönlendirmenin istek yöntemini koruyan sürümüdür. Tarayıcı 302 aldığında bir POST isteğini GETe çevirir ve form verisi kaybolur; 307 aldığında ise POST olarak devam eder. Bu yüzden form işleyen adreslerde, ödeme adımlarında ve API uçlarında 307 (kalıcıysa 308) tercih edilir. Sıradan bir içerik sayfasını taşırken 307'ye ihtiyacınız yoktur; orada 301 ile 302 arasındaki seçim yeterlidir.

Geliştirici araçlarında gördüğüm 307 Internal Redirect nereden geliyor#

O yönlendirmeyi sunucunuz değil, tarayıcınız üretiyor. Siteniz daha önce Strict-Transport-Security başlığı gönderdiyse tarayıcı bu kaydı saklar ve http:// ile yapılan istekleri ağa hiç çıkarmadan yerel olarak https://ye çevirir; ağ panelinde bu satır 307 Internal Redirect olarak görünür. Sunucu tarafındaki kuralınızı silseniz bile davranış devam eder, çünkü kaynak tarayıcının kendi kaydıdır. Test etmek için Chrome'da chrome://net-internals/#hsts ekranından alan adını silebilir ya da gizli pencere yerine temiz bir profil kullanabilirsiniz.

Yönlendirme zinciri kaç adıma kadar sorunsuz#

İdeali tek adım, iki adım kabul edilebilir, üç ve üzeri hissedilir gecikme üretir. Her ek adım tarayıcı için ayrı bir gidiş-dönüş demektir ve mobil bağlantıda bu maliyet birikir; ayrıca arama motorları uzun zincirlerde tarama bütçesini boşa harcar. Chrome'un sert sınırı yirmi adımdır ama pratikte bu sınıra döngü hatası olmadan ulaşılmaz. www, HTTPS ve alan adı kurallarını ayrı ayrı yazmak yerine tek bir RewriteRule içinde birleştirirseniz üç adımlık zincir bir adıma iner.

cPanel yönlendirme ekranındaki wildcard seçeneği ne işe yarar#

Wildcard yönlendirme, kaynak adresteki yolu hedefe olduğu gibi taşır. İşaretlemezseniz eski.com/urun/ayakkabi isteği yeni.com ana sayfasına düşer; işaretlerseniz yeni.com/urun/ayakkabi adresine gider. Alan adı taşımalarında bu kutunun işaretli olması neredeyse her zaman doğrudur, çünkü sayfa bazlı sinyallerin aktarılması ancak hedefin karşılığı olan sayfa olmasıyla mümkündür. İşaretlemeden yapılan taşımalar, teknik olarak 301 verildiği hâlde sıralama kaybının en sık nedenidir.

meta refresh kullanmak zararlı mı#

Alternatifi varken zararlıdır. Sunucu 200 döndüğü için HTTP düzeyinde bir yönlendirme sinyali oluşmaz, gecikmeli olanları arama motorları yönlendirme saymaz, geri tuşunu bozar ve JavaScript veya HTML yüklenmezse hiç çalışmaz. Yalnızca sunucu yapılandırmasına hiçbir erişiminizin olmadığı ortamlarda son çare olarak düşünülmelidir. Bir hosting hesabınız varsa aynı işi .htaccess içinde tek satırla ve doğru durum koduyla yapabilirsiniz.

Kapanış#

301 ile 302 arasındaki seçim teknik bir tercih değil, bir niyet beyanıdır: "bu adres bir daha kullanılmayacak" mı diyorsunuz, yoksa "şimdilik başka yere bakıyorum" mu? Bu soruya net cevap verdiğinizde geri kalanı mekaniktir — kuralı en erken katmanda yazmak, zinciri tek adıma indirmek, curl -sIL ile doğrulamak ve HSTS'in ürettiği 307 satırını sunucu kuralınızla karıştırmamak. Yöntem koruyan 307/308'i ise sadece form ve API adreslerinde hatırlamanız yeterli. Yanlış seçim siteyi düşürmez ama geçişi haftalarca uzatır ve ölçmeyi imkânsız hâle getirir; doğru seçim ise ek maliyet getirmez.

Taşıma sırasında yönlendirme kuralları, DNS geçişi ve SSL yenilemesi aynı güne denk geliyorsa işi tek başınıza yürütmek zorunda değilsiniz. Clou.TR'nin site taşıma hizmeti eski hosting hesabındaki .htaccess kurallarını ve alan adı yönlendirmelerini kesintisiz taşıyacak şekilde planlar; taşıma sonrası kalıcı olarak WordPress kullanacaksanız WordPress hosting paketleri yönlendirme ve önbellek katmanını hazır sunar. Kendi sunucunuzda nginx düzeyinde yönlendirme yönetmeyi ve zincirleri tek adıma indirmeyi tercih ediyorsanız VDS sunucu paketleri size tam yapılandırma erişimi verir.