A te SEO-javításaid csak akkor skálázódnak, ha ismételhető munkafolyamatot építesz

Összefoglaló

Az ügynökségek gyakran minden technikai SEO-megbízást friss vizsgálatként kezelnek, még akkor is, ha a mögöttes hibaminták ismétlődnek. Ez a megközelítés órákat pazarol el, és az egyes ügyfelek teljesítményét attól teszi függővé, hogy az utolsó auditot futtató személy mire emlékszik. A váltás egy kanonikus diagnosztikai út meghatározása: ugyanaz az alapszintű ellenőrzéskészlet minden ügyfélnek, egy közös playbookhoz rendelve, amely minden megbízás után fejlődik. Ha ez az út a helyén van, az olyan teljesítményproblémák, mint a lassú Largest Contentful Paint, ismételhető javításokká válnak, nem pedig egyszeri nyomozási feladattá. Ugyanez a logika vonatkozik a strukturált adatokra is, amelyeket mintaként kell szállítani, nem pedig testre szabott projektként. De a rendszernek szándékos kihagyási listára is szüksége van: nem minden talált hiba érdemel javítást, és a tudás, hogy mit érdemes figyelmen kívül hagyni, a munkafolyamat skálázhatóságának része.

Három héttel azután, hogy elindítottad a javítást, ugyanazt a grafikont bámulod. Az A ügyfél Largest Contentful Paintje zöldre váltott, de a B ügyfél ugyanazt a lassú mintát mutatja, amiről azt hitted, megoldottad. Beleásolsz a témájukba, a képcsővezetékükbe, a tárhelyükbe; más a stack, más a bűnös, ezért új auditot nyitsz. Az előző megbízás jegyzetei az ügyfél mappájában vannak, az ügyfél prioritásainak nyelvén írva. Fordítasz, újratesztelsz, és a nulláról újra rangsorolsz. Ez az ügynökségi SEO-munka rejtett adója: minden projekt a nulláról indul, és az előző ügyfél tudása csak a memóriádban él.

A megoldás nem egy nagyobb vagy jobb audit. Hanem egy ismételhető munkafolyamat – egy diagnosztikai út, amelyet minden ügyfélnél le tudsz futtatni, egy olyan playbookkal, amely minden alkalommal okosabb lesz. Ez a cikk végigvezet az egyszeri nyomozómunkától a skálázható rendszerig, beleértve azokat a részeket is, amelyek túl unalmasak ahhoz, hogy leírják, és azokat, amelyeket szándékosan nem javítasz meg.

Az ad hoc audit csapdája

Az a kísértés, hogy minden SEO-auditot friss vizsgálatként kezelj, érthető, hiszen minden ügyfél valóban más stacket mutat. Az egyik egy túlméretezett egyedi témát használ, a másik egy SaaS-termékrácsot, a harmadik egy harmadik féltől származó CDN-en tárolja a képeket, amelyet nem tudsz ellenőrizni. Ha a stack diktálja a folyamatodat, soha nem építesz fel folyamatot. Egy sor improvizációt fogsz építeni, amelyeket csak az kapcsol össze, hogy ugyanaz a személy végzi őket.

A csapda nem az, hogy különböző dolgokra kell nézned. A csapda az, hogy minden alkalommal ugyanabból a strukturálatlan helyről kezdesz nézni, közös útvonal nélkül a megoldáshoz. Vegyünk két ügyfelet ugyanazon a héten. Az A ügyfél lassú oldala egy blogsablon, amelyben egy nehéz carousel tolja ki a fő tartalmat. A B ügyfél lassú oldala egy termékrács beépített videóval és egy későn renderelődő webfonttal. A tünetek különbözőek, de a megoldáshoz vezető út azonos: azonosítsd a hajtás feletti legnagyobb elemet, nézd meg, mit kell betölteni előtte, ellenőrizd, hogy elmozdul-e valami a betöltése után, majd döntsd el, mit tud a böngésző később letölteni a korábbi helyett. Ha ezt az útvonalat egyszer dokumentálod, a második ügyfél már csak változók kitöltése.

