Web Siteniz Neden Satış Yapmıyor? 2026’da KOBİ ve Kurumlar İçin Yapay Zekâ ve ERP Entegreli Yeni Nesil Web Uygulaması (Web App) Rehberi

Pazartesi sabahı satış ekibinin ekranında üç ayrı sorun var. Bir müşteri stokta görüp satın aldığı ürünün depoda bulunmadığını öğreniyor. Başka biri cuma günü bıraktığı teklif talebine hâlâ cevap bekliyor. Üçüncü müşteri, arama kutusunda bulamadığı ürünü bir rakipten almış. Web sitesi açık. Ana sayfa yeni. Reklamlar çalışıyor. Fakat iş akışı çalışmıyor.

Yıllarca şirket sitelerini şirketi anlatan bir broşür gibi tasarladık. Broşürün hâlâ bir işi var: kimsiniz, ne yapıyorsunuz, neden güvenilirsiniz? Sorun, müşterinin bir sonraki adımında başlıyor. Kendi fiyatını görmek, uygun ürünü bulmak, teslimat tarihini öğrenmek veya başvurusunun durumunu izlemek isteyen kişi yeni bir paragraf okumaya gelmiyor. İşini tamamlamak istiyor.

2026’da web sitesi ile web uygulaması arasındaki asıl fark animasyon veya kullanılan framework değil, bu görevin ne kadarının güvenilir biçimde tamamlanabildiği. Bu rehberde iş güvenliği ekipmanı satan temsili bir işletmeyi izleyeceğiz. Aynı katalogdan bireysel müşteriye satış yapıyor, kurumsal müşteriye sözleşmeli fiyat ve teklif sunuyor; stok ERP/WMS’te, müşteri takibi CRM’de tutuluyor. Mimariyi bu akış üzerinden açacağız; her bölümün sonunda işletme açısından karşılığını da vereceğiz.

TankDev’de web tabanlı sistemleri, uygulamalı yapay zekâyı ve sistem entegrasyonunu birlikte tasarlıyoruz. Bu, her projeye aynı teknoloji listesini koyduğumuz anlamına gelmez. Önce hangi işin kaybolduğunu, hangi verinin doğru kabul edildiğini ve otomasyonun nerede durması gerektiğini belirliyoruz. Aşağıdaki senaryo, sayılar ve kodlar yaklaşımı açıklamak içindir; yayımlanmış bir müşteri performans sonucu değildir.

Önce teşhis: trafik var, satış nerede kayboluyor?

“Web sitem satış yapmıyor” tek bir hata değildir. Yanlış niyetli trafik, belirsiz teklif, güvensiz ürün bilgisi, yavaş etkileşim, çalışmayan ödeme veya satış ekibine ulaşmayan talep aynı sonuca benzer görünebilir. Yeni tasarıma başlamadan önce ürün görüntüleme → arama → sepete ekleme/teklif → kalıcı kabul → ödeme/CRM kabulü → gerçekleşen satış zincirini ölçeriz. B2B teklifini B2C kart ödemesiyle aynı dönüşüm penceresinde değerlendirmeyiz.

Illustrative monthly funnel, not a measured case study:
10,000 eligible sessions -> 500 cart/quote starts -> 200 durable submissions
120 completed sales, observed after the agreed attribution window

Submission rate = 200 / 10,000 = 2%
Realized sales rate = 120 / 10,000 = 1.2%

If a controlled change raises submissions to 250 AND the 60% close rate holds:
250 * 0.60 = 150 sales => 30 additional sales
Incremental contribution = 30 * contribution_margin_per_sale
This is a scenario, not a forecast or a framework performance claim.

İstemcide butona basılması, siparişin veritabanında kabul edilmesi ve paranın tahsil edilmesi ayrı olaylardır. event_id ve order_id/lead_id ile mükerrer ölçümü ayırırız; tarayıcı ve sunucu olaylarını aynı olayın iki satışı gibi saymayız. Consent tercihleri, reklam engelleyiciler ve çapraz cihaz yolculukları ölçümde eksik bırakabilir. Bu yüzden finansal sonuç ve operasyonel kayıtlar, yalnızca analytics panelindeki dönüşüm sayısıyla eşitlenmez.

İşletme açısından: Sorununuzu yeni bir ana sayfa çözecek mi, yoksa gelen talebi zamanında yanıtlamak mı gerekiyor? Önce bunu görünür kılmak gerekir. Aksi halde reklam bütçesini artırmak, daha fazla müşteriyi aynı bozuk akışa göndermekten öteye geçmeyebilir.

