WordPress Ölmedi, Siz Öldürüyorsunuz

Her yıl aynı manşet çıkar: “WordPress ölüyor.” Her yıl yanlış çıkar.

W3Techs verilerine göre WordPress, 2025 itibarıyla tüm web sitelerinin %43,6’sını çalıştırıyor. CMS pazarının %62,8’i. Rakip en yakın platform Shopify, ancak %5-7’ye ulaşabiliyor. Bu tablo hiç de ölüme benzemiyor.

Peki neden bu kadar çok insan WordPress’ten şikâyet ediyor? Neden “hacklendi”, “yavaş”, “çöktü” hikâyeleri bu kadar yaygın? Çünkü sorun WordPress’te değil, WordPress’in nasıl kullanıldığında.

Ben her hafta onlarca WordPress sitesiyle uğraşıyorum. Hacklenmiş siteler, beyaz ekranlar, 500 hataları, Google’dan silinen domainler. Neredeyse her vakada ortak bir paydaş var: İhmal edilmiş bakım.

WordPress’i Kim Öldürüyor?

WordPress öldürmek için üç yol var ve bunların hiçbiri platformun kendisiyle ilgili değil.

Birincisi: Güncellemeleri görmezden gelmek. Patchstack’in 2024 raporuna göre WordPress ekosisteminde o yıl 7.966 yeni güvenlik açığı keşfedildi; bir önceki yıla göre %34 artış. Bu rakam korkutucu görünüyor ama ayrıntıya girince tablo değişiyor. Bu açıkların %96’sı, yani 7.633’ü, üçüncü taraf eklentilerden ve temalardan kaynaklanıyor. WordPress çekirdeğinde tespit edilen açık sayısı: Yalnızca 7.

Platform güvenli. Kullandığınız eklentiler güvenli olmayabilir.

İkincisi: Terk edilmiş eklentileri aktif tutmak. 2024’te keşfedilen açıkların %33’ü, kamuoyuna duyurulmadan önce yamalanmamıştı. Çünkü bu açıklar, geliştiricilerin artık güncellemediği “zombie eklentilerde” bulunuyordu. Siz o eklentiyi aktif tuttuğunuz sürece, saldırganlar için açık bir kapı bırakıyorsunuz.

Üçüncüsü: “Kur ve unut” mantığı. Pek çok site sahibi WordPress’i statik bir broşür gibi görüyor. Bir kez kurulur, bir kez tasarlanır, sonra kendi haline bırakılır. Oysa WordPress, sürekli güncellemeler, güvenlik yamaları ve performans denetimleri gerektiren canlı bir yazılım ekosistemidir. Bunu unutmak, arabanıza hiç yağ koymadan 100.000 kilometre sürmek gibidir.

Hosting Seçimi: İlk Günahın Kaynağı

WordPress sorunlarının önemli bir kısmı, daha site kurulmadan önce başlıyor: Hosting seçiminde.

Aylık 70-80₺‘lik paylaşımlı hosting paketleri, pazarlama vaatlerinde “sınırsız trafik” ve “tek tık WordPress kurulumu” sunar. Gerçekte sunduğu şey: Yetersiz RAM, eski PHP sürümleri ve aynı sunucuyu paylaşan yüzlerce başka site. Bu ortamda WordPress’in yavaş çalışması sürpriz değil, fizik kuralıdır.

Bir WordPress sitesi yavaşladığında ilk suçlanan genellikle eklentiler veya tema olur. Ama çoğu vakada asıl darboğaz sunucunun kendisidir. PHP 7.4 çalıştıran bir sunucudan PHP 8.3’ün performansını beklemek, ya da 512 MB RAM’li bir ortamda WooCommerce mağazası işletmek; bunlar eklenti optimizasyonuyla çözülecek sorunlar değil.

Burada sıklıkla karşılaştığım bir yanlış anlama var: “Hosting değiştirmek pahalı.” Oysa hosting sınırlarına takılan bir sitenin yaşadığı performans kaybı, müşteri kaybı ve SEO düşüşü, iyi bir hosting’e yapılacak yatırımdan çok daha maliyetli. Doğru altyapı bir lüks değil, bir gerekliliktir.

”Ama WordPress Karmaşık” Argümanı

Bunu çok duyuyorum ve kısmen haklılar.

