Schema markup: teljes útmutató

A schema markup a schema.org szókészletére épülő jelölés, amellyel a weboldal forráskódjában géppel olvasható módon leírod, mi szerepel az oldalon: egy cég, egy üzlet, egy termék, egy cikk vagy egy kérdés-válasz blokk. A gyakorlatban JSON-LD kódként kerül az oldalba, típusokból és tulajdonságokból áll, és csak akkor ér valamit, ha pontosan egyezik a látható tartalommal és hibátlanul validál.

Alapfogalmak

A schema.org egy közös szókészlet, amelyet a nagy keresőmotorok együtt indítottak el, és amelyet ma nyílt közösségi folyamat fejleszt. Ez a szókészlet nem formátum és nem program, hanem egy szótár: megmondja, milyen dolgokat lehet leírni (ezek a típusok), és az egyes dolgoknak milyen jellemzői lehetnek (ezek a tulajdonságok). A schema markup ennek a szótárnak az alkalmazása egy konkrét oldalon. Amikor valaki azt mondja, hogy "tegyünk schemát a termékoldalra", valójában azt kéri, hogy a termékoldal kódjába kerüljön egy olyan leírás, amely a schema.org Product típusát és annak tulajdonságait használja.

Érdemes elválasztani a szókészletet a leírás módjától. A strukturált adat általános fogalmáról és a különféle formátumokról külön útmutató szól, ez a cikk a gyakorlati oldalra koncentrál: melyik típust mikor használd, hogyan épül fel egy jó JSON-LD blokk, hogyan kötöd össze az entitásokat, és hogyan kerül mindez egy CMS-be vagy sablonba. A Google a három elterjedt jelölési mód közül a JSON-LD-t ajánlja, mert a HTML-től elkülönülve, egyetlen szkriptblokkban él, így könnyebb karbantartani.

Típus, tulajdonság, érték

A schema.org három építőeleme minden jelölésben visszaköszön. A típus (@type) azt mondja meg, milyen dologról van szó, például Organization, LocalBusiness, Product vagy Article. A tulajdonság egy jellemző neve, például name, address, price vagy datePublished. Az érték lehet egyszerű szöveg, szám, dátum, URL, vagy egy újabb típus, amelynek saját tulajdonságai vannak. Ez utóbbi a beágyazás, és ettől lesz a schema markup több egy egyszerű kulcs-érték listánál.

A típusok hierarchiába rendeződnek. A legfelső szinten a Thing áll, alatta például a CreativeWork, az Organization, a Place vagy a Product. A LocalBusiness egyszerre leszármazottja az Organization és a Place típusnak, ezért örökli mindkettő tulajdonságait: lehet neve és logója, mint egy cégnek, és lehet címe és nyitvatartása, mint egy helynek. A hierarchia gyakorlati haszna, hogy mindig a legszűkebb, mégis pontos típust érdemes választani. Egy fodrászatnál a HairSalon pontosabb, mint a LocalBusiness, egy blogbejegyzésnél a BlogPosting pontosabb, mint az Article.

A leggyakrabban használt típusok

Típus	Mire való	Tipikus oldal
Organization	A cég vagy szervezet azonosítása: név, logó, elérhetőség, közösségi profilok	Főoldal, Rólunk oldal
LocalBusiness és altípusai	Fizikai címmel rendelkező vállalkozás: cím, nyitvatartás, telefonszám, földrajzi koordináták	Üzlet- vagy telephelyoldal
Product és Offer	Termék adatai és az ajánlat: ár, pénznem, elérhetőség	Termékoldal
Article, BlogPosting, NewsArticle	Szerkesztői tartalom: cím, szerző, megjelenési és módosítási dátum, kép	Blogcikk, hír
BreadcrumbList	Az oldal helye a webhely hierarchiájában	Szinte minden aloldal
FAQPage	Az oldalon látható kérdések és válaszok	GYIK oldal vagy szekció
WebSite és WebPage	A webhely és az adott oldal mint entitás, a többi jelölés kapcsolódási pontja	Minden oldal
Person	Szerző, alapító, szakértő	Szerzői oldal, cikkek szerzője

