A weboldal-készítési szerződés fontos pontjai megrendelőként

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

Ha előtted van egy weboldal-készítési szerződés, és nem tudod eldönteni, mi hiányzik belőle, ez az írás neked szól. Hat pontot nézünk végig, amelyeknél a legtöbb vita kirobban a megrendelő és a fejlesztő között. Mindegyikhez kapsz egy kérdést, amellyel a saját szerződésedet ellenőrizheted, és egy példát arra, mi történik, ha a pont kimarad.

Fontos. Ez a cikk nem jogi tanács. Marketing- és webfejlesztési oldalról írtuk, és nem helyettesíti az ügyvédi átnézést. A végén külön leírjuk, mikor érdemes ügyvédhez fordulnod. A szövegben jelöljük, mi hivatalosan igazolt (jogszabály vagy hivatalos szabályzat mondja ki), mi saját tapasztalat (weboldal-átvételeknél és -javításoknál láttuk), és mi szakmai feltételezés.

Miért kevés, ha a szerződésben csak annyi áll, hogy „weboldal elkészítése”?

Azért, mert egy ilyen mondatból nem derül ki, mit kell átadni, mikor van kész a munka, és kié lesz utána. A jó szerződés hat kérdést rendez külön pontban, ezek a teljesítés, a módosítási körök, a forrásfájlok és hozzáférések, a szerzői jog, a domain és a tárhely, valamint a hibajavítás.

Saját tapasztalat. Az átvett weboldalaknál a gondok többsége félreértésből ered. A felek mást értettek ugyanazon a szón. A megrendelő a „kész” szó alatt egy élesített, mérőkódokkal ellátott, kereshető oldalt értett, a fejlesztő egy jóváhagyott tervet a tesztszerveren.

Szakmai feltételezés. Minél kisebb a projekt, annál valószínűbb, hogy a szerződés egy egyoldalas ajánlatból és néhány e-mailből áll. Ez önmagában rendben lehet, de ilyenkor a hat pontot érdemes az ajánlat mellékleteként írásban rögzíteni, hogy később mindketten ugyanarra hivatkozhassatok.

Mikor számít teljesítettnek a weboldal?

Akkor, amikor a szerződésben előre leírt feltételek teljesülnek, és ezt egy átadás-átvételi eljárás rögzíti. Ha nincs leírva, mit kell átadni, a teljesítés megítélése vitatható lesz, és a vita általában a záró számla körül robban ki.

Egy jól megírt teljesítési pontban ezek az elemek szerepelnek.

• az oldalak listája, például főoldal, öt szolgáltatás-aloldal, kapcsolat, adatkezelési tájékoztató
• a funkciók listája (űrlap, foglalás, webshop, hírlevél-feliratkozás), és hogy melyik külső rendszerhez kapcsolódnak
• hogy a teljesítés az éles domainen vagy egy tesztszerveren történik
• milyen eszközökön és böngészőkben kell hibátlanul működnie az oldalnak
• ki tölti fel a szövegeket és a képeket, és mi történik, ha a megrendelő anyaga késik
• az átvételi időszak, vagyis hány napod van jelezni a hibákat, és mi történik, ha nem jelzel

Hivatalosan igazolt. A Polgári Törvénykönyv szerint a vállalkozási szerződésben a vállalkozó egy eredmény létrehozására vállal kötelezettséget, a megrendelő pedig az átadás-átvétel során köteles megvizsgálni a szolgáltatást. Hogy pontosan mi ez az eredmény, azt a szerződésnek kell meghatároznia.

Ellenőrző kérdés. Meg tudod mondani a szerződés alapján, egyetlen mondatban, mitől lesz kész a weboldal?

Ha hiányzik. A fejlesztő a tesztszerveren jóváhagyott tervet késznek tekinti, és kiszámlázza a záró részt. Te úgy látod, hogy az élesítés, az űrlap bekötése és a régi oldal átirányítása még hátravan. Mivel egyikőtök álláspontja sincs leírva, a vitát csak alkuval lehet lezárni.

Hány módosítási kör jár, és mi számít egy körnek?

Annyi, amennyit a szerződés kimond, ezért a számot és a kör fogalmát is érdemes leírni. Egy kör jellemzően azt jelenti, hogy egyszerre, egy összesített listában küldöd el a kéréseidet, és a fejlesztő ezt egyben dolgozza fel.

