HTTP’den HTTPS’e Geçiş Rehberi: 301 Yönlendirme, HSTS ve SEO’yu Korumak

Neden HTTP’den HTTPS’e Geçmek Artık Zorunlu Hale Geldi?

Artık sadece e-ticaret siteleri değil, en basit blog projeleri bile HTTPS kullanmak zorunda. Tarayıcılar HTTP siteleri “güvenli değil” etiketiyle işaretliyor, arama motorları HTTPS’i doğrudan bir sıralama sinyali olarak kullanıyor ve kullanıcılar adres çubuğunda kilit ikonu görmeden kart bilgilerini bırakmak istemiyor. Yani konu sadece teknik bir tercih değil, doğrudan güven, dönüşüm ve SEO meselesi.

Biz DCHost tarafında projelerin mimari tasarım ve kapasite planlama toplantılarında artık ilk soruyu genelde şöyle soruyoruz: “Bu siteyi HTTPS-first olarak mı kurguluyoruz, yoksa sonradan yamalayacak mıyız?” Deneyim gösteriyor ki HTTPS’i en baştan doğru kurgulayanlar, ileride HSTS, HTTP/3, CDN, WAF ve performans iyileştirmelerinde çok daha rahat hareket ediyor. Bu rehberde, HTTP’den HTTPS’e geçerken:

• Doğru SSL sertifikasını nasıl seçeceğinizi,
• 301 yönlendirmeleri hatasız nasıl kuracağınızı,
• HSTS’i ne zaman ve nasıl devreye alacağınızı,
• Ve en kritik nokta olarak SEO kaybı yaşamadan geçişi nasıl tamamlayacağınızı

adım adım ve pratik bir kontrol listesi eşliğinde anlatacağız. Anlattıklarımız hem paylaşımlı hosting ortamlarında hem de DCHost üzerindeki VPS ve dedicated sunucularda birebir uygulanabilir.

HTTPS’e Geçmeden Önce Yapılması Gereken Planlama

Alan adı ve alt alan adlarını envanter çıkarma

Sağlam bir HTTPS geçişi, önce neleri etkilediğinizi bilmekle başlar. Şu sorulara net cevabınız olmalı:

• Hangi alan adları var? (example.com, example.net vb.)
• Hangi alt alanlar yayında? (www, api, shop, blog, panel vb.)
• Aynı içerik birden fazla alan adında mı yayınlanıyor? (alias domainler)
• Mobil alt alan, ülke bazlı alt alan (tr.example.com, en.example.com) var mı?

Bu envanter size şu iki konuda yol gösterecek:

1. Hangi tür SSL sertifikasına ihtiyacınız olduğu,
2. 301 yönlendirmeleri nasıl tasarlamanız gerektiği.

Hangi SSL sertifika türünü seçeceğinize karar verme

Tek alan adınız ve sadece www + kök etki alanı kullanımınız varsa standart DV (Domain Validation) sertifika çoğu zaman yeterli. Çok sayıda alt alan kullanıyorsanız wildcard SSL, kurumsal kimliğinizi vurgulamak istiyorsanız OV/EV sertifikalar gündeme gelir.

Bu karar sürecini detaylı anlattığımız “Ücretsiz Let’s Encrypt mi, Kurumsal SSL Sertifikası mı?” rehberine mutlaka göz atmanızı öneririz. Orada e-ticaret, kurumsal site ve SaaS senaryolarını ayrı ayrı değerlendiriyoruz.

Altyapı: paylaşımlı hosting mi, VPS/dedicated mi?

HTTPS geçişinin teknik zorluğu büyük oranda altyapınıza bağlı:

