E-Ticaret Sitesi Taşıma Rehberi

Mevcut altyapı büyümeyi, entegrasyonları veya günlük operasyonu sınırladığında e-ticaret sitesi taşıma kararı gündeme gelir. Fakat taşıma, ürün CSV'sini içe aktarmaktan ya da alan adını yeni bir sunucuya yönlendirmekten ibaret değildir. URL ve SEO sinyalleri, ürün-müşteri-sipariş verileri, açık işlemler, stok, ödeme, e-belge, entegrasyon ve ölçüm aynı geçiş planında ele alınmalıdır.

“SEO kaybı olmadan” hedefi bir sonuç garantisi değil, ölçülebilir risk azaltma disiplinidir. Büyük değişikliklerde geçici trafik ve sıralama dalgalanması görülebilir. Sağlıklı proje; önce baz ölçümü alır, kaynak-hedef eşleştirmesini hazırlar, deneme aktarımı ve kullanıcı kabul testi yapar, son değişiklikleri delta aktarımıyla yakalar, go/no-go kararı verir ve veri etkisini de içeren rollback planını önceden kanıtlar.

Bu rehber; taşınmanın gerekli olup olmadığını sorgulamanıza, taşınacak ve arşivlenecek varlıkları ayırmanıza, URL ile veri mapping çalışmalarını karıştırmamanıza, canlıya geçiş koşullarını belirlemenize ve paket kapsamıyla özel proje işlerini karşılaştırmanıza yardımcı olur. Ana ilke nettir: güvenli altyapı değişikliği yalnız yeni siteyi açmaz; müşteri güveni ile ticari sürekliliği de korumaya çalışır.

E-Ticaret Sitesi Taşıma Nedir?

E-ticaret sitesi taşıma, çalışan bir mağazanın teknoloji, veri, URL, entegrasyon veya operasyonlarının kaynak platformdan hedef platforma kontrollü biçimde geçirilmesidir. Site migration genel taşıma sürecini; e-commerce replatforming ise mağazanın temel platformunun yeniden seçilip kurulmasını anlatır. Aynı alan adı korunurken uygulama altyapısının değişmesi de bir migrasyondur.

• Dosya taşıma: Kod, tema, medya ve yapılandırma dosyalarının yeni ortama alınmasıdır.
• Veri taşıma: Ürün, müşteri, sipariş ve ilişkili kayıtların hedef veri modeline dönüştürülmesidir.
• URL taşıma: Eski adreslerin yeni karşılıklarla eşleştirilmesi ve arama sinyallerinin tutarlı kılınmasıdır.
• Operasyon taşıma: Ödeme, stok, e-belge, kargo, ERP ve destek akışlarının yeni sistemde devam etmesidir.

E-Ticaret Sitesi Taşıma Türleri Nelerdir?

Taşıma türü, değişen varlık ile riski belirler. Yalnız hosting değişikliği ile alan adı, CMS, tasarım ve URL yapısının birlikte değiştiği proje aynı prosedürle yönetilemez. Aşağıdaki tablo Change of Address kullanımını da ayırır; aracın asıl alan adı değişiklikleri için olduğu, her URL değişiminde kullanılmadığı özellikle önemlidir.

Taşıma türü	Kullanıcıya görünen değişiklik	SEO riski	Veri riski	Change of Address	Temel kontrol
Aynı domain, yeni altyapı	Tasarım veya işlev değişebilir	Orta	Yüksek	Kullanılmaz	URL, render ve veri eşdeğerliği
Yeni domain	Marka ve adres değişir	Yüksek	Orta	Desteklenen alan geçişinde kullanılır	Bire bir mapping ve kalıcı yönlendirme
Yeni hosting/CDN	Genellikle görünmez	Orta	Düşük-orta	Kullanılmaz	DNS, kapasite, durum kodu
URL yapısı değişikliği	Sayfa adresleri değişir	Yüksek	Düşük	Aynı domainde kullanılmaz	Eski-yeni URL eşleştirmesi
HTTP'den HTTPS'e geçiş	Güvenli bağlantı görünür	Orta	Düşük	Kullanılmaz	TLS, canonical ve yönlendirme
www/non-www değişimi	Alan biçimi değişir	Orta	Düşük	Kullanılmaz	Tek tercih edilen host
Siteleri birleştirme	İçerik tek yapıda toplanır	Yüksek	Yüksek	Alan senaryosuna bağlı	Niyet ve kayıt çakışmaları

Karar çıkarımı: Proje adı “site taşıma” olsa da gerçek kapsam, değişen domain, URL, veri modeli ve operasyon akışlarının ayrı ayrı yazılmasıyla anlaşılır.

E-Ticaret Altyapısı Hangi Durumlarda Değiştirilmelidir?

Altyapı değişikliği; ölçülmüş kapasite sorunu, sürdürülemez teknik borç, kritik entegrasyon eksikliği, veri dışa aktarma kısıtı veya toplam sahip olma maliyetinin iş hedefleriyle uyuşmaması gibi kalıcı nedenlerde değerlendirilmelidir. Yavaş bir tema, bozuk ürün verisi ya da yanlış süreç tek başına platform değişikliğini haklı çıkarmaz.

Belirti	Ölçülecek veri	Mevcut altyapıda iyileştirme?	Taşıma önceliği	Yanlış karar riski
Yoğunlukta hata	5xx, yanıt süresi, kapasite	Ölçekleme denenebilir	Kanıt sonrası yüksek	Sorunu yeni sisteme taşımak
Entegrasyon kopukluğu	Manuel iş, hata ve gecikme	API/ara katman incelenir	Orta-yüksek	Gereksiz yeniden geliştirme
Stok/fiyat tutarsızlığı	Kanal farkı ve iptal oranı	Kaynak sistem düzeltilir	Kök nedene bağlı	Aynı yönetişim hatası
Raporlama yetersizliği	Karar için gereken veri	Veri ambarı düşünülebilir	Orta	Platformu rapor aracı sanmak
Güvenlik/bakım riski	Destek durumu, açıklar, yama	Kısa vadeli iyileştirme sınırlı olabilir	Yüksek	Riskli sistemi uzun tutmak
Veri çıkışı engeli	Export/API kapsamı ve sözleşme	Tedarikçiyle netleştirilir	Stratejik	Yeni bağımlılık oluşturmak

Yeni platform değerlendirmesi sırasında veri sahipliği, API ve çıkış koşullarını içeren paket seçim kriterlerini ayrıca incelemek, aynı sorunun tekrarlanmasını önler.

Taşınmadan Önce Mevcut Altyapı İyileştirilebilir mi?

Evet. Sorun tema kodundan, hosting kapasitesinden, yanlış cache ayarından, bozuk entegrasyondan, dağınık veriden veya ekip sürecinden doğuyorsa platform değişmeden iyileştirme mümkün olabilir. Teknik denetim, süreç haritası ve üç yıllık toplam maliyet karşılaştırması yapılmadan verilen “yenilenelim” kararı, çift lisans ve gereksiz operasyon riski yaratır.

Taşınma kararı, görünüm yenileme isteğinden ayrılmalıdır. Hazır paket, özel geliştirme ve hibrit yapının migrasyon sınırlarını anlamak için hazır e-ticaret altyapısı yaklaşımını mevcut veri ve entegrasyon kısıtlarıyla birlikte değerlendirin.

E-Ticaret Sitesi Taşımanın Başlıca Riskleri Nelerdir?

Risk yalnız organik trafik değildir. Yanlış fiyat, eksik açık sipariş, çift ödeme, bozuk stok, kişisel veri sızıntısı veya çalışmayan e-belge akışı, SEO sorunundan daha acil ticari etki yaratabilir. Riskler etki, olasılık, erken uyarı ve sorumlu ekip ile kayda alınmalı; her kritik riskin önleyici kontrolü ve geri dönüş tetikleyicisi bulunmalıdır.

Risk	Etki	Olasılık	Erken uyarı	Önleyici kontrol	Sorumlu
Organik görünürlük kaybı	Yüksek	Orta	Tıklama ve indeks düşüşü	Baz ölçüm ve URL mapping	SEO
Eksik ürün/varyant	Yüksek	Orta	Kayıt sayısı farkı	ID ilişki doğrulaması	Veri/e-ticaret
Yanlış fiyat/KDV	Kritik	Orta	Sepet toplamı farkı	Örnek sipariş mutabakatı	Finans
Stok ayrışması	Kritik	Yüksek	Fazla satış	Tek yazma sahibi ve son delta	Operasyon
Hesap/parola sorunu	Yüksek	Orta	Giriş ve destek artışı	Aktivasyon planı	Müşteri hizmetleri
Açık sipariş kaybı	Kritik	Orta	Durum/toplam farkı	İşlem sahipliği tablosu	Operasyon/finans
Ödeme/e-belge hatası	Kritik	Orta	Callback veya kuyruk hatası	Uçtan uca test	Teknik/finans

Karar çıkarımı: Yalnız SEO ekibinin yönettiği taşıma eksik kalır; veri, finans ve operasyon riskleri aynı go/no-go kurulunda temsil edilmelidir.

Taşıma Projesinin Başarı Kriterleri Nasıl Belirlenir?

“Site açıldı” başarı kriteri değildir. SEO, veri, sipariş, ödeme, stok, entegrasyon, performans ve güvenlik için baz değer, izin verilen sapma, test yöntemi, kanıt ve karar sahibi yazılmalıdır. Sıfır hata ifadesi yerine kritik hata toleransı, düzeltme süresi ve hangi sapmanın canlıya çıkışı durduracağı önceden kararlaştırılmalıdır.

Alan	Baz değer	Hedef/izin verilen sapma	Test	Go/no-go etkisi	Kanıt
URL	Onaylı envanter	Kritik URL'lerde hatasız	Toplu istek + örnekleme	Kritik	Redirect raporu
Ürün/veri	Kaynak sayılar ve toplamlar	Onaylı eşik içinde	Sayım, ilişki, örneklem	Kritik	Mutabakat tablosu
Ödeme	Çalışan senaryolar	Başarılı/başarısız akış doğru	Test siparişi	Bloker	İşlem ve sipariş kaydı
Stok	ERP/depo anlık görünüm	Rezervasyonla tutarlı	Son delta mutabakatı	Bloker	SKU bazlı fark raporu
Analitik	Ölçüm planı	Tekil purchase ve doğru değer	Debug + iş kaydı	Yüksek	Olay ekranı
Güvenlik	Risk listesi	Açık kritik bulgu yok	Yetki ve yapılandırma testi	Bloker	Onay kaydı

Taşıma öncesi ve sonrası ticari metriklerin tutarlı izlenmesi için e-ticaret raporlama çerçevesi baz ölçüm planına bağlanabilir.

Taşıma Ekibinde Kimler Yer Almalıdır?

Taşıma ekibi iş sponsoru, proje yöneticisi, e-ticaret yöneticisi, yazılım/altyapı, veri, SEO, operasyon/depo, finans/muhasebe, müşteri hizmetleri, pazarlama/analitik ve bilgi güvenliği/KVKK rollerini içermelidir. Eski ve yeni tedarikçi de veri çıkışı, destek ve geçiş sorumluluklarıyla matrise eklenmelidir. Tek kişinin bütün kararları üstlenmesi görünmeyen risk üretir.

İş	Yapan	Hesap veren	Danışılan	Bilgilendirilen
Gereksinim onayı	Proje yöneticisi	Sponsor	Tüm süreç sahipleri	Tedarikçiler
Veri çıkarma/eşleme	Veri ekibi	E-ticaret yöneticisi	Finans/operasyon	Sponsor
URL mapping	SEO + teknik	Pazarlama sahibi	İçerik	Proje ekibi
Entegrasyon/UAT	Teknik + süreç sahipleri	Proje yöneticisi	Tedarikçiler	Sponsor
Go/no-go	Karar kurulu	Sponsor	SEO, veri, finans, güvenlik	Tüm paydaşlar
DNS/rollback	Altyapı ekibi	Teknik lider	Veri ve operasyon	Müşteri hizmetleri

RACI; sorumlu, hesap veren, danışılan ve bilgilendirilen tarafları ayırır. Karar çıkarımı: Özellikle rollback yetkisi ve müşteri iletişimi canlı geceye bırakılmamalıdır.

Taşıma Kapsamı Nasıl Belirlenir?

Kapsam belgesi “taşınacak her şey” değil; kapsam içi, kapsam dışı ve sonraki faz varlıklarını tanımlar. Veri tarih aralığı, içerik eleme kuralları, korunacak entegrasyonlar, değişecek URL'ler, yeniden geliştirilecek özellikler ve sadeleştirilecek iş kuralları yazılmalıdır. Aşağıdaki keşif soruları teklif ve kabul belirsizliğini azaltır.

