Mit ellenőrzünk, mielőtt bármi kimegy?

Röviden

A dataviral.hu oldalait egy saját build generálja, ami hibával leáll, ha egy forrásfájlból hiányzik a fejléc-adat, ha rossz a JSON, vagy ha ismeretlen schema-típusra hivatkozunk. Egy második ellenőrzés a legenerált HTML-en fut: minden cikknek 3–5 másikra kell linkelnie, minden linknek indoklással, és minden cikknek legalább 3 másikból elérhetőnek kell lennie. A hiányzó szövegek nem tűnnek el, hanem egy generált listába kerülnek — jelenleg 32 nyitott elem áll rajta.

01Hol nincs „elbukik” pillanat?

A szoftverfejlesztésben megszokott, hogy a munkának van egy pontja, ahol valami megbukhat. Lefut egy teszt, és piros lesz. Nem indul el a folyamat. Valaki nem tudja kiadni azt, amit írt.

A marketingmunka nagy részében ilyen pont nincs. A szöveg elkészül és kimegy. A poszt megjelenik. A riport elmegy az ügyfélnek. Semmi nem áll meg, ha egy szám elírás, ha egy link rossz helyre visz, vagy ha egy állítás mögött nincs adat. Ezek a hibák nem a folyamat közben derülnek ki, hanem utána — vagy soha.

Ez a cikk arról szól, hogy a saját weboldalunknál hol van ilyen megállás, és mit tagad meg pontosan a rendszer. Nem elvi leírás: minden alább szereplő viselkedés ennek az oldalnak a kódjában van, és most is így fut.

02Mit tagad meg a build?

A dataviral.hu oldalait nem kézzel írjuk, hanem egy saját generátor állítja elő a forrásokból. Ez a generátor négy esetben nem generál kimenetet, hanem hibával leáll:

Ha egy oldalforrásból hiányzik a fejléc-adat. Cím, leírás, oldaltípus — ezek nélkül nem készül el az oldal.

Ha a fejléc-adat hibás. Egy elfelejtett vessző a szerkezetben megállítja a folyamatot, és megmondja, melyik fájlban.

Ha ismeretlen strukturáltadat-típusra hivatkozunk. A Google-nek és az AI-válaszmotoroknak szóló adatot generátorok állítják elő. Ha olyan típust kérünk, amire nincs generátor, a build megáll — nem ír ki csendben egy üres blokkot.

Ha egy oldalon van GYIK-jelölés, de nincs mögötte kérdés-válasz adat. Így nem lehet üres GYIK-szekció az oldalon.

A lényeg a különbség figyelmeztetés és leállás között. A figyelmeztetést el lehet nézni, főleg ha sok van belőle. A leállást nem.

03Miért a kész oldalt ellenőrizzük, és nem az adatot?

A Storylines cikkek között belső linkháló van: minden írás több kapcsolódó cikkre mutat, mindegyiknél egy mondattal, hogy miért kapcsolódik.

Ezt egy külön ellenőrzés nézi meg, és van egy fontos részlete: nem az adatfájlon fut, hanem a legenerált HTML-en. Vagyis nem azt nézi, hogy mit írtunk be, hanem hogy mi került ki ténylegesen az oldalra. Ha az adat rendben van, de egy sablonhiba miatt a linkek nem jelennek meg, az adat-alapú ellenőrzés zöldet mutatna. Ez pirosat mutat.

Amit ez az ellenőrzés megkövetel, cikkenként:

Legalább 3, legfeljebb 5 kapcsolódó cikk. Minden linkhez tartozó indoklás — ha 4 link van és 3 indoklás, az hiba. Legalább 3 másik cikkből elérhetőnek kell lennie, tehát nem lehet zsákutca. A kapcsolatoknak kölcsönösnek kell lenniük: ha A hivatkozik B-re, akkor B-nek is A-ra. Legalább 4 alcím. Link legalább egy szolgáltatásra. Érvényes strukturált adat, benne a szerző és a kiadó a céghez kötve. És a módosítás dátuma nem lehet korábbi, mint a megjelenésé.

Ha bármelyik nem teljesül, a folyamat hibával leáll, és kiírja, melyik cikknél mi a baj. Ennek a cikknek az írásakor is ez történt: az első próbálkozásnál két meglévő cikk 6 kapcsolatra ugrott az ötös felső határ helyett, és a linkeket át kellett rendezni.

04Mit csinálunk azzal, amit nem tudunk?

Ez a rész az, ami a leginkább szokatlan, és amiért a lista sosem lesz üres.

Ha egy szöveghez adat kellene, és nincs meg — például egy árazási sáv, egy évszám, egy létszám —, akkor nem írunk oda semmit. A hiányzó rész megjelölve marad a forrásban, kimarad a látogató által látott oldalból, és bekerül egy generált listába: mi hiányzik, melyik oldalról, és mit kell megadni hozzá.

Ez a lista most 32 nyitott elemet tartalmaz. Nem takarítottuk el a cikk kedvéért.

A legélesebb példa a strukturált adatnál van. A cég adatlapjához tartozik egy lista a közösségi profilokról, ami a keresők és az AI-válaszmotorok számára az egyik legerősebb azonosító jel. Ezek az URL-ek most nincsenek meg. A rendszer ezért kiszűri őket: a placeholderrel jelölt értékek egyszerűen nem kerülnek bele a strukturált adatba.

