HTTP'den HTTPS'e Yönlendirme Nasıl Kontrol Edilir? Adım Adım Test

Biz Talha Aslan ve ekibi olarak site geçişlerinde ve teknik SEO denetimlerinde bu kontrolü ilk sıraya koyuyoruz. Çünkü sorun çoğu zaman göze görünmez: site açılır, kilit simgesi yerindedir, ama arkada iki ya da üç adımlık bir zincir, geçici bir 302 veya ana sayfaya giden toplu bir kural çalışıyordur. Hızlı bir ilk bakış için ücretsiz yönlendirme denetleyici aracımızı başka bir sekmede açık tutabilirsiniz.

Bu rehberde önce doğru sonucun neye benzediğini, sonra adım adım kontrol yöntemini, ardından HSTS, karışık içerik ve yönlendirme zinciri gibi yan konuları anlatıyoruz. Her iddia için Google Search Central, IETF standartları ve web.dev gibi birincil kaynaklara dayanıyoruz. Örneklerde alan adı olarak yalnız example.com kullanıyoruz.

HTTP'den HTTPS'e yönlendirme neden bu kadar önemli?

Bir site HTTPS'e geçtiğinde eski http adresleri internette yaşamaya devam eder. Eski bağlantılar, yer imleri, e-posta imzaları, basılı broşürlerdeki adresler ve başka sitelerden gelen linkler hâlâ http sürümünü gösterir. Dolayısıyla bu ziyaretlerin her biri yönlendirme kuralınızdan geçer.

Google'ın yönlendirme belgesine göre kalıcı yönlendirmeler, hedef adresin kanonik, yani tercih edilen sürüm olduğuna dair bir sinyaldir. Kural eksik ya da yanlışsa iki sürüm aynı anda erişilebilir kalır ve arama motoru hangisini göstereceğine kendisi karar verir. Bu durum sinyallerin bölünmesine yol açabilir.

Kullanıcı tarafında da durum benzerdir. Örneğin bir form sayfası http üzerinden açılırsa girilen bilgiler şifresiz taşınabilir. Bu yüzden yönlendirmenin yalnız ana sayfada değil, sitenin bütün adreslerinde çalışması gerekir. Sertifikanın kendisini merak ediyorsanız SSL sertifikası ve HTTPS güvenliği yazımız temeli anlatıyor.

Doğru kurulmuş bir yönlendirme nasıl görünür?

Doğru kurulum basit bir resim verir. http://example.com/hizmetler/ adresini istediğinizde sunucu 301 kodu ve Location başlığında https://example.com/hizmetler/ değerini döndürür. Ardından tarayıcı bu yeni adresi ister ve 200 kodu alır. Toplamda iki adım, tek yönlendirme vardır.

Burada üç ayrıntıya bakarsınız. İlk olarak kod kalıcı olmalıdır. Ayrıca yol korunmalıdır: /hizmetler/ adresi /hizmetler/ adresine gitmeli, ana sayfaya değil. Son olarak hedef, sitenizin tercih ettiği tek sürüm olmalıdır; www'lu mu, www'suz mu kullandığınıza önceden karar vermiş olmanız gerekir.

Örnek senaryo olarak şu iki zinciri karşılaştırın. Sağlıklı olanda http://example.com/blog/ doğrudan https://example.com/blog/ adresine gider. Sorunlu olanda ise önce https://example.com/blog adresine, sonra sondaki eğik çizgi eklenerek https://example.com/blog/ adresine gider. İkinci zincir de sonunda hedefe ulaşır, ama her ziyarette fazladan bir tur atar.

Hangi durum kodunu görmelisiniz: 301 mi, 308 mi, 302 mi?

HTTP'den HTTPS'e yönlendirme kalıcı bir değişikliktir, bu nedenle 301 ya da 308 görmelisiniz. Google'ın HTTP durum kodları belgesi 308'i 301 ile eşdeğer sayar ve ikisini de hedefin işlenmesi için güçlü sinyal olarak tanımlar. Buna karşılık Google 302, 303 ve 307 kodlarını zayıf sinyal sayar.

