Domainváltás vagy platformváltás előtti technikai ellenőrzőlista: mit rögzíts, mielőtt bármit átkapcsolsz

Scheo · 2026-08-22 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A domainváltás és a platformváltás két külön művelet, de egy dologban azonosak: mindkettő az addig felépített technikai és bizalmi réteget mozgatja át egy új helyre. A keresők, az AI-válaszmotorok, a rád hivatkozó oldalak és a saját analitikád is egy konkrét URL-készlethez kötötték azt, amit rólad tudnak. Ha ezt a készletet úgy mozgatod meg, hogy előtte nem írtad le pontosan, mi volt, akkor nemcsak a hibát nem tudod majd kijavítani: észrevenni sem fogod, mert nem lesz mihez hasonlítani.

Ez az írás nem a migráció lépéseiről szól, hanem arról a néhány óráról, amit előtte érdemes rászánni az adatrögzítésre. A tapasztalat szerint ez a legjobban megtérülő munkaóra az egész projektben, mégis ez marad ki a leggyakrabban, mert a váltás napján mindenki a technikai átállásra figyel.

Miért kell mindent a váltás ELŐTT rögzíteni?

Rövid válasz: mert a régi állapot a váltás pillanatában megszűnik létezni, és a legtöbb adat utólag már nem állítható helyre. Ha a régi rendszert leállítod vagy a domaint átirányítod, a régi oldalak HTML-je, a régi belső linkstruktúra, a régi címkék és metaadatok nem lesznek lekérdezhetők. A régi szerver logjai gyakran a hosting váltásával együtt eltűnnek.

Hivatalosan igazolt: a Google Search Console teljesítményjelentése 16 hónapig őrzi az adatokat, és a régi tulajdon (property) adata a domainnel együtt marad ott, nem költözik át. A GA4-ben az esemény- és felhasználószintű adatmegőrzés alapértelmezetten korlátozott (2 vagy 14 hónap, beállítástól függően), az összesített riportok viszont tovább elérhetők. Saját tapasztalat: a legtöbb kisebb vállalkozásnál senki nem nézi meg ezeket a beállításokat a váltás előtt, és két évvel később már nincs mihez viszonyítani.

Mit veszítesz, ha kimarad az adatrögzítés?

Rövid válasz: az összehasonlítás lehetőségét, és ezzel a hibajavítás irányát. Konkrétan a következőket:

• Az elveszett URL-eket. Ha nincs teljes lista arról, mi létezett, nem tudod megmondani, melyik 40 aloldal nem kapott átirányítást.
• A hivatkozásokat. Egy régi aloldalra mutató külső link a váltás után 404-re fut, és ha nem tudod, hogy az az URL létezett, soha nem is fogod pótolni.
• A viszonyítási alapot. Forgalomesésnél nem lehet eldönteni, hogy a migráció, egy algoritmusfrissítés vagy szezonalitás okozta.
• Az örökölt átirányítási logikát. Egy több éve élő oldalon jellemzően van 20-200 régi átirányítás korábbi kampányokból és korábbi struktúrákból. Ezek nélkül a régi linkek egy része megszakad.
• A bizonyítékot. Ha külső fejlesztő végezte a váltást, alapvonal nélkül szakmai vita lesz abból, hogy romlott-e a helyzet.

Milyen tételekből áll a váltás előtti ellenőrzőlista?

Rövid válasz: legalább tizenöt tételből, és mindegyiket fájlba kell menteni, nem képernyőképre. A képernyőkép nem kereshető és nem összehasonlítható. A cél egy dátumozott mappa, benne CSV-k és szöveges fájlok.

