HubSpot’tan WordPress’e: CMS’i Diğer Her Şeyden Ayıklamak

🇬🇧 English: Read this article in English →

Bu serideki her geçiş şimdiye kadar düz bir takastı: bir içerik sistemi yerine bir başkası. HubSpot farklı; ve bu farkı gözden kaçırırsan projeyi baştan yanlış kapsamlandırırsın.

HubSpot aslında bir CMS değil. Bir paket — CMS Hub, artı bir CRM, artı pazarlama otomasyonu, artı e-posta, artı formlar, artı analytics; hepsi tek bir platformda, her şeyin diğer her şeyden haberdar olduğu bir bütün halinde eritilmiş. Biri “HubSpot’tan WordPress’e geçmek istiyoruz” dediğinde, neredeyse her zaman kastettiği şey “web sitesini HubSpot’tan çıkarmak istiyoruz” olur. Paketin geri kalanı — özellikle CRM — ayrı bir mesele; ve çoğu zaman cevabı “olduğu yerde bırak ve entegre et” olur.

Yani bu geçiş, diğerlerinin sormadığı bir soruyla başlar: sen aslında neyi taşıyorsun ve ne kalıyor? Bunu yanlış anla; ya çalışan bir CRM’i sebepsiz yere söküp atarsın ya da bir web sitesini taşırken bir zamanlar satışı besleyen her formu sessizce bozarsın. Meseleyi açık açık ortaya koyayım, sonra sona doğru teknik kısma gireyim.

Ekipler siteyi HubSpot CMS’ten neden taşıyor

• Maliyet katmanları. HubSpot’un fiyatı; koltuk, contact ve daha üst CMS katmanları ekledikçe dik bir eğimle tırmanır. Özellikle web sitesi tarafı için, WordPress barındırması yanında yuvarlama hatası kadar kalır.
• Esneklik ve sahiplik. HubSpot’un CMS’i kapalı, barındırılan bir sistem. HubL ve onun modül modeli içinde, onların altyapısında, onların kurallarıyla inşa edersin. WordPress ise sana kodu, barındırma seçimini ve plugin ekosistemini verir.
• Çıkış sorusu. Her seferinde gündeme getirdiğim şey bu. HubSpot, yol haritasını ve fiyatını senin kontrol etmediğin tek bir satıcı. WordPress satın alınamaz ve kimse sahibi değil. İçerik sitesi için bu fark, on yıllık bir ufukta önemlidir.
• Tanıdık bir yığında birleşmek. Zaten başka WordPress mülkleri işleten ekipler tek bir platform, tek bir beceri seti, tek bir tedarikçi kümesi ister.

Paketleşme hikâyesi, deneyimden

Yıllar önce bir ürün yaptık ve o ürün hiç niyetlenmediğimiz bir şeye dönüştü. Bir CD-ROM’a on bin web adresi koyduk — basit bir dizin. Müthiş sattı ve sonra şirketler sormaya başladı: “logomuz şu kategorinin altına girebilir mi? İlk sırada listelenebilir miyiz?” Yazılımımızın içinde reklam diye bir şeyi hiç düşünmemiştik. Evet dedik ve ürünümüz kazara bir medya platformuna dönüştü. Tek bir şey, sessizce beşe döndü.

HubSpot tam olarak bu; ama bilerek ve iyi yapılmış hali: aynı zamanda bir CRM olan, aynı zamanda bir pazarlama platformu olan bir CMS. Ve tıpkı bizim kazara medya platformumuz gibi, parçalar birbirine dolanır — web sitesinin formları CRM’i besler, CRM segmentleri sitedeki smart content’i sürer, analytics hepsini birbirine bağlar. HubSpot’tan çıkmanın asıl marifeti, bu iplikleri bilinçli olarak çözmektir — hangisini keseceğine, hangisini bir entegrasyon olarak tutacağına karar vermektir. Bunu tek parça, yekpare bir hamle gibi ele alma. Bir paketi yeniden parçalarına ayırmak ve yalnızca WordPress’e ait olan parçaları tutmak gibi ele al.

Alışıldık tavsiyem şu: web sitesi çoğu zaman WordPress’e aittir. CRM ise çoğu zaman hiç taşınmaya ihtiyaç duymaz — HubSpot CRM’i tut (ya da ileride, kendi projesi olarak, ayrı bir CRM’e geç) ve onu yeni WordPress sitesiyle entegre et. CRM geçişini web sitesi geçişinin içine zorla sokmak, bu projelerin şişip başarısız olmasının yoludur.

Bir HubSpot site geçişini nasıl planlıyorum

