301 Yönlendirmesi Nedir ve Ne Zaman Kullanılır?

Sesli Dinle — Makale

301 Moved Permanently (kalıcı olarak taşındı), bir kaynağın kalıcı olarak başka bir URL'ye atandığını bildiren HTTP durum kodudur; HTTP, web isteklerini ve yanıtlarını tanımlar. Sunucu, 301 yanıtıyla birlikte yeni hedefi Location başlığında bildirir; istemci bu hedefe ayrı bir istek gönderebilir.

301 yönlendirmesi içeriği kendiliğinden taşımaz. Yeni sayfanın hazırlanması, eski ve yeni URL'lerin doğru eşleştirilmesi, yönlendirme kuralının yayımlanması ve hedefin erişilebilir tutulması ayrı işlemlerdir. Hedef hatalıysa veya yeniden başka bir adrese gidiyorsa durum kodunun 301 olması tek başına yeterli değildir.

Adres değişikliği geçiciyse 301 kullanılmamalıdır. Tarayıcılar, ara önbellekler ve arama motorları kalıcı hedefi öğrenebilir; daha sonra kuralı değiştirmek her kullanıcıda hemen sonuç vermeyebilir. Canlıya almadan önce URL eşleştirmesi, istek yöntemi, önbellek davranışı ve geri dönüş planı birlikte sınanmalıdır.

301 Yanıtı Nasıl Çalışır?

1. İstemci eski URL'ye bir HTTP isteği gönderir.
2. Sunucu veya öndeki ağ bileşeni, normal içerik yerine 301 durum kodu ile bir Location değeri döndürür.
3. İstemci yönlendirmeyi izlemeyi seçerse hedef URL'ye yeni bir istek gönderir.
4. Hedef sunucu son içeriği ya da başka bir HTTP yanıtını döndürür.

Bu akış en az bir ek istek ve ağ turu oluşturur. Eski URL bir ara hedefe, o hedef de son sayfaya gidiyorsa her adım yeni bir bağlantı veya HTTP alışverişi gerektirebilir. Site içi bağlantıları doğrudan son URL'ye güncellemek, kullanıcıların yönlendirmeyi gereksiz yere izlemesini önler.

Location değeri mutlak veya kurallara uygun göreli bir adres olabilir; ancak alan adı taşıması ve farklı bileşenler arasında çalışan kurallarda tam hedefi açıkça üretmek hata riskini azaltabilir. Hedefte şema, alan adı, port, yol, sorgu ve kodlama beklenen biçimde olmalıdır.

301 Yanıtı Önbellekte Saklanır mı?

301 yanıtı, yöntem tanımı veya açık önbellek başlıkları aksini gerektirmedikçe önbellekler tarafından saklanabilir. Tarayıcı daha sonraki ziyarette sunucuya uğramadan öğrendiği hedefe gidebilir. Bu nedenle deneme için kalıcı kod kullanmak, kural sunucudan kaldırıldıktan sonra bile bazı istemcilerde eski sonucun görülmesine yol açabilir.

Tarayıcı önbelleği, ortak ara önbellek ve CDN önbelleği birbirinden bağımsız olabilir. Cache-Control ile tazelik süresi veya yeniden doğrulama davranışı bildirilebilir; ancak daha önce saklanmış 301 kopyaları yeni kural yayımlandığında her yerde anında kaybolmaz. Denetimde normal tarayıcı oturumunun yanında önbelleksiz istek ve doğrudan yanıt başlığı kontrolü de kullanılmalıdır.

301 İstek Yöntemini ve Gövdesini Nasıl Etkiler?

GET bir kaynağın içeriğini, HEAD ise yanıt gövdesi olmadan başlık bilgilerini ister. POST, gönderilen verinin sunucu tarafından işlenmesini ister; örneğin bir formu göndermek için kullanılabilir.

301, yalnız GET istekleriyle sınırlı değildir; fakat kullanıcı aracı bir POST isteğini yönlendirirken yöntemi GET'e çevirebilir ve gövdeyi yeniden göndermeyebilir. Kalıcı yönlendirmede yöntemin ve istek gövdesinin kesin olarak korunması gerekiyorsa 308 Permanent Redirect (kalıcı yönlendirme) daha açık anlam taşır.

