E-ticaret sitesi kurmak: doğru altyapı, güvenli ödeme, tutarlı veri.

Bu rehberi, yeni bir e-ticaret sitesi kurmak ya da mevcut mağazasını başka bir altyapıya taşımak isteyen marka ve işletme ekipleri için yazdık. Anlattıklarımız WooCommerce, Shopify ve ikas’ın resmî belgelerine, Google’ın e-ticaret ve tarama belgelerine, schema.org’a, EMVCo’nun 3-D Secure sayfasına ve PCI Güvenlik Standartları Konseyi’nin (PCI SSC) ödeme sayfası güvenliği yayınlarına dayanıyor. Ürün ve özellik adlarını Eylül 2026 itibarıyla kaynaktan doğruladık; fiyat yazmadık. Kendi saha gözlemlerimizi “Uzman notu” başlığıyla ayrı işaretledik.

Bir e-ticaret sitesi üç katmandan oluşur: altyapı seçimi, ürün sayfasından ödemeye kadar mağaza deneyimi ve ölçümle birlikte bağlanan ürün, stok ve sipariş verisi. Reklamlara giden ürün feed’i (ürün veri akışı) ve kampanyalar e-ticaret pazarlama sayfamızın konusu; bu rehber mağazanın kendisine odaklanır.

E-ticaret sitesi kurmak hangi kararlarla başlar?

İş, altyapı seçiminden önce ne satacağınızı, nasıl teslim edeceğinizi ve mağazanın hangi sistemlerle konuşacağını yazılı hâle getirmekle başlar. İlk görüşmelerde birlikte doldurduğumuz ihtiyaç listesi altı başlıktan oluşur:

• Ürün yapısı: ürün ve varyant sayısı, beden ve renk gibi seçenekler, set ya da kişiselleştirilmiş ürün olup olmadığı.
• Satış kanalları: web mağazasının yanında pazaryerleri, sosyal kanallar, fiziksel mağaza ve toptan satış.
• Ödeme ve teslimat: çalışılacak ödeme kuruluşu ya da banka, taksit ve havale gibi yöntemler, kargo firmaları, iade süreci.
• Entegrasyonlar: ERP (kurumsal kaynak planlama) ya da muhasebe yazılımı, depo ve stok sistemi, e-fatura, CRM (müşteri ilişkileri yönetimi) ve e-posta aracı.
• Dil ve pazar: tek dilde mi satılacağı, yurt dışına satış ve farklı para birimi olup olmadığı.
• Yönetim: ürünü, kampanyayı ve içeriği panelden kimin, ne sıklıkla güncelleyeceği.

Liste yazılmadan yapılan seçimde eksikler sonradan eklentiyle ya da özel kodla kapatılır; bakım yükü her eklemeyle büyür.

Hazır altyapı mı, özel e-ticaret yazılımı mı?

Çoğu mağaza için doğru başlangıç hazır bir altyapıdır; özel e-ticaret yazılımı, hazır altyapının karşılayamadığı bir iş kuralı ya da entegrasyon olduğunda gerekçesiyle seçilir. WooCommerce, WordPress’in üzerinde çalışan bir e-ticaret eklentisidir ve seçtiğiniz sunucuda barınır; Shopify ve ikas gibi barındırılan platformlarda sunucu ve bakım platformdadır, ödeme tarafındaki kapsam ise platforma göre değişir. Shopify, Level 1 PCI DSS (ödeme kartı veri güvenliği standardı) sertifikasının mağazayı, alışveriş sepetini ve web barındırmayı kapsadığını, bu uyumun da bütün mağazalara varsayılan olarak uzandığını yazıyor.¹

Özel geliştirme her gereksinime göre şekillenir, ama ödeme güvenliğinden yedeklemeye kadar bütün sorumluluğu mağazaya taşır. Hazır altyapının sınırını zorlayan bir gereksinimde önce uygulama, eklenti ya da API ile çözüm arıyoruz; örneğin ikas, mağaza verisini GraphQL tabanlı bir yönetim API’siyle dışarıya açıyor.³ “Özel yazılım gerekir” kararını bu kontrolden sonra veriyoruz.

Ölçek ve toplam sahip olma maliyeti nasıl karşılaştırılır?

