A vibe-coded weboldal nem bírja a tempót: 7 pontos elsősegély-ellenőrzőlista

Az AI-eszközzel készített weboldal órák alatt elkészül: ez a vibe-coding lényege. Az AI weboldalak javítása az esetek túlnyomó többségében nem jelent nulláról való újraírást. Elég rendszerezetten átnézni hét területet: a Core Web Vitals mutatókat és a sebességet, a HTTPS-t és az alapinfrastruktúrát, a kód biztonságát, a SEO-struktúrát, a technikai adósságot, az akadálymentességet, valamint a frissítéseket és a mentési tervet. Egy AI által generált weboldal kritikus hibáinak többségét egyetlen délután alatt megtalálja, teljes újraírás nélkül.

Mi az a vibe-coded weboldal, és miért nem bírja a tempót

A vibe-coding a weboldalak és alkalmazások készítésének olyan módja, amelyben a kérést természetes nyelven adja meg egy AI-eszköznek, például a Cursornak (AI kódszerkesztő), a Lovable-nek (AI alkalmazásépítő), a StackBlitz Boltjának vagy a Vercel v0-jának, és az működő kódot generál. Az eredmény első ránézésre késznek tűnik: a regisztráció működik, a tartalom megjelenik, a fizetések átmennek. E homlokzat mögött azonban gyakran olyan problémák rejlenek, amelyek csak a telepítés után, éles üzemben jönnek elő.

Az AI működő kódot generál, nem éles üzemre optimalizált kódot. A generátor a készítéskor semmit sem tud arról, milyen gyorsan töltődik be az oldal az ügyfelei mobilján, milyen biztonsági szabványok vonatkoznak az Ön alkalmazástípusára, milyen SEO-struktúrát értékel a Google 2026-ban, sem arról, mennyibe kerül majd a kód karbantartása három év alatt. Ezek a hiányosságok nem végzetesek, de meg kell találni és be kell zárni őket, és erre szolgál a rendszerezett audit.

A vibe-coding 2025-ben és 2026-ban robbanásszerűen elterjedt. A ProjectDiscovery „2026 AI Coding Impact Report” című jelentése szerint, amely 200 észak-amerikai és nyugat-európai biztonsági szakember felmérésén alapul, a megkérdezettek 100%-a tapasztalta, hogy az elmúlt 12 hónapban nőtt az előállított kód mennyisége, és közel felük (49%) e növekedés nagyobbik részét éppen az AI-asszisztált eszközöknek tulajdonítja. A közepes méretű cégek biztonsági csapatai érzik ezt a leginkább: 69%-uk egyre nagyobb nehézségekről számol be, amikor a növekvő mennyiségű AI-kódot kell biztonsági szempontból ellenőrizni.

A kis szlovák cégek számára, amelyek az egyedi fejlesztésnél jóval alacsonyabb áron készíttettek vibe-coded weboldalt, ez egyet jelent: a weboldal fut, de valószínűleg nem olyan jól, ahogyan futhatna. A kódban rejlő sebezhetőségek pedig valós kockázatot jelentenek.

7 pontos audit-ellenőrzőlista: áttekintés

Mielőtt rátérne az egyes pontok részleteire, itt az audit teljes áttekintése egyetlen táblázatban. Minden területnek megvan a maga súlyossága: a kritikus azt jelenti, hogy a probléma biztonsági incidenst vagy közvetlen ügyfélvesztést okozhat; a magas olyan állapot, amely rontja a teljesítményt vagy a SEO-t; a közepesnek nem feltétlenül van azonnali hatása, de hosszú távon nő a teher.

