A statikus weboldal olyan oldal, amelynek minden oldala előre elkészült HTML fájlként létezik, és a szerver csak kiszolgálja őket. Nincs adatbázis-lekérdezés, nincs szerveroldali kódfuttatás, nincs plugin. Ettől gyorsabb, olcsóbb üzemeltetni, és nagyságrendekkel kisebb a támadási felülete, mint egy klasszikus WordPressnek.
Ez a legtöbb céges bemutatkozó oldalnak, szolgáltatás-oldalnak és blognak pontosan elég. Nem elméleti kérdés: a milcomp.hu maga is így épül, és a váltás előtti és utáni számokat lentebb kiírom.
Mi a statikus weboldal, egy mondatban
A félreértés általában innen indul: sokan azt hiszik, hogy a "statikus" azt jelenti, hogy a tartalom nem változhat, vagy hogy kézzel kell HTML-t írni. Egyik sem igaz. A tartalom egy szerkesztőfelületen él, mentés után egy build lefut, és újragenerálja az érintett oldalakat. A szerkesztő ugyanazt látja, mint bármelyik CMS-ben.
A különbség az, hogy a látogató kiszolgálásakor már semmi nem történik. A munka a build idejére került, nem minden egyes látogatás idejére. Ennyi a trükk.
- Fogalom Statikus weboldal
Olyan weboldal, amelynek oldalai előre legenerált HTML fájlok, így a kiszolgálásukhoz nem kell adatbázis vagy szerveroldali programfutás.
Miért gyorsabb, konkrét számokkal
Nem adjektívumokkal érvelek, hanem azzal, amit a saját oldalunkon mértem. A milcomp.hu régi verziója Next.js alapon futott, az új Astro statikus kimenettel. Ugyanaz a 26 URL, ugyanaz a tartalom:
| Régi (Next.js) | Új (Astro, statikus) | |
|---|---|---|
| Géppel olvasható szöveg a 26 oldalon | 21 737 karakter | 45 885 karakter |
| Oldal h1 főcím nélkül | 7 | 0 |
| alt nélküli kép | 52 | 0 |
| hreflanggel ellátott oldal | 5 | 22 |
| Kliensoldali JavaScript | teljes React bundle, 25 script tag | 2 kis komponens |
| Build idő | percek | 2,4 másodperc 26 oldalra |
A géppel olvasható szöveg megduplázódása a legérdekesebb szám. Nem írtunk kétszer annyit: a régi oldalon a szöveg egy része csak azután került be a HTML-be, hogy a böngésző lefuttatta a JavaScriptet. Ami a keresőnek és az AI-nak nem mindig van meg. Kilenc oldal szövegtörzse egyszerűen visszatért attól, hogy a szerver rendereli.
A sebesség ennek a mellékterméke. A Lighthouse méréseink a kulcsoldalakon 100/100/100/100 értéket adnak, a legtöbb futásnál 0 ezredmásodperces blokkolási idővel. Ez nem varázslat, hanem az következik belőle, hogy nincs mit futtatni.
Miért biztonságosabb
A klasszikus céges WordPress támadási felülete három rétegből áll: a WordPress mag, a bővítmények, és a PHP-futtatás maga. A statikus oldalon ebből egyik sincs kiszolgálás közben.
- Nincs adatbázis a nyilvános oldal mögött, tehát nincs SQL injection.
- Nincs PHP-futtatás a webgyökérben, tehát a feltöltött webshell nem tud lefutni.
- Nincs bővítmény, tehát nincs mit frissíteni, és nincs elavult bővítmény.
- Nincs bejelentkezési felület a nyilvános oldalon, tehát nincs mit brute force-olni.
Ez nem elméleti előny. A saját szerverparkunkon 2026 májusában egy WordPress-alapú kiszolgálóról kellett feltöltött PHP webshelleket eltávolítanom. Statikus oldalon ez a támadási típus fogalmilag nem működik, mert a feltöltött fájl nem futtatható kód, hanem csak egy fájl.
A szerkesztőfelület természetesen továbbra is védendő, de az nem a nyilvános interneten él, hanem külön hostnéven, hozzáférés-védelem mögött.
"És akkor hogy szerkesztem?"
Ez a leggyakoribb ellenvetés, és jogos. A válasz: ugyanúgy, mint eddig.
A tartalom egy CMS-ben él, saját szerkesztőfelülettel, jogosultságokkal és médiatárral, és amikor mentesz, elindul egy build, amely újragenerálja az érintett oldalakat, majd az eredmény pár másodperc múlva élesben van. A mi oldalunkon ez a lépés 2,4 másodperc a teljes site-ra.
Amit el kell fogadni: a mentés és a megjelenés között eltelik pár másodperc, nem azonnali. A cserébe kapott előny, hogy a látogató soha nem vár adatbázisra.
Amit tévhitként érdemes eloszlatni: kapcsolati űrlap, kereső, hírlevél-feliratkozás mind működik statikus oldalon. Ezeket kis, elkülönített szolgáltatások kezelik, nem az oldal maga. A milcomp.hu kapcsolati űrlapja pontosan így működik.
Mikor NE válaszd
Itt jön az a rész, amit a legtöbb ügynökség kihagy. A statikus oldal nem univerzális válasz.
- Ha felhasználónként eltérő tartalmat kell mutatni. Belépés utáni fiókoldal, személyre szabott ajánlatok, jogosultságfüggő tartalom. Ezekhez alkalmazás kell, nem statikus oldal.
- Ha valós idejű adatot jelenítesz meg. Készlet, árfolyam, foglaltság, élő állapot. Részben megoldható, de ha ez a lényeg, akkor rossz eszközt választanál.
- Ha nagyon sok oldalad van és percenként változnak. A build ideje az oldalszámmal nő. Tízezer termékoldalnál, napi többszáz változással más architektúra kell.
- Ha a csapatod egy konkrét WordPress-ökoszisztémára épült. Ha minden folyamatotok egy bővítményre támaszkodik, a váltás költsége nem a fejlesztés, hanem a folyamatok átírása.
Egy tipikus céges bemutatkozó oldalra, szolgáltatás-oldalakra, referenciákra és blogra viszont a statikus a helyes választás, és ritkán van jó indok mást választani.
Gyakori kérdések
Mennyibe kerül egy statikus weboldal?
Nagyjából ugyanannyiba, mint egy hasonló minőségű dinamikus oldal, mert a munka nagy része a tervezés és a tartalom, nem a technológia. Az üzemeltetés viszont olcsóbb, mert nincs adatbázis és nincs futtatókörnyezet, amit karban kell tartani és frissíteni.
Jó a statikus weboldal a SEO-nak?
Igen, és nem csak a sebesség miatt. Ami számít, hogy a teljes szöveg benne van a kiszolgált HTML-ben, JavaScript futtatása nélkül. Ez a keresőknek és az AI-alapú keresőknek egyaránt fontos, mert a Google saját dokumentációja szerint is külön menetben, késleltetve fut a JavaScript-renderelés, és nem minden bejáró futtatja le.
Lehet blogot vezetni statikus oldalon?
Igen. A blogbejegyzések ugyanúgy a CMS-ben készülnek, kategóriákkal, kiemelt képpel, kereséssel. A különbség csak annyi, hogy megjelenéskor legenerálódnak, nem minden látogatáskor épülnek fel újra.
Mi történik, ha leáll a CMS?
Semmi. A nyilvános oldal független tőle, mert már legenerált fájlokat szolgál ki. Nem tudsz új tartalmat közzétenni, amíg a CMS nem jön vissza, de a látogatók ebből semmit nem vesznek észre. Klasszikus WordPressnél ugyanez az esemény fehér képernyőt jelentene.
Át lehet állni meglévő WordPressről?
Igen, és a tartalom migrálható. A kérdés inkább az, hogy melyik bővítményed funkciójára van tényleg szükség. Tapasztalatom szerint az esetek nagy részében a lista rövidebb, mint amire számítanak, de érdemes ezt végigvenni a váltás eldöntése előtt.
A milcomp.hu maga a demó: ezt az oldalt olvasod éppen. Ha téged is érdekel egy gyors, karbantartásmentes céges oldal, nézd meg a szolgáltatásainkat, vagy írj nekünk.
