Miért Üzleti Rendszer a Weboldal?
A legtöbb cégvezető azzal a kéréssel keres fel fejlesztőt, hogy “kellene egy szép weboldal”.
Néhány hónappal később kiderül, hogy a szép oldalról senki nem kér ajánlatot.
A céges weboldal nem digitális névjegykártya, hanem üzleti rendszer.
A célja mérhető eredmény: ajánlatkérés, foglalás, telefonhívás, feliratkozás, vagyis leadgenerálás.
Ha ezt nem tudod számokban követni, nincs weboldalad, csak online brosúrád.
2026-ban a látogatói elvárás jóval magasabb, mint öt évvel ezelőtt.
Két másodperc alatt el kell dőlnie, hogy mit kínálsz, kinek, és mi a következő lépés.
A mobilbarát weboldal ma nem extra, hanem alapfeltétel, hiszen a magyar kisvállalati oldalak forgalmának jellemzően 60-75 százaléka telefonról érkezik.
A weboldal minősége nem azon mérhető, hogy tetszik-e a vezetőségnek, hanem azon, hogy hány érdeklődőből lesz megkeresés.
Ez a cikk végigvezet a teljes döntési láncon. Először a céltól indulunk, onnan az oldaltípus kiválasztásán át a felhasználói útvonal és a tartalom megtervezéséig, majd a technológiai és technikai SEO döntésekig, végül a projekt lebonyolításáig és átadásáig.
A sorrend nem véletlen.
A rossz korai döntések évekre visszahúzzák a vállalkozás digitális jelenlétét, és a javításuk sokszor drágább, mint az eredeti fejlesztés.
Három hiba fordul elő a leggyakrabban.
Az első a bővíthetőség nélküli sablonvásárlás, ahol az első komolyabb igény, például egy foglalási funkció, azonnal falba fut. A második a technikai adósság: elavult pluginok, lassú oldal, kezelhetetlen kódbázis.
A harmadik a legfájóbb.
Tisztázatlan tulajdonjog, amikor a domain, a tárhely vagy a forráskód nem a cégé, hanem a fejlesztőé.
Ilyenkor az együttműködés vége nem költözés, hanem újrakezdés.
Melyik Weboldaltípus Illik Hozzád?
A típusválasztás nem esztétikai, hanem üzleti kérdés.
Egy ötven aloldalas bemutatkozó honlap kevesebb ajánlatkérést hozhat, mint egy jól megírt egyoldalas landing page, ha a forgalom hirdetésből jön.
Négy Típus, Négy Cél
Az alábbi táblázat a négy leggyakoribb formát hasonlítja össze. Az adatok magyar kis- és középvállalati projektek tipikus tapasztalati sávjai, nem garanciák, de jó kiindulási keretet adnak a tervezéshez.
| Típus | Elsődleges cél | Tipikus aloldalszám | Tartalomigény | Tipikus konverziós arány |
|---|---|---|---|---|
| Bemutatkozó honlap | Bizalomépítés, organikus megkeresések gyűjtése | 6-15 aloldal | Közepes: szolgáltatásleírások, referenciák, csapat | 1-3% (ajánlatkérés) |
| Landing page | Egyetlen kampányajánlat konverziója | 1-3 aloldal | Alacsony darabszám, magas szövegminőség | 3-10% (űrlap vagy hívás) |
| Webshop | Online tranzakció, ismételt vásárlás | 20-500+ (termékek szerint) | Nagyon magas: termékadatok, képek, leírások | 0,8-2,5% (vásárlás) |
| Webalkalmazás | Folyamat kiszolgálása bejelentkezés után | Nem aloldal-alapú, hanem funkció-alapú | Adatmodell és folyamatleírás dominál | 10-40% (aktiválás vagy foglalás) |
A választásnál négy szempontot érdemes végigvenni. Honnan jön a forgalom: organikus keresésből, ahol tartalomra és technikai SEO-ra van szükség, vagy fizetett hirdetésből, ahol fókuszált landing page teljesít jobban?
Mennyi az értékesítési ciklus hossza?
Egy 200 ezer forintos szolgáltatásnál egy űrlap elég.
Egy 15 milliós beruházásnál esettanulmány, kalkulátor és referenciaanyag kell a döntés érleléséhez.
Kell-e bejelentkezés vagy tranzakció?
Ha a felhasználónak saját adatot kell látnia, már nem weboldalról, hanem alkalmazásról beszélünk.
És végül: mennyi tartalmat tud a cég valóban előállítani, mert az üres aloldal rosszabb, mint a nem létező.
Mikor Nő Túl Magán az Oldal
A webalkalmazás akkor válik szükségessé, amikor a látogatónak nem információra, hanem műveletre van szüksége. Ügyfélportál a szerződések és számlák megtekintéséhez, online foglalási rendszer szabad kapacitásokkal, árkalkulátor, vagy testreszabott dashboard riportokkal.
Ezek a funkciók jellemzően nem a nulladik körben jelennek meg, hanem a második évben.
Ezért érdemes már az induló céges oldalt úgy megtervezni, hogy legyen hova növekedni.
Gyakorlati példa.
Egy tízfős könyvelőiroda 8 aloldalas bemutatkozó honlappal indul, de a fejlesztő már az elején szétválasztja a tartalomkezelést a megjelenítéstől, például headless CMS vagy jól strukturált API-réteg használatával.
Az ajánlatkérő űrlap nem e-mailbe küld, hanem egy adatbázisba ír és onnan továbbít.
Amikor egy évvel később jön a CRM-integráció, csak egy új célpontot kell bekötni. Amikor jön az ügyfélportál, a felhasználókezelés ugyanarra az alapra épül.
Ez a tervezési fegyelem az induló projektben jellemzően 10-15 százalék többletmunkát jelent.
Az újrakezdés ára ennek a tízszerese.
Az Érdeklődőtől a Megkeresésig
A konverzió nem az űrlapon dől el.
Sokkal korábban, ott, ahol a látogató eldönti, hogy hitelesnek tart-e téged.
Milyen Aloldalak Kellenek
Az információs architektúra a weboldal alaprajza: mi hol van, mi mihez tartozik, és mi honnan érhető el. Egy tipikus céges oldal váza a következő elemekből áll.
- Főoldal: az ajánlat összefoglalása, a fő szolgáltatások belépőpontjai, bizonyítékok és egy elsődleges CTA. Nem gyűjtőhely mindennek, hanem forgalomirányító.
- Szolgáltatások: gyűjtőoldal, alatta külön aloldal minden fő szolgáltatásnak. Ezek hozzák az organikus forgalom nagy részét, mert itt találkozik a tartalom a konkrét keresési szándékkal.
- Referenciák és esettanulmányok: nevesített projektek, kiinduló helyzet, elvégzett munka, mérhető eredmény. Három részletes eset többet ér, mint húsz logó.
- Rólunk: arcok, nevek, szakmai háttér, cégadatok. B2B-ben ez gyakran a második leglátogatottabb aloldal.
- Kapcsolat: űrlap, kattintható telefonszám, e-mail, cím, nyitvatartás, térkép. Ne legyen belőle labirintus.
- Blog vagy tudásbázis: a keresési szándék korai szakaszát célozza, és belső linkekkel táplálja a szolgáltatásoldalakat.
- ÁSZF, adatvédelmi tájékoztató, cookie-tájékoztató: nem opcionális, és nem elég egy letöltött sablon átnevezése.
Extra aloldal akkor indokolt, ha üzleti funkciója van: árkalkulátor összetett árazásnál, gyakori kérdések hosszú értékesítési ciklusnál, karrieroldal aktív toborzásnál, letölthető anyagok leadgyűjtéshez.
A Kattintástól a Megkeresésig
Nézzük végig, mit tapasztal egy érdeklődő.
A felhasználói útvonal megtervezése wireframe szinten történik, még a UX és UI tervezés előtt, mert itt lehet a legkisebb költséggel javítani.
- Belépés: a látogató Google-találatból vagy hirdetésből egy szolgáltatásoldalra érkezik, nem a főoldalra. A cím és a bevezető pontosan azt ismételje meg, amit a kereséskor gondolt.
- Első képernyő: érthető ajánlat egy mondatban, kinek szól, mi az eredmény, és egy elsődleges CTA. Görgetés nélkül.
- Bizalmi szakasz: ügyfélvélemények, referenciák, számok, tanúsítványok. Ez az a pont, ahol a látogató 70 százaléka dönt a maradásról vagy a visszalépésről.
- Részletek: folyamatleírás, árazási logika, gyakori kérdések. A rejtett ár nem óvatosság, hanem súrlódás.
- Konverzió: ajánlatkérő űrlap vagy hívás. Az űrlap 3-5 mezőnél ne legyen hosszabb, mert minden további mező jellemzően 5-10 százalékkal csökkenti a kitöltési arányt.
A konkrét konverzióoptimalizálás néhány visszatérő elemen múlik: kattintható telefonszám mobilon, sticky CTA hosszú oldalakon, vélemények közvetlenül az űrlap fölött, valamint visszaigazoló oldal, amit mérni tudsz.
Ki Készíti Elő a Tartalmat?
A projektek csúszásának első számú oka nem a fejlesztés, hanem a hiányzó tartalom.
Ezért a felelősséget és az időigényt előre rögzíteni kell.
- Szolgáltatásszövegek (megbízó vagy szövegíró, 5-10 munkanap): aloldalonként 400-800 szó, kulcsszó- és szándékkutatás alapján.
- Képanyag (megbízó, 3-5 munkanap): saját fotó a csapatról és a munkáról. Stockfotó rontja a hitelességet.
- Referenciák (megbízó, 5 munkanap): ügyfélengedélyek, konkrét számok, idézetek.
- Logó és arculat (megbízó, 1-2 munkanap): vektoros fájlok, színkódok, betűtípus-licencek.
- Jogi dokumentumok (jogász, 5-10 munkanap): ÁSZF, adatvédelmi tájékoztató, adatkezelési nyilvántartás.
- Szakmai jóváhagyás (döntéshozó, 2-3 munkanap körönként): egy nevesített felelős, nem bizottság.
Technológia, SEO és Teljesítmény
Nincs objektíven legjobb technológia.
Van olyan, ami a te tartalommennyiségedhez, csapatodhoz és növekedési terveidhez illik.
WordPress, Egyedi Vagy Statikus?
A három fő irány között a különbség nem a megjelenésben van, hanem a karbantartásban, a sebességben és a bővíthetőségben.
- WordPress: a legelterjedtebb CMS, hatalmas plugin-ökoszisztémával. Előny a gyors indulás és a széles fejlesztői piac. Hátrány a rendszeres frissítési teher, a plugin-halmozódásból eredő lassulás, és hogy a biztonsági incidensek nagy része elavult kiegészítőkből ered.
- Egyedi fejlesztés: pontosan a folyamataidra szabott működés, tiszta adatmodell, könnyű integráció CRM-mel vagy ERP-vel. Drágább induló költség, viszont nincs benne felesleges kód, és a bővítés kiszámítható.
- Statikus weboldal (például Astro vagy hasonló generátor headless CMS-sel): kimagasló sebesség, minimális támadási felület, alacsony üzemeltetési költség. A tartalomkezelés külön rendszerben történik, dinamikus funkciókhoz külön szolgáltatás kell.
SEO Már a Tervezésnél
A technikai SEO nem utólagos optimalizálás, hanem tervezési döntéssorozat.
Az alábbiakat a wireframe fázisban kell eldönteni, nem az élesítés után.
- URL-struktúra: beszédes, rövid, stabil URL-ek. Az utólagos átnevezés átirányítási láncokat és rangsorvesztést okoz.
- Információs architektúra: minden fontos aloldal legyen legfeljebb három kattintásra a főoldaltól.
- Belső linkelés: a blogtartalom kontextusban linkeljen a szolgáltatásoldalakra, ne csak a menü kötögesse össze az oldalt.
- XML sitemap és robots.txt: automatikusan generált, mindig aktuális oldaltérkép, beküldve a Google Search Console-ba.
- Strukturált adat: Organization, LocalBusiness, Service, FAQPage és Breadcrumb sémák. Ezek adják az alapot ahhoz, hogy AI-alapú keresők is idézni tudják a tartalmadat.
- Cím- és metaadat-stratégia: minden aloldalhoz egyedi title és leírás, keresési szándék szerint, nem cégnév-ismétléssel.
Teljesítmény és Akadálymentesség
A PageSpeed Insights pontszám laborteszt: szimulált eszközön, szimulált hálózaton mér.
A Core Web Vitals mezős adata viszont a valódi látogatóid böngészőjéből származik, és ez az, amit a Google a rangsorolásnál figyelembe vesz.
Mindkettő számít.
A labormérés fejlesztés közben ad azonnali visszajelzést, a mezős adat pedig 28 napos csúszóablakban mutatja a tényleges élményt.
Célértékek: LCP 2,5 másodperc alatt, INP 200 milliszekundum alatt, CLS 0,1 alatt.
Az akadálymentesség hasonlóan gyakorlati kérdés, nem jogi formalitás.
A WCAG akadálymentesség minimum szintjéhez tartozó ellenőrzőlista:
- Az egész oldal bejárható billentyűzettel, Tab és Enter segítségével.
- Szövegkontraszt legalább 4,5:1, nagy betűnél 3:1.
- Látható fókuszjelzés minden interaktív elemen.
- Értelmes alt szöveg minden informatív képen, dekoratív képnél üres alt.
- Űrlapmezők címkével összekötve, hibaüzenet szövegesen is olvasható.
- Videóknál feliratozás, mozgó elemeknél megállítási lehetőség.
A GDPR kapcsán egy tévhitet érdemes tisztázni.
A cookie-banner önmagában nem megfelelés.
A cookie-hozzájárulás megszerzéséig minden nem szükséges mérőkódot, így a Google Analytics és a Meta Pixel kódját is, blokkolni kell, és a visszavonásnak ugyanolyan egyszerűnek kell lennie, mint az elfogadásnak.
A Projekt Útja a Leszállításig
Egy egyszerűbb, 8-12 aloldalas céges weboldal készítés reálisan 4-8 hét.
Nem két hét, és nem hat hónap.
A csúszás szinte mindig ugyanhárom okra vezethető vissza: hiányzó tartalom, késői jóváhagyás, tisztázatlan terjedelem.
Mennyi Idő Alatt Készül El
- Célok és mérőszámok rögzítése (3-5 nap): egy mondatban az üzleti cél, mellé a fő KPI, például havi 15 ajánlatkérés. Innen vezethető le minden későbbi döntés.
- Kutatás és tervezés (1-1,5 hét): kulcsszó- és versenytárselemzés, oldaltérkép, wireframe. Ebben a szakaszban az AI kutatási és vázlatozási segítségként hasznos, de minden állítást emberi ellenőrzés zár.
- UX és UI tervezés (1-2 hét): kattintható dizájnterv mobil és desktop nézetben. Itt kell jóváhagyni, mert fejlesztés után minden módosítás drágább.
- Tartalomkészítés (párhuzamosan, 2-3 hét): szövegek, képek, referenciák. Ez fut a leggyakrabban túl, ezért érdemes már az első héten indítani.
- Fejlesztés és integrációk (1,5-3 hét): felépítés, űrlapok, analitika, strukturált adatok, teljesítményhangolás.
- Tesztelés és élesítés (3-5 nap): eszközteszt, űrlapteszt, mérési ellenőrzés, majd éles indulás.
Mit Kérj Számon a Fejlesztőn
- Az ajánlat tartalma tételes legyen: mit tartalmaz aloldalszámban, funkcióban, tartalomkészítésben, és mit nem. A “komplett weboldal” megfogalmazás nem terjedelem.
- Mérföldkövek és fizetési ütem: szakaszonként átadott, ellenőrizhető eredmény. Heti kattintható előnézet, ahogy például a CompletApp is dolgozik fix terjedelem és fix ár mellett, kizárja a “majd a végén meglátod” helyzetet.
- Módosítási körök száma: jellemzően két kör dizájnra és egy kör fejlesztés utáni finomításra. Ezt írásban kell rögzíteni.
- Támogatás hossza és tartalma: hány hónap hibajavítás, milyen reakcióidő, mi számít hibának és mi új igénynek.
- Átadási feltételek: mi az a csomag, amit a projekt végén kézhez kapsz, és hogyan dokumentált.
A tulajdonjog kérdését a szerződés aláírása előtt kell lezárni.
A domaint a cég nevére kell regisztrálni, a tárhelyet a cég fiókjában kell tartani.
A forráskód-tulajdonjog, az admin- és analitikai fiókok, a licencelt sablonok és pluginok jogai, a biztonsági mentések és a technikai dokumentáció a projekt végén a megbízóhoz tartoznak.
Élesítés Előtt és Utána
- Élesítés előtti ellenőrzés: minden link működik, űrlapok több eszközről tesztelve, mérőkódok hozzájárulás után aktiválódnak, egyedi 404-oldal él, mobil nézet valódi telefonon nézve, robots.txt nem tiltja az indexelést.
- Első hét: oldaltérkép beküldése a Google Search Console-ba, indexelés ellenőrzése, találatok kézi átnézése a fő kulcsszavakra.
- 2-4. hét: mérési hibák javítása, konverziós események ellenőrzése, űrlapból beérkező megkeresések számának összevetése a valós leadszámmal.
- 2. hónap: keresési lekérdezések elemzése a Search Console-ban, tartalomhiányok azonosítása, új aloldalak vagy blogcikkek tervezése a valós keresésekre.
- 3. hónap: konverzióoptimalizálás adat alapján. CTA-szövegek, űrlaphossz, első képernyő tesztelése, Core Web Vitals mezős adatok újraértékelése.
Kezdd a Céllal, Ne a Dizájnnal
A döntés egyszerűbb, mint amilyennek tűnik.
Ha a cél tisztán bemutatkozás és megkeresések gyűjtése, egy jól strukturált, gyors céges oldal 8-12 aloldallal tökéletesen elég, és nem kell túltervezni.
Ha viszont ügyfélkezelés, foglalás vagy tranzakció is szerepel a tervben, akkor már most érdemes bővíthető alapot választani. A tartalom és a megjelenítés szétválasztása, tiszta adatmodell, dokumentált kód: ezek az induláskor apró döntések, később viszont ezek döntik el, hogy fejleszteni vagy újraépíteni kell.
Egy gyakorlati javaslat, mielőtt fejlesztőt keresnél.
Írd le egy mondatban az oldal üzleti célját és a legfontosabb mérőszámot. Például: “Havi 20 ajánlatkérés ipari csarnokfelújításra, organikus keresésből.”
Ez az egy mondat többet ér minden dizájnreferenciánál, és azonnal megmutatja, ki érti a feladatot és ki csak árat mond.
És egy zárógondolat, ami a legtöbb projektet megmenthetné.
A weboldal nem egyszeri projekt, hanem folyamatosan karbantartott üzleti eszköz.
Az élesítés nem a befejezés, hanem a kezdet.
Onnantól jönnek az adatok, és az adatok mindig okosabbak, mint a legjobb terv.
