Honlapkészítés 2026-ban: mit kérj számon az ügynökségtől? A Convergo ellenőrzőlistája

Ha 2026 őszén rendelsz új weboldalt, jó tudni, mennyi minden változik körülötte egyetlen hónap alatt. Szeptember 17-én megjelent a WordPress 7.1.1, amely tizenegy biztonsági hibát javított, szeptember 22-én a Next.js kapott soron kívüli kritikus biztonsági frissítést, a Google pedig augusztus 31-én élesítette a Search Console generatív AI-riportjait. Közben a WordPress Playground WebMCP-támogatást kapott, vagyis az AI-ügynököknek szánt új webes szabvány már a legnépszerűbb tartalomkezelő tesztkörnyezetében is kipróbálható. A honlapkészítés 2026-ban ezért jóval többről szól a szép dizájnnál és a gyors betöltésnél: legalább ennyire számít, ki frissíti az oldalt egy keddi estén megjelenő kritikus javítás után, illetve látod-e majd, idéz-e belőle a Google AI-ja.

Ez a cikk egy gyakorlati ellenőrzőlista, amelyet az ajánlatkéréskor, a szerződéskötéskor és az átadáskor is magad mellé tehetsz. Négy nagy területre épül (technikai alapok, AI-kompatibilitás, biztonság és karbantartás, mérés), ezeket egészítik ki a tulajdonjogi, a sebességi és a jogi szempontok. Az alábbi listát mi is minden projektnél használjuk, mégis úgy állítottuk össze, hogy bármelyik ügynökséggel vagy szabadúszóval szemben ugyanúgy alkalmazható legyen. A részletes háttérnek (WordPress-biztonság, WebMCP, AI-riportok, sebesség) külön cikkeket szenteltünk, itt mindegyikből csak annyit veszünk át, amennyi a jó kérdéshez kell, mindezt 2026. szeptember 22-i állapot szerint, a legfrissebb kiadások és bejelentések alapján.

Röviden

• Egy 2026-ban készülő honlap alapfeltétele a frissíthető tartalomkezelő, az automatikusan megújuló HTTPS-tanúsítvány, a külső helyen tárolt és kipróbált mentés, valamint legalább PHP 8.2, de mivel ennek biztonsági támogatása 2026. december 31-én lejár, új projektnél inkább PHP 8.3 vagy 8.4 legyen a követelmény.
• A domain, a tárhely, a fizetős licencek és az adminisztrátori hozzáférés a te cégedé legyen, a forráskódot és a dokumentációt pedig az átadáskor kapd meg, különben minden későbbi ügynökségváltás drága lesz.
• Az AI-kompatibilitás három építőelemből áll: Schema.org alapú strukturált adatból, önmagukban is idézhető, forrással és dátummal ellátott szövegekből, valamint tiszta, címkézett HTML-űrlapokból, amelyek később WebMCP-eszközzé alakíthatók.
• A karbantartási szerződésben legyen leírva, ki telepíti a biztonsági frissítéseket, hány órán belül teszi ezt kritikus hibánál és készül-e előtte mentés, hiszen a WordPress 7.1.1 és a Next.js szeptemberi javításai megmutatták, hogy ez nagyon is gyakorlati kérdés.
• A mérés az indulás napján kezdődik: domain szintű Search Console-tulajdon és oldaltérkép, a 2026. augusztus 31. óta elérhető generatív AI-riportok figyelése, valamint konverziókövetés az űrlapküldésre, a telefonhívásra és a vásárlásra.
• Ha egy ügynökség garantált első helyet ígér a Google-ben, a saját nevére regisztrálná a domaint vagy nem tud mentés-visszaállítási próbát mutatni, az komoly vészjel, akármilyen szép is a portfóliója.

Miért más a honlapkészítés 2026-ban, mint két éve?

Azért, mert egy weboldalnak ma két közönsége van: az emberek és a gépek, vagyis a keresők AI-válaszai meg az egyre önállóbb AI-ügynökök. Közben a biztonsági frissítések üteme is felgyorsult, 2026 szeptemberében egyetlen hónap alatt jött kritikus javítás a WordPresshez, a Next.js-hez és a Chrome-hoz, így a karbantartásnak a szerződésben a helye.

A gépi közönség súlyát jól mutatják a számok. A Numinix szeptemberi összesítése szerint a Google AI Overviews (a találati oldal tetején megjelenő AI-összefoglaló) havonta 2,5 milliárd aktív felhasználót ér el, a beszélgetős AI Mode pedig több mint egymilliárdot. Augusztus vége óta az AI-összefoglaló dinamikusan bővül, az organikus találatok pedig lejjebb csúsznak a képernyőn. Egy weboldal értéke így már azon is múlik, hányszor használja forrásként a Google AI-ja, amit augusztus 31-e óta a Search Console generatív AI-riportjai oldalanként meg is mutatnak.

A másik változás az AI-ügynököké. Az AI-ügynök olyan program, amely a felhasználó nevében önállóan hajt végre feladatokat: keres, összehasonlít, űrlapot tölt ki vagy időpontot foglal. A WebMCP a Google által javasolt webes szabvány, amellyel egy weboldal strukturált eszközöket kínálhat fel ezeknek az ügynököknek, így azoknak nem kell a képernyőről kitalálniuk, hol a foglalás gomb. A kereskedelemben is látszik az irány, hiszen a Shopify Winter ’26 Edition Agentic Storefronts funkciója már az AI-beszélgetésekbe viszi a Shopify-webshopok termékeit.

