SEO migráció & áttervezés

Tudj meg többet

Miért számít az SEO migrációs tervezés 2025–2026 között?

SEO migráció ma már nehezebb, nem egyszerűbb, mert a modern weboldalak nem pusztán egy szerverről a másikra áthelyezett, egyszerű HTML-oldalakból állnak. Egy tipikus replatformolás ma már magában foglalja a JavaScript-feldolgozás változásait, a CDN-szabályokat, a szűrős/facettált navigációt, az API-alapú sablonokat, a lokalizációs rétegeket, valamint az analitika migrációját egyszerre. Ha akár csak egyetlen ilyen réteg elromlik, a Google napokon belül elveszítheti a URL-ek ekvivalenciáját, a kanonikus következetességet vagy a feltérési útvonalakat. Gyakran látom, hogy a cégek hat- vagy hétszámjegyű összeget fektetnek a dizájn újratervezésébe, miközben szinte semmit nem költenek a migrációs governance-re, majd azon csodálkoznak, hogy a rangsorolás miért omlik össze a launch után. A kockázat akkor a legnagyobb, amikor a fejlesztőcsapatok az SEO-t nem egy teljes rendszerátalakításként, hanem egy egyszerű átirányítási (redirect) táblázatként kezelik. Mielőtt bármilyen migráció elindulna, általában összehangolom egy technikai SEO audit keretében, hogy felmérjem a kiindulási problémákat, és szétválasszam a régi technikai adósságot az új launch miatti gondoktól. Ez a megkülönböztetés azért fontos, mert azt nem tudod kijavítani, amit nem tudsz hozzárendelni (attribuálni).

Ha a migrációs tervezés gyenge, az elszalasztott cselekvés költsége nem egyetlen nyilvánvaló hibaként jelentkezik, hanem rétegenként halmozódik fel. Először a nagy értékű landing page-ek elveszítik a helyezéseiket, mert a redirectek túl általánosan működnek, a canonicals megváltoznak, vagy a belső linkek még mindig elavult (visszavont) URL-ekre mutatnak. Ezután a Google a crawl budgetet parameteres duplikátumokra, redirect láncokra vagy soft 404-ekre pazarolja, miközben a fontos szekciók csak későn kerülnek elő. A bevételkiesés gyorsan megjelenik kategória-, márka- és long-tail keresőkifejezések esetén, különösen az eCommerce oldalaknál, ahol több ezer, sablonvezérelt oldal múlik a kiszámítható indexelésen. A versenytársak ez alatt az átláthatatlanság alatt növelik a részesedést, mert stabil URL-jelzéseket tartanak fenn, miközben a te webhelyed vegyeseket küld. Javaslom, hogy indulás előtt ellenőrizd a SERP gap-et egy competitor analysis keretében, hogy a vállalkozás pontosan értse, mekkora láthatóság forog kockán, és mely lekérdezési klasztereket kell először védeni. Egy rossz migráció nemcsak a forgalmat csökkenti; átadja a piaci részesedést azoknak a gyorsabban lépő szereplőknek, akik változatlanul megőrizték az architektúrájukat.

A nyereség jelentős, ha a migrációt mérnöki projektként irányítjuk, SEO-kontrollokkal beépítve minden fázisba. 41 eCommerce domainen, 40+ nyelven működve azt láttam, hogy a tervezett migrációk megőrzik a rangsorolási egyenlőséget, néhány héten belül helyreállítják az indexelést, sőt javíthatják a feltérési hatékonyságot is, mert a költözés során eltávolítják a régi, felesleges elemeket. Nagyon nagy webhelyeknél ugyanaz a folyamat, amely védi a forgalmat, azt is lehetővé teszi, hogy egyszerűbbé váljanak az URL-minták, rendbe tegyék a canonical logikát, és jobb indexelési kontrollt teremtsen a következő 12-24 hónapra. Több esetben a migráció volt az a mérföldkő, amikor végre meg lehetett javítani azokat a problémákat, amelyek éveken át gátolták a növekedést: például a mély lapozás csapdái, a gyenge belső linkelés és az ellenőrizetlen paraméterbővülés. Az eredmény nem csupán az indulás utáni túlélés; ez egy erősebb organikus alap tisztább adatokkal és kevesebb manuális „tűzoltással”. A munkám során a migrációs kontrollokat kombinálom a log fájl elemzéssel és az folyamatos SEO riportolással és analitikával, így nyomon tudjuk követni, hogy a Googlebot, az indexelés és a bevételi jelek az elvárások szerint helyreállnak-e. Így lehet a migrációt kockázati eseményből felhalmozódó előnnyé alakítani.

Hogyan közelítjük meg az SEO-migrációs és replatformolási projekteket

A migrációs módszertanomat egyetlen elv vezérli: minden olyan SEO-jel, amely számít, meg kell őrizni, szándékosan javítani kell, vagy üzleti indokkal egyértelműen le kell vonni. Ez nyilvánvalónak hangzik, mégis a legtöbb migráció azért bukik el, mert a csapatok csak URL-eket követnek, és figyelmen kívül hagyják a körülöttük lévő rendszereket: a belső linkelést, a sablonokat, a renderelést, a sitemap-eket, a logokat, az analitikát és a piaci eltéréseket. Nem használok egy általános, blogbejegyzésből másolt ellenőrzőlistát, amit egyformán ráhúznak egy 5 000 oldalas brosúraoldalra és egy 12 millió URL-es eCommerce katalógusra. Helyette a migrációt valódi kockázati klaszterek köré építem fel, például indexelhető paraméterkombinációk, árva (orphan) szekciók, sablonöröklődés és átirányítási konfliktusminták. Nagyméretű oldalak esetén ezt a munkát nagyrészt felgyorsítja a Python SEO automatizálás, így az URL-leltárak, a mappelek érvényességének ellenőrzése, a paritás-ellenőrzések és az anomáliadetektálás nagyléptékben feldolgozhatók. Ez az automatizálás teszi lehetővé, hogy a komplex migrációk gyorsan haladjanak anélkül, hogy kapkodóvá válnának. A cél nem az ítélet automatizálása; hanem az ismétlődő validációk eltávolítása, hogy az ítélet a legfontosabb oldalakra és mintákra összpontosulhasson.

