Site Taşıma Rehberi: Hosting, Domain ve Platform Değişimi

Site taşıma, web dünyasının ev taşımasıdır: herkes basit sanır, kimse eşyaların yolda dökülme ihtimalini planlamaz. Oysa üç farklı “taşıma” vardır ve her birinin riskleri ayrıdır: hosting taşıma (aynı site, yeni sunucu), domain değişimi (aynı site, yeni adres) ve platform göçü (aynı işletme, yeni altyapı). Üçünü birbirine karıştıran planlar, e-postası kaybolan, formu susan ve Google trafiği buharlaşan sitelerin hikâyesini yazar. İyi haberse şu: üç senaryonun da riskleri bilinir, adımları standarttır ve doğru sırayla ilerleyen taşımalar neredeyse her zaman olaysız biter.

Bu rehber, üç senaryoyu da adım adım anlatıyor: hazırlık, taşıma günü, doğrulama ve SEO koruması — hizmeti kendiniz yapacaksanız uygulama listesi, dışarıdan alacaksanız da teklifleri süzecek denetim listesi olarak kullanın.

Taşıma sonrası trafik düşüşü yaşıyorsanız (yani iş işten geçtiyse) teşhis rehberi ayrı: site yenileme sonrası trafik düşüşü. Tasarım yenilemeyle birleşen taşımalar için o yazıyla birlikte okuyun.

Hangi Senaryodasınız? 30 Saniyelik Yol Ayrımı

Birleşik geçişlerde temel ilke aşamalandırmadır: değişkenleri mümkün olduğunca ayrı zamanlara dağıtın; ayrılamıyorsa her katmanın test ve doğrulamasını ayrı ayrı kurun.

Başlamadan: Erişim Arkeolojisi

Taşımaların gizli birinci adımı, çoğu işletmede kazı çalışmasıdır: erişimler kimde? Alan adı yıllar önce bir tanıdığın hesabında alınmış, hosting eski ajansta, DNS kimsenin hatırlamadığı bir panelde… Taşımadan önce dört mülkün envanteri ve mümkünse şirket kontrolüne devri gerekir:

1. Alan adı (registrar hesabı): en kritik varlık — kimin hesabında, yenileme ne zaman, transfer kilidi/kodu erişilebilir mi?
2. DNS yönetimi: hangi panelden yönetiliyor (registrar mı, hosting mi, ayrı servis mi)?
3. Hosting: panel erişimi + FTP/SSH + veritabanı.
4. Bağlı servisler: SSL sağlayıcı, CDN, e-posta servisi, doğrulama kayıtları.

Bu arkeoloji bazen taşımanın kendisinden daha uzun sürer — ve tam da bu yüzden taşıma, mülkiyet düzenini kurmanın en iyi bahanesidir: her şey şirket hesaplarına, erişimler parola yöneticisine, yenilemeler takvime. Bir sonraki taşıma (ve bir sonraki ajans değişimi) bu düzenin üstünde acısız geçer.

Senaryo 1: Hosting Taşıma (Aynı Domain, Yeni Sunucu)

En yaygın ve en az riskli senaryo — doğru yapılırsa ziyaretçi hiçbir şey fark etmez. Yanlış yapılırsa: birkaç saatlik kesinti, kayıp e-postalar ve bozuk veritabanı.

Hazırlık (taşımadan 3–7 gün önce)

