E-Ticaret Altyapısı Değiştirme Rehberi: Veriyi, SEO'yu ve Satışı Korumak

Mevcut mağaza yavaşladığında, operasyon ekibi sürekli manuel işlem yaptığında veya işletmenin büyüme planı platformun sınırlarına dayandığında altyapı değişikliği gündeme gelir. Yeni bir sistem daha iyi tasarım, yeni pazarlara erişim ya da daha gelişmiş entegrasyonlar sağlayabilir. Bununla birlikte plansız geçiş; eksik ürün, yanlış stok, bozuk ödeme, kaybolan sipariş geçmişi ve organik trafik düşüşü gibi sorunları aynı anda üretebilir.

Bu rehber herhangi bir platformu varsayılan kazanan ilan etmez. Amaç; kaynak ve hedef sistemden bağımsız, denetlenebilir bir geçiş çerçevesi kurmaktır. Örneklerde resmî Google Search ve Shopify belgelerine yer verilmesi, her mağazanın Shopify'a taşınması gerektiği anlamına gelmez. Seçeceğiniz platformun kendi içe aktarma, URL, ödeme ve API belgeleri ayrıca incelenmelidir.

Bu içerik 12 Ekim 2026 tarihinde erişilebilen resmî dokümanlar temel alınarak hazırlanmıştır. Platform özellikleri, CSV şemaları, API sürümleri, ücretler ve entegrasyon koşulları değişebilir. Uygulamadan önce bağlantılı belgeleri, yönetim panelinizi ve sağlayıcı sözleşmelerinizi yeniden doğrulayın. İçerik hukuk, mali müşavirlik veya kişisel veri danışmanlığı değildir.

E-ticaret altyapısı ne zaman değiştirilmelidir?

Platform değişikliği, moda olduğu veya rakip başka bir sistem kullandığı için yapılmamalıdır. Önce bugünkü sorunu kanıtlayın. Aşağıdaki durumlardan birkaçı ölçülebilir biçimde mevcutsa araştırma başlatmak anlamlı olabilir:

• Mobil sayfa ve ödeme performansı satışları olumsuz etkiliyor.
• Ürün, stok, sipariş veya fatura verisi düzenli olarak elle taşınıyor.
• Zorunlu ödeme, kargo, ERP, CRM ya da pazaryeri bağlantısı güvenilir çalışmıyor.
• Yeni ülke, dil, para birimi veya B2B modeli mevcut sistemde sürdürülemiyor.
• Tasarım ve kullanıcı deneyimi değişiklikleri teknik borç nedeniyle çok yavaş ilerliyor.
• Pazarlama ekibi analitik, ürün beslemesi ve dönüşüm ölçümünü doğru kuramıyor.
• Platform, kritik bir özelliği yalnız işletmeye uygun olmayan pakette sunuyor.
• Bakım, eklenti ve geliştirme maliyeti öngörülen değerin üzerine çıkıyor.
• Veriye erişim, dışa aktarma veya hesap sahipliği yeterince açık değil.

Geçişin amacı “daha modern görünmek” ise başarı ölçülemez. Bunun yerine “mobil ödeme tamamlama oranını artırmak”, “stok sapmasını azaltmak”, “yeni ülke mağazasını açmak” veya “kampanya hazırlama süresini kısaltmak” gibi sonuçlar tanımlayın.

Önce kalma, iyileştirme ve geçiş seçeneklerini karşılaştırın

Yeni altyapı tek çözüm olmayabilir. Mevcut temanın sadeleştirilmesi, gereksiz eklentilerin kaldırılması, entegrasyonun yenilenmesi veya hosting iyileştirmesi daha düşük riskle aynı sonucu verebilir. Kararı üç senaryoyla değerlendirin:

Karar dosyasında yalnız aylık lisans ücretini değil en az üç yıllık toplam sahip olma maliyetini hesaplayın. Kurulum, tasarım, uygulama veya eklenti, veri taşıma, özel entegrasyon, işlem ücretleri, bakım, destek, eğitim ve olası satış kesintisini ayrı satırlar hâlinde yazın.