WordPress’in öğrenme eğrisi var. wp-admin arayüzü bazen karmaşık görünüyor. Eklenti çakışmaları gerçek bir sorun. WordPress plugin çakışmaları, genellikle tek bir eklentinin yanlış yapılandırılmasından ya da iki eklentinin aynı işlevi yapmaya çalışmasından kaynaklanıyor.

Ama şunu sormak gerekiyor: Hangi güçlü araç karmaşık değil ki?

Shopify’da bir ürün kataloğunu API üzerinden yönetmeye çalıştığınızda, Webflow’da özel bir backend mantığı kurmaya kalktığınızda, veya Wix’in eklenti sisteminin yetersiz kaldığı noktada ne yapıyorsunuz? Her platformun sınırı ve öğrenme eğrisi var. WordPress’in farkı, sınırının neredeyse sonsuz olması ve bu sonsuzluğun beraberinde sorumluluk getirmesi.

Güç ile sorumluluk arasındaki bu denge, WordPress’in zayıflığı değil, tasarımıdır.

Performans Sorunu Değil, Mimari Sorunu

Bir WordPress sitesinin yavaşlaması çoğu zaman tek bir eklentiden değil, birikmiş mimari kararlardan kaynaklanır.

Şu senaryoyu düşünün: Bir e-ticaret sitesi kuruluyor. İlk ay 15 eklenti var, site hızlı. Altı ay içinde SEO eklentisi, form eklentisi, popup eklentisi, analiz eklentisi, güvenlik eklentisi, yedekleme eklentisi, çeviri eklentisi ekleniyor. Bir yıl sonra eklenti sayısı 45’e çıkıyor. Her biri kendi JavaScript dosyasını, kendi CSS’ini, kendi veritabanı sorgularını çalıştırıyor. Tek bir sayfa yüklenirken 200’den fazla HTTP isteği gönderiliyor.

Bu noktada “WordPress yavaş” demek, 50 uygulama açıkken donan telefona bakıp “telefon çöp” demek gibi. Sorun cihaz değil; arkada gereksiz ne varsa aynı anda çalıştırıyor olman.

Sorun platformda değil, mimaride. Doğru yapılandırılmış bir WordPress sitesi; gereksiz eklentileri temizlenmiş, veritabanı optimize edilmiş, hız optimizasyonu uygulanmış, Google Core Web Vitals’da 95+ puan alabilir. LCP 4 saniyeden 0.8 saniyeye düşen siteler, PageSpeed skoru 32’den 98’e çıkan projeler; bunlar istisna değil, doğru bakımın doğal sonucu.

Verinin Söyledikleri

Saldırıya uğrayan WordPress sitelerinin yaklaşık %61’i güncel olmayan yazılım çalıştırıyordu. Bu rakamı tersine çevirelim: Güncel tutulan sitelerin %39’unun daha az risk altında olduğu anlamına geliyor.

2024’te keşfedilen güvenlik açıklarının %43’ü kimlik doğrulaması gerektirmeden istismar edilebiliyordu. Yani saldırganın giriş yapmasına bile gerek yok; eski bir eklenti sürümü yeterli. Otomatik botlar bu açıkları 7/24 tarayıp buluyor. Bu bir siber kurgu senaryosu değil; günlük rutin.

WordPress güvenlik saldırıları vakalarını incelediğimizde gördüğüm şey şu: Sitenin yaşı veya büyüklüğü saldırıyla neredeyse hiç bağlantılı değil. Küçük bir kafe sitesi de büyük bir e-ticaret platformu da eğer bakımsız bırakılmışsa aynı risk altında.

WordPress’in Gerçek Rakibi Kim?

Wix mi? Squarespace mi? Hayır.

WordPress’in gerçek rakibi, “bunu bir arkadaşıma yaptırdım, ucuza hallettim” kararıdır.

Bu karar genellikle şöyle bir zincir oluşturuyor: Ucuz hosting → yüklenen her eklenti için “neden olmasın” mantığı → güncelleme yapılmaması → zamanla şişen veritabanı → yavaşlayan site → sonunda hacklenme veya çöküş. Sonunda ödenen maliyet, baştan doğru yapılsaydı ödenecek miktardan kat kat fazla oluyor.

