CMS Nedir, Hangi CMS Seçilmeli? (2026 Rehber)

İçerik yönetim sistemi (CMS, Content Management System), bir web sitesinin içeriğini kod yazmadan oluşturmanızı, düzenlemenizi ve yayınlamanızı sağlayan yazılımdır. Kısacası CMS, sitenizin yönetici paneli ve içerik altyapısıdır: yazı eklemek, görsel yüklemek, sayfa düzenlemek veya ürün güncellemek için her seferinde geliştiriciye ihtiyaç duymazsınız; tarayıcıdan girdiğiniz bir panelden işinizi yaparsınız. Bugün tüm web sitelerinin %41,9'u tek başına WordPress ile, yani bir CMS ile çalışıyor (W3Techs, Haziran 2026); CMS kullanan sitelerin ise %59,5'i WordPress. Bu rakamlar CMS'in modern web yayıncılığının ne kadar merkezinde olduğunu gösteriyor. Eğer sitenizin içeriğini düzenli güncellemeyi planlıyor ve bunu teknik bir ekibe bağımlı kalmadan yapmak istiyorsanız, bir CMS büyük olasılıkla doğru zemindir.

Bir CMS'in işini iki katmanda düşünmek faydalı olur. İçerik yönetimi katmanı (CMA, Content Management Application), içerik üretenlerin gördüğü yüzdür: yazı editörü, medya kütüphanesi, menü düzenleyici, kullanıcı/rol yönetimi. İçerik sunum katmanı (CDA, Content Delivery Application), bu içeriği alıp ziyaretçiye HTML sayfa olarak sunan arka plandır. Siz bir blog yazısını editörde yazıp "Yayınla" dediğinizde, CMS o içeriği veritabanına kaydeder ve ziyaretçi siteye girdiğinde sayfayı bu veriden üretir. Bu ayrım sayesinde içerik (metin, görsel, ürün) ile tasarım (tema, şablon) birbirinden ayrı durur; temayı değiştirdiğinizde içeriğiniz yerinde kalır, içeriği güncellediğinizde tasarımı bozmazsınız. Pratikte bu, "tasarımı bir kez yap, içeriği yüzlerce kez güncelle" demektir ve bir markanın gerçek hayattaki en sık ihtiyacı tam olarak budur.

CMS Tam Olarak Ne İşe Yarar?

CMS'in temel vaadi şudur: içerik yönetimini teknik bilgiden ayırmak. Statik bir siteyi (her sayfası elle yazılmış HTML dosyaları) güncellemek için kod bilmeniz ve dosyaları sunucuya yüklemeniz gerekir. CMS bu sürtünmeyi ortadan kaldırır. Bir CMS'in pratikte sağladığı başlıca işlevleri somutlaştıralım:

• Kodsuz içerik düzenleme: Word benzeri bir editörle (genelde WYSIWYG — "ne görüyorsan onu alırsın") başlık, paragraf, liste, görsel ve bağlantı ekleyebilirsiniz. HTML bilmenize gerek kalmaz. Modern CMS'ler blok tabanlı editörlere (WordPress'te Gutenberg gibi) geçtiği için, bir bölümü sürükleyip yeniden sıralamak ya da iki sütunlu bir düzen kurmak da kod gerektirmez.
• Medya yönetimi: Görselleri, videoları, PDF'leri merkezi bir kütüphanede tutar; modern CMS'ler görselleri otomatik yeniden boyutlandırıp WebP gibi hafif formatlara dönüştürerek site hızına katkı sağlar. Görsele açık genişlik/yükseklik atanması, beklenmedik düzen kaymasını (CLS) azaltarak Core Web Vitals'ı doğrudan etkiler.
• Çok kullanıcı ve rol yönetimi: Editör, yazar, yönetici gibi rollerle kimin neyi düzenleyebileceğini belirlersiniz. Bu hem bir iş akışı düzeni hem de doğrudan bir güvenlik meselesidir; OWASP'ın güncel listesinde de en üst sıradaki risk "Broken Access Control", yani yetki kontrolünün hatalı kurulmasıdır.
• Şablon ve tema sistemi: Tasarımı tek yerden değiştirirsiniz; bir başlık stilini güncellediğinizde tüm sayfalara yansır. Tutarlı görsel hiyerarşi bu şekilde korunur ve markanız sayfadan sayfaya dağılmaz.
• Eklenti/modül ekosistemi: Form, SEO, e-ticaret, çoklu dil, önbellekleme gibi işlevleri çoğu zaman kod yazmadan eklersiniz. WordPress'in en büyük gücü tam da bu geniş ekosistemdir (60.000'i aşkın eklenti, 10.000'i aşkın tema). Aynı genişlik aynı zamanda bir risk kapısıdır: en sık görülen güvenlik açıkları güncellenmemiş üçüncü taraf eklentilerden gelir.
• Sürüm geçmişi ve taslak yönetimi: Bir yazının önceki hâline dönebilir, taslak olarak saklayıp planlı tarihte yayınlayabilirsiniz. Bir kampanya sayfasını gece yarısı canlıya almak ya da yanlış bir düzenlemeyi tek tıkla geri almak bu sayede mümkün olur.
• SEO ve teknik altyapı: Çoğu olgun CMS, otomatik sitemap üretimi, temiz URL yapısı, meta etiket düzenleme ve yapısal veri (schema) için hazır araçlar sunar. Bu, arama görünürlüğünü en baştan doğru kurmayı kolaylaştırır.

Bu işlevler, bir web sitesinin yalnızca yayına alınmasıyla bitmediğini, asıl işin sürekli bakım ve içerik tazeleme olduğunu hatırlatır. Bakımsız bir site güvenlik ve SEO açısından hızla değer kaybeder; CMS bu sürekliliği teknik olmayan bir ekibe bile mümkün kılar. Bir web projesinin baştan sona nasıl planlandığını ve CMS adımının bu yolculukta nereye oturduğunu web sitesi nasıl yapılır rehberimizde adım adım ele alıyoruz; içerik ve SEO'nun sonradan eklenmek yerine baştan planlanması gerektiğinin altını orada çiziyoruz. İçeriğin kendisi kadar onu yayınladığınız zeminin de bir SEO temeli kurduğunu unutmamak gerekir.

CMS, Web Sitesi Kurucu ve Özel Yazılım: Üçünü Nasıl Ayırırız?

Pratikte en sık karışan üç kavram CMS, web sitesi kurucu (site builder) ve özel yazılımdır; üçü de "web sitesi yapmanın yolu" olsa da farklı sahiplik, esneklik ve maliyet profilleri taşır. Karar vermeden önce bu üçünü net ayırmak gerekir:

Bu tabloda görülen en kritik nokta sahipliktir. Hazır kurucular aslında "barındırma + CMS + tasarım" paketini birlikte sunan kapalı sistemlerdir; size hız kazandırır ama tasarımınızı ve verinizi platforma kilitler. Açık kaynak bir CMS'te kod ve veri sizin elinizde kalır. Özel yazılımda ise her şey baştan size aittir. Bu eksende daha derin bir maliyet/esneklik karşılaştırmasını hazır site mi özel yazılım mı ve özel yazılım maliyeti neye göre belirlenir yazılarında ele alıyoruz; yaklaşık bütçe aralıkları içinse web tasarım fiyatları 2026 içeriğimize göz atabilirsiniz. Fiyatların kapsama göre değiştiğini ve net rakam yerine teklif almanın daha sağlıklı olduğunu hatırlatalım.

CMS Olmadan Site Yapılamaz mı?

Yapılabilir; CMS bir zorunluluk değil, bir araçtır. Bir siteyi farklı zeminlerde yayınlayabilirsiniz ve CMS bunlardan yalnızca biridir:

• Statik / elle kodlanmış site: Sayfalar doğrudan HTML/CSS olarak yazılır ya da modern bir yapıyla (örneğin Astro ile) statik dosyalara derlenir. İçerik nadiren değişiyorsa, en hızlı ve en güvenli seçenektir çünkü çalışan bir veritabanı veya sunucu mantığı yoktur; saldırı yüzeyi dardır. Astro'nun "az JavaScript" felsefesi, INP gibi etkileşim metriklerinde de avantaj sağlar.
• Hazır site kurucu (Wix, Squarespace, Shopify): Hızlı yayın ve düşük teknik bilgi avantajı sağlar; ama esneklik ve sahiplik sınırlıdır. Tasarımcıya kod düzeyinde kontrol isteyenler için Webflow, görsel arayüzle temiz kod üreten orta-ileri seviye bir alternatiftir.
• CMS (WordPress, headless CMS): İçeriği sık güncelleyen, bir ekibin yöneteceği, blog/ürün/sayfa sayısı büyüyen siteler için doğal seçimdir.
• Özel yazılım (Next.js, Nuxt, SvelteKit): Tam kontrol, en yüksek performans ve ölçek isteyen, kendine özgü iş mantığı olan ürünler için. Maliyet ve süre en yüksek olan yoldur ama tavanı da en yüksektir.

Pratik kural nettir: içeriğinizi ne sıklıkta ve kim güncelleyecek? İçerik az ve nadir değişiyorsa CMS'in getirdiği bakım yükü (güncelleme, güvenlik, yedekleme) gereksiz olabilir. İçerik canlı, ekip kalabalık ve büyüme bekleniyorsa CMS değeri ağır basar. Hangi zeminin sizin durumunuza uyduğunu karşılaştırmalı olarak değerlendirmek için iyi web tasarımının nasıl olması gerektiğini de bir referans çerçeve olarak kullanabilirsiniz; çünkü zemin ne olursa olsun hız, erişilebilirlik ve net hiyerarşi gibi ilkeler değişmez.

Hangi CMS? WordPress, Hazır Kurucu, E-ticaret ve Headless

"Hangi CMS seçilmeli" sorusunun tek bir doğru cevabı yoktur; doğru cevap işin türüne göre değişir. Ana aileleri ve güçlü oldukları yerleri ayıralım:

• WordPress (genel amaçlı CMS): Tüm web'in %41,9'unu, CMS pazarının %59,5'ini çalıştırır. En büyük gücü dev ekosistemi ve geniş ajans/destek havuzudur; içerik ağırlıklı kurumsal siteler, bloglar ve haber siteleri için varsayılan tercihtir. Zayıf yönü bakım ve güvenlik yüküdür: çekirdek, tema ve eklentiler düzenli güncellenmezse risk hızla büyür.
• Hazır kurucular (Wix %4,3, Squarespace, Webflow): Küçük işletme, portföy ve tasarım odaklı vitrin siteleri için hızlıdır. Webflow, tasarımcıya kod düzeyinde kontrol vererek bu grup içinde ayrı bir konumda durur.
• E-ticaret altyapıları: Shopify (%5,2 küresel pay) küresel liderdir; Türkiye'de ikas, TL, kargo ve e-fatura entegrasyonlarıyla güçlü yerel bir alternatiftir. WordPress üzerinde ise WooCommerce yaygın bir e-ticaret çözümüdür. İkisi arasındaki seçimi ikas mı Shopify mı yazısında derinleştiriyoruz.
• Headless CMS (Strapi, Sanity, Contentful): İçeriğin bir API'den geldiği, sunumun (web, mobil, ekran) ayrıştığı modeldir. Modern framework'lerle (Next.js, Astro) eşleşir; çok kanallılık ve hız avantajı sunar. Karmaşıklığı ve geliştirici gereksinimi daha yüksektir, bu yüzden "her siteye" değil, içeriği birden çok yüzeye dağıtan yapılara uygundur.

Aşağıdaki tablo, sık karşılaşılan ihtiyaçlara göre hangi ailenin öne çıktığını özetler. Pazar payı rakamları W3Techs'in Haziran 2026 verisidir ve zamanla değişebilir.

CMS Kimler İçin Doğru Seçim?

CMS'i "herkese uygun tek doğru" gibi sunmak yanıltıcı olur; doğrusu, belirli profillerde net biçimde öne çıkmasıdır. Müşterilerimizde gördüğümüz tipik uygun profiller şunlar:

• Düzenli blog / içerik yayınlayan markalar: Haftalık yazı, haber, duyuru üreten kurumsal siteler ve içerik pazarlaması yapan işletmeler. İçeriğin teknik ekibe takılmadan akması kritik; özellikle uzun satış döngülü B2B sitelerinde içerik, güven ve eğitim rolünü üstlendiği için CMS doğal bir zemindir.
• İçeriğini kendi yönetmek isteyen küçük ve orta ölçekli işletmeler: Hizmet sayfalarını, fiyatları, referansları kendi güncellemek isteyen ekipler. Her küçük değişiklik için ajansa dönmek istemeyenler.
• E-ticaret yapanlar: Ürün ekleme/güncelleme, stok, kategori yönetimi sürekli bir iştir. Burada Shopify (küresel pazarda %5,2 pay) ya da Türkiye'de ikas gibi yerel güçlü altyapılar, kargo/e-fatura/TL entegrasyonlarıyla öne çıkar; WordPress üzerinde ise WooCommerce yaygındır. Maliyet planlaması için e-ticaret sitesi açmak kaç para yazımız iyi bir başlangıçtır.
• Çok kanallı içerik dağıtan kurumlar: İçeriği aynı anda web, mobil uygulama ve ekranlara sunması gereken yapılar için headless CMS (içeriğin API'den geldiği, sunumun ayrıştığı model) güçlü bir seçenektir.

Buna karşılık CMS'in zayıf kaldığı durumlar da var: tamamen özgün iş mantığı, çok yüksek trafik veya milisaniyelik performans/ölçek gereksinimi olan ürünlerde özel yazılım (örneğin Next.js tabanlı bir uygulama) daha doğru olabilir. Aynı şekilde, içeriği neredeyse hiç değişmeyen tek sayfalık bir tanıtım sitesinde ya da tek hedefe odaklı bir dönüşüm odaklı landing page kurgusunda CMS'in bakım yükü gereksiz kalabilir. Bu kararı verirken markanıza özgülük, dönüşüm kritikliği ve uzun ömür gibi ölçütleri tartmanız gerekir; özel yazılım ve web sitesi hizmetimiz kapsamında bu değerlendirmeyi sizinle birlikte yapıyoruz.

CMS Seçerken Hangi Kriterlere Bakmalı?

Doğru CMS'i seçmek bir "marka tercihi" değil, ihtiyaç eşleştirmesidir. Müşteri projelerinde aşağıdaki kriterleri sırayla sorgulamak, yanlış karar olasılığını ciddi biçimde düşürür:

• İçerik sıklığı ve ekip: İçeriği kim, ne sıklıkta güncelleyecek? Kalabalık ve teknik olmayan bir ekip için sade, sezgisel bir panel ve net rol yönetimi belirleyicidir.
• Performans tavanı: Core Web Vitals eşikleri (LCP ≤ 2,5 sn, INP ≤ 200 ms, CLS ≤ 0,1) bir sıralama sinyalidir. Ağır eklentili bir WordPress kurulumu bu eşikleri zorlayabilirken, statik/headless yapılar genelde daha iyi performans verir. Hız ile SEO ilişkisini Core Web Vitals rehberimizde derinleştiriyoruz.
• Güvenlik ve bakım yükü: Bilinen açıkların çoğu güncellenmemiş bileşenlerden sömürülür; OWASP'ın güncel listesinde "tedarik zinciri" riski artık ilk üçtedir. Eklenti sayısını sınırlı tutmak, güvenilir kaynak seçmek ve düzenli güncelleme bu yükü yönetilebilir kılar. Konunun bütününü web sitesi güvenliği yazımızda ele alıyoruz.
• SEO esnekliği: Temiz URL, özelleştirilebilir meta etiketler, otomatik sitemap, yapısal veri ve 301 yönlendirme yönetimi. Bunlar yoksa arama görünürlüğünü baştan sınırlamış olursunuz.
• Erişilebilirlik desteği: WCAG 2.2 AA artık birçok pazarda yasal eşiktir; Avrupa Erişilebilirlik Yasası 28 Haziran 2025'te yürürlüğe girdi. Seçtiğiniz tema ve editörün erişilebilir çıktı üretebilmesi önemlidir. Ayrıntı için web erişilebilirliği rehberimize bakabilirsiniz.
• Çoklu dil ve büyüme: Yarın İngilizce bir versiyon, yeni bir ürün hattı ya da farklı bir içerik tipi gerekebilir. Seçtiğiniz CMS bu büyümeyi taşıyabilmeli.
• Taşınabilirlik: İçeriğinizi ve verinizi dışa aktarabilir misiniz? Bu, gelecekte platform değiştirmeniz gerektiğinde sizi kurtaracak en önemli özelliktir.

CMS Seçimi Neden Sonradan Pahalıya Mal Olur?

CMS, bir sitenin temelidir; üstüne içerik, tasarım, SEO geçmişi ve entegrasyonlar zamanla yığılır. Bu yüzden yanlış seçilmiş bir CMS'ten çıkmak, ilk kurulumdan çok daha maliyetlidir. En çok karşılaştığımız üç bağlanma (lock-in) kaynağı:

• İçerik ve veri kilidi: Hazır kurucularda içerik ve tasarım platforma kilitlenir; başka bir yere taşımak çoğu zaman zahmetli, bazen neredeyse imkânsızdır. Açık kaynak bir CMS'te ise kod ve veri sizindir, taşınabilirlik korunur.
• SEO ve URL geçmişi: CMS değiştirirken URL yapısı değişiyorsa, eski adreslerden yenilere 301 (kalıcı) yönlendirme yapılmazsa arama sıralaması ve backlink değeri kaybolur. Bu, bir site yenileme (redesign) sürecinin en kritik kuralıdır ve CMS göçlerinde de aynen geçerlidir. Göç sonrası sitemap'i Search Console'a yeniden göndermek ve 404'leri izlemek de aynı disiplinin parçasıdır.
• Eklenti/entegrasyon bağımlılığı: Belirli bir CMS'e özgü eklentiler ve entegrasyonlar üzerine kurulu iş akışları, başka platforma geçişte yeniden inşa edilmek zorunda kalır. Ne kadar derine "özel eklenti" gömerseniz, çıkış o kadar pahalılaşır.

Bu yüzden CMS seçimini "şu an hangisi kolay" sorusuyla değil, "üç yıl sonra bu site nereye büyüyecek, içeriği kim yönetecek, hangi entegrasyonlar gerekecek" sorularıyla yapmak gerekir. Doğru seçilmiş bir CMS, yıllarca üstüne sağlıklı biçimde inşa edebileceğiniz bir zemindir; yanlış seçilmiş olanı ise her büyüme adımında sizi yavaşlatır. Mevcut bir sitenin hangi altyapı veya e-ticaret platformuyla çalıştığını merak ediyorsanız e-ticaret altyapı tespit aracımızla hızlıca kontrol edebilir; kendi projeniz için hangi CMS veya yazılım zemininin uygun olduğunu netleştirmek isterseniz ücretsiz analiz ve teklif sihirbazımız üzerinden durumunuza özel bir değerlendirme alabilirsiniz.

Popüler CMS'ler Hangileri? WordPress, Webflow, Wix, Squarespace ve E-ticarette Shopify/ikas

Kısa cevap: En çok kullanılan CMS WordPress'tir; Haziran 2026 itibarıyla (W3Techs verisi, zamanla değişir) tüm web sitelerinin yaklaşık %41,9'unu, CMS kullanan sitelerin ise %59,5'ini çalıştırır. Onu küresel web payında Shopify (%5,2) ve Wix (%4,3) izler; yani WordPress en yakın rakibinin yaklaşık dokuz katı büyüklüktedir. Webflow ve Squarespace daha niş ama güçlü tasarım odaklı seçeneklerdir. E-ticarette küresel lider Shopify'dır, Türkiye pazarında ise ikas yerli ve güçlü bir alternatiftir. Doğru tercih platformun popülerliğiyle değil, sizin esneklik, bütçe, ekip yetkinliği ve sahiplik ihtiyacınızla belirlenir.

Burada kritik bir nüans var: "CMS" terimi tek bir teknik kategori değil, en az üç farklı yaklaşımı kapsıyor. Birincisi WordPress gibi açık kaynak, kendi barındırdığınız (self-hosted) sistemler; ikincisi Wix, Squarespace, Shopify ve ikas gibi barındırılan (hosted, SaaS) kapalı platformlar; üçüncüsü ise içeriğin sunum katmanından ayrıldığı headless CMS mimarisi. Bu üç model farklı sahiplik, maliyet ve bakım dengesi sunar. Aşağıda her platformu somut güçlü ve zayıf yönleriyle ele alıp sonunda kapsamlı bir karşılaştırma tablosu veriyoruz. Hangi altyapının size uyduğunu netleştirmek için içerik yönetimi ihtiyacınızı, ekibinizin teknik seviyesini ve büyüme hedefinizi baz alın; "herkesin kullandığı" değil "sizin işinizi taşıyan" platformu seçin. CMS seçimini sürecin tamamı içinde konumlandırmak isterseniz, web sitesi yapma adımları rehberimiz ile bu yazı birbirini tamamlar; altyapının domain/hosting/SSL ayağı için ise domain, hosting ve SSL altyapı rehberimize bakabilirsiniz.

WordPress neden hâlâ açık ara lider?

WordPress'i bu kadar baskın yapan tek bir teknik üstünlük değil, ekosistemidir. 60.000'den fazla eklenti ve 10.000'den fazla tema ile neredeyse her ihtiyaca hazır bir çözüm bulunur. Pratikte bunun anlamı şudur: iletişim ve form yönetimi, SEO (meta etiketleri, site haritası, şema işaretlemesi), çok dillilik, üyelik/abonelik, randevu/rezervasyon, önbellekleme (cache) ve e-ticaret (WooCommerce) gibi ihtiyaçların hemen hepsi için olgunlaşmış, topluluk tarafından sürekli güncellenen eklentiler vardır. Açık kaynaklıdır, yani kod ve veri tamamen sizindir; bir platforma kilitlenmezsiniz (vendor lock-in yok) ve istediğiniz an başka bir hosting'e taşıyabilirsiniz. İçerik ekibi teknik bilgi olmadan yazı/sayfa yönetebilir, görsel düzenleyebilir ve yayın takvimi kurabilir; bu da onu içerik ağırlıklı, blog ve haber odaklı siteler için doğal bir tercih yapar.

Buna karşılık WordPress'in iki gerçek bedeli vardır. Birincisi bakım yükü: çekirdek (core), tema ve eklentiler düzenli güncellenmezse güvenlik açığı oluşur. Bilinen açıkların (CVE) çoğu güncellenmemiş üçüncü taraf eklentilerden sömürülür. Nitekim OWASP Top 10:2025'te "Software Supply Chain Failures" (A03) yeni bir başlık olarak listeye girmiştir ve bu tam olarak eklenti/tema/bağımlılık riskidir; ayrıca "Security Misconfiguration" maddesi #5'ten #2'ye yükselmiştir ki bu da yanlış yapılandırılmış WordPress kurulumlarının ne kadar yaygın bir saldırı yüzeyi olduğunu gösterir. İkincisi performans şişmesi: çok sayıda eklenti yüklü, ağır temalı bir WordPress sitesi kolayca yavaşlar; her eklenti kendi CSS/JavaScript dosyalarını yükler, veritabanı sorgularını artırır ve ana iş parçacığını (main thread) bloke ederek Core Web Vitals eşiklerini (LCP ≤ 2,5 sn, INP ≤ 200 ms, CLS ≤ 0,1) ıskalamasına yol açabilir. Özellikle INP tarafında ağır JavaScript doğrudan etkileşim yanıtını geciktirir.

Bu bedeller yönetilebilir, ama bilinçli yönetilmelidir: WordPress'te az ama güvenilir eklenti seçmek, kullanılmayan eklenti ve temaları tamamen silmek (devre dışı bırakmak yetmez, kod sunucuda kalır), terk edilmiş/uzun süredir güncellenmeyen eklentilerden kaçınmak, bir önbellekleme ve görsel optimizasyon katmanı kurmak ve admin hesabını iki faktörlü doğrulama (2FA) ile korumak şarttır. Sunucu tarafı doğrulama, güçlü parola ve giriş denemelerini sınırlama (rate-limit) gibi temel önlemler de WordPress'in geniş saldırı yüzeyini daraltır. Güvenlik tarafını derinlemesine ele aldığımız web sitesi güvenliği rehberimizde WordPress'e özgü riskleri ve OWASP Top 10 önlemlerini ayrıntılandırıyoruz; hız tarafı için ise Core Web Vitals ve site hızı rehberimize ya da PageSpeed Insights iyileştirme rehberimize bakabilirsiniz.

Kime uygun: Sık güncellenen blog/haber siteleri, içerik ekibi olan kurumsal siteler, çok dilli ve SEO odaklı projeler, küçük-orta bütçeli işler ve WooCommerce ile esnek e-ticaret isteyenler. Kime uygun değil: Bakım ve güncelleme sorumluluğunu taşımak istemeyen, sıfır bakımla mümkün olan en yüksek performansı arayan ya da çok özgün/uygulama benzeri bir arayüz hedefleyen ekipler.

Webflow: tasarımcıya kod düzeyinde kontrol

Webflow, görsel bir tasarım aracıdır ama çıktısı temiz, üretim kalitesinde HTML/CSS koddur. Tasarımcının kod yazmadan, ama kodun nasıl davranacağını bilerek tasarım yapmasını sağlar; bu yönüyle "sürükle-bırak site kurucu" ile "özel kod" arasında konumlanır. Webflow'da çalışırken aslında doğrudan CSS kutu modeliyle (margin, padding, flexbox, grid) iş görürsünüz, sadece bunu görsel bir arayüzden yaparsınız. Animasyon, scroll etkileşimleri ve özgün düzen (layout) kontrolü Wix'ten belirgin biçimde güçlüdür; ürettiği kod genelde daha hafif ve daha temiz olduğu için performans potansiyeli de daha yüksektir. Tasarım odaklı pazarlama siteleri, ajans portföyleri, ürün/lansman sayfaları ve marka siteleri için iyi bir orta-ileri seviye seçenektir.

Webflow'un başlıca bedeli öğrenme eğrisidir: kutu modeli, flexbox/grid, konumlandırma ve duyarlı (responsive) breakpoint mantığına aşina olmayan biri için Wix kadar kolay değildir; gücünün önemli kısmı tam da bu CSS kavramlarına hâkimiyetten gelir. İkinci bedel, abonelik tabanlı ve barındırılan bir platform olmasıdır: büyüdükçe maliyet artar ve belirli platform sınırları (form gönderim limitleri, CMS öğe sayısı, dinamik mantık kısıtları) devreye girer. İçerik yönetimi için kendi CMS koleksiyonlarını sunar; bu, blog, vaka çalışması ve katalog gibi yapılandırılmış içerik için yeterlidir, ancak WordPress eklenti ekosisteminin genişliğine (üyelik, kompleks e-ticaret, niş entegrasyonlar) ulaşmaz. Mobil-öncelikli, duyarlı tasarımı doğru kurmak isteyen tasarımcılar için Webflow'un breakpoint sistemi güçlüdür; bu disiplinin ilkelerini mobil uyumlu responsive web tasarım rehberimizde, görsel ilke tarafını ise iyi web tasarımı nasıl olmalı yazımızda ele alıyoruz.

Kime uygun: Özgün, animasyonlu ve görsel olarak iddialı pazarlama/marka siteleri isteyen, temiz kod ve iyi performans önemseyen, kod yazmadan ama tasarım kontrolünü kaybetmeden çalışmak isteyen tasarımcı/ajanslar. Kime uygun değil: Hiç teknik arka planı olmayan ve "tek tıkla yayında olmak" isteyen kullanıcılar ya da geniş eklenti ekosistemine bağımlı, karmaşık işlevsellik gerektiren projeler.

Wix ve Squarespace: hız ve kolaylık önde

Wix (küresel web payı yaklaşık %4,3), gerçek bir sürükle-bırak site kurucudur. En büyük avantajı, teknik bilgi gerektirmeden çok hızlı yayına çıkmaktır: küçük işletmeler, tek kişilik girişimler, serbest çalışanlar ve "bir an önce internette olmak isteyen" işletmeler için idealdir. Altyapı bakımı tamamen sağlayıcıdadır; güvenlik güncellemesi, sunucu yönetimi, SSL sertifikası ve yedekleme sizin işiniz değildir. Bunun karşılığında esneklik ve sahiplik düşüktür: tasarım büyük ölçüde şablonun sınırlarıyla kısıtlıdır, içerik ve tasarım platforma kilitlidir ve başka bir altyapıya taşınması neredeyse imkânsızdır (vendor lock-in). Pratik bir uyarı: Wix'te bir şablon seçtikten sonra çoğu zaman temayı sıfırlamadan başka bir şablona geçemezsiniz; bu da ileride köklü bir tasarım değişikliğini zorlaştırır.

Squarespace ise tasarım odaklı, estetik ve tutarlı şablonlarıyla öne çıkar; portföy siteleri, küçük markalar, restoran/kafe, etkinlik ve görsel ağırlıklı işler için doğal bir tercihtir. Wix'e göre tasarım tutarlılığı ve "kutudan çıkar çıkmaz şıklık" genelde daha yüksektir, ancak özelleştirme yine şablonun çizdiği sınırla kısıtlıdır. Hem Wix hem Squarespace orta düzey performans sunar; optimizasyon kontrolünüz sınırlı olduğu için, ağır görselli bir Wix/Squarespace sitesinde LCP ve CLS gibi Core Web Vitals metriklerini tam istediğiniz gibi ince ayar yapmak her zaman mümkün olmaz. Görselleri sıkıştırmak, kritik CSS'i satır içine almak veya yazı tipi yüklemesini kontrol etmek gibi ileri optimizasyonlar bu kapalı platformlarda büyük ölçüde sağlayıcının insafına kalır.

Bir not: hem Wix hem Squarespace artık kendi e-ticaret modüllerini de sunar; küçük ölçekli, az ürünlü bir mağaza için bunlar yeterli olabilir. Ancak ödeme, kargo ve fatura akışlarının Türkiye'ye özgü ihtiyaçları söz konusu olduğunda, aşağıda ele aldığımız Shopify/ikas/WooCommerce üçlüsü genellikle daha sağlam bir temel sunar.

Karar kriteri: Bütçe kısıtlı, hız öncelikli, basit bir tanıtım/vitrin sitesi istiyorsanız hazır kurucu (Wix/Squarespace) mantıklıdır. Ama markaya özgü, dönüşüm-kritik, uzun ömürlü ve entegrasyon yoğun bir proje hedefliyorsanız bu başlangıç kolaylığının bedelini esneklik ve sahiplik kaybıyla ödersiniz; üstelik aylık abonelik uzun vadede sürekli bir gider kalemine dönüşür. Bu ikilemi maliyet, esneklik, sahiplik ve ölçeklenebilirlik eksenlerinde ayrıntılı ele aldığımız hazır site mi özel yazılım mı yazısı karar verirken yol gösterir; bütçe tarafını netleştirmek isterseniz 2026 web tasarım fiyatları yazımıza da bakabilirsiniz.

E-ticaret için: Shopify mi, ikas mı, WooCommerce mu?

E-ticarette CMS seçimi içerik sitesinden tamamen farklı kriterler ister. Burada belirleyici olan tema/eklenti çeşitliliğinden çok şudur: ödeme altyapısının (sanal POS, taksit) ülkeye uyumu, kargo entegrasyonu, e-fatura/e-arşiv, stok ve varyant (beden/renk) yönetimi, sepet/ödeme akışındaki sürtünme ve yerel vergi/yasal uyum. Bir e-ticaret platformunda yavaş ödeme akışı veya başarısız bir taksit ekranı, doğrudan ciro kaybı demektir; bu yüzden mobilde ödeme deneyimi en az tasarım kadar önemlidir. Türkiye'de e-ticaret yasal metinleri (mesafeli satış sözleşmesi, ön bilgilendirme formu, iade/cayma koşulları) ile KVKK aydınlatma ve çerez uyumu da seçilen platformda doğru kurulabilmelidir.

Shopify (küresel web payı yaklaşık %5,2) dünya çapında lider e-ticaret platformudur; barındırılan (hosted) yapısıyla altyapı, güvenlik ve ölçek derdini büyük ölçüde ortadan kaldırır, çok geniş bir uygulama (app) ekosistemi sunar ve trafik arttıkça sorunsuz ölçeklenir. Uluslararası satış, çoklu para birimi ve global lojistik söz konusu olduğunda olgunluğu rakipsizdir. Türkiye'de en büyük pratik zorluğu, yerel ödeme ve fatura akışlarının (yerli sanal POS, taksit, e-fatura/e-arşiv) her zaman sorunsuz oturmamasıdır; çoğu zaman aracı uygulamalar veya ek entegrasyon çalışması gerekir.

ikas, tam da bu noktada öne çıkan yerli alternatiftir: Türkiye pazarına göre tasarlanmış kargo entegrasyonları, e-fatura/e-arşiv akışları, TL bazlı yönetim ve yerel ödeme/banka POS sağlayıcılarıyla uyum sunar. Türkiye odaklı satış yapan, yerel operasyon, kargo ve mevzuat uyumunu önceleyen işletmeler için ikas çoğu zaman daha az sürtünmeli bir kurulum ve günlük operasyon deneyimi verir. Kapalı/barındırılan olması nedeniyle Shopify'a benzer bir sahiplik kısıtı taşır, ancak yerel iş akışları söz konusu olduğunda bu kısıtı fazlasıyla telafi edebilir. İki platformu yan yana koyup hangi durumda hangisinin avantajlı olduğunu ele aldığımız ikas mı Shopify mi karşılaştırmamız bu kararı netleştirir; Shopify tarafında adım adım kurulum için Shopify mağaza nasıl açılır rehberimize, e-ticareti baştan kurmanın maliyetini görmek için ise e-ticaret sitesi açmak kaç para yazımıza bakabilirsiniz.

Üçüncü yol WooCommerce'tur: WordPress üzerine kurulu açık kaynak bir e-ticaret eklentisidir. Zaten WordPress kullanan, içerik (blog/SEO) ve mağazayı tek çatıda toplamak isteyen, tam kontrol ve açık kaynak sahipliği arayan işletmeler için uygundur; ödeme, kargo ve fatura için Türkiye'ye özgü eklentiler de mevcuttur. Bedeli, Shopify/ikas'ın barındırılan kolaylığının aksine, hosting, SSL, güvenlik güncellemeleri, yedekleme ve performans optimizasyonunun tamamen sizin sorumluluğunuzda olmasıdır; ürün ve trafik arttıkça WordPress+WooCommerce kurulumu ciddi bir sunucu ve önbellekleme stratejisi ister. Bir başka pratik soru da rakip analizidir: bir rakibinizin hangi e-ticaret altyapısını kullandığını merak ediyorsanız, e-ticaret altyapı tespit aracımızla hızlıca kontrol edebilir; dönüşüm tarafını iyileştirmek için ise e-ticarette dönüşüm oranı artırma (CRO) rehberimizden faydalanabilirsiniz.

Headless CMS ve modern framework'ler: bir üst seviye

Geleneksel CMS'in ötesinde, içeriğin bir API'den geldiği ve sunum (frontend) katmanının bundan tamamen ayrıldığı headless yaklaşım vardır. "Baş" (head), yani kullanıcıya görünen arayüz, içerik deposundan ayrıldığı için bu isimle anılır. Burada üç popüler seçenek öne çıkar: Strapi (açık kaynak, kendi sunucunuzda barındırırsınız, tam kontrol), Sanity (gerçek zamanlı işbirliği, çok esnek içerik modelleme) ve Contentful (kurumsal ölçek, olgun süreçler). Bu sistemler genelde Next.js veya Astro gibi modern framework'lerle eşleşir ve içeriği tek bir kaynaktan web sitesine, mobil uygulamaya, dijital ekranlara ve hatta sesli arayüzlere besler. Avantajı yüksek hız (statik üretim + edge dağıtım), güvenlik (saldırı yüzeyi daha küçük) ve çok kanallılıktır; bedeli, kurulum ve sürekli bakım için geliştirici ekip gerektirmesi ve içerik editörü deneyiminin WordPress kadar "hazır" gelmemesidir.

Sunum tarafında 2026'nın manzarası şöyle özetlenebilir: React/Next.js en yaygın seçenek olup sunucu tarafı işleme (SSR) ve statik üretim (SSG) destekleriyle uygulama benzeri, dinamik ve SEO dostu siteler için güçlüdür; Astro "az JavaScript" felsefesiyle içerik odaklı, çok hızlı statik siteler üretir ve varsayılan olarak tarayıcıya minimum betik gönderdiği için Core Web Vitals açısından avantajlıdır; Vue/Nuxt React'e göre öğrenmesi genelde daha kolay bir alternatiftir; SvelteKit ise derleme aşamasında işin çoğunu hallederek çok hafif çıktı üretmesiyle dikkat çeker. Bu yaklaşımlar en yüksek performansı ve tam kontrolü verir, ancak maliyet ve geliştirme süresi olarak da en üst basamaktır; bu nedenle özgün ürün, yüksek trafik, ölçek ve performans-kritik dönüşüm hedefi olan projeler için anlamlıdır. Bu seviyede çoğu zaman tek bir CMS değil, ihtiyaçlara göre kurgulanmış bir mimari söz konusudur; böyle bir projeyi birlikte planlamak için özel yazılım ve web sitesi hizmetimize göz atabilirsiniz.

Sahiplik, lock-in ve maliyet modeli: gözden kaçan ama belirleyici eksen

Platform seçiminde çoğu kişi tasarım ve kolaylığa odaklanır, ama uzun vadede asıl farkı sahiplik (ownership) ve maliyet modeli yaratır. İki temel model vardır. Birincisi, barındırılan/SaaS platformlar (Wix, Squarespace, Shopify, ikas): başlangıç maliyeti düşük ve öngörülebilirdir, çünkü aylık/yıllık abonelik ödersiniz ve altyapı bakımı dahildir. Ancak içerik, tasarım ve çoğu zaman müşteri verisi platforma bağlıdır; platformdan çıkış (göç) zordur ve abonelik süresince ödeme devam eder. İkincisi, açık kaynak/self-hosted veya özel yazılım (WordPress, WooCommerce, headless, Next.js): kod ve veri sizindir, taşınabilir ve özelleştirilebilirsiniz; ön maliyet daha yüksektir ama bir platforma kilitli kalmazsınız. Burada "ucuz" görünen aylık abonelik, üç-beş yıllık ufukta sahiplik kaybıyla birlikte düşünülmelidir.

Lock-in'in pratik bir sonucu da yenileme (redesign) ve göç maliyetidir. Açık kaynak bir sitede ileride tasarımı yenilerken içerik ve URL yapısını koruyabilir, gerektiğinde eski URL'lerden yenilere kalıcı 301 yönlendirmeleriyle SEO değerini taşıyabilirsiniz. Kapalı bir platformdan çıkışta ise hem içeriği yeniden taşımak hem de URL yapısını korumak çok daha sancılıdır. Site yenilerken SEO kaybetmemenin kuralları ve göç planı için web sitesi yenileme (redesign) rehberimize bakabilirsiniz. Özetle: platform seçimi yalnızca bugünün ihtiyacını değil, üç yıl sonra siteyi büyütme, taşıma veya yenileme özgürlüğünü de belirler.

Hangi CMS'i seçmeli? Özet karar tablosu

Aşağıdaki tablo, platformları tasarımcı ve işletme gözüyle yan yana koyar. Tek bir "en iyi CMS" yoktur; doğru seçim projenizin bütçesine, ekibinizin teknik seviyesine, esneklik ve sahiplik ihtiyacına bağlıdır. Pazar payı rakamları Haziran 2026 (W3Techs) itibarıyladır ve zamanla değişir.

Pratik kural olarak şu eşleştirmeler işe yarar: hızlı, ucuz ve basit bir tanıtım sitesi için hazır kurucu (Wix/Squarespace) ya da WordPress; içerik ağırlıklı, ekibin sürekli düzenleyeceği bir site için WordPress veya headless CMS; tasarımın iddialı olduğu marka/pazarlama siteleri için Webflow; özgün, yüksek trafikli ve performans-kritik bir ürün için ise özel yazılım (Next.js/Astro vb.) doğru yöndür. E-ticarette küresel ölçek ve uluslararası satış için Shopify, Türkiye odaklı satış ve yerel operasyon uyumu için ikas, içerik ile mağazayı tek açık kaynak çatıda toplamak için WooCommerce öne çıkar. Seçimi yaparken üç soruyu netleştirin: içeriği kim, ne sıklıkta yönetecek; ekibinizin teknik seviyesi nedir; ve üç yıl sonra bu siteyi büyütüp taşıyabilmek sizin için ne kadar önemli. Hangi yolun işinize ve bütçenize uygun olduğundan emin değilseniz, projenizi birlikte değerlendirmek için ücretsiz analiz sihirbazımızı kullanabilir veya web ve mobil UI/UX tasarımı hizmetimiz üzerinden doğru altyapıyı birlikte seçebilirsiniz.

Headless CMS ve Özel Yazılım Ne Zaman Mantıklı?

Kısa cevap: İçeriğiniz tek bir web sitesinden fazlasına besleniyorsa (web + mobil uygulama + dijital ekran + kiosk + sesli asistan) headless CMS; ürünün kendisi karmaşık iş mantığı, yüksek trafik ve markaya özgü özel akışlar içeriyorsa özel yazılım mantıklıdır. Geleneksel WordPress gibi "monolitik" bir CMS, içerik yönetimi ile sunum katmanını tek pakette birleştirir; küçük-orta pazarlama sitelerinin büyük çoğunluğu için fazlasıyla yeterlidir ve nitekim WordPress hâlâ tüm web'in yaklaşık %41,9'unu, CMS pazarının %59,5'ini çalıştırır (W3Techs, Haziran 2026). En yakın rakibi Shopify (%5,2) ve Wix (%4,3) ile arada yaklaşık dokuz katlık bir fark vardır; yani "varsayılan" tercih hâlâ açık ara monolitik CMS'tir. Headless ve özel yazılım, bu standart kalıbın darboğaza döndüğü özel durumlar için vardır; "daha modern görünüyor" diye seçilen varsayılan değildir. Bu ayrımı net kurmak, çoğu projede bütçeyi ve süreyi koruyan en kritik karardır. Bu yazının üst başlığında ele aldığımız CMS seçim mantığını ve hazır site mi özel yazılım mı karşılaştırmasını burada bir adım derinleştiriyoruz; altyapının domain/hosting/SSL tarafını ise altyapı rehberimizde bulabilirsiniz.

Headless CMS Nedir, Geleneksel CMS'ten Farkı Ne?

Geleneksel (monolitik) bir CMS'te içerik yönetimi paneli, veritabanı ve sayfayı çizen sunum katmanı (tema) tek bir uygulamadır. WordPress'te bir yazı yazarsınız, aynı sistem onu HTML olarak ziyaretçiye sunar; içerik, veritabanı ve tema aynı çatı altında "yapışıktır". Headless CMS'te ise "baş" (head), yani sunum katmanı koparılır: içerik bir yönetim arayüzünde tutulur ama dışarıya yalnızca bir API (genelde REST veya GraphQL) üzerinden ham veri olarak verilir. Sayfayı çizme işini ayrı bir ön yüz (front-end) üstlenir — tipik olarak Next.js, Astro veya benzeri modern bir framework. "İçerik API'den gelir, sunum ayrıdır" cümlesi headless'in özünü tek satırda tarifler.

Bu farkı somutlaştırmak için iki mimariyi yan yana koyalım:

Bu mimarinin pratik sonucu şudur: aynı içerik kaynağı birden fazla "uç noktayı" besleyebilir. Bir ürün açıklamasını tek yerde düzenlersiniz; o veri hem web sitenize, hem mobil uygulamanıza, hem mağazadaki dijital ekrana, hem de bir sesli asistana aynı API'den akar. Tek bir CMS'i tek bir web sitesine kilitlemek yerine içeriği "çok kanallı" (omnichannel) bir kaynak hâline getirirsiniz. Yaygın headless çözümler arasında Strapi (açık kaynak, kendi sunucunuzda barındırırsınız — veri ve kod tamamen sizde, platform kilidi yok), Sanity (gerçek zamanlı iş birliği, çok esnek içerik modeli, yapılandırılmış içerik) ve Contentful (kurumsal ölçek, olgun altyapı, geniş entegrasyon) öne çıkar. Bunlar modern framework'lerle — Next.js veya Astro ile — eşleştiğinde hem hız hem çok kanallılık avantajı sağlar. WordPress'i de "headless modda" kullanmak mümkündür (REST/GraphQL API üzerinden içerik verip ön yüzü ayrı kurarsınız); yani headless bir ürün değil, bir mimari yaklaşımdır.

Headless CMS Ne Zaman Gerçekten Mantıklı?

Headless'i "trend olduğu için" seçmek en sık gördüğümüz hatadır; her ekstra mimari katman bakım, geliştirme süresi ve maliyet demektir. İçeriği tek web sitesinde sunan bir kurumsal sitede headless'in vaat ettiği çok kanallılık avantajı çoğunlukla teoride kalır, karmaşıklığı ise hemen başlar. Bizim müşterilerimizde net fayda gördüğümüz senaryolar şunlardır:

• Çok kanallı içerik: Aynı içeriği web + mobil uygulama + ekran/kiosk gibi birden fazla yüzeyde kullanıyorsanız, içeriği tek kaynakta tutup hepsini API'den beslemek tekrarlı emeği ortadan kaldırır. Örneğin bir kampanya metnini web'de, uygulamada ve mağaza ekranında ayrı ayrı güncellemek yerine tek yerde değiştirir, her kanal otomatik tazelenir. Tek bir web siteniz varsa bu avantaj çoğunlukla teorik kalır.
• Performans ve Core Web Vitals hassasiyeti: Ön yüzü Next.js/Astro ile statik veya edge'de üretip yalnızca gerekli JavaScript'i göndererek LCP'yi 2,5 sn altına, INP'yi 200 ms altına, CLS'yi 0,1 altına çekmek daha kontrol edilebilir hâle gelir. Astro'nun "az JavaScript" felsefesi, INP'yi bozan ağır ana iş parçacığı (main thread) yükünü baştan azaltır; çünkü INP, 12 Mart 2024'te FID'in yerini aldığından beri sadece ilk girişi değil tüm etkileşimlerin yanıt hızını ölçer ve ağır JavaScript'e karşı acımasızdır. CWV'nin tasarım ve geliştirme tarafını ayrıntılı ele aldığımız site hızı ve SEO Core Web Vitals rehberimiz ile ölçüm tarafını anlattığımız PageSpeed Insights rehberimiz bu noktada tamamlayıcıdır.
• Geliştirici ekibi ve özel ön yüz ihtiyacı: Tasarımınız standart tema kalıplarının dışına çıkıyorsa, ön yüzü kod düzeyinde özgürce kurmak istiyorsanız headless bu özgürlüğü verir. Sunum katmanı tema motoruna mahkûm değildir; görsel hiyerarşiyi, mikro etkileşimleri ve dönüşüm akışını piksel düzeyinde kurgulayabilirsiniz.
• Güvenlik yüzeyini daraltma: İçerik yönetim paneli (admin) ziyaretçiye açık ön yüzden tamamen ayrı bir sunucuda durabildiği için saldırı yüzeyi küçülür. WordPress'te en büyük riskin güncellenmemiş üçüncü taraf eklentiler olduğu düşünüldüğünde — OWASP Top 10:2025'te Software Supply Chain Failures (A03) artık ayrı bir madde olarak listede ve Security Misconfiguration #5'ten #2'ye yükseldi — bu mimari ayrım pratik bir güvenlik kazancıdır. Konuyu derinleştirmek için web sitesi güvenliği rehberimize bakabilirsiniz.

Buna karşılık headless'in maliyeti vardır ve bunu baştan bilmek gerekir. İçerik editörü artık "yazdığını anında sayfada görme" konforunu kolayca bulamaz — önizleme (preview) ortamı ayrıca kurulmalıdır; aksi halde editör değişikliğini yayınlamadan göremez. İki ayrı sistem (CMS + ön yüz) ayrı bakım, ayrı dağıtım (deploy) ve ayrı izleme ister. Basit bir kurumsal tanıtım sitesi için bu karmaşıklık çoğu zaman gereksizdir; ekibin içerik güncellemesi yavaşlar, küçük bir değişiklik bile geliştirici müdahalesi gerektirebilir. Pratik kuralımız: tek web siteniz var, ekip içeriği kolayca düzenlesin istiyorsanız geleneksel CMS yeterlidir; içerik birden çok kanala dağılıyor veya ön yüz performans/tasarım açısından kritikse headless mantıklıdır.

Özel Yazılım Ne Zaman Mantıklı?

Özel yazılım (Next.js/React gibi framework'lerle sıfırdan geliştirilen ürün), CMS'in de ötesinde bir karardır: burada artık "içerik yönetilen bir site" değil, "bir uygulama" yaparsınız. Tam kontrol, en yüksek performans ve sınırsız özelleştirme sunar; karşılığında en yüksek ön maliyet ve en uzun geliştirme süresini ister. Aşağıdaki sinyallerden birden fazlası varsa özel yazılım masaya gelmelidir:

• Karmaşık iş mantığı: Standart "sayfa + form" kalıbının dışına çıkan hesaplama, dinamik fiyatlandırma, rezervasyon/randevu, üyelik seviyeleri, kullanıcıya özel panel/dashboard, ödeme akışları, üçüncü taraf API entegrasyonları gibi özel akışlar varsa, hazır şablonlar ve eklentiler hızla yetersiz kalır. Eklenti üstüne eklenti yığmak "şişme" (bloat), çakışan kod ve performans kaybı üretir; her yeni eklenti aynı zamanda yeni bir güvenlik ve uyumluluk yüzeyidir.
• Yüksek trafik ve ölçek: Statik/edge mimarisiyle üretilen özel yazılım genelde en hızlı ve en iyi ölçeklenen seçenektir; ağır eklentili bir WordPress kurulumu aynı trafikte yavaşlayabilir, önbellek ve sunucu maliyeti büyür. Mobil trafiğin küresel olarak yaklaşık %60 olduğu ve Google'ın mobil-öncelikli indekslemeyi varsayılan yaptığı bir ortamda, mobilde hızlı kalmak doğrudan SEO ve dönüşüm meselesidir.
• Markaya özgü, dönüşüm-kritik deneyim: Her piksel ve her etkileşim dönüşüm hedefinize göre kurgulanacaksa, tema sınırlarına sıkışmadan tasarlamak istersiniz. Dönüşüm odaklı landing page rehberimizdeki ilkeleri — tek net CTA, az alanlı form, güçlü görsel hiyerarşi, sosyal kanıt — tema kısıtı olmadan uygulamak özel yazılımda daha kolaydır. Genel UI/UX disiplinini ise UI/UX tasarım yazımızda ele alıyoruz.
• Uzun ömür ve sahiplik: Hazır kuruculardaki platform kilidini (vendor lock-in) ve aylık abonelik bağımlılığını istemiyorsanız, kod ve veri tamamen sizde olduğunda taşınabilirlik ve kontrol elinizde kalır. Platform kapanırsa, fiyat politikası değişirse veya bir özelliği kaldırırsa esir kalmazsınız.
• Erişilebilirlik ve yasal uyum üzerinde tam kontrol: WCAG 2.2 AA hedeflerini (yeterli kontrast, görünür odak halkası, minimum dokunmatik hedef boyutu, etiketli form alanları) tema kısıtı olmadan, semantik HTML düzeyinde kurmak istiyorsanız özel ön yüz avantaj sağlar. AB'ye ürün/hizmet satan firmalar için 28 Haziran 2025'te yürürlüğe giren Avrupa Erişilebilirlik Yasası (EAA), EN 301 549 / WCAG 2.1 AA uyumunu zorunlu kıldığından bu kontrol giderek daha kritik hale geliyor. Ayrıntı için web erişilebilirliği rehberimize göz atın.

Önemli bir nüans: headless CMS ile özel yazılım birbirinin alternatifi olmak zorunda değildir; sıkça birlikte kullanılırlar. Özel bir Next.js uygulamasının içerik tarafını (blog, kampanya sayfaları, SSS) bir headless CMS'e (örneğin Strapi veya Sanity) bağlarsınız: pazarlama ekibi içeriği kod bilmeden günceller, geliştirici ekip uygulamanın çekirdeğine — ödeme, hesap, panel mantığına — odaklanır. Böylece "her şey koda gömülü, içeriği güncellemek için her seferinde geliştirici gerekiyor" tuzağına düşmezsiniz. Bu hibrit yaklaşım, içerik ağırlıklı ama aynı zamanda uygulama mantığı olan projelerde çoğu zaman en dengeli çözümdür.

Maliyet ve Süre: Karar Verirken Ne Beklemeli?

Maliyet, bu kararın çoğu zaman belirleyici eksenidir; ama yalnız ön maliyete bakmak yanıltıcıdır — bakım yükü, sahiplik ve uzun vadeli abonelik bağımlılığı da hesaba katılmalıdır. Genel çerçeve şöyledir:

Özel yazılımın yüksek ön maliyetinin karşılığında uzun vadede abonelik bağımlılığı olmaması önemli bir kalemdir; aylık platform ücreti ödemezsiniz, kod sizindir. Ancak bu, projenin bütçesi ve ömrü gerçekten bunu hak ediyorsa anlamlıdır. Kısa vadeli, bütçesiz ve basit bir ihtiyacı özel yazılımla çözmek, çoğu zaman gereğinden fazla harcamadır — aynı işi iyi kurgulanmış bir CMS hem daha ucuza hem daha hızlı yapar. Tersi de doğrudur: karmaşık bir iş mantığını eklentilerle zorlamak, başta ucuz görünüp zamanla bakım kabusuna ve performans borcuna dönüşebilir. Özel yazılımın maliyetini neyin belirlediğini — kapsam, entegrasyon sayısı, tasarım özgünlüğü, bakım — ayrıntılı kırdığımız özel yazılım maliyeti neye göre belirlenir yazımız ve genel bütçe çerçevesini verdiğimiz web tasarım fiyatları 2026 yazımız, teklif almadan önce beklentinizi netleştirmeniz için iyi bir başlangıçtır. Genel ilke olarak fiyatlar yaklaşıktır ve kapsama göre ciddi değişir; net bir rakam dayatan değil, ihtiyacınızı dinleyip kapsam çıkaran bir yaklaşım daha sağlıklıdır.

Sık Yapılan Hatalar: Mimari Seçiminde Nelere Dikkat Etmeli?

Müşterilerimizde tekrar tekrar gördüğümüz, sonradan pahalıya patlayan birkaç tipik hata var. Bunları baştan bilmek, doğru kararı vermenin yarısıdır:

• "Modern olsun" diye headless seçmek: Tek bir kurumsal tanıtım sitesinde headless'in çok kanallılık avantajı kullanılmazken, önizleme eksikliği ve çift sistem bakımı ekibi yavaşlatır. İhtiyaç yoksa karmaşıklık net bir kayıptır.
• Eklenti yığarak özel yazılımı taklit etmek: Karmaşık iş mantığını onlarca eklentiyle WordPress'e zorlamak, performansı düşürür ve her eklenti yeni bir güvenlik/uyumluluk yüzeyi açar. Bilinen açıkların çoğu güncellenmemiş üçüncü taraf bileşenlerden sömürülür.
• Önizleme ve editör deneyimini hesaba katmamak: Headless'e geçerken içerik ekibinin "anında görme" konforunu kaybetmesi, en sık atlanan maliyet kalemidir. Preview ortamı baştan planlanmazsa içerik üretimi tıkanır.
• Sahiplik ve taşınabilirliği göz ardı etmek: Hazır kuruculardaki platform kilidi, büyüme anında "çıkış" maliyetini ortaya çıkarır. Uzun ömürlü, markaya kritik bir projede veri ve kodun sizde olması stratejik bir tercihtir.
• SEO mirasını korumadan altyapı değiştirmek: CMS'ten headless'e ya da özel yazılıma geçerken URL yapısı değişiyorsa, eski adreslerden yeniye kalıcı 301 yönlendirme şarttır; aksi halde sıralama ve backlink değeri kaybolur. Bu konuyu web sitesi yenileme rehberimizde ayrıntılı işliyoruz.

Doğru Kararı Nasıl Verirsiniz?

Pratik bir karar çerçevesi olarak şu üç soruyu sırayla yanıtlamanızı öneririz. Birincisi: İçeriğim kaç farklı yüzeyde kullanılacak? Sadece bir web sitesiyse geleneksel CMS; web + uygulama + ekran gibi birden çoksa headless'i değerlendirin. İkincisi: Ürünümde standart "sayfa + form" dışında karmaşık iş mantığı var mı? Yoksa CMS yeterli; varsa (panel, hesaplama, rezervasyon, üyelik, ödeme, yoğun entegrasyon) özel yazılımı masaya alın. Üçüncüsü: Performans, tasarım özgünlüğü ve dönüşüm bu proje için ne kadar kritik? Kritikse — örneğin her milisaniyenin ve her etkileşimin dönüşüme etkisi varsa — ön yüzü tam kontrol edebileceğiniz headless veya özel yazılım öne çıkar.

Bu üç sorunun cevabını bir arada düşünün: çoğu zaman tek bir sinyal değil, sinyallerin birleşimi kararı netleştirir. Tek kanal + basit mantık + standart tasarım ise geleneksel CMS neredeyse her zaman doğru cevaptır. Çok kanal + performans hassasiyeti varsa headless; karmaşık mantık + ölçek + uzun ömür varsa özel yazılım öne çıkar. Aradaki gri bölgede ise hibrit (özel yazılım + headless içerik katmanı) çoğu zaman en dengeli yoldur.

Çoğu kurumsal tanıtım sitesi için doğru cevap hâlâ iyi kurgulanmış geleneksel bir CMS'tir; headless ve özel yazılım, ihtiyaç gerçekten oradayken devreye girer. Bu yüzden bir B2B veya kurumsal site planlıyorsanız, önce kurumsal web sitesi nasıl olmalı ve B2B web sitesi nasıl tasarlanır yazılarımızdaki bölüm ve güven öğeleri kontrol listesini netleştirmek, mimari kararından önce gelir. Hangi mimarinin işinize uyduğundan emin değilseniz, önce ihtiyacınızı netleştirmek en doğru adımdır: işinizi, trafik beklentinizi ve içerik akışınızı birlikte değerlendirip uygun altyapıyı çıkarmak için ücretsiz analiz ve teklif sihirbazımızı kullanabilir veya özel yazılım ve web sitesi geliştirme hizmetimiz kapsamında bizimle konuşabilirsiniz. Yanlış mimari seçimi sonradan en pahalı düzeltilen hatalardan biridir; doğru kararı baştan vermek, tüm projenin getirisini belirler.

Doğru CMS'i Seçme Kriterleri: Neye Göre Karar Vermeli?

Doğru CMS seçimi, "en popüler olanı kur" sorusu değildir; ihtiyaç, ölçek, ekip, bütçe, bakım kapasitesi, SEO ve güvenlik gereksinimlerinin kesişiminde verilen bir karar matrisidir. Aynı altyapı bir butik için doğru, bir kurumsal ihracatçı için yanlış olabilir. Kısa cevap: önce iş ihtiyacınızı ve büyüme planınızı netleştirin, sonra bu yedi kriteri tek tek puanlayıp size en az sürtünmeyi ve en düşük toplam sahip olma maliyetini (TCO) veren platformu seçin. Müşterilerimizde gördüğümüz en pahalı hata, kararı baştan değil de 18 ay sonra "platformu değiştirelim" noktasında vermek oluyor; o aşamada içerik göçü, URL haritalama, yeniden tasarım ve SEO değeri taşıma maliyeti, ilk doğru seçimin maliyetinin kat kat üzerine çıkıyor. Aşağıda her kriteri somut karar eşikleriyle açıyoruz. Genel platform manzarası ve teknoloji seçenekleri için web sitesi nasıl yapılır 2026 rehberi yazımız bütünsel çerçeveyi veriyor; hazır kurulum ile özel geliştirme tartışmasını ise hazır site mi özel yazılım mı yazısında ayrıntılandırdık.

Kriterlere geçmeden önce bir hatırlatma: bu yedi başlık birbirinden bağımsız değil. Ekip yetkinliği bütçeyi, bütçe bakım modelini, bakım modeli güvenlik yüzeyini etkiler. Bu yüzden tek bir kriteri "en önemli" ilan edip diğerlerini ihmal etmek yerine, hepsini ağırlıklandırıp toplam puana bakmak gerekir. Aşağıdaki tablo, bölümün sonunda detaylandırdığımız karar akışının özetidir.

1) İhtiyaç ve İçerik Tipi: Site Ne İş Yapacak?

İlk kriter teknik değil işlevseldir: site neyi başaracak? Çünkü içerik tipi platformu belirler. Müşterilerimizle her zaman bu soruyla başlarız, çünkü "güzel görünsün" hedefi tek başına hiçbir teknik kararı vermez. Doğru soru "hangi CMS güzel?" değil, "içeriğim hangi yapıda akıyor?" sorusudur.

• İçerik ağırlıklı (blog, haber, kurumsal tanıtım): Sık güncellenen, editörlerin yönettiği metin/görsel ağırlıklı yapı → klasik CMS (WordPress) veya headless CMS güçlü adaydır. WordPress, tüm web'in %41,9'unu, CMS pazarının ise %59,5'ini çalıştırıyor (W3Techs, Haziran 2026) ve bu hâkimiyetin ana sebebi tam da içerik yönetimindeki olgunluğudur. Kategoriler, etiketler, yazar yönetimi, taslak/yayın akışı gibi editöryel ihtiyaçlar burada hazır gelir.
• E-ticaret (ürün, sepet, ödeme): Katalog, varyant, stok, ödeme ve kargo gerektirir. Küresel lider Shopify (tüm web payı %5,2, WordPress'ten sonra en yakın altyapılardan biri); Türkiye'de ise ikas, TL, yerel kargo entegrasyonları ve e-fatura uyumuyla güçlü yerel alternatif. WooCommerce ise WordPress üzerinde popüler bir yoldur ve mevcut bir WordPress sitesine mağaza eklemek isteyenler için doğal bir geçiş sağlar.
• Çok kanallı / uygulama-benzeri (web + mobil + ekran/kiosk): İçeriğin API'den birden çok yüzeye dağıtılması gerekiyorsa headless CMS (Strapi, Sanity, Contentful) + modern framework (Next.js, Astro) mantıklıdır. Burada içerik bir kez girilir, web sitesinde de mobil uygulamada da mağaza içi ekranda da aynı kaynaktan beslenir.
• Özgün iş mantığı (rezervasyon, hesaplama, panel, entegrasyon yoğun): Hazır CMS kalıplarına sığmayan işler özel yazılıma (Next.js/React) yönelir; tam kontrol ve en yüksek performans, ama daha yüksek maliyet ve süre. Bir rezervasyon motoru, bir fiyat hesaplayıcı ya da üçüncü taraf ERP/CRM ile derin entegrasyon gerektiren akışlar bu sınıfa girer.

Karar kuralı net: içeriğiniz "metin + görsel + sayfa" ekseninde dönüyorsa CMS, "ürün + ödeme" ekseninde dönüyorsa e-ticaret altyapısı, "özgün akış + entegrasyon" ekseninde dönüyorsa özel yazılım. Sınırda kalan bir örnek verelim: çoğu sayfası kurumsal tanıtım olan ama küçük bir ürün satışı da yapacak bir firma için, baştan ağır bir e-ticaret platformuna geçmek yerine WordPress + WooCommerce veya headless bir kurguyla "ağırlıklı içerik, hafif mağaza" dengesi kurmak daha doğru olabilir. E-ticaret özelinde Türkiye gerçekleriyle karşılaştırma için ikas mı Shopify mı yazımıza, sıfırdan mağaza açma adımları için e-ticaret sitesi nasıl açılır 2026 rehberi yazımıza bakabilirsiniz.

2) Ölçek ve Trafik: Bugün İçin mi, 3 Yıl Sonrası İçin mi?

İkinci kriter ölçeklenebilirliktir. CMS'i bugünkü trafiğe göre değil, gerçekçi büyüme senaryosuna göre seçmek gerekir, çünkü platform göçü (migrasyon) maliyetli ve risklidir. Burada altın kural şudur: çok küçük başlayan bir siteyi devasa bir altyapıya kurmak da, hızla büyüyecek bir markayı dar bir hazır kurucuya hapsetmek de pahalı hatalardır.

• Küçük/orta, öngörülebilir trafik: WordPress veya hazır kurucular yeter. Ağır eklenti yükü olmadığı sürece bu segmentte sorun çıkmaz. Aylık birkaç bin ziyaretçilik bir kurumsal tanıtım sitesi için altyapı, performansta nadiren darboğaz olur; asıl darboğaz tema ve eklenti seçimidir.
• Yüksek/değişken trafik, kampanya pikleri: Eklentiyle şişmiş WordPress yavaşlayabilir; bu noktada statik/edge mimari (Next.js + CDN, JAMstack barındırma: Vercel, Netlify, Cloudflare Pages) genelde en iyi ölçeklenir ve en düşük gecikmeyi verir. İndirim günü, lansman ya da bir kampanyanın aniden viral olduğu anlarda, önbelleğe alınmış statik sayfaları edge ağından sunan bir mimari, sunucuyu tek tek render'a zorlayan bir kurulumdan çok daha dayanıklıdır.
• Çok dilli / çok bölgeli: İçeriğin yapılandırılmış saklanması (headless) ve edge dağıtım büyük avantajdır. Türkiye'den Avrupa'ya satış yapan bir ihracatçı için, ziyaretçiye en yakın edge noktasından içerik sunmak hem hız hem dönüşüm getirir.

Ölçek kriteri performansla iç içedir: Core Web Vitals "iyi" eşikleri (75. yüzdelik saha verisiyle LCP ≤ 2,5 sn, INP ≤ 200 ms, CLS ≤ 0,1) trafik arttıkça ve cihaz çeşitlendikçe daha zor korunur. Hatırlatalım: INP, 12 Mart 2024'te FID'in yerini alarak resmî bir Core Web Vital oldu ve etkileşime yanıt hızını tüm yaşam döngüsüyle ölçtüğü için ağır JavaScript'e karşı çok daha hassastır. Ağır temalı, çok eklentili bir CMS yüksek trafik altında bu eşikleri kaçırmaya başlarsa, hem dönüşüm hem SEO etkilenir. Pratik bir öneri: seçeceğiniz altyapıyı yayın öncesi gerçekçi bir trafik/cihaz senaryosunda ölçün; "demo'da hızlıydı" yeterli değildir. Performansın sıralamaya etkisini site hızı ve SEO Core Web Vitals rehberi yazısında, ölçüm araçlarını ise PageSpeed Insights nedir nasıl iyileştirilir yazısında derinlemesine işledik.

3) Ekip ve Teknik Yetkinlik: Siteyi Kim Yönetecek?

