Server Köçürmə (Miqrasiya) Necə Edilir? Məlumat İtirmədən Sayt Daşımaq

Server köçürmə (miqrasiya), bir veb saytın fayllarını, verilənlər bazasını, e-poçt hesablarını, DNS qeydlərini və tətbiq tənzimləmələrini mövcud serverdən yeni serverə planlı şəkildə köçürmə əməliyyatıdır. Məlumat itkisi olmadan sayt daşımaq üçün əsas metod belədir: əvvəlcə tam ehtiyat nüsxə alınır, yeni server eyni və ya daha güncəl proqram versiyaları ilə hazırlanır, fayl və verilənlər bazası köçürülür, hosts faylı və ya müvəqqəti URL ilə test edilir, DNS yönləndirməsi aşağı TTL ilə dəyişdirilir və köçürmə sonrası loglar, formalar, ödəniş axınları, e-poçt çatdırılması və SEO siqnalları yoxlanılır.

Server köçürmə əməliyyatı sadə bir kopyala-yapışdır prosesi deyil. Xüsusilə WordPress, WooCommerce, Laravel, xüsusi PHP tətbiqləri, yüksək trafikli xəbər saytları və ya korporativ e-poçt istifadə edən müəssisələr üçün səhv bir köçürmə; sifariş itkisi, pozulmuş Azərbaycan hərfləri, 500 xətaları, SSL xəbərdarlıqları, e-poçt kəsintisi və axtarış motoru görünürlüğündə azalma kimi nəticələr doğura bilər. Bu səbəbdən miqrasiya planı, texniki nəzarət siyahısı və geri dönüş ssenarisi ilə icra edilməlidir.

Bu bələdçidə bir hostinq və ya server dəyişikliyini 2026 SEO və performans gözləntilərinə uyğun şəkildə necə edəcəyinizi addım-addım izah edəcəyik. Həmçinin cPanel, Plesk, VPS, bulud server və əl ilə köçürmə kimi fərqli ssenarilərə toxunacaq; DNS müddəti, ehtiyat nüsxə əhatəsi, verilənlər bazası uyğunluğu, SSL qurulumu və köçürmə sonrası SEO nəzarətləri üçün tətbiq oluna bilən tövsiyələr paylaşacağıq.

Server Köçürmə Nə Zaman Lazımdır?

Bir veb saytı yeni serverə daşımaq adətən performans, təhlükəsizlik, maliyyət və ya genişləndirilə bilmə ehtiyacından yaranır. Məsələn, aylıq 5.000 ziyarətçili bir korporativ sayt paylaşımlı hostinq ilə problemsiz işləyə bilərkən, gündəlik 20.000 ziyarətçi alan bir e-ticarət saytında CPU limiti, yavaş sorğular və ödəniş səhifəsində zaman aşımı problemləri görünə bilər. Bu nöqtədə daha güclü bir hostinq paketi, VPS və ya bulud infrastrukturu seçilir.

Server köçürmə ehtiyacını göstərən ümumi siqnallar bunlardır:

• Səhifə açılış müddətinin 3 saniyənin üzərinə çıxması və Core Web Vitals göstəricilərinin pisləşməsi.
• Hostinq panelində CPU, RAM, inode və ya disk istifadə limitlərinin tez-tez dolması.
• PHP, MySQL, MariaDB, Node.js və ya ionCube kimi komponentlərdə güncəl versiya ehtiyacı.
• SSL yeniləmə, e-poçt çatdırılması və ya DNS idarəetməsi kimi mövzularda tez-tez problem yaşanması.
• Mövcud təchizatçıda dəstək keyfiyyəti, ehtiyat nüsxə və ya təhlükəsizlik səviyyəsinin qeyri-kafi qalması.
• Sayt trafikinin kampaniya, reklam və ya sezon dövrlərində qəflətən artması.

Əgər saytınız böyüyür və mövcud paket limitlərinə yaxınlaşırsa, son anda böhran anında köçürmə etmək yerinə nəzarətli bir miqrasiya planı qurmaq daha etibarlıdır. Ehtiyacınıza uyğun olaraq Veb hostinq paketləri, VPS server həlləri və ya Korporativ Hosting seçimlərini müqayisə edərək doğru infrastrukturu seçə bilərsiniz.

