Tecof • 15 Eylül 2026
Headless Commerce Nedir? Geleneksel E-ticaretten Farkları
Kısaca
Headless commerce, bir e-ticaret sisteminin yüzünü (vitrini) arkasından (katalog, sepet, sipariş, ödeme) ayıran mimaridir. Geleneksel kurulumda bu iki kısım tek paket olarak gelir ve tema değiştirmek dışında vitrine müdahale sınırlıdır. Headless'ta vitrin ayrı bir uygulamadır, ticaret fonksiyonlarına API üzerinden bağlanır ve tamamen size ait bir kodla yazılır. Kazancı esneklik ve hız, bedeli sürekli bakım yapılması gereken ikinci bir yazılım. 2026 itibarıyla soru "headless mi monolit mi" değil, "vitrini ayrı tütmenin bedelini karşılayacak kadar özel bir vitrinim var mı" sorusudur.
Perşembe akşamı 18.10. Yıllık 40 milyon TL ciro yapan bir mobilya mağazası headless geçişini altı ay önce tamamladı. Mobil açılış süresi 4,1 saniyeden 1,3 saniyeye indi, dönüşüm oranı yüzde 1,4'ten yüzde 1,9'a çıktı. Aynı akşam bir sorun da var: kargo firması entegrasyonu güncellendiğinde vitrindeki teslimat tarihi bloku iki gün bozuk kaldı, çünkü o blok artık panelin değil ekibin yazdığı kodun içinde.
İki tablo da gerçek ve ikisi aynı madalyonun yüzleri. Headless vitrini size verir; vitrinin sorumluluğunu da verir. Kararı belirleyen şey teknoloji hevesi değil, o sorumluluğu sürdürebilecek bir ekibinizin olup olmaması.
Headless Commerce Nedir, Geleneksel Yapıdan Nerede Ayrılır?
Adaki "head", kullanıcının gördüğü katmanı anlatır: ürün sayfası, liste, sepet ekranı, kampanya blokları. "Headless" ise bu katmanın sistemden sökülmesi, yerine istediğiniz teknolojiyle yazılmış bağımsız bir uygulamanın konması anlamına geliyor.
Monolitik yapı: tek paket
Geleneksel e-ticaret altyapılarında vitrin ile ticaret motoru aynı yazılımın içindedir. Tema seçersiniz, renkleri ve blokları panelden düzenlersiniz, bir kampanya bloku eklemek istediğinizde temayı düzenlersiniz. Avantajı şu: her şey birlikte güncellenir, önizleme çalışır, panelden yapılan değişiklik aynen yayına gider ve kimse kod yazmak zorunda kalmaz. Dezavantajı, kalıbın dışına çıkmak istediğinizde duvara çarpmanız.
Headless: baş ile gövdenin ayrılması
Headless kurulumda iki ayrı yazılım vardır. Arkada ticaret motoru çalışır: ürünler, stok, fiyat, sepet mantığı, sipariş, ödeme ve iade. Önde kendi yazdığınız vitrin uygulaması durur ve ihtiyacı olan her veriyi API çağrısıyla arkadan alır. Ürün sayfasını nasıl kurgulayacağınız, hangi bilgiyi nereye koyacağınız, hangi animasyonu kullanacağınız tamamen size kalır. Bu bağlantının nasıl kurulduğunu API ve entegrasyon yazısında ayrıntılı anlattık.
Terimler: API-first, composable, PWA
- API-first: sistemin bütün fonksiyonlarının önce API olarak tasarlanması. Panelden yapılabilen her şey API'den de yapılabilir demektir; headless'ın ön koşulu budur.
- Composable commerce: her işlevi (arama, ödeme, içerik, sadakat) ayrı sağlayıcıdan alma yaklaşımı. Headless'ın bir üst basamağıdır ve karmaşıklığı hızla arttırır.
- PWA: tarayıcıda çalışan ama uygulama gibi davranan vitrin. Headless ile sık birlikte anılır ama zorunlu değildir; uygulama mı site mi tartışması buradan başlar.
- BFF: vitrin ile API'ler arasına konan ara katman. Çok sayıda çağrıyı birleştirir; büyüyen headless projelerde kaçınılmaz hale gelir.
| Başlık | Monolitik | Headless | Kimin sorumluluğunda değişir |
|---|---|---|---|
| Vitrin değişikliği | Panel ya da tema | Kod deployu | Pazarlamadan yazılıma geçer |
| Hız optimizasyonu | Altyapı sağlar | Ekip yazar | Sağlayıcıdan ekibe geçer |
| Güvenlik yamaları | Otomatik gelir | Vitrin tarafı sizde | Kısmen size geçer |
| Yeni kanal ekleme | Sınırlı | Aynı API ile kolay | Avantaj headless'ta |
| İçerik önizleme | Hazır çalışır | Ayrı kurulur | Ek iş kalemi |
Ne Kazandırır: Hız, Kanal Çeşitliliği, Tasarım Özgürlüğü
Headless'ın vaatleri gerçek, ama her biri koşullu. Koşulları bilmeden karar verilen projeler altıncı ayda duruyor.
Hız kazancının gerçeği
Headless vitrin hızlı olmak zorunda değil, hızlı olabilir. Kazancın kaynağı şu: sayfayı önceden üretip statik olarak sunmak, yalnızca gereken veriyi çekmek, kullanılmayan kodu hiç yüklememek. İyi yazılmış bir headless vitrinde mobil açılış süresinin 1,5 saniyenin altına inmesi normaldir. Kötü yazılmış bir headless vitrin, tema tabanlı bir siteden yavaş olabilir; üç farklı analitik kütüphanesi ve gereksiz istemci kodu hızı aynı şekilde öldürür. Dağıtım tarafında CDN kurgusu bu denklemin yarısını oluşturur.
Çok kanal tek katalog
Aynı ticaret motoruna hem web sitesi, hem mobil uygulama, hem mağaza içi kiosk, hem de bir pazaryeri besleme servisi bağlanabilir. Türkiye özelinde asıl kazanç burada görünüyor: Trendyol ve Hepsiburada beslemeleri, kendi siteniz ve varsa fiziksel mağazanız tek katalogdan yönetildiğinde stok çakışması düşüyor. Ancak bunun için headless şart değil; API-first bir altyapı yeterli. Headless bu resimde yalnızca vitrinin de özel olması gerekiyorsa devreye giriyor.
Tasarım ve deneyim özgürlüğü
Yapılandırıcı ürünler, oda görselleştirme, ölçü seçici, kişiye özel üretim akışları — hazır temalarla yapılması zor olan bu deneyimler headless'ın asıl gerekçesi. Mobilya, halı, mücevher, medikal cihaz gibi kategorilerde ürün sayfası aslında bir uygulamadır; oraya hazır bir şablon sığmaz. Buna karşılık standart bir hazır giyim mağazasında ürün sayfası zaten çözülmüş bir problemdir ve özel yazılması dönüşüme karşılık gelmiyor.
Ne Maliyeti Var: Ekip, Süre, Bakım
Headless tartışmalarında en sık atlanan kalem, projenin bitmemesi. Vitrin yazdığınız anda bakım sorumluluğu doğuyor ve bu sorumluluk kapanmıyor.
İki yıllık toplam maliyet
| Kalem | Monolitik | Headless | Not |
|---|---|---|---|
| Kurulum süresi | 2-6 hafta | 3-6 ay | Entegrasyon sayısıyla artar |
| Vitrin geliştirme | Tema ücreti | Ekip ya da ajans | En büyük kalem |
| Aylık bakım | Altyapıda | Sürekli geliştirici | Yarım kişiden aşağı düşmez |
| Kampanya değişikliği | Saatler | Sprint | Pazarlama hızını etkiler |
| Yeni kanal | Yüksek | Düşük | Headless'ın net avantajı |
Gereken ekip
Minimum kadro şu: bir frontend geliştirici, bir de API ve entegrasyon tarafına bakan geliştirici, artı tasarımcı erişimi. Bu kadro yarı zamanlı olabilir ama sıfır olamaz. Tek kişiye bağlı headless projeleri, o kişi ayrıldığında donduğu için en riskli kurulum biçimi. Ajansla çalışıyorsanız sözleşmeye bakım maddesini ve kod devrini açık yazın.
Kaybettikleriniz
Headless'a geçerken kaybedilen şeyler genellikle listelenmiyor: panelden sayfa düzenleme, hazır önizleme, tema pazarındaki yüzlerce seçenek, eklenti ekosistemi ve güncellemelerin otomatik gelmesi. Pazarlama ekibinin "şu bloku şuraya alalım" talebi, monolitik yapıda yarım saatlik bir iş iken headless'ta bir geliştirme kalemine dönüşüyor. Bu, kararın en sık göz ardı edilen ve en çok pişmanlık üreten tarafı.
Kimin İçin Doğru, Kimin İçin Değil
Kararı duyguyla değil eşikle vermek gerekir. Aşağıdaki tablo sahadaki eğilimi özetliyor.
| Durum | Yıllık ciro | Teknik ekip | Öneri |
|---|---|---|---|
| Standart katalog, tek kanal | 0-15 milyon TL | Yok | Monolitik kalın |
| Pazaryeri + kendi site | 15-50 milyon TL | Dış kaynak | API-first monolitik |
| Özel ürün yapılandırıcısı | 15 milyon TL üstü | Var | Headless mantıklı |
| Çoklu ülke ve para birimi | 50 milyon TL üstü | Var | Headless ya da hibrit |
| B2B + B2C aynı katalog | 50 milyon TL üstü | Var | Headless güçlü aday |
Türkiye bağlamında ek kalemler
Yerel kurulumda headless kararını etkileyen üç başlık var. Birincisi muhasebe ve ERP tarafı: Logo, Mikro ya da Netsis entegrasyonu vitrinden bağımsızdır, yani headless geçişi bu işi ne kolaylaştırır ne zorlaştırır. İkincisi e-fatura ve GİB uyumu: bunlar arka uçta durur, vitrine dokunmaz. Üçüncüsü kargo: Yurtiçi ve Aras entegrasyonlarının güncellenmesi vitrindeki teslimat bloklarını etkiler ve bu blok headless'ta sizin sorumluluğunuzdadır. Bu üç kalem, geçişin "tamamen frontend işi" olmadığını gösteriyor. Seçim hatalarını altyapı seçimi yazısında, platform karşılaştırmasını ise üç popüler altyapının karşılaştırmasında ele aldık.
Ara Yol: Hibrit Kurulum ve Ajanik Katman
Tartışma genellikle ikili kurulur ama sahada en çok işe yarayan üçüncü bir yol var: gövdeyi hazır bırakıp yalnızca ihtiyacın olduğu sayfayı ayırmak.
Kısmi headless
Ürün yapılandırıcısı olan bir kategoriyi ayrı bir uygulama olarak yazıp geri kalan sayfaları panelde tutmak, maliyetin büyük bölümünü ödemeden kazancın büyük bölümünü alıyor. Ana sayfa, kategori listeleri ve blog panelde kalır, pazarlama ekibi özgürlüğünü korur; yalnızca bir akış özel yazılır.
Vitrin değil ajan ayırmak
Son iki yılın değişimi şu: ticaret fonksiyonlarına bağlanan şey artık yalnızca bir vitrin değil, yapay zeka ajanları da olabiliyor. Katalog, sipariş ve analitik fonksiyonları API olarak açıksa, stok kontrolü ya da fiyat güncellemesi bir ajana devredilebiliyor. Bu, headless'ın asıl teknik ön koşulunun API-first olması olduğunu bir kez daha gösteriyor; tanımlı yetki sınırlarıyla çalışan ajanlar aynı fonksiyonları kullanıyor.
Önce hızı ölçün, sonra mimariyi tartışın
Headless gerekçesi "sitemiz yavaş" ise, geçiş öncesinde üç şey denenmeli: görsellerin modern formata çevrilmesi, üçüncü parti betiklerin temizlenmesi ve önbellek ayarı. Sahada bu üç adımın tek başına 4 saniyeyi 2 saniyenin altına çektiği çok örnek var ve maliyeti headless projesinin yüzde biri.
30 Günde Kararı Vermek
Headless kararı mimari tartışmasıyla değil, ölçümle verilir. Aşağıdaki takvim, tartışmayı veriye çevirir.
1-7. gün: mevcut durumu ölçün
Mobil açılış süresi, en çok trafik alan beş sayfanın hızı, dönüşüm oranı ve sepeti terk oranını yazın. Bu hafta karar alınmaz, taban çizgisi kurulur. Taban çizgisi olmayan bir geçiş sonradan "daha iyi oldu mu" sorusunu cevaplayamaz.
8-14. gün: karşılanmayan talepleri listeleyin
Son altı ayda "bunu yapamadık" denen bütün vitrin taleplerini tek listeye alın. Her birinin yanına neden yapılamadığını yazın: tema sınırı mı, veri eksiği mi, zaman mı? Bu listenin en az üçte ikisi tema sınırından değil veri ve zaman eksiğinden geliyorsa headless sorunu çözmez.
15-21. gün: ucuz iyileştirmeleri uygulayın
Görsel optimizasyonu, betik temizliği ve önbellek ayarını yapın, sonra 1. haftadaki ölçümleri tekrarlayın. Hız hedefinize buradan ulaşıyorsanız headless gerekçesi hız olmaktan çıkıyor ve karar yalnızca özel deneyim ihtiyacına kalıyor.
22-30. gün: tek sayfayla pilot yapın
Karar hâlâ headless yönündeyse, en çok kazandıran tek sayfayı (genellikle ürün detayı) ayırıp pilot olarak yazın. Pilotun üç ölçüsü olsun: açılış süresi, dönüşüm ve geliştirme günü. Üçüncüsü genellikle tahminin iki katı çıkar ve asıl bilgi oradadır.
Yarın sabah yapabileceğiniz iş şu: son altı ayda vitrinde yapmak isteyip yapamadığınız üç şeyi yazın ve her birinin yanına "bu tema sınırı mı, yoksa zaman sınırı mı" diye not düşün. Üçü de zaman sınırıysa mimariyi değil takvimi değiştirmeniz gerekiyor. API-first bir e-ticaret kurulumunda vitrini ayrı yazma seçeneği açık kalır, pazaryeri ve ERP entegrasyonları ise her iki durumda aynı yerde durur.
Sıkça Sorulan Sorular
Headless her zaman daha hızlı mıdır?
Hayır. Headless hızlı olma imkânı verir, hızı garanti etmez. Kötü kurgulanmış bir headless vitrin, gereksiz istemci koduyla tema tabanlı bir siteden yavaş kalabilir. Hızı belirleyen şey mimari değil, sayfada ne kadar iş yapıldığı.
Headless'a geçince SEO'm zarar görür mü?
Doğru kurgulanırsa görmez, aksine hız kazancıyla fayda sağlar. Risk iki yerde: sunucu tarafı render kurulmazsa içerik taranamaz, ve URL yapısı değişirse eski adresler yönlendirilmediği için trafik kaybedilir. Geçiş planında yönlendirme tablosu ayrı bir kalem olmalı.
Küçük bir mağaza headless'a geçmeli mi?
Genellikle hayır. Standart kataloğu olan, tek kanaldan satan ve teknik ekibi olmayan bir mağazada headless'ın getirdiği esneklik kullanılmaz, bakım maliyeti ise ödenir. Aynı bütçe reklam ve içerik tarafında çok daha fazla dönüş getirir.
Geçiş ne kadar sürer?
Tek vitrin, sınırlı entegrasyon ve hazır bir ticaret motoruyla üç ay gerçekçi bir alt sınır. ERP, pazaryeri beslemesi, çok dil ve B2B fiyat listeleri devreye girdiğinde altı ayı geçiyor. Tahminin şaştığı yer genellikle vitrin değil, entegrasyonların test edilmesi.
Pazarlama ekibi sayfayı kendi düzenleyebilir mi?
Yalnızca bunun için ayrı bir içerik yönetim katmanı kurarsanız. Kurulmazsa her değişiklik geliştirme kuyruğuna girer. Bu katmanı ilk sürüme dahil etmeyen projelerde altıncı aydan sonra en büyük şikâyet buradan geliyor.
Composable commerce ile headless aynı şey mi?
Hayır. Headless yalnızca vitrini ayırır; composable, arka uçtaki her işlevi de ayrı sağlayıcıya böler. Composable esnekliği en üst düzeye çıkarır ama entegrasyon ve sözleşme yönetimini de çoğaltır; beş kişilik bir teknoloji ekibi olmadan yönetilmesi zor.
Headless mobil uygulama gerektirir mi?
Gerektirmez. Aynı API'den bir mobil uygulama beslemek kolaylaşır, ama uygulama kararı ayrı bir iş kararıdır ve trafiğinizin tekrar etme oranına bakmak gerekir. Tek seferlik alım yapılan kategorilerde uygulama nadiren karşılık veriyor.
Geçişi ajansa vermek mi, iç ekip kurmak mı daha iyi?
İlk sürüm ajansla hızlanır, bakım iç ekiple sürdürülebilir. Ajans seçiyorsanız sözleşmede üç maddeyi arayın: kodun tam devri, bağımlılık listesinin belgelenmesi ve en az altı ay bakım taahhüdü. Bu üçü yoksa proje değil borç satın alıyorsunuz.
Headless'tan geri dönmek mümkün mü?
Mümkün ama ucuz değil. Gövde aynı kaldığı için veriniz güvendedir; kaybedilen şey vitrine yapılan yatırım ve geçiş sırasındaki trafik dalgalanması olur. Bu yüzden pilotla başlamak, tam geçiş yapmaktan her zaman daha akıllı.