A „WordPress vagy egyedi fejlesztés” döntést a legtöbb helyen technológiai kérdésként teszik fel, pedig üzemeltetési kérdés. Nem az a lényeg, melyik rendszer „jobb”, hanem az, hogy a következő három-öt évben ki fog hozzányúlni, milyen gyakran, és mi történik akkor, ha az az ember vagy az a cég kiesik. Ez a cikk ebből a nézőpontból járja körül a témát.
Mikor jó választás a WordPress, és mikor az egyedi fejlesztés?
A WordPress akkor jó választás, ha a webhely fő feladata a tartalom közlése, a bizalomépítés és az érdeklődők gyűjtése, és a napi tartalomkezelést nem fejlesztő végzi. Egyedi fejlesztés akkor indokolt, ha maga a webhely a termék: saját üzleti logika, sok külső integráció, összetett jogosultságkezelés vagy szokatlan adatmodell jellemzi.
A gyakorlatban ez a következőket jelenti. WordPress felé billen a mérleg, ha a webhelyen leginkább szolgáltatásoldalak, referenciák, blog, űrlapok és esetleg egy egyszerűbb webshop van, ha a marketinges önállóan akar új aloldalt létrehozni, és ha fontos, hogy a projekt bármikor átadható legyen egy másik szakembernek.
Egyedi fejlesztés felé billen, ha a rendszer több lépcsős kalkulációt, saját ütemezést, ERP- vagy raktárrendszer-kapcsolatot, ügyfélspecifikus árazást vagy szigorú adatvédelmi elkülönítést kíván, illetve ha a felhasználói felület annyira eltér a megszokottól, hogy a dobozos megoldást amúgy is szét kellene szedni.
Saját tapasztalat: a legtöbb kis- és középvállalati webhely nem azért kap egyedi fejlesztést, mert az üzleti logika megkívánja, hanem mert a döntés pillanatában senki nem vette számba, hány funkció tér el ténylegesen a szokásostól. Ha ez a lista három-négy tételnél rövidebb, a dobozos irány jó eséllyel elegendő.
Miből áll valójában a két megoldás költségszerkezete?
Mindkét útnál a teljes ráfordítás nagyobb része nem az induláskor keletkezik, hanem az üzemeltetés éveiben. Négy tétel van: bevezetés, üzemeltetés, változtatás és kilépés, és a két platform ezek arányában tér el, nem abban, hogy „olcsó” vagy „drága”.
- Bevezetés: WordPressnél a kész sablonok és bővítmények miatt rövidebb az út az első éles verzióig. Egyedi fejlesztésnél a specifikáció, a tervezés és a tesztelés önmagában komoly szakasz.
- Üzemeltetés: WordPressnél visszatérő tétel a mag, a sablon és a bővítmények frissítése, valamint a fizetős kiegészítők licenceinek megújítása. Egyedi fejlesztésnél a keretrendszer és a függőségek (például npm- vagy Composer-csomagok) karbantartása, illetve a futtatókörnyezet gondozása jelent folyamatos munkát.
- Változtatás: ez a legkevésbé tervezett tétel. WordPressnél egy új aloldal vagy egy szövegmódosítás jellemzően fejlesztő nélkül megoldható. Egyedi rendszernél minden apró módosítás fejlesztői időt igényel, hacsak nem építettek bele admin felületet, ami viszont a bevezetés terjedelmét növeli.
- Kilépés: mennyibe kerül elhagyni a megoldást. Itt a mérőszám nem összeg, hanem idő: hány nap alatt tud egy új szakember dolgozni a kódon dokumentáció nélkül.
A rejtett tétel az átfutási idő. Ha egy kampányoldal két hét helyett két hónap alatt készül el, az elmaradt megkeresések is a döntés következményei.
Melyiket könnyebb karbantartani?
A WordPress karbantartása gyakoribb, de kisebb egységekben és jól dokumentált módon zajlik. Az egyedi fejlesztés ritkábban igényel beavatkozást, viszont amikor igen, az mélyebb szaktudást kíván, és kevesebben tudják elvégezni.
Hivatalos információ: a WordPress fejlesztői dokumentációja szerint a mag rendszeres kiadási ciklusban jelenik meg, és a biztonsági javítások külön, soron kívül is érkezhetnek. Ez azt jelenti, hogy a frissítés nem opcionális feladat, hanem menetrend.
Egy működő WordPress-karbantartás minimum ezekből áll:
- Automatikus mentés, ellenőrzött visszaállítási próbával (a mentés csak akkor mentés, ha egyszer már visszaállítottad).
- Staging környezet, ahol a frissítés előbb lefut, mint élesben.
- Bővítménylista időszakos átnézése: mi az, ami már nem kap frissítést, mi az, amit senki nem használ.
- Adminfiókok és jogosultságok felülvizsgálata, kétlépcsős azonosítás.
- A fájlszerkesztő kikapcsolása a wp-config.php fájlban:
define( 'DISALLOW_FILE_EDIT', true );
Egyedi fejlesztésnél ugyanez a lista a függőségek sérülékenységi vizsgálatával, a futtatókörnyezet verziókövetésével és az automatikus tesztekkel egészül ki. Ha nincs teszt és nincs dokumentáció, a karbantarthatóság gyakorlatilag egyetlen ember fejében lakik.
Melyik lesz gyorsabb: a WordPress vagy az egyedi fejlesztés?
A sebességet nem a platform neve dönti el, hanem a felépítés. Egy jól összerakott WordPress gyorsabb lehet egy rosszul megírt egyedi alkalmazásnál, és fordítva: az egyedi fejlesztés csak akkor gyors, ha valaki tudatosan optimalizálja.
Hivatalos információ: a Google dokumentációja szerint az oldalélmény jelei (köztük a Core Web Vitals mérőszámok: LCP, INP, CLS) szerepet játszanak a keresési megjelenésben, de nem írják felül a tartalom relevanciáját. Vagyis a gyorsaság szükséges higiénia, nem önmagában rangsorolási csodafegyver.
A WordPress-oldalak lassulásának tipikus okai a tapasztalat szerint ebben a sorrendben jelentkeznek: túl sok párhuzamosan futó bővítmény, nehéz vizuális szerkesztő, optimalizálatlan képek, gyenge tárhely, valamint a gyorsítótárazás hiánya vagy rossz beállítása. Ezek mindegyike orvosolható, de csak akkor, ha valaki foglalkozik vele.
Egyedi fejlesztésnél a kockázat máshol van: a böngészőben futtatott, kliensoldali renderelésre épülő felületek gyakran szép első benyomást adnak, de nagy JavaScript-csomaggal és gyenge interaktivitási mutatóval járnak. Ha egyedi irányba mész, kérd el a fejlesztőtől, hogy szerveroldali rendereléssel vagy előre generált HTML-lel dolgozzon.
Hogyan bővíthető hosszú távon a két megoldás?
A bővíthetőség valódi mérőszáma nem az, hogy elvileg mi építhető meg, hanem az, hogy egy új funkció hány nap alatt kerül élesbe, és hány embertől függ.
A WordPress bővítése három szinten történik: kész bővítménnyel, egyedi bővítménnyel vagy sablonkódból, illetve a beépített REST API-n keresztül, amivel akár fejetlen (headless) felépítés is megvalósítható. Az egyedi tartalomtípusok és mezők használata sokkal stabilabb alap, mint mindent oldalépítővel összekattintani.
Egyedi fejlesztésnél elvileg bármi megvalósítható, gyakorlatilag viszont minden apróságot meg is kell írni: jogosultságkezelést, űrlapkezelést, médiakönyvtárat, mentést, adminfelületet. Ezek dobozos rendszerben adottak. Szakmai feltételezés: a legtöbb túltervezett projekt ott bukik el, hogy az egyedi rendszerbe utólag kellett visszaépíteni azt a kényelmet, amit egy CMS alapból ad.
Milyen kockázatokat vállalsz az egyik és a másik úton?
WordPressnél a fő kockázat a bővítménylánc: elhagyott, frissítetlen vagy sérülékeny kiegészítők. Egyedi fejlesztésnél a fő kockázat a kulcsember-függés: dokumentálatlan kód, amit rajta kívül senki nem ért.
Hivatalos információ: a WordPress-ökoszisztéma biztonsági jelentései (például a Patchstack és a Wordfence éves összesítései) évek óta azt mutatják, hogy a bejelentett sérülékenységek túlnyomó többsége nem a magot, hanem a bővítményeket és sablonokat érinti. Ebből az következik, hogy a kockázatot nem a platform elhagyásával, hanem a bővítmények számának szigorú korlátozásával lehet a leghatékonyabban csökkenteni.
A másik oldalon az egyedi fejlesztés jellemző kockázatai:
- a kódot egyetlen fejlesztő vagy egyetlen cég ismeri, átadási dokumentáció nélkül,
- a használt keretrendszer néhány év alatt kifut a támogatásból, és a frissítés újraírással ér fel,
- nincs automatikus teszt, így minden módosítás után kézzel kell mindent végignézni,
- a forráskód és a szerverhozzáférés nincs a megrendelő birtokában.
Ez utóbbi a legfontosabb: szerződéskötéskor rögzítsd, hogy a forráskód, a tárhely, a domain és a verziókövető rendszer hozzáférése a tiéd. Ez a pont mindkét úton érvényes.
Hogyan hat a döntés az AI-keresőkben való megjelenésre?
Az AI-válaszmotorok szempontjából a platform önmagában semleges. Ami számít: kap-e a robot értelmezhető HTML-t a szerverről, stabilak-e az URL-ek, van-e strukturált adat, és van-e egyértelmű, idézhető válasz a szövegben.
A kockázat inkább az egyedi, kliensoldalon renderelő felületeknél jelentkezik: ha a tartalom csak JavaScript lefutása után áll össze, egyes gyűjtőrobotok kevesebbet látnak belőle. Ez nem elméleti probléma, de nem is automatikus katasztrófa, mert a nagy keresők renderelnek. A biztonságos irány így is a szerveroldali HTML.
Ellenőrizd ezeket, függetlenül attól, melyik utat választod:
- A robots.txt engedi-e a releváns robotokat, például:
User-agent: GPTBotésAllow: /, illetve a Google-Extended kezelése. (Ez üzleti döntés is: van, aki tudatosan tiltja.) - Van-e alap strukturált adat, például:
{"@context":"https://schema.org","@type":"LocalBusiness","name":"Cégnév","url":"https://pelda.hu"} - Minden fontos aloldalnak van-e önálló, beszédes URL-je, és megmarad-e átalakításkor átirányítással.
- A szolgáltatásoldalak elején szerepel-e két-három mondatos, önmagában is idézhető válasz.
Ez nem garantál AI-megjelenést, viszont hiányuk jó eséllyel akadályozza.
Hogyan dönts lépésről lépésre?
Írd össze az eltéréseket a dobozos működéstől, és a lista hossza dönt. Ez néhány óra munka, és többet ér minden platformvitánál.
- Sorold fel a webhely feladatait üzleti nyelven (nem funkciólistaként): mit kell tudnia, hogy pénzt hozzon.
- Jelöld meg, melyik feladat oldható meg bevett CMS-eszközzel, és melyikhez kell saját logika.
- Számold meg, hány tétel maradt a második csoportban. Három-négy alatt a dobozos irány jellemzően reális.
- Nézd meg, ki fogja szerkeszteni a tartalmat hetente, és milyen technikai tudással.
- Tisztázd az integrációkat: van-e hozzájuk hivatalos API, vagy fájlcserével kell dolgozni.
- Kérdezd meg, ki veszi át a rendszert, ha a fejlesztő nem elérhető, és mennyi idő alatt.
- Rögzítsd szerződésben a forráskódot, a hozzáféréseket, a mentési rendet és a dokumentáció elvárt szintjét.
Rövid ellenőrzőlista induláshoz, mindkét úton: verziókövetés, staging környezet, automatikus mentés visszaállítási próbával, SSL, mérés (analitika és Search Console), sebességmérés valós felhasználói adatból, átirányítási terv a régi URL-ekhez, és egy írásos lista arról, ki mit adminisztrálhat.
Források és további olvasnivalók
- Google Search Central dokumentáció (indexelés, strukturált adat, oldalélmény)
- web.dev: Core Web Vitals dokumentáció
- Schema.org szótár
- W3C: HTML és WCAG akadálymentesítési irányelvek
- WordPress Developer Handbook és WordPress kiadási dokumentáció
- OWASP Top 10 webalkalmazás-biztonsági lista
- Patchstack és Wordfence éves biztonsági jelentések
- OpenAI platform dokumentáció (GPTBot gyűjtőrobot kezelése)
- Anthropic támogatási dokumentáció (ClaudeBot gyűjtőrobot kezelése)
- W3Techs tartalomkezelő rendszerek használati statisztikája
- A platformválasztás következménye nem az induláskor, hanem az üzemeltetés éveiben látszik meg.
- A sebességet nem a rendszer neve dönti el, hanem a felépítés, a bővítmények száma és a képkezelés.
- WordPressnél a legnagyobb kockázat az elhagyott vagy sérülékeny bővítmény, egyedi fejlesztésnél a kulcsember-függés.
- Az AI-válaszmotorok szempontjából a szerveroldali HTML, a stabil URL-szerkezet és a strukturált adat számít, nem a platform.
- Döntés előtt írd össze, hány funkció tér el a dobozos megoldástól: ez a lista dönti el a kérdést, nem az ízlés.
Gyakori kérdések
Kisebb szolgáltató cégnek mindig a WordPress a jó választás?
Nem mindig, de a legtöbb esetben elegendő. Ha a webhely feladata a szolgáltatások bemutatása, referenciák közlése és érdeklődők gyűjtése, a dobozos irány gyorsabban élesedik és önállóan szerkeszthető. Akkor érdemes elgondolkodni az egyedi fejlesztésen, ha az üzleti logika (kalkuláció, időpontfoglalás összetett szabályokkal, külső rendszerkapcsolat) tényleg eltér a szokásostól.
Igaz, hogy a WordPress lassú?
Önmagában nem. A lassulás jellemzően a sok párhuzamos bővítményből, a nehéz oldalépítőből, az optimalizálatlan képekből és a gyenge tárhelyből jön. Ezek mind kezelhetők. Egy takarékosan felépített WordPress jó eséllyel megfelel a Core Web Vitals elvárásoknak, míg egy rosszul megírt egyedi alkalmazás könnyen elbukhat rajtuk.
Utólag át lehet állni WordPressről egyedi fejlesztésre, vagy fordítva?
Igen, de a költség nagy része nem a kódban van, hanem a tartalom átköltöztetésében és az URL-szerkezet megőrzésében. Ha átállsz, készíts teljes URL-leltárt, és minden régi címről állíts be 301-es átirányítást a legpontosabb új megfelelőre. Ennek elmulasztása jellemzően látható forgalomeséssel jár.
Melyik biztonságosabb?
Egyik sem eleve biztonságos vagy sérülékeny. A WordPressnél a sérülékenységek túlnyomó része a bővítményekhez és sablonokhoz kötődik, ezért a legjobb védekezés a bővítmények számának szigorú korlátozása, a rendszeres frissítés és a kétlépcsős azonosítás. Egyedi fejlesztésnél a függőségek elavulása és a hiányzó kódfelülvizsgálat a tipikus gyenge pont.
Fejetlen (headless) WordPress megoldás lehet a kettő között?
Lehet, ha van hozzá kapacitás. Így a szerkesztők a megszokott felületen dolgoznak, a megjelenítés viszont egyedi. Cserébe két rendszert kell üzemeltetni, és a karbantartás inkább az egyedi fejlesztés terheihez hasonlít. Kisebb csapatnál ez ritkán éri meg, nagyobb tartalommennyiségnél viszont értelmes köztes út.
Számít az AI-keresők szempontjából, hogy melyiket választom?
Közvetlenül nem. A gyűjtőrobotok a szerverről kapott HTML-t, a strukturált adatot és a stabil URL-eket értékelik, nem a mögötte lévő rendszert. A gyakorlati különbség ott jelentkezik, ha egy egyedi felület kizárólag kliensoldalon rendereli a tartalmat: ilyenkor kérj szerveroldali renderelést vagy előre generált HTML-t.
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.