Az eszköztár szintjén a Screaming Frogot, a Sitebulb-ot, a szervernaplók elemzését, a Google Search Console API-kat, a GA4- vagy Adobe Analytics exportokat, valamint egyedi crawlereket kombinálom a technológiai stack függvényében. Egy migráció soha nem támaszkodhat egyetlen adatszorra, mert mindegyik forrás más kérdésre ad választ: a crawlerek a struktúrát mutatják meg, a naplók a botok viselkedését, az GSC az indexelést és a lekérdezési mintázatokat, az analitika pedig a kereskedelmi hatást. Rutinszerűen építek pre-launch és post-launch adatcsatornákat, amelyek összehasonlítják a státuszkódokat, a canonicals-eket, a title-eket, a headingeket, a strukturált adatokat, a sitemap-be való felvételt és az oldalak belső linkszámait a régi és az új környezet között. Vállalati szinten ezek a kontrollok gyakran ismételhető szkriptekként kerülnek megírásra, hogy ugyanaz az ellenőrzés a launch week során naponta lefuttatható legyen. A riportolás egy döntéstámogató keretrendszerhez kapcsolódik, nem hiúsági dashboardokhoz, ezért a migrációs projektek sokszor kapcsolódnak szélesebb SEO reporting & analytics munkákhoz. Ha egy metrika elmozdul, a dashboardnak meg kell mondania, melyik template, szekció vagy technikai változás felelős érte. Ez lerövidíti az utat az észleléstől a javításig.

Az AI hasznos lehet migrációk során, de csak a folyamat szigorúan kontrollált részein. Claude és GPT-típusú modellekkel összefoglalókat készítek a change logokról, besorolom a redirect szándék és az elvárt működés közötti eltéréseket, csoportosítom a QA-észrevételeket, és a technikai megállapításokat stakeholder-kompatibilis dokumentációvá alakítom — különösen akkor, amikor több száz oldal vagy szabálykészlet átvizsgálása szükséges. Amit az AI nem csinál, az a végleges redirect-döntések meghozatala, a canonical policy meghatározása, illetve a launch readiness jóváhagyása determinisztikus validáció nélkül. Az AI legnagyobb értéke a mintafelismerés és a kommunikáció sebességében rejlik, ezért jól működik egyedi szkriptekkel és kézi review-val együtt. Multilingual oldalak esetén az AI segíthet a template-paritás összevetésében is piacok között, valamint jelezhet olyan inkonzisztens meta mintákat, amelyek kézi ellenőrzéssel túl sokáig tartanának. Ezek a munkafolyamatok közvetlenül kapcsolódnak a AI & LLM SEO workflows szolgáltatásomhoz, de a minőségbiztosítás továbbra is emberi irányítás alatt áll. Migrációknál egy gyorsan adott, de rossz válasz még mindig rossz, ezért minden automatizált vagy AI-val támogatott megállapítást ellenőrizni kell crawl, log vagy oldal-szintű bizonyítékok alapján.

A migráció során minden megváltozik a migration SEO-ban. Egy 200 oldalas szolgáltatóoldal néha túlélhet egy egyszerű átirányítási tervvel és egy körültekintő feltérképezéssel, de egy olyan vállalkozás, amely 500K és 10M közötti indexelt URL-t kezel, architektúra-szintű kontrollokat igényel. Jelenleg olyan ingatlanportfóliókkal dolgozom, amelyek domainenként kb. 20M URL-t generálnak, ingatlanonként pedig 500K–10M indexelt URL-t, így a módszertan az URL-növekedés, a faceted search (szűrési/paraméterezett találatok), a lokalizáció és az egyes template-ek részleges öröklése alapján épül fel a piacok között. Ezekben a környezetekben nem lehet minden egyes oldalt egyenként validálni; URL-szabályokat, oldaltípusokat, lekérdezés-klasztereket és indexelési útvonalakat kell validálni. Ezért a migrációs munka gyakran átfedésben van a webhely architektúrával, a nemzetközi & többnyelvű SEO-val és a weboldalfejlesztéssel + SEO-val. A migráció nem csupán annyi, hogy a tartalmat A platformról B platformra költöztetjük: meg kell védeni, hogyan áramlik a rendszerben a felfedezhetőség (discovery), a megjelenítés (rendering), a relevancia és az equity. Ha ezt a rendszert jól tervezték meg, az új platform a launch után jóval könnyebben skálázható lesz.

Vállalati SEO migrációs stratégia: hogyan néz ki a valódi platformváltás

A hagyományos migrációs tanácsok gyorsan elveszítik a jelentőségüket, amikor a weboldal nagy, többnyelvű, vagy mélyen integrált termékadatokkal. Egy redirect táblázat elegendő lehet egy kisebb oldalon, de nem elég akkor, amikor milliószámra jönnek létre URL-ek kategóriákból, szűrőkből, keresési állapotokból, márkalapokból és piac-specifikus variációkból. Vállalati környezetben a kockázat ritkán egyetlen végzetes hibából áll; sokkal inkább száz apró, egymást erősítő eltérésből, amelyek összességében aláássák a láthatóságot. A canonical címek elcsúsznak, a belső linkek még mindig a régi útvonalakra mutatnak, a sitemap-ek olyan URL-eket tesznek láthatóvá, amelyeket amúgy nem lehet indexelni, a JavaScript blokkolja a tartalmat, amíg meg nem történik a hydration, és az hreflang hivatkozások régi struktúrákat tükröznek. A régi rendszerek emellett olyan történeti ellentmondásokat is létrehoznak, amelyek csak migráció közben derülnek ki, például jó pozíciókat elérő oldalak, miközben a struktúra gyenge, vagy olyan sablonok, amelyek csendben vékony tartalmú duplikátumokat generálnak. Éppen ezért a vállalati migrációnak olyan modellezésen kell alapulnia, amely oldaltípusokra, szabálykészletekre és kivételkezelésre épül—nem kizárólag manuális, eseti ellenőrzésekre.