Altyapılar bugünkü sipariş hacmiyle birlikte büyüme planındaki ürün, sipariş ve entegrasyon yüküyle karşılaştırılır; maliyet de bütün yıllık kalemleriyle hesaplanır. Ölçekte ilk baktığımız yer veri modelidir. WooCommerce, 8.2 sürümüne kadar siparişleri WordPress’in genel içerik tablolarında (_posts ve _postmeta) tutuyordu; Ekim 2023’te yayımlanan 8.2’den beri yeni kurulumlarda Yüksek Performanslı Sipariş Depolama (HPOS) varsayılan olarak açık geliyor.² HPOS sipariş verisini, sipariş adresleri dahil, kendi dizinleri olan dört ayrı tabloda tutar; WooCommerce’e göre bu yapı okuma-yazma işlemlerini ve tablolardaki yoğunluğu azaltır.²

Toplam sahip olma maliyetine altı kalem girer: platform aboneliği ya da barındırma, tema ve tasarım, ücretli eklenti ve uygulamalar, ödeme kuruluşu komisyonları, entegrasyon geliştirme ve yıllık bakım (güncelleme, güvenlik, yedek). Barındırılan platformda sunucu kalemi abonelikte toplanır, ama ücretli uygulama arttıkça aylık gider büyür; WooCommerce ve özel geliştirmede ise bakım emeği süreklidir ve teklifte ayrı yazılmalıdır.

Kategori ve ürün sayfaları nasıl kurulmalı?

Kategori ve ürün sayfaları, alıcının da arama motorunun da bütün ürünlere menüden, kategoriden ve alt kategoriden düz bağlantılarla ulaşabileceği bir ağaç içinde kurulmalıdır. Google bu zinciri öneriyor; kategori sayfaları bir kategorideki bütün ürünlere bağlantı vermiyorsa Googlebot’un yalnız tarayarak bütün ürünleri bulamayabileceğini de yazıyor.⁴ Bağlantılar <a href> etiketiyle kurulmalı; başka HTML öğelerine bağlanan JavaScript olaylarıyla gezinme önerilmiyor.⁴

Google, site yapısını genellikle adres (URL) biçiminden değil, sayfalar arasındaki bağlantılardan çıkarır; genel kural olarak bir sayfaya site içinden ne kadar çok bağlantı varsa, o sayfanın göreli önemi o kadar yüksek sayılır.⁴ Google, çok satan bir ürüne ana sayfadan, blog yazılarından ya da bültenden bağlantı verilmesini de bu yüzden öneriyor.⁴

Ürün sayfasında alıcının karar için sorduğu her şey ilk ekranda ya da hemen altında durur: varyant, stok, fiyat, kargo ücreti, teslim süresi ve iade koşulu. Kategori ve ürün şablonlarında mobil hızı çoğu zaman görseller ve üçüncü taraf betikler belirler; ölçerek hızlandırma yöntemimizi web sitesi hızlandırma sayfamızda anlattık.

Site içi arama ve filtreler taramayı nasıl etkiler?

Filtreler alıcının ürünü daraltarak bulmasını kolaylaştırır, ama her filtre birleşimi yeni bir adres ürettiğinde arama motorları için tükenmeyen bir tarama yüküne dönüşebilir. Google’a göre filtreli gezinme (faceted navigation) en çok adres parametreleriyle uygulanır ve sonsuz adres alanları üretebilir; tarayıcılar bu adreslerin işe yaramadığını anlayana kadar çok sayıda adres tarar, yeni ve yararlı adresler de daha geç keşfedilir.⁵ Site içi arama kutusu da ürün keşfinin yolu değildir: Googlebot tarama sırasında genellikle arama kutusuna sorgu göndermez.⁴ Filtre adreslerini şu kurallarla kuruyoruz:

1. Dizine girmesi gerekmeyen filtreler: robots.txt ile taramaya kapatılır; Google, filtreli adreslerin taranmasına çoğu zaman gerek olmadığını, yalnız ürün sayfalarının ve filtresiz bir liste sayfasının taranmasına izin verilmesini öneriyor.⁵ Filtreler adresin # işaretinden sonraki bölümünde de tutulabilir; Google bu bölümü tarama ve dizinlemede genellikle desteklemez.⁵
2. Dizine girmesi istenen filtreler: parametre ayırıcısı olarak standart “&” kullanılır; filtreler yolun içindeyse sıraları hep aynı kalır ve aynı filtre iki kez yer almaz.⁵
3. Sonuçsuz birleşimler: ürün döndürmeyen filtre birleşimi genel bir hata sayfasına yönlendirilmez; aynı adreste 404 durum koduyla yanıtlanır.⁵
4. Kanonik ve nofollow: Google, rel=”canonical” ve rel=”nofollow” yollarının uzun vadede ilk maddedeki yöntemlerden genellikle daha az etkili olduğunu yazıyor; bunlara tek başına dayanmıyoruz.⁵

