WordPress’te SSL Sertifikası Nasıl Kurulur ve HTTPS’ye Nasıl Geçilir

Bir WordPress sitesine SSL sertifikası yerleştirmek üç adım gerektirir: sertifikayı sunucunuza yüklemek, WordPress’i URL’lerinizin HTTPS sürümlerine yönlendirmek ve eski HTTP trafiğini yeniden yönlendirmek. Çoğu barındırma sağlayıcısı artık ilk adımı sizin için hallediyor ve 5.7 sürümünden bu yana WordPress ikinci adımın büyük bir kısmını kendi başına yönetiyor. Bu rehber, ücretsiz ve ücretli sertifikalar için üç adımı da kapsar ve sonrasında genellikle ortaya çıkan hataları giderir.

Hızlı yanıt: Barındırma kontrol paneliniz üzerinden bir SSL sertifikası yükleyin, ardından WordPress’te Ayarlar > Genel bölümünü açın ve hem WordPress Adresi (URL) hem de Site Adresi (URL) alanlarını https sürümlerine değiştirin. HTTP isteklerinin HTTPS’e ulaşması için bir 301 yönlendirmesi ekleyerek işlemi tamamlayın.

SSL (Secure Sockets Layer’ın kısaltması olsa da, günümüzde verilen her sertifika aslında TLS kullanır), http:// adresini https:// yapan ve adres çubuğundaki “Güvenli Değil” etiketini kaldıran şeydir. Önce arka planı öğrenmek isterseniz, SSL sertifikası nedir yazısını okuyun. Aksi takdirde aşağıdaki tabloyla başlayın.

Hangi yöntem sizin kurulumunuza uyar

WordPress’e SSL eklemenin üç yolu vardır ve doğru olanı neredeyse tamamen barındırmanıza bağlıdır. Kurulumunuzu bulun, ardından ilgili yönteme geçin.

Kurulumunuz	Kullanılacak yöntem	Yaklaşık süre
Yönetilen WordPress barındırma	Kurulacak bir şey yok. Sertifika genellikle zaten etkindir, bu yüzden doğrudan WordPress’i HTTPS’e geçirme adımına atlayın	5 dakika
cPanel veya benzeri bir paylaşımlı barındırma	Yöntem 1, barındırma sağlayıcısının ücretsiz AutoSSL özelliği	10 dakika
SSL aracı olmayan bir barındırma, ya da işlemin sizin için yapılmasını istiyorsanız	Yöntem 2, eklenti sihirbazı	10 ila 15 dakika
VPS, özel sunucu veya ücretli bir sertifika	Yöntem 3, manuel kurulum	30 dakika artı doğrulama süresi
Sitenizin önünde Cloudflare varsa	Yöntem 1 veya 3, ardından Cloudflare SSL ayarını Full (strict) olarak yapın. Sorun giderme bölümüne bakın	15 dakika

Hangi yolu seçerseniz seçin, önce sitenin yedeğini alın ve bir hazırlık (staging) ortamınız varsa, değişikliği canlı ortama dokunmadan önce orada deneyin.

WordPress için SSL sertifikasına ihtiyacınız var mı?

Evet, ve çoğu kişi için sebep zaten görebildikleri şeydir: Chrome, Firefox, Safari ve Edge, adres çubuğunda düz HTTP sayfalarını Güvenli Değil olarak işaretler. Bu etiket, giriş formu da dahil olmak üzere, sertifikası olmayan bir sitenin her sayfasında görünür.

Bunu düzeltmek için üç pratik sebep:

• Kimlik bilgileri ve form verileri açık şekilde iletilir. Bir sertifika olmadan, aynı ağdaki herkes, ziyaretçilerin gönderdiği verileri, hatta kendi WordPress şifreniz dahil, okuyabilir.
• Ödemeler bunu gerektirir. WooCommerce çalıştırıyorsanız ya da herhangi bir kart verisi kabul ediyorsanız, HTTPS isteğe bağlı değildir. Ödeme ağ geçitleri HTTP üzerinden çalışmayı reddedecektir.
• Google, HTTPS’i bir sıralama sinyali olarak kullanır. Gerçek ama hafif bir sinyaldir, bu yüzden SEO argümanını sebep değil ekstra bir kazanç olarak görün. Asıl sebep tarayıcı uyarısıdır.

Bir WordPress sitesi hangi SSL sertifikasını kullanmalı?