1. Taşınmanın ölçülmüş iş gerekçesi nedir?
2. Hangi domain ve subdomainler kapsamda?
3. Hangi URL türleri değişecek?
4. Kaynak platform hangi export ve API'leri sunuyor?
5. Ürün, varyant ve medya hacmi nedir?
6. Müşteri ve adres kayıtlarının hangi tarih aralığı gerekli?
7. Geçmiş ve açık siparişler nasıl ayrılacak?
8. İade, kısmi sevkiyat ve iptaller nerede tamamlanacak?
9. Kupon ve sadakat bakiyesinin finansal sahibi kim?
10. Parola geçiş yöntemi teknik olarak destekleniyor mu?
11. Hangi sistem ürünün ana kaynağı?
12. Stok ve fiyatı hangi sistem yazacak?
13. ERP, muhasebe ve e-belge akışları neler?
14. Ödeme tokenı veya kayıtlı kart bağımlılığı var mı?
15. Kargo ve pazaryeri hesapları yeniden yetkilendirilecek mi?
16. Blog, yasal metin ve SEO metadata taşınacak mı?
17. Filtre, arama ve parametre URL'leri nasıl ele alınacak?
18. Çoklu dil, ülke veya para birimi var mı?
19. Analitik ve reklam olaylarının baz planı nedir?
20. Staging'de hangi veri kullanılabilir?
21. Kritik hata ve izin verilen sapma eşikleri nedir?
22. UAT'yi hangi iş birimleri yapacak?
23. Veri dondurma penceresi ne zaman?
24. Rollback hangi olayda tetiklenecek?
25. Eski sistem ne zaman salt okunur ve ne zaman kapalı olacak?

Taşıma Öncesi Mevcut Sistem Envanteri Nasıl Çıkarılır?

Mevcut sistem envanteri yalnız uygulama listesinden oluşmaz. Domainler, DNS, SSL, CDN/WAF, veritabanı, medya, tema, özel kod, eklenti, API, webhook, cron, kullanıcı yetkileri, analitik ve tüm ticari entegrasyonlar sahipleriyle kaydedilir. Her varlığın hedefi, taşıma yöntemi, riski ve kabul testi bulunmalıdır.

Varlık	Sahibi	Kaynak	Hedef	Taşınacak mı?	Yöntem	Risk	Kabul testi
Ürün kataloğu	E-ticaret	PIM/mağaza	Hedef katalog	Evet	API/ETL	İlişki kaybı	Sayım + örneklem
Medya	İçerik	CDN/depo	Yeni CDN	Evet	Dosya kopyası	Kırık URL	Hash + görsel test
Ödeme	Finans	Sağlayıcı	Yeni checkout	Yeniden kurulum	API/webhook	Çift tahsilat	Uçtan uca işlem
ERP akışı	Operasyon	ERP	Yeni mağaza	Evet	API/queue	Çift sipariş	ID ve toplam mutabakatı
Analitik	Pazarlama	Etiket yöneticisi	Yeni şablon	Evet	Ölçüm planı	Çift event	İş kaydı karşılaştırması

Karar çıkarımı: Envanterde sahibi olmayan varlık, canlı geçişte sahipsiz hata olma eğilimindedir.

Hangi Veriler Yeni E-Ticaret Altyapısına Taşınmalıdır?

Ürün, kategori, marka, varyant, özellik, medya, fiyat, stok, müşteri, adres, sipariş, iade, yorum, kupon, içerik ve SEO alanları ayrı veri nesneleridir. Her nesne için iş değeri, hukuki/operasyonel gereklilik, veri kalitesi ve hedef desteği değerlendirilir. Her kayıt yeni sisteme taşınmak zorunda değildir; bazıları yalnız arşivlenir veya onayla temizlenir.

Karar çıkarımı: Veri minimizasyonu ile tarihsel bütünlük dengelenmeli; hukuki saklama sonucu proje ekibi tarafından varsayılmamalıdır.

Kaynak Sistem ve “Source of Truth” Nasıl Belirlenir?

Source of truth, bir veri türü için doğru kabul edilen ana kaynaktır. Ürün PIM'den, stok ERP'den, sipariş mağazadan, belge durumu e-belge sisteminden gelebilir. Aynı alanın farklı sistemlerde farklı değer taşıması hâlinde canlı geçiş kuralı ve yazma yetkisi belirlenmezse doğru verinin üzerine eski veri yazılabilir.

Operasyon omurgasını ayrıntılandırmak için sipariş, stok, fatura ve kargo süreçleri kaynak sahipliği çalışmasına eşlik edebilir.

Veri Temizliği Taşımadan Önce Neden Yapılmalıdır?

Mükerrer ürün ve müşteri, eksik SKU/barkod, bozuk kategori ağacı, geçersiz iletişim bilgisi, eski görsel, tutarsız KDV/ölçü birimi ve kullanılmayan özel alanlar hedef sistemde daha pahalı sorunlara dönüşür. Çöp veriyi daha hızlı taşımak başarı değildir. Her temizlik kuralı, etkilenen kayıt sayısı, onaylayan ve geri izleme kaydıyla uygulanmalıdır.

Ürün kodu, varyant, görsel ve kategori hazırlığının temelini görmek için ürün verisi hazırlama rehberini temizlik planına bağlayabilirsiniz. Silme ve tekilleştirme kararları sipariş ilişkilerini bozmadan, örneklem ve ilişki testiyle doğrulanmalıdır.

Veri Eşleştirme (Data Mapping) Nedir?

Data mapping, kaynak nesne ve alanların hedefte hangi nesne ve alana, hangi dönüşümle yazılacağını tanımlar. Field mapping yalnız sütun adını değil veri tipini, zorunluluğu, varsayılanı, referansı, hata davranışını ve doğrulama kuralını kapsar. Basit kopyalama ile KDV dahil fiyatı farklı modele dönüştürmek aynı işlem değildir.

Karar çıkarımı: Mapping tablosu yazılım ekibinin teknik notu değil, veri sahibi tarafından onaylanan proje sözleşmesidir.

Kimlik Eşleştirmesi ve Veri İlişkileri Nasıl Korunur?

Referential integrity, ilişkili kayıtların birbirini doğru anahtarlarla göstermesidir. Eski ID ile yeni ID arasında kalıcı mapping tutulmalı; ürün-varyant, müşteri-adres, sipariş-satır, kategori-ürün ve yorum-ürün bağları bu tabloyla yeniden kurulmalıdır. SKU iş açısından değerli olsa da her sistemde benzersiz veya değişmez olmayabilir; tek başına güvenli anahtar sayılmaz.

Hedef sistemde external ID alanı varsa kaynak kimliği denetim izi olarak korunabilir. Yetim sipariş satırı veya yanlış ürüne bağlanan yorum, kayıt sayıları eşit olsa bile veri geçişinin başarısız olduğunu gösterir.

Ürün, Kategori ve Marka Verileri Nasıl Taşınır?

Ürün aktarımı ad, açıklama, SKU, barkod, marka, kategori ağacı, vergi, ölçü birimi, satış durumu, tedarikçi kodu, SEO alanı, teknik özellik, set ürün ve tamamlayıcı ürün ilişkilerini kapsar. Aktarım sırası genellikle referans sözlükleri, kategori/marka, ana ürün, varyant ve ilişkiler biçiminde planlanır; hedef modelin kuralları önce kanıtlanır.

Karar çıkarımı: Ürün kartı sayısı eşit olsa bile kategori, varyant ve set ilişkileri doğrulanmadıysa katalog tamamlanmış değildir.

Varyant ve Özellik Yapısı Nasıl Dönüştürülür?

Varyant; renk ve beden gibi satın alınabilir kombinasyondur, özellik ise filtreleme veya açıklama amacı taşıyabilir. Kaynak platformdaki seçenek modeli hedefte farklıysa kombinasyon patlaması, seçilemeyen varyant, yanlış filtre ve gereksiz URL üretimi doğabilir. Her varyantın SKU, barkod, fiyat, stok ve görsel ilişkisi ayrı kayıt olarak test edilmelidir.

Temsili örnek: “Sulama Hortumu” ana ürünündeki 10 m ve 20 m uzunlukları hedefte varyant; malzeme ve basınç sınıfı filtre özelliği olabilir. Eski `urun_id=82, varyant_id=3` kaydı yeni variant ID ile eşleştirilir; stok 20 m SKU'suna bağlanır, ana ürüne topluca yazılmaz.

Ürün Görselleri, Videolar ve Dosyalar Nasıl Taşınır?

Medya aktarımı yalnız HTML içindeki görsel adreslerini değiştirmek değildir. Orijinal dosya, türev boyutlar, dosya adı, alt metin, CDN URL'si, ürün/varyant ilişkisi, PDF ve teknik doküman bağımsız varlıklardır. Dosya sayısı, boyut, hash ve örnek görüntüleme kontrolü birlikte kullanılmalı; lisans ve erişim yetkisi de doğrulanmalıdır.

Eski CDN kapatılmadan kırık medya taraması yapılmalı; kritik görsel ve PDF URL'lerinin dış bağlantı veya organik trafik alıp almadığı URL envanterinde görülmelidir. Hotlink ve referer kuralları yeni domaini yanlışlıkla engellememelidir.

Fiyat, KDV, Para Birimi ve Kampanya Kuralları Nasıl Taşınır?

Liste fiyatı, indirimli fiyat, maliyet, KDV dahil/hariç durumu, para birimi, kur kaynağı, müşteri grubu, kampanya tarihi, kupon koşulu ve yuvarlama ayrı alan ve kurallardır. Ürün sayfası, sepet, ödeme, sipariş kaydı ve e-belge tutarları aynı iş kuralıyla uyuşmalıdır. Vergi ve muhasebe sonucu finans uzmanı tarafından onaylanmalıdır.

Geçiş anında fiyat kaynağı ve kur zamanı sabitlenmeli; iki sistemin kampanya motoru aynı anda çalıştırılmamalıdır. Temsili siparişler; indirimsiz, kuponlu, farklı KDV'li, müşteri gruplu ve para birimli senaryoları kapsamalıdır.

Stok ve Depo Verileri Canlı Geçişte Nasıl Korunur?

Toplam stok, satışa açık miktar, rezervasyon, depo, yoldaki stok, güvenlik stoğu ve iade bekleyen miktar aynı kavram değildir. Canlı satış sürerken ilk aktarımdan sonra değişen kayıtlar son delta ile yakalanmalı; geçiş penceresinde stok için tek yazma sahibi belirlenmelidir. Aksi hâlde çift düşüm veya fazla satış oluşabilir.

Açık siparişlerin rezervasyon etkisi kaynak ve hedefte aynı SKU/depo düzeyinde mutabık olmalıdır. Veri dondurma mümkün değilse kuyruk, çift yazım veya CDC yaklaşımı ancak idempotency ve uzlaştırma mekanizması kanıtlandıktan sonra seçilmelidir.

Müşteri ve Adres Verileri Nasıl Taşınır?

Müşteri kimliği, ad, iletişim bilgisi, fatura/teslimat adresi, şirket/vergi alanı, müşteri grubu, hesap durumu, segment ve izin kaydı ayrı amaçlarla işlenir. Gereksiz alanlar taşınmamalı; mükerrer e-posta, birden fazla hesap ve geçersiz adres kuralları iş sahibi tarafından çözülmelidir. Tarih ve kaynak bilgisi kaybolmamalıdır.

Aktarım dosyaları şifrelenmeli, erişim en az ayrıcalıkla sınırlandırılmalı ve geçici kopyaların silme planı bulunmalıdır. Gerçek müşteri verisi korumasız staging ortamına veya genel dosya paylaşım alanına konmamalıdır.

Müşteri Parolaları Yeni Altyapıya Taşınabilir mi?

Bazen taşınabilir, bazen taşınamaz; yöntem kaynak hash algoritmasına, hedef platform desteğine ve sağlayıcının güvenli export yaklaşımına bağlıdır. Parolalar düz metin olarak istenmemeli veya taşınmamalıdır. Uyum yoksa hesap aktivasyonu ya da parola sıfırlama planlanır. Kullanıcı deneyimi, güvenlik ve destek yükü birlikte değerlendirilir.

Karar çıkarımı: Parola yöntemi “müşteri CSV'si var” bilgisiyle belirlenemez; kimlik mimarisi ve iletişim provası gerekir. Geçiş iletişiminde müşteri güveni oluşturan açıklık ve doğrulama işaretleri korunmalıdır.

