CMS migration: teljes útmutató

A CMS migration, magyarul tartalomkezelő-rendszer váltás, az a folyamat, amikor egy webhely tartalmát, sablonjait és beállításait egyik CMS-ből a másikba költöztetjük. Keresőoptimalizálási szempontból a cél az, hogy a régi rendszerben felépített helyezések, linkek és indexelt oldalak veszteség nélkül átkerüljenek. Ehhez URL-leltár, mezőszintű adatleképezés, 301-es átirányítási térkép és az élesítés utáni mérés kell.

Alapfogalmak

A CMS (Content Management System) az a szoftver, amelyben a webhely tartalmát szerkesztjük, tároljuk és megjelenítjük. CMS-váltásról akkor beszélünk, amikor ezt a motort cseréljük le: például egy saját fejlesztésű rendszerről egy elterjedt nyílt forrású platformra, egy webáruház-motorról egy másikra, vagy egy hagyományos rendszerről úgynevezett headless megoldásra. A váltás önmagában technikai döntés, de a keresőoptimalizálásra gyakorolt hatása sokszor nagyobb, mint amire a projekt indításakor számítanak.

A CMS-váltás a webhely-migráció egyik típusa. A tágabb keretet, vagyis azt, hogy milyen migrációtípusok léteznek és hogyan kapcsolódnak egymáshoz, a site migration útmutató tárgyalja. Ha a rendszercsere mellett a domain is változik, azt külön kockázatként érdemes kezelni, erről a domain migration útmutató szól. Ez a cikk kizárólag arra koncentrál, ami a tartalomkezelő cseréjéből következik.

Miért kockázatos a CMS-váltás, ha a domain és a tartalom ugyanaz marad? Mert minden rendszer a saját logikája szerint állítja elő az oldalakat. Más URL-mintát használ, máshogy kezeli a kategóriákat és címkéket, más mezőben tárolja a title-t és a meta leírást, és más HTML-szerkezetet generál. Ha ezeket a különbségeket senki nem veszi számba, a keresőmotor egy részben új webhelyet lát a régi címen.

Érdemes a projekt elején azt is rögzíteni, ki felel a SEO szempontokért. A CMS-váltást jellemzően fejlesztők és tartalomszerkesztők viszik, akiknek a fő célja, hogy az új rendszer működjön és a tartalom átkerüljön. A keresőoptimalizálási paritás ellenőrzése külön feladat, és ha nincs gazdája, könnyen kimarad a határidő szorításában.

A legfontosabb fogalmak

Fogalom	Jelentése CMS-váltásnál
URL-leltár	A régi rendszer összes indexelhető és forgalmat hozó címének teljes listája.
Adatleképezés (mapping)	Melyik régi mező melyik új mezőbe kerül: cím, törzsszöveg, meta adatok, képek, szerző, dátum.
Átirányítási térkép	Régi URL és új URL párosítása, jellemzően 301-es állapotkóddal.
Paritás	Az új oldal SEO szempontból egyenértékű a régivel: ugyanaz a tartalom, belső linkek, meta adatok és indexelési jelzések.
Staging környezet	Zárt tesztkörnyezet, ahol az új rendszert élesítés előtt ellenőrizzük.

A paritás a CMS-váltás központi fogalma. A legbiztonságosabb migráció az, amelyik után a kereső szemszögéből szinte semmi nem változik: ugyanazok a címek, ugyanaz a szöveg, ugyanazok a jelzések. Minden eltérés, amit tudatosan vállalunk, legyen dokumentálva, és legyen mögötte indok.

Hogyan működik?

A keresőmotor nem tudja, hogy a webhely mögött CMS-t cseréltek. Csak azt látja, amit feltérképezéskor kap: a HTML-t, az állapotkódokat, az átirányításokat, a robots utasításokat és a sitemapot. A CMS-váltás tehát annyiban hat a keresésre, amennyiben ezek a kimenetek megváltoznak. Ez egyben jó hír is, mert a kockázat mérhető és ellenőrizhető, ha tudjuk, mit kell összevetni.

Élesítés után a feltérképező robot a régi címeken keresztül fedezi fel az új rendszert. Ahol a cím változatlan maradt, ott a tartalom és a jelzések változását dolgozza fel. Ahol a cím megváltozott, ott az átirányítás vezeti el az új címre, és a jelek fokozatosan átkerülnek. Ahol sem azonos cím, sem átirányítás nincs, ott 404-es hibát talál, és az oldal idővel kiesik az indexből. Hogy ez az átrendeződés mennyi ideig tart, az webhelyenként erősen eltér, ezért konkrét időtartamot ígérni nem érdemes.

A CMS-váltás négy fázisa

Felmérés: a régi webhely teljes feltérképezése, a forgalmat és linkeket hozó oldalak azonosítása, a jelenlegi meta adatok és strukturált adatok mentése.
Leképezés: az új rendszer URL-mintáinak, sablonjainak és mezőinek összevetése a régivel, az átirányítási térkép elkészítése.
Tesztelés: a staging környezet feltérképezése, az eredmény összehasonlítása a régi webhely mentésével, az eltérések javítása.
Élesítés és utánkövetés: átállás, azonnali ellenőrzés, majd hetekig tartó mérés és hibajavítás.