A harmadik tényező a biztonsági és platformváltozások sűrűsége. Az alábbi táblázat az elmúlt hetek legfontosabb eseményeit és azok következményeit gyűjti össze egy most készülő honlapra nézve.

A táblázat tanulsága, hogy egy honlap ma nem egyszeri termék, hanem folyamatosan karbantartandó rendszer, ezért ajánlatkéréskor a második és a harmadik évre is ugyanannyi figyelmet kell fordítani, mint az indulásra. Különben a ma olcsónak tűnő ajánlat két év múlva a legdrágább döntésnek bizonyulhat.

Hogyan használd az ellenőrzőlistát az ajánlatkéréstől az átadásig?

Három alkalommal vedd elő: ajánlatkéréskor küldd el minden ügynökségnek, hogy ugyanarra a kérdéssorra válaszoljanak, a szerződésbe emeld be átvételi feltételként, átadáskor pedig pontról pontra ellenőrizd a teljesítést. A válaszokat mindig írásban kérd, mert egy szóbeli „persze, megoldjuk” vita esetén semmit sem ér.

Nem kell fejlesztőnek lenned ahhoz, hogy a lista működjön. A legtöbb pontnál nem azt kell megítélned, hogy a technikai megoldás elegáns-e, hanem azt, hogy az ügynökség tud-e bizonyítékot mutatni: egy képernyőképet a PHP-verzióról, egy leírást a mentési rendről, egy visszaállítási próba jegyzőkönyvét vagy egy meghívót a Search Console-tulajdonhoz. Ahol a válasz homályos, ott kérdezz vissza, mert a homály ritkán takar jó hírt.

A pontok két csoportba sorolhatók. Vannak kötelező elemek, amelyek nélkül nem veszed át az oldalt, például a saját nevedre szóló domain, a működő HTTPS vagy a kipróbált mentés, mellettük pedig ajánlott elemek, amelyek a projekt méretétől függenek: egy ötoldalas bemutatkozó honlapnál a WebMCP-előkészítés még ráér, egy webshopnál viszont már most érdemes gondolni rá.

Vegyünk egy képzeletbeli, 12 fős kecskeméti asztalosüzemet, amely három helyről kér ajánlatot az új honlapjára. Ha mindhárom ajánlattevő ugyanazt a kérdéssort kapja, a válaszokból néhány perc alatt kiderül, hogy az egyik ügynökség a saját nevére regisztrálná a domaint, a másik nem vállal frissítést az átadás után, a harmadik viszont minden pontra konkrét, írásos választ ad. Az árkülönbség ettől még lehet jelentős, de legalább tudod, mit kapsz a pénzedért, így nem csak az utolsó oldalon álló végösszeg dönt.

Technikai alapok: frissíthető CMS, HTTPS, mentés, PHP 8.2 vagy újabb

A technikai alapok azok az elemek, amelyeket a látogató soha nem lát, mégis ezeken múlik, hogy az oldalad öt év múlva is biztonságosan működik-e.

Frissíthető tartalomkezelő, nem egyszeri kódhalom

A tartalomkezelő rendszer (CMS, content management system) az a szoftver, amelyben a szövegeket, a képeket és az oldalakat szerkeszted. 2026-ban három jellemző út létezik egy KKV számára: a saját tárhelyen futó WordPress, a headless felépítés (például Next.js-alapú megjelenítés egy külön tartalomforrással) és a zárt SaaS-platform, mint a Webflow vagy a Shopify. Mindhárom lehet jó döntés, a kérdés inkább az, hogy a választott rendszert ki és hogyan tartja naprakészen.

WordPressnél kérdezd meg, melyik fő verzióra épül az oldal. A WordPress 7.0 „Armstrong” idén május 20-án jelent meg, azóta érkezett a 7.1 „Mary Lou” és a 7.1.1-es biztonsági kiadás, a Gutenberg Times szerint pedig a 7.2 végleges változata a december 8-a és 10-e közötti napokra várható. Egy most átadott oldalnak a legfrissebb, 7.1.1-es verzión kell futnia, a sablonnak (témának) és a bővítményeknek pedig olyanoknak kell lenniük, amelyek a jövőbeli frissítéseket is túlélik. Arra is kérdezz rá, hány bővítményt használ az oldal, illetve melyik miért kell, mert minden felesleges bővítmény újabb frissítendő és potenciálisan sérülékeny elem.

Next.js-alapú oldalnál a támogatott kiadási ág a döntő kérdés: a Next.js blogja szerint jelenleg a 16.3 az aktív hosszú távú támogatású (LTS) ág, a 15.5 pedig karbantartott LTS. Ha valaki ennél régebbi verzióra építene, kérdezd meg, miért. SaaS-platformnál a frissítést a szolgáltató végzi, cserébe a platform változásait el kell fogadnod: a Webflow régi szerkesztője például 2026. augusztus 4-én megszűnt, a helyén már az oldalon belüli szerkesztés működik.

Az egyedi, saját fejlesztésű CMS nem ördögtől való, de ennél különösen fontos, hogy a forráskód és a dokumentáció a tiéd legyen, a rendszer pedig egy elterjedt, támogatott keretrendszerre (például Laravelre) épüljön. Ha csak az a fejlesztő érti, aki írta, akkor valójában nem egy honlapot vásárolsz, hanem egy hosszú távú függőséget.

PHP 8.2 vagy újabb, de inkább 8.3 vagy 8.4

