HTTP’den HTTPS’ye Geçiş Rehberi: SEO Kayıpsız SSL Migrasyonu, HSTS ve Canonical Ayarları

HTTPS’e Geçiş Neden Sadece Güvenlik Değil, Stratejik Bir SEO Kararı?

Artık modern tarayıcıların neredeyse tamamı HTTP siteleri “Güvenli değil” olarak işaretliyor, birçok kullanıcı kredi kartı bile girmediği kurumsal sitelerde dahi bu uyarıdan rahatsız olarak sayfayı terk ediyor. Aynı anda arama motorları da HTTPS’i uzun süredir bir sıralama sinyali olarak kullanıyor. Dolayısıyla HTTP’den HTTPS’ye geçiş bugün teknik bir ayrıntı değil, doğrudan gelir ve marka algısı etkisi olan stratejik bir karar.

Bu geçişi yanlış planladığınızda; kırık yönlendirmeler, yanlış canonical etiketleri, hatalı HSTS kullanımı ve mixed content sorunları nedeniyle hem SEO hem dönüşüm tarafında ciddi kayıplar yaşayabilirsiniz. DCHost ekibi olarak onlarca HTTPS geçişinde gördüğümüz tipik hataları ve en iyi uygulamaları bu rehberde topladık. Adım adım ilerleyerek; SSL kurulumu, 301 yönlendirme, HSTS, canonical ve Search Console ayarlarını doğru kurguladığınızda HTTP → HTTPS migrasyonunu neredeyse sıfır SEO kaybıyla tamamlayabilirsiniz.

HTTP → HTTPS konusunda daha temel bir bakış arıyorsanız, bu yazıyı okuduktan sonra HTTP’den HTTPS’e geçiş adımlarını özetlediğimiz rehberimize de göz atabilirsiniz.

Geçiş Öncesi Hazırlık: Envanter, Mimari ve Planlama

1. Mevcut URL ve alan adı mimarinizi netleştirin

Başarılı bir HTTPS migrasyonunun ilk adımı, neleri taşıdığınızı tam olarak bilmek. Şu soruların cevaplarını mutlaka yazılı hale getirin:

• Site için resmi (canonical) alan adınız hangisi? www.ornek.com mu, yoksa ornek.com mu?
• Park ettiğiniz veya yönlendirdiğiniz başka alan adları var mı? (örn. orneksite.com → ornek.com)
• Blog, mağaza, panel gibi subdomain’leriniz var mı? (örn. blog.ornek.com, shop.ornek.com)
• Statik içerik veya CDN için ayrı bir alan adınız var mı? (örn. static.ornek.com)

Bu mimariyi düzgün kurmak için daha önce detaylı anlattığımız www mi çıplak alan adı mı tercih etmeniz gerektiğini anlatan canonical domain rehberimizi mutlaka okumanızı öneririz. Ayrıca birden fazla domain kullanıyorsanız, birden fazla alan adını aynı siteye yönlendirme ve park domain stratejileri yazımız da işinize yarayacaktır.

2. SEO risk analizi yapın

HTTPS geçişi teknik olarak “site çapında URL değişikliği” demektir. Yani Google’ın gözünde tüm sayfalarınız yeni bir adrese taşınıyor. Bu nedenle:

• En çok trafik alan ilk 100–500 URL’i listeleyin.
• Backlink gelen önemli sayfaları belirleyin.
• Özel kampanya, landing page ve ödeme sayfalarını ayrı not edin.

Hedefiniz, bu sayfalar için 1:1 bire bir 301 yönlendirme sağlamaktır. Genel bir “her şeyi anasayfaya at” kuralı, SEO açısından büyük kayıplara yol açar. Eğer yakın zamanda alan adı değişimi de yapmayı planlıyorsanız, bunu tek seferde (HTTP → HTTPS ve eski domain → yeni domain) yapmak gerekir. Bu konuda detaylı bir perspektif için alan adı değiştirirken SEO kaybını önleme rehberimizi inceleyebilirsiniz.

3. Doğru SSL sertifikasını seçin