Ücretsiz seçenekle başlayın, çünkü WordPress sitelerinin büyük bir kısmı için gerçekten doğru cevap budur. Çoğu barındırma sağlayıcısı otomatik olarak ücretsiz Let’s Encrypt sertifikaları verir ve ücretsiz bir sertifika, ücretli bir sertifika kadar iyi şifreleme sağlar. Şifreleme tamamen aynıdır. Bir WordPress SSL sertifikasını diğerinden farklı kılan şey, sertifika otoritesinin verme öncesinde neyi doğruladığı ve bir sorun çıktığında neye sahip olacağınızdır.

Doğrulama seviyeleri

Tür	CA’nın kontrol ettiği şey	Verilme süresi	Uygun olduğu durum
Domain Validation (DV)	Alan adını kontrol ettiğiniz	Dakikalar içinde	Bloglar, tanıtım siteleri, çoğu WordPress kurulumu
Organization Validation (OV)	Alan adı artı kayıtlı kuruluşunuz	1 ila 3 iş günü	İşletme siteleri, üyelik alanları, müşteri portalları
Extended Validation (EV)	Şirketin tam yasal ve operasyonel kontrolü	1 ila 5 iş günü	Ödeme işleyen mağazalar, finans, kimliğin önemli olduğu her yer

Siteniz alt alan adları üzerinde çalışıyorsa, örneğin store.example.com üzerinde bir mağaza ve blog.example.com üzerinde bir blog varsa, bir joker (wildcard) sertifika hepsini alt alan adı başına tek tek yerine tek bir sertifikayla kapsar. Hangi türün uygun olduğundan emin değil misiniz? SSL Sihirbazı birkaç soruyla bunu belirginleştirir.

Ücretsiz sertifikanın yeterli olmaktan çıktığı durumlar

Ücretsiz sertifikalar yalnızca DV’dir, 90 gün geçerlidir ve destek ya da garanti içermez. Kişisel bir blog için bu sorun değildir. Dört durumda ise sorun haline gelir:

• Ödeme alıyorsanız. Ücretli sertifikalar, sertifikanın kendisi başarısız olduğunda kayıpları karşılayan bir garanti taşır. Ücretsiz olanlarda bu yoktur.
• Ziyaretçilerinizin kim olduğunuzu bilmesi gerekiyorsa. Bir DV sertifikası yalnızca birinin alan adını kontrol ettiğini kanıtlar. OV ve EV, doğrulanmış kuruluş bilgilerinizi sertifikanın içine koyar.
• Alt alan adları çalıştırıyorsanız. Ücretsiz joker sertifika verilmesi mümkün ama uğraştırıcıdır ve genellikle barındırma sağlayıcınızın sunmayabileceği bir DNS otomasyonu gerektirir.
• Yenileme otomatik değilse. Kimsenin yenilemediği 90 günlük bir sertifika, siteyi hiç sertifika olmaması kadar kesin şekilde çökertir. Barındırma sağlayıcınız otomatik yenileme yapmıyorsa, daha uzun süreli ücretli bir sertifika daha az iş demektir, daha fazla değil.

Yöntem 1: Barındırma sağlayıcınızdan ücretsiz SSL sertifikası alın

Bu en hızlı yoldur ve önce denenmesi gereken yöntemdir. Neredeyse her barındırma sağlayıcısı artık ücretsiz Let’s Encrypt sertifikaları sunuyor, genellikle zaten etkinleştirilmiş olarak.

• Barındırma kontrol panelinizi açın ve SSL/TLS, Let’s Encrypt veya AutoSSL’i arayın. cPanel’de bu, Security (Güvenlik) bölümünün altındadır.
• Alan adınızı seçin ve sertifikayı verin. Hem ana alan adını hem de www sürümünü ekleyin, aksi takdirde biri isim uyuşmazlığı uyarısı verecektir.
• Otomatik yenilemenin etkin olduğunu doğrulayın. İnsanların atladığı adım budur.

Kendi VPS’inizi veya özel sunucunuzu çalıştırdığınız için hiç barındırma paneliniz yok mu? Sertifikayı komut satırından veren ve kendi yenileme programını kuran Let’s Encrypt istemcisi Certbot‘u kullanın.