#	Auditterület	Mit keres	Eszköz	Súlyosság
1	Core Web Vitals	LCP 2,5 s alatt; INP 200 ms alatt; CLS 0,1 alatt	PageSpeed Insights	Kritikus
2	HTTPS és infrastruktúra	Érvényes SSL; HTTP-átirányítás; vegyes tartalom	Böngésző, SSL Checker	Kritikus
3	Kódbiztonság	Kiszivárgott API-kulcsok, hitelesítés, OWASP A01-A03	Manuális audit, SCA-eszközök	Kritikus
4	SEO-struktúra	H1, meta, sitemap.xml, schema markup	Search Console, Rank Math	Magas
5	Technikai adósság	Elavult függőségek, halott kód	npm audit / WP Scanner	Magas
6	Akadálymentesség (A11y)	Alt szövegek, ARIA, színkontraszt, billentyűzet	Lighthouse, axe DevTools	Közepes
7	Frissítések és mentések	Frissítési ütem, mentési terv, monitorozás	WP-CLI, uptime monitor	Magas

1. és 2. pont: sebesség, Core Web Vitals és infrastruktúra

A weboldal sebessége nem esztétikai kérdés, hanem közvetlen rangsorolási jel. A Google minden oldalt a Core Web Vitals alapján értékel, az adatokat pedig valódi látogatók valódi böngészőiből gyűjti a Chrome User Experience Report révén. A határértékeket a Google Search Central dokumentációja pontosan meghatározza:

• LCP (Largest Contentful Paint) - az oldal fő vizuális tartalmának betöltése: jó eredményhez 2,5 másodperc alatt.
• INP (Interaction to Next Paint) - a weboldal reakciósebessége interakciókor (kattintás, billentyűleütés): 200 milliszekundum alatt.
• CLS (Cumulative Layout Shift) - vizuális stabilitás betöltéskor, az elemek váratlan elmozdulásának mértéke: 0,1 alatt.

Hogy ezek a mutatók mit jelentenek a gyakorlatban, és miért számítanak a Google és a konverziók szempontjából, azt a Mik azok a Core Web Vitals, és miért számítanak című kísérő cikkünkben magyarázzuk el. Ha nem biztos benne, hol tartanak a mutatói, nézze meg a lépésről lépésre bemutatott módszert a Hogyan tudom gyorsan megállapítani, hogy lassú-e a weboldalam cikkben.

Az AI által generált weboldalak két okból jellemzően nem teljesítik ezeket az értékeket rögtön az első indítás után. Először: a képek nincsenek tömörítve, és a méretük nincs helyesen megadva közvetlenül a HTML-ben: az AI `<img src="hero.jpg">` kódot generál `width`, `height` és WebP-változat nélkül. Másodszor: a JavaScript blokkolóan töltődik be, mert a generátor nem tudja, mely szkriptek kritikusak az első megjelenítéshez, és melyek várhatnak `defer` vagy `async` betöltésre.

Mit tegyen: futtassa le a PageSpeed Insightst (pagespeed.web.dev) a főoldalon és három reprezentatív aloldalon is. Minden 50 pont alatti mobilos eredmény vészjelzés. A sebesség javításának konkrét lépéseit, a képtömörítéstől a lazy loadingon át a critical CSS-ig, a legtöbb WordPress-adminisztrátor programozó nélkül is elvégzi. Csak azt kell tudnia, pontosan mit mutat a PageSpeed.

A HTTPS kötelező, nem opcionális. A modern böngészők az érvényes SSL-tanúsítvány nélküli weboldalakat nem biztonságosként jelölik, és ezt a figyelmeztetést minden látogató közvetlenül a címsorban látja. Ellenőrizzen három dolgot: (1) a tanúsítvány érvényes és nem járt le, (2) minden HTTP-cím HTTPS-re irányít át, a „www” nélküli változatot is beleértve, (3) semmilyen erőforrás (kép, szkript, stíluslap) nem töltődik be nem biztonságos HTTP-n keresztül (ún. mixed content).

3. pont: kódbiztonság - az AI weboldalak javítása biztonsági audit is

A biztonság az a terület, ahol az AI által generált kód a leggyakrabban lemarad. Az ok rendszerszintű: az AI modell generáláskor a „működő kódra” optimalizál, nem a „biztonságos kódra éles környezetben”. Alapszintű tesztelésnél a kettő ugyanaz, valós terhelés alatt azonban lényegesen eltér. Íme a négy leggyakoribb probléma, amelyet az auditok során találunk:

Kiszivárgott titkok és API-kulcsok

Az AI-generátorok hajlamosak az API-kulcsokat, tokeneket és adatbázis-jelszavakat közvetlenül a forráskódba helyezni, néha olyan fájlokba is, amelyek egy nyilvános Git-repozitóriumba kerülnek. Az alapvető lépések: ellenőrizzen minden konfigurációs fájlt és a .env fájlokat, győződjön meg róla, hogy a .env szerepel a .gitignore-ban, és nincs commitolva, és nézze át a repozitórium commitelőzményeit. Ha egy kulcs kiszivárgott, azonnal vissza kell vonni, és újat kell kiadni: nem elég csak a fájlt kijavítani.

Hitelesítés és jogosultságkezelés (OWASP A01:2025)

Az OWASP Top 10:2025 szerint a Broken Access Control (A01) áll a webalkalmazások legkritikusabb sebezhetőségeinek első helyén. Az AI által generált kód jellemzően megvalósítja a bejelentkezési oldalt, de elfelejti minden API-végpontnál ellenőrizni a jogosultságot. Az eredmény: egy be nem jelentkezett felhasználó hozzáférhet egy másik ügyfél adataihoz, vagy adminisztrátornak fenntartott műveletet hajthat végre. Tesztelje kézzel: próbáljon meg hitelesítés nélkül megnyitni védett URL-eket, és figyelje, mit ad vissza a szerver.

Biztonsági konfigurációs hibák (OWASP A02:2025)

Az OWASP Top 10:2025 A02 kategóriája a szerver és az alkalmazás hibás konfigurációját fedi le, amely a második leggyakoribb probléma a webes projektekben. Az AI olyan alapértelmezett konfigurációkat állít be, amelyek nem alkalmasak éles üzemre: bekapcsolt debug mód az éles környezetben, a stack trace-t a nyilvánosság számára megjelenítő részletes hibaüzenetek, meg nem változtatott alapértelmezett adatbázis-jelszavak vagy aktívan hagyott, magasabb jogosultságú tesztfiók.

Injekciós támadások és a bemenetek validálása

Az AI az SQL-lekérdezéseket karakterláncként generálja, nem prepared statementekkel paraméterezett lekérdezésként, ami az SQL injection klasszikus alapja. Ez főleg olyan keretrendszereknél igaz, ahol az AI nem azt mondja, hogy „automatikus escapelésű ORM-et használok”, hanem egyszerűen ilyen kódot generál: `"SELECT * FROM users WHERE email = '" + email + "'"`. Ellenőrizzen minden űrlapot és minden végpontot, amely felhasználói bemenetet fogad.

WordPress-projektek auditjához a Patchstack scannert ajánljuk, amely a sebezhető bővítményeket és témákat ellenőrzi. A kód rendszerezett megtisztításával kapcsolatos tapasztalatainkat egy elavult architektúráról való átállásnál az Elementorról tiszta WordPress-témára való átállásról szóló cikkben is leírjuk: az audit elvei nagyrészt ugyanazok.

4., 5. és 6. pont: SEO, technikai adósság és akadálymentesség

SEO-struktúra: a Google-beli láthatóság alapja

Az AI képes tartalmat létrehozni, a SEO-metaadatok azonban gyakran generikusak, vagy teljesen hiányoznak. A SEO-struktúra ellenőrzésének kulcspontjai:

• Minden oldalnak egyedi, 50 és 60 karakter közötti `<title>` eleme és 150 és 160 karakter közötti meta descriptionje van, nem ugyanaz a sablon minden URL-re másolva.
• Minden aloldalon pontosan egy `<h1>` van: nem nulla, nem három.
• A képeknek a tartalmat valóban leíró alt szövegük van, nem csak „img_1234.jpg” vagy üres attribútum.
• Létezik a /sitemap.xml címen elérhető sitemap.xml, és helyesen regisztrálva van a Google Search Console-ban.
• A robots.txt nem blokkolja tévedésből a fontos aloldalak indexelését.
• A kanonikus URL-ek helyesen vannak beállítva duplikált tartalom esetén (pl. paraméteres URL-eknél).

