WordPress SSL ve HTTPS Kurulumu: Sertifika, Yönlendirme ve Karışık İçerik Rehberi

Admin · Dün 04:10 da

WordPress SSL ve HTTPS Kurulumu: Sertifika, Yönlendirme ve Karışık İçerik Rehberi

WordPress sitesini HTTPS’e geçirmek, yalnızca adresin başına https:// yazmaktan ibaret değildir. Sunucuda geçerli bir sertifika bulunmalı, WordPress doğru adresleri kullanmalı ve eski HTTP bağlantıları HTTPS sürümlerine yönlendirilmelidir.
Bunlardan biri eksik kaldığında site açılabilir ama görseller yüklenmeyebilir, yönetim panelinde yönlendirme döngüsü oluşabilir veya tarayıcı sertifika uyarısı gösterebilir.
Kurulumu doğru sırayla yapmak, bu sorunların büyük bölümünü önler. Aşağıdaki adımlar, mevcut WordPress sitesini HTTPS’e geçirirken izlenebilecek yolu anlatır.

SSL, TLS ve HTTPS Arasındaki Fark Nedir?

Hosting panellerinde hâlâ “SSL sertifikası” ifadesi kullanılsa da günümüzde güvenli bağlantı için TLS protokolü kullanılır. HTTPS, HTTP iletişiminin TLS üzerinden korunmasıdır.
Doğru yapılandırılmış bir HTTPS bağlantısı:

Tarayıcı ile bağlantının sonlandığı sunucu arasındaki veriyi şifreler.
Aktarım sırasında verinin değiştirilmesine karşı koruma sağlar.
Sertifikanın ziyaret edilen alan adıyla eşleşmesini doğrular.

Ancak HTTPS, sitenin içeriğinin doğru olduğunu veya işletmenin güvenilir olduğunu tek başına kanıtlamaz. Zararlı bir site de geçerli sertifika kullanabilir.
WordPress’te HTTPS hem ziyaretçiler hem yönetici için önemlidir. Giriş bilgileri, oturum çerezleri ve form verileri korunması gereken bilgiler arasındadır.

Kuruluma Başlamadan Önce Hazırlık Yapın

Önce dosyaların ve veritabanının güncel yedeğini alın. Ayrıca şu bilgileri kaydedin:

WordPress Adresi ve Site Adresi.
Tercih ettiğiniz alan adı: www içeren veya içermeyen sürüm.
Mevcut yönlendirme kuralları.
Kullanılan CDN veya ters proxy.
Sertifikanın kapsaması gereken alan adları.

HTTPS geçişi sırasında mümkünse alan adı, kalıcı bağlantı yapısı ve tema gibi başka büyük değişiklikleri aynı anda yapmayın. Böylece oluşabilecek bir sorunun nedenini daha kolay belirleyebilirsiniz.

1. Hosting Panelinden Sertifikayı Etkinleştirin

Sertifika, HTTPS bağlantısını karşılayan web sunucusunda veya ilgili proxy katmanında yapılandırılır. WordPress adres ayarı, bu işlemin yerine geçmez.
Hosting panelinizde şu bölümlerden biri bulunabilir:

Panel	Kontrol edilebilecek bölüm
cPanel	SSL/TLS Status ve sağlayıcı etkinleştirmişse AutoSSL
Plesk	SSL/TLS Certificates veya SSL It!
DirectAdmin	SSL Certificates
Yönetilen WordPress hizmeti	Domain veya güvenlik ayarları

Menü adı ve otomatik sertifika desteği sağlayıcıya göre değişebilir.
cPanel’in SSL/TLS Status ekranında domainlerin sertifika durumunu inceleyebilirsiniz. AutoSSL seçeneklerinin kullanılabilirliği sunucu yöneticisinin yapılandırmasına bağlıdır.

Ücretsiz sertifika kullanılabilir mi?

Let’s Encrypt ücretsiz DV sertifikaları sağlar. Hosting sağlayıcınız destekliyorsa kurulum ve yenileme panel üzerinden otomatik yürütülebilir. Ancak otomasyonun gerçekten etkin olduğunu kontrol etmek gerekir.
Sertifika üretilemiyorsa olası nedenler arasında yanlış DNS kayıtları, doğrulama isteğinin engellenmesi ve sertifika otoritesini sınırlandıran CAA kayıtları bulunur. Doğrulama yöntemi HTTP veya DNS üzerinden olabilir; her kurulumun gereksinimi aynı değildir.

Hangi adresler sertifikaya dahil edilmeli?

Şu iki adresi kullanıyorsanız ikisini de kontrol edin:

Kod:

ornek.com
www.ornek.com

Bir adresten diğerine yönlendirme yapılması, kaynak HTTPS adresinin sertifika ihtiyacını ortadan kaldırmaz. Tarayıcı, yönlendirme yanıtını almadan önce TLS bağlantısını kurar.
DV, OV ve EV sertifikaları doğrulama seviyesini ifade eder. Wildcard ve SAN ise kapsanan isimlerle ilgilidir; aynı sınıflandırma değildir.
Örneğin *.ornek.com, uygun alt alan adlarını kapsayabilir ama tek başına ornek.com veya daha derindeki a.b.ornek.com için geçerli sayılmaz. Sertifikanın isim listesini kontrol edin.

2. WordPress Ayarlarını Değiştirmeden HTTPS’i Test Edin

Tarayıcıda sitenizin HTTPS adresini açın:
https://ornek.com/
Şunları kontrol edin:

Sertifika alan adıyla eşleşiyor mu?
Süresi geçerli mi?
Tarayıcı güven uyarısı gösteriyor mu?
Doğru site ve içerik açılıyor mu?

Bazı tarayıcılar artık klasik kilit simgesini kullanmaz. Bu yüzden yalnızca simgeye bakmak yerine bağlantı ve sertifika ayrıntılarını inceleyin.
Geçerli HTTPS erişimini doğrulamadan WordPress adreslerini değiştirmek, yönetim paneline erişimi zorlaştırabilir.

3. WordPress Adreslerini HTTPS Olarak Güncelleyin

Yönetim panelinde Ayarlar → Genel bölümünü açın.
Burada iki alan bulunur:

Alan	Anlamı
WordPress Adresi	WordPress dosyalarının bulunduğu adres
Site Adresi	Ziyaretçilerin siteye ulaşmak için kullandığı adres

Bu adresler her kurulumda aynı olmayabilir. WordPress dosyaları alt dizindeyken site alan adının kökünden yayınlanabilir.
Mevcut alan adlarını ve dizin yollarını koruyarak protokolü değiştirin:
http://ornek.com → https://ornek.com
Örneğin WordPress Adresi /wordpress ile bitiyorsa, yalnızca HTTPS’e geçmek için bu yolu kaldırmayın.
Kaydettiğinizde yeniden giriş yapmanız istenebilir. Alanlar düzenlenemiyorsa wp-config.php içinde WP_HOME veya WP_SITEURL tanımlanmış olabilir.
Yönetici oturumlarını HTTPS üzerinden zorlamak için, uygun sunucu yapılandırması tamamlandıktan sonra şu sabit de kullanılabilir:
define( 'FORCE_SSL_ADMIN', true );
Bu ayar wp-config.php içinde, WordPress yüklenmeden önce tanımlanmalıdır. Bütün sitenin HTTPS yönlendirmesinin yerine geçmez.

4. HTTP İsteklerini HTTPS’e Yönlendirin

Eski bağlantılar ve yer imleri HTTP adreslerini çağırmaya devam edebilir. Bu istekleri, aynı içeriğin HTTPS adresine yönlendirin.
Örneğin:
http://ornek.com/iletisim/
şu adrese gitmelidir:
https://ornek.com/iletisim/
Bütün iç sayfaları ana sayfaya göndermeyin.
Hosting panelinizde HTTPS yönlendirme seçeneği varsa önce onu değerlendirin. Panel, eklenti ve CDN üzerinde aynı yönlendirmeyi tekrar tekrar tanımlamak sorun takibini zorlaştırabilir.

Apache için örnek .htaccess kuralı

HTTPS’in doğrudan ilgili web sunucusunda sonlandığı bir ortamda şu örnek kullanılabilir:

Kod:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://ornek.com%{REQUEST_URI} [R=302,L]
</IfModule>

ornek.com yerine kendi alan adınızı yazın. Bloğu # BEGIN WordPress bölümünün üstüne, WordPress’in yönettiği alanın dışına yerleştirin.
Test sırasında 302 kullanabilirsiniz. Hedefler doğru çalışıyorsa kalıcı yönlendirme için R=301 olarak değiştirin.
Nginx .htaccess dosyasını okumaz. Böyle bir ortamda yönlendirme panel veya Nginx yapılandırması üzerinden yapılmalıdır.

Cloudflare Kullanıyorsanız Bağlantının İki Tarafını Kontrol Edin

