Özel Kodlama mı WordPress mi? Dürüst Karşılaştırma

Genel geçer bir doğru cevap yok ve sektörün bu tartışmayı kapatmak için kullandığı sav ölçülebilir biçimde yanlış. Alışılmış iddia şu: özel kod hızlıdır, WordPress yavaştır. Sahada sıralama tersine çıkıyor — WordPress siteleri mobilde Core Web Vitals'ı Next.js sitelerinden daha sık geçiyor. Yani seçim başka bir şeye dayanmak zorunda; bu rehber de o başka şeyin ne olduğunu anlatıyor.

Biz ikisini de yapıyoruz. Hem Next.js ile özel web siteleri hem WordPress siteleri kuruyoruz ve bir müşteri için aralarında seçim yaparken teknik üstünlüğe bakmıyoruz. Baktığımız şey, siteye ikinci yılda kimin dokunacağı.

Alan verisi gerçekte ne söylüyor

HTTP Archive, Chrome User Experience Report üzerine kurulu bir Core Web Vitals Technology Report yayımlıyor. Bu rapor, veri paylaşımına izin vermiş Chrome kullanıcılarının gerçek sayfa yüklemelerini kaydediyor. Teknolojilerin laboratuvarda değil gerçek ziyaretçiler için nasıl çalıştığına dair en büyük kamuya açık karşılaştırma. Temmuz 2026 taramasında, tüm ülkeler ve tüm sıralama grupları genelinde, üç Core Web Vitals eşiğini de geçen mobil kaynakların payı şöyle.

WordPress, web geneli olan %53,2'nin biraz altında. Next.js, WordPress'in on beş puan altında. Astro, Shopify ve Wix — bir statik öncelikli çerçeve ve iki barındırmalı platform — diğer her şeyin belirgin biçimde üstünde.

Rakamı kullanmadan önce şerhini okuyun, çünkü asıl mesele o. Bu bir deney değil, popülasyon karşılaştırması. Kimse barındırmayı, sayfa türünü ya da bütçeyi sabit tutmadı. WordPress sitelerinin büyük bölümü paylaşımlı barındırmadaki tanıtım siteleri; Next.js sitelerinin büyük bölümü panelli, etkileşimli durum tutan uygulamalar — ki bunları hızlandırmak doğası gereği daha zor. Veri, WordPress'in daha iyi performansa neden olduğunu söyleyemez; biz de böyle bir iddiada bulunmuyoruz.

Söyleyebildiği şey daha dar ve daha işe yarar: modern bir çerçeve seçmek hızlı bir site üretmiyor. Üretseydi, o çerçevelerle kurulan siteler hızlı olurdu; HTTP Archive örneklemindeki 349.852 Next.js kaynağında değiller. Performans, yapım sırasında verilen kararlardan geliyor — Core Web Vitals rehberimizin ayrıntılı olarak savunduğu şey de bu.

İki yığın birbirinin tersi yerde kaybediyor

Toplam geçme oranları, seçim yapmanıza asıl yardımcı olacak bulguyu gizliyor. Aynı iki teknolojiyi metrik metrik ayırdığınızda — yine HTTP Archive, Temmuz 2026, mobil — başarısızlık biçimleri yer değiştiriyor.

WordPress, Time to First Byte'ta kaybediyor: mobil kaynaklarının yalnızca %24,4'ü iyi sayılıyor; Next.js'te bu oran %46,1, web genelinde %46,0. Bu bir sunucu sorunu — ucuz paylaşımlı barındırma, önbelleklenmemiş PHP, her istekte bir veritabanı sorgusu.

Next.js, Interaction to Next Paint'te kaybediyor: %58,8 iyi; WordPress'te %91,0. Bu bir ana iş parçacığı sorunu — arayüz dokunuşa cevap vermeden önce ayrıştırılması, hidrate edilmesi ve çalıştırılması gereken JavaScript.

Bu ikisi arasındaki fark pratikte belirleyici olan şey, çünkü TTFB sorunundan para vererek çıkabilirsiniz, INP sorununu yeniden inşa etmek zorundasınız. Bir WordPress sitesini düzgün sayfa önbelleği olan daha iyi bir barındırmaya taşımak, fiyatı belli ve sonucu aynı hafta alınan bir satın alma. Bir React uygulamasının gönderdiği JavaScript'i azaltmak ise uygulamanın ne olduğunu değiştirmek demek. Yığın seçerken aynı zamanda bu iki faturadan hangisini almayı tercih ettiğinizi de seçiyorsunuz.

