HTTP’den HTTPS’ye Geçiş yaparken WordPress adreslerini, kalıcı yönlendirmeleri, eski HTTP bağlantılarını ve mixed content sorunlarını nasıl kontrol edeceğinizi öğrenin.
Siteniz hâlâ http:// ile açılıyorsa mesele yalnızca adres çubuğundaki kilit simgesi değildir. Yönetim girişi, formlar ve ziyaretçiyle sunucu arasındaki veri alışverişi şifreli bağlantı üzerinden yürütülmelidir. HTTP’den HTTPS’ye Geçiş bu nedenle bir WordPress sitesinde yalnızca görsel bir değişiklik değil, URL yapısını ve bağlantı davranışını etkileyen teknik bir taşıma işlemidir.
Geçiş sırasında en sık sorun çıkaran yer ise sertifika kurulumu değil, eski HTTP adreslerinin sitede kalmasıdır. Bir görsel, CSS dosyası veya harici JavaScript hâlâ HTTP üzerinden çağrılıyorsa mixed content uyarıları görülebilir. Ayrıca yönlendirmeler yanlış kurulursa aynı adres birkaç kez başka URL’ye gönderilebilir. Bu yüzden WordPress için HTTP’den HTTPS’ye Geçiş tek bir ayarı değiştirip bırakılacak bir işlem değildir.
HTTPS geçişinden sonra 405 gibi HTTP durum kodlarıyla karşılaşılıyorsa sorunun protokolden mi yoksa sunucunun istek yöntemlerinden mi kaynaklandığını ayırmak gerekir. WordPress Sitenizdeki 405 Yöntem İzin Verilmiyor Hatası Çözümü konusu bu ayrımı anlamak açısından bağlantılıdır. Özellikle taşıma sırasında sunucu kurallarına müdahale edildiğinde farklı HTTP hataları aynı dönemde ortaya çıkabilir.
HTTP’den HTTPS’ye Geçiş WordPress’te nasıl yapılır?
HTTP’den HTTPS’ye Geçiş, geçerli bir SSL/TLS sertifikası kurularak WordPress adreslerinin HTTPS olarak değiştirilmesi, HTTP URL’lerinin kalıcı biçimde HTTPS karşılıklarına yönlendirilmesi ve site içindeki eski bağlantıların güncellenmesiyle yapılır. Ardından mixed content, yönlendirme ve Search Console kontrolleri gerçekleştirilmelidir.
İlk iş sertifikayı doğrulamak olmalı. Alan adınızı https:// ile açtığınızda tarayıcı sertifika hatası göstermemeli. Ana alanın yanında www kullanıyorsanız o sürümü de ayrıca deneyin.
Burada WordPress ayarlarına geçmeden önce HTTPS’in gerçekten sunucu tarafında çalıştığını görmek önemli. Aksi halde WordPress adreslerini HTTPS olarak değiştirdikten sonra yönetim paneline erişmek zorlaşabilir.
WordPress adresleri nereden değiştirilir?
Sertifika sorunsuzsa Ayarlar > Genel bölümündeki WordPress Adresi ve Site Adresi alanları kontrol edilebilir. Her ikisinin de doğru HTTPS adresini göstermesi gerekir.
WordPress çekirdeğinde HTTPS kullanımını denetleyen ve HTTP site adreslerini HTTPS karşılıklarına taşıyabilen fonksiyonlar güncel sürümlerde hâlâ bulunuyor. WordPress, hem home hem de siteurl HTTPS olduğunda siteyi HTTPS kullanıyor kabul ediyor.
Ben geçişlerde özellikle adresin www yapısına dikkat ediyorum. Eski site http://www.site.com iken yeni adres yanlışlıkla https://site.com olarak seçilmişse aynı anda hem protokol hem ana makine adı değişmiş oluyor. Bu da gereksiz yönlendirme zincirlerine yol açabiliyor. Önce hangi adresin asıl sürüm olacağına karar vermek işi belirgin biçimde sadeleştiriyor.
HTTP adresleri HTTPS’e nasıl yönlendirilir?
Eski URL’lerin çalışmaya devam etmesi gerekir, fakat ziyaretçi o adreslerde kalmamalıdır. http://site.com/ornek isteği kalıcı olarak https://site.com/ornek adresine gönderilmelidir.
Google, HTTP’den HTTPS’e geçişi URL değişikliği içeren bir site taşıması olarak değerlendiriyor. Taşınan adreslerde 301 veya diğer kalıcı yönlendirmelerin kullanılmasını öneriyor ve kalıcı yönlendirmelerin PageRank kaybına neden olmadığını açıkça belirtiyor.
Apache kullanılan bir sunucuda yönlendirme .htaccess üzerinden yapılabilir. Nginx ortamında ise sunucu yapılandırması kullanılır. Bazı hosting panelleri HTTPS yönlendirmesini kendi arayüzünden gerçekleştirdiği için aynı kuralı hem panelde hem .htaccess içinde açmak gereksiz yönlendirme oluşturabilir.
HTTP’den HTTPS’ye Geçiş sonrasında eski bir adresi tarayıcıya yazıp sonucu kontrol edin. Mümkünse HTTP adresi tek bir kalıcı yönlendirmeyle doğru HTTPS karşılığına ulaşmalı.
Eski HTTP bağlantıları neden güncellenmeli?
Yönlendirme çalışıyor diye veritabanındaki eski bağlantıları bırakmak iyi fikir değildir.
Yazılarda, görsellerde, tema ayarlarında veya bileşenlerde http://site.com ile başlayan bağlantılar bulunabilir. Bunların HTTPS karşılıklarıyla değiştirilmesi hem gereksiz yönlendirmeleri azaltır hem de mixed content sorunlarının önüne geçer.
WordPress veritabanında toplu değişiklik yapılacaksa önce yedek alınmalı. Arama ve değiştirme işleminin serileştirilmiş WordPress verilerine zarar vermeyen bir yöntemle yapılması gerekir.
Harici kaynakları da unutmayın. Font, analiz kodu, JavaScript kütüphanesi veya CDN adresi HTTP üzerinden geliyorsa tarayıcının Geliştirici Araçları > Console ve Network bölümlerinde bunları görebilirsiniz.
Mixed content varsa neresi kontrol edilmeli?
Sayfa HTTPS açıldığı halde içindeki bir kaynak HTTP üzerinden çağrılıyorsa mixed content oluşur. En sık eski görsel URL’lerinde, tema içindeki sabit adreslerde ve üçüncü taraf betiklerde görülür.
Ben HTTP’den HTTPS’ye Geçiş sonrasında yalnızca ana sayfaya bakmıyorum. Bir yazı, kategori sayfası, iletişim formu ve görsel yoğun bir içerik açıyorum. Sorun bazen ana sayfada hiç görünmezken yıllar önce hazırlanmış bir içerikte kalmış tek HTTP görseli nedeniyle ortaya çıkabiliyor.
CDN kullanılıyorsa onun alan adı da HTTPS üzerinden çalışmalıdır. Site HTTPS, CDN HTTP olduğunda geçiş tamamlanmış sayılmaz.
Search Console tarafında ne yapılmalı?
2026 itibarıyla Google’ın güncel taşıma belgeleri HTTP’den HTTPS’e geçişte yeni HTTPS URL’lerinin izlenmesini ve HTTPS site haritasının gönderilmesini öneriyor. Search Console’daki Change of Address aracı ise HTTP’den HTTPS’e geçiş için kullanılmıyor; bu araç alan adı veya alt alan adı değişiklikleri için tasarlanmış durumda.
URL-prefix mülkleri kullanıyorsanız HTTP ve HTTPS sürümleri ayrı doğrulanabilir. Domain property kullanıldığında ise protokol ve alt alan varyasyonları aynı mülk altında kapsanabilir.
Yeni sitemap HTTPS adreslerini içermeli. Canonical bağlantılar, dahili linkler ve varsa reklam ya da profil bağlantıları da yeni URL’lere çevrilmelidir. Google, taşıma sırasında sıralamalarda geçici hareketlilik olabileceğini ve orta büyüklükte sitelerde URL’lerin yeniden işlenmesinin birkaç hafta sürebileceğini belirtiyor.
Burada panikle tekrar HTTP’ye dönmek genellikle işleri daha karmaşık hale getirir. Yönlendirmeler doğruysa ve HTTPS sayfaları taranabiliyorsa Google yeni adresleri zamanla işler.
HSTS hemen açılmalı mı?
HSTS, tarayıcının alan adına yalnızca HTTPS üzerinden bağlanmasını isteyen ek bir güvenlik politikasıdır. Fakat HTTP’den HTTPS’ye Geçiş yapılır yapılmaz uzun süreli HSTS tanımlamak yerine önce HTTPS yapısının sorunsuz çalıştığından emin olmak daha güvenlidir.
Özellikle alt alanlarınız varsa hepsinin HTTPS desteği kontrol edilmelidir. Geçiş düzgün çalıştıktan sonra HSTS ayrı bir güvenlik adımı olarak değerlendirilebilir.
Sertifika, yönlendirme veya mixed content sorunu teknik inceleme gerektiriyorsa 11858 üzerinden destek alınabilir. 2011 yılından bu yana Türkiye genelinde milyonlarca kullanıcıya 7/24 profesyonel teknik destek sunan 11858, bilgisayar, akıllı TV, sosyal medya ve modem gibi farklı alanlarda hizmet veriyor. Gerektiğinde TeamViewer ve AnyDesk üzerinden lisanslı uzaktan bağlantı sağlanıyor. Hizmet dakika bazlı şeffaf ücretlendirmeyle yürütülüyor; yüzde 95 memnuniyet oranı ve 500.000’den fazla başarılı işlem tecrübesi bulunuyor.
HTTPS tarafı oturduktan sonra sitenin uygulama deneyimini geliştirmek için başka adımlar da değerlendirilebilir. WordPress ile PWA Oluşturma ve Optimize Etme Yöntemleri konusu, WordPress sitesinin tarayıcı ve mobil cihazlarla daha gelişmiş biçimde çalışmasını isteyenler için bağlantılı bir sonraki aşamadır. HTTPS’in düzgün kurulması, bu tür modern web özelliklerinde de önemli bir altyapı noktasıdır.
HTTP’den HTTPS’ye Geçiş sırasında başarı ölçütü yalnızca sitenin başında https:// görmek değildir. Eski bir HTTP bağlantısını açtığınızda doğru adrese gidiyor, sayfada güvensiz kaynak kalmıyor ve Google yeni URL’leri tarayabiliyorsa taşıma gerçekten yerine oturmuştur. Siz geçiş sırasında en çok yönlendirme, mixed content veya sertifika tarafında mı sorun yaşadınız? Yorumlarda paylaşabilirsiniz.
