WordPress SSL Kurulumu ve Mixed Content Hatası Çözümü

Özet

WordPress sitenizi HTTPS’e taşımak yalnızca tarayıcıda görünen küçük bir kilit simgesinden çok daha fazlasıdır: arama motoru sıralaması, çerez güvenliği, modern tarayıcı API’leri ve ödeme entegrasyonlarının tamamı geçerli bir SSL sertifikasına bağlıdır. Yine de pek çok site sahibi sertifikayı yükledikten sonra “siteniz tam olarak güvenli değil” uyarısıyla karşılaşır; sebebi neredeyse her zaman aynıdır: karışık içerik (mixed content) hatası. Bu rehberde SSL sertifikasını doğru kuran, HTTP’den HTTPS’e geçişi adım adım planlayan ve mixed content uyarılarını kalıcı olarak temizleyen yapılandırmaları, kod parçacıklarıyla birlikte ele alıyoruz.

SSL ve HTTPS Neden Bu Kadar Önemli?

HTTPS, tarayıcı ile sunucu arasındaki trafiği TLS üzerinden şifreleyen protokoldür. Geçerli bir SSL/TLS sertifikası olmadan iletilen her form gönderimi, parola, çerez ve API çağrısı; aynı ağdaki herhangi biri tarafından okunabilir veya değiştirilebilir. Modern tarayıcılar bu nedenle uzun zamandır HTTP üzerinden parola girilen sayfaları “güvenli değil” olarak işaretler, üçüncü taraf çerezleri kısıtlar ve Service Worker, geolocation, getUserMedia gibi güçlü API’leri yalnızca HTTPS bağlamında çalıştırır.

SEO tarafında Google, HTTPS’i 2014’ten bu yana hafif bir sıralama sinyali olarak kullanıyor; ancak doğrudan etkisinden çok dolaylı sonuçları belirleyici: HTTPS olmayan sitelerde tarayıcı uyarıları yüzünden ziyaretçiler hızla geri dönüyor, hemen çıkma oranı yükseliyor ve dönüşüm düşüyor. WooCommerce gibi e-ticaret kurulumlarında ise PCI-DSS zorunluluğu nedeniyle HTTPS pazarlık edilemez bir gerekliliktir.

Ayrıca HTTP/2, HTTP/3 ve QUIC gibi modern protokollerin neredeyse tüm uygulamalarda yalnızca TLS üzerinde çalıştığını unutmamak gerekir. Bu da HTTPS’in performans açısından da kazançlı olduğu anlamına gelir: tek TCP bağlantısı üzerinde paralel istek (multiplexing), başlık sıkıştırma ve sunucu push gibi optimizasyonlar yalnızca şifreli kanalda devreye girer.

Sertifika Türleri: Hangi SSL Sizin İçin Doğru?

SSL sertifikalarını doğrulama derinliğine ve kapsamına göre üç ana grupta inceleyebiliriz:

Domain Validated (DV)

En hızlı ve en uygun fiyatlı seçenek. Doğrulama tamamen otomatik bir e-posta veya DNS kaydı kontrolü ile yapılır. Let’s Encrypt, ZeroSSL ve cPanel/Plesk üzerindeki AutoSSL gibi ücretsiz çözümlerin tamamı DV kategorisindedir. Tarayıcıda kilit gösterir, kuruluş bilgisi göstermez. Bireysel bloglar, kurumsal tanıtım siteleri, küçük WooCommerce mağazalarının büyük kısmı için yeterlidir.

Organization Validated (OV)

Sertifika otoritesi (CA) şirket kayıt belgesini ve telefon doğrulamasını ister. Sertifikayı tarayıcı detayında görüntülediğinizde “Issued To” alanında firma adı yer alır. Kurumsal yatırım sitelerinde, B2B platformlarında ve bayi panelinde tercih edilir.

Extended Validation (EV)

En kapsamlı doğrulama biçimidir. Banka, finans, kredi kartı işleme platformları gibi yüksek güven gerektiren senaryolarda anlamlıdır. Modern tarayıcılarda artık adres çubuğunda yeşil şirket adı gösterilmiyor; bu nedenle yatırımın görsel etkisi azalmıştır, ancak güvenlik açısından sertifika zinciri yine en sağlam doğrulamayı sunar.

