pekarunagyker.hu — B2B oldal, ahol az ajánlatkérés a termék
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
- 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.
- 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.
- 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.
- 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.
- 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.
Külön oldal minden vevőtípusnak
Egy nagykereskedésnél nem egyforma vevő keres rá. Az étterem heti kiszállítást keres, a bolt polcra való pékárut, egy intézmény közétkeztetési mennyiséget, egy rendezvényszervező pedig egyszeri, nagy tételt. Ugyanaz a mondat mind a négynek rossz.
Ezért mindegyik szándék saját lapot kapott, saját szöveggel és saját gyakori kérdésekkel: beszállítás vendéglátóhelyeknek, boltoknak, intézményeknek, rendezvényre, valamint a kiszállítási területről és a nagykereskedelmi kínálatról szóló lapok. Ez nem tartalomduplázás: a keresőt címek szerint rangsorolja, nem szekciók szerint, és a látogató sem akar átgörgetni három olyan bekezdést, ami nem róla szól.
Az árak nem nyilvánosak, mert vevőcsoportonként eltérnek — ez üzleti döntés. A gépi réteg ettől még nem üres: a strukturált adat kimondja, kinek szól az ajánlat, milyen területen és mekkora mennyiségtől, ajánlatkérésre. Így a kereső és a nyelvi modellek pontosan azt tudják az oldalról, amit egy telefonáló megkérdezne, anélkül hogy árat kellene közölni.
Ami mérve van, és amit szándékosan nem mérünk
Az oldalon nincs forgalommérő szolgáltatás, nincs süti és nincs külső szkript. Egyetlen dolog van mérve: az ajánlatkérés hibaállapotai.
Ennek konkrét oka van. Ha az ember-ellenőrzés egy régebbi telefonon elakad, az ajánlatkérés a látogató szemszögéből egyszerűen „nem történik meg" — és erről senki nem szerez tudomást, mert a kérés a szerverhez el sem jut, tehát a naplóban sincs nyoma. A hibát ilyenkor a kimaradó bevétel jelzi, hetekkel később.
A mérés ezért sütimentes és azonosító nélküli: egy sor kerül a naplóba eseményenként — időbélyeg, esemény neve, hibaok, útvonal. Nem tárolódik IP-cím, böngészőazonosító vagy hivatkozó. Ennyi elég ahhoz, hogy egy elakadás napokon belül kiderüljön, és semmivel sem több.
Gépi olvasásra szánt réteg
Minden lapnak van gépi változata, plusz az oldalnak llms.txt és llms-full.txt összefoglalója, valamint hírcsatornája — mind ugyanabból a forrásból generálva, amiből a látható oldal épül. Nincs külön karbantartott másolat, tehát a két változat nem tud széttartani: ha egy szállítási feltétel módosul, mindkét helyen módosul.
Az eredmény
| Mit | Mennyi | Forrás |
|---|---|---|
| Saját forráskód | 6 998 sor | a projekt forrása, 2026-09-12 |
| Vevőtípusonkénti landolóoldal | 6 | pekarunagyker.hu/sitemap.xml |
| Védelmi réteg az ajánlatkérőn | 5, mind szerveroldali | a forráskód |
| Spam a beérkezett megkeresések közt | 0 | a megrendelő adatközlése, 2026. augusztus |
| Süti és külső mérőszkript | 0 | az oldal forrása |
| Megvásárolt űrlap- vagy oldalépítő bővítmény | 0 | a forráskód |
Ellenőrizd magad
- pekarunagyker.hu — az élő oldal; az ajánlatkérő űrlap kipróbálható.
- pekarunagyker.hu/llms.txt — a gépi olvasásra szánt összefoglaló.
- 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 — 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. 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.