1. Müşteriler siteden neden çıkar? Performans, belirsizlik ve tamamlanamayan görevler

Teknik tasarım: Core Web Vitals ile iş metriğini birlikte okumak

Bir ürün sayfası yüklenirken görüntünün geç gelmesi, filtreye basınca ekranın tepki vermemesi veya ödeme butonunun yer değiştirmesi farklı problemler yaratır. LCP ana içeriğin görünmesini, INP etkileşim yanıtını, CLS görsel kararlılığı izler. Web Vitals rehberindeki iyi deneyim eşikleri LCP ≤ 2,5 saniye, INP ≤ 200 ms ve CLS ≤ 0,1’dir; mobil ve masaüstü ayrı, gerçek kullanıcı dağılımının 75. yüzdeliğinde değerlendirilir.

Tek bir Lighthouse koşusundaki 100 puan, müşterilerin aynı deneyimi aldığını kanıtlamaz. Laboratuvar testi regresyon bulmaya; gerçek kullanıcı ölçümü cihaz, ağ ve sayfa türü dağılımını görmeye yarar. Ürün detayını, arama sonucunu, bayi sepetini ve ödeme akışını ayrı izleriz. Backend için p95/p99 latency, hata oranı ve dependency süreleri gerekir. Bir sayfanın LCP’si iyi olabilirken stok sorgusu sık sık timeout verebilir.

“100 ms hızlandık, satış yüzde X arttı” sonucunu kendi ölçümümüz olmadan yazmayız. Trafik kaynağı, kampanya, stok durumu, fiyat ve cihaz karışımı dönüşümü değiştirir. Mümkünse kontrollü deney, değilse aynı segmentte tarih aralığı ve değişiklik kaydı kullanırız. Hızın değeri yalnızca ilk açılışta değildir: arama, sepet ve teklif boyunca küçük beklemelerin tekrarlanması da görev tamamlama oranını etkileyebilir.

Neden Next.js? SSR, statik üretim ve cache sınırları

TankDev’in özel web uygulamalarında Next.js’i tercih edebilmesinin nedeni, herkese her istekte SSR yapmak değildir. Kamuya açık ürün açıklamaları ve rehberler önceden üretilebilir veya kontrollü cache kullanabilir. Server Components ile veri hazırlamayı sunucuda tutup tarayıcıya giden JavaScript’i sınırlarız; filtre ve sepet gibi etkileşimler istemci bileşeni olur. Bu ayrım Next.js’in bileşen modelinde açıklanır. Gerçek hız, veri erişimi ve asset bütçesinin de doğru kurulmasına bağlıdır.

Kişiye özel bayi fiyatını ortak CDN cache’ine koymak hız optimizasyonu değil veri sızıntısıdır. Cache key; dil, para birimi ve kamuya açık içerik sürümüyle tanımlanır. Kullanıcı/tenant bağlamındaki teklif ve fiyat yanıtları için private/no-store politikası açıkça uygulanır. Stok kartındaki değer kısa süreli read model olabilir; sipariş anındaki rezervasyon ise yetkili sistemde yeniden doğrulanır. Cache invalidation olayı kaçarsa TTL ve periyodik reconciliation devreye girer.

Illustrative route/data policy, independent of framework defaults:
/products/{slug}           Public editorial shell; versioned cache
/api/catalog/search       Public fields only; query/locale-aware cache
/api/account/prices       Authenticated, tenant-scoped; private, no-store
/api/cart                 Authenticated or scoped session; private, no-store
/api/orders               POST; server-side price/stock checks + idempotency
/api/orders/{id}          Object authorization on every read

Public HTML / JSON-LD must never contain another account's negotiated price.
Availability shown during browsing is not an inventory reservation.

WordPress’in doğası gereği yavaş, Next.js’in kendiliğinden hızlı olduğunu söylemek doğru değil. WordPress de sunucuda HTML üretebilir; iyi hosting, ölçülü eklenti kullanımı ve cache ile başarılı olabilir. WordPress’in optimizasyon belgeleri de bu işletim konularını ele alır. Biz ERP bağlantısı, özel yetki modeli ve karmaşık iş akışı gereken projelerde eklenti zinciri yerine bileşenlerini daha doğrudan yönettiğimiz özel yapıyı tercih ediyoruz. Bu kontrolün bakım ve geliştirme sorumluluğunu da üstlenmek gerekir.

İşletme açısından: hız, müşterinin işi yarıda bırakmamasıdır

