Szerver migráció lépésről lépésre: Hogyan költöztess weboldalt adatvesztés nélkül?

A szerver migráció egy weboldal fájljainak, adatbázisának, e-mail fiókjainak, DNS rekordjainak és alkalmazásbeállításainak tervezett átvitele a meglévő szerverről az új szerverre. Az adatvesztés nélküli weboldal-költöztetés alapvető módszere a következő: először teljes biztonsági mentést kell készíteni, az új szervert azonos vagy újabb szoftververziókkal kell előkészíteni, a fájlokat és az adatbázist át kell vinni, a hosts fájl vagy egy ideiglenes URL segítségével tesztelni kell, a DNS átirányítást alacsony TTL értékkel kell módosítani, majd a migráció után ellenőrizni kell a logokat, űrlapokat, fizetési folyamatokat, az e-mail kézbesítést és a SEO jelzéseket.

A szerver migráció nem egy egyszerű másolás-beillesztés folyamat. Különösen WordPress, WooCommerce, Laravel, egyedi PHP alkalmazások, nagy forgalmú hírportálok vagy vállalati e-mailt használó cégek esetében egy hibás költöztetés olyan következményekkel járhat, mint a rendelésvesztés, sérült ékezetes karakterek, 500-as hibák, SSL figyelmeztetések, e-mail leállás és a keresőmotoros láthatóság csökkenése. Ezért a migrációs tervet egy technikai ellenőrzőlistával és visszaállítási forgatókönyvvel együtt kell végrehajtani.

Ebben az útmutatóban lépésről lépésre végigvesszük, hogyan hajthatsz végre egy tárhely- vagy szervercserét a 2026-os SEO és teljesítményelvárásoknak megfelelően. Kitérünk továbbá a cPanel, Plesk, VPS, felhő szerver és manuális migráció különböző forgatókönyveire, és gyakorlatias tanácsokat adunk a DNS átfutási időre, a biztonsági mentés terjedelmére, az adatbázis-kompatibilitásra, az SSL telepítésére és a migráció utáni SEO ellenőrzésekre vonatkozóan.

Mikor van szükség szerver migrációra?

Egy weboldal új szerverre költöztetésének igénye általában teljesítménybeli, biztonsági, költség- vagy skálázhatósági okokból merül fel. Például egy havi 5.000 látogatóval rendelkező céges weboldal problémamentesen működhet megosztott tárhelyen, míg egy napi 20.000 látogatót vonzó webáruház esetében CPU limit, lassú lekérdezések és a fizetési oldalon időtúllépési hibák jelentkezhetnek. Ezen a ponton egy erősebb tárhelycsomag, VPS vagy felhő infrastruktúra válik szükségessé.

A szerver migráció szükségességére utaló gyakori jelek a következők:

• Az oldalbetöltési idő 3 másodperc fölé emelkedik, és a Core Web Vitals mutatók romlanak.
• A tárhely vezérlőpultjában a CPU, RAM, inode vagy lemezhasználati limitek gyakran betelnek.
• PHP, MySQL, MariaDB, Node.js vagy ionCube komponensek frissebb verziójára van szükség.
• Gyakori problémák merülnek fel az SSL megújítással, az e-mail kézbesítéssel vagy a DNS kezeléssel kapcsolatban.
• A jelenlegi szolgáltató támogatási minősége, biztonsági mentési vagy védelmi szintje elégtelen.
• Az oldal forgalma kampányok, hirdetések vagy szezonális időszakok alatt hirtelen megnő.

Ha az oldalad növekszik és megközelíti a jelenlegi csomag korlátait, sokkal biztonságosabb egy ellenőrzött migrációs tervet készíteni, mint az utolsó pillanatban, krízishelyzetben költöztetni. Igényeidtől függően összehasonlíthatod a Web hosting csomagok, VPS szervermegoldások vagy Vállalati Hosting lehetőségeket a megfelelő infrastruktúra kiválasztásához.

Felkészülés a migráció előtt: A legkritikusabb szakasz

Az adatvesztéssel járó migrációs projektek nagy része nem az átvitel során, hanem a felkészülés hiánya miatt vall kudarcot. A költöztetés megkezdése előtt fel kell mérni a meglévő oldal leltárát, és tisztázni kell, mely adatok kerülnek átvitelre, és mely szolgáltatások érzékenyek a kiesésre.

1. Készíts weboldal-leltárt