Az egyéni rétegben jön létre a legtöbb érték. Rendszeresen építek olyan szkripteket, amelyek összehasonlítják a régi és az új URL-készleteket, felismerik a redirect loopokat és a többtől-egyig (many-to-one) leképezéseket, sablon alapján mérik a title- és heading-paritást, illetve több millió rekord között jelzik a sitemap vagy canonical ellentmondásait. Egyes projekteknél ezek a szkriptek körülbelül 80%-kal csökkentették a manuális QA-ra fordított időt, így több idő maradt a mélyebb áttekintésre, nem pedig több táblázatra. Egy migráció során az automatizált validáció azonosított egy mintát: a lokalizált kategóriaoldalak ugyan helyesen redirectáltak, de a rossz canonical célpontot örökölték, ami 14 piac indexelését jelentősen gyengítette volna. Egy másik esetben a crawl- és logelemzés megmutatta, hogy a Googlebot ismételten túlköltekezik a kérésekkel a már megszűnt paraméteres URL-eknél, ezért átstrukturáltuk a belső linkeket, és megtisztítottuk a szerverválaszokat a feltérképezési hatékonyság 3×-os javításához pár héten belül. Ha a migrációk érintik az automatikusan generált landing page-eket vagy a nagyléptékű, sablonizált asseteket, a munka gyakran metszi a programmatic SEO for enterprise területét is, mert azok a szabályrendszerek, amelyek oldalakhoz vezetnek, megőrzendők vagy okosan átírhatók. A lényeg nem az, hogy mindenkinek több eszköze legyen; hanem az, hogy a webhely pontos hibamódjaira legyenek a megfelelő eszközök.

A migráció akkor is kudarcot vall, ha az SEO felelősje elszigetelt bírálóként vesz részt a folyamatban, nem pedig integrált szállítási partnerként. A szerepem általában a termék, a fejlesztés, az analitika, a tartalom és a régiós csapatok között helyezkedik el, mert a kiadás csak akkor sikerül, ha minden csapat tisztában van azzal, hogy a felfedezhetőséget és a rangsorolást mely döntések befolyásolják. A fejlesztőknek pontos, műszaki elfogadási kritériumokra van szükségük, nem pedig általános ajánlásokra. A tartalmi csapatoknak tudniuk kell, hogy mely címek, headingek és szövegminták kötelezőek az ekvivalencia szempontjából, és melyek javíthatók a launch után. A termékfelelősöknek kockázat szerint rangsorolt backstrecre van szükségük, hogy a launch-blokkolók elkülönüljenek a „nice-to-have” tételektől. Ezért a migrációs munka gyakran kapcsolódik a website development + SEO szolgáltatáshoz, illetve a launch után az azt követő SEO curation & monthly management folyamathoz. A migrációs deliverable nem egy PDF; ez egy működő döntési rendszer, amelyet a csapat időnyomás alatt is tud használni.

A migrációs munka eredményei ritkán lineárisak, és az elvárásokat őszintén kell beállítani. Az első 30 napban a fő cél a technikai stabilitás, az átirányítások pontossága, az újraindexelés gyorsítása, valamint az indexfelesleg (index bloat) megelőzése. 60–90 nap elteltével érdemes látni, hogy a magas értékű szekciók visszanyerik-e a láthatóságukat, illetve hogy a Googlebot a megfelelő sablonokra fordítja-e az idejét. 6 hónap múlva a vállalkozásnak értékelnie kell, hogy az új platform javította-e a feltérképezési hatékonyságot, a tartalomkihelyezés sebességét, valamint hogy mennyire jól skálázható új szekciókra vagy piacokra. 12 hónap elteltével a legjobb migrációk felülmúlják a régi oldalt, mert a költözés során nem csupán átörökítették, hanem eltávolították a technikai adósságot. Azokat a mutatókat figyelem a legszorosabban, mint a sablononkénti indexelt URL-ek arányának (indexed URL parity) egyezése, a márkanév nélküli láthatóság, a query cluster recovery, a crawl waste csökkentése és az organikus bevétel stabilitása. Ezek a jelzések megmutatják, hogy a migráció csak túlélte-e az átalakítást, vagy egy erősebb organikus rendszert hozott létre.

Szállítmányok

Mit tartalmaz

01 Migráció előtti alapmérés, amely rögzíti a helyezéseket, indexelt oldalak számát, sablonokat, bevételi oldalakat, feltérképezési (crawl) viselkedést és technikai adósságot, hogy az élesítés utáni változások valódi adatokhoz legyenek mérhetők, ne feltételezésekhez.

02 URL-készlet felmérése és átirányítási (redirect) térkép készítése oldalminta- és oldalszintű mélységben, biztosítva, hogy a legértékesebb örökölt (legacy) URL-ek a legrelevánsabb céloldalra kerüljenek, ne pedig tömegesen általános kategóriákba vagy a kezdőlapra.

