302 ve 307 Yönlendirmesi

Kısa özet — 302 ve 307 geçici yönlendirmelerdir: şimdilik başka bir yere giderken özgün URL’nin esas URL olarak kalmasını sağlarlar. Google ikisini aynı işler; bu yüzden anlamlı bir SEO farkı yoktur. Gerçek fark tekniktir: 307, isteğin türünü korumalıdır (form gönderimi düz bir sayfa isteğine dönüşmez); 302 ise geçmişte bunun değişmesine izin verirdi. Sıradan yönlendirmelerde düz 302, form veya veri gönderen API gibi isteklerde 307 kullanın; her yerde varsayılan olarak 307 kullanmanın maliyetsiz olduğunu düşünmeyin.

302 ve 307 yönlendirmeleri gerçekte ne anlama gelir

302 ve 307 birer yönlendirmedir: bir URL’yi istersiniz ve başka bir URL’ye ulaşırsınız. Sayı, sunucunun gönderdiği HTTP durum kodudur; tarayıcılara ve arama motorlarına bir mesaj taşır.

• 302 — “Found” (geçici). Özgün geçici yönlendirmedir. “Şimdilik buraya git; eski adres hâlâ asıl adres, geri döneceğim” der.
• 307 — “Temporary Redirect”. Mesaj aynıdır — geçici, eski URL hâlâ geçerli — ancak ek bir taahhüt taşır: tarayıcı, GET (yalnızca sayfa alma) veya POST (form gibi veri gönderme) olup olmadığı dahil, isteği aynen tekrarlamalıdır.

Yani kardeş kodlardır. Bunu şöyle düşünebilirsiniz: 307, tarayıcının form gönderimini sessizce düz bir sayfa isteğine çevirmemesini de garanti eden 302’dir.

SEO açısından fark eder mi?

Çoğu site sahibinin endişelendiği anlamda hayır. Google’ın kendi belgeleri, tarayıcılarının yönlendirmeyi işleme ve takip etme biçimi bakımından 307’yi “​eşdeğer 302” olarak listeler. İkisi de “geçici” sinyaldir; bu nedenle yalnızca yönlendirme yaptığınız için Google varsayılan olarak hedefi kanonik sayfa kabul etmez. Google belgeleri 302 ve 307’nin aynı veya farklı bağlantı değeri aktarıp aktarmadığını söylemez; açıkça söyledikleri, kalıcı yönlendirmedeki gibi hiçbir kodun kaynak sinyallerini hedefe teslim etmediğidir. Biri 307’nin 302’den “daha az değer aktardığını” söylerse kaynağını isteyin — Google bunu söyleyen bir belge yayımlamadı.

Hangisini ne zaman kullanmalıyım?

• Düz 302 kullanın — mevsimsel satış sayfası, A/B testi, bakım sayfası veya ülkeye özel ana sayfaya gönderme gibi günlük geçici yönlendirmelerde.
• 307 kullanın — yönlendirilen şey veri gönderiyorsa: form gönderimi, API çağrısı, giriş veya ödeme POST’u. Burada 307’nin yöntemi ve veriyi aynen koruma sözü önemlidir; düz 302 eski bir tarayıcının POST’u GET’e çevirip veriyi düşürmesine izin verebilir.

İnsanları şaşırtan bir nokta

Bazen tarayıcınızın geliştirici araçlarında sizin ayarlamadığınız bir 307 görürsünüz. Bu genellikle gerçek bir sunucu yönlendirmesi değildir: tarayıcı, http:// bağlantısını kendi başına https:// adresine yükseltir (HSTS adlı güvenlik özelliği) ve bunu size 307 olarak gösterir. Sunucunuz bunu hiç göndermemiştir. İleri Düzey sekmesinde ayrıntılı açıklama var.

Tam resmi — spesifikasyon geçmişini, Google ve Mueller’in tam ifadelerini, HSTS “hayalet 307”yi ve geliştiricileri şaşırtan framework varsayılanlarını — görmek için İleri Düzey sekmesine geçin.

Kısa özet — 302 ve 307 geçici yönlendirmelerdir ve Google ikisini aynı işler — belgelerinde 307 “302’ye eşdeğer” olarak geçer; Mueller de geçici ve kalıcı çiftler arasında “SEO açısından pek fark etmez” demiştir. Hiçbiri hedefin kanonik olması gerektiğine dair sinyal değildir ve Google aralarında PageRank/bağlantı değeri farkını yayımlanmış bir oranla açıklamamıştır. Gerçek fark yöntemin korunmasıdır: otomatik 307 takibi aynı HTTP yöntemini korumalıdır (POST yöntemi değişmeden kalır); 302 istemcinin POST’u GET’e çevirmesine izin verir — gövdenin her baytı, kimlik bilgileri ve kaynaklar arası davranış yine istemciye bağlıdır, varsaymak yerine doğrulayın. Yöntem kaybı sorun çıkaracaksa API, form, POST/webhook/ödeme/kimlik doğrulama akışlarında 307 kullanın; ancak idempotent olmayan yeniden oynatma riskine dikkat edin (yönlendirilen ödeme veya sipariş çağrısı yeniden gönderilebilir). Sıradan GET yönlendirmelerinde, Google’ın A/B testleri için açık 302 önerisi dahil, düz 302 uygundur. **HSTS “hayalet 307”**yi (protokol garantisi değil Chrome arayüz etiketi), framework ayrıntılarını (Next.js Server Actions için 303, diğer bağlamlarda 307 belgeler — sürümünüzü kontrol edin) göz önünde bulundurun; Bing’in 302-307 ayrımı yapan bir rehberi yoktur. Geçici yönlendirmelerde kendi sıralamam 307 / 302 / 303; ancak her yerde 307 varsayılanı maliyetsiz değildir, önce önbellek başlıklarını, eski istemci desteğini ve idempotency önlemlerini kontrol edin.