Cloudflare arkasındaki bir sitede iki bağlantı vardır: ziyaretçi ile Cloudflare arasındaki bağlantı ve Cloudflare ile asıl sunucu arasındaki bağlantı.
Flexible modunda ziyaretçi HTTPS kullanırken asıl sunucuya HTTP üzerinden ulaşılabilir. Sunucunun her HTTP isteğini HTTPS’e göndermesi bu yapıda yönlendirme döngüsü oluşturabilir.
Asıl sunucuda uygun sertifika bulunuyorsa Full (strict), sunucu bağlantısını şifreleyip sertifikayı doğrular. Önce bu gereksinimleri sağlayın, ardından modu değiştirin.
WordPress’in gerçek bağlantı protokolünü doğru algılaması da gerekir. Proxy başlıklarına göre yapılan ayarlar, güvenilir proxy yapılandırmasına dayanmalıdır.
Sorunu çözmek için koşulsuz olarak $_SERVER['HTTPS'] = 'on'; eklemek doğru bir genel çözüm değildir.

5. Karışık İçerik Hatalarını Temizleyin

HTTPS sayfasının görsel, CSS, JavaScript veya başka bir kaynağı HTTP üzerinden istemesi mixed content, yani karışık içerik oluşturabilir.
Tarayıcılar bazı kaynakları HTTPS’e yükseltirken bazılarını engeller. Bu nedenle sorun her zaman görünür bir uyarı şeklinde ortaya çıkmaz; bozuk tasarım veya çalışmayan özellik olarak da görülebilir.
Tarayıcının geliştirici araçlarını açın. Console ve Network bölümlerinde HTTP üzerinden çağrılan kaynakları inceleyin.
Sık karşılaşılan kaynaklar:

Yazılardaki eski görsel adresleri.
Tema ayarlarına kaydedilmiş logo bağlantıları.
Sayfa oluşturucuların içerikleri.
CSS dosyalarındaki sabit adresler.
Harici servis bağlantıları.

Normal bir dış bağlantının HTTP olmasıyla, sayfanın HTTP kaynağı yüklemesi aynı durum değildir. Sorunu tespit etmeden bütün bağlantıları topluca değiştirmeyin.

Veritabanındaki adresleri değiştirme

WordPress bazı ayarları serileştirilmiş veri olarak saklar. Düz SQL değiştirme işlemleri bu yapıyı bozabilir. Serileştirilmiş veriyi destekleyen bir araç kullanın.
Better Search Replace gibi bir eklentiyle işlem yapıyorsanız:

Veritabanı yedeğini alın.
Eski ve yeni adresi tam olarak yazın.
İlgili siteye ait tabloları seçin.
Önce kuru çalıştırma yapın.
Sonuçları inceleyip gerçek işlemi başlatın.

Aynı veritabanında başka uygulamalar varsa bütün tabloları gelişigüzel seçmeyin. WordPress’in guid alanlarını da HTTPS geçişi için değiştirmeyin.

WP-CLI ile örnek işlem

Doğru WordPress dizininde önce önizleme çalıştırın:
wp search-replace 'http://ornek.com' 'https://ornek.com' --skip-columns=guid --dry-run
Sonuç uygun görünüyorsa:
wp search-replace 'http://ornek.com' 'https://ornek.com' --skip-columns=guid
WP-CLI serileştirilmiş veriyi işleyebilir. Varsayılan olarak $wpdb üzerinde kayıtlı tabloları kullanır; eklentilerin özel tabloları veya Multisite için kapsam ayrıca belirlenmelidir.
İşlemden sonra sayfa oluşturucunun ürettiği dosyaları gerekiyorsa yenileyin ve önbellekleri temizleyin.
Harici bir servis HTTPS desteklemiyorsa yalnızca adresindeki protokolü değiştirmek yeterli olmaz. Uygun bir kaynakla değiştirmek veya kaldırmak gerekir.

HTTPS Eklentisi Kullanmak Şart mı?

Hayır. Sertifika, site adresleri, yönlendirmeler ve içerik bağlantıları doğru yapılandırıldığında HTTPS için sürekli çalışan bir eklenti zorunlu değildir.
Really Simple Security gibi araçlar geçişi kolaylaştırabilir. Ancak sundukları özellikler sürüme ve pakete göre değişebilir.
Ayrıca ekranda üretilen HTTP adreslerini dinamik olarak değiştirmek, veritabanındaki kayıtların kalıcı biçimde düzeltildiği anlamına gelmez. Eklentinin yaptığı işlemi anlamak gerekir.
Eklenti kullanmanız, geçerli sertifika ve doğru sunucu yapılandırmasını kontrol etme ihtiyacını ortadan kaldırmaz.

6. Kurulumu ve SEO Ayarlarını Doğrulayın