Köçürmə Öncəsi Hazırlıq: Ən Kritik Mərhələ

Məlumat itkisi yaşanan köçürmə layihələrinin böyük hissəsi köçürmə əsnasında deyil, hazırlıq çatışmazlığı üzündən uğursuz olur. Köçürməyə başlamazdan əvvəl mövcud saytın inventarı çıxarılmalı, hansı məlumatların köçürüləcəyi və hansı servislərin kəsintiyə həssas olduğu aydınlaşdırılmalıdır.

1. Sayt İnventarı Çıxarın

İlk addım, veb saytın texniki xəritəsini yaratmaqdır. İstifadə olunan CMS və ya framework, PHP versiyası, verilənlər bazası növü, disk ölçüsü, e-poçt hesabları, cron tapşırıqları, DNS qeydləri, SSL sertifikatı, xüsusi yönləndirmələr və üçüncü tərəf inteqrasiyalar qeyd edilməlidir. Məsələn, bir WordPress saytında sadəcə wp-content qovluğunu daşımaq kifayət deyil; .htaccess qaydaları, wp-config.php tənzimləmələri, verilənlər bazası cədvəl ön əlavələri, cache əlavələri və media faylları da nəzarət edilməlidir.

Bir e-ticarət saytında isə ödəniş infrastrukturu, kargo inteqrasiyası, stok sinxronizasiyası, ERP əlaqəsi, SMTP servisi və webhook URL ünvanları ayrıca incələnməlidir. Köçürmə sonrası sifariş gəlmirsə problem çox vaxt fayl köçürməsində deyil, unudulan bir API IP məhdudiyyətində və ya köhnə serverə tanımlı təhlükəsizlik qaydasında ortaya çıxır.

2. Tam Ehtiyat Nüsxə Alın və Doğrulayın

Server köçürmə əməliyyatında ehtiyat nüsxə almaq tək başına kifayət deyil; ehtiyat nüsxənin geri yüklənə bilər olduğu da doğrulanmalıdır. Tam ehtiyat nüsxə bu komponentləri əhatə etməlidir:

• Veb sayt faylları: public_html, tətbiq qovluqları, upload qovluqları, tema və əlavə faylları.
• Verilənlər bazaları: MySQL, MariaDB, PostgreSQL və ya tətbiqin istifadə etdiyi digər verilənlər bazaları.
• E-poçt məlumatları: poçt qutuları, yönləndirmələr, filtrlər, autoresponder tənzimləmələri.
• DNS qeydləri: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC qeydləri.
• Konfiqurasiyalar: .htaccess, nginx.conf, php.ini, cron job, environment faylları.
• SSL sertifikatları və xüsusi təhlükəsizlik qaydaları.

Praktik bir yanaşma olaraq köçürmə öncəsi ən az iki nüsxə ehtiyat nüsxə alın: biri mövcud serverdə, digəri fərqli bir lokasiyada saxlanılsın. Böyük saytlarda fayl ehtiyat nüsxəsi üçün rsync, verilənlər bazası üçün mysqldump və ya panel ehtiyat nüsxə alətləri istifadə edilə bilər. 10 GB üzəri verilənlər bazalarında tək parça dump yerinə sıxışdırılmış və bölünmüş ehtiyat nüsxələr daha etibarlı ola bilər.

3. DNS TTL Dəyərini Öncədən Azaldın

DNS dəyişikliyinin sürətli yayılması üçün TTL dəyərini köçürmə əməliyyatından 24 saat əvvəl azaltmaq yaxşı bir praktikadır. Məsələn, TTL dəyəri 14400 saniyədirsə bəzi istifadəçilər köhnə serverə saatlarla getməyə davam edə bilər. Köçürmədən əvvəl TTL dəyərini 300 saniyəyə endirmək, DNS keçidini daha nəzarətli hala gətirər. Köçürmə tamamlandıqdan və hər şey doğrulandıqdan sonra TTL yenidən 3600 və ya 14400 saniyəyə çıxarıla bilər.

