E-ticaret sitesi taşınırken unutulmaması gerekenler

Bir e-ticaret mağazasını taşımak yalnız ürün dosyasını yeni sisteme yüklemek değildir. Sayfa adresleri, müşteri ve sipariş verileri, görseller, ödeme akışı ve ölçümleme de geçiş planının parçasıdır.

İlk adım, neyin taşınacağını ve yeni sistemde neyin farklı olacağını görünür hale getirmektir. Kaynak ve hedef platformun aynı veri alanlarını destekleyeceğini varsaymamak gerekir.

Önce mevcut mağazanın envanterini çıkarın

Ürünler, varyantlar, kategoriler, içerik sayfaları ve görselleri listeleyin. Müşteri ve sipariş verilerinin aktarım kapsamı ayrıca değerlendirilmelidir. Dosya biçimleri ve veri alanları her sistemde aynı değildir.

Önemli URL adreslerini de kaydedin. Trafik alan sayfalar, dış bağlantı kazanan içerikler ve satışta öncelikli ürün grupları özellikle kontrol edilmelidir. Bir sayfanın yeni sistemdeki karşılığını bilmeden adresleri değiştirmeyin.

URL değişecek mi?

Aynı alan adında kalmak bütün adreslerin aynı kalacağı anlamına gelmez. Kategori ve ürün yolları değişebilir. Eski adres ile yeni karşılığını eşleştiren bir yönlendirme listesi hazırlayın.

Kaldırılan her ürünü ana sayfaya yönlendirmek doğru bir varsayım değildir. Eşdeğer içerik olup olmadığı, ürünün kalıcı olarak kaldırılıp kaldırılmadığı ve kullanıcı ihtiyacı birlikte değerlendirilmelidir.

Veriyi küçük bir örnekle test edin

Birkaç farklı ürün türünü hedef sisteme aktararak alanları kontrol edin. Varyant, stok, görsel sırası, açıklama ve teknik özellikler doğru yerde mi? Türkçe karakterler veya dosya bağlantıları bozulmuş mu?

Örnek aktarımda görülen sorunları bütün katalog taşınmadan çözmek, daha sonra yapılacak toplu düzeltmeleri azaltır.

Operasyon senaryolarını kontrol edin

• Ürün seçimi ve varyant değişimi
• Sepet ve ödeme adımları
• Kargo ve teslimat seçenekleri
• Sipariş bildirimleri
• Gerekli fatura veya stok entegrasyonları
• İade ve iletişim bilgilerinin görünürlüğü

Bu senaryoların hangi koşullarda test edileceği, ödeme sağlayıcısının deneme olanaklarına ve mağaza kurulumuna bağlıdır.

Yayın öncesi teknik kontrol yapın

Başlıklar, canonical, sitemap, robots ve noindex kuralları kontrol edilmelidir. Test ortamında kullanılan indeks engellerinin üretime yanlışlıkla taşınmadığından emin olun.

Görsellerin boyutları ve mobil sayfa davranışı da yeni platformda yeniden değerlendirilir. Platform değişimiyle tasarım yenilemesi birlikte yapılıyorsa hangi değişikliğin hangi sonucu etkileyebileceğini takip etmek daha zor olabilir.

Geçişi tek bir düğmeye bırakmayın

Yayın zamanı, sorumlular, eski ortamın ne kadar süre açık kalacağı ve geri dönüş planı belli olmalı. DNS veya alan adı değişiklikleri yalnız gerekli kayıtlar bilinerek yapılmalıdır. E-posta kayıtlarının web hostinginden ayrı yönetilebileceğini de unutmayın.

Google’ın hosting değişimi rehberi, adreslerin değişmediği altyapı geçişlerini ayrı ele alır. Adresler değişiyorsa URL değişiklikleriyle site taşıma rehberindeki adımlar da incelenmelidir.

Yayından sonra kontrol sürer

Kritik sayfaları, yönlendirmeleri, hataları ve sipariş akışını yeniden test edin. Search Console ve ölçüm araçlarındaki durumu izleyin; tarama ile indekslenmenin farklı aşamalar olduğunu akılda tutun.