Tek domainli basit bir kurumsal siteden, onlarca subdomain kullanan SaaS uygulamasına kadar farklı senaryolar için uygun sertifika türü değişir. Kısa özet:

• DV (Domain Validation): En yaygın, hızlı ve otomatik alınabilen sertifika türü. Çoğu blog, içerik sitesi ve KOBİ için yeterli.
• OV (Organization Validation): Organizasyon bilgisi doğrulanır, B2B kurumsal sitelerde tercih edilir.
• EV (Extended Validation): Daha kapsamlı şirket doğrulaması; yüksek regülasyonlu alanlarda (finans, hukuk, sağlık) mantıklı olabilir.
• Wildcard: *.ornek.com gibi, tüm subdomain’leri kapsar.
• SAN / Multi-domain: Birden çok farklı alan adını tek sertifikada toplar.

Bu kararları daha sağlam verebilmek için DV, OV ve EV SSL sertifikaları arasındaki farkları anlattığımız detaylı yazımıza ve B2B yapılar için hazırladığımız B2B kurumsal siteler için SSL ve güven mimarisi rehberimize göz atabilirsiniz.

SSL Kurulumu ve Test: Sunucu Tarafında Yapılması Gerekenler

1. DNS ve hosting tarafı önkontroller

SSL kurulumuna başlamadan önce:

• Alan adınızın doğru IP’ye çözüldüğünden emin olun (A / AAAA kayıtları).
• Reverse proxy / CDN (örneğin HTTP/3 destekli bir CDN) kullanıyorsanız, origin ve CDN arasındaki SSL modunu planlayın.
• Test için düşük TTL (300s gibi) kullanmanız, olası geri alımları hızlandırır.

DNS mimariniz karmaşıksa, nameserver ve DNS stratejisini doğru kurma rehberimize bakmanız faydalı olacaktır.

2. Sunucuya SSL sertifikası kurma

DCHost üzerinde paylaşımlı hosting, yönetilen VPS veya dedicated sunucu kullanıyor olun; panel üzerinden SSL kurulumunu birkaç adımda tamamlayabilirsiniz. Örneğin Let’s Encrypt ile otomatik DV sertifikası kullanıyorsanız, cPanel/DirectAdmin’de ilgili alan adı için “AutoSSL” veya eşdeğeri özelliği aktif etmek yeterli olabilir. Bu süreci daha detaylı görmek isterseniz Let’s Encrypt ile ücretsiz SSL kurulumu rehberimizi inceleyin.

VPS veya dedicated üzerinde manuel kurulum yapıyorsanız tipik Nginx yapılandırması şöyle görünür:

server {
    listen 443 ssl http2;
    server_name ornek.com www.ornek.com;

    ssl_certificate     /etc/ssl/certs/ornek.com.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/ornek.com.key;

    # Modern TLS ayarları
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers   HIGH:!aNULL:!MD5;

    root /var/www/ornek.com/public;
}

Apache için ise tipik bir VirtualHost örneği:

<VirtualHost *:443>
    ServerName ornek.com
    ServerAlias www.ornek.com

    DocumentRoot /var/www/ornek.com/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/ornek.com.crt
    SSLCertificateKeyFile /etc/ssl/private/ornek.com.key
    SSLCertificateChainFile /etc/ssl/certs/ornek.com.ca-bundle
</VirtualHost>

3. Mixed content ve güvensiz içerik testleri

Tarayıcı adres çubuğunda kilit simgesini görmeniz, sitenizin tamamen güvenli olduğu anlamına gelmez. Sayfa HTML’i HTTPS ile gelse bile, içinde HTTP ile çağrılan görseller, CSS, JS veya iframe’ler varsa mixed content hataları alırsınız. Bunlar hem güvenlik hem de kullanıcı deneyimi açısından sorun çıkarır.

Bu aşamada:

• Tarayıcı konsolunda (F12 → Console / Security) mixed content uyarılarını inceleyin.
• WordPress, Laravel gibi sistemlerde base URL ayarlarını https:// olacak şekilde güncelleyin.
• Veritabanında gömülü HTTP linklerini arayıp toplu güncelleyin.

