Weboldal költöztetés és tárhelyváltás Szombathely: kockázatok és checklist

Scheo · 2026-07-20 · Frissítve: 2026-09-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Egy tárhelyváltás papíron tíz percnek tűnik: átmásolod a fájlokat, átállítod a DNS-t, kész. A valóságban ez az a művelet, ahol egy vállalkozás egy hétre elveszítheti a beérkező e-mailjeit, hónapokra a keresőből érkező forgalma egy részét, és sokszor észre sem veszi, hogy a mérés közben leállt. A weboldal költöztetés Szombathelyen ráadásul gyakran nem egy nagy hosting cégtől indul, hanem egy helyi informatikustól vagy egy kisebb, Vas vármegyei szolgáltatótól, ahol a domain, a tárhely és a levelezés az évek során egyetlen ember fejében és fiókjában gyűlt össze. Ez a cikk arról szól, mit érdemes ilyenkor sorban végigvinni.

Miért kockázatosabb a költöztetés, mint amire elsőre számítasz?

Rövid válasz: mert egy domain mögött nem egy, hanem legalább négy különálló szolgáltatás fut (weboldal, levelezés, DNS, tanúsítvány), és a költöztetés során ezek nem egyszerre, nem is azonos sebességgel váltanak át.

Saját tapasztalat: a hibák túlnyomó része nem a fájlmásolásnál keletkezik, hanem ott, ahol valaki azt feltételezte, hogy egy dolog automatikusan viszi magával a másikat. A leggyakoribb feltételezés az, hogy ha a weboldal átkerül, akkor a levelezés is átkerül vele. Nem kerül át. A kettő technikailag két külön rekordkészlet ugyanazon a domainen.

A második gyakori tévedés az időzítés. A DNS-változás nem azonnali: a világ különböző pontjain lévő névszerverek és internetszolgáltatók a régi értéket még a beállított élettartamig (TTL) kiszolgálják. Ez alatt az átmeneti időszak alatt egyes látogatóid a régi tárhelyet látják, mások az újat. Ha közben mindkét helyen fut az oldal, két különböző adatbázisba érkezhetnek a megrendelések és az űrlapok.

Mit érdemes felmérni még az első fájl átmásolása előtt?

Rövid válasz: készíts leltárt arról, mi hol van és kinek van hozzá jogosultsága, mert a migráció kudarcainak jelentős része hozzáférési kérdés, nem technikai.

Egy szombathelyi kis- vagy középvállalkozásnál ez tipikusan így néz ki: a domaint évekkel ezelőtt a korábbi weboldalkészítő regisztrálta, a tárhely egy helyi szolgáltatónál van, a levelezést valaki átirányította egy ingyenes fiókra, a Google Search Console-hozzáférés pedig egy régen kilépett kolléga címén él. Amíg ezek nincsenek rendezve, a költözés nem indítható el felelősen.

A leltár minimuma:

• Domain regisztrátor: ki a bejegyzett tulajdonos, kinek van belépése, mikor jár le a fenntartás.
• Aktuális DNS-zóna: az összes rekord kiexportálva (A, AAAA, CNAME, MX, TXT, SRV). A TXT-rekordokat különösen könnyű ottfelejteni: SPF, DKIM, domain-igazolások mind ide tartoznak.
• Levelezés: hány postafiók van, mennyi adat van bennük, IMAP vagy POP3 alapú a használat, van-e szerveroldali átirányítás vagy automatikus válasz.
• Weboldal: milyen rendszer (CMS), milyen PHP- és adatbáziskiadás alatt fut, milyen bővítmények, milyen cron-feladatok.
• Külső integrációk: számlázó, könyvelés, webshop-szállítmányozás, űrlapokat fogadó rendszerek, esetleg osztrák partnerek felé futó adatkapcsolatok. Szombathely nyugat-magyarországi ipari és beszállítói város, ahol az osztrák piac közelsége miatt egy B2B cégnél nem ritka a kétnyelvű oldal vagy a külföldi partnerrendszerhez kötött folyamat, és ezek külön figyelmet igényelnek.
• Mérés: mérőkódok, konverziókövetés, hirdetési címkék, Search Console és analitika hozzáférések.

Szakmai feltételezés: a helyi szolgáltatótól való elköltözésnél gyakran nem a technikai átadás a szűk keresztmetszet, hanem az, hogy a felmondás és az átadás párhuzamosan zajlik. Érdemes úgy tervezni, hogy a régi szolgáltatás még legalább két-négy hétig éljen a váltás után is.