IETF'nin HTTP standardı RFC 9110, 301 için ilginç bir not düşer: tarihsel nedenlerle istemci, POST isteğini sonraki adımda GET'e çevirebilir. Yöntemin korunması gerekiyorsa 308 kullanılabilir. Kodların ayrıntılı farkını 301, 302, 307 ve 308 farkı yazımızda ele aldık.

HTTP'den HTTPS'e yönlendirmeyi araçla adım adım nasıl kontrol edersiniz?

Elle kontrolün en güvenilir yolu, her adımda sunucuya yeni istek atan ve durum kodlarını tek tek listeleyen bir araç kullanmaktır. Aşağıdaki sırayı kendi sitenizde uygulayabilirsiniz.

1. Yönlendirme denetleyici aracını açın ve Adres (URL) alanına http://example.com/ biçiminde, başında http olan adresinizi yazın.
2. Tek adres modunu seçin ve Denetle düğmesine basın. Zincirdeki her satırda durum kodunu, adresi ve yanıt süresini görürsünüz.
3. Yönlendirme sayısına bakın. İdeal sonuç 1'dir; 2 ve üzeri bir zincir olduğunu gösterir.
4. Tür bilgisini okuyun. Yalnız 301 ya da 308 varsa kalıcı, 302 ya da 307 görüyorsanız geçici bir kural çalışıyordur.
5. Son durum kodunun 200 olduğundan ve son adresin https ile başladığından emin olun.
6. Aynı işlemi bir alt sayfa, bir blog yazısı ve parametreli bir adres için tekrarlayın.
7. Son olarak 4 sürüm modunu çalıştırıp alan adınızın dört varyasyonunun aynı hedefte buluştuğunu doğrulayın.

Aracımız zinciri en fazla 10 adım izler. Bu sınır, Google'ın tarayıcılarının genel olarak izlediği adım sayısıyla örtüşür. Ancak meta refresh ve JavaScript ile yapılan yönlendirmeleri göstermez; çünkü yalnız sunucunun döndürdüğü durum kodlarını okur.

Dört adres sürümünü neden ayrı ayrı denetlemelisiniz?

Bir alan adının en az dört giriş kapısı vardır: http://example.com, http://www.example.com, https://example.com ve https://www.example.com. Sunucu kuralları çoğu zaman bunların bir kısmını yakalar, bir kısmını unutur. Dolayısıyla yalnız tek bir sürümü denetlemek yanıltıcı bir güven verir.

Örnek senaryo: http://example.com doğru biçimde https://example.com adresine gidiyor. Buna karşılık http://www.example.com önce https://www.example.com adresine, oradan da https://example.com adresine gidiyor. Ana sürümde sorun yoktur, ama www'lu eski linkler iki adımlık zincirden geçer.

Google'ın yönlendirme belgesi, ana sayfanız birden fazla adresten erişilebiliyorsa bunlardan birini tercih edilen adres olarak seçmenizi ve diğerlerini ona yönlendirmenizi önerir. Bu yüzden hedefiniz şudur: dört sürümün dördü de tek adımda, aynı https adresine ulaşmalı. Tercih edilen sürümün kendisi ise hiç yönlendirme yapmadan 200 döndürmelidir.

• http ve www'suz sürüm: tek 301 ile tercih edilen adrese gitmeli.
• http ve www'lu sürüm: zincirsiz, yine tek adımda aynı hedefe gitmeli.
• https ve tercih edilmeyen sürüm: tek 301 ile tercih edilen adrese gitmeli.
• https ve tercih edilen sürüm: doğrudan 200 döndürmeli.

Tarayıcı neden yanıltıcı bir sonuç gösterebilir?

Adres çubuğuna http yazıp sayfanın https olarak açıldığını görmek, kontrol için yeterli değildir. Bunun iki teknik nedeni vardır ve ikisi de resmi standartlarda yazılıdır.

