A weboldal költöztetés Debrecenben ritkán bukik el látványosan. Sokkal gyakoribb, hogy minden működni látszik, közben viszont a háttérben elveszik a régi linkek ereje, néhány napig akadozik a levelezés, vagy a mérés hetekre elnémul. Ez az útmutató azt szedi össze, mit rontanak el a legtöbben egy tárhelyváltásnál, és ad egy checklistet, amit lépésről lépésre végig tudsz venni.
Debrecen a keleti országrész központja, nagy egyetemi városi lakossággal és gyorsan fejlődő iparral, ahol a szolgáltatói és a B2B kereslet is bővül. Ebből fakad egy visszatérő helyzet: egy debreceni cég jellemzően egy helyi szolgáltatótól, egy korábbi ügynökségtől vagy egy ismerős fejlesztőtől költözik tovább. Ilyenkor a technikai tudás egy része a régi szolgáltatónál marad, és pont az apró, láthatatlan beállítások szoktak kimaradni az átadásból.
Miért kockázatos egyáltalán egy weboldal költöztetés?
Rövid válasz: mert egy weboldal nem egyetlen dolog, hanem több, egymástól független rendszer (fájlok, adatbázis, DNS, e-mail, tanúsítvány, mérés), és ezek nem egyszerre, nem azonos sebességgel állnak át.
Egy tárhelyváltás során a fájlokat és az adatbázist átmásolod egy új szerverre, de a látogató még mindig a régi címre (IP-re) érkezik, amíg a DNS át nem áll. Az e-mail sokszor teljesen külön szolgáltatáson fut. A tanúsítvány az új szerveren újra kell hogy generálódjon. A keresők és az analitika pedig a régi URL-struktúrát ismerik. (Saját tapasztalat:) a hibák többsége nem magából a másolásból ered, hanem abból, hogy valamelyik réteg átállása kimarad vagy rossz sorrendben történik.
Mi a leggyakoribb hiba az átirányításoknál?
A leggyakoribb hiba, hogy a régi címekről nem készül végleges (301-es) átirányítás az új címekre, vagy az átirányítás láncot alkot. Ez a szerzett linkerőt és a meglévő pozíciókat is kockáztatja.
Ha a költözéssel az URL-ek is változnak (például /szolgaltatasok.html helyett /szolgaltatasok/ lesz), akkor minden régi címnek pontos párja kell legyen az új oldalon. Hivatalosan igazolt: a Google dokumentációja szerint tartalmi költözésnél a 301-es (permanens) átirányítás a javasolt módszer, mert ez jelzi a keresőnek, hogy a tartalom végleg új helyre került.
Amit a legtöbben elrontanak:
- Lánc-átirányítás: a régi URL egy köztes címre mutat, az pedig egy harmadikra. Minden ugrás lassít és gyengít. Cél az egy lépéses átirányítás.
- Csak a főoldalra irányítás: minden régi aloldalt a nyitólapra dobnak. A kereső ezt gyakran lágy 404-ként kezeli, és a régi aloldal pozíciója elvész.
- Elfelejtett média és PDF: a képekre, letölthető dokumentumokra mutató régi linkek is 404-et adnak, ha nincs rájuk átirányítás.
Egy Apache alapú tárhelyen egy egyszerű szabály a .htaccess fájlban így néz ki:
Redirect 301 /regi-oldal.html https://ujdomain.hu/uj-oldal/
Nginx esetén a szerverblokkban jellemzően return 301 szolgál erre. A lényeg mindkét esetben ugyanaz: pontos, egy lépéses megfeleltetés a régi és az új cím között.
Miért marad ki olyan gyakran az e-mail a költözésnél?
Mert sokan azt hiszik, a weboldal és a levelezés ugyanaz. Valójában külön rekordok (MX) irányítják, és ha a DNS-t átállítod a webre gondolva, a leveleket akaratlanul is átirányíthatod egy üres új szerverre.
Ez a Debrecenben tipikus "helyi szolgáltatótól költözünk" helyzetben különösen éles. Sokszor a info@cegneve.hu típusú postafiókok a régi tárhelyen, a szolgáltató saját levelezőrendszerében élnek. Ha a domaint egy az egyben átvinni akarod, a levelek csak akkor maradnak elérhetők, ha:
- tudod, hol lesz a levelezés a költözés után (marad a réginél, vagy külön szolgáltatóhoz, például egy céges Google vagy Microsoft fiókhoz kerül),
- az
MXrekordokat ennek megfelelően állítod be, és nem a web IP-jére mutatnak, - a meglévő postafiókok tartalmát exportálod, mielőtt a régi hozzáférés megszűnik.
Saját tapasztalat: a legfájdalmasabb eset, amikor a régi tárhely-előfizetést a váltás után rögtön lemondják, és a postafiókokból még ki nem mentett levelek visszahozhatatlanul eltűnnek. A levelezés kimentése ezért az egyik legelső lépés legyen, ne az utolsó.
Mit kell tudni az SSL-tanúsítványról és a HTTPS-ről váltáskor?
Rövid válasz: az SSL-tanúsítvány az új szerverhez tartozik, nem "utazik" a fájlokkal. A váltás pillanatában legyen érvényes tanúsítvány, és a HTTPS legyen kikényszerítve, különben biztonsági figyelmeztetés vagy kevert tartalom fogadja a látogatót.
A legtöbb mai tárhely támogatja az ingyenes, automatikusan megújuló tanúsítványt (Let's Encrypt). A gond ott kezdődik, ha a tanúsítvány csak a DNS átállása után tud kiállni, mert addig az igazoló rendszer még a régi szervert látja. Ezért érdemes:
- az új szerveren előre előkészíteni a tanúsítványt, ahol a tárhely ezt támogatja,
- a váltás után ellenőrizni, hogy a HTTP forgalom is átirányul HTTPS-re,
- átnézni a kevert tartalom (mixed content) hibákat: régi,
http://előtagú kép- és szkripthivatkozásokat, amelyek a lakat ikont megtörik.
Hogyan kerüld el a DNS-átállás körüli kiesést?
A kulcs a DNS TTL (élettartam) előzetes csökkentése és a lépések helyes sorrendje. Ha a váltás előtt pár nappal levinni a TTL-t, az új beállítások sokkal gyorsabban terjednek szét.
A DNS rekordokat a világ szerverei egy ideig gyorsítótárazzák, ennek hossza a TTL. Ha ez például 24 óra, akkor a váltás után akár egy napig egyes látogatók még a régi szerverre érkeznek. Szakmai feltételezés: a legtöbb kisebb debreceni oldalnál a következő sorrend csökkenti a legjobban a kockázatot:
- Néhány nappal a váltás előtt vidd le a TTL-t (például 300 másodpercre).
- Töltsd fel és teszteld az oldalt az új szerveren, ideiglenes címen vagy a hosts fájl átírásával, még mielőtt a DNS-t állítod.
- Készítsd elő az e-mail rekordokat és a tanúsítványt.
- Csendesebb időszakban (nem csúcsforgalom idején) állítsd át a DNS-t az új szerverre.
- Tartsd életben a régi tárhelyet még legalább egy-két hétig, hogy az esetleges lemaradókat is kiszolgálja.
Miért néma a mérés a költözés után, és mit tegyél ellene?
Mert az analitikai kód, a konverziómérés és a Search Console beállítások nem másolódnak automatikusan az új tartalommal. Ha nem ellenőrzöd őket, hetekig vakon repülsz, épp amikor a legjobban kellene látnod a hatásokat.
A költözés utáni napokban a mérés a korai figyelmeztető rendszered. Ezekre figyelj:
- Search Console: ha az URL vagy a domain változott, add hozzá az új verziót, és ahol releváns, használd a költöztetés (change of address) funkciót. Kövesd az indexelési és lefedettségi jelentéseket.
- Analitika: ellenőrizd, hogy a mérőkód minden oldalon ott van-e az új szerveren. Egy sablonváltás gyakran letörli a beillesztett kódrészleteket.
- Konverziók és űrlapok: küldj tesztkitöltést minden fontos űrlapon. A levelezés átállása miatt előfordul, hogy az űrlap elküldi az adatot, de az e-mail értesítés nem érkezik meg.
- Sitemap és robots: az új
sitemap.xml-t add be a Search Console-ba, és nézd meg, hogy arobots.txtvéletlenül nem tiltja-e le a teljes oldalt (fejlesztés alatt gyakori a "minden tiltva" beállítás, ami élesben bent felejtődik).
Milyen a jó, lépésről lépésre költöztetési checklist?
Rövid válasz: a jó checklist a váltás előtti, alatti és utáni fázist külön kezeli, és semmit nem bíz a "majd biztos működik" érzésre.
Váltás előtt:
- Teljes biztonsági mentés a fájlokról és az adatbázisról.
- A meglévő postafiókok és levelek kimentése.
- A régi URL-ek listázása és megfeleltetése az új címeknek (átirányítási terv).
- DNS TTL csökkentése.
- Az oldal feltöltése és tesztelése az új szerveren, még a nyilvános átállás előtt.
Váltás alatt:
- SSL-tanúsítvány előkészítése az új szerveren.
- MX (e-mail) rekordok helyes beállítása.
- DNS átállítása csendes időszakban.
- 301-es átirányítások élesítése.
Váltás után:
- HTTPS és kevert tartalom ellenőrzése.
- Fontosabb aloldalak és a 404-es oldal végigkattintása.
- Űrlapok és e-mail értesítések tesztje.
- Analitika és Search Console ellenőrzése, sitemap beadása.
- A régi tárhely megtartása még egy-két hétig.
Ez a lista nem old meg minden helyzetet, és nem is ad biztos eredményt: minden oldal más felépítésű. De ha végigveszed, jó eséllyel kiszűröd azokat a hibákat, amelyek a legtöbb kellemetlenséget okozzák. Saját tapasztalat: a legnyugodtabb költözések azok, ahol a régi és az új rendszer egy darabig párhuzamosan él, és csak akkor kapcsolják le a régit, amikor az új már bizonyítottan mindent kiszolgál.
Források és további olvasnivalók
- Google Search Central: Site moves with URL changes (költöztetési útmutató)
- Google Search Central: Change of address tool dokumentáció
- MDN Web Docs: HTTP redirects (301, 302) leírás
- Let's Encrypt hivatalos dokumentáció (SSL-tanúsítvány)
- IETF DNS specifikációk (RFC 1034, RFC 1035) a TTL és a rekordtípusok kapcsán
- Schema.org: strukturált adat referencia
- A régi URL-ekről mindig 301-es (végleges) átirányítás vezessen az újakra, lánc nélkül.
- Az e-mail és a weboldal két külön dolog: a DNS-átállásnál külön kell kezelni a levelezést.
- SSL-tanúsítvány és HTTPS-kényszerítés a váltás pillanatában legyen kész, ne utólag.
- A DNS TTL csökkentése a váltás előtt lerövidíti az átmeneti kiesést.
- A mérés (Search Console, analitika, konverziók) átvitele nélkül vakon repülsz a költözés után.
Gyakori kérdések
Meddig tartsam meg a régi tárhelyet a költözés után?
Általában legalább egy-két hét ajánlott. Ennyi idő alatt a DNS mindenhol átáll, kiderülnek az esetleges hibák, és a késve érkező látogatókat is kiszolgálja a régi szerver. A levelezés kimentését érdemes még ez előtt elvégezni.
Elveszik-e a Google-helyezésem, ha költöztetem az oldalt?
Nem szükségszerűen. Ha az URL-ek nem változnak, a hatás jellemzően kicsi. Ha változnak, a pontos 301-es átirányítások és a Search Console költöztetési funkciója segíthet megőrizni a pozíciókat, de biztos eredményt egyetlen módszer sem ad.
Mi történik az e-mail címeimmel tárhelyváltáskor?
Attól függ, hol lesz a levelezés a váltás után. Ha marad a régi szolgáltatónál vagy külön rendszerbe (például céges Google vagy Microsoft fiókba) kerül, az MX rekordokat ennek megfelelően kell beállítani. A meglévő leveleket mindig mentsd ki, mielőtt a régi hozzáférés megszűnik.
Mennyi ideig tart, amíg a DNS-átállás mindenhol érvényre jut?
A TTL beállításától függ. Ha a váltás előtt lecsökkented (például 300 másodpercre), az új beállítás sokszor pár órán belül szétterjed. Magas TTL mellett ez akár egy napig is eltarthat, ezért érdemes előre csökkenteni.
Debrecenben helyi szolgáltatótól költözöm, mire figyeljek külön?
Kérd el időben az összes hozzáférést: tárhely, domain (regisztrátor), levelezés, tanúsítvány. Sokszor épp ezek maradnak a régi szolgáltatónál. A domain feletti rendelkezés különösen fontos, enélkül a DNS-t sem tudod átállítani.
Muszáj fejlesztőt bevonni, vagy egyedül is megoldható a költözés?
Egyszerűbb, kevés aloldalas oldalnál egy alapos, technikailag magabiztos tulajdonos végig tud menni a checklisten. Összetettebb oldalnál, sok átirányítással, egyedi levelezéssel vagy webshoppal a szakmai segítség csökkentheti a hibázás kockázatát.
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.