Form, dosya yükleme, API veya durum değiştiren isteklere toplu 301 kuralı uygulamadan önce gerçek istemcilerle test yapılmalıdır. Bir giriş veya ödeme isteğinin GET'e dönüşmesi ya da gövdesini kaybetmesi işlevi bozabilir. Yöntemi koruyan yönlendirme de gövdeyi yeni hedefe tekrar göndereceği için hedefin güvenilir ve aynı işlemi kabul etmeye hazır olması gerekir.

301, 302, 303, 307 ve 308 Arasındaki Farklar

Kalıcı-geçici seçimi ile yöntem koruma seçimi ayrı eksenlerdir. Basit bir sayfa GET isteğinde 301 yaygın ve uygundur. Aynı yöntemin korunması gereken kalıcı API yolu değişikliğinde 308 daha açık olabilir. Geçici adres değişikliğinde 302, yöntemin korunacağı geçici aktarımda 307; POST işlemi tamamlandıktan sonra sonuç sayfasının GET ile açılmasında 303 düşünülebilir.

301 Yönlendirmesi Hangi Durumlarda Kullanılır?

Kalıcı URL değişikliği: Bir sayfanın klasörü, dosya adı veya okunabilir yolu kalıcı biçimde değiştiyse eski URL, aynı içeriğin yeni URL'sine yönlendirilebilir. Yolun sonundaki eğik çizgi, büyük-küçük harf veya dosya uzantısı için tek biçim seçildiyse diğer biçimler de doğrudan ana hedefe gönderilebilir.

Alan adı taşıması: Site yeni alan adına geçiyorsa eski alan adındaki önemli her URL, yeni alan adındaki karşılığıyla eşleştirilmelidir. Eski alan adı, DNS hizmeti, sertifika ve 301 yanıtını veren altyapı çalışır durumda kalmalıdır. Yalnız yeni alan adını yayımlamak eski bağlantıları kendiliğinden taşımaz.

HTTPS ve www sürümlerinin birleştirilmesi: HTTP iletişimini TLS ile şifreleyen HTTPS kalıcı ana sürüm seçildiyse HTTP URL'leri karşılık gelen HTTPS URL'lerine yönlendirilebilir. Benzer biçimde www kullanılan ve kullanılmayan sürümlerden biri ana sürüm seçilebilir. Kuralların ters yönlerde birbirini tetiklememesi ve yolu-sorguyu yanlışlıkla kaybetmemesi gerekir.

İçerik birleştirme: İki benzer sayfa tek bir güncel içerikte birleştirildiyse eski sayfa, kullanıcının amacını karşılayan birleşik hedefe gönderilebilir. İçerik kaldırılmış ve gerçek bir karşılık yoksa 404 Bulunamadı veya 410 Artık Yok yanıtı, alakasız bir 301 yönlendirmesinden daha doğru olabilir.

HTTP'den HTTPS'ye Geçişte 301 Ne Yapmaz?

HTTP adresinden HTTPS adresine verilen 301, ilk şifresiz isteği geriye dönük olarak korumaz; yalnız istemciye sonraki hedefi bildirir. HTTPS hedefinde geçerli alan adı kapsamına sahip sertifika, eksiksiz zincir ve desteklenen TLS yapılandırması bulunmalıdır. Sayfadaki görsel, betik, stil ve form hedefleri de HTTPS'ye güncellenmelidir.

HSTS (HTTP Strict Transport Security), tarayıcıya bir alan adı için yalnız HTTPS kullanmasını söyleyen güvenlik politikasıdır; tarayıcı politikayı öğrendikten sonra HTTP girişimlerini ağ isteğinden önce HTTPS'ye yükseltir. HSTS, 301'in yerine geçen bir içerik taşıma kuralı değildir; yanlış veya ulaşılamayan HTTPS yapılandırmasını da düzeltmez. Uzun süreli ve alt alanları kapsayan bir HSTS politikası, HTTPS yolu kararlı olmadan açılmamalıdır.