1. Tam envanter çıkarın. Taşınacak şey yalnızca site değildir: dosyalar + veritabanı + e-posta hesapları ve içerikleri + DNS kayıtları + SSL + cron görevleri + alt alan adları. Unutulan kalem, taşıma gününün sürprizi olur; en çok unutulan da e-postadır.
2. DNS TTL’ini düşürün. Alan adının DNS kayıtlarındaki TTL değerini (ör. 4 saat) taşımadan en az bir gün önce düşük bir değere (300 sn) çekin — geçiş anında dünyanın sizi yeni sunucuda bulması dakikalar sürsün, saatler değil.
3. Yeni sunucuyu önce kurun, sonra test edin. Siteyi yeni sunucuya kopyalayın ve DNS’i değiştirmeden test edin (geçici önizleme adresi ya da bilgisayarınızın hosts dosyasıyla). PHP sürümü, eklenti uyumu, form gönderimi, SSL — hepsi yeni evde, taşınmadan önce doğrulanır; bulunan her uyumsuzluk, canlıda değil provada çözülür.
4. E-posta planını ayrıca yazın. E-postalar aynı hostingteyse: yeni sunucuda hesaplar önceden açılır, eski içerikler taşınır (IMAP kopyalama), geçiş sonrası iki tarafta da kısa süre kontrol edilir. Bu fırsatla e-postayı hostingten ayırmak (profesyonel e-posta servisi) çoğu işletme için doğru karardır — bir sonraki taşımada bu dert hiç olmaz.
5. Ekipte haber ve rol netliği: taşıma penceresi, içerik/ürün girişi yasağı ve kimin neye bakacağı önceden duyurulur — habersiz ekip üyesinin geçiş saatinde girdiği içerik, klasik veri kaybıdır.

Taşıma günü

1. Trafiğin en düşük olduğu saati seçin. (Analitik verinize bakın; çoğu yerel işletmede bu, hafta içi gece yarısı sonrasıdır.)
2. Son senkron: eski sunucudan o anki güncel yedeği alın (hazırlıktaki kopyadan sonra eklenen içerik/sipariş farkı kalmasın); e-ticarette kısa bir “bakım modu” penceresi en temizidir.
3. Son yedeği yeni sunucuya işleyin, son testleri yapın.
4. DNS’i yeni sunucuya çevirin.
5. Yayılımı izleyin; ilk saatlerde iki sunucuyu da açık tutun (DNS henüz eskiye bakan ziyaretçiler boşluğa düşmesin).

Doğrulama (ilk 48 saat)

• SSL çalışıyor mu (yeni sunucuda sertifika aktif ve geçerli, zorlamalı HTTPS yerinde)?
• Formlar gerçekten iletiyor mu (test gönderimi)? E-posta alıp gönderiyor mu?
• Site içi arama, ödeme, giriş gibi kritik akışlar?
• Hız karşılaştırması: taşınma gerekçeniz performanssa, kanıtını ölçün. Aynı sayfaların taşıma öncesi/sonrası TTFB ve LCP değerleri, kararınızın karnesidir.
• Birkaç gün sonra eski sunucuyu kapatın — ama yedeklerini bir süre saklayın.

SEO etkisi: URL’ler değişmediği için doğru yapılan hosting taşımasının kalıcı SEO etkisi yoktur; kısa süreli tarama dalgalanması normaldir. Google’a özel bir bildirim gerekmez. Hız iyileştiyse etki zamanla olumludur. Yine de geçiş haftasında Search Console’a günlük bakmak ucuz bir sigortadır.

Senaryo 2: Domain Değişimi (Yeni Adres)

En riskli senaryo — çünkü arama motorlarının sitenizle ilgili tüm birikimi eski adrese yazılıdır. Kural tektir ve tavizsizdir: her eski URL, yeni karşılığına 301 ile birebir yönlendirilir.

Hazırlık

1. URL envanteri: eski sitenin tüm URL’leri dökülür (site haritası + Search Console + analitik verisiyle; en çok trafik/bağlantı alan sayfalar işaretlenir).
2. Eşleme tablosu: eski → yeni URL haritası satır satır yazılır. Yapı aynı kalıyorsa desen bazlı kurallar yeter; değişiyorsa tablo elle doğrulanır. “Hepsini ana sayfaya yönlendiririz” çözümü, birikimi çöpe atmanın kibar adıdır — yönlendirme kuralları burada hayat kurtarır.
3. Yeni domain hazırlığı: yeni adres canlı, SSL’li ve tam çalışır durumda; Search Console’da iki domain de doğrulanmış.