Let’s Encrypt sertifikaları 90 gün geçerlidir ve yenilemenin genellikle son kullanma tarihinden yaklaşık 30 gün önce otomatik olarak gerçekleşmesi beklenir. Bu otomasyon bozulduğunda, ki bu genellikle bir alan adı taşındıktan veya bir DNS kaydı değiştikten sonra olur, site haftalarca sorunsuz kalır ve ardından uyarı vermeden “Güvenli Değil” hale gelir. Beklenen ilk yenileme tarihi için takviminize bir hatırlatma koyun ve bu tarih geçtikten sonra sertifikayı SSL Checker ile kontrol edin. Son kullanma tarihi ileriye taşındıysa, yenileme çalışıyor demektir.

Yöntem 2: WordPress’e bir eklenti ile SSL kurun

Çoğu kişinin başvurduğu eklenti Really Simple Security‘dir. Eylül 2024’e kadar Really Simple SSL olarak adlandırılıyordu; ücretsiz özellik seti SSL kurulumunun ötesine büyüdükçe sürüm 9 ile yeniden adlandırıldı. Üç milyondan fazla etkin kurulumu var.

İsimle birlikte değişen şey burada önemlidir: eklenti artık sadece yönlendirmeyi zorlamıyor, aynı zamanda bir Let’s Encrypt sihirbazı aracılığıyla sertifikayı sizin için de alabiliyor. Yani barındırma sağlayıcınız yapmadığında tüm işi kapsıyor.

• Really Simple Security’yi kurun ve etkinleştirin, bunu Eklentiler > Yeni Eklenti Ekle bölümünden yapın.
• Açılan tanıtım sürecini takip edin ya da eklentinin yönetici kenar çubuğuna eklediği yeni Security öğesine gidin. Daha eski öğreticiler Settings > SSL der, çünkü eklenti isim değişikliğinden önce orada bulunuyordu. Sunucuda zaten bir sertifika kuruluysa, eklenti bunu algılar.
• Sertifika yoksa, Install SSL certificate seçeneğini seçin ve ücretsiz bir Let’s Encrypt sertifikası almak için sihirbazı takip edin.
• Activate SSL seçeneğini seçin. Eklenti, site URL’lerinizi günceller, yönlendirmeyi kurar ve panoyu HTTPS üzerinden yeniden yükler.

Taahhüt etmeden önce bilinmesi gereken bir uyarı: HTTPS’i zorlayan bir eklenti bunu her istekte PHP içinde yapar. Sunucu yapılandırmasına yazılan bir yönlendirme, WordPress yüklenmeden önce gerçekleşir, bu da daha hızlıdır ve eklenti herhangi bir zamanda devre dışı bırakılsa bile çalışmaya devam eder. Sunucu dosyalarını düzenlemekte rahatsanız, geçişi manuel olarak yapın ve eklentiyi kritik yoldan uzak tutun.

Yöntem 3: Bir SSL sertifikasını manuel olarak kurun

Bu, ücretli bir sertifika için ya da tek tıkla kurulum aracı olmayan herhangi bir sunucu için izlenecek yoldur. Paylaşımlı barındırmada, önce planınızın üçüncü taraf sertifikaların kurulmasına izin verdiğini kontrol edin; bazı bütçe dostu barındırma sağlayıcıları bunu hala kısıtlıyor ya da ücretlendiriyor.

• Bir CSR oluşturun. Sertifika imzalama isteği, alan adı ve kuruluş bilgilerinizi sertifika otoritesine iletir. CSR oluşturucumuzu kullanın veya sunucunuza özel CSR rehberlerini takip edin.
• CSR’ı gönderin sertifika otoritesine ve doğrulamayı tamamlayın. DV dakikalar içinde biter, OV ve EV günler alır.
• Dosyaları kurun. Sertifikanın kendisini ve bir veya daha fazla ara sertifikayı alacaksınız. cPanel’de bunları, cPanel kurulum rehberini takip ederek SSL/TLS > Manage SSL sites altına yapıştırın. Diğer platformlar SSL kurulum rehberlerinde anlatılmıştır.
• WordPress’e dokunmadan önce SSL Checker ile doğrulayın.

Ara sertifikalara dikkat edin. Ana sertifikayı kurup zinciri atlarsanız, çoğu masaüstü tarayıcısı yine de bir asma kilit gösterir, çünkü başka bir yerde gördükleri ara sertifikaları önbelleğe alırlar. Mobil tarayıcılar, ödeme ağ geçitleri ve sitenize bir API üzerinden erişen her şey başarısız olur. “Chrome’da çalışıyor ama ödeme sayfasında bozuluyor” olan bir site çoğunlukla eksik bir zincir sorunudur ve SSL Checker bunu bildirecektir.