Kapsama göre bir başka kırılım da vardır: tek alan adı, wildcard (*.alanadi.com) ve multi-domain (SAN) sertifikalar. Birden fazla alt alan adı kullanıyorsanız wildcard sertifika yönetimi ciddi şekilde kolaylaştırır. Ayrı domainleriniz varsa SAN sertifikası tek bir CSR ile birden fazla alan adını kapsar.

Adım 1: Hosting Tarafında SSL Aktivasyonu

Türkiye’deki neredeyse tüm hosting paketleri artık ücretsiz Let’s Encrypt sertifikası sunuyor. cPanel ve Plesk panellerinde aktivasyon birkaç tıklamadan ibarettir; ancak doğrulama yapılırken DNS kayıtlarınızın doğru sunucuyu işaret ediyor olması zorunludur. Aksi halde HTTP-01 doğrulaması başarısız olur ve sertifika yenilenmez.

cPanel’de Let’s Encrypt Aktivasyonu

cPanel ana ekranında Security → SSL/TLS Status menüsüne girin. Liste hâlinde tüm alan adı ve alt alan adlarını göreceksiniz. Eksik olanlar için Run AutoSSL butonuna basın. AutoSSL, Comodo veya Sectigo kökenli ücretsiz sertifikayı her 90 günde bir otomatik yeniler.

Eğer hosting sağlayıcınız AutoSSL’i devre dışı bırakmışsa SSL/TLS → Manage SSL sites bölümünden manuel olarak sertifika, anahtar ve CA paketini (chain) yapıştırarak kurulum yapabilirsiniz. Anahtar (Private Key) ve sertifika (Certificate) eşleşmiyorsa cPanel hata verir; bu durumda CSR’yi yeniden üretip CA’ya tekrar imzalatmak gerekir.

Plesk’te SSL It! Eklentisi

Plesk Obsidian’da varsayılan olarak gelen SSL It! eklentisi Let’s Encrypt entegrasyonunu sunar. Domains → example.com → SSL/TLS Certificates yolundan Install diyerek tek tıkla yenilenen sertifika kurabilirsiniz. “Secure the wildcard domain” seçeneği için DNS doğrulaması (DNS-01) gerekir; Plesk DNS sunucusu kullanıyorsanız otomatik halleder, harici DNS kullanıyorsanız TXT kaydı eklemeniz istenir.

Reverse Proxy ve Cloudflare Senaryosu

Cloudflare gibi bir CDN/proxy önündeyseniz iki ayrı sertifikadan söz ediyoruz: Cloudflare Edge sertifikası ile origin (sunucunuz) sertifikası. SSL/TLS modunu mutlaka Full (strict) seçin. Flexible modunda Cloudflare ile origin arasındaki bağlantı şifrelenmez; bu da uygulamanın HTTP’de çalışmasına ve sonsuz yönlendirme döngülerine yol açar. Origin tarafında geçerli bir sertifika yoksa Cloudflare Origin CA üzerinden 15 yıllık ücretsiz sertifika üretip kurmanızı öneririm.

Adım 2: WordPress Adreslerini HTTPS’e Taşıma

Sertifika aktif olduktan sonra ilk dokunulması gereken yer WordPress yönetim panelidir. Ayarlar → Genel ekranında iki alan vardır: WordPress Adresi (URL) ve Site Adresi (URL). Her ikisini de https:// öneki ile kaydedin. Eğer panele erişiminiz kapanırsa veya yönlendirme döngüsüne girerseniz, panik yapmadan wp-config.php dosyanıza şu satırları ekleyebilirsiniz:

define( 'WP_HOME',    'https://www.example.com' );
define( 'WP_SITEURL', 'https://www.example.com' );

Bu sabitler veritabanındaki seçenekleri geçersiz kılar; böylece yönlendirme döngüsü kırılır. Ardından yönetim paneline girip ayarları kalıcı olarak güncelleyebilirsiniz.

Yönetim Paneli için Zorunlu HTTPS

WP-Admin ve WP-Login için HTTPS zorunluluğu, oturum çerezlerinin şifresiz iletildiği bir senaryoyu engeller:

define( 'FORCE_SSL_ADMIN', true );

Bu sabit aktif edildiğinde yönetim alanına HTTP üzerinden gelen istekler otomatik olarak HTTPS’e yönlendirilir. Reverse proxy arkasındaysanız, WordPress’in HTTPS’i doğru algılaması için aşağıdaki bloğu da wp-config.php‘nin başına eklemeyi unutmayın:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

