Mi van a motorháztető alatt? #3 - A canonicaltól a foglalási engine-ig: platformszolgáltatások a Weboldal Bérlésben
A frontend csak a Weboldal Bérlés látható rétege. A háttérben canonical URL-ek, sitemap és robots.txt, JSON-LD strukturált adatok, llms.txt és Markdown-kimenetek, consent, űrlapvédelem, Blog, valamint Google Naptárral összekapcsolható időpontfoglalási logika dolgozik ugyanazon tenant- és szolgáltatási rétegekre építve.
A sorozat első részében a közös MVC-alapú, multi-tenant alkalmazásmagot néztük meg. A második részben a responsive képektől az LCP-n és CLS-en át a saját RUM-ig jutottunk.
A harmadik, záró részben azokat a szolgáltatásokat vesszük elő, amelyek miatt a Weboldal Bérlés technikailag több egy HTML-t renderelő oldalépítőnél. A platformnak ugyanúgy része a canonical és a JSON-LD, mint a consent állapot, a blog szerzői adatmodellje vagy az a döntési folyamat, amely eldönti, hogy egy időpont valóban foglalható-e.
A frontend csak a platform egyik kimenete
Egy publikus oldal requestjének végén természetesen HTML kerül a böngészőbe, de ugyanabból a tenant- és tartalmi állapotból több más gépi kimenet is készülhet. A keresőrobot, az AI-agent, a közösségi megosztó és a normál böngésző nem feltétlenül ugyanazt a reprezentációt használja, miközben mindegyiknek ugyanarról a vállalkozásról és ugyanarról az oldalról kell konzisztens információt kapnia.
A fontos elv: a canonical, a schema, a sitemap vagy az llms.txt ne külön-külön karbantartott szöveg legyen, hanem ugyanannak a tenant- és tartalommodellnek más-más kimenete.
| Platformréteg | Publikus kimenet | Feladata |
|---|---|---|
| URL és meta | canonical, title, description, Open Graph | Az oldal elsődleges URL-jének és megosztási metaadatainak következetes meghatározása. |
| Strukturált adat | JSON-LD | A vállalkozás, szolgáltatás, oldal, szerző vagy blogcikk entitásainak géppel értelmezhető leírása. |
| Keresőrobot-fájlok | sitemap.xml, robots.txt | A publikus URL-ek feltérképezésének és robotutasításoknak a támogatása. |
| AI-barát kimenet | llms.txt, llms-full.txt, Markdown | Kiegészítő, géppel könnyen áttekinthető tartalmi térkép és oldalreprezentáció. |
| Blogmodell | BlogPosting, FAQPage, szerzők, citation | A cikk ne csak HTML legyen, hanem önálló tartalmi entitás saját metaadatokkal. |
Canonical: egy oldalhoz legyen egy elsődleges URL
Multi-tenant környezetben a canonical kezelés különösen fontos. Ugyanaz az alkalmazáskód technikai útvonalon, saját domainen, blogroute-on és különböző belső linkeken keresztül is előállíthat tartalmat. A publikus kimenetnek viszont tudnia kell, melyik az a cím, amelyet az adott tenant elsődleges URL-jének tekintünk.
A Weboldal Bérlésnél a canonical domain nem csak a HTML sorára hat. Ugyanehhez kell igazodnia többek között a sitemapnek, a blogcikkek saját URL-jeinek, a strukturált adatok @id és URL hivatkozásainak, valamint a gépi tartalmi kimenetek belső linkjeinek is.
Ezért domainváltás vagy canonical módosítás után nem elég egyetlen meta taget átírni: az automatikusan generált SEO asseteknek is ugyanazt az aktuális domainállapotot kell követniük.
A schema nálunk entitásmodell, nem SEO-dekoráció
A strukturált adat akkor hasznos, ha ugyanazt állítja a vállalkozásról, amit az oldal látható tartalma is. A rendszer ezért profil alapján tud eltérő fő entitást használni. Egy általános szolgáltatói oldalnál ez lehet Organization, helyi vállalkozásnál LocalBusiness, személyes szakértői profilnál Person, bizonyos szolgáltatói profiloknál pedig ProfessionalService is megjelenhet.
A fő entitás mellé kapcsolódhat WebSite, WebPage és Service. A lényeg nem a schema-típusok számának növelése, hanem hogy az entitások ugyanazokra az URL-ekre, nevekre, szolgáltatásokra és kapcsolati adatokra hivatkozzanak.
A blog külön réteg: az önálló cikk BlogPosting adatot kaphat szerzőkkel, publikálási és módosítási dátummal, képpel és opcionális citation hivatkozásokkal. Ha a cikkhez natív GYIK van bekapcsolva, a látható accordion és a FAQPage schema ugyanabból az aktív kérdés-válasz listából épül.
Sitemap, robots.txt, llms.txt és Markdown: ugyanaz a tartalom több gépi nézetben
A sitemap és a robots.txt klasszikus webes infrastruktúra. A sitemap a publikus útvonalak feltérképezését segíti, a robots.txt pedig többek között a sitemap helyét is jelölheti. Blog használatakor a publikált cikkek, illetve a rendszer logikája szerint releváns blogoldalak is bekerülhetnek a generált URL-készletbe.
Az llms.txt és az oldalankénti Markdown-kimenet más célt szolgál. Ezeket nem kezeljük „titkos SEO rangsorolási fájlként”. Kiegészítő, géppel könnyen olvasható reprezentációk, amelyek egy AI-agent vagy más automatizált kliens számára áttekinthetőbb tartalmi térképet adhatnak. A HTML továbbra is az elsődleges publikus oldal, a canonical pedig ugyanúgy érvényes marad.
A rendszer ezért az llms.txt kapcsolatát és az adott oldal Markdown-párját is jelezheti a HTML headben. Így a különböző reprezentációk nem egymással versengenek, hanem ugyanahhoz az elsődleges oldalhoz kapcsolódnak.
A Blog nem egy nagy HTML mező
A cikk törzse természetesen formázott HTML, de a blogmodell ennél több adatot tart nyilván. A cikknek saját slugja, canonical URL-je, SEO címe és leírása, kategóriája, címkéi, szerzői, publikálási állapota, dátumai, képei, GYIK-je és opcionális forráslistája lehet.
Ez azért fontos, mert ugyanazokat az adatokat több réteg is felhasználja. A szerző megjelenik a cikkoldalon és a strukturált adatban; a kategória és címke navigációt és listázást ad; az aktív GYIK egyszerre publikus tartalom és schema; a cikk dátumai pedig a frontend mellett a BlogPosting és a sitemap lastmod szempontjából is relevánsak.
Vagyis a szerkesztőben látható cikk csak egy nézet az adatmodell felett. Ez a különbség aközött, hogy „van egy HTML oldalunk”, vagy van egy tartalomkezelési rétegünk.
Consent és űrlapok: az állapotnak már az első rendernél számítania kell
A statisztikai vagy marketing mérés nem indulhat úgy, mintha a felhasználó már hozzájárult volna. A consent réteg ezért szükséges, funkcionális, statisztikai és marketing kategóriákat különít el, és a Google Consent Mode alapállapotát is a tárolt hozzájárulás szerint állítja.
A teljesítmény szempontjából ennek van egy másik oldala is: a banner első állapotának és kritikus CSS-ének már korán ismertnek kell lennie, különben a későn megjelenő felület layout shiftet okozhat. Emiatt a consent egyszerre adatvédelmi és renderelési kérdés.
A publikus űrlapoknál ugyanez a „platformszolgáltatás” szemlélet jelenik meg más formában: validáció, adatvédelmi elfogadás és – ahol aktív – reCAPTCHA spamvédelem ugyanabban a közös infrastruktúrában használható a kapcsolati, hírlevél- vagy időpontfoglalási folyamatoknál.
Az Időpontfoglaló valójában egy ütközéskezelő engine
Egy időpontválasztó felületet könnyű naptárként elképzelni, technikailag azonban a fontos rész az, hogy mikor szabad egyáltalán felajánlani egy idősávot. A válasz nem egyetlen adatbázis-lekérdezésből jön.
A foglalhatóságot a szolgáltatás időtartama, a heti munkaidő, a kivételek, a minimum és maximum előrefoglalás, az időpont-lépésköz, az előtte és utána alkalmazott buffer, a napi és e-mailhez kötött limitek, valamint a már létező foglalások együtt határozzák meg. Google Naptár kapcsolat esetén ehhez hozzáadódhat a kiválasztott naptár freeBusy foglaltsága is.
| Ellenőrzési réteg | Mit vizsgál? | Mit akadályoz meg? |
|---|---|---|
| Szolgáltatás | Időtartam, típus, aktív állapot | Érvénytelen vagy rossz hosszúságú slot felajánlását. |
| Munkaidő és kivétel | Heti szabályok, zárt vagy egyedi napok | Munkaidőn kívüli foglalást. |
| Foglalási szabályok | Lépésköz, előrefoglalás, napi limit, buffer | Túl közeli, túl távoli vagy egymásra torlódó időpontokat. |
| Belső foglalások | Meglévő aktív időpontok és átfedések | Dupla foglalást a saját adatbázison belül. |
| Google freeBusy | A kiválasztott külső naptár foglalt intervallumai | Olyan időpont felajánlását, amikor a naptárban már más program van. |
| Mentési ütközésvédelem | A slot állapota közvetlenül a beküldéskor | Azt, hogy két közel egyszerre érkező kérés ugyanazt az időpontot megszerezze. |
A publikus naptár tehát csak a döntés eredményét mutatja. Maga a döntési logika a szerveren marad, és ugyanazokat a szabályokat kell követnie az admin diagnosztikának és a frontend foglalhatóságnak is.
Google Naptár: olvasunk és írunk is, de nem vak tükrözéssel
A Google Naptár integráció OAuth kapcsolaton keresztül működik. Az ügyfél kiválaszthatja a használni kívánt naptárt; a rendszer pedig a beállításoktól függően eseményt hozhat létre vagy frissíthet a weboldali foglaláshoz, lemondáskor kezelheti a kapcsolódó Google eseményt, online szolgáltatásnál pedig Google Meet linket is létrehozhat.
A másik irány a freeBusy: itt nem a weboldali foglalást írjuk Google-be, hanem a már létező Google programokat vesszük figyelembe a szabad időpont számításakor. Ez az a rész, amely megakadályozza, hogy a weboldal foglalhatónak mutasson egy idősávot, miközben ugyanakkor már szerepel egy másik esemény a naptárban.
Az incremental sync syncToken segítségével a Google oldali változásokat is tudja követni. Ha egy kapcsolt eseményt kívül módosítanak vagy törölnek, a rendszer ezt naplózhatja és a foglalásnál külső változásként megjelölheti. Ez szándékosan nem „vak kétirányú másolás”: a saját foglalási adatmodell és a külső naptár szerepe külön marad.
A háttérben cronok, naplók és állapotellenőrzések dolgoznak
Amint egy platform külső API-val, e-maillel vagy generált SEO assetekkel dolgozik, már nem minden történik ugyanabban a HTTP requestben. Vannak feladatok, amelyek időzítetten vagy háttérfolyamatban futnak: ilyen lehet SEO assetek újragenerálása, Google Calendar incremental sync vagy különböző rendszerállapotok ellenőrzése.
Ezért önmagában az nem elegendő, hogy „van cron”. Tudni kell azt is, mikor futott utoljára, sikeres volt-e, milyen tenantot érintett, és hol maradt hibanapló. A superadmin rétegben ezek az integrációs és rendszerállapot-adatok azért fontosak, mert egy külső API hibája nem ugyanaz a problémakategória, mint egy publikus PHP vagy renderelési hiba.
A közös core itt válik valódi platformmá
A három cikkben végig ugyanoda jutottunk vissza. A multi-tenant architektúra önmagában csak szerkezeti döntés. Akkor válik értékessé, ha a közös rétegekben megoldott funkciók ténylegesen minden érintett weboldal számára következetesen használhatók.
- egy canonical javítás nem egyetlen oldal sablonjában él;
- egy schema-fejlesztés ugyanabból az üzleti és tartalmi adatból dolgozik;
- a responsive kép- és LCP-logika nem cikkenként külön beállítás;
- a consent és a spamvédelem közös infrastruktúra;
- a Blog saját tartalommodellel rendelkezik;
- az Időpontfoglaló ugyanahhoz a tenant-, e-mail-, feature- és üzemeltetési környezethez kapcsolódik;
- a release-ek pedig migrációkkal, verziózással és regressziós tesztekkel vihetők át a közös core-on.
Ez a „motorháztető” lényege: a felhasználó egy weboldalt lát, de mögötte egymással összekapcsolt, közösen verziózott szolgáltatási rétegek dolgoznak.
A sorozat végén
A Weboldal Bérlés technikai felépítését három nézőpontból bontottuk szét: először az MVC és multi-tenant architektúrát, utána a performance- és RUM-réteget, végül a SEO-, tartalom-, consent- és foglalási platformszolgáltatásokat.
A rendszer természetesen ettől még nem „kész”. Egy saját platform egyik előnye éppen az, hogy a közös core tovább fejleszthető anélkül, hogy minden ügyféloldalt külön projektként kellene újraépíteni. A másik oldala viszont ugyanilyen fontos: egy közös módosításnál a regressziós tesztelés, a kompatibilitás és a kontrollált release-folyamat nem opcionális.
Vagyis ugyanaz a tulajdonság, amely gyorsabbá teszi a központi fejlesztést, nagyobb felelősséget is jelent a kiadásnál. Nálunk ez nem külön folyamat a platform mellett - ez is a platform része.
#2 - A képfeldolgozástól a RUM-ig: performance a Weboldal Bérlésben
GYIK
Gyakran ismételt kérdések a Weboldal Bérlés platformszolgáltatásairól
Technikai válaszok a canonical, schema, llms.txt, Blog, consent és Google Naptárral integrált időpontfoglalás működéséről.
Nem automatikus AI- vagy Google-helyezést jelent. A rendszer olyan technikai alapokat ad, mint a következetes canonical URL-ek, strukturált adatok, szerzői és szolgáltatási entitások, sitemap, robots.txt, gépbarát tartalmi kimenetek és jól strukturált publikus HTML. A tényleges láthatósághoz továbbra is jó tartalom, hitelesség és relevancia szükséges.
A két elem más feladatot végez. A sitemap a publikus URL-ek feltérképezését segíti, a canonical pedig azt jelzi, hogy egy tartalom elsődleges URL-je melyik cím. Multi-tenant és saját domaines környezetben különösen fontos, hogy a metaadatok, a schema és a generált gépi fájlok ugyanahhoz a kanonikus domainhez igazodjanak.
Kiegészítő, géppel könnyen feldolgozható tartalmi reprezentációk. Nem helyettesítik a HTML-t, a sitemapet vagy a klasszikus SEO-t, és nem kezeljük őket önálló rangsorolási tényezőként. Arra alkalmasak, hogy AI-agentek és automatizált kliensek strukturáltabban lássák az oldal fontos tartalmait és hivatkozásait.
A BlogPosting a cikk saját metaadataiból épül: többek között cím, canonical URL, szerzők, publikálási és módosítási dátum, valamint elérhető kép használható hozzá. Ha a cikk-GYIK aktív, a rendszer ugyanabból az aktív kérdés-válasz listából készíti a látható GYIK blokkot és a FAQPage strukturált adatot.
A weboldali foglalhatóság számításakor a saját munkaidő-, kivétel-, buffer- és foglalási szabályok mellett a kiválasztott Google Naptár freeBusy foglalt intervallumai is figyelembe vehetők. Így egy Google-ben már foglalt időszak nem kerül ki szabad weboldali időpontként.
Az incremental sync sync tokenekkel követheti a külső változásokat. Egy kapcsolt esemény módosítása vagy törlése naplózható és a foglalásnál külső változásként megjelölhető. A rendszer nem vakon írja felül a saját foglalási adatmodellt, hanem elkülöníti a weboldali foglalás és a külső naptár állapotát.