1. Teljes crawl exportálása. Futtass végig egy crawlert (Screaming Frog, Sitebulb vagy hasonló) az egész oldalon, és mentsd ki az összes belső URL-t státuszkóddal, címmel, meta leírással, H1-gyel, canonical értékkel és indexelhetőségi állapottal. Ez lesz a migráció gerincoszlopa.
2. Sitemap fájlok mentése. Töltsd le nyersen a sitemap.xml és minden hivatkozott al-sitemap tartalmát. A generált sitemap az új platformon szinte biztosan más lesz, a régi viszont megmutatja, mit tartottál fontosnak.
3. A robots.txt archiválása. Mentsd el a fájl pontos tartalmát. Hivatalosan igazolt: a Google a robots.txt-t jellemzően legfeljebb 24 óráig gyorsítótárazza, tehát egy hibás új fájl gyorsan hat. A régi példány nélkül nehéz kideríteni, mi változott.
4. Meglévő átirányítási szabályok kimentése. Apache alatt a .htaccess, nginx alatt a szerverblokk, WordPressen a redirection plugin exportja, webshopnál az admin átirányítás-táblája. Mindegyik külön fájlba, dátummal.
5. Rangsor-alapvonal rögzítése. Mentsd ki a követett kulcskifejezések aktuális pozícióit a rangkövető eszközödből, és ha nincs ilyen, legalább a Search Console teljesítményjelentésének lekérdezés-szintű exportját 3 és 12 hónapra visszamenőleg.
6. Search Console oldal-szintű export. Lekérdezés helyett oldal (Pages) bontásban is exportálj: melyik URL hány megjelenítést és kattintást hozott. Migráció után ez az egyetlen fájl, amiből kiderül, melyik régi URL számított valóban.
7. Indexelési állapot pillanatkép. Az Oldalak (Page indexing) jelentésből mentsd ki, hány URL indexelt, és mi a kizárási okok megoszlása. Az új oldal első heteiben ez lesz a mérce.
8. Analitikai alapvonal. GA4-ből legalább 13 hónap: forgalmi forrásonkénti bontás, céloldal-szintű bontás, konverziós események havi bontásban. Exportáld CSV-be, ne bízd az online riportra.
9. Konverziós események és mérési azonosítók listája. Írd össze, milyen események léteznek, milyen néven, és melyik mérőkód (GA4 azonosító, Meta pixel, Google Ads konverziócímke) van beépítve, és pontosan hol. Platformváltásnál ezek a leggyakrabban felejtett elemek.
10. Külső hivatkozások exportja. Search Console Linkek jelentése (leggyakrabban hivatkozott oldalak és hivatkozó domainek), plusz ha van, egy külső linkelemző eszköz exportja. Ezekre az URL-ekre kell a legpontosabb átirányítás.
11. Strukturált adatok mentése. Mentsd ki, milyen sémákat használsz (Organization, LocalBusiness, Product, FAQPage, Article) és melyik sablonon. Platformváltásnál a strukturált adat szinte mindig elveszik, mert az új téma máshogy generálja.
12. Szerverlog minta. Kérj el a tárhelyszolgáltatótól legalább 30 nap nyers hozzáférési logot. Ez az egyetlen forrás, amiből kiderül, milyen URL-eket kérnek le valójában a robotok és az AI-crawlerek, beleértve azokat, amiket a crawler nem talált meg belső linkről.
13. DNS-rekordok pillanatképe. A teljes zóna kimentése: A, AAAA, CNAME, MX, TXT (benne az SPF, DKIM, DMARC és a tulajdonlás-igazoló rekordok). Saját tapasztalat: domainváltásnál a legfájdalmasabb üzemzavar nem SEO-hiba, hanem a leálló e-mail, mert az MX és a levelezés hitelesítő rekordjai kimaradtak.
14. SSL és HTTPS-állapot. Jegyezd fel, milyen tanúsítvány van, mikor jár le, és hogy a HTTP-ről HTTPS-re, illetve a www és nem-www között milyen irányba megy az átirányítás. Az új rendszerben ugyanannak az iránynak kell megmaradnia.
15. Oldalsebesség és Core Web Vitals alapvonal. Mérd le a legfontosabb öt sablont (főoldal, kategória, termék vagy szolgáltatás, blogcikk, kapcsolat), és mentsd a mért értékeket. Ha az új platform lassabb, ezzel tudod bizonyítani.
16. A régi oldal statikus mentése. Egy teljes fájlrendszer- és adatbázismentés, plusz egy statikus HTML-tükör a legfontosabb oldalakról. Ha valami visszaállításra szorul, ez ér a legtöbbet.
17. Átirányítási térkép megírása. Az 1. és 6. pont összefésülésével készíts egy táblázatot ilyen formában: regi_url;uj_url;301. Minden régi URL-nek legyen sora, és a maradék soroknak is legyen döntése, akár úgy, hogy szándékosan 410-et adnak vissza.