Aksi halde WordPress isteğin HTTP geldiğini sanıp sonsuz döngüye girebilir.

Adım 3: HTTP’den HTTPS’e Kalıcı Yönlendirme

Geçişin SEO açısından sağlıklı olması için tüm HTTP istekleri 301 yanıtıyla HTTPS adresine yönlendirilmelidir. Apache (cPanel) ortamında .htaccess dosyanızın en üstüne aşağıdaki bloğu ekleyin:

# BEGIN HTTPS Redirect
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>
# END HTTPS Redirect

Nginx kullanan sunucularda (LiteSpeed, OpenLiteSpeed, RunCloud gibi panellerde) server bloğuna şunu eklemek yeterlidir:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Yönlendirme yalnızca www ya da yalnızca kök etki alanına yapılacaksa HTTP_HOST kontrolü ekleyerek kanonik adresi sabitleyin. Karma yapı (hem www hem kök) Google için kafa karıştırıcı olabilir; her zaman tek kanonik adresi tercih edin.

Adım 4: Mixed Content Hatasını Anlamak

SSL kurup yönlendirmeleri yaptınız ama tarayıcı kilit yerine “Connection is not fully secure” uyarısı gösteriyor mu? Bu uyarının nedeni neredeyse her zaman karışık içeriktir: HTTPS sayfanız, içinde HTTP üzerinden çağrılan resim, betik veya stil dosyası barındırıyor demektir.

Mixed content iki türlüdür:

Pasif karışık içerik: Resim, video, ses gibi varlıklar HTTP üzerinden gelir. Tarayıcı bunları yükler, ancak sayfayı “tam güvenli değil” olarak işaretler.

Aktif karışık içerik: JavaScript, CSS veya iframe gibi sayfanın davranışını etkileyen dosyalar HTTP üzerinden çağrılır. Modern tarayıcılar bu istekleri otomatik bloklar; sonuç sıklıkla bozuk düzen, eksik fonksiyon veya beyaz boşluk olarak görünür.

Mixed Content Kaynaklarını Tespit Etme

Tarayıcı geliştirici araçlarını açın (F12) ve Console sekmesine bakın. “Mixed Content” satırlarını gördüğünüzde tam URL listelenir. Bu URL’leri toplayıp veritabanı taraması için bir tabloya kaydedin. Ayrıca Chrome’un Network sekmesinde “Insecure” filtresiyle yalnızca HTTP istekleri listelenir; bu liste rapor üretmek için en hızlı yöntemdir.

WP-CLI ile URL Tarama ve Toplu Replace

Eğer SSH erişiminiz varsa wp-cli ile veritabanını güvenli biçimde tarayabilirsiniz:

wp search-replace 'http://example.com' 'https://example.com' \
    --dry-run --report-changed-only --skip-columns=guid

wp search-replace 'http://example.com' 'https://example.com' \
    --report-changed-only --skip-columns=guid --all-tables

İlk komut --dry-run ile çalışır ve hiçbir değişiklik yapmadan etkilenecek satırları sayar; ikinci komut gerçek değişikliği uygular. --skip-columns=guid bayrağı SEO açısından kritiktir: GUID alanları kalıcı kimlik olarak kabul edilir ve değişmemelidir. --all-tables ise eklenti tarafından açılan özel tablolardaki URL’leri de tarar.

WooCommerce kullanıyorsanız siparişler, müşteri meta alanları ve PDF fatura URL’leri için ayrıca dikkatli olun; wp_postmeta ve wp_options tabloları en sık unutulan iki yerdir.

WP-CLI’ye Erişiminiz Yoksa: Better Search Replace

SSH erişimi yoksa “Better Search Replace” eklentisi ile aynı işlemi yapabilirsiniz. Önce mutlaka tam veritabanı yedeği alın, ardından “Run as dry run?” seçeneğiyle bir önizleme alın. Sonuçlar tutarlıysa kuru çalıştırma kapalıyken işlemi tekrar çalıştırın. Eklenti, serileştirilmiş PHP nesnelerini bozmadan değer değiştirir; bu önemlidir çünkü düz SQL REPLACE komutu serileştirme uzunluk değerlerini bozar ve eklenti ayarlarını çökertir.

Sabit Kodlanmış HTTP Kaynakları