Geçiş tamamlandığında şu kontrolleri yapın:

HTTP adresleri doğru HTTPS karşılıklarına gidiyor mu?
Ana sayfa ve iç sayfalar açılıyor mu?
Yönetici girişi, formlar ve ödeme işlemleri çalışıyor mu?
Karışık içerik hatası kaldı mı?
Canonical adresler ve site haritası HTTPS kullanıyor mu?
Sertifika yenilemesi etkin mi?

Search Console’da HTTPS adreslerini kapsayan mülkü kontrol edin. Yalnızca HTTP’den HTTPS’e geçiş için Adres Değişikliği aracını kullanmanız gerekmez. Geçiş sırasında geçici sıralama dalgalanmaları görülebilir; HTTPS tek başına sıralama artışı garantisi değildir.
Sertifika testi, sunucu tarafındaki TLS yapılandırmasını incelemeye yardımcı olur. Ancak iyi bir test puanı, WordPress’in bütün işlevlerinin doğru çalıştığını kanıtlamaz.

HSTS Ne Zaman Etkinleştirilmeli?

HSTS, tarayıcıya belirli bir süre boyunca ilgili alan adına yalnızca HTTPS üzerinden bağlanmasını söyleyen bir yanıt başlığıdır.
Örnek:
Strict-Transport-Security: max-age=300
Bu, kısa süreli bir deneme politikasıdır. HSTS zorunlu bir kurulum adımı değildir; HTTPS erişimi ve sertifika yenilemesi kararlı çalıştıktan sonra değerlendirilmelidir.
Şunları bilmek önemlidir:

Başlık HTTPS yanıtında gönderilir.
Politika öğrenildikten sonraki bağlantıları etkiler.
Önceden politika bilinmiyorsa ilk HTTP isteğini tek başına korumaz.
includeSubDomains, alt alan adlarını da kapsar.
preload, ayrıca değerlendirilen bir tarayıcı listesi sürecidir.

Bu yüzden başlangıçta bütün alt alan adlarını kapsayan uzun bir politika eklemeyin. HTTPS desteklemeyen bir alt alan adı varsa erişim sorunu yaşayabilirsiniz.

Yaygın Hatalar ve Çözümleri

Sorun	Kontrol edilecek noktalar
Sertifika alan adıyla eşleşmiyor	Sertifikanın isim listesi ve doğru sanal sunucu
HTTPS açılıyor ama tasarım bozuk	Karışık içerik, eski CSS adresleri ve önbellek
Sonsuz yönlendirme oluşuyor	CDN modu, proxy protokol algısı ve çelişen kurallar
Yönetim paneline erişilemiyor	WordPress adresleri, sertifika ve yönetici yönlendirmeleri
Sertifika yenilenmemiş	Doğrulama erişimi, DNS, otomasyon ve hata kayıtları
Bazı alt alan adları açılmıyor	Sertifika kapsamı ve HSTS politikası

Sıkça Sorulan Sorular

WordPress için ücretli SSL almak gerekir mi?

Her site için gerekmez. Uygun bir ücretsiz DV sertifikası HTTPS bağlantısı sağlayabilir. Kurumsal doğrulama gereksinimleri ayrıca değerlendirilir.

SSL sertifikası süresi dolunca ne yapılmalı?

Yenileme sisteminin neden başarısız olduğunu inceleyin. Sertifikalar süresi dolmadan yenilenmelidir; otomatik kurulum, otomatik yenilemenin her koşulda başarılı olacağı anlamına gelmez.

HTTPS’e geçince eski bağlantılar çalışır mı?

Doğru yönlendirme kurulursa eski HTTP bağlantıları ilgili HTTPS sayfasına ulaşabilir. İç sayfaların yollarını ve parametrelerini test edin.

Hosting değiştirince sertifika yeniden alınmalı mı?

Yeni sunucuda HTTPS yapılandırması gerekir. Uygun durumlarda mevcut sertifika ve özel anahtar güvenli şekilde taşınabilir veya yeni sertifika üretilebilir. Sertifika, kapsadığı alan adlarıyla ilişkilidir; yalnızca tek bir fiziksel sunucuya bağlı değildir.

HTTPS bütün güvenlik sorunlarını çözer mi?

Bağlantıyı korur. Zararlı eklentiler, zayıf parolalar, uygulama açıkları ve yedekleme ihtiyacı ayrıca ele alınmalıdır.

WordPress SSL ve HTTPS Kurulumu: Sertifika, Yönlendirme ve Karışık İçerik Rehberi

Admin

Webmaster