- A szövegeid és a saját képeid szerzői jogilag a tieid, de egy zárt rendszerből csak akkor tudod őket kivinni, ha géppel olvasható formában exportálhatók.
- A szoftver szerzői mű, ezért a forráskód és a továbbfejlesztés joga csak akkor a tiéd, ha a szerződés ezt kifejezetten kimondja.
- A domain, a tárhely, a Search Console és az Analytics fiókja a te cégedé legyen, a készítő pedig csak felhasználóként férjen hozzá.
- A zárt rendszer akkor lehet jó döntés, ha valóban egyedi funkció kell, és a kilépési út írásban rendezve van.
- Aláírás előtt kérj próbaexportot és független véleményt, mert ilyenkor még egy mondat módosítása is elég.
Ha a weboldalkészítő saját fejlesztésű tartalomkezelő rendszert (CMS) ajánl, az oldalad olyan szoftveren fog futni, amelyet igazán csak ő ismer. Ez önmagában nem baj. A kérdés akkor válik élessé, amikor szolgáltatót váltanál, és kiderül, mennyire vihető tovább a tartalmad, a dizájnod és a fejlesztés. Ebben segít ez a cikk még a megrendelés előtt. Megnézzük, mit kapsz meg ténylegesen, és mit nem.
A cikkben háromféle jelölést használunk. A Hivatalosan igazolt állítás jogszabályon, szabványon vagy a Google nyilvános dokumentációján alapul. A Saját tapasztalat az, amit weboldal-átvételek és szolgáltatóváltások során rendszeresen látunk. A Szakmai feltételezés ésszerű következtetés, de nincs mögötte mérés vagy hivatalos forrás.
Mit jelent pontosan, ha a weboldalkészítő saját fejlesztésű rendszert ajánl?
Azt jelenti, hogy az oldal adminfelülete, adatbázisa és sablonmotorja a készítő saját kódja, és nem egy széles körben használt, nyílt rendszer (például WordPress, Drupal vagy Joomla) része. A tartalmat ugyanúgy szerkesztheted, de a rendszer működését, frissítését és bővítését csak az érti, aki megírta.
A gyakorlatban három változattal találkozhatsz. Az első egy teljesen egyedi fejlesztés, amelyet csak a te oldaladhoz írtak. A második egy ügynökségi platform, amelyen a készítő több ügyfelének oldala fut, és te bérleti jelleggel használod. A harmadik egy ismert keretrendszerre (például Laravelre vagy Symfonyra) épülő saját admin, amelyhez egy másik fejlesztő viszonylag könnyen hozzá tud nyúlni, ha megkapja a kódot. A második változatnál a legnagyobb a kockázat, mert ott a szoftver jellemzően egyáltalán nem a tiéd, csak használod, amíg a szolgáltatás él.
Mi történik a tartalommal, ha véget ér az együttműködés?
A szövegek, képek és termékadatok a gyakorlatban akkor maradnak a tieid, ha géppel olvasható formában ki tudod őket exportálni. Ha a szerződés ezt nem rögzíti, a tartalom elvileg a tiéd, de a kinyerése kézi másolgatás lehet.
Hivatalosan igazolt. A szövegeid és a saját fotóid szerzői jogilag hozzád (vagy a szerzőjükhöz) tartoznak, függetlenül attól, melyik rendszerbe töltötted fel őket. A magyar szerzői jogi törvény (Szjt.) ebben nem tesz különbséget a tárolás helye szerint.
Saját tapasztalat. A jogi tulajdon ritkán okoz gondot, a formátum viszont gyakran. Zárt rendszereknél sokszor előfordul, hogy a cikkek belső azonosítókkal teletűzdelt HTML-töredékként állnak az adatbázisban, a képek átnevezett fájlnévvel és alt szöveg nélkül, a termékváltozatok pedig egyedi táblaszerkezetben. Egy 30 oldalas bemutatkozó oldalt még át lehet másolni kézzel, egy több száz termékes webshopot vagy egy több éves blogot már nem érdemes.
A tartalomhoz tartozik az URL-szerkezet, az oldalcímek és a meta leírások, az átirányítások listája és az űrlapokon beérkezett adatok is, ezeket pedig sokan elfelejtik. Nélkülük az új oldal úgy indul, mintha a régi soha nem létezett volna.
Mi lesz a dizájnnal és a fejlesztéssel?
A dizájn grafikai terve (például a Figma-fájl) általában átadható. A működő sablon viszont a saját rendszer sablonnyelvén készült, ezért máshol jó eséllyel újra kell építeni. A fejlesztést, vagyis az egyedi funkciók kódját akkor viheted tovább, ha a forráskódot és a használati jogot is megkapod.
Hivatalosan igazolt. Az Szjt. szerint a szoftver szerzői mű. Ha a szerződés mást nem mond, a fejlesztő a szerző, te pedig felhasználási engedélyt kapsz. A szoftverre vonatkozó vagyoni jogok a törvény kivételes szabálya szerint át is ruházhatók, de ehhez kifejezett szerződéses rendelkezés kell. A pontos megfogalmazásban ügyvéd tud segíteni.
Saját tapasztalat. Sok ajánlatban az áll, hogy „az elkészült weboldal a megrendelő tulajdonába kerül”. Ez jól hangzik, de nem derül ki belőle, hogy a weboldal itt a megjelenést, a tartalmat vagy a mögötte futó szoftvert jelenti. Bérelt platformnál szinte mindig csak az első kettőt.
Ki tudja továbbfejleszteni az oldalt, ha a készítő kiesik?
Egyedi rendszert reálisan csak az tud továbbfejleszteni, aki megkapja a teljes forráskódot, az adatbázist és a dokumentációt, és ismeri az alkalmazott programnyelvet. Ezek nélkül az oldal karbantartása a készítőhöz kötődik.
A kiesés nem mindig szándékos. A készítő nyugdíjba megy, megszünteti a vállalkozását, vagy egyszerűen elérhetetlenné válik. Egy nyílt rendszernél ilyenkor is van kihez fordulni, egy zárt rendszer kódját viszont lehet, hogy rajta kívül senki sem ismeri.
Egy átvevő fejlesztő tipikusan ezeket kéri először.
- A forráskódot verziókezelőben (például Git-tárolóban), a teljes előzménnyel.
- Az adatbázis mentését és a táblák leírását.
- A szerver beállításait, a programnyelv és a keretrendszer verzióját.
- A külső szolgáltatások (fizetés, levélküldés, térkép) hozzáféréseit.
Szakmai feltételezés. Egy ismert keretrendszerre épülő, rendesen dokumentált egyedi kódot egy tapasztalt fejlesztő jellemzően néhány nap alatt megért. Egy dokumentálatlan, egyedi megoldásokkal teli rendszer feltérképezése ennél jóval tovább tarthat, és ilyenkor sok fejlesztő inkább az újraépítést javasolja. Ezt nem mértük, de a fejlesztői gyakorlat ebbe az irányba mutat.
Mi kerül át ténylegesen a te tulajdonodba?
Annyi, amennyit a szerződés tételesen felsorol, és amit kézzelfoghatóan meg is kapsz. Az alábbi elemeket érdemes egyenként végigvenni.
- Domain. A .hu domain annak a nevén van, akit igénylőként megadtak. Ennek a te cégednek kell lennie, a regisztrátornál ellenőrizhető módon (Hivatalosan igazolt, ISZT Domainregisztrációs Szabályzat).
- Tartalom. Szövegek, képek, videók és dokumentumok exportálható formában.
- Grafikai terv. A forrásfájl, a betűtípusok licence és a logó vektoros változata.
- Forráskód. Teljes, futtatható állapotban, vagy legalább letétbe helyezve.
- Adatbázis. Teljes mentés a táblaszerkezet leírásával.
- Hozzáférések. Tárhely, DNS, Google Search Console, Google Analytics, Google Cégprofil. Ezekben a te fiókod legyen a tulajdonos, a készítő pedig csak felhasználó.
Saját tapasztalat. A legtöbb vita a hozzáféréseknél kezdődik. Ha a Search Console vagy az Analytics a készítő fiókjában van, váltáskor a mérési előzmények is nála maradhatnak.
Hogyan nézhet ki ez a szerződésben?
Egy jól megfogalmazott átadási pont tételes, például így szólhat.
„A szolgáltató a szerződés megszűnésétől számított 15 munkanapon belül átadja a megrendelőnek a weboldal teljes tartalmát JSON vagy CSV formátumban, a képfájlokat eredeti felbontásban, az URL-ek listáját, a teljes adatbázis-mentést, valamint a forráskódot és a telepítési leírást. A megrendelő a forráskódot saját weboldala működtetéséhez és továbbfejlesztéséhez harmadik féllel is módosíttathatja.”
Ez csak minta, a végleges szöveget ügyvéddel érdemes egyeztetni. Minden elem neve, formátuma és átadási ideje legyen benne.
Milyen kérdéseket tegyél fel a kilépési útról aláírás előtt?
Négy területet érdemes írásban tisztázni. Ezek a kilépés menete, a tartalom exportja, a dokumentáció és a forráskód elérhetősége. A válaszokat a szerződésbe vagy annak mellékletébe kérd, mert egy e-mailben tett ígéret később kevés.
A kilépési útról
- Ha felmondom a szerződést, meddig fut még az oldal, és mi történik utána az adatokkal?
- Milyen formában és mennyi idő alatt adjátok át az anyagokat?
- Segítetek az átköltözésben (átirányítások, DNS-váltás), és ennek mi a feltétele?
- Mi történik, ha a vállalkozásotok megszűnik?
A tartalom exportjáról
- Milyen fájlformátumban kapom meg a tartalmat (CSV, JSON, XML)?
- Benne vannak az exportban a meta adatok, az URL-ek, a képek alt szövegei és a kategóriák?
- Kérhetek próbaexportot még a szerződés előtt vagy az átadáskor?
- Az űrlapokon és a webshopban keletkezett adatok (rendelések, vásárlói adatok) is exportálhatók?
A dokumentációról
- Van-e írásos leírás a rendszer felépítéséről, telepítéséről és frissítéséről?
- Le van írva, milyen külső szolgáltatásokhoz kapcsolódik az oldal?
- Ki és hogyan javítja a biztonsági hibákat, és ez dokumentálva van?
A forráskód elérhetőségéről
- Megkapom a teljes forráskódot, vagy csak futtatási jogot kapok?
- Ha a kódot nem adjátok át, vállaljátok a letétbe helyezését (escrow) egy harmadik félnél?
- Más fejlesztővel módosíttathatom a kódot, vagy ezt a licenc tiltja?
- Milyen programnyelven és keretrendszeren fut, és ezeknek van még támogatása?
Saját tapasztalat. Az is sokat elárul, ahogyan a készítő ezekre a kérdésekre reagál. Ha nyugodtan és pontosan válaszol, jó eséllyel gondolt már a kilépési útra. Ha kitér, vagy azt mondja, hogy „erre úgysem lesz szükség”, érdemes óvatosnak lenned.
Mikor lehet mégis jó döntés a zárt rendszer?
Akkor, ha az oldalad olyan egyedi folyamatot szolgál ki, amelyet egy általános CMS csak sok bővítménnyel és kompromisszummal tudna, és a kilépési út írásban rendezve van. A zárt rendszer önmagában nem rossz választás.
Szakmai feltételezés. Előny lehet a kisebb támadási felület, mert egy egyedi rendszert ritkábban céloznak tömeges, automatizált támadások, mint a széles körben használt bővítményeket. A rendszeres frissítés ettől még ugyanúgy kell. Előny lehet az egyszerűbb adminfelület is, ha a csapatodban nincs technikai ember.
Az alábbi esetekben lehet ésszerű.
- Egyedi ügyfélkaput, foglalási logikát vagy belső rendszerhez kapcsolódó funkciót építtetsz, amelyet egyébként is egyedileg kellene fejleszteni.
- A készítő ismert keretrendszert használ, és a forráskódot átadja.
- A szerződés rögzíti az exportot, a dokumentációt és a felmondás utáni átadási időszakot.
- Hosszú távú együttműködést tervezel, és a készítőnek több éves, ellenőrizhető szakmai múltja van.
Milyen jelek szólnak egy zárt rendszer ellen?
A legerősebb figyelmeztető jel az, ha a készítő nem tud vagy nem akar írásban válaszolni arra, hogyan viheted el az oldalad. Ehhez gyakran más jelek is társulnak.
- Egy egyszerű bemutatkozó oldalhoz ajánl saját rendszert, pedig ehhez nem kell egyedi fejlesztés.
- A domain, a tárhely és a mérőkódok az ő nevén, az ő fiókjában lennének.
- A szerződés szerint az oldal a szolgáltatás megszűnésével lekapcsol, átadás nélkül.
- Próbaexportot nem ad, a tartalom kiadását pedig külön megrendeléshez kötné.
- Nem mondja meg, milyen technológián fut a rendszer.
- Más fejlesztő hozzáférését kizárja, és erre nem tud szakmai indokot adni.
Hogyan ellenőrizd egy próbaexporttal, hogy a kilépés tényleg működik?
Kérj exportot néhány oldalról, és nézd meg, hogy gépi úton betölthető-e egy másik rendszerbe. Ehhez nem kell programozónak lenned. Az számít, hogy minden adat külön mezőben legyen.
Egy jól használható exportban egy oldal nagyjából így néz ki.
{ "url": "/szolgaltatasok/arculattervezes", "title": "Arculattervezés", "meta_description": "...", "body_html": "<p>...</p>", "images": [{ "file": "arculat-minta.jpg", "alt": "Arculati kézikönyv oldalai" }], "updated": "2026-10-02" }
Ha az export egyetlen összefolyó szövegtömb, vagy hiányoznak belőle a képek, az átköltözés jó eséllyel kézi munka lesz.
A másik fontos lépés az URL-ek mentése. Hivatalosan igazolt. A Google Search Central dokumentációja URL-változással járó költözésnél állandó (301-es) átirányítást javasol a régi címekről az újakra, ehhez pedig a régi URL-ek teljes listája kell. Ezt a jelenlegi oldal sitemap fájljából is kinyerheted, egy átirányítást pedig parancssorból így ellenőrizhetsz.
curl -I https://pelda.hu/regi-oldal
A válaszban a HTTP/1.1 301 sort és az új címre mutató Location fejlécet keresd. Ha a zárt rendszerben nem kezelheted az átirányításokat, az a költözéskor komoly akadály lehet.
Szakmai feltételezés. Az AI-alapú válaszmotorok (például a Google AI-áttekintései vagy a ChatGPT keresése) is a meglévő, indexelt oldalakra hivatkoznak. Egy rosszul kezelt költözés után időbe telhet, mire az új címeket ismét forrásként használják. Ezt teljesen megelőzni nem lehet, de az átirányítások és a strukturált adatok (Schema.org) átvitele jó eséllyel segít.
Mikor érdemes független véleményt kérni az ajánlatról?
Akkor, amikor már a kezedben van az ajánlat és a szerződéstervezet, de még nem írtad alá. Ebben a szakaszban egy kérdés vagy egy mondat módosítása még semmibe sem kerül, később viszont egy költözés komoly munka.
Egy független szakember, aki nem érdekelt a projektben, néhány dolgot általában gyorsan meg tud nézni. Átnézi, hogy a szerződés tételesen felsorolja-e az átadandó elemeket, értelmezi a forráskódra és a licencre vonatkozó részt, és megmondja, valóban kell-e egyedi rendszer a kért funkciókhoz. A próbaexportot is megnézheti, és azt is, hogy a domain és a mérőfiókok a te nevedre kerülnek-e.
Saját tapasztalat. A legtöbb gondot olyan helyzetek okozzák, amelyekről az aláíráskor senki sem beszélt, mert mindkét fél jóhiszeműen a hosszú együttműködésre gondolt. Egy külső szem pont ezeket a hézagokat keresi. Ha bizonytalan vagy egy ajánlatban, küldd el egy független szakértőnek, és kérj tőle írásos véleményt a kilépési útról, mielőtt döntesz. Szerzői jogi és licenckérdésben ügyvéd véleményét is kérd ki.
Források és további olvasnivalók
- 1999. évi LXXVI. törvény a szerzői jogról (Szjt.)
- ISZT Domainregisztrációs Szabályzat (.hu domainek)
- Google Search Central, Webhely áthelyezése URL-változással
- Google Search Central, 301-es átirányítások és a Google Kereső
- Sitemaps.org, Sitemap protokoll
- Schema.org, strukturált adatok szókészlete
- W3C, HTML szabvány
Gyakori kérdések
A saját fejlesztésű CMS-ben feltöltött szövegeim kié lesznek?
A szövegek és a saját fotók szerzői jogilag a tieid maradnak, függetlenül attól, hol tárolják őket. Hogy a gyakorlatban el is tudod-e vinni őket, az az exportálhatóságon és a szerződésen múlik.
Megkapom a forráskódot, ha kifizettem a weboldalt?
Nem automatikusan. A szoftver szerzői mű, ezért a forráskód átadását és a továbbfejlesztés jogát a szerződésben kifejezetten rögzíteni kell. Ennek pontos megfogalmazásához érdemes ügyvédet bevonni.
Mi az a forráskód-letét (escrow)?
Egy harmadik félnél elhelyezett kódpéldány, amelyet meghatározott esetekben, például a fejlesztő megszűnésekor megkapsz. Akkor jó megoldás, ha a készítő a kódot nem akarja közvetlenül átadni.
Átvihető a dizájn egy másik rendszerbe?
A grafikai terv, például a Figma-fájl, általában átvihető. A működő sablont viszont az új rendszerben jó eséllyel újra kell építeni, mert a saját rendszer sablonnyelvén készült.
Hogyan ellenőrizhetem a szerződés előtt, hogy működik a kilépés?
Kérj próbaexportot néhány oldalról, és nézd meg, hogy az URL, a cím, a meta leírás, a szöveg és a képek külön mezőben szerepelnek-e. Ha egyetlen szövegtömböt kapsz, a költözés valószínűleg kézi munka lesz.
Rossz döntés egy zárt rendszer?
Nem feltétlenül. Egyedi funkcióknál indokolt lehet, ha a forráskód, a dokumentáció és az export írásban rendezve van. Egy egyszerű bemutatkozó oldalhoz viszont ritkán kell.
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.