Ez a dokumentáció a hiányzó alapeszköz. Nélküle minden megbízás új kirakósnak érződik, és az ügyfél a rejtvényfejtésedért fizet, nem az eredményért. Egyes csapatok úgy oldják meg ezt, hogy a folyamatukat szándékosan unalmassá és ismételhetővé teszik, ahogy arról már írtunk a unalmas, ismételhető ügynökségi SEO-munkafolyamat kapcsán. A lényeg nem az, hogy ne gondolkodjunk. Hanem az, hogy a gondolkodást szűkös erőforrássá tegyük, ne pedig alapértelmezetté minden alapvető ellenőrzésnél.

A nyomozómunkától a diagnosztikai útig

Képzeld el a pillanatot, amikor rájössz, hogy ismételni fogod magad. Az ügyfél ugyanazt a képernyőképet küldte, mint tavaly: az oldal betölt, majd a tartalom ugrik, majd a fő kép későn jelenik meg. Az ösztönöd az, hogy megnyisd a DevToolst és nézelődni kezdj. Állj! Az ismételhető útnak másként kell érződnie. Egy sablont kell megnyitnod, amelyben már ott van az első öt ellenőrzés, le kell futtatnod őket, és meg kell jelölnöd, hogy a diagnózis melyik rétegében van a probléma. A sablon nem ismeri az ügyfél stackjét, de ismeri az oldalbetöltés anatómiáját.

A diagnosztikai út rétegekre oszlik. Kezdd egy alap feltérképezéssel, hogy elkapd a nyilvánvalót: hiányzó címek, elromlott átirányítások, blokkolt erőforrások, duplikált kanonikusok. Ezután futtass teljesítménytesztet a legfontosabb oldalakon, mérd a Core Web Vitalseket, és húzd ki az erőforrás-szintű részleteket, amelyek megmagyarázzák, miért néznek ki úgy a számok, ahogy. Ezután értékeld az oldal relevanciáját: az oldal tartalma, fejlécei és metaadatai valóban egyeznek-e a megcélzott lekérdezéssel? Ezután ellenőrizd a strukturált adatokat: jelen van és érvényes az oldal géppel olvasható leírása? Végül nézd meg a szerver- és biztonsági alapokat: robots.txt, szitemap, HTTPS, átirányítási láncok.

Minden ügyfél megkapja mind az öt réteget, de a mélység változó. Egy kis brosúra-webhelynél az alap feltérképezés és az oldal-ellenőrzés az idő töredékébe kerülhet, mint ugyanaz a réteg egy nagy e-kereskedelmi katalógusnál. A lényeg az, hogy egyetlen ügyfél sem hagyhat ki réteget, és egyetlen ügyfél sem lehet az áldozata annak a folyamatnak, amely attól függ, melyik rétegeket érzed úgy, hogy aznap délután érdemes vizsgálni.

Jó kiindulópont egy dokumentált példa egy korábbi ügyféltől. Tegyük fel, hogy van egy ügyfeled, akinek a kezdőlapja azért lassú, mert a hős képet kérik be, mielőtt a kritikus CSS elérhető lenne. A playbookodban leírod, hogy ez a helyzet szinte mindig három dolog egyike: a kép túlméretezett, hiányzik a loading attribútum, vagy a szerver valami fontosabb dolog előtt küldi el a képet. Nem kell tudnod, melyik igaz, amíg el nem végzel egy gyors ellenőrzést. A playbook nem megoldás; ez egy differenciáldiagnózis. A következő ügyfélnél már tudod, hol kell keresni, nem pedig azon gondolkodni, hogy hol is keress.

Építsd fel a munkafolyamatot úgy, hogy túlélje az ügyféllel való érintkezést