Domen adınızın DNS idarəetməsini müntəzəm etmək, miqrasiya müvəffəqiyyətini birbaşa təsir edər. Domen adı və DNS konfiqurasiyası üçün domain sorğulama və domen idarəsi bələdçilərini nəzərdən keçirə bilərsiniz.

Server Köçürmə Metodlarının Müqayisəsi

Hər sayt üçün ən doğru köçürmə metodu eyni deyil. Kiçik bir korporativ sayt panel üzərindən asanlıqla daşına bilərkən, yüksək trafikli bir e-ticarət saytında pilləli sinxronizasiya və texniki xidmət rejimi lazım ola bilər.

Yeni infrastrukturu seçərkən sadəcə disk sahəsinə baxmaq yanıldıcıdır. PHP worker sayı, CPU nüvəsi, RAM, NVMe disk, ehtiyat nüsxə tezliyi, məlumat mərkəzi mövqeyi, LiteSpeed və ya Nginx dəstəyi, WAF və DDoS qoruması kimi kriteriyalar da performansı müəyyən edər. Bu səbəbdən ehtiyac analizi etmədən ən ucuz paketə keçmək, qısa müddətdə yenidən köçürmə ehtiyacı doğura bilər.

Addım-Addım Server Köçürmə Necə Edilir?

Addım 1: Yeni Serveri Hazırlayın

Yeni serverdə əməliyyat sistemi, veb server, PHP versiyası, verilənlər bazası servisi və lazımi modullar qurulmalıdır. WordPress üçün PHP 8.2 və ya 8.3, güncəl MariaDB, OPcache və uyğun memory_limit dəyəri tövsiyə edilir. Laravel kimi frameworklərdə Composer, cron, queue worker və storage icazələri ayrıca tənzimlənməlidir. Köhnə serverdə işləyən PHP əlavələri yeni serverdə yoxdursa sayt daşındıqdan sonra ağ ekran və ya 500 xətası görünə bilər.

Təhlükəsizlik tərəfində SSH port siyasəti, güclü parollar, firewall, malware taraması və avtomatik yeniləmələr konfiqurasiya edilməlidir. Köçürmə öncəsi yeni server boşkən təhlükəsizlik təməlini qurmaq, sonradan müdaxilə etməkdən daha asandır. SSL ehtiyacınız varsa SSL sertifikatı qurulması mövzusunu köçürmə planına mütləq əlavə edin.

Addım 2: Faylları Köçürün

Fayl köçürməsi üçün sayt ölçüsünə görə FTP, SFTP, SSH, rsync və ya panel ehtiyat nüsxə istifadə edilə bilər. Kiçik saytlarda sıxışdırılmış arxiv yaradıb yeni serverdə açmaq kifayətdir. Böyük saytlarda isə rsync ilə ilk nüsxə alınıb DNS dəyişimindən dərhal əvvəl ikinci dəfə sinxronizasiya edilməsi tövsiyə olunur. Bu metod, xüsusilə upload qovluğu davamlı dəyişən saytlarda zaman qazandırar.

Fayl köçürməsindən sonra icazələri nəzarət edin. Ümumiyyətlə qovluqlar 755, fayllar 644 icazələri ilə işləyir; lakin hər tətbiqin ehtiyacı fərqli ola bilər. wp-config.php, .env və ya bənzəri həssas fayllar hər kəs tərəfindən oxuna bilər olmamalıdır. Həmçinin gizli faylların, yəni .htaccess və .user.ini kimi faylların kopyalandığından əmin olun.

Addım 3: Verilənlər Bazasını Daşıyın

Verilənlər bazası köçürməsi, məlumat itkisini önləmənin ən həssas bölümüdür. Əvvəlcə köhnə serverdən dump alınır, ardından yeni serverdə verilənlər bazası və istifadəçi yaradılır. Simvol dəsti mümkünsə utf8mb4 olaraq tənzimlənməlidir. Azərbaycan hərflərinin pozulmaması üçün export və import zamanı eyni collation quruluşu qorunmalıdır.