Három fogalmat kell elválasztani egymástól. A hibajavítás az, amikor valami nem úgy működik, ahogy a szerződés leírta, és ez nem fogyaszt kört. A módosítás a leírt kereten belüli változtatás, például más színárnyalat, átrendezett blokk vagy cserélt kép. Az új igény a kereten kívül esik, például egy addig nem szereplő aloldal vagy egy új nyelvi változat, ezt külön meg kell rendelni.

Saját tapasztalat. Ahol a kör nincs meghatározva, ott a megrendelő gyakran apránként küldi a kéréseket e-mailben, csetben és telefonon. A fejlesztő mindegyiket külön körnek számolja, a megrendelő egyiket sem. Ebből a felek egyike biztosan csalódott lesz.

Ellenőrző kérdés. Le van írva, hány kör jár a tervezésnél és hány a megvalósításnál, és mi történik a kereten felüli kérésekkel?

Ha hiányzik. A harmadik hét után a fejlesztő jelzi, hogy a kérések túllépték a vállaltakat, és minden további változtatást külön számláz. Te úgy emlékszel, hogy szóban „korlátlan módosítást” beszéltetek meg. Írásos nyom nélkül ezt nehéz bizonyítani.

Megkapod-e a forrásfájlokat és a hozzáféréseket?

Csak akkor számíthatsz rájuk, ha a szerződés tételesen felsorolja őket, és kimondja, mikor és milyen formában kerülnek hozzád. Enélkül a weboldal működik, de nem tudsz vele szabadon gazdálkodni, és egy szolgáltatóváltásnál ez komoly akadály lehet.

Ezeket érdemes a szerződésbe vagy egy mellékletbe tételesen beírni.

• a weboldal adminisztrátori fiókja a saját e-mail-címedre
• a tárhely kezelőfelülete, az SFTP- és az adatbázis-hozzáférés
• a domain kezelése és a DNS-beállítások
• a Google Analytics, a Google Tag Manager és a Google Search Console tulajdonosi szintű jogosultsága
• a tervfájlok (például Figma), a logó és a grafikák szerkeszthető formátumban
• a megvásárolt sablonok és bővítmények licence, lehetőleg a te nevedre
• egy teljes biztonsági mentés az átadás napjáról

Saját tapasztalat. A leggyakoribb hiány az, hogy a mérőfiókokat a fejlesztő a saját Google-fiókjában hozza létre, és a megrendelő csak olvasási jogot kap. Amikor a közös munka véget ér, a korábbi mérési adatokhoz való hozzáférés is bizonytalanná válik. Hasonló a helyzet a sablonlicenccel, mert ha az a fejlesztő fiókjához tartozik, a frissítések egy idő után elmaradhatnak.

Ellenőrző kérdés. Ha holnap másik fejlesztőt bíznál meg, minden belépést meg tudnál adni neki anélkül, hogy a mostanitól kellene kérned?

Ha hiányzik. A fejlesztőd elérhetetlenné válik, az oldalon biztonsági frissítés kellene, és kiderül, hogy az admin fiók, a tárhely és a sablon licence is az ő nevén van. Az új szolgáltató csak hosszadalmas hozzáférés-visszaszerzés után tud munkához látni.

Kié lesz a weboldal szerzői jogilag?

A szerzői jog a művet létrehozó szerzőt illeti, ezért azt, hogy te mit tehetsz a weboldallal, a szerződésben kell rendezni. A gyakorlatban ez egy felhasználási engedélyt jelent, amelynek a terjedelmét, az időtartamát és a kizárólagosságát érdemes kifejezetten leírni.

Hivatalosan igazolt. A szerzői jogról szóló 1999. évi LXXVI. törvény szerint a szerző személyhez fűződő jogai (például a név feltüntetéséhez való jog) nem ruházhatók át. A vagyoni jogokra a szerző felhasználási szerződéssel ad engedélyt, és ezt a szerződést a törvény szerint főszabályként írásba kell foglalni. Ha a szerződés nem határozza meg a felhasználás terjedelmét, az engedély csak a szerződés céljához szükséges mértékre terjed ki. Ezért számít, hogy szerepel-e benne az átdolgozás joga.

Az átdolgozás joga azt jelenti, hogy a weboldalt később te vagy egy másik fejlesztő módosíthatja és bővítheti. Ha ez kimarad, vitatható lehet, hogy egy új szolgáltató hozzányúlhat-e a kódhoz és a dizájnhoz. Ügyvédi szemmel azt is érdemes megnézni, hogy a szerződés kizárólagos vagy nem kizárólagos engedélyt ad, továbbadható-e harmadik személynek, és határozott vagy határozatlan időre szól-e.