KVKK ve Ticari İleti Kayıtları Taşıma Sürecinde Nasıl Korunur?

Veri amacı, kapsamı, erişim rolü, saklama ve imha yaklaşımı aktarım başlamadan belgelenmelidir. İzin ve ret kayıtlarının tarihi, kaynağı ve kapsamı korunmalı; ret durumu yeni sistemde yanlışlıkla izne çevrilmemelidir. Testte maskelenmiş veya sentetik veri tercih edilmeli, işlem ve erişim kayıtları tutulmalı, tedarikçi rolleri uzman tarafından incelenmelidir.

KVKK'nın veri güvenliğine ilişkin yükümlülükleri, risk düzeyine uygun teknik ve idari tedbirleri vurgular. Bu rehber hukuk danışmanlığı değildir; aydınlatma, açık rıza, veri işleyen sözleşmesi, aktarım ve saklama kararları işletmenin veri koruma sorumlusu ve hukuk uzmanıyla doğrulanmalıdır.

Sipariş Geçmişi Nasıl Taşınmalıdır?

Sipariş numarası, müşteri, satırlar, işlem anındaki ürün adı, fiyat, vergi, indirim, para birimi, ödeme/kargo/fatura durumu, tarih, not ve entegrasyon kimlikleri birlikte korunmalıdır. Tarihsel sipariş bugünkü ürün fiyatıyla yeniden hesaplanmamalıdır. Hedefte aktif operasyon kaydı ile yalnız okunabilir arşiv görünümü arasındaki fark bilinçli seçilmelidir.

Kaynak sipariş kimliği yeni kimlikle eşleştirilmeli; müşteri hizmetleri eski numarayla arama yapabilmelidir. Satır toplamı, vergi, indirim ve genel toplam kontrolü kayıt sayısından daha güçlü bir doğrulama sağlar.

Açık Sipariş, İade ve Kısmi Sevkiyatlar Nasıl Yönetilir?

Açık işlemler için tek bir tamamlama sistemi seçilmelidir. Siparişin eski sistemde tamamlanması, yeni sisteme aktif taşınması veya iki tarafta salt okunur görünmesi ayrı modellerdir. Kısmi sevkiyat, kısmi iade, ödeme iadesi, kargo etiketi ve e-belge durumu parçalı olduğundan yalnız sipariş üst durumunu taşımak yeterli değildir.

Karar çıkarımı: İki sistemde aynı siparişin işlenmesi kadar hiçbir sistemde sahiplenilmemesi de kritiktir; her açık kayıt bir operasyon sahibine atanmalıdır.

Fatura ve E-Belge Geçmişi Site Verisiyle Birlikte Taşınır mı?

Sipariş geçmişi ile yasal e-belge arşivi aynı şey değildir. Mağaza veritabanındaki fatura numarası veya PDF bağlantısı; e-Fatura, e-Arşiv ya da e-İrsaliyenin XML, zarf, durum, muhafaza ve ibraz kayıtlarının yerine geçmez. Entegrasyon yeniden yetkilendirilmeli; eski belgeler yeniden üretilmeden doğru arşivden erişilebilir kalmalıdır.

GİB'in 509 Sıra No.lu VUK Genel Tebliği'nin güncel metni e-belge oluşturma, iletim, muhafaza ve ibraz çerçevesini ayrı düzenler. Geçiş yöntemi mali müşavir, GİB/özel entegratör ve teknik ekipçe doğrulanmalıdır. Güncel hizmet seçenekleri için yeni altyapıda e-belge entegrasyonunu planlayın; hizmeti e-ticaret paketine otomatik dahil varsaymayın.

Kupon, Hediye Çeki, Sadakat Puanı ve Bakiye Nasıl Taşınır?

Kod, kalan bakiye, son kullanım tarihi, kullanım koşulu, müşteri ilişkisi ve geçmiş kullanım ayrı alanlardır. Bu varlıklar müşteriye karşı parasal veya hizmet yükümlülüğü doğurabilir. Kaynak toplamı, hedef toplamı ve müşteri bazlı örnekler mutabık olmadan yeni sistemde etkinleştirilmemeli; eski sistemde mükerrer kullanım engellenmelidir.

Karar çıkarımı: Yalnız kod adedini eşitlemek yeterli değildir; kalan değer ve kullanım kuralı finansal sonuçla birlikte test edilmelidir.

Ürün Yorumları, Favoriler, İstek Listeleri ve Sepetler Taşınmalı mı?

Taşıma kararı iş değeri, kullanıcı beklentisi, ilişki anahtarları, gizlilik ve hedef desteğine bağlıdır. Yorum sahibinin ve ürünün kimliği, tarih, puan ve moderasyon durumu korunmalıdır. Favori ve istek listeleri hesap kimliğine; aktif sepetler ise oturum, fiyat ve stok durumuna bağımlı olduğundan her zaman güvenli biçimde taşınamaz.

Aktif sepet taşınmıyorsa kullanıcı iletişimi ve geçiş sonrası kampanya değerlendirilir; ancak bozulmuş sepeti “kurtarmak” için eski fiyat veya geçersiz kupon uygulanmaz. Yorum aktarımında doğrulanmamış puan veya sahte içerik üretilmemelidir.

Yedekleme ve Geri Yükleme Testi Nasıl Yapılır?

Yedek; veritabanı, medya, uygulama ayarı, yönlendirme kuralları, entegrasyon konfigürasyonu, DNS kayıtları ve gerekli erişim materyallerini kapsar. Kopya şifreli ve ayrı konumda tutulmalı; bütünlük kontrolü ile yetkili erişim kanıtlanmalıdır. Restore provası yapılmamış yedek, geri dönüş garantisi değildir. Prova tarihli test kanıtı üretmelidir.

RPO, kaybedilmesi kabul edilebilecek veri aralığını; RTO, hizmetin geri getirileceği hedef süreyi ifade eder. Bu hedefler proje vaadi olarak değil, iş etkisi ve gerçek restore ölçümüyle belirlenmelidir. Geri yükleme provasında sipariş ilişkileri ve medya erişimi de test edilmelidir.

Tam Veri Aktarımı, Delta Aktarımı ve Veri Dondurma Nedir?

Tam aktarım mevcut kapsamın topluca taşınmasıdır. Delta aktarımı ilk kopyadan sonra değişen kayıtları yakalar. Veri dondurma penceresi kaynakta değişikliğin sınırlandığı zaman aralığıdır. Paralel çalışma iki sistemin kontrollü birlikte açık olması; dual-write ise aynı işlemin iki hedefe yazılmasıdır ve güçlü idempotency olmadan risklidir.

Karar çıkarımı: Delta kapsamına hangi nesnelerin girdiği açıkça test edilmelidir; üçüncü taraf eklenti ve özel tabloların otomatik yakalandığı varsayılmaz.

Veri Aktarımı Doğruluğu Nasıl Ölçülür?

Başarılı import mesajı veri doğruluğunu kanıtlamaz. Kayıt sayısı, alan doluluk oranı, toplam tutar, stok/bakiye toplamı, benzersiz anahtar, hash/checksum, referans ilişkileri, uç değer örnekleri ve hata logları birlikte incelenir. Aktarım yeniden çalıştırılabilir olmalı; aynı kayıtların mükerrer oluşması engellenmelidir. Bulgular sorumlu ekiplerce ayrıca imzalanmalıdır.

Karar çıkarımı: Kayıt sayısı, ilişki ve finansal toplam aynı anda doğrulanmadıkça “eksiksiz aktarım” denemez.

SEO Taşıma Planına Nereden Başlanmalıdır?

SEO taşıma planı mevcut performansın fotoğrafını çekmekle başlar. Organik tıklama, sorgu, landing page, indeks durumu, backlink alan URL, dönüşüm, crawl ve log verisi kaydedilir. Sonra eski URL envanteri ile yeni bilgi mimarisi eşleştirilir. Mevcut hatalar körlemesine taşınmamalı; değerli arama niyeti de tasarım uğruna kaybedilmemelidir.

Genel kategori, ürün ve teknik SEO ilkeleri için e-ticaret SEO rehberini kullanabilir; bu projede odağı yalnız taşıma kaynaklı URL, indeksleme ve sinyal değişikliklerinde tutabilirsiniz. Google'ın URL değişikliğiyle site taşıma rehberi mapping, yönlendirme, iç link, sitemap ve izleme adımlarını birlikte önerir.

Taşıma Öncesi SEO Baz Ölçümü Nasıl Alınır?

Baz ölçüm aynı tarih aralığı, cihaz, ülke, sayfa türü ve kanal segmentleriyle kaydedilmelidir. Mevsimsellik, kampanya, stok durumu ve analitik yapı değişikliği karşılaştırmayı bozabilir. Bu nedenle organik görünürlük ile satış kaydı ayrı sistemlerden doğrulanır; taşıma sonrası tek günlük dalgalanma yerine trend ve sayfa grubu incelenir.

Karar çıkarımı: Trafik düşüşünü ancak taşıma öncesinde aynı tanımlarla ölçülmüş bir baz varsa SEO, ölçüm veya ticari sorun olarak ayırabilirsiniz.

Eski URL Envanteri Nasıl Çıkarılır?

Yalnız XML sitemap kullanmak eksik liste üretir. Search Console performans ve sayfa raporları, analitik landing page kayıtları, sunucu/CDN logları, site crawl çıktısı, ürün-kategori-içerik veritabanı, Merchant Center, reklam final URL'leri, backlink alan sayfalar, görsel/PDF dosyaları ve parametreli URL'ler birleştirilip tekilleştirilmelidir.

Karar çıkarımı: URL envanteri veri envanterinden ayrıdır; biri web adreslerinin arama ve kullanıcı değerini, diğeri iş kayıtlarının bütünlüğünü yönetir.

Eski ve Yeni URL Eşleştirmesi Nasıl Yapılır?

URL mapping, her eski adres için içerik ve kullanıcı niyeti bakımından en yakın yeni hedefi belirler. Ürün kodu, kategori kimliği, içerik konusu ve ticari değer yalnız metin benzerliğinden daha güvenilir işaretlerdir. Bire bir, çoktan bire ve karşılıksız senaryolar ayrı kuralla ele alınır; yapay zekâ önerileri yüksek değerli URL'lerde insan onayından geçer.

Karar çıkarımı: Çoktan bire eşleştirme yalnız yeni hedef eski sayfaların ortak niyetini gerçekten karşılıyorsa makuldür; backlink varlığı alakasız hedefi meşrulaştırmaz.

301, 308, 302 ve 307 Yönlendirmeleri Arasındaki Fark Nedir?

301 ve 308 kalıcı, 302 ve 307 geçici HTTP yönlendirmeleridir. 308 ve 307 isteğin yöntemini koruma konusunda daha katı davranır; ödeme callback'i veya form uçlarında gelişi güzel kod değişimi yapılmamalıdır. Kalıcı sayfa taşımalarında mümkünse sunucu taraflı yönlendirme seçilir, geçici bakım senaryosu kalıcıymış gibi işaretlenmez. Sonuçlar loglarla düzenli izlenir.

Google'ın resmî yönlendirme dokümanı 301/308'i kalıcı, 302/307'yi geçici olarak sınıflandırır ve mümkün olduğunda sunucu taraflı yaklaşımı önerir. JavaScript veya gecikmeli meta refresh varsayılan migrasyon çözümü olmamalıdır.

Her Eski URL Ana Sayfaya Yönlendirilmeli mi?

Hayır. İlgisiz eski URL'leri topluca ana sayfaya göndermek kullanıcı niyetini bozar ve soft 404 olarak değerlendirilebilir. Aynı ürün, muadil içerik, ilgili üst kategori, arşiv sayfası veya dürüst 404/410 kararı içerik eşdeğerliğine göre verilir. “Backlink var” gerekçesi alakasız yönlendirme için tek başına yeterli değildir.

Karar çıkarımı: Yönlendirme, kullanıcıya eski isteğinin anlamlı yeni karşılığını vermelidir; ana sayfa bir “SEO değer toplama kutusu” değildir.

404, 410 ve Soft 404 Nasıl Yönetilir?

404 kaynağın bulunmadığını, 410 kaynağın kasıtlı ve kalıcı kaldırıldığını bildirir. Her kaldırılan sayfa otomatik 410 yapılmaz; içerik yaşam döngüsü ve hata nedeni incelenir. Soft 404 ise sayfanın 200 veya ilgisiz yönlendirme döndürmesine rağmen arama sistemi tarafından fiilen yok sayılmasıdır. Özel hata sayfası gerçek 404 durumunu korumalıdır.