Geçiş

1. 301 yönlendirmeleri devreye alınır (eski domain, sayfa bazında yeniye akar).
2. Search Console’un adres değişikliği aracı çalıştırılır (eski mülkten yeniye).
3. Yeni domain’in site haritası gönderilir; iç linkler, şemalar ve canonical’lar yeni adresi göstersin.
4. Dış dünya güncellenir: işletme profili, sosyal hesaplar, dizinler, e-posta imzaları, reklam hesapları; ulaşabildiğiniz önemli backlink sahiplerinden güncelleme rica edilir.
5. Analitik ve izleme araçları yeni domain’e göre güncellenir; hedef/dönüşüm tanımları kontrol edilir — ölçümün koptuğu geçişte, başarının kendisi de görünmez olur.

Domain değişiminin iletişim katmanı

Teknik geçiş kadar önemli ikinci cephe, insanlara duyurudur: müşterilere e-posta/SMS bilgilendirmesi (“adresimiz değişti, eski bağlantılar otomatik yönlenir”), sosyal profillerde sabitlenmiş duyuru, e-posta adresleri de değişiyorsa çift yönlü geçiş dönemi (eski adreslere gelenlerin yönlendirilmesi + otomatik bilgilendirme yanıtı) ve kartvizit/katalog gibi basılı materyallerin güncelleme takvimi. Marka değişimiyle birleşen domain geçişlerinde bu katman, teknik katmandan daha uzun sürer — planı da ona göre kurun.

Sonrası

• Eski domain yıllarca elde tutulur ve yönlendirmeye devam eder — yönlendirme, kira gibi sürdükçe çalışır; domain’i bırakmak, tüm eski bağlantı ve yer imlerini çöpe atmak (ve adresi başkasının kapmasına açmak) demektir.
• Geçici dalgalanma beklenir: sıralamalar tipik olarak haftalar içinde toparlanır; marka sorgularının yeni adrese oturması izlenir.
• Search Console’da iki mülk de aylarca izlenir: eski tarafta hatalar eriyor mu, yeni tarafta kapsama büyüyor mu?

Senaryo 2,5: HTTPS ve www Standardizasyonu

Domain değişiminin küçük kardeşi de taşıma disiplinine tabidir: HTTP’den HTTPS’e geçiş ya da www’lu/www’suz sürüm birleştirme. Kurallar aynıdır, ölçek küçüktür: tek tercih belirlenir (tercihen https + tek varyant), diğer üç varyantın tamamı (http/https × www/köksüz) 301 ile tek hedefe akar, iç linkler ve canonical’lar tercih edilen sürümü gösterir, Search Console’da doğru mülk izlenir. En sık hata, varyantlardan birinin yönlendirilmeden ayakta kalması ve aynı içeriğin iki adreste yaşamasıdır — küçük görünen bu dağınıklık, sinyal bölünmesi ve kopya içerik sorunu üretir. Ayrıntılar için: canonical etiketi rehberi.

Senaryo 3: Platform Göçü (Yeni Altyapı)

Wix’ten WordPress’e, hazır sistemden özel yazılıma, ya da tersine — teknik olarak en kapsamlı senaryo, çünkü URL yapısı ve içerik depolama biçimi genellikle birlikte değişir.

Ana kurallar:

1. URL yapısını koruyabiliyorsanız koruyun. Yeni platformda eski URL desenini sürdürmek, göçün SEO riskini dramatik düşürür. Korunamıyorsa: eksiksiz 301 eşleme tablosu (yukarıdaki disiplinle).
2. İçerik denkliği denetimi: göç araçları başlıkları, görselleri, meta verileri ve yapılandırılmış veriyi her zaman tam taşımaz; örneklem denetimi (en değerli 50 sayfa birebir karşılaştırma) şarttır.
3. Şablon değişiminin SEO’su: yeni tema/şablon; başlık hiyerarşisi, iç link blokları, hız ve mobil davranışı değiştirir — göçle birlikte teknik SEO temellerinin yeniden doğrulanması gerekir.
4. Kademeli geçiş seçeneği: büyük sitelerde bölüm bölüm göç (önce blog, sonra hizmet sayfaları) risk dağıtır; küçük sitede tek seferlik geçiş + yoğun doğrulama daha pratiktir.

