GEO a TYPO3-hoz: Ahol a tanácsadás és a fejlesztés találkozik

A Generative Engine Optimisation, gyakori rövidítéssel GEO, sokszor új marketingdiszciplínaként jelenik meg. A jellemző ajánlások a tartalomra összpontosítanak: válaszolj meg több kérdést, rendszerezd világosabban az információt, és tegyél közzé olyan anyagot, amelyet az MI-alapú keresőrendszerek megértenek és idézni tudnak.

Mindez fontos, de a problémának csak egy részét fedi le.

Mielőtt a ChatGPT, a Gemini, a Google AI Mode vagy egy másik rendszer felhasználhatná egy webhely információit, hozzá kell férnie a tartalomhoz, azonosítania kell, mit jelentenek az információk, és meg kell értenie, hogyan viszonyulnak egymáshoz a cégek, személyek, termékek, szolgáltatások és helyszínek.

Egy összetett TYPO3-webhelyen ezek a kérdések nem válaszolhatók meg pusztán tartalomoptimalizálással. Olyan szemantikai koncepciót igényelnek, amely a webhely architektúráját és adatmodelljét is tükrözi.

Itt találkozik a tanácsadás és a fejlesztés.

A tanácsadónak meg kell értenie, mit jelentenek az ügyfél információi. A fejlesztőnek meg kell értenie, hogyan jeleníti meg, frissíti és szolgálja ki ezeket az információkat a TYPO3. Sok esetben ez nem két különálló fázis. A koncepciót és a megvalósítást kéz a kézben kell kidolgozni.

Az ügynökségek számára ez lehetőséget teremt arra, hogy az ügyfeleknek egy SEO-ellenőrzőlistánál többet kínáljanak. Ugyanakkor igényt is teremt olyan technikai partnerek iránt, akik részt tudnak venni az elemzésben, ahelyett hogy egy kész specifikációra várnának.

A GEO nem váltja ki a technikai SEO-t

A GEO-t néha teljesen új, saját szabályokkal rendelkező diszciplínaként írják le. A gyakorlatban sok eleme ismerős SEO-alapokra épül.

A Google kijelenti, hogy a bevált SEO-gyakorlatok továbbra is relevánsak az AI Overviews és az AI Mode számára. Egy oldalnak továbbra is elérhetőnek, indexelhetőnek és a Google Keresésre alkalmasnak kell lennie, mielőtt ezeknél a generatív funkcióknál szóba jöhetne. Nincs olyan speciális jelölés, amely garantálná a bekerülést egy MI által generált válaszba.^[1]

Ez a megkülönböztetés fontos, amikor a GEO-ról beszélünk az ügyfelekkel. Egy ügynökség nem ígérheti felelősen, hogy egy adott MI-rendszer ajánlani fog egy céget vagy idézni fog egy adott oldalt. Amit tehetünk, az a technikai és szemantikai alap javítása, amelyen ezek a rendszerek értelmezik a webhelyet.

A munka ezért továbbra is ismerős kérdésekkel kezdődik:

• Hozzáférnek-e a crawlerek a releváns oldalakhoz?
• Indexelhető-e a szánt tartalom?
• Helyesen vannak-e konfigurálva a kanonikus URL-ek és a nyelvi változatok?
• Elérhető-e a fontos információ a renderelt HTML-ben?
• Következetesen jelenik-e meg a cég, a termékei, szolgáltatásai, szakértői és helyszínei?
• Pontos maradhat-e a megvalósítás, miközben a tartalom változik?

Egy tisztázatlan oldalstruktúrájú, ellentmondásos információkat vagy hozzáférhetetlen tartalmat tartalmazó webhely nem lesz MI-kész attól, hogy hozzáadunk egy llms.txt fájlt vagy telepítünk még egy kiterjesztést.

A crawlerhozzáférés üzleti döntés

A technikai hozzáférés a GEO első rétege, de a döntés már régóta nem korlátozódik arra, hogy engedélyezzük vagy blokkoljuk a Googlebotot.

A különböző szolgáltatók eltérő crawlereket használhatnak a kereséshez, a modellképzéshez és a felhasználó által kiváltott hozzáféréshez. Az OpenAI például megkülönbözteti az OAI-SearchBotot, amely a ChatGPT keresést támogatja, a GPTBotot, amely a modellképzéshez kapcsolódik, és a ChatGPT-Usert, amely felhasználói kérésre férhet hozzá egy oldalhoz. Ezek a vezérlők egymástól függetlenek.^[2]