Taşıma sonrası 404'ler log, crawl ve Search Console verisiyle “mapping eksikliği, hatalı iç link, eski dış bağlantı, normal kaldırma” gruplarına ayrılır. Kullanıcıya arama veya kategori bağlantısı sunmak HTTP durumunu 200 yapmayı gerektirmez.

Yönlendirme Zinciri ve Yönlendirme Döngüsü Nedir?

Yönlendirme zinciri eski URL'nin ara adresler üzerinden nihai hedefe gitmesidir; döngü ise kuralların birbirini tekrar çağırıp hedefe ulaşamamasıdır. HTTP/HTTPS, www, slash, büyük-küçük harf, CDN ve uygulama kuralları birlikte zincir yaratabilir. Eski URL mümkün olduğunca doğrudan son hedefe bağlanmalı ve periyodik taramalarla izlenmelidir.

En yüksek trafik ve backlinke sahip URL'ler toplu istekle test edilmeli; uygulama, reverse proxy, CDN ve web sunucusundaki çelişkili kurallar ayrı katmanlarda incelenmelidir. Döngü kullanıcının ve crawler'ın erişimini tamamen kesebilir.

Yönlendirmeler Ne Kadar Süre Korunmalıdır?

Google'ın güncel site taşıma rehberi yönlendirmeleri mümkün olduğunca uzun, genel olarak en az bir yıl korumayı önerir. Kullanıcı yer imleri, eski e-postalar, reklamlar, backlinkler ve entegrasyonlar daha uzun süre gerektirebilir. Bu öneri hukuk kuralı değildir; eski domain sahipliği, SSL ve altyapı maliyeti risk planına dahil edilir.

Search Console Change of Address bildirimlerinin 180 günlük görünümü, yönlendirmelerin genel ömrüyle aynı şey değildir. Google'ın genel site taşıma dokümanındaki en az bir yıllık yaklaşım ile aracın 180 günlük işlem penceresi ayrı takip edilmelidir.

Canonical Etiketleri Taşıma Sırasında Nasıl Güncellenir?

Canonical, benzer veya yinelenen URL'ler arasında tercih edilen adresi bildiren bir sinyaldir. Yeni sayfalar kendilerine ya da gerçekten tercih edilen yeni URL'ye canonical vermeli; staging, eski domain, HTTP veya yanlış varyanta işaret etmemelidir. Canonical, kullanıcıyı taşımadığı için 301 yönlendirmesinin bire bir yerine geçmez.

Redirect, canonical, sitemap ve iç linkler aynı hedefi göstermelidir. Ürün varyantı, filtre ve parametre sayfalarında canonical kararı ürün keşfi ve içerik eşdeğerliğiyle verilir; bütün sayfaları ana kategoriye canonical etmek otomatik çözüm değildir.

İç Linkler Taşıma Sonrasında Neden Eski URL'lere Gitmemelidir?

Menü, breadcrumb, ürün önerisi, kategori açıklaması, blog, footer, banner ve CTA bağlantıları doğrudan yeni URL'ye gitmelidir. Eski adres üzerinden yönlendirme çalışsa bile zincir, sunucu yükü ve tutarsız sinyal üretir. WYSIWYG içerikleri, e-posta şablonları ve veritabanındaki absolute URL'ler ayrıca aranmalı, bulunan kalıntılar sistematik biçimde temizlenmelidir.

Crawl doğrulaması; bozuk linkleri, eski hostları, yanlış anchor hedeflerini ve redirect üzerinden geçen iç linkleri sınıflandırır. Anchor metinleri sırf taşıma yapıldı diye topluca değiştirilmez; kullanıcı niyeti korunur.

XML Sitemap Taşıma Sonrasında Nasıl Hazırlanır?

Yeni sitemap yalnız 200 dönen, canonical ve indekslenebilir yeni URL'leri içermelidir. Eski adres, yönlendirme, 404, noindex ve staging URL'si yeni sitemap'e konmaz. Büyük kataloglarda sitemap index ve ürün, kategori, içerik ayrımı kullanılabilir; lastmod yalnız gerçek anlamlı güncellemeyi yansıtmalıdır. Dosya üretimi her dağıtım sonrasında doğrulanmalıdır.

Sitemap gönderimi indeksleme garantisi değildir. Site içi gezinme ile sitemap çelişmemeli; eski sitemap yalnız geçiş izleme stratejisinde resmî rehberle uyumlu ve geçici kullanılmalıdır.

Robots.txt ve Noindex Kontrolleri Nasıl Yapılır?

Robots.txt tarama erişimini, noindex ise sayfanın arama indeksine alınmamasını yönetir. Staging için kullanılan kural canlıya taşınırsa önemli sayfalar görünmez olabilir. Admin, hesap, sepet, checkout ve site içi arama URL'lerinde güvenlik, crawl ve indeks kararları birbirinden ayrıdır; robots.txt bir erişim güvenliği aracı değildir.

Google'ın noindex uygulama dokümanı, kuralın görülebilmesi için sayfanın robots.txt ile engellenmemesi gerektiğini açıklar. Canlıya geçişte robots.txt, meta robots ve X-Robots-Tag ayrı kontrol edilir; kritik CSS/JavaScript kaynakları yanlışlıkla kapatılmaz.

Title, Meta Description, H1 ve İçerik Eşdeğerliği Nasıl Korunur?

Yüksek değerli landing page'lerde yalnız URL değil ana konu, ürün bilgisi, kategori açıklaması, önemli kullanıcı içeriği ve arama niyeti korunmalıdır. Taşıma ile bütün başlık ve metinleri aynı anda yeniden yazmak teşhisi zorlaştırır. Eski teknik hatalar kopyalanmaz; değerli kapsam da tasarım sadeleştirmesi sırasında silinmez.

Meta description doğrudan sıralama garantisi veya “puan” gibi sunulmaz. H1, title ve içerik eşdeğerliği sayfa türü örneklemiyle karşılaştırılır; özellikle kategori ve ürün şablonlarında boş veya yinelenen değerler raporlanır.

Kategori, Filtre, Arama, Sayfalama ve Parametre URL'leri Nasıl Taşınır?

Faceted navigation, ürün listesini renk, marka veya ölçü gibi filtrelerle daraltan gezinme yapısıdır. Filtre URL üretimi, canonical, noindex, crawl erişimi ve iç link davranışı birlikte tasarlanmalıdır. Eski filtrelerin tamamını ana kategoriye yönlendirmek, belirli kullanıcı niyetini kaybedebilir. Arama, sıralama, kampanya parametresi ve sayfalama ayrı kurala ihtiyaç duyar.

Sonsuz kaydırma, botların ürünlere erişebileceği sayfalanmış bağlantılarla test edilir. Parametreler analitik, cache ve WAF kurallarıyla çakışmamalı; benzersiz değer taşımayan kombinasyonların sınırsız URL üretmesi önlenmelidir.

Yapılandırılmış Veri Taşıma Sonrasında Nasıl Doğrulanır?

Ürün, teklif, fiyat, stok, puan, breadcrumb ve kuruluş verileri yeni görünür içerikle tutarlı olmalıdır. Eski URL, yanlış para birimi, güncel olmayan availability veya kaynağı belirsiz yorum puanı yaygın migrasyon hatalarıdır. Test aracı geçerli işaretleme gösterse bile zengin sonuç görünürlüğünü garanti etmez.

HTML'de gösterilmeyen fiyat veya yorum yapılandırılmış veriye eklenmemeli; ürün kimliği Merchant Center feed'iyle uyumlu olmalıdır. Bu makale için schema üretilmemiştir; kontrol taşınan mağazanın ürün şablonuna yöneliktir.

Ürün Görselleri, PDF'ler ve Medya URL'leri Nasıl Taşınır?

Medya URL envanteri dosya adı, kaynak adres, alt metin, boyut, ürün ilişkisi, HTTP durumu ve trafik/backlink bilgisini içermelidir. CDN domaini değişiyorsa eski görsel URL'leri için koruma veya yönlendirme kararı verilir. PDF kılavuzları, kataloglar ve teknik dokümanlar ürün sayfalarından bağımsız trafik alabilir.

Kırık görsel, düşük çözünürlük, yinelenen dosya, hotlink engeli ve eksik varyant görseli örneklenir. Cache temizliği origin kapasitesini zorlayabileceği için kademeli ısıtma ve erişim testi planlanır.

Çok Dilli ve Çok Ülkeli Sitelerde Hreflang Nasıl Taşınır?

Hreflang, sayfanın dil ve bölge alternatiflerini arama sistemlerine bildiren karşılıklı işaretlemedir. Her eski dil/ülke URL'si yeni karşılığıyla eşleştirilmeli; karşılıklı referanslar, x-default ve canonical aynı mimariyi göstermelidir. Domain, subdomain veya klasör değişimi her dil için ayrı test matrisi ve yerel ekip onayı gerektirir.

Yanlış ülke kodu veya çapraz eşleşme, kullanıcıyı farklı para birimi ve stok sayfasına gönderebilir. Çeviri sayfası olmayan dil için rastgele ana sayfa hedefi üretmek yerine gerçek içerik kapsamı belgelenir.

Aynı Alan Adında Altyapı veya Hosting Değiştirirken SEO Nasıl Korunur?

URL'ler değişmiyorsa ana riskler DNS, sunucu erişimi, render, içerik eşdeğerliği, durum kodu, canonical, robots/noindex ve performanstır. Change of Address aracı kullanılmaz. Eski ve yeni sunucu geçici paralel tutulabilir; DNS yayılımı sırasında iki ortamın sipariş ve stok verisi ayrışmasın diye yazma sahipliği açıkça belirlenir.

Search Console, log ve analitik izleme sürdürülür. Aynı URL'nin yeni sistemde 200 yerine 404/5xx döndürmesi veya JavaScript nedeniyle temel içeriği üretmemesi, adres değişmese bile organik risk yaratır.

Alan Adı Değişikliğinde Search Console Change of Address Nasıl Kullanılır?

Change of Address, desteklenen alan veya subdomain değişikliğini Google'a bildiren araçtır. Eski ve yeni mülk sahipliği doğrulanmalı, bire bir kalıcı yönlendirmeler kurulmalı ve yeni domain erişilebilir olmalıdır. Araç yönlendirme yerine geçen sihirli düğme değildir; site taşındıktan ve ön kontroller tamamlandıktan sonra kullanılır.

Search Console Change of Address yardımına göre aynı domain içindeki path değişikliği, yalnız hosting/CDN geçişi, HTTP'den HTTPS'e veya www/non-www değişimi için araç kullanılmaz. 180 günlük bildirim penceresi, genel en az bir yıllık redirect tavsiyesiyle karıştırılmamalıdır.

Search Console Taşıma Öncesi ve Sonrası Nasıl Kullanılır?

Eski ve gerekiyorsa yeni property önceden doğrulanır; sitemap, URL Inspection örnekleri, sayfa indeksleme, performans ve crawl istatistikleri izlenir. Domain property ile URL-prefix kapsamı ihtiyaca göre seçilir. Yüksek değerli URL'lerde canlı test yapılır; güvenlik ve manuel işlem bildirimleri düzenli aralıklarla kontrol edilir.

Search Console verisi gecikmeli olabilir. Tek günlük değişimle rollback kararı verilmez; sunucu logları, analitik, sipariş ve durum kodu verileriyle birlikte değerlendirilir.

Merchant Center ve Ürün Feed'leri Nasıl Güncellenir?

Ürün linki, mobil link, görsel linki, fiyat, stok ve landing page aynı ürünü ve güncel değeri göstermelidir. Domain değişiyorsa mağaza URL'sinin yeniden doğrulanması veya claim durumunun güncellenmesi gerekebilir. Feed URL'si, otomatik güncelleme, kargo/iade bilgileri ve politika sayfaları test edilir; redirect zincirine güvenilmez.

Google'ın Merchant Center mağaza URL doğrulama rehberi doğrulama ve claim işlemlerini açıklar. Feed onayı veya reklam yayını garanti değildir; “Needs attention” ve ürün reddi kayıtları geçiş sonrası yakından izlenmelidir.

Reklam Kampanyaları ve Açılış Sayfaları Taşıma Sonrasında Nasıl Kontrol Edilir?

Arama, görüntülü, sosyal ve yeniden pazarlama kampanyalarının final URL, UTM, tracking template, ürün seti ve katalog bağlantıları güncellenmelidir. Yönlendirme çalışsa bile doğrudan yeni hedef, gecikmeyi ve zinciri azaltır. Ölçüm doğrulanmadan bütçeyi kontrolsüz artırmak, teknik sorunu ticari dalgalanmayla karıştırabilir. Kritik kampanyalar ayrı ayrı onaylanmalıdır.