Hogyan állítsd össze a valóban teljes URL-listát?

Rövid válasz: egy forrásból soha nem lesz teljes, legalább négyet kell egyesíteni. A crawler csak azt találja meg, ami belső linkről elérhető. A sitemap csak azt tartalmazza, amit a rendszer beletesz. A Search Console csak azt mutatja, ami megjelenítést kapott. A szerverlog viszont azt is megmutatja, amit ténylegesen lekérnek.

A gyakorlatban ez négy CSV, amiket egyetlen táblázatban egyesítesz URL szerint, majd duplikátumot szűrsz. Egy pár száz oldalas céges honlapnál ez jellemzően 15-30 százalékkal több URL-t ad, mint amennyit a crawl önmagában megtalált. A többlet nagy része régi kampányoldal, nyomtatható változat, régi blogbejegyzés és paraméteres URL, tehát pontosan az a réteg, amit egy migráció csendben elnyel.

Ellenőrzésnek érdemes néhány kulcsfontosságú URL fejlécét kézzel is elmenteni: curl -sI https://regidomain.hu/fontos-oldal/. Így később összehasonlítható, mi változott a státuszkódban és a canonical fejlécben.

Mit ellenőrizz az első órában, az első napon és az első hónapban?

Rövid válasz: az első órában azt, hogy elérhető-e egyáltalán; az első napon azt, hogy jól van-e átirányítva; az első hónapban azt, hogy visszaépült-e az indexelés.

Első óra

• A főoldal és a legfontosabb öt aloldal 200-as státusszal betölt, HTTPS-en, tanúsítványhiba nélkül.
• A robots.txt nem tartalmaz Disallow: / sort, és nem a fejlesztői változat került ki.
• Nincs véletlen noindex a sablonokban. Ez a leggyakoribb platformváltási hiba, mert a fejlesztői környezet indexelés-tiltása gyakran átjön az élesbe.
• Húsz mintavételes régi URL 301-gyel a helyes új URL-re megy, egy lépésben, lánc nélkül.
• Az űrlapok küldenek, a levelek megérkeznek, a fizetési folyamat végigmegy.
• A mérőkódok tüzelnek: GA4 valós idejű riport, pixel-ellenőrző.

Első nap (24-48 óra)

• Teljes crawl az új oldalon, és összevetés a váltás előtti crawllal: mennyi URL hiányzik, hol keletkezett 404 vagy átirányítási lánc.
• A teljes régi URL-lista végigfuttatása státuszkód-ellenőrzésen, nem csak a mintáé.
• Új sitemap beküldése a Search Console-ban, és ha domain változott, a Címváltoztatás (Change of Address) eszköz használata. Hivatalosan igazolt: ez az eszköz kifejezetten domainváltásra való, platformon belüli URL-struktúra-váltásra nem.
• Az új domain vagy tulajdon hitelesítése, és a régi tulajdon megtartása, nem törlése.
• Belső linkek átírása: a szövegtörzsben maradt régi abszolút hivatkozások cseréje. Az átirányítás nem helyettesíti ezt.
• Hirdetési fiókok céloldalainak frissítése, hogy ne átirányításon keresztül érkezzen a fizetett forgalom.
• Canonical, hreflang és strukturált adat ellenőrzése legalább sablononként egy oldalon.

Első hónap

• Hetente egyszer: indexelt oldalak száma és a kizárási okok megoszlása a váltás előtti alapvonalhoz mérve.
• A Search Console lefedettségi hibáinak átnézése, különös figyelemmel a hirtelen megjelenő átirányítási hibákra és soft 404-ekre.
• Szerverlog elemzése: mely régi URL-eket kérik még a robotok, és kapnak-e rájuk helyes választ.
• Rangsor-összevetés a rögzített alapvonallal, kulcskifejezésenként, nem összesítve.
• Hivatkozó partnerek megkeresése a legértékesebb linkeknél, hogy közvetlenül az új URL-re mutassanak.
• A megmaradt 404-ek havi átnézése, és a hiányzó átirányítások pótlása.
• Ha AI-válaszmotorokban is szeretnél megjelenni, érdemes ellenőrizni, hogy az AI-crawlerek nincsenek-e véletlenül kizárva az új robots.txt-ben.