Özellikle WordPress projelerinde bu konu sık karşımıza çıktığı için, SSL sonrası mixed content ve güvensiz içerik hatalarını düzeltme rehberimizi adım adım takip etmenizi öneririz.

SEO Kayıpsız Geçiş İçin 301 Yönlendirme ve Canonical Stratejisi

1. Tek bir canonical domain seçin

Hem SEO hem de HSTS açısından tek bir ana domain seçmeniz gerekir. Örneğin:

• Resmi adresiniz https://www.ornek.com ise, https://ornek.com ve tüm HTTP varyasyonları buraya 301 ile yönlenmelidir.
• Resmi adresiniz https://ornek.com ise, tersi şekilde www’den çıplağa yönlendirme yapmalısınız.

Bu kararın artı/eksi’lerini ve HSTS ile ilişkisini detaylı açıkladığımız www mi çıplak alan mı sorusuna teknik cevap verdiğimiz rehber, geçiş öncesi mutlaka göz atmanız gereken bir kaynak.

2. HTTP → HTTPS 301 yönlendirme kuralları

Hedefiniz, tüm HTTP isteklerini bire bir HTTPS muadil sayfaya 301 ile yönlendirmek olmalı. Yani:

• http://ornek.com/urun/kirmizi-elbise → https://ornek.com/urun/kirmizi-elbise
• http://www.ornek.com/blog/yazi → https://www.ornek.com/blog/yazi

Apache (.htaccess) için tipik bir kural seti:

RewriteEngine On

# Tüm HTTP'yi HTTPS'ye zorla
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Canonical domaininizi de sabitlemek isterseniz, örneğin sadece www.ornek.com kullanacaksanız:

RewriteEngine On

# ornek.com'u www.ornek.com'a yönlendir
RewriteCond %{HTTP_HOST} ^ornek.com [NC]
RewriteRule ^(.*)$ https://www.ornek.com/$1 [L,R=301]

# HTTP'yi HTTPS'ye zorla
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.ornek.com/$1 [L,R=301]

Nginx için benzer bir kurgu:

server {
    listen 80;
    server_name ornek.com www.ornek.com;

    return 301 https://www.ornek.com$request_uri;
}

Burada en kritik nokta redirect loop oluşturmamak ve tüm varyasyonların tek bir hedefe (canonical domain) gitmesini sağlamak.

3. Canonical etiketlerini güncellemek

HTTP → HTTPS geçişinde sık gördüğümüz hatalardan biri, sayfa başlıklarında hâlâ HTTP içeren rel="canonical" etiketlerinin kalması. Bu durumda arama motoruna “Bu sayfanın aslı HTTP versiyonudur” demiş olursunuz ki, migrasyonu fiilen boşa çıkarır.

Yapmanız gerekenler:

• Tema veya layout dosyanızda canonical etiketini üreten kodu bulun.
• Base URL’yi https:// ile başlayacak şekilde düzeltin.
• Dil, filtre, sayfalama gibi parametreleri nasıl ele aldığınızı gözden geçirin.

Örnek bir canonical etiketi:

<link rel="canonical" href="https://www.ornek.com/urun/kirmizi-elbise" />

Özellikle çoklu domain veya subdomain kullanan yapılarda canonical stratejisi, park domain ve 301 yönlendirmelerle birlikte düşünülmelidir. Bu açıdan park alan adlarını, 301 yönlendirmeyi ve canonical kullanımı birlikte anlattığımız rehber iyi bir tamamlayıcıdır.

4. Sitemap, robots.txt ve dahili linkler

Geçiş sırasında aşağıdaki adımları atlamayın:

• sitemap.xml içindeki tüm URL’leri HTTPS olacak şekilde güncelleyin.
• robots.txt içinde referans verdiğiniz sitemap adresini HTTPS yapın.
• Site içi menü, footer, breadcrumb ve içerik linklerini mümkün olduğunca HTTPS’e çevirin.

Tek tek URL düzeltmek yerine sadece 301’e güvenmek teoride çalışsa da, pratikte her katmanda (HTML içeriği, canonical, sitemap, yönlendirme) tutarlı bir HTTPS kullanımı daha temiz ve izlenebilir bir mimari sunar. robots ve sitemap tarafını doğru kurmak için robots.txt ve sitemap.xml kurulum rehberimize de göz atabilirsiniz.