Kezdd egy kanonikus ellenőrzőlistával, nem jelentéssel. A kanonikus ellenőrzőlista azoknak az ellenőrzéseknek a listája, amelyeket minden ügyfélnél ugyanabban a sorrendben futtatsz, elegendő részletességgel ahhoz, hogy a csapatod más tagja is le tudja futtatni anélkül, hogy kérdezne. A jelentés olyan dolog, amit a munka után írsz; az ellenőrzőlista olyan dolog, amit azelőtt futtatsz, mielőtt megtudnád, mi is a munka. A Google saját útmutatása egyértelművé tette, hogy a keresőmotorok a hasznos oldalakat jutalmazzák, és az oldalélmény számít, és a Google megerősítette, hogy az oldalsebesség rangsorolási tényező. Ennek gyakorlati következménye, hogy nem kezelheted a teljesítményt úgy, mint egy majd később megcsináljuk fázist; ugyanannak a diagnosztikai útnak kell lennie, mint minden másnak.

Így néz ki egy ismételhető munkafolyamat:

1. Határozd meg az alapvonalat. Mielőtt bármit megváltoztatnál, rögzítsd a kulcsoldalak aktuális állapotát ugyanazzal a mérési módszerrel, amelyet a változtatás után is használni fogsz. Ha belső eszközzel mérsz, használd továbbra is azt az eszközt. Ha laborkörnyezetű böngészőt használsz, maradj ennél a böngészőnél. A mérőeszközök váltogatása a before és after között értelmetlenné teszi az összehasonlítást.
2. Minden hibát kategóriához rendelj, ne ügyfélhez. A probléma nem „az ügyfél kezdőlapjának képproblémája”. A probléma az, hogy „a hajtás feletti hős kép nem megfelelő betöltési stratégiát használ”. Ez a megfogalmazás lehetővé teszi, hogy a playbookodban ugyanarra a kategóriára keress a következő ügyfélnél.
3. Prioritást a hatás alapján rendelj, ne a darabszám alapján. Egy kis metaadat-ismétlődés egy alacsony forgalmú oldalon csak akkor éri meg a javítást, ha úgyis módosítod azt a fájlt. Egy elromlott kanonikus egy pénztermelő oldalon még ma javítandó. Szükséged van egy egyszerű pontozási szabályra, hogy két különböző ember ugyanazon az ügyfélen dolgozva ugyanazt a prioritási sorrendet kapja.
4. Csak azt javítsd, ami a listán van. Ha egyszer van egy rangsorolt listád, állj ellen a késztetésnek, hogy tovább kutakodj. A munkafolyamat célja, hogy döntéshez juss, nem az, hogy minden lehetséges tökéletlenséget felszínre hozzon.
5. Teszteld újra és rögzítsd. A javítás után futtasd le pontosan ugyanazt a mérést. Ha a szám nem változott, jegyzed le, mit próbáltál, hogy a következő ügyfélnél ne próbáld újra. Így halmozódik a playbook.

Ha a nulláról építed ezt fel, egy jó alapforrás egy technikai SEO-audit útmutató marketingeseknek, amely végigmegy a feltérképezhetőségen, az indexelhetőségen és a duplikált tartalmakon. Ehhez a webhelyhez a technikai SEO-audit útmutató nem technikai marketingeseknek adja meg azt a struktúrát, amelyet ügyfélkész sablonná alakíthatsz. A kulcs az, hogy ezt a struktúrát olyanná alakítsd, amit minden alkalommal ugyanúgy futtatsz, ügyfélspecifikus részletekhez fenntartott helyekkel, nem pedig üres oldalként.

Az alábbi táblázat összehasonlítja az ad hoc megközelítést az ismételhető munkafolyamattal:

Ad hoc megközelítés	Ismételhető munkafolyamat
Az audit azzal az eszközzel kezdődik, amelyiket épp meg akarsz nyitni	Ugyanaz az alap feltérképezés és ugyanaz az ellenőrzési sorrend minden ügyfélnek
A javítások ügyfélspecifikus jegyzetekben vannak rögzítve	A javítások hiba-kategóriákhoz vannak rendelve egy közös playbookban
A következő ügyfél újra levezeti a prioritási listát	A prioritást minden alkalommal ugyanaz a pontozási szabály adja
Az ellenőrzés egyszeri újratesztelés	Az újratesztelés ütemezett, és az alapvonalhoz viszonyítva történik
A tudás az ügyfélkapcsolat-vezető fejében él	A tudás a playbookban él, és minden ügyfél után fejlődik

Kísértés lesz, hogy a munkafolyamatot majd később formalizálod, ha több ügyfeled lesz. Ez fordítva van. Az első alkalom, amikor lefuttatod a munkafolyamatot, pontosan az az időpont, amikor le kell írnod, mert akkor még emlékszel, miért hoztad meg az egyes döntéseket.

Egy javítás, két ügyfél: egy végigjátszás

Vegyük a leggyakoribb teljesítményproblémát: egy nagy elem a hajtás felett, amely késlelteti a Largest Contentful Paint (LCP) mérést. A web.dev-en leírt Core Web Vitals rendszer az LCP-t a betöltés mérésére, az INP-t a válaszkészség mérésére, a CLS-t pedig a vizuális stabilitás mérésére használja. Az LCP az, ami általában megbotlasztja az embereket, mert a képek, videók és nagy szövegtömbök méretétől és betöltési viselkedésétől függ.

Képzeld el, hogy az A ügyfél egy gyártó, amelynek hős képe a teljes eredeti felbontásban jelenik meg, pedig a megjelenített méret kicsi. A javítás: a kép átméretezése, tömörítése, és a fetchpriority="high" hozzáadása, hogy a böngésző tudja, hogy előnyben részesítse. Elvégzed a javítást, újra mérsz, és az LCP-szám javul. A playbookban feljegyzed: „Hős kép teljes felbontásban, holott a megjelenített méret kicsi.”

Most jön a B ügyfél. Az ő webhelyük más CMS-t, más dizájnt használ, de ugyanaz a tünet. Ahelyett, hogy a nulláról kezdenél felfedezni, megnyitod a playbookot, rákeresel a „hős kép”-re, és meglátod a jegyzetet. Ellenőrzöd, hogy a gyökérok ugyanaz-e, megnézve a megjelenített méreteket és a letöltött bájtokat. Nem pontosan ugyanaz – a B ügyfélnek webfontja is korán betöltődik –, de mivel a playbook már dokumentálta a kép részt, a font részt gyorsabban izolálod. Az együttes javítás az idő töredéke alatt elkészül, mint az első ügyfélnél.

A lényeg nem az, hogy a javítás azonos. A lényeg az, hogy a diagnosztikai lépés azonos. Ugyanazt a listát ellenőrzöd, szűkíted az okot, és alkalmazod a megfelelő playbook-bejegyzést. Ez teszi skálázhatóvá a munkaterhelést: nem a javítás automatizálása, hanem a keresés automatizálása. Egy Core Web Vitals lépésről lépésre útmutató segíthet kodifikálni az LCP, INP és CLS konkrét ellenőrzéseit ügyfélkész sorozattá.

Figyelmeztetés: nem minden ügyfél lassú LCP-jét ugyanaz okozza. A playbooknak azokat a kategóriákat kell tartalmaznia, amelyeket valóban láttál, nem pedig elméletet minden lehetséges okról. Ha olyan okkal találkozol, amely nincs a playbookban, a javítás után vedd fel. Így a playbook a valódi ügyfelek valós problémáiban gyökerezik, és nem válik képzeletbeli szélsőséges esetek enciklopédiájává.

A strukturált adat minta, nem projekt