Az első lépés a weboldal technikai térképének elkészítése. Fel kell jegyezni a használt CMS-t vagy keretrendszert, a PHP verziót, az adatbázis típusát, a lemezterület méretét, az e-mail fiókokat, a cron feladatokat, a DNS rekordokat, az SSL tanúsítványt, az egyedi átirányításokat és a harmadik féltől származó integrációkat. Például egy WordPress oldalnál nem elég csupán a wp-content mappát átvinni; ellenőrizni kell a .htaccess szabályokat, a wp-config.php beállításait, az adatbázis tábla előtagokat, a gyorsítótár bővítményeket és a médiafájlokat is.

Egy webáruház esetében pedig külön meg kell vizsgálni a fizetési infrastruktúrát, a szállítási integrációt, a készletszinkronizációt, az ERP kapcsolatot, az SMTP szolgáltatást és a webhook URL címeket. Ha a migráció után nem érkeznek rendelések, a probléma legtöbbször nem a fájlátvitelben, hanem egy elfelejtett API IP korlátozásban vagy a régi szerveren beállított biztonsági szabályban keresendő.

2. Készíts teljes biztonsági mentést és ellenőrizd

A szerver migráció során önmagában a biztonsági mentés készítése nem elegendő; azt is ellenőrizni kell, hogy a mentés visszaállítható-e. A teljes biztonsági mentésnek a következő összetevőkre kell kiterjednie:

• Weboldal fájlok: public_html, alkalmazás mappák, feltöltési könyvtárak, téma és bővítmény fájlok.
• Adatbázisok: MySQL, MariaDB, PostgreSQL vagy az alkalmazás által használt egyéb adatbázisok.
• E-mail adatok: postafiókok, átirányítások, szűrők, automatikus válaszok beállításai.
• DNS rekordok: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC rekordok.
• Konfigurációs fájlok: .htaccess, nginx.conf, php.ini, cron job, environment fájlok.
• SSL tanúsítványok és egyedi biztonsági szabályok.

Gyakorlati megközelítésként a migráció előtt legalább két másolatot készíts a mentésből: az egyiket a jelenlegi szerveren tárold, a másikat egy eltérő helyszínen. Nagyobb oldalaknál a fájlmentéshez rsync, az adatbázishoz mysqldump vagy panel alapú mentési eszközök használhatók. 10 GB feletti adatbázisoknál az egy darab dump helyett a tömörített és darabolt mentések biztonságosabbak lehetnek.

3. Csökkentsd a DNS TTL értékét előre

A DNS változás gyors elterjedése érdekében jó gyakorlat a TTL érték csökkentése 24 órával a migráció előtt. Például ha a TTL érték 14400 másodperc, egyes felhasználók órákig a régi szerverre irányulhatnak. A TTL érték 300 másodpercre csökkentése a migráció előtt kontrolláltabbá teszi a DNS átállást. Miután a költöztetés befejeződött és minden ellenőrzésre került, a TTL visszaállítható 3600 vagy 14400 másodpercre.

A domain neved DNS kezelésének rendszeres karbantartása közvetlenül befolyásolja a migráció sikerét. A domain és DNS konfigurációhoz tanulmányozhatod a Domain ellenőrzés és domain kezelés útmutatókat.

Szerver migrációs módszerek összehasonlítása

Nem minden oldal számára ugyanaz a legmegfelelőbb migrációs módszer. Egy kis céges weboldal könnyedén átköltöztethető panelen keresztül, míg egy nagy forgalmú webáruháznál fokozatos szinkronizációra és karbantartási módra lehet szükség.

Az új infrastruktúra kiválasztásakor félrevezető lehet csak a lemezterületet nézni. A PHP worker szám, CPU mag, RAM, NVMe tárhely, biztonsági mentés gyakorisága, adatközpont elhelyezkedése, LiteSpeed vagy Nginx támogatás, WAF és DDoS védelem szintén meghatározzák a teljesítményt. Ezért igényfelmérés nélkül a legolcsóbb csomagra váltani rövid időn belül újabb migrációs kényszert szülhet.

Hogyan végezd el a szerver migrációt lépésről lépésre?

1. Lépés: Készítsd elő az új szervert