HSTS, Preload ve HTTP Güvenlik Başlıkları

1. HSTS nedir, ne işe yarar?

HSTS (HTTP Strict Transport Security), tarayıcıya “Bu alan adıyla <emdaima HTTPS üzerinden konuş” talimatı verir. Tarayıcı bir kez bu başlığı gördükten sonra, kullanıcı http:// adresi yazsa bile, arka planda otomatik olarak https:// isteği gönderilir.

Artıları:

• SSL strip gibi saldırıları zorlaştırır.
• Kullanıcı deneyimini iyileştirir; HTTP isteği bile görmeden HTTPS’e gider.

Eksileri ve riskleri:

• Yanlış bir sertifika veya yönlendirme kurgusunu “kilitlerseniz” geri almak zor olur.
• Özellikle preload listesine alındıysa, hata düzeltmesi haftalar/aylar sürebilir.

Bu yüzden HSTS’i HTTPS geçişi tamamen stabil hale geldikten sonra devreye almak en güvenli yaklaşımdır.

2. HSTS başlığını nasıl eklersiniz?

Temel bir HSTS başlığı şu şekildedir:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Nginx için örnek konfigürasyon:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache için:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Başlangıçta daha kısa bir max-age (örneğin 300 veya 86400 saniye) ile test edip, her şey sorunsuz çalışıyorsa süreyi 1 yıla çıkarıp includeSubDomains ve preload eklemek daha güvenli bir yaklaşımdır.

3. HSTS Preload ne zaman mantıklı?

HSTS Preload, alan adınızı tarayıcıların dahili “her zaman HTTPS” listesine aldırmanız anlamına gelir. Bunun için:

• Tüm site ve subdomain’lerinizin HTTPS ile sorunsuz çalıştığından emin olmanız,
• Hiçbir şekilde HTTP üzerinden erişim gerektiren bir alt yapı kullanmamanız,
• HSTS başlığınızı gerekli parametrelerle (özellikle includeSubDomains ve yeterli max-age) göndermeniz

gerekir. Preload başvurusu, geri dönüşü görece zor bir adımdır; bu yüzden ancak mimariniz oturduktan sonra düşünülmelidir.

HSTS ile birlikte kullanmanız gereken diğer güvenlik başlıklarını (CSP, X-Frame-Options, Referrer-Policy vb.) daha derinlemesine anlamak için HTTP güvenlik başlıkları rehberimizi mutlaka inceleyin.

Test, Yayına Alma ve İzleme Stratejisi

1. Staging ortamında HTTPS geçiş provasını yapın

Canlı site üzerinde doğrudan HTTPS geçişi yapmak yerine, aynı uygulamayı staging ortamında (örn. staging.ornek.com) HTTPS’e geçirip tüm sorunları önce burada görmek çok daha sağlıklıdır. Özellikle:

• Mixed content uyarıları,
• ESKI JS/CSS path’leri,
• 3. parti entegrasyon URL’leri (ödeme, kargo, CRM vb.)

genelde staging’de ortaya çıkar. Paylaşımlı hosting kullanıyorsanız, paylaşımlı hosting’de WordPress staging ortamı kurma rehberimizde bu süreci adım adım anlattık.

2. Search Console, Analytics ve sitemap güncellemeleri

HTTPS geçişinden hemen sonra:

• Google Search Console’da HTTPS versiyonunuz için ayrı bir mülk ekleyin.
• Güncel HTTPS sitemap’ini Search Console’a gönderin.
• Google Analytics ve benzeri araçlarda https:// base URL ayarlarını güncelleyin.
• Ücretli reklam kampanyalarınızda (Google Ads, sosyal medya) linkleri HTTPS olacak şekilde düzeltin.

Bu adımlar, Google’ın yeni URL yapınızı daha hızlı ve doğru şekilde taramasına yardımcı olur.

3. Sunucu logları ve hata izleme

Geçişin hemen ardından sunucu loglarını (access ve error log’lar) mutlaka yakından izleyin. Özellikle:

• 4xx (404, 410) hata oranlarındaki artış,
• 5xx (özellikle 502, 503) sunucu hata kodları,
• Beklenmeyen redirect zincirleri (301 → 301 → 301…)

SEO kaybının habercisi olabilir. Log okuma konusunda kendinizi geliştirmek istiyorsanız, Apache ve Nginx loglarıyla 4xx–5xx hatalarını teşhis rehberimiz ve sunucu loglarıyla Core Web Vitals iyileştirme fırsatlarını anlattığımız yazımız iyi bir başlangıç noktasıdır.

DCHost Müşteri Senaryolarından Öğrendiklerimiz

1. KOBİ e-ticaret sitesinde HTTPS geçişi ve sepet dönüşüm oranı

Bir KOBİ müşterimizin e-ticaret sitesinde HTTP → HTTPS geçişini planlarken ilk yaptığımız şey, sepet ve ödeme sayfalarını ayrı bir öncelik listesine almaktı. Önce staging ortamında SSL’i kurduk, tüm ödeme entegrasyon URL’lerini (banka, 3D Secure, sanal POS callback adresleri) HTTPS’e çektik ve mixed content testlerini tamamladık.

Canlı geçişi hafta içi gece trafiğinin en düşük olduğu zaman diliminde yaptık ve Search Console’da HTTPS mülkünü aynı gün ekledik. İlk hafta ufak dalgalanmalar olsa da 2–3 hafta içinde organik trafik eski seviyesini yakaladı; buna karşılık tarayıcı “Güvenli değil” uyarıları ortadan kalktığı için sepet tamamlama oranında gözle görülür bir artış oldu.

2. Kurumsal B2B sitede HSTS ve preload stratejisi

Bir başka müşteri senaryosunda, global B2B bir şirkete ait kurumsal sitede HTTPS yıllardır aktifti ancak HSTS kullanılmıyordu. Önce tüm subdomain’leri tarayıp HTTPS uyumluluğunu kontrol ettik, sadece eski bir staging subdomain’inde HTTP bağımlılığı olduğunu gördük. Bu alt alanı kapattıktan sonra önce 1 günlük max-age ile HSTS’i devreye aldık.

Herhangi bir sorun gözlemlemeyince süreyi 1 yıla çıkardık, ardından preload başvurusu yaptık. Sonuçta hem güvenlik puanları (SSLLabs gibi testlerde) yükseldi, hem de kurumsal güven algısı açısından IT ekibi iç denetimlerde daha rahat ilerleyebildi.

Sonuç ve DCHost ile Güvenli HTTPS Mimarisi

HTTP’den HTTPS’ye geçiş, doğru planlandığında hem güvenlik hem SEO tarafında kazançlı çıkacağınız bir yatırımdır. Yanlış kurgulandığında ise canonical karmaşası, hatalı 301 zincirleri, mixed content ve agresif HSTS kullanımı yüzünden hem sıralama hem dönüşüm kaybı yaşamanız mümkün. Bu rehberde DCHost ekibi olarak sahada en sık gördüğümüz hataları ve bunlara karşı pratik çözümleri özetledik.

Özetle; önce mimariyi ve canonical domaininizi netleştirin, sonra SSL kurulumunu temizce yapın, ardından 301 yönlendirme ve canonical etiketlerini tutarlı hale getirin. HSTS ve preload hamlelerini ise ancak geçiş tamamen stabil olduktan sonra devreye alın. Sunucu loglarını, Search Console raporlarını ve kullanıcı geri bildirimlerini ilk haftalarda yakından izlemeyi unutmayın.

Eğer HTTPS geçişinizi paylaşımlı hosting, yönetilen VPS, dedicated sunucu veya colocation altyapınız üzerinde DCHost ile planlamak isterseniz; SSL tedarikinden otomasyonuna, HSTS ve HTTP güvenlik başlıklarının doğru ayarlanmasına kadar tüm adımları beraber tasarlayabiliriz. Altyapı tarafını bize bırakıp içerik ve işinize odaklanmak istiyorsanız, DCHost ekibiyle iletişime geçmeniz yeterli.