Birincisi önbellektir. RFC 9110'a göre 301 yanıtı sezgisel olarak önbelleğe alınabilir. Yani tarayıcınız daha önce gördüğü kalıcı yönlendirmeyi hatırlar ve sunucuya hiç sormadan https adresine geçebilir. Sunucudaki kuralı silmiş olsanız bile sizin tarayıcınızda her şey yolunda görünür.

İkincisi HSTS'dir. RFC 6797'ye göre tarayıcı bir alan adını HSTS politikası olan site olarak tanıdıktan sonra, o alan adına giden http adreslerini istek göndermeden önce https'e çevirir. Bu durumda http isteği sunucunuza hiç ulaşmaz, yani sunucu tarafındaki yönlendirmeyi aslında test etmemiş olursunuz.

Kısacası ilk kez gelen bir ziyaretçinin ya da arama motoru tarayıcısının ne gördüğünü öğrenmek istiyorsanız, önbelleği ve HSTS kaydı olmayan bir istemciye ihtiyacınız vardır. Sunucu tarafında çalışan bir denetleyici bu yüzden daha doğru sonuç verir.

Komut satırında ya da kendi bilgisayarınızda nasıl test edersiniz?

Teknik ekipler yönlendirmeyi çoğu zaman komut satırından da kontrol eder. Mantık, aracımızla aynıdır: sunucuya yalnız yanıt başlıklarını soran bir istek gönderirsiniz ve dönen durum kodunu ile Location başlığını okursunuz. Böylece tarayıcının önbelleği ya da HSTS kaydı sonuca karışmaz.

Bu yöntemde iki noktaya dikkat edin. Birincisi, birçok komut satırı aracı yönlendirmeyi varsayılan olarak izlemez; yalnız ilk yanıtı gösterir. Zinciri görmek için aracın yönlendirmeleri izleme seçeneğini açmanız ya da her adımı elle tekrar istemeniz gerekir. İkincisi, kendi bilgisayarınızdaki DNS önbelleği ya da şirket ağınızdaki bir vekil sunucu, dış dünyadaki ziyaretçiden farklı bir sonuç üretebilir.

Bu yüzden biz komut satırı sonucunu her zaman dışarıdan çalışan bir denetleyiciyle karşılaştırıyoruz. İki sonuç aynıysa içiniz rahat olabilir. Farklıysa sorun çoğunlukla bir önbellek katmanında, içerik dağıtım ağında ya da yerel ağ ayarındadır. Örneğin içerik dağıtım ağında eski bir kural kalmışsa dış denetleyici onu görür, sizin yerel testiniz ise atlayabilir. Kısacası tek bir kaynağa güvenmek yerine iki farklı noktadan bakmak, saatler sürebilecek bir arızayı dakikalar içinde ayırt etmenizi sağlar.

Yönlendirme zinciri nedir ve kaç adım kabul edilebilir?

Yönlendirme zinciri, bir adresin son hedefe ulaşmadan önce birden fazla yönlendirmeden geçmesidir. HTTPS geçişlerinde en sık üç kaynaktan doğar: protokol kuralı, www kuralı ve sondaki eğik çizgi kuralı. Her kural kendi başına doğrudur, ama art arda çalıştıklarında zincir oluşur.

Google'ın URL değişiklikli site taşıma rehberi, doğrudan son hedefe yönlendirmenizi önerir. Bu mümkün değilse zincirdeki yönlendirme sayısını düşük tutmanızı, ideal olarak 3'ü geçmemenizi ve 5'in altında kalmanızı söyler. Ayrıca Google'ın tarayıcıları genel olarak 10 adıma kadar yönlendirme izler; bu sınırı aşan zincirlerde hedefe ulaşılamayabilir.

Pratikte biz HTTPS geçişi için tek bir hedef koyuyoruz: hiçbir sürümde birden fazla yönlendirme olmasın. Böylece hem kullanıcı her ziyarette fazladan bekleme yaşamaz, hem de arama motoru tarayıcıları boşuna fazladan istek göndermez. Zincirlerin nasıl tespit edilip birleştirildiğini yönlendirme zinciri hatası yazımızda ayrıntılı anlattık.