Egy általános szabály, amely minden MI-crawlert blokkol, ezért olyan következményekkel járhat, amelyeket az ügyfél nem szándékozott. Egy cég szeretné korlátozni a képzési célú felhasználást, miközben felfedezhető marad az MI-alapú keresésben.

Ez nem olyan döntés, amelyet a fejlesztőknek csendben, a robots.txt szerkesztése közben kellene meghozniuk. Beszélgetést igényel az ügyféllel a tartalom szándékolt felhasználásáról, majd egy technikailag helyes megvalósítást.

Egy TYPO3-projekt esetében általában a következőket vizsgáljuk:

• robots.txt és robots meta utasítások;
• CDN- és web application firewall-szabályok;
• HTTP-szintű botvédelem;
• kanonikus URL-ek;
• átirányítások és státuszkódok;
• XML-sitemapek;
• nyelvspecifikus URL-ek és hreflang;
• JavaScripten keresztül renderelt tartalom;
• staging-, archív és örökölt domainek;
• lejárt rekordok, amelyek indexelhetők maradnak.

A TYPO3 már most jó technikai alapot nyújt. A rendszer SEO-kiterjesztése támogatja a kanonikus URL-eket, a robots utasításokat, a metaadatokat és az XML-sitemapeket.^[3]

A fejlesztői feladat nem pusztán ezeknek a funkcióknak az aktiválása. A projekt oldalaihoz, nyelveihez, kiterjesztéseihez és a tartalom életciklusához igazítva kell konfigurálni őket.

A gépeknek több explicit kontextusra van szükségük

Egy emberi látogató sokat képes kikövetkeztetni a navigációból, a designból és a képekből. Egy gép, amely egy elszigetelt szövegrészletet dolgoz fel, esetleg nem rendelkezik ugyanezzel a kontextussal.

Egy oldal hivatkozhat „az upgrade-szolgáltatásunkra”, miközben a környező webhely egyértelművé teszi, hogy a cég TYPO3-upgrade-eket kínál digitális ügynökségek számára. Ha a részletet külön kérik le, a szolgáltató, a technológia és a célügyfél már nem biztos, hogy egyértelmű.

A fontos információnak ezért az oldal teljes vizuális kontextusán kívül is érthetőnek kell maradnia:

• Melyik szervezet nyújtja a szolgáltatást?
• Milyen technológiát, terméket vagy iparágat érint?
• Kinek szánják?
• Hol érhető el a szolgáltatás?
• Milyen tapasztalat támasztja alá az állítást?
• Ki írta vagy ellenőrizte az információt?
• Mikor ellenőrizték utoljára?

Ez nem azt jelenti, hogy természetellenesen ismételgetjük a kulcsszavakat. Azt jelenti, hogy a releváns entitásokat és kapcsolatokat elég világosan ábrázoljuk ahhoz, hogy emberek és gépek egyaránt értelmezni tudják őket.

Egy TYPO3-webhelyen ezek az entitások esetleg már léteznek domain-rekordokként. Más projektekben lehet, hogy általános tartalmi elemekbe ágyazódnak, vagy több kiterjesztés között oszlanak meg. Mielőtt a strukturált adatok megbízhatóan előállíthatók lennének, meg kell értenünk, milyen információ létezik, és melyik forrás legyen a mérvadó.

Ehhez tanácsadásra és technikai elemzésre egyaránt szükség van.

A strukturált adat nem tagek listája

A strukturált adat, amelyet jellemzően JSON-LD formában, a Schema.org szókészletével valósítanak meg, segíthet a gépeknek azonosítani, mit ábrázol egy oldal. Leírhat szervezeteket, személyeket, cikkeket, termékeket, ajánlatokat, szolgáltatásokat, eseményeket, helyszíneket és sok más entitást.

A nehéz rész nem a JSON-LD szintaxis előállítása. A nehéz rész annak eldöntése, mit kell ábrázolni, és hogyan viszonyulnak egymáshoz az entitások.

Egy oldal több érvényes sématípust is tartalmazhat anélkül, hogy koherens leírást adna a mögöttes üzletről. Fordítva, egy technikailag helyes megvalósítás félrevezetővé válhat, ha a strukturált adat már nincs szinkronban a látható tartalommal.

A Google megköveteli, hogy a strukturált adat megfeleljen annak az információnak, amelyet a látogatók látnak.^[4]

A sématípus kiválasztása ezért nem kezelhető tisztán szerkesztői döntésként, a megvalósítás pedig nem redukálható egy fejlesztői jegyre. A koncepciónak tükröznie kell az információ szemantikai jelentését és azt is, hogyan viselkedik az adat a TYPO3-on belül.