A PHP az a programozási nyelv, amelyen a WordPress, a WooCommerce és a legtöbb hazai tárhelyen futó tartalomkezelő dolgozik. A php.net hivatalos támogatási rendje szerint minden PHP-ág két év aktív és további két év csak biztonsági támogatást kap, utána semmilyen javítás nem jön hozzá. A szeptember 22-i helyzet így néz ki:

A WordPress hivatalos követelményoldala PHP 8.3-at vagy újabbat ajánl, adatbázisnak pedig MariaDB 10.11-et vagy MySQL 8.0-t, illetve ezeknél frissebbet. A WooCommerce a 11.5-ös verziótól, vagyis 2027 januárjától már a PHP 7.4-et és a 8.0-t sem támogatja. A „PHP 8.2 vagy újabb” tehát ma az abszolút minimum, de egy most induló projektnél ez azt jelentené, hogy az oldal alig három hónappal az indulás után már verzióváltásra szorul. Kérj PHP 8.3-at vagy 8.4-et, a szerződésbe pedig írasd bele, ki végzi a következő verzióváltást és mikor.

A futó PHP-verziót a WordPress Site Health oldala és a tárhely kezelőfelülete is kiírja, átadáskor kérj róla képernyőképet.

HTTPS, amely magától megújul

Az, hogy az oldal HTTPS-en fusson, 2026-ban alapelvárás, a valódi kérdés az, ki gondoskodik a tanúsítvány megújításáról. A böngészőgyártókat és a tanúsítványkiadókat tömörítő CA/Browser Forum SC-081v3 határozata szerint a nyilvános TLS-tanúsítványok (köznyelven SSL-tanúsítványok) maximális érvényessége lépcsőzetesen csökken: a 2026-os március 15-i fordulónaptól 200 nap, 2027-től 100 nap, 2029-től pedig mindössze 47 nap. Az évente egyszer kézzel megújított tanúsítvány kora tehát lejárt. Kérd, hogy a megújítás automatikusan történjen (erre szolgál az ACME protokoll, amelyet például a Let's Encrypt is használ), a lejárat előtti figyelmeztetés pedig olyan e-mail-címre menjen, amelyet valaki tényleg olvas.

Átadáskor három dolgot nézz meg: a http:// kezdetű címek automatikusan átirányítanak-e a https:// változatra, a böngésző jelez-e vegyes tartalmat (mixed content, vagyis titkosítatlanul betöltött képet vagy szkriptet), végül a www-s és a www nélküli cím ugyanoda vezet-e.

Mentés, amelyből vissza is lehet állni

A mentés csak akkor ér valamit, ha vissza is lehet állni belőle, ezt pedig valaki ki is próbálta. Az iparági alapszabály a 3-2-1 elv: legyen legalább három példány az adatokból, legalább két különböző tárolótípuson, ebből egy példány pedig a tárhelytől fizikailag független helyen. Egy KKV-honlapnál ez a gyakorlatban napi automatikus adatbázis- és fájlmentést jelent, amelyet a tárhelyen kívül egy külső tárolóra (például felhőalapú objektumtárba) is átmásolnak.

Kérdezz rá arra is, meddig őrzik a mentéseket. Mi legalább 30 napos visszamenőleges megőrzést javaslunk, mert egy feltört oldalnál gyakran csak hetekkel később derül ki a fertőzés, ilyenkor pedig egy mindössze hét napra visszanyúló mentéssor minden eleme fertőzött lehet. Webshopnál, ahol naponta keletkeznek rendelések, a napinál sűrűbb adatbázismentés is indokolt lehet.

Átadáskor kérj visszaállítási próbát: az ügynökség állítsa vissza az oldal egy korábbi mentését egy tesztkörnyezetbe, majd mutassa meg, hogy működik. Ez jellemzően nem nagy munka, mégis többet elárul az ügynökség üzemeltetési fegyelméről, mint bármilyen referencia vagy díj a falon.

Kié lesz a domain, a tárhely és a forráskód?

Mindegyik a te cégedé legyen. A domain a céged nevére szóljon, a tárhely- és licencszerződések a céged fiókjában fussanak, a forráskód egy olyan Git-tárolóban legyen, amelyhez hozzáférsz, az adminisztrátori jelszavak pedig egy közös jelszókezelőben. Az ügynökség dolgozhat mindezekben, de a kulcsokat ne ő őrizze egyedül.

Ez a pont elsőre bürokratikusnak tűnik, pedig a legtöbb fájdalmas ügynökségváltás itt csúszik el. Tegyük fel, hogy egy képzeletbeli balatoni panzió honlapját évekkel ezelőtt egy szabadúszó készítette, aki a domaint a saját nevére regisztrálta, a tárhelyet a saját fiókjából fizette, a fizetős foglalási bővítmény licence pedig szintén az ő nevén futott. Amikor a szabadúszó más munkába kezd és nem válaszol az e-mailekre, a panzió nemcsak a honlapját nem tudja frissíteni, hanem a saját domainjéhez sem fér hozzá, a foglalási bővítmény pedig licenc nélkül nem kap több biztonsági javítást. A helyzet megoldható, de hetekig tart és pénzbe kerül, miközben a főszezon nem vár.

Az alábbiakat kérd számon már az ajánlatkéréskor, az átadáskor pedig ellenőrizd:

• A domain-nyilvántartásban a céged szerepeljen a domain használójaként, a regisztrátori fiókhoz pedig neked is legyen saját hozzáférésed.
• A tárhelyszerződés a céged nevén legyen, vagy a szerződés írja le, hogy díjmentesen és rövid határidővel átadható.
• Minden fizetős téma és bővítmény licence a céged fiókjában fusson, a megújítási dátumokkal együtt, mert a lejárt licenc a frissítések végét is jelenti.
• A forráskód egy Git-tárolóban (például GitHubon vagy GitLabon) legyen, amelyhez legalább olvasási jogod van.
• Legyen saját adminisztrátori fiókod kétlépcsős azonosítással, a közös jelszavak pedig egy jelszókezelőben legyenek, ne e-mailben vagy táblázatban.
• Kapj rövid átadási dokumentációt a felépítésről, a használt bővítményekről, a mentési rendről és a frissítési folyamatról.

Egyedi fejlesztésnél a felhasználási jog külön mondatot érdemel. A szoftver a magyar szerzői jog szerint is szerzői műnek számít, ezért a szerződésnek ki kell mondania, milyen terjedelmű felhasználási jogot kapsz és átdolgozhatja-e később más fejlesztő a kódot. Egy korrekt ügynökség ezt magától is leírja, egy kevésbé korrekt pedig ilyenkor kezd el hirtelen óvatosan fogalmazni.

Kérj kilépési záradékot is. Ha az együttműködés véget ér, az ügynökség meghatározott időn belül (például 15 munkanapon belül) adja át az összes hozzáférést, a legfrissebb mentést és a dokumentációt, külön díj nélkül. Ez nem bizalmatlanság, csak ugyanolyan józan óvintézkedés, mint a kaució rendezése egy bérleti szerződésben.

Külön vészjelnek számítanak a „nulled”, vagyis feltört, licenc nélkül terjesztett fizetős bővítmények és témák, amelyek nem kapnak hivatalos frissítést, gyakran eleve kártékony kódot tartalmaznak, a használatuk pedig jogilag is aggályos.

AI-kompatibilitás: strukturált adat, WebMCP-készenlét, idézhető tartalom

Az AI-kompatibilitás azt jelenti, hogy a honlapodat a gépek is pontosan értik: a Google AI Overviews és AI Mode, a ChatGPT, a Gemini vagy a Perplexity forrásként tudja használni, egy AI-ügynök pedig el tud rajta végezni egy egyszerű feladatot. A szakma ezt GEO-nak (generative engine optimization, optimalizálás a generatív keresőkre) és AEO-nak (answer engine optimization, optimalizálás a válaszmotorokra) nevezi. Egy új honlapnál három építőelemet kérj számon.

Strukturált adat: a honlap gépi névjegye

A strukturált adat a Schema.org szókészletére épülő, a látogató számára láthatatlan leírás, amely gépileg olvasható formában közli, mi van az oldalon: ki a cég, hol található, mikor van nyitva, mennyibe kerül egy termék, ki írta a cikket és mikor frissítette. A Google a JSON-LD formátumot ajánlja, amely egy külön kódblokkban él az oldal forrásában, így a dizájntól függetlenül karbantartható. Egy KKV-honlapon legalább ezeket a típusokat kérd:

• Organization vagy LocalBusiness típust a főoldalon, a cégnévvel, címmel, telefonszámmal, nyitvatartással és a közösségi profilok linkjeivel.
• Article vagy BlogPosting típust a blogcikkeken, szerzővel, megjelenési és módosítási dátummal.
• Product és Offer típust a webshop termékoldalain, árral, pénznemmel és készletinformációval.
• BreadcrumbList típust a morzsamenühöz, amely az oldal szerkezetét mutatja meg a gépeknek.
• Service vagy FAQPage típust ott, ahol valóban szolgáltatásleírás vagy gyakori kérdések szerepelnek.

Két szabály mindenhol érvényes. A strukturált adat csak azt állíthatja, ami a látható oldalon is szerepel, különben a Google figyelmen kívül hagyja, súlyosabb esetben kézi intézkedéssel is sújthatja az oldalt. A jelölést ráadásul sablonból kell generálni, nem kézzel bemásolni, hogy egy árváltozás vagy egy új nyitvatartás automatikusan átvezetődjön. Átadáskor kérd, hogy az ügynökség futtassa le a főbb oldalsablonokat a Google Rich Results Test és a Schema Markup Validator eszközön, az eredményt pedig küldje el neked.

Idézhető tartalom: bekezdések, amelyek önmagukban is megállnak

Az AI-válaszok nem teljes oldalakat idéznek, hanem bekezdéseket, mondatokat és számokat. Az idézhető tartalom ezért olyan szöveg, amelynek bekezdései előzmények nélkül is érthetők, konkrét adatot tartalmaznak, a fontos állításoknál pedig megnevezik a forrást és a dátumot. A szolgáltatásoldalak elején két-három mondatban szerepeljen a lényeg (mit csinálsz, kinek, hol és milyen feltételekkel), a fogalmakat pedig definíciós mondatok magyarázzák. A „rugalmas árazás” semmit nem mond egy AI-nak, egy pontos kiszállási díj vagy egy konkrét határidő viszont idézhető.

Ugyanígy segít, ha a cikkeknek látható szerzője és frissítési dátuma van, a címsorok pedig olyan kérdések, amelyeket a vevőid ténylegesen feltesznek. Mivel a tartalmat legtöbbször te adod, az ügynökségtől annyit kérj számon, hogy a sablonok támogassák ezt a szerkezetet (szerzői doboz, frissítési dátum, GYIK-blokk, táblázatok), a szövegírásnál pedig ismerje és alkalmazza ezeket az elveket.

A mennyiség ráadásul nem pótolja a minőséget. A Numinix összesítése szerint a Google idei augusztusi spam frissítése után a top 10-es találatok 16,71%-a a 100. hely mögé került, a mozgás a szokásosnál 82%-kal nagyobb volt és mind a 20 vizsgált iparágat érintette. Ha egy ajánlat havi harminc, AI-val generált blogcikket ígér, kérdezd meg, ki ellenőrzi bennük a tényeket és ki vállal értük felelősséget.

WebMCP-készenlét: előkészítés, nem teljes bevezetés

A WebMCP a Google által javasolt webes szabvány, amellyel egy weboldal strukturált eszközöket deklarálhat az AI-ügynököknek, így azoknak nem kell a HTML-szerkezetből (a DOM-ból) kitalálniuk, hol a foglalás gomb és melyik mezőbe kerül a telefonszám. Két formája van: az imperatív API JavaScriptből regisztrál eszközöket, a deklaratív API pedig a meglévő HTML-űrlapokat látja el annotációkkal. A Chrome fejlesztői dokumentációja szerint a Chrome 149-es verziójától origin trialként (korlátozott, regisztrációhoz kötött próbaként) érhető el, a specifikáció pedig még változhat.

Ebből következik a józan álláspont: 2026 őszén egy átlagos KKV-honlapnál nem érdemes teljes WebMCP-bevezetésért fizetni, az előkészítésért viszont igen. Mivel a deklaratív API a meglévő űrlapokra épít, a legjobb előkészítés a tiszta, szabványos HTML. Minden űrlapmezőnek legyen címkéje (label) és beszédes neve, a kötelező mezők legyenek jelölve, a hibaüzenetek pedig szövegesen jelenjenek meg. Ha a legfontosabb üzleti műveletek (ajánlatkérés, időpontfoglalás, kosárba tétel) egyszerű űrlapként működnek, nem egy külső szolgáltató beágyazott ablaka mögé zárva, akkor a WebMCP véglegesedésekor kis munkával eszközzé alakíthatók.

Ugyanez az akadálymentességnek is jót tesz, vagyis a befektetés akkor is megtérül, ha a szabvány végül más formában véglegesedik. A WordPress-világban gyors a fejlődés: a Playground WebMCP-támogatást kapott 16 beépített művelettel (oldalkezelés, PHP-futtatás, navigáció, fájlműveletek), a WordPress Core AI csapata szerint pedig az MCP Adapter beküldésre kész a bővítménytárba. Ajánlatkéréskor elég annyit kérdezni, hogy ha a szabvány stabil lesz, mennyi munkával és milyen áron kerül be az oldalba.

Mit engedsz meg a gépeknek?

A Numinix összefoglalója szerint az oldal tulajdonosa a Search Console-ban kimaradhat a Google generatív AI-funkcióiból, a robots.txt fájlban pedig szabályozható, mely robotok olvashatják az oldalt. Egy KKV-nak többnyire az a jó, ha a Google és a nagy AI-asszisztensek hozzáférnek a tartalmához, de ezt az üzleti döntést neked kell meghoznod, az átadási dokumentáció pedig rögzítse a jelenlegi beállítást.

Milyen gyors legyen egy új weboldal és hogyan írd bele a szerződésbe?

A mércét a Google Core Web Vitals mutatói adják: a legnagyobb tartalmi elem 2,5 másodpercen belül jelenjen meg (LCP), a kattintásokra adott válasz legfeljebb 200 ezredmásodperc legyen (INP), az elrendezés elcsúszása pedig ne haladja meg a 0,1-es értéket (CLS). Mindezt a látogatások legalább 75%-ánál kell teljesíteni, mobilon is.

A Core Web Vitals a Google által meghatározott három felhasználóiélmény-mutató, amelyet valós látogatói adatokból is mér. Az INP (Interaction to Next Paint) 2024-ben váltotta a korábbi FID-mutatót, ezért ha egy ajánlatban még FID-értékek szerepelnek, az régi sablonra vagy régi tudásra utal. A 75%-os küszöb azt jelenti, hogy nem az átlag számít, hanem az, hogy a lassabb telefonnal és gyengébb mobilnettel érkezők is elfogadható élményt kapjanak.

A szerződésbe két lépcsőben érdemes beírni a sebességet. Átadás előtt laboratóriumi mérés dönt, például a PageSpeed Insights vagy a Lighthouse eredménye a főbb oldalsablonokon, mobilnézetben, mert valós látogatói adat ilyenkor még nincs. Az indulás után néhány héttel a Search Console Core Web Vitals jelentése és a Chrome valós felhasználói adatai (CrUX) mutatják meg, mit tapasztalnak a látogatók, feltéve, hogy az oldalnak már elegendő forgalma van. Érdemes rögzíteni, hogy ha a valós adatok a küszöbértékek fölött maradnak, az ügynökség meghatározott határidőn belül díjmentesen javít.

Légy igazságos is, mert a sebességet gyakran nem az ügynökség kódja rontja le, hanem az utólag beillesztett külső szkriptek, például egy chatablak, három különböző követőkód vagy egy automatikusan induló háttérvideó. A szerződésben ezért legyen leírva, hogy a vállalás az átadott állapotra szól, az utólagos beépítések hatását pedig közösen mérik. Kérdezz rá a képek kezelésére is, mert a modern képformátumok (WebP, AVIF), a képernyőmérethez igazított változatok és a lusta betöltés ma alapkövetelménynek számítanak.

Azt is kérdezd meg, használ-e az ügynökség natív böngészős megoldásokat (például a Chrome 146 óta elérhető View Transitions animációkat) a nehéz JavaScript-könyvtárak helyett.

Biztonság és karbantartás: ki frissít és mikor

A karbantartás a legtöbb ajánlatban egyetlen sor („rendszeres frissítés”), holott ez a honlap életének leghosszabb szakasza. A WordPress szeptember 17-én kiadott 7.1.1-es verziója a wordpress.org közleménye szerint 17 alaprendszer- és 19 blokkszerkesztő-hibajavítás mellett 11 biztonsági javítást tartalmazott. Ezek között volt XSS-hiba (kártékony szkript bejuttatását lehetővé tevő hiba) a wpautop() függvényben, jogosulatlan tématelepítés és path traversal hiba a REST Templates Controllerben, a WordPress pedig azonnali frissítést javasolt.

A Next.js-alapú oldalak sem úszták meg. Augusztus 25-én két kritikus sérülékenység miatt jelent meg a 16.3.3-as és a 15.5.24-es kiadás, szeptember 22-én pedig egy külső (upstream) függőség hibája miatt soron kívüli kritikus frissítésként a 16.3.6-os és a 15.5.26-os. Ha egy ügynökség azt mondja, hogy a modern, JavaScript-alapú oldalaknak nincs szükségük karbantartásra, ez a két dátum elég ellenérv.

A karbantartási szerződésnek öt kérdésre kell írásban válaszolnia: ki figyeli a biztonsági közleményeket, milyen határidővel telepíti a kritikus javításokat, készül-e minden frissítés előtt mentés, van-e tesztkörnyezet (staging), ahol a frissítést előbb kipróbálják, végül hogyan értesülsz arról, mi történt. Az alábbi táblázat egy kiinduló javaslat, amelyet a saját oldalad méretéhez igazíthatsz.

A 48 órás határidő a mi ajánlásunk, nem jogszabályi előírás. A lényeg, hogy legyen leírt határidő, mert enélkül a kritikus javítás könnyen a következő havi karbantartási körig várakozik, holott ez a néhány hét bőven elég egy automatizált támadásnak.

Az alapvető védelmi beállításokat is kérd számon: kétlépcsős azonosítás minden adminisztrátori fióknál, csak a feltétlenül szükséges jogosultságok (a szövegeket szerkesztő kollégának ne legyen adminisztrátori joga), a nem használt bővítmények és témák törlése (nem csak kikapcsolása), valamint webalkalmazás-tűzfal (WAF) a tárhely vagy egy külső szolgáltató szintjén. Egyik sem drága vagy bonyolult, együtt viszont jelentősen csökkentik a kockázatot.

Hogy mennyit ér mindez, azt egy saját becsléssel lehet a legjobban érzékeltetni. Vegyünk egy képzeletbeli debreceni webshopot, amely napi átlag 25 rendelést kap 18 000 Ft-os kosárértékkel, ez napi 450 000 Ft forgalom. Ha egy elmaradt bővítményfrissítés miatt feltörik és három napig áll, amíg tiszta mentésből helyreállítják, ez 25 × 18 000 × 3, vagyis 1 350 000 Ft kiesett forgalom, a helyreállítás díja és a vevői bizalom sérülése nélkül. Ha az incidens személyes adatokat is érint, a GDPR szerint főszabályként 72 órán belül a Nemzeti Adatvédelmi és Információszabadság Hatóságnak (NAIH) is be kell jelenteni, ami további munkát és jogi költséget jelent. Egy havi karbantartási díj ennek jellemzően a töredéke, a kérdés tehát nem az, hogy a biztonság drága-e, hanem hogy előre vagy utólag fizeted meg.

Milyen jogi és akadálymentességi elvárásoknak kell megfelelnie egy új honlapnak?

Minden céges honlapnál kell adatkezelési tájékoztató, jogszerű süti-hozzájárulás és a cég azonosító adatai. Webshopnál a 2025 nyara óta alkalmazandó európai akadálymentességi irányelv is vonatkozhat rád, ha nem vagy mikrovállalkozás, AI-chatbotnál pedig az idén augusztusban hatályba lépett uniós szabály szerint jelezni kell, hogy a látogató géppel beszél.

Az európai akadálymentességi irányelvet (European Accessibility Act, EAA) 2025. június 28-a óta kell alkalmazni, többek között az elektronikus kereskedelmi szolgáltatásokra, vagyis jellemzően a webshopokra. A szolgáltatást nyújtó mikrovállalkozások, tehát a 10 főnél kevesebbet foglalkoztató, legfeljebb 2 millió eurós éves árbevételű vagy mérlegfőösszegű cégek mentesülnek alóla. Ha a céged efölött van, a gyakorlati mérce a WCAG 2.1 AA szintje: megfelelő színkontraszt, billentyűzettel is bejárható oldal, alternatív szöveg a képeken és címkézett űrlapmezők. Ha mentesülsz, akkor is érdemes ezeket kérni, mert az elején sokkal olcsóbb beépíteni őket, mint utólag javítani, ráadásul ugyanez segíti az AI-ügynököket is.

A süti-hozzájárulásnál a leggyakoribb hiba, hogy a mérő- és hirdetési kódok már azelőtt betöltődnek, hogy a látogató bármire kattintott volna. Kérd, hogy a hozzájáruláskezelő (CMP) blokkolja ezeket a kódokat a hozzájárulásig, a Google-eszközök pedig megkapják a Consent Mode jelzéseit. Az adatkezelési tájékoztatót jogász vagy adatvédelmi szakember írja, ne sablongenerátor. Kerüljön bele minden külső szolgáltatás, amely személyes adatot kap, az űrlapszolgáltatótól a hírlevélrendszeren át a chatig.

Ha az új oldalon AI-chatbot vagy AI-alapú ügyfélszolgálat fut, a Gibson Dunn összefoglalója szerint az EU AI Act 50. cikkének átláthatósági kötelezettsége 2026. augusztus 2-án lépett hatályba: a felhasználóval közölni kell, hogy AI-rendszerrel lép kapcsolatba. Ez a gyakorlatban egy jól látható jelzés a chatablakban, amelyet az átadáskor egyetlen pillantással ellenőrizhetsz.

Mérés: Search Console, AI-riportok, konverziókövetés az első naptól

Egy honlap, amelynél nem látod, honnan jönnek a látogatók és mit csinálnak, olyan, mint egy bolt pénztárgép nélkül: lehet, hogy jól megy, de soha nem fogod tudni, mennyire. A mérést ezért ne utólagos kiegészítésként kérd, hanem az átadás részeként, az indulás napjára beállítva, mert az első hetek adatai később nem pótolhatók.

Search Console és az új AI-riportok

A Search Console a Google ingyenes eszköze, amely megmutatja, milyen keresésekre, hányszor és hányadik helyen jelenik meg az oldalad, illetve milyen technikai hibákat talál rajta. Kérd, hogy a tulajdon domain szintű (DNS-alapú) legyen, a tulajdonosi jogot pedig te is megkapd, ne csak az ügynökség. A Numinix összefoglalója szerint az augusztus 31-én globálisan elindult generatív AI-riportok oldalanként mutatják az AI-megjelenéseket, országok, eszközök és időbeli trendek szerint bontva. Ez a Google saját adatforrása arról, milyen gyakran használja fel az AI-ja az oldaladat, ezért egy új honlapnál az első hónaptól érdemes figyelni. Szeptemberben ráadásul egy kiadói fizetési pilot is elindult, amely az AI-válaszok formálásáért járó bevételt mutatja, vagyis az AI-láthatóság lassan pénzben is mérhető.

Konverziókövetés, amely a pénzt méri

A konverzió az a látogatói lépés, amely üzleti értéket teremt: ajánlatkérés, telefonhívás, vásárlás, időpontfoglalás vagy hírlevél-feliratkozás. Konverziókövetés nélkül a Google Ads és a Meta hirdetési algoritmusai vakon optimalizálnak, te pedig csak érzésre tudod megmondani, melyik csatorna hoz ügyfelet. Egy KKV-nál jellemzően négy-öt konverziót érdemes beállítani: az űrlapküldést, a telefonszámra és az e-mail-címre kattintást mobilon, webshopnál a vásárlást a kosárértékkel együtt, valamint az időpontfoglalást, ha van ilyen. Mindegyiknek látszania kell a Google Analytics 4-ben, hirdetés esetén pedig a hirdetési fiókokba is át kell kerülnie.

A Google Cégprofilodban szereplő weboldallinket lásd el UTM-paraméterrel (a link végére illesztett forrásjelöléssel), így az Analyticsben külön látod az onnan érkezőket. Magát a profilt is érdemes gondosan kitölteni, mert a Whitespark kutatása szerint a teljes Cégprofil nagyjából 13%-ban került be a helyi top 10-be, a minimálisan kitöltött csak körülbelül 4%-ban.

Ha a régi honlapot cseréled

Az új honlap indulásakor az egyik legdrágább hiba az elfelejtett átirányítás. Ha a régi oldal címei megváltoznak, a Google-ben és más oldalakon lévő linkek hibaoldalra (404) futnak, az évek alatt gyűjtött helyezések pedig elveszhetnek. Kérj átirányítási tervet, vagyis egy táblázatot, amely a régi oldal minden fontos címéhez hozzárendeli az új megfelelőjét 301-es (végleges) átirányítással. Az indulás előtt exportáld a Search Console és az Analytics legfontosabb adatait, hogy legyen mihez viszonyítani.

Az indulás napjának mérési teendői sorrendben:

• Ellenőrizd, hogy a domain szintű Search Console-tulajdon él és te is tulajdonos vagy benne.
• Küldd be az XML-oldaltérképet (sitemap) a Search Console-ban, majd nézd meg, hibátlanul feldolgozta-e a Google.
• Nézd meg, hogy a robots.txt nem tiltja-e le véletlenül az egész oldalt, ami a tesztkörnyezetből áthozott beállításoknál gyakori hiba.
• Fogadd el a süti-sávot, majd ellenőrizd, hogy a Google Analytics 4 valós idejű nézete mutatja-e a látogatásodat.
• Küldj be egy tesztűrlapot, kattints a telefonszámra mobilon, webshopnál adj le egy tesztrendelést, végül nézd meg, mindhárom megjelenik-e konverzióként.
• Próbálj ki néhány régi címet az átirányítási tervből, mindegyiknek a megfelelő új oldalra kell vinnie.
• Futtasd le a főoldalt és egy termék- vagy szolgáltatásoldalt a Rich Results Testen a strukturált adat ellenőrzésére.
• Állíts be emlékeztetőt 30 nappal későbbre, amikor átnézed az első AI-riportot, a Core Web Vitals valós adatait és a konverziók számát.

Hogyan kérj ajánlatot, hogy a válaszok összehasonlíthatók legyenek?

Írj egy egyoldalas projektleírást, csatold hozzá az ellenőrzőlistát, majd kérd, hogy minden ajánlattevő pontonként, írásban válaszoljon. Az árat bontva kérd (fejlesztés, tartalom, mérés, első év üzemeltetése, havi karbantartás), mert a legolcsóbb végösszeg mögül gyakran épp a karbantartás hiányzik.

A folyamat lépésről lépésre így néz ki:

• Írd le egy oldalon, mi a honlap üzleti célja (ajánlatkérés, foglalás, online értékesítés vagy toborzás), kik a látogatók és melyik az a három-négy művelet, amelyet az oldalon el kell tudniuk végezni.
• Gyűjtsd össze, mi van már meg: domain, tárhely, logó, szövegek, fotók, a régi oldal és annak Search Console-adatai.
• Küldd el ugyanazt a leírást és ugyanazt az ellenőrzőlistát három-négy ajánlattevőnek, ugyanazzal a határidővel.
• Kérd, hogy az ajánlat külön sorban tartalmazza a fejlesztés, a tartalomkészítés, a mérés beállítása, az első év üzemeltetése és a havi karbantartás díját.
• Pontozd a válaszokat: minden pontra 0 pont jár, ha nincs válasz vagy homályos, 1 pont, ha van érdemi válasz, 2 pont, ha bizonyíték is tartozik hozzá.
• Kérj referenciát olyan ügyféltől, akinek az oldalát az ügynökség legalább két éve üzemelteti, tőle pedig kérdezd meg, milyen gyorsan reagáltak egy hibára.
• A nyertes ajánlat pontjait emeld át a szerződésbe átvételi feltételként, a karbantartási vállalásokat pedig külön szolgáltatási szerződésben rögzítsd.

Tegyük fel, hogy a képzeletbeli kecskeméti asztalosüzem három ajánlata közül a legolcsóbb 22 pontot kap a lehetséges 50-ből, a középső 41-et, a legdrágább 44-et. Ilyenkor valószínűleg a középső ajánlat a legjobb választás, a pontszám pedig abban is segít, hogy a döntést a tulajdonostársak vagy a könyvelő előtt is meg tudd indokolni.

Milyen vészjelek utalnak arra, hogy rossz kezekbe kerül a honlapod?

A legbiztosabb vészjelek: a domaint az ügynökség a saját nevére regisztrálná, nincs írásos frissítési vállalás, nem tudnak mentés-visszaállítást mutatni, feltört bővítményeket használnak, vagy garantált első helyet ígérnek a Google-ben. Bármelyik elég ahhoz, hogy alaposabban rákérdezz, kettő együtt pedig ahhoz, hogy továbblépj.

• „Nálunk nem kell frissíteni, mert egyedi a rendszer.” Minden szoftverben vannak hibák, az egyediben is, csak ott senki más nem keresi és javítja őket.
• Az ajánlatban PHP 7.4 vagy 8.0 szerepel, esetleg a tárhelyen még ez fut, holott ezek a php.net szerint már semmilyen támogatást nem kapnak.
• Nincs tesztkörnyezet, a frissítéseket közvetlenül az éles oldalon végzik, jellemzően péntek délután.
• Az adminisztrátori hozzáférést „biztonsági okokból” nem adják ki, pedig a biztonság kétlépcsős azonosítással és jogosultságkezeléssel oldható meg, nem a tulajdonos kizárásával.
• Garantált első helyet ígérnek a Google-ben vagy garantált megjelenést az AI-válaszokban, holott a rangsorról a keresők algoritmusai döntenek, ezt senki nem garantálhatja.
• Átadási dokumentáció nincs, vagy csak a projekt végén, külön díjért kaphatod meg.
• A karbantartási díj fix, de nem derül ki, mit tartalmaz: hány órát, milyen határidőket és milyen jelentést.

Egy vészjel még nem ítélet, néha csak egy rossz megfogalmazás van mögötte. A lényeg, hogy rákérdezz, majd figyeld, mennyire konkrét és mennyire gyors a válasz.

A teljes ellenőrzőlista egy táblázatban

Az alábbi táblázat a fenti pontokat egy helyre gyűjti, az utolsó oszlop pedig azt mutatja, mikor kötelező az adott elem.

Ha egy ügynökség ezt a táblázatot látva megkönnyebbül, mert minden sorra van kész válasza, jó helyen jársz. Ha viszont bosszankodik, hogy „ez túl sok”, az is sokat elárul arról, hogyan bánik majd az oldaladdal az átadás után.

Miben segít a Convergo?

Ha új honlapot tervezel, a webdesign és weboldalkészítés szolgáltatásunkban ezt az ellenőrzőlistát követjük: a domain, a hozzáférések és a licencek a te cégednél maradnak, a mérést pedig az indulás napjára beállítjuk. Egy weboldal elkészítésének díja 299 000 Ft, a support, üzemeltetés és tárhely csomagunk pedig havi 30 000 Ft-ért három fejlesztői órát tartalmaz a frissítésekre és a karbantartásra. A landing page és mérés szolgáltatással a konverziókövetést és a Search Console-t is beállítjuk. Az első lépés egy ingyenes egyeztetés, ahol a lista alapján közösen átnézzük a jelenlegi oldaladat vagy az új projekt tervét.