Reklam onayı ve politika denetimi sağlayıcıya göre değişir. Yüksek harcamalı açılış sayfaları geçiş runbook'unda öncelikli smoke test grubuna alınmalıdır.

GA4, Tag Manager, Pikseller ve Dönüşüm Olayları Nasıl Taşınır?

Page view, view item, add to cart, begin checkout, purchase ve refund olaylarında ad, parametre, ürün kimliği, para birimi, değer ve transaction ID tutarlı olmalıdır. Çift tag, çift purchase, eksik consent, cross-domain ve referral hataları test edilir. Etiketin tetiklenmesi tek başına doğru ticari ölçüm değildir.

Test siparişi işaretlenir; gerçek zamanlı/debug sonucu sipariş ve ödeme kaydıyla karşılaştırılır. Eski ve yeni sistem paralelken aynı transaction ID'nin iki kez raporlanması önlenir.

Çerez Onayı ve Gizlilik Tercihleri Yeni Sisteme Nasıl Taşınır?

Onay yönetimi yeni domain ve şablonda çalışmalı; kullanıcının izin/ret tercihlerinin teknik ve hukuki olarak hangi koşullarda korunabildiği doğrulanmalıdır. Varsayılan izin, consent state kaybı veya onaydan önce pazarlama etiketi çalışması riskleri test edilir. Gizlilik, aydınlatma ve çerez metinleri gerçek veri akışıyla uyumlu olmalıdır.

Hukuk ve KVKK sorumlusu değerlendirmesi gerekir. Teknik cookie kopyası otomatik olarak geçerli hukukî dayanak oluşturmaz; domain değişimi ve sağlayıcı değişikliği ayrıca incelenir.

Staging Ortamı Nasıl Güvenli Kurulmalıdır?

Staging, canlı öncesi test ortamıdır ve parola/IP erişimi, arama motoru engeli, maskelenmiş veri, test ödeme bilgileri ve izole entegrasyonlarla korunmalıdır. E-posta/SMS sandbox'a alınır, ERP ve webhook hedefleri ayrılır, debug loglarında kişisel veri bırakılmaz. Gerçek müşteri verisi kullanımı istisna ve yetkiyle sınırlandırılmalıdır.

Canlı sayfalar staging'e, staging sayfalar da canlıya yanlış canonical vermemelidir. Noindex ve robots kuralları canlı konfigürasyona kopyalanmadan önce fark kontrolüyle kaldırılmalıdır.

Entegrasyon Envanteri Nasıl Hazırlanır?

Entegrasyon envanteri her bağlantının iş ve teknik sahibini, veri yönünü, kimlik doğrulamasını, endpoint/webhook adresini, çalışma sıklığını, kritik verisini, testini ve rollback etkisini kaydeder. ERP, muhasebe, PIM/WMS, e-belge, ödeme, kargo, pazaryeri, CRM, iletişim, sadakat, analitik, fraud ve özel dosya akışları eksiksiz listelenmelidir.

Karar çıkarımı: Bağlantı “var” demek yetmez; hangi hata senaryosunda yeniden deneyeceği ve çift işlem üretmeyeceği kanıtlanmalıdır.

ERP ve Muhasebe Entegrasyonları Taşıma Sırasında Nasıl Yönetilir?

Ürün, stok, fiyat, cari, sipariş, fatura ve iade için ana kaynak ayrı belirlenir. Eski ve yeni mağazanın aynı siparişi ERP'ye yazması engellenir. Kod, durum, depo, vergi ve para birimi eşleştirmesi test edilir; queue, retry, timeout ve hata kuyruğu izlenir. Ayrıntılı ERP mimarisinden çok migrasyon sahipliği önemlidir.

Mutabakat raporu, kaynak sipariş ID'si ile ERP belgesi ve hedef sipariş ID'sini bağlamalıdır. Cutover anında eski connector'ın ne zaman durduğu ve yeni connector'ın hangi checkpoint'ten başladığı runbook'a yazılır.

Sanal POS ve Ödeme Entegrasyonu Nasıl Taşınır?

Yeni domain, callback/return URL, webhook, IP izin listesi, sertifika ve API anahtarları ödeme kuruluşuyla doğrulanmalıdır. Başarılı, başarısız, 3D Secure, timeout, iptal, tam/kısmi iade ve tekrar deneme senaryoları test edilir. Test ve canlı anahtarlar ayrılır; ödeme sonucu ile sipariş ve stok durumu tutarlı olmalıdır.

Kart numarası ve CVV genel aktarım dosyasına konmaz. Kayıtlı kart veya ödeme tokenı sağlayıcıya, token kasasına, sözleşmeye, teknik yönteme ve gerekebilecek müşteri onayına bağlıdır. Domain ve checkout hazırlığı için sanal POS öncesi site gereksinimlerini ayrıca kontrol edin.

e-Fatura, e-Arşiv ve e-İrsaliye Entegrasyonları Nasıl Devam Ettirilir?

Site siparişi, ERP/muhasebe kaydı ve e-belge üretimi ayrı katmanlardır. Test ve canlı mükellef bilgisi, belge senaryosu, numaratör, vergi alanı, sipariş referansı ve hata kuyruğu doğrulanır. Açık siparişlerin belgesini hangi sistemin oluşturacağı belirlenir; aynı işlem için ikinci belge üretimi engellenir.

İptal/iade senaryosu ve belge görüntüleme uçtan uca test edilir. Eski e-belge arşivinin yalnız yeni site veritabanına sipariş kopyalamakla korunmadığı; muhafaza ve ibraz sorumluluğunun mali uzman ve sağlayıcıyla doğrulanacağı kayda alınır.

Kargo ve Lojistik Entegrasyonları Nasıl Test Edilir?

İl/ilçe/mahalle, adres, desi, hizmet kodu ve gönderi tipi eşleştirilir. Barkod/etiket, takip numarası, durum callback'i, iptal ve iade kargo akışları test edilir; aynı siparişe iki etiket üretilmesi önlenir. Geçiş günündeki açık paketlerin eski mi yeni sistemden mi yönetileceği runbook'ta yazmalıdır.

Yeni uygulama veya müşteri kodu gereksinimi kargo sağlayıcısıyla doğrulanır. Anlaşma ve operasyon ayrıntıları için e-ticaret kargo anlaşması rehberi bağlam sağlar; migrasyonda odak teknik yetkilendirme ve açık gönderi sahipliğidir.

Pazaryeri Entegrasyonları Nasıl Yeniden Doğrulanır?

Ürün, stok, fiyat, sipariş, fatura, kargo ve iade akışları ayrı ayrı test edilmelidir. API yetkisi, mağaza hesabı, webhook ve ürün eşleştirmesi doğrulanır; SKU ile pazaryeri ürün kimliği ilişkisi korunur. Geçiş penceresinde iki sistemin aynı stok/fiyatı yazmasına izin verilmez, açık sipariş için tek sorumlu belirlenir.

Pazaryerinden kendi markalı siteye genişleyen işletmeler kanal bağımlılığından markalı e-ticarete geçiş içeriğini stratejik bağlam için kullanabilir. Bu bölüm komisyon/hakediş mutabakatı değil, teknik ve operasyonel süreklilik kapsamındadır.

CRM, E-Posta, SMS ve Sadakat Sistemleri Nasıl Taşınır?

Müşteri kimliği, izin/ret, segment, sipariş geçmişi ve yaşam döngüsü olayları eşleştirilir. Hoş geldiniz, aktivasyon, parola sıfırlama, sipariş, kargo ve terk edilmiş sepet otomasyonları test edilir. Eski ve yeni otomasyonların aynı anda çalışıp çift mesaj göndermemesi için gönderimler kademeli açılır.

Kupon ve sadakat bakiyeleri finansal mutabakat tamamlanmadan aktif edilmez. Yanlış toplu iletiyi önlemek için gerçek gönderim kanalları staging'de kapatılır; şablonların eski domain veya bozuk bağlantı içermediği doğrulanır.

API Anahtarları, Webhook'lar, IP İzinleri ve Zamanlanmış Görevler Nasıl Yönetilir?

Her secret ve teknik hesabın sahibi belirlenir; staging ile production kimlikleri ayrılır. Secret'lar kaynak kod, TXT/CSV, log veya görev metnine yazılmaz. Yeni endpoint, DNS ve sertifika test edilir; webhook imzası, retry ve sıra dışı teslimat davranışı doğrulanır. Cron ve queue görevlerinin iki ortamda eşzamanlı çalışması engellenir.

Canlı kabulden sonra eski ve ortak anahtarlar kontrollü iptal edilir; IP allowlist ve erişim kayıtları gözden geçirilir. İptal sırası rollback penceresini bozmayacak şekilde planlanır.

Idempotency, Retry ve Çift İşlem Riski Nedir?

Idempotency, aynı isteğin tekrar gelmesi hâlinde sonucun ikinci kez oluşturulmamasıdır. Ödeme, sipariş, stok veya fatura mesajı ağ hatası nedeniyle yeniden gönderilebilir. Mesaj kimliği, transaction ID, sipariş numarası ve benzersiz anahtarlarla çift kayıt engellenir. Retry sınırsız çalışmamalı; gecikme, deneme sayısı ve hata kuyruğu tanımlanmalı, alarm eşikleri ayrıca belgelenmelidir.

Dead-letter/error queue çözülemeyen mesajları manuel inceleme için ayırır. Teknik uygulama platforma göre değişir; kabul testinde aynı webhook'un tekrar gönderildiği senaryo mutlaka bulunmalıdır.

Taşıma Öncesi Test Planı Nasıl Hazırlanır?

Test planı veri, SEO, içerik, müşteri hesabı, sepet, ödeme, sipariş, stok, belge, kargo, pazaryeri, analitik, güvenlik, performans, mobil, erişilebilirlik, entegrasyon ve rollback alanlarını kapsar. Her senaryonun ön koşulu, beklenen sonucu, kanıtı, sahibi, kritiklik derecesi ve tekrar test durumu bulunur. Kapsam değiştikçe plan sürüm kontrollü güncellenir.

Karar çıkarımı: Test matrisi yalnız “geçti/kaldı” tablosu değil, go/no-go kararının kanıt dosyasıdır.

UAT ve Kabul Kriterleri Nedir?

UAT, gerçek iş kullanıcılarının sistemin iş gereksinimini karşıladığını doğruladığı kullanıcı kabul testidir. Operasyon, depo, müşteri hizmetleri, finans ve pazarlama ekipleri gerçek senaryoları çalıştırmalıdır. “Sayfa açılıyor” teknik kontrolü, siparişin doğru stok düşüp belge ve kargo akışına ulaşmasını kanıtlamaz. Kabul kararı yazılı kanıta dayanmalıdır.

Kritik, yüksek, orta ve düşük hata sınıfları tanımlanır. Çift tahsilat riski, kişisel veri sızıntısı, açık sipariş kaybı, canlı noindex veya geri dönüş imkânsızlığı bloker olabilir; küçük görsel hizalama aynı ağırlıkta değerlendirilmez.

Test Siparişi Hangi Senaryoları Kapsamalıdır?

Test siparişi misafir ve üye alışverişi, yeni hesap, parola sıfırlama, varyant, son stok, kupon, ücretsiz kargo, gerekli para birimi/KDV, başarılı ve başarısız ödeme, 3D dönüşü, alternatif ödeme, iptal, tam/kısmi iade, e-belge, kargo, bildirim, purchase olayı ve mutabakatı kapsamalıdır.

Test kayıtları gerçek rapor, muhasebe ve müşteri iletişimini kirletmeyecek biçimde işaretlenir veya onaylı prosedürle temizlenir. Her testin sipariş, ödeme, stok, belge ve analitik kimlikleri tek kanıt paketinde bağlanır.

Performans ve Kapasite Taşıma Öncesinde Nasıl Test Edilir?

Ana sayfa, kategori, ürün, arama, sepet, checkout ve hesap şablonları ayrı ölçülür. TTFB sunucu yanıt başlangıcını; LCP büyük içeriğin görünme süresini; INP etkileşim yanıtını; CLS görsel kaymayı ölçer. API süresi, hata oranı ve checkout süresi de katalog ve eşzamanlı kullanıcı yüküyle test edilmelidir.

Laboratuvar testi ile gerçek kullanıcı alan verisi aynı değildir. Yük testi üretim müşterisini veya üçüncü tarafı etkilememeli; eski ve yeni ortam aynı koşullarda karşılaştırılmalıdır. Googlebot'un taşıma sonrası artabilecek tarama yükü kapasite planına eklenir.