Bazen tema veya eklenti dosyalarında doğrudan http:// yazılı asset URL’leri bulunur. Çocuk tema (child theme) klasörünüzü, custom CSS dosyalarınızı ve özel HTML widget’larını mutlaka tarayın:

grep -RIn 'http://example.com' wp-content/themes/your-theme/
grep -RIn 'http://example.com' wp-content/plugins/your-plugin/

Tema desteği veya CDN yapılandırmasında protokol bağımsız (//cdn.example.com/...) URL’lere geçmek de iyi bir alışkanlıktır.

Adım 5: HSTS, Upgrade-Insecure-Requests ve CSP

HTTP’den HTTPS’e geçtikten sonra eski yönlendirmelerin atlanması için tarayıcıya “bu siteye yalnızca HTTPS üzerinden gel” diyebilirsiniz. Bunun için HTTP Strict Transport Security başlığı kullanılır.

Apache için .htaccess:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Nginx için sunucu bloğunda:

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

HSTS başlığı bir yıl boyunca tarayıcıyı bağlar; bu yüzden test ortamında veya yeni geçişte önce kısa max-age (örneğin 300 saniye) ile başlayıp, üç-beş gün sorunsuz geçtikten sonra bir yıla yükseltmek güvenlidir.

Upgrade-Insecure-Requests

Eski içeriklerinizi tek tek temizlemek yerine, tarayıcıya HTTP olarak istenen kaynakları otomatik HTTPS’e yükseltmesini söyleyebilirsiniz:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Bu satırı tema header.php dosyanıza eklerseniz, içerikte hâlâ kalmış olan HTTP varlıkları tarayıcı tarafında HTTPS isteği olarak yapılır. Yalnızca dış kaynak HTTPS’i destekliyorsa işe yarar; aksi halde 404 alabilirsiniz. Bu nedenle upgrade-insecure-requests uzun vadeli çözüm yerine geçici bir tampon olarak görülmelidir.

İçerik Güvenliği Politikası (CSP)

Daha sıkı bir kontrol istiyorsanız CSP başlığı ile default-src 'self' https: gibi kurallar koyup HTTP isteklerini tamamen engelleyebilirsiniz. CSP’yi devreye almadan önce raporlama modunda (Content-Security-Policy-Report-Only) test etmeniz gerekir; aksi halde reklam veya analitik betikleri kırabilirsiniz.

Adım 6: Dış Servisler ve Entegrasyonlar

SSL geçişi sonrasında sıklıkla unutulan üç entegrasyon vardır:

Google Search Console: HTTPS adresi ayrı bir mülk olarak doğrulanmalıdır. Eski HTTP mülkünden kapsam aktarımı kendiliğinden olmaz; her iki versiyonu da Search Console’da tutmanız ve sitemap’i HTTPS sürümü için yeniden göndermeniz gerekir.

Google Analytics: Yönetici → Mülk Ayarları’nda “Default URL” alanını https:// ile güncelleyin. Yönlendirme zincirinden gelen referrer’lar bazen ölçümü etkileyebilir; HSTS sonrası birkaç gün veride dalgalanma olabileceğini hesap edin.

Üçüncü taraf API ve webhook’lar: Stripe, iyzico, PayTR gibi ödeme sağlayıcıları ile webhook URL’lerini HTTPS olarak güncellemek zorunludur. Sosyal medya entegrasyonları (Facebook OAuth, Google Login) çoğunlukla yalnızca HTTPS callback URL kabul eder; geçişten önce uygulama ayarlarını gözden geçirin.

Sorun Giderme Checklist

HTTPS geçişi sonrası sayfa açılmıyor veya kilit ikonu kırık görünüyorsa şu noktaları sırayla kontrol edin: (1) sertifika gerçekten o domain için mi düzenlendi, (2) sertifika zinciri (intermediate) eksiksiz mi, (3) SSL Labs taraması A veya A+ veriyor mu, (4) wp-config.php sabitleri ve site URL ayarları HTTPS olarak güncel mi, (5) .htaccess ya da Nginx yönlendirme kuralları çakışıyor mu, (6) Cloudflare modu Full (strict) mi, (7) WP Rocket veya LiteSpeed Cache gibi cache eklentileri eski HTTP versiyonu önbelleğe almış olabilir mi, (8) sabit URL’ler için yeni search-replace turu gerekli mi, (9) HSTS preload yanlış aktive edildi mi, (10) tarayıcı önbelleğini gizli sekmede temizledikten sonra hata devam ediyor mu.

Sertifika Yenileme Otomasyonu

Let’s Encrypt sertifikaları 90 gün geçerlidir. cPanel/Plesk ortamlarında AutoSSL/SSL It! bunu otomatik yapar, ancak DNS-01 doğrulaması kullandığınız wildcard sertifikalarda token zaman zaman elle yenilenmek zorunda kalabilir. Cron tabanlı bir kontrol kurun:

0 3 * * * /usr/local/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

Plesk veya cPanel kullanıyorsanız panelin yenileme günlüğüne haftada bir göz atmak yeterlidir; başarısız yenileme uyarılarını e-postaya yönlendirmek hayat kurtarır.

Performans Üzerinde HTTPS’in Etkisi

HTTPS ek bir TLS el sıkışma süresi getirir; ancak bu yük, HTTP/2 ve HTTP/3 ile fazlasıyla telafi edilir. TLS 1.3 özellikle “0-RTT” ile yeniden bağlantı kurulumunu neredeyse anlık hâle getirir. WordPress tarafında SSL geçişi sonrası dikkat edilmesi gerekenler şunlardır: Object Cache (Redis veya Memcached) hâlâ eski URL’leri tutabilir; geçiş sonrası önbelleği temizleyin. CDN entegrasyonunda kaynak (origin) URL’lerinin HTTPS’e güncellendiğinden emin olun. wp-cron dış servislerle iletişimde HTTPS sertifikası doğrulayamıyorsa cURL hatası verir; sunucuda güncel CA-Bundle dosyası olduğunu kontrol edin.

Yedekleme ve Geri Dönüş Planı

Mixed content temizlemek için search-replace çalıştırmadan önce mutlaka tam yedek alın. WordPress yedekleme stratejiniz UpdraftPlus, BlogVault veya hosting tarafındaki JetBackup gibi araçlardan birine dayanmalıdır. SQL dökümünü ayrıca indirip yerel diskinizde tutmak, en kötü senaryoda dakikalar içinde dönüş sağlar. Yedek planınızı yazarken üç soruyu yanıtladığınızdan emin olun: yedek nereye kaydediliyor (sunucuda kalan yedek değerli değildir), kaç sürüm tutuluyor (en az haftalık + günlük), ve geri yükleme prosedürü test edildi mi? Test edilmemiş yedek aslında yedek değildir.

Sıkça Sorulan Sorular (SSS)

SSL kurulumu sonrası site açılmıyor, ne yapmalıyım?

Yaygın iki neden vardır: wp-config.php dosyasında HTTPS sabitleri yazılmadan WordPress URL’leri elle değiştirildi (yönlendirme döngüsü) ya da Cloudflare SSL modu yanlış. İlk önce wp-config.php‘ye WP_HOME ve WP_SITEURL sabitlerini ekleyin, ardından Cloudflare panelinden SSL modunu Full (strict) yapın.

Hâlâ kilit yerine sarı uyarı görüyorum?

Geliştirici araçlarının Console sekmesinde “Mixed Content” uyarılarını görün, listelenen URL’leri search-replace ile HTTPS’e güncelleyin. Tema veya eklentilerin sabit kodladığı kaynaklar için upgrade-insecure-requests başlığı geçici çözüm sağlar.

Ücretsiz Let’s Encrypt sertifikası kurumsal site için yeterli mi?

Teknik açıdan evet: TLS gücü ve şifreleme aynıdır. Ancak müşterilerinizin sertifikada şirket ismi görmesi gerekiyorsa OV ya da EV sertifika tercih edin. Banka ve fintech projeleri için EV; standart kurumsal site için OV yeterlidir.

Search-replace sonrası eklenti ayarları kayboldu, neden?

Yüksek olasılıkla düz SQL REPLACE komutu kullanılmış ve serileştirilmiş PHP verileri bozulmuş. Yedeği geri yükledikten sonra mutlaka WP-CLI veya Better Search Replace gibi serialization-aware araçlarla işlem yapın.

HSTS’i devre dışı bırakmak için ne yapmalıyım?

Strict-Transport-Security başlığını sunucudan kaldırmak yetmez; tarayıcıda zaten kayıtlı olan kuralın süresi dolana kadar etkisi sürer. max-age=0 değerini bir hafta boyunca yayınlayarak aktif tarayıcılardan kuralı temizleyebilirsiniz. Bu nedenle HSTS preload listesine eklenmeyi acele etmeyin.

Sertifika yenilenmedi, site açılmıyor, ilk müdahale ne olmalı?

Önce HTTP üzerinden hosting paneline erişip SSL/TLS Status ekranını kontrol edin. AutoSSL hatası varsa neredeyse her zaman bir DNS kaydının eksik veya farklı sunucuyu işaret etmesidir. DNS sağlayıcınızdan A kayıtlarını doğrulayıp, sertifikayı yeniden çalıştırın. Sertifika düzelene kadar kullanıcılara duyuru için statik bir bakım sayfası yayınlayabilirsiniz.

Çok Siteli (Multisite) ve Alt Alan Senaryoları

WordPress Multisite kurulumlarında her alt site için ayrı bir HTTPS yönlendirmesi ve sertifika kapsamı düşünmek zorundasınız. Alt klasör (subdirectory) yapısı kullanıyorsanız tek sertifika tüm ağı kapsar. Alt alan adı (subdomain) yapısında ise wildcard sertifika gereklidir; aksi halde her yeni alt site için ayrı doğrulama yapmak zorunda kalırsınız. wp-config.php içinde define( 'COOKIE_DOMAIN', '.example.com' ); sabitini eklerseniz oturum çerezleri tüm alt alanlarda paylaşılabilir; ancak bu durumda HSTS başlığını mutlaka includeSubDomains ile yayınlamak gerekir, aksi halde tek bir alt alanda yapılan eksik geçiş tüm ağı zayıflatır.

Ek olarak, network admin panelinde Sites ekranından her alt sitenin siteurl ve home değerlerini tek tek HTTPS olarak güncellemek gerekir. WP-CLI ile bu işlemi tek komutla yapabilirsiniz: wp site list --field=url | xargs -I{} wp option update home {} --url={} benzeri bir döngü, on, yüz veya bin alt siteyi dakikalar içinde günceller.

Staging ve Üretim Arasında Geçiş Disiplini

SSL ile ilgili değişiklikleri her zaman önce staging ortamında test edin. Hosting sağlayıcınız staging özelliği sunuyorsa kullanın; sunmuyorsa Local by Flywheel veya DevKinsta gibi araçlarla yerel kopyada deneyin. .htaccess ya da Nginx kuralı değişiklikleri canlıya bir kerede uygulanmamalı; kademeli yayın (canary) yaklaşımı ile küçük bir trafik diliminde test etmek, hatayı erken yakalamayı sağlar. Yapılan her sertifika ve yönlendirme değişikliğini tarihi ve gerekçesiyle birlikte bir change log dosyasına kaydedin; aylar sonra sorun çıktığında nedenini geri izlemek için en değerli kaynak budur.

Kaynak Önerileri

HTTPS ve TLS dünyasını derinlemesine anlamak için Mozilla Web Security Cheat Sheet, Cloudflare Learning Center ve SSL Labs Test Aracı (ssllabs.com/ssltest/) güvenli yönlendirici niteliğindedir. WordPress üzerine düzenli olarak güncellenen iki kaynak da WordPress.org Hardening WordPress sayfası ile WP Hosting Performance Benchmarks 2026 raporudur. Mixed content denetimi için tarayıcının yerleşik DevTools’u dışında “Why No Padlock?” gibi ücretsiz online tarayıcılar hızlı bir özet sunar; ancak gerçek tarama için DevTools Console + sunucu erişim logları her zaman daha güvenilirdir.

Sonuç

SSL kurulumu, HTTPS yönlendirmesi ve mixed content temizliği aslında üç ayrı disiplinin (sunucu yapılandırması, WordPress yönetimi ve istemci tarafı denetim) birlikte yürütüldüğü tek bir projedir. Sertifikayı doğru kurun, yönlendirme zincirini sadeleştirin, search-replace ile veritabanını temizleyin, HSTS ile tarayıcıyı bağlayın ve son olarak tarama araçlarıyla doğrulayın. Bu beş adımı disipline ettiğinizde tarayıcıdaki kilit ikonu artık yalnızca bir ikon değil; tüm trafiğin uçtan uca şifrelendiğinin güvenilir bir göstergesidir. Düzenli yedek alma, otomatik sertifika yenileme ve önbellek yönetimi ile kurguladığınız bu yapı, WordPress sitenize uzun vadeli bir güvenlik ve performans avantajı kazandırır.