A weboldal költöztetés Ajka környékén szinte mindig azzal kezdődik, hogy egy vállalkozás kinőtte a korábbi megoldást: lassú a tárhely, elérhetetlen a régi fejlesztő, vagy egyszerűen új rendszerre vált. A gond ritkán a fájlok átmásolásával van. A baj ott keletkezik, ami a fájlok körül él: az átirányítások, a domainhez kötött e-mail, az SSL, a DNS és a mérés. Ez az útmutató végigveszi, mit rontanak el a legtöbben, és ad egy lépésről lépésre ellenőrzőlistát, amivel a váltás jó eséllyel forgalomvesztés nélkül lezajlik.
Miért kockázatosabb a költöztetés, mint amilyennek látszik?
Röviden: mert a weboldal nem egyetlen dolog, hanem összekapcsolt rendszerek halmaza, és ezek egy része láthatatlan. Amikor valaki tárhelyet vált, hajlamos csak arra figyelni, amit lát: a szövegre, a képekre, a menüre. A háttérben viszont ott az a réteg, ami eldönti, hogy egy Ajkáról érkező kereső egyáltalán megtalálja-e az oldalt: a domain névfeloldása, a régi URL-ek megőrzése, a levelezés útvonala.
Saját tapasztalat: a leggyakoribb hiba, hogy a régi és az új rendszer URL-szerkezete eltér (például más a kategóriák felépítése), és a régi címekről nem készül átirányítás. Ilyenkor a korábban jól teljesítő aloldalak 404-es hibára futnak, a kereső pedig fokozatosan kiejtheti őket. Ez nem azonnal látszik, csak hetekkel később a forgalmi grafikonon.
Miért érint ez egy ajkai céget másképp?
Röviden: mert a helyi vállalkozások gyakran egy helyi szolgáltatótól, összevont csomagban költöznek, ahol a tárhely, a domain és a levelezés egy kézben van. Ajka üveg- és fémipari hagyományú kisváros, ahol sok kis- és középvállalkozás dolgozik, és a környező falvak vonzáskörzete is idetartozik. Ez a helyi jelleg a webes jelenlétben is megmutatkozik: a cégek jelentős része évekkel ezelőtt egy ismerős fejlesztőtől vagy egy közeli informatikai szolgáltatótól kapta a weboldalát.
Saját tapasztalat: az ilyen összevont felállás előnye, hogy egyszerű volt. A hátránya költöztetéskor derül ki: a hozzáférések (tárhely admin, domain regisztrátor, e-mail fiókok) sokszor dokumentálatlanok, néha kizárólag a korábbi szolgáltató kezében vannak. Ezért egy ajkai költöztetés első lépése szinte mindig nem a technika, hanem a leltár: pontosan mi hol van, és kihez tartozik a jelszó.
Mit rontanak el a legtöbben az átirányításoknál?
Röviden: nem készítenek 301-es (végleges) átirányítást a régi címekről az újakra, vagy átirányítási láncot hoznak létre. Ha megváltozik az URL-szerkezet, minden fontos régi címnek egyetlen lépésben az új megfelelőjére kell mutatnia.
Hivatalosan igazolt: a Google Search Central dokumentációja szerint tartós költöztetéskor a 301-es átirányítás a javasolt megoldás, mert ez jelzi a keresőnek, hogy a cím véglegesen átkerült. Amit érdemes elkerülni: az átirányítási lánc, amikor A oldal B-re, B pedig C-re mutat. Ilyenkor a cél az, hogy A rögtön C-re irányítson.
Egy tipikus Apache-alapú tárhelyen a .htaccess fájlban így néz ki egy sor:
Redirect 301 /regi-szolgaltatas https://pelda.hu/uj-szolgaltatas
A gyakorlati ökölszabály: készíts táblázatot a régi és az új címek párosításával, és külön kezeld a nagy forgalmú oldalakat. A teljes tartalom feltérképezéséhez egy crawler (például egy site-térképező eszköz) segít, hogy egyetlen fontos cím se maradjon ki.
Miért bukik el sok költöztetés az e-mailen?
Röviden: mert a domainhez kötött e-mail ugyanannál a régi szolgáltatónál marad, miközben a domain már az új szerverre mutat, így a levelek elakadnak. Ez az egyik legfájdalmasabb hiba, mert a cég levelezése áll le, nem csak a weboldala.
Szakmai feltételezés: egy ajkai kkv esetében jó eséllyel a cegnev@sajatdomain.hu típusú levelezés ugyanabban a csomagban van, mint a tárhely. Amikor a domain DNS-ét átállítod az új szerverre, és nem viszed át helyesen az MX rekordokat, a levelek a rossz helyre próbálnak megérkezni.
A biztonságos megközelítés: még a váltás előtt dokumentáld a jelenlegi MX, SPF, DKIM és DMARC rekordokat, és döntsd el, hogy a levelezés a régi szolgáltatónál marad-e vagy átkerül. Ha marad, akkor az MX rekordoknak a régi levelezőszerverre kell mutatniuk, függetlenül attól, hogy a weboldal már máshol fut. Az SPF és DKIM beállítás elhagyása később a levelek kézbesíthetőségét ronthatja.
Mi a helyes DNS-sorrend, hogy ne legyen kiesés?
Röviden: előbb élesítsd és teszteld az új szervert, és csak akkor állítsd át a DNS-t, ha minden működik; a váltás előtt pedig csökkentsd a TTL-t. A DNS az a réteg, ami a domainnevet a szerver IP-címéhez rendeli, és a változás terjedése időbe telik.
Hivatalosan igazolt: a DNS-rekordokhoz tartozó TTL (Time To Live) érték határozza meg, meddig őrzik meg a köztes szerverek a régi választ. Ha a váltás előtt néhány nappal a TTL-t alacsonyabb értékre állítod, a tényleges átállás gyorsabban terjed.
Ajánlott sorrend:
- Új tárhely feltöltése és tesztelése egy ideiglenes címen vagy a hosts fájl átírásával, még a DNS-váltás előtt.
- TTL csökkentése a fő rekordokon a váltás előtt.
- A rekord (és szükség esetén CNAME) átállítása az új szerver IP-jére.
- MX rekordok ellenőrzése, hogy a levelezés a helyes szerverre mutasson.
- Terjedés megvárása, közben mindkét szerver legyen elérhető.
Saját tapasztalat: a régi tárhelyet ne mondd le azonnal. Hagyd élőben legalább egy-két hétig, amíg a DNS mindenhol frissül, különben egyes látogatók még a régi, üres szerverre futhatnak be.
Miért marad le sokaknál az SSL és a mérés?
Röviden: mert ezek a váltás pillanatában láthatatlanok, és csak akkor tűnnek fel, amikor már baj van belőlük. Az SSL-tanúsítvány adja a https elérést; ennek hiánya a böngészőben figyelmeztetést vált ki, ami bizalmat rombol.
Az új szerveren gondoskodj érvényes SSL-tanúsítványról, és ellenőrizd, hogy minden aloldal https-en, vegyes tartalom (mixed content) nélkül töltődik. A régi http címekről is legyen átirányítás a biztonságos változatra.
A mérésnél a leggyakoribb hiba, hogy az új rendszerbe nem kerül vissza a Google Analytics vagy más mérőkód, illetve a Google Search Console-ban nem történik meg az ellenőrzés. Szakmai feltételezés: ha a mérőkód pár napig hiányzik, valós forgalomvesztésnek tűnhet valami, ami csak mérési kiesés. Ezért az élesítés napján ellenőrizd, hogy a mérés valós idejű adatot mutat-e.
Hogyan néz ki egy jó költöztetési checklist?
Röviden: a checklist három szakaszra bomlik: előkészítés, élesítés, utólagos ellenőrzés. Az alábbi lista egy ajkai kkv tipikus költöztetéséhez igazodik.
Előkészítés
- Hozzáférések leltára: tárhely, domain regisztrátor, e-mail, mérőfiókok.
- Teljes biztonsági mentés a régi oldalról (fájlok és adatbázis).
- Régi URL-ek listázása crawlerrel, átirányítási táblázat készítése.
- Jelenlegi DNS-rekordok (A, CNAME, MX, SPF, DKIM, DMARC) rögzítése.
- TTL csökkentése a váltás előtt.
Élesítés
- Tartalom feltöltése és tesztelése az új szerveren, még a DNS-váltás előtt.
- 301-es átirányítások beállítása és próbája néhány kulcsoldalon.
- SSL-tanúsítvány érvényességének és a
httpsbetöltésnek az ellenőrzése. - MX és e-mail rekordok ellenőrzése, próbalevél oda-vissza.
- DNS átállítása, mindkét szerver életben tartása.
Utólagos ellenőrzés
- 404-es hibák figyelése és a hiányzó átirányítások pótlása.
- Search Console-ban új sitemap beküldése, indexelés követése.
- Mérőkód működésének visszaigazolása valós idejű adaton.
- Belső linkek és képek hivatkozásainak ellenőrzése.
- A régi tárhely megtartása addig, amíg a terjedés lezárul.
A weboldal költöztetés Ajka és a környező települések vállalkozásainál akkor sikeres, ha ezt a három szakaszt nem sietteted össze. A jól előkészített migráció nem garantál eredményt, de jelentősen csökkenti a forgalomvesztés kockázatát, és segítheti, hogy az oldal a váltás után is stabilan elérhető maradjon.
Források és további olvasnivalók
- Google Search Central: Site moves with URL changes (költöztetési útmutató)
- Google Search Central: Redirects and Google Search
- Google Search Console súgó: sitemap beküldés és indexelés
- Mozilla Developer Network (MDN): HTTP átirányítások és állapotkódok
- W3C: URL és webcím szabványok
- IETF RFC dokumentáció: DNS és MX rekordok
- A tartalom átmásolása a migráció legkisebb része: a régi címekről 301-es átirányítás kell az újakra.
- A domainhez tartozó e-mail gyakran ugyanattól a szolgáltatótól jön, mint a tárhely, ezért az MX rekordokat külön kell kezelni.
- A DNS TTL csökkentése a váltás előtt jó eséllyel lerövidíti azt az időt, amíg a látogatók a régi szerverre futnak be.
- SSL-tanúsítványt és mérőkódot (Google Analytics, Search Console) az élesítés napján ellenőrizni kell, nem utólag.
- Ajkán tipikusan helyi szolgáltatótól költöznek, ahol a hozzáférések és a beállítások dokumentálatlanok lehetnek, ezért az adatkinyerés az első lépés.
Gyakori kérdések
Mennyi ideig tart egy weboldal költöztetés?
A tartalom átvitele általában gyors, de a DNS terjedése miatt a teljes, biztonságos átállás jellemzően néhány órától akár egy-két napig is eltarthat. Ezért érdemes a régi tárhelyet legalább egy-két hétig megtartani, amíg minden látogató az új szerverre irányul.
Elveszíthetem a Google-helyezéseimet költöztetéskor?
Ha az URL-szerkezet változik és nincsenek 301-es átirányítások, akkor a korábban jól teljesítő oldalak kieshetnek az indexből. Helyesen beállított átirányításokkal és megőrzött tartalommal a rangsorolás jó eséllyel megtartható, bár ez nem garantált, és átmeneti ingadozás előfordulhat.
Mi történik a céges e-mailemmel költöztetéskor?
Ha a levelezés a domainhez kötött és ugyanannál a szolgáltatónál van, akkor a DNS-váltáskor az MX rekordokat külön kell kezelni. Ha ezt elmulasztod, a levelek a rossz szerverre próbálnak megérkezni, és a levelezés leállhat. Ezért a váltás előtt dokumentáld az összes levelezési rekordot.
Kell-e új SSL-tanúsítvány a költöztetés után?
Igen, az új szerveren érvényes SSL-tanúsítványt kell biztosítani, és ellenőrizni, hogy minden aloldal https-en, vegyes tartalom nélkül töltődik. A régi http címekről is legyen átirányítás a biztonságos változatra, különben a böngésző figyelmeztetést jeleníthet meg.
Mit tegyek, ha a régi szolgáltatónál vannak a hozzáféréseim?
Egy ajkai cég esetében gyakori, hogy a tárhely, a domain és a levelezés hozzáférései a korábbi helyi szolgáltatónál vannak. Az első lépés ezek összegyűjtése és dokumentálása. Ha valamelyik hozzáférés hiányzik, azt még a költöztetés megkezdése előtt kell rendezni, mert enélkül a domain vagy a levelezés átvitele elakadhat.
Le kell-e mondanom azonnal a régi tárhelyet?
Nem érdemes. Ajánlott a régi tárhelyet még legalább egy-két hétig élőben tartani a DNS teljes terjedéséig, valamint egy teljes biztonsági mentést megőrizni róla arra az esetre, ha az új rendszeren valami hiányozna.
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.