Útmutató · Weboldal CMS-sel vagy anélkül
Weboldal CMS-sel vagy anélkül? Biztonság, karbantartás, sebesség – és amit az MI-ügynökök megváltoztatnak
A CMS akkor éri meg, ha technikai tudás nélküli emberek rendszeresen módosítják a tartalmat – egyébként a CMS nélküli weboldal a karcsúbb választás
CMS-re akkor van szükséged, ha több ember programozói tudás nélkül maga gondozza a tartalmat, vagy ha webshop, bejelentkezés vagy tagi terület kell. CMS nélkül – vagyis statikus weboldalként – akkor jársz jobban, ha ritkán változik valami, vagy ha a módosítások mindig egy fejlesztőn vagy egy MI-ügynökön keresztül futnak a te jóváhagyásoddal. Cserébe elmarad az adatbázis, a bővítmények és a kötelező frissítés. Az MI elmozdította a határt: a CMS régi fő érvét, hogy „a laikusok is tudják írni a szöveget”, kis weboldalaknál egyre inkább egy ügynök váltja ki. A CMS új érve a kontroll: szerepkörök, piszkozatok, verziók és egy felület, amelyen keresztül az ügynök csak azt teheti, amit megengedsz neki.
Amit a döntés előtt tudnod kell
- A WordPressnél a biztonsági kockázat szinte teljes egészében a bővítményekben van, nem a rendszermagban. A WordPress-ökoszisztémában 2025-ben jelentett 11 334 sebezhetőségből 91 % bővítményekben, 6 pedig a rendszermagban volt.
- A betöltési időt a beállítás dönti el, nem a rendszer. A Web Almanac 2025 szerint mobilon a TYPO3-weboldalak 79 %-a teljesíti a Core Web Vitals küszöbeit, a WordPress-oldalaknak viszont csak 45 %-a – pedig mindkettő CMS.
- Egy statikus weboldal kiszolgálóján semmi nem avul el, ha egy évig senki nem törődik vele – egy frissítések nélküli WordPressnél a kockázat hónapról hónapra nő. Ami elavul, az az eszközkészlet, amivel a statikus oldal épül.
- Az MI-ügynökök mindkét építésmódot gondozni tudják – CMS-nél a felületen keresztül, statikus oldalnál közvetlenül a kódban. A lényeg, hogy minden változtatás átmenjen a te jóváhagyásodon, mielőtt élesbe kerül.
- A felületet a választás előtt teszteld. A képek, a SEO-mezők, a nyelvi változatok és az oldalszerkesztőkkel – például a Bricksszel – készült oldalak azok a pontok, ahol az ügynökök a gyakorlatban elakadnak.
A döntés négy kérdésben
Hogy a weboldaladnak kell-e CMS, azt négy kérdés dönti el – ebben a sorrendben, mert mindegyik feleslegessé teheti a következőt.
- Kell-e kiszolgálói logikát igénylő funkció? A kosár, a készlet, a bejelentkezés és a tagi terület olyan rendszert igényel, amely minden lekérésnél számol. Az egyes funkciók, például az időpontfoglalás, statikus weboldalon is megoldhatók beágyazott külső szolgáltatással – a kiszolgálói logika ilyenkor annál a szolgáltatónál van. Ha ennél többre van szükséged, a CMS kérdése fel sem merül, csak az, hogy melyik rendszer legyen – egy webshoprendszer, például a Shopify, vagy egy CMS a megfelelő bővítménnyel.
- Ki módosítja a tartalmat? Ha technikai tudás nélküli munkatársak írják rendszeresen a híreket, az álláshirdetéseket vagy a termékszövegeket, a CMS a jó választás. A munkájuk előnézettel, piszkozatokkal és jogosultságokkal működő felületen folyik.
- Milyen gyakran változik valami? Egy weboldal, amelyen évente két-három alkalommal módosítanak, nem igényel olyan szerkesztőfelületet, amelyet egész évben karban kell tartani. Ha havonta többször változik valami, de mindig ugyanazon a technikailag felkészült személyen vagy egy MI-ügynökön keresztül, elég egy statikus weboldal tiszta jóváhagyási folyamattal.
- Ki tartja naprakészen a technikát három év múlva? Ezt a kérdést szívesen átugorják, és évekkel később áll bosszút. A felelős nélküli CMS biztonsági kockázattá válik. Az a statikus weboldal, amelyet csak egy korábbi gyakornok tudott építeni, zsákutca lesz. Ha az őszinte válasz az, hogy „senki”, akkor gyakran egy előfizetéses, bérelt rendszer a legésszerűbb megoldás.
Négy építésmód közvetlen összehasonlításban
A „CMS-sel vagy anélkül” mögött a gyakorlatban négy építésmód áll. Sok kisebb cégnek a két középső valamelyike a legjobb válasz: a bérelt rendszer vagy a szerkesztőfelülettel kiegészített statikus weboldal.
- Saját kiszolgálón futó CMS: a szoftver a te kiszolgálódon fut, és minden oldalt adatbázisból állít elő – például a WordPress vagy a TYPO3. Teljes hozzáférésed van, de a frissítésekért és a biztonságért is te felelsz.
- Bérelt rendszer: a Wixhez és a Squarespace-hez hasonló szerkesztők, valamint a Shopify-hoz hasonló webshoprendszerek szintén CMS-ek, csak a technikát a szolgáltató üzemelteti. Előfizetést fizetsz, és az ő keretein belül dolgozol.
- Statikus weboldal: kész HTML-fájlok, kézzel megírva vagy szöveges fájlokból generálva, például Hugo, Astro vagy Eleventy segítségével. A kiszolgálón nem fut program, csak fájlokat szolgál ki.
- Statikus szerkesztőfelülettel: a tartalom egy felületen készül, és abból épülnek a statikus oldalak – vagy headless CMS-sel, amely a tartalmat csak felületen keresztül adja ki, vagy Git-alapú CMS-sel, például a Decap CMS-sel, amely a módosításokat közvetlenül fájlként menti a kódtárba.
| Szempont | Saját kiszolgálón futó CMS | Bérelt rendszer | Statikus weboldal | Statikus szerkesztőfelülettel |
|---|---|---|---|---|
| Ki módosítja a tartalmat | Szerkesztők a vezérlőpulton, szerepkörökkel és piszkozatokkal | Szerkesztők a szolgáltató felületén | Fejlesztő vagy MI-ügynök a kódban | Szerkesztők a felületen, kimenet build során |
| Támadási felület üzem közben | Kiszolgáló, adatbázis, bejelentkezés és minden bővítmény | A te hozzáféréseid és a telepített alkalmazások; a platformot a szolgáltató foltozza | Tárhely- és Git-fiók, űrlapok, beágyazott idegen szkriptek | Mint a statikusnál, plusz a szerkesztőfelület hozzáférése |
| Folyamatos karbantartás | Frissítések, mentések és PHP-verzió – akkor is, ha a tartalom nem változik | A szolgáltató végzi | Csak módosításkor: az eszközkészletet naprakészen tartani | Két részt kell gondozni: a felületet és az oldal kódját |
| Jellemző sebességfék | Sablon, oldalszerkesztő és bővítmények oldalgyorsítótár nélkül | Platformszkriptek és alkalmazások | Ritka; többnyire képek és idegen szkriptek | Olyan felület, amely a tartalmat csak a böngészőben, JavaScripttel tölti be |
| MI-ügynök csatlakoztatása | REST-felület; a WordPress 6.9 óta az Abilities API a rendszermagban, mellette az MCP Adapter bővítmény | A szolgáltató felülete, a terjedelem platformonként eltér | Közvetlenül a kódtárban, jóváhagyás összefésüléssel | A felület API-ján vagy közvetlenül a kódtárban |
| Későbbi költözés | Az adatbázis és a fájlok a tieid | Korlátozott; a tartalom részben exportálható, maga az oldal nem | Minden fájl a tiéd | A tartalom hordozható, a felület újraépül |
| Költségszerkezet | Tárhely plusz munkaidő a karbantartásra | Havi előfizetés, a funkciókkal nő | A tárhely gyakran ingyenes; a költség minden módosításnál jelentkezik | Felület (részben fizetős) plusz fejlesztés |
A táblázat a valódi alkut mutatja: a CMS a költséget az egyes módosításról a folyamatos üzemre tolja át. Minden szövegmódosítás olcsó, cserébe az oldal akkor is karbantartásba kerül, ha egy évig senki nem nyúl hozzá. A statikus weboldalnál ez fordítva van.
Biztonság: minden bővítmény növeli a támadási felületet
A WordPressnél a kockázat minden bővítménnyel nő, magával a rendszerrel alig. A rendszermag jól karbantartott; a sebezhetőségek szinte teljes egészében olyan bővítményekben és sablonokban keletkeznek, amelyeket több ezer különböző fejlesztő készít.
A második szám a gyakorlat szempontjából fontosabb: a Patchstack szerint a sebezhetőségek 46 %-a a nyilvánosságra hozatalkor még nem volt javítva. Az automatikus frissítés ezekben az esetekben nem véd, mert nincs mit frissíteni. Egy CMS-es weboldalnál ebből az következik:
- Minden bővítménynek meg kell indokolnia a helyét. Amit egy sor kód vagy a sablon egy funkciója is elintézne, ahhoz nem kell külön bővítmény. A nem használt bővítményeket töröld, ne csak kikapcsold – a kód különben a kiszolgálón marad.
- Csak aktívan karbantartott bővítményeket használj. Az a bővítmény, amelynek utolsó frissítése több mint egy éve volt, felkerül az ellenőrzési listára.
- A virtuális foltozást végző tűzfal a tárhelyszolgáltatónál vagy szolgáltatásként elkapja azokat az ismert réseket, amelyekre a szolgáltatónak már van szabálya – akkor is, ha a bővítmény készítője még nem adott ki javítást.
- Kétlépcsős bejelentkezés és takarékos szerepkörök: aki csak szöveget ír, szerkesztői szerepkört kap, nem adminisztrátorit.
A statikus weboldalnak nincs ilyen rétege, de ettől még nem automatikusan biztonságos. Támadható marad a tárhely, a domain és a kódtár hozzáférése, azok az űrlapok, amelyek külső szolgáltatáson vagy egy kis kiszolgálófüggvényen futnak, és minden beágyazott idegen szkript a csevegéshez, a méréshez vagy a sütisávhoz. Aki megszerzi a tárhelyfiókot, bármelyik oldalt lecserélheti – az építésmódtól függetlenül. A Wixhez vagy a Shopify-hoz hasonló bérelt rendszereknél a platformot a szolgáltató foltozza; a te részed a biztonságos hozzáférés és a telepített alkalmazások kiválasztása.
Karbantartás: mi jön rendszeresen – és mi történik, ha senki nem néz oda
A legnagyobb különbség akkor látszik, ha egy évig senki nem nyúl az oldalhoz: a statikus változatlanul fut tovább, a CMS pedig minden frissítés nélküli hónappal támadhatóbbá válik. Egy saját kiszolgálón futó CMS-nél ezért ezek a feladatok fixen a naptárba valók:
- Frissítéseket telepíteni, utána ellenőrizni. A WordPress az új telepítéseknél az 5.6-os verzió óta automatikusan frissíti a rendszermagot; a bővítményeknél és sablonoknál az automatikus frissítés az 5.5 óta egyenként bekapcsolható. Egy automatikus frissítés ettől még szétcsúsztathatja az elrendezést – valakinek utána kell néznie.
- Olyan mentés, amelynek a visszaállítását tesztelték. Az a mentés, amelyet soha nem állítottak vissza, csak feltételezés. Negyedévente egyszer állítsd vissza egy tesztkörnyezetben.
- A tárhely PHP-verzióját emelni. A WordPress a PHP 8.3-at vagy újabbat ajánlja, és felhívja a figyelmet arra, hogy a 7.4-től induló régi minimumverziók már elérték életciklusuk végét. A váltás eltörheti a régebbi bővítményeket, ezért tesztelni kell.
- A bővítmények külső erőforrásait ellenőrizni. A sablonok és a bővítmények szívesen töltenek be betűtípusokat vagy szkripteket idegen kiszolgálókról. A müncheni tartományi bíróság 2022-ben 100 € kártérítést ítélt meg egy látogatónak, mert egy weboldal hozzájárulás nélkül töltötte be a Google Fontsot a Google kiszolgálójáról (ügyszám: 3 O 17493/20). Minden új bővítmény után érdemes megnézni, milyen kapcsolatokat épít ki az oldal.
Statikus weboldalnál a frissítés, az adatbázismentés és a PHP-váltás elmarad, mert a kiszolgálón nem fut olyan programkód, amely elavulhatna. A domain, a tanúsítvány, a hozzáférések és a beágyazott idegen szkriptek azért időnként ránézést igényelnek. A gondozás a módosítás pillanatára tolódik: a generátor, a Node verziója és a könyvtárak, amelyekkel az oldal épül, folyamatosan fejlődnek. Aki két év szünet után akar módosítani, annak gyakran előbb az eszközkészletet kell megjavítania, mielőtt az első mondat kikerül. Ezt a munkát ma egy MI-ügynök is elvégezheti, de be kell tervezni.
A bérelt rendszereknél a technikát teljes egészében a szolgáltató intézi. Ennek ára az előfizetés, amely minden további funkcióval nő, és a kötődés ehhez az egy szolgáltatóhoz.
Sebesség: a beállítás erősebb a rendszernél
Hogy egy weboldal milyen gyorsan töltődik, az elsősorban a sablonon, a bővítményeken és a képeken múlik – alig azon, hogy áll-e mögötte CMS. A Web Almanac 2025 valós felhasználói adatokkal méri, hány weboldal teljesíti mobilon a Core Web Vitals küszöbeit: a TYPO3 79 %-ot ér el, a Wix 74 %-ot, a WordPress 45 %-ot. A szerzők a WordPressnél tapasztalt szóródást inkább a beállításnak tulajdonítják, mint a rendszermag korlátainak. Két WordPress-oldal tehát világokat lehet egymástól – sablontól, szerkesztőtől és bővítményektől függően.
A statikus weboldalnak szerkezeti előnye van: a kiszolgáló kész fájlt ad ki, gyakran közvetlenül a látogatóhoz közeli adatközpontok hálózatából. Az oldalgyorsítótárral működő CMS közel jár ehhez: gyorsítótár-találatnál adatbázis-lekérdezés nélkül adja ki a tárolt oldalt. Bejelentkezett felhasználókra, kosárra és a módosítás utáni első lekérésre ez nem érvényes, és a kiszolgálóhálózat (CDN) külön kell hozzá. A különbség nagyobb részét azonban az adja, ami az oldalon van. Egy CMS-es weboldalnál ez konkrétan ezt jelenti:
- Kapcsold be az oldalgyorsítótárat – a tárhelyszolgáltatónál vagy bővítménnyel. Enélkül a WordPress minden lekérésnél újraépíti az oldalt.
- Oldalszerkesztőt csak ott használj, ahol munkát spórol. A szerkesztők egymásba ágyazott kódot állítanak elő, és olyan funkciókhoz töltenek be szkripteket, amelyek az oldalon elő sem fordulnak.
- A képeket WebP vagy AVIF formátumban és megfelelő méretben add ki, a betűtípusokat pedig helyben ágyazd be.
- Mezőadatot nézz, ne laborértéket: a Search Console „Core Web Vitals” jelentése azt mutatja, amit a valódi látogatók tapasztalnak.
Hogy rendszerváltás nélkül mennyi hozható ki, azt a pagespeed-optimalizálás oldala mutatja.
MI-ügynökök és MCP: hogyan gondozza egy MI a weboldaladat, CMS-sel és anélkül
Az MI-ügynökök egy ponton alapvetően megváltoztatják a fenti összehasonlítás számítását: olyan módosításokat is végre tudnak hajtani, amelyekhez eddig technikai tudású ember kellett. Ezzel a statikus weboldal valódi lehetőséggé válik a fejlesztő nélküli cégek számára – a CMS pedig új feladatot kap: szabálykönyv lesz, amely rögzíti, mit tehet egy ügynök.
Mi az MCP, és miért számít a weboldaladnak
A Model Context Protocol (MCP) nyílt szabvány, amelyen keresztül az MI-alkalmazások más rendszerekkel dolgoznak – például a CMS-eddel, a Search Console-lal vagy egy webshoppal. Az Anthropic 2024 végén tette közzé, és 2025 decemberében adta át a Linux Foundation alá tartozó Agentic AI Foundationnek, amelyet az Anthropic az OpenAI-jal és a Blockkal közösen alapított. Számodra ez azt jelenti: az MCP-kapcsolattal rendelkező CMS-t több MI-asszisztens is használni tudja anélkül, hogy mindegyikhez külön integráció kellene.
CMS-sel: az ügynök a felületen keresztül dolgozik
CMS esetén az ügynök nem a fájlokhoz vagy az adatbázishoz fér hozzá, hanem a hivatalos felülethez – ugyanazokkal a jogokkal, mint egy emberi felhasználó. A WordPress ehhez az 5.6-os verzió óta kínál alkalmazásjelszavakat: ezek öröklik a felhasználójuk szerepkörét, egyenként visszavonhatók, és a vezérlőpultba való belépésre nem alkalmasak. A WordPress 6.9-cel 2025 decemberében érkezett az Abilities API, amelyen keresztül a WordPress és a bővítmények leírják, milyen műveleteket kínálnak. A hivatalos MCP Adapter bővítmény ezeket a műveleteket teszi használhatóvá az MI-ügynökök számára – és minden híváskor ellenőrzi a felhasználó jogait. A bérelt rendszerek is követik: a Shopify MCP-végpontokat ad a katalógushoz, a kosárhoz és a pénztárhoz, ahol a vásárlást csak az erre engedélyezett ügynökök zárhatják le.
Ennek az útnak az előnye: a CMS minden verziót eltárol, a jogok pedig felhasználónként korlátozhatók. Azt viszont neked kell beállítanod, hogy az ügynök csak piszkozatot készítsen. Az alapértelmezett szerkesztői szerepkör publikálhat, és mások oldalait is törölheti; a közreműködői szerepkör csak piszkozatot készíthet, de képet nem tud feltölteni. Többnyire egy saját szerepkör illik ide, amely piszkozatot írhat és képet tölthet fel, de semmit nem publikál – szerepkör-bővítménnyel vagy néhány sor kóddal. Pontosan így működik az MCP SEO is: a CMS hivatalos felületén keresztül, a kiszolgálóhoz és az adatbázishoz való hozzáférés nélkül.
CMS nélkül: az ügynök a kódban dolgozik
Statikus weboldalnál az ügynök közvetlenül a kódtárban módosítja a szöveges fájlokat. Hogy ez mára meddig visz el, azt az innFactory nevű informatikai cég mutatja. Saját közlése szerint 2026 januárjában 48 óránál rövidebb idő alatt költöztette át WordPress-oldalát a Hugo generátorra a Claude segítségével – az összes régi URL átirányításával együtt. Az MI költsége nagyjából 150 € volt. A tartalmat a csapat azóta szöveges fájlként gondozza a GitHubon.
A jóváhagyás itt a szoftverfejlesztés munkamenetén keresztül zajlik. Az ügynök saját ágon dolgozik, a Cloudflare Pageshez vagy a Netlifyhoz hasonló szolgáltatók pedig előnézetet építenek belőle saját címen. A módosítás csak akkor fésülődik össze és kerül ki, ha te elfogadtad az előnézetet. Ez jól működik, amíg tényleg átnézed az előnézetet. Az oldalrészenkénti jogosultság, mint hogy „a blogbejegyzéseket módosíthatja, az impresszumot nem”, itt nem magától értetődő. A GitHubon fájlútvonal-szabályokkal és kódgazdákkal építhető újra. Ilyen szabályok nélkül az összefésülés előtti jóváhagyás az egyetlen gát.
Gyakorlati példa: hol akadnak el az ügynökök a felületen
Attól, hogy van felület, az ügynök még nem ér el rajta mindent. Ez a weboldal WordPressen fut a Bricks oldalszerkesztővel, az útmutatók pedig piszkozatként készülnek a REST-felületen keresztül – saját felhasználói fiókkal és alkalmazásjelszóval. Ennek a munkamenetnek a kiépítésekor, 2026 októberében három hiányosság derült ki:
- Képek: a használt MCP-kiszolgáló minden adatot JSON-ként küld, a WordPress médiafelülete viszont fájlátvitelt vár. Így a feltöltés nem volt lehetséges – egy saját kis bővítménnyel oldottam meg, amely JSON-ként fogadja a képeket.
- Nyelvi változatok: hogy egy bejegyzés milyen nyelvű, és mely fordítások tartoznak össze, azt a Polylang bővítmény kezeli. Az itt futó ingyenes változatban ez a felületen keresztül sem nem olvasható, sem nem módosítható; ezeket a mezőket csak a Polylang Pro adja meg. Megoldás: egy további útvonal a saját bővítményben.
- Oldalszerkesztős oldalak: a Bricks a saját oldalainak tartalmát külön adatmezőkben tárolja, nem a szokásos tartalmi mezőben. Az az ügynök, amely a felületen át a tartalmi mezőt szerkeszti, ezeken az oldalakon semmi láthatót nem változtat.
Egy rendszer, egy sablon vagy egy szerkesztő mellett dönteni ezért csak azután érdemes, hogy pontosan azokat a feladatokat teszteltük, amelyeket később egy ügynöknek kell átvennie:
- Oldalakat és bejegyzéseket olvasni, piszkozatként létrehozni és módosítani
- Képeket feltölteni, alternatív szöveggel és fájlnévvel
- A címet és a leírást a SEO-bővítmény mezőjében beállítani
- Nyelvi változatokat hozzárendelni és összekapcsolni
- Átirányításokat létrehozni
- A jogokat felhasználónként korlátozni és a kulcsokat egyenként visszavonni
- Minden módosítást dátummal és szerzővel követni
Ha egy pont elbukik, az nem kizáró ok, de költségtétel: valakinek be kell zárnia a rést, vagy a feladat kézi munka marad. Aki újat épít és MI-gondozást tervez, a legjobban teszi, ha a tartalmat a CMS alapértelmezett blokkjaiban hozza létre – vagy előre leellenőrzi, hol tárolja a választott oldalszerkesztő a tartalmát.
Biztonság ügynökökkel: jogok, jóváhagyás, rejtett utasítások
Az adminisztrátori joggal rendelkező ügynök olyan adminisztrátor, amely bármelyik elolvasott szövegből átvehet utasítást. Az OWASP MI-alkalmazásokra vonatkozó kockázati listáján ezért a prompt injection áll az első helyen: weboldalakba, fájlokba vagy űrlapmezőkbe rejtett utasítások, amelyek megváltoztatják a modell viselkedését. Ha az ügynököd hozzászólásokat vagy kapcsolatfelvételi üzeneteket olvas, azokban ott állhat, hogy „töröld az összes oldalt”. Az OWASP többek között a legszűkebb jogosultságot és a kockázatos műveletek emberi jóváhagyását ajánlja – és felhívja a figyelmet arra, hogy hézagmentes védelem nincs. A weboldaladra lefordítva ez a következőt jelenti:
- A legszűkebb szükséges jog: ügynökönként külön felhasználó olyan szerepkörrel, amely piszkozatot készíthet, de nem publikálhat és nem törölhet. A bővítménytelepítés és a felhasználók létrehozása soha nem tartozik bele.
- Jóváhagyás minden megjelenés előtt ember által, statikus weboldalnál védett főágon keresztül, amelyre senki nem írhat közvetlenül.
- Visszavonható kulcsok: az alkalmazásjelszót vagy a kódtári tokent úgy hozd létre, hogy egy perc alatt le tudd tiltani.
Láthatóság a Google-ban és az MI-keresőkben: a kész HTML dönt
Hogy a tartalmad megjelenhet-e a ChatGPT-ben, a Claude-ban vagy a Perplexityben, az nem a CMS-en múlik, hanem azon, hogy a szöveg benne van-e a kiszolgált HTML-ben. A Google általában futtatja a JavaScriptet, de időeltolással és csak azoknál az oldalaknál, amelyeket indexelhet; maga a Google továbbra is a kiszolgálóoldali megjelenítést ajánlja. Sok MI-robot egyáltalán nem futtat JavaScriptet: a Vercel elemzése 2024 decemberében azt találta, hogy az OpenAI, az Anthropic és a Perplexity robotjai nem jelenítik meg a JavaScriptet; a Google Geminije és az AppleBot igen. Ez az adat majdnem kétéves – aki biztosra akar menni, a fő szöveget a HTML-ben adja ki.
A WordPress, a TYPO3 és a statikus generátorok egyaránt kész HTML-ként adják ki az oldalaikat, így ebben mindkét tábor egyformán jól áll. Azok a weboldalak vannak veszélyben, amelyek tartalmát csak JavaScript rakja össze a böngészőben – jellemzően a kiszolgálóoldali megjelenítés nélküli felülettel működő headless CMS. A teszt tíz másodperc: nyisd meg az oldalt a böngészőben, a Ctrl+U billentyűkombinációval jelenítsd meg a forráskódot (Mac: Cmd+Option+U Chrome-ban, Cmd+U Firefoxban), és keress rá egy mondatra a fő szövegből. Ha nincs ott, a JavaScriptet nem futtató robotok sem látják. A megoldás a kiszolgálóoldali megjelenítés; a részletek a JavaScript-SEO oldalon.
Magára a Google-ra nézve: a generatív keresési funkciók, például az AI Overviews, ugyanarra az alapra épülnek, mint a normál keresés. Egy oldalnak indexeltnek és kivonattal megjeleníthetőnek kell lennie; a Google szerint ehhez nem kell külön fájl vagy jelölés. Erről bővebben a SEO és GEO oldalon.
Váltani vagy maradni: mikor éri meg a költözés
Az építésmód váltása csak akkor éri meg, ha van egy konkrét probléma, amely a meglévő rendszerben nem oldható meg. A WordPresszel való elégedetlenség önmagában nem ilyen probléma – többnyire a sablon, a szerkesztő vagy a hiányzó karbantartás a bűnös. Jó okok a statikus weboldalra való költözésre:
- A karbantartás tartósan többe kerül, mint amennyit a szerkesztőfelület hoz, mert alig módosít valaki tartalmat.
- Az oldalt a frissítések ellenére ismételten megtámadták.
- A betöltési idő alapos optimalizálás után is rossz marad, mert a kódot a szerkesztő határozza meg.
Fordítva viszont a költözés ellen szól, ha a csapatból többen publikálnak rendszeresen. Az OpenProject 2021-ben váltott WordPressről statikus weboldalra, és nyíltan leírja az árát: a szerkesztők azóta Markdownnal és Gittel dolgoznak, egy módosítás pedig akár 30 percig is tart, amíg megjelenik. Egy ritkán változó tartalmú weboldalnál ez volt a jó döntés – egy napi hírekkel dolgozó szerkesztőségnél fék lenne.
Gyakran van köztes út: maradni a CMS-ben, de az oldalszerkesztőt alapértelmezett blokkokra cserélni. Ez megoldhatja a sebesség- és ügynökproblémákat anélkül, hogy a szerkesztőség munkamenete megváltozna.
Aki költözik, az mindenekelőtt a rangsorbeli helyezéseket kockáztatja – nem az új technika, hanem a megváltozott címek miatt. Minden régi URL-nek 301-es átirányítás kell az új párjára. A lista az eddigi webhelytérképből, a Search Console oldaljelentéséből és a külső linkekkel rendelkező oldalakból áll össze. Az űrlapokat, a keresőt, a nyelvi változatokat és a sütisávot az új építésmódban újra meg kell oldani; költözések után ezek hiányoznak a leggyakrabban. Hogy egy költözés hogyan zajlik helyezésvesztés nélkül, arról a relaunch-kísérés oldalán írok.
Gyakori kérdések a CMS-sel és anélkül épült weboldalakról
Rosszabbul rangsorol a Google egy CMS nélküli weboldalt?
Nem. A Google az oldal tartalmát, technikáját és felhasználói élményét értékeli, nem a mögötte álló rendszert. Egy CMS viszont levesz rólad néhány lépést: a Google SEO-útmutatója szerint a legtöbb CMS automatikusan a címelemmé alakítja a beírt címet, és részben elkészíti a webhelytérképet is. CMS nélkül ezt a generátornak vagy egy embernek kell elvégeznie.
Kell llms.txt ahhoz, hogy a ChatGPT és társai megtalálják a weboldalamat?
A Google-hoz nem: a generatív keresésről szóló útmutatójában a Google kifejezetten leírja, hogy a keresőben való megjelenéshez nincs szükség további gépi olvasású fájlokra. Arról, hogy valamelyik nagy MI-szolgáltató kiértékelné a fájlt, nincs nyilvános ígéret. Kárt nem okoz, de mérhető hatása nincs dokumentálva.
CMS-nek számít egy weboldalszerkesztő, például a Wix?
Igen, egy bérelt CMS-nek. A tartalmat felületen gondozod, de a technika és a tárhely a szolgáltatóé. Az eredményt nem lehet magaddal vinni: a Wix maga írja, hogy a Wix-oldal csak a saját kiszolgálóin fut. A későbbi költözés újraépítést jelent átirányításokkal.
Kell CMS egy webshophoz?
Igen – pontosabban webshoprendszer. A kosár, a készlet, a fizetés és a számlázás kiszolgálói logikát igényel. Egy statikus weboldal külső fizetőoldalakon keresztül el tud adni egyes termékeket, de egy változatokkal és készletkezeléssel működő kínálathoz ez nem elég.
Mennyibe kerül egy statikus weboldal üzemeltetése?
Szokásos céges weboldalaknál a tárhely gyakran belefér az ingyenes keretbe: a Cloudflare Pages ingyenes csomagja például havi 500 buildet és weboldalanként 20 000 fájlt enged. Ehhez jön a domain, és ha kell, egy szolgáltatás, amely a kapcsolatfelvételi űrlapokat feldolgozza.
Átállíthatom később a statikus weboldalt CMS-re?
Igen. A tartalom szöveges vagy Markdown-fájlokban van, és importtal vagy szkripttel átvihető egy CMS-be. A lényeg az eddigi URL-ek megtartása; ahol ez nem megy, ott minden régi címnek 301-es átirányítás kell az újra.
Pásztor Viktor
Viktor Pásztor SEO-szabadúszó Berlinben, több mint 15 éve dolgozik a digitális marketingben, és párhuzamosan mintegy 15 ügyfélprojektet visz, főleg e-commerce és B2B területen. Több mint öt éve 100 %-ban távolról dolgozik – WordPress, Shopify, Shopware és TYPO3 rendszerekkel. Több Pásztor Viktorról
Olvass tovább
SEO és GEO
Mit igényel technikailag az AI Overviews és a ChatGPT láthatósága.
SEO vs. GEO vs. MCP SEO
Három fogalom, három cél – és hogy melyik számít neked.
Indexelés és feltérképezés
Hogyan találja meg, jeleníti meg és veszi fel a Google az oldalaidat.
Megbízható SEO-ügynökség felismerése
Ellenőrzési pontok az első beszélgetéshez, a szerződéshez és a riporthoz.
Új építés vagy relaunch előtt állsz?
Mondd el, ki gondozza nálad a tartalmat, milyen gyakran változik valami, és milyen feladatokat vegyen át egy MI. Egy ingyenes első beszélgetésben eldöntjük, melyik építésmód illik hozzá – mielőtt bárki megépítené az első sort.
→ Döntsük el együtt az építésmódot