WordPress'te HTTPS Zorlama ve Karma Icerik Cozumu

SSL sertifikasını kurdunuz, tarayıcının adres çubuğunda kilit ikonu görünüyor, ama iş burada bitmiyor. Sertifika yüklenmiş olması, sitenizin gerçekten güvenli çalıştığı anlamına gelmez. WordPress hâlâ eski http:// adreslerini veritabanında saklıyor olabilir, tema ve eklentiler sayfaya sabit http:// bağlantılarla gömülü görseller yükleyebilir, arama motoru hâlâ sitenizin güvensiz sürümünü indeksliyor olabilir. Sonuç: kullanıcı adres çubuğunda kilit yerine "Güvenli değil" uyarısı görür ya da kilit gri renkte, üstünde küçük bir uyarı üçgeniyle belirir. Bu yazıda tam olarak bunu, yani sertifikayı kurduktan sonra kalan işi ele alıyoruz.

Hedefimiz üç aşamalı: önce WordPress'in kendi adreslerini https:// yapmak, sonra siteye gelen tüm trafiği tek bir 301 yönlendirmeyle HTTPS'e taşımak, en son da veritabanının derinliklerinde kalmış eski http:// bağlantılarını temizleyip karma içerik (mixed content) uyarılarını kökünden çözmek. Ben yıllardır barındırma tarafında bu geçişi hem elle hem de eklentiyle onlarca kez yaptım; aşağıdaki adımlar üretimde çalışan siteler üzerinde denenmiş, sıralaması bilerek kurulmuş bir yol haritası. SSL'i henüz kurmadıysanız önce Let's Encrypt ücretsiz SSL yazısına göz atın; bu makale sertifikanın çoktan yüklü olduğu varsayımıyla ilerliyor.

Karma Icerik (Mixed Content) Tam Olarak Nedir#

Karma içerik, HTTPS üzerinden yüklenen bir sayfanın içinde http:// ile çağrılan kaynaklar bulunması durumudur. Sayfanın kendisi şifreli gelir ama içindeki bir görsel, bir CSS dosyası ya da bir JavaScript dosyası şifresiz kanaldan istenir. Tarayıcı bunu güvenlik açığı olarak görür, çünkü şifresiz gelen o tek dosya araya girme (man-in-the-middle) saldırısına açıktır ve sayfanın bütünlüğünü bozar.

Tarayıcılar karma içeriği iki sınıfa ayırır. Pasif karma içerik görseller, video ve ses gibi sayfanın çalışma mantığını değiştiremeyen kaynaklardır; çoğu tarayıcı bunları yükler ama kilidi "eksik" gösterir. Aktif karma içerik ise script, CSS, iframe ve XHR/fetch istekleridir; bunlar sayfanın davranışını değiştirebildiği için modern tarayıcılar bunları doğrudan bloklar. Yani sabit http:// ile gömülü bir JavaScript dosyası yüzünden slider'ınız çalışmayabilir, formunuz gönderilmeyebilir. Sorunun nereden geldiğini görmek için tarayıcıda F12 ile geliştirici araçlarını açıp Console sekmesine bakın:

Mixed Content: The page at 'https://siteniz.com/' was loaded over HTTPS,
but requested an insecure image 'http://siteniz.com/wp-content/uploads/logo.png'.
This content should also be served over HTTPS.

Bu satır size hangi dosyanın hâlâ http:// ile çağrıldığını net şekilde söyler. Kaynağı üç yerden biri olur: veritabanına kaydedilmiş eski URL'ler, tema/eklenti kodunda sabit yazılmış http:// bağlantılar veya harici bir kaynağın (font, harita, reklam kodu) şifresiz sürümü. Aşağıdaki bölümlerde bu üçünü de teker teker kapatıyoruz.

WordPress Site Adreslerini HTTPS Yapmak#