Öndeki CDN veya ters proxy TLS'yi sonlandırıyorsa, uygulamanın özgün isteğin HTTPS olduğunu güvenilir biçimde öğrenmesi gerekir. Aksi halde öndeki katman HTTPS'ye, uygulama yeniden HTTP'ye yönlendirme üretip döngü oluşturabilir. İletilen protokol başlıkları yalnız güvenilir proxy'den kabul edilmelidir.

URL Eşleştirmesi Nasıl Hazırlanır?

Toplu taşıma öncesinde eski URL ile yeni URL'yi satır satır eşleştiren bir liste hazırlanmalıdır. Yalnız yol benzerliğine dayanan geniş kapsamlı düzenli ifadeler; kodlanmış karakterlerde, dil yollarında, sorgu parametrelerinde veya aynı ada sahip farklı içeriklerde yanlış hedef üretebilir.

• Her eski URL'yi kullanıcı amacını karşılayan en yakın yeni sayfayla eşleştirin.
• Hedef URL'nin 2xx sınıfındaki beklenen başarı yanıtını ve doğru içeriği verdiğini doğrulayın.
• Yol, sorgu parametreleri ve # sonrasındaki fragment’ın (parça tanımlayıcısının) yeni hedefte nasıl kullanılacağını ayrı belirleyin.
• Geçersiz veya güvenlik açısından sakıncalı parametreleri hedefe körlemesine taşımayın.
• Çok dilli ve mobil URL sürümlerini kendi doğru karşılıklarına gönderin.
• Eski URL'nin doğrudan son hedefe gittiğini otomatik denetimle sınayın.

Sorgu parametrelerinin korunması 301 kodunun kendiliğinden sağladığı bir özellik değildir; sonucu yönlendirme kuralının ürettiği Location değeri belirler. Hedefte zaten sorgu varsa eski sorgunun eklenmesi, değiştirilmesi veya atılması platforma ve kurala göre farklı davranabilir.

Parça tanımlayıcısı sunucuya gönderilen HTTP isteğinde yer almaz; sunucu gelen istekteki # sonrasını okuyarak yönlendirme seçemez. Location parça tanımlayıcısı içermiyorsa istemci eski adresteki parçayı yeni hedefte korur; hedef açıkça bir parça içeriyorsa onu kullanır. Bu nedenle sayfa içi bölüm bağlantıları tarayıcıda da sınanmalıdır.

Yönlendirme Zincirleri ve Döngüler Neden Sorun Çıkarır?

Eski URL'nin ara bir adrese, onun da başka bir adrese yönlenmesi zincir oluşturur. Her adım gecikme ekler, hata yüzeyini büyütür ve günlük incelemesini zorlaştırır. Alan adı taşıması, HTTP-HTTPS birleştirmesi ve yol değişikliği aynı anda yapılacaksa kurallar tek adımda son birleşik URL'yi üretmelidir.

Döngüde bir URL başka bir URL'ye, ikinci URL de yeniden ilkine veya daha önceki bir adıma yönlendirir. Son içerik açılmaz; tarayıcı çoğunlukla “çok fazla yönlendirme” hatası gösterir. Koşulların hem kaynak hem hedefte aynı anda çalışması, öndeki proxy ile uygulamanın birbirini ters yönde yönlendirmesi veya TLS sonlandırma bilgisinin yanlış anlaşılması döngü oluşturabilir.

CDN, ters proxy ve uygulama katmanlarının her biri yönlendirme üretebilir. Sorun giderirken yalnız son görünen koda değil, zincirdeki her Location değerine ve isteğin hangi katmandan geçtiğine bakılmalıdır.

301 ile Sunucu İçi Yeniden Yazma Aynı Şey midir?

301, istemciye görünen dış yönlendirmedir. Tarayıcı yeni URL'ye istek gönderir ve adres çubuğu değişir. Sunucu içi yeniden yazmada ise istek başka bir dosyaya, uygulama yoluna veya işleyiciye aktarılabilir; istemci aynı URL'de kalır ve çoğu durumda 3xx yönlendirme yanıtı görmez.

