Platform Geçişi: WordPress'ten Webflow'a veya Astro'ya Taşıma Rehberi

WordPress’ten ayrılmak isteyen işletme sahiplerinin çoğu, aslında WordPress’ten değil, WordPress’in belirli bir halinden kaçıyor: yavaşlayan eklenti yığınından, sürekli güncelleme yorgunluğundan, güvenlik açıklarından ya da tasarımcının elini kolunu bağlayan tema kısıtlarından. Çözüm arayışı iki farklı yöne çıkıyor: no-code tarafta Webflow (görsel düzenleme, sıfır bakım yükü, tasarımcı dostu), performans/geliştirici tarafında ise Astro (statik/headless mimari, uç seviye hız, tam kod kontrolü). Her iki yön de WordPress’in aksine, “eklenti biriktirerek büyüyen” değil, “baştan disiplinli kurulan” bir yapı sunuyor — ama bu disiplinin bedeli, geçiş sürecinin kendisi.

Bu yazı, platform değişikliğinin kendine özgü teknik yükünü ele alıyor: içeriği eski sistemden nasıl çıkarırsınız, tasarımı nasıl yeniden kurarsınız, form/arama/yorum gibi eklenti işlevlerini yeni platformda nasıl karşılarsınız ve sunucu tarafında ne değişir. Genel taşıma sürecini (DNS, 301 yönlendirme mantığı, taşıma günü kontrol listesi) zaten ayrıntılı işlediğimiz site taşıma rehberi yazımız kapsıyor — burada tekrar etmiyoruz, sadece platform-spesifik farklara odaklanıyoruz. Aynı şekilde domain değişip değişmediği ve toplu 301 stratejisinin ayrıntıları için domain değişikliği ve toplu 301 yönlendirme stratejisi yazımıza bakabilirsiniz; bu yazıda domain sabit kalıyor, yalnızca altyapı (CMS/platform) değişiyor varsayımıyla ilerliyoruz.

Önce Doğru Soru: Hangi Platforma, Neden?

”WordPress’ten kaçış” tek bir hedefe akmıyor. Üç yaygın rota var ve her biri farklı bir işletme profiline hizmet ediyor:

Bu tabloyu karar aracı olarak kullanın, tanım listesi olarak değil: bir ajans veya pazarlama ekibi sitede sık metin/görsel değişikliği yapıyorsa ve kod yazmak istemiyorsa Webflow’un görsel editörü doğru cevaptır. Site büyük ölçüde statik içerikse (kurumsal tanıtım, blog ağırlıklı, ürün sayfası az sayıda) ve hız/SEO en üst öncelikse Astro’nun derleme-zamanı render modeli fark yaratır. İçerik yapısı standart kalıplara sığmıyorsa (özel hesaplama motorları, karmaşık kullanıcı paneli, üçüncü parti sistemlerle derin entegrasyon) özel yazılım — yani sıfırdan veya bir framework üzerine kurulu özel bir uygulama — düşünülür. Bu üçüncü rotaya odaklı özel yazılım site taşıma projeleri, aşağıdaki tüm adımları (içerik envanteri, denklik haritası, aşamalı geçiş) aynı sırayla izler; farkı, “hedef platform hazır bir CMS değil, kodlanan bir sistem” olmasıdır — bu da geliştirme süresini uzatır ama esnekliği artırır.

Karar vermeden önce kendinize üç soru sorun:

1. İçeriği kim güncelleyecek? Teknik olmayan bir ekip üyesiyse, Astro’nun Markdown/MDX tabanlı içerik akışı bir öğrenme eğrisi getirir (çözülebilir, ama sıfır değildir); Webflow’un görsel panel deneyimi bu eğriyi büyük ölçüde düzleştirir.
2. Sitenin en büyük acısı ne? Hız/SEO ise Astro’nun statik render avantajı doğrudan sorunu çözer. Bakım yorgunluğu ve tasarım esnekliği ise Webflow’un no-code modeli daha hızlı rahatlatır. İkisi de değil de “iş mantığı WordPress’e sığmıyor” ise özel yazılım gündeme gelir.
3. Bütçe eğrisi nasıl? Webflow abonelik bazlı öngörülebilir bir maliyet sunar; Astro barındırma maliyeti düşüktür ama geliştirme/bakım için teknik kaynak gerektirir; özel yazılım en yüksek başlangıç maliyetine sahiptir ama uzun vadede özelleştirme kısıtı en azdır.

