Taşıma Sonrası WordPress URL’lerinde Arama ve Değiştirme Nasıl Yapılır?

Site yeni alan adında açılırken görseller, menüler veya sayfa oluşturucu ayarları hâlâ deneme ortamını gösterebilir. Eski host adını veritabanının tamamında körlemesine değiştirmek ise GUID değerlerine, dış bağlantılara, lisans ayarlarına veya başka bir multisite sitesine zarar verebilir.

Önce eski adresin nerelerde ve hangi amaçla tutulduğunu belirleyin. Ardından serileştirilmiş veriyi anlayan bir araçla önizleme yapın, gerekli tabloları seçin ve yeni siteyi gerçek kullanıcı akışlarıyla doğrulayın.

Taşıma sonrası URL değişikliği nedir?

Taşıma sonrası URL değişikliği, eski site adresine ait veritabanı kayıtlarını yeni adresle günceller. Bu değerler düz metinde, JSON içinde, blok işaretlemesinde veya PHP ile serileştirilmiş eklenti ve tema ayarlarında bulunabilir. Kullanılan araç veri biçimini korumalı ve yalnız doğrulanmış site adreslerini değiştirmelidir.

• Eski host adının geçtiği tablo ve sütunları önizleme raporunda ayrı ayrı inceleyin.
• İç bağlantıları; GUID, e-posta adresi, dış servis URL'si, lisans endpoint'i ve tarihî kayıtlardan ayırın.
• Önizleme ile gerçek işlem sayıları uyuşmazsa veya düzenleyici, giriş ya da entegrasyonlar bozulursa işlemi durdurun.

Gerçekçi bir WordPress örneği

Bir ajans, staging ortamını yeni alan adına taşıdıktan sonra içerikte ve sayfa oluşturucu ayarlarında eski host adını buluyor. Önizleme raporu eşleşmelerin büyük bölümünün yazı içeriği ve tema ayarlarında, küçük bir bölümünün ise dış callback adreslerinde olduğunu gösteriyor. Ekip yalnız iç site URL'lerini seçip callback ve GUID alanlarını dışarıda bırakıyor. Değişiklikten sonra editör, form, giriş, medya ve yönlendirmeler yeni sitede ayrı ayrı sınanıyor.

Neden önemlidir ve ne zaman kullanılır?

Bu işlem alan adı değişikliği, staging ortamından canlıya geçiş veya dizin yapısının yenilenmesi sonrasında gerekir. Yeni DNS ve TLS yapılandırması hazır olmadan, eski-yeni eşlemesi kesinleşmeden ve geri yüklenebilir veritabanı yedeği alınmadan değişiklik yapmayın.

Eski URL'nin sayfada görünmesi her zaman veritabanı kaydından kaynaklanmaz; değer tema dosyasında, CDN ayarında veya dış hizmette olabilir. Önce kaynağı bulun. Veritabanı değişikliğinden sonra kalan eşleşmeleri yeniden sayın; temsili sayfaları, blok ve sayfa oluşturucu editörlerini, formları, girişi, webhook'ları, zamanlanmış görevleri ve canonical etiketlerini kontrol edin.

Yeni başlayanlar için güvenli yöntem

1. Geri yüklenebilir bir veritabanı yedeği alın ve işlem sırasında yeni içerik girişini mümkünse durdurun.
2. Eski ve yeni URL'yi protokol, www kullanımı, eğik çizgi ve harf durumu dahil tam olarak yazın.
3. Serileştirilmiş veriyi destekleyen araçla yalnız seçilen tablolarda dry run çalıştırın.
4. Her veri türünden örnek eşleşmeleri inceleyin; GUID, dış bağlantı, e-posta ve entegrasyon adreslerini dışarıda bırakın.
5. İşlemi uyguladıktan sonra eşleşme sayılarını karşılaştırın ve etkilenmesi gereken bir kullanıcı akışıyla etkilenmemesi gereken kontrol akışını birlikte test edin.

İleri teknik yöntem

Multisite, özel tablo veya kodlanmış URL kullanan kurulumlarda kapsamı tablo ve sütun düzeyinde belirleyin. WP-CLI bağlamını, veritabanı öneklerini, alan ya da dizin tabanlı ağ yapısını ve eklentinin serileştirme biçimini gerçek veride doğrulayın.

• Değiştirilecek birincil anahtarları veya önizleme raporunu sabitleyin; işlem sırasında değişen veri kümesine dayanmayın.
• Normal metin ve serileştirilmiş ayarlardan örnekleri işlem öncesi ve sonrası karşılaştırın.
• Eski host adına gelen istekleri loglardan izleyerek veritabanı dışında kalan kaynakları bulun.
• Yedeği, kullanılan eski-yeni değerleri, dahil edilen ve dışlanan tabloları, eşleşme sayılarını ve test sonucunu bakım kaydına ekleyin.

Riskler, sık hatalar, yedek ve geri dönüş

En büyük risk, doğru görünen geniş bir arama-değiştirme işleminin başka alan adlarını, GUID değerlerini, imzalı callback'leri veya serileştirilmiş ayarları bozmasıdır.

• Yalnız httpya da host adının bir bölümünü aramayın; eski tam URL'yi kullanın.
• Multisite alt sitelerini, özel eklenti tablolarını ve dış servis adreslerini açıkça değerlendirin.
• Önizleme raporunu incelemeden gerçek işlemi başlatmayın.
• Sorun görülürse yeni yazıları durdurun ve doğrulanmış yedeği geri yükleyin; ters arama-değiştirmeyi ancak kapsam eksiksiz kaydedilmişse kullanın.

Giriş, düzenleyici veya entegrasyonlarda beklenmeyen bir değişiklik görülürse siteyi kullanıma açmayın. Önceki veritabanını geri yükleyip kapsamı daraltarak yeniden önizleme yapın.

İlgili AIOWS yazıları

• WordPress’teki HTTP Adresleri HTTPS’ye Güvenle Nasıl Çevrilir?
• Serileştirilmiş Veriyi Bozmadan WordPress’te Arama ve Değiştirme
• WordPress Alan Adı Veritabanında Nasıl Değiştirilir?

Sonuç ve önerilen yol

Önce eski URL'lerin tablo ve sütunlara göre envanterini çıkarın. Serileştirilmiş veriyi destekleyen bir araçla dry run yapın, dış bağlantıları ve tarihî kayıtları ayırın, ardından tek ve sınırlı bir işlem uygulayın. Eski ortamı yeni site ile entegrasyonlar doğrulanana kadar erişilebilir tutun.

Resmî kaynaklar

• WordPress site taşıma rehberi
• WP-CLI search-replace komutu