2026-ban a Google AI Mode is változtat a SEO dinamikáján: a vibe-coded weboldalaknál a helyes szemantikus HTML-struktúra és a világosan válaszoló tartalomblokkok kulcsfontosságúak az AI-válaszokban való hivatkozásokhoz. Erről részletesen a A Google AI Mode felváltja a klasszikus keresést: mit jelent ez az Ön weboldalára nézve cikkben írtunk. Ha teljes SEO-auditra van szüksége, keresőoptimalizálási szolgáltatásunk a technikai elemzést és a tartalmi ajánlásokat is lefedi.

Technikai adósság: a láthatatlan költség

Az AI által generált kód minden kérésiterációval nő: minden javítás új kódot ad hozzá anélkül, hogy a régit eltávolítaná. Néhány hónapnyi munka után olyan projektje lesz, amelyben jelentős a halott kód aránya, ugyanannak a könyvtárnak több verziója is jelen van, és vannak függőségek, amelyeket senki sem frissített. Ez a technikai adósság, és minden hónapban fizet érte: lassabb weboldallal, nehezebb karbantartással és nagyobb támadási felülettel a biztonsági fenyegetések számára.

Mit tegyen konkrétan: futtassa le az `npm audit` parancsot (Node.js-projekteknél) vagy a Patchstack scannert (WordPressnél), azonosítsa a sebezhető csomagokat, és állítson be rendszeres frissítési folyamatot. Nézze át a CSS/JS fájlokat, és távolítsa el a nem használt stílusokat és szkripteket. Ellenőrizze, hogy a CMS magja és a téma a legfrissebb verzión van-e.

Akadálymentesség (A11y): SEO-tényező és jogi kérdés is

Az AA szintű WCAG 2.1 a céges weboldalak sztenderdje, és egyben SEO-tényező is: a Google a tartalom relevanciájának meghatározásakor a HTML szemantikai minőségét is értékeli. Az AI-generátorok jellemzően kihagyják: az ARIA-címkéket az interaktív elemeknél (látható szöveg nélküli gombok, modális ablakok), a megfelelő színkontrasztot (normál szövegnél legalább 4,5:1 arány), a billentyűzetes navigációt és a funkcionális képek alt szövegeit. A Chrome DevTools Lighthouse-auditja egy perc alatt megmutatja e problémák többségét: az „Accessibility” fülön pontos hibákat kap, a megoldásra mutató hivatkozással.

7. pont: frissítések, mentések és monitorozás az indítás után

A vibe-coded weboldal az indítás után nem gondoskodik magáról. A frissítések elhanyagolása az egyik leggyakoribb oka annak, hogy az AI által generált weboldalak az indítás utáni első hat-tizenkét hónapban leállnak, vagy feltörik őket. Íme a konkrét lépések, amelyeket be kell állítani:

• Mentés: napi adatbázis- és fájlmentés elkülönített helyre (másik szerverre vagy felhőtárhelyre). A weboldallal azonos szerveren tárolt mentésnek nincs értelme: szerverhiba esetén mindkettőt elveszíti.
• Frissítések: a CMS magját, a bővítményeket és a témákat biztonsági javítás megjelenésekor haladéktalanul frissítse. Javasoljuk, hogy kövesse az értesítéseket a WordPress adminisztrációs felületén, vagy állítson be automatikus frissítést a biztonsági javításokra.
• Uptime monitoring: az olyan ingyenes eszközök, mint az UptimeRobot, e-mailben vagy Slacken értesítenek, ha a weboldal leáll, így nem kell megvárnia, hogy egy ügyfél szóljon.
• SSL-tanúsítvány: kövesse a lejárati dátumot, állítson be automatikus megújítást. A Let's Encrypt tanúsítványok 90 napig érvényesek: ha az automatikus megújítás nem sikerül (pl. DNS-változtatáskor), a weboldal HTTPS-hibára fut.
• Hibamonitorozás: állítsa be a szerverhibák naplózását (PHP-hibák, 404-es oldalak, sikertelen bejelentkezések), és rendszeresen ellenőrizze őket.

