Prenos strežnika (migracija) je načrtovan postopek prenosa datotek spletne strani, podatkovne baze, e-poštnih računov, DNS zapisov in nastavitev aplikacij iz obstoječega strežnika na nov strežnik. Osnovna metoda za prenos spletne strani brez izgube podatkov je naslednja: najprej se naredi popolna varnostna kopija, nov strežnik je pripravljen z enakimi ali novejšimi različicami programske opreme, datoteke in podatkovna baza se preneseta, testira se preko datoteke hosts ali začasne URL povezave, DNS preusmeritev se spremeni z nizkim TTL, in po prenosu se preverijo dnevniki, obrazci, postopki plačila, dostava e-pošte in SEO signali.
Postopek prenosa strežnika ni preprost postopek kopiranja in lepljenja. Zlasti za WordPress, WooCommerce, Laravel, posebne PHP aplikacije, visoko obremenjene novice ali podjetja, ki uporabljajo poslovno e-pošto, lahko napačen prenos povzroči izgubo naročil, pokvarjene znake v turščini, napake 500, SSL opozorila, prekinitev e-pošte in zmanjšanje vidnosti v iskalnikih. Zato je treba načrt migracije izvesti s tehničnim kontrolnim seznamom in scenarijem za vračilo.
V tem priročniku bomo korak za korakom obravnavali, kako izvesti spremembo gostovanja ali strežnika v skladu s pričakovanji SEO in zmogljivosti za leto 2026. Prav tako bomo obravnavali različne scenarije, kot so cPanel, Plesk, VPS, oblačni strežniki in ročni prenos; delili bomo uporabne nasvete za čas DNS, obseg varnostnih kopij, združljivost podatkovnih baz, namestitev SSL in SEO kontrole po prenosu.
Kdaj je potreben prenos strežnika?
Prenos spletne strani na nov strežnik običajno izhaja iz potreb po zmogljivosti, varnosti, stroških ali razširljivosti. Na primer, podjetniška stran z 5000 obiskovalci na mesec lahko brez težav deluje na deljenem gostovanju, medtem ko se na e-trgovinski strani z 20.000 obiskovalci na dan lahko pojavijo težave z omejitvijo CPU, počasnimi poizvedbami in izpadi na strani za plačilo. V tem primeru je priporočljivo izbrati močnejši paket gostovanja, VPS ali oblačno infrastrukturo.
Pogosti znaki, da je potreben prenos strežnika, vključujejo:
- Čas nalaganja strani, ki presega 3 sekunde in poslabšanje metrik Core Web Vitals.
- Omejitve uporabe CPU, RAM, inode ali diska se pogosto dosežejo v nadzornem panelu.
- Potreba po posodobljenih različicah komponent, kot so PHP, MySQL, MariaDB, Node.js ali ionCube.
- Pogoste težave s podaljšanjem SSL, dostavo e-pošte ali upravljanjem DNS.
- Nizka kakovost podpore, varnostne ravni ali varnostne kopije pri obstoječem ponudniku.
- Nehoteno povečanje prometa na spletni strani med kampanjami, oglaševanjem ali sezonskimi obdobji.
Če vaša spletna stran raste in se približuje omejitvam trenutnega paketa, je veliko bolj varno ustvariti nadzorovan načrt migracije, namesto da bi se v zadnjem trenutku spopadli s krizno situacijo. Glede na vaše potrebe lahko primerjate pakete gostovanja, VPS strežniške rešitve ali poslovno gostovanje in izberete pravo infrastrukturo.
Priprava pred prenosom: Najpomembnejša faza
Večina projektov prenosa, pri katerih pride do izgube podatkov, ne propade med prenosom, temveč zaradi pomanjkanja priprave. Pred prenosom je treba sestaviti inventar obstoječe spletne strani, jasno opredeliti, kateri podatki bodo preneseni in kateri storitvi so občutljivi na prekinitev.
1. Ustvarite inventar spletne strani
Prvi korak je ustvarjanje tehnične karte spletne strani. Zabeležiti je treba uporabljeni CMS ali ogrodje, različico PHP, vrsto podatkovne baze, velikost diska, e-poštne račune, naloge cron, DNS zapise, SSL certifikate, posebne preusmeritve in integracije tretjih oseb. Na primer, pri WordPress strani ni dovolj, da prenesete samo mapo wp-content; treba je preveriti pravila .htaccess, nastavitve wp-config.php, predpone tabel podatkovne baze, vtičnike za predpomnjenje in medijske datoteke.
Na e-trgovinski strani je treba dodatno preveriti plačilno infrastrukturo, integracijo dostave, sinhronizacijo zaloge, povezavo z ERP, SMTP storitev in URL naslove za webhooke. Če po prenosu ne prejemate naročil, je težava pogosto v prenosu datotek, ampak v pozabljeni omejitvi IP API ali varnostnem pravilniku, ki je bil določen na starem strežniku.
2. Naredite popolno varnostno kopijo in jo preverite
Pri prenosu strežnika samo izdelava varnostne kopije ni dovolj; treba je tudi preveriti, ali je varnostna kopija mogoče obnoviti. Popolna varnostna kopija mora vključevati:
- Datoteke spletne strani: public_html, mape aplikacij, mape za nalaganje, tematske in vtičnik datoteke.
- Podatkovne baze: MySQL, MariaDB, PostgreSQL ali druge podatkovne baze, ki jih uporablja aplikacija.
- Podatki o e-pošti: poštni predali, preusmeritve, filtri, nastavitve avto-odgovora.
- DNS zapisi: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC zapisi.
- Nastavitve: .htaccess, nginx.conf, php.ini, cron naloge, okoljske datoteke.
- SSL certifikati in posebna varnostna pravila.
Kot praktičen pristop je priporočljivo pred prenosom narediti vsaj dve kopiji varnostnih kopij: ena naj bo na obstoječem strežniku, druga pa shranjena na drugem mestu. Pri večjih straneh se za varnostno kopiranje datotek lahko uporabi rsync, za podatkovne baze mysqldump ali orodja za varnostno kopiranje v nadzornem panelu. Pri podatkovnih bazah, večjih od 10 GB, so lahko stisnjene in razdeljene varnostne kopije bolj varne kot enotne dump datoteke.
3. Zmanjšajte vrednost TTL DNS vnaprej
Za hitro širjenje DNS sprememb je dobra praksa, da se vrednost TTL zmanjša 24 ur pred prenosom. Na primer, če je vrednost TTL 14400 sekund, lahko nekateri uporabniki še vedno dostopajo do starega strežnika še ure. Zmanjšanje vrednosti TTL na 300 sekund pred prenosom omogoča bolj nadzorovano preusmeritev DNS. Ko je prenos končan in vse potrjeno, lahko vrednost TTL ponovno povečate na 3600 ali 14400 sekund.
Redno upravljanje DNS vašega domenskega imena neposredno vpliva na uspeh migracije. Za informacije o upravljanju domen in DNS si lahko ogledate vodnik za preverjanje domene in upravljanje domene.
Primerjava metod prenosa strežnika
Najboljša metoda prenosa ni enaka za vse strani. Medtem ko se lahko majhna poslovna stran enostavno prenese preko nadzornega panela, lahko visoko obremenjena e-trgovinska stran zahteva postopno sinhronizacijo in način vzdrževanja.
| Metoda | Primerni za | Prednosti | Na kaj biti pozoren |
|---|---|---|---|
| Prenos preko nadzornega panela | Majhne in srednje strani, ki uporabljajo cPanel, Plesk ali DirectAdmin | Hitro, praktično, samodejno prenaša večino nastavitev | Različice nadzornega panela in omejitve paketov morajo biti združljive |
| Ročni prenos datotek in podatkovne baze | WordPress, Laravel, posebne PHP aplikacije | Visoka stopnja nadzora | Preveriti je treba dovoljenja datotek, nabor znakov in nastavitve konfiguracije |
| Prenos s pomočjo Rsync | Strani z velikimi arhivi datotek ali bogato vsebino medijev | Hitro sinhronizira spremenjene datoteke | Zahteva SSH dostop in pravilne parametre |
| Postopna migracija | E-trgovina, članstvo, rezervacije in novičarske strani | Zmanjšuje tveganje za izpad in izgubo podatkov | Čas zadnje sinhronizacije je treba dobro načrtovati |
| Strokovna podpora pri prenosu | Podjetja s kritičnimi poslovnimi procesi | Vključuje analizo tveganja in načrt vračila | Predhodni raziskovalni podatki morajo biti popolno deljeni |
Pri izbiri nove infrastrukture ni dovolj, da gledate samo na prostor na disku. Število PHP delavcev, jedra CPU, RAM, NVMe disk, pogostost varnostnih kopij, lokacija podatkovnega centra, podpora za LiteSpeed ali Nginx, WAF in zaščita pred DDoS tudi določajo zmogljivost. Zato lahko prehod na najcenejši paket brez analize potreb povzroči potrebo po ponovnem prenosu v kratkem času.
Kakšne so korake za prenos strežnika?
Korak 1: Pripravite nov strežnik
Na novem strežniku je treba namestiti operacijski sistem, spletni strežnik, različico PHP, storitev podatkovne baze in potrebne module. Za WordPress se priporoča PHP 8.2 ali 8.3, posodobljen MariaDB, OPcache in ustrezna vrednost memory_limit. Pri ogrodjih, kot je Laravel, je treba prav tako nastaviti Composer, cron, delavca vrste in dovoljenja za shranjevanje. Če stari strežnik uporablja PHP dodatke, ki jih na novem strežniku ni, se lahko po prenosu prikaže beli zaslon ali napaka 500.
Na varnostnem vidiku je treba nastaviti politiko SSH za vrata, močna gesla, požarni zid, skeniranje zlonamerne programske opreme in samodejna posodabljanja. Vzpostavitev osnovne varnosti, ko je nov strežnik prazen pred prenosom, je lažje kot kasnejše posredovanje. Če potrebujete SSL, dodajte temo namestitev SSL certifikata v načrt prenosa.
Korak 2: Prenesite datoteke
Za prenos datotek se lahko glede na velikost spletne strani uporablja FTP, SFTP, SSH, rsync ali orodje za varnostne kopije v nadzornem panelu. Pri manjših straneh je dovolj ustvariti stisnjen arhiv in ga odpreti na novem strežniku. Pri večjih straneh je priporočljivo, da se z rsync najprej izvede prva kopija, nato pa se tik pred spremembo DNS izvede druga sinhronizacija. Ta metoda pri straneh, kjer se mapa za nalaganje nenehno spreminja, prihrani čas.
Po prenosu datotek preverite dovoljenja. Na splošno delujejo mape z dovoljenji 755, datoteke pa 644; vendar so potrebe vsake aplikacije lahko različne. Datoteke, kot so wp-config.php, .env ali podobne občutljive datoteke, ne smejo biti dostopne vsem. Prav tako se prepričajte, da so kopirane skrite datoteke, kot so .htaccess in .user.ini.
Korak 3: Prenesite podatkovno bazo
Prenos podatkovne baze je najobčutljivejši del, ki preprečuje izgubo podatkov. Najprej se iz starega strežnika izvede dump, nato se na novem strežniku ustvari podatkovna baza in uporabnik. Nabor znakov je treba nastaviti na utf8mb4, kolikor je mogoče. Da se prepreči pokvaritev turških znakov, je treba med izvozom in uvozom ohraniti enako strukturo collation.
Pri straneh, ki proizvajajo trenutne podatke, kot so WooCommerce ali sistemi članstva, se lahko med prenosom uporabi način vzdrževanja. V nasprotnem primeru lahko med širjenjem DNS nekateri uporabniki pišejo podatke na stari strežnik, nekateri pa na nov. To lahko povzroči neskladje v naročilih, komentarjih, zapisih obrazcev ali informacijah o članstvu. Pri kritičnih straneh je treba zadnji postopek dump podatkovne baze izvesti po aktivaciji načina vzdrževanja.
Korak 4: Posodobite konfiguracijske datoteke
Ime podatkovne baze, uporabniško ime, geslo, informacije o gostitelju in poti do datotek je treba prilagoditi novemu strežniku. Za WordPress se preveri wp-config.php, za Laravel .env, za posebne aplikacije config.php ali podobne datoteke. Če ostanejo absolutne poti do datotek, IP naslovi, nastavitve SMTP ali mape za predpomnjenje iz starega strežnika, se bo spletna stran morda odprla, vendar bo v ozadju povzročila napake.
Poleg tega je treba vrednosti PHP memory_limit, upload_max_filesize, post_max_size in max_execution_time prilagoditi potrebam vaše aplikacije. Na primer, če ima upravni panel omejitev nalaganja 32 MB in nalaga slike produktov, ki so 200 MB velike, se prenos lahko izvede uspešno, vendar se poslovanje ne more nadaljevati.
Korak 5: Testirajte pred spremembo DNS
Najbolj varna praksa prenosa je testiranje nove spletne strani na novem strežniku pred spremembo DNS. To lahko storite tako, da v datoteko hosts na vašem računalniku dodelite svoje domeno novi IP naslov strežnika. Tako boste lahko testirali nov strežnik s pravo domeno, medtem ko bodo obiskovalci še vedno dostopali do starega strežnika.
Testna lista mora vključevati naslednje kontrole:
- Ali se odpirajo domača stran, kategorije, izdelki, blog in kontaktne strani?
- Ali delujejo pošiljanje obrazcev, prijava uporabnikov, ponastavitev gesla in postopek plačila?
- Ali se vsi mediji, CSS in JavaScript datoteke naložijo brez težav?
- Ali se nadzorni panel odpre brez napak?
- Ali je SSL certifikat pravilno nameščen za pravo domeno?
- Ali obstajajo napake 404, 500, napake mešanih vsebin ali napake v preusmeritvah?
- Ali so robots.txt, sitemap.xml in kanonične oznake pravilne?
Korak 6: Namestite SSL certifikat
Na sodobnih spletnih straneh je SSL obvezen ne samo za varnost, temveč tudi zaradi SEO in zaupanja uporabnikov. Če se DNS spremeni pred namestitvijo SSL na novem strežniku, lahko uporabniki vidijo opozorilo, da ni varno. Zato je treba pripraviti SSL certifikat tik pred ali sočasno z DNS preusmeritvijo. Brezplačni certifikati, kot je Let’s Encrypt, so lahko dovolj za mnoge strani; za plačljive korporativne projekte so na voljo tudi certifikati z višjo stopnjo potrditve.
Prepričajte se, da se HTTP naslovi po SSL preusmerijo na HTTPS s 301, da ni napak mešanih vsebin in da so URL-ji HTTPS vključeni v zemljevid spletne strani. Za SSL produkte in možnosti namestitve si lahko ogledate SSL certifikati.
Korak 7: Spremenite DNS zapise
Ko so testi uspešno zaključeni, se A zapis na DNS preusmeri na nov IP naslov strežnika. Če se e-poštna storitev prenaša na enak strežnik, je treba posodobiti tudi zapise MX, SPF, DKIM in DMARC. Če ostane e-pošta pri drugem ponudniku, se zapisi MX ne smejo spreminjati. Ena izmed najpogostejših napak je, da se med prenosom spletne strani pomotoma spremenijo e-poštni zapisi in s tem prekinitev e-poštnega prometa.
Širitev DNS običajno traja od nekaj minut do 24 ur. Če je bil TTL prej znižan, večina uporabnikov hitro doseže nov strežnik. V tem času starega strežnika takoj ne izklopite. Varno je, da ostane aktiven vsaj 48 ur, po možnosti 72 ur.
Korak 8: Opravite zadnjo sinhronizacijo in preverjanje dnevnika
Po spremembi DNS je treba preveriti, ali so na starem strežniku zapisani novi podatki. Zlasti je treba primerjati naročila, obrazce za stik, uporabniške registre in komentarje. Dnevniki dostopa in napak spletnega strežnika pomagajo razumeti, kateri IP naslovi so pošiljali zahteve kateremu strežniku.
V prvih 24 urah po prenosu je treba spremljati napake 500, povečanje napak 404, počasne poizvedbe, skoke CPU in čakalne vrste e-pošte. Če teh kontrol ne izvedete, se lahko spletna stran zdi delujoča, vendar se lahko v ozadju zgodi izguba konverzije.
Kontrolni seznam za prenos spletne strani brez izgube podatkov
Spodnji kontrolni seznam zajema točke, ki najpogosteje povzročajo težave. Označevanje tega seznama pred in po prenosu drastično zmanjša tveganje migracije.
- Čas prenosa je bil načrtovan v urah z nizkim prometom.
- Popolne varnostne kopije datotek, podatkovnih baz, e-pošt in DNS so bile izdelane.
- Preverjeno je bilo, ali je varnostna kopija mogoče obnoviti.
- Vrednost TTL DNS je bila znižana vsaj 24 ur pred prenosom.
- Na novem strežniku so bili pripravljeni PHP, podatkovna baza in potrebni moduli.
- Datoteke so bile uspešno prenesene in preverjena so bila dovoljenja.
- Usklajenost niza znakov in collation podatkovne baze je bila potrjena.
- Konfiguracijske datoteke so bile posodobljene glede na nove strežniške informacije.
- Testi so bili opravljeni brez preusmeritve na spletno stran.
- SSL je bil nameščen in preverjene so bile preusmeritve HTTPS.
- DNS A, AAAA, MX, TXT zapisi so bili pravilno posodobljeni.
- Stari strežnik je bil aktiven vsaj 48 ur.
- Google Search Console, Analytics in dnevniki so bili spremljani.
Kontrole po migraciji za preprečitev izgube SEO
Prenos strežnika ne bi smel povzročiti izgube SEO, če se struktura URL ne spremeni. Vendar pa lahko v praksi počasnost, napake 404, napačen robots.txt, manjkajoč SSL ali napake pri preusmeritvah vplivajo na uvrstitve. Zato je nadzor SEO po prenosu enako pomemben kot tehnična migracija.
Kontrola URL in preusmeritev
Če med prenosom ne spreminjate strukture URL, je potreba po preusmeritvah 301 minimalna. V primeru spremembe domene, strukture permalinkov ali mape je treba stare URL-je preusmeriti na nove ustrezne URL-je s 301. Preusmeritev 302 ni primerna za stalni prenos SEO signalov. Na primer, če je stara stran /izdelek/abc preusmerjena na novo /trgovina/abc, je potrebno narediti točno preusmeritev; preusmeritev vseh starih URL-jev na domačo stran slabi uporabniško izkušnjo in SEO zmogljivost.
Kontrola robots.txt in zemljevida spletne strani
Če je bil med testiranjem uporabljen robots.txt za blokiranje iskalnikov, ga je treba po prenosu odstraniti. Ta napaka je eden izmed klasičnih razlogov za izgubo indeksiranja po prenosu. V datoteki zemljevida spletne strani morajo biti novi URL-ji HTTPS, ki jih je treba ponovno poslati preko Google Search Console.
Zmogljivost in Core Web Vitals
Čeprav je nov strežnik močnejši, lahko napačna nastavitev predpomnilnika zmanjša zmogljivost. LiteSpeed Cache, Redis, OPcache, CDN in optimizacija slik morajo biti pravilno nastavljeni. V prvem tednu po prenosu je treba spremljati PageSpeed Insights, Chrome UX Report in dnevnike strežnika, da se preveri, ali je prišlo do poslabšanja metrik LCP, INP in CLS. Za izboljšanje zmogljivosti gostovanja lahko izkoristite optimizacija hitrosti WordPress.
Kaj je treba upoštevati pri prenosu e-pošte
Med prenosom spletnih strani se pogosto pozabi na e-poštne strani, medtem ko so datoteke spletne strani uspešno prenesene. Če se e-pošta hrani na obstoječem strežniku, je treba prenesti poštne predale, uporabniška gesla, preusmeritve in filtre. IMAP sinhronizacija je zanesljiva metoda za prenos e-pošt iz starega predala v novega.
Na strani DNS zapis MX določa e-poštni strežnik, SPF pooblastila za pošiljanje, DKIM podpisovanje in DMARC politiko domene. Če so ti zapisi nepravilno konfigurirani, lahko e-pošta pade v mape z neželeno pošto ali pa je zavrnjena. Po prenosu je treba poslati testne e-pošte na Gmail, Outlook in poslovne e-poštne račune ter preveriti informacije o glavah e-pošte.
Pogoste napake pri prenosu strežnika
Skupna značilnost uspešnih migracijskih projektov je preprečevanje preprostih napak vnaprej. Naslednje napake so najpogosteje srečane težave:
- Prenos brez varnostne kopije ali brez preverjanja varnostne kopije.
- Sprememba IP brez zmanjšanja vrednosti TTL DNS.
- Izklop starega strežnika pred koncem širjenja DNS.
- Napačen prenos znakov podatkovne baze in pokvaritev turških znakov.
- Pomanjkanje preusmeritvenih pravil .htaccess ali nginx.
- Preusmeritev HTTPS prometa na nov strežnik brez SSL.
- Napačna posodobitev zapisov MX in TXT za e-pošto.
- Pustitev predpomnilnika preko starega strežnika.
- Ne spremljanje Search Console in dnevnikov po prenosu.
Še posebej pri spletnih straneh, ki izvajajo prodajo, je treba prenos izvesti v času, ko je promet in obseg naročil najnižji, ne pa v času največje obremenitve. Pri velikih e-trgovinskih projektih je priporočljivo načrtovati 15-30 minutno obdobje vzdrževanja, da se preprečijo morebitne neskladnosti podatkov v ozadju.
Kdaj bi morali poiskati strokovno pomoč pri prenosu?
Preprosto promocijsko stran je mogoče ročno prenesti; v nekaterih primerih pa je bolj smiselno poiskati strokovno pomoč, ki je lahko cenejša in varnejša. E-trgovinske strani z visokimi mesečnimi prihodki, podjetja z veliko e-poštnimi računi, portali, ki uporabljajo posebno programsko opremo, visoko obremenjene medijske strani in podjetja, ki hranijo regulirane podatke, spadajo v to kategorijo.
Strokovna podpora pri prenosu običajno vključuje predanalizo, varnostno kopiranje, postavitev testnega okolja, prenos, preusmeritev DNS, preverjanje in spremljanje. Tako se ne prenašajo le datoteke, temveč tudi kontinuiteta poslovanja. Če razmišljate o prehodu na infrastrukturo Hostragons, si lahko ogledate gostitvene rešitve Hostragons, da skupaj ocenite možnosti gostovanja, domene in SSL, ki ustrezajo vašim potrebam.
Zaključek: Načrtovan prenos strežnika preprečuje izpad in izgubo podatkov
Prenos strežnika ni postopek, katerega bi se bilo treba bati, če je pravilno načrtovan. Ključ do uspeha je, da ne pozabite na popolno varnostno kopijo, pravilno pripravo strežnika, načrt TTL DNS, testno okolje, namestitev SSL, preverjanje e-pošte in korake spremljanja po prenosu. Zlasti pri spletnih straneh, kjer se podatkovna baza nenehno spreminja, je zadnja sinhronizacija in način vzdrževanja odločilnega pomena.
Na kratko, da bi prenesli spletno stran brez izgube podatkov, ne hitite, preverite vsak korak in ne izklapljajte starega strežnika takoj. Če želite posodobiti svojo infrastrukturo in ponuditi hitrejšo in varnejšo spletno izkušnjo, lahko raziščete rešitve za gostovanje, domene in SSL na Hostragons in mirno ter nadzorovano razvijete načrt prehoda, ki ustreza vašim potrebam.
Pogosta vprašanja
Koliko časa traja prenos strežnika?
Čas tranja se razlikuje glede na velikost in kompleksnost strani. Majhna WordPress stran se lahko prenese v 30-60 minutah, medtem ko lahko pri večjih e-trgovinskih ali korporativnih projektih, ki imajo veliko e-poštnih računov, priprava, testiranje in širjenje DNS vključujejo postopek, ki traja 1-3 dni.
Ali se moja stran med prenosom izklopi?
Če je načrtovanje pravilno izvedeno, lahko izpad traja le nekaj minut ali pa ga uporabniki sploh ne opazijo. Za to je treba vnaprej znižati TTL DNS, testirati nov strežnik pred preusmeritvijo in ohraniti star strežnik odprt, dokler se širitev DNS ne zaključi.
Kateri je najpomembnejši korak za preprečitev izgube podatkov?
Najpomembnejši korak je preverjena popolna varnostna kopija. Datoteke, podatkovne baze, e-pošta in DNS zapisi morajo biti varnostno kopirani; zlasti na straneh, ki proizvajajo podatke o naročilih ali članstvu, je treba zadnjo varnostno kopijo podatkovne baze narediti po aktivaciji načina vzdrževanja.
Ali prenos strežnika vpliva na SEO uvrstitve?
Če se struktura URL ohrani, spletna stran deluje hitro, SSL in preusmeritve so pravilno izpeljane, prenos strežnika sam po sebi ne bi smel povzročiti izgube SEO. Vendar pa lahko napake 404, napačen robots.txt, počasni strežnik ali napačne 301 preusmeritve negativno vplivajo na uvrstitve.
Ali se e-poštni računi prenašajo skupaj s prenosom strežnika?
Če se e-pošta hrani na starem gostovanju, jo je treba prav tako prenesti. Poštni predali, preusmeritve, filtri ter zapisi MX, SPF, DKIM in DMARC morajo biti preverjeni. Če e-pošta ostane pri drugem ponudniku, zapisi MX ne smejo biti spremenjeni.