Hogyan kerülöd el az átirányítási hibákat?

Rövid válasz: minden régi URL-nek pontosan egy darab 301-es átirányítása legyen a végleges új címre, lánc és ideiglenes kód nélkül.

Hivatalosan igazolt: a Google Search Central dokumentációja a webhelyköltöztetésnél a 301-es (állandó) átirányítást írja le a szándék jelzésére, és javasolja a régi és az új verzió párhuzamos figyelését a Search Console-ban.

Ha a domain és az URL-szerkezet nem változik, csak a szerver, akkor átirányításra elvileg nincs szükség. A gyakorlatban mégis kell rájuk figyelni, mert a régi tárhelyen sokszor volt egy csomó öröklött szabály (www-re vagy www nélküli alakra terelés, HTTPS-kényszerítés, régi kampányoldalak átirányítása), és ezek a szerverkonfigurációban maradnak, nem a fájlokban.

Apache alatt tipikusan a .htaccess tartalmazza ezeket:

Redirect 301 /regi-szolgaltatas/ /szolgaltatasok/ipari-karbantartas/

Ellenőrizni a legegyszerűbben így tudod, még a DNS-váltás előtt, a hosts-fájlon keresztül az új szerverre mutatva:

curl -sI https://pelda.hu/regi-szolgaltatas/ | grep -i -e HTTP -e location

Amit itt látni akarsz: 301 és egyetlen Location sor, ami már a végleges, HTTPS-es, végleges alakú címre mutat. Ha két-három ugráson keresztül jut el oda, az lánc, és érdemes kisimítani. A belső hivatkozásokat is frissítsd a tartalomban, ne csak átirányítással oldd meg őket.

Miért bukik el ilyen sok migráció az e-mailen?

Rövid válasz: mert a levelezést az MX-rekord vezérli, a hitelesítést pedig a TXT-rekordok, és ezek külön életet élnek a weboldaltól.

Ha az új tárhelyre költözve az MX-rekord átvált, de a postafiókok tartalma nincs átmásolva, akkor a régi levelek eltűnnek a felhasználó szeme elől (a régi szerveren még ott vannak, de az ügyfélprogram már máshová csatlakozik). Ha az MX átvált, de az SPF-rekordot nem frissíted, a kimenő leveleid egy része spam mappába kerülhet.

Amit a váltás előtt tegyél:

• Készíts teljes IMAP-szintű másolatot a postafiókokról az új szerverre (mappaszerkezettel együtt), lehetőleg a váltás előtt, majd egy különbözeti szinkronnal a váltás után.
• Vidd át az SPF-, DKIM- és DMARC-rekordokat, és igazítsd őket az új kiküldő szerverhez.
• Ellenőrizd, hogy a weboldal rendszerüzenetei (űrlapok, megrendelés-visszaigazolások) honnan mennek ki. Ha a CMS a szerver saját levelezőjét használja, az új szerveren más lesz a küldő infrastruktúra.

Gyors ellenőrzés a rekordokra:

dig +short MX pelda.hu és dig +short TXT pelda.hu

Mi a helyes sorrend a DNS és az SSL beállításánál?

Rövid válasz: előbb készül el és lesz tesztelhető az új oldal, utána jön a tanúsítvány, és csak legvégül a DNS átállítása lecsökkentett TTL mellett.

1. Az új szerveren fusson az oldal teljesen készen, a saját hosts-fájlodból tesztelve.
2. Az új szerveren legyen érvényes SSL-tanúsítvány a domainre. Sok automatikus tanúsítványkiállítás csak akkor működik, ha a domain már az új szerverre mutat, ezért ha ez a helyzet, számolj rövid átmeneti hibaüzenettel, vagy használj DNS-alapú igazolást.
3. A váltás előtt 24-48 órával vidd le a TTL-t alacsony értékre (például 300 másodpercre), hogy a változás gyorsan terjedjen.
4. Váltsd át az A (és ha van, AAAA) rekordot, majd az MX-et. Lehetőleg ne pénteken, és ne kampányindítás előtti napon.
5. A stabilizálódás után emeld vissza a TTL-t a szokásos értékre.