Aşama 1: İçerik Dışa Aktarma — WordPress’in Verisini Kurtarmak

Platform göçünün ilk teknik adımı, WordPress veritabanındaki içeriği taşınabilir bir formata çevirmektir. Burada üç yöntem var ve seçim, hedef platforma göre değişir.

Yöntem A: WordPress’in yerleşik dışa aktarma aracı

Araçlar → Dışa Aktar menüsü, yazı, sayfa, yorum, özel alan ve medya bağlantılarını bir XML dosyasına (WXR formatı) döker. Avantajı hız ve basitlik; sınırı ise format — XML, hem Webflow’un CMS koleksiyon yapısına hem Astro’nun Markdown/MDX dosya yapısına doğrudan uymaz, bir dönüştürme adımı gerekir. Küçük siteler (50-100 sayfa/yazı altı) için bu dönüştürme elle veya basit bir betikle yapılabilir; büyük arşivlerde otomasyon şart.

Yöntem B: REST API ile programatik çekim

WordPress’in yerleşik REST API’si (/wp-json/wp/v2/posts, /wp-json/wp/v2/pages) içeriği JSON formatında sunar — bu format, hem Astro’nun içerik koleksiyonlarına (content collections) dönüştürülmesi hem de Webflow API’sine toplu yükleme için XML’den çok daha uygun bir ara formattır. Yüzlerce yazılık arşivlerde tercih edilen yöntem budur: bir betik tüm yazıları API’den çeker, HTML gövdesini Markdown’a çevirir (bu adım için turndown gibi kütüphaneler yaygın kullanılır), öne çıkan görselleri indirir ve hedef platformun beklediği dosya/koleksiyon yapısına yerleştirir.

Yöntem C: Doğrudan veritabanı erişimi

Özel alanlar (ACF gibi eklentilerle oluşturulmuş meta veriler), karmaşık taksonomiler veya özel yazı tipleri söz konusuysa, REST API bazen tüm veriyi açığa çıkarmaz (varsayılan olarak özel alanlar API yanıtında görünmeyebilir). Bu durumda wp_postmeta tablosuna doğrudan erişim veya bir eklentiyle (custom field’ları API’ye açan) genişletme gerekir. Bu adım teknik bilgi ister ve genellikle WordPress hosting taşıma sürecinde zaten alınmış tam bir veritabanı yedeğinden çalışılır — bu yüzden dışa aktarma öncesi güncel bir yedek şart (aşağıdaki yedekleme bölümüne bakın).

İçerik denklik haritası

Ham içerik çekmek yetmez; her WordPress kavramının hedef platformdaki karşılığını netleştiren bir eşleme tablosu kurmak taşımanın omurgasıdır:

Bu tablo boşsa taşıma sırasında en sık kaybolan şey özel alanlardır — çünkü görünürde “içerik” gibi durmazlar ama sayfanın belirli bir bölümünü (örneğin bir ürün sayfasındaki teknik özellik tablosu) besliyor olabilirler. Denklik haritasını içerik envanterinden önce değil, envanterle birlikte çıkarın.

Aşama 2: Tema ve Tasarımı Yeniden Kurmak

WordPress temaları PHP şablonları, Webflow tasarımları görsel bileşenler, Astro siteleri ise .astro bileşenleri ve CSS/framework kombinasyonlarıyla çalışır — üçü arasında doğrudan “içe aktarma” yoktur, tasarım pratikte yeniden inşa edilir. Bu, platform göçünün en çok küçümsenen adımıdır; birçok proje “içeriği aktardık, tasarımı hallederiz” diyerek başlar ve tasarım aşamasında beklenenin iki katı zaman harcar.

Astro’da yeniden kurulum