Güvenlik Testlerinde Neler Kontrol Edilmelidir?

Yetkilendirme, rol izolasyonu, yönetim paneli, parola sıfırlama, oturum/cookie, dosya yükleme, API/webhook doğrulaması, secret yönetimi, kişisel veri sızıntısı, log maskeleme, yedek erişimi, rate limit ve bağımlılık yapılandırmaları incelenir. SSL veya WAF tek başına güvenlik garantisi değildir; otomatik tarama da yetkin incelemenin yerini tutmaz.

OWASP Top 10:2025 risk temelli test kapsamı için resmî bir başlangıç sağlar. Sonuçlar yetkin güvenlik ekibi tarafından iş etkisiyle önceliklendirilmelidir.

Mobil ve Erişilebilirlik Testi Neden Taşıma Kapsamındadır?

Yeni tema teknik olarak çalışırken mobil menü, ürün galerisi, varyant seçimi, form hatası veya checkout kullanılamaz hâle gelebilir. Klavye erişimi, odak sırası, ekran okuyucu etiketleri, kontrast ve hata mesajları gerçek cihaz, tarayıcı ve ağ çeşitliliğinde test edilmelidir. Erişilebilirlik yalnız görsel kontrol değildir.

Uyumluluk sertifikası veya kusursuzluk garantisi verilmez. Kritik satın alma ve hesap akışları işlevsel testle birlikte kullanıcı deneyimi açısından doğrulanır.

Canlıya Geçiş Runbook'u Nasıl Hazırlanır?

Runbook, cutover yani kontrollü canlıya geçiş sırasında kimin ne zaman hangi işlemi yapacağını, ön koşulu, kanıtı, başarısızlık aksiyonunu ve geri dönüş noktasını zaman sırasıyla tanımlar. Sözlü plan yeterli değildir; son yedekten hypercare başlangıcına kadar tüm kritik adımlar saat ve karar sahibiyle yazılmalıdır.

Karar çıkarımı: Runbook her adımın yalnız ideal yolunu değil, başarısızlık hâlinde durma ve geri dönüş davranışını da içerir.

DNS, TTL, SSL, CDN ve WAF Geçişi Nasıl Planlanır?

DNS TTL, kaydın önbellekte ne kadar tutulacağını belirler; değer mevcut sağlayıcı ve iş sürekliliği planıyla doğrulanmadan körlemesine düşürülmez. A/AAAA, CNAME, nameserver ve doğrulama kayıtları envantere alınır. SSL sertifikası tüm gerekli domain/subdomainleri kapsamalı; CDN origin, cache, header, bot ve WAF kuralları test edilmelidir.

DNS değişimi herkeste aynı anda görünmeyebilir. Eski ve yeni origin paralelken sipariş veya stok verisinin ayrışması, web erişiminden daha ciddi rollback sorunudur. Eski origin doğrudan erişime açık kalıyorsa güvenlik sınırları korunur.

Alan Adı Değişikliği E-Posta Teslimatını Nasıl Etkiler?

MX posta alımını; SPF yetkili göndericileri; DKIM imzayı; DMARC ise kimlik doğrulama politikasını ve raporlamayı destekler. Yeni domain ve gönderici adresleri e-posta sağlayıcısında doğrulanmalı; parola sıfırlama, sipariş ve fatura bildirimleri teslimat açısından test edilmelidir. Web DNS değişikliği e-posta kayıtlarını yanlışlıkla silmemelidir.

Eski domain adreslerine gelen kritik ileti için geçiş planı oluşturulur. Şablonlar, linkler, reply-to ve destek adresleri güncellenir; spam/ret sonuçları hypercare dashboard'una eklenir.

Go/No-Go Kararı Hangi Ölçütlerle Verilir?

Go/no-go, canlıya devam veya durma kararını ölçülebilir kanıtlarla verir. Yüksek değerli URL hatası, ödeme alınamaması, çift çekim riski, stok/fiyat farkı, açık sipariş kaybı, veri sızıntısı, e-belge/kargo kesintisi, çift purchase, noindex ve geri dönüş imkânsızlığı canlıya çıkışı engelleyebilir.

Karar çıkarımı: Küçük görsel kusur ertelenebilir; finansal, veri veya güvenlik hatası “sonra düzeltiriz” sınıfına alınmamalıdır.

Rollback Planı Nedir ve Ne Zaman Kullanılır?

Rollback, eski sisteme veya güvenli önceki duruma kontrollü geri dönüştür. DNS'i geri çevirmek veri geri dönüşü değildir; yeni sistemde oluşan müşteri, sipariş ve ödeme kayıtlarının nasıl korunacağı önceden çözülmelidir. Tetikleyici, eşik, karar yetkisi ve maksimum karar süresi yazılır; eski sistemin aktif veya salt okunur durumu belirlenir.

Karar çıkarımı: Rollback provasız bir vaat değil, yeni yazılan veriyi de yöneten ikinci bir cutover senaryosudur.

Canlıya Geçiş Anında Hangi Smoke Testler Yapılmalıdır?

Smoke test, canlı sistemin kritik yollarının ayakta olduğunu hızlı doğrular; tam UAT'nin yerine geçmez. Ana domain/HTTPS, host politikası, ana sayfa, kategori, ürün, arama, giriş, parola, sepet, checkout, ödeme, sipariş, stok, e-belge, kargo, entegrasyon, bildirim, analitik, redirect, canonical, robots/noindex, sitemap, 404, mobil ve yönetim paneli sırayla test edilir.

Her kontrolün sonucu zaman damgası ve kanıtla kaydedilir. Hata logları, queue ve üçüncü taraf dashboardları kullanıcı ekranıyla birlikte izlenir.

İlk 24 Saatte Neler İzlenmelidir?

İlk 24 saat hypercare dönemidir: 4xx/5xx, uygulama ve entegrasyon hataları, ödeme dağılımı, sipariş sayısı/toplamı, stok-fiyat, e-belge/kargo kuyruğu, giriş/parola sorunu, redirect/crawl logu, analitik olay, kapasite ve destek bildirimleri birlikte izlenir. Tek dashboard, nöbetçi sorumlular ve eskalasyon kanalı hazırlanmalıdır.

Tek bir veri kaynağına güvenilmez. Analitikte sipariş düşerken ödeme ve ERP kayıtları sabitse önce ölçüm; bütün sistemlerde düşüş varsa erişim, checkout, kampanya ve mevsimsellik incelenir.

İlk 7, 30 ve 90 Günde Hangi Kontroller Yapılmalıdır?

İzleme dönemi teknik yangın söndürmeden kalıcı optimizasyona doğru ilerler. İlk hafta crawl ve operasyon hataları, ilk ay landing page ve ölçüm trendi, ilk üç ay kalıcı 404, eski sistem, erişim ve maliyet kararları ele alınır. Sabit bir “SEO toparlanma günü” vaat edilmez; site büyüklüğü ve değişim kapsamı sonucu etkiler.

Karar çıkarımı: Eski sistem ancak kabul, arşiv ve yönlendirme bağımlılıkları doğrulandıktan sonra kapatılır.

Taşıma Sonrası Trafik veya Satış Düşerse Kök Neden Nasıl Bulunur?

Korelasyon neden değildir. Baz tarih, mevsimsellik, kampanya, stok ve ölçüm değişimi kontrol edilir; sonra belirti SEO, ölçüm, teknik ve operasyon kanıtlarıyla ayrıştırılır. Aynı anda Search Console, analitik, ödeme/sipariş, log ve ürün feed'i verisine bakmak, tek araçtan yapılan acele yorumları azaltır.

Karar çıkarımı: Önce “gerçek satış mı düştü, yalnız ölçüm mü?” sorusu cevaplanmalı; sonra kanal ve sayfa türü düzeyine inilmelidir.

Taşıma Sonrası Eski Sistem Ne Zaman Kapatılmalıdır?

Yasal/operasyonel arşiv, açık sipariş/iade, finans mutabakatı, destek erişimi, restore edilebilir yedek ve redirect bağımlılığı doğrulanmadan eski sistem kapatılmaz. Uygulamanın kendisi kapansa bile yönlendirmeler CDN veya web sunucusunda sürebilir. Salt okunur arşiv, güvenlik ve maliyet açısından kontrollü bir ara model olabilir.

Saklama ve imha süreleri hukuk, mali müşavir ve KVKK süreç sahibiyle doğrulanır. Eski sistemi erken kapatmak rollback ve kanıt kaybı; gereksiz uzun açık tutmak maliyet, yetkisiz erişim ve yamalanmamış güvenlik riski doğurur.

Yapay Zekâ E-Ticaret Sitesi Taşımada Nasıl Kullanılabilir?

Yapay zekâ URL benzerliği, ürün/kategori sınıflandırma, alan eşleştirme adayı, yinelenen kayıt, eksik veri, log kümeleme, test taslağı ve içerik fark analizi için yardımcı olabilir. Nihai redirect, veri silme, finansal bakiye veya güvenlik kararı vermemelidir. Eşik, örnekleme, insan onayı ve geri alınabilirlik zorunludur.

Müşteri, sipariş, ödeme, cari ve ticari sır verileri yetkisiz genel amaçlı AI sistemlerine yüklenmemelidir. Güvenli kullanım çerçevesini derinleştirmek için yapay zekâ destekli e-ticaret yaklaşımını; içerik ve URL tutarlılığının cevap motorlarına etkisi için yapay zekâ aramalarında görünürlük rehberini inceleyebilirsiniz.

E-Ticaret Sitesi Taşıma Maliyeti Hangi Kalemlerden Oluşur?

Taşıma maliyeti lisans fiyatından daha geniştir: veri çıkarma/temizleme, mapping/import, SEO, tema, özel geliştirme, entegrasyon, test, çift çalışma, hosting/CDN/WAF, eğitim, canlı destek, arşiv ve iç ekip zamanı hesaba katılır. Ürün, müşteri, sipariş, varyant, medya, URL, dil, trafik ve zaman kısıtı maliyeti değiştirir; kesin fiyat keşifsiz verilemez.

Karar çıkarımı: SoloCommerce paket maliyeti ile migrasyon projesi maliyeti aynı değildir; standart ürün, özel iş ve üçüncü taraf gideri ayrı teklif kalemleri olmalıdır.

E-Ticaret Sitesi Taşıma Projesi Ne Kadar Sürer?

Tek bir süre yoktur. Keşif, veri temizliği, geliştirme, deneme aktarımı, ikinci prova, UAT, delta, canlı geçiş ve hypercare aşamalarının süresi veri kalitesi, API erişimi, özel entegrasyon, domain değişimi, içerik hacmi, ekip kapasitesi ve onay gecikmesine bağlıdır. Hızlı görünmek için provayı atlamak kontrollü geçiş değildir.

Küçük katalog ve az entegrasyon daha kısa; çoklu dil, yüksek sipariş geçmişi, özel fiyat/stok ve ödeme tokenı daha karmaşık olabilir. Her takvim varsayım, bağımlılık, blackout dönemi ve kabul kriterleriyle birlikte planlanmalıdır; teklif veya kesintisizlik garantisi sayılmaz.

Yeni E-Ticaret Altyapısı Seçerken Taşınabilirlik İçin Neler Sorulmalıdır?

Yeni platform yalnız bugünkü işlevle değil, gelecekte veri çıkarma ve geçiş kolaylığıyla değerlendirilmelidir. Ürün, müşteri ve sipariş exportu; API/webhook; veri sahipliği; özel alan; URL/redirect; canonical/sitemap/robots; parola ve ödeme bağımlılığı; staging, log, yedek/restore, güvenlik, SLA ve çıkış koşulları kanıtla sorulmalıdır.

Veri hacmi ve entegrasyona göre SoloCommerce paket seçimini incelerken taşınabilirlik ve operasyon kapsamı sunan e-ticaret altyapısı seçeneklerini güncel canlı sayfadan karşılaştırın; özel migrasyon işlerini standart paket varsaymayın.

SoloCommerce'e Geçiş Hangi İhtiyaçlarda Değerlendirilebilir?

SoloCommerce; markalı mağaza, ürün/kategori/varyant, tema/sayfa, sepet/checkout, fiyat/set ürün ve blog/SEO temeli arayan işletmelerce değerlendirilebilir. 14.07.2026 tarihli paket sayfasında büyüme seviyesinde pazaryeri görünürlüğü; profesyonelde cari, tahsilat, satış belgesi ve stok/depo görünürlüğü; Enterprise'ta özel entegrasyon, SLA ve proje bazlı kurulum belirtilmektedir.