Müşteriniz teknoloji adını görmez. Ürünü açabildiğini, doğru fiyatı gördüğünü ve “gönder” dediğinde ne olduğunu anlayabildiğini görür. Yatırım kararı da buna dayanmalı: hangi ekranda zaman kaybediliyor, kaç talep tamamlanmıyor, düzeltmenin katkısı nasıl ölçülecek? Sadece tanıtım isteyen küçük bir siteye karmaşık portal kurmak ekonomik olmayabilir; bayi siparişi ve ERP akışı olan bir işletmeye yalnızca tema değiştirmek de sorunu çözmez.

2. Akıllı arama ve kişiselleştirme: müşterinin niyetini ürüne bağlamak

Teknik tasarım: exact match, filtre ve semantic retrieval birlikte

Örneğimizde bir müşteri “Ankara’da kışın dış sahada çalışmak için su geçirmeyen bot arıyorum” yazıyor. Başka bir müşteri yalnızca ürün kodunu biliyor. İkisine aynı vektör aramasını uygulamak iyi arama tasarımı değildir. Kod, barkod ve tam ürün adı deterministic eşleşir; kategori, numara, sertifika ve fiyat gibi alanlar yapılandırılmış filtrelere dönüşür. Doğal dilde kullanım amacı semantic retrieval için ek sinyaldir.

Arama hattı; sorgu normalizasyonu → exact/lexical adaylar + vektör adayları → yetki ve ürün uygunluğu filtreleri → birleştirme/reranking → güncel fiyat/stok ekleme şeklinde kurulabilir. RAG, seçilmiş ve izinli kaynaklardan gelen adayları modele bağlayıp açıklama üretir. LLM’nin ürün kimliği, sertifika veya teslimat tarihi uydurmasına izin verilmez. “Bu koşul için doğrulanmış ürün bulunamadı” sonucu, yanlış güven veren tavsiyeden daha değerlidir.

Vektör indeksine fiyat ve stok yazıp bunları güncel gerçek kabul etmeyiz. İndeksin işi ürünün anlamını bulmaktır; ticari gerçek ürün/ERP servisinden gelir. Ürün açıklaması, teknik özellikler, dil ve kaynak sürümü embedding kaydıyla tutulur. Model değiştiğinde embedding sürümü ayrılır; indeks yeniden kurulabilir. Küçük ve orta ölçekli katalogda mevcut PostgreSQL’e pgvector eklemek yeterli olabilir. pgvector belgeleri exact/approximate arama ve filtreleme seçeneklerini açıklar; seçimi kendi katalog dağılımında recall ve latency ile sınarız.

{
  "query": "waterproof winter work boots, size 42",
  "constraints": {
    "category": "work-boots",
    "size": "42",
    "waterproof_claim": "verified"
  },
  "candidate_ids": ["SKU-42-A", "SKU-42-B"],
  "evidence": [
    {"product_id": "SKU-42-A", "source_version": "spec-v18", "field": "waterproof"}
  ],
  "commercial_data_source": "authoritative-product-service",
  "policy": "explain_only_returned_candidates; no_purchase_authority"
}

Yetki filtresi yalnızca yanıtta ürün adını gizlemekten ibaret değildir. Bayiye kapalı katalog, özel fiyat listesi ve teknik doküman retrieval aşamasında yetkili kapsamda kalır; son kontrolde de nesne yetkisi doğrulanır. Kullanıcının sorusu tenant kimliğini belirleyemez. Ürün metni içinde bulunan talimatlar araç yetkisi doğurmaz. Kişiselleştirme; açıkça alınan kullanım tercihi ve izinli hesap bilgisiyle yapılır, tüm müşteri verisini modele göndermekle değil.

Kalite için temsilî ve etiketli bir sorgu seti gerekir: ürün kodu, yazım hatası, çok anlamlı ifade, ürünsüz sorgu ve güvenlik açısından kritik özellikler ayrı değerlendirilir. Recall@k adayın bulunmasını; uygunluk doğruluğu cevabın gereksinimi karşılamasını; unsupported-claim oranı kaynak dışı iddiayı ölçer. p95 yanıt süresi, arama başına maliyet, sıfır sonuç oranı ve aramadan sepete/teklife geçiş birlikte izlenir. Model erişilemezse lexical arama çalışmaya devam eder.

İşletme açısından: her ziyaretçiyi sohbet etmeye zorlamayın