İkisi de geçici — başlangıç noktası bu

Önce şunu netleştirelim: 302 ve 307 aynı kategoridedir. Google, 302 (Found), 303 (See Other) ve 307 (Temporary Redirect) kodlarını “geçici yönlendirmeler” olarak birlikte gruplar ve üçünün davranışını aynı açıklar: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (çeviri) “Googlebot yönlendirmeyi izler, ancak dizine ekleme hattı bunu hedefin kanonik olması için sinyal olarak kullanmaz.” Basitçe, geçici yönlendirme varsayılan olarak kaynak URL’yi kanonik tutar; kalıcı yönlendirme (301/308) gibi kaynak sinyallerini hedefe vermez.

Bu, kalıcı katmanın bir altındaki birebir karşılaştırmadır: 301/308 kalıcı çifttir, 302/307 geçici çifttir ve “numarası büyük olan yöntemi korur” mantığı iki çiftte de aynıdır.

Gerçek fark: yöntem ve gövdenin korunması

Asıl önemli ayrım tek cümlede şudur: istemci 307’yi otomatik izlediğinde mevcut HTTP spesifikasyonu (RFC 9110) aynı istek yöntemini korumasını gerektirir; 302 ise istemciye POST’u GET’e çevirme serbestisi tanır. Bu, yöntem için spesifikasyon garantisidir; gövdenin her baytı, kimlik bilgileri veya kaynaklar arası davranış için genel garanti değildir — bunlar yönlendirmeyi uygulayan istemciye bağlıdır. 307’nin her durumda her şeyi aynı biçimde yeniden oynattığını varsaymak yerine gerçek bir istekle doğrulayın.

Bu belirsizliğin neden var olduğunu anlatmak önemli; çoğu yazı gerçeği söyler ama nedenini açıklamaz. HTTP/1.0 döneminde 302 metni teknik olarak istemcilerin yönlendirmeyi izlerken yöntemi değiştirmemesi gerektiğini söylüyordu; ancak ilk tarayıcılar (Netscape ve ardından herkes) bunu görmezden gelip GET dışı yöntemleri, özellikle POST’u, 302’de sessizce GET’e çevirdi. Evrensel ama tutarsız bu davranış fiilî standarda dönüştü. HTTP/1.1 (RFC 2616, 1999; sonrasında RFC 7231 ve bugünkü RFC 9110) karışıklığı bitirmek için ayrımı iki açık kodla resmileştirdi:

• 303 (See Other) — yönlendirme hedefini GET veya HEAD ile alır (yalnızca “her zaman GET” değildir; RFC 9110 iki güvenli yönteme de izin verir); POST sonrası güvenle yeniden yüklenebilen sonuç sayfasına yönlendirmenin yoludur.
• 307 (Temporary Redirect) — otomatik takipte yöntemi kesin olarak korur; spesifikasyon yine de her istemciyi yönlendirmeyi takip etmeye zorlamaz.

MDN pratik sonucu açıkça koyar: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (çeviri) “307 ile 302 arasındaki fark, yönlendirilmiş istek yapılırken 307’nin istemcinin istek yöntemini ve gövdesini değiştirmemesini garanti etmesidir. 302’de eski istemciler yöntemi hatalı biçimde GET’e çevirdi.” 307 yeni bir yetenekten çok belirsizliği kaldırdı: düzgün davranan bir 302’nin baştan beri yapması gerekenin spesifikasyonla garanti edilen biçimidir. Güncel tarayıcılar Netscape dönemindeki karmaşadan çok daha tutarlı olsa da 307, belirsizliği teamül yerine spesifikasyonla ortadan kaldırır.

Yan yana:

İki hassas noktayı ayırın: RFC’nin 302’de dönüşe izin verdiği yöntem POST’tur, her yöntem değil — kendi istemcinizi kontrol etmeden “302 always breaks PUT/DELETE” (çeviri) “302 her zaman PUT/DELETE’i bozar” diye genelleme yapmayın. Ayrıca hiçbir kod yalnızca durum kodu nedeniyle varsayılan olarak önbelleğe alınabilir değildir: RFC 9111, yalnızca durum kodundan sezgisel biçimde önbelleğe alınabilenler arasında 302 veya 307’yi saymaz. Önbellekleme, seçtiğiniz yönlendirme koduna değil açık Cache-Control/Expires başlıklarına bağlıdır.

Kendi Ahrefs tanımım da yöntem koruma noktasını aynı anlatır: “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (çeviri) “307 yönlendirmesi 302 yönlendirmesiyle aynıdır; farkı, yönlendirme yapılırken özgün isteğin HTTP yöntemini (POST, GET) korumasıdır.”

Google, SEO açısından 302 ve 307’yi farklı ele alır mı?

Hayır — Google bu konuda alışılmadık derecede açıktır. 301-vs-308 konusu gibi bu da yerleşmiş ve tartışması düşük bir noktadır.

Google’ın HTTP durum kodları belgelerinde 302 satırı, tarayıcılarının yönlendirmeyi izleyip hedefin işlenmesi için zayıf sinyal kullandığını söyler; 307 satırı ise kelimesi kelimesine “Equivalent to 302.” (çeviri) “302’ye eşdeğer.” der. Google ardından şu uyarıyı ekler: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (çeviri) “Google bu durum kodlarını aynı işlese de anlamsal olarak farklı olduklarını unutmayın. Diğer istemciler yararlanabilsin diye yönlendirmeye uygun durum kodunu kullanın.”

