WordPress Yerine Astro Tercih Etmenin Kimsenin Bahsetmediği Bedelleri

Astro, son yılların en çok konuşulan static site generator’larından biri. Lighthouse skorları mükemmel, island architecture yaklaşımı zarif, build süreleri kısa. Geliştiriciler haklı olarak seviyor.

Ama bir web sitesi sadece geliştiriciden ibaret değil. Bir de içerik üreten editörler, siteyi yöneten operasyon ekibi ve teknik bilgisi sınırlı müşteriler var. Astro’nun parlak yüzeyinin altında, bu kullanıcılar için ciddi sürtünme noktaları gizleniyor.

WordPress mükemmel mi? Hayır. Ama 20 yılda çözdüğü problemlerin Astro’da “henüz çözülmemiş” olması, onu seçerken gözden kaçırılmaması gereken bir gerçek.

CMS Yok: Müşteriniz Git ve Markdown Öğrenmeli

Astro’da içerik yönetimi varsayılan olarak dosya tabanlıdır. Blog yazısı eklemek için bir .md veya .mdx dosyası oluşturmanız, frontmatter formatını bilmeniz ve bunu Git ile repoya göndermeniz gerekir.

Bir geliştirici için bu doğaldır. Ancak müşteri profili genellikle geliştirici değildir. Bir pazarlama müdürü, bir restoran sahibi ya da bir e-ticaret operatörcüsü “branch oluşturup commit atma” sürecine hâkim değildir ve bunu öğrenmek istemez.

Strapi, Contentful veya Sanity gibi bir headless CMS entegre edilebilir. Ancak bu, projeye yeni bir bağımlılık, yeni bir maliyet kalemi ve yeni bir bakım yükü ekler. WordPress’te bu, zaten var olan bir özellik.

Yönetim Paneli Yok: Ekip Yönetimi Sıfırdan Kurulmalı

WordPress’in /wp-admin paneli yılların ürünüdür. Kullanıcı yönetimi, içerik taslakları, yayın takvimi, SEO ayarları, yorum moderasyonu, eklenti yönetimi; hepsi tek bir arayüzde yaşar.

Astro’da bu arayüz yoktur. Site ayarlarını değiştirmek için konfigürasyon dosyalarını düzenlemeniz, bir içeriği taslak olarak tutmak için draft: true frontmatter alanı eklemeniz gerekir. Tüm bu işlemleri tarayıcıdan değil, terminalden veya kod editöründen yaparsınız.

Teknik bir ekip için bu kabul edilebilir olabilir. Ancak çapraz fonksiyonlu bir ekipte, yani içerik, pazarlama ve operasyonun birlikte çalıştığı bir ortamda, merkezi bir yönetim panelinin olmaması iş akışlarını yavaşlatır ve geliştirici bağımlılığı yaratır.

Kimlik Doğrulama Yok: Giriş, Abonelik ve Roller Bulunmuyor

Üyelik sistemi gerektiren her senaryo, Astro’da sıfırdan inşa edilmelidir: kullanıcı kaydı, oturum yönetimi, rol bazlı erişim kontrolü, şifre sıfırlama akışları.

WordPress’te ise kullanıcı rolleri (Yönetici, Editör, Yazar, Abone) kurulumla birlikte gelir. Üyelik eklentileri, ödeme duvarları ve abonelik sistemleri eklenti ekosisteminde hazırdır.

Eğer projeniz korumalı içerik, kullanıcıya özel paneller veya abonelik modeli içeriyorsa, Astro’da bunu kendiniz yazacak veya Clerk, Auth0, Supabase Auth gibi üçüncü parti hizmetlere bağımlı olacaksınız. Her biri ayrı maliyet, ayrı entegrasyon, ayrı bakım demektir.

Ortam Kütüphanesi Yok: Her Görsel Manuel Yönetilmeli

WordPress’in medya kütüphanesi, yüklenen tüm görselleri, videoları ve dosyaları tek bir yerde toplar. Sürükle-bırak yükleme, otomatik boyutlandırma, alt metin düzenleme ve doğrudan yazı içine ekleme gibi özellikler varsayılandır.

Astro’da görseller public/ veya src/assets/ dizinine elle eklenir. Optimizasyon için astro:assets modülü mevcuttur, ancak bu bir kütüphane deneyimi sunmaz. Hangi görselin nerede kullanıldığını takip etmek, kullanılmayan görselleri temizlemek ve toplu işlem yapmak tamamen geliştiricinin sorumluluğundadır.

Düzinelerce blog yazısı ve yüzlerce görsel içeren bir projede bu, gözardı edilemeyecek bir operasyonel yüktür.

Arama Yok: Algolia veya Benzeri Bir Hizmete Ücret Ödemelisiniz

WordPress, dahili arama fonksiyonuyla birlikte gelir. Mükemmel olmayabilir, ama çalışır. Daha gelişmiş arama için SearchWP veya Relevanssi gibi eklentiler mevcuttur.

Astro statik bir site ürettiği için sunucu taraflı arama mümkün değildir. Seçenekleriniz sınırlıdır:

WordPress, dahili arama fonksiyonuyla birlikte gelir. Mükemmel olmayabilir, ama çalışır. Daha gelişmiş arama için SearchWP veya Relevanssi gibi eklentiler mevcuttur.

Astro statik bir site ürettiği için sunucu taraflı arama mümkün değildir. Seçenekleriniz sınırlıdır:

Her iki durumda da, WordPress’te bir eklenti ile 5 dakikada çözülen problem, Astro’da bir mühendislik kararı, entegrasyon süreci ve potansiyel bir maliyet kalemine dönüşür.

E-posta Desteği Yok: Bildirim ve Gönderim İşlemleri Yapılamaz

WordPress, kutudan çıktığı haliyle e-posta gönderebilir: form bildirimleri, şifre sıfırlama, yeni yorum uyarıları ve yönetici bildirimleri. Newsletter eklentileri ile toplu e-posta gönderimi de mümkündür.

Astro statik bir site olarak çalıştığında sunucu tarafı yoktur; dolayısıyla e-posta gönderimi yapılamaz. SSR modunda bile, e-posta göndermek için Resend, SendGrid, Amazon SES veya Mailgun gibi bir harici servis entegre etmeniz gerekir.

İletişim formu yanıtları, sipariş onayları, abonelik bildirimleri gibi temel iş akışlarının her biri ayrı bir üçüncü parti entegrasyona bağımlıdır. Bu hem geliştirme süresini uzatır hem de aylık işletme maliyetini artırır.

Sonuç: Doğru Araç, Doğru Problem İçin

Astro, statik performansın kritik olduğu, geliştirici ekibin güçlü olduğu ve içerik ihtiyaçlarının öngörülebilir olduğu projelerde parlayan bir araçtır. Ancak WordPress’in yıllar içinde çözdüğü operasyonel problemleri “bizde o yok” diyerek geçiştirmek, projenin ilerleyen aşamalarında ciddi sürtünmelere yol açar.

Framework seçerken Lighthouse skorlarına değil, projeyi kimin kullanacağına, kimin yöneteceğine ve kimin içerik üreteceğine bakın.