Headless CMS: ki tölti fel a tartalmat, ha nem a fejlesztő?
Nemrég belefutottam egy posztba, ami ezzel a kérdéssel indított: nálad ki tölti fel az új tartalmakat a weboldalra, a marketinges csapat, vagy mindig a fejlesztőt hívjátok? A mögötte lévő cikk WordPress-környezetben járja körül a témát, és az ACF-mezők meg a Gutenberg blokkszerkesztő között választat.
A kiindulóponttal teljesen egyetértek. Tényleg sokat elárul az oldaladról, hogy egy új kampányoldalhoz kell-e fejlesztő. Csak épp a felkínált két válasz egy olyan világban létezik, ahol a weboldal WordPressen fut. Mi nem ott dolgozunk, és azt látjuk, hogy ma már van egy harmadik válasz is: a tartalmat az AI tölti fel a szövegíró promptja alapján, közvetlenül a tartalomkezelőbe.
Az igazi kérdés nem a szerkesztőfelület
Az ACF és a Gutenberg vitája mindig ugyanoda fut ki: kontroll vagy szabadság. A szigorúan definiált mezőknél a szerkesztő nem tud elrontani semmit, cserébe minden új elemhez fejlesztő kell. A szabad blokkszerkesztőnél a marketinges bármit összerak, cserébe fél év múlva ugyanaz a szekció ötféleképpen néz ki az oldalon.
Mindkét fájdalom valódi. Döntéshozóként viszont nem az a kérdés, melyik plugin nyer, hanem az, hogy hány fejlesztői órán múlik a tartalmad. Ha egy termékoldal szövegcseréje ticketet és két nap átfutást jelent, akkor nem a marketingesed lassú, hanem a rendszer, amiben dolgozik.
Mit jelent ugyanez egy modern frontend stacken?
Nálunk a weboldalak React alapú frontendre és headless CMS-re épülnek. A headless annyit tesz, hogy a tartalom és a megjelenés külön él: a tartalomkezelőben adatok vannak (cím, szöveg, kép, mező), a megjelenítést pedig a frontend kódja végzi. A fenti dilemma ettől nem tűnik el, csak máshogy oldódik meg.
Úgy érdemes elképzelni, mintha legóznál. A blokkok nem a szerkesztőfelületen születnek, hanem a designrendszerben: mindegyik egy megírt komponens, adott formával és adott színnel, benne a márka tipográfiájával és térközeivel. Ahogy a legónál is előre adott, milyen elemek és milyen színek közül választhatsz, itt is ez a helyzet. Az aloldalaidat ezekből az elemekből rakod össze, a sorrend a tiéd, a márka szabályai viszont nem alku tárgyai. Így az a kolléga sem tud kilépni a márkakönyvből, aki lelkesedésből designernek képzeli magát: ugyanabból a szekcióból nem tud ötféle változat keletkezni. Ez a kontroll és a szabadság közötti választás feloldása, nem félúton megkötött kompromisszum.
Van ennek egy mellékhatása, ami most vált igazán fontossá. Ha a tartalom strukturált adat, akkor gépileg is olvasható és írható. Egy felületen keresztül lekérdezhető, milyen cikkek vannak fent, milyen mezőket vár egy blogbejegyzés, milyen blokkokból épülhet fel egy aloldal. Erre épül a harmadik válasz.
Félreértés ne essék, a WordPress nem rossz eszköz. Egy bemutatkozó oldalhoz vagy egy egyszerű bloghoz tökéletesen megteszi, és a vállalati WordPress-projektekről mi is írtunk korábban. A különbség ott kezd pénzben látszani, ahol sok tartalomtípus, több nyelv vagy napi tartalmi munka van. Arról, hogy mikor indokolt egyáltalán egyedi fejlesztés a sablon helyett, külön írtunk a sablonok és az egyedi webalkalmazások különbségéről szóló cikkben.
A harmadik válasz: az AI tölti fel a tartalmat
Az elmúlt másfél évben megjelent egy szabvány, ami pontosan erről szól, csak nem így hívják: MCP, vagyis Model Context Protocol. Az Anthropic tette közzé 2024 végén, mostanra a nagyobb AI-eszközök java része érti.
Mi az az MCP?
Szabványos csatlakozó az AI és a saját rendszereid között. Anélkül minden eszközhöz külön integrációt kellene fejlesztetni, ezzel viszont egyszer beköti a fejlesztő, és onnantól az asszisztens látja, milyen tartalomtípusaid vannak, milyen mezőket kell kitölteni, és mi van már fent az oldaladon.
Ha a tartalomkezelőd MCP-n keresztül elérhető, az asszisztens nagyjából ugyanazt látja, amit a szerkesztőd az admin felületen. Innentől a "töltsd fel" lépés kiesik a folyamatból.
A gyakorlatban ez így néz ki. A tartalom emberi fejjel születik meg: te mondod meg, mi az üzenet, milyen példák kerüljenek bele, mik a valódi számok, milyen hangon szólaljon meg a céged. Az AI ezután nem egy dokumentumot ad vissza, amit valakinek be kell másolnia. Létrehozza a cikket a megfelelő blokkokkal, megírja a meta mezőket, belinkeli a korábbi releváns cikkeket, legenerálja és feltölti a borítóképet, elkészíti a gyakori kérdéseket strukturált adatként. Piszkozatként. Utána jön egy ember, elolvassa, és vagy publikálja, vagy visszadobja.
Ez a különbség a "használok AI-t szövegíráshoz" és a bekötött AI között. Az első spórol egy órát az íráson. A második kiveszi a folyamatból az egész kattingatós részt: a blokkok összerakását, a képfeltöltést, a méretezést, a meta mezőket, a belső linkeket.
Így működik ez nálunk, ezen a blogon
Nem elméletben mondom. Ez a cikk is így került fel.
A blogunkon van 119 régi bejegyzés, amit korábban egy külsős szolgáltatás gyártott, napi tempóban. Kattintást gyakorlatilag nem hozott: a keresőből érkező forgalom 95 százaléka a saját márkanevünkre jött. Tavasszal leállítottuk, és helyette összeraktunk egy saját folyamatot.
Hetente kétszer elindul egy ütemezett AI-futás. Megnézi a Search Console friss adatait, összeveti a tartalomstratégiánkkal, és eldönti, hogy új cikk kell-e, vagy inkább egy meglévőt érdemes feljavítani. Megírja a szöveget, létrehozza a cikket a tartalomkezelőben, generál hozzá borítóképet, kitölti a meta mezőket, belinkel két-három korábbi cikket és a kapcsolódó szolgáltatásoldalt. Piszkozatként áll meg, publikálni ember publikál.
Ennél a cikknél annyi a különbség, hogy a téma egy Facebook-posztból jött, és a véleményt is én diktáltam bele. A többi lépés ugyanaz volt.
A látványos rész egyébként nem az írás. Az írásban ma már senki nem lepődik meg. A látványos az, hogy a tartalom pontosan abba a szerkezetbe kerül, amit a fejlesztőink megterveztek, és nem kell utána senkinek megigazítania.
A blogcikk ebből a legszelídebb eset
Egy cikk viszonylag ártalmatlan tartalom. Az igazi kérdés a kampányoldalaknál dől el, mert ott szokott elfogyni a türelem: indul egy hirdetés, kellene hozzá egy landing page csütörtökre, a fejlesztőknek meg tele a naptáruk.
Ugyanez a logika viszont ott is működik, ha az oldalad blokk-készletre épül. A hero, az árazási kártyák, a lépéssoros folyamatábra, a kiemelt dobozok, a gyakori kérdések mind kész, márkahelyes komponensek. Egy új kampányoldal ilyenkor inkább összeállítás, mint fejlesztés: az AI megírja a szövegeket, kiválasztja és sorba rakja a blokkokat, létrehozza az oldalt piszkozatként, a marketinges pedig az admin felületen csiszol rajta és élesíti.
Egy dolgot érdemes hozzátenni. Minél nagyobb üzleti tétje van egy oldalnak, annál többet ér, ha ember is végignézi. Egy blogcikkben egy pontatlan félmondat kellemetlen, egy termékoldalon egy rosszul megfogalmazott ígéret pénzbe kerül.
Mit nyersz vele, és mikor ne csináld
Nálunk egy kész szöveg feltöltése blokkokkal, képekkel, meta mezőkkel, belső linkekkel korábban félóra-óra kattintgatás volt cikkenként. Ma ez pár perc olvasás és egy jóváhagyás. Aki hetente egy tartalmat tesz ki, annak ez néhány óra havonta, aki naponta dolgozik tartalommal, annak jóval több. Az időnél viszont többet ér, hogy a marketinges nem a fejlesztő naptárára vár, ha eszébe jut egy kampányoldal.
Ettől még nem minden cégnek való, és ezt jobb az elején tisztázni:
Ha a weboldalad öt aloldalból áll, és évente kétszer nyúlsz hozzá, ne bonyolítsd. Ott ez a kérdés nem termel megtakarítást.
Ha nincs designrendszer és nincs rendes blokk-készlet, az AI-nak nincs miből építkeznie. Előbb a rendszer, utána az automatizálás.
Ha nincs, aki jóváhagyja, ne kapcsold be. Az átolvasás nélküli publikálás márkakockázat, a Google pedig pontosan a tömegben gyártott, érték nélküli tartalmat bünteti.
Ha a tartalomkezelődben nincs piszkozat és verziótörténet, előbb az legyen meg. Visszavonhatóság nélkül semmilyen automatizálást nem érdemes élesíteni.
Mit kérdezz a fejlesztődtől, mielőtt aláírod a következő ajánlatot
Nem kell architektúra-vitába belemenned hozzá. Négy kérdés elég:
Írható-e a tartalom programozott felületen keresztül, vagy csak kézzel, az admin felületen?
Kaphat-e a gépi felhasználó saját, korlátozott jogosultságú kulcsot, amit bármikor visszavonhatunk?
Van-e piszkozat és verziótörténet minden tartalomtípuson?
Dokumentált-e, milyen blokkokból épülhet fel egy oldal, és melyik mit vár?
Ha mind a négyre igen a válasz, a weboldalad akár ma készen áll erre. Ha nem, az sem tragédia, csak kerüljön fel a következő fejlesztési kör listájára.
Mi egyedi weboldalakat és webalkalmazásokat építünk modern frontend stacken, headless tartalomkezelővel, és ha kéred, gépi hozzáféréssel az AI-nak. Ha most állsz weboldal előtt, vagy csak elfáradtál abban, hogy minden szövegmódosításhoz fejlesztőt kell hívnod, írj nekünk, és megnézzük, hol tart a te rendszered.
Gyakori kérdések
Mi az az MCP, és miért érdekes ez egy cégvezetőnek?
Az MCP egy szabvány arra, hogy egy AI-asszisztens biztonságosan használni tudja a céged rendszereit, például a weboldalad tartalomkezelőjét. Cégvezetőként annyit érdemes tudni róla, hogy ezzel a tartalomfeltöltés kézi munkája kiesik a folyamatból: az AI oda írja a szöveget, a képet és a meta adatokat, ahová eddig egy ember kattintgatta be őket.
Nem lesz ettől generikus, sablonos AI-szöveg a blogunk?
Attól függ, mit adsz be neki. Az irány, a vélemény, a példák és a valódi számok tőletek jönnek, az AI ezt önti formába és teszi a helyére. Nálunk minden cikk piszkozatként áll meg, és ember dönt arról, hogy kimehet-e. Ha ez a jóváhagyási lépés kimarad, tényleg sablonos szöveg lesz belőle.
Bünteti a Google az AI-val készült tartalmat?
Az AI használata önmagában nem büntetett. A Google irányelvei a keresési találatok manipulálására tömegben gyártott, érték nélküli tartalmat célozzák, függetlenül attól, hogy ember vagy gép írta. Egy szakértői véleményt, valódi tapasztalatot és konkrétumokat tartalmazó cikknél nem az a kérdés, milyen eszközzel készült.
WordPressen is működik ez?
Elvben igen, a WordPressnek is van API-ja, és léteznek hozzá MCP-megoldások. A gyakorlati különbség a tartalom szerkezetében van: ha az oldalad egyetlen nagy HTML-mezőben tárolja a szöveget, az AI is csak HTML-masszát tud beletölteni. Ha viszont jól definiált blokkokból és mezőkből épül, akkor pontosan abba a formába kerül a tartalom, amit a designrendszer megenged.
Mennyi idő ezt bevezetni egy meglévő weboldalon?
Ha a weboldal már headless tartalomkezelőn fut, jól definiált blokkokkal, akkor a gépi hozzáférés bekötése napokban mérhető munka. Ha viszont nincs mögötte blokk-készlet és designrendszer, akkor előbb azt kell felépíteni, és az már fejlesztési projekt. Ilyenkor jellemzően a következő újratervezésnél érdemes betervezni.
Ki felel a tartalomért, ha az AI tölti fel?
Ugyanaz, aki eddig: ti. Ezért ragaszkodunk ahhoz, hogy a gépi felhasználónak csak piszkozat létrehozására legyen joga, és a publikálás emberi döntés maradjon. A kulcs bármikor visszavonható, a verziótörténetből pedig minden változás visszakövethető.