A táblázat nem teljes lista, a schema.org több száz típust tartalmaz. A gyakorlatban azonban egy átlagos céges webhely vagy webshop jelölési igényének nagy részét ez a nyolc típus lefedi. Aki ezeket jól és következetesen használja, már előrébb jár, mint az a webhely, amely tucatnyi típust rak ki hiányosan.

Hogyan működik?

A schema markup működése három lépésben írható le. Először a jelölés bekerül az oldal HTML-jébe, JSON-LD esetén egy script type="application/ld+json" blokkba, amely a head vagy a body részben is állhat. Másodszor a kereső feltérképező robotja letölti az oldalt, és a HTML feldolgozása közben kiolvassa ezt a blokkot is. Harmadszor a kereső értelmezi a típusokat és tulajdonságokat, összeveti őket az oldal látható tartalmával, és eldönti, hogy felhasználja-e őket, például egy bővített találati megjelenéshez.

Fontos, hogy a jelölés nem parancs, hanem javaslat. A Google saját dokumentációja szerint a helyes jelölés sem garantálja, hogy bővített találat jelenik meg. A kereső a jelölést jelzésként kezeli, amely segít megérteni az oldalt, de a megjelenítésről a saját szempontjai szerint dönt. Ezért rossz stratégia a schema markupot trükknek tekinteni, és jó stratégia pontos, hiánytalan leírásnak.

Egy egyszerű JSON-LD blokk felépítése

Az alábbi példa egy kitalált cég Organization jelölése. A kulcsok a schema.org tulajdonságnevei, az értékek a cég adatai.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.pelda.hu/#organization",
  "name": "Példa Kft.",
  "url": "https://www.pelda.hu/",
  "logo": "https://www.pelda.hu/kepek/logo.png",
  "telephone": "+36 1 000 0000",
  "sameAs": [
    "https://www.facebook.com/peldakft",
    "https://www.linkedin.com/company/peldakft"
  ]
}
</script>

Az @context mondja meg, hogy a kulcsokat a schema.org szókészlete szerint kell értelmezni. Az @type a típus, az @id pedig egy egyedi azonosító, amely erre az entitásra mutat. Az @id nem kell, hogy megnyitható oldal legyen, csak egy stabil, egyedi URI, a bevett gyakorlat a saját domain egy horgonnyal kiegészítve, például a főoldal címe és utána #organization. A sameAs a cég hivatalos profiljait sorolja fel, ez segít a keresőnek összekapcsolni a webhelyet a más helyeken szereplő ugyanazon céggel.

Beágyazás és @id hivatkozás

Az entitások kétféleképpen kapcsolhatók össze. Az egyik a beágyazás: egy tulajdonság értéke maga egy teljes objektum, például egy Product offers tulajdonságában ott áll az Offer az árral és az elérhetőséggel. A másik a hivatkozás: a tulajdonság értéke csak egy objektum, amelyben egyedül az @id szerepel, és ez az azonosító egy máshol, akár ugyanazon az oldalon egy másik blokkban teljes egészében leírt entitásra mutat.

A hivatkozás akkor hasznos, ha ugyanaz az entitás több helyen szerepel. A cég egyszerre kiadója a cikknek, eladója a terméknek és tulajdonosa a webhelynek. Ha mindhárom helyre beágyazva bemásolnád a teljes Organization leírást, az adatok előbb-utóbb eltérnének egymástól. Ha viszont egyszer írod le egy stabil @id-vel, és mindenhol csak erre hivatkozol, egyetlen forrásból dolgozol. Az összetartozó entitásokat egy @graph tömbbe is gyűjtheted, így egy oldalon egyetlen szkriptblokk tartalmazza az egész, egymásra hivatkozó hálót.

Fő módszerek

A schema markup bevezetésének három fő útja van, és a legtöbb webhelyen ezek keverednek. Az első a kézzel írt vagy sablonba égetett JSON-LD, a második a CMS-bővítmények és beépített funkciók használata, a harmadik a címkekezelőn keresztüli beillesztés. Mindegyiknek megvan a helye, de nem mindegy, melyik típust melyik módszerrel kezeled.

Kézi jelölés és sablonszintű generálás