03 Sablon-egyezőség (template parity) felülvizsgálat a title-ek, meta description-ök, canonicals, headingek, hreflang, strukturált adatok, belső linkek és indexelési direktívák tekintetében, hogy a kritikus SEO-jelek megmaradjanak a platformváltás során.

04 Staging környezet QA (minőségbiztosítás), amely ellenőrzi a megjelenítést, feltérképezhetőséget (crawlability), robots szabályokat, státuszkódokat, faceted navigation-t, JavaScript hydration-t és a mobil viselkedést, mielőtt bármi éles környezetbe kerülne.

05 Élesítési napi (launch-day) monitorozási keretrendszer, amely szervernaplókat, GSC-t, analitikát, crawl snapshotokat, XML sitemaps-eket és átirányítási érvényesítést foglal magában, hogy a kritikus hibák órákon belül észlelhetők legyenek, ne hetek múlva.

06 Nemzetközi migrációs vezérlők ccTLD, almappa (subfolder) vagy aldomain (subdomain) beállításokhoz, beleértve a hreflang konzisztenciát, regionális canonicals-eket, nyelvváltási logikát és piac-specifikus oldal-mappolást.

07 Belső linkelés helyreállítása, amely frissíti a navigációt, morzsamenüket (breadcrumbs), lábléc linkeket, XML sitemaps-eket és kontextuális linkeket, hogy a Google közvetlenül új URL-eket fedezzen fel, ne csak az átirányításokra támaszkodjon.

08 Visszaállítási (rollback) és vészhelyzeti tervezés előre definiált küszöbértékekkel, felelősségi körökkel (issue ownership), eszkalációs útvonalakkal és vészszabály-készletekkel a robots-ra, canonicals-ekre, redirect-ekre és a szerver válaszkezelésre.

09 Élesítés utáni helyreállítási (recovery) útiterv, amely az indexelést, a crawl hatékonyságot, a bevételhez kapcsolódó sablonokat és a query cluster-eket helyezi előtérbe, hogy a cég tudja, mit kell javítani 1. héten, 2. héten, 1. hónapban és 3. hónapban.

10 Vezetői és megvalósítási dokumentáció fejlesztőknek, termékmenedzsereknek, tartalomcsapatoknak és vezetésnek lefordítva, hogy a migrációs döntések megvalósíthatóak és az érintettek között nyomon követhetők legyenek.

Folyamat

Hogyan működik

Fázis 01

1. fázis: Audit, benchmark és migrációs kockázati modell

1-2. hét fókusza az, hogy még a megjelenési dátumokról való beszélgetés előtt megértsük a jelenlegi oldalt. Kiinduló adatokat gyűjtök az organikus forgalomról, a legfontosabb bevételt hozó URL-ekről, a sablontípus-csoportokról, az indexáltsági szintekről, a belső linkekről, a feltérképezési gyakoriságról, a strukturált adatokról és a jelenlegi technikai adósságról. Ezután felépítek egy migrációs kockázati modellt, amely különválasztja a kritikus sablonokat az alacsony hatású területektől, és azonosítja, mi kell, hogy a költözés során teljesen azonos maradjon, illetve mi fejleszthető a migráció alatt. A kimenet egy benchmark csomag, egy kockázati nyilvántartás, valamint egy priorizált scope, amelyekre a termék, a fejlesztés, a SEO és a vezetői csapatok egymással összehangolhatják a munkát.

Fázis 02

2. fázis: URL-mappelés, specifikáció és staging QA

A 2-5. hét célja, hogy a stratégiát megvalósítási szabályokká alakítsuk. Létrehozom az átirányítási mappelési logikát, meghatározom a kanonikus és indexálási irányelveket, dokumentálom a sitemap szabályait, ellenőrzöm a template-ek egyezőségét, és validálom a staging környezeteket a feltérhetőség és a megjelenítés szempontjából. Ez az a szakasz, ahol teszteljük a belső linkelést, a breadcrumbs-t, az oldalszámozást, a hreflang-et és a strukturált adatokat is, hogy ne legyenek a bejelentés utáni meglepetések. E fázis végére a csapat egy indítási ellenőrzőlistával rendelkezik, passz/fail kritériumokkal, nem pedig azzal a homályos érzéssel, hogy az új oldal „készen áll”.

Fázis 03

3. fázis: Indítási kontroll és az első 72 óra

Az indítási hetet incidensek megelőzéseként futtatjuk, nem ünneplésként. Figyelem az állapotkódokat, az átirányítási válaszok viselkedését, a robots-direktívákat, az élő XML sitemape-eket, az analitika nyomkövetést, a GSC beküldéseket, a szervernaplókat, valamint a kulcsfontosságú sablonmintákat már a go-live utáni órákban. Amint problémák felmerülnek, azokat az üzleti hatás alapján rangsorolom: először a bevételt hozó oldalak, a magas linkértékkel rendelkező oldalak, illetve a fő sablonok. Az eredmény egy élő hibajegyzék (issue queue) felelősökkel, határidőkkel és validálással, hogy a vállalkozás pontosan tudja, mi hibás, mi lett javítva, és mit figyelünk éppen.

Fázis 04

4. fázis: Helyreállítás, újra-feltérképezés és a növekedés stabilizálása

Az utolsó fázis a következő 4-12 hetet fedi le, néha a nagyon nagy weboldalak esetén ennél is tovább tarthat. Az oldalszintű, lekérdezéscsoportos és sablon szintű régi és új teljesítményt összehasonlítom, majd végigmegyek a feltérképezési hatékonyságon, az indexelési egyezésen, az átirányítások rendbetételén, a belső linkek frissítésén, valamint a szükséges tartalmi vagy metatag-helyreállításon. Itt lesz a migráció már nem csak reakciós, hanem stratégiai: amikor a stabilitás visszaáll, az új platformot a réginél jobb skálázhatóságra lehet optimalizálni. Az eredmény egy helyreállítási ütemterv, rendszeres teljesítményriportok, valamint egy migráció utáni fejlesztési backlog, amelyet a várható hatás alapján rangsorolok.

