lunavera.hu — sablon-WordPress helyett teljes egyedi rendszer
Mennyi ebből saját munka?
Ez a kérdés dönti el, hogy egy oldal eszköz-e vagy bérlemény. A számok a projekt forráskódjából jönnek, 2026. szeptember 12-i állapot:
| Mit | Mennyi |
|---|---|
| Saját forráskód (TypeScript/TSX) | 34 581 sor |
| Saját kiszolgáló-végpont | 11 |
| Nyilvános lap | 20 sablonból, 25 megjelenő cím |
| Beépített külső bővítmény, oldalépítő, sablon | 0 |
| Külső szolgáltatás, ami a látogató adatát látja | 0 |
| Mérő- és ellenőrző szkript a projekt mellett | 156 |
A 156 ellenőrző szkript nem a termék része, hanem a bizonyítéké: minden funkcióhoz tartozik egy futtatható mérés, ami megmondja, hogy még mindig azt csinálja-e, amit kell. A hírlevélküldés, a foglalási naptár, a bérletlevonás és a visszaigazoló levelek mind így lettek átadva — nem „megnéztem, jónak tűnik" alapon.
Mi volt a régi oldalon?
A megrendelő évek óta élt egy megvásárolt sablonon futó WordPress-oldallal. Amikor a teljes tartalmát lementettük és soronként átnéztük, a következő derült ki:
- két aloldal — a kristályágy és a kezelések — bitre a főoldal másolata volt,
- a három tanfolyami szint mindegyike ugyanazt a szöveget tartalmazta, egy negyedik szolgáltatásét,
- egyetlen aloldalon állt valódi, saját szöveg,
- az adatvédelmi tájékoztatóban
CÉGNÉV,CÍMésADÓSZÁMhelykitöltők maradtak.
Ez nem vélemény és nem értékesítési érv: a régi oldal teljes mentéséből jött ki, fájlszinten. A látogató ebből annyit érzékelt, hogy „valahogy nem áll össze" — a keresőnek viszont pontosan ez a képe volt az oldalról: egymást másoló lapok, saját mondanivaló nélkül.
Mi épült helyette?
25 saját lap, bővítmény nélkül
Minden oldal saját designnal és saját kóddal készült, szerveroldali rendereléssel: amit a látogató lát, azt a kereső és a nyelvi modellek is ugyanúgy megkapják, futtatás nélkül. Nincs oldalépítő, nincs bővítménylánc, ami magától frissül a tulajdonos alatt.
Időpontkérés saját végponttal
A foglalási és a letöltési űrlap mögött saját szerverkód fut, nem egy űrlapbővítmény. Előtte ember-ellenőrzés: token nélkül és hamis tokennel a beküldés 403-mal elutasításra kerül, mielőtt bármi adat keletkezne. A beérkezett kérések naplózása jelszó és süti nélkül történik.
A megbízó telefonja a vezérlőpult
A legtöbb sablonoldalnál a tulajdonos vagy beleszokik egy idegen adminfelületbe, vagy minden apró változtatásért a fejlesztőnek ír. Itt egyik sem történik: a rendszer kezelőfelülete a Telegramon belül nyílik meg, azon a telefonon, amit a megbízó amúgy is a kezében tart.
Ezen a felületen tud naptárat lezárni (mikor nem elérhető), jelentkezőnél visszaigazolni, hogy a foglaló megérkezett, és bérletet vezetni. Nem kell jelszót megjegyeznie, nem kell belépnie, és nincs külön alkalmazás, amit frissíteni kell.
Ami emögött áll, az a projekt legkényesebb része. A Telegram minden megnyitáskor átad egy aláírt adatcsomagot, amit a bot kulcsából számol — aki nem ismeri a kulcsot, nem tud érvényes aláírást hamisítani. A rendszer három kaput tart, és mindhárom kötelező: stimmel-e az aláírás, nem túl régi-e az adat, és szerepel-e a megnyitó fiók az engedélyezettek között. A harmadik kapu azért létfontosságú, mert az aláírás önmagában bárkinél érvényes: nélküle mindenki, aki a botot megtalálja, lezárhatná a megbízó naptárát.
Amit ez kizár: a „titkos webcím" mint védelem. Egy cím előbb-utóbb megjelenik egy böngésző előzményében, egy megosztott képernyőn vagy egy naplóban — a cím ismerete önmagában senkit nem jogosít fel semmire.
Értesítés két, egymástól független csatornán
Minden beérkező megkeresés egyszerre megy e-mailben és Telegram-üzenetben. Ez szándékos párhuzamosság: a levél percekig ülhet a postafiókban, és ha a levélküldő hibázik, az csak a naplóból derülne ki. A telefon azonnal jelez, és a megkeresés minden adata ott van az üzenetben — nem kell utána sehova kattintani.
A sorrend is meg van kötve: a látogató visszajelzése nem függ attól, hogy az értesítés kiment-e. Ha a Telegram lassú vagy elérhetetlen, a jelentkezés akkor is sikeres, mert az adat a lemezen már ott van. Egyik csatorna kiesése sem jelent elveszett foglalást.
Hírlevélrendszer, ami a jogszabályt is kiállja
Nem egy hírlevélszolgáltatás beépítése történt, hanem saját rendszer épült: feliratkozás, kétlépcsős megerősítés, leiratkozás, küldés és statisztika.
A kétlépcsős megerősítés nem kényelmi kérdés. Reklámlevelet Magyarországon előzetes, bizonyítható hozzájárulás nélkül nem lehet küldeni, és a bizonyítás terhe az adatkezelőn van. Egy űrlapba beírt cím ezt nem igazolja — bárki beírhatja bárki más címét. A megerősítő levélre adott kattintás viszont azt bizonyítja, hogy a cím tulajdonosa maga kérte. A rendszer ezért hozzájárulás-naplót vezet, és minden leiratkozó hivatkozás aláírt: nem lehet más címére leiratkozni, és nem lehet visszaélni a linkkel.
A statisztikánál egy olyan részlet dönti el a szám igazságát, amit a legtöbb rendszer figyelmen kívül hagy: a megnyitásokat nem emberek rontják el, hanem gépek. A Gmail a képeket a saját kiszolgálóin előtölti, az Apple Mail 2021 óta szintén, a céges levelezők biztonsági szkennerei pedig végigjárják a levélben lévő hivatkozásokat. Szűrés nélkül ezek mind lelkes olvasónak látszanak. A rendszer felismeri és kiszűri őket — tárolás nélkül, tehát úgy, hogy közben nem keletkezik új személyes adat.
Bérletek: ahol egyetlen versenyhelyzet pénzbe kerül
A bérlet-nyilvántartás írásai egyetlen soron mennek végig, sorosítva. Ennek a döntésnek konkrét tétje van: a műveletek olvasnak, ellenőriznek, majd írnak, és a lépések közötti pillanatban két egyidejű kérés mindkettője a művelet előtti állapotot látná. Egy bérletnél ez kétszeres levonást jelentene ugyanarra a jelentkezésre — vagyis egy fizető vendég elveszítene egy alkalmat.
Ugyanez az elv a foglaltsági naptárnál: az írás előbb ideiglenes fájlba megy, aztán átnevezéssel lép a helyére. Így a foglaló soha nem olvashat félig kiírt listát — vagy a régi állapotot látja, vagy az újat, harmadik lehetőség nincs.
Résztvevői visszajelzések, két adatvédelmi réteggel
A lezajlott alkalmakról érkező visszajelzések saját rendszerben futnak, moderálással: ami kimegy a nyilvános oldalra, arról a megbízó dönt. A tárolás kétrétegű, és ez tudatos adatvédelmi döntés — a beküldő azonosítására alkalmas adat nem kerül egy fájlba a nyilvánosan megjelenő szöveggel.
A Google Cégprofil értékelése is megjelenik az oldalon, de elavulás elleni védelemmel. Egy csillagsor a láblécben csak addig ér valamit, amíg igaz. A veszély nem az, hogy ma rossz számot írunk ki, hanem hogy a jó szám fél év múlva rossz lesz, és ezt senki nem veszi észre: a profilon gyűlnek az értékelések, az oldal meg ott ragad egy régi értéken.
Holdnaptár, ami számol — és inkább üres, mint hamis
A csoportos alkalmak szekciója valós csillagászati számításból dolgozik: a holdfázis kiszámolt érték, nem egy kézzel beírt ikon. A projekt legfontosabb döntése mégsem ez volt, hanem az, hogy a szekció üresen ment élesbe. Az építés közben minta-dátumok álltak benne, élő visszaszámlálóval. Ezek látszatra jól mutattak — de valaki elindulhatott volna egy nem létező alkalomra. Kitalált adat nem megy ki éles oldalra: a szekció üres állapotot kapott egy igaz mondattal és egy értesítéskérő gombbal, amíg a valódi dátumok meg nem érkeznek.
Bolygóállás: néhány száz sor számítás egy külső szolgáltatás helyett
Az oldalon megjelenik, melyik égitest melyik jegyben jár, és halad-e visszafelé. Ez nem egy API-ból jön, hanem saját számítás: klasszikus Kepler-pályaelemek, a Kepler-egyenlet iteratív megoldásával, néhány száz sorban, függőség nélkül.
Két oka van annak, hogy így készült. Az oldalnak akkor is működnie kell, ha egy külső szolgáltatás leáll vagy fizetőssé válik — ez a leggyakoribb módja annak, hogy egy évekkel korábban átadott oldal magától elromlik. A másik: így a látogató adata nem megy sehova.
Ugyanez az elv a hangfelvételek hullámrajzánál. Az a görbe a hangfájlból számolódik, építéskor — korábban egy kézzel bemásolt számsor volt, aminek az a baja, hogy fájlcserénél némán hazudik: egy másik felvétel görbéje fut egy másik hang alatt, és ez semmilyen hibaüzenetben nem jelenik meg.
A résztvevő-számláló szintén magától telik. A megbízó szavaival: vannak, akik hónapokig figyelnek, mielőtt jelentkeznek. Egy álló szám ilyenkor visszafelé sül el — ha valaki márciusban ugyanazt látja, mint januárban, abból azt olvassa ki, hogy nem történik semmi.
Kristályágy, amit billentyűzettel is végig lehet járni
A szolgáltatás legnehezebben elmagyarázható részéhez saját interaktív elem készült: hét kristály, mindegyik saját fénykúppal, kattintással és billentyűzettel egyaránt bejárható. Az akadálymentesség nem utólagos javítás volt rajta, hanem a komponens megírásának feltétele.
Egy süti, nulla mérőszkript
Az oldalon egyetlen süti működik: az, amelyik a látogató saját hozzájárulási döntését jegyzi meg, 12 hónapig. Nincs forgalommérő szolgáltatás, nincs hirdetési képpont, és nincs beágyazott külső videólejátszó sem — a videók és a hangfelvétel a saját szerverről mennek. Ez nem beállítás kérdése: a rendszerben nincs olyan kód, ami harmadik félhez adatot küldene.
A biztonsági fejlécek — tartalombiztonsági szabályzat, kereten belüli megjelenítés tiltása, HSTS — az alkalmazás kódjában vannak, nem csak a kiszolgáló beállításában. Így a domainváltás nem veszejtheti el őket.
Strukturált adat: egy ember, egy entitás
Az induló állapotban ugyanaz a személy két különböző azonosítóval szerepelt a strukturált adatban, két fél életrajzzal — gépi szemmel két különböző ember. Egy egyszemélyes szolgáltatásnál ez a lehető legrosszabb, mert ott a szakértelem a személyhez kötődik. A javítás után egyetlen forrásból épül a személy, a vállalkozás, a cím és a morzsamenü minden lapon; a cikkek Article, a szolgáltatáslisták ItemList, az utalvány Product és Offer jelölést kaptak.
Gépi olvasásra szánt változat — ugyanabból a forrásból
Az oldal látványra épül: görgetésre induló animációk, képbe ágyazott állítások. Embernek jó, gépnek nehéz. Ezért minden lapnak van gépi olvasásra szánt, tényszerű változata (.md tükör), plusz egy llms.txt és egy llms-full.txt — ugyanabból az adatból generálva, amiből a felület is épül. Nincs külön karbantartott másolat, tehát nem tud széttartani: ha egy ár változik, mindkét helyen változik.
Hogyan zajlott a költözés?
Egy élő oldal cseréjénél nem a design a kockázat, hanem a címek és a levelezés. A sorrend ezért kötött volt:
- Friss, teljes mentés a régi WordPressről — adatbázis és fájlok, épség-ellenőrzéssel — mielőtt bármi történik.
- A keresőzár feloldása és a DNS-váltás ugyanabban az órában. Ha a domain előbb jön át, mint ahogy az oldal indexelhetővé válik, a kereső a régi címeket kidobja az indexből — a felépült helyezés elveszik.
- 11 régi cím tartós átirányítása az új megfelelőjére. A lista a régi oldal adatbázisából származik, nem találgatásból: minden publikált lap kapott célt.
- A levelezés érintetlen maradt. Csak a webcím-rekordok cserélődtek; a postafiókok, a levélküldési hitelesítés (SPF, DKIM, DMARC) egyetlen karaktert sem változott, és a váltás után ellenőrizve is lett, hogy megy a levél.
- A bemutató-cím lezárása átirányítással, hogy ne maradjon két azonos tartalmú, egymással versenyző webhely.
- Bejelentés a keresőknek ugyanaznap: oldaltérkép beküldve, a többi keresőnek azonnali értesítés.
Az eredmény
| Mit | Mennyi | Forrás |
|---|---|---|
| Saját forráskód | 34 581 sor | a projekt forrása, 2026-09-12 |
| Saját kiszolgáló-végpont | 11 | a projekt forrása |
| Saját lap az oldaltérképben | 25 | lunavera.hu/sitemap.xml |
| Sablon, oldalépítő, bővítmény | 0 | a forráskód |
| Nyomkövető és hirdetési süti | 0 | sütitájékoztató + a böngésző saját felülete |
| Forgalommérő vagy hirdetési szkript | 0 | az oldal forrása |
| Külső szolgáltatás, ami látogatói adatot lát | 0 | a forráskód |
| Régi cím átirányítva | 11 | a régi WordPress adatbázisa |
| Ellenőrző szkript a funkciókhoz | 156 | a projektkönyvtár |
| Válaszidő (TTFB) | 0,05–0,09 s | napi mérés a saját szerveremről, a nyilvános címen át — a pontos, aznapi érték a főoldal mérés-dobozában áll |
A sebességszám laboratóriumi jellegű: egy adott gépről, adott hálózaton mértem. A te eszközödön mért érték ettől eltérhet — ezért az alábbi linkeken magad is megmérheted.
Mit mond minderről a megrendelő?
A fenti számok az én méréseim. Az alábbi szöveg nem: a megrendelő küldte, és a hozzájárulásával, névvel áll itt.
Ügyfélvélemény
A legprofibb cég, akivel valaha találkoztam!
Volt már pár kísérletem a weboldalam elkészítésére, de teljesen laikusként sajnos rengeteg extra kört kellett futnom, mire megtaláltam azt a csapatot, aki végül minden elképzelésemet felülmúlta.
A ROOTCR professzionalitását és kreativitását nehéz néhány mondatban megfogalmazni.
Segítőként szerettem volna kitűnni, de mire rájuk találtam, már teljesen elvesztem a különböző vélemények, tanácsok és elképzelések között. Nekem sem volt már igazán tiszta képem arról, hogyan lehetne mindazt megmutatni, amit képviselek.
Elég volt elmesélnem, mivel foglalkozom, és napokon belül egy szinte kész weboldallal leptek meg.
A technikai tudás és a gyorsaság mellett számomra talán az volt a legszimpatikusabb, ahogyan beleálltak a közös munkába. Azt éreztem, hogy valóban időt szántak arra, hogy megértsék, mivel foglalkozom, mit képviselek, és mi az, ami számomra fontos.
Fantasztikusan tudtunk együtt dolgozni, és minden kérésem hallgató fülekre talált.
A weboldalam két hét alatt elkészült, és azt kell mondanom: keretet adott annak, amit én magamtól nem tudtam volna keretbe foglalni.
Ha valóban fontos számodra, hogy a weboldalad ne csak szép és professzionális legyen, hanem téged is tükrözzön, egy percig se keress tovább.
Névvel, a szerző írásos hozzájárulásával közölve.
Ellenőrizd magad
- lunavera.hu — az élő oldal.
- lunavera.hu/sitemap.xml — az oldalak száma és a frissítési dátumok.
- lunavera.hu/llms.txt — a gépi olvasásra szánt összefoglaló.
- PageSpeed Insights — sebességmérés a Google saját műszerével.
- Rich Results Test — a strukturált adat bármelyik lapon.
- Nyisd meg a
lunavera.hu/reiki-oktatascímet: a régi oldal egyik webcíme. Nem hibaoldalra visz, hanem az új megfelelőjére — ez a 11 átirányítás egyike.
Mi tanulható belőle?
Hogy egy oldalcserénél az elveszíthető érték nem a design, hanem a címek, a levelezés és a keresőben felépült pozíció. Ezt hárman szokták elrontani: aki a régi címeket nem irányítja át, aki a levelezést a webcímmel együtt költözteti, és aki előbb húzza át a domaint, mint hogy az új oldal indexelhető lenne. Mindhárom hiba visszafordítható, de hetekbe és forgalomba kerül.
A másik tanulság a holdnaptáré: egy üres szekció igaz mondattal többet ér, mint egy teli, kitalált adattal. A látogató az elsőt megbocsátja. A másodikat egyszer tapasztalja meg — amikor kiáll egy nem létező alkalomra.
A harmadik pedig az, hogy hol van a határ weboldal és rendszer között. Egy sablonoldal addig tart, amíg a látogató el nem küldi az űrlapot; onnantól a tulajdonosnak kell dolgoznia. Itt a munka java a küldés után kezdődik: értesítés két csatornán, foglaló-nyilvántartás, bérletlevonás, hírlevél-hozzájárulás igazolása, naptárzárás a telefonról. Ezek egyike sem látszik a lapon — és pont ezek veszik le a napi terhet a megbízóról.
Ezt bővítménnyel nem lehet összerakni, mert a folyamat, amire készült, egyetlen vállalkozásé. Egy megvásárolt modul mindig általános: azt tudja, amit a legtöbb felhasználónak kell, és a maradékot a tulajdonos kézzel pótolja. A saját kód azt tudja, ami ennek a vállalkozásnak kell — és semmi mást, amit később karban kellene tartani.
Ha ismerős a helyzet — meglévő sablonoldal, ami már inkább akadály —: egyedi weboldal készítés, vagy nézd meg előbb, hogy javítani vagy újraírni éri-e meg.