1. Önce sınırı çiz — tam olarak neyin taşınacağına (sayfalar, blog, HubDB, formlar) ve neyin kalacağına (CRM, pazarlama otomasyonu, e-posta) ve kalan parçaların WordPress ile nasıl entegre olacağına karar ver.
2. Sayfaları, blog yazılarını, HubDB tablolarını, modülleri, formları, CTA’ları ve smart-content kurallarını envanterle.
3. Taşımaya değmeyeni buda.
4. WordPress’e eşle — sayfa/blog’u sayfalara ve postlara, HubDB’yi custom post type’lara ya da custom tablolara, modülleri bloklara, formları bir WordPress form plugin’ine, smart content’i bir kişiselleştirme yaklaşımına.
5. Boş hedefi kur ve editörlerle, pazarlamayla doğrula.
6. Taşı, staging’de kuru koşu yap, tekrarla.
7. Cutover’dan önce yönlendirmeler (redirect), sonra izle — özellikle form gönderimleri ve tracking.

Teknik Kısım: HubSpot Geçişi Asıl Nerede Kırılıyor

Sonucu belirleyen ayrıntılar.

İlk gerçek problem: veriyi çıkarmak

HubSpot, siteni yeniden inşa edecek temiz ve eksiksiz bir “her şeyi dışa aktar” seçeneği sunmaz. Sayfalar ve blog yazıları CMS/Blog API’leri üzerinden çekilebilir; yapılandırılmış veri HubDB‘de yaşar ve HubDB API‘si üzerinden çıkar; formlar ve alanları Forms API üzerinden gelir. Siteyi birkaç API kaynağından, üstüne yer yer render edilmiş sayfaları scrape ederek toparlamayı bekle. Her zamanki gibi: her kaynağın anlık kopyasını (snapshot) bir dosyaya al, sayfalama (pagination) sınırlarına saygı göster, toplamları karşılaştır ve dönüşümü canlı üzerinde değil, o donmuş kopya üzerinde yap.

HubL modülleri çevrilmez

HubSpot sayfaları, HubSpot şablonlarında dizilmiş, HubL (HubSpot’un şablonlama dili) ile yazılmış modüllerden kurulur. Bu, taşınabilir içerik değil; sunum ve mantıktır — hiçbiri WordPress’e geçmez. Her modül; bir Gutenberg bloğu, pattern ya da tema bileşeni olarak yeniden inşa edilmek zorundadır ve her modül örneğinin içindeki içeriğin çıkarılıp WordPress’teki karşılığına yeniden yerleştirilmesi gerekir. Her modül türünü envanterle ve bunu sonradan akla gelen bir iş olarak değil, işin çekirdek yeniden-inşa kısmı olarak ele al.

HubDB, kılık değiştirmiş ilişkisel içeriktir

HubDB, HubSpot’un ilişkisel tablo özelliğidir — ekipler bunu konum dizinleri, ürün katalogları ve kaynak listeleri gibi şeyler için kullanır ve çoğu zaman dinamik sayfaları besler. Bu gerçek anlamda yapılandırılmış içeriktir ve ACF alanlarıyla birlikte WordPress custom post type’larına (ya da custom tablolara) doğal biçimde eşlenir. Ama HubDB’nin ürettiği dinamik sayfalar — satır başına bir sayfa, şablonlanmış düzenlerle — bir WordPress archive/single-template kurulumu olarak yeniden inşa edilmek zorundadır. Tabloyu bir CPT’ye, sütunları alanlara, dinamik sayfa şablonunu bir WordPress şablonuna eşle. Ve satırlar birbirine referans veriyorsa, iki geçişli (two-pass) bir import sırasında HubDB satır ID’lerini koru.

Formlar CRM’e bağlı — asıl tuzak burası

HubSpot formları sadece veri toplamaz; doğrudan HubSpot CRM’e gönderim yapar ve workflow’ları tetikleyebilir. Formları WordPress’te (Gravity Forms, Fluent Forms veya benzeri) yeniden kurduğunda, gönderimlere ne olacağına karar vermek zorundasın. CRM kalıyorsa, yeni formların gönderimleri Forms API ya da bir entegrasyon üzerinden HubSpot’a geri itmesi gerekir; yoksa satış ekibinin dayandığı lead akışını sessizce bozarsın. Gözden kaçırılabilecek en tehlikeli şey tam da bu: taşınmış gibi görünen ama artık satışı beslemeyen bir web sitesi. Cutover’dan önce her formu gideceği yere eşle ve gerçek bir gönderimi baştan sona test et.

Smart content ve kişiselleştirme

HubSpot’un smart content‘i; CRM verisine, yaşam döngüsü aşamasına (lifecycle stage) ya da cihaza göre farklı segmentlere farklı içerik gösterir. WordPress’in native bir karşılığı yok. Her smart kural için karar ver: (tutulan) HubSpot verisiyle beslenen bir WordPress kişiselleştirme plugin’ine mi dönüşecek, cihaz/oturum-açmış koşullarına mı sadeleşecek, yoksa tümden mi düşecek? Kaç smart kuralın gerçekten kullanımda olduğu konusunda dürüst ol — deneyimime göre bu sayı, kurulmuş olanların çok altındadır; ve kimsenin bakımını yapmadıklarını yeniden inşa etmeye değmez.

CTA’lar, tracking ve analytics