Mit ad hozzá a Yoast SEO for TYPO3

A Yoast SEO for TYPO3 hasznos része lehet ennek a felállásnak, különösen a szerkesztői munkához.

Integrálja a tartalomelemzést a TYPO3-backendbe, és segíti a szerkesztőket az oldalcímek, leírások, fókuszkifejezések és az olvashatóság szempontjainak áttekintésében. Nagyobb szerkesztői csapatok esetében ez javíthatja a konzisztenciát, és könnyebben felismerhetővé teszi a hiányos optimalizálási munkát.^[5]

A Yoast egy alapszintű strukturáltadat-megvalósítást is nyújt. A standard kimenete tartalmazza a WebSite és a BreadcrumbList típusokat, míg a provider-alapú architektúrája konfiguráción keresztül bővíthető.^[6]

Ezek hasznos építőelemek, de nem adnak teljes GEO-koncepciót.

A Yoast nem tudhatja, mit jelent egy képzési program az ügyfél szervezetében, hogyan viszonyul egy járműajánlat egy helyszínhez, vagy melyik TYPO3-rekord egy szolgáltatásleírás mérvadó forrása. Nem tudja eldönteni, hogy két vizuálisan hasonló oldal ugyanazt a szemantikai entitást képviseli-e.

A Yoastot ezért szerkesztői és technikai alapnak tekintjük. A projektspecifikus modell továbbra is elemzést, tanácsadást és fejlesztést igényel.

Strukturált adat kiválasztása egy egyetem számára

Egy partnerügynökséggel közösen választottuk ki a megfelelő elsődleges és támogató Schema.org-típusokat egy egyetemi webhelyhez.

Első pillantásra a feladat megközelíthető lett volna úgy, hogy minden oldalkategóriához hozzárendelünk egy sématípust. A gyakorlatban a munka az egyetem információs architektúrájának részletesebb megértését igényelte.

A webhely különböző fogalmakat tartalmazott: magát az intézményt, képzési programok gyűjteményeit, egyes programokat, tanácsadási információkat, eseményeket, valamint fizikai vagy virtuális helyszíneket. Némelyik oldal hasonló elrendezést használt, mégsem ugyanazt képviselte.

Egy fontos megkülönböztetés a programáttekintés és az egyes képzési programok között volt.

A több programot tartalmazó áttekintés CollectionPage-ként ábrázolható egy ItemList segítségével. A részletoldal egy adott programot képvisel, és helyette EducationalOccupationalProgram-ként írható le, az intézményhez, egy képesítéshez, egy ajánlathoz vagy támogató dokumentumokhoz fűződő kapcsolatokkal.

A különbség inkább szemantikai, mint vizuális. Felismerése tanácsadást igényel: valakinek értenie kell a tartalmat, a felhasználói utat és a mögöttes információ jelentését.

Ennek a megkülönböztetésnek megbízható TYPO3-megvalósítássá alakítása fejlesztői feladat. A megvalósításnak azonosítania kell, honnan származnak a programadatok, hogyan tartják karban a kapcsolatokat, és hogyan generálódik a végső JSON-LD.

Hasonló megkülönböztetéssel találkoztunk a fizikai és az online egyetemi események között. Mindkettő eseményként ábrázolható, de egy fizikai nyílt nap egy Place-re utalhat, míg egy online tájékoztató egy VirtualLocation-t igényel.

Ezek a példák a koncepciónak csak egy kiválasztott részét mutatják be. A teljes leképezés további oldalkategóriákat és az ügyfélnek átadott projektspecifikus szabályokat is tartalmazott. A fontos tanulság nem a sématípusok végső listája, hanem a kiválasztásukhoz használt folyamat.

Figyelembe vettük a tágabb Schema.org-szókészlet és a Google által jelenleg megjelenített strukturáltadat-funkciók közötti különbséget is. Egy típus hasznos szemantikát fejezhet ki anélkül, hogy külön rich resultot eredményezne. A rich result-támogatás ezért releváns volt, de nem az egyetlen ok egy sématípus kiválasztására vagy elvetésére.^[7]

Hivatkozott Schema.org-típusok:CollegeOrUniversity · CollectionPage · ItemList · EducationalOccupationalProgram · Event · Place · VirtualLocation

Egy járműértékesítő portál modellezése

Egy másik projektben tanácsadóként támogattunk egy partnerügynökséget egy járműértékesítő portál strukturáltadat-stratégiájának meghatározásában.