Összehasonlítás

SEO migrációs szolgáltatás: standard ügynökségi folyamat vs vállalati (enterprise) megközelítés

Dimenzió

Szokásos megközelítés

Saját megközelítés

Felfedezés

Egy rövid, indulás előtti feltérképezés és egy általános ellenőrzőlista, gyakran baseline rangsorok, sablon szerinti szegmentálás vagy bevételi oldalak priorizálása nélkül.

Teljes körű benchmark a forgalom, a rangsorok, a bevételi sablonok, a naplók (logok), a indexelt oldalak és a technikai adó tekintetében, hogy a post-launch időszakban bekövetkező változások pontosan visszavezethetők legyenek.

Átirányítási leképezés

Későn létrehozott, egy az egyhez vagy sok az egyhez jellegű, nagytételben végzett átirányítások, kevés üzleti logikával és minimális érvényesítéssel.

Szabályalapú és prioritásvezérelt leképezés, amely megőrzi a szándékot, a linkértéket és a magas értékű útvonalakat; automatizált érvényesítés láncokra, körhivatkozásokra és nem egyezésekre.

QA sablon

Kézi ellenőrzések kis oldalmintán, általában csak a látható elemekre fókuszálva.

Paritás-ellenőrzések a címek, kanonikus URL-ek, headingek, struktúrált adatok (schema), hreflang, belső linkek, megjelenítési kimenet és indexelési szabályok terén sablononként és piacanként.

Indítási nyomon követés

Várni, amíg a Search Console és az analitika néhány nappal később jelez problémákat, majd reaktívan kivizsgálni.

Figyelni a státuszkódokat, az átirányításokat, a szervernaplókat, a sitemap beküldéseket, a feltérképezéseket és a sablon-pillanatképeket a launch után néhány órán belül.

Nemzetközi kezelés

A lefordított webhelyeket a fő piac duplikátumainak tekinti, és abban bízik, hogy az átirányítások kezelik a regionális összetettséget.

Piacról piacra ellenőrzi a logikát a hreflang, a kanonikus célok, a helyi sablonok, az URL-minták és a regionális bevételi oldalak tekintetében.

Post-launch recovery

Fixáld a látható problémákat eseti alapon, és jelents sikert, miután a forgalom már nem csökken.

Futtass egy strukturált helyreállítási tervet, amely magában foglalja a re-crawl gyorsítását, a belső linkek frissítését, a feltérképezési pazarlás csökkentését, az indexelési paritás biztosítását és a szekciószintű növekedési lehetőségeket.

Ellenőrzőlista

Teljes SEO migrációs ellenőrzőlista: mit fedünk le

✓ A legfontosabb oldalak, sablonok és örökölt minták URL-térképezésének pontossága, mert a rossz térképezés értékességet juttat irreleváns céloldalakra, és éveken át felépített helyezéseket ronthat meg. KRITIKUS
✓ A régi és az új sablonok közötti kanonikus egyezés biztosítása, mert a hibás kanonikus akár még akkor is kiveheti a helyes oldalt az indexből, ha az átirányítások technikailag helyesek. KRITIKUS
✓ A robots, a meta robots és a header direktívák ellenőrzése staging és production környezetben is, mert egyetlen noindex vagy blokkolt útvonal sablon szinten képes teljes szakaszokat eltávolítani a találatokból. KRITIKUS
✓ Belső linkek frissítése a navigációban, a morzsamenükben, a láblécekben és a kontextusfüggő modulokban, mert a felfedezéshez használt átirányításokra hagyatkozás lelassítja a helyreállást, és feleslegesen pazarolja a feltérképezési (crawl) keretet.
✓ XML sitemap lefedettség és tisztaság, mert a sitemapekbe olyan URL-ek kerülhetnek be, amelyek átirányítva vannak, kanonikalizálva lettek, vagy nem indexelhetők, és ez feldolgozáskor összezavarja a keresőmotorokat.
✓ Szerkezeti adatok megőrzése termék-, kategória-, szervezet-, GYIK-, breadcrumb- és cikk sablonokhoz, mert a kiesett séma a bevezetés után csökkentheti a rich result jogosultságot.
✓ Hreflang és regionális URL-következetesség, mert a hibás piaci hivatkozások gyakran országok közötti kannibalizációt és gyengébb helyi láthatóságot eredményeznek.
✓ Szerverválasz-ellenőrzés, beleértve a 200, 301, 302, 404 és 410 viselkedést, mert az inkonzisztens státuszkód-kezelés miatt a Google újraértékeli a webhely minőségét, és lelassítja a konszolidációt.
✓ JavaScript-alapú oldalakon a megjelenítés és a tartalmi egyezés biztosítása, mivel a kliensoldali futásig elrejtett tartalom gyengébb indexelést vagy hiányos relevancia-jelzéseket eredményezhet.
✓ Visszaállítási készültség felelősi hozzárendelésekkel és hibaküszöbökkel, mert a leggyorsabb módja a károk minimalizálásának, ha pontosan tudod, mikor és hogyan kell visszavonni egy rosszul sikerült bevezetési elemet.

Eredmények

Valós eredmények SEO migrációs projektekből

Vállalati divat eCommerce

+18% nem márkás láthatóság 4 hónap alatt

