> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/headless-commerce-klasik-e-ticaret-altyapisi-farki*

---

# Headless Commerce Nedir? Klasik E-Ticaret Altyapısından Farkı Ne?

*Yayın Tarihi: 2026-08-18 04:00:01*

Klasik bir e-ticaret platformunda ürün yönetimi, tema, kategori sayfaları, sepet, müşteri hesabı ve checkout çoğunlukla aynı ürünün içinde gelir. Headless commerce mimarisinde ise kullanıcının gördüğü vitrin, ticari işlemleri yöneten backend’den ayrılır. Özel web sitesi, mobil uygulama, kiosk veya başka bir satış deneyimi; ürün, fiyat, stok, sepet ve müşteri verisini API’ler üzerinden commerce sisteminden alır.
Bu ayrım tasarım ve kanal özgürlüğü sağlayabilir; ancak hazır temanın üstlendiği routing, cache, arama, oturum, checkout geçişi, izleme, SEO ve yayın operasyonlarının bir bölümünü artık geliştirme ekibi yönetir. Bu nedenle headless commerce “daha modern olduğu için her mağazaya daha iyi” bir çözüm değildir.
Bu rehber mevcut Headless CMS içeriğini tekrar etmez. Odak, içerik deposu değil; katalog, fiyat, stok, sepet, müşteri, checkout ve sipariş işlemlerini yöneten e-ticaret altyapısının özel frontend’lerle nasıl çalıştığıdır.

## Headless commerce nedir?