Bu, tarayıcı işleme yanıtıdır. Googlebot’un yönlendirmeyi nasıl alıp izlediği bakımından ikisini aynı işler ve Google dışı istemcilerin doğru davranması için anlamsal olarak doğru kodu seçmenizi ister. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Burada dikkat edilmesi gereken bir nüans var: tarayıcı işleme eşdeğerliği, dizine ekleme sonucuyla aynı iddia değildir. Google’ın Yönlendirmeler ve Google Arama belgesi 302, 303 ve 307’yi “geçici yönlendirmeler” altında toplar ve “dizine ekleme hattının yönlendirmeyi hedefin kanonik olması için sinyal olarak kullanmadığını” söyler. Bu gerçek ve yararlı bir garantidir; ancak kaynak URL’nizin sıralamayı koruyacağı veya hedefin başka sinyallerle hiç dizine giremeyeceği sözü değildir. “302 ve 307 aynı işlenir” ile “ikisi de hedef için kanonik sinyal değildir” ifadelerini iki ayrı, birlikte doğru iddia olarak ele alın; Google belgelerinin söylemediği biçimde iki kodun PageRank ya da bağlantı değerini birebir eşitlediğinizi iddia etmeyin.

John Mueller de aynı şeyi kendi sözleriyle anlatır. Search Off the Record programının “Let’s talk redirects” bölümünde Martin Splitt, 301 ve 302’nin yanında 307 ve 308’in neden var olduğunu doğrudan sorar. Mueller şöyle der: “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (çeviri) “Bunu yakın zamanda araştırmam gerekti. Genellikle 301 ve 302 ile iletilenler GET istekleridir.” … “And with 307, 308, it also forwards POST requests.” (çeviri) “307 ve 308 ile POST istekleri de iletilir.” Ardından SEO sorusunu netleştirir: “I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (çeviri) “Bence SEO açısından pek fark etmez. Daha çok API’lerde çalışıp çalışmadığı sorusudur. API’lerin doğrudan Search’te dizine eklenmesi genellikle gerekmez.”

Bu çerçevenin anlamı şu: 302 yerine 307 seçmenin tek nedeni işlevsellik sorusudur (“API’lerde çalışıyor mu?”); sıralama değildir. İki koddan birinin SEO avantajı olduğunu söyleyen güvenilir birincil kaynak yoktur.

Bing, 302 ve 307’yi farklı ele alır mı?

Açıkçası: Bing bunu söylemedi. Bing’in herkese açık yönlendirme rehberleri (2011 tarihli “Yönlendirmeleri yönetme — 301’ler, 302’ler ve canonical” yazısı ve 2020 tarihli “Bing ile web sitesi taşıma” yazısı) yalnızca kalıcı 301-geçici 302 ayrımını ele alır; 307 veya 308 adını hiç anmaz. Fabrice Canel’in doğrudan açıklama yaptığı 301-vs-308 konusunun aksine, 302-vs-307 hakkında Bing temsilcisine ait bir ifade bulamadım.

Bu nedenle eşitlik varsaymak yerine açık söyleyeyim: Bing’in 302 ile 307’yi özel olarak ayıran bir açıklaması yok. Geçici yönlendirme tartışması için bilinmesi gereken belgeli bir Bing davranışı var: Bingbot aynı 302’yi art arda yeterince kez görürse onu 301 gibi ele almaya ve sinyalleri ileri birleştirmeye başlar; ancak Bing bu davranışın tekrarlanan 307’ler için de geçerli olduğunu kamuya açık biçimde doğrulamadı. Bunu 307 hakkında gerçek bir belge boşluğu olarak görün, 307’nin davranışına dair gerçek olarak değil.

307 teknik olarak ne zaman doğru seçimdir

Özgün yöntemi veya gövdeyi kaybetmek bir şeyi bozacaksa:

• API’ler ve webhook uç noktaları — yöntemi ve yükü korunarak yeni URL’ye ulaşması gereken bir POST/PUT/DELETE isteği.
• Form gönderimleri (POST akışları) — Mueller’in ifadesiyle: “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (çeviri) “Bir alan adında formunuz varsa ve sonuçlar başka bir alana iletiliyorsa — neredeyse bozuk bir kurulum diyeceğim — 307 veya 308 kullanırsınız.”
• Ödeme, satın alma ve giriş/kimlik doğrulama POST geçişleri — gövdenin sessizce düşmesi işlemi başarısız kılacak her yer.

Bir güvenlik notu: 307’nin yöntemi koruma garantisi iki taraflıdır. Özgün istek idempotent değilse — ödeme alma, sipariş gönderme veya yan etkisi olan başka bir işlem — otomatik 307 takibi aynı isteği yeni URL’de yeniden oynatır. Genellikle istediğiniz budur; ancak istemci yeniden denemesi veya yönlendirme zinciri idempotent olmayan çağrıyı birden fazla kez gönderebilir. Yeniden oynatmanın güvenli olduğunu varsaymak yerine alıcı uç noktaya idempotency anahtarı ve yinelenen gönderim kontrolü ekleyin.

