Trafik kaybetmeden WordPress'ten headless CMS'e geçiş
Bir WXR dışa aktarımı, uyuşmayan bir içerik modeli ve taşınmayacak eklenti mantığı. Geçiş yolu adım adım — nelerin bozulduğu dahil.
Bu makale kararın verildiğini varsayar. Konu, bunu uçurum şeklinde bir trafik grafiğiyle uyanmadan yapmaktır.
Bunu her şeyden önce yapın, çünkü geçişlerin gerçek bütçesini belirlediği yer burasıdır.
Eklenti listesini gözden geçirin ve her birini üç kovadan birine ayırın:
| Kova | Örnek | Taşınır mı? |
|---|---|---|
| İçerik saklar | Advanced Custom Fields, özel yazı tipleri | Evet — dışa aktarımda yer alır |
| İçeriği dönüştürür | Kısa kodlar, sayfa oluşturucular, ilgili-yazı blokları | Kısmen — çıktı gövdededir, mantık değildir |
| Davranış sağlar | Formlar, rezervasyonlar, üyelikler, e-ticaret, önbellekleme | Hayır — yeniden inşa edin veya değiştirin |
Üçüncü kova projenin kendisidir. Bir form eklentisi bir form servisine dönüşür. Bir üyelik eklentisi, ön yüzünüzde auth artı erişim sınırlamasına dönüşür. Bunu kimse dışa aktarmaz ve geçişlerin uzamasının nedeni budur.
İkinci kovanın belirli bir tuzağı var: sayfa oluşturucular. Yazılarınız Elementor, WPBakery veya benzeriyle oluşturulduysa, dışa aktarılan gövde temiz HTML değil, bir kısa kod ve sarıcı işaretleme çorbasıdır. Onu temizlemeyi ya da etkilenen sayfaları elle yeniden yazmayı planlayın. Onları şimdiden sayın.
Tools → Export → All content bir WXR dosyası üretir: yazılar, sayfalar, özel yazı tipleri, taksonomiler, yorumlar ve medyaya referanslar içeren XML.
Referanslar, dosyalar değil. Görseller hâlâ wp-content/uploads içinde durur ve ayrıca taşınması gerekir.
Dosyaya güvenmeden önce kontrol edilmeye değer iki şey:
wp_posts ile karşılaştırın.İçgüdü, içe aktarıp sonra toparlamaktır. Tam tersini yapın.
Sekiz özel alanı olan bir WordPress yazısı, yapılandırılmış bir CMS'te genellikle iki veya üç düzgün tiptir. Bu biçimi içe aktarmadan önce belirleyin, aksi hâlde WordPress'in modelini, kaçmak için özellikle seçtiğiniz bir sisteme taşırsınız.
corpusctl'de yerleşik içerik tipleri yoktur; onları panelden veya API'den tanımlarsınız ve alanlar roller taşır — title, slug, body. Rol, sistemin siz onu nasıl adlandırdığınızdan bağımsız olarak hangi alanın başlık olduğunu bilme biçimidir; okuma süresi ve içindekiler tablosu gibi hesaplanan alanları yapılandırma olmadan çalıştıran da budur.
Tipik bir eşleme:
| WordPress | Şuna dönüşür |
|---|---|
| Yazı başlığı | title rolüne sahip alan |
| Yazı slug'ı | slug rolüne sahip alan |
| Yazı içeriği | body rolüne sahip alan, bloklar |
| Öne çıkan görsel | medya referansı |
| Kategoriler, etiketler | taksonomi ilişkisi veya bir tags alanı |
| Yazar | ilişkiyle ayrı bir author tipi |
| ACF alan grubu | kendi alanları veya iç içe bir nesne |
Yerelleştirme bir alan özelliğidir, ayrı bir site değil. WPML veya Polylang çalıştırıyordunuzsa, bu yapının basitleştiği adım budur.
corpusctl'in içe aktarıcı modülü WXR'ı okur ve bir deneme (dry-run) modu vardır: hiçbir şey yazmadan bir plan üretir.
Yanıt, oluşturacağı girdileri, ayrıca her biri için bir gerekçeyle skipped ve warnings içerir. İkisini de okuyun. Sessiz atlama, ikinci ayda 400 yazının hiç gelmediğini böyle keşfedersiniz.
İçe aktarma limitleri bir nedenle vardır — ayrıştırıcı, DOCTYPE/ENTITY bildirimleri içeren XML'i doğrudan reddeder, çünkü XML-bombası vektörü budur ve boyut tavanının üzerindeki dosyalar belleğe akıtılmak yerine reddedilir. Dışa aktarımınız ikisinden birine takılıyorsa, onu bölün.
Sonra gerçekten çalıştırın ve sayıları uzlaştırın: giren yazılar, çıkan yazılar, tip bazında.
Bu en büyük görevdir ve normal bir web projesidir, dolayısıyla geçişe özgü tek tavsiye URL'lerle ilgilidir.
Mümkünse URL yapısını koruyun. Koruduğunuz her URL, yazmak zorunda kalmadığınız bir yönlendirme ve aktarmak zorunda kalmadığınız bir sıralama sinyalidir. Mevcut yapı /2019/03/some-post/ ise ve ondan nefret ediyorsanız, onu değiştirmek ayrı bir projedir — bir URL yeniden yapılandırmasını bir CMS geçişine dahil etmeyin. İkisi de ters giderse hangisinin neden olduğunu bilemezsiniz.
Okuma tarafında, corpusctl'in istemcisi bir API çağırmaz: yayınlanan içerik yayın anında değişmez, hash ile adreslenen bir dosyaya yazılır ve istemci slug'ı yerel olarak bir manifest parçasına çözer, ardından o adresi nginx kenar önbelleğinden çeker. İki istek, ikisi de önbelleğe alınabilir, hiçbiri veritabanına dokunmaz.
Blok render'ıcıları sıfır varsayılan stil ile gelir, dolayısıyla tasarım işiniz sizin tasarım işinizdir — CMS, tartışacak hiçbir CSS katmaz.
Her eski URL'nin yeni evine bir 301'e ihtiyacı var. İnsanların yazdığı liste:
Unuttukları liste:
/some-post/image-name/) — WordPress her medya öğesi için bir tane üretir ve Google bunları dizine ekledi/feed/, /comments/feed/, kategori bazında beslemeler/page/2/, /page/3/ …?p=123 ve ?page_id=123 sorgu dizesi biçimleriURL listesini site haritasından değil Search Console'dan (Pages raporu) dışa aktarın. Site haritası yayınlamayı amaçladığınız şeydir; Search Console ise Google'ın gerçekte bulduğu şeydir.
Düşük trafikli bir saatte canlıya geçin, ardından iki hafta izleyin:
Search Console — 404'lerde bir sıçrama veya "haricî" (excluded) sayfalar için Coverage; bir şablonun diğerlerinden daha çok kaybedip kaybetmediğini görmek için sayfa tipine göre segmentlenmiş Performance.
Sunucu günlükleri — tarama günlüğü, Googlebot'un neye vurduğunu ve ne aldığını söyler. Günlükteki bir 404, kaçırdığınız bir yönlendirmedir ve onu aynı gün düzeltmek hiçbir şeye mal olmazken bir ay sonra düzeltmek sıralamaya mal olur.
Core Web Vitals — laboratuvar skorları değil, saha verisi. Bir headless geçişinin gerçek bir iyileşme gösterdiği yer genellikle burasıdır, çünkü önbellekten servis edilen önceden inşa edilmiş içeriğin arkasına saklanacağı yavaş bir origin yoktur.
WordPress kurulumunu en az bir ay silmeyin. Onu çalışır durumda, bağlantısız ve noindex tutun; böylece bir sayfanın eskiden nasıl göründüğünü kontrol edebilirsiniz.
Editörler önizlemeden şikayet edecek. WordPress, CMS'in içinde önizleme yapar. Headless önizleme, taslak modu aracılığıyla ön yüzünüzden geçer ve bunu geçişten önce bağlamadıysanız, editör ekibi ilk gün fark eder. Önce onu bağlayın. (corpusctl'in taslak modu yardımcısı, secret'ı sabit zamanlı bir karşılaştırmayla doğrular ve onaylanmış göreli bir yol olmayan herhangi bir slug'ı reddeder; bu da elle yazılmış çoğu önizleme uç noktasının sahip olduğu açık-yönlendirme (open-redirect) açığını kapatır.)
Kısa kodlar artık bırakır. Bir eklentinin render ettiği her şey, içe aktarılan gövdede ham metin olarak görünür. İçe aktarmadan sonra korpusta [ karakterini grep'leyin.
Yorumlar. WXR onları dışa aktarır; çoğu headless CMS'in onları koyacak yeri yoktur. Yorumlar önemliyse, geçişten sonra değil önce bir üçüncü taraf servisi planlayın.
İlk ay daha yavaştır. İnsanlar on yıl sonra WordPress'te her şeyin nerede olduğunu bilir. Bunun için bütçe ayırın ve aynı hafta bir lansman planlamayın.