• Paylaşımlı hosting: Genellikle cPanel/Plesk gibi paneller üzerinden 1-2 tıkla SSL kurulabiliyor, çoğu zaman Let’s Encrypt otomatik sunuluyor. 301 yönlendirme ve HSTS ayarlarını .htaccess veya panel üzerinden yapıyorsunuz.
• VPS veya dedicated sunucu: Nginx/Apache/Caddy gibi web sunucularını kendiniz yönetiyorsanız daha fazla esneklik ama aynı zamanda daha fazla sorumluluk var. Sertifika yenileme otomasyonundan HSTS ve HTTP/3 ayarlarına kadar her şeyi siz (veya bizim yönetilen hizmetlerimiz) kurguluyor.

Eğer proje büyüyor, trafik artıyor ve güvenlik/güncelleme yükü sizi zorluyorsa, DCHost üzerinde yönetilen VPS veya dedicated çözümleri tercih edip SSL, yönlendirme ve güvenlik başlıklarını ekibimize bırakabilirsiniz.

SSL Sertifikası Kurulumu: cPanel, Plesk, Nginx ve Apache Kısa Özet

cPanel veya Plesk üzerinde SSL kurulumunun mantığı

Paylaşımlı hosting veya yönetim paneli olan sunucularda süreç benzer ilerler:

1. Alan adını hesabınıza ekleyin (addon domain / subscription).
2. Paneldeki SSL/TLS veya SSL Sertifikaları bölümüne girin.
3. Let’s Encrypt veya benzeri ücretsiz sağlayıcıyı seçin, alan adını işaretleyip sertifika kurulumunu başlatın.
4. DNS kayıtlarınız doğruysa (özellikle A/AAAA), birkaç saniye içinde sertifika kurulur.

Modern panellerde genellikle otomatik yenileme varsayılan olarak aktif gelir. Yine de sertifika süresini ve yenileme loglarını takip etmenizi öneririz. Sertifika hataları ve tarayıcı uyarılarını nasıl okuyacağınızı detaylı olarak “SSL Sertifika Hataları Rehberi” yazımızda anlattık.

Nginx üzerinde temel HTTPS yapılandırması

VPS veya dedicated üzerinde Nginx kullanıyorsanız, tipik bir HTTPS sunucu bloğu şöyle görünür:

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

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Güvenli protokol ve şifreler için TLS 1.3 rehberimize bakın
    # ...

    root /var/www/html;
    index index.php index.html;

    # Uygulama konfigürasyonları
}

Burada dikkat edilmesi gereken noktalar:

• listen 443 ssl http2; satırıyla HTTPS ve HTTP/2 etkinleştirilir.
• Sertifika yollarınız Let’s Encrypt veya kullandığınız CA’ya göre değişir.
• HTTP’den HTTPS’e yönlendirmeyi ayrı bir server bloğu ile yapacağız (bir sonraki bölümde).

Nginx’te TLS 1.3, OCSP Stapling ve Brotli sıkıştırmayı adım adım kurmak için “Nginx’te TLS 1.3, OCSP Stapling ve Brotli” rehberimize mutlaka bakın; HTTPS performansını doğrudan etkileyen ayarlar orada.

Apache üzerinde temel HTTPS yapılandırması

Apache tarafında ise genellikle şu yapıya benzer bir VirtualHost kullanılır:

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

    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    # Diğer ayarlar (Rewrite, PHP-FPM, vb.)
</VirtualHost>

Apache’de HTTP’den HTTPS’e yönlendirme için genellikle mod_rewrite veya VirtualHost *:80 içinde Redirect 301 kullanılır; bunu da 301 yönlendirme bölümünde detaylandıracağız.

ACME otomasyonu ve wildcard sertifikalar

Birden fazla alt alanı olan, staging/canlı ortamları ayrı subdomain’lerde tutan SaaS projeleri için wildcard SSL ve otomatik yenileme kritik hale gelir. DNS tabanlı doğrulama ve wildcard otomasyonu için “Let’s Encrypt Wildcard SSL Otomasyonu” rehberinde DNS-01 challenge ve panel entegrasyonlarını adım adım anlattık.

HTTP’den HTTPS’e 301 Yönlendirme Nasıl Kurulur?

Neden mutlaka 301 kullanmalısınız?