Itt az információ már erősen strukturált volt. Minden jármű sok műszaki jellemzőt tartalmazott, de egy hirdetés csak rövid ideig maradhatott elérhető. A modellnek részletesen le kellett írnia a járművet, miközben konzisztens maradt a változó árakkal és elérhetőséggel.

A választott megközelítés több szempontot kombinált:

• Organization vagy egy megfelelő LocalBusiness-altípus a cég és helyszínei számára;
• Vehicle a járműspecifikus tulajdonságokhoz;
• Product és Offer a kereskedelmi ajánlathoz, beleértve az árat és az elérhetőséget;
• Service a cég kapcsolódó szolgáltatásaihoz.

Egyetlen sématípus sem írta le a teljes helyzetet.

A Vehicle azt fejezte ki, mi volt a tétel. A Product és az Offer azt a tényt képviselte, hogy egy adott jármű meghatározott kereskedelmi feltételek mellett elérhető volt. Az eladó, a helyszínei és a kapcsolódó szolgáltatások különálló entitások voltak, amelyeket össze kellett kapcsolni anélkül, hogy tévesen összeolvasztották volna őket.

E kapcsolatok kiválasztása a szemantikai különbségeik megértését igényelte. Pontosan tartásuk az alkalmazás és annak adatáramlásainak megértését igényelte.

Egy járműportál esetében a frissesség ugyanolyan fontos, mint a teljesség. Egy JSON-LD blokk szintaktikailag érvényes maradhat, miközben olyan információt jelenít meg, amely már nem igaz. Ha egy járművet eladtak, a látható hirdetés, annak elérhetősége, a sitemap és bármely gyorsítótárazott strukturált adat nem mondhat ellent egymásnak.

Ez további megvalósítási kérdéseket vetett fel:

• Melyik rendszer mérvadó az elérhetőség és az ár tekintetében?
• Milyen gyorsan tükröződnek a változások a webhelyen?
• Mi történik az URL-lel, ha egy járművet eladnak?
• Mikor kell eltávolítani az XML-sitemapből?
• Elavulhat-e a gyorsítótárazott strukturált adat?
• Hogyan validálható a kimenet a sablon- vagy integrációs változtatások után?

A Google felhasználhatja a Product és Offer strukturált adatokat olyan információk megértéséhez, mint az ár és az elérhetőség. A helyes jelölés jogosultságot teremthet bizonyos keresési megjelenésekre, de nem garantálja, hogy a Google meg is jeleníti őket.^[8]

Hivatkozott Schema.org-típusok:Organization · LocalBusiness · Vehicle · Product · Offer · Service

Ez a projekt különösen világosan mutatta meg, miért nem választható el a GEO az alkalmazásfejlesztéstől. A strukturált adat nem egy sablon statikus kiegészítése volt. A gyorsan változó üzleti adatok egy másik reprezentációja volt.

Ahol a tanácsadás és a fejlesztés találkozik

A strukturáltadat-projekteket gyakran két elszigetelt fázisra osztják. Egy tanácsadó összeállít egy listát az ajánlott sématípusokról, majd később egy fejlesztőt kérnek meg a megvalósításukra.

Egyszerű webhelyek esetében ez elegendő lehet. Összetett TYPO3-projektek esetében nem hisszük, hogy ez adja a legjobb eredményt.

A megvalósítási döntések már a koncepcionális munka során elkezdődnek.

A megfelelő sémák kiválasztásához a csapatnak értenie kell az elérhető típusok közötti szemantikai különbségeket. Ugyanakkor tudnia kell, hogyan tárolódik az ügyfél információja, melyik rendszer birtokolja, milyen gyakran változik, és milyen kapcsolatokat tud a TYPO3 megbízhatóan generálni.

Egy programáttekintés és egy egyes program hasonlónak tűnhet, de nem ugyanazt jelentik. Egy jármű nem ugyanaz az entitás, mint a kereskedelmi ajánlat, amely alatt eladják. Egy szervezet nem azonos az egyik helyszínével. Egy fizikai eseményhelyszín különbözik egy virtuálistól.

E különbségek felismerése a tanácsadói munka része. Rekordokra, integrációkra és frontend-kimenetre való leképezésük a fejlesztői munka része. A végső koncepció csak akkor válik megbízhatóvá, ha ezeket a nézőpontokat együtt dolgozzák ki.