Sadece hosting mi, mağaza yapısı da mı değişiyor?

Taşıma planını bu ayrımı yaparak başlatın. Alan adı ve bütün sayfa yolları aynı kalırken yalnız dosyaların sunulduğu yer değişebilir. Başka bir projede alan adı aynı kalmasına rağmen ürün ve kategori yolları değişir. Bir üçüncü senaryoda ise hem marka adresi hem platform hem tasarım yenilenir. Bu durumların aynı kontrol listesiyle ve aynı risk varsayımıyla yürütülmesi uygun değildir.

Örneğin bir kurumsal kataloğun aynı adreslerle yeni hostinge taşındığını düşünelim. Odak; dosyaların eksiksiz sunulması, sertifika, DNS, formlar ve eski sunucuya bağlı servisler olabilir. Buna karşılık mağaza platformu değişiyorsa ürün alanları, sipariş akışı ve adres eşleştirmeleri de uygulamanın parçasıdır. İlk senaryoda test edilen bir formun çalışması, ikinci senaryodaki bütün ödeme ve stok işlemlerinin doğru olduğunu göstermez.

Aynı anda yapılacak değişiklikleri bir listede görünür hale getirin. Platform geçişi, tasarım, kategori düzeni, alan adı ve ölçüm kurulumu farklı sorumlulara sahip olabilir. Hangi değişikliğin zorunlu, hangisinin ertelenebilir olduğunu konuşmak geçişi yönetmeyi kolaylaştırır. Bir sorun görüldüğünde hangi bileşenin değiştiğini anlamak için bu kayıt yararlıdır.

Bir yönlendirme tablosunda hangi alanlar bulunmalı?

Her satırda eski adres, sayfanın türü, yeni karşılığı, kararın gerekçesi ve test sonucu bulunabilir. “Ürün” veya “kategori” bilgisi, toplu kontrol sırasında hataları ayırmanıza yardımcı olur. Yeni karşılığı henüz belli olmayan adresleri boş bırakıp unutmak yerine “karar bekliyor” olarak işaretleyin. Yayın öncesinde bu satırların sorumlusu ve çözümü görülmelidir.

Varsayımsal bir mağazada eski bir ürün kalıcı olarak kaldırılmış olsun. Aynı ihtiyacı karşılayan güncel ürün varsa bu ilişki değerlendirilir. Böyle bir karşılık yoksa kullanıcıyı ilgisiz ana sayfaya göndermek, aradığı cevabı bulmasını sağlamaz. Karar, envanterdeki her tür sayfanın gerçek durumuna göre verilmelidir. Bütün kaldırılan adresler için otomatik tek kural kullanmak kolay görünse de kontrolü zorlaştırabilir.

Tabloyu yalnız yeni adreslerin açılıp açılmadığına bakarak doğrulamayın. Eski adresten başlatılan isteğin ilgili hedefe ulaştığını, gereksiz zincir oluşmadığını ve hedefte beklenen içeriğin bulunduğunu da kontrol edin. Önemli dış bağlantılardan veya kayıtlı müşteri bağlantılarından gelen kişinin deneyimini böyle görürsünüz. Teknik SEO kapsamındaki adres kontrolü, veri aktarımı testinden ayrı bir teslim olarak yazılabilir.

Veri aktarımında mutabakat nasıl yapılır?

Kaynak ve hedefteki ürün sayılarını karşılaştırmak başlangıçtır; ancak sayıların eşit olması verinin doğru olduğu anlamına gelmez. Aynı ürünün iki kez eklenmesiyle başka bir ürünün eksik kalması toplamı değiştirmeyebilir. Bu nedenle ürün kodu veya uygun benzersiz anahtar üzerinden örnekler seçin. Varyantı olan, farklı görsel sayısına sahip ve özel alan kullanan ürünler kontrol grubunda yer alsın.