Miért csak 6-10 hét múlva látszik a rossz migráció ára?

Rövid válasz: mert az indexelés és az újraértékelés lassabb, mint a forgalom napi ingadozása, ezért az esés eleinte elvész a zajban. Ez a rész saját nézőpont, tehát saját tapasztalat és szakmai feltételezés keveréke, nem hivatalos állítás.

A váltás utáni első két hétben a régi URL-ek nagy része még indexben van, a márkás keresések változatlanul beesnek, és a visszatérő látogatók emlékezetből is megtalálnak. A negyedik hét körül kezd látszani, hogy a hosszú farkú, információs lekérdezésekre érkező forgalom fogy. A hatodik és tizedik hét között áll be az új, alacsonyabb szint, és ekkor már nehéz visszakeresni, mi történt, mert a döntéshozók fejében a migráció addigra lezárt projekt.

Ehhez jön egy második mechanizmus: a lassan gyűjtött külső hivatkozások és a régi tartalomra épült említések értéke nem egyszerre esik ki, hanem ahogy a keresők újrafeldolgozzák a hivatkozó oldalakat. Ez hetekben mérhető folyamat. Szakmai feltételezés: az AI-válaszmotorok esetében ez a késleltetés még hosszabb lehet, mert a modellek és a hozzájuk kapcsolt keresési index frissítési üteme eltérő, tehát egy migráció után egy darabig még a régi URL-eket idézhetik. Ez nem garantált viselkedés, csak megfigyelés.

A gyakorlati következtetés: a migráció akkor van kész, ha 10 hét után az alapvonalhoz mérten stabil a kép, nem akkor, amikor az oldal betölt. Ezért érdemes már a projekt elején kitűzni egy visszamérési dátumot, és naptárba tenni.

Miben más a platformváltás, mint a domainváltás?

Rövid válasz: domainváltásnál a cím változik, platformváltásnál a tartalom előállítási módja, és az utóbbi csendesebben ront el dolgokat. Domainváltásnál a hibák látványosak: rossz átirányítás, 404, e-mail-kiesés. Platformváltásnál viszont a struktúra maradhat változatlan, miközben eltűnnek a meta leírások, megváltozik a címsor-hierarchia, kiesik a strukturált adat, más lesz a képek alt szövege, és a lapozás vagy a szűrés új paraméteres URL-eket generál.

Ezért platformváltásnál a rögzítés hangsúlya a tartalmi mezőkön van: cím, meta leírás, H1, canonical, alt szöveg, strukturált adat, belső linkek. A crawl exportjában ezek mind benne vannak, tehát a váltás után ugyanazzal az eszközzel újra lefuttatva mezőnként összehasonlítható, mi veszett el. Saját tapasztalat: a leggyakoribb veszteség a kézzel írt meta leírás és a képek alt szövege, mert ezek gyakran a régi téma vagy a régi plugin saját adatbázistáblájában laktak, és a migrációs script nem hozza át őket.

Ha a váltás során az URL-struktúra is változik, akkor a két művelet egyszerre történik, és ilyenkor érdemes megfontolni a szétválasztást: előbb platform, változatlan URL-ekkel, majd néhány hét stabil működés után a domain. Ez lassabb, viszont ha romlik valami, egyértelmű, melyik lépés okozta. Ez javaslat, nem szabály, és nem minden projektben kivitelezhető.

Források és további olvasnivalók

• Google Search Central: Site moves with URL changes (dokumentáció)
• Google Search Central: Change of Address tool (Search Console súgó)
• Google Search Central: Robots.txt specifikáció és gyorsítótárazás
• Google Search Console súgó: Teljesítményjelentés és adatmegőrzés
• Google Analytics 4 súgó: Adatmegőrzési beállítások
• Sitemaps.org: XML sitemap protokoll
• Schema.org: strukturált adat szókészlet
• W3C: HTTP státuszkódok és átirányítási szemantika (RFC 9110)