# Digiösvény WordPress weboldalak diagnosztikája, készítése, javítása és működtetése vállalkozásoknak – érthető scope-pal, mérési kontextussal és világos következő lépéssel. - Website: https://digiosveny.hu/de/ ## Kritikus PHP-biztonsági frissítés: teendők WordPress-weboldalakhoz - Link: https://digiosveny.hu/de/kritikus-php-biztonsagi-frissites-teendok-wordpress-weboldalakhoz/ - Veröffentlicht: 2026-10-22T14:21:52+02:00 - Autor: Márton A PHP biztonsági frissítéseit nem érdemes halogatni. Ha egy weboldal sérülékeny PHP-verziót használ, az növelheti a biztonsági kockázatot, és veszélyeztetheti a webhely megbízható működését. A WordPress-oldalak üzemeltetőinek ezért ellenőrizniük kell a tárhelyen futó PHP-verziót, majd biztonságosan megtervezniük a szükséges frissítést. ## Mit jelent a kritikus PHP-biztonsági kiadás? A PHP a WordPress működéséhez használt szerveroldali programozási nyelv. A PHP biztonsági kiadásai olyan hibákat javíthatnak, amelyek támadási lehetőséget teremthetnek az érintett rendszereken. A konkrét érintett verziókról és javításokról az elsődleges forrás ad tájékoztatást; a weboldal üzemeltetőjének ezt kell ellenőriznie, mielőtt frissítési döntést hoz. [Az eredeti WordPress-közlemény](https://wordpress.org/news/2026/10/critical-php-security-release/) a PHP biztonsági kiadásával kapcsolatos részletek kiindulópontja. A cikk nem helyettesíti a közleményben szereplő technikai információk ellenőrzését. ## Miért fontos ez egy WordPress-weboldalnál? A PHP-verzió nem önmagában működik. A WordPress-verzió, a bővítmények, a sablon és a tárhely beállításai együtt határozzák meg, hogy a webhely biztonságosan és megfelelően működik-e. Egy elavult vagy érintett PHP-verzió ezért karbantartási feladatot jelezhet. A frissítés azonban kompatibilitási problémát is okozhat, ha a weboldal valamelyik összetevője nem támogatja az újabb verziót. Az üzleti kockázat kétoldalú: a frissítés elmaradása biztonsági kitettséget hagyhat fenn, a nem ellenőrzött frissítés pedig működési hibát okozhat. A cél nem a vak frissítés, hanem az állapot felmérése és a változtatás ellenőrzött végrehajtása. ## Teendők PHP-frissítés előtt 1. **Ellenőrizze a jelenlegi PHP-verziót.** Nézze meg a tárhely kezelőfelületén vagy kérdezze meg a tárhelyszolgáltatót. Ne feltételezze, hogy a WordPress frissítése automatikusan frissíti a PHP-t is. 2. **Vesse össze a verziót az elsődleges közleménnyel.** Ellenőrizze, hogy az Ön által használt verzió érintett-e, és milyen javított verziót javasol a forrás. 3. **Vizsgálja meg a kompatibilitást.** Ellenőrizze a WordPress, a sablon és a bővítmények támogatását. Különösen figyeljen az egyedi fejlesztésekre és a régóta nem frissített összetevőkre. 4. **Készítsen biztonsági mentést.** A frissítés előtt gondoskodjon a weboldal és az adatbázis visszaállítható mentéséről. A mentés meglétét is ellenőrizze. 5. **Frissítsen ellenőrzött módon.** Ha rendelkezésre áll tesztkörnyezet, először ott próbálja ki a módosítást. Ezután ellenőrizze a fő oldalakat, az űrlapokat és a webhely fontos funkcióit. 6. **Kövesse a tárhelyszolgáltató útmutatását.** A PHP-verzió váltása a tárhely beállításaitól függhet. Ha nem biztos a teendőkben, kérjen technikai segítséget a szolgáltatótól vagy a weboldal karbantartójától. ## Frissítés után: mit érdemes ellenőrizni? * Betöltődnek-e a fontos oldalak és a WordPress adminisztrációs felülete? * Működnek-e az űrlapok, a keresés és az üzleti szempontból lényeges funkciók? * Megjelenik-e hibaüzenet, vagy tapasztalható-e váratlan működés? * A tárhely vagy a weboldal naplóiban látható-e új hiba? Ha hibát észlel, ne ismételje meg találomra a frissítést. Rögzítse a tapasztalt jelenséget, és kérje a tárhelyszolgáltató vagy a weboldal karbantartójának segítségét. ## Biztonsági frissítés mint rendszeres karbantartás A PHP-verzió ellenőrzése nem egyszeri feladat. A rendszeres karbantartás része a WordPress, a bővítmények, a sablon és a szerverkörnyezet állapotának áttekintése is. Egy átlátható frissítési folyamat segít időben felismerni a kockázatokat, miközben csökkenti a váratlan kompatibilitási hibák esélyét. **Következő lépés:** ha nem tudja, milyen PHP-verzió fut a weboldalán, vagy bizonytalan a frissítés hatásában, kérjen [ingyenes weboldalauditot](https://digiosveny.hu/ingyenes-weboldalaudit/). Az ellenőrzés segíthet tisztázni a technikai állapotot és a következő vizsgálati lépést. ## PHP-sebezhetőségek: miért okozhatnak webhelykiesést, és mit tehetnek az üzemeltetők? - Link: https://digiosveny.hu/de/php-sebezhetosegek-miert-okozhatnak-webhelykiesest-es-mit-tehetnek-az-uzemeltetok/ - Veröffentlicht: 2026-10-22T14:19:04+02:00 - Autor: Márton **Összefoglaló:** A PHP-t érintő kritikus sebezhetőségek veszélyeztethetik a sérülékeny szervereket, és webhelykiesést, jogosulatlan kódfuttatást vagy adatvesztést okozhatnak. A cikkben szereplő eredeti beszámoló szerint a hibák széles körben használt PHP- verziókat érintettek, és már aktív kihasználásról is érkezett jelentés. A webhelytulajdonosok első feladata a tényleges PHP-verzió és a tárhelyszolgáltató által kiadott biztonsági frissítések ellenőrzése. ## Miért jelenthetnek a PHP-sebezhetőségek széles körű kockázatot? A PHP számos webhely és tartalomkezelő rendszer működésében vesz részt. A cikkben említett rendszerek között szerepel a WordPress, a Drupal, a Magento és a Joomla. Ha a szerver ezeket a hibás PHP-verziókat futtatja, a támadók bizonyos körülmények között jogosulatlan kódot hajthatnak végre rajta. Az eredeti beszámoló szerint a hibák kihasználása már megkezdődött. Ezért nem elegendő kizárólag a webhely látható működését ellenőrizni. A frissítési állapotot a tárhelyen futó PHP-verzió alapján kell megállapítani. Egy webhely akkor is érintett lehet, ha a látogatók számára hibátlanul jelenik meg. ## Mit állított a beszámoló a hibákról? A cikk két kritikus PHP-sebezhetőséget nevezett meg: **CVE-2026-109618** és **CVE- 2026-109619**. A forrásszöveg szerint a hibák a PHP 5.4-es vagy újabb verzióit futtató webszervereket érintették. A javított verzióként a cikk a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 kiadásokat sorolta fel. **Fontos:** ezek a verziószámok és állítások az átadott eredeti cikkből származnak. A frissítés előtt ellenőrizd az aktuális PHP biztonsági közleményeket és a tárhelyszolgáltatód tájékoztatását. A szolgáltató saját, visszaportolt javításokat tartalmazó csomagot is biztosíthat, ezért a verziószám önmagában nem minden esetben mutatja meg a javítás állapotát. ## Milyen következménye lehet egy sikeres támadásnak? A cikk szerint a támadók a hibák kihasználásával távoli kódfuttatást érhetnek el. Ez lehetőséget adhat arra, hogy jogosulatlan műveleteket végezzenek az érintett szerveren. A beszámoló a szolgáltatásmegtagadást és az adatok veszélyeztetését is a lehetséges következmények között említi. A Wiz kutatói arra figyelmeztettek, hogy a támadók webes hátsó ajtókat, más néven webshell-eket telepíthetnek. Ezek olyan eszközök lehetnek, amelyek távoli hozzáférést biztosítanak a feltört webhelyhez. Egy ilyen behatolás után a puszta PHP-frissítés nem feltétlenül elegendő: az üzemeltetőnek azt is vizsgálnia kell, történt-e jogosulatlan módosítás vagy adat-hozzáférés. ## Miért lehet nehéz gyorsan minden érintett rendszert frissíteni? A PHP sokféle tárhelyen és webalkalmazásban működik. A cikkben idézett Censys-vizsgálat körülbelül 2,58 millió internetes gazdagépet és 54,9 millió PHP-t használó webes tulajdont azonosított. Ezek a számok az eredeti beszámolóban szerepelnek; nem tekinthetők automatikusan a jelenlegi érintett rendszerek számának. A frissítések telepítését az is nehezítheti, hogy a PHP-verziót nem mindig a webhely tulajdonosa kezeli közvetlenül. Megosztott tárhelyen, felhőszolgáltatásban vagy menedzselt WordPress-csomagban a szolgáltató végezheti el a frissítést. Egyéni szerveren viszont az üzemeltetőnek kell ellenőriznie a csomagokat, a kompatibilitást és a telepítés eredményét. A beszámoló a helyzetet a Log4Shellhez hasonlította, mivel mindkét esetben széles körben használt infrastruktúra-szoftverről és sok, különböző szervezet által kezelt rendszerről van szó. Ez a párhuzam a kitettség kezelésének nehézségére utal. Nem jelenti azt, hogy a két sebezhetőség technikailag azonos lenne. ## Mit tegyen most a webhely tulajdonosa? 1. **Azonosítsd a PHP-verziót.** Ellenőrizd a tárhely kezelőfelületén, a szerver beállításaiban vagy a szolgáltató dokumentációjában, melyik PHP-verzió fut az érintett webhelyen. 2. **Kérdezd meg a tárhelyszolgáltatót.** Ha nem te kezeled a szervert, ellenőrizd, hogy a szolgáltató telepítette-e a megfelelő biztonsági javítást. Kérj egyértelmű tájékoztatást arról, melyik csomag vagy verzió tartalmazza a javítást. 3. **Telepítsd a támogatott frissítést.** Saját szerver esetén a PHP-csomagokat a használt operációs rendszer és a PHP hivatalos biztonsági tájékoztatása alapján frissítsd. Ne válassz verziót kizárólag egy régebbi cikk alapján. 4. **Ellenőrizd a webhely működését.** A frissítés után vizsgáld meg a fontos oldalakat, űrlapokat és integrációkat. A kompatibilitási problémák egyes funkciókat érinthetnek akkor is, ha a webhely kezdőlapja betöltődik. 5. **Vizsgáld meg a biztonsági jeleket.** Ha a frissítés előtt fennállhatott a kitettség, ellenőrizd a szervernaplókat és a fájlokat. Gyanús módosítás vagy jogosulatlan hozzáférés esetén kérj biztonsági szakértői segítséget. Ne törölj naplókat, és ne állíts vissza mentést a helyzet felmérése nélkül. Ezek a lépések eltüntethetik a vizsgálathoz szükséges információkat, vagy visszahozhatnak egy korábban eltávolított hibát. ## A webalkalmazás-tűzfal hasznos, de nem helyettesíti a javítást Az eredeti cikk szerint a Cloudflare szabályokat vezetett be a támadások mérséklésére. A webalkalmazás-tűzfal segíthet kiszűrni bizonyos káros kéréseket, de a védelem konfigurációtól és a támadási módszertől függ. Nem szünteti meg a szerver sérülékenységét. A tartós védelemhez a javított PHP-csomag telepítése és annak ellenőrzése szükséges. A tűzfalszabály kiegészítő védelmi rétegként működik. Ne kezeld a frissítés helyettesítőjeként. ## Mit jelent ez a vállalkozások webhelyeinek üzemeltetésében? Egy PHP-sebezhetőség nem csupán fejlesztői kérdés. Ha a webhely üzleti megkereséseket, rendeléseket vagy ügyféladatokat kezel, a kiesés és a jogosulatlan hozzáférés az ügyfélélményt és a működést is érintheti. A tényleges kockázatot azonban csak a használt PHP-verzió, a tárhely beállításai és a megtett javítások ismeretében lehet megítélni. Érdemes ezért egyértelmű felelősségi rendet kialakítani: ki ellenőrzi a szolgáltatói értesítéseket, ki telepíti a frissítéseket, és ki vizsgálja meg a webhelyet egy biztonsági esemény után. A rendszeres frissítési folyamat csökkenti annak esélyét, hogy egy kritikus javítás észrevétlen maradjon. ## Összegzés A PHP széles körű használata miatt egy kritikus sebezhetőség sokféle webhelyet érinthet. Az eredeti beszámoló aktív kihasználásról és sürgős biztonsági frissítésekről írt. A webhely tulajdonosának ezért ellenőriznie kell a futó PHP-verziót, egyeztetnie kell a tárhelyszolgáltatóval, majd meg kell győződnie a javítás sikeres telepítéséről. Ha a webhely korábban sérülékeny verziót használt, a frissítés mellett a jogosulatlan módosítások és hozzáférések ellenőrzése is indokolt lehet. Bizonytalan vagy gyanús esetben ne találgatás alapján avatkozz be. Kérj segítséget a tárhelyszolgáltatótól vagy megfelelő biztonsági szakértőtől. ## Közvetett promptinjekció elleni védelem: így fejleszti folyamatosan a Google Workspace a Gemini biztonságát - Link: https://digiosveny.hu/de/kozvetett-promptinjekcio-elleni-vedelem-igy-fejleszti-folyamatosan-a-google-workspace-a-gemini-biztonsagat/ - Veröffentlicht: 2026-10-22T03:06:41+02:00 - Autor: Márton **Röviden:** A közvetett promptinjekció olyan támadási forma, amely rosszindulatú utasításokat rejt el az AI által feldolgozott tartalomban. A felhasználó ezeket nem feltétlenül adja meg közvetlenül. A Google Workspace védelmi megközelítése ezért nem egyetlen szűrőre épül: új támadások felderítését, tesztelését, szintetikus adatok előállítását, többféle védelmi réteg finomítását és ismételt mérést kapcsol össze. **Írta: Adam Gavish, a Google GenAI biztonsági csapatából.** Az AI-asszisztens nemcsak a felhasználó kérését dolgozhatja fel. Hozzáférhet e-mailekhez, dokumentumokhoz, webes tartalmakhoz vagy más, a feladat szempontjából releváns adatokhoz is. Ez hasznosabbá teszi az eszközt. Egyúttal új támadási felületet hoz létre. A közvetett promptinjekció (indirect prompt injection, IPI) során a támadó olyan tartalomba rejt utasításokat, amelyet az AI később feldolgoz. A cél az, hogy a modell eltérjen a felhasználó eredeti szándékától. Ehhez a felhasználónak nem kell közvetlenül megadnia a rosszindulatú parancsot. Ez nem egyszeri hibajavítási feladat. Az új modellek, az ügynöki automatizálás és a változatos adatforrások folyamatosan módosítják a támadási környezetet. A védelemnek ezért együtt kell fejlődnie a fenyegetésekkel. A Google korábbi, réteges védelemről szóló ismertetője bemutatta az IPI elleni védekezés alapelveit. Ez a cikk a következő lépést részletezi: hogyan kapcsolódik össze a támadások felderítése, a védelem fejlesztése és a hatékonyság ellenőrzése a Workspace Gemini-funkcióiban. ## A védekezés első lépése: az új támadások korai felismerése A hatékony védelemhez először meg kell érteni, hogyan változnak a támadások. A Google többféle forrásból gyűjt új mintákat, majd elemzi, reprodukálja és rendszerezi azokat. A cél nem pusztán egy-egy ismert eset kezelése. A csapatnak azt is fel kell tárnia, milyen más változatok és támadási útvonalak következhetnek belőlük. ### Emberi red teaming A red teaming során szakemberek ellenséges helyzeteket szimulálnak. Valós felhasználási módokhoz igazodó támadási kísérletekkel keresik a rendszer gyenge pontjait. Az eredményeket a termékcsapatokkal együtt vizsgálják, hogy az azonosított problémákból javítás és új teszteset szülessen. Az emberi tesztelés különösen hasznos lehet olyan összetett helyzetekben, ahol a támadás több lépésből vagy különböző adatforrások kombinációjából áll. A szakértő nemcsak azt figyeli, hogy egyetlen rosszindulatú utasítás átjut-e a védelmen. Azt is vizsgálja, hogyan értelmezi a rendszer a teljes feladatot. ### Automatizált red teaming Az automatizált tesztelés gépi tanulásra épülő keretrendszerekkel nagy mennyiségű támadási változatot állíthat elő és próbálhat ki. A rendszer iteratívan módosítja a teszteseteket. Így olyan kombinációk és szélső esetek is vizsgálhatók, amelyeket a kizárólag kézi tesztelés nehezebben fedne le. Ez a módszer segít feltérképezni az összetett támadási útvonalakat, és ellenőrizni, hogy a védelmi intézkedések különböző körülmények között is működnek-e. Az automatizálás nem váltja ki az emberi szakértelmet. Kiterjeszti a tesztelés lehetséges terjedelmét. ### Külső biztonsági kutatók és nyilvános támadási minták A Google AI Vulnerability Rewards Program (VRP) lehetőséget ad külső biztonsági kutatóknak arra, hogy jelentést tegyenek az általuk felfedezett, AI-rendszereket érintő sérülékenységekről. A Google a közreműködő kutatásokat a program keretében elismeri és jutalmazza. A vállalat emellett meghívásos, élő hackereseményeket is szervezhet, ahol a résztvevők kiadás előtti funkciókat vizsgálhatnak. A külső kutatók eltérő nézőpontokat és tesztelési módszereket hoznak. Ha egy bejelentett problémát reprodukálni lehet, a csapat értékelheti a hatását, kijelölheti a felelősöket, majd javítást készíthet. A nyilvánosan megosztott támadási kutatások szintén fontos jelzések. A Google nyílt forrású információkat figyel, például közösségi bejegyzéseket, sajtóközleményeket és szakmai blogokat. Az így azonosított mintákat elemzi, reprodukálja és belső nyilvántartásba veszi. ### A sérülékenységek katalogizálása Az újonnan felfedezett esetek elemzésen mennek keresztül. A folyamat része a reprodukálás, az ismétlődések ellenőrzése, a támadási technikák és lehetséges hatások besorolása, valamint a megfelelő felelősök kijelölése. A rendezett katalógus segít összekapcsolni a különböző forrásból érkező jelzéseket. Így a csapat nemcsak az egyedi hibákat kezeli, hanem a visszatérő mintákat is felismerheti. Ez teremti meg a következő lépés, a célzott tesztadatok előállításának alapját. ## Szintetikus adatok: több támadási változat, szélesebb tesztlefedettség A felderített támadási mintákból a Google a Simula segítségével szintetikus adatokat állít elő. Ezek a példák az ismert támadásokat különböző változatokkal bővítik. A cél az, hogy a védekezés ne csak az eredeti mintára reagáljon, hanem annak módosított formáit is kezelni tudja. A szintetikus adatok a védelmi modellek értékelését és tanítását is támogatják. A közölt beszámoló szerint a munkafolyamat felgyorsítása 75%-kal növelte a szintetikus adatgenerálást. Ez a vállalat által ismertetett folyamatra vonatkozó adat; önmagában nem jelenti azt, hogy a támadások száma vagy a kockázat ugyanilyen arányban csökkent. A nagyobb adatmennyiség csak akkor hasznos, ha a tesztek következetesek. Ezért a generált példák a tanítási és az ellenőrzési folyamatokat is támogatják. A cél a megismételhető értékelés, a változatos támadási lefedettség és a védelmi teljesítmény következetes mérése. ## Több védelmi réteg, eltérő frissítési sebesség A különböző védelmi mechanizmusok más-más módon reagálnak az új fenyegetésekre. Egy szabályalapú konfiguráció gyorsan módosítható. Egy gépi tanulási modell frissítése viszont új adatkészleteket, tanítást és ellenőrzést igényelhet. A Google megközelítése ezért több védelmi réteget kombinál. ### Determinisztikus védelem A determinisztikus védelmek előre meghatározott szabályok alapján működnek. A Google példaként említi a felhasználói megerősítést, az URL-ek tisztítását és az eszközláncolásra vonatkozó házirendeket. Ezeket központi Policy Engine szabályozza. Az ilyen védelem előnye, hogy bizonyos fenyegetésekre konfigurációs módosítással gyorsan lehet reagálni. Egy célzott szabály vagy javítás hamarabb bevezethető, mint egy teljes modellfrissítés. A szabályalapú megközelítés ugyanakkor nem helyettesíti azokat a védelmeket, amelyeknek változatosabb vagy kevésbé kiszámítható tartalmakat kell értelmezniük. ### Gépi tanulásra épülő védelem Az új támadási példákból összeállított adatok felhasználhatók a gépi tanulási védelmek frissítéséhez. A tanítási és az ellenőrzési példákat külön kezelik, hogy a teljesítményt olyan eseteken is lehessen mérni, amelyeket a modell nem használt fel tanulás közben. Ez a szétválasztás segít elkerülni, hogy az értékelés pusztán azt mutassa: a modell felismeri a már látott példákat. A rögzített adat- és tesztelési folyamat emellett megismételhető összehasonlítást tesz lehetővé a különböző modellverziók között. ### LLM-alapú védelem A Google az LLM-alapú védelmek rendszerutasításait is finomítja. Az új szintetikus példákon iteratívan teszteli a módosításokat, és a meghatározott védelmi mérőszámok alapján értékeli az eredményeket. Ennek célja, hogy a modell felismerje a feldolgozott adatokba ágyazott rosszindulatú utasításokat, és ne kövesse azokat a felhasználó eredeti kérésével szemben. A rendszerutasítások finomhangolása önmagában nem teljes védelem. A többi technikai és működési réteggel együtt ad védelmi értéket. ### A Gemini modell megerősítése Az alkalmazás- és rendszerszintű korlátok mellett a Google a modell belső ellenálló képességét is fejleszti. A közölt megközelítés szerint a friss támadási minták és szintetikus adatkészletek segítségével azt gyakorolják, hogy a Gemini felismerje és figyelmen kívül hagyja a tartalomba rejtett káros utasításokat. A cél kettős: a modell tartsa tiszteletben a felhasználó szándékát, és közben ne kövesse a feldolgozott adatokban elhelyezett ellenséges parancsokat. A Google beszámolója szerint a modellkeményítés javította a beágyazott utasítások felismerését, és csökkentette a támadások sikerességét úgy, hogy a rutinfeladatok hatékonysága ne sérüljön. ## A védelem hatékonyságának mérése Egy védelmi módosítás önmagában nem bizonyítja, hogy a rendszer biztonságosabb lett. A változtatás hatását tesztelni kell. A Google a szintetikus támadási adatokkal több Workspace-funkciót, köztük a Gmailt és a Dokumentumokat vizsgálja. A végpontok közötti értékelés során ugyanazokat a támadási helyzeteket a védelem bekapcsolásával és anélkül is lefuttatják. Az összehasonlítás megmutatja, hogyan változnak a kiválasztott mérőszámok az adott módosítás után. Ez segít ellenőrizni egy frissített gépi tanulási modell vagy egy finomított LLM-rendszerutasítás hatását. A tesztelés standardizált eszközkészletet használ, hogy az eredmények összevethetők legyenek. A megbízható értékeléshez a támadási példák minősége és a tesztelési folyamat következetessége egyaránt számít. A mérés így nem egyszeri jóváhagyás, hanem a folyamatos fejlesztési ciklus része. ## Mit jelent a folyamatos védelem a Workspace-felhasználóknak? A közvetett promptinjekció összetett probléma. Egyetlen szűrő vagy modellfrissítés nem zárja le véglegesen. A Google által ismertetett folyamat több egymásra épülő tevékenységet kapcsol össze: * **Felderítés:** emberi és automatizált tesztelés, külső kutatói jelzések, valamint nyilvános támadási minták elemzése. * **Rendszerezés:** az esetek reprodukálása, besorolása és a felelős csapatokhoz rendelése. * **Adatbővítés:** szintetikus támadási változatok előállítása a tesztelési lefedettség növelésére. * **Védelemfejlesztés:** determinisztikus szabályok, gépi tanulási modellek, LLM- alapú védelmek és modellkeményítés alkalmazása. * **Értékelés:** a módosítások összehasonlító, végpontok közötti tesztelése. Ez a működésmód nem jelent abszolút kockázatmentességet. Azt mutatja meg, hogyan lehet a változó fenyegetésekre ismételhető, mérhető fejlesztési ciklussal reagálni. A felhasználók számára a lényeg az, hogy az AI által feldolgozott tartalmat és a modellnek adott közvetlen utasításokat külön bizalmi kategóriaként kell kezelni. ## Összegzés A Google Workspace közvetett promptinjekció elleni megközelítése folyamatos munkafolyamatra épül. A csapat új támadásokat keres, rendszerezi és változatokká bővíti azokat, majd többféle védelmi réteget fejleszt. Végül összehasonlító tesztekkel ellenőrzi a változtatások hatását. A módszer legfontosabb tanulsága, hogy az AI-biztonság nem egyetlen modell képességén múlik. A felderítés, a szabályalapú kontrollok, a tanítóadatok, a modellviselkedés és a mérés együtt alkotnak védelmi rendszert. Mivel a támadási technikák változnak, ezt a rendszert is folyamatosan felül kell vizsgálni. _A cikk a Google által ismertetett biztonsági megközelítést foglalja össze és szerkesztői szempontból értelmezi._ ## Ingyenes vagy fizetős WordPress-bővítmény? Így válasszon biztonságosan - Link: https://digiosveny.hu/de/ingyenes-vagy-fizetos-wordpress-bovitmeny-igy-valasszon-biztonsagosan/ - Veröffentlicht: 2026-10-20T05:55:12+02:00 - Autor: Márton A WordPress-bővítményekkel új funkciókat adhat webhelyéhez anélkül, hogy mindent egyedileg kellene fejlesztenie. SEO-eszközre, űrlapra, biztonsági megoldásra, teljesítményjavításra vagy webáruház-funkcióra van szüksége? Sok esetben talál ingyenes és fizetős lehetőséget is. A döntés azonban nem pusztán arról szól, hogy költsön-e egy bővítményre. A fontos kérdés az, hogy az adott eszköz megfelel-e a webhelye céljának, rendszeresen karbantartják- e, és milyen támogatást kap hozzá. Egy ingyenes bővítmény is lehet megfelelő. Egy fizetős változat sem automatikusan jobb. ## Mit jelent az ingyenes és a fizetős WordPress-bővítmény? Az ingyenes bővítményeket jellemzően díj nélkül telepítheti. Egyes fejlesztők korlátozott funkciókat kínálnak ingyen, majd fizetős csomaggal teszik elérhetővé a bővített lehetőségeket. Más bővítmények ingyenes változata önmagában is alkalmas lehet egy egyszerű feladatra. A fizetős bővítményért általában licencdíjat vagy előfizetési díjat kell fizetni. Cserébe a fejlesztő további funkciókat, frissítéseket vagy ügyféltámogatást kínálhat. Ezek pontos tartalma bővítményenként és csomagonként eltér. Vásárlás előtt ellenőrizze, mit tartalmaz az adott licenc, és milyen feltételekkel újítható meg. ## Mikor lehet elegendő az ingyenes változat? Az ingyenes bővítmény jó választás lehet, ha egyszerű, jól körülhatárolt feladatot kell megoldania. Például egy alapvető kapcsolatfelvételi űrlaphoz vagy egy kisebb webhely egyszerű funkciójához nincs feltétlenül szükség prémium csomagra. Az ingyenes verzió akkor is hasznos lehet, ha először szeretné kipróbálni az eszközt. Tesztelés közben ellenőrizheti, hogy illeszkedik-e a munkafolyamatához, és nem okoz- e problémát a webhely többi elemével. A próba azonban nem helyettesíti a karbantartás és a kompatibilitás ellenőrzését. ### Ellenőrizze a bővítmény állapotát A díjmentesség önmagában nem jelent kockázatot. A gondot az elhanyagolt, nem frissített vagy nem megfelelően dokumentált bővítmény okozhatja. Telepítés előtt nézze meg, mikor frissítették utoljára, milyen WordPress-verzióval kompatibilis, és milyen visszajelzéseket hagytak a felhasználók. * **Frissítések:** ellenőrizze, hogy a fejlesztő kiad-e rendszeres javításokat. * **Kompatibilitás:** nézze meg, hogy a bővítmény illeszkedik-e a webhelye jelenlegi környezetéhez. * **Dokumentáció:** keressen telepítési és használati útmutatót. * **Funkciók:** telepítés előtt tisztázza, hogy az ingyenes változat valóban lefedi- e az igényeit. ## Mikor indokolt a fizetős bővítmény? A fizetős változat akkor lehet indokolt, ha olyan funkcióra van szüksége, amelyet az ingyenes verzió nem tartalmaz. Ilyen lehet például egy összetettebb munkafolyamat, több beállítási lehetőség vagy egy üzletileg fontos integráció. A fizetős csomag akkor is értéket adhat, ha az ügyféltámogatás és a frissítések feltételei megfelelnek az elvárásainak. Ne a funkciólista hossza alapján döntsön. Először írja le, milyen problémát kell megoldania a bővítménynek. Ezután ellenőrizze, hogy a fizetős funkció valóban szükséges- e, és hogyan illeszkedik a webhely jelenlegi rendszeréhez. Ha csak egyetlen, ritkán használt lehetőség miatt fizetne, mérlegelje, hogy az arányban áll-e a költséggel. ## A döntés előtt vizsgálja meg a teljes működési költséget A bővítmény ára csak egy szempont. A telepítés, a beállítás, a frissítések követése és az esetleges hibák kezelése szintén időt igényelhet. Egy ingyenes eszköz sem feltétlenül költségmentes, ha sok kézi munkát vagy külön fejlesztést kíván. Ugyanakkor a fizetős licenc sem garantálja, hogy a bővítmény minden helyzetben megfelelő lesz. Értékelje a bővítményt a webhely egészének részeként. Nézze meg, hogy a funkció nem érhető-e el már egy meglévő eszközben. Több, egymást átfedő bővítmény növelheti a karbantartási terhet, és megnehezítheti a hibák okának feltárását. ## Telepítés előtt kövesse ezt az ellenőrzőlistát 1. **Határozza meg a feladatot.** Fogalmazza meg pontosan, milyen hiányt kell megszüntetnie a bővítménynek. 2. **Hasonlítsa össze a szükséges funkciókat.** Ne fizessen olyan lehetőségért, amelyre nincs szüksége. 3. **Vizsgálja meg a fejlesztő és a bővítmény adatait.** Ellenőrizze a frissítéseket, a dokumentációt és a kompatibilitási információkat. 4. **Olvassa el a licenc feltételeit.** Tisztázza a díjfizetés, a megújítás, a támogatás és a frissítések részleteit. 5. **Tesztelje biztonságosan.** Jelentősebb változtatás előtt készítsen biztonsági mentést, és lehetőség szerint tesztkörnyezetben próbálja ki a bővítményt. 6. **Ellenőrizze a működést.** Telepítés után nézze meg, hogy a webhely fontos funkciói továbbra is megfelelően működnek-e. ## Összegzés: ne az árcédula, hanem az illeszkedés döntsön Az ingyenes WordPress-bővítmény megfelelő lehet egyszerű, korlátozott igényekhez. A fizetős változat akkor éri meg, ha szüksége van a többletfunkciókra, és a licenc feltételei, a támogatás, valamint a frissítések megfelelnek a webhelye működésének. Választás előtt ellenőrizze a bővítmény állapotát, a szükséges funkciókat és a rendszerrel való kompatibilitást. Ha meglévő webhelyén szeretné feltárni a technikai vagy működési problémákat, kérjen [ingyenes weboldalauditot](https://digiosveny.hu/ingyenes-weboldalaudit). ## Yoast SEO 28.7: AI-alapú metaadat-frissítés és az elavult kód eltávolítása - Link: https://digiosveny.hu/de/yoast-seo-28-7-ai-alapu-metaadat-frissites-es-az-elavult-kod-eltavolitasa/ - Veröffentlicht: 2026-10-20T05:54:32+02:00 - Autor: Márton A Yoast SEO 28.7 két területen hoz változást: bővíti az AI-eszközökkel használható Yoast SEO Abilities lehetőségeit, és eltávolítja a korábbi verziókban már elavult kódot. Az első fejlesztés egyszerűbbé teszi a bejegyzések keresési és közösségi megjelenéséhez tartozó metaadatainak frissítését. A második elsősorban azokat érintheti, akik saját témát vagy bővítményt fejlesztenek, illetve egyedi kódot futtatnak a Yoast SEO mellett. Ha csak a Yoast SEO szokásos funkcióit használja, valószínűleg nem kell külön teendővel számolnia. Egyedi integráció esetén viszont érdemes ellenőrizni, hogy a kód hivatkozik- e az eltávolított elemek valamelyikére. ## SEO-metaadatok frissítése AI-eszközből A Yoast SEO Abilities lehetővé teszi, hogy kompatibilis AI-eszköz segítségével hozzáférjen bizonyos SEO-adatokhoz és műveletekhez. A korábbi fejlesztések már támogatták a SEO-, olvashatósági és nyelvi pontszámok ellenőrzését, valamint egyes bejegyzésadatok lekérdezését és technikai beállításainak módosítását. A 28.7-es verzió tovább bővíti ezt a lehetőséget: mostantól a keresési találatokban és a közösségi megosztásokban megjelenő címek és leírások is frissíthetők. A `yoast-seo/update-post-seo-data` képesség hat további mezőt kezel: * **SEO-cím**, amely a keresési találatokban jelenhet meg. * **Meta leírás**, amely röviden összefoglalhatja az oldal tartalmát a keresési találatokban. * **Open Graph-cím és -leírás**, amelyet például a Facebook vagy a LinkedIn használhat a megosztott tartalom előnézetében. * **X-cím és -leírás**, amely az X-en megjelenő megosztási előnézethez tartozik. ### Gyakorlati példa: terméknév-váltás Tegyük fel, hogy egy vállalkozás átnevez egy terméket, de a hozzá tartozó SEO-cím és közösségi előnézet még a korábbi nevet tartalmazza. Egy kompatibilis AI-eszköz lekérdezheti a bejegyzés SEO-adatait, így a módosítás előtt ellenőrizhető, mely mezők szorulnak frissítésre. Ezután ugyanabban a munkafolyamatban átírhatók az elavult címek és leírások. Az AI-eszköz ebben a folyamatban a módosítás végrehajtását segíti. A tartalom és a metaadatok pontosságát továbbra is érdemes embernek ellenőriznie. Különösen fontos ez akkor, ha a terméknév, az ajánlat vagy az oldal tartalma több helyen is megjelenik. ### Mi marad változatlan? A fókusz kulcskifejezés továbbra is csak olvasható mező. Az AI-eszköz nem állíthatja be helyette; ezt a felhasználó kezeli. A hozzáférés a WordPress beépített jogosultsági ellenőrzéseit követi, ezért az elérhető műveletek a felhasználói jogosultságoktól is függenek. A Yoast SEO Abilities használatához kompatibilis AI-eszközre és a szükséges WordPress- kapcsolatra van szükség. Az új mezők a 28.7-es verzió telepítése után érhetők el a már beállított képességeket használóknak. Az első beállításhoz a Yoast fejlesztői dokumentációja ismerteti az LLM és a WordPress MCP Adapter összekapcsolását, valamint a képességek listáját és sémáit. ## Az elavult kód éves eltávolítása A Yoast SEO 28.7 eltávolítja a 26.1-es vagy korábbi verziókban elavultnak jelölt kód egy részét. Az érintett elemekről a fejlesztők már korábban figyelmeztetést kaphattak. Ezért a szokásos bővítményhasználat mellett sok webhelyen nem jelentkezik látható változás. A kockázat főként azokat a webhelyeket érinti, amelyek témája, bővítménye vagy egyedi kódja továbbra is ezekre az elemekre támaszkodik. ### Eltávolított vagy módosított elemek * `WPSEO_Frontend` osztály: a Yoast SEO 14.0-ban már elavultként jelölték, a 28.7- es verzió pedig eltávolítja. * `wpseo_opengraph` és `wpseo_twitter` műveletek: ezek helyett a `wpseo_frontend_presenters` használata javasolt. A régi műveletekre hivatkozó kód továbbra is figyelmeztetést válthat ki. * `wpseo_robots_array` szűrő: a szűrőnek tömböt kell visszaadnia. Más típusú visszatérési érték végzetes hibát okozhat. * `WPSEO_Database_Proxy::upsert()` metódus: a `$where` és a `$format` argumentum elavult. A közlemény szerint ezeket egy későbbi éves tisztítás során távolítják el. ### Mit ellenőrizzen frissítés előtt? Ha egyedi fejlesztésű témát vagy bővítményt használ, keresse meg a fenti osztályokra, műveletekre, szűrőkre és argumentumokra történő hivatkozásokat. Tesztelje a módosításokat elkülönített tesztkörnyezetben, mielőtt éles webhelyen frissít. Ha nincs hozzáférése a kódhoz, kérje meg a fejlesztőt vagy a webhely karbantartóját az ellenőrzésre. A Yoast SEO közleménye az eltávolított elemek teljes listáját is tartalmazza. Egyedi integráció karbantartásakor ezt a listát és a fejlesztői dokumentációt vegye alapul, ne feltételezze, hogy minden régi hivatkozás azonos módon viselkedik. ## Mit jelent a frissítés a webhely üzemeltetőinek? A 28.7-es kiadás egyszerre kínál kényelmi fejlesztést és karbantartási változást. Az AI-képességek megkönnyíthetik a metaadatok frissítését egy támogatott munkafolyamatban. Az elavult kód eltávolítása pedig tisztább alapot ad a bővítmény további fejlesztéséhez, de felszínre hozhat olyan egyedi integrációkat, amelyek már nem támogatott elemekre épülnek. A frissítés előtt ezért két kérdést érdemes tisztázni: használ-e a webhely Yoast SEO Abilities-kompatibilis AI-eszközt, és fut-e rajta olyan egyedi kód, amely a felsorolt régi elemekre hivatkozik? Az első kérdés a funkció használatáról szól. A második a kompatibilitásról és a frissítés előtti tesztelésről. ## Digiösvény szakmai szempont A bővítményfrissítések önmagukban nem garantálnak jobb keresési láthatóságot. A metaadatoknak pontosan kell tükrözniük az oldal tartalmát, az egyedi integrációknak pedig együtt kell működniük a telepített szoftververziókkal. Érdemes ezért a frissítést ellenőrzött folyamatként kezelni: vizsgálja meg a változásokat, tesztelje az érintett funkciókat, majd ellenőrizze az oldal működését a telepítés után. **Forrás:** a Yoast SEO 28.7 kiadásáról szóló eredeti közlemény. A cikk a megadott forrásanyag alapján készült. ## Hogyan mérhetik kisvállalati döntéshozók, hogy egy lassú Alap üzleti weboldal rontja az ügyfélszerzést? - Link: https://digiosveny.hu/de/hogyan-merhetik-kisvallalati-donteshozok-hogy-egy-lassu-alap-uzleti-weboldal-rontja-az-ugyfelszerzest/ - Veröffentlicht: 2026-10-20T05:53:11+02:00 - Autor: Márton Rövid bevezetés   A lassú, akadozó vállalati weboldal nemcsak bosszantó a látogatók számára — üzleti kockázat is. Ennek felmérése és bizonyítása viszont mérhető: a döntéshozóknak nem elég „szubjektíven lassúnak” érezni az oldalt, hanem konkrét mérőszámokra, valós felhasználói adatokra és üzleti eseményekre kell támaszkodni. Az alábbi cikk a kisvállalati döntéshozók számára mutatja meg, hogyan állítsanak fel egyszerű, megismételhető méréseket, milyen eszközöket és mutatókat használjanak, és hogyan kössék össze a teljesítményt az ügyfélszerzés üzleti eredményeivel.   Bizonyított tények (kulcsforrások röviden)   - Core Web Vitals — LCP (Largest Contentful Paint), INP (Interaction to Next Paint) és CLS (Cumulative Layout Shift) a Google által javasolt, valós felhasználói élményt leíró fő metrikák. Ajánlott célok: LCP ≤ 2.5 s, INP < 200 ms, CLS < 0.1. (developers.google.com)   - A „Page Experience” (amelybe a Core Web Vitals beletartozik) egyike a Google által figyelembe vett rangsorolási jeleknek; azonban nem ez az egyetlen döntő tényező. (developers.google.com)   - A PageSpeed Insights és a Lighthouse eszközök egyszerre adnak labor (szimulált) és field (valós felhasználói) adatokat; a valós felhasználói adatok forrása a Chrome User Experience Report (CrUX). (developers.google.com)   - A Google Search Console Core Web Vitals riportja segít azonosítani, mely oldalak nem teljesítik a CWV célokat, és nyomon követni a javításokat. (support.google. com)   - Részletes, technikai vizsgálathoz (vízesés-diagramok, filmstrip, szerverválasz- idők) gyakran használják a WebPageTest-et és a Lighthouse-t. (product.webpagetest. org)     Probléma és tünetek   Mikor gyanakodjunk, hogy a weboldal lassúsága rontja az ügyfélszerzést?   - Csökkenő konverzió (például kevesebb űrlapbeküldés, ajánlatkérés, vásárlás) anélkül, hogy a forgalom jelentősen változott.   - Növekvő visszafordulási arány (bounce rate) vagy rövidebb munkamenet-idő ( session duration).   - Több „félbehagyott” checkout vagy kosárfolyamat, illetve alacsony kattintási arány a hirdetésekről érkező forgalomnál.   - Szubjektív panaszok ügyfélszolgálattól: „az oldal nagyon lassú mobilon”.     Ezek tünetek — nem bizonyítékok. A bizonyíték felépítése az események és a webteljesítmény összekapcsolása: például A/B vagy időalapú vizsgálat, amikor egy optimalizáció ( pl. képoptimalizálás) után mérjük a konverzió változását.   Mit és hogyan érdemes mérni   1. a. Alapmérések — felhasználói élmény (field) és labor     - Field (valós felhasználói) mutatók: Core Web Vitals (LCP, INP, CLS) és FCP/ FID/TTFB azoknál az eszközöknél, amelyekből CrUX adatok gyűlnek. Ezek megmutatják, amit a látogatók ténylegesen tapasztalnak. Ellenőrizhető eszközök: PageSpeed Insights (CrUX + Lighthouse), Google Search Console Core Web Vitals. (developers. google.com)   - Lab (szimulált) mérések: Lighthouse és WebPageTest használata részletes diagnosztikához( waterfall, asset list, filmstrip). Lab-mérés segít reprodukálni konkrét problémákat és iterálni a javításokon. (product.webpagetest.org)     Ajánlott mérőszámok (üzleti összekapcsolással)   - Technikai/UX: LCP, INP, CLS, Time to First Byte (TTFB), First Contentful Paint( FCP), teljes oldal betöltési idő (lab). (Core Web Vitals célértékek: LCP ≤ 2.5 s, INP < 200 ms, CLS < 0.1.) (developers.google.com)   - Üzleti: konverziós arány (CR) oldalanként, űrlapkitöltési arány, hirdetésből érkező látogatók CVR-je, félbehagyott kosár aránya, új/returning user arány.   - Keresőforgalmi hatás: organikus helyezés és impressions/clicks a Search Console- ból (előtte/utána összehasonlítás), különösen ha az oldal organikus látogatások jelentik az ügyfélszerzés fő csatornáját.     Hogyan kössük össze a teljesítményt és üzleti eredményt (módszertan)   - Esemény-alapú mutatók: állítsa be a fontos konverziókat (pl. űrlapbeküldés, vásárlás) Google Analytics-ben vagy más analitikában, és bontsa fel ezek teljesítményét oldalanként, eszközönként (mobil/desktop) és forgalmi forrásonként.   - Idősoros A/B vagy before/after vizsgálat: hajtson végre egy mérhető optimalizációt( például képek lazy-load, egy kritikus JS eltávolítása), majd hasonlítsa össze a konverziós arányt és a CWV-t a javítás előtti és utáni időszakban. Fontos: kontrollálja a külső tényezőket (kampányok, szezonális hatás).   - Szegmentálás: mérje külön a mobil és asztali felhasználókat — sok kisvállalati közönségben a mobil a meghatározó, és itt gyakori a rosszabb teljesítmény.   - Bizonyíték-szint: ha a CWV vagy LCP jelentősen javul és a CR is javul ugyanazon szegmensekben, akkor erős a korreláció; a biztosabb ok-okozat megállapításához ismételt, kontrollált tesztek szükségesek.     Üzleti hatás — mit lehet mérhetően várni?   - Nem adok kitalált arányokat: a pontos hatás iparág-, oldal- és forgalomfüggő. A mérési folyamat célja, hogy a saját adataiból állítsa elő a bizonyítékot: például „a szolgáltatásoldal LCP-jét 5s-ről 2s-re csökkentve X nap alatt Y%- kal nőtt az ajánlatkérő űrlapok száma”. Az általános logika: kevesebb várakozás = több befejezett feladat = több lead/konverzió.   - SEO hatás: a jobb page experience segíthet a keresői láthatóság fenntartásában/ optimalizálásában, de nem garantálja a rangsor-emelkedést — relevancia és tartalom továbbra is kulcs. (developers.google.com)     Prioritások: Most / Következő / Később   Most (alapellenőrzés, gyors nyereség)   - Ellenőrizze a Core Web Vitals állapotot a Search Console-ban; azonosítsa a legkritikusabb oldalcsoportokat (pl. fő termékoldalak, szolgáltatásoldalak, konverziós jutási pontok). (support.google.com)   - Futtasson PageSpeed Insights-ot és egy WebPageTest/Lighthouse labtesztet a top 5 konverziós oldalra (mobil és desktop). Jegyezze fel LCP, INP, CLS és a bottlenecke-ket. (developers.google.com)     Következő (technikai beavatkozások, A/B tesztek)   - Képek és média optimalizálása (méret, formátum, responsive srcset, lazy-loading).   - Kritikus CSS inline és deferred JS; font- és third-party script audit (hirdetés, chat widgetek).   - Indítson rövid A/B vagy időalapú tesztet, ahol egy optimalizált verziót hasonlít a kontrollal a konverziók méréséhez.     Később (stratégiai fejlesztés)   - Architektúra és hosting: fontolja meg CDN, gyorsabb hosting vagy edge rendering opciókat, ha a szerver oldali válaszidő a probléma.   - UI/UX redesign, ha az oldal információs architektúrája vagy túl sok interaktív elem okozza a lassulást.   - Folyamatos monitoring: integrálja a Web Vitals felügyeletet a rendszeres riportokba.     Döntési kritériumok a „javítsuk most” vs „várjunk” kérdéshez   - Mennyire fontos az oldal az ügyfélszerzés szempontjából? (pl. forgalom + konverziók aránya)   - Mekkora a teljesítményjavítás becsült költsége vs várható bevételnövekedés? Használjon egyszerű ROI-számítást: (várható többletkonverzió × átlagérték)– fejlesztési költség.   - Lehet-e gyors, alacsony költségű beavatkozást végrehajtani (pl. képek, cache beállítás) mielőtt nagy redesign-ba kezdene? Mindig érdemes a „kis lépések, gyors győzelmek” irányt választani első körben.   - Kockázat: ha a weboldal organikus forgalomból él, a Page Experience elhanyagolása hosszabb távon növelheti a kockázatot a láthatóságra nézve. (developers.google. com)     Rövid ellenőrzőlista (azonnali teendők)   1. a. Adatok begyűjtése     - Add hozzá a webhelyet a Google Search Console-hoz; nézd meg a Core Web Vitals riportot. (support.google.com)   - Futtasd le a PageSpeed Insights jelentést a főoldalra és 3–5 konverziós oldalra( mobil + desktop). Jegyezd fel LCP/INP/CLS értékeket. (developers.google.com)     2. b. Laborvizsgálat     - WebPageTest és/vagy Lighthouse futtatás: waterfall, TTFB, kritikus erőforrások azonosítása. (product.webpagetest.org)     3. c. Üzleti mérés     - Állítsd be a konverziós eseményeket analitikában (űrlap, vásárlás, call-click). Szegmentáld mobil/desktop és forgalmi forrás szerint.   - Válassz egy rövid tesztidőszakot és implementálj egy könnyű optimalizálást( képek, cache). Mérd 2–4 hétig és hasonlítsd össze a kontroll időszakkal.     4. d. Prioritáslista     - Sorold be a javítandó feladatokat (magas hatás / alacsony erőforrás igény előre). Példák: képek WebP-re konvertálása; critical CSS beállítás; elavult third-party script eltávolítása.     5. e. Folyamatos monitoring     - Állíts be havi riportot: Core Web Vitals + konverziók + organikus forgalom. Ha a javítások után a konverzió nem javul, folytasd a hibakeresést (UX, tartalom, targeting).     Záró megjegyzés — bizonyíték és döntés A legmeggyőzőbb üzleti bizonyíték a saját adataidból származik. Használj valós felhasználói metrikákat (CrUX / Search Console) és laborvizsgálatokat (Lighthouse, WebPageTest) együtt, majd köss össze minden változást az analitika konverzióival. A Core Web Vitals és a Page Experience eszközei segítenek objektív mércét adni a „lassúság” megítéléséhez, de mindig a saját konverziós adataid mutatják meg, hogy egy adott javítás üzletileg megéri-e.   Ha szeretnéd, elkészítek egy rövid audit-űrlapot (3–5 oldalra) a prioritások automatikus kiszámításához a te webhelyed adatai alapján — ebben az esetben szükségem lesz a 3 legfontosabb konverziós oldal URL-jére és az analitika hozzáférési adataira (vagy exportált konverziós számokra). --- ## Nem biztos benne, mi fogja vissza a weboldalát? A kutatásvezérelt tartalmi folyamat a friss piaci jeleket, a weboldal állapotát és az ellenőrzött témákat rendezi publikálás előtti minőségkapukba. [Kérem az ingyenes weboldalauditot](https://digiosveny.hu/ingyenes-weboldalaudit/) Ha már konkrét projektben gondolkodik: [Kitöltöm a projekt-igényfelmérést](https://digiosveny.hu/igenyfelmero-urlap/). ## Ár- és scope-transzparencia a weboldalon — hogyan előzheti meg a szerződéses vitákat és többletmunkát a szolgáltatási scope egyértelmű kommunikálása - Link: https://digiosveny.hu/de/ar-es-scope-transzparencia-a-weboldalon-hogyan-elozheti-meg-a-szerzodeses-vitakat-es-tobbletmunkat-a-szolgaltatasi-scope-egyertelmu-kommunikalasa/ - Veröffentlicht: 2026-10-20T05:50:37+02:00 - Autor: Márton Rövid összefoglaló   Átlátható ár- és scope-kommunikáció a weboldal-fejlesztési/karbantartási szerződésekben egyszerre csökkenti a jogi viták és a váratlan többletköltségek kockázatát, és javítja a weboldal üzleti teljesítményét (UX, kereső‑láthatóság, konverziók, biztonság, karbantartás). Az alábbi cikk két szintre választja szét a bizonyított tényeket ( forrással) és a szakmai javaslatokat, majd gyakorlati mérőpontokra, üzleti hatásra és döntési kritériumokra bontja a szükséges lépéseket.   H2: Probléma és tünetek   A tipikus probléma   - A szerződésben nem határozzák meg egyértelműen, mi tartozik a „kész” weboldalba( például tartalomfeltöltés, SEO‑alapbeállítások, 3rd‑party widgetek, utólagos hibajavítások, karbantartás). Ennek következménye a scope creep: kontrollálatlan változtatások, költség- és időtúllépés, és viták a számlázásról. (Definíció és okok: PMI). (pmi.org)     Jelzőtünetek, amikre figyeljen   - „Kész” oldal után folyamatosan jönnek a „csak ez egy apróság” kérések — a partner óradíjat számláz, vagy ingyen dolgozik, és nő az elégedetlenség.   - Mérésekben romlanak a felhasználói teljesítménymutatók (lassú LCP, rossz INP, magas CLS), miután extra komponenseket adtak hozzá (chat, analitika, hirdetéshálózat).   - Utólag derül ki, hogy a biztosított karbantartás nem tartalmaz biztonsági frissítéseket vagy SLA‑időt (downtime vagy gyors javítás hiánya). A Web‑performance oldali tünetek mögött gyakran harmadik fél szkriptek, render‑blokkoló erőforrások vagy nem kezelt image/asset‑kezelés állnak. (web.dev)     H2: Bizonyított tények (ellenőrizhető forrásokkal)   - Core Web Vitals: a Google három „pólusú” százalékos (75‑öd percentilis) mérőszáma ma LCP (Largest Contentful Paint), INP (Interaction to Next Paint) és CLS ( Cumulative Layout Shift), ezekhez küszöbértékek tartoznak, amelyek alapján a URL‑csoportokat Good / Needs improvement / Poor kategóriákba sorolják. ( web.dev)   - INP: az INP 2024. márciusában vált a válaszkészségre használt Core Web Vital‑ metszetre, helyettesítve a korábbi FID‑et; ez más mérési szemlélet (teljes interakciós késleltés a látogatás során). (developer.chrome.com)   - Page Experience és SEO: a Core Web Vitals a Google Page Experience komponensének része, és szerepet játszik a rangsorolásban — de önmagában nem garantál top‑ pozíciót; tartalom és relevancia továbbra is elsődleges. (developers.google. com)   - Teljesítmény és üzleti eredmény: több nagyszabású vizsgálat összefüggést talált a mobiloldal‑sebesség és a konverziók között (például Deloitte/Google „Milliseconds Make Millions” és Akamai riportok), az eredmények iparágtól és mintától függően eltérnek, de konzisztensen azt mutatják, hogy kisebb késések rontják a funnel‑ átmeneteket és a konverziót. (Lásd a tanulmányok forrásait). (thinkwithgoogle. com)     H2: Mit és hogyan érdemes mérni (műszaki checklist)   H3: Metrikák — mit mérjen minden weboldalon   - LCP (Largest Contentful Paint) — cél: p75 ≤ 2,5 s; ha rossz, ellenőrizze a kritikus hero‑képeket, betöltési sorrendet, preload beállításokat. (web.dev)   - INP — cél: p75 ≤ 200 ms; ha magas, keresni kell hosszú main‑thread feladatokat, harmadik fél JavaScript‑ek blokkjait, nagy JS‑futtatási időket. (web.dev)   - CLS — cél: p75 ≤ 0,1; ha magas, azonosítsa a dinamikusan betöltött képeket, reklámok vagy webfontok okozta elmozdulásokat. (web.dev)     H3: Eszközök és módszerek — lab vs. field   - Field (valódi felhasználói adatok): Chrome UX Report (CrUX), Search Console Core Web Vitals report — ezek mutatják a 28 napos p75 értékeket. (support. google.com)   - Lab: Lighthouse, WebPageTest, Chrome DevTools — hasznos hibakereséshez és regresszióteszthez.   - RUM (Real User Monitoring): telepítse a web‑vitals vagy hasonló könyvtárat, hogy a saját felhasználói forgalmából kapjon értékeket; ügyeljen, hogy a mérés ne rontsa a teljesítményt (defer, sendBeacon stb.). (web.dev)     H3: Scope‑specifikus műszaki tételek, amiket szerződésben rögzíteni kell   - Melyik metrikát és milyen küszöbértékkel fogadják el (pl. LCP p75 ≤ 2,5s mobilon a fő sablonokra). (tény: Google definiál küszöböket). (web.dev)   - Kinek a felelőssége a harmadik fél script bevezetése és optimalizálása (chat, analitika, marketing pixelek). (ajánlás: ha ügyfél hozza be, explicit change request és teljesítményellenőrzés szükséges).   - Mérés és jóváhagyás: mely riport lesz mérvadó átadáskor (pl. PageSpeed Insights + Search Console p75 eredmények), és milyen időablakban (például 28 nap CrUX, vagy a projekt utáni 7 napos feltöltéskor). (support.google.com)     H2: Üzleti hatás — miért számít a scope‑transzparencia a cégnek   - Költségkontroll és cashflow: egyértelmű scope = kevesebb „rejtett” óraszámla, kevesebb vita, pontosabb ROI‑számítás. (PMI és iparági tapasztalatok). (pmi. org)   - Kereső‑láthatóság és forgalom: ha az oldal UX (Core Web Vitals + Page Experience) romlik, a láthatóság és organikus forgalom kockázatos lehet; ezzel együtt a tartalomminőség és relevancia továbbra is meghatározó. (developers.google. com)   - Konverzió és bevétel: a nagyszabású ipari vizsgálatok összefüggést mutatnak a mobil sebesség és a konverziós funnel teljesítménye között (Deloitte/Google; Akamai). Az üzleti hatás mértéke vállalatonként eltér — ezért mérni kell saját site‑on. (thinkwithgoogle.com)   - Biztonság és üzemeltetés: ha nem világos, hogy ki végzi a biztonsági frissítéseket és backupokat, nő a kompromittálódás, downtime és a helyreállítási költség kockázata — ezek gyakran többszörösei a megelőző karbantartásnak. (gyakorlati guideline‑ok maintenance contracts). (weblegal.net)     H2: Prioritások — most / következő / később (üzleti rövidtávú sorrend)   Most (azonnali, 0–4 hét)   - Közös scope‑definíció és change‑request folyamat lefektetése: mi tartozik a fixed‑price árajánlatba, mi lesz add‑on (óradíj/feature price). (szerződéses tétel). (pmi.org)   - Alapvető mérések beállítása: Search Console, PageSpeed Insights, Lighthouse CI, és egy RUM csomag (web‑vitals) életbe léptetése a fő sablonokon. (mérés: field + lab kombináció). (support.google.com)     Következő (1–3 hónap)   - Teljesítmény‑ és biztonsági audit: harmadik fél szkriptek inventory, image/ asset audit, JS execution‑time vizsgálat; soroljon fel „tiltott” vagy csak change‑requesttel engedélyezett widgeteket. (scribd.com)   - Szerződéshez csatolt SLA/maintenance csomag megalkotása: response windows, included hours, patch‑policy, backup és exit clause. (simonij.com)     Később (3–12 hónap)   - Teljes fejlesztési roadmap és performance budget bevezetése — minden sprintben mérje a hatást (CI/QA metrikák).   - Üzleti hatásmérés: A/B vagy időszakos tesztek a sebességjavítások üzleti eredményére( konverzió, AOV, funnel‑progression) — mert iparági benchmarkok iránymutatók, de a döntés alapja a saját adata legyen. (thinkwithgoogle.com)     H2: Döntési kritériumok (mikor fogadjon el módosítást vagy pluszköltséget)   - Ha az új követelmény befolyásolja a Core Web Vitals‑t (LCP/INP/CLS) vagy a biztonságot: automatikus change request‑számlázás szükséges, becsült fejlesztési idő és elfogadott mérőhatár megadásával. (példa: „chat widget bevezetése esetén a vendor 3 órát számlázhat az integrációért és 1 órát a teljesítmény‑teszthez; ha INP>200 ms lesz, további optimalizálási munkára kell tervet kérni”). (web. dev)   - Ha a változtatás rendszeres karbantartási munkát hoz (pl. havi tartalomfeltöltés, ár‑változás): ez legyen külön retainerben rögzítve (óraszám vagy havidíj).( simonij.com)   - Költség/haszon analízis: kis, üzletileg nem fontos vizuális módosításoknál( pl. betűkészlet‑váltás) mérje, mennyi idő menne rá; ha óradíjas költség meghaladja az üzleti értéket, ajánljon későbbre halasztást.     H2: Rövid ellenőrzőlista (átadás/előkészítés és szerződés)   1. a. Scope‑lista — részletes, sablononként: funkciók, integrációk, kötelező tartalom, képméretek, SEO‑alapok (meta, canonical), hozzáférések.   1. a. Teljesítmény‑mérőpontok szerződésbe: mely eszközök (Search Console, PageSpeed Insights/CrUX), mely metrikák (LCP, INP, CLS), elfogadható küszöbök, és az elfogadási időablak. (support.google.com)   1. a. Harmadik fél inventory: az ügyfél által behozott összes script listázása és jóváhagyási mechanizmus. (szerepeljen a change requestben). (scribd.com)   1. a. Karbantartás és biztonság: frissítési gyakoriság, backup policy, SLA‑vállalások, mit tartalmaz a havi retainer, mi extra. (simonij.com)   1. a. Változáskezelés (change request): egyszerű 3‑lépéses folyamat — igény bejelentése, becslés és jóváhagyás, végrehajtás + teszt. (szerződés melléklete legyen). (pmi. org)     Záró megjegyzés — bizonyított tények vs. javaslatok   Bizonyított tények (röviden): Core Web Vitals definiált metrikák és küszöbök; INP váltotta fel FID‑et; Page Experience befolyásolja a rangsorolás egyes aspektusait; mobil sebesség és konverzió között mérhető, iparági tanulmányok által dokumentált kapcsolat áll fenn. (web.dev)   Szakmai javaslatok (összegzés): szerződésben rögzítsen mérőpontokat és change‑request folyamatot; különítsen el karbantartást és fejlesztést; mérje a saját üzleti hatást( A/B vagy idősoros elemzés), és alkalmazzon performance budgetet a fejlesztések során. Ezek a javaslatok a fentiekkel kompatibilisek és gyakorlati megoldást kínálnak a viták és többletköltségek minimalizálására.   Ha szeretné, összeállítok egy szerződés‑melléklet‑sablont (scope checklist + change request űrlap + javasolt CWV küszöbök), amelyet közvetlenül be lehet csatolni egy ajánlathoz — ehhez megkérdezem, milyen CMS/technológia van használatban és van‑e meglévő Search Console/CrUX adat. --- ## Nem biztos benne, mi fogja vissza a weboldalát? A kutatásvezérelt tartalmi folyamat a friss piaci jeleket, a weboldal állapotát és az ellenőrzött témákat rendezi publikálás előtti minőségkapukba. [Kérem az ingyenes weboldalauditot](https://digiosveny.hu/ingyenes-weboldalaudit/) Ha már konkrét projektben gondolkodik: [Kitöltöm a projekt-igényfelmérést](https://digiosveny.hu/igenyfelmero-urlap/). ## Kilépési pontok azonosítása és javítása a keresésből érdeklődővé alakító weboldal folyamatban — mire kell fókuszálnia kisvállalati döntéshozónak - Link: https://digiosveny.hu/de/kilepesi-pontok-azonositasa-es-javitasa-a-keresesbol-erdeklodove-alakito-weboldal-folyamatban-mire-kell-fokuszalnia-kisvallalati-donteshozonak/ - Veröffentlicht: 2026-10-18T10:43:43+02:00 - Autor: Márton ## Rövid válasz Kilépési pontok (drop-offok) azonosítása és javítása a webhelyen a mérőszámok (funnel, kijárati oldalak, Core Web Vitals), kvalitatív vizsgálat (felhasználói teszt, heatmap, kérdőív) és hibajavítás (teljesítmény, UX-frikciók, biztonság) összehangolt munkája— a kisvállalati döntéshozónak a legnagyobb üzleti értéket adó oldalakra, mobilra és a fizetést/konverziót érintő lépésekre kell fókuszálnia először. (cxl.com) --- ## Probléma és tünetek - Gyors látogatószám-csökkenés egy adott lépésnél (pl. kosár → fizetés), megnövekedett kilépési oldalak vagy rövid munkamenetek. - Lassú betöltődés, törődés nélküli elrendezésváltások vagy interakciók, amelyek miatt a felhasználó elhagyja az oldalt. - Indexelési / láthatósági problémák: oldalak nem jelennek meg a keresésben vagy nem hivatkozzák őket AI-s összegzések (generative/AI search) részeként. - Biztonsági figyelmeztetések a böngészőkben (nem HTTPS, mixed content), vagy szolgáltatói hibák, amelyek bizalmatlanságot okoznak. Ezek tünetei a technikai, UX és tartalmi problémák keverékéből adódnak; a megoldáshoz össze kell kapcsolni analitikát, webes méréseket és használhatósági vizsgálatokat.( google.com) --- ## Mit és hogyan érdemes mérni 1. a. Alap funnel- és oldalmutatók b. - Lépésenkénti konverziók és drop-offok (funnel exploration / funnel analysis). Kövesd az egyes lépésekbe belépők számát, a kilépések abszolút számát és arányát; szükség esetén számold ki az “exit rate”-et (GA4-ben az Exit metrikából és Sessions/Entrances adatokból). (support.google.com) 1. a. Viselkedési adatok b. - Oldalon töltött idő, visszafordulás (engagement), heatmap és kattintási út. Ezek segítenek elkülöníteni “nem érdekel” jellegű kilépést a használhatósági problémáktól. (cxl.com) 1. a. Teljesítmény és Core Web Vitals b. - Mérd LCP (Largest Contentful Paint), INP (Interaction to Next Paint) és CLS (Cumulative Layout Shift) értékeket, valamint eszköz- és földrajzi bontást. Használj valós felhasználói (field) adatokat és lab teszteket (PageSpeed Insights / Lighthouse). A Core Web Vitals definíciói és küszöbértékei dokumentáltak.( web.dev) 1. a. Technikai SEO és indexelés b. - Search Console: feltérképezési hibák, Mobile‑first indexing ellenőrzése, Core Web Vitals jelentés. Kövesd a címkék (robots, canonical), sitemap és strukturált adatok épségét. (support.google.com) 1. a. AI-kereső láthatóság (emerging) b. - Használd a keresőmotorok által kínált új jelentéseket (pl. Bing AI Performance/ Google erőforrások a generatív megjelenéshez), hogy lásd, mely oldalak kerülnek felhasználásra AI-eredményekben; ez nem egyszerű rangsor, de fontos láthatósági jel. (blogs.bing.com) 1. a. Biztonság és megbízhatóság b. - Ellenőrizd HTTPS / HSTS, Content Security Policy, és egyéb fontos HTTP-fejléceket; a böngésző figyelmeztetések komoly kilépési okok lehetnek. Használj OWASP és egyéb hiteles útmutatókat a beállításhoz. (cheatsheetseries.owasp.org) Módszertan: kezdd kvantitatív adatokkal (analitika + webes mérések), majd azonosítsd a legnagyobb kieső pontokat, és végezz célzott kvalitatív vizsgálatot (5–10 moderált felhasználói teszt, vagy session replay + rövid kérdőív). (cxl.com) --- ## Biznisi hatás (mire érdemes fókuszálni) - A főbb üzleti hatások: bevétel / leadek kiesése, hirdetésből szerzett forgalom pazarlása, márkahitelesség romlása (biztonsági figyelmeztetések miatt). - Prioritás: közvetlen bevételt hozó oldalak (pl. fizetés, ajánlatkérés), magas forgalmú belépőoldalak (pl. szolgáltatási leírások, termékoldalak), és erőforrásigényes technikai hibák, amelyek minden látogatót érintenek (pl. teljesítmény). (cxl. com) Példa: ha a checkout oldal 40%‑os lépésközi kiesést mutat, ez közvetlenül átszámítható elmaradt ügyfélszámra — érdemes először ott beavatkozni (UX-hibák, rejtett költségek, fizetési hibák). (baymard.com) --- ## Prioritások: most / következő / később - Most (alacsony büdzsé, gyors hatás): - Funnel‑vizsgálat + konverziós hibaazonosítás a legnagyobb forgalmú oldalakra; egyszerű UX‑javítások (pl. rögzített kosár‑összeg, látható shipping info), hibajegy a szerver‑oldali lassulásokra. (cxl.com) - Következő (néhány hét): - Core Web Vitals javítása: képek optimalizálása (modern formátumok, lazy loading), kritikus CSS inline‑elése, harmadik féltől származó script- ek felülvizsgálata. Futtass Lighthouse/PSI és valós‑felhasználói mérést.( developers.google.com) - Később (1–3 hónap): - Redesign vagy rebuild döntés előkészítése: ha sok fragmentált technikai adósság van (régi CMS, rossz komponens‑struktúra), számíts újraépítésre. Ezzel együtt hosszabb távú SEO és AI‑láthatóság stratégia (strukturált adatok, forrásmegjelölés, tartalom‑átalakítás). (developers.google.com) --- ## Döntési kritériumok (kisvállalati szemmel) 1. a. Üzleti érték: mekkora bevétel/lead esik ki az adott oldalnál? 1. a. Megvalósíthatóság vs költség: milyen gyors és olcsó a javítás (content change vs. rebuild)? 1. a. Kockázat: érinti‑e a probléma biztonságot, vagy jogi/következményi kitettséget? 1. a. Mérhetőség: képesek vagyunk‑e A/B‑vel / funnel utókövetéssel mérni a hatást? 1. a. Hosszú távú fenntarthatóság: a javítás beépíthető‑e a karbantartási folyamatba, vagy csak egy rövid távú patch marad? Használj egyszerű pontozást (1–5) ezekre a kritériumokra, hogy rangsorold a teendőket. Ez a kisvállalati döntéshozónak gyorsan ad költség/haszon becslést. --- ## Bizonyított tények (rövid) - A Core Web Vitals fő mérőszámai: LCP, INP és CLS; ezek mérhetők és küszöbértékek szerint kategorizálhatók. (web.dev) - A PageSpeed Insights és Lighthouse ad mind labor, mind valós‑felhasználói ( field) adatot a teljesítmény értékeléséhez. (developers.google.com) - Google Search Console tartalmaz Core Web Vitals riportot és feltérképezési hibákat; mobile‑first indexing irányelvek hivatalosan dokumentáltak. (support. google.com) - GA4‑ben elérhetőek az Entrances/Exits metrikák és funnel‑exploration eszközök; a klasszikus “Exit rate” számítást sok esetben kézzel kell előállítani GA4 nézetekben. (support.google.com) - Bing és Google egyre több eszközt ad az AI‑eredményekben való megjelenés mérésére( Bing: AI Performance / Google: útmutatók a generatív megjelenéshez). (blogs. bing.com) - Fontos biztonsági fejek: HSTS és Content Security Policy — az OWASP részletes útmutatást ad. (cheatsheetseries.owasp.org) --- ## Szakmai javaslatok (ajánlott lépések) - Azonosítsd az 3–5 legfontosabb oldalad (forgalom × konverziós potenciál) és ott kezdd a funnel‑vizsgálatot. (cxl.com) - Gyors nyerés: távolítsd el vagy aszinkronizáld a felesleges third‑party szkripteket, optimalizáld képeket, és csökkentsd a kritikus render‑blokkoló CSS/JS‑t. ( developers.google.com) - Kérdezz meg valódi felhasználókat: 5–10 moderált teszt vagy pár tucat rövid exit‑survey gyors insightot ad. (cxl.com) - Biztonságos alapok: HTTPS + HSTS + CSP beállítása, rendszeres sebezhetőségellenőrzés. Ezek megelőzik a bizalomvesztést okozó figyelmeztetéseket. (cheatsheetseries. owasp.org) - Kövesd a keresőmotorok új javaslatait az AI‑eredményekre való optimalizálásról; strukturált, forrás‑átlátható tartalom előnyös. (developers.google.com) --- ## Rövid ellenőrzőlista (gyors 10 pont) 1. a. Azonosítottad a 3 legfontosabb konverziós oldalt? 1. a. Van funnel‑exploration riportod (eszköz: GA4 vagy alternatív)? (support.google. com) 1. a. Megnézted az Exit/Exits metrikát az érintett oldalaknál? (support.google.com) 1. a. PageSpeed/Lighthouse jelentés futtatva a fő oldalakra (mobil + desktop)? (developers. google.com) 1. a. Core Web Vitals mezők jók vagy mely oldalak kevésbé teljesítenek? (web.dev) 1. a. Heatmap vagy session‑replay használat a lépésközi hibák feltárására? (cxl.com) 1. a. Kifizetés/űrlapok egyszerűsítve: kevesebb mező, vendégvásárlás lehetősége? (baymard. com) 1. a. HTTPS érvényes, HSTS és CSP alapbeállítások élesítve? (cheatsheetseries.owasp. org) 1. a. Strukturált adatok és metaadatok rendben — és a keresőmotorok irányelvei szerint optimalizálva az AI‑megjelenésekre? (developers.google.com) 1. a. Prioritási tábla: rövidtávú impact × implementációs költség alapján rangsorolva? --- Ha szeretnéd, át tudok nézni egy konkrét oldalt (melyik URL-ekre fókuszáljunk), és egy rövid audit‑prioritási listát készítek belőle a fenti kritériumok alapján. --- ## Nem biztos benne, hol veszít érdeklődőt a weboldala? Egy rövid, konkrét technikai átvilágítás megmutatja a legfontosabb problémákat, a keresési és konverziós akadályokat, valamint a következő lépést. **Smart Publish AI + AI chatbot:** ha folyamatos, felügyelt tartalomkészítést és weboldali érdeklődő-kezelést szeretne, a rendszer külön projektként is beköthető. [Kérem az ingyenes weboldalauditot](https://digiosveny.hu/ingyenes-weboldalaudit/) Konkrét Smart Publish AI, bloggenerátor vagy chatbot projekthez: [Kitöltöm a projekt-igényfelmérést](https://digiosveny.hu/igenyfelmero-urlap/). ## Hol szaladnak el a keresésből érkező érdeklődők? Konkrét weboldalhibák, amelyek bizonyítható üzleti hatást okoznak kisvállalatoknál - Link: https://digiosveny.hu/de/hol-szaladnak-el-a-keresesbol-erkezo-erdeklodok-konkret-weboldalhibak-amelyek-bizonyithato-uzleti-hatast-okoznak-kisvallalatoknal/ - Veröffentlicht: 2026-10-17T10:37:58+02:00 - Autor: Márton Rövid összefoglaló Hol „szaladnak el” a keresésből érkező érdeklődők? Legtöbbször nem a marketing üzenet hiánya okozza a lemorzsolódást, hanem technikai és UX-hibák: lassú vagy instabil oldalletöltés, elakadt űrlapok, böngésző-biztonsági figyelmeztetések, keresőmotorok által nem indexelt tartalom vagy olyan tartalmi/strukturális hiányosságok, amelyek miatt a találati oldal (vagy új generációs kereső-összegzés) nem emeli ki az oldaladat. A következőkben hibakörönként tüneteket, mérési módszereket, üzleti hatásokat és gyakorlati prioritásokat adok — elkülönítve az ellenőrizhető tényeket és a szakmai javaslatokat.   Bizonnyított tények (ellenőrizhető, forrásokkal)   - A Google Core Web Vitals három mezőadat-metrikát definiál: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) és Cumulative Layout Shift (CLS); ezek a Page Experience jelzőrendszer részei. (developers.google.com)   - A „Page Experience” (amelyben a Core Web Vitals szerepel) hatással lehet a keresési rangsorolásra; a Search Console eszközben külön riportok vannak ezek figyelésére. (support.google.com)   - Google-elemzések és iparági tanulmányok szerint a mobiloldal sebessége erősen korrelál a lemorzsolódással: a Google „The Need for Mobile Speed” jelentése 2016/2017-ben azt mutatta, hogy a vizsgált mobillátogatások ~53%-a elhagyható volt, ha a betöltés 3 másodpercnél hosszabb volt. (thinkwithgoogle.com)   - A „Milliseconds Make Millions” (Deloitte / 55, megbízásból Google) vizsgálat szerint a kis, órákra lebontott javulások (pl. 0,1 s) is kimutatható hatást mutattak a konverziókra bizonyos nagy márkák mintáján. (A tanulmány módszertanát és korlátait a publikáció ismerteti.) (web.dev)   - Az OWASP Top 10 dokumentálja a leggyakoribb webalkalmazás-sebezhetőségeket, amelyek üzleti és jogi kockázatot jelentenek (üzleti kár, adatvesztés, bizalomvesztés).( top10.owasp.org)     1. a. Probléma és tünetek — konkrét weboldalhibák és hogyan jelentkeznek     - Lassú LCP / hosszú betöltési idő (pl. nagy, nem optimalizált hero-kép; render- blocking JS/CSS). Tünet: a felhasználó a kattintás után „üres” vagy csak részlegesen megjelenő oldalt lát, növekszik a visszafordulás. (Oldalbetöltési optimalizálást javasolja a PageSpeed/Lighthouse dokumentáció.) (developer.chrome.com)   - Rossz interakció (INP/korábbi FID problémák): gombokra kattintva nincs reakció, űrlap nem dolgozza fel a bevitelt. Tünet: félbehagyott konverziók, alacsony űrlapkitöltés. (INP a Core Web Vitals része.) (web.dev)   - Vizualis ingadozások (CLS): későn betöltődő képek/ads/fontok elmozdítják a tartalmat, véletlen kattintások (pl. „Vásárlás” helyett „Bezárás”). Tünet: panaszok, hibás tranzakciók. (web.dev)   - Intruzív interstitial/overlay (mobilon különösen problémás): Google letilthatja vagy hátrébb sorolhatja az ilyen felületeket, és a felhasználó gyorsan elhagyja az oldalt. Tünet: megnövekedett visszafordulás a belépő oldalról. (developers. google.com)   - HTTPS / biztonsági hibák, kevert tartalom: böngésző figyelmeztetés vagy „nem biztonságos” címke; látogatói bizalomvesztés és levél- vagy tranzakció-lemorzsolódás. Google 2014 óta tekinti a HTTPS-t rangsorolási jelnek; a Page Experience részeként fontos. (developers.google.com)   - Broken forms, 4xx/5xx hibák, rossz átirányítások, duplikált kanonizáció: a látogató elakad, és a keresőbot nem indexel. Tünet: csökkenő organikus forgalom, alacsony indexáltság. (Search Console Coverage és URL-inspection segít.) ( support.google.com)   - Harmadik féltől származó script-ek (chat, analitika, reklám): ezek blokkolhatják a renderelést vagy lelassíthatják az oldalt. Tünet: jó mobil/laptop hálózaton is ingadozó teljesítmény; PageSpeed lehetőségek jelzik. (developers.google. com)     2. b. Mit és hogyan érdemes mérni (gyakorlatiasan)     - Metrikák (ellenőrizhető): LCP, INP, CLS (Core Web Vitals); TTFB, FCP; oldalméret, requests száma; konverziós funnel lépések (sessions → add-to-cart → checkout). A Core Web Vitals definíciói és küszöbértékei a Google-dokumentációban találhatók.( developers.google.com)   - Eszközök (ajánlott, megbízható források): - Google Search Console — Core Web Vitals és Coverage riportok (valódi keresési adatok és crawl-eredmények). (support.google.com) -   - PageSpeed Insights / Lighthouse — labor és mezőadat (CrUX) ajánlásokkal.( developers.google.com) -   - web-vitals JavaScript könyvtár: saját RUM-gyűjtéshez (valódi látogatói adatok). (github.com) -   - Szoftveres auditok: WebPageTest, GTmetrix, szerver-monitoring, és log- elemzés. (Ezekről a Google dokumentáció is beszél.) (developers.google. com) -   -     - Mérés-sablon (konkrét lépések): 1) állíts be RUM-et (web-vitals → Analytics/ endpoint), 2) futtass heti-szintű Lighthouse-szintetikus teszteket különböző hálózati profilon, 3) figyeld a GSC Coverage/Indexing üzeneteket, 4) tarts A/B kontrollt konverziós méréshez (pl. gyorsabb vs eredeti oldal) — így a sebességjavulás üzleti hatása igazolható.     3. c. Üzleti hatás — miért számít ez pénzben?     - Látogatói lemorzsolódás: a Google által közölt vizsgálat szerint (mobil) a lassabb oldalaknál jelentősen nő az elhagyás valószínűsége; a Deloitte/Google tanulmány konkrétan kimutatta, hogy kis sebességjavulások is mérhető növekedést eredményezhetnek a konverzióban bizonyos iparágakban. Ezek nem univerzális„ minden üzletre” mutatók — de egyértelmű kapcsolat van a sebesség/UX és a bevétel között. (thinkwithgoogle.com)   - Kereső-szereplés és organikus forgalom: a Page Experience (beleértve Core Web Vitals és HTTPS) elemek a rangsorolási jelek részei; ha az oldalad folyamatosan„ rossz” CWV-vel szerepel, bizonyos lekérdezésekben hátrébb kerülhet. (developers. google.com)   - Bizalom és jogi kockázat: sebezhetőségek (OWASP Top 10) feltárása adatvesztéshez, visszatérő ügyfélvesztéshez, vagy szabályozási bírsághoz vezethet (személyes adatok kezelése). (top10.owasp.org)     4. d. Prioritások — most / következő / később (kisvállalati fókusz)     - Most (azonnali, alacsony költségű, nagy hatás): - Ellenőrizd Search Console Coverage-t és Page Experience-figyelést; javíts minden 5xx/404 hibát és indexálási problémát. (support.google.com) -   - Aktiváld HTTPS és ellenőrizd kevert tartalomra; állítsd be HSTS ésszerűen.( HTTPS bevezetés erősen javasolt; Google korábban jelezte rangsorolási előnyét.) (developers.google.com) -   - Minimalizáld render-blocking JS/CSS (defer/async, critical CSS) és optimalizáld a világnézetben legnagyobb LCP elemeket (hero képek). (developer.chrome. com) -   -     - Következő (1–3 hónap): - Implementálj RUM-ot (web-vitals → Analytics) és állíts fel alap-mutatókat( LCP/INP/CLS per fontos oldal). (github.com) -   - Audit a harmadik féltől származó script-ekre (tömegesen késleltetni vagy feltételekhez kötni). -   - Javítsd a mobil UX kisebb akadályait (űrlapvalidáció, gombok célszerűsége). -   -     - Később (3–12 hónap): - Architektúra/hosting változtatások (CDN, image delivery, szerveroldali cache). -   - Redesign vagy rebuild döntés: csak akkor, ha a technikai adósság túl nagy és a javítások széttagolt, vagy a költség/haszon-elemzés azt mutatja, hogy egy új platform hatékonyabb. -   -       5. e. Döntési kritériumok (mit mérj, hogy eldöntsd: javítás vs. rebuild)     - Működési kockázat és javítási költség: becsüld meg a javítás fejlesztői munkaóráit vs. egy új webhely költségét. (Ha ugyanazon funkciók kisebb fejlesztéssel javíthatók → javíts.)   - Üzleti kitettség: hány látogatót/leadet/forgalmat érint a probléma? Használj valós adatot (Analytics + Search Console) a becsléshez. (developers.google. com)   - Mérés-alapú döntés: ha egy kisebb, mérhető változtatás (pl. képek WebP-re, defer JS) > X% növekedést adhat a konverzión, akkor ne rebuildelj; ha sok kritikus hibát kell egyszerre orvosolni, érdemes architektúrát cserélni. ( A Deloitte/Google tanulmány szemlélteti, hogy kis javulások is hozhatnak értéket.)( web.dev)     6. f. Rövid ellenőrzőlista (audit onnan, hogy a keresésből érkezők elakadnak)     - Alapok (azonnal): - Search Console hozzáférés és Coverage-ellenőrzés: nincs-e hirtelen 4xx/ 5xx/robot-block? (support.google.com) -   - HTTPS minden oldalon; nincs kevert tartalom. (developers.google.com) -   - Fő belépőoldalak futtatása PageSpeed Insights-on (mobil + desktop) — jegyezd LCP/INP/CLS értékeket. (developers.google.com) -   -     - Teljesítmény és UX: - Van-e render-blocking JS/CSS a fölötte-látványos tartalomnál? Javítandó: async/defer, critical CSS. (developer.chrome.com) -   - Képek megfelelő méretezése és modern formátumok (WebP/AVIF) használata.( PSI javaslatok között lesz.) (developers.google.com) -   - Űrlapok: szerver- és kliens-oldali validáció működik? Hibakezelés látható a felhasználónak? -   -     - Kereső/structural: - Van-e érvényes sitemap.xml és robots.txt? GSC-ben nincsenek indexálási figyelmeztetések. (support.google.com) -   - Szerkezet és schema (localBusiness, product stb.) alapok rendben — különösen, ha helyi / termékforgalmazás a fő csatorna. (Schema növeli az esélyét kiemelt megjelenéseknek.) -   -     - Biztonság és karbantartás: - Függőségek naprakészek; ismert CVE-k nincsenek a komponensekben (OWASP és dependency scanning ajánlott). (top10.owasp.org) -   -       Záró megjegyzés — mi az „első lépés” ma?   1. a. Hozz hozzáférést a Google Search Console-hoz (ha még nincs), és nézd meg a Coverage + Core Web Vitals riportokat. 2) Futtasd a legforgalmasabb (vagy bevételt hozó) belépőoldal(ak)at PageSpeed Insights-on, jegyezd fel az LCP/INP/CLS értékeket és a PSI által adott konkrét audit-okat (pl. render-blocking fájlok). Ezek a mérések adják meg azt a számsort és prioritási listát, amely alapján kisvállalati döntésként vagy gyors javítást végezhetsz, vagy mélyebb platform-döntést hozol. (support. google.com)     Ha szeretnéd, át tudok nézni egy konkrét oldalt (URL megadása esetén) és a Search Console vagy PageSpeed kimenete alapján egy rövid, priorizált hibajegyzéket készítek— pontos mérésre alapozva, hogy el tudd dönteni: gyors javítás vagy redesign. --- ## Nem biztos benne, hol veszít érdeklődőt a weboldala? Egy rövid, konkrét technikai átvilágítás megmutatja a legfontosabb problémákat, a keresési és konverziós akadályokat, valamint a következő lépést. **Smart Publish AI + AI chatbot:** ha folyamatos, felügyelt tartalomkészítést és weboldali érdeklődő-kezelést szeretne, a rendszer külön projektként is beköthető. [Kérem az ingyenes weboldalauditot](https://digiosveny.hu/ingyenes-weboldalaudit/) Konkrét Smart Publish AI, bloggenerátor vagy chatbot projekthez: [Kitöltöm a projekt-igényfelmérést](https://digiosveny.hu/igenyfelmero-urlap/). ## Miért nem lesznek érdeklődők a keresési látogatókból? Weboldalhibák és javítási prioritások - Link: https://digiosveny.hu/de/miert-nem-lesznek-erdeklodok-a-keresesi-latogatokbol-weboldalhibak-es-javitasi-prioritasok/ - Veröffentlicht: 2026-10-17T04:08:22+02:00 - Autor: Márton A keresési forgalom önmagában nem hoz érdeklődőket. A látogatónak gyorsan meg kell találnia a keresett választ, bíznia kell az oldalban, majd könnyen tovább kell lépnie. Ha a weboldal lassú, nehezen használható, vagy nem működik a kapcsolatfelvételi útvonal, az érdeklődés megszakad. Ebben az útmutatóban végigvesszük a leggyakoribb akadályokat, a mérésükhöz használható eszközöket és a javítási sorrendet. A cél nem az, hogy minden problémára újratervezés legyen a válasz. Először azonosítsa, hol akad el a látogató, majd a bizonyítékok alapján rangsorolja a teendőket. ## Miért nem konvertál a keresési forgalom? A keresőből érkező látogató konkrét szándékkal érkezik. Ha a céloldal nem felel meg ennek a szándéknak, vagy a következő lépés nem egyértelmű, a látogató visszatérhet a találati listához. Ugyanez történik akkor is, ha technikai hiba, gyenge mobilélmény vagy bizalmi probléma akadályozza a tájékozódást. A leggyakoribb problémák hét területre oszthatók: * **Teljesítmény:** a fő tartalom lassan jelenik meg, vagy az oldal betöltés közben ugrál. * **Mobilhasználat:** a menü, a CTA vagy az űrlap nehezen érhető el telefonon. * **Felugró elemek:** reklámok vagy ablakok eltakarják a tartalmat. * **Űrlap és checkout:** túl sok mező, kötelező regisztráció vagy nehezen érthető hibaüzenet nehezíti a továbblépést. * **Keresőbeli láthatóság:** fontos oldalak véletlenül kimaradnak az indexelésből. * **Biztonság:** a tanúsítvány vagy más biztonsági beállítás hibája figyelmeztetést válthat ki a böngészőben. * **Tartalmi relevancia:** az oldal nem ad gyors, világos választ arra, amit a látogató keres. ## 1. Lassú betöltés és instabil oldalélmény Ha a látogató hosszasan vár a fő tartalomra, nehezebben jut el az ajánlatig vagy a kapcsolatfelvételig. A lassú betöltés önmagában nem bizonyítja, hogy minden látogató távozik, de egyértelmű jelzés arra, hogy érdemes megvizsgálni az oldal teljesítményét. A Google a Core Web Vitals mutatókkal méri a betöltési élmény, az interaktivitás és a vizuális stabilitás egyes részeit. A három fő mutató az LCP, az INP és a CLS. A Google útmutatója az LCP esetében a 2,5 másodperc alatti értéket sorolja a jó tartományba. A méréshez használható a PageSpeed Insights és a Lighthouse. A laboradatokat érdemes a valós felhasználói adatokat tartalmazó terepi mérésekkel együtt értelmezni. **Mit ellenőrizzen?** * Megfelelő sebességgel jelenik-e meg a fő tartalom mobilon és asztali gépen? * Elmozdulnak-e az oldalelemek betöltés közben? * Van-e olyan nagy kép, script vagy más erőforrás, amely késlelteti a megjelenést? ## 2. Mobilon megszakadó konverziós útvonal A mobilos látogató nem tud kapcsolatba lépni, ha a fő gombot eltakarja egy sáv, a menü nem működik, vagy az űrlap mezői nehezen kezelhetők. Ilyenkor a forgalom megérkezik, de a következő lépés nem hozzáférhető. Nyissa meg a fontos oldalakat valódi telefonon is. Ellenőrizze a menüt, a fő CTA- t, a telefonszámot, az űrlapot és a visszajelzést, amelyet a beküldés után kap a látogató. Ne csak azt nézze, hogy az oldal „reszponzívnak” tűnik-e. A teljes folyamatot próbálja végig. ## 3. Túl sok akadály az űrlapon vagy a checkoutban Minden szükségtelen mező újabb feladatot ad a látogatónak. A kötelező regisztráció, a nem egyértelmű hibajelzés vagy a későn megjelenő költség szintén megszakíthatja a folyamatot. Webshopnál ezért a kosár és a fizetés lépéseit külön is mérje. A Baymard Institute e-kereskedelmi kutatásai visszatérő checkout-problémákat és kosárelhagyást dokumentálnak. Ezek nem bizonyítják, hogy egy adott webáruházban ugyanaz a hiba okozza az elhagyást. Ehhez az adott oldal mérési adatait és használhatóságát kell megvizsgálni. **Gyakorlati ellenőrzés:** nézze meg, mely mezők szükségesek valóban az első kapcsolatfelvételhez. Tesztelje a hibás adat megadását, a mobilos kitöltést és a sikeres beküldés utáni visszajelzést. ## 4. Indexelési hiba: a fontos oldal nem jelenik meg a keresőben Előfordulhat, hogy egy fontos szolgáltatási vagy termékoldal véletlenül noindex beállítást kap, vagy a robots.txt fájl megakadályozza a feltérképezését. A két beállítás nem ugyanaz: a robots.txt a feltérképezést szabályozza, a noindex pedig az indexelésre vonatkozó jelzés. Hibás konfiguráció esetén egy releváns oldal nehezebben vagy egyáltalán nem jelenik meg a keresési találatok között. A Google Search Console URL-ellenőrző eszközével vizsgálja meg a fontos oldalakat. Nézze meg az indexelési állapotot, a megjelenéseket, a kattintásokat és azokat a keresési kifejezéseket, amelyek forgalmat hoznak. Ha egy oldal nem látható, előbb az okot azonosítsa, és csak utána módosítsa a beállításokat. ## 5. Biztonsági figyelmeztetés vagy elérhetőségi hiba Lejárt vagy hibásan beállított tanúsítvány esetén a böngésző biztonsági figyelmeztetést jeleníthet meg. Ez megakadályozhatja, hogy a látogató eljusson az oldalra. Ellenőrizze a tanúsítvány érvényességét, a megújítási folyamatot és az esetleges vegyes tartalmi hibákat. A webhely biztonságának felmérése nem merül ki a tanúsítvány ellenőrzésében. A rendszeres frissítés, a függőségek áttekintése és a megfelelő biztonsági vizsgálat szintén része lehet a karbantartásnak. A szükséges ellenőrzés mélységét a weboldal működése és kockázata határozza meg. ## 6. A tartalom nem felel meg a keresési szándéknak A látogató gyorsan szeretné megérteni, hogy jó helyen jár-e. Ha az oldal általános bevezetővel kezdődik, és csak később tér rá a keresett kérdésre, nehezebb felismerni a relevanciáját. A címnek, a bevezetőnek és az oldal fő tartalmának ugyanarra az igényre kell választ adnia. A Google people-first iránymutatása a látogatóknak hasznos, megbízható tartalmat helyezi előtérbe. Ez nem jelent garantált megjelenést a keresőben vagy az AI-alapú összefoglalókban. A tartalom minőségét és teljesítményét a keresési adatokkal, a felhasználói viselkedéssel és a tényleges érdeklődésekkel együtt érdemes értékelni. Ha gyakran feltett kérdésről ír, adjon rövid, pontos választ a cikk elején, majd fejtse ki a részleteket. Strukturált adatot csak akkor használjon, ha az adott tartalomtípushoz és oldalhoz valóban illik. ## Mit mérjen, mielőtt fejlesztésbe kezd? A különböző eszközök eltérő kérdésekre adnak választ. Együtt használva segítenek megkülönböztetni a technikai hibát, a tartalmi problémát és a konverziós útvonal akadályát. * **PageSpeed Insights és Lighthouse:** teljesítmény, Core Web Vitals és laboradatok. * **Google Search Console:** indexelési állapot, megjelenések, kattintások és keresési lekérdezések. * **GA4:** elkötelezett munkamenetek, elköteleződési arány, konverziós események és funnel-lépések. Az adatok csak megfelelő mérési beállítás mellett értelmezhetők. * **Hőtérkép és munkamenet-visszajátszás:** megmutathatja, hol akadnak el a látogatók. Az ilyen eszközök adatkezelési és hozzájárulási beállításait is ellenőrizze. * **Biztonsági és rendelkezésreállási ellenőrzés:** tanúsítvány, böngészőkonzol, elérhetőség és a webhelyhez illő biztonsági vizsgálatok. Ne egyetlen mutatóból vonjon le üzleti következtetést. A magas kilépési arány például önmagában nem bizonyít hibát. Vizsgálja meg, hogy a látogató megtalálta-e a választ, elérte-e a kívánt oldalt, és működött-e a következő lépés. ## Javítási sorrend: először a blokkoló hibák ### Azonnal ellenőrizze * A fontos oldalak indexelhetők-e, és nincs-e rajtuk véletlen noindex beállítás? * Érvényes-e a biztonsági tanúsítvány? * Működik-e mobilon és asztali gépen a fő CTA és az űrlap? * Elérhető-e a weboldal a látogatók számára, és nem jelenik-e meg biztonsági figyelmeztetés? ### Ezután mérje fel a teljesítményt és a viselkedést * Vizsgálja meg a Core Web Vitals értékeket mobilon és asztali gépen. * Keresse meg a GA4-ben a konverziós folyamat megszakadásának pontjait. * Használjon kvalitatív megfigyelést annak megértésére, miért akadnak el a látogatók. * Ellenőrizze, hogy a keresési kifejezés és a céloldal tartalma összhangban van- e. ### Később döntsön nagyobb fejlesztésről Ha a teljesítményprobléma visszatérő, és az oldal technikai felépítése korlátozza a javítást, mérlegelje az architektúra módosítását vagy az újratervezést. Biztonsági oldalon alakítson ki rendszeres frissítési és ellenőrzési folyamatot. A teljes újraépítés előtt hasonlítsa össze a javítás várható hatását, költségét és a rendelkezésre álló belső vagy külső kapacitást. ## Döntési szempontok: javítás vagy újratervezés? * **Mi a bizonyított akadály?** Technikai hibát, keresési láthatósági problémát vagy tartalmi és használhatósági gondot lát? * **Melyik oldal érintett?** A forgalom és az érdeklődések szempontjából fontos oldalra koncentráljon. * **Mekkora a javítás terjedelme?** Egy képoptimalizálás vagy űrlapjavítás nem feltétlenül igényel teljes redesign-t. * **Van-e mérhető kiindulópont?** Rögzítse a jelenlegi forgalmat, a konverziós eseményeket és az érintett útvonal teljesítményét. * **Rendelkezésre áll-e a megvalósításhoz szükséges kapacitás?** A jó javaslat csak akkor hasznos, ha a javítás végre is hajtható. ## Gyors ellenőrzőlista * **Indexelés:** ellenőrizze a fontos URL-eket a Search Console-ban, és nézze át a robots.txt fájlt. * **Biztonság:** ellenőrizze a tanúsítvány érvényességét, a megújítási folyamatot és a böngészőhibákat. * **Teljesítmény:** mérje meg az LCP, INP és CLS értékeket mobilon és asztali gépen. * **Mobilélmény:** próbálja végig a menüt, a CTA-t és az űrlapot telefonon. * **Konverzió:** ellenőrizze, hogy rögzülnek-e a fontos események, és hol szakad meg a folyamat. * **Tartalom:** nézze meg, hogy a cím és a bevezető világosan válaszol-e a keresési szándékra. * **Webshop:** tesztelje a kosarat és a checkoutot, különösen a költségek és a fizetési lépések átláthatóságát. ## A lényeg: mérjen, rangsoroljon, majd javítson A keresési látogatók érdeklődéssé alakítását több tényező befolyásolja. Először a látogatást blokkoló hibákat ellenőrizze: biztonsági figyelmeztetés, indexelési probléma, hibás CTA vagy működésképtelen űrlap. Ezután vizsgálja meg a sebességet, a mobilélményt és a tartalom relevanciáját. Nagyobb fejlesztésről csak akkor döntsön, ha az adatok megmutatják, miért nem elegendő a célzott javítás. Ha már van weboldala, de nem világos, hol akad el a keresési forgalom, kérjen [ingyenes weboldalauditot](https://digiosveny.hu/ingyenes-weboldalaudit/). Az áttekintés segíthet azonosítani a vizsgálandó technikai, keresési és konverziós akadályokat.