A legnagyobb kontrollt az adja, ha a JSON-LD-t a sablon állítja elő az oldal saját adataiból. Egy termékoldal sablonja ugyanabból az adatbázismezőből tölti ki a látható árat és a jelölés price tulajdonságát, így a kettő nem tud eltérni. Ez a módszer fejlesztői munkát igényel, cserébe pontos, és a webhely növekedésével sem romlik. Egyedi fejlesztésű oldalaknál és nagyobb webshopoknál ez a javasolt alap.

Az alábbi példa egy termékoldal jelölése, amelyben az ajánlat beágyazva, az eladó cég pedig @id hivatkozással szerepel.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://www.pelda.hu/termek/kavedaralo-k2/#product",
  "name": "K2 kézi kávédaráló",
  "image": "https://www.pelda.hu/kepek/k2-kavedaralo.jpg",
  "description": "Kerámia őrlőtárcsás kézi kávédaráló, állítható őrlési finomsággal.",
  "sku": "K2-001",
  "brand": { "@type": "Brand", "name": "Példa" },
  "offers": {
    "@type": "Offer",
    "url": "https://www.pelda.hu/termek/kavedaralo-k2/",
    "price": "12990",
    "priceCurrency": "HUF",
    "availability": "https://schema.org/InStock",
    "seller": { "@id": "https://www.pelda.hu/#organization" }
  }
}
</script>

Az ár ponttal elválasztott számként, pénznemjel nélkül szerepel, a pénznem külön tulajdonságba kerül ISO kóddal. Az availability értéke egy schema.org által definiált URL, nem szabad szöveg. Az sku és a brand nem kötelező, de segíti a termék egyértelmű azonosítását. A kép abszolút URL-lel szerepel, relatív út helyett.

Ugyanezen az oldalon a morzsamenü jelölése egy külön BreadcrumbList blokk. A position a sorrendet adja, az utolsó elem az aktuális oldal, amelynél az item elhagyható.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Főoldal", "item": "https://www.pelda.hu/" },
    { "@type": "ListItem", "position": 2, "name": "Kávédarálók", "item": "https://www.pelda.hu/kavedaralok/" },
    { "@type": "ListItem", "position": 3, "name": "K2 kézi kávédaráló" }
  ]
}
</script>

A morzsamenü jelölését ugyanaz a sablonlogika állítsa elő, amely a látható morzsamenüt rajzolja, így ha a kategóriastruktúra változik, a jelölés automatikusan követi. Ha egy termék több kategóriában is szerepel, a jelölés azt az utat mutassa, amelyet a látogató az oldalon lát.

CMS-bővítmények és beépített funkciók

WordPressen a népszerű SEO-bővítmények többsége automatikusan előállít alapjelölést: WebSite, WebPage, Organization vagy Person, cikkeknél Article, és gyakran BreadcrumbList. A webshopmotorok, például a WooCommerce, a termékoldalakra Product jelölést tesznek. A Shopify témák egy része szintén tartalmaz termékjelölést. Ez gyors indulást ad, de két kockázatot hordoz. Az egyik a duplikáció: ha a téma és egy bővítmény is kirak Product jelölést, két, egymásnak részben ellentmondó blokk kerül az oldalra. A másik a hiányosság: az automatikus jelölés csak azt tudja kitölteni, ami az adatmodellben megvan, a cég sameAs profiljait vagy a telephely nyitvatartását neked kell megadnod a beállításokban.

A bővítményes úton ezért az első lépés mindig egy leltár: mit rak ki a téma, mit a SEO-bővítmény, mit a webshopmotor, és mit egy esetleges külön schema-bővítmény. A leltár után egy típusért egyetlen forrás feleljen, a többit kapcsold ki.

Címkekezelő és egyedi blokkok

A Google Tag Manageren keresztül is beilleszthető JSON-LD, és a Google dokumentációja szerint a JavaScripttel generált jelölést is fel tudja dolgozni, ha az oldal renderelése után a kódban megjelenik. Ez azonban lassabb és törékenyebb út: a jelölés a renderelésen múlik, és a címkekezelőben élő adatok könnyen elválnak az oldal valós tartalmától. Kisebb, ritkán változó blokkokra, például egy statikus Organization jelölésre vészmegoldásként elfogadható, termékárakra és készletre nem ajánlott.

