# RootCR — a rootcr.hu teljes tartalma Generálva: 2026-08-14 · Forrás: https://rootcr.hu/ --- # AI-kereshetőség — alapfelszereltség, nem felár URL: https://rootcr.hu/ai-keresooptimalizalas/ Frissítve: 2026-08-14 # AI-kereshetőség: nem felár, hanem alapfelszereltség > **Röviden:** Minden általam épített weboldal és webshop úgy készül, hogy a Google és a nyelvi modellek (ChatGPT, Perplexity, Gemini, Google AI Overviews) gépi formában is meg tudják érteni: teljes strukturált adat, gépi olvasásra szánt tartalomtükör minden oldalhoz, `llms.txt`, idézhető bekezdés-szerkezet és beengedő robots.txt. Ez nem utólag megvásárolható csomag, hanem az építés része — és nem kerül külön pénzbe. Ha önálló, meglévő oldalra szóló GEO/AEO munkára van szükséged, azt a testvérmárkánk, az [aiseo42](https://aiseo42.hu/) viszi. ## Miért nem külön tétel? Mert utólag ráaggatva a fele nem működik. A strukturált adat akkor megbízható, ha **ugyanabból a forrásból generálódik, mint a látható tartalom** — különben a termék ára megváltozik az oldalon, a bejelentett ár meg nem, és a Google épp azt bünteti. Ugyanez igaz a gépi tükrökre és a frissítési dátumokra: ha valaki kézzel tartja karban, előbb-utóbb hazudni fog. Egy sablonrendszerben ez bővítmény kérdése, és a minőség a bővítmény gyártóján múlik. Saját kódnál a kereshetőség egyszerűen a rendszer része. Ezért nincs nálam „SEO-csomag" felár: az alap tartalmazza. ## Mi az, ami minden oldalba beépül? **Teljes strukturált adat.** Oldalanként `WebPage`, morzsamenü, a szolgáltatásoldalakon `Service` árral, a cikkeken `Article` szerzővel és dátummal, a gyakori kérdésekből `FAQPage`. Nem sablonból: a séma az oldal tényleges tartalmából épül, tehát nem tud elcsúszni tőle. **Gépi olvasásra szánt tükör minden oldalhoz.** Ugyanaz a tartalom, jelölés nélküli, tiszta szövegként, ugyanazon az útvonalon `.md` kiterjesztéssel, és a HTML fejlécében meghirdetve. Egy nyelvi modell így félreértés nélkül, egy kéréssel megkapja a lényeget. **`llms.txt` és `llms-full.txt`.** Az első egy tömör tény- és oldallista dátumokkal, a második a **teljes tartalom egyetlen fájlban**. Ez a néhány kilobájt a legolcsóbb módja annak, hogy egy modell az egész oldalt tisztán feldolgozza. **Idézhető szerkezet.** Minden oldal élén 40–70 szavas, önmagában megálló összefoglaló; a címsorok maguk a keresett kérdések; a számok mellett ott a forrás és a dátum. A modellek bekezdés-szinten emelnek át tartalmat — ez a forma az, amit át tudnak emelni. **Beengedő robots.txt.** GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot, ClaudeBot, Google-Extended, Applebot, CCBot, Amazonbot és társaik — név szerint engedve. Ami nincs beengedve, az nem tud idézni. **Szerveroldali kimenet.** A tartalom valódi szöveg a HTML-ben, nem JavaScript után jelenik meg. Ami csak futtatás után áll össze, azt a modellek nagy része nem látja. **Sebesség és tiszta fejlécek.** Hash-elt, korlátlanul cache-elhető eszközök, saját szerverről kiszolgált betűtípusok, nulla külső követő a kritikus úton. ## A bizonyíték: ez az oldal Nem kell elhinned. Nyisd meg: - [rootcr.hu/llms.txt](https://rootcr.hu/llms.txt) — a tény- és oldallista, amit a modellek olvasnak. - [rootcr.hu/llms-full.txt](https://rootcr.hu/llms-full.txt) — a teljes oldal tartalma egy fájlban. - [rootcr.hu/ai-keresooptimalizalas.md](https://rootcr.hu/ai-keresooptimalizalas.md) — ennek a lapnak a gépi tükre. - [Rich Results Test](https://search.google.com/test/rich-results) — illeszd be bármelyik oldalcímemet, és nézd meg a strukturált adatot hibalistával. Ugyanez a felszereltség kerül minden ügyfél-projektbe. A [bucipek.hu esettanulmányban](/referenciak/bucipek/) látod, mit jelent ez számokban: 192 indexelt URL, nulla strukturált adat hiba. ## Hogyan mérem, hogy célba ér? Szlogen helyett műszer. Amit hetente kigyűjtök a kiszolgáló naplójából: | Mit | Miből derül ki | |---|---| | Elérik-e a modellek a tartalmat | GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, bingbot találatok | | Jön-e látogató AI-felületről | hivatkozó forrás: chatgpt.com, perplexity.ai, gemini.google.com | | Idéznek-e ténylegesen | havonta ugyanaz az öt kérdés a ChatGPT-nek, Perplexitynek, Gemininek — rögzítve | | Sebesség | napi automatikus mérés, ugyanazzal a paranccsal | A harmadik sor a lényeg, és a legkevésbé automatizálható: a kérdéseket fel kell tenni, és rögzíteni kell, ki jelenik meg forrásként. ## Mikor kevés ez, és mikor kell külön munka? Amit itt leírtam, az **technikai alap**: attól, hogy a modell el tudja olvasni az oldaladat, még nem fog idézni. Az idézéshez tartalom kell — olyan oldalak, amelyek egy-egy konkrét kérdést válaszolnak meg számokkal és döntési szabállyal. Ez írás, nem kód. Ha az oldalad most készül nálam, a technikai alap adott, és a tartalmi szerkezetet együtt rakjuk össze. **Ha viszont már van weboldalad, és kifejezetten arra kell munka, hogy a nyelvi modellek idézzenek**, arra önálló szolgáltatás való — azt a testvérmárkánk viszi:
aiseo42 — ugyanaz a műhely, önálló GEO/AEO szolgáltatás Meglévő oldalakra szóló generatív keresőoptimalizálás: aiseo42.hu (magyarul) · aiseo42.com (angolul). Ugyanaz a fejlesztő áll mögötte, aki a rootcr.hu-t építi.
## Gyakori kérdések ### Ez ugyanaz, mint a hagyományos keresőoptimalizálás? Nagyrészt igen, de a hangsúly máshol van: a kereső oldalakat rangsorol, a modell bekezdéseket idéz. A részletes különbséget itt bontom ki: [hogyan kerül be egy magyar kkv a ChatGPT és a Google AI válaszaiba](/tudastar/hogyan-kerul-be-egy-kkv-a-chatgpt-valaszaiba/). ### Garantálod, hogy megjelenek a ChatGPT válaszaiban? Nem, és aki garantálja, az vagy nem érti, vagy nem mondja el, mit ad el. A modell dönt, és a döntés hónapról hónapra változik. Amit garantálni lehet: a tartalom elérhető, olvasható, tényszerű, dátumozott és gépi formában is értelmezhető — ezek nélkül biztosan nem jelensz meg. ### Mennyivel drágítja ez a projektet? Semmivel. Az [árakban](/arak/) szereplő összeg ezt tartalmazza; az árat az aloldalak száma, az integrációk és az egyedi logika mozdítja, nem a kereshetőség. ### Meglévő, más által készített oldalra is megcsinálod? Igen, de előbb megnézem a rendszert, és megmondom, mennyi belőle a foltozás és mennyi az újraépítés: [félbehagyott weboldal átvétele](/tudastar/felbehagyott-weboldal-atvetele/). Ha az oldal alapvetően rendben van, és csak a láthatóságon kell dolgozni, arra az [aiseo42](https://aiseo42.hu/) a jobb út. ### Mi az a strukturált adat pontosan? Egy gépi olvasásra szánt réteg, ami nem szövegként, hanem adatként mondja el, mit ábrázol az oldal. Külön írásban kibontva: [mi az a strukturált adat](/tudastar/mi-az-a-strukturalt-adat/). --- # Weboldal és webshop készítés árak URL: https://rootcr.hu/arak/ Frissítve: 2026-08-14 # Mennyibe kerül egy egyedi weboldal vagy webshop? > **Röviden:** A RootCR-nél az egyedi weboldal 100 000 Ft-tól, az egyedi webshop 400 000 Ft-tól indul, az automatizálás 20 000 Ft/órától (minden ár nettó). A pontos ár a terjedelemtől függ, és az ajánlatban fix összegként szerepel — nem óradíjas becslésként, aminek a végét senki nem látja. Az alábbiakban az is szerepel, mi mozdítja az árat fölfelé, és mi az, amiért nem kell fizetned. ## A kiindulási árak | Szolgáltatás | Tartalom | Ár | |---|---|---| | [Egyedi weboldal](/egyedi-weboldal-keszites/) | Egyedi design, teljes strukturált adat, védett űrlap, mérési jegyzőkönyv | 100 000 Ft-tól | | [Webshop](/webshop-keszites/) | Egyedi termék-adatmodell, saját rendelési folyamat, fizetés + számlázás, admin | 400 000 Ft-tól | | [Automatizálás](/folyamat-automatizalas/) | Rendszerek összekötése, ütemezett feldolgozás, riasztás | 20 000 Ft/órától | A „-tól” nem marketingfogás, hanem a legkisebb értelmes projekt ára: az a terjedelem, ami alatt már nem éri meg egyedi fejlesztést venni. A tényleges ajánlat ennél jellemzően nagyobb, mert a legtöbb feladat több, mint a minimum — és ezt jobb az elején kimondani, mint az ajánlatban meglepetésként. ## Mitől lesz drágább — és mitől nem? **Fölfelé mozdítja az árat:** az aloldalak és sablonok száma; az integrációk (fizetés, számlázó, raktár, futár, CRM); az admin felület mélysége; az egyedi logika (kalkulátorok, foglalás, vevőnkénti árazás); a migráció régi rendszerből. **Nem mozdítja fölfelé:** a visszajelzéseid — két kör a designra benne van; a technikai keresőoptimalizálás és a strukturált adat, mert az alapfelszereltség; a mérési jegyzőkönyv; az átadás és a dokumentáció. ## Mi az, amit az ár mindig tartalmaz? - Fix ár és fix határidő, írásban. - Kéthetenkénti működő bemutató — nem képernyőkép, hanem megnyitható oldal. - Többrétegű űrlapvédelem. - Teljes strukturált adat. - Mérési jegyzőkönyv az átadáskor. - A teljes forráskód és minden hozzáférés — licencdíj, kötelező havidíj és sikerdíj nélkül. - Hat hónap díjmentes hibajavítás. ## Miért fix ár, és nem óradíj? Mert így a becslés kockázata az enyém, nem a tiéd. Ha alábecsültem a munkát, az az én bajom — te azt fizeted, ami az ajánlatban áll. Ez a különbség egy fix áras ajánlat és egy „nagyjából ennyi lesz” becslés között: az utóbbinál a kockázatot a megrendelő viseli, gyakran anélkül, hogy tudná. Ennek ára van: az ajánlat előtt pontosan tisztázni kell, mi tartozik bele. Ezért kérdezek sokat az első beszélgetésen, és ezért van az ajánlatban tételes lista arról is, mi *nincs* benne. ## Mikor NE engem válassz? Őszintébb ezt itt leírni, mint az első levélben kiderülnie. Ne engem válassz, ha: - 80–150 ezer forintos, sablonból készülő névjegyoldalt keresel — arra a sablon való, és jó is arra; - ha holnapra kell; - ha a legolcsóbb ajánlatot keresed — abban a versenyben nem indulok. Akkor válassz engem, ha az oldal vagy a webshop pénzt hoz vagy munkaórát spórol, és ezt mérni is akarod. ## Gyakori kérdések az árakról ### Van rejtett költség? Az oldal futtatásához tárhely kell: statikus oldalnál havi néhány ezer forint, webshopnál jellemzően tíz-húszezer forint — ez a szolgáltató számlája, a te nevedre. Üzemeltetést vállalok, de nem kötelező: az átadott rendszer bárhol futtatható. ### Miért drágább, mint egy sablonoldal? Mert nem ugyanaz készül. A sablonoldalnál a designt és a működést valaki más találta ki, te a beállításokat kapod meg. A sablon rejtett üzemköltségét — bővítménydíjak, javítgatás, elmaradt konverzió — a [WordPress kontra egyedi weboldal](/tudastar/wordpress-vagy-egyedi-weboldal/) írásban számolom ki tételesen. ### Mit kapok az ár mellé bizonyítékként? Mérési jegyzőkönyvet: betöltési idők, Core Web Vitals értékek, indexeltség, strukturált adat hibalista — mindegyik mellett a mérés módja és dátuma, hogy fél év múlva magad is megismételhesd. Élő példák: [referenciák](/referenciak/). ### Az ajánlat mennyi ideig érvényes? Az ajánlatban szerepel a lejárat dátuma. Ha a terjedelem közben változik, új ajánlat készül — a régi árat nem húzom rá csendben egy nagyobb feladatra. --- # Egyedi weboldal készítés, sablon nélkül URL: https://rootcr.hu/egyedi-weboldal-keszites/ Frissítve: 2026-08-14 # Egyedi weboldal készítés, sablon nélkül > **Röviden:** Az egyedi weboldal-fejlesztés azt jelenti, hogy az oldal designja és kódja a te cégedre készül, nem egy megvásárolt sablon beállításaiból áll össze. Akkor éri meg, ha az oldalnak dolga van: érdeklődőt hoz, rendelést vesz fel, folyamatot szolgál ki. A RootCR-nél az egyedi weboldal 100 000 Ft-tól indul, fix áras ajánlattal, jellemzően 3–5 hét alatt készül el, és a forráskód a tiéd marad. ## Mit jelent nálam az „egyedi”? Nem azt, hogy egy sablont átszínezek. Azt, hogy az oldal minden sora — a design, a HTML, a stíluslap, az űrlap mögötti szerverkód — erre a projektre készül. Ennek három következménye van, és mindhárom mérhető: **Sebesség.** Az oldal csak azt tölti be, ami a te tartalmadhoz kell. Nincs oldalépítő-keretrendszer, nincs harminc bővítmény stíluslapja, nincs külső betűtípus-szerver. Az átadáskor mérési jegyzőkönyvet kapsz: betöltési idők valós eszközökön, Core Web Vitals értékek, és a mérés módja, hogy fél év múlva magad is megismételhesd. **Biztonság.** Minden űrlap mögött többrétegű védelem fut: eredet-ellenőrzés, csapda-mező, méretkorlát, ember-ellenőrzés, IP-alapú korlátozás. Ezt nem egy bővítmény ígéri, hanem szerveroldali kód végzi, amit átadáskor dokumentálva megkapsz. Hogy ez a gyakorlatban hogyan néz ki, azt megnézheted a [pekarunagyker.hu ajánlatkérőjéről szóló esettanulmányban](/referenciak/pekarunagyker/). **Kereshetőség.** Az oldal teljes strukturált adattal készül: a Google és a nyelvi modellek (ChatGPT, Perplexity, Google AI) gépi formában is megkapják, hogy mit csinálsz, mennyiért és hol. Ez nem utólagos SEO-csomag, hanem az építés része — a módszert a [strukturált adatról szóló írásban](/tudastar/mi-az-a-strukturalt-adat/) bontom ki. ## Mikor NEM éri meg egyedi oldalt rendelni? Ha az oldalad digitális névjegy — cím, telefonszám, három bekezdés —, akkor egy tisztességesen beállított sablonoldal elég, és ezt az első beszélgetésen meg is mondom. Egyedi fejlesztést akkor érdemes venni, ha az oldal pénzt hoz vagy munkaórát spórol: érdeklődőket gyűjt, ajánlatkérést vesz fel, foglalást kezel, vagy egy belső folyamatot vált ki. Ilyenkor a sablon korlátai — a lassúság, a törékeny bővítménylánc, a testre nem szabható űrlapok — havonta kerülnek pénzbe, csak nem látszik számlán. A döntést végigvezetem itt: [mikor éri meg egyedi weboldal a WordPress helyett](/tudastar/wordpress-vagy-egyedi-weboldal/). ## Mi van az árban? Az egyedi weboldal 100 000 Ft-tól indul (nettó); a pontos ár a terjedelemtől függ, és az ajánlatban fix összeg, fix határidővel. Az árban benne van: - egyedi design — vázlattól a kész oldalig, két körös visszajelzéssel, - a teljes fejlesztés: HTML, CSS, JavaScript, szerveroldali kód, - védett kapcsolatfelvételi vagy ajánlatkérő űrlap, - teljes strukturált adat és technikai keresőoptimalizálás, - mérési jegyzőkönyv az átadáskor, - a teljes forráskód és minden hozzáférés átadása. Ami nincs benne alapból, és külön tételként kérhető: szövegírás, fotózás, logó, folyamatos üzemeltetés. A részletes árképzésről a [weboldal készítés árak](/arak/) oldalon írok, tipikus projektméretekkel. ## Hogyan zajlik? Négy lépés: beszélgetés (díjmentes, ekkor derül ki, tudok-e érdemben segíteni), írásos ajánlat fix árral és határidővel, építés kéthetenkénti működő bemutatóval, átadás mérési jegyzőkönyvvel és teljes hozzáférés-átadással. A leggyakoribb csúszási ok nem a fejlesztés, hanem a hiányzó tartalom — ezért a szükséges anyagok listáját az első héten megkapod. ## Mihez kapcsolódik ez a szolgáltatás? Ha a weboldal mellett rendelést is fel kell venni, az már [egyedi webshop](/webshop-keszites/). Ha az oldal mögött ismétlődő kézi munka van — adatok másolása rendszerek között —, akkor [folyamat-automatizálás](/folyamat-automatizalas/) a válasz. A valóságban a projektek fele mindkettőt érinti, ezért az ajánlat is egyben kezeli. ## Gyakori kérdések ### Mennyi idő alatt készül el? Jellemzően 3–5 hét, az ajánlatban fix dátummal. A határidő nem becslés: ha csúszik, annak oka van, és arról előre szólok. ### Kié lesz a kód? A tiéd. Teljes forráskód, minden hozzáférés, licencdíj és kötelező havidíj nélkül. Bármelyik fejlesztő át tudja venni. ### Tudsz szöveget is írni az oldalra? A szerkezetet és a címsorokat én adom, a szakmai tartalom tőled jön; kérésre szövegírót vonok be, külön tételként. ### Mi lesz a régi oldalammal? Az átállást én intézem: átirányítások a régi címekről, hogy a meglévő Google-helyezések ne vesszenek el. A meglévő oldal átvételéről külön is írtam: [javítani vagy újraírni](/tudastar/felbehagyott-weboldal-atvetele/). ### Mobilon is ugyanilyen gyors lesz? Az a cél, és ezt méréssel bizonyítom, nem ígérettel. A mérési jegyzőkönyv mobil és asztali értékeket is tartalmaz, mert a kettő nem ugyanaz. --- # Folyamat-automatizálás kkv-knak URL: https://rootcr.hu/folyamat-automatizalas/ Frissítve: 2026-08-14 # Folyamat-automatizálás: ahol most valaki minden nap ugyanazt másolja > **Röviden:** A folyamat-automatizálás azt jelenti, hogy a cégben naponta ismétlődő kézi munkát — adatok másolását rendszerek között, riportok összeállítását, számlák és rendelések egyeztetését — kód végzi el ember helyett. A RootCR rendszereket köt össze (webshop, számlázó, raktár, táblázat, e-mail) és ütemezett feldolgozásokat épít, 20 000 Ft/órás díjtól vagy fix áras ajánlattal. A megtérülés számolható: ha egy feladat napi fél órát visz el, az évi több mint 120 munkaóra. ## Honnan ismered fel, hogy automatizálni kellene? Három tünet, a gyakorlatból: 1. **A „másolós” kolléga.** Valaki minden reggel kinyit két rendszert, és az egyikből a másikba viszi az adatot. Rendelések a webshopból a számlázóba. Készlet a táblázatból az adminba. E-mailből sorok egy Excelbe. Ez nem munkakör, ez egy hiányzó szkript. 2. **A hó végi több napos riport.** Ami több forrásból, kézzel áll össze, az nemcsak lassú — hibázik is. Az automatizált riport magától készül el, mindig ugyanúgy. 3. **A „két hét múlva derült ki” hiba.** Elakadt egy rendelés, nem ment ki egy számla, betelt egy tárhely — és senki nem szólt. Az automatizálás fele nem a munka elvégzése, hanem a riasztás: ha valami elakad, arról azonnal e-mailt kapsz, nem az ügyfél telefonjából értesülsz. ## Mit építek pontosan? - **Rendszer-összekötések.** Webshop ↔ számlázó, webshop ↔ raktár, űrlap ↔ CRM ↔ e-mail, bank ↔ könyvelési export. Ha a rendszerednek van felülete vagy API-ja, összeköthető; ha nincs API, akkor is van megoldás: ütemezett export-import, felület-vezérlés. - **Ütemezett feldolgozások.** Éjszakai árfrissítés, készletszinkron, heti riport, automatikus mentés. Egyszer megírva, felügyelet mellett fut — így néz ki ez élesben a [teljes katalógust kezelő eszköznél](/referenciak/honeyzsu/), ami napi órák kézi munkáját váltotta ki. - **Nyelvi modellre épülő feldolgozás — ott, ahol tényleg megéri.** Bejövő e-mailek osztályozása, szabad szöveges megrendelések strukturálása, dokumentumokból adatkinyerés. Nem varázslat: ellenőrzési lépéssel, naplózással, emberi jóváhagyási ponttal ott, ahol tévedni drága. - **Riasztás és napló.** Minden automatizmus naplóz, és hibánál szól. Ez a különbség a „megírtam egy szkriptet” és az „üzemben tartható rendszer” között. ## Mennyibe kerül, és hogyan számold a megtérülést? Kisebb feladatnál óradíjas elszámolás: 20 000 Ft/óra (nettó), előre egyeztetett kerettel. Nagyobb, körülhatárolt feladatnál fix áras ajánlat. A megtérülés-számítás egyszerű: (naponta megspórolt perc × munkanapok száma × a kolléga órabére) mínusz a fejlesztés ára. Egy napi 30 perces feladat évi körülbelül 125 órányi bér — a legtöbb automatizálás hónapokban mérhető idő alatt fordul pluszba. Az első beszélgetésen ezt a számítást közösen, a te számaiddal végigcsináljuk; a képletet és egy kitöltött példát itt bontok ki: [napi fél óra másolgatás = évi 125 óra](/tudastar/automatizalas-megterulese/). ## Mihez kapcsolódik ez a szolgáltatás? Az automatizálás ritkán áll önmagában. Ha a bejövő adat forrása egy űrlap vagy egy oldal, az [egyedi weboldal](/egyedi-weboldal-keszites/); ha rendelés, akkor a [webshop](/webshop-keszites/) rendelés utáni szakasza. Ugyanaz a projekt, csak az a része, amit eddig ember pótolt. ## Gyakori kérdések ### A mi rendszerünk nagyon régi vagy nagyon egyedi. Ezzel is megy? Legtöbbször igen. Első lépésben megnézem, milyen kapcsolódási pontja van (API, export, adatbázis, felület), és őszintén megmondom, ha nem éri meg. ### Mi történik, ha az automatizmus hibázik? Naplóz és riaszt. A kritikus lépések — pénz, számla, kifelé menő kommunikáció — emberi jóváhagyási pontot kapnak, amíg meg nem bízol benne. ### Függeni fogok tőled? Nem. A kód, a dokumentáció és minden hozzáférés a tiéd; bevett technológiákra építek, hogy bármelyik fejlesztő átvehesse. ### Mennyi idő alatt látszik az eredmény? Egy körülhatárolt összekötés jellemzően napok kérdése, egy több rendszert érintő folyamat heteké. Az első lépés mindig a legfájóbb, legjobban mérhető feladat — hogy a megtérülés a projekt elején látszódjon, ne a végén. --- # bucipek.hu — pékség-honlap rendelési és karrier modullal URL: https://rootcr.hu/referenciak/bucipek/ Frissítve: 2026-08-14 # bucipek.hu — pékség-honlap saját rendelési és karrier modullal > **Röviden:** Egy pékség honlapja, amely nemcsak bemutat, hanem dolgozik is: rendelést vesz fel, és karrier oldalán önéletrajzot fogad. A fájlfeltöltés minden webhely legveszélyesebb pontja, ezért itt a feltöltött állomány valódi típusát a tartalma alapján ellenőrzi a rendszer, makrót és futtatható tartalmat keres, majd vírusellenőrzés fut. Az oldal 192 URL-lel szerepel a Google indexében, strukturált adat hiba nélkül. ## A feladat Egy működő pékségnek olyan honlap kellett, ami két dolgot tud, amit egy bemutatkozó oldal nem: rendelést fogad, és jelentkezőt gyűjt. Mindkettő adatot vesz át a látogatótól — az egyik személyeset, a másik ráadásul fájlt. Ez a pont dönti el, hogy egy honlap eszköz-e vagy kockázat. ## A megoldás ### Rendelési modul A rendelés nem egy általános kosármotor, hanem a pékség tényleges folyamatára írt logika: mit lehet mikorra kérni, mi van készleten, mi az, ami előrendelésre megy. A rendelés a beérkezés pillanatában értesítést küld, és naplózódik — nem egy postafiókban kell utána keresgélni. ### Karrier modul és a fájlfeltöltés A karrier oldalon bárki tölthet fel önéletrajzot, és a fájlfeltöltés minden webhely legveszélyesebb pontja. Ezért a feltöltött állomány valódi típusát a tartalma alapján ellenőrzi a rendszer — nem a kiterjesztése alapján, mert azt bárki átírja —, a dokumentumban futtatható tartalmat és makrót keres, majd vírusellenőrzés fut. Ha bármelyik lépés elbukik, a fájl nem kerül lemezre. Ami átmegy, webről nem elérhető könyvtárba kerül, és 365 nap után automatikusan törlődik. Ez utóbbi nem technikai finomság: személyes adatot határidő nélkül tárolni nem szabad. ### Kereshetőség Az oldal teljes strukturált adattal készült: terméktípusok, nyitvatartás, elérhetőség, gyakori kérdések — gépi formában is. Nem utólagos kiegészítésként, hanem az építés részeként. ## Az eredmény | Mit | Mennyi | Forrás | |---|---|---| | Indexelt URL | 192 | Google Search Console | | Strukturált adat hiba | 0 | Google Search Console / Rich Results Test | | Fájlellenőrzési rétegek | 3 (típus, makró, vírus) | a rendszer forráskódja | | Önéletrajzok automatikus törlése | 365 nap | ütemezett feladat | ## Ellenőrizd magad - [site:bucipek.hu](https://www.google.com/search?q=site%3Abucipek.hu) — hány oldal van a Google indexében, épp most. - [PageSpeed Insights](https://pagespeed.web.dev/) — illeszd be a `https://bucipek.hu/` címet, és mérj a Google saját műszerével. - [Rich Results Test](https://search.google.com/test/rich-results) — a strukturált adat hibalistája ugyanarra a címre. - [bucipek.hu](https://bucipek.hu/) — maga az élő oldal. ## Mi tanulható belőle? Hogy egy honlap akkor kezd megtérülni, amikor munkát vesz át: rendelést, jelentkezést, adminisztrációt. És hogy a fájlfeltöltés nem funkció, hanem felelősség — ha egy fejlesztő ezt egy bővítményre bízza, valójában nem tudja, mi véd. Ha hasonló feladatod van, itt a szolgáltatás: [egyedi weboldal készítés](/egyedi-weboldal-keszites/). --- # honeyzsu.hu — kézműves webshop saját katalóguskezelővel URL: https://rootcr.hu/referenciak/honeyzsu/ Frissítve: 2026-08-14 # honeyzsu.hu — kézműves webshop, saját katalóguskezelővel > **Röviden:** Kézműves termékek webshopja 18 egyedi oldallal, sablon nélkül, saját designnal. A projekt igazi tanulsága nem a látvány, hanem a mögötte lévő eszköz: egy parancssori katalóguskezelő, amellyel a tömeges árazás, készlet- és leírásmódosítás percek alatt lefut ahelyett, hogy naponta órákat vinne el az admin felületen kattintgatva. ## A feladat Kézműves terméknél a bolt maga is a termék része: ha a webshop ugyanúgy néz ki, mint a többi ezer, a kézzel készített áru is olcsóbbnak látszik. Egy sablonrendszer viszont pont ezt nem engedi — a design a beállítások keretei között mozoghat. A második, kevésbé látványos feladat a napi működés volt: sok termék, gyakran változó árral, készlettel, leírással. Az admin felületen ez darabonkénti kattintgatás, ami idővel több munkát jelent, mint maga az értékesítés. ## A megoldás ### 18 egyedi oldal, sablon nélkül Minden oldal saját designnal és saját kóddal készült. Nem egy sablon átszínezése, ezért az oldalak nem is „egyformák, csak más képpel”: mindegyik a saját tartalmához igazodik. ### Katalóguskezelő parancssori eszköz Ez a projekt legnagyobb üzleti hozadéka. Az eszköz a teljes katalógust kezeli: tömeges árazás, készlet, kategória és leírás módosítás — ellenőrzéssel és visszavonható lépésekkel, minden futás előtt automatikus mentéssel. Ami korábban napi órákat vitt el, az percek alatt lefut. Ez az a pont, ahol a webshop és a [folyamat-automatizálás](/folyamat-automatizalas/) találkozik: ugyanaz a munka, csak az a része, amit eddig ember pótolt. ### Termék-strukturált adat A termékek árral és készletinformációval jelenhetnek meg a Google találataiban és az AI-válaszokban. Ez a webshopoknál nem díszítés: ettől függ, hogy a termék egyáltalán megjelenik-e összehasonlításban. ## Az eredmény | Mit | Mennyi | Forrás | |---|---|---| | Egyedi oldal | 18 | a projekt terjedelme | | Tömeges katalógusműveletek | percek (korábban napi órák) | a katalóguskezelő futásideje | | Mentés a módosítás előtt | minden futásnál | az eszköz működése | | Sablon és bővítmény a rendszerben | 0 | a forráskód | ## Ellenőrizd magad - [honeyzsu.hu](https://honeyzsu.hu/) — az élő webshop. - [PageSpeed Insights](https://pagespeed.web.dev/) — sebességmérés a Google saját műszerével. - [Rich Results Test](https://search.google.com/test/rich-results) — a termékek strukturált adata bármelyik termékoldalon. ## Mi tanulható belőle? Hogy egy webshopnál a látható rész a fele. A másik fele az, hogy a tulajdonos hány órát tölt a rendszerrel naponta — és ezt az órát csak akkor lehet visszaadni, ha valaki a napi működésre is épít eszközt, nem csak a vitrint rakja ki. Ha ismerős a helyzet: [egyedi webshop készítés](/webshop-keszites/). --- # Referenciák — élő, ellenőrizhető rendszerek URL: https://rootcr.hu/referenciak/ Frissítve: 2026-08-14 # Referenciák > **Röviden:** Minden itt szereplő oldal éles üzemben fut — nem terv, nem képernyőkép. Minden szám mellett ott a mérés módja és dátuma, és a legtöbbet magad is ellenőrizheted egy kattintással. Három rendszer: egy pékség-honlap saját rendelési és karrier modullal, egy nagykereskedelmi ajánlatkérő öt védelmi réteggel, és egy kézműves webshop 18 egyedi oldallal. ## Az élő rendszerek | Oldal | Mi ez | A lényeg egy számban | |---|---|---| | [bucipek.hu](https://bucipek.hu/) | Pékség-honlap rendelési és karrier modullal | 192 indexelt URL, nulla strukturált adat hiba | | [pekarunagyker.hu](https://pekarunagyker.hu/) | Nagykereskedelmi ajánlatkérő | 5 egymásra épülő védelmi réteg az űrlapon | | [honeyzsu.hu](https://honeyzsu.hu/) | Kézműves webshop | 18 egyedi oldal, saját katalóguskezelő eszközzel | Az esettanulmányok: [bucipek.hu](/referenciak/bucipek/) · [pekarunagyker.hu](/referenciak/pekarunagyker/) · [honeyzsu.hu](/referenciak/honeyzsu/) ## Hogyan mérek, és miért így? A sebességet nem szlogenként állítom, hanem naponta megmérem. A saját szerverről, a nyilvános címen keresztül (tehát a Cloudflare-en át, ahogy egy látogató is érkezik), oldalanként három futtatással, a legjobb értéket megtartva. A pontos parancs a főoldal mérés-dobozában olvasható, hogy megismételhető legyen. Fontos tisztesség-szabály: **ez laboratóriumi mérés.** Ugyanarról a gépről, ugyanabban a hálózatban, terhelés nélkül. A te eszközödön, a te mobilhálózatodon mért érték ettől eltér — ezért a helyes lépés nem az, hogy elhiszed, hanem az, hogy megméred: - [PageSpeed Insights](https://pagespeed.web.dev/) — illeszd be bármelyik fenti címet, és a Google saját műszerével mérj. - [Rich Results Test](https://search.google.com/test/rich-results) — ugyanígy ellenőrizhető, hogy a strukturált adat hibátlan-e. Ha egy szám mellett nincs ott, hogy mikor és mivel mértem, akkor annak a számnak nincs helye ezen az oldalon. Ez a szabály rám is vonatkozik: az indexeltségi értékek forrása a Google Search Console, és minden ilyen állítás mellett ott a nyilvános ellenőrzés módja is. ## Mi közös a három projektben? - **Saját kód.** Egyik rendszer sem sablonból készült, és egyikben sincs bővítmény-lánc, ami magától frissül alattad. - **Védett űrlap.** Ahol adatot vagy fájlt fogad az oldal, ott többrétegű, szerveroldali ellenőrzés fut — nem egy kapcsoló egy admin felületen. - **Teljes strukturált adat.** Mindhárom oldal gépi formában is elmondja, mit csinál, és ez látszik a keresőben. - **Átadott hozzáférés.** A forráskód és minden belépés a megrendelőé; egyik oldal sem függ tőlem az átadás után. --- # pekarunagyker.hu — ajánlatkérő öt védelmi réteggel URL: https://rootcr.hu/referenciak/pekarunagyker/ Frissítve: 2026-08-14 # pekarunagyker.hu — egy űrlap, amit a botok nem tudnak megenni > **Röviden:** Egy nagykereskedelmi ajánlatkérő űrlapon öt védelmi réteg fut egymás után: a kérés csak a saját oldalról érkezhet, a rejtett csapda-mező kiszűri az automata kitöltőt, a túl nagy törzs el sem éri az alkalmazást, lefut az ember-ellenőrzés, végül IP-címenként korlátozott a beküldések száma. Mindegyik réteg szerveroldali kód, nem egy bővítmény ígérete — és a megkeresés előbb kerül lemezre, csak utána megy a levél. ## A feladat Nagykereskedelmi ajánlatkérésnél a beérkező üzenet pénzt ér: minden egyes sor egy potenciális vevő. Ugyanez a beviteli pont viszont a legkedveltebb célpont is — az automata kitöltők óránként próbálkoznak. Két rossz kimenet van: a spam elönti a postafiókot (és a valódi megkeresés elvész benne), vagy a védelem annyira szigorú, hogy a valódi érdeklődő is fennakad. ## A megoldás: öt réteg, sorrendben 1. **Eredet-ellenőrzés.** A beküldés csak a saját oldalról érkezhet. Ami máshonnan jön, azt a szerver már az adatok kiolvasása előtt elutasítja. 2. **Csapda-mező.** Egy rejtett mező, amit ember sosem lát és sosem tölt ki. Az automata kitöltő viszont minden mezőt kitölt — és ezzel leleplezi magát. A válasz szándékosan „sikeres”, hogy a bot ne tanuljon a hibából. 3. **Méretkorlát.** A túl nagy kérés-törzs el sem éri az alkalmazást: a kiszolgáló szintjén elakad. Ez az a réteg, ami a legolcsóbban véd a terheléses próbálkozás ellen. 4. **Ember-ellenőrzés.** Süti nélküli, adatvédelmi szempontból tiszta ellenőrzés, ami a látogatót nem terheli képválogatással. 5. **IP-korlát.** Címenként korlátozott számú beküldés óránként. Ez nem a botok fő szűrője, hanem a maradék elleni védelem — és a költséges műveletek elé kerül, hogy egy támadó ne tudjon rajtuk keresztül munkát végeztetni a szerverrel. ## Ami az űrlap után történik A megkeresés **először lemezre kerül, és csak utána megy a levél.** Ez a sorrend szándékos: ha a levélküldő szolgáltatás kiesik, az érdeklődő akkor sem vész el. Ha a levél mégsem megy ki, arról a napló azonnal árulkodik. A kimenő értesítés hitelesített feladóval megy (SPF és DKIM), válaszcímként pedig az érdeklődő címe szerepel — így a válasz egy kattintás, nem másolgatás. ## A kiszolgálás oldala Az űrlapot fogadó szolgáltatás önálló, korlátozott jogú folyamatként fut: nem lát a saját könyvtárán kívülre, nem tud jogot emelni, nem tud a rendszer többi részéhez nyúlni, és memória- és folyamatkorlát alatt dolgozik. Ha egy sebezhetőség mégis lenne benne, a kárt ez a keret határolja be. ## Ellenőrizd magad - [pekarunagyker.hu](https://pekarunagyker.hu/) — az élő oldal; az ajánlatkérő űrlap kipróbálható. - Küldj el egy üres űrlapot: azonnal látszik, mit mond a rendszer, és hogy a hibaüzenet mennyit árul el (szándékosan keveset). - [PageSpeed Insights](https://pagespeed.web.dev/) — sebességmérés a Google saját műszerével. ## Mi tanulható belőle? Hogy az űrlapvédelem nem egy kapcsoló, hanem sorrend. A rétegek olcsótól a drágáig épülnek egymásra: előbb az, ami egy fejléc olvasásából eldől, utoljára az, ami külső szolgáltatás hívását igényli. Ez a sorrend dönti el, hogy egy támadó tud-e munkát végeztetni a szervereddel. Ha neked is űrlapon jön a bevétel: [egyedi weboldal készítés](/egyedi-weboldal-keszites/). A védelmi rétegek részletes bontása külön írásban: [hogyan véd egy ajánlatkérő űrlap a spam ellen](/tudastar/urlap-spam-vedelem/). --- # Napi fél óra másolgatás = évi 125 óra: az automatizálás megtérülése URL: https://rootcr.hu/tudastar/automatizalas-megterulese/ Frissítve: 2026-08-14 # Napi fél óra másolgatás = évi 125 óra: az automatizálás megtérülése > **Röviden:** Egy naponta ismétlődő, fél órás kézi feladat évente körülbelül 125 munkaórát visz el — ez egy 5000 Ft-os órabérrel számolva évi 625 000 Ft. A megtérülés képlete egyszerű: (naponta megspórolt perc ÷ 60) × munkanapok × órabér, mínusz a fejlesztés ára. A legtöbb jól megválasztott automatizálás hónapokban mérhető idő alatt fordul pluszba — de csak akkor, ha valóban ismétlődő és valóban szabályozható feladatot választasz. ## A képlet ``` éves megtakarítás = (naponta megspórolt perc ÷ 60) × munkanapok × órabér megtérülési idő = a fejlesztés ára ÷ (éves megtakarítás ÷ 12) ``` Magyarországon egy évben nagyjából **250 munkanap** van. Ezzel: | Naponta elvitt idő | Éves óraszám | Éves költség 4000 Ft/óra bérrel | 6000 Ft/óra bérrel | |---|---|---|---| | 15 perc | 62,5 óra | 250 000 Ft | 375 000 Ft | | 30 perc | 125 óra | 500 000 Ft | 750 000 Ft | | 1 óra | 250 óra | 1 000 000 Ft | 1 500 000 Ft | | 2 óra | 500 óra | 2 000 000 Ft | 3 000 000 Ft | Ezek nem elméleti számok: a napi fél óra az az idő, amit egy kolléga a rendelések átmásolásával, a készlet frissítésével vagy a heti riport összeollózásával tölt. ## Egy végigszámolt példa **A helyzet:** a webshopból naponta kézzel viszik át a rendeléseket a számlázóba. Napi 40 perc, egy kolléga, 4500 Ft-os órabérrel számolt bérköltséggel. **A jelenlegi költség:** (40 ÷ 60) × 250 × 4500 = **750 000 Ft / év** **A fejlesztés:** a webshop és a számlázó összekötése, hibakezeléssel és riasztással: 12 óra × 20 000 Ft = **240 000 Ft**. **A megtérülés:** 750 000 ÷ 12 = 62 500 Ft havi megtakarítás → 240 000 ÷ 62 500 ≈ **3,8 hónap.** És ami a táblázatban nem szerepel: a kézi átvitel **hibázik.** Egy elrontott számla javítása nemcsak idő, hanem ügyfélbizalom is. ## Mit érdemes automatizálni? Három feltétel egyszerre: 1. **Ismétlődő.** Naponta vagy hetente ugyanaz. Az évi kétszeri feladatra írt szkript nem térül meg. 2. **Szabályozható.** Le tudod írni mondatokban, mit kell csinálni. Ha minden esetben mérlegelni kell, az még nem automatizálható — legfeljebb előkészíthető ember számára. 3. **Mérhető a bemenet és a kimenet.** Van rendszer, ahonnan az adat jön, és van, ahova megy. Tipikus, jól megtérülő feladatok: rendelés → számlázó, készletszinkron a rendszerek között, éjszakai árfrissítés, heti-havi riport összeállítása, bejövő e-mailek osztályozása és iktatása, automatikus mentés és ellenőrzés. ## Mit NE automatizálj? - **Amit még nem értesz.** Ha a folyamat ma is kaotikus, az automatizálás gyorsabban fogja csinálni a rosszat. - **Ami havonta változik.** A gyakran változó szabályt drágább karbantartani, mint kézzel végigcsinálni. - **Ahol a tévedés drága, és nincs ellenőrzési pont.** Pénzmozgás, kifelé menő kommunikáció, jogi következményű döntés — ide emberi jóváhagyási pont kell, legalábbis addig, amíg a rendszer bizalmat nem szerez. - **Amit egyszerűbb megszüntetni.** A legjobb automatizálás néha az, hogy kiderül: az a riport senkinek nem kell. ## A rész, amit a legtöbben kihagynak: a riasztás Az automatizálás fele nem a munka elvégzése, hanem az, hogy **szóljon, ha elakad.** Egy szkript, ami csendben hibázik, rosszabb, mint a kézi munka — mert a kézi munkánál legalább valaki észreveszi. Minden automatizmusnak legyen naplója és riasztása. Ez a különbség a „megírtam egy szkriptet” és az „üzemben tartható rendszer” között — és ez az a rész, amit az olcsó megoldásokból kihagynak. ## Hogyan kezdj hozzá? 1. Egy héten át **írd fel**, mire megy el az idő. Nem emlékezetből — menet közben. 2. Válaszd ki azt az **egy feladatot**, ami a legtöbb időt viszi és a legjobban szabályozható. 3. Számold ki a fenti képlettel, mennyit ér évente. 4. Kérj rá árat. Ha a megtérülés egy éven belül van, csináld meg. 5. Csak utána jöjjön a második feladat. Ezt a számítást az első beszélgetésen közösen, a te számaiddal végigcsináljuk: [folyamat-automatizálás](/folyamat-automatizalas/). ## Gyakori kérdések ### Mennyi idő egy ilyen fejlesztés? Egy körülhatárolt összekötés jellemzően napok kérdése, egy több rendszert érintő folyamat heteké. Az elsőnek mindig a legfájóbb, legjobban mérhető feladatot érdemes választani. ### Mi van, ha a rendszerünknek nincs API-ja? Akkor is van megoldás: ütemezett export-import, adatbázis-szintű kapcsolat, vagy felület-vezérlés. Első lépésben megnézem, milyen kapcsolódási pontja van, és megmondom, ha nem éri meg. ### Az automatizálás elveszi a kolléga munkáját? A gyakorlatban azt a részét veszi el, amit senki nem szeret csinálni — a másolgatást. Az így felszabaduló idő jellemzően oda kerül, ahol emberre tényleg szükség van: az ügyfélhez. --- # Félbehagyott weboldal átvétele: javítani vagy újraírni? URL: https://rootcr.hu/tudastar/felbehagyott-weboldal-atvetele/ Frissítve: 2026-08-14 # Félbehagyott weboldal átvétele: javítani vagy újraírni? > **Röviden:** Egy örökölt vagy félbehagyott projektnél a döntés nem a kód szépségén múlik, hanem három dolgon: megvan-e minden hozzáférés, érthető-e a rendszer felépítése, és mennyi az, amit ténylegesen újra kellene írni. Ha a hozzáférések megvannak és a szerkezet követhető, a javítás szinte mindig olcsóbb. Ha a hozzáférés hiányos vagy a rendszer minden ponton kivételekből áll, az újraírás olcsóbb — akkor is, ha elsőre drágábbnak tűnik. ## Az első lépés, amit még ma megtehetsz Mielőtt bárkivel beszélsz, szerezd meg ezt a hetet. Ez akkor is a tiéd, ha maradsz a mostani fejlesztőnél: 1. **Domain-hozzáférés** (a regisztrátornál, a te nevedre). 2. **Tárhely- vagy szerver-hozzáférés.** 3. **A weboldal adminfelületének** teljes jogú belépése. 4. **A forráskód** — teljes egészében, nem részletekben. 5. **Az adatbázis** mentése. 6. **Google Search Console és analitika** tulajdonosi jog. 7. **E-mail és DNS** beállítások. Ha ezekből bármelyik hiányzik, az a legsürgősebb feladat — sokkal fontosabb, mint hogy szép-e a kód. Hozzáférés nélkül nem a rendszert, hanem a céged online jelenlétét nem birtoklod. ## Mit nézek meg először? Amikor átveszek egy projektet, nem a kód esztétikáját nézem. Négy kérdésre keresek választ: ### 1. Mi a rendszer valójában? Sablon? Sablon plusz tizenöt bővítmény? Egyedi kód? Egy keretrendszer, amiből kinőtték? Ez határozza meg, mi mennyibe kerül ezután. ### 2. Mennyi a kivétel? Ez a legjobb előrejelző. Ha a rendszer minden ponton „ezt itt még gyorsan megoldottuk”-ból áll, akkor minden módosítás kockázat, és minden becslés hazugság lesz. Ha van benne rend — akár egyszerű rend —, a javítás kiszámítható. ### 3. Van-e biztonsági kockázat most? Elavult komponensek, hitelesítés nélküli végpontok, ellenőrizetlen fájlfeltöltés, jelszavak a forráskódban. Ez a rész nem várhat a nagy döntésre: amit ma be lehet zárni, azt ma zárjuk be. ### 4. Mi a helyzet a keresőben? Hány oldal van indexelve, mire jön forgalom, van-e olyan pozíció, amit egy rossz átállással el lehet veszíteni. Ez határozza meg, mennyire kell óvatosnak lenni az URL-ekkel. ## A döntési szabály | Jel | Javítás | Újraírás | |---|---|---| | Minden hozzáférés megvan | ✓ | | | A szerkezet követhető, van benne rend | ✓ | | | A hiba egy körülhatárolt részen van (űrlap, egy modul) | ✓ | | | A tartalom és a keresőpozíciók értékesek, az URL-ek jók | ✓ | | | Hiányzik a forráskód vagy egy kulcshozzáférés | | ✓ | | Minden módosítás eltör valami mást | | ✓ | | A rendszer alapfeltevése nem illik a folyamathoz | | ✓ | | Ismert, javítatlan biztonsági hiba a rendszer magjában | | ✓ | | Öt vagy több fizetős bővítmény tartja életben | | mérlegelendő | A legfontosabb sor a harmadik alulról: **ha a rendszer alapfeltevése nem illik a folyamathoz, a javítás sosem ér véget.** Nem azért, mert a fejlesztő rossz, hanem mert minden új igény újabb kivétel lesz. Erről szól a [WordPress kontra egyedi](/tudastar/wordpress-vagy-egyedi-weboldal/) döntés is. ## Mit vihetsz át újraírásnál? - **A tartalmat** — szöveg, kép, termékadat exportálható. - **A keresőpozíciókat** — a régi címekről átirányítás megy az újakra. Ez a technikai lépés dönti el, hogy az újraírás után nő vagy zuhan a forgalom. - **A vevő- és rendelési adatokat** — adatbázisból migrálva. Amit nem viszel át: a technikai adósságot. Ez a cél. ## Hogyan zajlik nálam? Először átnézem a meglévő rendszert, és írásban megmondom, mit találtam, mi a kockázat most, és javítani vagy újraírni éri-e meg. Ez néhány óra munka, és őszinte választ kapsz akkor is, ha az a válasz, hogy a mostani rendszert érdemes megtartani, vagy hogy a mostani fejlesztőddel jobban jársz. Ha az újraírás mellett döntünk, az új rendszer párhuzamosan készül, és az átállás egyetlen, előre egyeztetett időpontban történik, átirányításokkal. ## Gyakori kérdések ### A régi fejlesztő nem adja ki a hozzáféréseket. Mit tegyek? Kérd írásban, hivatkozva a szerződésre és arra, hogy a domain és az adat a tiéd. A domain a regisztrátornál általában átíratható tulajdonosi igazolással is. Ez sajnos gyakori helyzet, és a leggyorsabban attól javul, ha írásban, dátummal kéred. ### Mennyibe kerül az átnézés? Néhány óra munka óradíjas elszámolásban. Ennek a végén írásos véleményt kapsz — akkor is, ha nem én folytatom. ### Nem veszítem el a Google-helyezéseimet? Ha az átirányításokat valaki komolyan veszi, nem. Ha kihagyja, akkor igen — ezért van ez a lépés minden ajánlatomban tételként. --- # Hogyan kerül be egy magyar kkv a ChatGPT és a Google AI válaszaiba? URL: https://rootcr.hu/tudastar/hogyan-kerul-be-egy-kkv-a-chatgpt-valaszaiba/ Frissítve: 2026-08-14 # Hogyan kerül be egy magyar kkv a ChatGPT és a Google AI válaszaiba? > **Röviden:** A nyelvi modellek nem cégeket rangsorolnak, hanem **dokumentumokat idéznek.** Ahhoz, hogy egy modell megemlítse a cégedet, olyan oldalad kell legyen, ami egy konkrét kérdésre önmagában megálló, tényszerű, ellenőrizhető választ ad — és amit a robotok elérnek, elolvasnak és gépi formában is megértenek. Ez a munka nagyrészt ugyanaz, ami a hagyományos keresőben is előre visz, csak szigorúbban végigcsinálva. Garanciát rá senki nem adhat. ## Mi változott? Régen a kereső tíz linket adott, és te választottál. Ma egyre több kérdésre **kész válasz** érkezik — a Google AI-összefoglalójától a ChatGPT keresőjén át a Perplexityig —, és a válasz alatt két-három forrás szerepel. Az a néhány forrás az új első hely. Erre két rövidítés terjedt el: **AEO** (answer engine optimization, válaszmotor-optimalizálás) és **GEO** (generative engine optimization). Ugyanarról szólnak: hogyan lesz a tartalmadból idézhető forrás. ## Amit a modell keres — és amit nem A nyelvi modell nem „a legjobb céget” keresi. Egy kérdésre keres **hivatkozható mondatot.** Ezért: - **Nem segít:** a „több éves tapasztalat, megbízható partner, minőségi szolgáltatás” típusú szöveg. Ez semmilyen kérdésre nem válasz. - **Segít:** „Egy egyedi webshop 400 000 Ft-tól indul, jellemzően 6–10 hét alatt készül el, és a forráskód a megrendelőé marad.” Ez tény, ez idézhető, és ez el is dönt egy kérdést. ## A hat lépés, ami ténylegesen számít ### 1. Legyen dokumentum, amit idézni lehet A legfontosabb lépés, és a legtöbben itt buknak el. Ha a cégedről egyetlen dokumentum létezik — a szolgáltatás-önleírás —, akkor semmilyen kérdésre nem vagy forrás. Kellenek olyan oldalak, amelyek **egy konkrét kérdést válaszolnak meg** („megéri-e egyedi webshopot fejlesztetni?”, „mennyibe kerül egy weboldal?”, „miért lassú a WooCommerce?”). ### 2. Az oldal eleje adja meg a választ Minden oldal és cikk elején legyen egy 40–70 szavas, önmagában megálló összefoglaló, ami alany–állítmány szerkezetű tényekkel válaszol a fő kérdésre. Ez az, amit egy AI-összefoglaló át tud emelni. (Ezen az oldalon is ez a „Röviden” blokk.) ### 3. Kérdés-formájú címsorok A címsor legyen maga a keresett kérdés, és az első mondat közvetlenül válaszoljon rá. A modell bekezdés-szinten emel át tartalmat — nem oldal-szinten. ### 4. Számok forrással és dátummal „Gyors az oldal” — semmi. „TTFB 0,065 s, saját szerverről mérve, 2026. augusztus 14.” — ez idézhető. A modellek és az emberek is a forrásolt, dátumozott számot fogadják el. ### 5. Gépi olvashatóság - A tartalom legyen **szerveroldalon renderelt szöveg**, ne csak JavaScript után jelenjen meg. - A robotok kapjanak **engedélyt** a robots.txt-ben (GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended és társaik). - Legyen **strukturált adat**: gépi formában is elmondva, ki vagy, mit csinálsz, mennyiért. Erről külön: [mi az a strukturált adat](/tudastar/mi-az-a-strukturalt-adat/). - Érdemes **llms.txt**-t és oldalanként **markdown-tükröt** kiszolgálni: a modellnek szánt, tiszta, jelölés nélküli változatot. Ez a néhány kilobájt a legolcsóbb módja annak, hogy a teljes tartalmadat egy kéréssel, félreértés nélkül megkapja. ### 6. Egyértelmű entitás A modellek entitásokban gondolkodnak. Egy azonosíthatatlan cég gyenge entitás. Ami segít: **egyetlen kanonikus önmeghatározás**, ami szó szerint ugyanaz mindenhol (weboldal, llms.txt, LinkedIn, e-mail aláírás); név és arc a cég mögött; kölcsönösen linkelő saját felületek; impresszum, ami azonosít. ## Mit lehet mérni? Ez a terület tele van megalapozatlan ígéretekkel, ezért a mérés különösen fontos: | Mit mérj | Hogyan | |---|---| | Elérik-e egyáltalán a modellek a tartalmadat | Szervernapló: GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, bingbot találatok hetente | | Jön-e látogató AI-felületről | Hivatkozó forrás: chatgpt.com, perplexity.ai, gemini.google.com | | Idéznek-e | Havonta ugyanaz az öt kérdés a ChatGPT-nek, a Perplexitynek és a Gemininek, rögzítve | A harmadik a legfontosabb és a legkevésbé automatizálható: kérdezd meg havonta ugyanazokat a kérdéseket, és nézd meg, ki jelenik meg forrásként. ## Amit senki nem garantálhat Hogy megjelensz. Nem a te oldaladon múlik egyedül: a modell dönt, és a döntés hónapról hónapra változik. Aki garanciát ígér, az vagy nem érti, vagy nem mondja el, mit ad el. Amit **lehet** garantálni: hogy a tartalom elérhető, olvasható, tényszerű, dátumozott és gépi formában is értelmezhető. Ezek nélkül biztosan nem jelensz meg — ezekkel esélyed van, és ugyanez a munka a hagyományos keresőben is előre visz. Ez a különbség egy tisztességes és egy hangzatos ajánlat között. ## Gyakori kérdések ### Ez ugyanaz, mint a hagyományos keresőoptimalizálás? Nagyrészt igen, de a hangsúly máshol van: a kereső oldalakat rangsorol, a modell bekezdéseket idéz. Ezért lesz fontosabb az önmagában megálló összefoglaló, a kérdés-formájú címsor és a forrásolt szám. ### Elég, ha blogolok? Nem a mennyiség számít. Nyolc-tíz alaposan megírt, számokkal alátámasztott, évente frissített írás többet ér, mint heti egy tartalmi töltelék — a modellek a jól körülhatárolt, tényszerű forrást részesítik előnyben. ### Mibe kerül ez? Ha az oldal építésének része, akkor nem külön tétel: nálam a strukturált adat és a gépi olvashatóság minden [egyedi weboldal](/egyedi-weboldal-keszites/) alapfelszereltsége. A tartalom megírása az, ami időt kér — attól függően, hogy a szakmai anyag tőled jön-e. --- # Tudástár URL: https://rootcr.hu/tudastar/ Frissítve: 2026-08-14 # Tudástár > **Röviden:** Itt azokat a kérdéseket válaszolom meg, amiket az ügyfeleim a döntés előtt feltesznek: sablon vagy egyedi, melyik webshop-rendszer, mennyibe kerül, meddig lehet gyorsítani egy lassú oldalt, mikor éri meg automatizálni. Minden írásban van döntési szabály és számolás — nem hirdetés, hanem az az anyag, amit én is elolvasnék a helyedben. ## Döntés a rendszerről - [Mikor éri meg egyedi weboldal a WordPress helyett — és mikor nem?](/tudastar/wordpress-vagy-egyedi-weboldal/) Döntési tábla és a sablon rejtett üzemköltségének kiszámítása. - [Shopify, WooCommerce, Unas vagy egyedi webshop? Döntési útmutató](/tudastar/shopify-woocommerce-unas-vagy-egyedi-webshop/) Négy rendszer, négy jellemző helyzet, és hogy melyiknél hol van a fal. - [Félbehagyott weboldal átvétele: javítani vagy újraírni?](/tudastar/felbehagyott-weboldal-atvetele/) Mit nézek meg először, és milyen jelnél mondom azt, hogy újra kell írni. ## Sebesség és pénz - [Miért lassú a WordPress webshop, és meddig lehet gyorsítani?](/tudastar/miert-lassu-a-wordpress-webshop/) Hol keletkezik a lassúság, mit old meg a gyorsítótár, és hol van a plafon. - [Weboldal készítés árak: mitől függ, és mi a reális?](/tudastar/weboldal-keszites-arak/) Mit fedez egy 100 ezres, egy 500 ezres és egy több milliós projekt. - [Napi fél óra másolgatás = évi 125 óra: az automatizálás megtérülése](/tudastar/automatizalas-megterulese/) A képlet, egy kitöltött példa, és hogy mit ne automatizálj. ## Láthatóság és biztonság - [Hogyan kerül be egy magyar kkv a ChatGPT és a Google AI válaszaiba?](/tudastar/hogyan-kerul-be-egy-kkv-a-chatgpt-valaszaiba/) Mit lehet ténylegesen megtenni, és mi az, amit senki nem garantálhat. - [Mi az a strukturált adat, és miért jelenik meg a versenytársad árral a Google-ban?](/tudastar/mi-az-a-strukturalt-adat/) Mit lát a kereső, ha nem csak a szöveget olvassa. - [Hogyan véd egy ajánlatkérő űrlap a spam ellen? Az öt réteg](/tudastar/urlap-spam-vedelem/) Rétegek olcsótól a drágáig, és miért számít a sorrend. ## Miért írom ezeket? Mert a rossz döntés drágább, mint a fejlesztés. A legtöbb kérdés, amivel megkeresnek, nem az, hogy „mennyibe kerül”, hanem az, hogy „egyáltalán kell-e ez nekem”. Ezekre a kérdésekre itt kapsz választ akkor is, ha végül nem engem választasz — és ha mégis, akkor legalább tudod, mit veszel. --- # Mi az a strukturált adat, és miért jelenik meg a versenytársad árral a Google-ban? URL: https://rootcr.hu/tudastar/mi-az-a-strukturalt-adat/ Frissítve: 2026-08-14 # Mi az a strukturált adat, és miért jelenik meg a versenytársad árral a Google-ban? > **Röviden:** A strukturált adat egy gépi olvasásra szánt réteg az oldalon, amely nem szövegként, hanem adatként mondja el, hogy egy oldal mit ábrázol: terméket árral és készlettel, céget címmel és nyitvatartással, cikket szerzővel és dátummal. Ettől jelenhet meg a találatnál ár, értékelés, GYIK vagy morzsamenü. Nem rangsoroló tényező önmagában, de a találat kinézetét befolyásolja — és a nyelvi modellek is ezt olvassák a legkönnyebben. ## Miért van rá szükség? A kereső a szöveget is elolvassa, de a szöveg értelmezése bizonytalan. „14 900 Ft” — ez ár? Kedvezmény? Szállítási díj? Egy régi akció maradványa? A strukturált adat ezt a bizonytalanságot szünteti meg. Egy külön blokkban, szabványos formában (a schema.org szótárával, JSON-LD formátumban) kijelented: **ez a lap egy termék, az ára 14 900 forint, készleten van, ez a gyártó.** Nincs találgatás. ## Mit lehet vele elmondani? | Típus | Mit mond el | Mi lehet belőle a találatnál | |---|---|---| | Termék (Product) | Név, ár, pénznem, készlet, értékelés | Ár és készlet a találat alatt | | Cég (Organization / LocalBusiness) | Név, cím, elérhetőség, nyitvatartás | Cégpanel, térképes megjelenés | | Gyakori kérdések (FAQPage) | Kérdés-válasz párok | Lenyíló kérdések a találat alatt | | Cikk (Article) | Cím, szerző, megjelenés és frissítés dátuma | Dátum és szerző a találatban | | Morzsamenü (BreadcrumbList) | Az oldal helye a szerkezetben | Útvonal a cím alatt a nyers URL helyett | | Szolgáltatás (Service) | Mit nyújtasz, hol, milyen áron | Pontosabb megértés, AI-válaszokhoz idézhető tény | ## Mit ad, és mit nem? **Amit ad:** a találat kinézetét. Egy ár, egy értékelés vagy egy lenyíló kérdéssor a találatban több kattintást hoz ugyanarról a pozícióról. Emellett a nyelvi modellek is ezt a réteget dolgozzák fel a legmegbízhatóbban — az AI-válaszokba bekerülés egyik legolcsóbb feltétele. **Amit nem ad:** helyezést. A strukturált adat önmagában nem rangsoroló tényező. Ha rossz a tartalom, a strukturált adattól nem lesz jó. És ha az adat nem egyezik azzal, ami az oldalon látszik — például más árat jelentesz be, mint amit a látogató lát —, az kifejezetten büntethető. ## A leggyakoribb hibák 1. **Nincs egyáltalán.** A leggyakoribb eset. Ilyenkor a kereső találgat. 2. **Nem egyezik a láthatóval.** Bejelentett ár, ami nem az oldalon szereplő ár. Ez a legsúlyosabb hiba. 3. **Elavult adat.** A készlet „raktáron”, miközben hetek óta nincs. A strukturált adat akkor működik, ha ugyanabból a forrásból generálódik, mint a látható tartalom — nem kézzel karbantartva. 4. **Hiányos kötelező mezők.** Ár pénznem nélkül, cikk dátum nélkül. Ilyenkor a kiegészített találat egyszerűen nem jelenik meg. 5. **Ugyanaz a kérdés több oldalon.** A GYIK-blokk legyen oldalspecifikus, ne minden oldalon ugyanaz. ## Hogyan ellenőrizd? - [Rich Results Test](https://search.google.com/test/rich-results) — illeszd be a saját címedet, és megmutatja, mit lát a Google, és hol hibázik. - [Schema Markup Validator](https://validator.schema.org/) — a szabvány szerinti ellenőrzés. - Google Search Console → a fejlesztések jelentései: itt látszik, hogy a **teljes oldalon** hány hiba van, nem csak azon az egy lapon, amit épp ellenőrzöl. A cél nem az, hogy „legyen strukturált adat”, hanem hogy **nulla hiba** legyen. Ez az érték az, amit egy átadási jegyzőkönyvben kérni érdemes — nálam ez alapfelszereltség, példa: [bucipek.hu esettanulmány](/referenciak/bucipek/). ## Ki csinálja meg? A legjobb, ha nem utólagos ráaggatás, hanem az építés része, és ugyanabból a forrásból generálódik, mint az oldal látható tartalma. Így nem tud elcsúszni: ha a termék ára változik, a bejelentett ár is változik, mert ugyanaz az adat. Ha az oldalad most készül, ez ne külön tétel legyen az ajánlatban, hanem alapkövetelmény — nálam az: [egyedi weboldal készítés](/egyedi-weboldal-keszites/). ## Gyakori kérdések ### Kell hozzá bővítmény? Sablonrendszerben jellemzően igen, és ott a minőség a bővítménytől függ. Egyedi fejlesztésnél a strukturált adat a rendszer része, nem külön réteg. ### Miért nem jelenik meg a találatnál, pedig hibátlan? Mert a kiegészített találat lehetőség, nem jogosultság: a Google dönti el, mikor jeleníti meg. A hibátlan adat ehhez feltétel, nem garancia. ### Ez ugyanaz, mint a meta leírás? Nem. A meta leírás egy mondat az embernek. A strukturált adat gépnek szóló adathalmaz, amit a látogató nem lát. --- # Miért lassú a WordPress webshop, és meddig lehet gyorsítani? URL: https://rootcr.hu/tudastar/miert-lassu-a-wordpress-webshop/ Frissítve: 2026-08-14 # Miért lassú a WordPress webshop, és meddig lehet gyorsítani? > **Röviden:** Egy WooCommerce webshop lassúságának ritkán egy oka van. A három fő forrás: a betöltendő kód mennyisége (sablon + bővítmények), az adatbázis-lekérdezések száma terméklistázásnál, és a nem gyorsítótárazható oldalak (kosár, pénztár, bejelentkezett vevő). Gyorsítótárral és képoptimalizálással jellemzően jelentős javulás érhető el a nyilvános oldalakon, de a kosár és a pénztár marad lassú — mert azokat nem lehet előre kiszámolni. Ott a plafon. ## Hol keletkezik a lassúság? ### 1. A betöltendő kód mennyisége Egy tipikus WooCommerce webshop tucatnyi stíluslapot és szkriptet tölt be: a sablonét, az oldalépítőét, minden bővítményét. Ezek nagy része az adott oldalon nem is használódik — de letöltődik, feldolgozódik és lefut. Ez a rész az, amit a látogató a **legelső másodpercben** megérez: a lap vázlata már látszik, de még nem lehet kattintani rajta. ### 2. Az adatbázis-lekérdezések száma A terméklistázás WooCommerce-ben nem egy lekérdezés. Minden termékhez tartozik ár, készlet, variáns, adó, kép, kategória, esetleg vevőcsoport-specifikus ár — és a bővítmények is beleszólnak. Egy 24 terméket mutató kategórialap könnyen több száz lekérdezést futtat le. Ez a rész az, amitől **a szerver válasza maga lassú** (magas TTFB), és ezen a képoptimalizálás semmit nem segít. ### 3. Az oldalak, amiket nem lehet gyorsítótárazni A gyorsítótár úgy működik, hogy az oldal kész változatát elmenti, és a következő látogatónak azt adja ki. Ez remekül működik a nyitólapon és a termékoldalakon. **Nem működik** viszont ott, ahol az oldal minden látogatónak más: kosár, pénztár, fiók, bejelentkezett nagykereskedelmi vevő saját áraival. Vagyis pontosan azokon az oldalakon nem segít, ahol a pénz keletkezik. ## Mit old meg a gyorsítótár, és mit nem? | Probléma | Gyorsítótár segít? | Miért | |---|---|---| | Lassú nyitólap, kategórialap | Igen, sokat | Az oldal kész változata kiszolgálható | | Nagy, tömörítetlen képek | Nem, de a képoptimalizálás igen | Külön probléma, külön eszköz | | Sok bővítmény szkriptje és stíluslapja | Részben | Kevesebbet kell számolni, de ugyanannyit kell letölteni | | Lassú kosár és pénztár | Nem | Minden látogatónak más, nem menthető el | | Lassú admin felület | Nem | A gyorsítótár a nyilvános oldalakat szolgálja ki | | Vevőcsoportos árazás | Nem | Ugyanaz az oldal, más árakkal — nem gyorsítótárazható | ## Meddig lehet gyorsítani? A reális sorrend 1. **Mérj, ne tippelj.** [PageSpeed Insights](https://pagespeed.web.dev/) és a szerveroldali válaszidő (TTFB) külön nézendő. Ha a TTFB magas, a kliensoldali optimalizálás nem fog segíteni. 2. **Képek.** Modern formátum, helyes méret, késleltetett betöltés. A legolcsóbb, leggyorsabban megtérülő lépés. 3. **Bővítmény-leltár.** Minden bővítménynél kérdés: mit ad, és mennyibe kerül milliszekundumban? A leggyakoribb eredmény, hogy három-négy kidobható. 4. **Gyorsítótár és tömörítés.** Innentől a nyilvános oldalak gyorsak lesznek. 5. **Adatbázis és tárhely.** Ha idáig eljutottál és a kosár még mindig lassú, akkor a probléma szerkezeti. Az 1–4. lépés a legtöbb boltnál érezhető javulást hoz, és néhány nap munka. Az 5. lépésnél kell eldönteni, hogy foltozol vagy építesz. ## Mikor kell inkább újraépíteni? Nem sebességi szám dönti el, hanem szerkezeti jel. Építs újra, ha: - a **pénztár** lassú, és ezen a gyorsítótár per definitionem nem segít; - **vevőnkénti árazás** vagy nagykereskedelmi logika van a boltban, ami minden oldalt egyedivé tesz; - a bolt működéséhez **öt vagy több fizetős bővítmény** kell, amiket egymáshoz igazítva tartotok életben; - minden frissítés után **valami eltörik**, és ezt már be is áraztátok a havi költségbe; - az admin felületen töltött **napi munkaóra** nagyobb, mint ami az árbevételhez képest indokolt. Ilyenkor a kérdés már nem a sebesség, hanem az, hogy a rendszer alkalmas-e arra, amit csináltok vele. Erről szól az [egyedi webshop készítés](/webshop-keszites/), és a rendszerválasztást itt vezetem végig: [Shopify, WooCommerce, Unas vagy egyedi](/tudastar/shopify-woocommerce-unas-vagy-egyedi-webshop/). ## Mit jelent a „gyors” konkrétan? Sebességnél a szlogen semmit nem ér, mérés kell. Ezért mérem naponta a saját és a referencia-oldalaimat, ugyanazzal a paranccsal, és az eredmény kint van a [főoldalon](/) és a [referenciák](/referenciak/) alatt. Ugyanezt bárki megismételheti — ez a lényeg. ## Gyakori kérdések ### Egy jobb tárhely megoldja? Ritkán önmagában. Jobb tárhely csökkenti a szerveroldali időt, de a betöltendő kód mennyiségét és a lekérdezések számát nem. Ha a lekérdezésszám a gond, drágább vasat veszel ugyanahhoz a problémához. ### Mennyi idő alatt lehet gyorsítani egy meglévő boltot? A mérés és a képek-bővítmények-gyorsítótár kör jellemzően néhány nap. Ez a legjobb ár-érték arányú lépés, és érdemes ezzel kezdeni, mielőtt bárki új rendszerről beszél. ### Az újraépítés alatt áll a bolt? Nem. Az új rendszer párhuzamosan készül, és az átállás egy előre egyeztetett időpontban történik, átirányításokkal — hogy a keresőben meglévő pozíciók se vesszenek el. --- # Shopify, WooCommerce, Unas vagy egyedi webshop? URL: https://rootcr.hu/tudastar/shopify-woocommerce-unas-vagy-egyedi-webshop/ Frissítve: 2026-08-14 # Shopify, WooCommerce, Unas vagy egyedi webshop? Döntési útmutató > **Röviden:** Ha szabványos terméket árulsz szabványos folyamattal, egy bérelhető rendszer (Shopify, Unas, Shoprenter) a leggyorsabb és legolcsóbb út. Ha sok a testreszabás, de a folyamat még illeszthető, a WooCommerce ad több szabadságot — cserébe karbantartást kér. Egyedi fejlesztés akkor éri meg, ha a rendelési folyamatod eltér a szabványostól: vevőnkénti árazás, minimum rendelés, összetett variánsok, gyártási átfutás. A döntés nem ízlés kérdése, hanem azé, hogy hány kivételed van. ## A kérdés, ami eldönti Nem az, hogy „melyik a legjobb rendszer”. Hanem ez: > Hányszor mondtad már egy fejlesztőnek vagy egy szoftveres kollégának, hogy **„igen, de nálunk ez nem így működik”?** Nulla-egy alkalom: bérelhető rendszer. Kettő-három: WooCommerce vagy alapos rendszerválasztás. Négy vagy több, és mindegyik a rendelési folyamatot érinti: egyedi fejlesztés. ## A négy út ### Bérelhető rendszer (Shopify, Unas, Shoprenter) **Mikor jó:** szabványos termék, darabra rendelés, fix árak, házhoz szállítás. Kis csapat, aki nem akar rendszert üzemeltetni. **Előny:** napok alatt elindul, az üzemeltetés a szolgáltató dolga, a fizetés és a szállítás bekötve érkezik. **Hol a fal:** a havidíj és a tranzakciós jutalék a forgalommal együtt nő; a testreszabás a rendszer keretein belül mozoghat; az adataid és a boltod a szolgáltató platformján élnek. Ha később váltanál, a migráció külön projekt. ### WooCommerce (WordPress) **Mikor jó:** ha van már WordPress-oldalad, a termékkör közepesen összetett, és van, aki karbantartja. **Előny:** nagy szabadság, rengeteg bővítmény, sok fejlesztő ismeri, a rendszer a tiéd. **Hol a fal:** minden kivételhez bővítmény kell, minden bővítményhez karbantartás. A sebesség a bővítmények számával romlik, a kosár és a pénztár pedig nem gyorsítótárazható — erről bővebben: [miért lassú a WordPress webshop](/tudastar/miert-lassu-a-wordpress-webshop/). ### Egyedi fejlesztés **Mikor jó:** ha a rendelési folyamat maga a különbség. Nagykereskedelmi árlisták vevőcsoportonként, minimum rendelési mennyiség, nem lineárisan árazódó variánsok, előrendelés gyártási átfutással, rendelés, ami a termelést is ütemezi. **Előny:** a rendszer a folyamatodat követi, nem fordítva; nincs csomagváltási kényszer és tranzakciós jutalék; a forráskód a tiéd. **Hol a fal:** magasabb belépő ár és hosszabb átfutás. Ha a folyamatod valójában szabványos, ez tiszta veszteség — ezért mondom meg az első beszélgetésen, ha nem ide való a feladat. ### Vegyes út Gyakori és jó megoldás: marad a bérelhető rendszer az értékesítésre, és mellé egyedi kód kerül arra, amit az nem tud — árszinkron, készletkezelés, rendelés utáni folyamat, riport. Ez a [folyamat-automatizálás](/folyamat-automatizalas/) területe, és sokszor a legjobb ár-érték arányú lépés. ## Döntési táblázat | Ha ez igaz | Ajánlott irány | |---|---| | Fix árak, darabra rendelés, néhány tíz termék | Bérelhető rendszer | | Van már WordPress-oldal, közepes termékkör, van karbantartó | WooCommerce | | Vevőcsoportonként eltérő árak | Egyedi | | Termékenkénti minimum rendelési mennyiség | Egyedi | | A variáns nem lineárisan módosítja az árat | Egyedi | | Gyártási átfutás, előrendelés | Egyedi | | A rendelés a termelést is ütemezi | Egyedi | | Kész rendszer jó, de a rendelés utáni folyamat kézi | Vegyes út: automatizálás | | A tranzakciós jutalék már havonta több tízezer forint | Számold ki a megtérülést egyedire | ## Amit érdemes előre végiggondolni - **A migráció ára** mindig több, mint amennyire számítasz — termékadat, vevőadat, rendelési előzmény, URL-átirányítások. - **A keresőben elért pozíciók** átvihetők, de csak akkor, ha valaki kifejezetten foglalkozik az átirányításokkal. - **A termék-strukturált adat** nem díszítés: ettől függ, megjelenik-e a terméked árral és készlettel a találatok között. Erről: [mi az a strukturált adat](/tudastar/mi-az-a-strukturalt-adat/). - **A napi működés** ugyanolyan fontos, mint a vitrin: ha a tulajdonos naponta órákat tölt az adminban, azt az órát vissza lehet adni — [példa](/referenciak/honeyzsu/). ## Gyakori kérdések ### Válthatok később bérelhetőről egyedire? Igen, és ez a gyakori út: a bolt bérelhető rendszerben indul, majd amikor a kivételek száma megnő, egyedi rendszerre költözik. A migrációt előre kell tervezni, nem az utolsó héten. ### Melyik a leggyorsabb? Az, amelyik a legkevesebb fölösleges kódot tölti be — ez rendszer helyett megvalósítás kérdése. Egy jól beállított bérelhető rendszer gyorsabb lehet, mint egy húsz bővítménnyel megpakolt WooCommerce. ### Egyedi rendszernél ki üzemelteti a szervert? Ahogy megállapodunk. Vállalom, de nem kötelező: az átadott rendszer bárhol futtatható, és minden hozzáférés a tiéd. Részletek: [egyedi webshop készítés](/webshop-keszites/). --- # Hogyan véd egy ajánlatkérő űrlap a spam ellen? URL: https://rootcr.hu/tudastar/urlap-spam-vedelem/ Frissítve: 2026-08-14 # Hogyan véd egy ajánlatkérő űrlap a spam ellen? Az öt réteg > **Röviden:** Egy űrlapot nem egy megoldás véd, hanem rétegek sorozata: eredet-ellenőrzés, rejtett csapda-mező, méretkorlát, ember-ellenőrzés és IP-alapú korlátozás. A sorrend számít: elöl az olcsó ellenőrzések állnak, amelyek egy fejléc elolvasásából eldőlnek, hátul a drágák, amelyek külső szolgáltatást hívnak. Így egy támadó nem tud a szervereddel dolgoztatni, és a valódi érdeklődő sem akad fenn. ## Miért nem elég egyetlen megoldás? Mert a támadók sem egyfélék. Az egyszerű kitöltőrobot minden mezőt kitölt és elküld — ezt egy rejtett mező kifogja. A célzott szkript már utánozza a böngészőt — ezt csak ember-ellenőrzés fogja meg. A tömeges próbálkozás pedig nem is a tartalomról szól, hanem arról, hogy a szerveredet lefoglalja. Egy megoldás mindig csak egy támadástípus ellen véd. Amit építeni kell, az nem fal, hanem szűrősor. ## Az öt réteg, sorrendben ### 1. Eredet-ellenőrzés A böngésző minden beküldésnél elárulja, melyik oldalról indult a kérés. Ha nem a saját oldaladról, a szerver elutasítja — még mielőtt bármit kiolvasna az adatokból. **Ára:** egy fejléc összehasonlítása. Gyakorlatilag ingyen. **Mit fog meg:** a máshonnan, közvetlenül a végpontra irányuló beküldést. ### 2. Csapda-mező (honeypot) Egy rejtett mező, amit ember sosem lát és sosem tölt ki — a böngésző elrejti a képernyőről, a billentyűzetes navigációból is ki van véve. Az automata kitöltő viszont a HTML-t olvassa, nem a képernyőt, ezért kitölti. Egy fontos részlet: ha a csapda bejelez, a válasz **legyen „sikeres”.** Ha hibát írsz vissza, a bot fejlesztője megtudja, mi buktatta le, és legközelebb kikerüli. **Ára:** egy mező vizsgálata. Ingyen. **Mit fog meg:** a tömeges kitöltőrobotok nagy részét. ### 3. Méretkorlát A túl nagy kérés-törzs el se érje az alkalmazást: a kiszolgáló szintjén akadjon el. Ez nem a spam ellen véd elsősorban, hanem az ellen, hogy valaki a memóriádat és a sávszélességedet foglalja le. **Ára:** egy beállítás a kiszolgálón. **Mit fog meg:** a terheléses próbálkozást és a hibás kliensek okozta pazarlást. ### 4. Ember-ellenőrzés Itt jön a kép a képbe — vagy pontosabban: ma már nem kell képválogatás. A modern megoldások (például a Cloudflare Turnstile) a böngésző viselkedéséből döntenek, süti nélkül, a látogató zaklatása nélkül. Ez a reCAPTCHA legfontosabb alternatívája, és adatvédelmi szempontból is tisztább. **Ára:** egy hálózati hívás egy külső szolgáltatás felé, időkorláttal. Ez a legdrágább lépés — ezért van hátul. **Mit fog meg:** a böngészőt utánzó, célzott szkripteket. ### 5. IP-alapú korlátozás Címenként korlátozott számú beküldés adott időablakban. Nem a botok fő szűrője, hanem a maradék elleni védelem, és egyben a költséges lépések védelme. **Ára:** memóriában tartott számláló. **Mit fog meg:** az ismétlődő próbálkozást ugyanarról a címről. ## Miért számít a sorrend? Mert minden ellenőrzésnek ára van, és a támadó pont ezt akarja megfizettetni veled. Ha az ember-ellenőrzés (külső hívás) **előbb** fut, mint az IP-korlát, akkor bárki, aki másodpercenként küld egy kérést, kikényszerít másodpercenként egy kimenő hálózati hívást a szerveredről. A védelem lesz a terhelés forrása. A helyes sorrend tehát: **olcsó ellenőrzések elöl, drágák hátul, és a számláló még a drágák előtt.** Ez a különbség az „öt réteget használok” és az „öt réteget jól használok” között. ## Amit még érdemes megcsinálni - **Előbb mentés, aztán levél.** A beérkezett megkeresés kerüljön lemezre, és csak utána menjen az értesítő levél. Ha a levélküldő szolgáltatás kiesik, az érdeklődő akkor sem vész el. - **Riasztás a néma hibára.** Ha a mentés sikerült, de a levél nem ment ki, arról azonnal tudni kell. A legdrágább hiba az, amiről senki nem szól. - **Visszaigazoló levél az érdeklődőnek.** Nem udvariasság: ez zárja le a bizonytalanságot, hogy „vajon megérkezett-e”. - **Megőrzési idő.** A beérkezett megkeresés személyes adat. Legyen határideje, és teljen is le magától. - **Naplózás jelszó és süti nélkül.** Ami nem kell, azt ne is tárold. Így néz ki mindez élesben: [pekarunagyker.hu esettanulmány](/referenciak/pekarunagyker/). ## Gyakori kérdések ### A reCAPTCHA nem elég? Egy réteg önmagában soha nem elég, és a reCAPTCHA a felhasználót is terheli. A süti nélküli, viselkedés-alapú ellenőrzés ma jobb csere — de az is csak egy réteg az ötből. ### Nem fog fennakadni a valódi érdeklődő? Az első három réteg számára a valódi látogató láthatatlan: nem kell tennie semmit. A negyedik réteg jó megvalósítás mellett a legtöbb látogatónak egy kattintás vagy annyi sem. Az ötödik réteg csak akkor jelez, ha valaki órán belül sokadszor küld. ### Ez mennyibe kerül? Ha az űrlap az építés része, akkor semmibe: nálam ez minden [egyedi weboldal](/egyedi-weboldal-keszites/) alapfelszereltsége. Utólag, meglévő rendszerbe építve néhány óra munka. --- # Weboldal készítés árak: mitől függ, és mi a reális? URL: https://rootcr.hu/tudastar/weboldal-keszites-arak/ Frissítve: 2026-08-14 # Weboldal készítés árak: mitől függ, és mi a reális? > **Röviden:** A weboldal árát három dolog mozgatja: hány különböző oldaltípus készül, mennyi egyedi logika van benne (űrlap, kalkulátor, foglalás, rendelés), és hány külső rendszerrel kell összekötni. A sablonoldalak jellemzően 80–150 ezer forintból kihozhatók, az egyedi fejlesztés nálam [100 000 Ft-tól](/arak/) indul, és a legtöbb valódi projekt e fölött van. A legfontosabb kérdés nem az ár, hanem az, hogy két ajánlat ugyanarra vonatkozik-e. ## Miből áll össze egy weboldal ára? Egy ajánlat mögött négy tétel van, akármilyen tagolásban írja le a fejlesztő: 1. **Design.** Sablon átszínezése, vagy erre a cégre készült arculat. Ez a legnagyobb egyszeri különbség két ajánlat között. 2. **Fejlesztés.** Hány különböző oldaltípus (nyitólap, szolgáltatásoldal, referencia, blog, kapcsolat), és mennyi egyedi működés van bennük. 3. **Integráció.** Űrlap, levélküldés, számlázó, foglalás, fizetés, CRM. Minden összekötés külön munka és külön hibalehetőség. 4. **Átadás.** Mérés, dokumentáció, hozzáférés-átadás, betanítás. Az a rész, amit sokan kihagynak — és ezért olcsóbbnak látszanak. ## Mit fedez egy adott összeg? | Nagyságrend | Jellemzően ez fér bele | |---|---| | 80–150 ezer Ft | Sablonoldal, beállítva, saját szöveggel és képekkel. Digitális névjegyre elég. | | 100–400 ezer Ft | Egyedi design és kód, néhány oldaltípus, védett kapcsolatfelvételi űrlap, technikai keresőoptimalizálás, mérési jegyzőkönyv. | | 400 ezer – 1,5 millió Ft | Több oldaltípus, egyedi logika (ajánlatkérő, kalkulátor, foglalás), egy-két integráció, tartalmi struktúra kereséshez. | | 1,5 millió Ft fölött | Webshop egyedi termékmodellel, több rendszer összekötése, admin felület, migráció régi rendszerből. | Ezek nagyságrendek, nem árlista. A pontos összeg a terjedelemtől függ — és onnantól, hogy a terjedelem tisztázott, fix árat lehet rá adni. ## Fix ár vagy óradíj? Két elszámolás létezik, és a különbség nem az ár, hanem az, **ki viseli a becslés kockázatát.** - **Fix ár:** ha a fejlesztő alábecsülte a munkát, az az ő vesztesége. Cserébe az ajánlat előtt pontosan tisztázni kell, mi tartozik bele — ez több kérdést és egy alaposabb egyeztetést jelent. - **Óradíj:** rugalmasabb, cserébe a végösszeg a projekt közepén derül ki. Kutatás jellegű, előre nem körülhatárolható feladatnál ez a helyes forma; kész terjedelmű weboldalnál viszont a megrendelőre tolja a kockázatot. Én weboldalra és webshopra fix áras ajánlatot adok, automatizálásra pedig — mert ott a feladat gyakran menet közben tisztázódik — óradíjas keretet vagy fix árat, a feladat természetétől függően. ## A rejtett költségek Amit az ajánlatok gyakran nem tartalmaznak, de fizetni fogod: - **Tárhely és domain.** Statikus oldalnál havi néhány ezer forint, webshopnál jellemzően tíz-húszezer. Ez a szolgáltató számlája, a te nevedre. - **Fizetős bővítmények éves díja** — sablonrendszereknél tipikusan több tétel. - **Karbantartás.** Frissítések, hibajavítás. Kérdezd meg előre, hogy mi ingyenes és meddig. - **Szövegírás és fotó.** A legtöbb ajánlat ezt nem tartalmazza, közben a projekt csúszásának ez a leggyakoribb oka. - **A késés ára.** Ha az oldal fél évvel később indul, az elmaradt érdeklődő is költség. ## Hogyan hasonlíts össze két ajánlatot? Kérdezd meg mindkét fejlesztőtől ugyanezt a hat kérdést, és a válaszok többet mondanak, mint a végösszeg: 1. **Kié lesz a forráskód és minden hozzáférés az átadás után?** 2. **Fix ár vagy becslés? Ha becslés, mi történik, ha túlfut?** 3. **Mi az, ami az árban NINCS benne?** 4. **Mit mérünk az átadáskor, és kapok-e róla írásos jegyzőkönyvet?** 5. **Milyen rendszerre épül, és hány fejlesztő tudná átvenni?** 6. **Mennyi ideig javítod díjmentesen, ami nem az ajánlat szerint működik?** Ha az egyik ajánlat feleannyi, de ezekre a kérdésekre nincs válasza, akkor nem olcsóbb — hanem kevesebb. ## Hol tartok én? A kiindulási áraim nyilvánosak, és az is nyilvános, mikor mondom azt, hogy ne engem válassz: [árak](/arak/). A döntést a rendszerről pedig itt vezetem végig: [WordPress vagy egyedi weboldal](/tudastar/wordpress-vagy-egyedi-weboldal/). ## Gyakori kérdések ### Miért nem ad senki pontos árat a weboldalára? Mert a „weboldal” szó ötven különböző terjedelmet takar. Ami tisztességesen kirakható, az a kiindulási ár és az, hogy mi mozdítja fölfelé — ez nálam kint van. ### Az olcsó ajánlat mindig rossz? Nem. Ha a feladat tényleg egy sablonoldal, akkor az olcsó ajánlat a helyes ajánlat. A baj akkor van, ha ugyanarra a feladatra kapsz kétszeres különbséget — akkor a kettő nem ugyanazt tartalmazza. ### Mikor kell fizetni? A fizetési ütemezés minden ajánlat része, tehát a megrendelés előtt látod, mikor mit kell fizetni. Ez is azok közé a kérdések közé tartozik, amit érdemes minden ajánlatkérésnél feltenni — ha egy ajánlat nem írja le, kérd, hogy írja le. --- # Mikor éri meg egyedi weboldal a WordPress helyett — és mikor nem? URL: https://rootcr.hu/tudastar/wordpress-vagy-egyedi-weboldal/ Frissítve: 2026-08-14 # Mikor éri meg egyedi weboldal a WordPress helyett — és mikor nem? > **Röviden:** A WordPress jó választás, amíg az oldalad azt csinálja, amit egy átlagos oldal: bemutat, tájékoztat, kapcsolatfelvételi űrlapot kínál. Abban a pillanatban, hogy kivételt kérsz — egyedi rendelésfelvétel, vevőnkénti ár, összekötés a vállalatirányítással —, minden kivétel egy újabb bővítmény, minden bővítmény egy újabb függőség, és a rendszer összköltsége csendben átcsúszik az egyedi fejlesztés fölé. A döntés nem a rendszerről szól, hanem arról, hogy a te folyamatod szabványos-e. ## Mire jó a WordPress, és ezt érdemes kimondani A WordPress a világ weboldalainak jelentős részét kiszolgálja, és ez nem véletlen. Olcsó belépő, rengeteg fejlesztő ismeri, sablonok százezreiből lehet válogatni, és egy blog vagy egy bemutatkozó céges oldal esetében ma is teljesen ésszerű választás. Aki azt mondja, hogy a WordPress „rossz”, az vagy nem használta eleget, vagy el akar adni valamit. A kérdés tehát nem az, hogy a WordPress jó-e. A kérdés az, hogy **a te folyamatod szabványos-e.** ## A három pont, ahol a sablon szorít ### 1. A bővítménylánc Egy sablonoldal ritkán marad egy sablon. Kell hozzá űrlap-bővítmény, gyorsítótár-bővítmény, keresőoptimalizáló bővítmény, biztonsági bővítmény, esetleg többnyelvűsítő és oldalépítő. Ezek egymástól függetlenül frissülnek, és egy frissítés elég, hogy a kosár vagy az űrlap leálljon. A gyakorlati következmény nem technikai, hanem üzleti: **a hibát nem te veszed észre először, hanem a vevő,** aki nem tud rendelni. És a javítás nem nulla forint. ### 2. A sebesség Egy sablon annyi mindent tölt be, amennyit a készítője elképzelt — nem amennyi a te oldaladhoz kell. Az oldalépítő a saját stíluslapját és szkriptjeit hozza, minden bővítmény a magáét. A gyorsítótár-bővítmény ezen tompít, de a plafon adott: a betöltendő kódmennyiséget nem lehet utólag eltüntetni, csak halasztani. Ezt részletesen kibontom itt: [miért lassú a WordPress webshop](/tudastar/miert-lassu-a-wordpress-webshop/). ### 3. A biztonság A feltöltött fájl valódi típusának ellenőrzése, a beküldött adat tisztítása, a visszaélések korlátozása: ez kód, nem kapcsoló. Sablonrendszerben azt kapod, amit a bővítmény gyártója megírt — és azt sem tudod, mit írt meg. Egy nyilvános bővítmény sebezhetősége ráadásul minden telepítést egyszerre érint: a támadónak elég egyszer megtalálnia. ## Számold ki: a sablon rejtett üzemköltsége Az összehasonlítás akkor tisztességes, ha nem a fejlesztési árat veted össze a fejlesztési árral, hanem a **hároméves teljes költséget.** A képlet: ``` sablon 3 éves költsége = fejlesztés + (fizetős bővítmények éves díja × 3) + (karbantartás és hibajavítás éves óraszáma × óradíj × 3) + az elmaradt bevétel a leállások és a lassúság miatt ``` Az utolsó tétel a legnehezebben becsülhető és a legnagyobb. Ha nem tudod megbecsülni, hagyd ki — a többi tétel is elég ahhoz, hogy a különbség kiderüljön. A tanulság a legtöbb esetben ugyanaz: **a sablon nem olcsóbb, hanem később fizetteti ki magát.** ## Döntési táblázat | Ha ez igaz rád | Akkor | |---|---| | Az oldal bemutat, tájékoztat, van rajta egy kapcsolati űrlap | Maradj sablonon, és költs inkább szövegre és fotóra | | Blogot vezetsz, gyakran publikálsz, több szerző dolgozik | A WordPress erre kifejezetten jó | | A látogatóból érdeklődőt kell csinálni, és ezt mérni akarod | Határeset — egyedi űrlap és mérés sablon fölé is építhető | | Rendelést veszel fel, ami nem „darab × ár” | Egyedi fejlesztés | | Vevőnként eltérő árakat vagy minimum mennyiséget kezelsz | Egyedi fejlesztés | | Össze kell kötni a számlázóval, raktárral, vállalatirányítással | Egyedi fejlesztés vagy [automatizálás](/folyamat-automatizalas/) | | Már most is havonta fizetsz azért, hogy valaki „megjavítsa” az oldalt | Számold ki a hároméves költséget, mielőtt újra fizetsz | ## Mit vihetsz át, ha váltasz? Ez a leggyakoribb félelem, és a legkevésbé indokolt. Váltásnál átvihető: - **A tartalom.** Szöveg, kép, termékadat — ezek exportálhatók. - **A Google-helyezések.** A régi címekről átirányítás megy az újakra, így az eddig megszerzett pozíciók nem vesznek el. Ez a váltás legfontosabb technikai lépése, és ha valaki kihagyja, az látszik a forgalmon. - **A domain, az e-mail, az analitika.** Ezek nem a rendszerhez tartoznak. Amit nem viszel át: a bővítmények beállításait — de pont azoktól akartál szabadulni. ## A rossz ok a váltásra Ne azért válts, mert valaki azt mondta, hogy „a WordPress lassú”. Válts azért, mert **név szerint meg tudod nevezni azt a három dolgot, amit a mostani rendszered nem tud,** és amiért havonta fizetsz — időben vagy pénzben. Ha ezt a három dolgot nem tudod felsorolni, a váltás nem oldja meg a problémát, csak elhalasztja. ## Gyakori kérdések ### Mennyivel drágább az egyedi fejlesztés? A belépő magasabb: nálam [100 000 Ft-tól](/arak/) indul egy egyedi weboldal, míg egy sablonoldal 80–150 ezerből kihozható. A különbség a hároméves üzemköltségen múlik, nem a kezdő számlán. ### Nem lesz nehezebb karbantartani egy egyedi oldalt? Fordítva szokott lenni. Egy egyedi oldalon nincs harminc idegen függőség, ami magától frissül alattad. Ami van, azt egyvalaki írta, és dokumentálva van. ### Mi van, ha az egyedi fejlesztő eltűnik? Ezért kell forráskódot, dokumentációt és teljes hozzáférést kapnod az átadáskor, és ezért érdemes bevett technológiát választani. Ha ezek megvannak, bármelyik fejlesztő folytatni tudja — ez a különbség egy egyedi rendszer és egy „csak ő érti” rendszer között. ### Meg lehet menteni a meglévő oldalt? Sokszor igen. Előbb átnézem a kódot, és megmondom, javítani vagy újraírni éri-e meg: [félbehagyott weboldal átvétele](/tudastar/felbehagyott-weboldal-atvetele/). --- # Egyedi webshop készítés URL: https://rootcr.hu/webshop-keszites/ Frissítve: 2026-08-14 # Egyedi webshop készítés — ha a folyamatod nem fér bele a sablonba > **Röviden:** Egyedi webshopot akkor éri meg fejlesztetni, ha a rendelési folyamatod eltér a szabványostól: egyedi árazás vevőnként, minimum rendelési mennyiség, összetett variánsok, gyártási átfutás, vagy olyan integráció, amire nincs kész bővítmény. A RootCR-nél az egyedi webshop 400 000 Ft-tól indul, fix áras ajánlattal, jellemzően 6–10 hét alatt készül el; a fizetés és a számlázás bekötve, a forráskód a tiéd. ## Előbb az őszinte rész: mikor jobb a kész rendszer? Ha szabványos terméket árulsz szabványos folyamattal — fix árak, darabra rendelés, házhoz szállítás —, akkor egy jól beállított Shopify, WooCommerce vagy hazai bérelhető rendszer olcsóbb és gyorsabb lesz. Ezt az első beszélgetésen megmondom, és nem vállalom el a projektet csak azért, mert elvállalható. A választást döntési táblával végigvezetem itt: [Shopify, WooCommerce, Unas vagy egyedi webshop](/tudastar/shopify-woocommerce-unas-vagy-egyedi-webshop/). Egyedi fejlesztésre akkor van szükséged, ha a fenti mondatra már legalább egyszer azt mondtad egy fejlesztőnek: „igen, de nálunk ez nem így működik”. Nagykereskedelmi árlisták vevőcsoportonként. Minimum rendelési mennyiség termékenként. Variánsok, amik az árat nem lineárisan módosítják. Előrendelés gyártási átfutással. Rendelésfelvétel, ami a termelést is ütemezi. Ezekre a kész rendszerekben bővítményt keresel, a bővítményhez másik bővítményt, és két év múlva a kivételek foltozása kerül többe, mint amennyibe az egyedi rendszer került volna. ## Mit kapsz egy egyedi webshopban? - **Egyedi termék-adatmodell.** A terméked úgy kerül a rendszerbe, ahogy a valóságban létezik: méretekkel, variánsokkal, minimum mennyiséggel, vevőnkénti árazással — nem három szabványmezőbe gyömöszölve. - **Saját kosár- és rendelési logika.** A rendelési folyamat a te működésedet követi, beleértve azt is, ami a rendelés *után* történik: visszaigazolás, gyártásba adás, szállítási értesítés. - **Fizetés és számlázás bekötve.** Bankkártyás fizetés és a számlázód (például Számlázz.hu, Billingo) összekötése — a rendelésből emberi kéz érintése nélkül lesz számla. A konkrét fizetési szolgáltatót az ajánlat rögzíti. - **Admin felület, amit tényleg használni fogsz.** Nem egy általános motor ezer menüpontja, hanem a te öt napi műveleted, öt kattintásra. Tömeges műveletekhez parancssori eszközt is kapsz — így néz ki ez a gyakorlatban a [honeyzsu.hu webshopnál](/referenciak/honeyzsu/). - **Termék-strukturált adat.** A termékeid árral és készletinformációval jelenhetnek meg a Google találataiban és az AI-válaszokban. - **Mérhető átadás.** Sebesség- és indexeltség-mérés jegyzőkönyvvel, hogy lásd, mit kaptál. ## Mennyibe kerül, és miből áll össze az ár? A kiindulási ár 400 000 Ft (nettó). Fölfelé a terjedelem mozdítja: a termék-adatmodell bonyolultsága, az integrációk száma (fizetés, számlázás, raktár, futár), az admin felület mélysége. Az ajánlatban minden tétel külön szerepel, az ár fix, nem óradíjas becslés. Részletek és tipikus projektméretek: [webshop készítés árak](/arak/). ## Mi történik a rendelés után? A webshop nem a fizetés gombnál ér véget. A rendelés utáni út — visszaigazolás, gyártásba adás, készletmozgás, számla, szállítási értesítés — pontosan az a szakasz, ahol a kész rendszerek megszorulnak, és ahol a legtöbb kézi munka keletkezik. Ezt a részt [folyamat-automatizálásként](/folyamat-automatizalas/) építem meg, sokszor ugyanabban a projektben. ## Gyakori kérdések ### Meglévő webshopot át tudsz venni? Igen — előbb átnézem a kódot, és megmondom, javítani vagy újraírni éri-e meg. Őszinte választ kapsz akkor is, ha az a válasz, hogy maradj a mostani rendszernél. ### Mi van, ha nő a forgalom? Az egyedi rendszer a te szervereden fut, és úgy skálázódik, ahogy a forgalmad kívánja — nincs csomagváltási kényszer és nincs tranzakciós jutalék. ### Kié a kód és az adat? A tiéd. Teljes forráskód, adatbázis, hozzáférések — átadva, dokumentálva. Nincs vendor lock-in: bármelyik fejlesztő folytatni tudja. ### Mennyi az átfutás? Jellemzően 6–10 hét, az ajánlatban fix dátummal. A leggyakoribb csúszási ok a hiányzó termékadat — ehhez az első héten kapsz bekérő listát. ### Miért lassú a mostani WooCommerce webshopom? Jellemzően nem egyetlen ok van, hanem a bővítmények által betöltött kód mennyisége és az adatbázis-lekérdezések száma. Meddig lehet gyorsítani és honnan kell újraépíteni: [miért lassú a WordPress webshop](/tudastar/miert-lassu-a-wordpress-webshop/).