E-Fatura/e-Arşiv seçenekleri opsiyonel veya teklif kapsamındadır. Eski platformdan veri çıkarma, geçmiş sipariş/müşteri/parola/yorum aktarımı, URL mapping, tema uyarlaması, ödeme tokenı, ERP migrasyonu ve özel cutover her pakete otomatik dahil kabul edilmemelidir. işletmenize uygun e-ticaret paketini karşılaştırın; veri örneği, entegrasyon envanteri ve kabul kriterleriyle özel proje kapsamını ayrıca isteyin.

SoloCommerce Taşıma Projesi İçin Hangi Bilgiler Hazırlanmalıdır?

Keşif öncesi hazırlanan somut envanter kapsam ve maliyet belirsizliğini azaltır; otomatik teklif veya sorunsuz geçiş garantisi vermez. Mevcut platform/hosting, domain ve URL yapısı, veri hacimleri, açık işlemler, SEO öncelikleri, entegrasyonlar, iş kuralları, hedef tarih, UAT ekibi ve rollback beklentisi birlikte paylaşılmalıdır.

• Mevcut platform, hosting, domain/subdomain ve URL örneklerini hazırlayın.
• Ürün, kategori, varyant, müşteri, sipariş, açık sipariş/iade ve medya sayılarını çıkarın.
• Çoklu dil, para birimi, özel alan, B2B/cari/rol ve kampanya kurallarını belgeleyin.
• ERP, muhasebe, e-belge, ödeme, kargo, pazaryeri, CRM, analitik ve reklam envanterini ekleyin.
• Eski sistemin export/API örnekleri ile parola, token ve veri çıkış kısıtlarını gösterin.
• Hedef tarih, blackout dönemi, UAT ekibi, güvenlik/yasal gereksinim ve başarı eşiklerini yazın.
• Rollback için RPO/RTO beklentisini, eski sistemin tutulma süresini ve karar yetkisini açıklayın.

Hazırlık tamamlandığında kontrollü geçiş için e-ticaret paketi seçeneklerini standart kapsam ve özel proje ayrımıyla değerlendirmek daha sağlıklı olur.

E-Ticaret Sitesi Taşıma Kontrol Listesi

Aşağıdaki 155 madde keşiften 90 günlük izlemeye kadar proje planına dönüştürülebilir. Her maddeye sorumlu, son tarih, kanıt ve durum alanı ekleyin. Kontrol listesi bütün işletmeler için aynı teknik reçete değildir; veri hacmi, mevzuat, entegrasyon ve risk düzeyine göre uzman ekip tarafından uyarlanmalıdır.

1. İş gerekçesi ve kapsam

• Belgele taşınmayı tetikleyen ölçülmüş iş sorununu ve beklenen sonucu.
• Ayır kapsam içi, kapsam dışı ve sonraki faz gereksinimlerini.
• Karşılaştır mevcut altyapıda iyileştirme maliyetini taşıma maliyetiyle.
• Tanımla değişecek domain, URL, tasarım, veri ve entegrasyon alanlarını.
• Onayla başarı kriterlerini ve kabul edilebilir sapmaları sponsorla.

2. Ekip, sorumluluk ve iletişim

• Ata proje sponsoru, yöneticisi ve teknik karar sahibini.
• Oluştur SEO, veri, operasyon, finans ve güvenlik RACI matrisini.
• Belirle go/no-go ve rollback karar yetkilerini.
• Yayınla acil iletişim, nöbet ve eskalasyon listesini.
• Planla müşteri, tedarikçi ve iç ekip bilgilendirme zamanlarını.

3. Mevcut sistem envanteri

• Listele domain, subdomain, DNS, hosting, CDN, WAF ve sertifikaları.
• Kaydet uygulama, veritabanı, medya deposu, tema ve özel kodları.
• Say ürün, varyant, müşteri, sipariş, medya ve URL hacimlerini.
• Envanterle eklenti, modül, cron, queue, API ve webhook'ları.
• Eşleştir kullanıcı rolleri, yönetim hesapları ve erişim sahiplerini.

4. Veri sahipliği ve kaynak sistem

• Belirle her veri türü için source of truth sistemini.
• Ata ürün, stok, fiyat, sipariş ve belge mutabakat sahiplerini.
• Çiz veri akış yönlerini ve yazma yetkilerini.
• Çöz aynı alanın sistemler arasındaki mevcut farklarını.
• Dondur geçiş anındaki tek yazıcı kuralını karar kaydında.

5. Veri temizliği

• Tekilleştir mükerrer ürün ve müşteri kayıtlarını onaylı kuralla.
• Tamamla eksik SKU, barkod, kategori ve zorunlu alanları.
• Sınıflandır geçersiz iletişim, eski hesap ve bozuk adresleri.
• Arındır süresi dolmuş kampanya ve kullanılmayan özel alanları.
• Kaydet silme, birleştirme ve düzeltme kararlarının denetim izini.

6. Ürün, kategori ve varyant

• Eşleştir eski ve yeni ürün kimliklerini kalıcı mapping tablosunda.
• Doğrula kategori ağacı, marka ve ürün ilişkilerini.
• Koruma altına al varyant SKU, barkod, görsel ve stok bağlarını.
• Test et set ürün, tamamlayıcı ürün ve teknik özellik dönüşümlerini.
• Örnekle aktif, pasif, stok dışı ve çok varyantlı ürünleri.

7. Fiyat, stok ve kampanya

• Mutabıklaştır liste, indirimli, müşteri grubu ve kampanya fiyatlarını.
• Onaylat KDV, para birimi, kur ve yuvarlama kurallarını finans ekibine.
• Ayır toplam stok, rezervasyon, depo ve satışa açık miktarı.
• Engelle iki sistemin aynı anda stok veya fiyat yazmasını.
• Planla son stok/fiyat deltasını ve kampanya açılış sırasını.

8. Müşteri, adres ve parola

• Sınırlandır taşınacak müşteri alanlarını amaç ve gereklilikle.
• Tekilleştir aynı e-posta veya telefonla açılmış hesapları.
• Eşleştir müşteri, şirket, adres ve kullanıcı ilişkilerini.
• Kararlaştır hash geçişi, just-in-time, aktivasyon veya sıfırlama yöntemini.
• Prova et parola iletişimi, token süresi ve destek senaryosunu.

9. Sipariş, iade ve finansal bakiye

• Ayır geçmiş, açık, kısmi sevkli, iadeli ve iptal siparişleri.
• Ata her açık işlemin eski veya yeni sistem sahibini.
• Koruma altına al işlem anındaki fiyat, vergi ve indirim görüntüsünü.
• Mutabıklaştır kupon, hediye çeki, sadakat ve müşteri bakiyelerini.
• Önle aynı iade, tahsilat veya sevkiyatın iki kez işlenmesini.

10. Yedek ve restore

• Yedekle veritabanı, medya, ayar, redirect ve entegrasyon konfigürasyonunu.
• Şifrele yedekleri ve erişimi en az ayrıcalıkla sınırla.
• Doğrula yedek bütünlüğünü hash veya araç raporuyla.
• Geri yükle temsili ortamda ve kritik iş ilişkilerini test et.
• Ölç gerçek restore süresini RPO/RTO planına kaydet.

11. Tam ve delta aktarım

• Çalıştır en az bir tam deneme aktarımı üretim kopyası olmayan güvenli ortamda.
• Belirle delta kapsamına giren nesne ve değişiklik kaynaklarını.
• Kaydet her delta çalışmasının checkpoint ve zaman damgasını.
• Test et aktarımı yeniden çalıştırınca mükerrer kayıt oluşmadığını.
• Tanımla veri dondurma penceresi ve izin verilen faaliyetleri.

12. SEO baz ölçümü

• Dışa aktar organik tıklama, gösterim, sorgu ve landing page verisini.
• Kaydet indeks, 404, 5xx, crawl ve Core Web Vitals bazını.
• Listele backlink alan ve dönüşüm getiren yüksek değerli URL'leri.
• Segmentle ürün, kategori, blog, cihaz ve ülke performansını.
• Not et mevsimsellik, kampanya ve stok etkilerini karşılaştırma dosyasına.

13. URL envanteri ve mapping

• Birleştir sitemap, Search Console, analitik, log, crawl ve veritabanı URL'lerini.
• Tekilleştir protokol, host, slash ve parametre varyasyonlarını.
• Sınıflandır URL'leri sayfa türü, trafik, backlink ve indeks durumuyla.
• Eşleştir her değerli eski URL'yi en yakın yeni niyetle.
• Onaylat kritik ve yapay zekâ önerili mapping'leri insan ekiplerine.

14. Redirect ve canonical

• Uygula kalıcı değişikliklerde sunucu taraflı 301 veya uygun 308'i.
• Yönlendir eski URL'yi doğrudan nihai hedefe.
• Temizle redirect zinciri, döngü ve çelişkili proxy kurallarını.
• Yaz yeni sayfalara doğru self-referencing canonical değerlerini.
• Reddet ilgisiz toplu ana sayfa yönlendirmelerini.

15. Sitemap, robots ve noindex

• Üret yalnız 200, canonical ve indekslenebilir URL'lerden yeni sitemap'i.
• Çıkar redirect, 404, noindex ve staging adreslerini sitemap'ten.
• İncele canlı robots.txt kurallarını staging farkıyla.
• Kaldır ürün ve kategori şablonlarındaki istenmeyen noindex'i.
• Doğrula X-Robots-Tag ve meta robots değerlerini ayrı ayrı.

16. İçerik, yapılandırılmış veri ve medya

• Karşılaştır title, H1, ana içerik ve metadata eşdeğerliğini.
• Güncelle menü, breadcrumb, blog, banner ve CTA iç linklerini.
• Doğrula ürün fiyatı, stok ve yapılandırılmış veri tutarlılığını.
• Taşı orijinal görsel, türev, alt metin, PDF ve ürün ilişkilerini.
• Tara kırık medya URL'leri ve yanlış CDN erişim kurallarını.

17. Search Console ve Merchant Center

• Doğrula eski ve yeni Search Console mülk sahipliklerini.
• Gönder yeni sitemap'i ve kritik URL'leri örnekle.
• Kullan Change of Address aracını yalnız desteklenen domain geçişinde.
• Güncelle Merchant Center mağaza URL doğrulama ve claim durumunu.
• Eşleştir feed linki, görsel, fiyat ve stok değerlerini landing page ile.

18. Analitik, reklam ve consent

• Belgele olay adları, parametreler, ürün kimliği ve transaction ID planını.
• Test et view item, cart, checkout, purchase ve refund olaylarını.
• Engelle çift tag ve çift purchase tetiklenmesini.
• Güncelle reklam final URL, UTM ve tracking template değerlerini.
• Doğrula consent state ve izinsiz pazarlama etiketi davranışını.

19. ERP, muhasebe ve e-belge

• Eşleştir ürün, depo, vergi, durum ve belge kodlarını.
• Durdur eski sipariş connector'ını onaylı checkpoint'te.
• Başlat yeni entegrasyonu yalnız tek yazma sahibi doğrulanınca.
• Test et fatura, e-Arşiv, e-İrsaliye, iptal ve iade senaryolarını.
• Ayır site sipariş arşivi ile yasal e-belge arşivini.

20. Ödeme, kargo, pazaryeri ve CRM

• Güncelle ödeme callback, return URL, webhook ve IP izinlerini.
• Prova et başarılı, ret, timeout, iptal ve kısmi iade ödemelerini.
• Üret test kargo etiketi ve doğrula takip callback'ini.
• Engelle pazaryerine iki sistemden stok/fiyat gönderimini.
• Kademelendir CRM, e-posta, SMS ve sadakat otomasyonlarını.

21. API, webhook, secret ve cron

• Ayır staging ve production secret'larını farklı güvenli kasalarda.
• Döndür ortak veya uzun süredir kullanılan API anahtarlarını.
• Doğrula webhook imzası, retry, sıra dışı teslim ve idempotency'yi.
• Durdur çift çalışan cron ve queue consumer süreçlerini.
• İptal et kabul sonrası kullanılmayan anahtar ve IP izinlerini.

22. Staging ve test verisi

• Koru staging'i parola, IP kısıtı ve ayrı hesaplarla.
• Maskele kişisel veriyi veya sentetik veri seti kullan.
• Yönlendir e-posta/SMS'i sandbox ve güvenli alıcı listesine.
• İzole et canlı ERP, ödeme ve webhook hedeflerini.
• Temizle debug loglarındaki kişisel veri ve secret izlerini.

23. UAT, performans ve güvenlik