Sepetten siparişe ödeme akışı nasıl işler?

Ödeme akışı sepetle başlar, kart doğrulamasıyla sürer ve sipariş kaydıyla biter; her adım alıcıya sürpriz ya da gereksiz engel çıkarmayacak biçimde, en az alanla kurulur. EMVCo da ödeme sürecine eklenen gereksiz sürtünmenin sıklıkla yarım kalan alışverişe yol açtığını yazıyor.⁶

3D Secure, kartla yapılan çevrim içi ödemede alıcının kimliğini kartı veren bankanın doğruladığı protokoldür; mağaza ile banka arasında işlem, ödeme yöntemi ve cihaz bilgisini taşır.⁶ Banka bu veriyle riski değerlendirir; birçok işlemde alıcı yalnız “Satın al” düğmesine basar ve ödeme onaylanır.⁶ Riski yüksek görülen işlemde banka ek doğrulama isteyebilir: tek kullanımlık şifre, bilgiye dayalı soru ya da biyometrik doğrulama gibi.⁶ Protokol hem tarayıcıda hem mobil uygulamada çalışır; EMVCo en uygun işlevsellik için 2.2 ya da daha yeni bir sürümün değerlendirilmesini öneriyor.⁶

Shopify, akışı şöyle tarif ediyor: alıcı doğrulama için kartı veren bankanın alanına yönlendirilir, ardından ödemeyi tamamlamak için mağazanın alanına geri döner.⁷ 3D Secure ile doğrulanan ödemede sahte işlemden doğan ters ibraz (chargeback) sorumluluğu mağazadan kartı veren bankaya geçer.⁷ Bu koruma sınırsız değildir: Shopify, kartı veren kuruluşların çok fazla ters ibraz oluştuğunda sorumluluk devrini kaldıran politikaları olduğunu yazıyor.⁷ Bu sınırı kurulumda çalışılan ödeme kuruluşuyla teyit ediyoruz.

Shopify Payments, 3D Secure’u yalnız kartı veren banka işlemi onaylamak için istediğinde kullanır.⁷ Bizim kurduğumuz kısım akışın mağaza tarafıdır: doğrulamanın telefonda kesintisiz açılması, bankadan dönüşte siparişin bir kez ve doğru durumla kaydedilmesi, başarısız doğrulamada sepetin korunması.

Ödeme sayfasının güvenliği için PCI DSS ne ister?

Kart verisi ödeme kuruluşunun sitenize gömülü formunda girilse bile PCI DSS, o sayfanın güvenliğini mağazadan ister: v4.0.1’deki SAQ A öz değerlendirme anketini kullanabilmenin ölçütlerinden biri, mağazanın sitesinin betik saldırılarına açık olmadığını teyit etmiş olmasıdır.⁹ PCI SSC, alıcının tarayıcısında çalışan betiklerin kart verisi çalmak isteyen saldırganların önemli bir hedefi hâline geldiğini ve “e-skimming” denen bu saldırıların belirgin biçimde arttığını yazıyor.⁸ Standardın 6.4.3 ve 11.6.1 şartları, ödeme sayfasındaki betiklerin yetkilendirilmesini, bütünlüğünün denetlenmesini ve değişikliğe karşı izlenmesini, güvenliği etkileyen HTTP başlıklarının da yönetilmesini hedefler.⁸ PCI SSC’ye göre v4.0.1’in yeni şartları 1 Nisan 2025’te yürürlüğe girdi.⁹ Ödeme formunun sitede nasıl yer aldığı, sorumluluğun sınırını belirler:

PCI SSC, SAQ A’nın bir mağazaya uygun olup olmadığının üye iş yeri anlaşmasını yapan banka (acquirer) ya da ilgili kart markalarıyla teyit edilmesini öneriyor;⁹ bu teyidi kurulumda birlikte alıyoruz.

Ürün, stok ve sipariş verisi hangi sistemlerle konuşur?

