HTTP'den HTTPS'ye Geçiş

TL;DR — HTTP→HTTPS geçişi, sitenizdeki her sayfayı güvenli olmayan http:// adresinden güvenli https:// adresine taşımak anlamına gelir. Bir sertifika kurar, ardından hiçbir şeyin bozulmaması ve sıralama kaybı yaşanmaması için her eski URL’yi yeni güvenli sürümüne yönlendirirsiniz. Dikkatli yapıldığında güvenlidir — hasar yalnızca özensiz uygulamadan gelir.

Aslında ne yapıyorsunuz

HTTP URL’lerini HTTPS’e taşımak, onların canonical URL’lerini değiştirir ve kalıcı sunucu tarafı yönlendirmeleri ile tutarlı canonical sinyalleri kullanmalıdır. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes HTTPS yapılandırması ayrıca geçerli bir TLS sertifikası sunmalı ve karışık kaynaklardan kaçınmalıdır. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Şu anda sayfalarınız http:// ile başlayan adreslerde yaşıyor. Bunların https:// adresinde yaşamasını istiyorsunuz — güvenli, şifreli sürüm, asma kilit gösteren ve Chrome’un “Not Secure” uyarısını tetiklemeyen sürüm. İçerik, ana bilgisayar adları, yollar ve sorgu dizeleri aynı kalır ve aynı anda CMS veya barındırma platformunu değiştirmiyorsunuz. Yalnızca her URL’nin ilk birkaç karakteri değişir.

Sayfaların kendileri taşınmadığı için bu, site geçişlerinin en nazik türüdür — ancak yalnızca tüm bunlar geçerli olduğu sürece. Aynı anda alt alan adlarını birleştiriyor, URL’leri yeniden yapılandırıyor, içeriği yeniden yazıyor veya platform değiştiriyorsanız, bu farklı ve daha yüksek riskli bir harekettir; aşağıdaki kısa versiyonun notuna bakın. Aksi takdirde, yine de bir geçiştir, bu yüzden özen gerektirir.

En önemli tek kural

Her eski http:// URL’yi 301 yönlendirmesiyle karşılık gelen https:// sürümüne yönlendirin. 301, “kalıcı” yönlendirmedir; arama motorlarına “bu sayfa artık kalıcı olarak burada, tüm sinyalleri buraya taşıyın” der. Google, 301’lerin PageRank kaybına yol açmadığını doğrulamıştır; temiz bir geçiş trafiğinizi korur.

Sorun, yönlendirmeler eksik olduğunda veya sayfalarınız hâlâ eski http:// adresinden bir görsel veya komut dosyası yüklemeye çalıştığında başlar. Bu “karışık içerik”, sayfanızın bazı bölümlerinin tarayıcıda bozulmasına neden olabilir. Yani iş, geçişin kendisi değil — hiçbir şeyin eski adreslere işaret etmediğinden emin olmaktır.

Sürecin kısa versiyonu

1. Bir anlık görüntü alın sitenizin şu anki hâlinden — sayfaların tam listesi ve mevcut sıralamalarınız — böylece sonradan karşılaştırabilirsiniz.
2. Bir sertifika edinin ve kurun. Ücretsiz bir tane (Let’s Encrypt gibi) SEO için mükemmel çalışır.
3. Önce bir kopya üzerinde test edin mümkünse, böylece lansman günü sürpriz olmaz.
4. Açın: her eski URL’yi güvenli sürüme yönlendirin, dahili bağlantılarınızı ve site haritanızı güncelleyin ve hâlâ http:// üzerinden yüklenen her şeyi düzeltin.
5. Search Console’u yeniden kontrol edin. En basit çözüm, her http/https/www varyantını otomatik olarak kapsayan bir Domain özelliğidir — her birini ayrı ayrı doğrulamanız gerekmez.
6. Yönlendirmeleri koruyun (en az bir yıl, ideal olarak sonsuza kadar) ve trafiğinizi birkaç hafta izleyin. Küçük bir dalgalanma normaldir.

Ayrıca URL’leri yeniden adlandırıyorsanız, alt alan adlarını birleştiriyorsanız, yeni bir CMS’ye taşınıyorsanız veya sayfalardaki içeriği değiştiriyorsanız, durun — bu, düz bir protokol değişikliğinden daha büyük ve daha riskli bir harekettir. Bunun yerine tam site geçişi oyun kitabını kullanın ve HTTPS geçişini buna dahil edin.

Tam mühendislik versiyonunu mu istiyorsunuz — sertifika seçenekleri, binlerce URL için yönlendirme eşlemesi, dört Search Console özelliği, izleme pencereleri ve bir geri alma planı? Gelişmiş sekmesine geçin. (HTTPS’in bir sıralama sinyali olarak nereye oturduğu için, HTTPS merkeziyle başlayın.)

TL;DR — HTTP→HTTPS geçişi, yalnızca protokolün değiştiği bir site geçişidir: ana bilgisayar, yollar, sorgu dizeleri, içerik ve platform aynı kalır; yalnızca şema değişir. Bunların tümü geçerliyse en düşük riskli geçiş türüdür, ancak disiplin her site taşımasıyla aynıdır. Canlı HTTP sitesinin kıyaslamasını alın, bir TLS sertifikası seçip kurun (ücretsiz DV sertifikası, ücretli olanlarla aynı hafif sıralama sinyalini sağlar; Google sertifika vereni değil şemayı kontrol eder), hazırlık ortamında prova yapın ve ardından geçişi başlatın: her URL’yi sunucu tarafında birebir 301 ile yönlendirin (301’ler PageRank kaybettirmez), her sayfanın canonical değerini kendi HTTPS URL’si yapın, iç bağlantıları, site haritası kayıtlarını ve hreflang ek açıklamalarını güncelleyin; komut dosyalarını bozmadan önce engellenebilir karışık içeriği giderin. Search Console’da tüm şema/ana bilgisayar varyantlarını kapsayan bir Domain mülkü ekleyin veya ayrıştırılmış veri istiyorsanız HTTPS URL-prefix mülklerini doğrulayın; HTTPS site haritasını gönderin ve alan adı taşımalarına özgü Change of Address aracını kullanmayın. Yönlendirmeleri en az bir yıl tutun; bu süre son kullanma tarihi değil alt sınırdır. Crawl Stats ve dizine eklemeyi izleyin: toparlanan düşüş geçişin oturduğunu, kalıcı düşüş ise bir şeyin bozulduğunu gösterir. Geri alma planınız olsun, fakat önce HTTPS’i onarın; önbellek, HSTS, çerezler ve service worker’lar gerçek bir HTTP geri dönüşünü güvensiz kılabilir. HSTS preload’ı tek yönlü kapı değil, geri alınması yavaş ve operasyonel açıdan riskli bir karar sayın.

HTTPS merkezi, HTTPS’te olmanın nedenini kapsar ve taşımayı üst düzeyde özetler. Bu, o bölümün derin, adım adım eşlikçisidir — bir taşımanın gerçekten ters gittiği veya temiz gittiği kısım.

Önce, riski doğru boyutlandırın: bu yalnızca protokol tabanlı bir taşıma

Google, protokol değişikliklerini URL değişiklikleri olan site taşımaları olarak ele alır; geçici sıralama veya raporlama dalgalanmaları mümkündür ve hiçbir taşıma zaman çizelgesi garanti edilmez. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Site moves with URL changes Taşıma güvenliği ve Search işleme ilişkili ancak ayrı konulardır. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

Site taşımaları bir tehlike yelpazesinde yer alır. Alan adınızı, URL yapınızı veya CMS/platformunuzu değiştirmek, URL’lerinizin kimliğini yeniden yazar ve gerçek risk taşır. Yalnızca protokol değişikliği, diğer her şey sabit kaldığında düşük riskli durumdur. Bunu tek kuralı bir yönlendirme olarak ele almadan önce tüm bunları doğrulayın:

• Ana bilgisayar adları — geçişle birlikte www/www olmayan birleştirme veya alt alan adı değişikliği yok.
• Yollar ve sorgu dizeleri — aynı sürüme dahil edilmiş URL yeniden yapılandırması, slug yeniden adlandırması veya parametre temizliği yok.
• İçerik — sayfalar aynı anda yeniden yazılmıyor, birleştirilmiyor veya budanmıyor.
• Platform/oluşturma davranışı — paralel olarak gerçekleşen CMS, çerçeve veya barındırma taşıması yok.

Dördü de geçerli olduğunda, alan adı, yollar ve içerik aynıdır; yalnızca her URL’nin önündeki şema değişir. Google’ın bunun için “Change of Address aracını kullanmanıza gerek yok” demesinin nedeni budur: bildirilecek bir adres değişikliği yoktur.

