Sertifika kurulup HTTPS yönlendirmesi çalışsa bile yazılar, medya kayıtları, widget ayarları ve eklenti seçenekleri eski HTTP URL'lerini kullanabilir. Bu kayıtlar mixed content uyarılarına veya engellenen kaynaklara yol açar.
Yönlendirme, tarayıcının eski URL'ye yaptığı isteği yeni adrese taşır; veritabanındaki kayıtlı değeri güncellemez. Tema ve sayfa oluşturucu ayarları serileştirilmiş olabileceği için dönüşüm bu yapıyı anlayan bir araçla yapılmalıdır.
Önce HTTP URL'lerinin veritabanından mı, tema dosyasından mı, CDN veya dış hizmetten mi geldiğini belirleyin. Veritabanı kayıtları için yedek alın, dry run çalıştırın ve yalnız aynı siteye ait tam URL'leri HTTPS'ye çevirin.
- HTTP ve HTTPS arasındaki fark
- Eski HTTP adresleri neden veritabanında kalır?
- Mixed content sorunu nedir?
- HTTP URL’lerini HTTPS’ye çevirmeden önce
- Eklentiyle HTTP URL’lerini HTTPS’ye çevirme
- WP-CLI ile güvenli arama-değiştirme
- Doğrudan SQL neden risklidir?
- Yönlendirme ve WordPress adreslerini kontrol etme
- HTTPS dönüşümünden sonra siteyi test etme
- Sonuç ve doğru işlem sırası
HTTP ve HTTPS arasındaki fark
HTTP, tarayıcı ile sunucu arasındaki veri aktarımını sağlar. HTTPS aynı iletişimi TLS sertifikasıyla şifreler ve ziyaretçinin doğru sunucuya bağlandığını doğrulamaya yardımcı olur.
SSL sertifikasını kurmak, sitenin HTTPS üzerinden açılabilmesi için ilk adımdır. Ancak içerikte kayıtlı bütün bağlantılar otomatik olarak değişmez. Bir görsel hâlâ http://example.com/image.jpgadresini kullanıyorsa sayfa güvenli ve güvensiz kaynakları birlikte yükler.
Eski HTTP adresleri neden veritabanında kalır?
WordPress medya bağlantıları, menüler, bileşenler, tema seçenekleri ve eklenti ayarlarını veritabanında saklayabilir. Site yıllarca HTTP ile çalıştıysa bu adresler birçok tabloda bulunabilir. Eski URL'leri güncellemeden önce kaynağın veritabanı, tema dosyası, CDN veya harici hizmet olup olmadığını belirleyin.
- Yazı ve sayfa içeriklerinde tam görsel adresleri,
- Elementor veya başka bir sayfa oluşturucunun tasarım verileri,
- Tema özelleştirici ayarları,
- Menü ve bileşen bağlantıları,
- Üçüncü taraf script ve font adresleri.
Bazı kayıtlar normal metindir; bazıları ise PHP tarafından serileştirilmiştir. Güvenli araçlar bu yapıyı okuyup uzunluk bilgisini doğru biçimde günceller.
Mixed content sorunu nedir?
Bir sayfa HTTPS ile açıldığı hâlde içindeki bir kaynak HTTP üzerinden istenirse mixed content oluşur. Tarayıcı pasif içerikleri uyarıyla yükleyebilir, JavaScript gibi aktif içerikleri ise tamamen engelleyebilir.
Örneğin sayfanın tasarımı bozuluyor ve geliştirici konsolunda “Blocked loading mixed active content” mesajı görüyorsanız, bir CSS veya JavaScript dosyası eski protokolle çağrılıyor olabilir.
Bu nedenle arama-değiştirme işlemi yalnızca kilit simgesini düzeltmek için değil, sitenin bütün kaynaklarını tutarlı biçimde HTTPS’ye taşımak için yapılır.
HTTP URL’lerini HTTPS’ye çevirmeden önce
- Veritabanının tam yedeğini alın.
- Eski ve yeni adresi tam olarak yazın:
http://example.com→https://example.com. - WWW kullanıp kullanmadığınızı kontrol edin.
- Önce dry run, yani değişiklik yapmayan önizleme çalıştırın.
- Sonuç sayısını kaydedin ve beklenmeyen tabloları inceleyin.
http://example.comile http://www.example.comaynı arama değildir. Yanlış kaynağı seçmek, bazı bağlantıları değiştirmeden bırakabilir veya hedef adresi hatalı oluşturabilir.
Eklentiyle HTTP URL’lerini HTTPS’ye çevirme
Komut satırı kullanmak istemiyorsanız serileştirilmiş veriyi destekleyen bir arama-değiştirme aracı en kolay yöntemdir. Güvenli akış şu şekildedir:
- Aranacak değere eski tam adresi girin.
- Yeni değere HTTPS kullanan doğru adresi yazın.
- Önce dry run çalıştırın.
- Etkilenecek tabloları ve kayıt sayısını kontrol edin.
- Yedeğin hazır olduğundan emin olduktan sonra gerçek işlemi başlatın.
- İşlem geçmişini ve değişen kayıt sayısını saklayın.
Yalnızca httpkelimesini httpsile değiştirmeyin. Bu yöntem dış sitelere ait adresleri, API uçlarını veya değişmemesi gereken metinleri de etkileyebilir.
WP-CLI ile güvenli arama-değiştirme
SSH erişimi olan kullanıcılar WP-CLI ile aynı işlemi komut satırından yapabilir. Önce dry run çalıştırın:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-runSonuçlar doğru görünüyorsa --dry-runseçeneğini kaldırarak gerçek işlemi başlatabilirsiniz:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefixWordPress’in resmi WP-CLI search-replace belgesi, seçenekleri ve seri veri desteğini açıklar.
Doğrudan SQL neden risklidir?
Basit bir SQL REPLACE()sorgusu metin alanlarında çalışabilir, ancak serileştirilmiş verinin uzunluk bilgisini güncellemez. Eski ve yeni adreslerin karakter sayısı farklıysa tema veya eklenti ayarı okunamaz hâle gelebilir. Serileştirilmiş veriyi anlayan bir araç, URL uzunluğu değiştiğinde WordPress ayarlarının bozulmasını önler.
Bu nedenle doğrudan SQL yalnızca verinin yapısını kesin olarak bildiğiniz alanlarda ve staging testiyle kullanılmalıdır. Genel WordPress site taşımasında serileştirilmiş veriyi anlayan bir araç daha güvenlidir.
Yönlendirme ve WordPress adreslerini kontrol etme
Veritabanı değişikliği tamamlandıktan sonra Ayarlar → Genelbölümünde WordPress Adresi ve Site Adresi alanlarının HTTPS kullandığını doğrulayın. Bu değerler wp-config.phpiçinde sabitlenmişse panelde düzenlenemeyebilir.
Ayrıca HTTP trafiğini HTTPS’ye yönlendiren tek bir kalıcı yönlendirme bulunmalıdır. Hosting paneli, CDN ve .htaccessaynı anda farklı kurallar uyguluyorsa yönlendirme döngüsü oluşabilir.
HTTPS durumunu ayrıca AIOWS SSL Yöneticisiile sertifika, yönlendirme ve mixed content açısından kontrol edebilirsiniz.
HTTPS dönüşümünden sonra siteyi test etme
- Ana sayfa, önemli açılış sayfaları ve yazıları gizli pencerede açın.
- Tarayıcı geliştirici araçlarında Console ve Network sekmelerini kontrol edin.
- Form, ödeme, üyelik ve giriş akışlarını deneyin.
- Önbellek ve CDN kullanıyorsanız eski HTML kopyalarını temizleyin.
- Kaynak kodunda eski alan adıyla arama yapın.
Birkaç eski bağlantı kalmışsa bütün veritabanını yeniden değiştirmeden önce bunların nereden geldiğini bulun. Tema dosyası, harici script veya CDN ayarı veritabanı aramasından etkilenmez.
ALL IN ONE WP SETTINGS · REPLACE MANAGER
URL değişikliklerini önce görün, sonra güvenle uygulayın
Arama ve değiştirme işlemi veritabanındaki yüzlerce hatta binlerce değeri etkileyebilir. Bu nedenle iyi bir araç yalnızca metni hızlı değiştirmemelidir. İşlem öncesinde hangi kayıtların etkileneceğini göstermeli, WordPress’in veri yapısını korumalı ve yapılan değişikliği daha sonra inceleyebilmenizi sağlamalıdır. All in One WP Settings içindeki Replace Manager bu süreci tek bir yönetim ekranında toplar.
Dönüşümü uygulamadan önce dry run çalıştırarak eşleşme sayısını ve kapsamı görebilirsiniz. Eski ve yeni adresi kontrol ettikten sonra gerçek işlemi başlatırsınız. Modül, widget ayarları, tema seçenekleri, sayfa oluşturucu içerikleri ve eklenti verileri gibi serileştirilmiş kayıtları sıradan metin olarak ele almaz. Böylece doğrudan SQL sorgularında oluşabilecek veri bozulması riski azalır.
Yapılan işlemlerin WordPress panelinde görünür kalması da önemli bir avantajdır. Aylar önce hangi alan adının değiştirildiğini hatırlamak veya terminal geçmişi aramak gerekmez. İşlem geçmişi daha sonraki kontroller için açık bir kayıt sunar. Önizleme, veritabanına yazmadan önce kapsamı incelemeyi kolaylaştırır. Deneyimli yöneticiler ise HTTPS geçişi, alan adı değişikliği ve site taşıma gibi tekrar eden işleri daha hızlı tamamlar.
Daha sonra yeni bir değişiklik gerektiğinde önceki işlemi güncel durumla karşılaştırabilirsiniz. Bu kayıt, taşıma sonrasında kalan birkaç eski yolun kaynağını bulurken veya birden fazla yöneticinin alan adı ve HTTPS ayarları üzerinde çalıştığı projelerde özellikle yararlıdır.
Ekip içindeki görev paylaşımı da daha anlaşılır kalır.
- Veritabanına yazmadan önce eşleşmeleri önizleyin.
- Serileştirilmiş WordPress verilerini koruyun.
- Tamamlanan değişiklikleri işlem geçmişinden inceleyin.
- HTTPS, alan adı ve yol değişikliklerini aynı araçla yönetin.
Replace Manager modülünü inceleyinFiyatlandırma ve deneme seçenekleri
Sonuç: HTTPS geçişinde doğru işlem sırası
HTTPS geçişinde en güvenli sıra; sertifikayı ve WordPress adreslerini doğrulamak, yedek almak ve dry run çalıştırmaktır. Ardından serileştirilmiş veriyi koruyan araçla tam URL’yi değiştirin ve yönlendirme, önbellek ile mixed content testlerini tamamlayın.
Taşıma sonrası daha geniş URL değişiklikleri için taşıma sonrası URL arama-değiştirmeve serileştirilmiş veriyi bozmadan arama-değiştirmerehberlerini kullanabilirsiniz.