Beş soruluk geçiş karar çerçevesi

1. Bugünkü sorunun parasal veya operasyonel etkisi nedir?
2. Mevcut sistem bu sorunu makul süre ve bütçeyle çözebilir mi?
3. Hedef sistem zorunlu ihtiyaçları bugün gerçekten karşılıyor mu?
4. Geçişten sonra bakım ve veri sahipliği kimde olacak?
5. Beklenen fayda, geçiş ve üç yıllık işletme maliyetini haklı çıkarıyor mu?

Bu soruların cevapları yazılı değilse tasarım görüşmelerinden önce keşif çalışması yapılmalıdır.

Bu karar dosyasını teklif talebine, yani RFP'ye dönüştürün. Her adaya aynı senaryoları gönderin: varyantlı ürün, kampanya, kısmi iade, depo transferi ve mevcut muhasebe bağlantısı. Yanıtta hangi işin standart özellik, ücretli uygulama veya özel geliştirme olduğunu ayrı ayrı isteyin. Lisans kadar veri dışa aktarma, API erişimi, destek yanıtı, servis sürekliliği ve sözleşme sonunda çıkış koşullarını da karşılaştırın. “Destekliyoruz” yanıtını kabul ölçütüne bağlayın; örneğin pilot siparişin stok, fatura ve kargo kayıtları tek kimlikle izlenebilsin. Teklif değerlendirmesini satış sunumuna değil bu gösterimlere dayandırın.

Geçiş kapsamını ve sorumluları netleştirin

Bir altyapı geçişi; e-ticaret, pazarlama, operasyon, finans, müşteri hizmetleri ve teknik ekipleri aynı anda etkiler. “Ajans taşır” ifadesi yeterli sorumluluk tanımı değildir. Her iş için yapan, onaylayan ve bilgilendirilen kişiyi belirleyin.

Asgari çalışma alanları şunlardır:

• Ürün ve kategori verisi
• Müşteri hesapları ve izin kayıtları
• Geçmiş ve açık siparişler
• Stok, depo ve tedarik akışı
• Ödeme, vergi, fatura ve iade
• Kargo ve teslimat kuralları
• Tema, içerik ve dönüşüm bileşenleri
• Alan adı, URL, yönlendirme ve SEO
• Analitik, reklam ve ürün beslemeleri
• E-posta, SMS ve otomasyonlar
• Yetkiler, güvenlik, yedek ve arşiv

Kapsam dışı bırakılan verileri de yazın. Örneğin on yıllık bütün siparişleri yeni sisteme almak yerine yasal ve operasyonel gereksinime göre eski sistemi salt okunur arşiv olarak tutmak tercih edilebilir. Bu karar mali ve hukuki danışmanlarla doğrulanmalıdır.

Kaynak mağazanın eksiksiz envanterini çıkarın

Yeni siteyi tasarlamadan önce kaynak sistemin fotoğrafını çekin. Panel toplamları ile dışa aktarılan satır sayılarını karşılaştırın. Aktif, taslak, arşiv ve tükenen ürünleri; varyantları; lokasyon bazlı stokları; müşteri kayıtlarını; açık iadeleri ve bekleyen siparişleri ayrı sayın.

Envanter dosyasında şu alanlar bulunmalıdır:

• Ürün kimliği, SKU, barkod ve varyant seçenekleri
• Başlık, açıklama, kategori, marka ve özel alanlar
• Liste ve satış fiyatı, vergi sınıfı ve maliyet
• Stok miktarı, rezerv ve depo konumu
• Görsel, video, belge ve alt metinler
• Müşteri hesabı, pazarlama izni ve adresler
• Sipariş, ödeme, kargo, iade ve fatura durumları
• Sayfa, blog, politika, menü ve form içerikleri
• Kupon, hediye kartı, sadakat ve üyelik bilgileri
• Eski URL, trafik, bağlantı ve yeni hedef URL
• Uygulama, API anahtarı, webhook ve veri sahibi