Döntési szabály: melyik módszer melyik típushoz

Típus	Ajánlott forrás	Indok
Organization, WebSite	Egyszer, központilag (bővítmény-beállítás vagy globális sablon)	Ritkán változik, minden oldal erre hivatkozik
LocalBusiness	Telephelyoldal sablonja, adatbázisból	Több telephelynél mindegyik saját oldalt és saját @id-t kap
Product, Offer	Termékoldal sablonja, ugyanabból a mezőből, mint a látható ár	Az ár és a készlet gyakran változik, eltérés nem megengedett
Article, BlogPosting	SEO-bővítmény vagy cikksablon	A dátumok és a szerző a CMS-ben már megvannak
BreadcrumbList	Ugyanaz a logika, amely a látható morzsamenüt rajzolja	A kettő így mindig egyezik
FAQPage	Csak ott, ahol a kérdések és válaszok láthatóan az oldalon vannak	Rejtett tartalomhoz jelölést tenni irányelvsértés

Gyakori hibák

A schema markup hibái két csoportra oszlanak. Az egyik a technikai hiba, amelyet egy validátor azonnal jelez: hibás JSON szintaxis, rossz típusnév, hiányzó kötelező tulajdonság. A másik a tartalmi hiba, amely szintaktikailag hibátlan, mégis gondot okoz: a jelölés mást állít, mint amit a látogató lát, vagy olyan típust használ, amely nem illik az oldalhoz. A második csoport a veszélyesebb, mert a validátor zölden jelez, a probléma mégis ott van.

Technikai hibák

Szintaktikai hiba a JSON-ban: egy felesleges vessző az utolsó elem után, egy hiányzó idézőjel vagy egy nem escapelt idézőjel a szövegben az egész blokkot olvashatatlanná teszi. Ha a leírás mezőbe a CMS nyers szöveget illeszt, a benne lévő idézőjel a leggyakoribb bűnös.
Elírt típus- vagy tulajdonságnév: a schema.org kis- és nagybetűérzékeny, a localbusiness vagy a DatePublished nem létező nevek.
Rossz értékformátum: az ár "12 990 Ft" formában, a dátum magyar formátumban, a nyitvatartás szövegként. A dátumoknak ISO 8601 formátumban kell lenniük, az árnak pedig számnak.
Relatív URL-ek: a képek, a logó és az @id értékek legyenek abszolút címek.
Duplikált blokkok: téma és bővítmény egyszerre jelöl, ezért két Product vagy két Organization kerül az oldalra, eltérő adatokkal.

Tartalmi és irányelvbeli hibák

A Google irányelvei szerint a jelölésnek az oldal látható tartalmát kell leírnia. Ha a jelölésben szereplő ár, értékelés vagy kérdés-válasz nem jelenik meg a látogatónak, az nemcsak félrevezető, hanem kézi intézkedést is vonhat maga után. Tipikus példa, amikor egy cikkoldalra valaki FAQPage jelölést tesz olyan kérdésekkel, amelyek sehol nem olvashatók, vagy amikor a termékjelölés egy régi akciós árat mutat, miközben az oldalon már a teljes ár szerepel.

Gyakori hiba a helytelen típusválasztás is. Egy szolgáltatásoldal nem Product, egy kategóriaoldal nem egyetlen termék, és egy cég minden aloldala nem LocalBusiness. A LocalBusiness jelölés oda tartozik, ahol a telephely adatai valóban szerepelnek, jellemzően a kapcsolat vagy a telephely oldalán, míg az Organization a teljes cégre vonatkozik. Szintén hiba, ha a saját cégre vonatkozó értékeléseket saját oldalon jelölik meg olyan módon, amelyet a Google irányelvei kifejezetten kizárnak a bővített megjelenésből.

Karbantartási hibák

A harmadik, sokszor elfelejtett hibaforrás az idő. A jelölés egyszer elkészül, aztán a cég költözik, új telefonszámot kap, megszűnik egy közösségi profil, vagy egy sablonfrissítés után eltűnik egy tulajdonság. Ha a jelölést senki nem ellenőrzi rendszeresen, a keresőnek adott leírás lassan elavul. Ezért a jelölés a tartalomkezelési folyamat része legyen, ne egyszeri projekt.