Az új szerveren telepíteni kell az operációs rendszert, a webszervert, a PHP verziót, az adatbázis szolgáltatást és a szükséges modulokat. WordPress esetén PHP 8.2 vagy 8.3, friss MariaDB, OPcache és megfelelő memory_limit érték javasolt. Laravel keretrendszernél a Composer, cron, queue worker és a storage jogosultságok külön beállítandók. Ha a régi szerveren működő PHP kiterjesztések hiányoznak az új szerverről, a költöztetés után fehér képernyő vagy 500-as hiba jelentkezhet.

Biztonsági oldalon az SSH port politika, erős jelszavak, tűzfal, malware ellenőrzés és automatikus frissítések konfigurálása szükséges. A migráció előtt, amikor az új szerver még üres, könnyebb kiépíteni a biztonsági alapokat, mint utólag beavatkozni. Ha SSL-re van szükséged, mindenképpen építsd be a migrációs tervbe a SSL tanúsítvány telepítése témakörét.

2. Lépés: Fájlok átvitele

A fájlátvitelhez az oldal méretétől függően FTP, SFTP, SSH, rsync vagy panel alapú mentés használható. Kis oldalaknál elegendő egy tömörített archívumot létrehozni és az új szerveren kicsomagolni. Nagyobb oldalaknál javasolt az rsync használata az első másolat elkészítéséhez, majd közvetlenül a DNS csere előtt egy második szinkronizáció végrehajtása. Ez a módszer különösen időt takarít meg a folyamatosan változó feltöltési mappával rendelkező oldalaknál.

A fájlátvitel után ellenőrizd a jogosultságokat. Általánosságban a mappák 755, a fájlok 644 jogosultsággal működnek; azonban minden alkalmazás igénye eltérő lehet. A wp-config.php, .env vagy hasonló érzékeny fájlok nem lehetnek mindenki által olvashatók. Győződj meg arról is, hogy a rejtett fájlok, mint a .htaccess és .user.ini, szintén átmásolásra kerültek.

3. Lépés: Adatbázis migrációja

Az adatbázis átvitele a legérzékenyebb része az adatvesztés megelőzésének. Először a régi szerverről dump készül, majd az új szerveren létrejön az adatbázis és a felhasználó. A karakterkódolást lehetőség szerint utf8mb4-re kell állítani. Az ékezetes karakterek sérülésének elkerülése érdekében az exportálás és importálás során ugyanazt a rendezési (collation) struktúrát kell megőrizni.

WooCommerce vagy tagsági rendszer esetén, ahol valós idejű adatkeletkezés van, a migráció alatt karbantartási mód használható. Ellenkező esetben a DNS propagáció alatt egyes felhasználók a régi, mások az új szerverre írhatnak adatokat. Ez inkonzisztenciát okoz a rendelésekben, hozzászólásokban, űrlap beküldésekben vagy tagsági adatokban. Kritikus oldalaknál az utolsó adatbázis dumpot a karbantartási mód bekapcsolása után kell elkészíteni.

4. Lépés: Konfigurációs fájlok frissítése

Az adatbázis nevet, felhasználónevet, jelszót, hoszt információt és fájl elérési utakat az új szervernek megfelelően kell módosítani. WordPress esetén a wp-config.php, Laravelnél az .env, egyedi alkalmazásoknál a config.php vagy hasonló fájlok ellenőrzése szükséges. Ha a régi szerverhez tartozó abszolút elérési utak, IP címek, SMTP beállítások vagy gyorsítótár könyvtárak megmaradnak, az oldal látszólag működhet, de a háttérben hibákat generál.

Továbbá a PHP memory_limit, upload_max_filesize, post_max_size és max_execution_time értékeket az alkalmazás igényeihez kell igazítani. Például ha egy admin felület 200 MB-os termékfotókat tölt fel, és a feltöltési limit 32 MB marad, a migráció hiába sikeres, a működés nem folytatódhat.

5. Lépés: Tesztelés a DNS csere előtt

A legbiztonságosabb migrációs gyakorlat, ha még a DNS átirányítás előtt teszteled az oldalt az új szerveren. Ehhez a számítógéped hosts fájljában rendeld hozzá a domain nevedet az új szerver IP címéhez. Így amíg a látogatók még a régi szervert érik el, te az éles domain névvel tesztelheted az új szervert.

A tesztlistának a következő ellenőrzéseket kell tartalmaznia:

• Betöltődik-e a főoldal, kategória, termék, blog és kapcsolat oldal?
• Működik-e az űrlap beküldés, felhasználói bejelentkezés, jelszó visszaállítás és fizetési folyamat?
• Hiánytalanul betöltődnek-e a képek, CSS és JavaScript fájlok?
• Hiba nélkül megnyílik-e az admin felület?
• Telepítve van-e az SSL tanúsítvány a megfelelő domain névre?
• Van-e 404, 500, vegyes tartalom (mixed content) vagy átirányítási hurok hiba?
• Helyes-e a robots.txt, sitemap.xml és a canonical címkék?

6. Lépés: SSL tanúsítvány telepítése

A modern weboldalakon az SSL nemcsak biztonsági, hanem SEO és felhasználói bizalom szempontjából is kötelező. Ha a DNS átirányítás az SSL telepítése előtt megtörténik az új szerveren, a felhasználók "nem biztonságos" figyelmeztetést láthatnak. Ezért az SSL tanúsítványt közvetlenül a DNS átállás előtt vagy azzal egy időben kell előkészíteni. Az ingyenes tanúsítványok, mint a Let’s Encrypt, sok oldal számára elegendőek lehetnek; fizetést fogadó vállalati projekteknél magasabb validációs szintű SSL opciók választhatók.

SSL után győződj meg róla, hogy a HTTP címek 301-es átirányítással HTTPS-re mutatnak, nincs mixed content hiba, és az oldaltérkép HTTPS URL-eket tartalmaz. Az SSL termékekért és telepítési lehetőségekért látogass el a SSL tanúsítványok oldalra.

7. Lépés: DNS rekordok módosítása

A tesztek sikeres befejezése után a DNS oldalon az A rekordot az új szerver IP címére kell irányítani. Ha az e-mail szolgáltatás is ugyanarra a szerverre költözik, az MX, SPF, DKIM és DMARC rekordokat is frissíteni kell. Ha az e-mail egy másik szolgáltatónál marad, az MX rekordokhoz nem szabad hozzányúlni. Az egyik leggyakoribb hiba, hogy csak a weboldalt akarják költöztetni, de véletlenül módosítják az e-mail rekordokat, és megszakad a levélforgalom.

A DNS propagáció általában néhány perc és 24 óra között zajlik le. Ha a TTL előre csökkentésre került, a legtöbb felhasználó rövid időn belül eléri az új szervert. Ebben az időszakban ne kapcsold ki azonnal a régi szervert. Legalább 48 óráig, lehetőség szerint 72 óráig tartsd elérhetően, ez egy biztonságos gyakorlat.

8. Lépés: Végső szinkronizáció és log ellenőrzés

A DNS csere után ellenőrizni kell, hogy keletkezett-e új adat a régi szerveren. Különösen a rendeléseket, kapcsolatfelvételi űrlapokat, felhasználói regisztrációkat és hozzászólásokat kell összehasonlítani. A webszerver access log és error log fájljai segítenek megérteni, mely IP címek melyik szerverre küldtek kéréseket.

A migráció utáni első 24 órában figyelni kell az 500-as hibákat, a 404-es hibák számának növekedését, a lassú lekérdezéseket, a CPU kiugrásokat és az e-mail sorokat. Ezen ellenőrzések nélkül az oldal működőképesnek tűnhet, de a háttérben konverzióvesztés történhet.

Professzionális ellenőrzőlista az adatvesztés nélküli weboldal költöztetéshez

Az alábbi ellenőrzőlista a gyakorlatban legtöbb problémát okozó pontokat fedi le. A migráció előtti és utáni lista kipipálása jelentősen csökkenti a költöztetés kockázatát.

• A migráció időpontja alacsony forgalmú időszakra lett ütemezve.
• Teljes fájl, adatbázis, e-mail és DNS biztonsági mentés készült.
• A mentés megnyithatósága és visszaállíthatósága tesztelve lett.
• A DNS TTL értéke legalább 24 órával korábban csökkentésre került.
• Az új szerveren a PHP, adatbázis és szükséges modulok előkészítésre kerültek.
• A fájlok hiánytalanul átvitelre kerültek, és a jogosultságok ellenőrizve lettek.
• Az adatbázis karakterkódolásának és rendezésének kompatibilitása megerősítésre került.
• A konfigurációs fájlok az új szerver adatai szerint frissítve lettek.
• A hosts fájl segítségével élesítés előtti tesztelés történt.
• Az SSL telepítve lett, a HTTPS átirányítások ellenőrizve lettek.
• A DNS A, AAAA, MX, TXT rekordok helyesen frissítve lettek.
• A régi szerver legalább 48 óráig aktív maradt.
• A Google Search Console, Analytics és log bejegyzések figyelemmel kísérésre kerültek.