WooCommerce burada ayrı bir satırı hak ediyor. Genelde %40,1, mobilde iyi TTFB oranı yalnızca %13,3 ile veri setindeki en zayıf yaygın yapılandırma — bir mağaza, en çok önem taşıyan sayfalarında önbelleği kapatılmış bir WordPress sitesidir. Bunun platform seçimi açısından anlamını WooCommerce, Shopify ve özel geliştirme yazısında ele almıştık.

Türkiye'nin popüler sitelerinin bu iki yığından hangisini gerçekte kullandığını, 162 ana sayfayı tarayarak WordPress mi Next.js mi yazısında ölçtük.

"Özel kod daha güvenlidir" neden artık otomatik değil

Güvenlik savı genelde omuz silkerek kuruluyor: WordPress tüm web sitelerinin %40,7'sini çalıştırıyor, saldırganların hedefi de bu yüzden o. Rakam gerçek — W3Techs 5 Eylül 2026'da ölçtü: 20 milyondan fazla siteden oluşan bir örneklem, WordPress'i CMS'i bilinen sitelerin %58,9'una yerleştiriyor. Ama hedef olmak, savunma değil ilgi hakkında bir bilgi; ve Temmuz 2026 bize çok daha iyi bir test verdi.

WordPress çekirdeğindeki iki açık, CVE-2026-60137 ve CVE-2026-63030, zincirlenerek varsayılan kurulumlarda kimlik doğrulaması gerektirmeyen uzaktan kod çalıştırmaya dönüştürülebiliyordu. CISA ikisini de 21 Temmuz 2026'da Known Exploited Vulnerabilities kataloğuna ekledi ve federal kurumlara 24 Temmuz ile 4 Ağustos son tarihlerini verdi. Bu, sahada sömürüldüğü doğrulanmış açıkların kataloğu; ve 1.695 kaydının yalnızca altısının WordPress'le ilgili olduğunu bilmek de anlamlı — diğer dördü yıllar önce eklenmiş eklentiler ve bir barındırma paneli.

Yani çekirdek gerçekten, ciddi biçimde delindi. Şimdi güvenlik savının hiç değinmediği kısım: WordPress 7.0.2'yi katalog kaydından önce, 17 Temmuz'da yayımladı ve WordPress.org ekibi etkilenen tüm sürümlerde otomatik güncellemeyi zorunlu hâle getirdi. Hiç giriş yapılmamış siteler projenin kendisi tarafından yamalandı.

Hiçbir özel uygulamada bu yok. Size özel yazılmış Node sitenizin bir bağımlılığında zincirlenebilir bir RCE çıkarsa, düzeltme size biri güvenlik bildirimini okuduğunda ulaşır ve biri dağıtım yaptığında yayına girer. Dürüst karşılaştırma "WordPress saldırı alır, özel kod almaz" değil. WordPress daha fazla gelen risk ve bunu kapatacak gerçek bir mekanizma taşıyor; özel kod daha az gelen risk ve hiçbir mekanizma taşımıyor.

Kimsenin fiyatlamadığı yükümlülük

Ertelenmiş bakım ölçülebilir bir şey ve bu konuşmaların kaderini performanstan çok daha fazla belirlemeli. WordPress.org, güncelleme servisine bağlanan kurulumların sürüm dağılımını yayımlıyor; PHP de hangi dallarının hâlâ güvenlik yaması aldığını. Eylül 2026 itibarıyla ikisini yan yana koyun:

• WordPress kurulumlarının %38,7'si güvenlik desteği olmayan bir PHP sürümünde çalışıyor. PHP 8.1 ve altındaki her şeyin ömrü doldu; kurulumların %17,1'i hâlâ 2022'de yama almayı bırakan PHP 7.4'te.
• %32,4'ü WordPress 6.9 ya da daha eskisini kullanıyor; güncel 7.1 dalında olanların oranı %51,8.
• Kurulumların %24,8'inin kullandığı PHP 8.2, 31 Aralık 2026'da güvenlik desteğinden çıkıyor.

Bunların hiçbiri WordPress aleyhine bir sav değil. "Güncellemeleri biz hallederiz" cümlesinin milyonlarca sitede neye dönüştüğünün ölçümü; ve aynı çürüme özel uygulamalarda da yaşanıyor — iki yıllık kilit dosyası olan bir Node projesi tam olarak aynı yerde. Fark, kimsenin o istatistiği yayımlamaması; o yüzden bir şey kırılana kadar görünmez kalıyor.