Yönlendirme döngüsü olduğunu nasıl anlarsınız?

Döngü, yönlendirmelerin hiçbir zaman 200 koduna ulaşmadan aynı adreslere dönüp durmasıdır. Tarayıcı bu durumda genellikle çok fazla yönlendirme olduğunu söyleyen bir hata sayfası gösterir. Denetleyici araçta ise aynı adresin zincirde iki kez geçtiğini ve sonucun hiçbir zaman 200 olmadığını görürsünüz.

HTTPS geçişlerinde döngünün tipik nedeni, iki katmanın birbirine ters kural uygulamasıdır. Örnek senaryo: bir içerik dağıtım ağı ziyaretçiyle https konuşuyor, ama sunucuya http ile bağlanıyor. Sunucu gelen isteği http sandığı için yeniden https'e yönlendiriyor, ağ da yine http ile soruyor. Sonuç sonsuz bir tur olur.

Benzer bir döngüyü, içerik yönetim sistemindeki site adresi ayarı ile sunucu kuralı birbiriyle çeliştiğinde de görürsünüz. Döngüyü çözmek için önce hangi katmanın hangi kuralı uyguladığını tek tek listeleyin. Adım adım çözüm için ERR_TOO_MANY_REDIRECTS çözümü yazımıza bakabilirsiniz.

HSTS nedir ve yönlendirmenin yerini tutar mı?

HSTS, sitenin tarayıcıya "bundan sonra beni yalnız HTTPS ile ziyaret et" demesini sağlayan bir güvenlik politikasıdır. RFC 6797'de tanımlıdır; sunucu bu politikayı yanıta eklediği Strict-Transport-Security başlığıyla iletir. Başlıktaki zorunlu max-age değeri, politikanın kaç saniye geçerli olacağını belirtir.

HSTS yönlendirmenin yerini tutmaz, onu tamamlar. Bunun nedeni standartta açıkça yazılıdır: tarayıcı bu başlığı yalnız güvenli bağlantı üzerinden aldığında dikkate alır, http üzerinden gelen başlığı yok saymak zorundadır. Yani ziyaretçinin bir kez https sayfasına ulaşması gerekir. O ilk ulaşmayı da 301 yönlendirmesi sağlar.

Standart, ilk ziyaretin bu yüzden korunmasız olduğunu da kabul eder. Tarayıcı henüz politikayı öğrenmemişse ilk istek şifresiz kanaldan gider. Bu açığı kapatmak için standart, tarayıcılara önceden yüklenen listeleri olası bir çözüm olarak anar. Ancak böyle bir listeye girmek geri alınması zahmetli bir karardır; dolayısıyla önce yönlendirmenizin ve sertifikanızın kusursuz çalıştığından emin olmalısınız.

HSTS'yi açmadan önce nelere dikkat etmelisiniz?

HSTS güçlü bir araçtır, ama hatalı yapılandırmanın etkisi de güçlüdür. Web.dev'in HTTPS rehberi, siteniz yeterince sağlam çalıştığından emin olmadan HSTS'yi açmamanızı önerir. Çünkü politikayı kaydetmiş tarayıcılar, sertifikada bir sorun çıktığında siteye erişimi tamamen kesebilir.

Bu nedenle biz şu sırayı izliyoruz:

1. HTTPS sürümünün bütün sayfalarda sorunsuz açıldığını, yönlendirme olmadan doğrulayın.
2. Ardından 301 yönlendirmesini açın ve dört sürümü denetleyin.
3. Sertifikanın geçerliliğini ve zincirini SSL sorgulama aracı ile kontrol edin.
4. HSTS'yi düşük bir max-age değeriyle başlatın ve sorun çıkmadıkça bu değeri kademeli olarak artırın.
5. includeSubDomains seçeneğini yalnız bütün alt alan adlarınızın HTTPS desteklediğinden eminseniz ekleyin.