Egy partnerügynökség számára ez nem jelenti az ügyfélkapcsolat vagy a stratégiai szerep feladását. Ott tudunk bekapcsolódni az elemzésbe, ahol speciális TYPO3- és szemantikai tudásra van szükség, hozzá tudunk járulni az ügyféllel folytatott megbeszélésekhez, és a megállapodott koncepciót olyan megvalósítássá tudjuk fordítani, amely illeszkedik a meglévő rendszerhez.

A látható kimenet végül talán egy JSON-LD blokk lesz. A valódi érték a mögötte álló döntésekben és adatkapcsolatokban rejlik.

Hogyan közelítsenek az ügynökségek egy TYPO3 GEO-projektet

Amikor egy ügyfél arra kér egy ügynökséget, hogy „adjon GEO-t” egy TYPO3-webhelyhez, az első eredmény ne egy általános Schema.org-típuslista legyen.

A jelölés kiválasztása előtt az ügynökségnek meg kell értenie, mit képviselnek az ügyfél információi, és hogyan léteznek a rendszeren belül. Minden releváns entitás esetében a projektnek tisztáznia kell:

• melyik TYPO3-rekord vagy külső rendszer a mérvadó forrás;
• strukturált-e az információ, vagy szerkesztői tartalomba ágyazódik;
• hogyan viszonyulnak egymáshoz az entitások oldalakon és kiterjesztéseken át;
• hogyan hatnak a nyelvi és site-változatok ezekre a kapcsolatokra;
• mi történjen, ha a rekordok megváltoznak, lejárnak vagy eltűnnek;
• hogyan validálják a generált kimenetet;
• mit vár az ügyfél a GEO-tól, és mely eredmények nem garantálhatók.

Ezek a kérdések gyakran feltárják, hogy a szemantikai koncepció és a technikai architektúra nem tervezhető egymástól függetlenül.

Ha egy szolgáltatást több oldalon külön tartanak karban, előfordulhat, hogy nincs megbízható forrás egy konzisztens Service-entitáshoz. Ha egy helyszín csak formázott szövegként létezik egy tartalmi elemen belül, nem kapcsolható megbízhatóan a szervezethez, az eseményekhez és az ajánlatokhoz. Ha a jármű elérhetőségét egy külső rendszerből importálják, a strukturált adatnak ugyanazt a frissítési ciklust kell követnie, ahelyett hogy egy külön karbantartott TYPO3-mezőre támaszkodna.

A megoldás nem feltétlenül igényli a teljes tartalommodell újjáépítését. Sok projektben néhány gondosan kiválasztott strukturális változtatás is elég. A cél az, hogy megbízható forrást hozzunk létre a fontos információknak, és csak azokat a kapcsolatokat alakítsuk ki, amelyek pontosan tarthatók.

Egy sémaleképezés lehet ennek az elemzésnek az egyik eredménye, de még nem megvalósítási koncepció. A koncepciónak azt is el kell magyaráznia, honnan származik az információ, hogyan alakítja a TYPO3 látható és gépileg olvasható kimenetté, és hogyan marad mindkét reprezentáció konzisztens, amikor a mögöttes adat változik.

Ezért szeretünk már a koncepcionális fázisban bekapcsolódni egy GEO-projektbe. A partnerügynökséggel közösen meg tudjuk érteni az ügyfél igényeit, meg tudjuk kérdőjelezni vagy finomítani a szemantikai modellt, és közvetlenül egy karbantartható TYPO3-megvalósítássá tudjuk fordítani.

Ha az egyik ügyfeled GEO-ról, strukturált adatról vagy az MI-alapú keresésben való láthatóságról kérdez, még azelőtt be tudunk kapcsolódni a projektbe, hogy a technikai specifikáció rögzülne. Az ügynökség megtartja az ügyfélkapcsolatát, miközben szakosodott partnert nyer azon a területen, ahol a szemantikai tanácsadás és a TYPO3-fejlesztés átfedésbe kerül.

Források

1. Google Search Central — AI features and your website. developers.google.com/search/docs/appearance/ai-features↩
2. OpenAI — Overview of OpenAI crawlers. platform.openai.com/docs/bots↩
3. TYPO3 Documentation — SEO features (EXT:seo). docs.typo3.org — cms-seo Features↩
4. Google Search Central — Structured data general guidelines. developers.google.com — sd-policies↩
5. TYPO3 Documentation — Yoast SEO for TYPO3. docs.typo3.org — yoast_seo↩
6. Yoast SEO for TYPO3 — Structured data configuration. docs.typo3.org — Yoast StructuredData↩
7. Google Search Central — Structured data markup that Google Search supports. developers.google.com — search-gallery↩
8. Google Search Central — Product (Product, Review, Offer) structured data. developers.google.com — product↩