• Çalıştır UAT'yi operasyon, depo, finans, destek ve pazarlamayla.
• Sınıflandır hataları kritik, yüksek, orta ve düşük etkiyle.
• Yükle test et ana şablonları ve kritik API kapasitesini güvenli koşulda.
• Denetle rol, oturum, parola, dosya ve API yetkilendirmelerini.
• Tekrarla düzeltilen kritik senaryoları bağımsız kanıtla.

24. DNS, SSL, CDN, WAF ve e-posta

• Envanterle A, AAAA, CNAME, nameserver, MX ve doğrulama kayıtlarını.
• Planla TTL değişikliğini sağlayıcı ve rollback penceresiyle.
• Doğrula sertifikanın tüm gerekli domain/subdomainleri kapsadığını.
• Test et CDN origin, cache, header, bot ve WAF politikalarını.
• Güncelle SPF, DKIM, DMARC ve gönderici domain doğrulamalarını.

25. Cutover ve go/no-go

• Zamanla runbook adımlarını sorumlu ve geri dönüş noktalarıyla.
• Dondur onaysız kod, içerik ve veri değişikliklerini.
• Mutabıklaştır son delta sonrası kritik kayıt ve toplamları.
• Yürüt smoke testleri tanımlı sıra ve kanıtla.
• Kaydet go/no-go kararını açık hata ve iş etkisiyle.

26. Rollback

• Tanımla ölçülebilir rollback tetikleyici ve eşiklerini.
• Prova et DNS/uygulama geri dönüşünü veri uzlaştırmayla birlikte.
• Koru yeni sistemde oluşan sipariş, müşteri ve ödeme kayıtlarını.
• Belirle eski sistemin aktif, salt okunur ve kapalı durumunu.
• Yetkilendir rollback karar sahibini ve maksimum karar süresini.

27. İlk 24 saat

• İzle 4xx/5xx, latency, kapasite ve uygulama loglarını.
• Karşılaştır ödeme, sipariş, stok, fiyat ve toplamları.
• Gözle e-belge, kargo, ERP ve pazaryeri kuyruklarını.
• Ölç giriş, parola, checkout ve müşteri destek bildirimlerini.
• Eskalasyon yap kritik eşiği aşan olayları nöbet düzeniyle.

28. İlk 7, 30 ve 90 gün

• Örnekle ilk hafta redirect, canonical ve indeks sorunlarını.
• Karşılaştır ilk ay organik landing page ve ticari KPI trendlerini.
• İncele Core Web Vitals ve entegrasyon hata trendini.
• Temizle 90 günde kalıcı yanlış 404 ve eski erişimleri.
• Değerlendir SLA, maliyet, kapasite ve eski sistem kapatma kararını.

29. Eski sistem, arşiv ve imha

• Doğrula açık sipariş, iade ve finans mutabakatının tamamlandığını.
• Arşivle restore edilebilir veri ve gerekli denetim kanıtlarını.
• Sınırlandır salt okunur arşiv erişimini görev bazında.
• Danış hukuk, mali müşavir ve KVKK sorumlusuna saklama/imha için.
• Sil geçici aktarım dosyalarını onaylı ve kayıtlı yöntemle.

30. Maliyet, sözleşme ve destek

• Ayır lisans, migrasyon, özel geliştirme ve üçüncü taraf maliyetlerini.
• Hesapla çift lisans, ek altyapı, iç ekip ve fırsat maliyetini.
• Netleştir veri çıkışı, silme, yedek, destek ve fesih koşullarını.
• Tanımla hypercare, bakım, SLA ve hata çözüm sorumluluklarını.
• Onayla kapsam değişikliklerinin teklif ve takvim etkisini.

31. Yapay zekâ ve insan onayı

• Anonimleştir AI eşleştirmesinde kullanılacak veri setlerini.
• Sınırlandır AI rolünü aday üretme ve anomali tespitiyle.
• Örnekle düşük güvenli URL ve alan eşleştirmelerini.
• Onaylat kritik redirect, veri silme ve bakiye kararlarını insanlara.
• Kaydet AI modeli, eşik, çıktı sürümü ve geri alma yöntemini.

E-Ticaret Sitesi Taşırken Sık Yapılan Hatalar

Taşıma hataları çoğu zaman tek teknik ayardan değil, kapsam ve sahiplik boşluğundan doğar. Aşağıdaki örnekler “hata – sonucu – doğru yaklaşım” düzenindedir. Sonuçları mutlak değil, tipik risk olarak okuyun; doğru yaklaşımı proje veriniz ve tedarikçi yetenekleriyle doğrulayın. Her bulgu için sorumlu ve termin belirleyin.

• Kök neden analizi yapmadan platform değiştirmek – aynı sorunu hedefe taşır – performans, veri ve süreç bazını önce ölçün.
• Her şeyi aynı anda değiştirmek – hata kaynağını belirsizleştirir – domain, tasarım ve içerik değişimini mümkünse aşamalandırın.
• Yalnız ürün CSV'sine odaklanmak – müşteri, sipariş ve ilişkiler kaybolur – nesne ve ilişki envanteri hazırlayın.
• Veri envanteri çıkarmamak – kapsam ve maliyet sürprizi üretir – kaynak, sahip, hacim ve kabul testini kaydedin.
• ID/SKU ilişkisini plansız bırakmak – varyant ve sipariş bağını koparır – eski-yeni ID mapping ve external ID kullanın.
• Müşteri parolasını kesin taşınır saymak – giriş krizi yaratır – hash uyumluluğunu test edip aktivasyon alternatifini prova edin.
• Açık sipariş ve iadeleri unutmak – sevk, tahsilat veya iade kaybı doğurur – her açık işlemin tamamlama sistemini seçin.
• Kupon ve sadakat bakiyesini mutabakatsız taşımak – finansal fark ve çift kullanım yaratır – toplam ve müşteri bazlı örnekleri onaylayın.
• Yedeğe restore etmeden güvenmek – rollback anında geri dönülemez durum yaratır – geri yükleme provası ve süre ölçümü yapın.
• Son delta planlamamak – ilk provadan sonraki sipariş ve stok değişimlerini kaybettirir – checkpoint'li delta veya dondurma uygulayın.
• Yalnız sitemap'ten URL listesi almak – trafik ve backlink alan eski sayfaları kaçırır – log, analitik, crawl ve veritabanını birleştirin.
• Bütün URL'leri ana sayfaya yönlendirmek – niyeti bozar ve soft 404 riski doğurur – eşdeğer hedef, 404 veya 410 kararı verin.
• Redirect zinciri veya döngü bırakmak – erişim ve taramayı yavaşlatır ya da keser – eski adresi doğrudan nihai hedefe bağlayın.
• Canonical'ı eski veya staging domaine bırakmak – tercih edilen URL sinyalini çeliştirir – canlı canonical'ları toplu test edin.
• Canlıya noindex/robots engeli taşımak – önemli sayfaları indeks dışı bırakabilir – üç kontrol katmanını ayrı doğrulayın.
• İç linkleri eski URL'de bırakmak – gereksiz redirect ve çelişki üretir – menüden WYSIWYG içeriğine kadar yeni hedefleri yazın.
• Merchant Center ve reklam URL'lerini unutmak – ürün reddi ve kampanya hatası doğurur – feed ve final URL'leri doğrudan güncelleyin.
• Analytics purchase olayını çift çalıştırmak – gelir ve dönüşümü şişirir – transaction ID ile iş sistemi mutabakatı yapın.
• Ödeme callback/webhook adresini güncellememek – tahsilat ile siparişi ayırır – sağlayıcı dashboardu ve uçtan uca test kullanın.
• Test ve canlı API anahtarlarını karıştırmak – işlem ve veri güvenliği riski yaratır – ortam bazlı secret kasaları kullanın.
• İki sistemin stok/fiyat yazmasına izin vermek – fazla satış ve tutarsızlık doğurur – geçiş anında tek yazıcı belirleyin.
• UAT'yi yalnız yazılım ekibine bırakmak – gerçek iş hatalarını kaçırır – finans, depo, destek ve pazarlamayı teste katın.
• Go/no-go ölçütü koymamak – baskı altında öznel karar üretir – kritik eşik ve kanıtı önceden onaylayın.
• Veri etkisini düşünmeden DNS rollback yapmak – yeni siparişleri kaybettirebilir – teknik ve veri geri dönüşünü tek planda birleştirin.
• İlk gün izleme ekibi kurmamak – küçük hata büyüyene kadar görünmez – dashboard, nöbet ve eskalasyon hazırlayın.
• Eski sistemi çok erken veya uzun tutmak – rollback kaybı ya da maliyet/güvenlik riski yaratır – kabul ve arşiv eşikleriyle kapatın.
• Müşteri iletişimini plansız yapmak – parola mesajını sahte gösterebilir – doğrulanabilir, zamanlı ve destekli iletişim hazırlayın.
• AI eşleştirmesini incelemeden uygulamak – anlamsız redirect ve silme üretir – güven skoru, örnekleme ve insan onayı kullanın.
• Paket kapsamıyla özel migrasyonu aynı sanmak – bütçe ve teslim beklentisini bozar – standart, proje ve üçüncü taraf kalemini ayırın.
• Sıfır SEO kaybı veya sıfır kesinti garantisi vermek – gerçekçi olmayan taahhüt yaratır – risk, eşik, geçici dalgalanma ve geri dönüş planını açıklayın.

Sıkça Sorulan Sorular

E-ticaret sitesi taşıma nedir?

E-ticaret sitesi taşıma, çalışan bir mağazanın teknoloji, veri, URL, entegrasyon veya operasyonlarının kaynak platformdan hedef platforma kontrollü biçimde geçirilmesidir. Site migration genel taşıma sürecini; e-commerce replatforming ise mağazanın temel platformunun yeniden seçilip kurulmasını anlatır.

Ürünler yeni e-ticaret altyapısına nasıl aktarılır?

Ürün, kategori, marka, varyant, özellik, medya, fiyat, stok, müşteri, adres, sipariş, iade, yorum, kupon, içerik ve SEO alanları ayrı veri nesneleridir. Her nesne için iş değeri, hukuki/operasyonel gereklilik, veri kalitesi ve hedef desteği değerlendirilir.

E-ticaret sitesi taşıma ne kadar sürer?

Tek bir süre yoktur. Keşif, veri temizliği, geliştirme, deneme aktarımı, ikinci prova, UAT, delta, canlı geçiş ve hypercare aşamalarının süresi veri kalitesi, API erişimi, özel entegrasyon, domain değişimi, içerik hacmi, ekip kapasitesi ve onay gecikmesine bağlıdır.

E-ticaret sitesi taşıma maliyeti ne kadardır?

Taşıma maliyeti lisans fiyatından daha geniştir: veri çıkarma/temizleme, mapping/import, SEO, tema, özel geliştirme, entegrasyon, test, çift çalışma, hosting/CDN/WAF, eğitim, canlı destek, arşiv ve iç ekip zamanı hesaba katılır.

Uygulama Kontrol Listesi

E-ticaret sitesi taşımak yeni bir tasarım açmak veya ürün import etmek değildir. URL ve SEO sinyalleri, ürün-müşteri-sipariş ilişkileri, açık operasyon, stok ve fiyat, ödeme/e-belge, entegrasyon, güvenlik ve ölçüm aynı proje omurgasında yönetilmelidir. Deneme aktarımı, son delta, UAT, go/no-go, rollback ve hypercare olmadan canlı geçiş gereksiz risk taşır.

Önce mevcut varlıkları ve kabul eşiklerini çıkarın; sonra standart paket özelliği ile özel migrasyon işini ayrı karşılaştırın. En iyi hedef altyapı bile bozuk veri, eksik URL mapping veya sahipsiz entegrasyonu kendiliğinden düzeltmez. Aynı nedenle SEO sıralaması, kesintisizlik, veri eksiksizliği veya satış artışı garanti edilemez; bunlar ölçülür, test edilir ve kontrollü biçimde izlenir.

Solofor e-ticaret paketleri sayfasını inceleyerek ürün, kategori, checkout, içerik, SEO, stok, pazaryeri, cari, entegrasyon ve yüksek hacim ihtiyaçlarınıza uygun güncel SoloCommerce seçeneklerini karşılaştırabilirsiniz. Veri aktarımı, URL yönlendirme, tema uyarlaması ve özel entegrasyon kapsamını mevcut sistem envanteri ve geçiş hedefleri üzerinden ayrıca netleştirin. E-belge bağlantısını plana dahil edecekseniz Solofor e-Fatura çözümleri sayfasındaki güncel seçenekleri inceleyin.