Az indok egyszerű: egy hamis vagy találomra beírt profil-URL rosszabb, mint a hiányzó. A hiányzót később pótolni lehet; a hamisat előbb ki kell javítani, és közben rossz jelet ad.

Ugyanezért került ki egy alapítói portréfotó hivatkozása is a strukturált adatból: a fájl, amire mutatott, sosem került be a repóba. A kép helye 404-et adott volna, a strukturált adat pedig egy nem létező kép URL-jét állította volna. Amíg nincs meg a fotó, a mező kimarad, a helyén pedig üres keret áll.

05Miért nem írunk hamis frissesség-dátumot?

A keresők figyelik, mikor módosult utoljára egy oldal. Ezért kísértés minden változtatásnál újraírni a dátumot — a rendszer szemében frissebbnek látszik az oldal.

Két helyen kerültük ezt el.

Az oldaltérképnél a módosítás dátuma nem kézzel beírt érték, hanem az adott forrásfájl utolsó tényleges commit-dátuma a verziókövetőből. Nem tudunk frissességet állítani ott, ahol nem történt semmi.

A cikkeknél nehezebb volt. Mind egyetlen adatfájlban él, tehát a fájl dátuma mindegyiknél ugyanaz — ha ezt írnánk ki, akkor egy designváltás vagy egyetlen cikk szerkesztése az összes írást „frissnek” jelentené. Ezért van egy külön nyilvántartás, ami cikkenként tárolja a tartalom ujjlenyomatát és azt a dátumot, amikor ez az ujjlenyomat utoljára megváltozott.

Az ujjlenyomat csak a szöveget fogja be: cím, leírás, összefoglaló, tézis, tanulságok, GYIK és a szakaszok. A design, a linkháló és a szolgáltatás-hivatkozás nem része. Ha átrendezzük a belső linkeket, az nem tartalomfrissítés, tehát nem is jelezzük annak.

06Mi az, ami most is nyitva van?

Az eddigiekből könnyű azt olvasni, hogy itt minden a helyén van. Nincs.

A 32 nyitott elem mellett négy oldal még a régi designban áll, és az átkattintáskor látszik a váltás. Több oldalon egyáltalán nincs strukturált adat. A nyelvváltó négy oldalon még ott van, pedig angol verzió nincs mögötte. A saját hibalistánkat két külön dokumentumban vezetjük, és a kettő részben átfed.

Ez a felsorolás nem szerénykedés, hanem a rendszer működésének a következménye: ha a hiányzó dolgok listába kerülnek ahelyett, hogy eltűnnének, akkor a lista látható marad. Az a rendszer, amiben soha nincs nyitott elem, jellemzően nem hibátlan — csak nem vezet listát.

→Mit érdemes megjegyezni?

A saját oldalunk buildje hibával leáll hiányzó fejléc-adatnál, hibás JSON-nál és ismeretlen schema-típusnál — nem figyelmeztet, hanem megáll.
A linkháló-ellenőrzés nem az adaton fut, hanem a legenerált HTML-en: azt nézi, ami tényleg kikerült az oldalra.
A hiányzó szövegek egy generált listába gyűlnek. Most 32 nyitott elem van rajta, és ezt a cikk írásakor sem takarítottuk el.
A placeholderrel jelölt közösségi profil-URL-eket a rendszer kihagyja a strukturált adatból: a hamis profil-hivatkozás rosszabb, mint a hiányzó.
A cikkek frissesség-dátuma tartalom-ujjlenyomatból jön, nem a fájl mentési idejéből — így egy designváltás nem tesz úgy, mintha a szöveg frissült volna.

→GYIK

Gyakori kérdések

Miért kell egy weboldalhoz ellenőrzés, ha egyszer elkészült?

Mert egy oldal ritkán készül el. Szöveg változik, új cikk kerül fel, egy szolgáltatás átnevezés miatt elromlik egy link. Ha ezeket senki nem ellenőrzi automatikusan, akkor a hibák addig maradnak bent, amíg valaki véletlenül rájuk nem talál — jellemzően egy ügyfél vagy egy kereső.

Mit jelent az, hogy a build hibával leáll?

Azt, hogy ha egy forrásfájlban hiba van, a folyamat nem generál kimenetet, és nem is figyelmeztetéssel megy tovább, hanem megszakad. Ez szándékos: a figyelmeztetést könnyű elnézni, a leállást nem. Így nem tud élesbe kerülni olyan oldal, aminek hiányzik a fejléc-adata vagy hibás a strukturált adata.

Mi történik, ha egy adat hiányzik a szövegből?

Nem találjuk ki. A hiányzó rész megjelölve marad a forrásban, és bekerül egy generált listába, ami megmutatja, mit kell még megadni és melyik oldalon. A weboldal kimenetéből viszont kimarad, tehát a látogató nem lát félkész mondatot.

→Kapcsolódó gondolatok

Amit magunknak írtunk — és ami közben elromlott Ugyanannak a rendszernek a két oldala: az egyik azt írja le, mit tagad meg, a másik azt, hogyan épült és hol romlott el.
Az AI jó segédeszköz. Döntéshozónak már kevésbé. A hiányzó adat listába tétele az a pont, ahol a gépi kimenet nem tud kitalált adatként átcsúszni.
Hol érdemes AI-t beépíteni egy marketingcsapat működésébe? Egy működés akkor nevezhető rendszernek, ha meg is tudja állítani a hibás munkát, nem csak gyorsítja.

→Olvasd tovább