WordPress Multisite çalıştırmak birkaç ek adım gerektirir, bunlar Multisite SSL rehberinde anlatılmıştır.

WordPress sitenizi HTTP’den HTTPS’e geçirin

Sertifika sunucuda. WordPress bunun farkında değil hala. Bir çok rehber burada önce bir veritabanı arama ve değiştirme işlemi yapmanızı önerir, ancak çoğu site için bu yıllardır gerekli değil.

WordPress’in kendi başına yaptıkları

Mart 2021’de yayınlanan WordPress 5.7‘den bu yana, çekirdek, ortamınızın HTTPS’i destekleyip desteklemediğini algılar ve bunu Araçlar > Site Sağlığı > Durum altında, HTTPS durumu bölümünde bildirir. HTTPS kullanılabilir olduğunda, bu bölüm siteyi tek tıkla geçiren bir düğme sunar.

Daha da önemlisi, Site Adresi (URL) ve WordPress Adresi (URL) her ikisi de https olduğunda, WordPress sayfayı işlerken içeriğinizdeki güvensiz URL’leri yeniden yazar. Kendi alan adınızda http adresleriyle kaydedilmiş resimler, bağlantılar ve gömülü içerikler, veritabanını hiç düzenlemenize gerek kalmadan https üzerinden sunulur. Bu, eski öğreticilerin elle yapmanızı söylediği adımdır.

Kesin olarak anlaşılması gereken bir nokta, çünkü hala yapmanız gerekenleri belirler: yeniden yazma, içerik görüntülenirken içeriğe eklenen filtreler aracılığıyla çıktı üzerinde gerçekleşir. Veritabanınız hala eski http URL’lerini tutar. Ziyaretçiler için sonuç aynıdır, bu yüzden geçiş bir arama ve değiştirme işlemi olmadan çalışır, ama saklanan veri değişmemiştir. Bu, siteyi dışa aktardığınızda, başka bir barındırma sağlayıcısına taşıdığınızda veya doğrudan veritabanını sorguladığınızda önemlidir ve bu yüzden bir arama ve değiştirme işlemini eninde sonunda çalıştırmak, hiç yapmamaktan daha değerlidir.

İki URL ayarını değiştirin

Site Sağlığı tek tıkla düğme sunmuyorsa, ya da bunu açıkça yapmayı tercih ediyorsanız, Ayarlar > Genel‘i açın. İki alan var ve her ikisinin de değişmesi gerekiyor:

• WordPress Adresi (URL), WordPress dosyalarının bulunduğu yer.
• Site Adresi (URL), ziyaretçilerin yazdığı adres.

Her ikisinde de http://‘yi https:// olarak değiştirin, ardından kaydedin. Yalnızca birini değiştirmek, kendinizi panodan kilitleyen en yaygın hatadır. Bu olursa, ikisini de FTP üzerinden wp-config.php‘den ayarlayabilirsiniz:

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

Bu satırları “That’s all, stop editing” yazan satırın üzerine ekleyin ve example.com’u kendi alan adınızla değiştirin. Bu sabitler tanımlıyken, Settings > General bölümündeki alanların salt okunur hale geleceğini unutmayın.

Hala arama ve değiştirme yapmanız gereken durumlar

Çekirdeğin yeniden yazması işlenmiş içeriği kapsar. Her yere ulaşmaz, bu yüzden bir arama ve değiştirme hala şunlar için çözümdür:

• Tema dosyalarında veya functions.php‘de sabit kodlanmış URL’ler.
• Serileştirilmiş veri olarak saklanan eklenti ayarları, bu yüzden hiçbir zaman düz bir SQL arama ve değiştirme işlemi çalıştırmamalısınız.
• Sayfa oluşturucuların yazdığı seçenek satırları, özel alanlar ve widget içeriği.

Serileştirilmiş verileri doğru şekilde işleyen ve deneme çalıştırma (dry-run) modu bulunan Better Search Replace‘i ya da WP-CLI’yi kullanın:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

Deneme çalıştırma çıktısını okuyun, ardından uygulamak için komutu –dry-run olmadan tekrarlayın. Önce veritabanını yedekleyin.

WordPress’te 301 yönlendirme ile HTTPS’i zorunlu kılın