Her kontrol için beklenen sonucu yazın. Ürün adı, kodu, fiyatı, stok durumu, varyantları, kategori ilişkisi ve görsel sırası ayrı incelenebilir. Teknik doküman veya kullanım açıklaması varsa bağlantıların açıldığını doğrulayın. Metinde karakter bozulması, satır düzeni veya eski siteye kalan görsel adresi gibi sorunlar yalnız toplam kayıt sayısıyla görünmez.

Son veri aktarımı sırasında yeni siparişlerin nasıl ele alınacağı da belirlenmelidir. Deneme aktarımıyla yayın arasındaki günlerde kaynak sistem değişmeye devam edebilir. Hangi verinin tekrar alınacağı, hangi işlemin durdurulacağı ve ekibin hangi paneli esas kabul edeceği belli olmalı. Taşıma dosyalarının kimlerle paylaşılacağı ve ne zaman kaldırılacağı da erişim planının parçasıdır.

Form ve bildirimleri ayrı bir test kümesi yapın

Site ekranının açılması, talebin doğru kişiye ulaştığını kanıtlamaz. Bir teklif formunda kullanıcıya başarı mesajı gösterilmesi, sunucu kaydı ve bildirim teslimi farklı aşamalar olabilir. Eski hostinge bağlı bir gönderim servisi yeni ortamda çalışmayabilir. Yeni altyapıda gerekli servislerin ve izinlerin yeniden tanımlandığını kontrol edin.

Deneme talebinin açıkça test olduğu yazılmalı ve işletmenin belirlediği adrese gönderilmelidir. Telefon, WhatsApp ve e-posta bağlantılarını da telefondan deneyin. Gereken robot doğrulaması veya spam kontrolü korunurken normal kullanıcının hata halinde ne yapacağı anlaşılır olmalıdır. Yalnız otomatik sistem testine değil, gerçek form akışına da bakın.

Kurumsal e-postayı web dosyalarından ayrı değerlendirin. DNS değişikliği yapılacaksa mevcut posta kayıtlarını envantere alın ve hangi kaydın hangi hizmete ait olduğunu belirleyin. Gereksiz kayıtları tahmin ederek silmek yerine mevcut yapıdan sorumlu kişiyle doğrulayın. Yeni sitenin yayınlanması işletmenin normal e-posta akışının kesilmesini gerektirmez.

Yayın gününde görev dağılımını sade tutun

Bir kişi yayın kararını verirken teknik uygulama, mağaza operasyonu ve kontrol sorumluları ayrı olabilir. Kimin hangi aşamanın tamamlandığını bildireceğini önceden yazın. Kontrol edilmeden “tamamlandı” sayılacak işleri azaltın. Özellikle ödeme, stok ve iletişim akışlarında bir sorunun kim tarafından değerlendirileceği belli olsun.

Geri dönüş planı yalnız eski dosyaların bir kopyasını saklamak değildir. Yayından sonra yeni sipariş geldiyse geri dönüş sırasında bu kayıtların nasıl korunacağı düşünülmelidir. Hangi sorunların hızlı düzeltmeyle çözüleceği, hangilerinin geçişi durduracağı önceden konuşulabilir. Her karar için evrensel bir süre veya eşik yoktur; işletmenin işlem hacmi ve teknik yapısı dikkate alınır.

Yayın kaydına yapılan değişiklikleri ve saatlerini ekleyin. Böylece satış veya analiz verisinde farklılık görüldüğünde ekiplerin elinde ortak bir zaman çizelgesi olur. Kayıtlar gereksiz kişisel veri içermemeli; yapılan işlem, sorumlu ve kontrol sonucu yeterli olabilir. Küçük bir proje için bile bu notlar sonraki bakımda işe yarar.

İçerik yenilemesini aktarım hatasından ayırın

Taşıma sırasında bazı metinlerin, ürün adlarının veya kategori yapısının bilinçli olarak değiştirilmesi istenebilir. Bu kararları aktarım hatalarıyla aynı listede tutmayın. Bir ürün açıklaması tasarım kararıyla kısaltıldıysa onayı belli olmalı; dosyadan eksik aktarıldıysa düzeltilmesi gereken veri sorunu olarak kaydedilmelidir. Farklı nedenleri ayırmak kontrol sürecini hızlandırır.