İlk ve en temel adım, WordPress'in kendi bildiği adresi güncellemektir. WordPress iki ayrı adres tutar: WordPress Adresi (URL), çekirdek dosyalarının bulunduğu yer; ve Site Adresi (URL), ziyaretçilerin girdiği ana adres. Bunların ikisi de https:// ile başlamalı. Yönetim panelinde Ayarlar > Genel ekranına gidip her iki alanı da http://siteniz.com yerine https://siteniz.com olarak değiştirin ve kaydedin.

Panele erişiminiz yoksa (örneğin yanlış ayar yüzünden yönlendirme döngüsüne girdiyseniz) aynı değeri wp-config.php dosyasına sabitleyebilirsiniz. Bu, veritabanındaki değeri geçersiz kılar ve panele girmeden düzeltme yapmanızı sağlar:

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

Bu iki satırı wp-config.php içinde /* That's all, stop editing! */ satırından önce ekleyin. Bir uyarı: bu tanımlar aktifken Ayarlar > Genel ekranındaki alanlar gri (düzenlenemez) görünür, çünkü artık değer dosyadan geliyor. Bu normaldir.

Sitenizi bir yük dengeleyici, Cloudflare ya da ters proxy arkasında çalıştırıyorsanız, WordPress bağlantının HTTPS olduğunu algılayamayıp yönlendirme döngüsüne girebilir. Bu klasik "too many redirects" hatasıdır. Çözümü, proxy'nin gönderdiği başlığı WordPress'e okutmaktır:

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

Bu bloğu da wp-config.php içine, require_once satırından önce ekleyin. Bu adımdan sonra WordPress kendini artık HTTPS sitesi olarak görür, ama eski içeriklerdeki bağlantılar hâlâ http:// olabilir; onları birazdan temizleyeceğiz.

htaccess ve nginx ile Tum Trafigi 301 Yonlendirme#

Adres ayarını değiştirmek, kullanıcının http:// ile gelmesini engellemez. Birisi tarayıcıya elle http://siteniz.com yazarsa ya da eski bir bağlantıya tıklarsa, sunucunun onu kalıcı olarak (301) HTTPS'e taşıması gerekir. 301, hem tarayıcıya hem de arama motoruna "bu sayfa temelli taşındı" der; bu sayede SEO değeri yeni adrese aktarılır. Bu konunun tüm inceliklerini HTTPS yönlendirme rehberimizde ayrıntılı işledik, ama WordPress'e özel özü burada da vereyim.

Apache kullanıyorsanız, sitenizin kök dizinindeki .htaccess dosyasına aşağıdaki kuralı WordPress'in kendi blok yorumlarının dışına, dosyanın en üstüne ekleyin:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Cloudflare ya da bir proxy arkasındaysanız %{HTTPS} off koşulu yanıltıcı olabilir; bu durumda iletilen protokol başlığını kontrol etmek daha güvenlidir:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Nginx kullanıyorsanız .htaccess çalışmaz; yönlendirmeyi sunucu bloğunda tanımlarsınız. En temiz yöntem, 80 portunu dinleyen ayrı bir sunucu bloğu açıp tek işini yönlendirme yapmaktır:

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

Yönlendirmeyi kurduktan sonra mutlaka test edin. Komut satırından tek bir istekle 301 dönüp dönmediğini görebilirsiniz:

curl -I http://siteniz.com
# Beklenen: HTTP/1.1 301 Moved Permanently
# Location: https://siteniz.com/

Yönlendirme kalıcı olarak yerine oturduktan sonra bir adım daha atıp HSTS (HTTP Strict Transport Security) başlığını devreye alabilirsiniz. HSTS, tarayıcıya "bu siteye bir daha asla http:// ile bağlanma" der ve ilk 301 adımını bile atlatır. Ama dikkatli olun: yanlış yapılandırılmış HSTS, sertifikanız bir gün sorun çıkarırsa siteyi tamamen erişilmez yapabilir, çünkü tarayıcı http:// denemeyi reddeder. Bu yüzden HSTS'i ancak HTTPS'in her koşulda sorunsuz çalıştığından emin olduktan sonra ekleyin:

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