Siteniz artık https üzerinden yanıt veriyor, ama hala http üzerinden de yanıt veriyor ve her eski bağlantı ile yer imi oraya işaret ediyor. Kalıcı bir HTTPS yönlendirmesi hem ziyaretçileri hem de arama motorlarını güvenli sürüme gönderir ve eski URL’lerin sıralama sinyallerini aktarır. Mümkün olduğunda bunu PHP yerine sunucu seviyesinde ayarlayın.

Apache

WordPress kök dizininizdeki .htaccess dosyasının en üstüne, WordPress bloğunun üzerine şunu ekleyin:

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

Bunu kalıcı yapan şey R=301 bayrağıdır. [R,L] olarak yazılan bir kural bunun yerine geçici bir 302 verir, bu da eski bir rehberden bir yönlendirme kopyaladıysanız kontrol etmeye değer bir hatadır.

Nginx

Nginx’in .htaccess dosyası yoktur ve Apache için yazılmış yeniden yazma kurallarını anlamaz. Bunun yerine site yapılandırmanızdaki sunucu bloğunu düzenleyin:

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

Yapılandırmayı nginx -t ile test edin, ardından systemctl reload nginx ile yeniden yükleyin.

HTTPS’i yalnızca pano için zorunlu kılın

Özellikle giriş işlemlerini ve yönetim alanını güvence altına almak için bunu wp-config.php‘ye ekleyin:

define( 'FORCE_SSL_ADMIN', true );

Bu, wp-admin ve giriş sayfasını kapsar. Ön yüzü yönlendirmez, bu yüzden sunucu seviyesindeki bir yönlendirmenin yerine geçmek yerine onu tamamlar.

Her şey çalıştığında HSTS

HSTS, tarayıcılara alan adınız için düz HTTP’yi tamamen reddetmelerini söyler; bu da ilk istek ile yönlendirme arasındaki boşluğu kapatır. Apache’de:

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

Bunu yalnızca HTTPS bir süredir kararlı olduktan sonra ekleyin ve preload direktifini başlangıçta kapalı bırakın. Preload etmek hızlıca geri almak zordur ve bir alt alan adında henüz HTTPS’e geçmemiş bir şey varsa, o alan adı erişilemez hale gelir.

Geçişin arkasında bıraktığı sorunları giderin

Karma içerik (Mixed content)

Karma içerik, HTTPS üzerinden sunulan ama hala resim, betik, stil sayfası ya da yazı tipini HTTP üzerinden çeken bir sayfadır. Tarayıcılar artık bunu ikiye ayırıyor: yükseltilebilir kaynaklar, çoğunlukla resimler ve medya, bunları istek göndermeden önce sessizce HTTPS’e yükseltirler, ve betikler ile stil sayfaları gibi engellenebilir kaynaklar ise hiç yüklenmez. Bu yüzden karma içerikli bir sayfa yalnızca kilitsiz görünebilir, ya da tamamen stilsiz gelebilir.

WordPress’te olağan kaynaklar bir tema dosyasında sabit kodlanmış bir resim URL’si, HTTP üzerinden yüklenen harici bir betik ve hala HTTP için yapılandırılmış bir CDN’dir. Sorunlu kaynağı adlandıran tarayıcı konsolunu açın ve kaynağında düzeltin. Karma içeriği nasıl düzeltirsiniz rehberimiz teşhisi ayrıntılı olarak kapsar.

Önbellekler ve CDN

Geçişten sonra sayfa önbelleğinizi ve CDN’inizi temizleyin. Bir HTTP sayfasının önbelleğe alınmış bir kopyası eski işaretlemeyi sunmaya devam eder ve tamamlanmış bir geçişin bozuk görünmesine yol açar.

E-postalar ve işlemsel şablonlar

Bu neredeyse herkesin gözden kaçırdığı bir şeydir. WooCommerce sipariş e-postaları, şifre sıfırlama mesajları, fatura şablonları ve bülten alt bilgileri genellikle sabit kodlanmış HTTP bağlantıları taşır ve bunlar normal bir arama ve değiştirmenin dokunduğu tabloların dışında yer alır. Kendinize bir test siparişi ve bir test şifre sıfırlama gönderin, ardından bağlantıların gerçekte nereye işaret ettiğini kontrol edin.

WordPress SSL sorunlarını giderme