Üçüncü kriter çoğunlukla atlanır ama uygulamada en belirleyici olanıdır: günlük yönetimi kim, hangi yetkinlikle yapacak? En güçlü platform bile sizin ekibinizin kullanamadığı platformsa yanlış seçimdir. Teknik kararı, kararı uygulayacak insanlardan bağımsız vermek, kullanılmayan bir özellik yığını için ödeme yapmaktır.

• Teknik olmayan, içeriği kendi güncelleyecek ekip: Sürükle-bırak hazır kurucular (Wix, Squarespace) veya editör dostu WordPress doğru. Wix tüm web payında %4,3 ile WordPress'in başlıca rakiplerinden biridir ve düşük teknik bilgiyle hızlı yayın avantajı sunar. Webflow, tasarımcıya kod düzeyinde kontrol verirken temiz çıktı üretir; orta-ileri seviyedir ve daha çok tasarım disiplinine sahip ekiplere hitap eder.
• İçerik editörü var, geliştirici yok: WordPress'in olgun editör deneyimi ve eklenti ekosistemi (60.000+ eklenti, 10.000+ tema) avantajlı; ama eklenti seçimi disiplinli olmalı. "İhtiyaç oldukça eklenti ekle" alışkanlığı, zamanla hem performansı hem güvenliği bozar. Burada doğru yaklaşım, az sayıda güvenilir ve bakımı sürdürülen eklentiyle çalışmaktır.
• Geliştirici/ajans desteği olan ekip: Headless CMS veya özel yazılım masaya gelir; bu yapılar geliştirici olmadan sürdürülemez. Buna karşılık, bir geliştirme ekibi varsa headless kurgu, içerik girenlerle kodu birbirinden ayırarak her iki tarafı da rahatlatır.