HubSpot CTA’ları izlenen (tracked) öğelerdir; onları WordPress butonları/blokları ile değiştir ve tıklama takibine hâlâ ihtiyacın olup olmadığına karar ver (GA4 ya da tutulan HubSpot tracking kodu üzerinden). HubSpot’un analytics/CRM’ini tutuyorsan, HubSpot tracking script’i WordPress sitesinde kalabilir — bu, cutover boyunca attribution’ı korumanın çoğu zaman en temiz yoludur. Ve redirect haritasını dikkatle planla: HubSpot URL yapıları (özellikle blog ve HubDB dinamik sayfaları) WordPress varsayılanlarından farklıdır; ve tam da bunlar, korunması gereken SEO değerine sahip sayfalardır.

Üyeler ve gated (kilitli) içerik

HubSpot’un membership/gated içeriğini kullanıyorsan, o hesaplar ve erişim kuralları taşınmaz. Parolalar taşınabilir değildir. Bir WordPress membership plugin’i, elle eşlenmiş erişim kuralları ve parola sıfırlamaları için plan yap.

Dürüst kapanışım

Bir HubSpot geçişini batıran hata, onu diğerleri gibi ele almaktır — sanki bir CMS’i bir başkasıyla takas ediyormuşsun gibi. Öyle değil. Sen bir paketi yeniden parçalarına ayırıyor ve yalnızca web sitesini taşıyorsun; bu sırada neyin geride kalacağına ve nasıl bağlanacağına bilinçle karar veriyorsun.

Önce o sınırı çiz. Modülleri yeniden inşa et. HubDB’yi gerçek yapılandırılmış içeriğe eşle. Ve her şeyden önce, formları bozma — artık CRM’i beslemeyen, taşınmış bir web sitesi, satış ekibi lead’lerin durduğunu fark edene kadar başarı gibi görünen bir başarısızlıktır.

Ayıklamayı özenle yap; web sitesi sahibi olduğun bir platforma, seçtiğin bir barındırmaya, editörlerinin kendi başına çalıştırabileceği bir yere iner — CRM ise işini yapmaya devam eder, bağlı ama artık web siteni rehin tutmayan bir halde. İyi bir HubSpot geçişinin asıl teslim ettiği şey budur: bir kurtarma operasyonu değil, doğru parçaların doğru yerlerde durması.

Son Bir Şey: Peki HubSpot’un Yaptığını WordPress’le Yapamaz mısın?

Biri taşımaya kesin karar verir vermez hep şu soru geliyor: HubSpot’tan çıkarsak, o bütünleşik makinenin tamamını kaybetmez miyiz — CRM’le konuşan formları, pazarlamayla konuşan CMS’i, hepsi tek yerde olan o düzeni? Haklı soru. Ve dürüst cevap şu: o makinenin her parçasını, gerçekten sahip olduğun bir altyapının üstünde yeniden kurabilirsin.

Çünkü HubSpot’un asıl vaadi hiçbir zaman CMS değildi. Paketti — web sitesinin, formların, CRM’in ve pazarlamanın birbirinden haberdar olduğu tek bir giriş. O kolaylık gerçek; aksini iddia etmeyeceğim. Ama aslında ne için ödediğine bir bak: bir web sitesi çalıştırmak için koca bir suite kiralıyordun. WordPress, aynı paketi açık ve sahip olunabilir parçalardan yeniden kurmana izin verir:

• WordPress + WooCommerce, CMS ve ticaret motoru olarak — doğru düzgün yapılmış bir CMS; kod da barındırma da senin.
• Bir forms plugin’i — Gravity Forms ya da Fluent Forms — tuttuğun hangi CRM ise doğrudan ona bağlı. HubDB, custom post types’a döner; modüller bloklara döner; formlar satışı beslemeye devam eder.
• Seçtiğin bir CRM — HubSpot CRM’i tut ve entegre et ya da WordPress-native bir CRM çalıştır. Web sitesi artık suite’in rehinesi değil.

İstersen headless de gider. WordPress, 2016 sonundan beri core’da bir REST API sunuyor; WPGraphQL de — artık Automattic’in arkasında durduğu — olgun bir GraphQL katmanı veriyor. CMS, yanına hangi pazarlama yığını gelirse gelsin onunla güzel geçinir; web sitesini kapalı bir sistemin içine hapsetmek yerine.

Üstüne, HubSpot’un asla vermediği fazlasını getirir: plugin ekosistemi, insanlar için kurulmuş gerçek bir editör, büyüdükçe tıkırdayan bir contact-başı ya da koltuk-başı sayaç yok ve hiçbir satıcının dokunamayacağı tek şey — WordPress’i kimse ayağının altından satın alamaz.

Bu geçişin bütün anlamı da bu. Ne bir düşüş, ne de bir kurtarma. Doğru yapılmış bir çözme işi (unbundling): CMS’in düzgün hali olarak WordPress, hangi CRM ve pazarlama katmanını tutmaya karar verirsen onunla güzel geçinir — web sitesinin rehin olduğu kapalı bir suite yerine.