A márkafüggetlen szakszervizek weboldala szinte mindenhol ugyanúgy néz ki: főoldal, egy hosszú „szolgáltatásaink” oldal, galéria, kapcsolat. Ez a felépítés a klasszikus keresésben évekig működött, mert az autós rákeresett a településre és a „autószerviz” kifejezésre. A válaszmotorok viszont másképp kérdeznek vissza. Az autós ma nem szervizt keres, hanem azt írja be, hogy „P2002 hibakód, mit jelent és mennyire sürgős”, vagy hogy „miért nem fejeződik be a DPF-regeneráció rövid városi úton”. Aki erre a kérdésre nem ad kész, önmagában is megálló magyarázatot a saját oldalán, az nem kerül be a válaszba, akármilyen jó a műhelyében a munka.
Miért nem elég egy összevont „szolgáltatásaink” oldal?
Röviden: mert a nyelvi modell nem szolgáltatáslistát keres, hanem egy konkrét kérdésre adott, bekezdésnyi, ellenőrizhető magyarázatot, és az összevont oldal minden témából csak két mondatot tartalmaz.
Tovább a témában: Service schema a szolgáltatásoldalakon · Product séma webshopban
Gondolj bele, mi van egy tipikus szolgáltatás-oldalon: „Diagnosztika, DPF-tisztítás, EGR-felújítás, vezérműlánc-csere, klímatöltés, futómű.” Tizenkét szolgáltatás, mindegyikhez három sor. Ez a szerkezet a modell szempontjából egyetlen, gyenge relevanciájú blokk. Amikor valaki azt kérdezi, hogy „mi okozza a vezérműlánc-zajt hidegindításkor”, ebből az oldalból nincs mit kiemelni, mert nincs benne ok, nincs benne tünetleírás, nincs benne vizsgálati módszer. A modell inkább egy fórumhozzászólást vagy egy külföldi szakportált idéz, ahol a válasz ténylegesen ott áll.
Hivatalosan igazolt: a Google Search Central dokumentációja évek óta azt írja, hogy a tartalomnak az adott témában elsődleges, érdemi információt kell nyújtania, és a strukturált adat a tartalom értelmezését segíti, nem helyettesíti azt. Saját tapasztalat: a szolgáltatás-oldalak szétbontása után a hosszú, kérdés jellegű keresésekre érkező forgalom mérhetően más karakterű lesz, gyakoribbak a konkrét hibajelenséggel érkező megkeresések. Szakmai feltételezés: a válaszmotorok azért részesítik előnyben a fókuszált oldalakat, mert egy szűk témára írt szöveg kevesebb ellentmondó állítást tartalmaz, így kisebb a kockázata, hogy a modell félreidéz.
Hogyan épül fel egy hibajelenség-oldal a tünet-ok-vizsgálat-beavatkozás logika szerint?
Röviden: pontosan abban a sorrendben, ahogy az autós gondolkodik, vagyis a tapasztalt jelenségtől halad a lehetséges okokon és a mérésen át a döntésig.
- Tünet: mit lát, hall, érez a vezető. Ne szakszóval kezdd, hanem a hétköznapi leírással: „sárga motorhiba-jelzés, csökkentett üzemmód, hidegen kattogó hang a motor elejéből, hirtelen megnőtt fogyasztás, sűrű füst gyorsításkor.” Ez a szakasz azért kulcsfontosságú, mert a keresések többsége ilyen köznyelvi megfogalmazással indul.
- Ok: a jelenség mögötti reális műszaki magyarázatok, fontossági sorrendben. Írd le azt is, mi a leggyakoribb és mi a ritka. A modell szereti a rangsorolt felsorolást, mert abból tud óvatos, feltételes választ szerkeszteni.
- Vizsgálat: hogyan dől el, melyik ok áll fenn. Itt szerepeljen a konkrét mérés: differenciálnyomás-értékek olvasása, gyártói adatsor, oszcilloszkópos jelalak, nyomásveszteség-mérés, visszfolyás-mérés, kipufogógáz-elemzés. Ez a szakasz különbözteti meg a valódi szakszervizt a tartalommásoló oldalaktól.
- Beavatkozás: mi történik utána, milyen kimenetek lehetségesek, mikor elég a tisztítás vagy a szoftveres kényszerregeneráció, és mikor kerül sor alkatrészcserére. Fogalmazz feltételesen: „jó eséllyel”, „a mérés eredményétől függően”, „tapasztalatunk szerint gyakran”.
Ez a négyes szerkezet nem csak SEO-fogás. Ugyanez a logika él a műhelyben is, amikor a szerelő átveszi az autót. Ha a szöveg követi a valós munkafolyamatot, akkor hiteles, és a hitelesség az, amit a modellek visszaellenőriznek, amikor több forrás ellentmond egymásnak.
Milyen H2-váz működik egy konkrét hibajelenség-oldalon?
Röviden: kérdés formájú alcímek, mindegyik alatt egy tömör, önmagában is kiemelhető válaszmondattal. Nézd meg egy „nem fejeződik be a DPF-regeneráció” oldal vázát:
- Miről ismered fel, hogy a részecskeszűrő regenerációja megszakad? (tünetek: emelkedett alapjárat, forró kipufogószag, megnőtt fogyasztás, ventilátor hosszú utánfutása)
- Milyen hibakódok utalnak eltömődött részecskeszűrőre? (P2002, P242F, P2463 és a márkaspecifikus kódok viszonya)
- Miért nem indul el a regeneráció rövid városi útszakaszokon? (hőmérséklet, üzemidő, motorvezérlő feltételrendszere)
- Mit mér a szerviz a diagnosztika során? (differenciálnyomás, kipufogógáz-hőmérséklet, olajhígulás, korom- és hamutömeg számított értékei)
- Mikor elég a kényszerregeneráció és mikor kell kiszerelt tisztítás?
- Milyen okot érdemes kizárni a szűrő cseréje előtt? (szivárgó porlasztó, hibás EGR-szelep, nyomásérzékelő cső eltömődése, turbónyomás-hiba)
- Mit tehetsz utána, hogy ne ismétlődjön?
Figyeld meg, hogy egyik alcím sem így szól: „DPF-tisztítás szolgáltatásunk”. Minden alcím kérdés, mert a válaszmotor gyakorlatilag kérdés-válasz párokat keres. Saját tapasztalat: ha az alcím alatti első mondat önállóan is értelmes, teljes válasz, akkor lényegesen gyakrabban jelenik meg szó szerinti idézetként. Ha az első mondat átvezetés („Ebben a szakaszban bemutatjuk, hogy...”), akkor a kiemelhető tartalom elveszik.
Mely márkákat, motorkódokat és hibakódokat szerepeltesd szövegesen?
Röviden: azokat, amelyeket ténylegesen vállalsz, és mindet folyó szövegben vagy felsorolásban, sosem képen vagy PDF-ben.
A gyakorlatban ez három réteget jelent. Az első a márka és a modellcsalád: melyik gyártók járműveihez van gyártói szintű diagnosztikád és alkatrész-ellátásod. A második a motorkód, mert a kérdések jelentős része már ezen a szinten érkezik: az azonos hengerűrtartalmú motorok között generációnként komoly eltérés van, és a szerelő ezt tudja, az általános tartalom nem. Írd ki a konkrét kódokat ott, ahol releváns a téma szempontjából, például a vezérműlánc-zaj oldalán a lánchajtású dízel- és benzinmotorok kódjait, a részecskeszűrő oldalán az adott gyártó közös nyomócsöves dízeleit. A harmadik réteg maga a hibakód.
Hivatalosan igazolt: a generikus OBD-II kódok (a P0-val és jellemzően P2-vel kezdődő tartomány egy része) szabványosított jelentéssel bírnak, ezt a vonatkozó ISO- és SAE-szabványok rögzítik, tehát ezekre nyugodtan lehet definíciós igényű mondatot írni. A gyártóspecifikus kódok ellenben márkánként eltérő jelentésűek, ezért ott mindig jelezd, hogy a kód értelmezése a gyártói adatbázis alapján történik. Ez az óvatosság nem gyengíti a szöveget, hanem erősíti: a modellek a bizonytalanságot korrekten jelölő forrásokat jellemzően szívesebben idézik olyan témákban, ahol a téves állításnak következménye van.
Egy praktikus szabály: minden hibajelenség-oldalon legyen egy rövid felsorolás „gyakran érintett motorok és tipikus kódok” címmel. Ez a blokk teszi lehetővé, hogy a modell összekösse a köznyelvi tünetleírást a műszaki azonosítóval, és fordítva.
Hogyan mutasd meg a diagnosztikai eszközparkot E-E-A-T-jelként?
Röviden: névvel, funkcióval és azzal, hogy pontosan mit mérsz vele, mert az eszközlista önmagában semmit nem bizonyít, a mérési eljárás leírása viszont nehezen másolható tapasztalati jel.
A leggyengébb megoldás egy fotógaléria a műszerekről. A legerősebb egy külön oldal, amely végigveszi, milyen vizsgálat milyen eszközzel történik: gyártói szintű diagnosztikai szoftver a vezérlőegységek élő adatsorához, oszcilloszkóp a porlasztó- és érzékelőjelek alakjának vizsgálatához, kompresszió- és hengernyomásveszteség-mérés, visszfolyásmérés a befecskendezőknél, füstölésmérés, klímarendszer szivárgásvizsgálata, futóműgeometria-mérés. Minden eszközhöz tartozzon egy mondat arról, milyen kérdést dönt el.
Szakmai feltételezés: a mérési eljárások részletes leírása azért működik jól az AI-válaszokban, mert a modellek a szakmai mélységet a konkrétság mentén becsülik meg, és az „oszcilloszkópos jelalak-vizsgálat a vezérműszíj-fázishelyzet ellenőrzéséhez” típusú megfogalmazás statisztikailag ritka a hirdetésszerű szövegekben. Emellett érdemes megnevezni a szerelők végzettségét, a rendszeres továbbképzéseket és a szerviz működési idejét, mert ezek ellenőrizhető, valós tapasztalati jelek.
Milyen strukturált adatot tegyél a hibajelenség-oldalra?
Röviden: egy Service típusú JSON-LD blokkot, amelynek szolgáltatója egy AutoRepair típusú entitás, plusz ahol tényleg vannak kérdések, egy FAQPage blokk.
Egy minimális, mégis működőképes váz így néz ki:
{ "@context": "https://schema.org", "@type": "Service", "serviceType": "Részecskeszűrő diagnosztika és regenerációs hibakeresés", "provider": { "@type": "AutoRepair", "name": "A szerviz neve", "address": { "@type": "PostalAddress", "addressLocality": "Székesfehérvár", "addressCountry": "HU" }, "telephone": "+36..." }, "areaServed": { "@type": "AdministrativeArea", "name": "Fejér vármegye" }, "termsOfService": "https://..." }
Hivatalosan igazolt: a Schema.org szótárában létezik az AutoRepair típus, és a Google strukturált adatokra vonatkozó általános irányelvei szerint a jelölésnek meg kell felelnie az oldalon látható tartalomnak. Ha tehát a sémában szerepel egy szolgáltatás, annak a szövegben is ott kell lennie. Ne jelölj olyan értékelést, amit nem a saját rendszered gyűjt, és ne tegyél a sémába olyan mezőt, amit az oldal nem támaszt alá.
Szakmai feltételezés: a strukturált adat közvetlen hatása az AI-válaszokra ma nem bizonyított úgy, ahogy a klasszikus rich result esetében, viszont a séma egyértelműsíti az entitás és a hely kapcsolatát, ami a helyi jellegű kérdéseknél segítheti a helyes hozzárendelést. A kockázat alacsony, a lehetséges haszon reális, ezért érdemes megcsinálni.
Miért csak akkor leszel idézhető forrás, ha vállalod a szakmai magyarázatot?
Röviden: mert az a szerviz, amely minden kérdésre azt válaszolja, hogy „hozd be, megnézzük”, semmilyen információt nem ad, amit egy válaszmotor továbbadhatna.
Ez a saját nézőpontom, és a szakmában sokan nem értenek vele egyet. A gyakori ellenérv úgy szól: ha leírod, mi a hiba oka és hogyan lehet megvizsgálni, akkor az autós vagy maga próbálja megjavítani, vagy elviszi a tudást egy másik műhelybe. A tapasztalat ezzel szemben az, hogy a részletes magyarázat jellemzően szűri az érdeklődőt: aki elolvassa, hogy a részecskeszűrő tisztítása előtt ki kell zárni a szivárgó befecskendezőt, az pontosan azért választ szakszervizt, mert érti, miért nem elég a legolcsóbb megoldás. Aki pedig magától megcsinálja, az sosem lett volna vevő.
Van egy második, ma fontosabb szempont is. A modell nem tud hivatkozni arra, ami nincs leírva. Ha a szakmai tudásod kizárólag a telefonbeszélgetésekben és a műhelyben él, akkor a gépi válaszokban láthatatlan maradsz, miközben a helyedet olyan tartalmak töltik ki, amelyeket nem szerelők írtak. A magyarázat vállalása tehát nem tudásátadás, hanem jelenlét. Az időpontfoglalásra terelő gomb maradjon ott a szöveg végén és a szakaszok között, de ne az legyen a tartalom helyett.
Milyen ellenőrzőlistával induljon el egy szakszerviz?
Röviden: nyolc lépéssel, amelyek nagyjából egy negyedév alatt elvégezhetők, ha hetente egy hibajelenség-oldal készül el.
- Gyűjtsd össze a munkalapokból a tíz-tizenöt leggyakoribb hibajelenséget, ahogy az ügyfél elmondta, nem ahogy a szerelő rögzítette.
- Minden jelenséghez rendelj egy külön aloldalt beszédes, kérdés jellegű címmel és tiszta, olvasható webcímmel.
- Írd meg mindegyiket a tünet-ok-vizsgálat-beavatkozás szerkezettel, kérdés formájú H2-kkel és rövid nyitóválaszokkal.
- Tedd bele szövegesen az érintett márkákat, motorkódokat és a releváns OBD-kódokat, jelölve, melyik szabványos és melyik gyártóspecifikus.
- Készíts egy eszközpark-oldalt, amely minden műszernél leírja, milyen kérdést dönt el, és hivatkozz rá minden hibajelenség-oldalról.
- Illeszd be a Service és az AutoRepair sémát, majd ellenőrizd validátorral, hogy nincs benne olyan állítás, ami a szövegben nem szerepel.
- Adj minden oldalhoz négy-hat valódi kérdést és rövid, tényszerű választ, olyanokat, amelyek ténylegesen elhangzanak a pultnál.
- Frissítsd a szövegeket, ha a műhely tapasztalata változik, és tüntesd fel a módosítás dátumát.
Hasznos kiegészítés a robots.txt átnézése is. Hivatalosan igazolt: az OpenAI külön dokumentálja a felhasználói ágenseit, és a szolgáltatók leírják, hogyan lehet ezek hozzáférését szabályozni. Ha a szerviz oldalán korábban valaki mindent letiltott, akkor a legjobb tartalom sem jut el a válaszmotorokhoz.
Hogyan ellenőrizd, hogy tényleg idéznek-e?
Röviden: rendszeres, azonos szöveggel megismételt kérdésekkel és a hivatkozó forgalom külön mérésével, mert a válaszok változékonyak.
Állíts össze húsz-harminc kérdést pontosan úgy, ahogy egy autós írná, és havonta futtasd le őket a nagyobb asszisztensekben. Jegyezd fel, kit idéznek, milyen szövegrészt emelnek ki, és van-e köztük a saját oldalad. Az analitikában érdemes külön nézni az asszisztensekből érkező hivatkozásokat. Saját tapasztalat: ugyanaz a kérdés két héttel később gyakran más forrásokat hoz, ezért egyetlen mérés semmit nem mond el, a trend viszont igen. Ez a fajta munka nem hoz azonnali eredményt, és senki nem ígérhet biztos megjelenést, de a fókuszált, szakmailag vállalható oldalak jó eséllyel tartósabban maradnak meg hivatkozásként, mint a hirdetésszerű szolgáltatás-oldalak.
Források és további olvasnivalók
- Google Search Central: Structured data general guidelines
- Google Search Central: Creating helpful, reliable, people-first content
- Google Search Quality Rater Guidelines
- Schema.org: Service, AutoRepair, FAQPage típusdokumentáció
- OpenAI dokumentáció: GPTBot és OAI-SearchBot felhasználói ágensek
- ISO 15031-6 és SAE J2012: diagnosztikai hibakódok szabványa
- Bing Webmaster Guidelines
- W3C: Web Content Accessibility Guidelines (WCAG)
- Minden gyakori hibajelenség kapjon saját oldalt, mert a válaszmotor bekezdésnyi, konkrét magyarázatot idéz, nem szolgáltatáslistát.
- A tünet-ok-vizsgálat-beavatkozás szerkezet pontosan azt a logikát követi, ahogy az autós kérdez és ahogy a modell szemezget.
- A márkák, motorkódok és OBD-hibakódok szövegesen, nem képen szerepeljenek, mert a szöveges említés kereshető és idézhető.
- A diagnosztikai eszközpark és a mérési módszer részletes leírása erős tapasztalati jelzés, ami nehezen másolható.
- Aki csak időpontfoglalásra terel, ritkán lesz hivatkozott forrás: a szakmai magyarázat vállalása a belépő.
Gyakori kérdések
Hány külön hibajelenség-oldalt érdemes létrehozni egy kisebb szerviznek?
Indulásnak tíz-tizenöt oldal elég, ha ezek a ténylegesen leggyakoribb munkákat fedik le. Fontosabb, hogy mindegyik valódi mérési és beavatkozási tapasztalatot tartalmazzon, mint az, hogy sok legyen belőlük. Az üres, általános szövegekkel feltöltött ötven oldal gyengébb eredményt hoz, mint tizenöt alapos.
Nem baj, ha leírom a hiba okait, és az ügyfél emiatt máshova viszi az autót?
Saját tapasztalat szerint a részletes magyarázat inkább szűri az érdeklődőt, mint elviszi. Aki érti, miért kell kizárni a szivárgó befecskendezőt a szűrőcsere előtt, az jellemzően pont a felkészült műhelyt keresi. Aki pedig házilag megoldja, az valószínűleg amúgy sem lett volna ügyfél.
Elég, ha a hibakódokat egy letölthető PDF-ben vagy képen szerepeltetem?
Nem érdemes így megoldani. A szöveges tartalom kereshető és idézhető, a képre írt kód viszont a legtöbb feldolgozás számára nehezen hozzáférhető. A hibakódokat és motorkódokat írd bele a folyó szövegbe vagy felsorolásba.
Segít-e a Service-séma abban, hogy a ChatGPT idézzen?
Hivatalosan ez nincs kimondva. A séma egyértelműsíti, hogy milyen szolgáltatásról, milyen szervizről és milyen területről van szó, ami segítheti a helyes hozzárendelést, de önmagában nem eredményez megjelenést. A tartalmi mélység marad az elsődleges tényező.
Mit tegyek, ha a válaszmotor rossz információt mond a szervizemről?
Először nézd meg, honnan származhat: gyakran egy elavult katalógusadat vagy régi aloldal az ok. Frissítsd a saját oldalad adatait, egységesítsd a nevet, címet és nyitvatartást minden felületen, és ahol lehet, javíttasd a hibás külső forrást. A javulás nem azonnali, több hetes átfutással érdemes számolni.
Hogyan kezeljem a gyártóspecifikus hibakódokat, ha márkafüggetlen vagyok?
Írd le, hogy a szabványos OBD-kódok jelentése egységes, a gyártóspecifikus kódoké viszont márkánként eltér, és ezeket gyártói adatbázisból értelmezed. Ez a megkülönböztetés pontosabbá teszi a szöveget, és jelzi a szakmai felkészültséget is.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.