Ha a teljesítmény ismételhető úton fut, ugyanez a logika vonatkozik a strukturált adatokra is. Ha valaha is részt vettél strukturált adatok bevezetésében, tudod, milyen gyorsan válik egyedi projektté: valaki ír egy sémát a kezdőlapra, valaki más egy másikat a bloghoz, a validációs hibákat pedig hónapokig figyelmen kívül hagyják. Ennek elkerülésének módja, ha a strukturált adatokat mintaként kezeled, sablonnal alkalmazod, nem pedig kreatív gyakorlatként minden oldalon.

A Yoast kezdő útmutatója szerint a strukturált adat az oldalhoz hozzáadott kód, amely segít a keresőmotoroknak megérteni, mi a tartalom, ami gazdagabb találatokhoz és jobb láthatósághoz vezethet. A Search Engine Land 2025-ös útmutatója szintén a strukturált adatokat úgy keretezi, mint annak biztosítékát, hogy a tartalom érthető legyen a változó keresési környezetben, beleértve az AI-vezérelt keresést is. Ha rendszeresen gondolkodsz azon, hogy milyen kategóriái vannak az ügyfeleid oldalainak – cikkek, termékek, helyi vállalkozások, GYIK, események –, felépíthetsz egy kis séma-sablonkönyvtárat. Minden sablon rögzíti a szükséges tulajdonságokat és a validációs lépéseket. Amikor egy új ügyfélnek termékoldala van, a terméksablont alkalmazod, ahelyett, hogy emlékezetből írnál új jelölőnyelvet.

Egy részletes példa: Az A ügyfél egy helyi vállalkozás szolgáltatásoldallal. A B ügyfél egy szoftvercég dokumentációs webhellyel. Más séma, igen, de a szállítási folyamat azonos. Azonosítod az oldaltípust, megnyitod a megfelelő sablont, kitöltöd a mezőket, beilleszted az oldal HTML-jébe, és validálod egy teszteszközzel. A validációs lépés nem alku tárgya, mert egy érvénytelen séma rosszabb, mint a semmi – azt mondja a keresőmotoroknak, hogy nem bízhatnak meg a strukturált adataidban. A minta azt jelenti, hogy a második ügyfél az első idejének töredékébe kerül, és a sablon minden alkalommal fejlődik, amikor egy szélsőséges esetet találsz.

Van egy mélyebb előny is, amely visszakanyarodik a munkafolyamathoz. Ha minden oldaltípushoz van séma-sablon, gyorsan látod, mely oldalakról hiányzik a géppel olvasható leírás. Ez ellenőrzőlista-kategóriává válik, nem külön projektté. Ugyanez a döntési logika érvényes: ha egy oldal értékes és mondanivalójában releváns, a séma hozzáadása megéri; ha az oldal egy vékony címkearchívum, amelyet úgyis noindexelni gondolsz, a séma nem prioritás. Egy strukturált adatok bevezetési útmutatója segíthet felállítani a validációs hurkot, de az igazi nyeremény az, hogy eldöntöd: a hurok minden ügyfélnél ugyanúgy fut.

A legnehezebb készség: visszautasítani a javítást

Az ügynökségi munka gyakori feltételezése, hogy a szállított érték arányos a talált hibák számával. Az ügyfél lát egy hosszú listát a problémákról, és azt hiszi, alapos munkát végeztél. A probléma az, hogy a hosszú lista felhígítja a hatásodat. A megbízást azzal töltöd, hogy egy nem látogatott oldal metaadat-eltérését javítod, miközben egy kategóriaoldal átirányítási lánca továbbra is pazarolja a feltérképezési keretet. Több talált hiba nem több érték. Gyakran az ellenkezője igaz: az a képesség, hogy azt mondd: „ezt nem érdemes megjavítani”, az, ami a jelentést ajánlássá változtatja.