E-ticaret göçlerinde ek dosya: müşteri hesapları ve sipariş geçmişi (KVKK dahil), stok/varyant eşleşmesi, ödeme entegrasyon testleri ve sepet/ödeme akışının uçtan uca gerçek denemesi. Platform göçünde bir de kültürel gerçek vardır: ekip, yıllardır alıştığı panelden yenisine geçer — göç planına yönetici eğitimi ve ilk ay için “eski işi yeni panelde nasıl yaparım” rehberi eklemek, iç direnci ve hata oranını düşürür.

Vaka Günlüğü: Bir E-Ticaret Sitesinin Hosting Taşıması

Temsili vaka — günlük ~150 siparişlik bir mağaza, yavaşlayan paylaşımlı hostingten performans sunucusuna geçiyor:

Pazartesi: Envanter çıkarılır: site + veritabanı + 14 e-posta hesabı + 2 alt alan adı (blog eski bir kurulumda!) + 3 cron görevi. Alt alan adı, envanter olmasa unutulacaktı. TTL 300 saniyeye çekilir. (Vaka temsilidir; süreler tipik orta ölçekli taşımalardan derlendi.)

Salı–Çarşamba: Yeni sunucu kurulur; site kopyalanır, hosts dosyasıyla test edilir. İlk sorun burada yakalanır: yeni sunucunun PHP sürümü, eski bir ödeme eklentisiyle uyumsuz — eklenti güncellenir, testte doğrulanır. (Bu sorun canlı geçişte yakalansaydı: satış kaybıyla ödenecekti.)

Perşembe 02:00–02:40: Bakım modu açılır; son veritabanı senkronu (üç günün siparişleri) yapılır; DNS çevrilir. 02:25’te yeni sunucu trafiği almaya başlar; test siparişi + form + e-posta kontrolleri geçer. Bakım modu kapanır. Toplam müşteri görünür kesintisi: 40 dakika, gecenin en ölü saatinde.

Perşembe–Cuma: Nöbet: loglarda 404 avı (iki unutulmuş görsel yolu düzeltilir), hız ölçümü (mobil LCP belirgin iyileşir), e-posta çift yönlü test. Cumartesi eski sunucu pasife alınır, yedekleri arşivlenir; hesap iki hafta sonra kapatılır. Nöbetin sessiz geçmesi başarı sayılır ve raporlanır.

Sonuç: sıfır kayıp sipariş, ölçülür hız kazanımı, bir hafta sonra Search Console’da olumlu tarama istatistikleri. Kahramanlık yok; envanter, test ve sıra var.

Taşıma Günü Evrensel Kontrol Listesi

Senaryodan bağımsız, geçiş gününün son kontrolü:

• Güncel tam yedek alınmış (iki kopya: eski ortamda + tamamen bağımsız bir lokasyonda)
• DNS TTL düşürülmüş, erişimler (registrar, hosting, panel) elde
• Yeni ortam test edilmiş: SSL, formlar, kritik akışlar, hız
• E-posta planı yazılı ve hazır
• (Domain/platform değişiminde) 301 eşleme tablosu kurulu ve örneklemle test edilmiş
• robots.txt yeni ortamda doğru (test ortamının “engelle” kuralı canlıya taşınmasın — klasik felaket)
• Analytics ve Search Console yeni yapıya hazır
• Geri dönüş planı: işler ters giderse DNS’i eskiye çevirme kararının eşiği, süresi ve sorumlusu belli
• Taşıma penceresi ekipçe biliniyor; ilk 48 saat nöbetçisi atanmış

Büyük Site Taşımaları: Ölçek Farkı