A projekt egy örökölt store-front (legacy) platformról egy gyorsabb technológiai stackre való átállást foglalt magában 12 piacon. A fő kockázat az volt, hogy egy URL-átalakítás során (amely egyben a navigáció logikáját is megváltoztatta) elveszítjük a kategória- és márkaoldalakhoz kapcsolódó értéket (equity). Újraraktam az átirányítási (redirect) szabályokat minták alapján, ellenőriztem a canonical és a hreflang megfelelőségét (paritást), és a migrációs monitorozást összekapcsoltam a nemzetközi és többnyelvű SEO vezérléseivel. A forgalom átmenetileg az 1. héten csökkent, a 3. hétre stabilizálódott, és a nem márkás láthatóság 4 hónapon belül 18%-kal meghaladta a korábbi platform eredményeit, mert csökkent a feltérképezési (crawl) pazarlás és javult a belső linkelés.

Nagy marketplace

Indulás után napi 500K+ URL-t újrafeldolgozva

A marketplace milliószámra kezelt kombinációkat különböző eladók, kategóriák és helyszíni oldalak között, miközben jelentős kockázatot jelentettek a paraméterduplikációk és az árván maradó készletoldalak. Többlépcsős szabályokat, egyedi validációs szkripteket és a webhelyarchitektúra frissítéseket alkalmaztuk annak érdekében, hogy az indulás után ne áraszthassanak el alacsony értékű állapotok az indexet. Az első hónapban a Googlebot-ot a friss, kiemelt (prioritásos) szekciók felé irányítottuk, miközben az elavult paraméteres URL-eket tisztán, zökkenőmentesen kivontuk a forgalomból. Ennek eredményeként gyorsabb lett az újrafeldolgozás, jobban kontrollálhatóvá vált az indexelés, és nem következett be hosszan tartó láthatóság-csökkenés a bevételt generáló sablonok esetében.

B2B ipari katalógus

3×-os feltérképezési hatékonyság és forgalom-helyreállás 5 hét alatt

Ez az átállás egyetlen projektben kombinálta a domainváltást, a CMS-váltást és a tartalomtakarítást, ami azt jelentette, hogy a csapat gyakorlatilag mindent egyszerre változtatott meg. A webhelyen több mint 1,6M régi URL volt, következetlen kanonikus (canonical) beállításokkal, valamint még mindig feltérképezett tucatnyi alacsony minőségű belső keresési útvonallal. A feltérképezés helyreállításához és az indexelési jelek tisztításához redirect-konszolidációt, logfájl-elemzést és a bevezetés utáni schema & strukturált adatok javításokat végeztem. Öt héten belül a szerves látogatások visszatértek az alapértékre, a feltérképezési hatékonyság pedig nagyjából 3×-ra javult, mivel a Googlebot sokkal kevesebb időt töltött duplikált vagy már megszüntetett útvonalakon.

Kapcsolódó esettanulmányok

4× Growth

SaaS

Nemzetközi kiberbiztonsági SaaS

80-ról 400 látogatásra/nap 4 hónap alatt. Nemzetközi kiberbiztonsági SaaS platform több piacos SEO s...

0 → 2100/day

Marketplace

Használt autó piactér – Lengyelország

Nulláról 2100/nap organikus látogatóra 14 hónap alatt. Teljes körű SEO indulás a lengyel autó piacté...

10× Growth

eCommerce

Prémium bútor e-kereskedelem – Németország

30-ról 370 látogatásra/nap 14 hónap alatt. Prémium bútor e-kereskedelem a német piacon....

Andrii Stanetskyi

A projekt mögött álló szakértő

11 év alatt oldok meg SEO-problémákat minden területen — eCommerce, SaaS, egészségügy, marketplace-ek, szolgáltató cégek. A startupokhoz készített egyedi auditoktól a több domaines enterprise stackek menedzseléséig mindent csinálok. Megírom a Python-t, felépítem a dashboardokat, és én felelek az eredményért. Nincs közvetítő, nincs fiókmenedzser — közvetlen hozzáférés ahhoz, aki ténylegesen dolgozik.

200+

Szállított projektek

18

Iparágak

40+

Leckedelt nyelvek

11+

Év SEO-ban

Megfelelőségi felmérés

Az SEO-migráció megfelelő az Ön vállalkozása számára?

Vállalati szintű e-kereskedelmi márkák, amelyek új platformra váltanak, headless fejlesztést végeznek, vagy régiós üzlethelyiszintű (regionalizált) storefront-struktúrára térnek át. Ha a katalógusod, a kategóriarendszered és a belső linkelés jelentős mértékben hozzájárul a bevételhez, akkor a migráció feletti kontroll nem opcionális, hanem kötelező. Ez különösen igaz azokra az üzleti szereplőkre, akiknek a vállalati eCommerce SEO mélységét is biztosítaniuk kell az indulás után.

Nemzetközi vállalkozások, amelyek domaint cserélnek, nyelvi mappákat módosítanak, piaci útvonalakat (market routing) alakítanak át, vagy több országban a CMS-logikát frissítik. Ezek a migrációk fokozott kockázattal járnak, mert a hreflang, a kanonikus (canonical) hivatkozások és a lokalizált sablonok mindvégig összhangban kell maradjanak. Ha több csapat vagy több piac is érintett, akkor ezt a munkát már a legelejétől érdemes nemzetközi és többnyelvű SEO felügyelettel kombinálni.

Olyan vállalatok, amelyeknek 100K+ URL-jei vannak, faceted navigációval rendelkeznek, nagy dokumentációs kódexszel vagy programozottan generált oldalakkal dolgoznak. Ilyen méretek mellett a kizárólag manuális QA túl lassú és túl törékeny, ezért a folyamatban előnyös az automatizálás és a szabályalapú validáció. Ezen projektek közül sok jól illeszkedik a programozott SEO-hoz vállalati szinten, amikor a sablonok és az oldalgenerálási logika változnak.