Ürün kodunu bilen satın almacı hızlı sipariş ekranı ister; hangi ürünü seçeceğini bilmeyen müşteri açıklama ister. İkisine farklı yol sunmak satış desteğidir. AI’ın değeri sayfanın köşesinde konuşan bir kutu olması değil, doğru ürünü bulma süresini ve tekrarlanan soru yükünü azaltmasıdır. Güvenlik ekipmanında doğrulanmamış özelliği varmış gibi sunmak ise satış kazanımı değil risk üretir.

3. ERP, stok, WMS ve CRM: satışın arka plandaki doğruluk sözleşmesi

Teknik tasarım: önce her verinin ve kararın sahibini belirlemek

Web uygulaması yalnızca ön yüzden ibaret değildir; frontend, API, iş kuralları, kalıcı kayıt ve entegrasyon sınırlarından oluşur. Tarayıcıya stok sayısını çizmek kolaydır. İki müşteri son ürünü aynı anda aldığında hangisinin hakkı olduğunu belirlemek asıl iştir. ERP, WMS ve uygulama veritabanı arasında aynı “stok” kelimesi de farklı şeyler ifade edebilir: fiziksel adet, kullanılabilir adet, rezerve adet, transferdeki miktar ve güvenlik stoğu.

Bir vitrindeki stok bilgisi birkaç saniye gecikebilir; sipariş onayı aynı gevşeklikle verilemez. Yetkili stok servisi atomik rezervasyon sunuyorsa o API kullanılır. Böyle bir sözleşme yoksa site “kesin sipariş” yerine teyit bekleyen talep kabul edebilir veya web kanalına ayrılmış stok kotası yönetilebilir. Sadece web DB’sindeki sayacı kilitlemek, fiziksel mağazada veya ERP’de aynı ürün satılıyorsa tüm kanallarda overselling’i önlemez.

-- PostgreSQL illustration: valid ONLY if this inventory ledger is the
-- reservation authority for the relevant channel/allocation.
BEGIN;
INSERT INTO orders(id, tenant_id, idempotency_key, request_hash, state)
VALUES (:order_id, :tenant, :key, :hash, 'PENDING');
-- UNIQUE(tenant_id, idempotency_key). On conflict: ROLLBACK,
-- load the original order, compare its request hash, return it or 409.
-- Resolve duplicate admission BEFORE attempting another reservation.

UPDATE inventory_allocations
SET reserved = reserved + :qty, version = version + 1
WHERE sku = :sku AND channel = 'web'
  AND :qty > 0 AND on_hand - reserved >= :qty
RETURNING sku, version;
-- Require exactly one updated row; otherwise ROLLBACK / unavailable.
UPDATE orders SET state='RESERVED' WHERE id=:order_id;

INSERT INTO outbox(event_id, aggregate_id, event_type, payload)
VALUES (:event_id, :order_id, 'order.accepted.v1', :payload);
COMMIT;
-- External ERP/payment calls happen after this transaction.

Fiyat tarayıcıdan gelen total alanından alınmaz. Sunucu; hesap, para birimi, miktar, vergi, kampanya ve geçerli fiyat sürümünü yeniden değerlendirir. Sonuç değiştiyse müşteriye yeni toplam gösterilir. Ödeme yetkilendirme/tahsilat akışıyla stok rezervasyonu bir distributed transaction değildir. Ödeme başarısızsa rezervasyonu bırakma; ERP reddederse siparişi incelemeye alma veya iş kuralına göre iptal/iade başlatma adımları ayrıca tanımlanır. PSP cevabı kaybolduğunda körlemesine ikinci tahsilat yapılmaz; sağlayıcının idempotency ve durum sorgusu sözleşmesi kullanılır.

Outbox, idempotency ve reconciliation neyi çözer?

Sipariş DB’ye yazıldı, ERP çağrısı timeout verdi. Bu anda “başarısız oldu” demek yeterli değildir: ERP kaydı oluşturmuş, cevap ağda kaybolmuş olabilir. order_id ile external_order_id eşlemesi, idempotency key, request hash ve attempt kaydı tutulur. Outbox olayı siparişle aynı transaction’da yazılarak DB kaydı ile sonraki aktarım arasındaki boşluk kapatılır. Bu dual-write probleminin kapsamı transactional outbox açıklamasında da anlatılır.

Outbox kaydı ERP’yi kesintisiz yapmaz; aktarım niyetinin kaybolmamasını ve yeniden denenebilmesini sağlar. Relay aynı olayı tekrar gönderebilir. Karşı tarafta inbox/dedup veya sorgulanabilir dış işlem kimliği gerekir. Retry; exponential backoff, jitter, sınırlı attempt ve iş deadline’ıyla çalışır. Desteklenmeyen ürün kodu gibi kalıcı hata tekrar edilerek düzelmez. DLQ/inceleme kaydı, alarm ve sorumlu kişi gerekir.