Astro bileşen tabanlı çalışır: her sayfa şablonu, header/footer gibi tekrar eden parçalar ve içerik listeleme mantığı (blog arşivi, kategori sayfası) ayrı .astro bileşenleri olarak yazılır. Statik site oluşturucu (SSG) ya da sunucu tarafı render (SSR) modunu seçmek burada kritik bir karardır: tamamen statik içerikli sitelerde (kurumsal tanıtım, blog) SSG hem en hızlı hem en ucuz barındırma seçeneğidir; kullanıcıya özel içerik (giriş yapılmış panel, dinamik fiyatlandırma) varsa SSR veya hibrit render gerekir. WordPress temasının görsel dilini (renk, tipografi, bileşen aralıkları) birebir kopyalamak yerine, tasarım sistemini (renk paleti, spacing ölçeği, bileşen kütüphanesi) yazılı hale getirip sıfırdan, ama tutarlı biçimde kurmak — hem daha temiz kod hem gelecekte bakımı kolay bir sonuç verir.

Webflow’da yeniden kurulum

Webflow’un görsel düzenleyicisi, WordPress temasının PHP şablon mantığını değil, CSS kutu modelini (flexbox/grid) doğrudan görsel arayüzde kurmayı gerektirir. Burada pratik yol, eski temanın ekran görüntülerini birebir kopyalamak değil, marka kimliğini (logo, renk, tipografi) koruyarak Webflow’un bileşen (Symbol) ve CMS şablon (Collection Template) yapısına uygun bir yeniden tasarımdır. Symbol’lar (header, footer, CTA blokları gibi tekrarlayan öğeler) kurulduktan sonra, CMS koleksiyonuna bağlı dinamik şablon sayfaları (örneğin her blog yazısı için otomatik oluşan sayfa) tanımlanır — bu, WordPress’teki tema şablon hiyerarşisinin (single.php, archive.php) Webflow karşılığıdır.

Tasarım denkliği kontrol listesi

Tema yeniden kurulumunu “bitti” saymadan önce doğrulanması gereken kalemler:

• Mobil görünüm tüm kırılma noktalarında (dar telefon, tablet, geniş masaüstü) test edildi
• Header/footer menü yapısı ve iç link hedefleri birebir korundu
• Yazı tipi yükleme stratejisi (web font) performansı düşürmüyor — eski temada gömülü onlarca font ağırlığı taşınmadı
• Görsellerin yeni platformda otomatik boyutlandırma/sıkıştırma (responsive image) desteği aktif
• 404 sayfası, arama sonuç sayfası gibi “unutulan” şablonlar da yeniden kuruldu
• Favicon, Open Graph görselleri ve meta veri şablonları yeni sistemde tanımlı
• Erişilebilirlik temelleri (kontrast, odak durumları, alt metin alanları) yeni tasarımda korundu

Aşama 3: Form ve Eklenti İşlevselliğinin Yeniden Kurulması

WordPress’in gücü büyük ölçüde eklenti ekosisteminden gelir — iletişim formu, arama, SEO meta yönetimi, önbellekleme, güvenlik, çoklu dil, üyelik sistemi… Platform değişikliğinde bu işlevlerin her biri için bir karşılık bulunmalı, aksi halde site “taşındı ama eksik” biçiminde yayına girer.

Form işlevselliği

WordPress’te Contact Form 7, WPForms veya Gravity Forms gibi eklentilerle kurulan formlar, hem Webflow’da hem Astro’da farklı mimarilerle çözülür:

• Webflow’da: Yerleşik form bileşeni doğrudan e-posta bildirimi ve temel entegrasyonları (Zapier, Mailchimp) destekler; karmaşık koşullu mantık (bir alana göre başka alanın görünmesi) için üçüncü parti form araçları (Jotform, Typeform gömme) gerekebilir.
• Astro’da: Statik sitede form gönderimi sunucu tarafı işlem gerektirdiğinden, form verisi genellikle üçüncü parti bir servise (Formspree, Netlify Forms, özel bir API endpoint) POST edilir. Bu, WordPress’teki “eklenti kur, çalışsın” basitliğine kıyasla bir entegrasyon adımı ekler ama esneklik ve hız kazandırır — form gönderimi CMS’in ağırlığını taşımaz.