Bu döngü WordPress’e özgü değil. Her platformda bu ihmal zinciri kurulabilir. WordPress’te daha görünür, çünkü platform oldukça yaygın kullanılıyor ve açık kaynak olduğu için güvenlik açıkları kamuoyuyla paylaşılıyor. Kapalı kaynaklı platformlar aynı açıkları barındırabiliyor; sadece siz haberleri göremiyorsunuz.

İhmalin Gerçek Maliyeti

Bakım yapmamak “para biriktirmek” değil, borç biriktirmek.

Bir WordPress sitesinin hacklenmesinden sonra temizleme maliyeti, projenin büyüklüğüne bağlı olarak binlerce liraya ulaşabiliyor. Buna Google’ın siteyi kara listeye alması durumunda kaybedilen organik trafik, müşteri güveninin sarsılması ve SEO sıralamasının düşmesi eklendiğinde, toplam kayıp çoğu zaman sitenin ilk yapım maliyetini aşıyor.

Proaktif bakımın maliyeti ise bunun yanında ihmal edilebilir düzeyde. Düzenli güncellemeler, aylık güvenlik taramaları ve performans denetimleri; bunlar teknik olarak karmaşık işler değil. Ama “yapılması gereken” ile “yapılan” arasındaki uçurum, WordPress ekosisteminin en büyük açığı olmaya devam ediyor.

Peki Ne Yapmak Gerekiyor?

WordPress’i seçip bırakmak değil; doğru yönetmek. Bunun pratik karşılığı birkaç temel alışkanlık:

1. Eklenti envanterinizi düzeltin. Her ay bir kez oturun, kullanmadığınız eklentileri silin. “Belki lazım olur” mantığı en tehlikeli WordPress alışkanlığıdır. 60 eklentisi olan bir site gördüğümde, 40’ının gereksiz olduğunu tahmin ediyorum ve genellikle yanılmıyorum.

2. Güncellemeleri ertelemeyin. Özellikle güvenlik yamalarını. Bir eklentinin güncelleme notunda “Security fix” yazıyorsa, o güncellemeyi yapmamak açık bir kapı bırakmaktır. Staging ortamında test edip uygulayın; doğrudan canlıya basmayın.

3. Terk edilmiş eklentileri temizleyin. WordPress deposunda son 2 yılda güncellenmemiş bir eklenti kullanıyorsanız, alternatif arayın. Bu eklentiler için güvenlik yaması gelmeyecek. Patchstack verilerine göre yamalanmamış açıkların büyük kısmı bu terk edilmiş eklentilerde bulunuyor.

4. Hosting altyapınızı değerlendirin. PHP sürümünüz 8.2 veya üstü mü? Sunucu yanıt süreniz (TTFB) 200ms altında mı? RAM ve CPU kaynakları yeterli mi? Bu soruların cevabı “hayır” ise, hiçbir eklenti optimizasyonu yeterli olmayacaktır.

5. Yedekleme yapın. “Hostingim yedek alıyor” yeterli değil. Yedekleme, sitenizin kontrolündedir; hostinginizin değil. Harici bir konuma, düzenli aralıklarla, ve en önemlisi test edilmiş yedek. Yedekten geri dönüşü hiç denemediyseniz, yedeğiniz yok demektir.

6. Bir bakım ve destek süreci kurun. WordPress’i kendi başınıza yönetmek zor geliyorsa, bu iş için profesyonel destek almak; hack sonrası temizleme maliyetinden her zaman ucuzdur. Yangın söndürmek yerine, yangın önlemek.

Son Söz

WordPress ölmüyor. İnternetin %43’ü bu platform üzerinde çalışıyor ve bu rakam her çeyrek büyümeye devam ediyor.

Ama her gün, binlerce WordPress sitesi hayatını kaybediyor; hacklenmiş, yavaşlamış, Google’dan silinmiş, kullanılamaz hale gelmiş. Bunların neredeyse tamamı önlenebilir vakalar. Platform değil, bakım eksikliği yok ediyor.

WordPress zor mu? Bazen. Sorunlu mu? Kesinlikle. Ama “zor” ile “ölü” arasındaki farkı göremeyenler, her yıl aynı manşeti atmaya devam edecek. Veriler ise her yıl aynı cevabı verecek.