Yeni sunucuda ana sayfa HTTPS ile açılırken görseller eski HTTP hostundan gelebilir, IPv6 yanlış sertifika sunabilir veya ödeme callback’i eski alanı kullanabilir. Taşıma yalnız dosya ve veritabanını değil, DNS, TLS ve dış entegrasyonları da kapsar.
Eski ortamı geri dönüş için erişilebilir tutun. Yeni hedef bütün kritik yolları geçmeden kalıcı yönlendirmeyi ve DNS geçişini tamamlamayın.
Taşıma HTTPS’yi neden bozar?
Yeni ortamda sertifika doğru virtual hosta atanmalıdır. WordPress home/siteurldeğerleri, veritabanındaki serileştirilmiş URL’ler, oluşturulmuş CSS dosyaları, CDN origin’i ve dış callback’ler eski adresi gösterebilir.
Gerçekçi örnek
A kaydı yeni sunucuya giderken eski AAAA kaydı önceki hostta kalmıştır. IPv4 kullanan ziyaretçi doğru sertifikayı, IPv6 kullanan ziyaretçi eski sertifikayı görür. Aynı anda sayfa oluşturucu CSS’i eski HTTP medya URL’lerini içerir.
Bu iki hata farklı katmanlardadır: DNS ve sertifika sorunu altyapıda, saklanan URL sorunu WordPress verisinde çözülmelidir.
Neden önemlidir?
Eksik taşıma giriş, ödeme, cron, webhook, OAuth ve e-posta bağlantılarını kesebilir. Yalnız ana sayfayı test etmek yeterli değildir; kullanıcı ve sistem akışlarının tamamı yeni kanonik HTTPS adresini kullanmalıdır.
Çözüm adımları
- Eski ve yeni DNS kayıtlarını, TTL’leri ve IPv6 durumunu kaydedin.
- Yeni hostların tamamında geçerli sertifika ve tam zincir kurun.
- WordPress adreslerini tek seferde yeni HTTPS hostuna güncelleyin.
- Serileştirme güvenli araçla eski URL’leri değiştirip oluşturulan CSS/cache dosyalarını yenileyin.
- CDN origin, webhook, OAuth ve ödeme callback adreslerini taşıyın.
- Hedef doğrulandıktan sonra eski hosttan tek kanonik yönlendirme açın.
İleri kontroller
DNS yanıtlarını farklı çözümleyicilerden karşılaştırın. IPv4, IPv6, CDN edge ve origin üzerinden sunulan sertifikaları da ayrı ayrı karşılaştırın. Derin içerik, medya, giriş, REST, form, ödeme, cron, site haritası ve canonical çıktısını sınayın. Eski hostun yalnız beklenen yönlendirmeyi verdiğini ve çerez domaininin doğru olduğunu doğrulayın.
Riskler ve geri alma
Düz SQL ile genel metin değiştirmek serileştirilmiş veriyi bozabilir. Eski siteyi erken kapatmak veya DNS’i hedef testi bitmeden değiştirmek geri dönüşü zorlaştırır. İşlem öncesi veritabanı ve yapılandırma yedeği tutun; kritik akış başarısızsa trafiği eski ortama geri çevirebilin.
AIOWS nasıl yardımcı olur?
AIOWS SSL Yöneticisi
Taşıma sonrasında AIOWS SSL Yöneticisi, yeni ortamda WordPress adreslerinin ve uygulama tarafındaki HTTPS davranışının tutarlı olduğunu denetlemeye yardımcı olur.
Modül DNS, CDN sertifikası veya dış entegrasyonları kendiliğinden taşımaz. Önce yeni genel hostun doğru sertifikayı sunduğunu doğrulayın; ardından WordPress, medya ve callback yollarını ayrı sınayın.
Host uyuşmazlığı, mixed content veya eski callback görülürse yeni yönlendirmeler eklemek yerine ilgili katmanı düzeltin. Eski ortamı ve geri dönüş penceresini bütün kabul testleri tamamlanana kadar koruyun.
AIOWS SSL Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili yazılar
- WordPress Sitesine SSL Nasıl Kurulur?
- WordPress Mixed Content Görsel Hatası Nasıl Çözülür?
- WordPress HTTPS Canonical URL ve Site Haritası Ayarları
Sonuç
Önce yeni hedefte DNS ve TLS’yi doğrulayın, sonra WordPress ile dış entegrasyonları yeni HTTPS adresine hizalayın. Eski ortamı ancak gerçek kullanıcı ve sistem akışları geçtikten sonra kapatın.