includeSubDomains, standarda göre politikayı alt alan adlarına da uygular. Örneğin eski bir yönetim paneli ya da test alt alan adı hâlâ yalnız http ile çalışıyorsa, bu seçenek o adrese erişimi bozabilir. Ayrıca standart, max-age değerinin sıfır olmasının politikayı kaldırdığını belirtir; yine de tarayıcıların bu değişikliği ancak bir sonraki güvenli ziyarette öğreneceğini unutmayın.

Karışık içeriği neden ayrıca denetlemelisiniz?

Yönlendirme doğru çalışsa bile sayfanın içindeki görseller, betikler ve stil dosyaları hâlâ http adreslerini kullanıyor olabilir. Web.dev bu duruma karışık içerik, İngilizcesiyle mixed content adını verir. Sayfanın adresi HTTPS'tir, ama içindeki bazı kaynaklar şifresiz bağlantıdan gelir.

Web.dev iki türü ayırır. Pasif karışık içerik görsel, video ve ses gibi kaynaklardır; tarayıcı adres çubuğunda güvenli değil uyarısı gösterebilir ve Chrome bazen bu kaynakları kendiliğinden https'e yükseltmeyi dener. Aktif karışık içerik ise betik, stil dosyası ve iframe gibi kaynaklardır; çoğu tarayıcı bunları varsayılan olarak engeller. Sonuçta menü çalışmaz, form işlemez ya da tasarım dağılır.

Yönlendirme denetleyicisi yalnız sayfa adresinin yolculuğunu gösterir, sayfanın içindeki kaynakları taramaz. Bu yüzden karışık içeriği tarayıcının geliştirici araçlarındaki sorunlar ve konsol bölümünden ayrıca kontrol edersiniz. Kalıcı çözüm, kaynak adreslerini https ile ya da protokolden bağımsız göreli yollarla yazmaktır. Ayrıntılı rehber için mixed content hatası yazımızı okuyabilirsiniz.

Alt sayfalar ve parametreli adresler doğru yönleniyor mu?

En sık rastladığımız hata, yalnız ana sayfayı test edip işi bitmiş saymaktır. Oysa kuralın yol ve sorgu dizesi bölümünü koruyup korumadığını ancak alt sayfalarla görürsünüz. Örneğin bazı kurallar her http isteğini https ana sayfaya gönderir; bu durumda ana sayfa testi başarılı görünür.

Örnek senaryo: http://example.com/urunler/mavi-sandalye?renk=lacivert adresini denetlediğinizde hedef https://example.com/urunler/mavi-sandalye?renk=lacivert olmalıdır. Hedef https://example.com/ çıkıyorsa kural yolu düşürüyordur. Hedefte ?renk=lacivert kısmı yoksa sorgu dizesi kayboluyordur ve kampanya etiketleri gibi bilgiler de kaybolur.

Bu nedenle test listenize şunları ekleyin:

• Ana sayfa ve en çok trafik alan üç sayfa.
• Bir kategori ya da hizmet sayfası ve bir blog yazısı.
• Sorgu dizesi olan bir adres, örneğin UTM parametreli bir kampanya linki.
• Görsel ya da PDF gibi doğrudan bir dosya adresi.
• Var olmayan bir adres; bu adres https'e geçtikten sonra 404 döndürmeli, ana sayfaya gitmemeli.

İç linkler, canonical ve site haritası HTTPS'e geçti mi?

Yönlendirme, eski adresleri yakalayan bir güvenlik ağıdır; sitenin kendi içinde sürekli kullanılmamalıdır. Google'ın site taşıma rehberi, yeni sitedeki iç linkleri eski adreslerden yeni adreslere çevirmenizi açıkça önerir. Aksi halde her iç tıklama gereksiz bir yönlendirmeden geçer.

