Amikor egy cégvezető új WordPress-oldalról dönt, a fejlesztői csapatnál előbb-utóbb mindig előkerül ugyanaz a kérdés. A tartalmat szigorúan felépített mezőkkel vezéreljük, vagy hagyjuk, hogy a szerkesztők szabadon építkezzenek blokkokból? ACF Blocks vagy Gutenberg full site editing? A kérdés nem az, hogy melyik technológia modernebb, hanem az, hogy melyik architektúra fogja éveken keresztül támogatni a vállalkozásod működését és melyik miatt fizetsz később felesleges fejlesztési és karbantartási költségeket. Ki vállal érte felelősséget, amikor két év múlva megérkezik a karbantartási számla?
A döntés mögött konkrét üzleti választás áll, nem technikai divat. Ez határozza meg hosszú távon a weboldal karbantartási költségeit, a márka megjelenésének konzisztenciáját és a marketingcsapat mozgásterét a napi munkában. Valójában tartalmi infrastruktúráról döntünk, nem pluginról, egy jól felépített infrastruktúra pedig hosszú távon megtérül, egy rosszul átgondolt viszont nem.
Az ACF Blocks és a Gutenberg full site editing nem egymást kizáró technológiák, két különböző filozófiát képviselnek, amelyek más-más problémára adnak jó választ. A cikk célja, hogy ezt a döntést üzleti fejjel lehessen végiggondolni, ne technológiai hovatartozás, hanem az adott tartalom valódi igénye alapján.
Miért épp most kell jól dönteni?
A Gutenberg 2018-ban jelent meg és azóta fokozatosan nőtte ki magát egy egyszerű blokkszerkesztőből teljes site editing rendszerré. A 2026. május 20-án megjelent WordPress 7.0 „Armstrong” óta ez már nem egyszerű irányzat, hanem a platform deklarált útja. Ez a verzió nyitotta meg a Gutenberg harmadik fázisát és a mesterséges intelligencia alapjait, az AI Client réteget és az Abilities API-t is beemelte a WordPress magjába.
A teljes képhez azonban hozzátartozik a másik szám is. A blokktémák a valóságban még mindig kisebbségben vannak. Egy 2026 februárjában, 50 000 WordPress-oldalon végzett felmérés szerint (ThemeSniffer) az oldalak nagyjából 82%-át továbbra is klasszikus téma hajtja, miközben a blokktémák használata egy év alatt körülbelül 50%-kal nőtt. A hivatalos irány tehát adott, a piac viszont még nem tart ott. Ez a rendszer a theme.json fájlra épül, amely a design tokeneket, azaz a színpalettát, a tipográfiát és a térközöket egyetlen helyen, kódszinten tárolja, a Site Editor felülete pedig ennek a fájlnak vizuális megjelenítője. Pontosan ez a „hivatalos irány” címke az, ami most sok döntéshozót rossz irányba visz, hiszen az, hogy valami a WordPress alapértelmezett útja lett, még nem jelenti azt, hogy a te oldaladnak is az a jó válasz.
Az ACF ezzel szemben egy teljesen más problémát old meg. Az Advanced Custom Fields plugin lényege, hogy a fejlesztő előre meghatározott mezőket hoz létre egy adott tartalomtípushoz és a szerkesztő ezeket a mezőket tölti ki, nem pedig szabad blokkokat rendezget. A megközelítés adatközpontú, előbb definiáljuk, milyen adatstruktúrára van szükség és csak utána foglalkozunk a megjelenéssel. Az ACF Blocks funkció ezt a logikát hozta be a Gutenberg-szerkesztőbe, vagyis a fejlesztő PHP-sablonokkal renderelt, de ACF-mezőkkel vezérelt blokkokat építhet, natív JavaScript-fejlesztés nélkül.
A technikai különbség, ami mindent meghatároz
A két rendszer közötti legfontosabb technikai eltérés a rendering módja. A natív Gutenberg-blokkok JavaScript alapú React-komponensekként épülnek fel és a szerkesztőben valós idejű, a végeredményt pontosan tükröző előnézetet adnak. Az ACF blokkok ezzel szemben PHP-sablonokból renderelődnek, a szerkesztő pedig alapértelmezetten egy mezőkitöltő űrlapot mutat, amelyet a fejlesztő kapcsolhat át élő előnézetre.
Ennek gyakorlati következménye van a csapat összetételére nézve is. Ha a fejlesztői csapat elsősorban PHP-ban otthonos, ahogy egy tipikus magyar digitális műhelynél gyakran ez a helyzet, az ACF-blokkok építése lényegesen gyorsabb és kevésbé költséges, mint egy egyedi Gutenberg-blokk React-alapú fejlesztése. Egy natív blokk elkészítéséhez nem elég a logika megírása, a teljes stílusozást és a szerkesztőn belüli megjelenítést is kézzel kell felépíteni hozzá, ami komoly többletmunka egy olyan projektnél, ahol amúgy is szoros a határidő. Döntéshozóként ezt egyetlen mondatban érdemes lefordítani, a technológia megválasztása itt közvetlenül fejlesztői órákat, azaz forintot és átfutási időt jelent, nem elvont architektúra-ízlést.
Mikor éri meg az ACF Blocks mellett dönteni?
Az ACF Blocks akkor bizonyul a jobb választásnak, ha a projekt jellege inkább strukturált adatkezelést igényel, mint szabad tartalomszerkesztést. Egy intézményi weboldal fix aloldalakkal, egy komplex termékkatalógus, vagy egy olyan többnyelvű site, ahol a WPML-lel párhuzamosan kell kezelni a mezőket nyelvenként, tipikusan ide tartozik. Ilyen esetekben az a cél, hogy a szerkesztő ne tudjon elrontani semmit, a mezők egyértelműen jelezzék, mit kell kitölteni és a végeredmény garantáltan a márka vizuális elveinek megfelelően jelenjen meg.
Az ACF mellett szól az is, hogy a relációs mezők, vagyis amikor egy tartalomtípus más tartalomtípusokra hivatkozik, jóval kifinomultabbak, mint amit a Gutenberg natívan kínál. Egy olyan oldalnál, ahol a termékek kategóriákhoz, azok pedig gyártókhoz és dokumentumokhoz kapcsolódnak, ez a fajta adatmodellezés az ACF erőssége, nem a blokkszerkesztőé.
Mikor éri meg a Gutenberg és a full site editing mellett dönteni?
A Gutenberg és a full site editing ezzel szemben ott ragyog igazán, ahol a tartalom természete inkább szerkesztői, mint strukturált. Egy blog, egy hírportál jellegű aldomain, vagy egy olyan landing page rendszer, ahol a marketingcsapat gyakran, önállóan épít új oldalakat, sokkal jobban működik natív blokkokkal, mert a szerkesztő azonnal látja, mit csinál,és nem függ minden apró változtatásnál a fejlesztői csapattól.
Az elmúlt két év WordPress-verziói emellett komoly teljesítménybeli és jövőbiztonsági érveket is hoztak a natív megoldás mellé. A theme.json harmadik verziója és a Pattern Overrides funkció, amellyel egy mintaelemet globálisan kezelhetünk úgy, hogy az egyes előfordulásoknál mégis eltérő tartalmat engedünk meg, nem új fejlemény. Mindkettő a 2024 nyarán megjelent WordPress 6.6-tal érkezett. A teljesítménykülönbség pedig mérhető. A WordPress core saját, 2025 novemberében publikált teljesítménymérése szerint a 6.9-es verzióban, alap telepítésen, a blokktéma First Contentful Paint ideje 33,1%-kal, a blokktémák LCP-értéke pedig átlagosan 25%-kal javult. Klasszikus témáknál ugyanez a szám 4% volt. A becsületes olvasat viszont az, hogy ugyanez a verzió a klasszikus témákra is kiterjesztette az igény szerinti blokkstílus-betöltést, ami a tesztoldalakon átlagosan 45%-kal kevesebb CSS-t jelentett. A szakadék tehát szűkül, és a gyakorlatban ritkán az architektúra címkéje dönt, hanem az, hogy mi minden fut még az oldaladon.
Ettől még fontos szempont marad, hiszen az oldalsebesség túlmutat a felhasználói élményen. A Core Web Vitals a Google rangsorolási jelei közé tartozik, nem a legerősebb tényezőként, de mérhető módon. A strukturált tartalom és a tiszta architektúra ma már nem csak a Google miatt számít. Az AI-alapú keresők is ezekből a jelekből értik meg, miről szól egy weboldal, és hogy érdemes-e forrásként hivatkozni rá. Itt ér össze a fejlesztői döntés a láthatósággal. Egy tiszta, jól strukturált, gyors oldal nem csak a látogatónak jó, a Google és az egyre fontosabb AI-alapú keresők számára is könnyebben érthető és megjeleníthető.
A Block Bindings API, ami már két éve halványítja a határvonalat
Érdemes külön kiemelni egy fejlesztést, amely alapjaiban árnyalja a fenti döntési logikát. A Block Bindings API, amely nem 2026-os újdonság (2024 márciusában, a WordPress 6.5-tel érkezett, és a 6.6-ban bővült tovább), lehetővé teszi, hogy egyedi mezőket, köztük ACF-mezőket is, közvetlenül a natív Gutenberg-blokkokhoz kössünk, anélkül hogy egyedi blokkot kellene fejleszteni hozzájuk. A gyakorlatban ez azt jelenti, hogy egy natív bekezdés blokk tartalma egy ACF-mezőből töltődik be, miközben a szerkesztő élményében semmi nem változik a natív blokkokhoz képest. Vagyis aki ma hibrid architektúrát választ, nem kísérletezik, hanem két éve bevált gyakorlatot követ.
Ez a fejlesztés lassan elmossa az éles határvonalat a két rendszer között, és egyre több fejlesztői csapat épít hibrid architektúrát. A gyakorlatban ez legtöbbször úgy néz ki, hogy a fix, intézményi oldalak, mint a főoldal vagy a kapcsolati oldal, ACF Flexible Content mezőkre épülnek, a blogbejegyzések natív Gutenberg-blokkokkal készülnek egy szűk, egyedi blokkokból álló kiegészítő készlettel, a landing page-eket pedig szintén natív blokkokkal, néhány egyedi elemmel egészítik ki. Ez a fajta munkamegosztás minden tartalomtípusnak azt az élményt adja, amire valóban szüksége van. Vagyis a jó válasz ma már ritkán az, hogy „az egyik vagy a másik”, sokkal inkább az, hogy tudatosan, rétegenként osztod el, melyik tartalomtípus melyik rendszeren fut a legjobban.
Tipikus hibák, amikor a döntés elhamarkodott
A leggyakoribb hiba, amikor egy csapat ideológiai alapon dönt a natív Gutenberg mellett egy komplex, erősen strukturált, többnyelvű vállalati oldalnál, csak azért, mert ez a hivatalos irány, és később szembesül azzal, hogy a relációs adatok kezelése vagy a mezőnkénti fordításkezelés jóval nehézkesebb, mint egy jól megtervezett ACF-struktúrával lett volna. A másik gyakori hiba ennek a fordítottja, egyszerű, tartalomközpontú blogoldalakhoz túlbonyolított, egyedi ACF-blokk rendszert építenek, ahol a szerkesztők folyamatosan a fejlesztői csapatra szorulnak egy-egy apró tartalmi változtatás miatt, miközben natív blokkokkal ugyanezt percek alatt önállóan megoldhatnák.
A harmadik tipikus buktató a hosszú távú karbantartás alábecslése. Az egyedi Gutenberg-blokkok React-alapú kódja a WordPress-frissítésekkel együtt változhat, ami rendszeres karbantartási költséget jelent, míg egy jól felépített ACF-struktúra ebből a szempontból stabilabb, cserébe viszont erősebben függ egyetlen plugintól.
Hogy ez a függőség mit jelent a gyakorlatban, arra 2024 ősze adta a legélesebb példát. 2024. október 12-én a WordPress.org, a WP Engine és az Automattic jogvitájának közepén, a plugin-irányelvek 18. pontjára hivatkozva, leforkolta az ACF-et Secure Custom Fields néven és azok az oldalak, amelyek a WordPress.org automatikus frissítéseit használták, gyakorlatilag átkapcsoltak egy másik pluginra. Decemberben bírósági végzés adta vissza a plugin kezelését a WP Engine-nek, a per pedig 2026-ban is folyik. Weboldal nem állt meg emiatt, de rengeteg üzemeltető töltött el egy hetet azzal, hogy kiderítse, mi fut valójában a saját oldalán. Ez az a kockázattípus, amit egy architektúra-döntésnél be kell árazni, nem az, hogy „lassabb-e a plugin”, hanem az, hogy kinek a kezében van a frissítési csatorna.
Mindhárom hiba közös gyökere ugyanaz: valaki a technológiát választotta ki előbb, és csak utána nézte meg, mire is lesz valójában szükség. Pedig fordítva működik jól.
A tízperces teszt, amit érdemes neked is elvégezned
Nem kell architektúra-vitába belemenned ahhoz, hogy megérezd, jó helyen van-e a mostani oldalad. Kérd meg a marketingesedet, hogy a jelenlétedben hozzon létre egy új aloldalt, mondjuk egy egyszerű kampányoldalt szöveggel, képpel és egy űrlappal, és mérd az időt. Ha tíz perc alatt megvan és nem kellett fejlesztőt hívni, a szerkesztői szabadság rendben van. Ha az első lépésnél megakad, vagy azzal kezdi, hogy „ezt a fejlesztőktől kell kérni”, akkor minden apró tartalmi változtatás számlázott fejlesztői óra. Aztán fordítsd meg a tesztet, nyisd meg a legutóbb készült öt aloldalt egymás mellett. Ha ugyanaz a szekció ötféleképpen néz ki, a szabadságot már túl drágán fizeted, ott kontrollra van szükség. Ez a két megfigyelés többet mond a helyes architektúráról, mint bármelyik plugin-összehasonlító táblázat.
A gyakorlati döntési szempont
A legtöbb vállalati projektben ma már nem az a kérdés, hogy ACF-et vagy Gutenberget válasszanak, hanem az, hogy melyik tartalomtípus melyik technológiával működik hosszú távon a legjobban. Ha a cél a kontroll, a konzisztencia és a strukturált adatkezelés, az ACF Blocks az erősebb választás. Ha a cél a szerkesztői szabadság, a gyors iteráció és a natív teljesítmény, a Gutenberg és a full site editing viszi el a pontot. A legtöbb komolyabb vállalati weboldalnál a válasz egyébként nem is vagy-vagy, hanem mindkettő, tudatosan elosztva a projekt különböző rétegei között. Mert, és ez a lényeg, ez nem plugin-választás, hanem tartalmi infrastruktúra-döntés. A technológia mindkét oldalon elérhető. A jól megválasztott architektúra viszont éveken keresztül versenyelőnyt jelent, a rossz döntés pedig ugyanennyi ideig többletköltséget.
És van egy eset, amikor ez az egész döntés nem számít, ha öt-hat aloldalas bemutatkozó oldalról van szó, amihez évente kétszer nyúlsz hozzá. Ott a különbség néhány óra fejlesztés, és bármelyik utat választod, jól jársz, ezzel a kérdéssel foglalkozni inkább időpazarlás, a pénzed máshol térül meg jobban. Ez a döntés akkor kezd valódi pénzt jelenteni, amikor sok tartalomtípusod, több nyelved vagy egy naponta dolgozó marketingcsapatod van. Ha nem ez a helyzet, ezt is meg szoktuk mondani.
Hol jövünk a képbe mi?
A legtöbb csapat el tud készíteni egy WordPress-oldalt akár ACF-en, akár natív blokkokon. A különbség nem a kivitelezésben van, hanem a döntésben, ami megelőzi. Mi azok vagyunk, akik a kód leírása előtt megkérdezik, milyen tartalomtípusaid lesznek, ki fogja szerkeszteni, hány nyelven, mennyire kell önállóan mozognia a marketingesnek és mennyibe kerülhet mindez három év múlva. És ha az derül ki, hogy neked a csendes, hibrid megoldás a jó, vagy hogy egy adott réteghez épp nem az „új és menő” technológia való, ezt őszintén meg is mondjuk, akkor is, ha ez nekünk kevesebb fejlesztést jelent.
Fontos ugyanis látni, hogy a CMS-architektúra önmagában ma már nem versenyelőny. Egy jól megválasztott ACF- vagy Gutenberg-struktúra csak egy réteg egy nagyobb rendszerben. Hiába tökéletes a fejlesztői döntés, ha nincs mögötte üzleti stratégia, nincs hozzá jó tartalom és kommunikáció, vagy ha az oldalt a modern, AI-alapú keresők nem értik meg, akkor csak egy gyors, szép, de láthatatlan oldalad lesz. A technológia, a tartalom és a kereshetőség egyetlen rendszert alkot.
A W5labs ezért nem egyszerűen weboldalt fejleszt. Olyan digitális rendszereket tervezünk és építünk, amelyekre a vállalkozások növekedése épül, a stratégia megtervezi a rendszert, a kreatív kialakítja a kommunikációját, a fejlesztés felépíti, a support pedig működésben tartja és védi. A WordPress-architektúra kérdése ennek a rendszernek csak az egyik, bár fontos, rétege. Az pedig, hogy a WordPress 7.0 óta maga a platform is kapott gépi olvasásra szánt réteget (Abilities API), csak megerősíti a lényeget, a weboldalad ma két közönségnek épül, embernek és gépnek egyszerre.
Ha új oldal előtt állsz, vagy csak nem vagy biztos benne, hogy a jelenlegi felépítésed téged szolgál-e, nézzük végig együtt, mennyire támogatja a mostani weboldalad, tartalmad és digitális jelenléted az üzleti növekedést, és mennyire látható a modern AI-keresők számára. Nem egyszerűen weboldalakat fejlesztünk, hanem digitális növekedési rendszereket építünk, amelyek hosszú távon is versenyelőnyt jelentenek.