Mikor javítson, és mikor írja újra a nulláról?

Nem minden vibe-coded weboldalt éri meg javítani: néha gazdaságosabb egy új, egyedi weboldal. Erre nincs általános válasz: a megállapítások súlyosságától, az üzleti kontextustól és a projekt korától függ. Íme egy tájékoztató jellegű döntési keretrendszer:

Helyzet	Javítás	Részleges újraírás	Új weboldal
Biztonsági hibák a kód elszigetelt részeiben	Igen: célzott javítások	Kiterjedt hitelesítési hibáknál	Ritka
Teljesítmény (50 alatti CWV-pontszám mobilon)	Képoptimalizálás, lazy load	JS/CSS bundle-ök refaktorálása	Csak alapvető architektúrahibánál
A SEO-struktúra teljesen hiányzik	Meta, schema, sitemap pótlása	URL-ek átstrukturálása	Ritka eset
Technikai adósság a kód több mint 50%-ában	Szelektív refaktorálás lépésről lépésre	Fokozatos migráció	A teljes stack cseréjekor
Az üzlet vagy az alapfunkcionalitás változása	Nem	Részleges újratervezés	Igen: új követelmények

Megjegyzés: ezek tájékoztató jellegű forgatókönyvek a hozzávetőleges tájékozódáshoz; a konkrét ajánlás a projekt terjedelmétől és az audit eredményeitől függ.

Általános szabály, amely a szlovák weboldalak auditjainál érvényes: ha a vibe-coded weboldal a megfelelő üzleti problémát oldja meg, jó a tartalma, és az első indítás után az ellenőrzőlista 7 pontjából legalább 4-et teljesít, a javítás a gazdaságilag észszerűbb választás. Ha egyszerre bukik el a 2. és a 3. biztonsági ponton, és a kód architektúrája nem teszi lehetővé az elszigetelt javítást, az új, egyedi weboldalba fektetett pénz két-három éves távlatban többet hoz vissza.

Ha azt mérlegeli, hogy a weboldala elérte-e azt a pontot, ahol a javítások már nem elegendőek, olvassa el az 5 jel, hogy ideje újratervezni a weboldalt című áttekintést is: e jelek közül több a vibe-coded projektekre is ugyanúgy érvényes.

A gyakorlatban: amit a szlovák piacon látunk

Szlovák kis cégek és webáruházak weboldalainak auditjai során az AI által generált projekteknél több visszatérő mintába ütközünk. Ezeket általánosan írjuk le: nem konkrét ügyfeleket, hanem ismétlődő, tipikus helyzeteket:

• A kiszivárgott API-kulcsok a leggyakoribb biztonsági megállapítás: a fizetési kapu vagy az e-mail-szolgáltató kulcsai a repozitóriumban, néha a commitelőzményekben is, ahol a fájl törlése önmagában nem elég.
• 5 másodperc feletti LCP mobilon egy több megabájtos, eredeti méretű hero kép miatt: az AI méretek és WebP-konverzió nélküli `<img>` elemet generált.
• Hiányzó bemenetvalidálás az űrlapokon: a kapcsolatfelvételi űrlap a bemenetet tisztítás nélkül adja tovább közvetlenül egy adatbázis-lekérdezésnek vagy az e-mail törzsének.
• A sitemap létezik, de nincs regisztrálva a Search Console-ban: a weboldal „indexelhetőnek tűnik”, de a Google nem térképezi fel aktívan, mert nem tud az új tartalomról.
• A mentés ugyanarra a szerverre készül: a hosting kiesésekor a mentést is elveszíti. Ez az egyik első konfigurációs lépés, amelyet minden weboldal karbantartásba vételekor rendezünk.