Aynı rehber, her yeni adresin kendisini gösteren bir canonical etiketi taşımasını ve yönlendirmeler devreye girdikten sonra canonical işaretlerinin yeni adresleri gösterdiğini doğrulamanızı ister. Ayrıca yeni adreslerle bir site haritası hazırlayıp Search Console'a göndermenizi önerir. Canonical etiketlerindeki tipik hataları canonical hatalarını tespit etme rehberimizde topladık.

Pratik bir kontrol yöntemi şudur: sayfanın kaynak kodunda http:// ifadesiyle arama yapın. Kendi alan adınıza giden her eşleşme, ya bir iç link ya da bir kaynak adresidir ve düzeltilmesi gerekir. Web.dev de site içi adreslerin belirli bir protokole bağlı olmamasını önerir. Başka sitelere verdiğiniz linkleri ise yalnız o site HTTPS destekliyorsa değiştirin.

Search Console'da HTTPS geçişini nasıl izlersiniz?

Google'ın site taşıma rehberi, Search Console'da hem HTTP hem HTTPS site varyasyonlarını doğrulamanızı önerir. Böylece eski sürümün dizinden çıkışını ve yeni sürümün yerini almasını ayrı ayrı izlersiniz. Aynı rehbere göre HTTP'den HTTPS'e geçişte Adres Değişikliği aracını kullanmanız gerekmez.

Bir noktaya dikkat edin: Google'ın HTTP durum kodları belgesine göre Google'ın denetim araçları yönlendirmeleri izlemez. Dolayısıyla http adresini denetlediğinizde yalnız yönlendirme bilgisini görürsünüz; hedef sayfanın durumunu öğrenmek için https adresini ayrıca denetlemeniz gerekir.

Geçişten sonraki haftalarda dizine eklenen sayfalarda http adreslerinin azaldığını, https adreslerinin arttığını görmeyi beklersiniz. Google yönlendirilen adresi bir süre alternatif ad olarak tutabilir; bu normaldir. Rapordaki durumları nasıl okuyacağınızı Search Console HTTPS raporu yazımızda anlattık.

HTTP'den HTTPS'e yönlendirme ne kadar süre yerinde kalmalı?

Kısa cevap: mümkün olduğu kadar uzun. Google'ın site taşıma rehberi, yönlendirmeleri mümkün olduğunca uzun süre, genel olarak en az bir yıl tutmanızı önerir. HTTPS geçişinde ise bunun da ötesine geçmenizi öneriyoruz, çünkü bu yönlendirmeyi kaldırmak için makul bir gerekçe yoktur.

Düşünün: başka sitelerdeki eski http linkleri yıllarca yerinde kalır. Kural kalkarsa bu linkler ya şifresiz sayfa açar ya da hiç çalışmaz. Üstelik HTTP'den HTTPS'e yönlendirme genellikle tek bir sunucu kuralıdır ve bakım maliyeti yok denecek kadar azdır. Dolayısıyla kaldırmak risk getirir, tutmak ise neredeyse hiçbir şeye mal olmaz.

Sunucu ya da hosting değişikliği yaptığınızda bu kuralın yeni ortama taşındığını mutlaka kontrol edin. Taşımalarda en sık unutulan şeylerden biri budur. Genel süre tartışması için 301 yönlendirme ne kadar süre kalmalı yazımıza göz atabilirsiniz.

Hangi yönlendirme yöntemini seçmelisiniz?

Google'ın yönlendirme belgesi, sunucu tarafı yönlendirmeleri doğru yorumlanma olasılığı en yüksek yöntem olarak sıralar. Bu yöntemde yönlendirmeyi sunucu yapılandırma dosyaları ya da sunucu tarafı kod kurar ve durum kodu doğrudan yanıtla gelir.

Sunucu tarafı yönlendirme mümkün değilse meta refresh bir seçenektir. Google, anında, yani sıfır saniyelik meta refresh yönlendirmesini kalıcı, gecikmeli olanı geçici olarak yorumlar. JavaScript ile yönlendirmeyi ise yalnız son çare olarak önerir; çünkü sayfanın işlenmesi başarısız olursa Google yönlendirmeyi hiç görmeyebilir.