Her iki durumda da, eski formda kullanılan tüm alanların (özellikle koşullu görünen alanlar ve dosya yükleme alanları) yeni sistemde birebir karşılığı olduğunu, gönderim sonrası e-posta bildiriminin doğru adrese gittiğini ve spam koruması (reCAPTCHA veya honeypot) aktif olduğunu taşıma öncesi test ortamında doğrulayın.

Arama işlevselliği

WordPress’in yerleşik arama motoru (veya bir arama eklentisi) sunucu tarafında veritabanı sorgusuyla çalışır. Statik bir Astro sitesinde sunucu tarafı sorgu olmadığından, arama genellikle derleme zamanında üretilen bir istemci tarafı indeks (örneğin Pagefind veya benzeri statik arama kütüphaneleri) ile çözülür. Webflow’da ise yerleşik arama, CMS koleksiyonları üzerinde sınırlı ama kurulumsuz çalışır; daha gelişmiş filtreleme için üçüncü parti arama servisi (Algolia gibi) entegre edilebilir.

SEO meta yönetimi

Yoast SEO veya Rank Math gibi eklentilerin ürettiği başlık şablonları, meta açıklamalar, canonical etiketler ve yapılandırılmış veri (schema) çıktısının hiçbiri otomatik taşınmaz — her biri yeni sistemde ayrı ayrı yeniden kurulur. Astro’da bu genellikle her sayfa/koleksiyon girdisinin frontmatter’ında title/description alanları ve paylaşılan bir SEO bileşeniyle (meta etiketleri merkezi üreten bir Astro bileşeni) yapılır; Webflow’da ise her sayfanın ve CMS şablonunun kendi SEO panelinde (sayfa ayarları içinde) elle veya dinamik alan bağlamayla doldurulur. Bu adım atlanırsa, taşıma sonrası arama motorlarının gördüğü meta veriler eski sayfalarla tutarsızlaşır — bu da taşıma sonrası dalgalanmayı normalden büyütebilir.

Önbellekleme ve performans eklentileri

WordPress’te WP Rocket veya benzeri önbellekleme eklentileri, sayfa hızını sunucu tarafında statik HTML üreterek artırır. İlginç olan şu: Astro zaten derleme zamanında statik HTML ürettiği için, bu eklentinin çözdüğü sorun platformun doğasında zaten yoktur — ayrı bir önbellekleme katmanı genellikle gereksizleşir. Webflow’da barındırma altyapısı (kendi CDN’i) benzer bir rol üstlenir. Yani bu iki platforma geçişin dolaylı bir faydası, “hız eklentisi yönetme” yükünün ortadan kalkmasıdır.

Güvenlik eklentileri

Wordfence gibi güvenlik eklentileri WordPress’e özgü tehdit yüzeyine (giriş formu saldırıları, eklenti/tema güvenlik açıkları, dosya bütünlüğü) karşı çalışır. Webflow tamamen yönetilen bir platform olduğundan bu yükün büyük bölümü platform tarafından üstlenilir. Astro’nun statik çıktısı ise saldırı yüzeyini doğası gereği küçültür (çalışan bir veritabanı veya giriş paneli yoksa, brute-force veya SQL enjeksiyonu gibi klasik WordPress tehditlerinin çoğu anlamsızlaşır) — ama form işleme veya SSR fonksiyonları gibi dinamik parçalar varsa, güvenlik dikkati o parçalara kayar.

Aşama 4: Hosting ve Sunucu Tarafı Taşıma

Platform değişikliği, çoğu zaman hosting değişikliğini de beraberinde getirir — çünkü WordPress’in PHP + MySQL gereksinimi, Astro’nun statik dosya sunumu veya Webflow’un tamamen yönetilen barındırması ile aynı altyapıda çalışmaz. WordPress site taşıma hizmeti ile platform göçü burada kesişir ama aynı şey değildir: biri altyapıyı aynı tutup sunucu değiştirir, diğeri altyapının kendisini değiştirir. Sunucu tarafı adımlar hedef platforma göre ayrışır.