Apache, Nginx, CDN veya uygulama çerçevesindeki bir “rewrite” özelliği yapılandırmaya göre iç yeniden yazma ya da dış yönlendirme üretebilir. Özelliğin adı yerine gerçek HTTP durum kodu, Location başlığı ve tarayıcının yeni istek gönderip göndermediği kontrol edilmelidir.

Arama Motoru ve Site Taşıması Açısından Neler Yapılmalı?

Kalıcı yönlendirme, eski ve yeni URL arasında güçlü bir taşıma sinyalidir; ancak görünürlük veya trafik sonucu tek başına durum koduyla garanti edilmez. Hedefin içerik bakımından uygun, erişilebilir ve dizine eklenebilir olması; site içi bağlantıların, site haritasının ve tercih edilen standart URL’yi gösteren canonical bildirimlerinin yeni URL'yi göstermesi gerekir.

Google, URL değişiklikli site taşımalarında sunucu taraflı kalıcı 301 veya 308 yönlendirmelerini ve yönlendirmelerin genel olarak en az bir yıl korunmasını önerir. Eski bağlantılar ile yer imleri kullanılmaya devam ediyorsa yönlendirmeyi daha uzun süre, hatta altyapı sürdükçe tutmak kullanıcılar açısından yararlı olabilir. Bu süre içinde eski alan adının yenilenmesi ve sertifikasının çalışması unutulmamalıdır.

Arama motorunun yönlendirmeyi görebilmesi için eski URL’ye erişebilmesi gerekir. Taşınan eski adresleri robots.txt ile taramaya kapatmayın; yeni sayfalarda da yalnız hazırlık için konmuş noindex ve tarama engellerinin kaldırıldığını doğrulayın.

Her eski URL'yi ana sayfaya yönlendirmek doğru değildir. Açık bir karşılık yoksa uygun 404 veya 410 yanıtı verilmelidir; alakasız toplu yönlendirmeler arama sistemlerince hata sayfasına benzeyen “soft 404” davranışı olarak değerlendirilebilir.

301 Kuralı Nasıl Test Edilir ve Yayına Alınır?

302 ile hedef eşleştirmesi denenebilir; ancak bu test 301’in kalıcılık ve önbellek davranışını doğrulamaz. Yeni eşleştirmeyi üretim öncesinde sınamak, küçük bir URL grubunda izlemek ve doğru hedefler kanıtlandıktan sonra bütün kuralları açmak geri dönüş riskini azaltır.

1. Eski-yeni URL eşleştirmesini üretim öncesi ortamda örneklerle değil tüm listeyle sınayın.
2. GET, HEAD ve varsa POST gibi etkilenebilecek yöntemleri ayrı deneyin.
3. İlk yanıtın 301, Location hedefinin doğru ve son yanıtın beklenen içerik olduğunu doğrulayın.
4. HTTP, HTTPS, www ve ana alan adı birleşimlerinde zincir ile döngü arayın.
5. Site içi bağlantıları, site haritasını, canonical bildirimini ve reklam-kampanya hedeflerini yeni URL'ye güncelleyin.
6. Sorgu parametrelerini, kodlanmış karakterleri ve boş ya da beklenmeyen girdileri sınayın.
7. Yayın sonrası 404 ve 410 yanıtlarını, yönlendirme (3xx), istemci hatası (4xx) ve sunucu hatası (5xx) oranlarını; en sık yönlendirilen eski URL'leri ve hedef hatalarını günlüklerden izleyin.

Açık Yönlendirme Açığı Nasıl Önlenir?

Yönlendirme hedefi kullanıcı girdisinden üretiliyorsa yalnız izin verilen alan adları ve yollar kabul edilmelidir. Kontrolsüz hedef, open redirect (açık yönlendirme) açığına dönüşebilir. Location başlığına satır sonu veya geçersiz karakter girmesine izin verilmemeli; oturum belirteci ve kişisel bilgi sorgu dizesine taşınmamalıdır.