SEO ellenőrzések a migráció után a láthatóság megőrzéséért

A szerver migráció elméletileg nem okozhat SEO veszteséget, amíg az URL struktúra nem változik. A gyakorlatban azonban a lassúság, 404 hibák, hibás robots.txt, hiányzó SSL vagy átirányítási hibák befolyásolhatják a rangsorolást. Ezért a migráció utáni SEO ellenőrzés ugyanolyan fontos, mint a technikai migráció.

URL és átirányítás ellenőrzése

Ha a weboldal költöztetésekor nem változtatod meg az URL struktúrát, minimális a 301-es átirányítások szükségessége. Ha azonban egyidejűleg változik a domain név, a permalink struktúra vagy a mappaszerkezet, a régi URL-eket 301-es átirányítással kell az új megfelelőikre irányítani. A 302-es ideiglenes átirányítás nem alkalmas a SEO jelzések végleges átvitelére. Például ha a régi /termek/abc oldal az új /bolt/abc címre költözött, egyedi átirányítást kell végezni; az összes régi URL-t a főoldalra irányítani negatívan hat a felhasználói élményre és a SEO teljesítményre.

Robots.txt és oldaltérkép ellenőrzése

Ha a tesztelés során a robots.txt-ben Disallow parancsot használtál a keresőmotorok kizárására, az élesítéskor el kell távolítani. Ez a hiba a migráció utáni indexelési veszteség egyik legklasszikusabb oka. Az oldaltérkép fájlnak az új HTTPS URL-eket kell tartalmaznia, és újra be kell küldeni a Google Search Console-on keresztül.

Teljesítmény és Core Web Vitals

Még ha az új szerver erősebb is, a helytelen gyorsítótár beállítás ronthatja a teljesítményt. A LiteSpeed Cache, Redis, OPcache, CDN és a képi optimalizálás helyes konfigurálása szükséges. A migráció utáni első héten a PageSpeed Insights, Chrome UX Report és a szerver logok figyelésével ellenőrizni kell, hogy romlottak-e az LCP, INP és CLS mutatók. A tárhely teljesítmény javításához hasznosíthatod a WordPress sebesség optimalizálás tartalmakat.

Az e-mail migráció során figyelembe veendő szempontok

Sok weboldal költöztetésnél a webes fájlok problémamentesen átvitelre kerülnek, miközben az e-mail oldal elsikkad. Ha az e-mailek a jelenlegi szerveren vannak tárolva, a postafiókokat, felhasználói jelszavakat, átirányításokat és szűrőket át kell költöztetni. Az IMAP szinkronizáció megbízható módszer a régi fiókban lévő levelek új fiókba való átvitelére.

A DNS oldalon az MX rekord határozza meg a levelező szervert, az SPF a küldési jogosultságot, a DKIM az aláírást, a DMARC pedig a domain szabályzatot. Ha ezek a rekordok hibásan vannak konfigurálva, az e-mailek a spam mappába kerülhetnek vagy teljesen visszautasításra kerülhetnek. A migráció után teszt küldeményeket kell indítani Gmail, Outlook és vállalati e-mail címekre; és ellenőrizni kell a levél fejléc információit.

Gyakori szerver migrációs hibák

A sikeres migrációs projektek közös pontja az egyszerű hibák előzetes megelőzése. Az alábbi hibák a leggyakrabban tapasztalt problémák:

• Biztonsági mentés nélkül vagy a mentés tesztelése nélkül végrehajtott migráció.
• IP csere a DNS TTL érték csökkentése nélkül.
• A régi szerver lekapcsolása a DNS propagáció befejeződése előtt.
• Az adatbázis karakterkódolásának hibás átvitele és az ékezetes karakterek sérülése.
• A .htaccess vagy nginx átirányítási szabályok elfelejtése.
• HTTPS forgalom átirányítása az új szerverre SSL telepítése nélkül.
• Az e-mail MX és TXT rekordok hibás frissítése.
• A gyorsítótár bővítmény régi szerver elérési úttal hagyása.
• A migráció utáni Search Console és log figyelés elmulasztása.

Különösen az élő értékesítést folytató oldalaknál a migrációt ne a hétköznapi munkaidős csúcsforgalomban, hanem a legalacsonyabb forgalmú és rendelési volumenű időszakban végezd. Nagy e-kereskedelmi projekteknél egy 15-30 perces karbantartási ablak tervezése megelőzi a háttérben esetlegesen fellépő adatinkonzisztenciákat.