Really Simple SSL ile Hizli Cozum#

Elle uğraşmak istemiyor ya da hızlı bir çözüm arıyorsanız, en yaygın eklenti Really Simple SSL'dir. Bu eklenti tek tıkla site adreslerini HTTPS'e çevirir, yönlendirmeyi ekler ve karma içeriği çoğu durumda otomatik düzeltir. Kurulumu basittir: Eklentiler > Yeni Ekle menüsünden aratıp kurar, etkinleştirir ve çıkan "SSL'i etkinleştir" düğmesine tıklarsınız.

Eklentinin çalışma mantığını anlamak önemli. Really Simple SSL, veritabanındaki URL'leri kalıcı olarak değiştirmez; bunun yerine sayfa çıktısını çalışma anında (on-the-fly) tarayıp http:// bağlantıları https:// olarak yeniden yazar. Bu, hızlı ve geri alınabilir bir yaklaşımdır ama bir maliyeti vardır: her sayfa yüklemesinde bu değiştirme işlemi çalışır, yani küçük bir performans yükü getirir. Küçük ve orta ölçekli siteler için bu fark hissedilmez, ama yüksek trafikli bir sitede kalıcı çözümü tercih ederim.

İki yaklaşımı karşılaştıralım:

Benim önerim şudur: acil bir siteyse ya da müşteriye hızlı sonuç göstermeniz gerekiyorsa Really Simple SSL ile başlayın, sonra fırsat bulunca aşağıdaki search-replace adımını uygulayıp veritabanını gerçekten temizleyin ve eklentiyi kaldırın. Böylece hem hızlı çözersiniz hem de uzun vadede temiz ve bağımsız bir kuruluma sahip olursunuz. Eklentinin ücretsiz sürümü çoğu site için yeter; premium sürüm HSTS, güvenlik başlıkları ve merkezi yönetim gibi ekstralar sunar.

Veritabanindaki http URL'lerini Search-Replace ile Guncellemek#

İşin en kritik ve en çok atlanan kısmı budur. WordPress veritabanında yıllar içinde birikmiş yüzlerce hatta binlerce http://siteniz.com bağlantısı olabilir: yazı içeriklerine gömülü görseller, menü linkleri, widget ayarları, tema seçenekleri, eklenti verileri. Bunları elle tek tek düzeltmek imkânsıza yakındır; toplu bir arama-değiştirme işlemi gerekir.

Önce yedek alın. Bu adım veritabanını doğrudan değiştirdiği için, bir hata durumunda geri dönebilmeniz şart. Yedeklemeyi ister barındırma panelinden ister komut satırından yapabilirsiniz. Düzenli otomatik yedek için yedekleme çözümlerimize da göz atmanızı öneririm.

# Veritabanini yedekle (elle geri donebilmek icin)
mysqldump -u kullanici -p veritabani_adi > yedek-$(date +%F).sql

En güvenli araç WP-CLI'dir çünkü serileştirilmiş (serialized) verileri doğru şekilde işler. WordPress bazı ayarları PHP serialize formatında saklar; bu formatta metin uzunlukları veriye gömülüdür. Düz bir SQL REPLACE komutuyla http:// yazısını https:// ile değiştirirseniz, karakter sayısı değiştiği için serileştirilmiş veri bozulur ve o ayarlar çalışmaz olur. WP-CLI bunu otomatik olarak düzgün yönetir:

# Once ne degiseceginin provasini yap (hicbir sey yazmaz)
wp search-replace 'http://siteniz.com' 'https://siteniz.com' --dry-run

# Sonuc dogru gorunuyorsa gercek degistirmeyi calistir
wp search-replace 'http://siteniz.com' 'https://siteniz.com' --all-tables --report-changes-only