WordPress hosting taşıma — geçiş öncesi son durum

Astro veya Webflow’a geçmeden önce bile, mevcut WordPress sitesinin sağlıklı ve erişilebilir bir ortamda olması gerekir — çünkü içerik dışa aktarma, canlı sitenin veya güncel bir yedeğin üzerinden yapılır. Çoğu geçiş projesinde en pratik yol, önce mevcut cPanel site taşıma hizmeti kapsamında WordPress’i (varsa) daha kontrollü bir test/hazırlık ortamına almak, dışa aktarma ve doğrulama işlemlerini orada yürütmek, canlı siteyi ise geçiş anına kadar dokunmadan yayında tutmaktır. Bu, “kaynak” ve “hedef” ortamların birbirine karışmasını önler.

Astro’da sunucu tarafı: statik barındırma ve derleme hattı

Astro’nun ürettiği çıktı, çoğunlukla saf HTML/CSS/JS dosyalarından oluşur — bu da PHP çalıştıran klasik paylaşımlı hosting yerine, statik dosya sunmaya ve otomatik derlemeye (CI/CD) odaklanan modern barındırma platformlarını (statik siteye özel barındırma servisleri) doğal seçim yapar. Sunucu taşımasının pratik akışı şöyledir:

1. Depo (repository) kurulumu: İçerik ve kod bir sürüm kontrol sistemine (git) yüklenir.
2. Derleme hattı bağlama: Barındırma servisi, depoya her değişiklik gönderildiğinde otomatik derleme (build) tetikler.
3. Ortam değişkenleri: Form entegrasyonu, analitik anahtarları gibi gizli bilgiler barındırma panelinde tanımlanır (kod içine gömülmez).
4. Önizleme ortamı: Canlıya almadan önce, geçici bir alt alan adında son kontrol yapılır.
5. DNS yönlendirme: Domain, yeni barındırmaya yönlendirilir — bu adım genel taşıma rehberimizdeki DNS/TTL disipliniyle birebir örtüşür.

Bu akışın WordPress’teki “dosyaları FTP ile yükle, veritabanını içe aktar” mantığından temel farkı, sitenin artık bir dosya kümesi değil, bir derleme süreci olmasıdır — her içerik değişikliği (yeni blog yazısı dahil) teknik olarak yeni bir derleme tetikler. Bu, teknik olmayan bir içerik ekibi için öğrenilmesi gereken yeni bir zihinsel model demektir.

Webflow’da sunucu tarafı: neredeyse yok

Webflow, barındırmayı platformun kendisi üstlendiği için klasik anlamda “sunucu taşıma” adımı içermez — proje Webflow’un kendi altyapısında yayınlanır, kullanıcı yalnızca domain’i Webflow’a yönlendirir (DNS kayıtları). Bu, web sitesi sunucu taşıma yükünü pratik olarak sıfırlayan en büyük avantajlardan biridir: sunucu seçimi, güncelleme, yedekleme altyapısı, SSL yenileme gibi işler platformun sorumluluğuna geçer. Bunun bedeli esnekliktir — sunucu düzeyinde özel yapılandırma (özel önbellek kuralları, sunucu tarafı özel betikler) mümkün değildir.

Genel hosting taşıma hizmeti değerlendirmesi

Hangi platforma geçilirse geçilsin, sunucu/barındırma tarafının genel taşıma disiplini (DNS hazırlığı, TTL düşürme, geçiş penceresi, 48 saatlik doğrulama) sabittir ve bu konuyu ayrıntılı olarak site taşıma rehberimizde işledik. Buradaki fark, taşınan “şeyin” doğasıdır: klasik hosting taşıma hizmetinde dosya + veritabanı taşınır, platform göçünde ise bambaşka bir teknoloji yığınına geçiş yapılır — bu da test ve doğrulama listesini genişletir (yukarıdaki tasarım ve işlev denkliği kontrol listeleri buna eklenir).

Aşama 5: Yedekleme Stratejisi — Platform Göçüne Özel