A Denva minden AI által generált weboldal AI-eszközök utáni javításra való átvételekor a fent leírt 7 pontos ellenőrzőlista szerinti tömör audittal kezd. Az eredmény a megállapítások priorizált listája, a javítás óraszámban kifejezett tájékoztató becslésével: üres frázisok nélkül, csak konkrét lépések. Négy fázis, semmi meglepetés.

Ha a weboldala olyan problémába ütközött, amely túlmutat a gyors javításon, nézze meg, mikor érdemes teljes újratervezésen gondolkodni, például ha az üzlet továbblépett attól az eredeti terjedelemtől, amelyre a vibe-coded projektet tervezték.

Összegzés: a „működik”-től a „megbízhatóan működik”-ig

A vibe-coded weboldal nem automatikusan rossz weboldal. Olyan weboldal, amely gyors rajtot kapott, és most rutinszerű biztonsági és teljesítményellenőrzésre van szüksége, ugyanúgy, mint bármely öt éve elindított weboldalnak, amelyről azóta senki sem gondoskodott. Az ellenőrzőlista hét pontja lefedi azoknak az okoknak a túlnyomó többségét, amelyek miatt az AI által generált weboldalak megrekednek a rangsorban, ügyfeleket veszítenek, vagy az üzemeltetés első évében feltörik őket.

Ha független rálátásra van szüksége a kódra és az audit eredményeire, vagy nincs ideje saját maga elvégezni, kérjen kötelezettség nélküli konzultációt. 24 órán belül válaszolunk, és megmondjuk, konkrétan mire van szüksége a weboldalának.

GYIK

Gyakori kérdések.

Mi az a vibe-coded weboldal?

A vibe-coded weboldal olyan oldal vagy alkalmazás, amely elsősorban AI-eszközzel (Cursor, Lovable, Bolt, v0 és hasonlók) készült: az ember természetes nyelven adja meg a kéréseket, az AI pedig kódot generál. Jellemzően gyorsabban elkészül, mint egy egyedi weboldal, de rendszerezett audit nélkül gondjai lehetnek a sebességgel, a biztonsággal vagy a SEO-val.

Drágább az AI weboldal javítása, mint egy új weboldal?

A javítás általában olcsóbb: tapasztalataink alapján becslésünk szerint egy új weboldal árának 20-40%-a, ha a projekt alaparchitektúrája megállja a helyét. Új weboldalnak akkor van értelme, ha a vibe-coded projekt egyszerre több területen is elbukik, vagy ha lényegesen megváltoztak a fő üzleti követelmények. A konkrét összeget egy rövid konzultáció után pontosítjuk.

Mennyi ideig tart egy vibe-coded weboldal auditja?

Az alapvető biztonsági és teljesítményauditot (az ellenőrzőlista 1., 2. és 3. pontja) egy-két munkanap alatt elvégezzük. A SEO-struktúrát, a kódot és az akadálymentességet is magában foglaló átfogó audit három-öt munkanapig tart. Az eredmény a megállapítások priorizált listája, a javítás terjedelmének becslésével.

Kijavíthatom magam a vibe-coded weboldalt?

Igen, ha van technikai tudása. Az 1. (CWV), a 4. (SEO) és a 6. (akadálymentesség) pontot a legtöbb WordPress-adminisztrátor ingyenes eszközökkel (PageSpeed Insights, Search Console, Lighthouse) is elvégzi. A 3. (kódbiztonság) és az 5. (függőségek) pont programozói tapasztalatot vagy külső auditot igényel.

Biztonságos módja a vibe-coding a weboldalkészítésnek?

A vibe-coding hatékony módja a prototípusok és MVP-k készítésének. Valódi ügyfeleket és fizetéseket kezelő éles weboldalnál viszont elengedhetetlen a biztonsági audit: nem azért, mert az eszköz rossz, hanem mert az AI-generátor emberi ellenőrzés nélkül nem ismeri az Ön konkrét biztonsági követelményeit. A talált hibák általában nulláról való újraírás nélkül is javíthatók.