A weboldal, ami nem készül el - hanem folyamatosan fejlődik
Nem WordPress, nem white-label: így működik a Weboldal Bérlés saját Website-as-a-Service platformja.
Van egy mondat, ami elsőre talán furcsán hangzik egy weboldalnál: nálunk a weboldal nem készül el végleg.
Persze ettől még egy weboldalnak az indulás napján késznek kell lennie. Működnie kell. Mobilon is. Gyorsan. Érthetően. Nem lehet félkész azzal a magyarázattal, hogy „majd egyszer továbbfejlesztjük”.
Nem erről beszélünk.
Arról beszélünk, hogy a web nem áll meg azon a napon, amikor egy oldal élesedik. Változnak a böngészők, a keresők, a mobileszközök, a biztonsági elvárások, a SEO, a teljesítménymérés, és most már az AI-alapú keresők és válaszrendszerek is. Ha a környezet folyamatosan változik, akkor egy weboldal technikai háttere sem maradhat éveken át ugyanaz.
A Weboldal Bérlés nálunk ezért nem egy egyszer elkészített weboldal havi számlázással. Egy folyamatosan fejlesztett és üzemeltetett saját weboldalplatform, amelyen több önálló ügyfélweboldal működik.
Röviden: miről szól ez a modell?
- Nem különálló WordPress-telepítéseket adunk bérbe.
- Nem egy külföldi weboldalépítőt címkézünk át a saját nevünkre.
- Saját fejlesztésű közös alkalmazásmagot használunk.
- Az egyes weboldalak saját tartalommal, domainnel, beállításokkal és adminisztrációval működnek.
- A platform technikai fejlesztései központilag készülnek el.
- A weboldal mellé üzemeltetési és szakmai segítség is tartozik.
- Nem egy technológiai rövidítést akarunk eladni, hanem egy kiszámítható weboldal-szolgáltatást.
1. „Nem készül el”? Ez elsőre rosszul hangzik
Jogosan. Ha valaki weboldalt rendel, akkor kész weboldalt szeretne, nem egy örök béta verziót.
A címben szereplő mondat ezért nem azt jelenti, hogy a weboldal folyamatosan félkész. Pont az ellenkezőjét.
Egy adott release-nek – vagyis az éppen éles weboldalverziónak – stabilnak kell lennie. De maga a platform nem fagyhat be ebbe az állapotba. Ha egy böngészőváltozás miatt módosítani kell a navigáción, ha új SEO-technikai elvárás jelenik meg, ha javítható a képkezelés vagy a Core Web Vitals teljesítmény, akkor a rendszernek tovább kell tudnia fejlődni.
Régebben sok weboldalnál teljesen természetes volt ez a folyamat:
elkészült → átadták → működött → néhány év múlva elavult → készült helyette egy új.
Mi ezen akartunk változtatni.
2. Van erre szakmai kifejezés is: Website-as-a-Service
A nemzetközi szakmában erre a megközelítésre a Website-as-a-Service elnevezést használják. Rövidítve: WaaS.
Fontos pontosítás: ez nem egy ISO-szabvány, nem programozási nyelv és nem egyetlen kötelező technikai architektúra neve. Inkább egy szolgáltatási modell, amely a SaaS – Software-as-a-Service – gondolkodását viszi át a weboldalak világába.
És még valami.
Nem attól lesz valami Website-as-a-Service, hogy havonta számlázzák.
Egy hagyományos weboldalkészítést is el lehet osztani havi díjakra. Attól az még ugyanúgy lehet egyszeri projekt. A WaaS lényege inkább az, hogy a weboldal egy folyamatosan működtetett szolgáltatási és technológiai környezet része.
3. Weboldalprojekt vagy folyamatos weboldal-szolgáltatás?
A két modell között nem az a különbség, hogy az egyik jó, a másik rossz. Más problémára valók.
| Szempont | Hagyományos weboldalprojekt | Website-as-a-Service modell |
|---|---|---|
| Indulás | Egy konkrét fejlesztési projekt készül el. | Egy működő platformon készül el az ügyfél weboldala. |
| Átadás után | A további fejlesztés és karbantartás külön feladat lehet. | A technikai háttér folyamatos üzemeltetése a szolgáltatás része. |
| Frissítések | Oldalanként vagy projektenként kell elvégezni őket. | A közös platform fejlesztései több weboldal számára is elérhetővé válhatnak. |
| Adminisztráció | A választott CMS vagy egyedi rendszer határozza meg. | A szolgáltatás részeként kialakított ügyféladmin működik. |
| Technikai háttér | A domain, tárhely, SSL, e-mail és karbantartás külön is kezelhető. | Ezek egy része vagy egésze egy szolgáltatáson belül kezelhető. |
| Költségmodell | Jellemzően nagyobb egyszeri fejlesztési díj + későbbi költségek. | Jellemzően előfizetéses, kiszámíthatóbb folyamatos díj. |
Egy nagyon egyedi üzleti rendszerhez továbbra is lehet, hogy külön fejlesztési projekt a helyes út. Egy fodrásznak, tanácsadónak, kivitelezőnek, alkotónak vagy más kisvállalkozásnak viszont sokszor nem az a célja, hogy saját webes infrastruktúrát üzemeltessen.
Ő weboldalt szeretne. Működőt.
4. Nem WordPress. Nem white-label. Más alapokra építettük.
A Weboldal Bérlés saját fejlesztésű rendszer. Nem WordPressre épül, és nem egy külső weboldalépítő white-label változata.
Ez fontos különbség. De nem azért, mert a WordPress „rossz”, vagy mert egy white-label platformmal ne lehetne jó weboldalakat készíteni.
Lehet.
A WordPress mögött hatalmas ökoszisztéma van. Egy white-label platform pedig kifejezetten arra alkalmas, hogy egy ügynökség saját márkanév alatt, gyorsan építsen és kezeljen sok ügyféloldalt. Ezek teljesen legitim technológiai döntések.
Mi egyszerűen más döntést hoztunk: a platformot is mi fejlesztjük.
| Megközelítés | Mire épül? | Fő előny | Fő kompromisszum |
|---|---|---|---|
| WordPress-alapú szolgáltatás | WordPress core, témák, bővítmények és egyedi fejlesztések. | Nagy ökoszisztéma, sok kész megoldás, gyors indulás. | A karbantartásnál több külső komponens és verzió együttműködését is kezelni kell. |
| White-label website builder | Egy külső szolgáltató kész platformja saját márkanév alatt. | Nagyon gyors piacra lépés, kész editor és infrastruktúra. | A platform lehetőségeit és korlátait végső soron a külső szolgáltató határozza meg. |
| Saját multi-tenant platform | Saját alkalmazásmag, saját adatmodell, admin és renderelési logika. | Nagy technikai kontroll és központilag fejleszthető működés. | A fejlesztési, üzemeltetési és kompatibilitási felelősség is a platform készítőjéé. |
Ez utóbbi a mi utunk.
Nem feltétlenül a könnyebb. Viszont pontosan tudjuk, hol van egy route, hogyan épül fel egy modul, miből készül a HTML, hogyan dolgozik a képkezelés, mi kerül a canonical URL-be, vagy mi történik egy admin Mentés gomb után.
Ha érdekel a mélyebb technikai rész, erről külön is írtunk a Weboldal Bérlés rendszerarchitektúráját bemutató cikkünkben.
5. Mit jelent nálunk a multi-tenant?
Itt jön egy kicsit technikaibb rész, de nem kell tőle megijedni.
A multi-tenant modell leegyszerűsítve azt jelenti, hogy egy közös alkalmazásmag több különálló ügyfélweboldalt szolgál ki. A szakirodalomban ez ismert SaaS-architekturális minta; a Microsoft dokumentációiban is külön tárgyalják a multi-tenant SaaS alkalmazások felépítését.
A fontos rész azonban az elkülönítés.
Attól, hogy a core közös, az ügyféloldalak nem lesznek egyformák. Saját domain, saját tartalom, saját képek, saját navigáció, saját színek, saját beállítások és saját adminisztráció tartozhat hozzájuk.
Egy motor, több önálló weboldal. Talán így a legegyszerűbb elképzelni.
Ha például a közös képkezelésen javítunk, annak előnye nem csak egyetlen ügyféloldalon jelenhet meg. Ha a SEO-rétegben készül egy jobb megoldás, azt sem kell húsz külön rendszerben húszféleképpen újra megírni.
Ez a közös platform egyik legnagyobb előnye.
6. Mit lát ebből az ügyfél – és mi történik mögötte?
Ideális esetben az ügyfél a technikai rész nagy részét nem látja. És ez így van jól.
| Amit az ügyfél lát | Ami a háttérben történik |
|---|---|
| Szerkeszthető weboldal | Saját ügyféladmin, jogosultságok, validáció és tenant-specifikus adatkezelés. |
| Moduláris blokkok | Közös komponensek, variánsok és szerveroldali renderelés. |
| Gyors képek | Responsive képváltozatok, méretezés, prioritás és teljesítményoptimalizálás. |
| SEO-beállítások | Metaadatok, canonical, sitemap, robots, strukturált adatok és további technikai SEO-rétegek. |
| Weboldal statisztika és vitalitás | Valós felhasználói mérés és Web Vitals adatok feldolgozása. |
| Magnus és SEO Központ | Webhely- és oldalszintű elemzések, Search Console-adatok és AI-támogatott értékelés. |
| Időpontfoglalás, ha szükséges | Szolgáltatások, időablakok, foglalási szabályok, értesítések és Google Naptár-integráció. |
| Domain, e-mail, SSL | Az oldal működéséhez szükséges infrastruktúra és üzemeltetési folyamatok. |
Az ügyfél szempontjából viszont nem az a kérdés, hogy melyik controller futott le.
Hanem az, hogy át tudja-e írni az árat, fel tud-e tölteni egy képet, működik-e mobilon az oldal, megérkezik-e az ajánlatkérés, és van-e kit megkérdezni, ha valamihez segítség kell.
A technológia akkor végzi jól a dolgát, ha nem kell állandóan beszélni róla.
7. A közös core előny. És felelősség is
A saját platformot könnyű úgy bemutatni, mintha csak előnye lenne.
Nem.
Ha saját a rendszer, akkor nem lehet egy problémára egyszerűen azt mondani, hogy „majd a plugin fejlesztője javítja”, vagy „ezt a külső builder nem tudja”.
A routing a miénk. Az adatmodell a miénk. Az admin a miénk. A frontend működés a miénk. A regresszió is a mi problémánk.
Ezért egy közös core-nál különösen fontos:
- a verziózott fejlesztés és release-folyamat;
- a visszamérés és regressziós tesztelés;
- a mentések és visszaállíthatóság;
- a tenantok adatainak és beállításainak következetes elkülönítése;
- a teljesítmény valós felhasználói mérése;
- és az, hogy egy központi változtatás ne rontsa el azt, ami már működik.
Ez kevésbé látványos része egy weboldalnak. De hosszú távon sokkal fontosabb, mint hogy egy szerkesztőben hány animáció közül lehet választani.
8. Miért kell folyamatosan fejlődnie egy weboldalplatformnak?
Mert maga a web is folyamatosan változik.
Néhány év alatt teljesen átalakulhat, hogy mit tekintünk jó technikai megoldásnak. Ami tegnap bevett gyakorlat volt, ma lehet felesleges, holnap pedig kifejezetten hátrányos.
Nálunk ezért a platformfejlesztés több irányból érkezik:
- böngésző és frontend: reszponzív működés, navigáció, accessibility, új böngészőviselkedések;
- teljesítmény: LCP, INP, CLS, képkezelés, JavaScript-terhelés és valós RUM adatok;
- SEO: technikai struktúra, canonical URL-ek, sitemap, strukturált adatok;
- AI és keresés: AEO/GEO-szemlélet, géppel értelmezhető tartalmi struktúrák és AI-támogatott elemzések;
- üzleti funkciók: új blokkok, blog, ajánlatkérés, időpontfoglalás és külső integrációk;
- üzemeltetés: biztonság, mentések, kompatibilitás és a közös infrastruktúra fejlesztése.
És itt válik értelmessé igazán a cím.
A weboldal elkészül. A platform nem.
9. Az ügyfélnek ettől még nem kell „WaaS-t” tanulnia
Lehetne a főoldal tetejére nagy betűkkel azt írni, hogy:
„Multi-tenant Website-as-a-Service platform.”
Szakmailag rendben lenne.
Marketing szempontból viszont körülbelül annyit érne, mint egy étlap, amelyen az ebéd helyett a konyhai elszívórendszer műszaki specifikációja szerepel.
Egy kisvállalkozó nem WaaS-t akar venni.
Jó weboldalt akar. Olyat, ami jól néz ki, szerkeszthető, működik telefonon, a Google is értelmezni tudja, nem kell külön tárhelyes és SSL-es problémákat megoldania, és ha elakad, van mögötte valódi ember.
Ezért a Weboldal Bérlés név marad.
A Website-as-a-Service inkább arra jó, hogy szakmailag pontosan meg tudjuk fogalmazni, milyen szolgáltatási modell és technológiai gondolkodás van mögötte.
10. Miért tartjuk fontosnak, hogy saját a platform?
Nem azért, hogy minden mondatban elmondhassuk: „ezt mi programoztuk”.
Hanem azért, mert így amikor valamit másképp szeretnénk megoldani, van lehetőségünk hozzányúlni a rendszer valódi működéséhez.
Ha a képbetöltésen kell változtatni, nem csak egy beállítást keresünk. Ha egy új SEO-réteget akarunk beépíteni, nem feltétlenül egy plugint keresünk hozzá. Ha a navigáció egy adott böngészőben rosszul viselkedik, le tudunk menni addig a kódig, ahol a probléma ténylegesen keletkezik.
Ez szabadság.
És ugyanekkora felelősség.
A kettő együtt adja azt, amit mi saját fejlesztésű Website-as-a-Service platform alatt értünk.
11. Egy mondatban: mi a Weboldal Bérlés szakmailag?
Ha nagyon pontosan akarjuk megfogalmazni:
A Weboldal Bérlés egy saját fejlesztésű, multi-tenant Website-as-a-Service platform kisvállalkozások számára, integrált weboldal-adminisztrációval, technikai háttérrel és szakértői segítséggel.
Ha viszont egy vállalkozónak mondjuk el:
Kapsz egy saját weboldalt, amit tudsz szerkeszteni. Mi pedig folyamatosan fejlesztjük és üzemeltetjük mögötte azt a rendszert, amit neked nem kell.
Talán ez a lényeg.
Nem egy WordPress-oldalt adunk havidíjért. Nem egy külföldi white-label weboldalépítőt értékesítünk tovább. Saját weboldalplatformot építünk és üzemeltetünk, és ehhez szakmai segítséget is adunk.
A weboldal tehát elkészül.
De a fejlődése nem ér véget.
Források
- Mono Solutions Websites-as-a-Service – A Mono Solutions hivatalos oldala a Websites-as-a-Service modellről, különösen kisvállalkozások és digitális szolgáltatók szemszögéből.
- Microsoft Learn Architecting Multi-tenant Applications in Microsoft Azure (2013) – Microsoft szakmai anyag a multi-tenant alkalmazási modellről és annak SaaS-környezetben való használatáról.
- Duda White Label Website Builder – A Duda hivatalos leírása a white-label website builder modellről, amely jó összehasonlítási alap a saját fejlesztésű platform és a külső, átbrandelhető rendszer közötti különbséghez.
- Weboldal Bérlés Mi van a motorháztető alatt? #1 – Így épül fel a Weboldal Bérlés rendszerarchitektúrája (2026) – Saját technikai háttéranyag a Weboldal Bérlés MVC-alapú, multi-tenant architektúrájáról, a közös core-ról és a frontend renderelésről.
A szerzőkről
GYIK
Gyakran ismételt kérdések a Website-as-a-Service és a Weboldal Bérlés működéséről
Rövid válaszok a WaaS modellről, a multi-tenant működésről, valamint a saját platform, a WordPress és a white-label megoldások közötti különbségekről.
A Website-as-a-Service olyan szolgáltatási modell, amelyben a weboldal nem egyszeri, lezárt fejlesztési projektként működik, hanem egy folyamatosan üzemeltetett és fejlesztett platform része. A WaaS nem egységes technikai szabvány, inkább üzleti és technológiai megközelítés.
A két fogalom nagyon közel áll egymáshoz. A „weboldal bérlés” közérthetően azt mondja el, mit kap az ügyfél, a Website-as-a-Service pedig szakmailag azt írja le, hogy a weboldal folyamatos szolgáltatás és platform részeként működik.
Nem. A Weboldal Bérlés saját fejlesztésű rendszer, saját alkalmazásmaggal, adatmodellel, ügyféladminnal és renderelési logikával. Ez nem a WordPress minősítése, hanem egy eltérő architekturális döntés.
A multi-tenant modellben egy közös alkalmazásmag több önálló ügyfélweboldalt szolgál ki. Az egyes weboldalak saját domainnel, tartalommal, képekkel és beállításokkal működnek, miközben a közös platform technikai fejlesztéseit központilag lehet kezelni.
White-label modellnél egy külső szolgáltató kész weboldalépítő platformja jelenik meg a szolgáltató saját márkája alatt. Saját platformnál maga az alkalmazás, az adatmodell és a működés is saját fejlesztés, ezért nagyobb a technikai kontroll, de a fejlesztési és üzemeltetési felelősség is.
Nem azt, hogy a weboldal félkész. Az éles verziónak stabilan kell működnie. A folyamatos fejlődés azt jelenti, hogy a mögöttes platform követi a böngészők, a teljesítményelvárások, a SEO, az AI-alapú keresés, a biztonság és az üzleti funkciók változásait.
Kapcsolódó cikkek
Mi van a motorháztető alatt? #3 - A canonicaltól a foglalási engine-ig: platformszolgáltatások a Weboldal Bérlésben
A frontend csak a Weboldal Bérlés látható rétege. A háttérben canonical URL-ek, sitemap és robots.txt, JSON-LD strukturált adatok, llms.txt és Markdown-kimenetek, consent, űrlapvédelem, Blog, valamint Google Naptárral összekapcsolható időpontfoglalási logika dolgozik ugyanazon tenant- és szolgáltatási rétegekre építve.
Mi van a motorháztető alatt? #2 - A képfeldolgozástól a RUM-ig: performance a Weboldal Bérlésben
A gyors weboldal nem egy PageSpeed-pontszámmal kezdődik, és nem egy cache plugin bekapcsolásával ér véget. A Weboldal Bérlésben a teljesítmény a renderelési, kép-, videó-, asset- és mérési pipeline része: responsive képek, LCP-prioritás, célzott JavaScript, stabil layout és saját RUM együtt adja a rendszert.
Mi van a motorháztető alatt? #1 - Így épül fel a Weboldal Bérlés rendszerarchitektúrája
Ez a sorozat nem arról szól, hogy melyik gombot kell megnyomni az adminban. Megmutatjuk, mi történik mögötte: hogyan épül fel a Weboldal Bérlés saját MVC-alapú, multi-tenant rendszere, hogyan kapcsolódnak egymáshoz a blokkok, variánsok, weboldal-specifikus adatok és a frontend renderelés – és miért nem egy WordPress-telepítésből vagy white-label site builderből áll a szolgáltatás.