Bir e-ticaret sitesinde ürün, stok ve sipariş verisinin tek bir doğru kaynağı olmalı; mağaza, ERP, Merchant Center ve analitik bu kaynaktan aynı kimliklerle beslenmelidir. Altyapıların API’leri bu bağlantının zeminidir. ikas’ın geliştirici belgesinde yönetim API’sinin v1 sürümü için tanımlanan izinler ürün ve varyantları, bütün satış kanallarındaki siparişleri, müşterileri, stok konumlarını ve stok seviyelerini kapsıyor; ikas yeni API kullanıcılarına v2 sürümünü öneriyor.³ WooCommerce tarafında HPOS, okuma-yazma kilitlerinin uygulanmasını ve eşzamanlı işlemlerde çakışmaların (race condition) önlenmesini kolaylaştırır;² ERP’nin sık sipariş okuyup yazdığı mağazalarda bu farkı önemsiyoruz.

Google’ın Content API for Shopping’i 18 Ağustos 2026’da kapandı, 1 Eylül 2026’dan itibaren bu API’ye giden istekler kademeli olarak hata almaya başladı ve yerini Merchant API aldı.¹⁰ Ürünleri Shopify’daki Google & YouTube uygulaması gibi bir iş ortağı uygulamasıyla gönderen mağazaların bir şey yapması gerekmiyor; taşımayı sağlayıcı üstleniyor.¹⁰ Veriyi kendi yazılımıyla gönderen mağazaların entegrasyonu ise Merchant API’ye taşınmalıdır; bu API tek bir ürünü bütün zorunlu alanları göndermeden güncelleyebiliyor, ek süre gerekenler de uzatılmış erişim için başvurabiliyor.¹⁰

Ölçüm ve yapısal veri yayından önce nasıl doğrulanır?

Ölçüm ve yapısal veri, yayından önce gerçek bir test siparişi mağaza kaydıyla yan yana konarak doğrulanır. GA4’te satın alma ve iade olaylarında sipariş kimliği (transaction_id) zorunludur; değer (value) gönderilen olaylarda para birimi (currency) de olay düzeyinde ayarlanır.¹¹ Test siparişinde GA4’teki sipariş kimliği, tutar ve ürün kodları mağaza kaydıyla birebir aynı olmalıdır; olayların tam listesi e-ticaret pazarlama sayfamızda.

Ürün sayfasındaki yapısal veri de aynı kaynaktan üretilir. Product türü schema.org’da satışa sunulan her türlü ürün ya da hizmet olarak tanımlanır; teklif (offers), marka, SKU ve GTIN gibi özellikleri vardır.¹² GTIN değeri 8, 12, 13 ya da 14 haneden oluşan ve geçerli GS1 kontrol hanesi taşıyan bir sayı (ya da buna dayalı bir GS1 Digital Link adresi) olmalıdır; SKU ise satıcıya özgü stok kodudur.¹² Beden ya da renk varyantları isVariantOf özelliğiyle bir ürün grubuna (ProductGroup) bağlanabilir.¹²

E-ticaret sitesi yaptırmak: yayına kadar ve ilk 30 gün

Doğru sıra şudur: kapsam yazılı hâle gelir, altyapı bu kapsamla seçilir, ödeme ve entegrasyon test edilerek yayına alınır, ilk 30 gün ölçümle izlenir.

1. Keşif: ihtiyaç listesi, mevcut sitenin adres envanteri, ödeme kuruluşu ve entegrasyon kararları.
2. Altyapı ve tasarım: altyapı karşılaştırması, sayfa ağacı ve mağaza ekranlarının tasarımı.
3. Geliştirme ve entegrasyon: tema, ödeme ve 3D Secure akışı, ERP ve Merchant Center bağlantısı, GA4 olayları, yapısal veri.
4. Test ve yayın: üç test siparişi, yönlendirmeler, telefonda uçtan uca kontrol.
5. İlk 30 gün: sipariş ve ödeme hataları, tarama ve 404 raporları, GA4 ile sipariş kaydı arasındaki fark haftalık okunur.

Alan adı, barındırma ya da platform aboneliği, ödeme sözleşmesi, Merchant Center, Analytics ve kod deposu firmanızın adına açılır; kurulum, entegrasyon ve yayın sonrası işletmeyi markention ekibi yürütür. Siteyi, ürün, kampanya ve içerik değişikliklerinin kod gerektirmeden panelden yapılabileceği biçimde kuruyoruz.

Görüşmelerde şu üç sorunun yanıtı karşılaştırmayı kolaylaştırır: altyapı hangi ölçütle öneriliyor, ödeme sayfasındaki betikler nasıl denetleniyor, stok ve siparişin tek doğru kaynağı hangi sistem olacak. Mağazanızın ihtiyaç listesini birlikte çıkarmak isterseniz aşağıdan size uygun bir görüşme günü seçebilirsiniz.