Az Ön számára megfelelő ez a szolgáltatás? Olyan vállalkozásoknak való, amelyek már elköteleződtek a tervezett indulási dátumok mellett, és olyan üzemeltetőt keresnek, aki nyomás alatt is közvetlenül tud együttműködni a fejlesztési, elemzési (analytics) és termékcsapatokkal. Az én szerepem olyan csapatokhoz illik, akik pontos hibalistákat, döntési keretrendszereket és megvalósítási támogatást szeretnének, nem pedig általános tanácsadást. Különösen hasznos, ha a migráció egy szélesebb körű újraépítés része a weboldalfejlesztés + SEO keretében.

Nem megfelelő?

Egy kis brosúra jellegű weboldal néhány oldallal, illetve minimális (vagy egyáltalán nem számottevő) organikus jelenléttel nem feltétlenül igényel teljes migrációs felmérési és végrehajtási munkát. Ilyenkor gyakran elegendő egy célzott technikai SEO audit és az átirányításokra vonatkozó útmutatás.

Azok a csapatok, amelyek még mindig CMS-t választanak, újratervezési irányt vagy információs architektúrát dolgoznak ki, de még nem kezdték el az implementációt, a migrációs végrehajtás átbeszélése előtt több értéket kaphatnak először a website-development-seo vagy a site architecture tervezéséből.

GYIK

Gyakran ismételt kérdések

A SEO-migráció az a folyamat, amelynek során megőrizzük és átvisszük a weboldal organikus keresőmotorokban elért „értékét”, amikor a site platformja, domainje, URL-struktúrája, dizájnrendszere vagy technikai stack-je megváltozik. Azért kockázatos, mert a Google nem úgy érzékeli az újratervezést, mint a felhasználók: számára elsősorban módosult URL-ek, megváltozott belső linkek, eltérő canonical-ek, új megjelenítési (renderelési) viselkedések és sokszor új feltérési útvonalak jelennek meg. Ha ezek a jelek nem konzisztensen, megfelelően kerülnek át, a helyezések akkor is csökkenhetnek, ha a tartalom nagyjából ugyanolyannak tűnik. A kockázat különösen nő azokon a weboldalakon, ahol sok sablon, több piac vagy sok generált URL van. A migráció akkor tekinthető sikeresnek, ha a keresőmotorok egyértelműen meg tudják érteni, mi került áthelyezésre, mi maradt ekvivalens, és mi lett szándékosan kivezetve.

A költség több tényezőtől függ: a feladatok terjedelmétől, a kezelt URL-ek számától, a technikai összetettségtől, az érintett piacok számától, valamint attól, hogy mikor kapcsolódik be a SEO a folyamatba. Egy kisebb vagy közepes weboldal migrációja lehet egy fókuszált konzultációs együttműködés, míg egy multinacionális e-kereskedelmi platformváltás jellemzően többhetes, gyakorlati támogatást igényel a tervezéstől a QA-n és az élesítésen át egészen a helyreállításig. A legnagyobb árazási szempont nem pusztán az oldalak száma, hanem az egyedi sablonok száma, az átirányítási szabályok összetettsége és az érintett szereplők száma. Általában a migrációkat kockázat és munkaterhelés alapján határozom meg, nem pedig önkényes csomagszintek szerint. Ha pontos becslést szeretnél, látnom kell a jelenlegi architektúrát, az élesítési ütemtervet, a piacokat, valamint azt, hogy a fejlesztői támogatás már rendelkezésre áll-e.

A legtöbb komoly SEO-migrációnál a tervezés a bevezetés előtt jellemzően 4–8 hetet vesz igénybe, a launch (élesítés) utáni monitorozás pedig legalább 4–12 hétig tart. A nagyobb, vállalati szintű projektek, ahol bonyolult lokalizáció, több kódbázis vagy több millió URL is érintett, ennél több időt igényelhetnek, mert a redirect-logika, a sablonok egyezősége és az ellenőrzés (QA) több lépést és erőforrást követel. A leggyakoribb hiba, amit látok, hogy a SEO-t körülbelül két héttel a megjelenés előtt kezdik el, amikor már sok kritikus döntés rögzítésre került. A jó ütemezés része a bázis (baseline) teljesítménymérés, a feltérképezés, a staging környezet QA-ja, a launch utáni kontroll és a visszaállítás (recovery) terve. A recovery ideje nem adható meg fix napokban, mert a Google különböző oldalakat különböző tempóban indexel újra, de az első trendjelek általában néhány napon vagy héten belül megjelennek.

A „nulla forgalomvesztés” egy cél, nem pedig olyan ígéret, amit bármelyik őszinte SEO-szolgáltató feltétel nélkül garantálna. Még jól előkészített és gondosan kivitelezett migrációknál is előfordulhat rövid távú ingadozás, mert a Google-nek időre van szüksége az átirányítások feldolgozásához, az új oldal újra feltérképezéséhez és a sablonok újraértékeléséhez. Amit vállalok: kontrollált kockázat, gyors hibafelismerés és a lehető legrövidebb, reálisan elérhető regenerálódási görbe. Sok jól sikerült migrációnál a legértékesebb szekciók 2–6 héten belül visszaállnak, míg a teljes normalizálódás nagyobb oldalkörnyezetben több hónapot is igénybe vehet. A tervezés azért fontos, mert egy rövid, kezelhető esés nagyon más, mint egy megelőzhető, negyedévig tartó 40%-os visszaesés.