Hivatalosan igazolt. A WordPress a GPL licenc alatt érhető el, a fizetős sablonok és bővítmények licencfeltételeit viszont a fejlesztőjük határozza meg. A fejlesztő ezekre nem adhat több jogot, mint amennyit ő maga kapott.

Saját tapasztalat. Érdemes kérni egy listát arról, mi a fejlesztő saját munkája, és mi származik harmadik féltől (tartalomkezelő, sablon, bővítmények, betűtípusok, stockfotók), milyen licenccel.

Szakmai feltételezés. Az AI-eszközzel készült szövegek és képek szerzői jogi megítélése még kiforratlan. Ha a fejlesztő ilyet használ, kérd, hogy a szerződés vagy az átadási dokumentáció ezt jelezze.

Ellenőrző kérdés. Szerepel a szerződésben, hogy módosíthatod és mással is módosíttathatod a weboldalt?

Ha hiányzik. Két év múlva új arculatot kérsz egy másik ügynökségtől. A korábbi fejlesztő jelzi, hogy a dizájn az ő szellemi terméke, és az átdolgozáshoz nem adott engedélyt. Akár igaza van, akár nincs, a projekt megáll, amíg ez tisztázódik.

Kinek a nevén legyen a domain és a tárhely?

A domain igénylője, vagyis a jogosultja a megrendelő legyen, és a tárhelyszerződés is lehetőleg a megrendelő nevén fusson, vagy legyen leírva, hogyan kerül át hozzá. A domain a céged online címe, és aki a jogosultja, az dönt róla.

Hivatalosan igazolt. A .hu domainek nyilvántartását az Internet Szolgáltatók Tanácsa (ISZT) Domainregisztrációs Szabályzata rendezi. Eszerint a domain használati jogát az igénylő szerzi meg, a regisztrátor csak közreműködik az eljárásban. Ha tehát a fejlesztő a saját nevére igényli a domaint, a használati jog az övé.

Saját tapasztalat. Ugyanez a tárhelynél is gondot okoz, ha az a fejlesztő gyűjtőfiókjában van. Ilyenkor a céges e-mail-fiókok, a mentések és a DNS-rekordok is az ő kezében vannak, és egy előre meg nem tervezett szolgáltatóváltás könnyen a levelezés kiesésével jár.

Ellenőrző kérdés. Ki szerepel a domain igénylőjeként és a tárhelyszerződés feleként, és van-e saját belépésed mindkettőhöz?

Ha hiányzik. A közös munka véget ér, a domain a fejlesztő nevén van, és a megújítás elmarad. Az oldal és a céges levelezés egyszerre leáll, a domain visszaszerzése pedig egy jogosultváltási eljárás, amelyhez a korábbi jogosult közreműködése kell.

Mi a hibajavítás rendje az átadás után?

Az átadás utáni hibajavítást a szerződésnek külön kell szabályoznia, és el kell választania a folyamatos karbantartástól. Le kell írni, mi számít hibának, hogyan jelented be, milyen gyorsan reagál a fejlesztő, és meddig tart a kötelezettsége.

• a hiba fogalma, vagyis a szerződésben leírt működéstől való eltérés
• a bejelentés csatornája, például jegykezelő vagy egy kijelölt e-mail-cím
• a hibák súlyossági szintjei, például leállt oldal, nem működő űrlap, apró megjelenési hiba
• mi nem hiba, például a megrendelő által telepített bővítmény vagy egy későbbi frissítés okozta eltérés
• meddig tart a hibajavítási kötelezettség az átadás után

Hivatalosan igazolt. A Ptk. hibás teljesítésre vonatkozó szabályai, köztük a kellékszavatosság, akkor is irányadók, ha a szerződés nem tér ki rájuk. Hogy ezek a ti esetetekben pontosan hogyan érvényesülnek, különösen cégek közötti szerződésnél, azt ügyvéd tudja megítélni.

Saját tapasztalat. A vita sokszor abból lesz, hogy az átadás után hónapokkal egy bővítményfrissítés elront valamit. A megrendelő hibának látja, a fejlesztő karbantartásnak. Ha a szerződés kimondja, hogy a frissítések kezelése a karbantartási szerződés része, ez a kérdés el sem jut a vitáig.

Ellenőrző kérdés. Ha az átadás után két hónappal nem érkeznek meg az űrlapról a levelek, a szerződés alapján tudod, kinek kell javítania, és milyen feltételekkel?

Ha hiányzik. Az űrlap hetekig nem küld értesítést, és ezalatt elvesznek az ajánlatkérések. A fejlesztő szerint a levelezőszerver a hibás, a tárhelyszolgáltató szerint a weboldal. Mivel senkinek nincs leírt felelőssége, mindenki a másikra mutat.