Yinelenen SKU, eksik barkod, bozuk karakter, geçersiz e-posta, boş fiyat ve erişilemeyen görsel bağlantılarını geçişten önce temizleyin. Kirli veriyi otomatik taşımak, otomasyonu hızlandırır fakat sonucu iyileştirmez.

Veri sözlüğü ve alan eşleme tablosu hazırlayın

Kaynak sistemdeki “kategori”, hedef sistemde “koleksiyon”, “ürün grubu” veya “taksonomi” olabilir. Aynı isimli alanlar bile farklı kurallarla çalışabilir. Her alan için kaynak, hedef, dönüşüm kuralı, zorunluluk, örnek değer ve onay sahibini belirleyin.

Aktarım sırası ilişkileri korumalıdır. Örneğin ürün ve müşteri kayıtları oluşmadan geçmiş siparişleri içe aktarmak bağlantıları bozabilir. Shopify'ın resmî geçiş rehberi ürünler, müşteriler ve tarihsel siparişler arasında planlı bir sıra önerir. Hedefiniz başka bir platformsa onun ilişki ve içe aktarma kurallarını kullanın.

Pratik sıra ürün → müşteri → sipariş şeklindedir; kaynak kimliği ile hedef kimliğinin eşleme dosyasını her aşamada saklayın. Geçiş boyunca stok ve ürün verisinin tek doğruluk kaynağını seçin. Kaynak ERP stok sahibi ise yeni mağaza bu veriyi tüketmeli; prova ortamından ERP'ye yanlışlıkla stok yazılmamalıdır. Canlıya alma saatinde yazma yetkisinin hangi sistemden hangisine geçtiğini kayda alın. İki panelde aynı anda bağımsız düzenleme yapılması, doğru taşınmış veriyi bile kısa sürede çelişkili hâle getirir.

İçe aktarma sınırlarını da prova planına ekleyin. Shopify'ın ürün içe aktarma belgesinde ürün CSV'sinin 15 MB'ı aşmaması gerektiği belirtilir. Büyük dosyayı ilişkili ürün satırlarını koruyarak bölün; ilk yüklemeden önce mevcut ürünleri dışa aktararak yedek alın. Başlatılan içe aktarma iptal edilemez; bu nedenle canlı katalog üzerinde deneme yüklemesi yapmak yerine küçük pilot ve geri yükleme yöntemi hazırlayın. Sipariş tarihçesinde toplam tutar, para birimi, tarih ve iade durumunun taşınabilmesi kullanılan araca bağlıdır; geçmiş siparişi yeni bir tahsilat veya müşteri bildirimi tetiklemeden arşivleyebildiğinizi doğrulayın.

Müşteri parolalarının taşınabileceğini varsaymayın. Shopify'ın müşteri içe aktarma belgesi, başka bir çevrim içi mağazadaki müşteri parolalarının CSV ile aktarılamadığını belirtir. Benzer kısıtlar başka altyapılarda da olabilir. Yeni parola ya da hesap aktivasyon iletişimi, müşteri deneyimi planının parçasıdır.

SEO geçişini ayrı bir iş akışı olarak yönetin

Organik görünürlük, yalnız sayfa metnini kopyalayınca korunmaz. URL yapısı, iç bağlantılar, canonical etiketleri, indekslenebilirlik, yapılandırılmış veri ve sunucu yanıtları birlikte değerlendirilmelidir.

Google'ın URL değişiklikli site taşıma rehberi, eski URL'lerden yeni karşılıklarına sunucu taraflı kalıcı yönlendirmeler kurulmasını, yönlendirmelerin test edilmesini, iç bağlantıların güncellenmesini ve yeni sitemap gönderilmesini önerir. Google ayrıca geçiş sırasında sıralama dalgalanmasının normal olabileceğini; orta ölçekli sitelerde sayfaların taşındığını fark etmenin haftalar sürebileceğini açıklar.