Kritik soru şudur: yayından sonra içeriği bizim kendimiz mi gireceğiz, yoksa her küçük değişiklik için ajansa mı döneceğiz? Cevap "kendimiz" ise editör deneyimi olgun bir CMS; "ajans yönetir" ise mimari özgürlük öne çıkar. Bir başka pratik filtre: yönetim panelinde sık yapılacak işler (yeni yazı, ürün güncelleme, banner değişimi) kaç tıkla ve ne kadar net yapılabiliyor? Bu kararın UX tarafındaki etkilerini UI/UX tasarım nedir nasıl yapılır yazısında ele aldık; çünkü yönetim panelinin kullanılabilirliği de bir UX konusudur ve günde defalarca o panelle çalışacak ekibin verimini doğrudan belirler.

4) Bütçe ve Toplam Sahip Olma Maliyeti (TCO)

Dördüncü kriter bütçedir, ama doğru ölçü "kurulum fiyatı" değil toplam sahip olma maliyetidir. Müşterilerimizde gördüğümüz hata, ön maliyeti karşılaştırıp aylık/yıllık gizli maliyetleri görmezden gelmek oluyor. Bir platform kurulumda ucuz görünüp; abonelik, eklenti lisansı, işlem komisyonu, tema güncellemesi ve bakım kalemleriyle üç yıl içinde en pahalı seçeneğe dönüşebilir. Doğru karşılaştırma, "bugün ne kadar?" değil, "üç yılda toplam ne kadar?" sorusudur.