Mikor érdemes professzionális migrációs támogatást igénybe venni?

Egy egyszerű bemutatkozó oldal manuális költöztetése lehetséges; azonban bizonyos esetekben a professzionális segítség igénybevétele alacsonyabb költségű és biztonságosabb. Az ebbe a csoportba tartoznak a magas havi forgalmat bonyolító webáruházak, a sok e-mail fiókkal rendelkező cégek, az egyedi szoftvert használó portálok, a nagy forgalmú médiaoldalak és a szabályozás alá eső adatokat tároló vállalkozások.

A professzionális migrációs támogatás folyamata általában előzetes elemzésből, biztonsági mentésből, tesztkörnyezet telepítéséből, átvitelből, DNS átállásból, validálásból és monitorozásból áll. Így nemcsak a fájlok, hanem az üzletmenet folytonossága is átköltöztetésre kerül. Ha a Hostragons infrastruktúrájára tervezel áttérni, az igényeidnek megfelelő tárhely, domain és SSL lehetőségek együttes értékeléséhez tekintsd meg a Hostragons hosting megoldások oldalt.

Összegzés: A tervezett szerver migráció megelőzi a leállást és az adatvesztést

A szerver migráció, ha megfelelően van megtervezve, nem egy félelmetes művelet. A siker kulcsa az, hogy ne hagyd ki a teljes biztonsági mentést, a megfelelő szerver előkészítést, a DNS TTL tervet, a tesztkörnyezetet, az SSL telepítést, az e-mail ellenőrzéseket és a migráció utáni monitorozás lépéseit. Különösen a folyamatosan változó adatbázissal rendelkező oldalaknál játszik kritikus szerepet az utolsó szinkronizáció és a karbantartási mód.

Röviden, az adatvesztés nélküli weboldal költöztetéshez ne siess, ellenőrizz minden lépést, és ne kapcsold ki azonnal a régi szervert. Ha szeretnéd megújítani az infrastruktúrádat, és gyorsabb, biztonságosabb webes élményt nyújtani, tekintsd meg a Hostragons tárhely, domain és SSL megoldásait; és nyugodtan, ellenőrzött módon készítsd el az igényeidnek megfelelő átállási tervet.

Gyakran Ismételt Kérdések

Mennyi ideig tart a szerver migráció?

Az időtartam az oldal méretétől és összetettségétől függ. Egy kis WordPress oldal 30-60 perc alatt átköltöztethető, míg nagy e-kereskedelmi vagy sok e-mail fiókkal rendelkező vállalati projekteknél a folyamat az előkészítéssel, teszteléssel és DNS propagációval együtt 1-3 napot is igénybe vehet.

Leáll az oldalam a szerver migráció alatt?

Megfelelő tervezéssel a leállás néhány percre csökkenthető, vagy a felhasználók észre sem veszik a kiesést. Ehhez a DNS TTL-t előre csökkenteni kell, az új szervert élesítés előtt tesztelni kell, és a régi szervert a DNS propagáció befejeződéséig bekapcsolva kell tartani.

Mi a legfontosabb lépés az adatvesztés elkerüléséhez?

A legfontosabb lépés a hitelesített, teljes körű biztonsági mentés. A fájlokról, adatbázisról, e-mailekről és DNS rekordokról biztonsági mentést kell készíteni; különösen a rendelési vagy tagsági adatokat generáló oldalaknál az utolsó adatbázis mentést a karbantartási mód bekapcsolása után kell elkészíteni.

Befolyásolja a szerver migráció a SEO rangsorolást?

Ha az URL struktúra megmarad, az oldal gyorsan működik, az SSL és az átirányítások helyesen vannak beállítva, a szerver migráció önmagában nem okoz SEO veszteséget. Azonban a 404 hibák, a hibás robots.txt, a lassú szerver vagy a hibás 301 átirányítások negatívan befolyásolhatják a rangsorolást.

Az e-mail fiókok is átkerülnek a szerver migrációval?

Ha az e-mailek a régi tárhelyen vannak tárolva, azokat külön át kell költöztetni. A postafiókokat, átirányításokat, szűrőket és az MX, SPF, DKIM, DMARC rekordokat ellenőrizni kell. Ha az e-mail egy másik szolgáltatónál marad, az MX rekordokat nem szabad módosítani.