Belirti	Olağan sebep	Çözüm
Sonu gelmeyen yönlendirme döngüsü, ERR_TOO_MANY_REDIRECTS	Cloudflare SSL ayarı Flexible olarak ayarlanmış. Cloudflare sunucunuzla HTTP üzerinden konuşur, sunucunuz HTTPS’e yönlendirir, Cloudflare geri gönderir	Cloudflare SSL/TLS şifreleme modunu Full (strict) olarak ayarlayın ve kaynak sunucuda geçerli bir sertifika bulundurun
Geçişten sonra wp-admin’e giriş kilitlendi	İki URL alanından yalnızca biri değiştirildi	WP_HOME ve WP_SITEURL’ü FTP üzerinden wp-config.php‘de ayarlayın
Yalnızca bazı sayfalarda asma kilit yok	O sayfalarda karma içerik	Tarayıcı konsolunda HTTP kaynağını bulun, kaynağında düzeltin
Site sorunsuzdu, haftalar sonra “Güvenli Değil” oldu	Yenileme bozulduğu için bir Let’s Encrypt sertifikası süresi doldu	Yeniden verin, ardından kontrol panelinizde otomatik yenilemeyi doğrulayın
Tarayıcıda çalışıyor ama bir uygulama ya da ödeme ağ geçidi için başarısız oluyor	Zincirde ara sertifikalar eksik	Tam CA paketini kurun, ardından SSL Checker ile yeniden kontrol edin
www veya ana alan adında isim uyuşmazlığı uyarısı	Sertifika ikisinden yalnızca birini kapsıyor	Sertifikayı her iki adı da kapsayacak şekilde yeniden verin; tek başına bir yönlendirme bunu düzeltemez, uyarı herhangi bir yönlendirme çalışmadan önce ortaya çıkar

Sertifika kuruluysa ve site hala güvensiz olarak bildiriliyorsa, SSL hata rehberleri belirli tarayıcı hata kodlarını kapsar.

Geçiş sonrasında: SEO kontrol listesi ve beklenecekler

• Google Search Console’a HTTPS özelliğini ekleyin. Bir HTTP özelliği HTTPS URL’leri hakkında rapor vermez. Yenisini ekleyin ve eskisini de tutun, ya da her ikisini de kapsayan bir Domain özelliği kullanın. Bing Webmaster Tools kullanıyorsanız, orayı da güncelleyin.
• XML site haritanızı https URL’leriyle yeniden gönderin.
• Canonical etiketlerini kontrol edin https’e işaret ettiklerinden emin olun. Çoğu SEO eklentisi site URL’leri değiştiğinde otomatik olarak güncellenir, ama bunu sayfa kaynağında doğrulayın.
• Google Analytics ve Ads özellik ayarlarını ve site URL’nizi saklayan herhangi bir üçüncü taraf hizmeti güncelleyin.
• Dahili bağlantıları güncelleyin, mutlak (absolute) olanları. Göreceli (relative) bağlantıların herhangi bir şeye ihtiyacı yoktur.

Bunu daha önce hiç yapmamış olan insanları endişelendiren, sonrasında normal olan şey şudur: Google yeniden taradığı sürece Search Console bir süre gösterimlerinizi HTTP ve HTTPS özellikleri arasında bölünmüş olarak gösterecek ve sıralamalar genellikle birkaç hafta boyunca oturana kadar hareket eder. Google, bir HTTP’den HTTPS’e geçişi URL değişiklikleri olan bir site taşıması olarak ele alır, bu yüzden bir miktar dalgalanma bir şeylerin bozulduğunun işareti değil, beklenen bir şeydir. 301 yönlendirmeleri yerinde olduğu ve her sayfa çözüldüğü sürece, beklemekten başka yapılacak bir şey yoktur.

Açıkça söylenmesi gereken bir şey var: HTTPS’ten HTTP’ye geri dönmek, bir sorun için neredeyse hiçbir zaman doğru çözüm değildir. Bu, ikinci bir site taşıması, başka bir sıralama karışıklığı turu demektir ve tarayıcı uyarıları geri döner. HTTPS sorun yaratıyorsa, sebep neredeyse her zaman sorun giderme tablosundaki maddelerden biridir ve onu düzeltmek, geçişi tersine çevirmekten çok daha ucuzdur.

Sıkça Sorulan Sorular

Farklı bir platformu HTTPS’e mi taşıyorsunuz, ya da genel prosedürü mü istiyorsunuz? Bir siteyi HTTP’den HTTPS’e nasıl geçirirsiniz rehberimize bakın.