HTTPS geçişi özelinde ise meta refresh ve JavaScript pratik değildir, çünkü ikisi de önce http sayfasının yüklenmesini gerektirir. Yani ziyaretçi bir an da olsa şifresiz bir sayfayla karşılaşır. Bu yüzden HTTP'den HTTPS'e yönlendirme için sunucu ya da içerik dağıtım ağı düzeyinde bir kural kurmanızı öneriyoruz. Ayrıca bizim aracımız da yalnız sunucu yanıtlarını okuduğu için bu yöntemi doğrudan denetler.

En sık karşılaşılan hatalar nelerdir?

Yıllar içinde denetlediğimiz sitelerde aynı hataların tekrar ettiğini görüyoruz. Aşağıdaki liste, kontrol sırasında özellikle bakmanızı önerdiğimiz noktaları özetliyor.

• Geçici kod kullanmak: kalıcı geçişte 302 kalması, Google'a zayıf sinyal gönderir.
• Zincir kurmak: protokol, www ve eğik çizgi kurallarının art arda çalışması.
• Yolu düşürmek: bütün http adreslerini https ana sayfaya göndermek.
• Sorgu dizesini kaybetmek: kampanya parametrelerinin hedefte görünmemesi.
• HTTPS'ten HTTP'ye düşüş: bazı eski kuralların tam ters yönde çalışması.
• Alt alan adlarını unutmak: blog, mağaza ya da panel alt alan adlarında kuralın olmaması.
• İç linkleri güncellememek: sitenin kendi menüsünün hâlâ http adreslerine bağlanması.
• HSTS'yi aceleyle ve yüksek bir değerle açmak: sertifika sorununda siteye erişimin kesilmesi.

Bu hataların çoğu tek bir kontrol turunda ortaya çıkar. Ancak bazıları, örneğin alt alan adı eksikleri, ancak alan adının bütün varyasyonlarını listelediğinizde görünür hale gelir.

Geçişten sonra neyi, ne zaman denetlemelisiniz?

HTTPS geçişi tek seferlik bir ayara benzer, ama sitede yapılan her değişiklik kuralı bozabilir. Tema güncellemesi, eklenti değişikliği, sunucu taşıması ya da yeni bir içerik dağıtım ağı ayarı bunların başında gelir. Bu yüzden kontrolü bir takvime bağlamak işinizi kolaylaştırır.

Site tümüyle yeni bir alan adına ya da yeni bir yapıya taşınıyorsa HTTPS kontrolü daha büyük bir listenin yalnız bir parçasıdır. O durumda SEO migration kontrol listesi yazımızdaki adımları da uygulamanızı öneririz.

Sonuç: hangi tablo sizi rahatlatmalı?

Özetle, sağlıklı bir HTTP'den HTTPS'e yönlendirme şu tabloyu verir: dört sürümün her biri tek bir 301 ya da 308 ile aynı https adresine gider, tercih edilen sürüm doğrudan 200 döndürür, alt sayfalar yolunu ve parametresini korur. İç linkler, canonical etiketleri ve site haritası zaten https adreslerini gösterir.

Bunun üzerine HSTS'yi temkinli bir sırayla eklerseniz hem kullanıcılarınızı korursunuz hem de arama motoruna tutarlı bir sinyal verirsiniz. Karışık içeriği de ayrıca temizlediğinizde tarayıcı uyarıları ortadan kalkar.

Bu kontrolü bir kez yapmak yetmez; her büyük değişiklikten sonra aynı listeyi tekrar çalıştırın. Biz Talha Aslan ve ekibi olarak teknik denetimlerde bu listeyi her seferinde baştan uyguluyoruz, çünkü en basit kural bile beklenmedik bir güncellemeyle sessizce bozulabiliyor.

Kaynaklar: Google Search Central: Yönlendirmeler ve Google Arama, Google Search Central: URL değişiklikli site taşıma, Google Search Central: HTTP durum kodları, IETF RFC 6797: HSTS, web.dev: Karışık içerik nedir?

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.