WordPress, otomatik cevap olarak öldü; yazılım olarak değil.
Bu ayrım önemlidir. "WordPress öldü" ifadesini gerçek bir pazar iddiası olarak kullanırsanız, veriler bunu reddeder. W3Techs raporuna göre, WordPress Haziran 2026 itibarıyla bilinen bir CMS'e sahip web sitelerinin %59,2'sini ve tüm web sitelerinin %41,5'ini güçlendiriyor. Buna ölü diyemezsiniz.
Ancak 2026'da web siteleri oluşturuyorsanız, eski içgüdü yanlış hissettirmeye başladı. Bir müşteri hızlı bir site, özel düzen, temiz SEO, birkaç entegrasyon ve on eklenti gerektirmeyen bir düzenleme iş akışı istiyor. Cevap eskiden WordPress'ti çünkü özel kodlama yavaş ve pahalıydı. AI bu denklemi değiştirdi.
Cloudflare'in EmDash'i bu değişimi görmezden gelmeyi zorlaştırıyor. Cloudflare, WordPress'in hiçbir değeri olmadığını söylemiyor. Söylediği şey, bir sonraki CMS'in TypeScript tabanlı, serverless, Astro destekli, eklenti-korumalı (sandboxed) ve ilk günden itibaren AI ajanları için inşa edilmiş olabileceğidir.
Hala WordPress'e saygı duyuyorum. Doğru projede hala kullanırdım. Artık varsayılan olmayı hak ettiğini düşünmüyorum.
WordPress neden varsayılan olarak öldü
WordPress kazandı çünkü teknik olmayan insanlara yayıncılık gücü verdi. Bu gerçek bir atılımdı. Bir tema yükleyebilir, bir sayfa oluşturucu ekleyebilir, blog gönderileri yayınlayabilir, formlar ekleyebilir, SEO meta verileri ekleyebilir ve siteyi müşteriye teslim edebilirdiniz.
Bu vaat, birçok işletme sitesi için kötü yaşlandı.
Basit bir site genellikle bir eklenti yığınına dönüşür: sayfa oluşturucu, önbellek eklentisi, SEO eklentisi, form eklentisi, güvenlik eklentisi, görsel eklentisi, çerez eklentisi, yönlendirme eklentisi, schema eklentisi ve bazen sayfa oluşturucuyu daha az acı verici hale getirmek için özel alan eklentisi. Her parça güncellemeler, ayarlar, veritabanı tabloları, varlıklar ve başka bir başarısız noktası ekler.
Sorun WordPress çekirdeği değil. Sorun, birçok WordPress projesinin bir yıl sonra aldığı operasyonel şekildir. Site, temiz HTML, küçük bir CMS ve birkaç API çağrısı olarak gönderilebilecek sayfalar için küçük bir arka uç sistemine dönüşür.
Patchstack'in 2026 WordPress güvenlik raporu, bakım maliyetini görmezden gelmeyi zorlaştırıyor. Rapor, 2025'te WordPress ekosisteminde 11.334 yeni güvenlik açığı bulunduğunu ve bunun 2024'e göre %42 artış olduğunu belirtiyor. Ayrıca yeni güvenlik açıklarının %91'inin eklentilerde, %9'unun temalarda bulunduğunu ve WordPress çekirdeğinde sadece 6 güvenlik açığı bildirildiğini, bunların da düşük öncelikli olduğunu söylüyor.
İşte nokta burası. WordPress'in kendisi kötü adam değil. Riskin yaşadığı yer eklenti yüzeyidir.
EmDash en temiz sinyaldir
Bu, baştan dahil etmem gereken kısımdı. Cloudflare, 1 Nisan 2026'da EmDash'i v0.1.0 önizlemesi olarak tanıttı ve onu WordPress'in manevi halefi olarak tanımladı.
Detaylar bu makaledeki argümanla örtüşüyor. EmDash TypeScript ile yazılmış, Astro tarafından destekleniyor, MIT altında açık kaynaklı ve serverless barındırma için tasarlanmış. Ayrıca sürekli geri gelen belirli WordPress acı noktasını hedefliyor: eklentiler.
WordPress'te bir eklenti, sitenin bulunduğu dünyanın içinde çalışır. Çok fazla güven gerektiren şekillerde veritabanına, dosya sistemine ve çalışma zamanına (runtime) dokunabilir. Cloudflare'in EmDash modeli, eklentileri izole Dinamik Çalışanlara (Dynamic Workers) iter ve onlara bağlamalar (bindings) aracılığıyla beyan edilmiş yetenekler verir. Bir eklenti, bu işi yapmadan önce içerik okuma veya e-posta gönderme gibi tam olarak ihtiyaç duyduğu izinleri istemelidir.
Bu modern CMS fikridir: daha az ortam güveni, daha fazla açık izin.
EmDash ayrıca önemli çünkü AI ajanlarını iş akışının bir parçası olarak ele alıyor. Cloudflare, her EmDash örneğinin uzak bir MCP sunucusunun yanı sıra CLI araçları ve ajan becerileri sunabileceğini belirtiyor. Bu, bir kodlama ajanının bir yönetim panelini kazımak veya verinin nerede yaşadığını tahmin etmek yerine, yapılandırılmış araçlar aracılığıyla içerik, şemalar, medya ve迁移 çalışmalarını yönetebileceği anlamına gelir.
Bir müşteriye bugün körü körüne EmDash'e geçmesini söylemem. Bu bir önizleme. Önemli olan yön şudur: Cloudflare, WordPress'in yerini alacak şeyi, artık web sitelerinden istediğim aynı şeyler etrafında inşa ediyor: korumalı (sandboxed) uzantılar, temiz ön uç mimarisi, programatik kontrol ve ajan-okunabilir operasyonlar.
AI özel site matematiğini değiştirdi
Birkaç yıl önce, özel olmak pahalı demekti. Ya her sayfa ve bileşeni oluşturması için bir geliştiriciye para öderdiniz ya da bir sayfa oluşturucu kullanır ve ağırlığı kabul ederdiniz.
AI orta yolu pratik hale getiriyor. Bir düzeni tanımlayabilir, bileşenler oluşturabilir, boşlukları iyileştirebilir, metin yazabilir, yapılandırılmış içerik oluşturabilir, küçük bir yönetim akışı kurabilir ve tam olarak ihtiyacınız olan servisleri bağlayabilirsiniz. v0, Framer AI, Webflow AI, Lovable tarzı uygulama oluşturucular ve modern kodlama ajanları gibi araçlar, özel arayüzlerin üretilmesini hızlandırdı.
Bu, AI'nın zevk, QA veya mühendislik kararlarının yerini aldığı anlamına gelmez. Bu, ilk taslağın artık tüm bütçeyi tüketmediği anlamına gelir.
WordPress'in varsayılan konumunu kaybettiği yer burasıdır. Markayla tam olarak eşleşen, hızlı yüklenen, temiz schema gönderen ve ağır bir arka uçtan kaçınan özel bir Next.js, Astro, EmDash veya Webflow yapısı elde edebiliyorsam, WordPress uzlaşmasını haklı çıkarmak zorlaşır.
Bir sayfa oluşturucu size düğmeler verir. AI destekli bir kod iş akışı size gerçek sistemi verir: bileşenler, içerik modeli, rotalar, meta veriler, görsel işleme, formlar, analitik ve dağıtım kuralları. Bunu inceleyebilirsiniz. Sürümleyebilirsiniz. Test edebilirsiniz.
Bu, bir tema pazar yerinden daha önemlidir.
Arka uç işe uygun olmalı
Bir broşür sitesinin varsayılan olarak veritabanı destekli bir yönetim paneline ihtiyacı yoktur. Bir açılış sayfasının hızlı görünmesi için PHP, MySQL, yirmi seçenek ekranı ve bir önbellek katmanına ihtiyacı yoktur.
Projenin ihtiyacı olduğunda bir arka uç kullanın:
Bir tema blokları saklayacak bir yere ihtiyaç duyduğu için bir arka uç eklemeyin.
Yalın modern bir yığın daha küçük olabilir. Statik sayfalar, sunucu tarafında oluşturulan rotalar, headless bir CMS, Supabase, Git tabanlı bir içerik akışı, barındırılan formlar, Stripe, bir arama sağlayıcısı ve küçük bir API, web sitelerinin büyük bir yüzdesini kapsar. Daha az hareketli parça elde edersiniz ve performans üzerinde daha iyi kontrol sahibi olursunuz.
Temiz HTML ve ölçülü SEO çalışmasına önem vermemin nedeni de budur. Lighthouse SEO puanı vaka çalışmamda→, kazanım disiplinli işaretleme, schema, hız, erişilebilirlik ve önbelleklemeden geldi. Bir site oluşturucu yardımcı olabilir, ancak nihai çıktı hala tarayıcılar, arama motorları ve AI ajanları tarafından okunabilir olmalıdır.
AI, tam tasarımı daha az maliyetli hale getirir
WordPress'e karşı en güçlü dava artık sadece hız değil. Tasarım kontrolüdür.
Çoğu WordPress projesi bir tema ile başlar, ardından markayı ona uydurmak için eğip büker. Yazı tiplerini, renkleri, bölümleri ve boşlukları değiştirirsiniz, ancak tema hala parmak izlerini bırakır. Site, onu inşa eden araç gibi görünür.
AI bu iş akışını tersine çevirir. Marka, teklif, kitle ve gerçek etkileşim modeli ile başlayabilirsiniz. Ardından arayüzü bu kısıtlamalar etrafında oluşturursunuz.
Bu daha iyi bir sıradır.
Bir danışman sitesi, ihtiyaç duyduğu tam kanıt yapısına sahip olabilir. Bir SaaS sayfası, genel bir kahraman görseli yerine yoğun bir ürün yüzeyi gösterebilir. Bir müzik ürün sayfası, bir şablon yerine gerçek bir stüdyo aracı gibi hissettirebilir. Yerel bir işletme sayfası, bir temanın düzen varsayımlarıyla savaşmadan rezervasyon, güven, konum ve hizmet bilgilerini görünür kılabilir.
Çıktının hala incelenmesi gerekir. AI kötü CSS, zayıf erişilebilirlik, şişmiş JavaScript ve belirsiz metinler oluşturabilir. Bir insanın hala sayfayı incelemesi, mobil testi yapması, bağlantıları kontrol etmesi, meta verileri doğrulaması, Lighthouse çalıştırması ve yazıyı dürüst tutması gerekir.
Ancak AI, özel olmanın yavaş olduğu bahanesini ortadan kaldırır.
WordPress'in hala kazandığı durumlar
Düzenleme iş akışı ürün olduğunda hala WordPress'i seçerdim.
Bir ekip çok sayıda gönderi yayınlıyorsa, mevcut WordPress editoryal alışkanlıklarını kullanıyorsa, WooCommerce'e bağımlıysa, belirli olgun eklentilere ihtiyaç duyuyorsa veya zaten istikrarlı bir WordPress kurulumunda yılların SEO geçmişine sahipse, moda için yeniden inşa etmek kötü bir harekettir.
WordPress ayrıca özel bir ön uçtan çok tanıdık bir yönetim yüzeyine ihtiyaç duyan ekipler için de iyi çalışır. İnsanların zaten bildiği bir aracın değeri vardır.
Hata, sitenin ne yapması gerektiğini sormadan WordPress'i seçmektir.
Birçok yeni yapı için site; hız, yapı, özel tasarım, kontrollü entegrasyonlar ve düşük bakım gerektirir. WordPress bunları yapabilir, ancak genellikle bunlara ekstra katmanlar aracılığıyla ulaşır. AI destekli özel yapılar bunlara daha doğrudan ulaşır.
Pratik kuralım
Bugün WordPress'i seçmeden önce üç soru sorardım.
İlk olarak, müşterinin özellikle WordPress yönetim deneyimine ihtiyacı var mı?
İkinci olarak, bir eklenti zorlu bir iş problemini küçük özel bir entegrasyondan daha mı iyi çözüyor?
Üçüncü olarak, site on iki aylık güncellemeler, pazarlama talepleri, izleme scriptleri ve içerik değişikliklerinden sonra hala bakımı kolay olacak mı?
Cevap evet ise, WordPress doğru tercih olabilir.
Cevap hayır ise, daha hafif bir mimari ile başlar ve tam arayüzü oluşturmak için AI kullanırdım. Bu bir statik site, headless bir CMS, React veya Astro ön ucu, EmDash, Webflow, Framer veya küçük bir full-stack uygulama olabilir. Yığın, alışkanlığa değil, işe uygun olmalıdır.
AI ajanlarının yararlı olduğu yer de burasıdır. İyi bir ajan siteyi inceleyebilir, bağlantıları doğrulayabilir, meta verileri kontrol edebilir, bir yapıyı test edebilir, içeriği güncelleyebilir ve bir iz bırakabilir. Bu kontrol katmanı hakkında MCP geliştirici iş akışları makalemde→ yazmıştım. Aynı fikir web siteleri için de geçerlidir: araçlar her şeyi bir eklenti ekranının arkasına gizlemek yerine, net eylemler sunmalıdır.
Karar
WordPress, otomatik cevap olarak öldü. WordPress yazılım olarak ölmedi.
EmDash erken aşamada, ancak CMS konuşmasının nereye gittiğini gösteriyor: varsayılan olarak serverless, TypeScript dostu, ön uç yerli (frontend-native), daha güvenli eklenti sınırları ve manuel yönetim işleri yerine AI-ajan iş akışları.
Web; daha hızlı ön uçlara, daha küçük arka uçlara, AI destekli tasarıma ve nihai çıktı üzerinde daha açık kontrole doğru ilerledi. WordPress'in hala bir yeri var, ancak o yeri proje proje hak etmesi gerekiyor.
Bir yayıncılık makinesine ihtiyacınız varsa, bir tane kullanın. Tam olarak hissettiren, hızlı yüklenen ve ağır bir arka uçtan kaçınan özel bir web sitesine ihtiyacınız varsa, AI daha iyi yolu almayı kolaylaştırdı.