Több mint öt éve építek weboldalakat, és azt hittem, a technikai alapokat már álmomból is tudom. Aztán elkezdtem AI-val dolgozni, és kiderült, hogy van pár dolog, amit évek óta rutinból csináltam, pedig lehetett volna jobban is.
Az AI nem helyettem építette meg az oldalakat. Inkább úgy működött, mint egy kolléga, aki ránéz a munkádra, és megkérdezi: ezt biztos így akartad? Ebben a cikkben összeszedtem, mik voltak ezek, és mit jelentenek neked, ha weboldalt csináltatnál.
A gyorsító plugin, ami nem mindig gyorsít
Évekig az első dolgom egy új oldalnál az volt, hogy feltelepítettem a WP Rocketet. Bekapcsoltam szinte mindent, és vártam, hogy villámgyors legyen az oldal.
Csakhogy nem mindegy, milyen szerveren fut a weboldal. Ha a tárhely LiteSpeed szerveren van, akkor a LiteSpeed saját cache megoldása sokkal jobban teljesít, mert közvetlenül a szerverrel dolgozik együtt. Van, ahol ehhez jön még egy Redis nevű réteg, ami az adatbázis lekéréseit gyorsítja. Ezek nem vetélytársak, hanem különböző szinteken dolgoznak, és az a jó beállítás, ami a konkrét tárhelyhez illik.
Volt egy eset, amikor a gombok mobilon rossz helyre görgettek az oldalon. Kiderült, hogy a gyorsító plugin menet közben töltötte be a képeket és a betűtípusokat, ezért az oldal elcsúszott, mire a görgetés célba ért. Asztali gépen minden tökéletes volt, telefonon viszont nem.
A másik tanulság, hogy a gyorsítótár nem egy réteg, hanem több. Van a pluginé, a tárhelyé, néha egy Cloudflare is előtte, és a Bricks is tárol saját CSS-t. Ha az egyiket üríted, a másik még mutathatja a régi verziót.
Hogy neked melyik megoldás illik, az attól függ, milyen szerveren fut az oldalad:
| Szerver vagy tárhely típusa | Ajánlott megoldás | Amire figyelj |
|---|---|---|
| LiteSpeed szerver | LiteSpeed Cache plugin | Ingyenes, és közvetlenül a szerverrel dolgozik, itt általában ez a legerősebb |
| Apache szerver | WP Rocket | Fizetős, de egyszerű beállítani, sokszor alapból jó eredményt ad |
| Nginx szerver | WP Rocket, vagy a tárhely saját szerveroldali cache-e | Ha a tárhely ad saját cache-t, azt érdemes használni, és nem duplázni |
| Menedzselt WordPress tárhely | A tárhely beépített cache megoldása | Egyes tárhelyek nem is engedik a külön cache plugineket |
| Redis (ha a tárhely kínálja) | Object cache kiegészítésnek | Nem helyettesíti az oldal cache-t, hanem mellette gyorsítja az adatbázist |
| Cloudflare | CDN réteg bármelyik mellé | Ez is tárol, ezért módosítás után ezt is üríteni kell |
Hogy te milyen szerveren vagy, azt a tárhelyszolgáltatód ügyfélszolgálata pár perc alatt megmondja. Aki kicsit bátrabb, a böngésző fejlesztői eszközeiben is megnézheti: a Network fülön az oldal válaszában a server sor elárulja, például LiteSpeed vagy nginx.
Mit jelent ez neked? Azt, hogy a gyors weboldal nem egy plugin feltelepítéséből lesz, hanem abból, hogy valaki megnézi, min fut az oldalad, és ahhoz állítja be.
Kétszer ugyanaz a SEO
Ez egy kicsit kínos. A Bricks Builder saját SEO beállításait is kitöltöttem, és mellette a SEOPress plugint is. Úgy gondoltam, a kettő együtt biztosan jobb.
Nem jobb. Az oldal forráskódjában kétszer jelent meg a cím, a leírás és a megosztási kép. Amikor valaki megosztotta a cikket Facebookon, nem volt biztos, melyik képet és címet fogja mutatni. A Google is két, néha eltérő jelzést kapott ugyanarról az oldalról.
A megoldás egyszerű: egy forrás legyen. Nálam ma a SEOPress kezeli a SEO-t, a Bricks saját SEO kimenete ki van kapcsolva. Aki a technikai részletekre kíváncsi, a Novamira cikkemben leírtam, pontosan hogyan.
Ami a Google-nek szól: a schema
Egy amerikai fogászati ügyfél oldalán láttam, hogy a szolgáltatás oldalak több ezer megjelenést kaptak a Google-ben, de szinte senki nem kattintott rájuk. Az AI-val végignézve kiderült, hogy az oldalon csak egy általános cégleírás volt a Google számára, minden oldalon ugyanaz. Az egyes szolgáltatásokról a Google gyakorlatilag nem tudott semmit.
Ezt hívják schema jelölésnek. Ez egy láthatatlan réteg az oldalon, ami elmondja a keresőnek, hogy ez egy szolgáltatás, ez egy GYIK, ez egy blogcikk. Ma már nemcsak a Google, hanem az AI keresők is ebből tájékozódnak.
Ugyanitt derült ki, hogy a lenyíló fülekbe rejtett szöveg és a sehova sem mutató gombok is rontják az eredményt. Apróságnak tűnnek, de összeadódnak. A schema egy másik buktatójáról az Elementor FAQ schema hibáról szóló cikkemben írtam.
WebP a képeknek, WebM a videóknak
Azt régóta tudtam, hogy a képeket WebP formátumban érdemes feltölteni, mert töredék méretűek ugyanolyan minőségben. Erről külön cikkem is van: képek optimalizálása weboldalakhoz.
Amit nem tudtam: a videóknak is van ilyen formátuma. Ez a WebM. Egy háttérvideónál ez több tíz megabájt különbség is lehet, és ez mobilnet mellett nagyon sokat számít. A biztonság kedvéért MP4 is marad tartaléknak, így a régebbi eszközökön is lejátszható.
Közben egy másik dolgot is kiváltottam. Évekig fizettem egy képtömörítő előfizetésre, aztán AI-val összeraktam egy saját eszközt, ami ugyanazt tudja, sőt AVIF formátumban is ment, és be lehet állítani, hány kilobájtos legyen a kép. Nincs havidíj, nincs limit.
Az ellenőrzés, ami régen órákig tartott
Talán ez a legnagyobb változás. Régen egy oldal átadás előtti ellenőrzése azt jelentette, hogy oldalanként végigkattintgattam, olvasgattam, és valljuk be, néha kimaradt valami. Egy hiányzó képleírás, egy rossz link, egy mobilon szétcsúszó szekció.
Ma az AI percek alatt végignézi az összes oldalt. Minden kép leírását, minden meta adatot, minden linket, a mobil nézetet, és akár élesben is teszteli az űrlapot, hogy tényleg megjön-e a levél. Nincs olyan, hogy elfáradok a tizedik aloldalnál.
Ma a munkám nagy része minőségellenőrzés
A munkám nagy részében ma a Novamira segít. Ez egy eszköz, amivel az AI közvetlenül a WordPress oldalon dolgozik: szerkeszt, javít, beállít. Hogy ez hogyan néz ki a gyakorlatban, azt ebben a cikkben mutattam meg egy valódi projekten.
Ettől viszont nem lett kevesebb a munkám, csak máshol van. Az időm nagy része ma arra megy, hogy ellenőrizzem, amit az AI csinált. Jó-e a szín, stimmel-e a szöveg, működik-e egy régebbi telefonon is. Az AI egyre jobb ebben, de a döntés és a felelősség az enyém marad.
Az idő, amit az AI megspórol, nálam az ellenőrzésbe megy. Ettől lesz alaposabb az oldal, nem attól, hogy gyorsabban kész van. Arról, hogy miért nem lesz ettől tízezer forintos egy weboldal, itt írtam bővebben.
Mit jelent ez neked, ha weboldalt csináltatnál?
Érdemes megkérdezni a fejlesztődtől, hogy
- a gyorsítás a tárhelyedhez van-e beállítva,
- egy helyről jön-e a SEO,
- van-e oldalszintű schema,
- és milyen formátumban kerülnek fel a képek és videók.
Ha ezekre magabiztos választ kapsz, jó kezekben vagy.
Ha kíváncsi vagy, hogyan néz ki ez a gyakorlatban, nézd meg a munkáimat, vagy kérj ajánlatot, és megnézzük együtt, mire van szüksége a te oldaladnak.
Frequently asked questions
Melyik a legjobb gyorsító plugin WordPresshez?
Nincs egy legjobb. LiteSpeed szerveren általában a LiteSpeed Cache, más szervereken sokszor a WP Rocket a jó választás. A tárhely dönti el, nem a plugin népszerűsége. A fenti táblázatban összeszedtem, melyik szerverhez mit ajánlok.
Használhatok két SEO plugint egyszerre?
Nem érdemes. Duplán jelennek meg a címek és leírások, ami összezavarja a Google-t és a közösségi megosztást. Mindig egy forrás kezelje a SEO-t.
Mi az a WebM formátum?
Egy videóformátum, ami az MP4-nél jóval kisebb fájlméretet ad hasonló minőségben. Olyan a videóknak, mint a WebP a képeknek.
Olcsóbb egy weboldal, ha AI-val készül?
Nem feltétlenül. Az AI gyorsítja a munkát, de az ellenőrzés, a döntések és a felelősség továbbra is emberi feladat. Nálam a megspórolt idő alaposabb ellenőrzésre megy.