Reconciliation, olay akışının sigortasıdır. Belirli yaştan eski ERP_PENDING siparişler dış kimlikle sorgulanır; aktarım kayıtları ve ERP kayıtları karşılaştırılır. Webhook kaçmışsa durum tamamlanır; tutarsızlık bulunursa inceleme açılır. Kullanıcıya “ERP teyidi bekleniyor” demek, belirsiz bir sonucu tamamlandı diye boyamaktan daha doğrudur. Yetkili stok/ERP kapalıyken neyin satılabileceği önceden belirlenir: kamuya açık katalog açık kalabilir, kesin stok taahhüdü durdurulabilir.

CRM: formun gönderilmesi, satış talebinin takip edilmesi değildir

Teklif formunda önce validasyon, bot/rate-limit kontrolü ve kalıcı lead kaydı yapılır; lead_id müşteriye verilir. CRM ile e-posta bildirimi ayrı outbox tüketicileri olabilir. E-posta gitmedi diye talep kaybolmaz. Lead kaydının atanan ekibi, next_action_at alanı, CRM kabul durumu ve yanıt süresi izlenir. Aynı formun mobil bağlantı kopunca tekrar gönderilmesi idempotency ile tek talebe bağlanır. Benzer e-posta adresleri ise otomatik birleştirme için tek başına yeterli değildir.

Bu protokolü API ve sistem entegrasyonu rehberimizde daha ayrıntılı açıyoruz. Uzun AI işleri de varsa, asenkron LLM worker mimarisi aynı kabul, sahiplik ve tekrar sınırlarının model tarafındaki karşılığını anlatır.

İşletme açısından: müşterinin gördüğü durum ile deponun yaptığı iş uyuşmalı

“Siparişiniz alındı” ile “ödemeniz tahsil edildi” ve “siparişiniz sevke hazır” aynı cümle değildir. Müşteri hangi aşamada olduğunu görmeli; ekip de hangi kayıt için müdahale gerektiğini bilmelidir. Entegrasyona yapılan yatırımın getirisi burada ölçülür: çift veri girişinin süresi, stok uyuşmazlığı, unutulan teklif, mükerrer işlem ve müşteri durum sorma çağrıları. Her kesintiyi yok etmek yerine kesintide işin kaybolmamasını ve ekibin ne yapacağını tasarlarız.

4. Headless CMS: tek yayın düzeni, farklı kanallar ve doğru veri sahipliği

Teknik tasarım: CMS, PIM ve ERP’nin görevlerini ayırmak

Headless CMS, içerik yönetimini belirli bir sayfa temasından ayırır. Editör ürün kullanım rehberini, hizmet açıklamasını veya kampanya içeriğini yönetir; web ve mobil istemciler versioned API’den okur. Klasik CMS’teki “sayfanın içine ürün bilgisini yazalım” yaklaşımından, ilişkilendirilebilir içerik modellerine geçilir. Örneğin bir rehber ürün kodunu metin olarak kopyalamak yerine product_id referansları tutar.

Fiyatı, stok adedini ve bayi indirimini CMS’te düzenlemek veri sahipliğini yeniden bozar. CMS açıklamayı; PIM varsa zengin ürün bilgisini; ERP/ticari servis fiyat ve işlem verisini yönetir. “Tek merkez” tüm veriyi tek veritabanına yığmak değildir. Kullanıcıya tek arayüz sunarken her alanı yetkili kaynaktan birleştirmek ve aynı veriyi üç yerde elle güncellememektir.

{
  "content_id": "guide-winter-workwear",
  "schema_version": 3,
  "locale": "tr",
  "status": "published",
  "revision": 18,
  "product_refs": ["SKU-42-A"],
  "seo": {"canonical_path": "/tr/rehber/kislik-is-ekipmani"},
  "commercial_fields": "resolved_by_product_and_pricing_services"
}

Yayın akışında taslak, editör incelemesi, onay, planlama ve geri alma tanımlanır. Draft preview erişimi doğrulanır; taslaklar public cache’e ve sitemap’e sızmaz. Webhook imzası ve event id kontrol edilerek yayın sonrası ilgili cache etiketleri ve arama indeksleri güncellenir. İçerik şeması değiştiğinde eski mobil istemcilerin okuyabildiği sürüm korunur. Çok dillilikte içerik çevirisi, canonical ve hreflang eşleşmesi aynı yayın kontrolüne bağlanır.

