Valós munka egy ügyfelünknél, név és szám nélkül; minden olyan részlet kimaradt, amiből a cég kitalálható.
Röviden: egy műszaki szakterületen dolgozó mérnökiroda régi, kódba égetett weboldalát szerkeszthető tartalomkezelőre költöztettük. Kapott egy regisztrációs tagsági részt védett szakmai cikkekkel, egy külön ügyfélnyilvántartást, szerkesztői kézikönyvet, és a munka végén mérési tervet sütikezelő-összehasonlítással. Az átállított, szerkeszthető oldalak fejlesztői környezetben készen állnak az éles átállásra.
Egy mérnökirodában a terv addig nem megy ki, amíg valaki át nem nézte és alá nem írta. A weboldalukkal fordítva volt: kint volt, de érdemben senki nem tudott hozzányúlni, mert a szöveg a programkódban élt, és minden javításhoz fejlesztőt kellett hívni.
A weboldal-költözés tartalomkezelőre az a munka, amikor a kódba égetett oldalak szerkeszthető blokkokra kerülnek át úgy, hogy a címek, a szövegek és a keresőben elért helyek megmaradjanak. Ennél az ügyfélnél ehhez jött még a tagsági rész, a regisztrációk nyilvántartása és a mérés rendbetétele.
Kiinduló helyzet: oldalak, amelyekhez csak programozó nyúlhatott
Az iroda weboldala több domainen futott, régi, kézzel kódolt oldalakon. Adminfelület volt, de a tartalmat nem lehetett vele szerkeszteni. A keresőnek szóló fejlécek, az oldaltérkép és az átirányítások hibásak voltak, az angol nyelvű változatot pedig a kereső nem tudta rendesen bejárni.
A vezetés a szakmai anyagait regisztrációhoz kötve szerette volna megosztani a partnereivel. Ehhez sem felület, sem nyilvántartás nem volt. Minden új szolgáltatásleírás vagy javítás fejlesztői megrendelés lett, ajánlattal és várakozással. Ahány domain, annyi külön karbantartás: egy hibát minden oldalcsaládon külön kellett volna javítani.
A mérés ugyanígy félkész volt. A látogatási adat egy régi mérőkódon át érkezett, célt senki nem állított be, így azt sem lehetett látni, eljut-e egy érdeklődő az ajánlatkérésig.
Mérnöki nyelven: az épület állt, de a megvalósulási dokumentáció hiányzott hozzá. Bővíteni csak bontással lehetett.
Mit csináltunk: előbb felmérés, aztán költözés, végül tagság és mérés
A munka három szakaszban ment. Az alapozásban tartalmi auditot és projekttervet készítettünk. A második szakaszban átköltöztettük az oldalakat, és felépítettük a tagsági részt a nyilvántartással. A gondozási szakaszban szerkesztői kézikönyv és mérési terv készült. A szakaszok között az ügyfél döntött a nyitott kérdésekről.
- Tartalmi audit és projektterv. Oldalanként rögzítettük, mi van, mi hibás, mi költözik és mi marad el. Az ügyfél PDF-ben kapta meg.
- A tartalomkezelő hibáinak javítása. A költözés közben előjött hibákat nem kerülőúttal oldottuk meg, hanem a rendszer kódjában javítottuk, és átadtuk a fejlesztőjének beolvasztásra.
- Angol tartalom és sablonfordítás, hogy az angol oldalak saját, bejárható címen éljenek.
- Az oldalak átállítása szerkeszthető blokkokra. Minden átállított oldalt gépi összevetéssel hasonlítottunk a régihez, képre és szövegre is.
- Tagsági rész: regisztráció, jelszó nélküli belépés, védett szakmai cikkek.
- Ügyfélnyilvántartás a regisztrációkhoz, hírlevél-szinkronnal, törlési lánccal és telepítőcsomaggal.
- Adatkezelési tájékoztató-tervezet és szerkesztői kézikönyv.
- Mérési terv: csak olvasó felmérés a meglévő mérésről, nyitott kérdések az ügyfélnek, a válaszok átvezetése, sütikezelő-összehasonlítás, a beállítás-csomag próbafuttatása, majd beállítás a jóváhagyás után.
A címek változása miatt minden régi URL-ről átirányítás kellett az újra; a Google is ezt kéri a címváltozással járó költözésnél (Google Search Central: költözés URL-változással).
A törlési lánc azért került be, mert aki visszavonja a regisztrációját, annak az adata a hírlevél-listából is tűnjön el. Az érintett törléshez való jogát a GDPR 17. cikke rögzíti (GDPR 17. cikk).
Mi készült: a csomag, amit a csapat tovább tud vinni
Az ügyfél nem egy weboldalt kapott, hanem anyagokat, amelyekkel a saját csapata tovább tud dolgozni. Az alábbi lista azt mutatja, mi van ma a kezében: ezekkel a csapat maga szerkeszti, bővíti és méri az oldalt, és a regisztrált partnerekkel is maga tartja a kapcsolatot.
- átállított, szerkeszthető oldalak magyarul és angolul, fejlesztői környezetben;
- tartalmi audit és projektterv PDF-ben;
- szerkesztői kézikönyv PDF-ben a blokkok használatáról;
- tagsági rész regisztrációval, jelszó nélküli belépéssel és védett cikkekkel;
- ügyfélnyilvántartás forráskóddal és telepítőcsomaggal;
- adatkezelési tájékoztató-tervezet;
- mérési terv és sütikezelő-összehasonlító PDF;
- a jóváhagyott mérési beállítás és egy összefoglaló az ügyfélnek.
Példa (a munkából, általánosítva): egy régi szolgáltatás-oldalon a cím, a bevezető és a kapcsolati blokk a kódban élt. Az átállítás után ugyanez külön szerkeszthető blokkokká vált, a szövegnek változatlanul kellett átkerülnie, és ezt a gépi összevetés oldalanként ellenőrizte. A bevezetőt az átállás után a csapat a kézikönyv alapján maga írhatja át, fejlesztő nélkül.
Mit látott és mit döntött a vevő
Az ügyfél a munka közben főleg döntési pontokkal találkozott, nem kóddal. A legtöbb kérdés olyan volt, amire csak ő felelhetett: ki küldje a rendszerleveleket, hogyan mérjünk, melyik sütikezelőt használja, és mikor álljon át az oldal. A szakmai szövegek az övéi maradtak, a költözés nem írta át őket.
A levélküldésnél az ügyfél oldali szolgáltató beállítása nem ment át a levelezőszolgáltató ellenőrzésén. Ezért a belépő- és regisztrációs levelek küldésére a mi levélküldőnket állítottuk be; ezt az ügyfél üzemeltetőjével egyeztetve döntöttük el.
A mérésnél a meglévő címkekezelő maradt, a mérést pedig az üzleti célokhoz igazítottuk. Az ajánlatkérés kapott egy alapértéket, hogy a riport ne csak darabot lásson.
A hozzájárulásnál az alap változat mellett döntöttünk. A Google leírása szerint ilyenkor a címkék a látogató hozzájárulásáig nem töltődnek be, és a hiányzó adatot a rendszer nem pótolja modellezéssel (Google Analytics súgó: Consent Mode). Kevesebb adat, cserébe egyszerűbb a beállítás és a magyarázat.
A sütikezelőt az ügyfél választja ki, mi összehasonlítást adtunk hozzá.
Mi jön ezután: éles átállás, és az oldal a csapaté
A következő lépés az éles átállás. Az átállított oldalak fejlesztői környezetben készen állnak, az ügyfélnyilvántartás a telepítőcsomaggal a közös szerverre kerülhet, a tartalomkezelőben javított hibák pedig a rendszer fejlesztőjénél várnak beolvasztásra. Az átállás napját és a sütikezelőt az ügyfél választja ki.
Az átállás után a csapat a kézikönyv alapján maga írja és bővíti az oldalt, a regisztrációk egy helyen futnak össze, a már beállított mérés pedig attól a naptól mutatja, eljut-e egy érdeklődő az ajánlatkérésig. Innen a weboldal a mérnökiroda saját munkaeszköze, nem egy fejlesztőre váró projekt.
Időkeret: nyár elejétől az ősz közepéig
A szerződés nyár elején jött létre, a tervezés röviddel utána indult. Az oldalak átállítása az ősz elején ment végig, a tagsági rész és a nyilvántartás a következő hetekben készült el. A mérési terv a munka végén, egy rövid szakaszban állt össze, a beállítással együtt.
A tervezés és az átállítás között hosszabb szünet volt. Maga az átállítás gépies rész lett, mert minden oldalt ugyanaz az ellenőrzés kísért; a hosszabb szakaszok a tagsági résznél és a nyilvántartásnál jöttek, ahol a levélküldést és a telepítést több féllel kellett egyeztetni. A legtöbb várakozás nem a fejlesztésnél, hanem a jóváhagyásoknál és a hozzáféréseknél keletkezett, és az átállás időpontja is ezen múlik.
A mérésnél a sorrend kötött volt: előbb a meglévő beállítás felmérése, aztán a terv a kérdésekkel, utána az ügyfél válaszai, és csak ezek után a beállítás.
Mit vihetsz el ebből a saját cégedhez
Egy weboldal-költözés ritkán a technikán bukik el. Inkább azon, hogy a projekt elején senki nem írja le, kié a domain, ki küldi a leveleket, és ki dönt a mérésről. Ha ezek megvannak, a költözés nagyrészt ellenőrizhető, gépies munka.
- Írd le a hozzáféréseket és a jóváhagyókat, mielőtt bárki hozzányúl az oldalhoz.
- Költözésnél a szöveg maradjon érintetlen; a tartalmi javítás külön kör legyen, külön jóváhagyással.
- Ha regisztrációt gyűjtesz, a törlés útját is tervezd meg, ne csak a feliratkozásét.
- A mérési tervet a célokkal kezdd: mit tekintesz ajánlatkérésnek, és mennyit ér neked.
- A sütikezelőt összehasonlítás alapján válaszd, ne az első ajánlat alapján.
A többi eset az esettanulmányok áttekintőjében van, egy gyártói példa az ipari gyártó hirdetési fiókjáról és weboldaláról szól. A mérnökirodai módszert az AI a mérnökirodában cikk írja le.
Gyakori kérdések
Mi a különbség a weboldal újratervezése és a költözés között?
Újratervezésnél a tartalom és a kinézet is változik, költözésnél a tartalom marad, csak szerkeszthető helyre kerül. Ennél a mérnökirodánál a költözés volt a cél: a meglévő szakmai szövegek ne változzanak, a címek ne törjenek el, és utána a csapat maga tudja javítani az oldalt, fejlesztő nélkül.
Miért kellett külön ügyfélnyilvántartás a tagsági részhez?
Mert a regisztráció személyes adat, és annak útja végig kell legyen követhető: ki regisztrált, kapott-e hírlevelet, és ha a törlését kéri, minden helyről eltűnik-e. A weboldal tartalomkezelője erre nem való. A külön nyilvántartás ezt a láncot egy helyen kezeli, telepítőcsomaggal, hogy az ügyfél saját gépén fusson.
Mit tud a csapat maga csinálni a költözés után?
Szövegeket, szolgáltatásleírásokat és szakmai cikkeket ír és tesz közzé a szerkeszthető blokkokban, a szerkesztői kézikönyv alapján, fejlesztő nélkül. A tagsági részben védett cikkeket oszt meg a regisztrált partnerekkel, a regisztrációk pedig a nyilvántartásba futnak, hírlevél-szinkronnal és törlési lánccal. Egy új oldalhoz sem kell külön fejlesztői megrendelés.
Források
- Site moves with URL changes – Google Search Central, megnyitva 2026-10-21.
- Art. 17 GDPR – Right to erasure – gdpr-info.eu, a 2016/679 rendelet szövege, 2016.
- Consent mode on websites and mobile apps – Google Analytics súgó, megnyitva 2026-10-21.