En önemli tek sonuç: URL’ler birebir ve deterministik olarak eşlendiğinden (http://example.com/x → https://example.com/x), yönlendirme mantığınız genellikle tek bir sunucu kuralı olabilir ve yönlendirme haritanız kendini yazar. Bunu, her eski URL’nin elle kontrol edilen bir hedefe ihtiyaç duyduğu bir alan adı veya platform taşımasıyla karşılaştırın. Bu çerçeveyi koruyun — size çabayı nereye harcayacağınızı (sertifika, karışık içerik, Search Console) ve nereye harcamayacağınızı (yönlendirme hedefleri üzerinde kafa yormak) söyler.

Aynı anda ayrıca alan adını veya platformu değiştiriyorsanız durun: bu yığılmış bir taşımadır, riskler çoğalır ve protokol değişikliği en az endişenizdir. Daha zor taşımayı tam site taşıma playbook’unu kullanarak yapın ve HTTPS’i buna dahil edin.

Adım 1 — Hiçbir şeye dokunmadan önce canlı HTTP sitesini kıyaslayın

Bir taşımanın iyi gidip gitmediğini, karşılaştırabileceğiniz bir “önceki” görüntü olmadan anlayamazsınız. Site hâlâ HTTP üzerindeyken şunları yakalayın:

• Canlı sitenin tam bir taraması — her 200 URL’sini ve kritik olarak mevcut her yönlendirmeyi ve hedefini kaydedin. Lansmandan sonra bu taramayı yeniden çalıştırıp ikisini karşılaştıracaksınız; 200 olan ve artık 404 olan her şey bir gerilemedir.
• Takip ettiğiniz anahtar kelimeler için bir sıralama anlık görüntüsü, böylece lansman sonrası bir düşüşün bir temeli olur.
• Bir Search Console dışa aktarımı — Performans (sorgular, sayfalar, tıklamalar, gösterimler), Sayfa Dizinleme raporu ve Tarama İstatistikleri. GSC verileri HTTP özelliğinden HTTPS özelliğine aktarılmaz, bu nedenle bu dışa aktarım “önceki” durumun tek kaydınızdır.
• Geri bağlantı profiliniz, böylece hangi URL’lerin en fazla harici eşitlik taşıdığını ve bu nedenle en çok temiz, tek atlamalı yönlendirmeye ihtiyaç duyduğunu bilirsiniz.
• robots.txt dosyanız ve mevcut haliyle noindex yönergeleriniz — bunlardan hiçbirinin sessizce HTTPS sitesini engellemek üzere taşınmadığından emin olmak istersiniz.

Adım 2 — TLS sertifikasını seçin ve kurun

İşte insanlara para kazandıran SEO ile ilgili gerçek: sıralama sinyali URL şemasını kontrol eder, sertifikayı değil. Gary Illyes bunu “temel olarak URL’nin önündeki ilk beş karaktere bakmak ve HTTPS ise … minimal bir artış alacaktır” şeklinde tanımladı. Bu nedenle SEO için ücretsiz bir Alan Adı Doğrulaması (DV) sertifikası — Let’s Encrypt varsayılandır — ücretli bir OV veya EV sertifikasıyla tam olarak aynı sinyali kazandırır. OV/EV kurumsal kimlik satın alır, sıralama değil. Kendinize (veya bir müşteriye) bir sıralama artışı veya belirli bir sertifika türü ya da anahtar algoritması için özel bir fayda vaat etmeyin — Google’ın kendi açıklaması bunu hafif, minimal bir sinyal olarak adlandırır, ödemeye değer bir kaldıraç değil.

Teknik olarak doğru yapmanız gereken şeyler:

• Kapsam. Tek alan adlı bir sertifika tek bir ana bilgisayar adını kapsar; bir joker (*.example.com) bir düzey derinliğini kapsar — foo.example.com için çalışır ancak değil foo.bar.example.com. Derin alt alan adları çalıştırıyorsanız, çok alan adlı (SAN) veya ek sertifikalar planlayın.
• Anahtar gücü. Google’ın yönergesi “2.048 bitlik bir RSA anahtar çifti oluşturun” şeklindedir — daha kısa olanı kaba kuvvetle kırılabilir, daha uzunu kaynakları boşa harcar.
• Otomatik yenileme. Taşıma sonrası en yaygın olay süresi dolmuş bir sertifikadır. Yenilemeyi otomatikleştirin (Let’s Encrypt bunun için yapılmıştır) ve süre sonunu izleyin. Nüansı not edin: Google genellikle HTTPS’i bir sayfanın kurallı sürümü olarak tercih eder, ancak bu tercih koşulludur, otomatik değildir — geçersiz bir sertifika, güvenli olmayan bağımlılıklar, HTTPS’ten HTTP’ye bir yönlendirme veya bir HTTP kurallı etiketi Google’ın kurallı seçimini HTTP URL’sine geri çevirebilir ve HSTS bu tercihi geçersiz kılamaz. Evidence for this claim Google generally prefers HTTPS as the canonical version of a page, but that preference is conditional: an invalid certificate, insecure dependencies, an HTTPS-to-HTTP redirect, or an HTTP canonical tag can flip Google's choice back to the HTTP URL. HSTS is a browser-only mechanism and cannot override Google's canonical selection. Scope: Describes Google's conditional HTTPS canonical preference, not a guarantee that certificate problems are search-invisible. Confidence: high · Verified: 2026-07-17 Google: Consolidate duplicate URLs Bu nedenle süresi dolmuş bir sertifika Arama için zararsız bir olay değildir — aynı anda bir UX/güvenlik acil durumudur (kullanıcı güvenini yok eden tam ekran bir tarayıcı uyarısı) ve devam ettiği sürece HTTPS kurallı tercihiniz için gerçek bir risktir. Her iki durumda da hızlıca düzeltin. (Sertifika hatası sınıflandırmasının tamamı için — süresi dolmuş, kendi kendine imzalanmış, ana bilgisayar adı uyumsuzluğu, eksik zincir — bkz. TLS/SSL sertifikaları derinlemesine inceleme.)

Adım 3 — Hazırlık ortamında prova yapın

Tüm geçişi önce bir hazırlık/ön üretim kopyasında yapın. Doğruladığınız şeyler:

• Yönlendirme kuralı her yol biçimi için tetiklenir; sorgu dizeleri, sondaki eğik çizgi varyantları ve www/www olmayan dahil.
• Yönlendirme döngüsü yok (HTTPS’i HTTP’ye ve tekrar geri gönderen yanlış yapılandırılmış bir kural herkesi kilitler — siz dahil).
• Sayfalar DevTools konsolunda engellenebilir karışık içerik olmadan temiz bir şekilde işlenir.
• Kurallı etiketleriniz hazırlık ortamında zaten https:// yayar.

Hazırlık kopyasını dizinlemeden koruyun (kimlik doğrulama veya kaldırmayı unutmadığınız bir noindex — prodüksiyona taşınan ve yalnızca geçiş için eklenmiş bir noindex, klasik bir kendi kendine yaralanmadır). Google’ın kendi rehberliği bunu açıkça belirtir: yalnızca geçiş için gerekli olan noindex veya robots.txt engellemelerini kaldırmayı unutmayın.

Adım 4 — Ölçekte yönlendirme eşlemesi

Protokol değişikliği için eşleme deterministiktir, bu yüzden onu devasa bir arama tablosu yerine tek bir kural ile yönetirsiniz:

• Sunucu tarafında, bire bir ve kalıcı (301). Her http:// URL → https:// üzerinde aynı yol. Bunu sunucu/kenar yapılandırmasında (Apache, Nginx veya CDN’niz) yapın, uygulama kodunda veya istemci tarafı JavaScript ile değil, böylece botlar temiz bir sunucu 301’i görür.
• Yönlendirme zinciri yok. Zaten HTTP yönlendirmeleriniz varsa (örneğin http://a → http://b), HTTPS geçişinin bunu http://a → http://b → https://b’ye dönüştürmesine izin vermeyin. Orijinal kuralları güncelleyin, böylece eski URL’ler tek atlamada nihai HTTPS hedefine ulaşır. Google 10 atlamaya kadar takip eder, ancak “doğrudan nihai hedefe yönlendirmeyi önerir.” Her ekstra atlama boşa harcanan tarama bütçesi ve biraz kayıp hızdır.
• Ana sayfaya asla toplu yönlendirme yapmayın. Eşleşmeyen URL’ler yine de kendi HTTPS ikizlerine çözümlenmelidir. Her şeyi / üzerine boşaltmak, sıralamaları gerçekten kaybettiren geçiş hatasıdır.
• Haritayı bir tarama ile doğrulayın. Lansmandan sonra HTTP URL listesini yeniden tarayın ve her birinin doğru HTTPS URL’sine tek bir 301 döndürdüğünü doğrulayın — 302 değil, zincir değil, 404 değil.

Adım 5 — Her canonical, sitemap ve hreflang sinyalini yeniden yönlendirin

Yönlendirmeler ağır işi yapar, ancak Google’ın özensiz iç yapıları düzeltmek için onlara güvenmesine izin vermeyin. Gerçek sinyalleri güncelleyin:

• Canonical’lar. Her sayfa, kendi rel="canonical" URL’sini gösteren kendine referans veren bir https:// taşımalıdır — Google’ın site taşıma rehberliği “Her yeni URL, kendine referans veren bir rel=“canonical” <link> etiketine sahip olmalıdır.” der. Hâlâ http://’yi gösteren bir canonical, geçişinizle çelişir. (Bu, canonicalization konusunun uyardığı türden çelişkili bir sinyaldir — tüm sinyalleri HTTPS URL’si üzerinde hizalayın.)
• İç bağlantılar. Bunları şablonlarda ve içerikte https:// (veya protokol-göreli/kök-göreli) olarak değiştirin — binlerce iç bağlantıyı http://’yi gösterir ve temizlemek için yönlendirmeye güvenir halde bırakmayın. Her iç http:// bağlantısı, hem kullanıcılar hem de botlar için gereksiz bir yönlendirme atlamasıdır.
• XML sitemap’ler. Bunları yalnızca HTTPS URL’leriyle yeniden oluşturun, canonical, dizinlenebilir sayfaları listeleyin ve lastmod’u güncelleyin. Lansmandan sonra yeni sitemap’i GSC’de gönderin.
• Hreflang. Uluslararası bir kurulum yürütüyorsanız, her hreflang açıklaması her alternatifin HTTPS sürümüne referans vermelidir. Yarı geçirilmiş hreflang (bazı http, bazı https), sessiz ve teşhis edilmesi zor bir uluslararası SEO hatasıdır.
• Yapılandırılmış veri ve Open Graph URL’leri. og:url, JSON-LD içindeki canonical referansları ve sabit kodlanmış mutlak URL’lerin tümü HTTPS olmalıdır.

Adım 6 — Lansmandan önce karışık içeriği öldürün, sonradan değil

Karışık içerik, HTTP üzerinden bir alt kaynak yükleyen bir HTTPS sayfasıdır. Lansman gününün en yaygın gerilemesidir. Güncel terminoloji (eski “aktif/pasif” ayrımı tarihseldir, ancak eski belgelerde ve araçlarda hâlâ görürsünüz) bunu tarayıcının ne yaptığına göre ayırır:

• Engellenebilir karma içerik — betikler, stil sayfaları, iframe’ler, XMLHttpRequest/ fetch (eski “aktif” kategorisi). Tarayıcılar bunları doğrudan engeller çünkü değiştirilmiş bir betik tüm sayfayı yeniden yazabilir. Geçişten sonra siteyi gerçekten bozan şey budur: engellenen bir stil sayfası veya JS paketi sayfayı stilsiz veya işlevsiz bırakabilir. Önce bunları düzeltin.
• Yükseltilebilir (isteğe bağlı engellenebilir) karma içerik — görseller, ses, video (eski “pasif” kategorisi). Modern tarayıcılar bu istekleri giderek otomatik olarak HTTPS’ye yükseltir ve yükseltme başarısız olursa engeller; yalnızca uyarı verip HTTP üzerinden görüntülemek yerine. “Hâlâ yükleniyor” ifadesini tarayıcı sürümüne bağlı bir davranış olarak ele alın, bir garanti olarak değil. Yine de sonraki adımda düzeltin.
• İstisnalar vardır — bazı tarayıcı/gömme bağlamları (belirli eklenti yüklü kaynaklar, bazı eski <applet>/<embed> durumları) her iki kurala da tam olarak uymaz; bu, genel kuralı varsaymak yerine hedef kitlenizin gerçekten kullandığı tarayıcılarda davranışı doğrulamanın bir başka nedenidir.

HTTPS sitesini tarayarak (Ahrefs Site Audit, Screaming Frog), Chrome DevTools konsolunu izleyerek veya CSP raporlarını toplayarak bulun. Geçiş dönemi için proaktif bir ağ olarak, Content-Security-Policy: upgrade-insecure-requests başlığı tarayıcıya http:// alt kaynak isteklerini yapmadan önce sessizce https://’ye yükseltmesini söyler — ancak bir CSP başlığı, her uç noktanın HTTPS sürümünün gerçekten var olduğunu veya HTTP ile aynı davrandığını kanıtlamaz ve kaynak URL’leri düzeltmenin veya gerçek tarayıcılarda test etmenin yerini almaz. Kafa karışıklığını önleyen bir açıklama: bir HTTP sayfasına sıradan bir çapa bağlantısı karma içerik değildir — yalnızca gezinir.

Adım 7 — Search Console kapsamını doğru ayarlayın

Bu, insanların hafife aldığı adımdır — ancak bu evrensel bir kontrol listesi değil, bir karardır. Search Console’un URL-ön eki özellikleri http://example.com, http://www.example.com, https://example.com ve https://www.example.com adreslerini veri paylaşmayan dört ayrı özellik olarak izler. Dördünü de doğrulamanız gerekmez:

• Bir Alan adı özelliği her protokolü ve alt alan adı varyantını otomatik olarak birleştirir — bir tane ekleyin, başka hiçbir şeye dokunmadan geçişi emer. Bu, çoğu site için en basit varsayılandır.
• URL-ön eki özellikleri verileri tam protokol ve ana bilgisayara göre böler. Bunları yalnızca bu bölümlemeyi bilinçli olarak istiyorsanız koruyun veya ekleyin — örneğin, canlı HTTPS sitesine hâlâ ne kadar HTTP kalıntı trafiğinin geldiğini karşılaştırmak için. Bu bir raporlama tercihidir, bir gereklilik değil.

Her iki durumda da:

• Yeni HTTPS site haritasını gönderin siteyi izlediğiniz her yere (Alan adı özelliği veya HTTPS URL-ön eki özelliği).
• Adres Değişikliği aracını kullanmayın. Google açıkça belirtiyor: “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (çeviri) «Sitenizi HTTP’den HTTPS’ye taşıyorsanız, Adres Değişikliği aracını kullanmanıza gerek yoktur.» Bu araç yalnızca alan adı düzeyindeki taşımalar içindir ve burada kullanmak iyi niyetli bir hatadır.
• Daha önce doğruladığınız HTTP özelliklerini koruyun — yönlendirmelerin işlendiğini ve eski URL’lerin dizinden çıktığını gösterirler; bu yararlı bir izleme sinyalidir, karmaşa değil.
• Disavow dosyanızı yeniden gözden geçirin, varsa — girdileri HTTP URL’lerine atıfta bulunur ve özellik başına yaşar.

Tüm siteyi izlemek yerine tek tek URL’leri teşhis etmek için GSC’nin HTTPS raporu, bir URL’nin HTTPS’ye taşınmamasının sertifika, yönlendirme, canonical, robots ve site haritası değerlendirme nedenlerini işaretler. Bunu örneklenmiş bir teşhis aracı, tam bir envanter değil olarak ele alın — örneklenmiştir ve URL’leri eşleştirirken sorgu parametrelerini yok sayar, bu nedenle kendi taramanızın yakalayacağı her şeyi yakalamaz. Nasıl okunacağı için GSC HTTPS raporu derinlemesine incelemesine bakın.

Adım 8 — İzleme pencereleri: oturma vs. bozuk

Sıralamada geçici dalgalanma bekleyin — bu normaldir ve panik yapmak ya da geri dönmek için bir neden değildir. Disiplin, oturan bir düşüşü bozuk olandan ayırmaktır:

• Toparlanan bir düşüş günler ila birkaç hafta içinde, dizinin HTTP URL’lerini HTTPS ile değiştirmesidir. Google, küçük ve orta ölçekli bir sitenin çoğu sayfanın taşınmasının birkaç hafta sürdüğünü; daha büyük sitelerin daha uzun sürdüğünü belirtir.
• Kalıcı bir düşüş bir şeyin bozulduğu anlamına gelir — başıboş bir robots.txt engeli, staging’den kalan bir noindex, hâlâ http://’yi gösteren canonical’lar, toplu olarak hâlâ HTTP üzerinde olan iç bağlantılar veya eşitlik sızdıran yönlendirme zincirleri.

Sabit bir toparlanma penceresi yoktur — tek bir sayının “bitti” demesini beklemek yerine bunları bağımsız olarak izleyin:

• TLS/tarayıcı davranışı — sertifika geçerliliği ve zinciri ile temsili sayfalardaki gerçek DevTools konsolu (karışık içerik hatası yok, sertifika uyarısı yok). Bu, Search metriklerinin size söylemeyeceği şeydir.
• GSC Tarama İstatistikleri sitenin izlendiği her yerde — Googlebot’un HTTPS URL’lerini getirdiğini ve yanıt kodu karışımının sağlıklı kaldığını (çoğunlukla 200 + eski URL’lerdeki 301’ler) görmek istersiniz. 5xx artışı, sunucunuzun yeni yük altında zorlandığı anlamına gelir.
• Sayfa Dizine Ekleme raporu — HTTPS URL’lerinin “Dizine eklendi” durumuna, HTTP URL’lerinin “Yönlendirmeli sayfa” durumuna geçmesi. Bu geçiş tam olarak görmek istediğiniz şeydir.
• URL İnceleme birkaç önemli sayfada — bildirilen canonical’ın HTTPS URL’si olduğunu ve sayfanın karışık içerik olmadan işlendiğini doğrulayın.
• Sunucu günlükleri — botların gerçekte hangi URL’lere eriştiğinin ve hangi durumu aldıklarının gerçek kaynağı. Botların hâlâ HTTP URL’lerine vurduğunu (kısa süreliğine sorun değil) veya zincirlere/döngülere çarptığını (sorun) izleyin.
• Analitik ve iş sonuçları — HTTPS→HTTP yönlendirme verileri kesildiği için bir miktar “doğrudan” trafik görünebilir; bu nedenle kendi dış bağlantılarınızın HTTPS hedeflerine gittiğinden emin olun; ayrıca dönüşümleri/geliri bağımsız olarak izleyin — sıralama metriğinin toparlanması, iş metriklerinin de toparlandığını garanti etmez.

Kural olarak 2–4 hafta boyunca aktif olarak izleyin, ardından dizine ekleme tamamen geçene kadar daha hafif bir gözle takip edin — daha büyük veya daha yavaş taranan siteler daha uzun sürebilir ve garantili bir bitiş tarihi yoktur.

Adım 9 — Yönlendirmeleri koruyun ve HSTS’yi bilinçli olarak ekleyin

• 301’leri uzun süre koruyun. Google’ın ifadesi “as long as possible, generally at least 1 year” (çeviri) “mümkün olduğunca uzun, genel olarak en az 1 yıl” şeklindedir. Bu, kaldırmanın güvenli olduğu bir son kullanma tarihi değil, Google’ın önerdiği alt sınırdır. Eski http:// URL’lerine verilmiş dış bağlantılar ve yer imleri hiçbir zaman tamamen kaybolmadığından, uygulamada yönlendirmeleri sitenin ömrü boyunca tutun.
• HSTS ikinci bir katmandır, 301’in yerine geçmez. Strict-Transport-Security başlığı tarayıcılara alan adınız için her zaman HTTPS kullanmalarını söyler ve “ilk istek sorununu” kapatır: yeni ziyaretçinin 301 çalışmadan önce HTTP üzerinden yaptığı ilk istek, SSL stripping saldırganının hedeflediği aralıktır. Ancak HSTS’yi uygulayan tarayıcı, tarayıcıya özgü dahili bir 307 yönlendirmesi yapar; tarayıcılar bunu arama motoru tarayıcılarına göstermez. Arama motorları hâlâ sunucu tarafındaki 301 yönlendirmesine ihtiyaç duyar. İkisi de gerekir.
• HSTS preload’ı tek yönlü kapı değil, geri alınması yavaş ve riskli bir karar olarak değerlendirin. Tarayıcılara gömülü preload listesine başvurmak için en az bir yıllık max-age, politikanın yalnızca gönderdiğiniz ana bilgisayara değil tüm alt alan adlarına uygulanmasını sağlayan includeSubDomains ve preload gerekir. HTTPS’e tam hazır olmayan herhangi bir alt alan adı bu yüzden bozulur. Kaldırma hstspreload.org üzerinden mümkündür, fakat değişikliğin tarayıcı sürüm döngülerine yayılması yavaştır; eski listeyi kullanan tarayıcılar güncellenene kadar HTTPS zorlamayı sürdürür. Yani karar operasyonel açıdan risklidir, kelimenin tam anlamıyla geri döndürülemez değildir. Google’ın uyarısı nettir: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (çeviri) “Sitenizin hiçbir zaman sertifika doğrulama hatalarıyla HTTPS sunmayacak kadar sağlam çalıştığından emin olmadan HSTS’yi etkinleştirmeyin.”

Adım 10 — Bir geri alma planınız olsun (ve sınırlarını bilin)

Düşük riskli bir geçişin bile çıkış planı olmalıdır; ancak bir şey bozulduğunda varsayılan hareket HTTP’ye dönmek değil, HTTPS’i onarmaktır. “Geri alma”, garantili bir tersine çevirme değil sınırlı bir güvenlik ağıdır. Tarayıcı ve CDN’lerde önbelleğe alınmış 301’ler, Secure işaretli çerezler, HTTPS origin’i altında kaydedilmiş service worker’lar ve HSTS/preload politikası, yayın sırasında her şeyi doğru yapsanız bile ziyaretçilerinizin bir bölümü için HTTP’yi yeniden sunmayı güvensiz veya etkisiz kılabilir.

Geçişi yapmadan önce:

• Yayını düşük trafik dönemine denk getirin. Google açıkça “time your move to coincide with lower traffic, if possible” (çeviri) “mümkünse taşımanızı düşük trafik dönemine denk getirin” önerisinde bulunur. Sakin bir zaman aralığında daha az kullanıcı yayın günü hatalarından etkilenir ve müdahale alanınız olur.
• Yönlendirmenin altında HTTP hizmetini açık tutun. HTTP listener’ını kapatmayın; 301’lerin çalışacağı bir kaynak ve HTTPS ciddi biçimde bozulursa yönlendirme kuralını geri alma seçeneği kalsın.
• İlk gün HSTS’yi etkinleştirmeyin. HSTS ve özellikle preload, HTTP’ye geri dönüşü çok daha az uygulanabilir kılar. Tarayıcı politikayı önbelleğe aldıktan sonra sunucunuz ne yaparsa yapsın alan adınızla HTTP üzerinden iletişim kurmaz. HSTS’yi yalnızca HTTPS sitesi bir süre kararlı çalıştıktan sonra ekleyin.
• Durdurma ölçütlerini önceden tanımlayın: örneğin site genelinde 5xx, yönlendirme döngüsü veya yaygın karışık içerik engellemesi. Bu ölçütlerden biri oluşursa şu sırayı izleyin: (1) bozuk sertifika, eksik kaynak veya hatalı canonical gibi HTTPS sorununu doğrudan düzeltebilir misiniz? Genellikle evet; bu, geri dönmekten daha hızlı ve güvenlidir. (2) Yalnızca HTTPS kullanılamaz durumdaysa yönlendirme kuralını geçici önlem olarak geri alın. Bunun eksik kalacağını kabul edin: önbellekteki yönlendirmeler, çerezler ve service worker’lar sunucu kararını değiştirdiğiniz için kendiliğinden temizlenmez.

Canlı hata ayıklamak yerine sakin bir şekilde teşhis edin ve “HTTP’ye geri dön” seçeneğini, asla kullanmayı ummadığınız, camı kırılacak bir seçenek olarak düşünün — rutin, temiz bir geri alma olarak değil.

AI özeti

Gelişmiş sürümün kısa özeti:

• Koşullu olarak yalnızca protokol geçişidir. Ana bilgisayar, yollar, sorgu dizeleri, içerik ve platform aynı kalır; yalnızca şema değişir. Beş koşulun tümü sağlanıyorsa URL’ler birebir eşleşir ve çoğunlukla tek yönlendirme kuralı yeter; bu nedenle en düşük riskli geçiştir. Alan adı taşımalarına özgü Change of Address aracı kullanılmaz. Başka bir şey de değişiyorsa bunu birleşik geçiş sayın.
• Önce kıyaslama alın: tam tarama (tüm 200 yanıtlarını ve mevcut yönlendirmeleri kaydedin), sıralama anlık görüntüsü, GSC dışa aktarımı, backlink profili ve mevcut robots/noindex durumu. GSC verisi HTTPS mülküne aktarılmaz.
• Sertifika: sıralama sinyali şemaya bağlıdır; ücretsiz DV sertifikası (Let’s Encrypt), ücretli sertifikalarla aynı hafif sinyali sağlar. OV/EV kimlik sunar, sıralama artışı değil. 2 048 bit anahtar kullanın, wildcard kapsamının tek etiket derinliğinde olduğunu unutmayın ve yenilemeyi otomatikleştirin. Google genellikle HTTPS canonical’ı tercih eder; ancak bozuk sertifika, güvensiz bağımlılıklar, HTTPS→HTTP yönlendirmesi veya HTTP canonical etiketi tercihi HTTP’ye çevirebilir. HSTS bunu geçersiz kılamaz.
• Hazırlık ortamında prova yapın: her yol biçimi yönlendirilmeli, döngü ve engellenebilir karışık içerik olmamalı, canonical’lar HTTPS üretmelidir. Geçişe özgü noindex üretime ulaşmadan kaldırılmalıdır.
• Geçiş anı: her URL’yi sunucu tarafında birebir 301 ile doğrudan nihai HTTPS hedefine yönlendirin; 301’ler PageRank kaybettirmez. Ana sayfaya toplu yönlendirme yapmayın. Ardından self-referencing HTTPS canonical’ları, iç bağlantıları, site haritalarını, hreflang’i ve OG/JSON-LD URL’lerini güncelleyin.
• Karışık içerik: güncel sınıflar, tarayıcının doğrudan engellediği blockable (script, stil, iframe, XHR) ve modern tarayıcıların HTTPS’e yükselttiği ya da başarısız olursa engellediği upgradable (görsel, ses, video) içeriktir. Eski active/passive ayrımı tarihseldir. upgrade-insecure-requests CSP geçici bir güvenlik ağıdır; HTTPS uç noktasının varlığını kanıtlamaz. HTTP sayfalarına giden normal bağlantılar karışık içerik değildir.
• Search Console yapılandırması bir karardır, sabit sayı değildir. Tüm şema ve ana bilgisayar varyantlarını otomatik birleştiren tek Domain mülkü ekleyin. URL-prefix mülkleri (http, https, http-www, https-www) isteğe bağlı segmentasyondur. HTTPS site haritasını gönderin, disavow dosyasını gözden geçirin. GSC HTTPS raporu, sorgu parametrelerini yok sayan örneklemeli tanı aracıdır; tam envanter değildir.
• Sabit pencereye bağlı kalmadan ayrı sinyalleri izleyin: TLS/tarayıcı davranışı, Crawl Stats, Page Indexing, URL Inspection, günlükler ve analitik/iş sonuçları hikâyenin farklı parçalarını anlatır. Günler veya haftalar içinde toparlanan düşüş yerleşmedir; kalıcı düşüş ise bir engel, kayıp canonical, HTTP iç bağlantıları ya da zincir gibi bir hatayı gösterir.
• Yönlendirmeleri en az bir yıl alt sınırıyla koruyun; bu son kullanma tarihi değildir. Çoğu site süresiz tutar. HSTS, tarayıcıya özgü bir 307’dir; arama motoru tarayıcıları bunu görmez. 301’in yerine değil üstüne eklenir. Preload’ın geri alınması yavaş ve risklidir; hstspreload.org üzerinden mümkündür ama aceleye getirilmemelidir.
• Sınırları belli geri alma planı hazırlayın: önce HTTPS’i onarın; bu genellikle daha hızlı ve güvenlidir. Düşük trafikte yayınlayın, HTTP hizmetini açık tutun, ilk gün HSTS kullanmayın ve durdurma ölçütlerini tanımlayın. Yine de önbellekteki yönlendirmeler, çerezler ve service worker’lar gerçek HTTP geri dönüşünü eksik bırakabilir.

Resmi dokümantasyon

Geçişi planlamak ve yürütmek için birincil kaynak belgeler.

Google

• URL değişiklikleriyle site taşıma — sunucu tarafı 301’leri, tek atlamalı yönlendirmeleri, self-referencing canonical’ları, yönlendirmeleri en az bir yıl tutmayı, HTTP→HTTPS için Change of Address aracı kullanılmamasını ve düşük trafikte yayınlamayı kapsayan geçiş rehberi.
• Yinelenen URL’leri birleştirme — Google’ın koşullu HTTPS canonical tercihi: HTTPS genellikle tercih edilir; bozuk sertifika, güvensiz bağımlılıklar, HTTPS→HTTP yönlendirmesi veya HTTP canonical etiketi tercihi HTTP’ye çevirebilir.
• Sunucularınızda HTTPS’i etkinleştirme (web.dev) — sertifikalar, 2 048 bit anahtarlar, HTTPS canonical’a 301, HSTS ve çerezler.
• HTTPS neden önemlidir? (web.dev) — HTTPS’e geçişin güvenlik ve tarayıcı özellikleri gerekçesi.
• Karışık içeriği düzeltme (web.dev) — tarihsel active/passive ayrımının güncel karşılığı olan blockable/upgradable karışık içerik ve upgrade-insecure-requests.
• Sıralama sinyali olarak HTTPS (2014) — özgün “very lightweight signal” yazısı ve sertifika türü, göreli URL’ler ile robots.txt notları.
• Sayfa deneyimini anlama — HTTPS ve GSC HTTPS raporunun sayfa deneyimindeki yeri.

Sertifikalar ve yapılandırma

• Let’s Encrypt — yerleşik yenilemeye sahip ücretsiz ve otomatik DV sertifikaları.
• SSL Labs Server Test — kurulumdan sonra TLS yapılandırmanızı derecelendirin.
• hstspreload.org — HSTS preload uygunluk koşulları ve kaldırma uyarıları.

Chrome / Chromium

• A secure web is here to stay (2018) — Chrome 68’in tüm HTTP sayfalarını “Güvenli Değil” diye işaretlemesi ve çoğu siteyi geçişe iten son tarih.

Kaynaktan alıntılar

Bir geçişin nasıl yürütüleceğini belirleyen, kayda geçmiş açıklamalar. Her derin bağlantı, kaynak sayfadaki alıntılanan bölüme gider.

Google — yönlendirmeler ve PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” (çeviri) “301 ve diğer kalıcı yönlendirmeler PageRank kaybına yol açmaz.” — Google Search Central. Alıntıya git
• “Keep the redirects for as long as possible, generally at least 1 year.” (çeviri) “Yönlendirmeleri mümkün olduğunca uzun, genel olarak en az 1 yıl tutun.” — Google Search Central. Alıntıya git
• “Each new URL should have a self-referencing rel=“canonical” <link> tag.” (çeviri) “Her yeni URL’de kendisine referans veren bir rel=“canonical” <link> etiketi bulunmalıdır.” — Google Search Central. Alıntıya git

Google — HTTP→HTTPS’e özgü ayrıntılar

• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (çeviri) “Sitenizi HTTP’den HTTPS’e taşıyorsanız Change of Address aracını kullanmanız gerekmez.” — Google Search Central. Alıntıya git
• “Expect temporary fluctuation in site ranking during the move.” (çeviri) “Taşıma sırasında site sıralamasında geçici dalgalanma bekleyin.” — Google Search Central. Alıntıya git

Google — HSTS ve sertifikalar (web.dev)

• “Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect.” (çeviri) “301 yönlendirmesinin maliyetinden kaçınmak için HTTP Strict Transport Security (HSTS) kullanın.” — web.dev (Google). Alıntıya git
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (çeviri) “Sitenizin hiçbir zaman sertifika doğrulama hatalarıyla HTTPS sunmayacak kadar sağlam çalıştığından emin olmadan HSTS’yi etkinleştirmeyin.” — web.dev (Google). Alıntıya git

Gary Illyes — sinyal şemaya dayalıdır

• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (çeviri) “Temelde URL’nin başındaki ilk beş karaktere bakılıyor; HTTPS ise çok küçük bir artış elde ediyor.” — Gary Illyes, Google, 2016 (Search Engine Land üzerinden). Haberin tamamını okuyun

Hangi yolu izlemeliyim?

“Şema dışında bir şeyi de değiştiriyor muyum?”

• Yalnızca http:// → https://; ana bilgisayar, yollar, sorgu dizeleri, içerik ve platform aynı → bu makaledeki yalnızca protokole özgü planı uygulayın. Tek yönlendirme kuralı yeterlidir; Change of Address aracı kullanılmaz.
• Alan adı, ana bilgisayar/alt alan adları, URL yapısı, içerik veya CMS/platform da değişiyor → durun. Bu, daha yüksek riskli birleşik bir geçiştir. Tam site geçişi planını uygulayın ve HTTPS’i ona dahil edin.

“Hangi sertifikaya ihtiyacım var?”

• Yalnızca HTTPS şeması + sıralama sinyali gerekiyor → ücretsiz bir DV sertifikası (Let’s Encrypt). Ücretli olanlarla aynı hafif sinyal — daha fazla ödeyip bir sıralama artışı beklemeyin.
• Görünür bir kuruluş adı / düzenlemeye tabi sektör istiyorum → OV/EV — ancak bunun kimlik satın aldığını, SEO satın almadığını anlayın.
• Birden fazla alt alan adı → joker karakter yalnızca bir etiket derinliğini kapsar; derin alt alan adları için SAN/çok alanlı bir sertifika gerekir.

“Başlatma sonrası bir sıralama düşüşü göründü — panik mi yoksa beklemek mi?”

• İlk birkaç hafta içinde ve yavaşça toparlanıyor → bekle. Bu, dizinin HTTP’yi HTTPS ile değiştirmesidir. Normal.
• Birkaç hafta sonra toparlanmıyor → bir şey bozuldu. Sırayla kontrol edin: başıboş robots.txt engeli → hayatta kalan noindex → kurallar hâlâ http:// üzerinde → dahili bağlantılar hâlâ http:// üzerinde → yönlendirme zincirleri → sayfaları engelleyen karışık içerik.

“HSTS’yi şimdi açmalı mıyım?”

• Başlatma günü / geçiş henüz istikrarlı olduğu kanıtlanmadı → hayır. HSTS, ihtiyacın olursa HTTP’ye geri dönüşü çok daha az uygulanabilir kılar.
• HTTPS bir süredir sorunsuz çalışıyor ve yenileme otomatik → başlığı ekleyin.
• Ön yükleme listesini düşünüyor musunuz? → yalnızca geri dönmeyeceğinizden emin olduğunuzda; kaldırma gerçekten mümkün ama yavaş ve operasyonel olarak riskli, kelimenin tam anlamıyla tek yönlü bir kapı değil.

“Dört Search Console mülkünün tümünü doğrulamam gerekiyor mu?”

• Yalnızca süreklilik istiyorum, bölümlenmiş verilerle ilgilenmiyorum → hayır. Bir Domain mülkü ekleyin; tüm şema/ana bilgisayar varyantlarını otomatik olarak kapsar.
• HTTP’de kalan trafiği canlı HTTPS sitesiyle karşılaştırmak istiyorum → bu bölüm için ayrı URL-ön eki mülklerini koruyun veya ekleyin — isteğe bağlı, zorunlu değil.

“Change of Address aracına ihtiyacım var mı?”

• HTTP → HTTPS, aynı alan adı → hayır. Google bunu açıkça söylüyor.
• Gerçek alan adını değiştiriyorum → evet — ancak bu farklı bir geçiştir.

“Eski bir URL’nin belirgin bir HTTPS ikizi yok — nereye yönlendirilir?”

• Protokol değişikliği için her zaman bir ikiz vardır → https:// üzerinde aynı yol, tek atlama.
• Sayfa gerçekten yok → bu bir içerik kararıdır (404/410 veya en yakın ilgili sayfaya yönlendirme) — hepsini ana sayfaya yığmayın.

HTTP → HTTPS geçiş kontrol listesi

Öncesi (kıyaslama + hazırlık)

• Canlı HTTP sitesinin tam taraması kaydedildi (her 200 + mevcut her yönlendirme + hedef).
• Sıralama anlık görüntüsü, GSC dışa aktarımı (Performans, Sayfa Dizine Ekleme, Tarama İstatistikleri) ve geri bağlantı profili arşivlendi.
• Mevcut robots.txt ve noindex yönergeleri kaydedildi.
• TLS sertifikası alındı (ücretsiz DV yeterlidir), 2 048 bit anahtar, otomatik yenileme yapılandırıldı.
• Joker kapsamı, alt alan adı derinliğinize göre kontrol edildi.
• Tüm geçiş, hazırlık ortamında prova edildi: her yol biçimi yönlendirilir, döngü yok, engellenebilir karışık içerik yok, canonical’lar HTTPS yayar.
• Lansman, daha düşük trafikli bir zaman dilimine planlandı.
• Bunun gerçekten yalnızca protokol değişikliği olduğu doğrulandı: ana bilgisayar, yollar, sorgu dizeleri, içerik ve platform tümü değişmedi.

Geçiş

• Her HTTP URL’si, HTTPS karşılığına sunucu tarafında ve birebir 301 yönlendirilir.
• Yönlendirme zinciri yok — eski URL’ler, tek adımda nihai HTTPS hedefine ulaşır.
• Eşleşmeyen URL’ler için ana sayfaya toplu yönlendirme yok.
• Her sayfa, HTTPS URL’sine rel="canonical" ile kendine referans verir.
• Dahili bağlantılar, XML site haritaları ve hreflang HTTPS’ye güncellendi (yönlendirmelere bırakılmadı).
• og:url / JSON-LD / sabit kodlanmış mutlak URL’ler HTTPS’ye güncellendi.
• Engellenebilir karışık içerik (komut dosyaları, stiller, iframe’ler, XHR) düzeltildi — bunlar doğrudan engellenir.
• Yükseltilebilir karışık içerik (görseller, medya) düzeltildi — yalnızca tarayıcının otomatik yükseltmesine güvenmeyin; geçiş ağı olarak upgrade-insecure-requests CSP ayarlandı, bir düzeltme değil.
• Yalnızca geçişe özgü noindex veya robots.txt engeli kaldırıldı.

Search Console ve sonrası

• GSC’de alan adı mülkü eklendi (önerilen varsayılan) — veya özellikle bölümlenmiş veri istiyorsanız HTTPS URL önek mülkleri ayrı ayrı doğrulandı.
• Yeni HTTPS site haritası gönderildi; eski HTTP mülkleri, izleme için doğrulanmış olarak tutuldu (varsa).
• Adres Değişikliği aracı kullanılmadı (yalnızca alan adı taşımaları için).
• Reddetme dosyası (varsa) HTTP URL’leri için incelendi.
• Yönlendirmeler en az 1 yıl boyunca bir taban olarak tutuldu, kaldırma tarihi olarak değil — ideal olarak sitenin ömrü boyunca.
• HTTP dinleyicisi, yönlendirmenin altında canlı tutuldu (sınırlı geri alma güvenlik ağı, garantili geri alma değil).
• HSTS, lansman gününde etkinleştirilmedi; yalnızca HTTPS kararlı olduğunu kanıtladıktan sonra eklendi.
• TLS/tarayıcı davranışı, Tarama İstatistikleri, Sayfa Dizine Ekleme, URL İnceleme, günlükler ve analiz/iş sonuçları 2–4 hafta boyunca izlendi (sabit bir bitiş tarihi yok); iyileşmeyen bir düşüş = bir şey bozuldu.

Standart işletim prosedürü: geçişi çalıştırın

Tekrarlanabilir bir runbook. Her aşamaya bir sahip atayın; hazırlık ortamı provasını atlamayın.

T-eksi (bir hafta önce) — kıyaslama ve oluşturma

1. Canlı HTTP sitesini tarayın; durum kodları ve mevcut yönlendirmelerle tam URL listesini dışa aktarın.
2. GSC’yi (Performans, Sayfa Dizine Ekleme, Tarama İstatistikleri) dışa aktarın ve sıralamaları + geri bağlantıları anlık görüntüleyin.
3. DV sertifikasını hazırlık ortamında edinin ve kurun; zincirin doğrulandığını onaylayın (SSL Labs).
4. Tek sunucu tarafı 301 kuralını oluşturun (http → https, yolu + sorguyu koruyun).
5. Şablonları, canonical’lar, dahili bağlantılar, site haritaları, hreflang ve OG/JSON-LD HTTPS yayacak şekilde güncelleyin.
6. Hazırlık ortamında karışık içerik taraması yapın; önce engellenebilir, sonra yükseltilebilir olanları düzeltin.

T-sıfır (lansman, düşük trafikli zaman dilimi) 7. Sertifikayı üretime dağıtın; HTTPS’in geçerli bir zincirle hizmet verdiğini doğrulayın. 8. 301 kuralını etkinleştirin. Hemen örnek kontrol yapın: birkaç URL’nin her biri doğru HTTPS URL’sine tek bir 301 döndürür. 9. Ana sayfanın ve üst şablonların konsolda karışık içerik hatası olmadan işlendiğini doğrulayın. 10. Yalnızca geçişe özgü noindex/robots.txt engelini kaldırın.

T-artı (ilk saat → ilk gün) 11. Eski HTTP URL listesini yeniden tarayın; tek atlamalı 301’leri, zincir, 404 ve döngü bulunmadığını doğrulayın. 12. GSC’ye önerilen varsayılan olarak bir Domain mülkü ekleyin; yalnızca ayrıştırılmış veri istiyorsanız HTTPS URL-prefix mülklerini tek tek doğrulayın. HTTPS site haritasını gönderin. 13. Yeni yük altında 5xx sıçramaları için sunucu günlüklerini ve hata oranlarını izleyin.

T-plus (ilk 2–4 hafta) 14. GSC Tarama İstatistikleri + Sayfa Dizinlemeyi günlük izleyin: HTTPS URL’leri → “Dizinlendi,” HTTP URL’leri → “Yönlendirmeli sayfa.” 15. Anahtar sayfalarda URL İnceleme’yi spot kontrol edin: bildirilen canonical = HTTPS, temiz işleniyor. 16. Kıyaslama noktanızla karşılaştırın; iyileşen bir düşüşü (yerleşme) takılı bir düşüşten (bozuk) ayırt edin ve ikincisini düzeltin. 17. Disavow dosyasını HTTP URL’leri için gözden geçirin.

T-artı (kararlı dönem → sürekli) 18. HTTPS’in kararlı olduğu kanıtlandıktan ve yenileme otomatikleştirildikten sonra HSTS başlığını ekleyin. 19. Preload’ı yalnızca geri dönmeye ihtiyaç duymayacağınızdan eminseniz düşünün; kaldırmak mümkündür fakat yavaş ve operasyonel açıdan risklidir. 20. 301’leri ve HTTP listener’ını en az bir yıl tutun; bu kaldırma tarihi değil alt sınırdır, ideal olan kalıcı tutmaktır. Bir olay yaşanırsa HTTP’ye geri dönmeyi düşünmeden önce HTTPS’i onarın. Önbellek, çerezler ve service worker’lar geri dönüşü eksik bırakabilir.

Duruma göre oyun kitapları

Paylaşımlı hosting’de küçük site (birkaç yüz URL) Ücretsiz bir Let’s Encrypt sertifikası alın (çoğu host tek tıkla yapar), tek 301 kuralını ekleyin, iç bağlantıları ve site haritasını güncelleyin, DevTools’ta bir karışık içerik taraması yapın, GSC’de HTTPS Domain özelliğini doğrulayın. Hepsini bir öğleden sonra yapabilirsiniz. Ana risk, unutulmuş sabit kodlanmış bir http:// varlığıdır — onu tarayın.

CDN arkasındaki büyük site (100k+ URL) 301’i edge katmanına (CDN/reverse proxy) yerleştirin; böylece uygulama başına mantık yerine ölçekte tek kural çalışır. Önce sağlam bir kıyaslama alın: geçiş öncesi tarama ve GSC dışa aktarımı tek güvenlik ağınızdır. Dizinin geçişinin küçük sitelere göre daha uzun sürmesini bekleyin. Yük altında 5xx için Crawl Stats’i izleyin; eski HTTP yönlendirmelerinin yenilerle üst üste binip zincir oluşturmasına dikkat edin. Tek atlamalı 301’leri doğrulamak için gruplar hâlinde yeniden tarayın.

Mevcut yönlendirme katmanı olan site (geçmiş geçişler, kısa URL’ler) Tuzak yığmadır: http://old → http://new → https://new. Kaynak kurallarını yeniden yazın, böylece her eski URL tek atlamada nihai HTTPS hedefine ulaşır. Başlatmadan sonra zincirleri açıkça denetleyin — eşitlik burada sızar.

hreflang’lı uluslararası site Her hreflang ek açıklaması ve geri dönüş bağlantıları HTTPS alternatiflerine başvurmalıdır. Yarı göç edilmiş bir hreflang kümesi (bazı http, bazı https) hedeflemeyi sessizce bozar. Tüm ek açıklamaları HTTPS üzerinde tek bir doğruluk kaynağından yeniden oluşturun.

Zaten geçiş yaptınız, sıralamalar düştü ve toparlanmadı Tanıyı sırayla çalışın: (1) robots.txt içinde engellenen veya artık noindex taşıyan bir şey var mı? (2) canonicals https://’yi mi gösteriyor? (3) iç bağlantılar HTTP üzerinde mi? (4) yönlendirme zincirleri veya döngüler var mı? (5) engellenebilir karışık içerik sayfaları bozuyor mu veya kötü bir sertifika Google’ın canonical tercihini HTTP’ye mi çeviriyor? Çoğu “HTTPS sıralamalarımı öldürdü” hikayesi bu beşinden biridir — protokol değişikliğinin kendisi değil. Altta yatan HTTPS sorununu doğrudan düzeltin; ilk hamle olarak HTTP’ye geri dönüşe atlamayın.

Ne yapılmamalı

• Her şeyi ana sayfaya yönlendirmek. En yıkıcı geçiş hatasıdır. Her eski URL kendi HTTPS karşılığına ulaşmalıdır. Google, çok sayıda eski URL’yi ana sayfa gibi ilgisiz tek hedefe yönlendirmemeyi açıkça söyler.
• 301 yerine 302 kullanmak. 302 geçici yönlendirmedir ve taşımanın kalıcı olmadığını bildirir. Arama motorlarının URL’yi ve değerini tam aktarması için 301 kullanın.
• Yönlendirme zinciri oluşturmak. http://a → http://b → https://b tarama bütçesini ve hızı tüketir. Doğrudan nihai HTTPS hedefine yönlendirin.
• İç bağlantıları http:// üzerinde bırakmak. Temizliği 301’e bırakmak, her iç tıklama ve taramada yönlendirme çalıştırır. Bağlantıları düzeltin.
• Canonical’ları hâlâ http:// adresine yöneltmek. Eski şemaya referans veren self-canonical, geçişle çelişir ve canonical seçimini karıştırır.
• Engellenebilir karışık içeriği yayın sonrasına bırakmak. Engellenen stil dosyası veya JS paketi ilk gün gerçek kullanıcılar için sayfayı bozabilir. Bu içeriği geçişten önce düzeltin.
• Protokol değişiminde Change of Address aracını kullanmak. Bu araç alan adı taşımaları içindir; Google burada gerekmediğini söyler.
• Dört GSC mülkünün de doğrulanması gerektiğini varsaymak. Tek Domain mülkü tüm şema/ana bilgisayar varyantlarını otomatik birleştirir. Yalnızca eski HTTP mülkünü doğrulayıp HTTPS’i gören hiçbir mülk eklememek ise kaçınılması gereken gerçek hatadır.
• Yayın günü HSTS veya preload etkinleştirmek. HTTPS sitesi bozuk çıkarsa HTTP’ye geri dönüşü çok daha az uygulanabilir kılar. Yalnızca HTTPS kararlı olduktan sonra ekleyin.
• Geçişe özgü noindex değerini üretimde bırakmak. Hazırlık ortamını korumak için eklenen ve unutulan noindex ya da robots.txt engeli yeni siteyi sessizce dizinden çıkarır.
• HTTP listener’ını hemen kapatmak. 301’lerin çalışacağı kaynak ve yönlendirme kuralını geri alma seçeneği kalması için açık tutun.
• “HTTP’yi açık tutmayı” garantili geri alma sanmak. Önbellekteki yönlendirmeler, çerezler ve service worker’lar HTTP’yi yeniden sunmayı güvensiz veya eksik kılabilir. Önce HTTPS’i onarın; geri dönüşü rutin işlem değil son çare sayın.

HTTP → HTTPS göçü — kopya kağıdı

Yönlendirme ve eşleme gerçekleri

Sertifika gerçekleri

Yeniden yönlendirilecek sinyaller

Karışık içerik ve HSTS

GSC özellikleri Bir Domain özelliği, tüm şema/ana bilgisayar varyantlarını otomatik olarak birleştirir — önerilen varsayılan. URL öneki özellikleri (http://example.com · http://www.example.com · https://example.com · https://www.example.com) isteğe bağlı segmentasyondur, evrensel bir gereklilik değildir.

301’i zorla (sunucu tarafı)

Protokol yönlendirmesini uygulama kodunda değil, sunucu/edge yapılandırmasında yapın. Önce staging’de test edin — hatalı bir kural, herkesi dışarıda kilitleyen bir yönlendirme döngüsü oluşturabilir.

Apache (.htaccess)

# 301 every HTTP request to the same path on HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Nginx

# Dedicated port-80 server block that 301s to HTTPS, preserving host + path
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Bir URL’nin temiz tek atlamalı 301 döndürdüğünü doğrulayın

Her eski URL’nin doğrudan HTTPS karşılığına 301 döndürdüğünü doğrulayın; 302 veya zincir olmamalıdır.

macOS / Linux

# Show every hop and status code for one URL
curl -sIL http://example.com/some/page \
  | grep -Ei '^(HTTP/|location):'
# Want a single 301 -> https://example.com/some/page -> 200, no extra hops

Windows (PowerShell)

# Follow redirects and print each status + Location
$r = Invoke-WebRequest -Uri "http://example.com/some/page" -MaximumRedirection 10
$r.BaseResponse.ResponseUri.AbsoluteUri   # final URL should be https://

HTML’de kalan karışık içeriği bulun

İşlenmiş bir sayfada güvenli olmayan alt kaynakları (script/stil/görsel/iframe) grep ile arayın.

macOS / Linux

curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Chrome DevTools Konsolu — canlı sayfadaki güvenli olmayan alt kaynakları işaretleyin

Herhangi bir HTTPS sayfasındaki Konsol’a yapıştırın; hâlâ http:// adresine işaret eden tüm öğeleri listeler (karışık içerik olmayan normal çapa bağlantılarını atlar):

[...document.querySelectorAll('[src],link[href],iframe[src]')]
  .map(el => el.src || el.href)
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('Insecure sub-resource:', u));

Yayından sonra URL listesini toplu kontrol edin (tek atlamalı 301’ler)

Kayıtlı HTTP URL listenizi besleyin ve temiz tek atlamalı 301 olmayan her şeyi işaretleyin.

macOS / Linux

# urls.txt = one http:// URL per line (from your pre-migration crawl)
while read -r u; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -I "$u")
  loc=$(curl -sI "$u" | awk -F': ' 'tolower($1)=="location"{print $2}' | tr -d '\r')
  echo "$code  $u  ->  $loc"
done < urls.txt

Tüm siteyi taramak için Ahrefs Site Audit veya Screaming Frog gibi bir tarayıcı, her URL için ayrı betik yazmaktan daha hızlıdır; yine de bu parçacıklar örnek kontroller ve CI için kullanışlıdır.

Lansman öncesi geçiş eşlemesini denetleyin

Act as a technical SEO reviewing an HTTP-to-HTTPS migration. I will provide a crawl
of live HTTP URLs, the current redirect export, the proposed HTTPS URL list, and a
staging crawl.

For every old URL, determine whether it maps one-to-one to the same host, path, and
query on HTTPS. Flag redirect chains, loops, 302s, homepage dumps, missing targets,
HTTP canonicals, HTTP internal links, HTTP sitemap or hreflang entries, blockable
mixed content, and staging noindex/robots blocks.

Return a table with old URL, observed status, first target, final target, expected
target, issue, severity, owner, and retest. Separate launch blockers from normal
post-launch index settling. Do not recommend the Change of Address tool for this
protocol-only move.

Lansman sonrası düşüşü teşhis edin

Compare the pre-launch crawl and Search Console exports with the post-launch crawl,
logs, Page Indexing, Crawl Stats, and URL Inspection samples. Test for blocked
crawling, surviving noindex, HTTP canonicals or internal links, redirect chains or
loops, 5xx responses, and mixed-content rendering failures. Explain which evidence
shows normal HTTP-to-HTTPS canonical crossover and which evidence shows a broken
migration. Give the smallest reversible fix and a validation query for each finding.

Yalnızca protokol geçiş çerçevesi

HTTP→HTTPS’i bir sertifika kurulumu olarak değil, birbirine bağlı dört sistem olarak ele alın:

1. Taşıma: HTTPS, gereken her ana bilgisayar adında geçerli bir sertifika ve eksiksiz bir zincir sunar.
2. Yönlendirme: Her HTTP URL’si, tam HTTPS karşılığına tek bir kalıcı, sunucu tarafı yönlendirmesi döndürür. 301, URL anlamını koruyan köprüdür; Google, kalıcı yönlendirmelerin PageRank kaybettirmediğini söyler.
3. Sinyaller: Canonical’ler, iç bağlantılar, site haritaları, hreflang ve yapılandırılmış URL referanslarının tümü, tarayıcıların taşımayı yönlendirmeler yoluyla yeniden keşfetmesini sağlamak yerine HTTPS üzerinde hemfikirdir.
4. Gözlem: Kaydedilmiş bir temel çizgi, lansman sonrası tarama, günlükler ve Search Console, beklenen bir dizin geçişini teknik bir arızadan ayırt eder.

Yalnızca protokol kapsamı, yalnızca ana bilgisayar, yol, sorgu davranışı, içerik ve işleme eşdeğer kaldığında riski düşük tutar. Bunlar aynı anda değişirse, her arızanın teşhis edilebilir bir nedeni olması için işi ayrı geçişlere bölün.

Geçiş doğrulama araçları

• Yönlendirme Denetleyicisi — tek bir HTTP URL’sinin tam yolunu inceleyin ve eşleşen HTTPS URL’sine tek adımda ulaştığını doğrulayın.
• Toplu HTTP Durum Kodu Denetleyicisi — kaydedilmiş lansman öncesi URL kümesini kalıcı yönlendirmeler, bozuk hedefler, döngüler ve beklenmeyen durumlar için yeniden test edin.
• Canonicalization Denetleyicisi — son HTTPS sayfasının, HTTP’ye geri işaret etmek yerine amaçlanan HTTPS canonical’ini bildirdiğini doğrulayın.

Sonuçları lansman öncesi ve sonrası dışa aktarın. Bir araç sonucu, izole olarak değerlendirilmek yerine onaylanmış URL eşlemesiyle karşılaştırılabildiğinde en kullanışlıdır.

Geçiş sürüm testleri

Test 1: hazırlık provası

• Amaç: Yönlendirmeler kullanıcıları veya tarayıcıları etkilemeden önce içeriğin ve sinyallerin HTTPS’e hazır olduğunu kanıtlayın.
• Yöntem: Hazırlık ortamında temsili yolları ve şablonları tarayın; canonical’leri, iç bağlantıları, hreflang’i, site haritalarını, robots yönergelerini ve işlenmiş kaynak URL’lerini inceleyin.
• Beklenen sonuç: Sayfalar eşdeğer şekilde işlenir, HTTPS sinyalleri yayar, engellenebilir karışık içerik içermez ve yalnızca geçişe özgü tarama veya dizin engeli taşımaz.
• Arıza tetikleyicisi: HTTP sinyalleri, engellenen kaynaklar, sertifika hataları veya devam eden bir noindex/robots kısıtlaması.
• Sonraki adım: Lansmanı tutun ve kaynak şablonu veya yapılandırmayı düzeltin.

Test 2: bire bir yönlendirme tekrarı

• Amaç: Üretim yönlendirmesinin her eski URL’nin hedefini koruduğunu doğrulayın.
• Yöntem: Kaydedilmiş HTTP URL taramasını toplu durum denetleyicisi aracılığıyla yeniden oynatın ve ilk ve son hedefleri onaylanmış eşlemeyle karşılaştırın.
• Beklenen sonuç: Her eski URL, son yanıtı sağlıklı olan tam HTTPS karşılığına tek bir kalıcı yönlendirme döndürür.
• Arıza tetikleyicisi: Bir zincir, döngü, 302, ana sayfa dökümü, değiştirilmiş yol/sorgu, 4xx veya 5xx hedefi.
• Sonraki adım: Kaynak yönlendirme kuralını düzeltin; tekrar geçene kadar geri alma için HTTP dinleyicisini kullanılabilir tutun.

Test 3: lansman sonrası arama sinyali kontrolü

• Amaç: Tarayıcıların tutarlı bir geçiş hikayesi aldığını doğrulayın.
• Yöntem: Ana HTTPS URL’lerini inceleyin ve kaydedilmiş temel çizgiye karşı günlükleri, Tarama İstatistiklerini ve Sayfa Dizinlemeyi izleyin.
• Beklenen sonuç: HTTPS URL’leri taranır ve canonical olarak seçilirken, HTTP URL’leri giderek artan şekilde yönlendirilmiş olarak görünür; yanıt hataları sitenin belirlenmiş temel çizgisi içinde kalır.
• Arıza tetikleyicisi: Kalıcı HTTP canonical’leri, yaygın engellenen tarama, yönlendirme döngüleri veya önemli bir 5xx artışı.
• Sonraki adım: Önceden tanımlanmış geri alınabilir düzeltmeyi uygulayın; HTTPS sürümü kararlı olana kadar HSTS’yi etkinleştirmeyin.

Zaman ayırmaya değer kaynaklar

Konuşmalarım

• Better Safe Than Sorry with HTTPS — SMX East 2016 (SlideShare) — TLS, yaygın HTTPS uygulama hataları ve geçiş tuzakları hakkındaki derinlemesine incelemem: 302 yerine 301 hataları, eksik HTTPS canonical’ları, Bing/Baidu tarafından dizinden çıkarılmanıza neden olabilecek TLS SNI yanlış yapılandırmaları ve HTTPS→HTTP bağlantılarındaki yönlendirme verisi (“karanlık trafik”) kaybı. (Geçerli feragatname geçerlidir: bu sistemlere dair anlayışımdır ve içindeki benimseme istatistikleri 2016 yılına aittir.)

İlgili yazılarım

• The Beginner’s Guide to Technical SEO — geçişlerin ve HTTPS’in büyük resimde nereye oturduğu.

Sektörden kaynaklar

• Google’ın URL değişiklikleriyle site taşıma rehberi — sunucu tarafı 301’ler, tek atlamalı yönlendirmeler, yönlendirmeleri en az bir yıl tutma ve HTTP→HTTPS için Change of Address kullanmama kurallarıyla temel geçiş planı.
• Google’ın Sunucularınızda HTTPS’i etkinleştirme ve Karışık içeriği düzeltme belgeleri — en yoğun ve kullanışlı uygulama rehberleri.
• Let’s Encrypt — yerleşik yenilemeye sahip ücretsiz, otomatik DV sertifikaları; sıralama sinyali için gereken budur.
• SSL Labs sunucu testi — sertifika kurulduktan sonra TLS yapılandırmasını derecelendirin.
• hstspreload.org — preload kararı vermeden önce uygunluğu kontrol edin ve kaldırma uyarılarını okuyun.
• HSTS nedir ve nasıl kullanılır? (Kinsta) — preload’a bağımlı kalma riskini kapsayan uygulamalı HSTS rehberi.
• HTTPS kolaydır (Troy Hunt) — TLS kurulumunu sıfırdan anlaşılır kılan kısa video serisi.

Alıntı yapmaya değer istatistikler

• 301 yönlendirmeleri PageRank kaybettirmez. Google’ın net ifadesi — “HTTPS’ye geçmek bağlantı değeri kaybettirir” efsanesini çürüten ve tüm geçiş yaklaşımını tanımlayan sayı. Kaynak
• Yönlendirmeleri en az 1 yıl tutun. Google’ın önerdiği minimum — kaldırmanın güvenli olduğu bir sınır değil; çoğu site bunları süresiz tutar. Kaynak
• Chrome 68’den (Temmuz 2018) bu yana tüm HTTP sayfaları “Not Secure” olarak işaretleniyor. HTTPS geçişini isteğe bağlı olmaktan çıkarıp zorunlu hale getiren son tarih. Kaynak
• Web sitelerinin yaklaşık %89’u artık HTTPS kullanıyor. Geçiş, geri kalan olmamakla ilgilidir, sıralama kazancıyla değil (W3Techs, 2026; güncel rakamı doğrulayın).
• Googlebot bir yönlendirme zincirinde 10 atlamaya kadar (10 hops) takip eder, ancak Google doğrudan nihai hedefe yönlendirmeyi önerir — “zincir yok” kuralının arkasındaki sınır. Kaynak

Kendinizi test edin: HTTP’den HTTPS’e Geçiş

HTTP→HTTPS geçişi yürütmeyle ilgili beş hızlı soru. Her biri için bir cevap seçin, ardından kontrol edin.

Değişiklik günlüğü