Headless CMS ile micro-frontends aynı karar değildir. Micro-frontends, ayrı ekiplerin belirli arayüz alanlarını bağımsız geliştirme/yayınlama ihtiyacında düşünülebilir. Bunun karşılığı runtime bağımlılıkları, ortak tasarım sistemi, oturum, erişilebilirlik, sürüm uyumu ve gözlemlenebilirlik yüküdür. Tek ürün ekibi ve sınırlı ekran sayısında modüler bir Next.js uygulaması genellikle daha az işletim maliyetiyle aynı ihtiyacı karşılayabilir. Bu senaryoda micro-frontends başlangıç şartı değildir.

İşletme açısından: aynı açıklamayı üç yerde düzeltmemek

İçerik ekibi teknik ekibe her metin değişikliğinde görev açmamalı. Fakat yanlış fiyatın her kanala aynı anda yayılması da başarı sayılmaz. İyi bir yönetim paneli, doğru kişiye doğru alanı açar: editör içeriği, ticari ekip fiyat politikasını, depo stok hareketini yönetir. Yayınlayan kişinin ve değişen sürümün belli olması, “kim neyi değiştirdi?” sorusunu tahminden çıkarır.

5. Yapay zekâ dostu web uygulaması: SEO, GEO ve entity tutarlılığı

Teknik tasarım: keşfedilebilir içerik ile özel işlemleri ayırmak

Sitedeki AI asistanı ile sitenin dış arama sistemlerinde görünmesi farklı projelerdir. İlki kendi katalog ve servislerinize bağlanan bir ürün özelliğidir. İkincisi kamuya açık bilginizin bulunması, anlaşılması ve uygun bir soruda kaynak olarak seçilebilmesidir. İyi chatbot yapmak Google’da indekslenmeyi sağlamaz; schema eklemek de ürün arama kalitesini düzeltmez.

Kamuya açık ürün, kategori ve hizmet sayfaları kalıcı URL’lerle erişilebilmeli; önemli içerik yalnızca oturum açtıktan veya chat başlattıktan sonra görünmemelidir. HTML, title, H1, açıklama, internal link ve gerçek HTTP durumları uyumlu olmalıdır. Kaldırılan ürünü sonsuza kadar 200 boş sayfa olarak tutmak; her filtre kombinasyonunu ayrı indekslenebilir URL’ye açmak veya çevirileri yanlış canonical’a bağlamak modern framework ile de mümkündür. Teknik SEO açık bir yayın politikası ister.

Entity, şirketin veya ürünün ayırt edilebilir kimliğidir. Aynı şirketin Türkçe ve İngilizce sayfalarında ticari adı, domain’i, iletişimi ve doğrulanabilir profilleri tutarlı olmalıdır. Organization için sabit @id, ürün için kararlı SKU/ürün kimliği ve uygun olduğunda gerçek GTIN/marka ilişkisi kullanılır. Var olmayan sertifika, sahte değerlendirme veya hayali şube eklenmez. Fiziksel işletmenin web bilgisi ile işletme profillerindeki iletişim/konum verisini tutarlı tutmak da aynı veri kalitesi işinin parçasıdır.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://supplier.example/#organization",
      "name": "Example Safety Supplier",
      "url": "https://supplier.example/"
    },
    {
      "@type": "Product",
      "@id": "https://supplier.example/products/boot-a#product",
      "name": "Work Boot A",
      "sku": "SKU-42-A",
      "description": "Public description matching the visible page"
    }
  ]
}

Bu JSON-LD kimlik ilişkisini göstermek için küçültülmüş bir örnektir; merchant listing uygunluğu için tam şema değildir. Gerçek satın alınabilir sayfada Offer, fiyat, para birimi ve availability gibi alanlar ilgili gereksinimlere göre üretilir ve görünen içerikle eşleşir. Google’ın merchant listing belgesi kullanılmalıdır. Bayiye özel fiyat public structured data’ya taşınmaz; şemaya eklenecek kamuya açık bir teklif yoksa uydurulmaz.

GEO açısından açıklamalar, modelin alıntılayabileceği somut bilgiyi taşımalıdır: hangi müşteri için hangi problem çözülüyor, kapsam ne, ön koşullar ne, sonuç hangi kanıtla destekleniyor? Bunu anahtar kelime tekrarıyla değil açık hizmet sayfaları, karşılaştırmalar, teknik açıklamalar ve doğrulanabilir vaka kayıtlarıyla kurarız. Her sayfaya aynı uzun SSS’yi kopyalamak yerine sayfanın karar sorularını cevaplarız.

