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

01Field Notes

Hol 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.

02Field Notes

Mit 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.

03Field Notes

Mié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.

04Field Notes

Mit 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.

05Field Notes

Mié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.

06Field Notes

Mi 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.