Geliştiricilerin 307’yle seçmeden karşılaşmasının önemli bir nedeni, bazı framework ve edge platformlarının GET dışı isteklerde yöntemi koruyan kodu varsayılan almasıdır. En açık belgeli örnek Next.js’tir: güncel API referansına göre redirect(), Server Action içinden çağrıldığında 303, diğer desteklenen bağlamlarda 307 döndürür. Bu nedenle tek kodun framework’ün her yerinde geçerli olduğunu varsaymak yerine Next.js sürümünüzün belgelerini kontrol edin. Diğer framework, CDN ve yük dengeleyiciler ürüne ve sürüme göre değişir; benzer görünen bir platformla aynı yanıtı vereceğini varsaymadan gerçek durum kodunu doğrulayın. Beklenmedik 307 veya 303 çoğu zaman platformun yöntemi bilinçli ele aldığını gösterir; yine de kendi kurulumunuzda doğrulayın.

302 ne zaman pratik varsayılandır

Düz GET isteklerindeki standart geçici yönlendirmeler — korunacak bir yöntem yoktur, dolayısıyla 307 garantisi burada ek bir şey kazandırmaz:

• Bölge/dil yönlendirmeleri (içeriği bölgeye göre tamamen engellememe uyarısıyla).
• A/B ve bölünmüş testler — Google’ın website-testing rehberi, yönlendirilen test varyantlarında yönlendirmenin geçici olması nedeniyle 301 yerine açıkça 302 kullanılmasını söyler.
• Bakım modu / “yakında döneceğiz” yönlendirmeleri — ancak ziyaretçiyi gönderecek gerçek bir kaynak varsa; sitenin tamamı kullanılamıyorsa Google’ın kendi rehberi yönlendirme yerine 503 (service unavailable) düşünür. Yönlendirilen şey GET dışı bir istekse — bakım sayfanıza giden ödeme veya API çağrısı gibi — 307 bu isteği yeni URL’de yeniden oynatır; yan etkili çağrılarda bu otomatik olarak güvenli değildir, alışkanlıkla 307 seçmeyin.
• Mobil↔masaüstü (m-dot) yönlendirmeleri — Mueller’in 302’nin özellikle doğru kod olduğunu söylediği örnek: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (çeviri) “Bir dahaki gelişinde kişinin mobil sürümü mü masaüstü sürümü mü istediğini gerçekten bilemeyeceğiniz için 302 yönlendirmesi doğru seçim olur.” Doğru hedef ziyaretçiye bağlıdır; bu kalıcı bir taşıma değildir.

HSTS “hayalet 307” — sunucunuzun hiç göndermediği 307

Bu bölüm ayrı olmalı; yönlendirme kodu seçmekten tamamen farklı bir konudur ve ikisini karıştırmak yönlendirme zincirlerini incelerken gerçek kafa karışıklığı yaratır.

Site HTTPS üzerinden HSTS başlığı (Strict-Transport-Security) gönderirse tarayıcı bunu hatırlar. Daha sonra http:// sürümüne gitme denemesinde isteği kendi başına https://’ye yükseltir; URI ağ üzerinden istek gönderilmeden önce değiştirilir. Chrome’un güncel sürümleri bu dahili yükseltmeyi DevTools’ta 307 olarak gösterir, ancak sunucu hiçbir şey göndermemiştir. Tam etiket, bayt sayısı veya başlık sunumu Chrome sürümüne özgü arayüz davranışıdır; HTTP veya HSTS spesifikasyonunun gereği değildir. “307”yi her tarayıcıda veya gelecekteki her sürümde garanti edilen etiket saymayın. John Mueller kendi sitesinde bunu şöyle açıklar: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (çeviri) “HTTPS URL’sini HSTS başlığıyla gördükten sonra (örneğin HTTP sürümünden gelen herhangi bir yönlendirmeyle), HTTP sayfasına bir sonraki erişim denemenizde Chrome bunu 307 yönlendirmesi görüyormuş gibi ele alır.” Ardından kritik açıklama gelir: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (çeviri) “Sunucunuz 307 döndürmüyor; Chrome yönlendirmeyi sizin için yaptığını açıklamak üzere size öyle gösteriyor.”

Kendi durum kodları yazımımda aynı noktayı işaretledim: “307 HSTS Policy” (“istemciyi HTTPS kullanmaya zorlar”) anlamı, “307 Temporary Redirect” anlamından ayrıdır. SEO nüansı da şudur: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (çeviri) “Web sunucuları istemcilerin yalnızca HTTPS bağlantıları kullanmasını istediğinde (HSTS politikası), 307 tarayıcıda önbelleğe alındığı için Google onu görmez.” Ağ sekmenizde hiç yapılandırmadığınız bir 307 görürseniz yanlış yönlendirme kuralı aramadan önce bunun HTTP→HTTPS yükseltmesini yapan HSTS olup olmadığını kontrol edin.

Yaygın efsaneler