A négy fázis közül a leképezést szokták alábecsülni. A tartalom exportja és importja gyakran eszközzel megoldható, de a mezők jelentése rendszerenként eltér. Egy régi rendszerben a kivonat mező lehetett egyben a meta leírás is, az újban ez két külön mező. Ha az importáló szkript ezt nem tudja, az összes oldal meta leírás nélkül kerül élesbe.

Egy saját példa a leképezésre: egy 1200 oldalas szakmai blogot költöztetünk. A régi rendszer cikk URL-jei /cikk/123-cim mintát követnek, az új rendszer alapértelmezetten /blog/cim/ formát ad. Két út van: vagy az új rendszer permalink-beállításait igazítjuk a régi mintához, vagy mind az 1200 címre átirányítást írunk. Az első megoldás paritást tart, a második 1200 átirányítást és egy új URL-struktúrát jelent, amit a keresőnek újra meg kell tanulnia. Ha nincs üzleti ok a változtatásra, az első a jobb döntés.

Fő módszerek

A CMS-váltásnak nincs egyetlen helyes módja. A választás attól függ, mennyi idő és fejlesztői kapacitás áll rendelkezésre, mekkora a webhely, és mennyire tér el az új rendszer a régitől. Az alábbi három módszer fedi le a gyakorlati esetek nagy részét.

1. Egylépcsős átállás paritással

Az új rendszerben a régi webhelyet a lehető legpontosabban leképezzük: azonos URL-ek, azonos tartalom, azonos meta adatok, és csak a motor cserélődik. Ahol az új rendszer nem tudja pontosan visszaadni a régi URL-mintát, ott egyedi útvonal-szabállyal vagy átirányítással pótoljuk a hiányt. A dizájn és a szerkezet átalakítása egy későbbi, külön projekt. Ez a legkisebb kockázatú út, mert ha élesítés után a forgalom változik, az ok szűk körben kereshető.

2. Egylépcsős átállás átalakítással

A rendszercserével együtt változik az URL-struktúra, a navigáció és a sablonok. Időt takarít meg, de ha a forgalom esik, nehéz kideríteni, hogy a CMS, az új URL-ek, a megváltozott belső linkelés vagy a tartalom átírása okozta. Ennél a módszernél az átirányítási térkép és az élesítés előtti összehasonlító feltérképezés nem opcionális.

3. Szakaszos migráció

A webhely részeit egymás után költöztetjük: először például a blogot, aztán a termékoldalakat. A két rendszer egy ideig párhuzamosan fut, a kiszolgálást egy fordított proxy vagy útválasztási szabály osztja meg. Nagy webhelyen ez csökkenti egy-egy lépés kockázatát, cserébe az átmeneti időszakban két rendszert kell üzemeltetni, és figyelni kell arra, hogy a közös elemek, például a fejléc menüje és a sitemap, egységesek maradjanak.

A szakaszos módszernél minden egyes szakasz után ugyanazt az ellenőrzést kell lefuttatni, mint egy teljes migrációnál. Ez több munka, de egy hibás szakasz csak a webhely egy részét érinti, és a tanulságok a következő lépésnél már beépíthetők.

Döntési szabály

Helyzet	Javasolt módszer
A webhely jól teljesít, a váltás oka technikai (biztonság, karbantarthatóság)	Egylépcsős átállás paritással
A régi URL-struktúra kifejezetten rossz, és úgyis át kell alakítani	Átalakítással, de részletes átirányítási térképpel
Sok ezer oldal, több tartalomtípus, külön felelős csapatok	Szakaszos migráció
Szűk határidő, kevés tesztelési idő	Paritás, az átalakítás későbbre halasztva

A gyakorlati szabály egyszerű: egyszerre csak annyit változtass, amennyinek a hatását el tudod különíteni. Ha a CMS-csere mellett új dizájn is jön, a legtöbb esetben jobban jársz, ha először a motor cserélődik, és a dizájn csak akkor kerül élesbe, amikor a forgalom már stabil.

Gyakori hibák

A CMS-váltások során előforduló SEO hibák nagy része nem a rendszerből, hanem a hiányos előkészítésből ered. Az alábbiak azok, amelyekkel a leggyakrabban találkozni, és amelyek szinte mindig megelőzhetők egy alapos ellenőrzőlistával.

Tipikus hibák és megelőzésük