Web sitesi yedekleme ve taşıma birlikte anılan iki kavramdır ama platform göçünde yedeklemenin rolü klasik hosting taşımasından farklıdır: burada amaç sadece “bir şeyler ters giderse eski hale dön” değil, aynı zamanda “kaynak veriyi kaybetmeden defalarca yeniden işleyebilme” güvencesidir — çünkü içerik dönüştürme (XML/JSON’dan Markdown’a, WordPress yapısından CMS koleksiyonuna) genellikle tek seferde mükemmel olmaz, birkaç deneme-yanılma turu gerektirir.

Üç katmanlı yedekleme modeli

1. Kaynak anlık görüntüsü (dokunulmaz): Geçiş projesine başlamadan önce alınan, dosya + veritabanının tam bir kopyası. Bu yedek, proje süresince hiç değiştirilmez veya üzerine yazılmaz — dönüştürme betiği hata verirse veya bir içerik kalemi eksik çıkarsa, buraya geri dönülür.
2. Çalışma kopyası: Kaynak anlık görüntüden türetilen, üzerinde dönüştürme denemeleri yapılan kopya. Dönüştürme betiği burada test edilir, hatalar burada düzeltilir.
3. Hedef platform yedeği: Yeni platform (Astro deposu veya Webflow projesi) kendi içinde de düzenli yedeklenir — Astro’da bu doğal olarak git geçmişidir (her commit bir geri dönüş noktasıdır); Webflow’da platformun kendi sürüm geçmişi (backup/publish history) kullanılır.

Geçiş günü için ek önlem: paralel yayın

Platform göçlerinde “eski platformu hemen kapatma” kuralı, klasik hosting taşımasından daha da kritik hale gelir — çünkü geri dönüş, sadece DNS’i eski sunucuya çevirmek kadar basit olmayabilir (yeni platformda birkaç hafta içerik girildiyse, geri dönüşte o içerik kaybolur). Pratik yaklaşım: eski WordPress kurulumunu, yeni platform en az 2-4 hafta sorunsuz çalışana kadar salt-okunur biçimde (yeni içerik girilmeden) erişilebilir tutmak — hem acil durum yedeği hem de “unutulan bir sayfa var mıydı?” kontrolü için.

cPanel üzerinden tam yedek alma

WordPress kaynağı bir cPanel ortamındaysa, cPanel site taşıma hizmeti kapsamında sunulan tam hesap yedeği (dosya yöneticisi üzerinden veya cPanel’in yerleşik yedekleme aracıyla alınan .tar.gz paketi) tek bir dosyada hem dosyaları hem veritabanını hem de e-posta yapılandırmasını kapsar. Bu paket, platform göçü projesinde kullanılmasa bile, “her şey ters giderse eski siteyi dakikalar içinde ayağa kaldırabilme” güvencesi olarak saklanmalıdır — büyüklüğüne göre bulut depolama veya yerel bir disk üzerinde, tek bir yerde değil en az iki farklı konumda tutulması önerilir.

Adım Adım Genel Geçiş Süreci (Özet Akış)

Yukarıdaki beş aşamayı tek bir kronolojik akışta toplarsak:

1. Hazırlık: Hedef platform kararı (Webflow / Astro / özel yazılım), kapsam belirleme, kaynak WordPress’in tam yedeğinin alınması.
2. İçerik envanteri ve denklik haritası: Yazı, sayfa, özel alan, medya, yönlendirme listesinin çıkarılması; her birinin hedef platformdaki karşılığının tanımlanması.
3. İçerik dışa aktarma ve dönüştürme: XML/REST API ile çekim, format dönüşümü, medya taşıma.
4. Tasarım yeniden kurulumu: Tasarım sistemi tanımı, bileşen/şablon kurulumu, mobil ve erişilebilirlik testleri.
5. İşlev denkliği: Form, arama, SEO meta, önbellekleme ve güvenlik karşılıklarının kurulması ve test edilmesi.
6. Test ortamında tam prova: Geçici alt alan adında (veya önizleme URL’sinde) sitenin uçtan uca kontrolü — bu adım atlanmaz.
7. Sunucu/hosting geçişi: Hedef platforma göre derleme hattı kurulumu (Astro) veya doğrudan yayın (Webflow); DNS hazırlığı.
8. Geçiş günü ve 301 yönlendirmeleri: URL yapısı değiştiyse (çoğu göçte değişir, çünkü platformlar farklı URL kalıpları kullanabilir), her eski URL’nin yeni karşılığına yönlendirilmesi — bu konunun ayrıntılı stratejisi için domain değişikliği ve toplu 301 yönlendirme yazımıza bakın.
9. 48 saat + haftalar süren doğrulama: Arama motoru kapsama takibi, form/işlev testi, hız ölçümü.
10. Eski platformun kapatılması: Belirlenen güvenlik penceresi (tipik 2-4 hafta) sonunda, eski WordPress kurulumunun arşivlenmesi.