WooCommerce və ya üzvlük sistemi kimi anlıq məlumat istehsal edən saytlarda köçürmə zamanı texniki xidmət rejimi istifadə edilə bilər. Əks halda DNS yayılımı əsnasında bəzi istifadəçilər köhnə serverə, bəziləri yeni serverə məlumat yaza bilər. Bu da sifariş, şərh, forma qeydi və ya üzvlük məlumatlarında uyğunsuzluq yaradar. Kritik saytlarda son verilənlər bazası dump əməliyyatı, texniki xidmət rejimi açıldıqdan sonra alınmalıdır.

Addım 4: Konfiqurasiya Fayllarını Yeniləyin

Verilənlər bazası adı, istifadəçi adı, parol, host məlumatı və fayl yolları yeni serverə görə düzəldilməlidir. WordPress üçün wp-config.php, Laravel üçün .env, xüsusi tətbiqlər üçün config.php və ya bənzəri fayllar nəzarət edilir. Köhnə serverə aid mütləq fayl yolları, IP ünvanları, SMTP tənzimləmələri və ya cache qovluqları qalarsa sayt görünüşdə açıla bilər lakin arxa planda xəta istehsal edər.

Həmçinin PHP memory_limit, upload_max_filesize, post_max_size və max_execution_time dəyərləri tətbiqinizin ehtiyacına görə tənzimlənməlidir. Məsələn 200 MB məhsul görsəli yükləyən bir idarəetmə panelində upload limiti 32 MB qalarsa köçürmə müvəffəqiyyətli olsa belə əməliyyat davam edə bilməz.

Addım 5: DNS Dəyişdirmədən Əvvəl Test Edin

Ən etibarlı köçürmə praktikası, DNS dəyişdirmədən əvvəl yeni serverdə saytı test etməkdir. Bunun üçün kompüterinizdəki hosts faylına domen adınızı yeni server IP ünvanı ilə eşləyə bilərsiniz. Beləcə ziyarətçilər hələ də köhnə serveri görərkən siz gerçək domen adı ilə yeni serveri test edərsiniz.

Test siyahısı bu nəzarətləri ehtiva etməlidir:

• Ana səhifə, kateqoriya, məhsul, bloq və əlaqə səhifələri açılır?
• Forma göndərimi, üzv girişi, şifrə sıfırlama və ödəniş axını işləyir?
• Görsəllər, CSS və JavaScript faylları tam yüklənir?
• İdarəetmə paneli xəta vermədən açılır?
• SSL sertifikatı doğru domen adı üçün qurulub?
• 404, 500, mixed content və ya yönləndirmə döngüsü xətası var?
• robots.txt, sitemap.xml və canonical etiketləri doğrudur?

Addım 6: SSL Sertifikatını Qurun

Müasir veb saytlarda SSL sadəcə təhlükəsizlik deyil, SEO və istifadəçi etibarı baxımından da məcburidir. Yeni serverdə SSL qurulmadan DNS dəyişərsə istifadəçilər etibarlı deyil xəbərdarlığı görə bilər. Bu səbəbdən DNS keçidindən dərhal əvvəl və ya keçidlə eyni zamanlı olaraq SSL sertifikatı hazırlanmalıdır. Let’s Encrypt kimi pulsuz sertifikatlar bir çox sayt üçün kifayət ola bilər; ödəniş alan korporativ layihələrdə isə doğrulama səviyyəsi daha yüksək SSL seçimləri üstünlük qazana bilər.

SSL sonrası HTTP ünvanlarının HTTPS’ə 301 ilə yönləndiyindən, mixed content xətası olmadığından və sayt xəritəsində HTTPS URL’lərinin yer aldığından əmin olun. SSL məhsulları və qurulum seçimləri üçün SSL sertifikatları səhifəsinə göz ata bilərsiniz.

Addım 7: DNS Qeydlərini Dəyişdirin

Testlər müvəffəqiyyətlə tamamlandıqdan sonra DNS tərəfində A qeydi yeni server IP ünvanına yönləndirilir. Əgər e-poçt xidməti eyni serverdə daşınırsa MX, SPF, DKIM və DMARC qeydləri də yenilənməlidir. E-poçt fərqli bir təchizatçıda qalacaqsa MX qeydlərinə toxunmamaq lazımdır. Ən sıx edilən səhvlərdən biri, sadəcə veb saytı daşımaq istərkən e-poçt qeydlərini səhvən dəyişdirmək və poçt trafikini kəsməkdir.