Pratik karar: kısa vadeli, bütçesiz, basit bir site için hazır kurucu başlangıçta çok daha ekonomiktir. Markaya özgü, dönüşüm-kritik, uzun ömürlü ve entegrasyon yoğun bir proje için özel yazılımın yüksek ön maliyeti, abonelik bağımlılığının olmaması ve performans avantajıyla zamanla geri döner. Tabloya eklediğimiz "çıkış maliyeti" satırını atlamayın: bugün ucuz olan ama yarın taşınması zor olan bir platform, gizli bir bağımlılık maliyeti taşır. Fiyat aralıkları kapsama göre değiştiği için kesin rakam yerine teklif alıp karşılaştırmanızı öneririz; web tarafında neyin maliyeti neye göre değiştiğini web tasarım fiyatları 2026 ve özel yazılım maliyeti neye göre belirlenir yazılarımızda kalemlere ayırdık.

5) Bakım Yükü ve Sahiplik: Sorumluluk Kimde?

Beşinci kriter bakımdır ve doğrudan riskle ilgilidir, çünkü bakımsız site güvenlik ve SEO açısından hızla değer kaybeder. Burada platformlar net biçimde ayrışır; üçü arasındaki fark, "kim hata yaparsa siz cezasını çekersiniz?" sorusunun cevabıdır.