Vaka Kurgusu: Bir Mimarlık Bürosunun Webflow’a Geçişi

Orta ölçekli bir mimarlık bürosunun kurumsal sitesi, yıllarca birikmiş 40’tan fazla eklentiyle ağırlaşmış bir WordPress kurulumu üzerinde çalışıyordu. Sayfa yükleme süreleri mobilde 6 saniyeyi aşmış, her güncelleme bir eklenti çakışması riskiyle gelmiş, tasarım ekibi (dışarıdan çalışan bir stüdyo) her portföy projesi eklemek için geliştiriciye bağımlı kalmıştı. Ekip, üç platformu değerlendirdi: WordPress’i sadeleştirmek (mevcut yapıyı temizlemek), Astro’ya geçmek (en yüksek performans) ve Webflow’a geçmek (tasarım özerkliği). Karar Webflow yönünde verildi — çünkü asıl acı noktası hız değil, tasarım ekibinin her değişiklik için geliştiriciye muhtaç olmasıydı.

Süreç sekiz hafta sürdü. İlk iki hafta içerik envanteri ve denklik haritasına ayrıldı: 85 portföy projesi, 30 blog yazısı, özel alanlarla (proje yeri, metrekare, tamamlanma yılı) zenginleştirilmiş bir yapı tespit edildi. REST API üzerinden çekilen veri, bir dönüştürme betiğiyle Webflow CMS koleksiyon yapısına aktarıldı; özel alanlar koleksiyon özel alanlarına birebir eşlendi. Üçüncü ve dördüncü haftalarda tasarım stüdyosu, eski temanın görsel dilini koruyarak ama Webflow’un Symbol ve şablon yapısına uygun sıfır bir tasarım kurdu — bu adım en çok zaman aldı, çünkü “birebir kopya” değil “aynı kimlik, yeni yapı” hedeflendi. Beşinci haftada iletişim formu ve proje talep formu Webflow’un yerleşik form bileşenine taşındı, CRM entegrasyonu (form gönderiminin otomatik olarak satış ekibine düşmesi) yeniden kuruldu. Altıncı haftada SEO meta şablonları (her portföy sayfası için dinamik başlık/açıklama kalıbı) kuruldu ve test edildi.

Yedinci hafta, geçici bir önizleme adresinde uçtan uca kontrol yapıldı: 85 portföy sayfasının her biri tek tek açılıp görsellerin, özel alanların ve iç linklerin doğru göründüğü teyit edildi; bu adımda üç projede görsel eksikliği, bir projede yanlış eşlenmiş metrekare alanı bulundu ve düzeltildi. Sekizinci hafta DNS geçişi yapıldı; eski WordPress kurulumu, salt-okunur biçimde üç hafta boyunca ayrı bir alt alan adında erişilebilir tutuldu. Geçiş sonrası ilk ay içinde organik trafik geçici bir dalgalanma yaşadı (URL yapısındaki küçük değişiklikler nedeniyle bazı sayfalarda geçici sıralama kayması), ancak sekizinci haftada trafik geçiş öncesi seviyesine döndü ve mobil sayfa hızı 6 saniyeden 2 saniyenin altına indi. Tasarım ekibi ilk kez geliştirici beklemeden yeni bir portföy projesi ekleyebildi. (Vaka temsilidir.)

Sık Yapılan Hatalar