Mérés

A schema markup mérése két szinten zajlik: a jelölés helyességének ellenőrzése, és a hatásának követése. Az első objektív és azonnal elvégezhető, a második lassabb, és óvatos értelmezést igényel, mert a bővített megjelenésről a kereső dönt, és a kattintásokat sok más tényező is befolyásolja.

Validálás

Két eszközt érdemes párban használni. A Google Rich Results Test (bővített találatok tesztje) azt mutatja meg, hogy az oldal jelölése alkalmas-e a Google által támogatott bővített megjelenésekre, és melyik kötelező vagy ajánlott tulajdonság hiányzik. A Schema Markup Validator (validator.schema.org) általánosabb: a teljes schema.org szókészlethez méri a jelölést, azokat a típusokat is ellenőrzi, amelyekhez a Google nem kínál külön megjelenést. Az egyik a Google-specifikus alkalmasságot, a másik a szókészlet szerinti helyességet nézi.

Mindkét eszköz élő URL-lel és beillesztett kóddal is használható. A beillesztett kódos mód a staging és fejlesztés alatt hasznos, az élő URL-es mód pedig élesítés után, mert akkor azt látod, amit a kereső is lekér, beleértve a JavaScripttel generált jelölést.

Search Console jelentések

A Search Console a támogatott bővített találattípusokhoz külön jelentéseket ad, például termékekhez, morzsamenühöz vagy videókhoz. Ezek az érvényes, a figyelmeztetéssel rendelkező és az érvénytelen elemek számát mutatják, és felsorolják az érintett URL-eket. A jelentés azért értékes, mert nem egyetlen oldalt néz, hanem a teljes feltérképezett állományt, így egy sablonhiba itt tömegesen jelenik meg. A teljesítményjelentésben a keresési megjelenés szerinti bontás megmutatja, hogy a bővített megjelenésű találatok hány kattintást és megjelenést hoztak.

Ellenőrzőlista élesítés előtt és után

Ellenőrzés	Eszköz	Elvárt eredmény
Szintaxis	Schema Markup Validator, beillesztett kóddal	Nulla hiba
Google-alkalmasság	Rich Results Test, sablontípusonként egy URL	Érvényes elem, kötelező tulajdonság nem hiányzik
Duplikáció	Forráskód, keresés az application/ld+json kifejezésre	Típusonként egy forrás
Egyezés a látható tartalommal	Kézi szúrópróba: ár, név, dátum, kérdések	Minden érték szerepel az oldalon is
@id konzisztencia	Két-három oldal jelölésének összevetése	Ugyanaz az entitás mindenhol ugyanazt az @id-t kapja
Tömeges állapot	Search Console bővített találat jelentések	Az érvénytelen elemek száma nem nő

Kidolgozott példa: egy helyi vállalkozás jelölése lépésről lépésre

Az alábbi eset szemléltető, kitalált forgatókönyv, a munkafolyamatot mutatja, nem valós mérést. Egy budapesti fodrászat kétoldalas webhelyén eddig semmilyen jelölés nem volt. A munkát öt lépésben végeztük el. Első lépésben összegyűjtöttük a forrásadatokat egy táblázatba: hivatalos név, cím, telefonszám, nyitvatartás, logó URL, közösségi profilok. Ez a lépés fontosabb, mint a kód, mert minden későbbi hiba innen ered. Második lépésben kiválasztottuk a típust: a HairSalon, amely a LocalBusiness altípusa, így az Organization és a Place tulajdonságait is örökli.