Binlerce sayfalık siteler ve yüksek trafikli platformlarda taşıma, proje yönetimi disiplini ister; ek katmanlar:

• Aşamalı DNS geçişi: trafiğin kademeli aktarımı (önce düşük trafikli alt alanlar) ve yük altında gözlem
• Log tabanlı 301 doğrulaması: eşleme tablosu, canlı trafiğin en çok istek alan URL’leriyle otomatik test edilir; kırık yönlendirme, hacim sırasına göre düzeltilir
• Tarama bütçesi gözetimi: geçiş sonrası bot davranışı izlenir; parametre patlamaları ve yönlendirme zincirleri (301 → 301 → 200) tekilleştirilir — zincir, hem botu hem kullanıcıyı yavaşlatır
• Dondurulmuş dönem: taşıma penceresi etrafında içerik/kampanya değişiklik yasağı; değişkenler sabitlenir
• Paydaş provası: geçiş gecesinin saat saat senaryosu, rollerle birlikte önceden yazılır ve bir kez masa başında prova edilir

Bu ölçekte “taşıma hizmeti” değil, taşıma projesi satın alınır — teklifte proje planı, rol dağılımı ve geri dönüş senaryosu görünmelidir.

DNS’i Beş Dakikada Anlamak: Taşımanın Görünmez Motoru

Taşımaların çoğu DNS kavramlarına takıldığı için mini sözlük:

• A kaydı: alan adını sunucu IP’sine bağlar — hosting taşımasında değişen esas kayıt budur.
• MX kaydı: e-postanın nereye düşeceğini söyler — site taşınırken MX yanlış güncellenirse mailler kaybolur; e-posta ayrı servisteyse MX’e hiç dokunulmaz.
• CNAME: bir adı başka ada bağlar (www, alt alan adları); envanterde unutulmasın.
• TXT kayıtları: doğrulamalar ve e-posta güvenliği (SPF/DKIM/DMARC) burada yaşar — taşımada silinirse mailleriniz spam’e düşmeye başlar; taşıma öncesi tüm TXT kayıtlarının kopyasını alın.
• TTL: kaydın önbellek süresi; geçiş çevikliğinin ayarı.
• Nameserver (NS) değişimi: DNS yönetiminin kendisini başka sağlayıcıya taşımak — hosting taşımaktan farklıdır ve tüm kayıtların yeni tarafta birebir kurulmasını gerektirir. Mümkünse DNS yönetimini hostingten bağımsız bir yerde (registrar ya da ayrı DNS servisi) tutun: gelecekteki her taşıma, tek A kaydı değişikliğine iner.

Altın kural: taşıma öncesi mevcut DNS kayıtlarının tam ekran görüntüsü/dökümü alınır. Beş dakikalık bu arşiv, “eskiden hangi kayıt vardı” krizlerinin tamamını çözer.

Hizmet Alacaksanız: Taşıma Teklifini Değerlendirme

”Site taşıma hizmeti” ararken sorulacaklar:

1. Envanter soruyor mu? E-postayı, alt alan adlarını, cron’ları sormadan fiyat veren, sürpriz faturanın davetiyesidir.
2. Test-sonra-geçiş mi? Yeni ortamda DNS öncesi test aşaması planda var mı?
3. Kesinti beklentisi ne? Doğru cevap çoğu senaryoda “sıfıra yakın”dır; “bir gün kapalı kalır” cevabı, yöntem eskiliğinin itirafıdır.
4. SEO tarafını kim üstleniyor? Domain/platform değişiminde 301 tablosu tekliften çıkıyorsa, taşıma değil nakliye satın alıyorsunuz.
5. Doğrulama ve nöbet dahil mi? Geçiş sonrası 48 saatlik kontrol + bir hafta erişilebilirlik.
6. Erişimler nasıl yönetiliyor? Geçici erişimler iş sonunda kapatılır; alan adı ve hosting mülkiyeti her zaman sizde kalır.