Google’ın AI özellikleri rehberi, AI Overviews ve AI Mode için özel bir AI şeması veya ek teknik dosya şartı koymaz; temel SEO ve uygun indekslenebilirlik geçerlidir. Bu Google’a ait kapsamdır, tüm yapay zekâ sistemlerinin aynı şekilde çalıştığı anlamına gelmez. Teknik uygunluk görünürlük garantisi de değildir. Makalemizdeki SSS’nin amacı okuyucuya cevap vermektir; arama sonucunda özel bir görünüm taahhüdü değildir.

Ölçümde marka ve markasız sorgular, ülke/dil, cihaz ve tarih kaydedilir. Google gösterim/tıklaması, AI yanıtında marka anılması, kaynak URL’si ve siteye gelen yönlendirme ayrı tutulur. Sıfır referral, hiç anılmadığınızı kanıtlamaz; tek başarılı prompt da kalıcı görünürlük sayılmaz. Sabit sorgu setinde tekrarlı gözlem, sayfa sürümü ve ticari dönüşüm bağlantısı gerekir. Bu ayrımı ChatGPT’de görünürlük rehberimiz ve teknik SEO/GEO yazımız ayrıntılandırır.

İşletme açısından: arama sistemine şirketinizi doğru anlatmak

“Bizi öner” demek yerine neyi, kimin için ve hangi koşullarda yaptığınızı açık yazmanız gerekir. Bir satın almacı da bir arama sistemi de aynı temel sorulara cevap arar. TankDev’in GEO hizmeti bu bilgiyi içerik, entity yapısı, teknik erişim ve ölçümle birlikte ele alır. Kendi sitemizdeki SEO/GEO vaka kaydı ise belirli teknik kontrollerin kanıtlarını gösterir; bunları satış artışı veya garantili AI önerisiyle eşitlemeyiz.

6. Güvenlik, erişilebilirlik ve operasyon: uygulamanın görünmeyen teslim kapsamı

Bayi ekranındaki bir butonu gizlemek yetkilendirme değildir. API; tenant, rol ve kayıt sahipliği kontrolünü her işlemde uygular. Yönetim hesaplarında güçlü oturum politikası, ayrı servis kimlikleri, en az ayrıcalık, secret rotation ve denetim izi tasarlanır. Dosya yüklemeleri boyut/tür/zararlı içerik kontrollerinden geçer; public dizine gelişigüzel bırakılmaz. Loglarda parola, token, kart bilgisi veya ham müşteri evrakı tutulmaz. Ödeme için desteklenen sağlayıcı akışı kullanılır; hassas kart verisini gereksizce uygulamaya taşımayız.

Erişilebilirlik doğrudan görev tamamlama konusudur: klavyeyle ürün seçimi, etiketli form alanları, anlaşılır hata özeti, okunabilir kontrast, görünür focus ve ekran okuyucuya durum bildirimi. Mobilde yanlış input türü veya kaybolan form alanı satış akışını kesebilir. Tasarımın yalnızca geniş masaüstü ekranında iyi görünmesi teslim kabulü için yeterli değildir.

Operasyonda HTTP uptime tek başına yeterli olmaz. Checkout hata oranı, CRM’de bekleyen en eski talep, ERP aktarım yaşı, AI fallback oranı ve fiyat/stok read model gecikmesi izlenir. Trace/correlation id ile müşterinin işleminden dependency çağrısına gidilebilir. Backup alınması ile restore edilebilmesi ayrı testtir. RPO kabul edilebilir veri kaybını, RTO geri dönüş hedefini tanımlar; hedefler işletmeyle kararlaştırılıp geri yükleme provasında ölçülür.

İşletme açısından: “7/24 hatasız çalışan dijital personel” sözü yerine hangi koşulda ne olacağını bilmek daha değerlidir. ERP gece kapandığında talep kabul ediliyor mu? Nöbetçi ekip kime haber veriyor? Bir gün önceki yedeğe dönüş kaç siparişi etkiler? TankDev’in mühendislik kapsamına bu soruların cevapları, kabul senaryoları ve işletim dokümantasyonu da girer.

7. Yatırım hesabı ve geçiş planı: web uygulaması ne zaman mantıklı?

Teknik ve ticari hesap: geliştirme fiyatından toplam sahip olma maliyetine