Sağlıklı URL haritası şu kurallara uyar:

• Her önemli eski URL en yakın anlamdaki yeni URL'ye eşlenir.
• URL'den URL'ye 301 veya 308 kalıcı yönlendirme kullanılır; harita otomatik taramayla doğrulanır.
• Ürün ürün sayfasına, kategori ilgili kategoriye, içerik eşdeğer içeriğe gider.
• İlgisiz yüzlerce adres yalnız ana sayfaya yönlendirilmez.
• Yönlendirme zincirleri ve döngüleri temizlenir.
• Eski ve yeni XML sitemap ayrı ayrı saklanır.
• Reklam, e-posta, QR kod, sosyal medya ve ürün beslemesi bağlantıları güncellenir.
• 404 ve yanlış 200 yanıtları yayın öncesi taranır.

Yeni sayfalar kendi yeni URL'lerini gösteren self-canonical etiketleri taşımalıdır. İç bağlantılar yönlendirme üzerinden değil doğrudan yeni adrese gitmeli; görsel, video ve belge URL'leri de envantere dahil edilmelidir. Görselin yeni CDN'de bulunması tek başına yeterli değildir: eski medya adresinin davranışı, alt metin, erişim izni ve sayfada yüklenmesi kontrol edilmelidir. Google yönlendirmelerin genel olarak en az bir yıl korunmasını önerir; alan adı ve eski URL kurallarının bu süre boyunca işletme bütçesinde karşılığı bulunmalıdır. Yeni sitemap yalnız doğru canonical ve indekslenebilir URL'leri içermeli, test ortamının noindex veya robots engelleri canlıya taşınmamalıdır.

Başlık, meta açıklama ve ana içerikte aynı anda gereksiz büyük değişiklikler yapmak, geçiş etkisini içerik değişikliğinden ayırmayı zorlaştırır. Zorunlu olmayan SEO deneylerini mağaza kararlı hâle geldikten sonra yapın.

Tasarım eşitliği değil, işlev eşitliği arayın

Eski ekranı piksel piksel kopyalamak yerine müşterinin tamamlaması gereken işleri listeleyin. Arama, filtre, varyant seçimi, stok mesajı, fiyat görünümü, sepete ekleme, kupon, teslimat tahmini, ödeme ve sipariş takibi yeni sistemde kesintisiz çalışmalıdır.

Özellikle şu içerikleri gerçek veriyle doğrulayın:

• Çok uzun ürün adı ve açıklaması
• Çok sayıda varyant ve tükenen seçenek
• İndirimli fiyat ve kampanya rozeti
• Kişiselleştirilebilir ürün
• Dijital ürün veya farklı teslimat biçimi
• Set, paket veya ön sipariş
• Mobil filtre ve kategori gezinmesi
• Türkçe karakter ve uzun adres
• Yasal metin onayı ve pazarlama izni

Yeni tema demo ürünlerle iyi görünüp gerçek katalogda bozulabilir. Temsilci ürün örnekleri seçmek, son hafta toplu sürpriz yaşamayı azaltır.

Ödeme, kargo ve finans akışını uçtan uca test edin

Ödeme sağlayıcısının logosunun görünmesi, tahsilat akışının hazır olduğu anlamına gelmez. Başarılı ve başarısız ödeme; farklı kart, taksit, 3D Secure, iptal, tam ve kısmi iade senaryoları sözleşmenin ve teknik imkanın izin verdiği ölçüde denenmelidir.

Kargo testinde ücret, ücretsiz kargo eşiği, bölge kısıtı, desi, farklı depo, etiket, takip kodu ve müşteriye bildirim kontrol edilmelidir. Vergi ve fatura tarafında ürün sınıfı, KDV, şirket bilgisi, e-belge, indirim ve iade bağlantıları uzmanlarla doğrulanmalıdır.