DNS yayılımı ümumiyyətlə bir neçə dəqiqə ilə 24 saat arasında tamamlanar. TTL öncədən azaldıldıysa çoxu istifadəçi qısa müddətdə yeni serverə çatar. Bu müddətdə köhnə serveri dərhal bağlamayın. Ən az 48 saat, mümkünsə 72 saat əlçatan halda tutmaq etibarlı bir praktikadır.

Addım 8: Son Sinxronizasiyanı və Log Nəzarətini Edin

DNS dəyişikliyindən sonra köhnə serverə yazılmış yeni məlumat olub olmadığı nəzarət edilməlidir. Xüsusilə sifarişlər, əlaqə formaları, istifadəçi qeydləri və şərhlər müqayisə edilməlidir. Veb server access log və error log faylları, hansı IP’lərin hansı serverə istək göndərdiyini anlamağa kömək edər.

Köçürmə sonrası ilk 24 saat içində 500 xətaları, 404 artışı, yavaş sorğular, CPU sıçramaları və e-poçt növbələri izlənməlidir. Bu nəzarətlər edilməzsə sayt işləyir kimi görünər lakin arxa planda dönüşüm itkisi yaşana bilər.

Məlumat İtirmədən Sayt Daşımaq Üçün Peşəkar Nəzarət Siyahısı

Aşağıdakı nəzarət siyahısı, praktikada ən çox problem çıxaran nöqtələri əhatə edər. Köçürmə öncəsi və sonrası bu siyahını işarələmək, miqrasiya riskini ciddi ölçüdə azaldar.

• Köçürmə zamanı aşağı trafik saatlarına planlandı.
• Tam fayl, verilənlər bazası, e-poçt və DNS ehtiyat nüsxəsi alındı.
• Ehtiyat nüsxənin açıla bilər və geri yüklənə bilər olduğu test edildi.
• DNS TTL dəyəri ən az 24 saat əvvəl azaldıldı.
• Yeni serverdə PHP, verilənlər bazası və lazımi modullar hazırlandı.
• Fayllar tam köçürüldü və icazələr nəzarət edildi.
• Verilənlər bazası simvol dəsti və collation uyğunluğu doğrulandı.
• Config faylları yeni server məlumatlarına görə yeniləndi.
• Hosts faylı ilə canlıya almadan test edildi.
• SSL quruldu, HTTPS yönləndirmələri nəzarət edildi.
• DNS A, AAAA, MX, TXT qeydləri doğru şəkildə yeniləndi.
• Köhnə server ən az 48 saat aktiv tutuldu.
• Google Search Console, Analytics və log qeydləri izləndi.

SEO İtkisi Yaşamamaq Üçün Miqrasiya Sonrası Nəzarətlər

Server köçürmə, URL quruluşu dəyişmədiyi müddətcə nəzəri olaraq SEO itkisi yaratmamalıdır. Lakin praktikada yavaşlıq, 404 xətaları, yanlış robots.txt, əskik SSL və ya yönləndirmə xətaları sıralamaları təsir edə bilər. Bu səbəbdən köçürmə sonrası SEO nəzarəti texniki miqrasiya qədər əhəmiyyətlidir.

URL və Yönləndirmə Nəzarəti

Sayt daşıyarkən URL quruluşunu dəyişdirmirsinizsə 301 yönləndirmə ehtiyacı minimumdur. Lakin eyni anda domen adı, permalink quruluşu və ya qovluq quruluşu dəyişirsə köhnə URL’lər yeni qarşılıqlarına 301 ilə yönləndirilməlidir. 302 müvəqqəti yönləndirmə, SEO siqnallarının qalıcı köçürməsi üçün uyğun deyil. Məsələn köhnə /mehsul/abc səhifəsi yeni /magaza/abc ünvanına daşındıysa təkbətək yönləndirmə edilməlidir; bütün köhnə URL’ləri ana səhifəyə yönləndirmək istifadəçi təcrübəsini və SEO performansını mənfi təsir edər.