Legalább ezeket tesztelem: átirányítások, státuszkódok, kanonikus URL-ek, robots szabályok, XML oldaltérképek, belső linkek, analitika követés, strukturált adatok, hreflang, mobil megjelenítés és az indexelhetőség sablononként. Komplex, JavaScript- vagy headless rendszereknél összehasonlítom a megjelenített HTML-t is, és ellenőrzöm, hogy a kulcstartalom látható-e, illetve nincs-e hibás „hydration” folyamat. Nagyobb oldalaknál a tesztelésnek a szabályokra és a sablonokra kell fókuszálnia, nem csak néhány mintalapra, mert egy apró sablonhiba akár ezreket is érinthet. Emellett validálom a staging környezetet is, hogy véletlenül se kerüljön át „noindex” vagy tiltott erőforrás-beállítás a produktív rendszerbe. A kilistázott indítási ellenőrzőlista csak akkor működik, ha minden pontnál egyértelmű a „átmegy/meg nem felel” kritérium, és van felelős is.

Igen, mert minden platform eltérő erősségeket és hibalehetőségeket hoz magával. A Shopify-migrációk gyakran felszínre hozzák az URL-kezelés, a sablonozás és az alkalmazások által generált duplikációk korlátait, míg a Magento-projektek bonyolultabbá válhatnak a rétegzett navigáció, a store view-k és a korábbi (legacy) átirányítások előzményei miatt. A headless megoldásoknál a megjelenítés, a hydratálás, a gyorsítótárazás és az előnézeti környezet kockázatai is szerepet játszanak, amit a hagyományos CMS-platformok kevésbé érintenek. Az egyedi platformoknál pedig még nagyobb a szórás: az SEO viselkedése attól függ, mit fejlesztett az adott csapat, és pontosan mi az, ami a keresőbotok számára elérhető. A migráció alapelvei ugyanazok, de a kivitelezési részletek, a QA mélysége és a monitorozási prioritások a technológiai stack függvényében változnak.

A kulcs az, hogy ne kizárólag oldalszinten gondolkodjunk, hanem sablonokban, szabályokban és szegmensekben. A URL-eket oldaltípus, piac (ország/nyelv), keresési szándék és üzleti érték alapján csoportosítom, majd a migrációs viselkedést ezekben a klaszterekben validálom. Ezt feltérképező eszközökkel, logokkal, API-kkal és egyedi szkriptekkel ellenőrzöm. Így milliós nagyságrendű rekordokat is lehet auditálni anélkül, hogy azt feltételeznénk, hogy mindegyik egyedileg kézzel áttekinthető. A 10M+ generált URL-t tartalmazó oldalakon külön választom a generált állapotokat, amelyeket soha nem szabad indexelni, attól a tartalomtól, amelynek meg kell őriznie a megszerzett láthatóságot. A skálázás akkor kezelhető, ha az architektúra, az átirányítási logika és a monitorozás már az első naptól skálára van tervezve.

A launch után a munka a megelőzésről egy kontrollált helyreállításra és optimalizálásra vált. Folyamatosan figyelem a feltérképezési (crawl) viselkedést, az indexelést, a láthatóságot, az organikus bevételt, az átirányítások (redirectek) teljesítményét, valamint a sablon-szintű rendellenességeket. Ezután az elvégzendő javításokat üzleti hatásuk alapján rangsorolom. A legtöbb vállalkozásnál legalább 1–3 hónap utókövetés szükséges, mert ekkor derülnek ki a rejtett problémák, és ekkor látható, hogyan értelmezi a Google az új oldalt. Nagyobb cégeknél a migráció gyakran egy tágabb működési modell kiindulópontja a [SEO curation & monthly management](/services/seo-monthly-management/) keretében. A folyamatos támogatás különösen akkor értékes, ha azt szeretné, hogy az új platform ne csak visszahozza az alaphelyzetet, hanem felül is múlja a régit.

Következő lépések

Kezdd el az SEO migrációs projektedet egy valódi tervvel

A sikeres migráció nem szerencse, és nem is annak az eredménye, hogy az indulás előtti napon elküldtek egyetlen redirect táblázatot. A jelenlegi oldal beazonosításán (benchmarking), a bevételt termelő oldalak védelmén, az új sablonok nagy léptékű validálásán, valamint az első hetek olyan pontosságú követésén alapul, hogy a problémák még veszteséggé válásuk előtt észrevehetők legyenek. Ezt a munkát végzem gyakorlóként: 11+ év vállalati eCommerce SEO tapasztalat, 41 domain 40+ nyelven, 10M+ URL-architektúrákban szerzett tudás, valamint egy szállítási modell, amely ötvözi a technikai mélységet a Python automatizálással és AI-alapú QA-val. Az eredmény nem csak a kisebb indulási kockázat. Egy tisztább, jobban skálázható organikus alapot ad, amely képes támogatni a jövőbeni növekedést tartalomban, kategóriákban, piacokon és a termékek felfedezésében.

Az első lépés egy migrációs felmérő (scoping) egyeztetés, ahol áttekintjük a jelenlegi platformod, a célplatformot, a kiadási (launch) ütemtervet, az URL-mennyiségeket, a piacbeállítást (market setup) és azokat a webhelyszekciókat, amelyek a legnagyobb kereskedelmi jelentőséggel bírnak. Ezt követően általában meg tudom határozni a valószínű kockázati területeket, azt, hogy mit kell azonnal auditálni, valamint hogy a projekthez szükség van-e teljes körű migrációs keretrendszerre, vagy inkább szűkebb beavatkozásra. Ha továbbhaladunk, az első kézbesíthető (deliverable) jellemzően egy alap (baseline) audit és migrációs kockázati modell az első 5–10 munkanapon belül készül el, az elérhetőségtől (access) és az összetettségtől függően. Nem kell tökéletes dokumentációval rendelkezned a megkeresés előtt; az analitika, a Search Console, egy crawl (feltérképezés) és az alapvető launch-tervek általában elegendők a kezdéshez. Ha a migrációs dátumod már közel van, az is működőképes, de minél korábban integráljuk a SEO-t, annál több kockázatot tudunk eltávolítani a launch előtt.