Bir test siparişi yalnız teşekkür sayfasına ulaşmak değildir. Shopify'ın test siparişi rehberi sipariş işleme, stok, e-posta, kargo ve vergi ayarlarının kontrolünü geçiş sürecinin parçası olarak ele alır. Aynı uçtan uca yaklaşım hangi platform seçilirse seçilsin uygulanmalıdır.

Küçük pilot, tam prova ve canlı geçiş sırası

Önce farklı veri yapılarını temsil eden 10–20 ürünlük küçük bir grubu aktarın. Tek varyantlı, çok varyantlı, tükenen, indirimli, çok görselli ve özel alanlı ürünler pilotta yer almalıdır. Kayıt sayısı kadar alan doğruluğunu da kontrol edin.

Pilot geçtikten sonra bütün veriyi prova ortamına alın. Prova aktarımında geçen süreyi ölçün; başarısız kayıtları sınıflandırın; düzeltme ve yeniden çalıştırma adımlarını yazın. Sonra gerçek canlı geçişi aynı komut, dosya ve kontrol listesiyle tekrarlayın.

Örnek canlı geçiş akışı:

1. Değişiklik dondurma saatini ekip ve tedarikçilere bildirin.
2. Kaynak sistemin tarihli tam yedeğini alın.
3. Son ürün, müşteri, stok ve sipariş farkını çıkarın.
4. Delta veriyi hedef sisteme aktarın ve toplamları karşılaştırın.
5. Ödeme, kargo, vergi, e-posta ve entegrasyon duman testlerini çalıştırın.
6. Alan adını veya trafik yönünü planlanan pencerede değiştirin.
7. URL yönlendirmelerini etkinleştirip örnekleri ve yüksek trafikli sayfaları test edin.
8. Gerçekçi bir sipariş verin; stok, bildirim, fatura ve kargo sonucunu izleyin.
9. Analitik ve reklam dönüşümlerinin tekilleştiğini doğrulayın.
10. İlk 72 saat için sorumlu ve müdahale kanalını aktif tutun.

Alan adı değişiminden önce DNS kayıtları, mevcut TTL, SSL sertifikası, e-posta kayıtları ve sağlayıcı doğrulamalarını inceleyin. Gerekliyse TTL'yi önceden azaltın; DNS önbellekleri nedeniyle bir süre iki sistemin de ziyaret alabileceğini hesaba katın. Dondurma penceresinde hangi değişikliklerin duracağını açıkça belirtin: ürün düzenleme durabilirken açık sipariş sevkiyatı devam edebilir. Bu ayrım delta senkronizasyonunun kapsamını belirler. Geri dönüş kararı verilirse yalnız DNS'yi çevirmek yetmez; yeni mağazada oluşan siparişlerin ve rezervlerin eski operasyona nasıl taşınacağını da prova edin.

QA matrisiyle kanıt toplayın

“Baktık, çalışıyor” yerine beklenen sonucu ve kanıtı olan test matrisi kullanın.

Masaüstü testinin yanında gerçek telefon, farklı tarayıcı, yavaş bağlantı ve klavye kullanımı da kontrol edilmelidir. Erişilebilirlik yalnız yasal bir madde değil; müşterinin ürüne ulaşıp satın alabilmesinin temelidir.

Geri dönüş planı ve karar eşiği oluşturun

Geri dönüş planı, başarısızlık beklentisi değil operasyon disiplinidir. Canlı geçişten önce hangi durumda ilerlemeyi durduracağınızı yazın. Örneğin ödeme alınamaması, stok yazımının durması, siparişlerin merkezi sisteme düşmemesi veya kritik yönlendirmelerin bozulması yayın durdurma nedeni olabilir.

Plan şunları içermelidir:

• Kaynak sistemin ne kadar süre çalışır tutulacağı
• Alan adı değişikliğinin geri çevrilme yöntemi
• Son başarılı yedek ve geri yükleme sahibi
• Geçiş sırasında alınan siparişlerin nasıl korunacağı
• Müşteriye ve ekibe yapılacak iletişim
• Tedarikçi destek numaraları ve erişimler
• İlerleme, durma ve geri dönme kararını verecek kişi

Kaynak mağazayı açık sipariş, iade, ödeme mutabakatı ve saklama gereksinimleri doğrulanmadan silmeyin veya kapatmayın.

Yayın sonrası ilk 30 günün kontrol paneli

Geçiş alan adı açıldığında bitmez. İlk hafta günlük, daha sonra haftalık olarak şu metrikleri izleyin:

• Başarılı ödeme ve ödeme hatası oranı
• Dönüşüm, sepete ekleme ve ödeme başlatma oranı
• Sipariş, tahsilat, fatura ve kargo mutabakatı
• Stok sapması ve aşırı satış vakası
• 404, yönlendirme ve sunucu hataları
• Search Console gösterim, tıklama ve indeks durumu
• Site hızı ve mobil kullanılabilirlik
• Reklam gelir ve dönüşüm ölçümü
• Müşteri hesabı ve parola talepleri
• Destek kayıtlarında tekrar eden problemler

Eski ve yeni dönemi karşılaştırırken kampanya, mevsimsellik, fiyat ve reklam bütçesi değişikliklerini not edin. Her düşüşü platforma, her artışı tasarıma bağlamak yanlış karar üretir.

E-ticaret altyapısı değiştirme kontrol listesi

• [ ] İş gerekçesi, başarı ölçütü ve bütçe onaylandı.
• [ ] Kalma, iyileştirme ve geçiş seçenekleri karşılaştırıldı.
• [ ] Ürün, müşteri, sipariş, içerik ve entegrasyon envanteri çıkarıldı.
• [ ] Kaynak verilerin doğrulanmış yedeği alındı.
• [ ] Alan eşleme ve veri temizleme kuralları yazıldı.
• [ ] Kişisel veri, izin ve saklama gereksinimleri değerlendirildi.
• [ ] Eski-yeni URL haritası ve yönlendirmeler hazırlandı.
• [ ] Tasarım gerçek katalog örnekleriyle test edildi.
• [ ] Ödeme, kargo, vergi, fatura ve e-posta akışları doğrulandı.
• [ ] Analitik, reklam ve ürün beslemeleri test edildi.
• [ ] Pilot ve tam prova aktarımı tamamlandı.
• [ ] Açık siparişler ile son stok farkı için plan hazırlandı.
• [ ] Değişiklik dondurma ve canlı geçiş saatleri belirlendi.
• [ ] Geri dönüş eşikleri, yedek ve karar sahibi tanımlandı.
• [ ] İlk 72 saat ve 30 günlük izleme sorumluları atandı.

Geçişi satış sürekliliği projesi olarak yönetin

Doğru altyapı geçişi en hızlı yapılan değil, müşteriyi, veriyi ve organik talebi koruyarak tamamlanan geçiştir. Timurial olarak mevcut mağazanın teknik ve operasyonel envanterini çıkarıyor; hedef platform seçimini gereksinimlerle doğruluyor; veri eşleme, SEO yönlendirme, ödeme-kargo entegrasyonu, QA ve canlı geçiş planını tek yol haritasında birleştiriyoruz. Mağazanızın geçiş kapsamını ve risklerini netleştirmek için projenizi bize anlatın.

Resmî kaynaklar

• Google Search Central: URL değişiklikli site taşıma
• Google Search Central: Yönlendirmeler ve Google Search
• Google Search Console: Sitemap yönetimi
• Shopify: Shopify'a geçiş rehberi
• Shopify: Ürünleri CSV ile içe ve dışa aktarma
• Shopify: Ürünleri CSV ile içe aktarma sınırları
• Shopify: Müşterileri içe ve dışa aktarma
• Shopify: URL yönlendirmeleri
• Shopify: Test siparişleri