Harmadik lépésben megírtuk a JSON-LD-t egy @graph tömbben, a WebSite, a HairSalon és a kapcsolatoldal WebPage entitásával, egymásra @id-vel hivatkozva. Negyedik lépésben beillesztett kóddal validáltunk, és a Schema Markup Validator jelezte, hogy a nyitvatartásban a napok nevét magyarul írtuk, ezért a szókészlet szerinti angol napnevekre cseréltük. Ötödik lépésben élesítettük a kódot a sablon láblécében, majd élő URL-lel újra teszteltük. A kész jelölés lényegi része így néz ki:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://www.fodraszpelda.hu/#website",
      "url": "https://www.fodraszpelda.hu/",
      "name": "Fodrász Példa",
      "publisher": { "@id": "https://www.fodraszpelda.hu/#business" }
    },
    {
      "@type": "HairSalon",
      "@id": "https://www.fodraszpelda.hu/#business",
      "name": "Fodrász Példa",
      "url": "https://www.fodraszpelda.hu/",
      "logo": "https://www.fodraszpelda.hu/logo.png",
      "telephone": "+36 1 000 0000",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Példa utca 1.",
        "addressLocality": "Budapest",
        "postalCode": "1000",
        "addressCountry": "HU"
      },
      "openingHoursSpecification": [
        {
          "@type": "OpeningHoursSpecification",
          "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
          "opens": "09:00",
          "closes": "18:00"
        }
      ]
    },
    {
      "@type": "WebPage",
      "@id": "https://www.fodraszpelda.hu/kapcsolat/#webpage",
      "url": "https://www.fodraszpelda.hu/kapcsolat/",
      "isPartOf": { "@id": "https://www.fodraszpelda.hu/#website" },
      "about": { "@id": "https://www.fodraszpelda.hu/#business" }
    }
  ]
}
</script>

A példából kiolvasható döntési szabály: a jelölés minősége a forrásadat minőségén múlik. Ha a cím a Google Cégprofilban, a láblécben és a jelölésben három különböző írásmóddal szerepel, a kereső három apró eltérést lát. Ezért a munka első lépése mindig az egységes adatlap, és csak utána jön a kód.

Kapcsolódó részletes útmutatók

A schema markup a technikai SEO egyik építőköve, és szorosan összefügg azzal, hogy a kereső mit tud feltérképezni és indexelni. Ha a jelölt oldal robots.txt tiltás vagy noindex miatt nem kerül be az indexbe, a jelölése sem jut érvényre, ezért a jelölés ellenőrzését érdemes a feltérképezési és indexelési beállítások átnézésével együtt végezni. Az alábbi útmutatók ezeket a kapcsolódó területeket dolgozzák fel részletesen.

Technikai SEO: a teljes témakör
Structured data: teljes útmutató, a strukturált adat fogalmáról és formátumairól
Robots.txt: teljes útmutató
Meta robots: teljes útmutató
X-Robots-Tag: teljes útmutató
XML sitemap: teljes útmutató

Milyen sorrendben érdemes olvasni?

Ha most ismerkedsz a témával, a strukturált adatról szóló útmutatóval kezdd: az elmagyarázza, mi a különbség a JSON-LD, a Microdata és az RDFa között, és miért épp a JSON-LD terjedt el. Ez az alap segít abban, hogy a fenti kódpéldákat ne csak másold, hanem értsd is, és egy meglévő, más formátumú jelölést is fel tudj ismerni egy örökölt webhelyen.

Ha a jelölés már kész, de a Search Console jelentéseiben az elemek száma jóval kisebb, mint ahány oldalt megjelöltél, a hiba gyakran nem a kódban van, hanem az indexelésben. Ilyenkor a robots.txt, a meta robots és az X-Robots-Tag útmutató segít kideríteni, hogy a kereső egyáltalán eléri és indexelheti-e az érintett oldalakat. Egy tiltott vagy noindex jelzésű oldal jelölése hiába hibátlan, nem kerül felhasználásra.

Nagyobb webshopnál vagy sok telephelyes cégnél, ahol több ezer jelölt oldal van, az XML sitemap segít abban, hogy a kereső minden fontos, jelölt oldalt megtaláljon, és a Search Console-ban oldaltérképenként is szűrhesd az állapotukat. Így egy sablonhiba hatása gyorsabban behatárolható.

Rövid döntési szabály a továbblépéshez

Hibát jelez a validátor: maradj ennél a cikknél, a Gyakori hibák és a Mérés szekció a kiindulópont.
A validátor rendben van, de a Search Console kevés elemet lát: indexelési útmutatók.
Nem világos, miért épp JSON-LD, vagy örökölt Microdata jelölést kell átírni: a strukturált adat útmutató.
A teljes technikai kép érdekel: a technikai SEO pillér.