--dry-run bayrağı çok değerlidir: hiçbir şey yazmadan kaç satırın etkileneceğini önizletir. Sonucu inceleyip beklediğiniz sayıda değişiklik olduğunu gördükten sonra bayrağı kaldırıp gerçek komutu çalıştırın. WP-CLI'ye erişiminiz yoksa, phpMyAdmin üzerinden de yapabilirsiniz ama serileştirme riskine dikkat edin; bu yüzden phpMyAdmin'de en riskli alanlar olan wp_posts içeriğiyle sınırlı kalmayı tercih ederim:

-- Yazi iceriklerindeki gomulu baglantilar (serialize icermez, guvenli)
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://siteniz.com', 'https://siteniz.com');

-- Yazi adresleri (guid'i genellikle degistirmeyin; RSS okuyucularini bozar)
UPDATE wp_posts
SET post_content_filtered = REPLACE(post_content_filtered, 'http://siteniz.com', 'https://siteniz.com');

Bir not: wp_posts tablosundaki guid sütununa dokunmayın. guid, RSS beslemelerinde her yazının kalıcı benzersiz kimliği olarak kullanılır; onu değiştirmek abonelerin tüm yazıları "yeni" olarak tekrar görmesine yol açar. Tarayıcıda görünen adresi belirleyen o değil, permalink yapısıdır. wp_options, wp_postmeta gibi serileştirilmiş veri içeren tabloları elle değiştirmek yerine mutlaka WP-CLI kullanın.

Değiştirmeyi tamamladıktan sonra WordPress önbelleğini ve varsa CDN önbelleğini temizleyin, sonra tekrar F12 > Console'a bakın. Bu noktada karma içerik uyarılarının büyük çoğunluğu kaybolmuş olmalı.

Tema, Eklenti ve Harici Kaynaklardan Gelen Karma Icerik#

Veritabanını temizledikten sonra hâlâ birkaç inatçı karma içerik uyarısı kalabilir. Bunların kaynağı genellikle veritabanı değil, kodun kendisidir. Bazı tema ve eklentiler görselleri, fontları ya da script'leri kodun içine sabit http:// ile yazar. Bunları bulmak için Console'daki uyarı satırındaki tam dosya yolunu okuyun; size hangi klasördeki hangi dosyanın sorumlu olduğunu söyler.

En sağlıklı yaklaşım, kaynakları protokol-bağımsız ya da tam https:// hâline getirmektir. Modern standart, kaynağı doğrudan https:// ile yazmaktır; eskiden kullanılan protokolsüz //alan.com/dosya.js yazımı hâlâ çalışır ama artık önerilmez. Bir tema dosyasında şuna benzer bir satır görürseniz düzeltin:

// Yanlis - karma icerige yol acar
wp_enqueue_script( 'harita', 'http://maps.example.com/api.js' );

// Dogru
wp_enqueue_script( 'harita', 'https://maps.example.com/api.js' );

Harici kaynaklarda ise bir incelik var: bazen sorun sizde değil, o hizmetin HTTPS'i desteklememesindedir. Eğer gömdüğünüz bir font, harita ya da widget yalnızca http:// sunuyorsa, o kaynağı HTTPS destekleyen bir alternatifle değiştirmeniz gerekir; yoksa tarayıcı onu bloklamaya devam eder. Tema kodunu doğrudan düzenliyorsanız, ana temada değil bir alt tema (child theme) içinde çalışın; aksi halde tema güncellemesi değişikliğinizi silip süpürür.

Son bir güvenlik ağı olarak, çıktıdaki kalıntı http:// kaynaklarını tarayıcıya otomatik yükseltmesini söyleyen bir başlık ekleyebilirsiniz. Content-Security-Policy: upgrade-insecure-requests başlığı, sayfadaki tüm http:// isteklerini tarayıcı düzeyinde https://'e çevirir. Bu bir çözüm değil, bir emniyet kemeridir; asıl işi yukarıdaki adımlarla yapmalısınız:

Header always set Content-Security-Policy "upgrade-insecure-requests"

WordPress güvenliğini bir üst seviyeye taşımak isterseniz, sunucu önünde bir WAF (web uygulama güvenlik duvarı) ve DDoS koruması katmanı da bu HTTPS temelinin üzerine oturur. HTTPS, güvenliğin başlangıcıdır; tek başına yeterli değildir ama olmazsa olmazıdır.

HTTPS Gecisi Sonrasi Kontrol Listesi#

Geçişi tamamladıktan sonra atlanan bir detay yüzünden sorun yaşamamak için son bir tur atmak gerekir. Aşağıdaki tablo, benim her HTTPS geçişinden sonra tek tek işaretlediğim kontrol listesidir. Her maddeyi doğrulamadan işi "bitti" saymayın.

Arama motoru tarafını da unutmayın. Google Search Console'da sitenizin HTTPS sürümünü ayrı bir "mülk" olarak ekleyip doğrulayın ve güncel sitemap.xml dosyanızı gönderin. Analytics kullanıyorsanız, mülk ayarlarındaki varsayılan URL'yi de https:// olarak güncelleyin; aksi halde yönlendirme trafiği raporlarda kopuk görünebilir. Bu SEO tarafındaki ince ayarların tamamını SEO hizmetlerimiz kapsamında da ele alıyoruz.

Son olarak, geçişten sonra birkaç gün sitenizin canlı davranışını izleyin. Özellikle ödeme formları, iletişim formları, harici API çağrıları ve gömülü içerikler (video, harita) HTTPS geçişinden en çok etkilenen noktalardır. Bir şeyin çalışmadığını fark ederseniz ilk bakacağınız yer yine F12 > Console olacaktır.

Sıkça Sorulan Sorular#

SSL kurdum ama tarayıcı hâlâ "Güvenli değil" diyor, neden?#

Bu neredeyse her zaman ya karma içerik ya da eksik yönlendirme kaynaklıdır. Sertifikanın yüklü olması yeterli değildir; sayfanın içinde tek bir http:// ile çağrılan görsel ya da script kalmışsa tarayıcı kilidi tam güvenli göstermez. Önce F12 ile Console sekmesini açıp hangi kaynağın hâlâ http:// olduğuna bakın, sonra veritabanı search-replace ve tema düzeltmeleri adımlarını uygulayın. Bir diğer olasılık, kullanıcının hâlâ http:// sürümüne gidiyor olması ve 301 yönlendirmenizin eksik olmasıdır.

Really Simple SSL kullanmak mı yoksa elle yapmak mı daha iyi?#

İkisinin de yeri var. Really Simple SSL hızlıdır, tek tıkla çalışır ve teknik bilgi gerektirmez; ama URL'leri veritabanında kalıcı düzeltmez, her sayfa yüklemesinde çalışma anında yeniden yazar ve küçük bir performans yükü getirir. Elle yapılan search-replace ise veritabanını gerçekten temizler, hiçbir ek yük getirmez ve sizi eklentiye bağımlı bırakmaz. Benim önerim, acil durumda eklentiyle başlayıp fırsat bulunca veritabanını search-replace ile temizlemek ve ardından eklentiyi kaldırmaktır.

Veritabanında URL değiştirirken neden WP-CLI öneriliyor?#

Çünkü WordPress bazı ayarları serileştirilmiş (serialized) PHP formatında saklar ve bu formatta metin uzunlukları verinin içine gömülüdür. Düz bir SQL REPLACE komutu http:// yazısını https:// ile değiştirdiğinde karakter sayısı bir arttığı için serileştirilmiş veri bozulur; o ayar bir daha okunamaz. WP-CLI'nin search-replace komutu bu uzunlukları otomatik yeniden hesaplayarak veriyi bozmadan değiştirir. phpMyAdmin ile yapacaksanız yalnızca serileştirme içermeyen wp_posts.post_content gibi alanlarla sınırlı kalın.

wp-config.php'ye eklediğim satırlar yüzünden panel ayarları gri göründü, sorun mu var?#

Hayır, bu tamamen normaldir ve beklenen davranıştır. wp-config.php içine WP_HOME ve WP_SITEURL tanımlarını eklediğinizde WordPress bu değerleri dosyadan okur ve veritabanındaki değeri geçersiz kılar. Bu yüzden Ayarlar > Genel ekranındaki iki alan düzenlenemez (gri) hâle gelir; çünkü artık değerin kaynağı panel değil, dosyadır. Değeri değiştirmek isterseniz dosyadaki satırı düzenlersiniz. Bu satırlar özellikle yönlendirme döngüsü yaşandığında panele girmeden düzeltme yapmayı sağladığı için faydalıdır.

HTTPS'e geçince SEO ve arama sıralamam etkilenir mi?#

Doğru yapılırsa etkilenmez, hatta olumlu etkilenir. Kritik nokta, tüm eski http:// adreslerinden yeni https:// adreslerine 301 (kalıcı) yönlendirme kurmaktır; 301, sayfanın SEO değerini yeni adrese aktarır. Ayrıca Google Search Console'a HTTPS sürümünü mülk olarak ekleyin ve güncel sitemap gönderin. Google HTTPS'i hafif bir sıralama sinyali olarak kabul ettiğinden, düzgün bir geçiş genelde nötr ya da olumlu sonuç verir. Yanlış yapılan tek şey, yönlendirmeyi 302 (geçici) yapmak ya da hiç kurmamaktır.

Cloudflare veya proxy arkasındayım, "too many redirects" hatası alıyorum, ne yapmalıyım?#

Bu, WordPress ile proxy'nin protokol konusunda anlaşamamasından kaynaklanır. Proxy ziyaretçiye HTTPS sunar ama sunucuya HTTP olarak iletir; WordPress bağlantıyı HTTP sanıp tekrar HTTPS'e yönlendirmeye çalışır ve döngü oluşur. Çözüm, wp-config.php içine HTTP_X_FORWARDED_PROTO başlığını kontrol eden bloğu ekleyip $_SERVER['HTTPS']'i on yapmaktır. Ayrıca Apache kuralınızda %{HTTPS} off yerine %{HTTP:X-Forwarded-Proto} !https koşulunu kullanın. Cloudflare tarafında SSL/TLS modunu "Full" ya da "Full (Strict)" seçmek de bu döngüyü önler.

Kapanış#

HTTPS geçişi, sertifikayı kurmakla değil, sitenin her köşesini şifreli kanala taşımakla tamamlanır. Özetle sıralama şudur: önce WordPress adreslerini https:// yapın, sonra tüm trafiği 301 ile HTTPS'e yönlendirin, ardından veritabanındaki eski bağlantıları WP-CLI search-replace ile temizleyin ve son olarak tema, eklenti ve harici kaynaklardan gelen karma içerik kalıntılarını kapatın. Bu dört adımı sırasıyla uyguladığınızda kilit ikonu kesintisiz görünür, tarayıcı hiçbir uyarı vermez ve arama motoru sitenizin güvenli sürümünü indekslemeye başlar.

Bu işi düzgün altyapı üzerinde yapmak her şeyi kolaylaştırır. Clou.TR WordPress hosting paketlerinde ücretsiz SSL, WP-CLI erişimi ve otomatik yedekleme hazır gelir; böylece yukarıdaki adımların hepsini panel üzerinden dakikalar içinde tamamlarsınız. Daha fazla kaynak ve performans isteyen büyük siteler için VDS sunucularımıza, site geçişini bizim yapmamızı isterseniz site taşıma hizmetimize, sürekli bakım ve güvenlik için WordPress bakım paketimize göz atabilirsiniz. Sertifikanızı henüz almadıysanız ücretsiz SSL rehberimizle başlayıp buraya dönebilirsiniz. Güvenli bir site, güvenilir bir markanın ilk adımıdır.