Örneğin eski mağazada üç ayrı kategori birleştirilecek olsun. Yalnız yeni kategori adını yazmak yeterli değildir. Hangi ürünlerin orada bulunacağı, eski adreslerin karşılığı ve menü bağlantıları birlikte ele alınır. Görsel düzeni onaylayan kişiyle ürün gruplarını doğrulayan kişi farklı olabilir. Bu nedenle içerik kararlarının sorumlusu ve onayı envanterde görünmelidir.

Yeni sitede kullanılmayacak içerikleri de gerekçesiyle işaretleyin. “Eski dosyada kalmış” bilgisi bir içeriğin artık yararsız olduğunu göstermez; müşteri sorularına veya önemli bağlantılara cevap veriyor olabilir. Öte yandan güncel olmayan her metni sırf sayı azalmaması için taşımak da zorunlu değildir. İçeriğin gerçek görevine bakarak karar verin ve yayın kontrolünde bu kararın uygulandığını doğrulayın.

Kontrol listesinin tamamlanması için bütün ekiplerin aynı dosyayı görmesi yararlıdır. Farklı kişilerde farklı sürüm bulunuyorsa çözülen bir sorun tekrar açılabilir veya yeni karar unutulabilir. Gereksiz ayrıntı eklemeden ortak bir durum alanı kullanın: bekliyor, uygulanıyor, kontrol edildi gibi basit etiketler yeterli olabilir. Son durum, yalnız uygulayan kişinin değil kontrol eden kişinin de kaydıyla anlaşılır hale gelir.

Teslim kaydına açık kalan işleri ekleyin

Yayın kararı verildiğinde bazı küçük iyileştirmeler sonraya bırakılmış olabilir. Bunları kayıtsız bırakmak yerine sorumlu ve hedef tarihleriyle listeleyin. Çalışmayı durduracak kritik hata ile sonraki sürümde ele alınabilecek geliştirme aynı durum değildir. Hangi koşullarda yayının onaylandığı işletme tarafından anlaşılmalıdır.

Bu liste, taşımanın başarısız olduğu anlamına gelmez; geriye kalan kapsamın görünür olmasını sağlar. Yeni veri veya müşteri geri bildirimi geldikçe öncelik değişebilir. Tamamlanan işi tekrar açmadan önce nedenini ve beklenen sonucu yazmak, geçiş sonrası bakımın daha düzenli ilerlemesine yardımcı olur.

Geçiş sonrası takipte neye bakılır?

Önce işin çalıştığını doğrulayın: ürün bulunuyor mu, sipariş tamamlanıyor mu, form iletilebiliyor mu, kritik sayfalar açılıyor mu? Ardından arama araçlarındaki tarama ve indeks verisini izleyin. Yeni raporların oluşmasıyla sorunun çözülmesi aynı anda gerçekleşmeyebilir. Tek günlük hareketi kesin sıralama kaybı veya kesin başarı olarak yorumlamayın.

Arama trafiğinde değişiklik varsa yalnız toplam ziyaret sayısına bakmayın. Etkilenen sayfa grupları, eski adresler, sorgular ve cihazlar karşılaştırılabilir. Ölçüm etiketinin değişmesi de raporu etkileyebileceği için iş verisiyle ölçüm verisini birlikte değerlendirin. Yeni mağazada sipariş çalışırken analizde görünmüyorsa sorun satıştan çok ölçüm uygulamasında olabilir; ikisi aynı sonuç değildir.

Geçiş sonunda teslim dosyasına adres eşleştirmelerini, bilinen sınırlamaları ve kontrol sonuçlarını ekleyin. İşletmenin ekibi bundan sonra hangi paneli ve hangi destek kanalını kullanacağını bilsin. E-ticaret projesi veya ikas kurulumu için bize mevcut siteyi ve geçiş nedeninizi ilettiğinizde, bu envanteri projenizin gerçek koşullarına göre hazırlayabiliriz.