Robots.txt və Sitemap Nəzarəti

Test zamanı axtarış motorlarını əngəlləmək üçün robots.txt içində Disallow istifadə edildisə canlıya alınca qaldırılmalıdır. Bu səhv, köçürmə sonrası indeks itkisinin ən klassik səbəblərindən biridir. Sitemap faylında yeni HTTPS URL’ləri yer almalı, Google Search Console üzərindən təkrar göndərilməlidir.

Performans və Core Web Vitals

Yeni server daha güclü olsa belə yanlış cache tənzimləməsi performansı aşağı sala bilər. LiteSpeed Cache, Redis, OPcache, CDN və görsəl optimizasiyası doğru konfiqurasiya edilməlidir. Köçürmə sonrası ilk həftə PageSpeed Insights, Chrome UX Report və server logları izlənərək LCP, INP və CLS göstəricilərində pisləşmə olub olmadığı nəzarət edilməlidir. Hostinq performansını yaxşılaşdırmaq üçün WordPress sürət optimizasiyası məzmunlarından yararlana bilərsiniz.

E-Poçt Daşıma Əsnasında Diqqət Ediləcəklər

Bir çox sayt daşımasında veb fayllar problemsiz köçürülərkən e-poçt tərəfi gözdən qaçırılır. Əgər e-poçtlar mövcud serverdə tutulursa poçt qutuları, istifadəçi parolları, yönləndirmələr və filtrlər daşınmalıdır. IMAP sinxronizasiyası, köhnə qutudakı e-poçtları yeni qutuya köçürmək üçün etibarlı bir metodudur.

DNS tərəfində MX qeydi poçt serverini, SPF göndərim səlahiyyətini, DKIM imzalamanı, DMARC isə domen adı siyasətini müəyyən edər. Bu qeydlər yanlış konfiqurasiya edilərsə e-poçtlar spam qovluğuna düşə bilər və ya tamamilə rədd edilə bilər. Köçürmə sonrası Gmail, Outlook və korporativ poçt hesablarına test göndərimi edilməli; poçt header məlumatları nəzarət edilməlidir.

Tez-tez Edilən Server Köçürmə Səhvləri

Müvəffəqiyyətli miqrasiya layihələrində ortaq nöqtə, sadə səhvlərin öncədən önlənməsidir. Aşağıdakı səhvlər ən sıq qarşılaşılan problemlərdir:

• Ehtiyat nüsxə almadan və ya ehtiyat nüsxəni test etmədən köçürmə etmək.
• DNS TTL dəyərini azaltmadan IP dəyişdirmək.
• Köhnə serveri DNS yayılımı bitmədən bağlamaq.
• Verilənlər bazası simvol dəstini yanlış köçürmək və Azərbaycan hərflərini pozmaq.
• .htaccess və ya nginx yönləndirmə qaydalarını unutmaq.
• SSL qurmadan HTTPS trafikini yeni serverə yönləndirmək.
• E-poçt MX və TXT qeydlərini yanlış yeniləmək.
• Cache əlavəsini köhnə server yolu ilə buraxmaq.
• Köçürmə sonrası Search Console və log izləməsi etməmək.

Xüsusilə canlı satış edən saytlarda köçürmə əməliyyatı həftə içi iş saatı sıxlığında deyil, trafik və sifariş həcminin ən aşağı olduğu zaman aralığında edilməlidir. Böyük e-ticarət layihələrində 15-30 dəqiqəlik texniki xidmət pəncərəsi planlamaq, arxa planda yarana biləcək məlumat uyğunsuzluqlarını önləyər.

Nə Zaman Peşəkar Miqrasiya Dəstəyi Almalısınız?

Sadə bir tanıtım saytını əl ilə daşımaq mümkün ola bilər; lakin bəzi hallarda peşəkar dəstək almaq daha aşağı maliyyətli və daha etibarlıdır. Aylıq yüksək dövriyyə istehsal edən e-ticarət saytları, çox sayda e-poçt hesabı olan şirkətlər, xüsusi proqram istifadə edən portallar, yüksək trafikli media saytları və tənzimləməyə tabe məlumat saxlayan müəssisələr bu qrupa girər.