A gyakorlatban egy ismételhető munkafolyamat legfontosabb kimenete egy kihagyási lista. Képesnek kell lenned azt mondani az ügyfélnek: „Ugyanazt a diagnosztikai utat futtattuk, mint minden ügyfelünknél. Íme a három dolog, ami számít, és íme a kilenc dolog, amit szándékosan nem fogunk megtenni, mert nem mozdítják a prioritásaidat.” Ehhez a kijelentéshez több magabiztosság kell, mint az összes lehetséges fejlesztés felsorolásához, és ez az a rész, ami fenntarthatóvá teszi a munkafolyamatot több ügyfél esetén.

Hol kell meghúzni a vonalat? Általában két kérdés alapján. Először is, érinti-e a hiba egy olyan oldalt, amely üzleti célt támogat? Egy lassú kép az ÁSZF-oldalon lehet, hogy nem éri meg az ügyfél költségvetését, bármit mond is az audit eszköz. Másodszor, a hiba befolyásolja-e a felhasználói élményt a keresés szempontjából fontos mérőszámok szerint? Ha egy oldalnak már alacsony az LCP-je, mert többnyire szöveges, egy apró elmozdulás az oldal alsó részén valószínűleg nem a megbízás fókuszpontja. A tágabb SEO-kontextus ezt alátámasztja: a modern keresési trendek a felhasználói szándékot és az E-E-A-T-t helyezik előtérbe a kulcsszóhalmozással szemben, ami azt jelenti, hogy egy valóban hasznos, de kisebb technikai hibával rendelkező oldal még mindig jobb, mint egy kifinomult oldal, amely nem válaszol a lekérdezésre.

Van egy pragmatikus ok is a kihagyásra. Minden elvégzett javítás kis kockázatot hoz a visszalépésre. Ha egy megosztott sablonhoz nyúlsz egy metaadat-probléma javításához, elromolhat a behúzás, késleltetheted a folyamatot, vagy hibát vihetsz a kanonikusba. Minél többet javítasz, annál többet kockáztatsz. A fegyelmezett kihagyási lista kicsiben tartja a változtatási felületet, és megbízhatóvá teszi a javításaidat. Az ügyfél sokkal inkább emlékezni fog arra az egy értelmes fejlesztésre, amely működött, mint a húsz kozmetikai ellenőrzésre, amit kipipáltál.

Összegzés: A szállított termék egy rendszer, nem egy jelentés

Abban a pillanatban, amikor az ügynökséged abbahagyja, hogy minden ügyfelet vadonatúj vizsgálatként kezeljen, a munkád elkezd kamatozni. Az első ügyfél ad egy diagnosztikai mintát, a második teszteli, a harmadik fejleszti, és az ötödikre már csukott szemmel is le tudod futtatni ugyanazt az utat – nem azért, mert kevesebb figyelmet fordítasz, hanem mert a figyelmed az egyes ügyfelek valóban egyedi részeire összpontosul. A munkafolyamat az eszköz, az ügyfélspecifikus ajánlások pedig csak ennek az eszköznek a kimenetei.

A gyakorlati lépések egyértelműek: határozd meg a kanonikus auditrétegeket, építs fel a hiba-kategóriák szerint szervezett playbookot, használd ugyanazt az alapvonalat és újratesztelési módszert, alkalmazd a strukturált adatokat sablonokból, és tarts fenn kihagyási listát. Egyikhez sem kell új eszköz, vagy a csapatod készségeinek drámai megváltoztatása. Fegyelem kell ahhoz, hogy leírd, amit már amúgy is csinálsz, hogy a következő ügyfélnek ne kelljen megfizetnie az újrafelfedezését.

Amikor arra kérnek, hogy az ügyfelek sorában rangsorold a SEO- és teljesítménymunkát, a válasz nem az, hogy több auditort vegyél fel. A válasz az, hogy az auditfolyamatot elég ismételhetővé tedd ahhoz, hogy a tizedik ügyfél az első töredékébe kerüljön. Ez a különbség az óráid eladása és egy olyan rendszer eladása között, amely akkor is működik, amikor az órák már rég eltűntek.