1. Denklik haritası çıkarmadan dönüştürme betiğine başlamak. İçerik önce teknik olarak taşınır, özel alanların nereye gideceği “sonra düşünülür” — sonuç, taşındıktan sonra fark edilen eksik veri parçalarıdır. Denklik haritası, dönüştürme betiğinden önce gelir.
2. Tasarımı “birebir kopyalamaya” çalışmak. WordPress temasının piksel piksel kopyası hedeflendiğinde, yeni platformun güçlü yanları (Webflow’un bileşen sistemi, Astro’nun performans avantajları) kullanılmadan harcanır. Hedef, aynı marka kimliği ile daha iyi bir yapı olmalı, birebir klon değil.
3. Form entegrasyonlarını test ortamında değil canlıda test etmek. Form gönderiminin doğru adrese gittiğini, CRM’e düştüğünü, spam korumasının çalıştığını canlıya geçtikten sonra fark etmek, kaybedilen müşteri talepleri anlamına gelir. Test ortamında gerçek bir form gönderimi mutlaka denenmelidir.
4. SEO meta şablonlarını unutmak. Eski platformdaki Yoast/Rank Math çıktısı otomatik taşınmaz; yeni platformda meta başlık/açıklama şablonları kurulmazsa, arama motorları her sayfayı “başlıksız” veya jenerik başlıklı görür — bu, taşıma sonrası trafik kaybının sık görülen nedenlerinden biridir.
5. Eski platformu geçiş gününde hemen kapatmak. Yeni sistemde fark edilmemiş bir eksiklik varsa (bir sayfa, bir form, bir özel alan), eski platform hâlâ erişilebilirse hızlıca referans alınabilir; kapatılmışsa geri dönüş çok daha maliyetlidir.
6. URL yapısı değişikliğini yönlendirmesiz bırakmak. Platform değiştiğinde URL kalıpları genelde değişir (örneğin /blog/yazi-basligi/ yerine /yazilar/yazi-basligi); her eski URL için yeni karşılığa 301 yönlendirmesi kurulmazsa, birikmiş arama sıralaması büyük ölçüde kaybedilir.
7. İçerik ekibini yeni iş akışına hazırlamadan geçmek. Astro’da Markdown/MDX ile veya git tabanlı bir akışla çalışmak, WordPress’in görsel editörüne alışmış bir ekip için yeni bir öğrenme eğrisidir; geçiş öncesi eğitim/dokümantasyon verilmezse, geçiş sonrası “nasıl yeni yazı ekleyeceğiz?” sorusu operasyonu durdurur.
8. Yedeği tek katmanlı almak. Sadece “bir yedek aldık” güvencesiyle dönüştürme denemelerine başlamak, ilk hatalı denemede kaynak veriyi bozma riski taşır. Kaynak anlık görüntüsünün hiç dokunulmadan saklanması gerekir.

Sık Sorulan Sorular

Sonuç

Platform göçü, bir “aktarım” değil, sitenin ikinci kez inşa edilmesidir — içerik farklı bir kalıba dökülür, tasarım farklı bir mantıkla kurulur, eklentilerin çözdüğü her işlev yeni bir karşılıkla eşlenir. Bu yüzden genel bir hosting taşımasından çok daha fazla planlama ve test gerektirir, ama karşılığında WordPress’in eklenti yorgunluğundan kalıcı olarak kurtulma fırsatı sunar.

Karar noktası basit bir formüle indirgenebilir: içeriği kim, ne sıklıkla güncelleyecek ve en büyük acı noktası ne? Görsel özerklik ve sıfır bakım önceliğiniz ise Webflow, ham hız ve SEO kontrolü önceliğiniz ise Astro, standart kalıplara sığmayan özel iş mantığınız varsa özel yazılım doğru rotadır. Hangi rota seçilirse seçilsin, süreç aynı disiplinden geçer: eksiksiz içerik envanteri, dikkatli denklik haritası, sabırlı tasarım yeniden kurulumu, tam işlev testi ve aşamalı bir geçiş takvimi.

Platform göçünüzü teknik SEO kaybı olmadan planlamak isterseniz teknik SEO hizmetleri sayfamıza göz atabilir veya doğrudan iletişime geçebilirsiniz.