Peşəkar köçürmə dəstəyində proses ümumiyyətlə ön analiz, ehtiyat nüsxə, test mühiti qurulumu, köçürmə, DNS keçidi, doğrulama və izləmə addımlarından ibarətdir. Beləcə sadəcə fayllar deyil, iş davamlılığı da daşınmış olar. Hostragons infrastrukturuna keçməyi planlayırsınızsa ehtiyaclarınıza uyğun hostinq, domen və SSL seçimlərini birlikdə dəyərləndirmək üçün Hostragons hosting həlləri səhifəsini nəzərdən keçirə bilərsiniz.

Nəticə: Planlı Server Köçürmə Kəsintini və Məlumat İtkisini Önləyər

Server köçürmə, doğru planlandığında qorxulacaq bir əməliyyat deyil. Müvəffəqiyyətin açarı; tam ehtiyat nüsxə, doğru server hazırlığı, DNS TTL planı, test mühiti, SSL qurulumu, e-poçt nəzarətləri və köçürmə sonrası izləmə addımlarını atlamamaqdır. Xüsusilə verilənlər bazası davamlı dəyişən saytlarda son sinxronizasiya və texniki xidmət rejimi kritik rol oynayar.

Qısacası məlumat itkisi olmadan sayt daşımaq üçün tələsməyin, hər addımı doğrulayın və köhnə serveri dərhal bağlamayın. İnfrastrukturunuzu yeniləmək, daha sürətli və etibarlı bir veb təcrübəsi təqdim etmək istəyirsinizsə Hostragons üzərindəki hostinq, domen və SSL həllərini nəzərdən keçirə bilər; ehtiyaclarınıza uyğun keçid planını sakit və nəzarətli şəkildə yarada bilərsiniz.

Tez-tez Verilən Suallar

Server köçürmə nə qədər davam edər?

Müddət sayt ölçüsünə və mürəkkəbliyinə görə dəyişər. Kiçik bir WordPress saytı 30-60 dəqiqəyə daşına bilərkən, böyük e-ticarət və ya çox e-poçtlu korporativ layihələrdə hazırlıq, test və DNS yayılımı daxil proses 1-3 gün davam edə bilər.

Server köçürmə əsnasında saytım bağlanar?

Doğru planlama edilərsə kəsinti bir neçə dəqiqəyə endirilə bilər və ya istifadəçilər kəsinti hiss etməyə bilər. Bunun üçün DNS TTL öncədən azaldılmalı, yeni server canlıya alınmadan test edilməli və köhnə server DNS yayılımı tamamlanana qədər açıq tutulmalıdır.

Məlumat itkisi olmaması üçün ən əhəmiyyətli addım nədir?

Ən əhəmiyyətli addım doğrulanmış tam ehtiyat nüsxədir. Fayllar, verilənlər bazası, e-poçt və DNS qeydləri ehtiyat nüsxələnməli; xüsusilə sifariş və ya üzvlük məlumatı istehsal edən saytlarda son verilənlər bazası ehtiyat nüsxəsi texniki xidmət rejimi açıldıqdan sonra alınmalıdır.

Server köçürmə SEO sıralamalarını təsir edər?

URL quruluşu qorunar, sayt sürətli işləyər, SSL və yönləndirmələr doğru edilərsə server köçürmə tək başına SEO itkisinə səbəb olmaz. Lakin 404 xətaları, yanlış robots.txt, yavaş server və ya səhv 301 yönləndirmələri sıralamaları mənfi təsir edə bilər.

E-poçt hesabları da server köçürmə ilə daşınar?

Əgər e-poçtlar köhnə hostinq üzərində saxlanılırsa ayrıca daşınmalıdır. Poçt qutuları, yönləndirmələr, filtrlər və MX, SPF, DKIM, DMARC qeydləri nəzarət edilməlidir. E-poçt fərqli bir təchizatçıda qalacaqsa MX qeydləri dəyişdirilməməlidir.