Yığını seçmeden önce bakımı fiyatlayın. İkinci yılda güncellemelerin sahibi yoksa, WordPress bunu size bir defacement'la yüksek sesle söyler; özel geliştirme ise artık yükseltemediğiniz bir bağımlılıkla sessizce.

Kararı gerçekte veren soru

Performansı ve güvenliği bir kenara koyduğunuzda ayakta tek bir soru kalıyor: yayından sonra siteyi kim, ne sıklıkla değiştiriyor?

Cevap "her hafta sayfa yayımlayan, bölüm yerlerini değiştiren, kampanya yürüten bir pazarlama ekibi" ise, doğru cevap genelde WordPress. Ürün, düzenleme modelinin kendisi. O ekibe kendine özgü bir yönetim paneli olan başsız bir CMS vermek, WordPress'in yirmi yılda oturttuğu şeyi kötü bir kopyayla yeniden yazmak için para ödemek demek.

Cevap "içerik yılda birkaç kez değişiyor, asıl önemli olan davranış" ise — teklif motoru, yapılandırıcı, üye alanı, ERP entegrasyonu — doğru cevap genelde özel geliştirme. O davranışı zaten eklenti olarak yazacaktınız; eklenti de altında bakımını yine üstlendiğiniz bir CMS olan özel koddur.

Adını koymaya değer bir üçüncü cevap var: hiç kimse. Pek çok site yayına alınıyor ve beş yılda iki kez ele alınıyor. Onlar için yığın neredeyse fark etmiyor, barındırma ise fazlasıyla ediyor — yukarıdaki TTFB verisinin söylediği şey de bu.

Nerede hayır diyoruz

WordPress'i kendimize yakıştırmamak gibi bir tavrımız yok; varsayılan olarak da önermiyoruz. Kendi tavsiyemize koyduğumuz iki dürüst sınır:

Gerçekten kendine özgü bir iş akışına ihtiyaç duyup bunun eklentilerle çözülmesini isteyen bir müşteriye WordPress sitesi yapmayız. O yol altı ay boyunca daha ucuz görünür; sonra her yükseltme, birbiriyle hiç tanışmamış dört satıcı arasında bir müzakereye dönüşür.

Asıl ihtiyacı yayıncılık olan bir müşteriye özel site yapmayız. Bu kararın doğru teknik gerekçelerle verildiğini gördük ve yine de tuttuğunu görmedik; çünkü pazarlama ekibi sonunda bir başlığı değiştirmek için geliştiriciye rica etmeye başlıyor. Darboğazınız içerik üretim hızıysa, bir çerçeve onu çözmez.

İkisini de nasıl kapsamlandırdığımızın tam resmi web sitesi yapımı rehberimizde. Kendi durumunuz için net bir cevap istiyorsanız, sitenin ne yapması gerektiğini bize anlatın; hangisini kuracağımızı ve nedenini söyleyelim — cevap satmadığımız bir platform olduğunda da.

Bir öğleden sonrada karar vermek

Şu beş soruyu sırayla yanıtlayın. Net cevap üreten ilk soru genelde tartışmayı bitirir.

1. Kim, ne sıklıkla düzenliyor? Geliştirici olmayanlarca haftalık düzenleme WordPress'i işaret eder. Nadiren ve bizim tarafımızdan düzenleme özel geliştirmeyi.
2. Değer sayfalarda mı, davranışta mı? Sayfalar WordPress'i, davranış özel geliştirmeyi işaret eder.
3. İkinci yılda güncellemelerin sahibi kim ve bütçesi var mı? Cevap "kimse" ise, zorunlu otomatik güncellemesi ve yönetilen barındırması olan seçeneği alın.
4. Site en zorlu anında ne yapıyor? Önbelleklenmiş bir WordPress sayfasındaki kampanya yığılması sorun değil. Canlı fiyat hesaplayan bir yapılandırıcı, sayfa önbelleğiyle çözülecek bir mesele değil.
5. Yerine adam bulabiliyor musunuz? W3Techs'in ölçtüğü %40,7'lik payıyla WordPress'in iş gücü havuzu derin. Kendine özgü bir yığında ise elinizde sizinkiler ve devralmaya ikna edebildikleriniz var.

Bunları dürüstçe yanıtladığınızda iki yığın rekabet etmeyi bırakıyor. Farklı soruların cevapları bunlar; karşılaştırmanın zor gelmesinin sebebi de konuyla ilgili yazıların çoğunun performans üzerinden tartışması — alan verisinin iki yönde de desteklemediği bir dava.