HTTP’den HTTPS’e geçiş, arama motorları açısından kalıcı bir adres değişikliğidir. Bu nedenle 301 (Moved Permanently) kullanmak zorundasınız. 302 gibi geçici yönlendirmeler, hem SEO sinyallerinin tam taşınmamasına hem de arama motorlarının yeni adresleri kalıcı görmemesine neden olabilir.

301, 302, 404, 410 ve 5xx kodlarının SEO ve hosting tarafındaki etkilerini detaylıca incelediğimiz “HTTP Durum Kodları Rehberi” yazımıza göz atarsanız yönlendirme stratejinizi çok daha sağlam kurabilirsiniz.

Apache / .htaccess ile tüm trafiği HTTPS’e yönlendirmek

Paylaşımlı hosting veya .htaccess kullanan Apache kurulumlarında temel senaryo şudur: Gelen tüm HTTP isteklerini aynı URL’nin HTTPS versiyonuna kalıcı (301) olarak yönlendirirsiniz.

.htaccess içine eklenecek tipik bir kural:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Birkaç önemli not:

• Bu kuralı mümkünse dosyanın başına, diğer rewrite kurallarından önce ekleyin.
• Eğer alt dizin kurulumunuz varsa (/blog gibi), DocumentRoot ve RewriteBase ayarlarını ayrıca kontrol edin.
• Birden çok kez HTTPS’e yönlendirme yapmamak için (redirect chain), var olan kurallarınızla çakışmadığından emin olun.

Nginx ile HTTP → HTTPS yönlendirme

Nginx’te HTTP ve HTTPS için genellikle iki ayrı server bloğu kullanırız. HTTP bloğu sadece yönlendirme yapar:

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

    return 301 https://$host$request_uri;
}

Bu yapı:

• Tüm http://example.com/* ve http://www.example.com/* isteklerini,
• Aynı path ve query string ile https:// versiyonuna yönlendirir.

HTTP ve HTTPS için server_name değerlerinin birebir uyumlu olması, ileride HSTS ve preload aşamasında karışıklık yaşamamanız açısından önemlidir.

Panel (cPanel/Plesk) üzerinden yönlendirme

Birçok panel, “Domain yönlendirme” veya “Force HTTPS” tarzı bir seçenek sunuyor. Bu tür butonlar genellikle arka planda .htaccess veya sanal host yapılandırmasını bizim biraz önce yazdığımız kurallarla güncelliyor. Yine de şu konuları manuel kontrol etmenizde fayda var:

• Yönlendirme gerçekten 301 mi? (302 değil)
• Yönlendirme hedefi tam olarak https://alanadiniz.com/ mu?
• Redirect chain oluşuyor mu? (HTTP → www → HTTPS gibi gereksiz çift atlamalar)

Tarayıcı geliştirici araçlarındaki Network sekmesi veya komut satırında curl -I http://example.com ile gelen yanıt başlıklarını inceleyerek 301’in doğru çalıştığını doğrulayabilirsiniz.

HSTS, Preload ve Diğer Güvenlik Başlıkları

HSTS nedir, neden önemlidir?

HSTS (HTTP Strict Transport Security), tarayıcıya “Bu alan adına bir daha asla HTTP üzerinden gelme, her zaman HTTPS kullan” diyen bir güvenlik başlığıdır. Böylece:

• Kullanıcı http:// yazsa bile tarayıcı otomatik olarak HTTPS’e çevirir.
• SSL strip gibi bazı saldırı vektörlerinin önüne geçilir.
• Güvenlik denetimlerinde (örn. PCI DSS) artı puan sağlar.

Temel HSTS başlığı örneği:

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

Bunu Nginx için add_header, Apache için Header always set ile gönderebilirsiniz.

HSTS preload listesi ve dikkat edilmesi gerekenler

HSTS’i bir adım ileri götürmek için Chrome’un HSTS preload listesine alan adınızı ekleyebilirsiniz. Bu liste, tarayıcılara gömülü gelir; kullanıcı sitenize ilk kez girerken bile tarayıcı HTTP’ye hiç dokunmadan doğrudan HTTPS’e gider.