• Hazır kurucular: Altyapı bakımı (sunucu, güncelleme, güvenlik yaması) sağlayıcıdadır. Bu bir avantajdır; teknik yükü siz taşımazsınız. Karşılığında platforma bağımlılık ve sınırlı optimizasyon kontrolü gelir. Sağlayıcı bir özelliği kaldırırsa ya da fiyatını değiştirirse buna uymak zorunda kalırsınız.
• WordPress (arada konum): Çekirdek, tema ve eklentilerin güncellenmesi sizin sorumluluğunuzdadır. Bu süreç ihmal edilirse açıklar birikir; bilinen güvenlik açıklarının (CVE) büyük çoğunluğu güncellenmemiş bileşenlerden sömürülür. WordPress, güç ekosisteminin bedelini bakım disipliniyle öder. Pratikte bu, düzenli güncelleme, kullanılmayan eklenti/temayı silme ve değişiklikleri önce bir test (staging) ortamında deneme rutini demektir.
• Headless / özel yazılım: Bakım ekibe/ajansa aittir; tam kontrol ama tam sorumluluk. Sürekli geliştirici desteği gerektirir. Buna karşılık, modern statik/edge mimaride saldırı yüzeyi daha dar olduğundan, "yamalanması gereken yüzey" de daha küçüktür.

Bakım her platformda süreklilik gerektiren bir süreçtir: güvenlik güncellemeleri, içerik tazeleme, performans izleme, yedekleme ve kırık link kontrolü. Burada en sık yapılan hata, bakımı "bir kerelik" sanmaktır; oysa yedeklerin düzenli, otomatik, sürümlü ve site dışında (off-site) tutulması ve geri yükleme testinin periyodik yapılması, bir saldırı ya da arıza sonrası çoğu zaman tek kurtarma yoludur. Bu yüzden CMS seçerken "kim, hangi sıklıkta, hangi bütçeyle bakacak?" sorusunun cevabı baştan netleşmelidir. Bir süre bakımsız kalmış ve eskimiş bir siteyi yenilerken nelere dikkat edileceğini web sitesi yenileme redesign rehberi yazımızda anlattık.

6) SEO ve Performans Uyumu: Platform Sizi Yavaşlatıyor mu?

Altıncı kriter SEO ve performanstır; çünkü en iyi içerik bile görünmüyorsa ve site yavaşsa karşılığını alamaz. CMS bu noktada doğrudan etkilidir: doğru altyapı SEO çalışmasının önünü açar, yanlış altyapı her adımda ayağınıza dolanır.

• Mobil öncelik: Google'ın varsayılan indekslemesi mobil-öncelikli; yani sitenizin mobil sürümü indekslenir ve sıralanır. Mobil cihazlar küresel web trafiğinin yaklaşık %60'ını oluşturuyor; Türkiye gibi pazarlarda bu oran daha da yükseliyor. CMS ve temanız mobilde eksiksiz içerik sunmalı, aksi halde SEO kaybı yaşanır. Mobil tarafın detayları için mobil uyumlu responsive web tasarım rehberi yazımız var.
• Core Web Vitals: CWV bir sıralama sinyalidir ve tüm eşikleri geçen siteler ölçülebilir organik iyileşme, düşük hemen çıkma ve yüksek etkileşim görür. Ağır eklentili WordPress bu eşikleri zorlayabilir; statik/edge mimari genelde avantajlıdır. Temiz kod üreten Webflow ya da "az JS" felsefesindeki Astro gibi seçenekler, ağır JavaScript'in yorduğu INP tarafında öne çıkar. Hatırlatma: INP'yi bozan ana etken ana iş parçacığını bloke eden ağır script'tir; az script ve kod bölme (code splitting) burada belirleyicidir.
• Teknik SEO kontrolü: Platform; özelleştirilebilir meta etiketler, otomatik sitemap, temiz URL yapısı, yapılandırılmış veri (schema) ve 301 yönlendirme yönetimine izin vermeli. Bunlar olmazsa SEO elinizi bağlar. Özellikle URL yapısını kontrol edemediğiniz bir platform, ileride bir yenileme ya da göç sırasında 301 yönlendirme haritasını kurmanızı zorlaştırır.
• Türkçe ve UTF-8: Seçtiğiniz altyapı ve font, Türkçe karakterleri (ç, ğ, ı, İ, ö, ş, ü) ve özellikle noktalı/noktasız I ayrımını sorunsuz desteklemeli; lang="tr" tanımı doğru büyük/küçük harf dönüşümü ve erişilebilirlik için gereklidir. Bazı popüler fontlarda "İ/ı" sorunları çıktığı için seçilen yazı tipini gerçek Türkçe metinle test etmek şarttır.

SEO'yu CMS seçiminden ayrı düşünmemek gerekir; doğru altyapı, on-page ve teknik SEO çalışmasının önünü açar. Bir CMS'in SEO dostu olup olmadığını değerlendirirken meta başlık/açıklama üretiminden sitemap'e, schema desteğinden URL temizliğine kadar kontrol listesi çıkarın; başlık ve açıklama metinlerini hızlı oluşturmak için meta title ve description oluşturucu aracımızı kullanabilirsiniz. Uygulama adımları için ise SEO nedir nasıl yapılır 2026 rehberi, on-page SEO nedir nasıl yapılır ve teknik SEO denetimi nasıl yapılır yazılarımız var.

7) Güvenlik ve Yasal Uyum: Risk Yüzeyi Ne Kadar?

Yedinci kriter güvenliktir ve Türkiye'de KVKK boyutuyla doğrudan hukuki sonuç doğurur. Her platformun bir saldırı yüzeyi (attack surface) vardır; CMS seçimi bu yüzeyin büyüklüğünü belirler. Genel kural: ne kadar çok dış bileşene (eklenti, paket, tema) bağımlıysanız, savunmanız gereken alan o kadar büyür.

