E-ticaret sitesi kurma kararının en çok konuşulan tarafı “hangi altyapı daha iyi” sorusudur. Oysa bu sorunun genel geçer bir cevabı yok — çünkü altyapılar birbirinden kalite olarak değil, model olarak ayrılıyor.
Bir altyapı bulutta çalışıyor ve bakımını sağlayıcı üstleniyor. Diğeri sizin sunucunuzda çalışıyor ve bakımı size ait. Birinde kaynak kodu açık, diğerinde değil. Birinde her şeyi değiştirebiliyorsunuz ama her şeyden siz sorumlusunuz.
Bu farklar iyi ya da kötü değil — takas. Ve doğru takas, tamamen sizin durumunuza bağlı: ekibinizde teknik kaynak var mı, kataloğunuz ne kadar karmaşık, entegrasyon ihtiyacınız ne, kaç yıllık bir plan yapıyorsunuz.
Bu yazı bir sıralama sunmuyor. Modelleri tanımlıyor, hangi durumda hangisinin zorlanacağını anlatıyor ve kararı verirken soracağınız soruları veriyor.
Not: Aşağıda geçen altyapıların paket yapıları, fiyatlandırmaları ve özellik kapsamları zaman içinde değişiyor. Bu yazıdaki değerlendirmeler mimari model üzerinedir; güncel özellik ve ücret bilgisi için ilgili sağlayıcının kendi kaynaklarından doğrulama yapmanız gerekir. Hiçbir sağlayıcıyla ticari bağım yok.
Önce: Altyapı Seçimi Ne Kadar Belirleyici?
Sanıldığından az. Sahada gördüğüm tablo şu: aynı altyapıda çok iyi işleyen ve hiç satmayan mağazalar yan yana duruyor.
E-ticaret başarısında etkenlerin göreli ağırlığı
Göreli gösterimdir. Altyapı en alttadır ama sıfır değildir — yanlış seçim bir tavan koyar. Doğru seçim başarı getirmez; yanlış seçim ise büyümeyi belli bir noktadan sonra durdurabilir. Karar bu çerçevede verilmelidir.
Bu yüzden altyapı kararına aylar harcamak yanlış. Ama hiç düşünmeden karar vermek de yanlış — çünkü taşınma maliyeti yüksek ve zamanla artıyor.
Dört Model
Piyasadaki tüm çözümler, dört yapısal modelden birine giriyor. Marka adlarına bakmadan önce bu dördünü ayırt etmek gerekiyor.
Ayrıca kurumsal ticari sürümler var — açık kaynak bir çekirdeğin üzerine kurulmuş, lisanslı ve destekli sürümler (örneğin Adobe Commerce, Magento’nun ticari sürümü olarak konumlanıyor). Bunlar Model 3 ile Model 4 arasında bir yerde duruyor.
Modellerin Yapısal Farkları
Aşağıdaki tablo bir kalite karşılaştırması değil — sorumluluğun kimde olduğunun dökümü.
| Konu | Bulut (SaaS) | Paket/kiralık | Açık kaynak | Özel yazılım |
|---|---|---|---|---|
| Sunucu ve barındırma | Sağlayıcı | Sağlayıcı (modele göre) | Siz | Siz |
| Güncelleme ve yama | Sağlayıcı | Sağlayıcı | Siz | Siz |
| Güvenlik bakımı | Sağlayıcı | Sağlayıcı | Siz | Siz |
| Kaynak koda erişim | Yok / sınırlı | Sınırlı (modele göre) | Tam | Tam |
| Özelleştirme sınırı | Platformun izin verdiği | Modül yapısı kadar | Sınırsız | Sınırsız |
| Başlangıç süresi | En kısa | Kısa | Orta | En uzun |
| Teknik ekip ihtiyacı | Düşük | Düşük–orta | Orta–yüksek | Yüksek |
| Sağlayıcıya bağımlılık | Yüksek | Yüksek | Düşük | Yok |
| Aylık sabit gider | Abonelik | Kira / lisans | Barındırma + bakım | Sunucu + ekip |
Tabloyu okuma biçimi: Sol tarafa gittikçe sorumluluk azalıyor, kontrol de azalıyor. Sağa gittikçe tam tersi. “Hangisi daha iyi” sorusu bu yüzden yanlış kurulmuş bir soru — doğru soru şu: bu sorumluluğu taşıyacak kaynağınız var mı?
Model 1 ve 2: Hazır Altyapılar
Bulut tabanlı ve paket çözümleri birlikte ele alıyorum çünkü kullanıcı açısından deneyim benzer: panelden yönetiyorsunuz, teknik yük sağlayıcıda.
Yapısal olarak size ne sağlıyor
Hız. Ürünlerinizi yükleyip kısa sürede satışa başlayabiliyorsunuz. Sunucu kurulumu, sertifika, güvenlik yapılandırması gibi adımlar ortadan kalkıyor.
Öngörülebilir maliyet. Aylık veya yıllık bir gider var; sürpriz sunucu ve bakım maliyeti yok.
Yerel entegrasyonlar. Türkiye pazarındaki sağlayıcılar genellikle yerel kargo firmaları, ödeme kuruluşları, e-fatura sistemleri, muhasebe programları ve pazaryerleriyle hazır bağlantılar sunuyor. Bu, kendi başına ciddi bir zaman ve maliyet kalemi.
Bakım yükünün olmaması. Güvenlik açığı çıktığında yamayı sağlayıcı geçiyor. Bu, teknik ekibi olmayan firmalar için önemli bir güvence.
Yapısal olarak sınırlarını nereden görürsünüz
Özelleştirme, platformun izin verdiği kadar. Standart dışı bir akış kurmak istediğinizde — özel fiyatlandırma mantığı, alışılmadık bir ürün yapılandırıcısı, kendine özgü bir sipariş süreci — platformun sunduklarıyla sınırlı kalırsınız. Bazı sağlayıcılar geliştirici erişimi veya API sunuyor; kapsamı sağlayıcıya göre değişiyor ve satın almadan önce sorulmalı.
Veri ve taşınabilirlik. Bir gün ayrılmak istediğinizde ürün, müşteri ve sipariş verisini hangi formatta alabileceğiniz kritik. Bu, sözleşme imzalamadan önce sorulması gereken sorudur — sonradan sorulduğunda geç kalınmış oluyor.
Sağlayıcıya bağımlılık. Fiyatlandırma değişebilir, bir özellik kaldırılabilir, hizmet koşulları güncellenebilir. Bunlar sizin kontrolünüzde değil ve iş modelinizin bir parçası hâline geliyor.
SEO tarafında platform kısıtları. URL yapısı, kanonik yönetimi, filtre sayfalarının davranışı, sayfa hızı — bunların ne kadarına müdahale edebildiğiniz platforma göre değişiyor. Platform bazlı ayrımları İkas SEO, Shopify SEO ve WooCommerce SEO sayfalarında ayrı ayrı ele aldım.
Model 3: Açık Kaynak
Kaynak kodu açık ve kendi sunucunuzda çalışan çözümler. Türkiye’de en yaygını, WordPress üzerinde çalışan WooCommerce. Daha büyük ölçekli projelerde Magento ve türevleri, ayrıca PrestaShop ve OpenCart gibi seçenekler kullanılıyor.
Yapısal olarak size ne sağlıyor
Tam kontrol. Kodun tamamına erişiminiz var. İstediğiniz her şeyi değiştirebilirsiniz.
Lisans ücreti yok. Yazılımın kendisi için ödeme yapmıyorsunuz. Maliyet barındırma, geliştirme ve bakımda toplanıyor.
Taşınabilirlik. Veriniz sizde, sunucunuz sizde. Sağlayıcı değiştirmek bir taşınma işlemi, bir kopuş değil.
Geniş ekosistem. Özellikle WooCommerce tarafında çok sayıda eklenti ve tema mevcut, ihtiyaçların çoğu için hazır bir çözüm bulunabiliyor.
Yapısal olarak neyi üstleniyorsunuz
Güvenlik tamamen sizde. Güncelleme geçilmediğinde açık kalıyor. E-ticarette bu, ödeme ve müşteri verisi riski demek. Düzenli bakım isteğe bağlı değil, zorunlu.
Performans yönetimi sizde. Açık kaynak modelinin doğası gereği kurulum üzerine eklenen her bileşen sayfaya yük bindiriyor ve bu yükü dengelemek teknik bir iş. Sahada karşılaştığım tablo genellikle yazılımın kendisiyle değil, yıllar içinde birikmiş ve kimsenin gözden geçirmediği eklenti yığınıyla ilgili oluyor.
Eklenti bağımlılığı ve çakışma riski. Her eklenti üçüncü bir tarafın kodu. Biri güncellenmediğinde ya da diğeriyle çakıştığında site etkileniyor.
Sürekli bir teknik kaynak gerekiyor. Kendi ekibinizde ya da dışarıda. “Kurduk, bitti” diye bir durum yok.
Magento tarafında ayrıca ölçek maliyeti. Güçlü ve büyük kataloglar için tasarlanmış bir yapı; buna karşılık kurulum, barındırma ve geliştirme açısından belirgin biçimde daha ağır. Küçük bir mağazada bu ağırlık karşılığını vermiyor.
En sık yapılan hesap hatası: “Lisans ücreti yok, o hâlde daha ucuz.” Açık kaynakta maliyet ortadan kalkmıyor — yer değiştiriyor. Barındırma, ücretli eklentiler, geliştirici zamanı ve düzenli bakım kalemlerini topladığınızda toplam sahip olma maliyeti, hazır bir altyapının abonelik bedelinin üzerine çıkabiliyor. Karşılaştırma yaparken bu kalemler mutlaka hesaba katılmalı.
Model 4: Özel Yazılım
Sıfırdan geliştirilen çözüm. Doğru koşullarda çok güçlü, yanlış koşullarda en pahalı hata.
Ne zaman gerçekten gerekli
Karar vermeden önce netleşmesi gerekenler
Özel yazılımda proje bittiğinde iş bitmiyor — asıl maliyet orada başlıyor. Sözleşme öncesi netleşmesi gerekenler:
- Kaynak kodun mülkiyeti kimde? Bu, sözleşmede açıkça yazılmalı.
- Bakım ve geliştirme nasıl devam edecek? Aylık kaynak taahhüdü var mı?
- Ekip ayrılırsa ne olur? Devir belgeleri, teknik dokümantasyon, kod standartları.
- Ödeme, kargo, e-fatura, muhasebe entegrasyonları kapsamda mı? Hazır altyapılarda paketin parçası olan bu kalemler, özel yazılımda ayrı ayrı geliştirilecek işler.
- Güvenlik sorumluluğu kimde? Özellikle ödeme ve kişisel veri tarafında.
Karar Ağacı: Hangi Model Size Uygun?
Marka adı seçmeden önce model seçmek gerekiyor. Aşağıdaki sorular sırayla cevaplandığında model genellikle kendiliğinden netleşiyor.
Model seçimi — sırayla sorulacak sorular
Birinci soru en belirleyicisi. Teknik kaynağı olmayan bir firmanın açık kaynak seçmesi, kısa vadede tasarruf gibi görünüp orta vadede güvenlik ve performans sorununa dönüşüyor.
Sağlayıcıyla Konuşurken Sorulacak Sorular
Model netleştikten sonra sıra marka seçimine geliyor. Bu aşamada demo izlemek yeterli değil — sorulması gereken somut sorular var.
Birinci satır her şeyden önemli. Veri taşınabilirliği sorulmadan imzalanan bir sözleşme, ileride altyapı değiştirmek istediğinizde en büyük engel hâline geliyor. Cevabı yazılı olarak almanız gerekiyor.
Kurulum Sırası: Neyin Önce Yapılacağı
Altyapı seçildikten sonra sıra kurulumda. Aşağıdaki sıra, sonradan düzeltmesi pahalı olan işleri öne alıyor.
Yayına almadan önce mutlaka: Geliştirme aşamasında arama motorlarını engellemek için konulan noindex etiketini ve robots.txt kısıtını kaldırdığınızdan emin olun. Bu, e-ticaret sitelerinde en sık yapılan ve aylarca fark edilmeyen hatadır — site kusursuz çalışır, Google’da hiç görünmez.
Mevcut Bir Siteden Taşınıyorsanız
Sıfırdan kurulum ile taşıma farklı işler. Taşımada asıl risk, biriken arama görünürlüğünün kaybedilmesi.
Maliyeti Nasıl Karşılaştırmalı?
Altyapı karşılaştırmasında en yaygın hata, yalnızca aylık bedele bakmak. Anlamlı karşılaştırma toplam sahip olma maliyeti üzerinden yapılır.
Üç yıllık toplam üzerinden hesaplandığında, ilk bakışta pahalı görünen bir seçenek daha ucuz çıkabiliyor — ya da tersi. Karar bu hesapla verilmeli.
Vaka Kurgusu: Yanlış Altyapı Seçiminin Bedeli
Aşağıdaki senaryo, sahada sıkça karşılaşılan bir örüntüyü aktarmak amacıyla temsili olarak kurgulanmıştır; belirli bir müşteriye ait gerçek veri içermez.
Durum: Ev dekorasyonu ürünleri satan, kurucu ortağının teknik geçmişi olmayan bir işletme, “gelecekte her şeyi özelleştirebiliriz” düşüncesiyle doğrudan açık kaynak bir altyapı üzerinde, dışarıdan bir freelance geliştiriciyle siteyi kuruyor. İlk üç ay her şey normal görünüyor: site açılıyor, siparişler geliyor.
Uygulama: Geliştirici projeyi teslim ettikten sonra başka bir işe geçiyor. Site üzerinde düzenli güncelleme yapan kimse kalmıyor. Altı ay içinde kullanılan eklentilerden biri güncellenmiyor, bu da hem bir güvenlik açığına hem de ödeme sayfasında ara sıra yaşanan hatalara yol açıyor. Kategori sayfalarının yüklenme hızı kademeli olarak düşüyor çünkü zamanla eklenen ek modüller sayfaya yük bindiriyor.
Sonuç penceresi (yaklaşık 8-10. aydan itibaren): Yavaşlayan sayfa hızı ve ara sıra yaşanan ödeme hataları, hem dönüşüm oranını hem de arama motoru görünürlüğünü olumsuz etkiliyor. İşletme sahibi, sorunu çözmek için tekrar bir geliştirici arıyor; ancak devraldığı kod tabanının dokümantasyonu eksik olduğundan yeni geliştirici önce mevcut yapıyı anlamak için ayrı bir ücret talep ediyor. Toplamda, ilk kurulumda “tasarruf edilen” lisans ücreti, birikmiş bakım borcu ve kayıp satışlar nedeniyle kat kat geri ödeniyor.
Çıkarılan ders: Açık kaynak modeli, teknik kaynağı sürekli olan işletmeler için güçlü bir seçenektir; ancak “sürekli bakım” kısmı atlanınca avantaj dezavantaja dönüşür. Kuruluş öncesi netleştirilmesi gereken soru şuydu: “Bu siteyi kim, ne sıklıkla bakımdan geçirecek?” Bu soru baştan cevaplanmadan seçilen model, modelin kendisinden bağımsız olarak sorun üretir. (Vaka temsilidir.)
Sık Yapılan Hatalar
- Model kararını marka adına göre vermek. “Herkes bunu kullanıyor” mantığıyla seçilen bir altyapı, işletmenin gerçek ihtiyaçlarıyla örtüşmeyebilir. Önce model (bulut, paket, açık kaynak, özel), sonra marka seçilmeli.
- Veri taşınabilirliğini sözleşme öncesi sormamak. Bu, en sık karşılaşılan ve en pahalıya mal olan ihmaldir. Ayrılma senaryosu düşünülmeden imzalanan bir sözleşme, ileride ciddi bir kilitlenme riski doğurur.
- Yayın öncesi noindex etiketini kaldırmayı unutmak. Geliştirme aşamasında konulan arama motoru engelleri kaldırılmadan siteyi yayına almak, aylarca fark edilmeyen bir görünürlük kaybına yol açar.
- Ölçümü sonradan kurmak. Analiz ve dönüşüm takibi yayından önce kurulmadığında, ilk dönemin verisi geri getirilemez şekilde kaybolur.
- URL yapısını gereksiz yere değiştirmek. Taşıma veya yeniden kurulum sırasında adresleri değiştirmek, yönlendirme haritası eksiksiz hazırlanmadıkça biriken arama görünürlüğünü riske atar.
- Toplam sahip olma maliyetini hesaplamadan karşılaştırma yapmak. Sadece aylık abonelik bedeline bakmak, bakım, entegrasyon ve kesinti maliyetlerini göz ardı eder; bu da yanlış bir “ucuz/pahalı” algısına yol açar.
- Teknik kaynağı olmadan açık kaynak veya özel yazılım seçmek. Güvenlik ve bakım sorumluluğunu üstlenecek kimse yoksa, bu modellerin sunduğu esneklik avantaja değil riske dönüşür.
- Yasal metinleri (mesafeli satış sözleşmesi, KVKK, iade koşulları) yayın sonrasına bırakmak. Bu metinler yayın öncesi tamamlanmalı; sonradan eklemek hem hukuki risk hem de güven kaybı yaratır.
Yapay Zeka Araçlarının E-Ticaret Altyapısındaki Yeri
2026 itibarıyla e-ticaret altyapılarının büyük kısmı, ürün açıklaması üretimi, görsel etiketleme, müşteri destek chatbot’u ve kişiselleştirilmiş ürün önerisi gibi alanlarda yapay zeka destekli özellikler sunuyor veya bu özelliklere kolay entegrasyon imkânı tanıyor. Bulut tabanlı platformlarda bu özellikler genellikle panelden aktif edilebilen hazır modüller şeklinde geliyor; açık kaynak ve özel yazılımda ise üçüncü parti servislerle entegrasyon gerektiriyor.
Altyapı seçerken bu boyutu da değerlendirmek faydalı: yapay zeka destekli arama (ürün içi akıllı arama), otomatik ürün açıklaması üretimi ve müşteri sorularını yanıtlayan chatbot entegrasyonları, özellikle geniş kataloglu mağazalarda operasyonel yükü ciddi ölçüde azaltabiliyor. Ancak bu araçların ürettiği içerik (özellikle ürün açıklamaları) yayınlanmadan önce mutlaka insan gözden geçirmesinden geçmeli — hem doğruluk hem de marka sesi tutarlılığı açısından.
Ayrıca arama motorlarının yapay zeka destekli özetleme özellikleri (AI Overview ve benzeri) büyüdükçe, ürün ve kategori sayfalarının yapısal veri (structured data) ile net biçimde işaretlenmesi daha da önem kazanıyor. Hangi altyapıyı seçerseniz seçin, ürün şeması, fiyat, stok durumu ve değerlendirme puanlarının doğru şekilde işaretlenip işaretlenemediğini kuruluş öncesi sorgulamak gerekiyor.
Sıkça Sorulan Sorular
Sağlayıcı Değiştirme Kararını Ne Zaman Gündeme Almalı?
Mevcut altyapıdan memnuniyetsizlik her zaman “altyapıyı değiştirmek” anlamına gelmemeli. Değişim kararı vermeden önce, sorunun kaynağının gerçekten altyapı mı yoksa yapılandırma mı olduğunu ayırt etmek gerekiyor.
| Belirti | Altyapı Sorunu Olabilir | Yapılandırma/Kullanım Sorunu Olabilir |
|---|---|---|
| Sayfa hızı düşük | Platform mimarisi ağır, optimizasyon seçeneği kısıtlı | Gereksiz eklenti/uygulama birikmiş, görseller optimize edilmemiş |
| Belirli bir özellik yok | Platform bu özelliği hiç desteklemiyor | Özellik var ama doğru yapılandırılmamış |
| Entegrasyon çalışmıyor | Sağlayıcı ilgili sistemle hazır bağlantı sunmuyor | API doğru kurulmamış veya güncel değil |
| Destek yavaş | Sağlayıcının destek kapasitesi yetersiz | Yanlış kanaldan veya yanlış önceliklendirmeyle destek talebi açılmış |
| SEO sonuçları zayıf | Platform kritik SEO kontrollerine izin vermiyor | İçerik, iç link ve teknik SEO çalışması eksik |
Bu ayrımı yapmadan altyapı değiştirmek, aynı sorunları yeni platformda tekrar üretme riski taşır. Değişim kararından önce mevcut kurulumun bir teknik denetimden geçmesi, gereksiz bir taşıma maliyetinden tasarruf ettirebilir.
Yayın Öncesi Son Kontrol Listesi
Site teknik olarak hazır göründüğünde bile, yayına almadan önce aşağıdaki maddelerin tek tek doğrulanması, sonradan ortaya çıkabilecek maliyetli sürprizlerin büyük kısmını önler.
- URL yapısı nihai mi? Kategori ve ürün URL’lerinin yayından sonra değişmeyeceğinden emin olun; değiştirilmesi gereken bir durum çıkarsa mutlaka 301 yönlendirmesiyle yapılmalı.
- noindex ve robots.txt kısıtları kaldırıldı mı? Geliştirme aşamasında konulan arama motoru engelleri hâlâ aktifse, site yayında olsa bile Google tarafından görülmez.
- Ödeme akışı gerçek bir kartla uçtan uca test edildi mi? Test modunda çalışan bir ödeme sayfası, canlı ortamda farklı davranabilir; 3D Secure dönüşü dahil tüm adımlar denenmeli.
- Analiz ve dönüşüm takibi doğru olaylara bağlı mı? Sepete ekleme, ödeme başlatma ve satın alma olaylarının doğru tetiklendiği, gerçek bir test siparişiyle doğrulanmalı.
- Mesafeli satış sözleşmesi, iade koşulları ve KVKK metinleri yayında mı? Bu metinlerin eksik veya güncel olmayan sürümlerle yayına çıkması hem hukuki risk hem de müşteri güveni açısından sorun yaratır.
- Mobil deneyim test edildi mi? Trafiğin büyük kısmı mobil cihazlardan geldiğinden, sipariş akışının mobilde de sorunsuz çalıştığından emin olunmalı.
- Yedekleme ve kurtarma planı var mı? Açık kaynak veya özel yazılım kullanılıyorsa, düzenli otomatik yedekleme ve olası bir arıza durumunda geri dönüş süresi netleştirilmeli.
- Sitemap ve yapısal veri gönderildi mi? Search Console’a sitemap gönderimi ve ürün/kategori sayfalarındaki yapısal veri işaretlemesi, arama motorlarının siteyi doğru anlaması için baştan yapılmalı.
Bu liste, kurulumun teknik olarak “bitmiş” görünmesi ile “yayına hazır” olması arasındaki farkı kapatmayı hedefler. Deneyimler gösteriyor ki, listenin atlanan tek bir maddesi bile aylar sonra fark edilen ve düzeltmesi orantısız zaman alan bir soruna dönüşebiliyor.
Özetle
Altyapı seçimi bir kalite sıralaması değil, bir sorumluluk dağılımı tercihi. Bakımı ve güvenliği sağlayıcıya bırakmak istiyorsanız hazır altyapılar; tam kontrol istiyor ve teknik kaynağınız varsa açık kaynak; iş akışınız gerçekten standart dışıysa özel yazılım.
Yanlış seçim genellikle şuradan çıkıyor: teknik kaynağı olmayan bir firmanın kontrol istemesi, ya da standart bir mağazanın kendine özel bir sistem istemesi. İkisi de sonradan pahalıya mal oluyor.
Ve şunu unutmamak gerekiyor: altyapı, e-ticaret başarısının en küçük bileşeni. Doğru seçim size satış getirmiyor — sadece önünüzü açık tutuyor.
Kurulum sonrası tarafı için e-ticaret SEO sayfasına, tasarım ve dönüşüm kurgusu için e-ticaret web tasarım yazısına, kanal kararı için pazaryeri mi kendi siteniz mi yazısına bakabilirsiniz.
Altyapı seçimini kendi durumunuza göre birlikte değerlendirmek isterseniz iletişim sayfasından ulaşabilirsiniz.
Stok tutmadan satacaksanız: Stoksuz e-ticaret (dropshipping) rehberi