• “307, 302 ile aynı SEO değerini aktarmıyor.” Desteksiz bir iddia — Google’ın kendi belgeleri yönlendirmenin işlenmesi bakımından 307’yi “302’ye eşdeğer” sayar ve iki kodu da hedefi kanonik yapma sinyali olarak görmez. Ancak Google hiçbir kod için kesin PageRank/bağlantı değeri formülü yayımlamadı; bu yüzden her iki yönde de eşit veya eşit olmayan belirli bir aktarım oranı iddia etmeyin. Doğru ifade, Google’ın ikisini aynı işlemesidir; aktarılan değeri nicelendirdiği değil.
• “302 is the safer/recommended choice because it’s clearer how search engines treat it.” (çeviri) “Arama motorlarının onu nasıl işlediği daha açık olduğu için 302 daha güvenli veya önerilen seçimdir.” Abartılı. Google’ın 307 işlemesi de aynı şekilde belgelenmiştir (“302’ye eşdeğer”); bir kodun arama motorlarınca daha iyi anlaşıldığı bir durum değildir. 307’nin yöntemi/gövdeyi koruma garantisi işlevsel bir avantaj sağlar. (Bazı üçüncü taraf rehberler tersini söyler; kaynaklar sekmesindeki nota bakın.)
• “Tarayıcımdaki Ağ sekmesinde 307 görüyorsam sunucum yanlış yapılandırılmıştır.” Çoğu zaman yanlış — HSTS açıksa ve HTTPS sürümünü daha önce yüklediyseniz bu 307, sunucu yanıtı değil Chrome’un kendi HTTP→HTTPS yükseltmesidir.
• “302’ler her zaman POST’u GET’e çevirir; form için asla 302 kullanmayın.” Güncel tarayıcılar için abartılı. POST→GET dönüşümü eski istemcilerde gerçek ve belgelenmiş bir sorundu; 307’nin garantili seçenek olarak var olma nedeni budur, bugün her 302’nin POST verisini düşürdüğünün kanıtı değil. 302 evrensel olarak bozuk değil, belirsizdir.
• “Sıralama kazanmak için tüm geçici yönlendirmeleri 307’ye çevirin.” Yanlış ve gereksiz değişiklik. Sıralama avantajı yoktur. 307’yi seçmenin geçerli nedeni yöntem/gövdeyi gerçekten koruma ihtiyacı (veya geleceğe dönük genel güvenlik)tir.
• “303 ve 307 temelde aynıdır.” Hayır — 303 takip isteğini açıkça GET’e çevirir (POST sonrası sonuç sayfası için tasarlanmıştır); 307 özgün yöntemi ve gövdeyi korur. Aynı listede görünmeleri karıştırılmalarına yol açar.

Önerim

Geçici yönlendirmelerde tercih ettiğim uygulama sırası 307 / 302 / 303; meta refresh (0) ve HTTP refresh (0) bunun arkasında gelir. Aslında 307’yi 302’nin üstüne koyuyorum — SEO’ya yardım ettiği için değil, yöntemi koruyan kodu her zaman kullanırsanız daha sonra form veya API yönlendirdiğiniz gün kod değiştirmeniz gerekmeyebilir. Düz GET yönlendirmesi 307 ile de çalışır ve sonradan kapsama sahip olursunuz. Bu bir eksiksizlik argümanıdır, maliyetsiz bir seçim değil: 307 varsayılanı da her yönlendirme gibi cache-control disiplinine, desteklediğiniz eski istemcilerde çalışmaya ve GET dışı hedeflerde idempotency önlemlerine ihtiyaç duyar. Mueller aynı eksiksizlik fikrini şöyle ifade etti: “if you always use them, then you’re always safe.” (çeviri) “Onları her zaman kullanırsanız her zaman güvendesiniz.” Bununla birlikte düz 302 tamamen uygundur; özel m-dot durumunda teknik olarak daha doğru kod 302’dir.

Bu konu nereye oturuyor

302 ve 307 geçici 3xx yönlendirme kodlarından ikisidir; bu kümede her birinin ayrı derinlemesine makalesi, kalıcı çift 301/308, her zaman GET kardeşi 303 ve kardeş karşılaştırmaları (bir üst katmandaki aynı yöntem-koruma mantığına sahip 301-vs-308 ile kalıcı-geçici 301-vs-302) bulunur. Ayrıca operasyonel tehlikeler, yönlendirme zincirleri ve döngüler ele alınır. Sunucu yanıtlarının tamamı için HTTP Durum Kodları merkezine bakın; yönlendirme türü, kanonikleştirme sayfasında anlatılan kanonikleştirme sinyallerinden biridir.

Yapay zekâ özeti

İleri Düzey sürümün kısaltılmış özeti:

• İkisi de geçici yönlendirmedir. 302 ve 307, kalıcı 301/308 gibi kaynak sinyallerini hedefe vermeden varsayılan olarak kaynak URL’yi kanonik tutar.
• Google ikisini aynı işler. Belgelerinde 307’nin “302’ye eşdeğer” olduğu, Mueller’in ise “for SEO, it doesn’t really matter.” (çeviri) “SEO açısından pek fark etmez.” dediği görülür. Bu tarayıcı işleme iddiasıdır; PageRank/bağlantı değeri formülü değildir. Google iki kod için kesin eşit veya eşit olmayan aktarım oranı yayımlamadı; “aynı işleniyor” ifadesi kaynağın mutlaka sıralamayı koruyacağı veya hedefin başka sinyallerle dizine giremeyeceği anlamına gelmez.
• Gerçek fark yöntemin korunmasıdır. Otomatik 307 takibi aynı yöntemi korur (POST yöntemi korunur); 302 istemcinin POST’u GET’e çevirmesine izin verir. 307, bu belirsizliği kapatmak için HTTP/1.1’de (RFC 2616 → 7231 → 9110) eklendi; ancak gövdenin her baytı, kimlik bilgileri ve kaynaklar arası davranış istemciye bağlıdır ve RFC’nin dönüş izni özellikle POST’u adlandırır, her GET dışı yöntemi değil.
• 307 kullanın — API, form, POST/webhook/ödeme/kimlik doğrulama akışlarında; ancak idempotent olmayan yeniden oynatmaya (ödeme veya sipariş çağrısının yönlendirmeyle tekrarlanmasına) dikkat edip idempotency önlemleri ekleyin. 302 kullanın — düz GET yönlendirmelerinde, bölge/dil, Google’ın A/B testleri için açık önerisi ve (Mueller’in örneği) mobil↔masaüstü yönlendirmelerinde. Bakım yönlendirmesi gerçek bir kaynak olup olmamasına bağlıdır; tam kesinti için 503 çoğu zaman daha doğrudur.
• Framework varsayılanları sürüm ve bağlama bağlıdır. Next.js Server Actions için 303, başka bağlamlarda 307 belgeler; kendi sürümünüzü kontrol edin, diğer framework ve CDN’lerin aynı davrandığını varsaymayın.
• HSTS “hayalet 307”: Ağ sekmesindeki 307, Chrome’un HSTS nedeniyle HTTP’yi kendi başına HTTPS’ye yükseltmesi olabilir; sunucu yanıtı değildir. “307” etiketinin tam biçimi Chrome sürümüne özgü arayüz tercihidir, HTTP/HSTS spesifikasyonunun gereği değil. Mueller: “Sunucunuz 307 döndürmüyor; Chrome yönlendirmeyi sizin için yaptığını açıklamak üzere size öyle gösteriyor.”
• Bing: 302-vs-307 ayrımı yapan bir rehber yoktur; tekrarlanan 302’nin 301 gibi ele alınması davranışının 307 için de geçerli olduğunu varsaymayın.
• Hiçbir kod yalnızca durumundan dolayı varsayılan olarak önbelleğe alınmaz (RFC 9111); açık Cache-Control/Expires başlıkları gerekir.
• Patrick’in tercih sırası: meta/HTTP refresh yerine 307 / 302 / 303; yine de her yerde 307 varsayılanının maliyetsiz olmadığını bilip önbellek başlıklarını, eski istemci desteğini ve idempotency önlemlerini kontrol edin.

Resmî belgeler

Birincil kaynak belgeleri ve spesifikasyonlar.

Google

• HTTP durum kodları, ağ ve DNS hataları ve Google Arama — 302’nin “zayıf sinyal” satırı, 307’nin “302’ye eşdeğer” satırı ve “anlamsal olarak farklı — uygun kodu kullanın” uyarısı.
• Yönlendirmeler ve Google Arama — 302, 303 ve 307’yi “geçici yönlendirmeler” altında toplar ve kanonikleştirmeyi açıklar.
• Search Off the Record, 51. bölüm — “Let’s talk redirects” (John Mueller + Martin Splitt) — 307/308’in neden var olduğunu ve ne zaman önemli olduklarını anlatan kayıt.
• John Mueller — 301, 302, 307 ve diğer yönlendirmeler için arama motoru rehberi — 302 dizine ekleme davranışı (kaynak URL “R” genellikle dizine girer; yönlendirme önbelleğe alınmaz).
• John Mueller — 307s — HSTS “hayalet 307” açıklaması.

Bing / Microsoft

• Yönlendirmeleri yönetme – 301’ler, 302’ler ve canonical (Ekim 2011) — Bing’in kalıcı için 301, geçici için 302 yaklaşımı (307’den söz etmez).
• Bing ile web sitesi taşıma (Aralık 2020) — genel site taşıma rehberi (yine 307’ye özgü bir ifade yok).

Spesifikasyonlar

• MDN — 307 Temporary Redirect — yöntem/gövde koruma tanımı ve eski istemcilerin yöntemi GET’e çevirmesine dair tarihçe.
• RFC 9110 — HTTP Semantics — §15.4.8 “307 Temporary Redirect” ve §15.4.3 “302 Found”; iki kodun güncel spesifikasyon metni.

Kaynaktan alıntılar

Google’dan kayda geçmiş ifadeler ve spesifikasyon. Kaynak sayfa destekliyorsa her bağlantı alıntıya atlayan bir metin parçası bağlantısıdır.

Google belgeleri — 307, 302’ye eşdeğer

• “Equivalent to 302.” (çeviri) “302’ye eşdeğer.” (307 satırı) — Google Search Central. Alıntıya git
• Google’ın yukarıdaki birebir uyarısının Türkçe aktarımı: “Google bu durum kodlarını aynı işlese de anlamsal olarak farklı olduklarını unutmayın. Diğer istemciler yararlanabilsin diye yönlendirmeye uygun durum kodunu kullanın.” Alıntıya git
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (çeviri) “Googlebot yönlendirmeyi izler, ancak dizine ekleme hattı yönlendirmeyi hedefin kanonik olması için sinyal olarak kullanmaz.” (302/303/307’yi kapsayan geçici yönlendirmeler) Alıntıya git