Ancak burada büyük bir sorumluluk var:

• Bir kez preload listesine girdikten sonra HTTP’ye geri dönmek çok zordur.
• Tüm alt alanlarınız (includeSubDomains) HTTPS desteklemiyorsa ciddi erişim sorunları yaşanabilir.

Bu nedenle:

1. Tüm alan ve alt alanlarınızda HTTPS’in sorunsuz çalıştığından emin olun.
2. Önce preload’suz HSTS’i (sadece header) birkaç hafta/ay kullanın.
3. Logları, hataları ve kullanıcı şikayetlerini izleyin.
4. Her şey yolundaysa preload başlığını ekleyip listeye başvurun.

HSTS ile birlikte CSP, X-Frame-Options gibi diğer başlıkları da doğru kurmak için “HTTP Güvenlik Başlıkları Rehberi” yazımıza mutlaka göz atın.

SEO Kaybı Yaşamadan HTTPS’e Geçiş Kontrol Listesi

1. Tüm HTTP URL’leri 301 ile HTTPS’e yönleniyor mu?

İlk ve en kritik adım: Hiçbir HTTP URL’si 200 dönmemeli. Sitenizin:

• Kök adresini (http://example.com),
• Örnek bir kategori ve içerik sayfasını,
• Özel sayfalarınızı (giriş, sepet, ödeme vb.),

tek tek test edin. curl -I veya online HTTP header kontrol araçlarıyla dönen kodun 301 olduğundan ve hedefin HTTPS olduğundan emin olun.

2. Canonical etiketlerinizi güncellediniz mi?

Birçok sitede HTTPS’e geçildikten sonra aylarca <link rel="canonical" href="http://..." /> kaldığını görüyoruz. Bu, arama motorlarına “asıl sayfa HTTP versiyonu” mesajı verir. Geçişten hemen sonra:

• Tüm sayfaların canonical etiketlerini HTTPS olacak şekilde güncelleyin.
• CMS kullanıyorsanız (WordPress, Magento vb.) site adresi ayarını HTTPS’e çekin.

WordPress özelinde staging/canlı geçişi ve SSL sonrası adres düzenlemelerini nasıl yaptığımızı WordPress staging ortamı rehberimizde ayrı bir senaryo olarak anlattık.

3. XML sitemap ve robots.txt güncellemesi

Arama motorlarına gönderdiğiniz XML sitemap dosyaları da artık HTTPS URL’leri içermeli:

• CMS içinde veya SEO eklentinizde (Yoast, RankMath vb.) site adresini HTTPS yapın.
• XML sitemap’ı yeniden oluşturun ve https:// ile başladığından emin olun.
• robots.txt içindeki Sitemap: satırının da HTTPS’e güncellendiğini kontrol edin.

Bu adım, arama motorlarının HTTPS URL’lerinizi daha hızlı taramasına ve dizine eklemesine yardımcı olur.

4. İç linkler ve mixed content sorunları

Sayfalarınızda, menülerinizde ve içeriklerinizde hala http:// ile başlayan dahili linkler kalmış olabilir. Bunlar iki soruna yol açar:

• Kullanıcı gereksiz yönlendirmeye maruz kalır (performans kaybı).
• Görsel, CSS, JS gibi varlıklar HTTP’den çağrılıyorsa mixed content uyarıları alırsınız.

Mixed content, SSL kilidinin kırılmasının en yaygın sebebidir. Bu konuyu, tarayıcı uyarılarını ve çözüm yollarını detaylıca mixed content ve SSL hataları rehberimizde adım adım anlattık.

Pratik yaklaşım:

• Veritabanı içinde toplu http://example.com → https://example.com değiştirme (özellikle WordPress).
• Temadaki sabit URL’leri gözden geçirme.
• JS/CSS dosyalarında harici kaynak URL’lerini kontrol etme.

5. Google Search Console ve Analytics ayarları

HTTPS geçişi sonrası mutlaka:

• Google Search Console’da HTTPS mülkünü ekleyin.
• Eski HTTP mülkünü silmeyin; hatalar ve eski backlink’ler için hala işinize yarar.
• Analytics tarafında (UA/GA4) referans URL’leri ve filtreleri kontrol edin.

Search Console’da yeni sitemap’ı gönderip tarama hatalarını izleyin. İlk birkaç hafta 404 ve yönlendirme hatalarında dalgalanmalar normaldir; önemli olan bunları kısa sürede temizlemeniz.

6. Backlink ve harici link gözden geçirmesi

Tüm süreci kendi sitenizde doğru yapsanız bile, önemli birkaç backlink hala HTTP’ye işaret ediyorsa:

• Bu linkler elbette 301 ile HTTPS’e gidecek,
• Ancak mümkünse önemli sitelerden düzeltme rica etmek uzun vadede daha temiz bir profil sağlar.

Özellikle ana menülerde, footer’da yer alan sabit linklerinizi verdiğiniz iş ortakları veya dizin siteleri varsa, onlara HTTPS’e geçtiğinizi bildirmek iyi bir pratiktir.

7. Performans: HTTP/2, HTTP/3 ve TLS ayarları

HTTPS’e geçiş, doğru yapıldığında performansı düşürmek zorunda değildir; hatta çoğu zaman HTTP/2 ve HTTP/3 sayesinde sayfa yüklenme sürelerini iyileştirebilirsiniz. Modern tarayıcılar bu protokolleri yalnızca HTTPS üzerinden kullanır.

HTTP/3’ün hosting performansına etkilerini detaylı şekilde anlattığımız “HTTP/3 Protokolü” rehberine göz atarak, TLS ayarlarınızı sadece güvenli değil aynı zamanda hızlı olacak şekilde kurgulayabilirsiniz.

Gerçek Dünya Senaryoları: Blog, E-ticaret ve SaaS Geçişleri

Küçük WordPress blog: Tek domain, tek sertifika

Senaryo: example.com üzerinde tek WordPress blog, www kullanılmıyor. DCHost üzerindeki paylaşımlı hosting hesabında cPanel mevcut.

İzleyeceğiniz yol:

1. cPanel’den Let’s Encrypt DV sertifikası kurun.
2. .htaccess’e HTTP → HTTPS 301 kuralını ekleyin veya paneldeki “Force HTTPS” seçeneğini aktif edin.
3. WordPress genel ayarlarda Site Adresi ve WordPress Adresi’ni https://example.com yapın.
4. Veritabanı içinde eski http://example.com linklerini HTTPS’e çevirin.
5. Hafif bir HSTS başlığı ekleyin (preload’suz).
6. Search Console ve sitemap’ları güncelleyin.

Bu ölçek için geçiş genellikle dakikalar içinde tamamlanır ve doğru yapıldığında organik trafikte dalgalanma minimum olur.

E-ticaret sitesi: Çok alt alan, sepet/ödeme sayfalarında ekstra dikkat

Senaryo: www.example.com üzerinde mağaza, shop.example.com üzerinde ödeme altyapısı, cdn.example.com statik içerik sunuyor. Trafik yüksek, SEO kritik.

İzlemeniz gereken ek adımlar:

• Tüm alt alanları kapsayacak doğru SSL tasarımı (gerekirse wildcard + tekil sertifikalar kombinasyonu).
• Hem example.com hem www.example.com için net bir kanonik yapı (genellikle biri 301 ile diğerine yönlenir).
• Ödeme sayfalarında mixed content olmaması için ekstra sıkı test.
• HSTS’i önce max-age kısa tutarak (örneğin birkaç gün) pilot olarak devreye almak.

Bu ölçekte, çoğu zaman staging ortamında (örneğin staging.example.com) tam geçişi test edip, sorunları orada çözdükten sonra canlıya almak en sağlıklısıdır.

SaaS uygulaması: Subdomain-temelli çok kiracılı yapı

Senaryo: Her müşteri için musteri1.example.com, musteri2.example.com gibi alt alan adları, bazı büyük müşterilerde özel alan adları (app.musteri.com) kullanılıyor.

Bu senaryoda dikkat edilmesi gerekenler:

• ACME otomasyonu ve wildcard sertifikalarla tüm alt alanların HTTPS’ini yönetmek.
• Müşterilerin özel alan adları için DNS-01 challenge ve otomatik SSL kurulumu.
• HSTS’i includeSubDomains ile kullanacaksanız, tüm müşteri alt alanlarının HTTPS hazır olduğundan emin olmak.

Bu tür çok kiracılı mimarilerde, ACME challenge türlerini anlattığımız rehber ve wildcard otomasyon yazıları özellikle işinize yarayacaktır.

DCHost Altyapısında HTTPS Geçişini Kolaylaştıran Noktalar

DCHost olarak hem paylaşımlı hosting hem de VPS/dedicated tarafında, HTTP’den HTTPS’e geçişi mümkün olduğunca otomatik ve hatasız hale getirmek için altyapımızı sürekli güncelliyoruz.

• Birçok pakette otomatik Let’s Encrypt kurulumu ve yenilemesi.
• cPanel/Plesk ortamlarında tek tıkla HTTPS zorunlu kılma (301).
• VPS/dedicated müşterilerimiz için yönetilen hizmetlerde Nginx/Apache üzerinde TLS 1.3, HTTP/2/HTTP/3 ve HSTS yapılandırması.
• Colocation tarafında kendi donanımını barındıran müşterilere SSL/TLS ve güvenlik başlıkları danışmanlığı.

Özellikle yüksek trafikli WordPress, WooCommerce, Laravel veya Node.js projelerinizde; SSL sadece “sertifika takma”dan ibaret değil, performans ve ölçeklenebilirlik işin içine girdiğinde daha geniş bir mimari konusu haline geliyor. Bu noktada DCHost’un VPS, dedicated ve colocation çözümlerini, proje gereksinimlerinize göre birlikte planlayabiliriz.

Özet, Yol Haritası ve Son Adım

HTTP’den HTTPS’e geçiş, doğru planlama ile yaptığınızda bir “risk” değil, tam tersine güvenlik, güven ve SEO açısından ciddi bir fırsattır. Özetle:

• Alan adı ve alt alan envanterinizi çıkarın, doğru SSL tipini seçin.
• Önce sertifikayı kurun, sonra HTTP → HTTPS 301 yönlendirmesini eksiksiz uygulayın.
• Canonical, sitemap, robots.txt, iç linkler ve mixed content’i temizleyin.
• Search Console, Analytics ve backlink’lerinizi HTTPS’e güncelleyin.
• Her şey stabil olduktan sonra HSTS (ve gerekiyorsa preload) ile güvenliği bir seviye daha yukarı taşıyın.

Bu rehberi bir kontrol listesi gibi kullanarak, hem küçük bir blogu hem de yoğun trafikli bir e-ticaret veya SaaS uygulamasını güvenle HTTPS’e taşıyabilirsiniz. Daha ileri seviyede, TLS 1.3, HTTP/3, OCSP Stapling, güvenlik başlıkları ve WAF gibi konulara girmek isterseniz, DCHost blogunda onlarca detaylı makale ve pratik rehber sizi bekliyor.

Eğer kendi kendinize uğraşmak istemiyorsanız veya kritik bir projeyi sıfır hata toleransıyla HTTPS’e geçirmek istiyorsanız, DCHost üzerinde doğru hosting (paylaşımlı, VPS, dedicated veya colocation) seçimini yapıp, geçiş planını birlikte tasarlayabiliriz. Böylece siz işinize odaklanırken, SSL, 301, HSTS ve performans tarafını biz güvenle arka planda yürütürüz.