Ve zamanlama uyarısı: taşımayı kampanya/sezon dönemine, büyük içerik lansmanına ya da tatilinize denk getirmeyin — taşıma sakin dönemin işidir. Taşıma tarihini belirlerken şirket takvimindeki üç şeye bakın: kampanyalar, tatiller ve fatura/bordro gibi kritik iç dönemler.

Hosting Seçimi: Yeni Evi Doğru Seçmek

Taşınma kararı verildiyse, hedefin seçimi de taşımanın parçasıdır — kısa kriter seti:

• Performans kanıtı: pazarlama sayfasındaki “ışık hızı” değil, deneme/iade garantisiyle kendi sitenizin test kurulumu. TTFB’yi kendi içeriğinizle ölçün.
• Türkiye trafiği için lokasyon/CDN: kitleniz yerliyse sunucu yakınlığı ya da iyi bir CDN katmanı gecikmeyi belirler.
• Teknik uyum: gereken PHP/veritabanı sürümleri, SSH erişimi, kolay staging ortamı, otomatik yedek derinliği ve yedeğin dışa aktarılabilirliği (içeride hapsolan yedek, yedek değildir).
• Destek gerçeği: gece bir sorun açtığınızda kimin, ne kadar sürede, hangi yetkinlikte döndüğü — taşınma öncesi küçük bir destek talebiyle test edilebilir.
• Çıkış kolaylığı: bugün girerken yarın çıkışın kolaylığına bakın; veriyi ve DNS’i rehin alan yapılar, ucuz fiyatın pahalı yüzüdür.
• Kaynak izolasyonu: paylaşımlı hostingte komşu yoğunluğundan etkilenme; büyüyen sitede VPS/bulut kademesine geçiş yolu.

Son bir seçim notu: referansları pazarlama sayfasından değil, sizinle benzer ölçekteki gerçek kullanıcılardan dinleyin; hosting deneyimi, ölçeğe göre bambaşka yaşanır.

Fiyat, bu listeden sonra gelir — çünkü kötü evin ucuzluğu, bir sonraki taşımanın peşinatıdır.

Ne Zaman Taşınmalı? Gerekçelerin Dürüst Değerlendirmesi

Taşıma bir araçtır; bazen yanlış soruna uygulanır. Gerekçe muhasebesi:

Haklı gerekçeler: kronik yavaşlık ve kaynak sınırları (site büyüdü, paylaşımlı hosting daraldı), sık kesintiler ve kötü destek deneyimi, güvenlik gereksinimleri (izolasyon, güncel altyapı), coğrafi performans ihtiyacı, birleşme/marka değişimi (domain senaryosu) ve platformun gerçek sınırlarına dayanmak (ihtiyacınız olan özellik altyapıda yok).

Sahte gerekçeler: “Site yavaş, hosting değiştirelim” — yavaşlığın nedeni çoğu zaman sunucu değil sitedir (şişmiş tema, dev görseller, eklenti yükü); önce hız teşhisi yapılmalı, taşınma kararı ölçüme dayanmalıdır. Sunucu yanıt süresi (TTFB) kötüyse hosting suçludur; sayfa render süresi kötüyse site suçludur — ikisini ayıran, boşa taşınmaz. “SEO düştü, domain değiştirelim” — neredeyse her zaman yanlış teşhis ve büyük risk; düşüşün gerçek nedenini bulmadan adres değiştirmek, ateşi termometre kırarak düşürmektir.

Kısa karar kuralı: taşınma, ölçülmüş bir sorunun ölçülmüş çözümüyse yapılır; his ve hevesle yapılmaz. Bir ek not: sağlayıcınıza kızgınlıkla verilen ani taşınma kararları, en hazırlıksız taşımaları üretir — öfke geçene kadar envanter çıkarın; taşınma yine olacaksa bile planlı olsun.

Sık Yapılan 8 Taşıma Hatası

