# 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.

- **Eredeti HTML oldal:** [https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-seo-schema-idopontfoglalo-platform](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-seo-schema-idopontfoglalo-platform)
- **AI tartalmi térkép:** [llms.txt](https://weboldal-berles.hu/llms.txt)

- **Megjelenés:** 2026-08-28
- **Kategória:** Weboldal bérlés
- **Szerző:** Szabó Balázs
- **Címkék:** adatvédelem, AEO és GEO, Google Naptár, időpontfoglaló, strukturált adatok, technikai SEO, webfejlesztés, weboldal bérlés

A [sorozat első részében](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-berles-rendszerarchitektura) a közös MVC-alapú, multi-tenant alkalmazásmagot néztük meg. A [második részben](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-teljesitmeny-core-web-vitals-rum) 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](https://weboldal-berles.hu) 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](https://weboldal-berles.hu) 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](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-teljesitmeny-core-web-vitals-rum)