Headless commerce, storefront olarak adlandırılan kullanıcı arayüzünün commerce backend’den ayrıldığı e-ticaret mimarisidir. Frontend ürün kataloğu, koleksiyonlar, fiyatlar, sepet, müşteri hesabı ve checkout ile ilgili verileri Storefront API, GraphQL veya REST servisleri üzerinden kullanır.
Shopify, custom storefront’ların ürün ve koleksiyon görüntüleme, sepete ekleme ve checkout gibi commerce yeteneklerine Storefront API üzerinden erişebildiğini belirtir  [Shopify Storefront API ile Headless Geliştirme](https://shopify.dev/docs/storefronts/headless/building-with-the-storefront-api). Adobe Commerce da web API’lerinin üçüncü taraf entegrasyonları ve headless uygulamalar oluşturmak için kullanılabildiğini açıklar  [Adobe Commerce Web API](https://developer.adobe.com/commerce/webapi/).
**Kısa tanım:** Klasik e-ticarette vitrin ve ticari motor aynı paket içinde çalışır. Headless commerce’ta vitrin bağımsız geliştirilir; commerce backend katalog ve transaction yeteneklerini API ile sunar.

## Headless commerce mimarisi hangi katmanlardan oluşur?

- **Storefront frontend:** Web sitesi, mobil uygulama, kiosk veya başka müşteri arayüzü.

- **Commerce backend:** Ürün, fiyat, stok, sepet, müşteri, promosyon, checkout ve sipariş işlemleri.

- **API katmanı:** Frontend ile commerce servisleri arasındaki GraphQL veya REST iletişimi.

- **İçerik katmanı:** Kampanya, landing page ve editoryal içerik için CMS veya headless CMS.

- **Arama ve öneri:** Ürün araması, filtreleme, kişiselleştirme ve merchandising servisleri.

- **Entegrasyonlar:** ERP, PIM, CRM, ödeme, kargo, pazaryeri ve analitik sistemleri.

- **Frontend hosting ve cache:** CDN, edge, server rendering ve deploy altyapısı.

Headless commerce tek bir API çağrısından ibaret değildir. Sepete ürün ekleme, oturum taşıma, müşteri girişi, pazar ve para birimi bağlamı, indirimler ve checkout gibi durum bilgisi taşıyan işlemlerin uçtan uca tasarlanması gerekir.

## Klasik e-ticaret altyapısı nasıl çalışır?

Klasik veya monolitik e-ticaret platformunda backend ve sunum katmanı aynı uygulama yaşam döngüsüne bağlıdır. Platformun tema motoru katalog verisini işler, HTML çıktısını üretir, sepet oturumunu yönetir ve checkout’a doğrudan bağlanır.
Bu yapı mutlaka eski veya yavaş değildir. Olgun platformlar; tema, uygulama, ödeme, müşteri hesabı, yönetim paneli ve operasyon araçlarını hazır sunabilir. Küçük ve orta ölçekli işletmeler için tek platformun güncelleme, güvenlik ve uyumluluk sorumluluğunu azaltması önemli avantajdır.

## Headless commerce ile klasik e-ticaret arasındaki temel farklar

KriterKlasik e-ticaretHeadless commerce
FrontendPlatformun tema veya storefront sistemiBağımsız web veya uygulama projesi
Backend bağlantısıPlatform içinde doğrudanStorefront API, GraphQL veya REST
Tasarım özgürlüğüTema ve platform sınırlarına bağlıFrontend teknoloji ve deneyimi daha serbest
CheckoutPlatformla doğal olarak bütünleşikHosted checkout veya özel API akışıyla bağlanır
Yayın süreciTema ve platform deployment’ıFrontend, backend ve entegrasyonlar ayrı yayınlanabilir
Teknik ekip ihtiyacıDaha düşük olabilirFrontend, API, DevOps ve QA uzmanlığı gerekir
Operasyon maliyetiDaha öngörülebilir olabilirHosting, izleme, API ve bakım katmanları artar
Çoklu kanalPlatformun hazır kanallarıyla sınırlı olabilirAynı backend farklı özel storefront’ları besleyebilir

## Headless CMS ile headless commerce aynı şey midir?

Hayır. Headless CMS; metin, görsel, kampanya ve editoryal içeriği API ile sunar. Headless commerce ise ürün, fiyat, stok, sepet, müşteri, ödeme ve sipariş gibi ticari verileri ve işlemleri yönetir.
Bir projede ikisi birlikte kullanılabilir. Örneğin CMS ana sayfa ve kampanya içeriğini, commerce backend ise ürün fiyatını ve sepete ekleme işlemini sağlar. Ancak içerik CMS’si tek başına sipariş veya stok motoru değildir. Bu ayrım, mevcut Headless CMS içeriğiyle cannibalization oluşmasını önleyen ana sınırdır.

## Headless commerce ile composable commerce aynı şey midir?

Headless, öncelikle frontend ile commerce backend’in ayrılmasını ifade eder. Composable commerce ise katalog, arama, checkout, promosyon, CMS ve diğer iş yeteneklerinin bağımsız bileşenler halinde seçilip birleştirilmesini hedefler.
Bir sistem headless olabilir fakat commerce backend’in büyük bölümü tek platformda kalabilir. Composable yapı genellikle daha fazla servis, sözleşme, veri senkronizasyonu ve vendor yönetimi gerektirir. Bu nedenle iki terim birbirinin yerine otomatik kullanılmamalıdır.

## Headless commerce hangi avantajları sağlayabilir?

- Markaya özel ve tema sınırlarından bağımsız kullanıcı deneyimi.

- Web, mobil, kiosk ve diğer kanallarda ortak commerce backend kullanımı.

- Frontend’in commerce backend’den bağımsız yayınlanabilmesi.

- Belirli sayfalarda server rendering, edge cache ve statik üretim seçenekleri.

- İçerik, arama ve öneri servislerinin ihtiyaca göre seçilebilmesi.

- Farklı ülke, marka veya iş modeli için ayrı storefront’lar oluşturulabilmesi.

- Frontend teknoloji yığınının ekip yetkinliğine göre seçilebilmesi.

Shopify Headless kanalı aynı mağaza için birden fazla custom storefront ve Storefront API erişim anahtarı yönetilmesini destekler  [Shopify Headless Build Seçenekleri](https://shopify.dev/docs/storefronts/headless/getting-started/build-options). Bu özellik çoklu deneyim ihtiyacını kolaylaştırabilir; ancak her storefront ayrı test ve bakım yüzeyi oluşturur.

## Headless commerce otomatik olarak daha hızlı mıdır?

Hayır. Headless mimari performans için daha fazla kontrol sağlar, fakat iyi performansı garanti etmez. Büyük JavaScript bundle’ı, seri API çağrıları, yavaş backend, cache eksikliği veya client-side render edilen ana içerik klasik temadan daha yavaş sonuç üretebilir.
Google’ın web performansı rehberi, server-side rendering’in HTML cevabında içerik ve görsellerin daha erken keşfedilmesine yardımcı olabileceğini belirtir  [Google web.dev – LCP Optimizasyonu](https://web.dev/articles/optimize-lcp). Buna rağmen TTFB, CDN, API gecikmesi, görseller ve hydration maliyeti ayrıca ölçülmelidir.
Performans alanıHeadless fırsatıHeadless riski
HTML üretimiSSR veya statik üretimYavaş server render ve API zinciri
CacheCDN ve edge seviyesinde ayrıntılı kontrolFiyat ve stok için yanlış cache süresi
JavaScriptİhtiyaca göre frontend geliştirmeBüyük bundle ve ağır hydration
GörsellerÖzel responsive image pipelineOptimizasyonsuz medya ve geç keşif
APIİhtiyaç kadar veri sorgulamaÇok sayıda seri request ve rate limit

## Headless commerce SEO açısından riskli midir?

Headless commerce SEO’ya karşı değildir; ancak frontend’in doğru HTML, URL ve meta çıktısını üretmesi gerekir. Google JavaScript’i işleyebilir, fakat JavaScript uygulamalarında crawling, rendering ve indexing farklı aşamalardan geçtiği için geliştiricilerin teknik sınırlamaları dikkate alması gerekir  [Google JavaScript SEO Temelleri](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics).
Ürün ve kategori sayfalarında aşağıdakiler ilk HTML veya güvenilir render çıktısında bulunmalıdır:

- Benzersiz title, meta description ve canonical.

- Ürün adı, açıklama, fiyat ve stok bilgisi.

- Google tarafından taranabilen gerçek HTML bağlantıları.

- Product, Offer, Breadcrumb ve gerekli structured data.

- Kalıcı kategori, ürün ve varyant URL’leri.

- Doğru HTTP durum kodları ve redirect davranışı.

Google, JavaScript kaynaklı sorunlarda URL Inspection ve render edilmiş HTML kontrolünü önerir  [Google JavaScript Arama Sorunlarını Düzeltme](https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript). Headless migration öncesinde URL envanteri ve redirect planı hazırlanmalıdır.

## API katmanı nasıl tasarlanmalıdır?

Frontend’in commerce backend’e doğrudan çok sayıda sorgu göndermesi yerine gerektiğinde Backend for Frontend veya server katmanı kullanılabilir. Bu katman erişim anahtarlarını korur, birden fazla servisten gelen veriyi birleştirir, cache uygular ve frontend’e ihtiyaç duyduğu yanıtı verir.
Shopify Storefront API ürün, koleksiyon, sepet ve checkout deneyimlerini özel storefront’lara açar  [Shopify Storefront API](https://shopify.dev/docs/api/storefront). Adobe Commerce GraphQL API de frontend geliştirme için katalog, sepet, müşteri ve diğer commerce yeteneklerine tek endpoint üzerinden erişim sağlar  [Adobe Commerce GraphQL API](https://developer.adobe.com/commerce/webapi/graphql/reference/).
API tasarımında yetkilendirme, rate limit, timeout, retry, idempotency, cache invalidation ve gözlemlenebilirlik baştan planlanmalıdır.

## Sepet ve checkout headless yapıda nasıl çalışır?

Frontend sepete ekleme işlemini Storefront API üzerinden yapabilir ve commerce backend bir cart kimliği üretir. Kullanıcı checkout’a geçtiğinde platformun hosted checkout’una yönlendirilebilir veya desteklenen API’lerle özel akış kurulabilir.
Hosted checkout ödeme güvenliği, vergi, kargo ve platform güncellemelerinin büyük bölümünü sağlayıcıda tutabilir. Tam özel checkout ise daha fazla kontrol verir; ancak ödeme uyumluluğu, hata durumları, adres doğrulama ve sipariş bütünlüğü sorumluluğunu artırır.
Sepet kimliği, müşteri oturumu, pazar, para birimi ve indirimlerin storefront ile checkout arasında korunması gerekir. Aksi halde kullanıcı sepete eklediği ürünleri veya giriş durumunu checkout’ta kaybedebilir.

## Müşteri hesabı ve kimlik doğrulama neden karmaşıktır?

Klasik platformda müşteri girişi tema, hesap sayfası ve checkout ile doğal olarak bağlıdır. Headless yapıda frontend kimlik doğrulama akışını, token yaşam döngüsünü, güvenli cookie kullanımını ve checkout’a oturum taşımasını ayrıca uygular.
Shopify Customer Account API müşteri, sipariş, ödeme, fulfillment, indirim ve iade gibi müşteri kapsamlı verilere authenticated erişim sağlar; API sürümleri düzenli güncellenir  [Shopify Customer Account API](https://shopify.dev/docs/storefronts/headless/building-with-the-customer-account-api). Bu sürüm ve yetkilendirme yaşam döngüsü operasyon planına dahil edilmelidir.

## Headless commerce entegrasyon maliyetini nasıl değiştirir?

ERP, PIM, CRM, arama, CMS, ödeme ve kargo sistemleri klasik platformda uygulama veya eklentiyle bağlanabilir. Headless projede bu servislerin frontend ve commerce backend arasındaki sorumluluk sınırları açıkça tasarlanmalıdır.
[E-ticaret entegrasyonu](/e-ticaret-entegrasyon-hizmeti) yalnız endpoint bağlamak değildir. Ürün kimliği, fiyat, stok, müşteri, sipariş ve event verisinin hangi sistemde ana kayıt olduğu; retry ve hata durumunda nasıl uzlaştırılacağı belirlenmelidir.

## Ekip ve operasyon modeli nasıl değişir?

AlanKlasik altyapıHeadless commerce
Frontend geliştirmeTema ve platform şablonlarıBağımsız uygulama ve component sistemi
BackendPlatform işlevleri ağırlıklıAPI, BFF ve entegrasyon geliştirme
DevOpsPlatform hosting’iyle sınırlı olabilirFrontend hosting, CDN, secrets ve deployment
QAPlatform ve tema regresyonuFrontend, API, checkout ve entegrasyon sözleşmeleri
İçerik ekibiTema editörüCMS, page builder veya özel yönetim arayüzü
İzlemePlatform loglarıFrontend, API, backend ve üçüncü taraf servisleri

Headless yapıda frontend, API ve commerce backend ayrı sürüm takvimlerine sahip olabilir. Contract test, feature flag, observability, rollback ve incident ownership tanımlanmadığında ekip bağımsızlığı koordinasyon maliyetine dönüşür.

## Headless commerce’ın toplam maliyeti neden yükselebilir?

- Özel frontend geliştirme ve tasarım sistemi.

- Frontend hosting, CDN ve server rendering kaynakları.

- API gateway veya Backend for Frontend katmanı.

- Headless CMS, arama ve kişiselleştirme gibi ek servisler.

- Otomatik test, monitoring ve hata takibi.

- API sürüm yükseltmeleri ve bağımlılık bakımı.

- Checkout, müşteri hesabı ve analitik entegrasyonları.

- Birden fazla vendor için lisans ve destek yönetimi.

Maliyet yalnız ilk geliştirme teklifinden hesaplanmamalıdır. Üç yıllık geliştirme, hosting, lisans, bakım, güvenlik, sürüm güncelleme ve operasyon yükü birlikte değerlendirilmelidir.

## Headless commerce ne zaman mantıklıdır?

- Markaya özel ve tema sınırlarını aşan deneyim stratejik öneme sahipse.

- Web, mobil, kiosk veya birden fazla özel storefront aynı backend’i kullanacaksa.

- Birden fazla ülke, marka veya iş modeli farklı frontend gerektiriyorsa.

- Commerce backend korunurken frontend tamamen yenilenecekse.

- Güçlü frontend, backend, DevOps ve QA ekibi varsa.

- API kapsamı kritik commerce senaryolarını gerçekten destekliyorsa.

- Uzun vadeli operasyon bütçesi ve sahiplik modeli belirlenmişse.

## Headless commerce ne zaman gereksiz olabilir?

- Hazır tema iş ihtiyaçlarının büyük bölümünü karşılıyorsa.

- Tek web mağazası ve standart checkout yeterliyse.

- Teknik ekip küçük ve sürekli bakım kapasitesi sınırlıysa.

- Hız sorunu yalnız kötü görsel, eklenti veya tema optimizasyonundan kaynaklanıyorsa.

- Platformun hazır uygulama ekosistemi kritikse.

- Projenin ana hedefi yalnız tasarımı yenilemekse.

- API limitleri gereken işlevleri desteklemiyorsa.

Bu durumlarda klasik [e-ticaret](/e-ticaret) altyapısını optimize etmek, headless dönüşümden daha düşük riskli ve ekonomik olabilir.

## Headless commerce kararı için değerlendirme matrisi

SoruKlasik yapıya işaret ederHeadless yapıya işaret eder
Kaç storefront var?Tek standart mağazaBirden fazla özel kanal
Tasarım ihtiyacıTema özelleştirmesi yeterliPlatform dışı özel deneyim gerekir
EkipAjans veya küçük teknik ekipSürekli ürün ve platform ekibi
EntegrasyonHazır uygulamalar yeterliÖzel servis ve veri akışları yoğun
Yayın sıklığıSeyrek tema güncellemesiBağımsız ve sık frontend release’i
BütçeDüşük toplam sahip olma maliyeti öncelikliStratejik esneklik için operasyon bütçesi var

## Headless commerce’a geçiş nasıl planlanmalıdır?

- Mevcut storefront işlevlerini ve entegrasyonlarını envanterleyin.

- Headless dönüşümün çözeceği ölçülebilir problemi tanımlayın.

- Commerce platformunun Storefront API kapsamını doğrulayın.

- Checkout, müşteri hesabı, B2B, pazar ve ödeme senaryolarını prototipleyin.

- URL, canonical, structured data ve redirect planını hazırlayın.

- SSR, cache, API timeout ve performans bütçelerini belirleyin.

- Analitik ve dönüşüm event sözleşmesini kurun.

- Frontend–backend contract testleri ve gözlemlemeyi hazırlayın.

- Tek ülke, marka veya sayfa grubuyla kademeli geçiş yapın.

- Eski storefront için geri dönüş ve paralel çalışma planı oluşturun.

Tam yeniden yazım yerine belirli landing page, mobil uygulama veya bölgesel storefront ile başlamak riski azaltabilir. [Özel web yazılım hizmeti](/ozel-web-yazilim-hizmeti) kapsamında mimari karar, yalnız frontend teknolojisine değil transaction bütünlüğü ve operasyon modeline göre verilmelidir.

## Headless commerce kontrol listesi

- Headless dönüşümün çözeceği gerçek iş problemi tanımlı mı?

- Commerce backend gerekli Storefront API yeteneklerini sunuyor mu?

- Sepet ve müşteri oturumu checkout’a güvenilir biçimde taşınıyor mu?

- Ürün, fiyat ve stok verisi doğru cache politikasıyla gösteriliyor mu?

- Ana içerik ve bağlantılar Google tarafından render edilebiliyor mu?

- URL, canonical, sitemap ve redirect planı hazır mı?

- Frontend, API ve backend için ayrı monitoring bulunuyor mu?

- API timeout, retry, rate limit ve fallback davranışları tanımlı mı?

- İçerik ekibinin sayfa yönetim aracı hazır mı?

- Analitik ve dönüşüm event’leri storefront değişiminden etkileniyor mu?

- API sürüm yükseltme ve güvenlik sahipliği belirlenmiş mi?

- Toplam sahip olma maliyeti en az birkaç yıllık hesaplandı mı?

## Sonuç: Headless commerce bir frontend değil işletim modeli kararıdır

Headless commerce, özel storefront’u katalog ve transaction sisteminden ayırarak tasarım, kanal ve yayın esnekliği sağlayabilir. Ancak bu esneklik; API, cache, checkout, müşteri hesabı, SEO, monitoring ve deployment sorumluluklarını mağazanın teknik ekibine taşır.
Klasik e-ticaret altyapısı standart ihtiyaçlarda daha hızlı, ekonomik ve operasyonel olarak güvenli olabilir. Headless yaklaşım ise çok kanallı deneyim, yüksek özelleştirme ve sürekli ürün geliştirme gerçekten stratejikse anlamlıdır. Karar teknoloji modasına göre değil, API kapsamı, ekip kapasitesi ve toplam sahip olma maliyetiyle verilmelidir.

### E-ticaret mimarinizi iş hedeflerinize göre seçin
Mevcut platform, storefront ihtiyaçları, API kapsamı, checkout, entegrasyonlar, SEO ve operasyon maliyeti birlikte incelenerek klasik veya headless mimari için uygulanabilir yol haritası oluşturulabilir.[E-ticaret mimarisi analizi için iletişime geçin](/iletisim)

## Sıkça Sorulan Sorular

### Headless commerce nedir?

Headless commerce, kullanıcıya gösterilen storefront frontend’in ürün, fiyat, sepet, müşteri, checkout ve sipariş işlemlerini yöneten commerce backend’den ayrıldığı ve bu yeteneklere API’lerle bağlandığı e-ticaret mimarisidir.

### Headless commerce ile headless CMS aynı mıdır?

Hayır. Headless CMS editoryal içerik ve medya yönetir. Headless commerce ise katalog, fiyat, stok, sepet, müşteri ve sipariş işlemlerini yönetir. Aynı projede iki sistem birlikte kullanılabilir.

### Headless commerce her zaman daha hızlı mıdır?

Hayır. SSR, cache ve optimize frontend iyi performans sağlayabilir; ancak büyük JavaScript paketleri, çok sayıda API çağrısı, yavaş backend veya kötü cache politikası headless mağazayı klasik temadan daha yavaş yapabilir.

### Headless commerce SEO açısından uygun mudur?

Uygun olabilir. Ürün ve kategori içeriği, HTML bağlantıları, canonical, structured data ve doğru HTTP cevapları Google tarafından erişilebilir olmalıdır. Client-side JavaScript’e tamamen bağımlı yanlış uygulamalar tarama ve indeksleme sorunları oluşturabilir.

### Headless commerce küçük işletmeler için gerekli midir?

Genellikle standart storefront ve checkout ihtiyacı olan küçük işletmeler için zorunlu değildir. Hazır tema ve platform özellikleri yeterliyse klasik altyapı daha düşük geliştirme ve bakım maliyeti sunabilir.

### Headless commerce’a geçişte en büyük risk nedir?

En büyük risk, hazır platformun yönettiği checkout, müşteri hesabı, SEO, analitik, cache ve entegrasyon sorumluluklarının eksik planlanmasıdır. Geçişten önce API kapsamı ve uçtan uca transaction akışları prototiplenmelidir.

> Orijinal Kaynak: https://www.webioo.com.tr/blog/headless-commerce-klasik-e-ticaret-altyapisi-farki