• Üçüncü taraf bileşen riski: WordPress'te en büyük risk, güncellenmemiş veya terk edilmiş üçüncü taraf eklentiler ve zayıf admin parolalarıdır. Güvenilir eklenti seçmek, kullanılmayanı silmek ve admin'i iki adımlı doğrulama (2FA) ile korumak şarttır. Tedarik zinciri açıkları (Software Supply Chain Failures) artık OWASP Top 10:2025 listesinde A03 olarak yeni bir başlık halinde yer alıyor; bu, eklenti/paket bağımlılıklarının ne kadar ciddiye alınması gerektiğini gösterir.
• Yapılandırma hataları: Security Misconfiguration, OWASP Top 10:2025'te 5. sıradan 2. sıraya (A02) yükseldi. Bu, "kur ve unut" yaklaşımının ne kadar riskli olduğunu gösterir; platform ne olursa olsun güvenli varsayılanlar ve doğru yapılandırma gerekir. Açıkta kalan yönetim panelleri, varsayılan parolalar ve gereksiz açık servisler en sık görülen hatalardır.
• Temel zorunluluklar: HTTPS/TLS (Let's Encrypt ile ücretsiz, çoğu hosting otomatik sağlar) artık opsiyonel değil; tarayıcının "güvenli değil" uyarısını önler ve bir sıralama sinyalidir. Bunun üstüne düzenli ve site dışı yedekleme, sunucu tarafı doğrulama, CSRF token, kaba kuvvet saldırısına karşı rate-limit, güçlü parola + 2FA ve girdi temizleme (injection/XSS önleme) gelir. CMS'iniz bu pratikleri kolaylaştırmalı, zorlaştırmamalı.
• KVKK boyutu: Kişisel veri işleyen sitelerde teknik/idari veri güvenliği tedbirleri yasal zorunluluktur (KVKK m.12): HTTPS, şifreleme, erişim kontrolü, log tutma ve veri ihlali bildirimi gerekir. Ayrıca siteye girişte çerez bandı + çerez politikası bulunmalı; analitik/pazarlama gibi zorunlu olmayan çerezler için açık rıza alınmalıdır. Aydınlatma metni ile açık rıza/ticari ileti izni ayrı ayrı düzenlenmelidir; tek kutuda "kabul ediyorum" hukuken sakıncalıdır. Platformunuz çerez yönetimini ve ayrı rıza akışlarını destekleyebilmeli.

Karar açısından: az bağımlılıkla çalışan, güncel tutulan ve güvenli varsayılanlarla gelen bir altyapı düşük risk yüzeyi sağlar. Çok eklentili, ihmal edilen bir WordPress kurulumu ise hem teknik hem hukuki risk yığar; bir güvenlik açığı yalnızca site çökmesi değil, KVKK kapsamında bildirim yükümlülüğü ve idari yaptırım anlamına da gelebilir. Güvenlik tarafının uçtan uca uygulamasını web sitesi güvenliği nedir nasıl sağlanır yazımızda topladık; erişilebilirliğin hem yasal (örneğin AB'ye satış yapanları kapsayan EAA) hem SEO yönünü ise web erişilebilirliği nedir nasıl sağlanır yazısında işledik.

Kriterleri Birleştirmek: Pratik Karar Akışı

Bu yedi kriteri tek tek puanladıktan sonra çoğu karar netleşir. Önemli olan, kriterleri izole değil birlikte okumaktır: yüksek bütçe ama teknik olmayan bir ekip, "özel yazılım"a değil, bakımı sağlayıcıya bırakan ama esnek bir kurguya işaret edebilir; düşük bütçe ama güçlü bir geliştirme ekibi, açık kaynak headless bir kurguyu mümkün kılabilir. Özetle uyguladığımız akış şudur:

1. Sık güncellenen, içerik ağırlıklı pazarlama sitesi + teknik olmayan ekip → hazır kurucu (Wix/Squarespace) veya editör dostu WordPress.
2. Editörlerin yöneteceği, içerik ağırlıklı yapı + çok kanallılık ihtiyacı → klasik veya headless CMS (WordPress, Strapi/Sanity/Contentful + Next.js/Astro).
3. Özgün ürün, yüksek/değişken trafik, tam kontrol ve performans/ölçek ihtiyacı → özel yazılım (Next.js vb. + edge/CDN).
4. E-ticaret → karar büyük ölçüde Türkiye operasyonuna (kargo, e-fatura, TL, ödeme) göre şekillenir; Shopify, ikas ve WooCommerce arasındaki seçim, satış hacmi ve yerel entegrasyon ihtiyacına bağlıdır.

Mevcut ya da rakip bir sitenin hangi altyapıyla çalıştığını teknik olarak doğrulamak, karşılaştırmanızı somutlaştırır; bunun için e-ticaret altyapı tespit aracımızı kullanarak bir sitenin Shopify, ikas, WooCommerce ya da başka bir altyapıda olup olmadığını saniyeler içinde görebilir, beğendiğiniz bir sitenin "hangi CMS?" sorusunu kanıtla yanıtlayabilirsiniz. Kararı kendi başınıza vermek istemiyorsanız, ihtiyaç-ölçek-bütçe üçgenine göre doğru CMS'i belirleyip kurgulamak bizim işimiz: özel yazılım ve website hizmetimiz ile altyapı seçiminden yayına kadar süreci yönetiyor, hızlı bir ön değerlendirme için ücretsiz analiz ve teklif sihirbazımız üzerinden başlayabiliyorsunuz. Doğru CMS, en parlak ya da en popüler olan değil; ihtiyacınıza en az sürtünmeyle ve en düşük toplam maliyetle hizmet edendir.

CMS Seçiminde Sık Yapılan Hatalar (ve Bunlardan Nasıl Kaçınılır)?

CMS seçiminde en sık yapılan hata, kararı yanlış kritere dayandırmaktır: trendlere, "herkes onu kullanıyor" algısına veya tek bir özelliğe (ör. tema güzelliğine) göre seçim yapmak. Doğru CMS kararı, projenin gerçek ihtiyaçlarına — içerik hacmi, ekip yetkinliği, esneklik, performans, güvenlik yükü ve sahiplik beklentisi — göre verilir. Müşterilerimizde gördüğümüz başarısız altyapı kararlarının neredeyse tamamı, aşağıdaki birkaç tekrar eden hatadan birine dayanıyor. Önemli olan şu: bu hatalar genelde teknik bir bilgisizlikten değil, yanlış soruları sormaktan kaynaklanıyor. "Hangi CMS en iyisi?" sorusu yanlış sorudur; doğru soru "bizim ekibimiz, içeriğimiz ve büyüme planımız için hangi CMS en uygunu?" sorusudur. Bu bölümde altı sık hatayı somut örneklerle açıyor, her birinde "neden yanlış" ve "nasıl kaçınılır" ekseninde ilerliyor, ardından kararı pratik bir çerçeveye bağlıyoruz.

Hataları topluca görmek için önce kısa bir özet tablosu verelim; ardından her birini tek tek açacağız.

Hata 1: Modaya veya Popülerliğe Göre Seçim Yapmak

En yaygın hata, CMS'i ihtiyaca değil popülerliğe göre seçmektir. "WordPress dünyanın en yaygın CMS'i, o zaman benim için de doğru" mantığı tek başına yanıltıcıdır. Doğru, WordPress 2026 Haziran itibarıyla tüm web sitelerinin yaklaşık %41,9'unu, CMS kullanan sitelerin ise %59,5'ini çalıştırıyor (W3Techs); en yakın rakibi Shopify'ın (%5,2) yaklaşık 9 katı bir pay, üçüncü sıradaki Wix ise %4,3 seviyesinde. Ama bu rakam WordPress'in her proje için doğru olduğu anlamına gelmez — yalnızca çok geniş bir ekosistem ve büyük bir topluluk olduğu anlamına gelir. Tek sayfalık bir kampanya sitesi, yüksek trafikli özgün bir ürün ya da API'den içerik besleyen çok kanallı bir yapı için WordPress, ihtiyaca uymayan ağır bir tercih olabilir. Pazar payı bir "güven sinyali"dir, bir "uygunluk kanıtı" değil; bu ikisini karıştırmak hataların kaynağıdır.

Aynı hatanın tersi de var: "WordPress eski, artık herkes headless/Next.js'e geçiyor" söylemine kapılıp basit bir kurumsal tanıtım sitesini gereksiz yere özel yazılımla kurmak. Bu durumda da projenin içeriğini güncellemesi gereken pazarlama ekibi, geliştirici olmadan tek bir metni bile değiştiremez hale gelir; "hızlı ve modern olalım" diye seçilen altyapı, içerik güncellemesini her seferinde bir geliştirici talebine dönüştürür. Geçici moda ile kalıcı ilkeyi ayırmak gerekir: hız, erişilebilirlik, mobil-öncelik, net hiyerarşi, kullanıcı odaklılık ve güvenlik kalıcı ilkelerdir ve her zaman geçerlidir; belirli bir framework akımı, belirli bir tasarım modası (glassmorphism, brutalism gibi) ise geçicidir ve markaya uyuyorsa kullanılır, körü körüne takip edilmez. Trend, ilkenin yerini almaz. Bu ayrımı iyi web tasarımının ne olduğunu anlattığımız yazıda ve genel web sitesi yapma rehberinde de vurguluyoruz.

Doğru yaklaşım, kararı net bir soru setine bağlamaktır. Müşterilerimizle altyapı kararını verirken pratikte şu beş soruyu masaya koyuyoruz:

• İçeriği kim, ne sıklıkla güncelleyecek? Teknik olmayan bir pazarlama ekibi haftada birkaç kez içerik girecekse, kodsuz panel şarttır; içerik yılda birkaç kez değişiyorsa esneklik daha az kritiktir.
• Site büyüdüğünde ne kadar trafik bekliyoruz? Bugün 1.000 ziyaretçi olan site bir yıl sonra 100.000'e çıkacaksa, bugünkü altyapı yarının yükünü kaldırmalı.
• Bütçe modeli ne? Aylık abonelik (OPEX) mi, yoksa ön yatırım (CAPEX) mi mantıklı? Hazır kurucular düşük başlangıç ama sürekli abonelik; özel yazılım yüksek ön maliyet ama abonelik bağımlılığı yok.
• Veriyi ve kodu sahiplenmek bizim için kritik mi? İleride başka bir ajansa veya altyapıya geçme ihtimaliniz varsa, lock-in büyük bir maliyettir.
• Hangi entegrasyonlar gerekecek? E-fatura, kargo, CRM, ödeme, ERP — gereken entegrasyonlar platformun ekosisteminde hazır mı, yoksa özel geliştirme mi gerektiriyor?

Bu soruları cevaplamadan verilen "popüler olanı seçtim" kararı, çoğu zaman bir yıl içinde "yeniden yapalım" konuşmasına döner; ki bu, hem bütçe hem de SEO birikimi açısından en pahalı senaryodur. Hazır site mi özel yazılım mı karşılaştırmamız bu soru setini daha ayrıntılı işliyor; özel yazılım tarafında maliyetin neye göre değiştiğini ise özel yazılım maliyeti yazımızda ele alıyoruz.

Hata 2: Eklenti Bağımlılığı ("Plugin Hell")

İkinci sık hata, özellikle WordPress dünyasında, her ihtiyaç için bir eklenti kurarak siteyi onlarca üçüncü taraf bileşene bağımlı hale getirmektir. WordPress'in en büyük gücü olan ekosistemi (60.000'den fazla eklenti, 10.000'den fazla tema) aynı zamanda en büyük tuzağıdır. Müşterilerimizde sık gördüğümüz tablo şu: galeri için bir eklenti, form için başka bir eklenti, SEO için bir tane daha, sayfa kurucusu (page builder) için bir devasa eklenti, sosyal medya butonları için bir tane, önbellek için bir tane... ve sonunda 30-40 eklentiyle çalışan, her güncellemede bir şeyi bozulan bir site. İronik olan şu: bu eklentilerin birçoğunun işlevi (basit form, görsel galeri) aslında tema veya birkaç satır kodla, tek bir bağımlılık eklemeden çözülebilir.

Bu "eklenti şişmesi"nin (plugin bloat) üç somut bedeli var:

• Performans kaybı: Her eklenti ek CSS/JavaScript yükler. Ağır script'ler ana iş parçacığını (main thread) bloke eder ve INP (Interaction to Next Paint) değerini bozar — ki INP, 12 Mart 2024'te FID'in (First Input Delay) yerini alan resmî bir Core Web Vital'dir ve "iyi" eşiği 75. yüzdelikte 200 ms'nin altıdır. INP, tek bir etkileşimi değil tüm etkileşimleri ve giriş gecikmesi + işleme + sunum aşamalarının tamamını ölçtüğü için FID'den çok daha kapsamlıdır; düzgün ayrılmamış (code splitting yapılmamış) eklenti yığını bu eşiği rahatlıkla aşar. Page builder'ların ürettiği fazla DOM, gereksiz görseller ve render-engelleyici kaynaklar ise LCP eşiğini (2,5 sn) zorlar. Üstelik bu yük mobilde katlanır: mobil cihazlar daha yavaş CPU/şebeke kullanır, dolayısıyla masaüstünde "yeterince hızlı" görünen bir eklenti yığını mobilde CWV'yi düşürür — ve Google mobil-öncelikli indeksleme ile sitenin mobil sürümünü sıraladığı için bu doğrudan SEO kaybıdır. Bu mekanizmayı site hızı ve Core Web Vitals rehberimizde, ölçüm tarafını ise PageSpeed Insights yazımızda ayrıntılı anlatıyoruz.
• Güvenlik yüzeyi genişlemesi: Her eklenti, sitenize başka bir geliştiricinin kodunu ekler. OWASP Top 10:2025'te A03 Software Supply Chain Failures (tedarik zinciri zafiyetleri) artık ayrı bir madde olarak listede; çünkü bilinen açıkların (CVE) çoğu güncellenmemiş veya terk edilmiş üçüncü taraf bileşenlerden sömürülüyor. Bir eklentinin geliştiricisi projeyi bıraktığında, o eklenti sitenizde yamanmamış açık bir kapı olarak kalır — ve siz bunu fark etmeyebilirsiniz bile. Eklenti sayısı arttıkça, sitenizin güvenliği artık sizin değil, en zayıf eklentinin geliştiricisinin disiplinine bağlı hale gelir.
• Kırılganlık ve bakım yükü: Eklentiler birbiriyle çakışır; bir güncelleme diğerini bozar. Çok eklentili bir site, her WordPress/PHP sürüm yükseltmesinde test gerektiren kırılgan bir yapıya döner. Bu, görünmeyen ama sürekli akan bir "teknik borç faizi"dir: her ay biraz bakım zamanı yer, her güncellemede risk taşır.

Doğru yaklaşım eklentiden kaçınmak değil, disiplinli eklenti hijyenidir: yalnızca güvenilir, aktif bakılan (son güncelleme tarihi yakın, kullanıcı sayısı yüksek, değerlendirmesi iyi) ve gerçekten ihtiyaç duyulan eklentileri kur; kullanılmayan her eklentiyi (devre dışı bırakmakla yetinmeyip) sil; mümkün olan işlevi tema/kod düzeyinde çöz; ağır, çok amaçlı page builder yerine daha hafif çözümleri veya bloklarla çalışan yerleşik editörü değerlendir. Pratik bir kural olarak, bir eklenti eklemeden önce "bu işlevi gerçekten dış bir bileşene mi yaptırmalıyım, yoksa zaten elimdeki araçlarla mı çözebilirim?" diye sormak, zamanla biriken eklenti yükünün büyük kısmını engeller. İçerik ağırlıklı, çok kanallı bir proje için eklenti yığınına bel bağlamak yerine headless bir CMS (Strapi, Sanity, Contentful) ile modern bir framework (Next.js, Astro) eşleştirmesi çoğu zaman hem hız hem güvenlik açısından daha sürdürülebilir olur; özellikle Astro'nun "az JavaScript" felsefesi, eklenti şişmesinin tam tersi bir zemin sunar. Özetle: eklenti sayısı bir kolaylık değil, yönetilmesi gereken bir teknik borçtur.

Hata 3: Güvenliği ve Bakımı Sonraya Bırakmak

Üçüncü hata, CMS'i "kur ve unut" sanmaktır. Hiçbir CMS bakımsız güvende kalmaz; bakım, yayın sonrası biten değil yeni başlayan bir süreçtir. WordPress'e özgü en büyük risk, çekirdeğin kendisi değil; güncellenmemiş veya terk edilmiş üçüncü taraf eklentiler ve zayıf admin parolalarıdır. OWASP Top 10:2025'te A02 Security Misconfiguration (güvenlik yanlış yapılandırması) #5'ten #2'ye yükseldi — yani yanlış yapılandırılmış, varsayılan ayarlarla bırakılmış sistemler giderek daha büyük bir tehdit; listenin en tepesinde ise hâlâ A01 Broken Access Control (yetki kontrolünün hatalı kurulması) duruyor. Bu, "varsayılan admin kullanıcısı, tahmin edilebilir parola, herkese açık yönetim paneli" gibi ihmallerin neden bu kadar sık sömürüldüğünü açıklıyor. Buna karşı temel önlemler nettir:

• CMS çekirdeğini, temayı ve tüm eklentileri düzenli güncelle; kullanmadığın bileşenleri sil. Bilinen açıkların çoğu, yaması çıkmış ama uygulanmamış güncellemelerden sömürülür.
• Admin girişini güçlü parola + 2FA ile koru; giriş denemelerine rate-limit (kaba kuvvet/brute-force önleme) uygula. Yönetim paneli URL'sini varsayılanından değiştirmek ve IP kısıtlamak da yüzeyi daraltır.
• HTTPS/TLS zorunlu; SSL terimi yaygın olsa da güncel protokol TLS'tir (1.2/1.3). Let's Encrypt ile ücretsiz sertifika alınabilir, çoğu hosting otomatik sağlar. HTTPS aynı zamanda bir Google sıralama sinyalidir ve tarayıcının "güvenli değil" uyarısını önler.
• Form ve girişlerde sunucu tarafı doğrulama, CSRF token ve girdi temizleme (injection/XSS önleme) uygula. İstemci tarafı doğrulama tek başına asla yeterli değildir.
• Düzenli, otomatik, sürümlü ve site dışı (off-site) yedek al; geri yüklemeyi periyodik test et — yedeğin gerçekten çalışıp çalışmadığını ancak geri yükleyerek bilirsin. Fidye veya saldırı sonrası çoğu zaman tek kurtarma yolu budur.
• WAF (Web Application Firewall) + CDN (örn. Cloudflare) ile kötü trafiği ve botu filtrele, DDoS riskini azalt, yaygın saldırı kalıplarını engelle.

Buradaki kritik nokta, güvenliğin CMS seçim kararının bir parçası olduğudur. Hazır kurucularda altyapı bakımı (sunucu, çekirdek güncellemeleri) sağlayıcıdadır; bu bir avantajdır ama karşılığında kontrolü ve görünürlüğü de sağlayıcıya devredersiniz. WordPress arada durur: kolaylığı yüksek ama güncellemeleri sizin yapmanız gerekir. Özel yazılımda kontrol tamamen sizdedir ama sorumluluk da öyle. Yani "bu altyapıyı kim, nasıl güncel ve güvenli tutacak?" sorusunun cevabı belirsizse, seçim daha baştan eksiktir.

Bu konunun Türkiye'deki ayağı yalnızca teknik değil, aynı zamanda hukukidir. KVKK (6698 sayılı Kanun) m.12 gereği kişisel veri işleyen her sitede "veri güvenliği" teknik ve idari tedbirleri yasal zorunluluktur: HTTPS, şifreleme, erişim kontrolü, log tutma ve veri ihlali bildirimi gerekir. Bir iletişim formu bile (ad, e-posta, telefon topladığı için) sitenizi veri sorumlusu yapar. Yani bir güvenlik açığı, sadece teknik bir arıza değil aynı zamanda hukuki bir risktir; veri ihlali halinde hem Kurul'a hem ilgili kişilere bildirim yükümlülüğü doğar. CMS seçerken güvenliği sonraya bırakmak, bu yüzden hem operasyonel hem yasal bir borçlanmadır. Güvenlik tarafını uçtan uca web sitesi güvenliği rehberimizde, altyapı/SSL kurulumunu ise domain, hosting ve SSL altyapı yazımızda adım adım ele alıyoruz.

Hata 4: Erişilebilirliği ve Yasal Uyumu Göz Ardı Etmek

Daha az konuşulan ama giderek pahalılaşan bir hata da, CMS/tema seçerken erişilebilirliği (accessibility / a11y) hiç hesaba katmamaktır. Birçok hazır tema, görsel olarak çekici olsa da düşük metin kontrastı, etiketsiz form alanları, klavyeyle gezilemeyen menüler, görünmez odak halkası ve alt-metni olmayan görseller gibi temel WCAG hatalarıyla gelir. WebAIM Million raporuna göre tespit edilen erişilebilirlik hatalarının büyük çoğunluğunu tam da bu birkaç tür oluşturur: düşük kontrast, eksik alt metni, boş bağlantılar, etiketsiz form alanları, boş butonlar ve eksik dil tanımı. Yani sorunlar genelde egzotik değil, temel ve tekrar edendir — ve kötü seçilmiş bir tema bu hataları daha baştan sitenize taşır.

Erişilebilirliğin hedef çıtası bellidir. WCAG 2.2, 5 Ekim 2023'te resmî W3C standardı (Recommendation) oldu, WCAG 2.1'e göre 9 yeni başarı kriteri ekledi (odak görünürlüğü, sürükleme hareketleri, minimum hedef boyutu, erişilebilir kimlik doğrulama gibi) ve ayrıca ISO/IEC 40500:2025 olarak ISO standardıdır. Hemen her yasanın hedeflediği uyum seviyesi AA'dır. Tema/bileşen seçerken bakılması gereken somut kriterlerden bazıları:

Bu konunun bir de yasal boyutu var ve giderek sertleşiyor: Avrupa Erişilebilirlik Yasası (EAA) 28 Haziran 2025'te yürürlüğe girdi ve EN 301 549 / WCAG 2.1 AA uyumunu zorunlu kıldı. AB'ye ürün veya hizmet satan Türkiye firmaları da (e-ticaret, bankacılık, e-kitap, ulaşım gibi alanlarda) bu kapsama girebilir; piyasada olan eski hizmetler için geçiş süresi 28 Haziran 2030'a kadar uzanıyor, ihlal cezaları ise ülkeye göre 100.000 EUR'ya ya da yıllık cironun %4'üne kadar çıkabiliyor. Türkiye'de kamu siteleri için erişilebilirlik düzenlemeleri zaten var; özel sektör için henüz aynı sertlikte genel bir yasa olmasa da AB'ye satış yapan firmalar EAA'ya tabidir. Üstelik erişilebilirlik salt bir yükümlülük değil; anlamlı HTML, net hiyerarşi ve hızlı yükleme aynı zamanda SEO'ya ve dönüşüme katkı sağlar — yani erişilebilir bir altyapı genelde daha iyi sıralanan ve daha iyi dönüştüren bir altyapıdır. Bu yüzden CMS/tema seçerken "erişilebilir tema/bileşen üretiyor mu, anlamlı HTML ve klavye gezinmesi destekliyor mu?" sorusu artık opsiyonel bir lüks değil, bir altyapı kriteridir. Detayları web erişilebilirliği rehberimizde, mobil/dokunmatik tarafını ise mobil uyumlu responsive tasarım rehberimizde bulabilirsiniz.

Hata 5: Sahiplik ve Taşınabilirliği (Vendor Lock-in) Düşünmemek

Beşinci sık hata, kısa vadeli kolaylık uğruna uzun vadeli sahipliği feda etmektir. Hazır site kurucular (Wix, Squarespace, Shopify) hızlı yayın ve düşük teknik bilgi gerektirmeleriyle cazip; küçük işletme ve hızlı başlangıç için tamamen mantıklı. Ancak içerik ve tasarım platforma kilitlenir (vendor lock-in); ileride başka bir altyapıya taşımak istediğinizde tasarımınızı ve çoğu zaman içeriğinizi birebir taşıyamaz, yeniden kurmak zorunda kalırsınız — ve aylık abonelik bağımlılığı sürer. Buna karşılık açık kaynak CMS (WordPress, headless) veya özel yazılımda kod ve veri sizindir; taşınabilirlik yüksektir, ajans veya altyapı değiştirmek bir krize dönüşmez.

Lock-in maliyetini görünür kılmak için kararı verirken şu soruları sormakta fayda var: İçeriğimi standart bir formatta (ör. dışa aktarma/export) alabiliyor muyum? Tasarımım bana mı ait, platforma mı? Bu sağlayıcıyı bir gün bırakmak istersem ne kaybederim? Burada doğru/yanlış bir platform yoktur; doğru/yanlış bir eşleşme vardır. Pratik karar çerçevesini özetlersek:

E-ticaret tarafında platform kararını ayrıca ikas mı Shopify mı karşılaştırmamızda derinlemesine ele alıyoruz; Shopify mağaza kurulumunu adım adım görmek isterseniz Shopify rehberimize, e-ticaretin toplam maliyetini merak ediyorsanız e-ticaret maliyet rehberimize göz atabilirsiniz. Mevcut bir sitenin hangi altyapıda çalıştığını merak ediyorsanız, e-ticaret altyapı tespit aracımızla rakiplerinizin veya kendi sitenizin CMS/altyapısını saniyeler içinde görebilirsiniz.

Hata 6: Bugünün Sitesine Göre Seçip Ölçeği Öngörmemek

Altıncı ve sıklıkla en pahalıya patlayan hata, kararı bugünkü küçük siteye göre verip büyüme senaryosunu hiç hesaba katmamaktır. CMS seçimi bir gün için değil, en az birkaç yıl için verilen bir karardır. Bugün 10 sayfalık tanıtım sitesi için "en kolayı"nı seçmek mantıklı görünür; ama içerik 10 katına çıktığında, trafik patladığında, ekip büyüdüğünde veya yeni bir satış kanalı (mobil uygulama, pazaryeri, ekran) eklendiğinde, "en kolay" altyapı çoğu zaman "en kısıtlayan" altyapıya dönüşür. Bu noktada yapılan platform değişikliği yalnızca yeniden geliştirme maliyeti değil; biriken SEO değerinin, backlink'lerin ve sıralamaların riske atılması demektir.

Ölçeği öngörmenin pratik karşılığı birkaç eksende düşünülür:

• İçerik hacmi: Yüzlerce ürün/yazı olacaksa, içerik modelleme, kategorizasyon ve arama önemlidir; bunu kötü kuran bir altyapı, içerik büyüdükçe yönetilemez hale gelir.
• Trafik ve performans: Yüksek trafik beklentisi varsa, statik/edge sunum (Next.js/Astro) veya güçlü önbellekleme şarttır; ağır eklentili bir WordPress yük altında yavaşlar ve CWV eşiklerini (LCP 2,5 sn, INP 200 ms, CLS 0,1) kaçırır.
• Ekip ve rol yönetimi: Ekip büyüyecekse, kimin neyi düzenleyebileceğini belirleyen rol/yetki yönetimi (ki bu aynı zamanda bir güvenlik meselesidir — OWASP A01) bugünden düşünülmeli.
• Çok kanallılık: İçeriğin ileride sadece web değil mobil uygulama veya başka ekranlarda da kullanılacağı öngörülüyorsa, headless bir CMS bu esnekliği baştan sağlar; tek kanala kilitli bir kurucu sağlamaz.

Bu hatadan kaçınmanın yolu, kararı "bugünkü site" değil "üç yıl sonraki site" üzerinden vermektir. Mevcut bir sitenin bu yüzden yenilenmesi gerekiyorsa, doğru CMS'e geçişin nasıl SEO kaybetmeden yapılacağını (özellikle URL yapısı değişiyorsa eski→yeni kalıcı 301 yönlendirmelerinin neden zorunlu olduğunu) web sitesi yenileme (redesign) rehberimizde ele alıyoruz. Kurumsal ölçekte bir sitenin hangi bölümleri ve hangi güven sinyallerini taşıması gerektiğini ise kurumsal web sitesi rehberimizde bulabilirsiniz.

Sonuç: Doğru CMS, "En Popüler" Değil, "En Uygun" Olandır

CMS seçimi, özünde bir teknoloji tercihi değil bir ihtiyaç-eşleştirme kararıdır. WordPress'in %41,9'luk pazar payı onu varsayılan doğru cevap yapmaz; Next.js'in popülerliği onu her proje için zorunlu kılmaz. Doğru karar, bu altı sık hatadan kaçınarak verilir: modaya değil ihtiyaca göre seç, eklenti bağımlılığını teknik borç olarak yönet, güvenlik ve bakımı baştan planla, erişilebilirlik ile KVKK/EAA uyumunu altyapı kriteri say, sahiplik ve taşınabilirliği gözden kaçırma, kararı bugünün değil üç yıl sonraki sitenin ölçeğine göre ver. Bu altı eksene net cevap verebiliyorsanız, hangi CMS'i seçerseniz seçin sağlam bir zeminde durursunuz.

Pratik bir özet: kararı verirken kendinize tek bir bütünleştirici soru sorun — "Bu altyapıyı bir yıl sonra, içerik 10 katına çıktığında, ekip değiştiğinde ve trafik arttığında hâlâ rahatça, güvenli ve hızlı biçimde yönetebilecek miyiz?" Cevap "evet" olan altyapı, sizin için doğru olandır. Bu rehberin tamamlayıcısı olarak web sitesi yapma adımları, altyapının domain/hosting/SSL ayağı için altyapı rehberimiz ve B2B/kurumsal odaklı bir site planlıyorsanız B2B web sitesi tasarım rehberimize göz atabilirsiniz.

Hangi CMS'in işinize uygun olduğundan emin değilseniz, kararı tahmine bırakmayın. Alis Dijital olarak içerik hacminizi, ekip yapınızı, performans ve güvenlik beklentilerinizi, büyüme planınızı ve gereken entegrasyonları birlikte değerlendirip size en uygun altyapıyı (hazır kurucu, WordPress, headless veya özel yazılım) önümüze koyduğumuz somut bir yol haritasıyla netleştiriyoruz. Ücretsiz analiz ve teklif sihirbazımızdan başlayabilir, dilerseniz doğrudan özel yazılım ve web sitesi hizmetimizi ya da web ve mobil UI/UX tasarımı hizmetimizi inceleyebilirsiniz. Doğru altyapı kararı, ilerideki yüzlerce saatlik bakım ve yeniden yapım maliyetinden sizi kurtarır; yanlış karar ise her ay küçük küçük ödenen, zamanla büyüyen bir fatura olarak geri döner.