Google’dan John Mueller (Search Off the Record, 51. bölüm — “Let’s talk redirects”; resmî döküm PDF’i, pasajla ilişkilendirilmiştir — eşleşen bağlantı metnine sahip HTML sayfası olmadığından bunlarda #:~:text= derin bağlantısı yoktur)

• Mueller’in yukarıdaki birebir açıklamasının Türkçe aktarımı: “Bunu yakın zamanda araştırmam gerekti. Genellikle 301 ve 302 ile GET istekleri; 307 ve 308 ile POST istekleri de iletilir.”
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (çeviri) “POST kullanan bir API’niz varsa veya bir alan adındaki formun sonuçları başka bir alana iletiliyorsa — neredeyse bozuk bir kurulum diyeceğim — 307 ya da 308 kullanırsınız.”
• Mueller’in yöntem korumasına ilişkin devam açıklamasının Türkçe aktarımı: “Eksiksizlik açısından bu kodları sürekli kullanmak güvenli kalmanızı sağlar. SEO açısından belirleyici bir fark yoktur; asıl soru API akışında çalışıp çalışmadığıdır ve API’lerin doğrudan Search’te dizine eklenmesi genellikle gerekmez.”
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (çeviri) “Bu tür (mobil/masaüstü) yönlendirmede teknik açıdan 302 doğru olur; çünkü kişi bir sonraki gelişinde mobil sürümü mü masaüstü sürümü mü istediğini gerçekten bilemezsiniz.” Döküm PDF’i

Google’dan John Mueller (johnmu.com — HSTS “hayalet 307”)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (çeviri) “HTTPS URL’sini HSTS başlığıyla gördükten sonra Chrome, HTTP sayfasına bir sonraki erişimde bunu 307 yönlendirmesi görüyormuş gibi ele alır.”
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (çeviri) “Sunucunuz 307 döndürmüyor; Chrome yönlendirmeyi sizin için yaptığını açıklamak üzere size öyle gösteriyor.” Yazıyı oku

MDN — yöntemi koruma farkı

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (çeviri) “307 ile 302 arasındaki fark, yönlendirilmiş istek yapılırken 307’nin istemcinin istek yöntemini ve gövdesini değiştirmemesini garanti etmesidir. 302’de eski istemciler yöntemi hatalı biçimde GET’e çevirdi.” Alıntıya git

Hangi geçici yönlendirme: 302 mi 307 mi?

İkisi de geçici ve SEO açısından eşdeğer olduğuna göre karar tek soruya iner — yönlendirilen istek korumanız gereken bir yöntem veya gövde taşıyor mu?

“Emin değilim” yoluna dair not: Google 307’yi 302 ile aynı işler ve düz GET yönlendirmelerinde de sorunsuz çalışır; varsayılan olarak 307 seçmek yanlış değildir. Ancak bunun maliyetsiz olduğunu varsaymayın. Önbellek başlıklarınızı doğrulayın, desteklediğiniz eski istemcilerin 307’yi öngörülebilir biçimde ele aldığını kontrol edin ve yönlendirilen isteğin (API’ye GET dışı çağrı gibi) yan etkileri varsa idempotency önlemi olmadan otomatik 307’nin onu yeniden oynatmasına izin vermeyin.

Kaçınılacak geçici yönlendirme hataları

307’nin sözde daha az değer aktarması nedeniyle 302 seçmek

Google, arama bakımından 307’yi 302’ye eşdeğer belgeler. Seçimi sıralamaya göre değil istek davranışına göre yapın.

302 daha eski olduğu için her zaman daha güvenli varsaymak

Eski istemciler 302’nin yöntem davranışını belirsiz hale getirdi. Bir POST, PUT, DELETE, webhook veya API gövdesi korunacaksa açık koruma garantisi için 307 kullanın.

Her DevTools 307’sini sunucu kuralı sanmak

Sunucu hiç döndürmemiş olsa bile Chrome dahili HSTS yükseltmesini 307 olarak gösterebilir. Yönlendirme ayarını değiştirmeden önce isteği sunucu tarafı bir denetleyiciyle veya curl ile tekrarlayın.

Her 302’nin POST’u GET’e çevirdiğini iddia etmek

Tarihsel davranışa izin verilir ve davranış belirsizdir; her güncel istemcide garanti edilmez. Kesinlik gerektiğinde 307 kullanın; tüm 302 uygulamalarını bozuk diye tanımlamayın.

SEO kazancı için her 302’yi 307 ile değiştirmek

Sıralama avantajı yoktur. Yöntem/gövdeyi korumak doğruluğu artırıyorsa veya framework’ün daha güvenli varsayılanı uygunsa kodu değiştirin.

303 ile 307’yi karıştırmak

Yöntem bakımından işlevsel karşıtlardır: 303 takip isteğini bilerek GET’e çevirir; 307 özgün yöntemi ve gövdeyi korur.

Beklenmedik 307’yi veya bozuk 302 akışını teşhis edin

DevTools açıklanamayan Internal Redirect / 307 gösteriyor

Belirti: http:// gezinmesi Chrome’da 307 olarak görünür, ancak hiçbir yönlendirme kuralı yoktur.

Olası neden: HSTS, sunucuya ulaşmadan önce isteği tarayıcı içinde yükseltmiştir.

Çözüm: Girdinin başlatıcısını ve başlıklarını kontrol edin; ardından yönlendirmeleri otomatik takip etmeyen bir sunucu tarafı araçla HTTP URL’sine doğrudan istek gönderin — tarayıcıyla değil, çünkü yeni bir Gizli pencere bile önceden yüklenmiş HSTS durumunu uygulayabilir. curl’u da otomatik olarak tarafsız temel kabul etmeyin; kendi HSTS deposu yapılandırılmış olabilir, nasıl çağırdığınızı not edin. Ham sunucu yanıtı DevTools’tan farklıysa “hayalet 307’yi düzeltmeyin”; gerçek HTTP→HTTPS sunucu yönlendirmesini ayrıca denetleyin ve GET dışı her isteği kontrollü bir test olarak yeniden oynatın — otomatik takip eden HEAD isteği POST/gövde davranışını kanıtlayamaz.

Geçici yönlendirmeden sonra POST gövdesini kaybediyor

Belirti: Bir form, webhook, giriş veya API çağrısı hedefe GET olarak ya da gövdesiz ulaşıyor.

Olası neden: Kaynak, istemcinin yöntemi değiştirmesine izin veren 302 kullanmıştır veya bir aracı yanıtı yeniden yazmıştır.

Çözüm: Geçici taşıma için 307 kullanın; ardından güvenli bir test isteğini yeniden oynatıp hedef günlüklerinde yöntemin, içerik türünün ve gövdenin eksiksiz ulaştığını doğrulayın.

Genel yönlendirme seçtiğiniz halde platform 307 gönderiyor

Belirti: Bir framework veya edge platformu beklenen 302 yerine 307 döndürüyor.

Olası neden: Platform, çoğu zaman GET dışı istek için yöntemi koruyan geçici kodu seçmiştir.

Çözüm: Taşımanın gerçekten geçici olduğunu ve isteği korumanın doğru olduğunu doğrulayın. Öyleyse kodu bırakın — Google ikisini aynı işler. Yalnızca uygulama anlamı veya istemci uyumluluğu farklı bir yanıt gerektiriyorsa değiştirin.

302 ve 307 bir bakışta

Pratik kural: sıradan geçici sayfa GET yönlendirmesinde ikisi de çalışır; sağlam biçimde ulaşması gereken geçici GET dışı istekte 307 kullanın.

Aldığınız gerçek yönlendirmeyi belirleme araçları

Patrick’in ücretsiz aracı

• Bulk HTTP Status Code Checker — 500’e kadar URL için sunucu tarafı istekler gönderip gerçek kodları ve zincirleri inceleyin. Sunucu yanıtlarını Chrome’un yalnızca HSTS kaynaklı dahili 307 gösteriminden ayırmak için özellikle kullanışlıdır.

İstek davranışını inceleme

• Redirect Checker — tek bir kaynağı her sıçramada izleyip sunucunun 302 veya 307 ile başlayıp başlamadığını doğrulayın.
• Browser DevTools Network panel — başlatıcıyı ve Chrome’un bir girdiyi dahili yönlendirme olarak etiketleyip etiketlemediğini inceleyin; tek başına sunucu yanıtının kanıtı saymayın.
• curl ve uygulama günlükleri — staging’de güvenli bir POST gönderip hedefin aynı yöntem ve gövdeyi aldığını doğrulayın; curl’u kendi HSTS deposuyla (--hsts) yapılandırdıysanız sonucu yorumlarken bunu hesaba katın. Yalnızca durum kodu veren araçlar yükün ulaştığını kanıtlayamaz.

Kendinizi sınayın: 302 ve 307

İki geçici yönlendirme ve aralarındaki gerçek fark hakkında beş soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• Yönlendirmelerin 11 türü ve SEO etkisi (Ahrefs, Joshua Hardwick ile) — her yönlendirme türüne dair kapsamlı özetim. Geçici yönlendirmeler için tercih ettiğim uygulama sırasını 307 / 302 / 303 > meta refresh 0 / HTTP refresh 0 olarak verir ve SEO kararını açıklar: “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.” (çeviri) “SEO açısından aynıdır; ancak yönlendirilen formlardan veri gönderiyorsanız GET ile POST arasında geçiş yapmak istemezsiniz.”
• HTTP durum kodları ve SEO etkisi (Ahrefs) — 307’nin iki ayrı anlamı (Temporary Redirect ve HSTS Policy 307) ve HSTS ile “Google won’t see the 307 because it’s cached in the browser.” (çeviri) “Google, tarayıcıda önbelleğe alındığı için 307’yi görmez.” notu dahil tüm durum kodlarına referans.
• The Beginner’s Guide to Technical SEO — yönlendirmelerin daha geniş çerçevedeki yeri.

Konuşmalarım

• Patrick Stox on SlideShare ve Speaker Deck — yönlendirme ve kanonikleştirmeyi ele alan teknik SEO konuşmalarım. (Değişmeyen notum: “Sistemleri anlayışım… %100 eksiksiz veya doğru olmayabilir.”)

Resmî

• Google — HTTP durum kodları, ağ ve DNS hataları — “302’ye eşdeğer” satırı ve “anlamsal olarak farklı, uygun kodu kullanın” uyarısı.
• Google — Yönlendirmeler ve Google Arama — 302/303/307’yi geçici yönlendirmeler olarak gruplar.
• Search Off the Record — “Yönlendirmeleri konuşalım” (Google Search Relations, 51. bölüm) — yukarıdaki Mueller/Splitt alıntılarının kaynağı.

Sektörden

• John Mueller — 307s — tarayıcının gösterdiği ancak sunucunun göndermediği HSTS “hayalet 307”yi açıklar.
• MDN — 307 Temporary Redirect — yöntem/gövde koruma tanımı ve eski istemcilerin yöntemi GET’e değiştirmesine dair tarihçe.
• An SEO’s guide to redirects (Search Engine Land, Helen Pollitt) — yönlendirme ailesine dair genel teknik bakış.
• URL Redirects For SEO: A Technical Guide (Search Engine Journal) — başka bir teknik özet.
• Düzeltilmesi gereken efsane: Conductor’un “302 vs 307” sayfası 302’yi 307’nin üstünde önerir; gerekçesi “arama motorlarının 302 yönlendirmesini nasıl ele aldığı açık” ifadesidir. Bu, 307’yi açıkça “302’ye eşdeğer” sayan Google belgeleriyle çelişir — 307’nin işlemesi de aynı ölçüde belgelenmiştir. “302 is the safer SEO choice” (çeviri) “302 daha güvenli SEO seçimidir” ifadesini otorite kabul etmeyin; tek gerçek karar etkeni yöntem/gövdeyi koruyup korumamanızdır.
• r/TechSEO — yönlendirme ve kanonikleştirme hata ayıklaması topluluğu.

Değişiklik günlüğü