A weboldal költöztetés Egerben ott dől el, hogy előre felméred-e a nem látható részeket: az átirányításokat, az e-mail-fiókokat, az SSL-t, a DNS-t és a mérést. A fájlok és az adatbázis másolása a könnyebb fele. A hibák többsége abból ered, hogy valaki átkapcsolja a domaint, mielőtt az új helyen minden a helyére került volna, és ezzel egy időben áll le a levelezés, tűnnek el a régi URL-ek, vagy szakad meg a mérés.
Egy egri vállalkozás jellemzően egy helyi, sok éve használt szolgáltatótól költözik: ott van a tárhely, a domain és sokszor a céges e-mail is egy kézben. Ez kényelmes, de migrációkor pont ez a csomópont a kockázat: ha nincs meg minden hozzáférés és export, félúton akadhatsz el. Ez a cikk végigveszi, mit rontanak el a legtöbben, és ad egy sorrendbe tett ellenőrzőlistát.
Miért kockázatosabb a migráció, mint amilyennek tűnik?
Mert egyszerre több, egymástól független rendszert mozgatsz: a tárhelyet, a domaint (DNS), az e-mailt, az SSL-t és a mérést. Ezek külön is elromolhatnak, és külön logika szerint frissülnek.
A klasszikus tévhit, hogy a költözés annyi, hogy "átmásolom a fájlokat és kész". A valóságban a látogató a domainre érkezik, a domain a DNS-en keresztül mutat egy szerverre, a szerveren fut a weboldal, az SSL-tanúsítvány teszi biztonságossá a kapcsolatot, a levelezés pedig sokszor ugyanahhoz a domainhez kötődik, de teljesen más rekordokon. Ha ezt egyetlen mozdulatnak képzeled, könnyen kimarad valami.
Saját tapasztalat: a legtöbb bosszúságot nem a weboldal maga okozza, hanem a levelezés és a régi linkek. A weboldalt egy látogató frissítésre újratölti, egy elveszett e-mail viszont nem jön vissza magától.
Mit rontanak el a legtöbben a migrációkor?
Öt visszatérő hiba van: hiányos átirányítások, leálló e-mail, kihagyott vagy késve kiállított SSL, elkapkodott DNS-váltás és a mérőkódok ellenőrzés nélküli "átvitele".
1. Az átirányítások kimaradnak vagy láncot alkotnak
Ha megváltozik a domain, az URL-szerkezet vagy csak a http-ről https-re váltasz, a régi címeket 301-es (végleges) átirányítással kell az új megfelelőjükre küldeni. Ha ez kimarad, a korábban belinkelt és a keresőben indexelt oldalak 404-es hibát adnak. Ez rontja a felhasználói élményt, és a keresési láthatóságot is visszavetheti, ami egy erősen kereséssel induló piacon, mint az egri szálláshely- és programkeresés, közvetlenül a foglalási szándékú forgalmat érinti.
Gyakori a másik véglet is: az átirányítás működik, de láncban. A régi URL a http-verzióra megy, az a www nélkülire, az a https-re, végül az új oldalra. Minden ugrás lassít és gyengíti az átadott értéket. Cél az egy lépéses átirányítás.
Szakmai feltételezés: egy tartalommal régóta futó egri oldalnál (blog, szállásleírások, programajánlók) tipikusan több tucat, akár több száz belső és külső hivatkozás mutat régi URL-ekre, ezért érdemes teljes URL-listát exportálni migráció előtt.
2. Leáll az e-mail
Ez a leggyakoribb és legfájóbb hiba. Ha a levelezés is a régi tárhelyen volt, a domain átkapcsolásával a bejövő levelek elkezdhetnek az új, üres szerverre menni, miközben a régi postafiókok tartalmát senki nem exportálta. Az MX-rekordok, az SPF, a DKIM és a DMARC beállítások nélkül a kimenő leveleid is könnyen spam mappába kerülhetnek.
3. SSL nélkül vagy késve élesített tanúsítvánnyal indul az új oldal
Ha a DNS már az új szerverre mutat, de ott még nincs kiállítva a tanúsítvány, a látogató "nem biztonságos" figyelmeztetést kap. Ez pár óra alatt is sok bizalmat rombol.
4. Elkapkodott DNS-váltás
A DNS-módosítás nem azonnali: a rekordokhoz tartozik egy TTL (élettartam) érték, és amíg a régi bejegyzés a világ különböző pontjain gyorsítótárban van, a látogatók egy része még a régi szervert látja, más része már az újat. Ha közben csak az egyik helyen frissíted a tartalmat vagy fogadod a rendelést, adatok csúszhatnak el.
5. A mérés csendben elnémul
A mérőkódok (GA4, Google Search Console, hőtérkép, hirdetési pixelek) sokszor a sablonba vagy egy bővítménybe vannak beépítve. Költözéskor előfordul, hogy a régi kód nem jön át, vagy duplán szerepel. Hetekkel később derül ki, hogy nincs adat, addigra viszont pótolhatatlan az elveszett időszak.
Milyen sorrendben csináld? A lépésről lépésre checklist
A biztonságos sorrend: előbb felmérés és teljes mentés, aztán az új környezet felépítése és tesztelése, és csak a legvégén a DNS-átkapcsolás, majd az azt követő ellenőrzés.
Előkészítés (mielőtt bármihez hozzányúlnál)
- Kérd be a régi szolgáltatótól az összes hozzáférést: tárhely-adminisztráció, FTP/SFTP, adatbázis, domain-kezelő (regisztrátor) fiók, e-mail-fiókok.
- Készíts teljes mentést: fájlok, adatbázis, és külön az e-mailek exportja.
- Exportáld a jelenlegi URL-listát (sitemap, Search Console, esetleg egy feltérképező eszköz), hogy legyen mihez igazítani az átirányításokat.
- Jegyezd fel a jelenlegi DNS-rekordokat: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC). Ezt utólag nehéz rekonstruálni.
- Csökkentsd a DNS TTL-t (pl. 300 mp-re) néhány nappal a váltás előtt, hogy gyorsabb legyen az átállás.
Az új környezet felépítése
- Töltsd fel a fájlokat és importáld az adatbázist az új tárhelyre.
- Állítsd be és teszteld az oldalt az új szerveren, még a domain átkapcsolása előtt (ideiglenes cím vagy a gépi
hostsfájl segítségével). - Állítsd ki az SSL-tanúsítványt az új helyen, és ellenőrizd, hogy a https hibátlanul betölt.
- Hozd létre a postafiókokat az új szerveren, és töltsd vissza a levelezés exportját, ha a levelezés is költözik.
- Készítsd elő az átirányítási szabályokat (pl.
.htaccessvagy a szerver konfigurációja), és teszteld néhány mintaoldalon.
Egy egyszerű átirányítás Apache alatt így néz ki:
Redirect 301 /regi-oldal /uj-oldal
A teljes http-ről https-re és www-re irányítást pedig érdemes egyetlen szabállyal, egy ugrásban megoldani, hogy ne alakuljon ki lánc.
Az átkapcsolás napja
- Válassz forgalmilag csendes időszakot. Egy egri szálláshelynél vagy programszervezőnél ez nem a hétvége és nem a szezoncsúcs.
- Frissítsd a DNS-rekordokat az új szerverre (A/AAAA, szükség esetén CNAME), és az MX-, SPF-, DKIM-, DMARC-rekordokat a levelezéshez.
- Hagyd a régi tárhelyet aktívan még legalább néhány napig, amíg a DNS mindenhol frissül. Így senki nem lát üres oldalt vagy hibát.
Élesítés utáni ellenőrzés
- Nézd meg, hogy a https zöld, a tanúsítvány érvényes, és nincs vegyes (http-s) tartalom.
- Kattints végig a fő útvonalakon: nyitóoldal, szolgáltatás/szállás oldalak, kapcsolat, foglalás vagy ajánlatkérő űrlap.
- Teszteld a régi URL-eket: 301-gyel jutnak-e a helyes új címre, lánc nélkül.
- Küldj és fogadj tesztlevelet minden postafiókból, és ellenőrizd egy levélteszttel, hogy az SPF/DKIM/DMARC rendben van.
- Ellenőrizd a GA4-et valós idejű nézetben, a Search Console-ban a tulajdon és a sitemap állapotát, és a hirdetési pixelek betöltését.
- Küldd be az új sitemapet a Search Console-ba, és kérj újrafeltérképezést a fő oldalakra.
Miért fontos ez pont egy egri vállalkozásnak?
Mert Eger keresletének nagy része turizmusból, borászatból és oktatásból jön, és ezek erősen kereséssel indulnak; egy elrontott migráció pont a döntés előtti pillanatban akaszthatja meg a látogatót.
Amikor valaki egri szállást, borkóstolót, programot vagy képzést keres, tipikusan konkrét szándékkal, gyakran mobilon és időnyomás alatt teszi. Ha ilyenkor a foglalási oldal 404-et ad, lassan tölt egy átirányítási lánc miatt, vagy "nem biztonságos" jelzést mutat, a látogató jó eséllyel visszalép és a versenytársnál foglal. A szezonális kereslet ráadásul felnagyítja a hibát: egy rossz időzítésű költözés a csúcsidőben többe kerülhet, mint máskor egész hónapban.
Saját tapasztalat: a helyi szolgáltatóváltás önmagában nem rossz döntés, sokszor indokolt (sebesség, támogatás, korszerűbb környezet). A kulcs a sorrend és a türelem: a párhuzamos futtatás és a DNS természetes átfutási idejének kivárása a legtöbb kellemetlenséget megelőzi.
Mit érdemes a szolgáltatóváltásnál előre tisztázni?
A hozzáféréseket, az e-mail sorsát és a domain tulajdonjogát: ez a három pont okozza a legtöbb elakadást a régi, helyi szolgáltatótól való költözésnél.
- Kié a domain? Győződj meg róla, hogy a domain a te (vagy a céged) nevén van, és hozzáférsz a regisztrátori fiókhoz. DNS-t módosítani csak innen tudsz.
- Költözik-e az e-mail? Ha igen, hová, és megvan-e minden fiók exportja. Ha marad a régi helyen, akkor a DNS-ben az MX-rekordokat nem szabad átírni.
- Van-e felmondási vagy adatkiadási feltétel? Kérd írásban, meddig marad elérhető a régi tárhely, hogy legyen átfedés.
Hivatalosan igazolt: a Google Search Central dokumentációja szerint a webhelyáthelyezésnél a tartós (301) átirányítások és a régi oldalak elérhetőségének fenntartása segíti, hogy a kereső a lehető legkevesebb zökkenővel kövesse a változást. Ez nem jelent automatikus vagy azonnali eredményt, de csökkenti a láthatóság átmeneti visszaesésének kockázatát.
Források és további olvasnivalók
- Google Search Central: Site moves with URL changes; Site moves without URL changes (dokumentáció)
- Google Search Console súgó: sitemap beküldése és URL-ellenőrzés
- Google Analytics 4 súgó: mérőkód telepítése és ellenőrzése
- W3C és IETF: HTTP állapotkódok (301, 302) és a HTTPS ajánlások
- MDN Web Docs: HTTP redirections
- DMARC.org, valamint az SPF (RFC 7208) és DKIM (RFC 6376) specifikációk az e-mail hitelesítéshez
- A migráció legnagyobb kockázata nem a fájlok másolása, hanem az elveszett átirányítások és a leálló e-mail.
- A régi és az új tárhely fusson párhuzamosan, amíg a DNS mindenhol frissül; a domaint utoljára kapcsold át.
- Egy egri helyi szolgáltatótól gyakran hiányzik a teljes hozzáférés-lista és az e-mail-export, ezt előre kérd be.
- A 301-es átirányítások és az SSL nélkül a keresési láthatóság és a foglalási szándékú forgalom sérülhet.
- A mérőkódokat (GA4, Search Console) az élesítés napján ellenőrizd, ne feltételezd, hogy átjöttek.
Gyakori kérdések
Mennyi ideig tart egy weboldal költöztetés Egerben?
A tényleges munka gyakran egy-két nap, de a DNS átfutása miatt a teljes, biztonságos átállás jellemzően több napig is elhúzódhat. Ez alatt a régi és az új tárhely párhuzamosan fusson, hogy senki ne lásson hibát.
Elveszik-e a Google-helyezésem a költözéskor?
Nem szükségszerű, de van kockázata. Ha minden régi URL-t 301-gyel átirányítasz a helyes új címre, és a régi oldalak egy ideig elérhetők maradnak, a láthatóság jó eséllyel megőrizhető. Rövid átmeneti ingadozás előfordulhat, ami idővel általában rendeződik.
Mi történik az e-mail fiókjaimmal költözéskor?
Ha a levelezés is a régi tárhelyen volt, előre exportálni kell a fiókok tartalmát, és az új helyen létrehozni azokat. A DNS-ben az MX-, SPF-, DKIM- és DMARC-rekordokat is frissíteni kell, különben leállhat a levelezés vagy spamként kezelik a leveleidet.
Kell-e külön SSL-tanúsítvány az új tárhelyen?
Igen. Az SSL a szerverhez kötődik, ezért az új helyen újra ki kell állítani, ideális esetben már a domain átkapcsolása előtt. Így a látogatók nem kapnak 'nem biztonságos' figyelmeztetést.
Miért ne kapcsoljam át rögtön a domaint az új szerverre?
Mert a DNS nem frissül azonnal mindenhol, és ha az új oldal még nincs teljesen kész vagy nincs SSL-je, a látogatók egy része hibát lát. Előbb építsd fel és teszteld az új környezetet, és csak utána, csendes időszakban módosítsd a DNS-t.
Honnan tudom, hogy a mérés a költözés után is működik?
Az élesítés napján nézd meg a GA4 valós idejű jelentését, a Search Console-ban a tulajdon és a sitemap állapotát, és a hirdetési pixelek betöltését. Ne feltételezd, hogy a kódok automatikusan átjöttek, mindig ellenőrizd.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.