İlk geliştirme bedeli TCO’nun yalnızca bir bölümüdür. Hosting, veritabanı, yedek, trafik, model kullanımı, CMS lisansı, entegrasyon bakımı, izleme ve ekip zamanı aynı hesaba girer. Faydada ciro yerine katkı marjına ve gerçekten serbest kalan iş süresine bakılır. Otomasyonla kazanılan bir saat, başka işte kullanılamıyorsa otomatik nakit tasarrufu sayılmaz. Aynı faydayı hem ek satış hem personel tasarrufu olarak iki kez yazmayız.

Illustrative monthly calculation, not a quotation:
Automatable manual work: 400 operations * 6 min = 40 hours
Residual exception work after automation: 10 hours
Potential released capacity: 30 hours

Net monthly value = incremental contribution margin
                  + monetizable released capacity
                  + avoided error cost
                  - incremental operating cost

Simple payback = initial investment / positive net monthly value
Test low/base/high assumptions; include rollout and maintenance costs.
If net value <= 0, the proposed scope needs to change.

Sabit fiyat listesiyle her ERP entegrasyonuna aynı bedeli vermek yanıltır. Desteklenen API, test ortamı, veri temizliği, alan eşlemeleri, yetki modeli ve hata kurtarma kapsamı eforu değiştirir. Aynı şekilde her katalog AI istemez; exact arama ve doğru filtre çoğu sorunu daha düşük maliyetle çözebilir. İlk sürümden Kafka cluster’ı, Kubernetes ve micro-frontends istemek yerine ihtiyaç duyulan bağımsızlık ve kapasite kanıtlanır.

Mevcut sitenin URL envanteri, trafik alan sayfaları ve iç bağlantıları taşınmadan tasarım yayına alınmaz. Değişen URL’ler anlamca karşılık gelen sayfalara tek adımlı yönlendirilir; tümünü ana sayfaya göndermekten kaçınılır. Sitemap, robots, canonical, hreflang ve analytics olayları staging’de ve canlıda kontrol edilir. Sipariş verisi taşınacaksa sayım/toplam/kimlik karşılaştırması ve cutover planı gerekir. Rollback yalnızca eski frontend’i açmak değildir; yeni şemaya yazılan verinin nasıl korunacağı da tanımlanır.

TankDev bu işin neresinde?

TankDev’de bu kapsamı; kullanıcı ekranları, servis katmanı, veri modeli, rol/kayıt bazlı yetki, entegrasyon sözleşmeleri ve yayın/işletim düzeniyle birlikte geliştiriyoruz. Hazır model yeterliyse onu kontrollü biçimde bağlarız; özel model ancak görev ve veri gerektiriyorsa değerlendirilir. Projenin sonunda yalnızca çalışan bir demo değil, hangi koşullarda doğru çalıştığı ve hata olduğunda nasıl yönetileceği anlaşılabilen bir sistem hedefleriz.

Teslim; kaynak kodu ve sürüm düzeni, API/veri sözleşmeleri, erişim sahipliği, ortam kurulumu, izleme ve kabul kayıtlarıyla somutlaştırılır. Bakımın kimde olduğu, model veya ERP sürümü değişince neyin yeniden test edileceği ve hata bildirimine kim yanıt vereceği proje başında konuşulur. Mimari kararların maliyetle ilişkisini PoC’den production’a rehberimizde daha derin ele alıyoruz.

İşletme açısından: ekran değil, tamamlanan iş satın almak

“Beş bin liraya site yaptıralım” ile başlayan soru, ihtiyacınız yalnızca bir tanıtım adresiyse makul bir bütçe arayışıdır. Ancak müşteri hesabı, özel fiyat, stok, teklif ve ERP aktarımı bekliyorsanız satın aldığınız kapsam değişir. Karşılaştırmayı sayfa sayısı üzerinden değil; tamamlanan iş, doğruluk, ekip zamanı ve sahip olma maliyeti üzerinden yapın. Ucuz ya da pahalı etiketinden önce kapsamın aynı olup olmadığını kontrol edin.

Web uygulamasını dijital çalışan gibi düşünmek faydalı bir benzetme olabilir: talep alır, doğrular, ilgili sisteme taşır ve durumunu bildirir. Fakat bu çalışanın yetkileri, sınırları ve yöneticisi de olmalıdır. Sitenizde hangi adımın satış veya operasyon kaybı ürettiğini birlikte incelemek için projenizin kapsamını TankDev ile konuşabilirsiniz. Başlangıç noktası yeni bir tema seçmek değil, müşterinizin yarım kalan işini belirlemektir.