Saját tapasztalat: a HSTS beállítás sok migrációt tud megkeseríteni. Ha a régi szerver hosszú élettartamú HSTS-fejlécet küldött, a böngészők akkor is HTTPS-t fognak erőltetni, amikor az új szerveren a tanúsítvány még nem áll készen, és a látogató hibaüzenetet lát. Ezt előre érdemes ellenőrizni.

Mit kezdj a méréssel, hogy ne legyen vakfolt a váltás körül?

Rövid válasz: a mérőkódokat és a konverziókat a váltás napján külön ellenőrizd, mert a másolás során rendszeresen kimaradnak vagy duplikálódnak.

A tipikus hibák: a mérőkód a régi sablonban maradt, és az új oldalon nincs benne; vagy egyszer a sablonban, egyszer a bővítményben is szerepel, így minden oldalletöltés kétszer számolódik; vagy a köszönőoldal URL-je megváltozott, és a konverziómérés némán leáll.

• Jegyezd fel a váltás pontos időpontját, és tegyél egy jelölést az analitikába, hogy később az adatszakadást ne trendnek olvasd.
• A Search Console-ban ellenőrizd a lefedettséget és a sitemapet a váltás után néhány nappal, majd egy hónappal.
• Nézd meg az űrlapokat élesben, valódi kitöltéssel, mind a weboldal, mind az e-mail oldaláról.
• Ellenőrizd a hirdetési fiókok konverziókövetését is, ha futnak kampányok.

Hogyan néz ki egy használható költöztetési checklist?

Rövid válasz: három szakaszban gondolkodj: felkészülés, éles váltás, utókövetés. A legtöbb kudarc az első szakasz kihagyásából ered.

Felkészülés

1. Hozzáférés-leltár (domain, tárhely, DNS, levelezés, mérés, hirdetési fiókok).
2. Teljes mentés a régi szerverről: fájlok, adatbázis, postafiókok.
3. A meglévő URL-ek listájának kigyűjtése (sitemap, analitika, keresőkonzol adatai alapján).
4. Szerverkörnyezet összehasonlítása (rendszerkiadások, kiterjesztések, memórialimitek).
5. Az új környezet felépítése és tesztelése hosts-fájlból, keresőmotorok elől lezárva.
6. Átirányítási terv elkészítése, ha az URL-ek változnak.
7. TTL csökkentése.

Éles váltás

1. Tartalomzár: a váltás alatt ne legyen szerkesztés a régi oldalon.
2. Utolsó különbözeti szinkron (adatbázis, feltöltött fájlok, levelek).
3. A keresőmotor előli lezárás feloldása az új szerveren, robots-beállítás ellenőrzése.
4. DNS-váltás (A, majd MX), SSL ellenőrzése.
5. Átirányítások és fő útvonalak végigkattintása, űrlaptesztek.
6. Mérőkódok ellenőrzése, sitemap újraküldése.

Utókövetés

1. Az első 72 órában napi hibanapló- és 404-ellenőrzés.
2. Levélküldés és -fogadás tesztelése több külső szolgáltató felé is.
3. A régi tárhely megtartása néhány hétig, mentéssel együtt.
4. Egy hónap múlva összevetés: forgalom, megjelenések, konverziók, oldalsebesség.

Egy jól előkészített migráció önmagában nem javít a láthatóságodon, és nem is garantál helyezéseket. Amit reálisan elérhetsz vele, az az, hogy a költözés ne rontson: az addig felépített találatok, hivatkozások és mérési előzmények megmaradjanak. Szakmai feltételezés: a szombathelyi cégeknél, ahol a munkaerőért és az ügyfelekért is határon átnyúló a verseny, az elérhetőség kiesése különösen drága, mert egy nem kézbesített ajánlatkérés jó eséllyel egy másik, akár osztrák oldali beszállítóhoz kerül át.

Források és további olvasnivalók

• Google Search Central: Site moves with and without URL changes
• Google Search Central: Redirects and Google Search
• Google Search Console súgó: Change of address eszköz
• IETF RFC 7208 (Sender Policy Framework, SPF)
• IETF RFC 6376 (DomainKeys Identified Mail, DKIM)
• IETF RFC 7489 (DMARC)
• IETF RFC 1035 (Domain Names, Implementation and Specification)
• W3C: Cool URIs don't change
• Mozilla Developer Network: HTTP Strict Transport Security
• Let's Encrypt hivatalos dokumentáció: Challenge Types