Milyen marketing- és technikai pontok maradnak ki a leggyakrabban?

Saját tapasztalat. A jogi pontok mellett a marketing- és technikai elvárások szoktak kimaradni, pedig ezek döntik el, hogy az új oldal hoz-e érdeklődőt. Ezeket érdemes a teljesítési feltételek közé beírni.

• a régi oldal címeinek 301-es átirányítása az újakra, egy előre egyeztetett URL-lista alapján
• a mérőkódok (Analytics, Tag Manager, hirdetési pixelek) beépítése és a konverziók tesztelése
• a süti-hozzájárulás kezelése, összhangban a mérőkódokkal
• az oldalak címe, meta leírása és a strukturált adatok (Schema.org) alapbeállítása
• a mobilos megjelenés és a betöltési sebesség mérhető elvárása
• az akadálymentesség szintje, ha releváns, például a WCAG 2.2 AA szint

Hivatalosan igazolt. A Google Search Central webhely-áthelyezési útmutatója tartós, szerveroldali (301-es) átirányítást javasol, amikor egy oldal címei megváltoznak. Apache-szerveren egy ilyen sor így néz ki.

Redirect 301 /regi-szolgaltatas/ https://www.pelda.hu/szolgaltatasok/uj-szolgaltatas/

Szakmai feltételezés. Ha az átirányítás kimarad, a korábban jól teljesítő aloldalak forgalma jó eséllyel visszaesik egy időre, mert a keresők és az AI-alapú válaszmotorok a régi címeket nem létező oldalnak látják. A visszaesés mértéke oldalanként eltér, előre nem lehet pontosan megmondani.

Mikor fordulj ügyvédhez?

Akkor, amikor a szerződés jogi következményeiről kell dönteni, és nem csak a tartalmi hiányokat kell pótolni. Ügyvédet érdemes bevonni, ha az alábbiak közül bármelyik igaz.

• a szerződés kötbért, kártérítési korlátozást vagy felelősségkizárást tartalmaz
• a szerzői jogi pontot kell megfogalmazni vagy módosítani (kizárólagosság, átdolgozás, időtartam)
• a weboldal személyes adatot kezel (webshop, foglalás, regisztráció), és adatfeldolgozói szerződés is kell
• külföldi a fejlesztő, vagy a szerződés idegen jog szerint szól
• már van vita, és a domain, a hozzáférések vagy a záró számla a tét

Milyen ellenőrzőlistával nézd át a szerződésedet aláírás előtt?

Ezzel a hét kérdéssel gyorsan kiszűrheted a legnagyobb hiányokat. Ha bármelyikre „nem tudom” a válasz, kérj írásban pontosítást a fejlesztőtől.

1. Le van írva oldalanként és funkciónként, mitől lesz kész az oldal, és hogyan zajlik az átvétel?
2. Meg van határozva a módosítási körök száma és az, hogy mi számít egy körnek?
3. Tételes lista szól az átadandó hozzáférésekről, forrásfájlokról és licencekről?
4. Kifejezetten szerepel a felhasználás terjedelme és az átdolgozás joga?
5. A te neveden lesz a domain, és tisztázott a tárhely sorsa?
6. Van leírt hibajavítási rend, elválasztva a karbantartástól?
7. Bekerültek a teljesítési feltételek közé az átirányítások és a mérőkódok?

Miben segítünk a szerződés átnézésénél?

A Scheo csapata a szerződés marketing- és technikai pontjait nézi át, vagyis a teljesítés tartalmi leírását, a hozzáférések listáját, a mérést, az átirányításokat, valamint a domain és a tárhely kérdését. Jogi tanácsot nem adunk, de a jogi pontoknál jelezzük, ha ügyvédi átnézést javaslunk.

Ha aláírás előtt állsz, küldd el nekünk a kapott szerződést vagy ajánlatot, és visszajelzünk, mely pontokat érdemes megkérdezni, pontosítani vagy kiegészíteni, mielőtt aláírod.

Források és további olvasnivalók

• 2013. évi V. törvény a Polgári Törvénykönyvről (vállalkozási szerződés, hibás teljesítés)
• 1999. évi LXXVI. törvény a szerzői jogról
• Internet Szolgáltatók Tanácsa (ISZT), Domainregisztrációs Szabályzat
• Google Search Central, Webhely áthelyezése URL-módosítással
• WordPress.org, a WordPress licence (GPL)
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2
• Schema.org dokumentáció