Hiba	Következmény	Megelőzés
Az URL-leltár csak a sitemapból készül	Kimaradnak a régi, de linkeket hozó címek	Leltár feltérképezésből, analitikából, Search Console adatokból és szervernaplókból
A meta adatok nem kerülnek át	Automatikusan generált, egyforma title és leírás	Mezőszintű leképezés és mintavételes ellenőrzés import után
A staging noindex beállítása élesbe kerül	Az oldalak kikerülhetnek az indexből	Élesítési ellenőrzőlistán külön pont a robots utasításokra
Átirányítás a főoldalra minden régi címről	A kereső ezeket soft 404-ként kezelheti	Egy az egyhez párosítás a legközelebbi releváns oldalra
Átirányítási láncok	Lassabb feltérképezés, jelvesztés kockázata	A régi átirányításokat is frissíteni a végső célra
Megváltozott belső linkek	A belső linkek átirányításon keresztül mutatnak	Import után a törzsszövegek linkjeinek átírása az új címekre
Elvesző strukturált adatok	Kieshetnek a bővített találati megjelenések	A régi sablonok strukturált adatainak leltára és újraépítése

A staging környezet kezelése külön figyelmet érdemel. A tesztkörnyezetet el kell zárni a keresők elől, de ez a zárás nem kerülhet át az éles oldalra. A legbiztonságosabb a jelszavas védelem, mert azt élesítéskor biztosan eltávolítják, hiszen enélkül a látogatók sem érnék el az oldalt. Ha mégis noindex vagy robots.txt tiltás védi a stagingot, az élesítés után első teendő ennek ellenőrzése. A részleteket a meta robots és a robots.txt útmutató tárgyalja.

Gyakori, kevésbé látványos hiba a képek elvesztése. A régi rendszer képei gyakran saját könyvtárszerkezetben, saját fájlnevekkel élnek. Ha az új rendszer átnevezi vagy átméretezi őket, a régi kép URL-ek 404-et adnak, és a képkeresésből érkező forgalom elveszhet. A képfájlok címeit is fel kell venni a leltárba, és ahol változnak, ott rájuk is átirányítás kell.

Végül a tartalmi eltérés: az import során eltűnhetnek bekezdések, táblázatok, beágyazott elemek, vagy megváltozhat a címsorok hierarchiája. Ezt csak összehasonlító ellenőrzés mutatja meg, szemre nem. Hasznos, ha az import után oldalanként összevetjük a régi és az új törzsszöveg szószámát: ahol jelentős az eltérés, ott kézi ellenőrzés kell, mert jó eséllyel hiányzik valami a tartalomból.

Mérés

A CMS-váltás sikerét két időpontban kell mérni: élesítés előtt a stagingon, és élesítés után az éles webhelyen. A kettő között az a különbség, hogy előtte még olcsó javítani, utána már forgalom múlik rajta. A mérés alapja mindkét esetben a kiinduló állapot mentése, amelyhez viszonyítani lehet.

Élesítés előtti ellenőrzőlista

A régi webhely teljes feltérképezése elmentve: URL, állapotkód, title, meta leírás, H1, canonical, szószám, belső linkek száma.
A staging feltérképezése ugyanezekkel az oszlopokkal, majd a két táblázat összevetése URL szerint.
Az átirányítási térkép minden sora tesztelve: a régi cím egyetlen lépésben, 301-es kóddal az új címre visz, amely 200-as kódot ad.
Az új XML sitemap csak indexelhető, 200-as kódú, kanonikus címeket tartalmaz.
Robots.txt, meta robots és X-Robots-Tag fejlécek ellenőrizve.
Strukturált adatok mintavételesen validálva.

Élesítés utáni mérés

Az élesítés napján a legfontosabb a hibák gyors kiszűrése: a teljes átirányítási lista újratesztelése, a top oldalak kézi ellenőrzése és a szervernaplók figyelése, hogy a feltérképező robot milyen állapotkódokat kap. Ezt követően heti bontásban érdemes figyelni az organikus kattintásokat és megjelenéseket a Search Console-ban, az indexelési jelentést, a 404-es hibák alakulását és a feltérképezési statisztikákat.

Egy saját eltérés-táblázat mintája, amelyet az összehasonlító feltérképezés után töltünk ki:

Mérőszám	Régi webhely	Staging	Teendő, ha eltér
Indexelhető URL-ek száma	1200	1184	A 16 hiányzó cím azonosítása, átirányítás vagy visszaállítás
Üres meta leírás	0	312	Az import mezőleképezésének javítása
Duplikált title	4	4	Nincs új teendő, régi hiba
Belső link átirányításra mutat	0	845	Belső linkek tömeges átírása

A számok a korábbi 1200 oldalas blog példájához tartoznak, és illusztrációk, nem mért adatok. A lényeg a módszer: minden sornál a régi állapot a mérce, és minden eltérés vagy javítandó, vagy tudatosan vállalt döntés.

Mikor tekinthető lezártnak a migráció? Akkor, ha az átirányítások stabilan működnek, a feltérképezési hibák száma visszatért a korábbi szintre, és az organikus forgalom a szezonális ingadozást figyelembe véve a korábbi sáv közelében van. Addig a heti áttekintést érdemes felelőshöz rendelt feladatként kezelni.

A régi rendszert ne kapcsold le azonnal. Ha élesítés után derül ki, hogy egy mező vagy egy oldalcsoport hiányzik, a régi adatbázis és a régi feltérképezés mentése a leggyorsabb forrás a visszaállításhoz. A szervernaplók elemzéséhez a log file analysis útmutató ad részletes módszert.