1. E-postayı unutmak. Sitenin taşındığı gün maillerin kaybolması — bir numaralı klasik.
2. TTL’i düşürmeden DNS değiştirmek. Kimi ziyaretçi saatlerce eski (artık güncellenmeyen) sunucuyu görür.
3. Test ortamı robots.txt’sini canlıya taşımak. Site, kendi eliyle Google’dan gizlenir; haftalar sonra fark edilir.
4. ”Hepsi ana sayfaya 301.” Sayfa bazlı birikim buharlaşır; teknik olarak yönlendirme, pratikte imha.
5. Son senkronu atlamak. Hazırlık kopyasıyla canlı arasındaki üç günlük siparişler/yorumlar kaybolur.
6. Eski domain’i/sunucuyu erken kapatmak. Yönlendirmeler ve son yedekler onunla birlikte gider.
7. SSL’i sona bırakmak. Geçiş anında “güvenli değil” uyarısı; ilk izlenim de, dönüşüm de yaralanır.
8. Tek kişilik gece operasyonu. Yorgun tek kişi + geri dönüş planı yokluğu; küçük aksilik, uzun kesintiye döner.

Küçük İşletme Kısayolu: Minimum Uygulanabilir Taşıma

Beş sayfalık kurumsal siteniz varsa yukarıdaki tam disiplin göz korkutabilir; küçültülmüş sürüm şudur: (1) alan adı ve hosting erişimlerinin elinizde olduğunu doğrulayın; (2) tam yedek alın (site + veritabanı) ve bilgisayarınıza da indirin; (3) TTL’i bir gün önce düşürün; (4) yeni sunucuya kurup önizleme adresinden ana sayfa + iletişim formunu test edin; (5) sakin bir saatte DNS’i çevirin; (6) formu bir kez daha test edin ve ertesi gün Search Console’a bakın. Bu altı adım, küçük sitedeki taşıma risklerinin %90’ını kapatır — geri kalan %10 için bu rehberin ilgili bölümleri her zaman burada. Küçük sitenin avantajını da kullanın: içerik az olduğu için tam sayfa turu (her sayfayı tek tek açıp bakmak) beş dakikada biter — büyük sitelerin örneklemle yetindiği doğrulamayı siz eksiksiz yapabilirsiniz.

Taşıma Sonrası SEO İzleme Takvimi

Geçiş bitti; arama tarafının nöbeti başlar:

Bu takvimin okuma disiplini için: Search Console kullanım rehberi. Ve bir beklenti kalibrasyonu: dalgalanma normaldir, tek yönlü ve derinleşen kayıp normal değildir — ikincisini gördüğünüz hafta teşhise başlayın, çeyrek sonunu beklemeyin.

Sık Sorulan Sorular

Sonuç

Site taşımanın özü üç cümledir:

1. Taşıma bir an değil, süreçtir. Hazırlık + test + geçiş + 48 saat doğrulama; dört aşamadan birini atlayan, atladığını taşıma günü öğrenir. Toplam emeğin kabaca dağılımı da bunu söyler: %40 hazırlık, %10 geçiş, %30 doğrulama, %20 sonrası izleme.

2. Envanter her şeydir. Site, veritabanı, e-posta, DNS, SSL, cron, alt alan adları — liste tam olmadan hiçbir taşıma “basit” değildir. Envanterin en değerli satırı da çoğu zaman en sıkıcı olanıdır: erişimler kimde?

3. Adres değişiyorsa 301 kutsaldır. Sayfa bazlı, eksiksiz, kalıcı yönlendirme; arama birikiminizin taşındığı tek kamyon budur.

Ve genel bir kapanış gözlemi: bu rehberdeki işlerin hiçbiri zor değildir; zor olan, hepsini hatırlamaktır. Kontrol listelerini kopyalayın, kendi envanterinizle doldurun ve taşıma gününe liste ile girin — hafıza, gece 02:00’de güvenilir bir araç değildir.

Taşımanızı planlamak ya da denetletmek isterseniz teknik SEO hizmetleri sayfasına bakabilir veya iletişime geçebilirsiniz.