Weboldal technikai átvilágítás: mit nézek meg és mit kapsz tőle

Az első kör mindig a sebesség, mert itt a legközvetlenebb az üzleti hatás. A Google PageSpeed Insights eszközével mérek, mobilon és asztali nézetben is — a kettő közül a mobil a szigorúbb mérce. A mobilteszt gyengébb processzort és lassabb hálózatot szimulál, ráadásul a Google az oldalad mobilváltozatát indexeli és rangsorolja. Asztali 90-es pontszám mellett simán lehet mobilon 40-es — a legtöbb oldalon pedig a látogatók többsége pont ezt a mobilos élményt kapja.

A pontszámnál fontosabb a három Core Web Vitals mutató, mert ezek valós felhasználói élményt mérnek, és a Google megerősítette, hogy a rangsorolásban is szerepet játszanak:

Az átvilágításban nem a számot adom vissza, hanem az okot mögötte: optimalizálatlan képek, renderelést blokkoló szkriptek, lassú szerverválasz (TTFB) vagy egyszerűen túl sok egymásra pakolt bővítmény (plugin). Ugyanaz a 40-es mobilpontszám tízféle okból jöhet — a javítás ára és sorrendje pedig az októl függ.

Ez nem behatolásteszt (penetration test), hanem alaphigiéniai ellenőrzés. Tapasztalatom szerint a legtöbb oldal ezen a szinten bukik el, nem kifinomult támadásokon.

• HTTPS mindenhol: van-e vegyes tartalom (mixed content), rendben van-e az átirányítás HTTP-ről, nem jár-e le rövidesen a tanúsítvány.
• Biztonsági fejlécek (security headers): HSTS, tartalombiztonsági szabályok, kattintás-eltérítés (clickjacking) elleni védelem — pár sornyi beállítás, mégis az oldalak nagy részéről hiányzik.
• Látható verzióinformációk: kiolvasható-e kívülről, milyen WordPress-, PHP- vagy plugin-verzió fut. Egy támadónak ez térkép: pontosan tudja, melyik ismert sérülékenységet érdemes próbálnia.
• Admin-felület: az alapértelmezett útvonalon, mindenféle védelem nélkül érhető-e el a belépési oldal.

Tisztázzuk: ez technikai SEO, nem kulcsszó-stratégia. Nem azt mondom meg, milyen témákra írj cikket — azt nézem meg, hogy amit már megépítettél, azt a Google egyáltalán látja-e és jól érti-e.

• Indexelhetőség: nincs-e véletlen noindex beállítás az oldalon. Meglepően gyakori — jellemzően úgy marad ott, hogy a fejlesztői (staging) változatból élesítettek, és a pipát senki nem vette ki.
• robots.txt és sitemap.xml: léteznek-e, jót mondanak-e a keresőnek, és a sitemap tényleg a friss tartalmat tükrözi-e.
• Meta-alapok: title és description minden fontos oldalon, duplikációk nélkül.
• Oldalstruktúra: címsor-hierarchia, belső linkelés, canonical-beállítások — ezekből érti meg a kereső, mi miről szól.

Ezek egyike sem hoz önmagában első helyet. De ha valamelyik hibás, a legjobb tartalom is láthatatlan maradhat.

Megnézem, min fut az oldal, és az mennyire időzített bomba. Elavult WordPress-mag, évek óta nem frissített PHP, ismert sérülékenységű bővítmények — ezek nem elméleti kockázatok: automatizált botok keresik őket tömegesen, célzott támadó sem kell hozzá.

A másik gyakori minta a túlbonyolítás: negyvennél több plugin, három egymást átfedő gyorsítótár-megoldás, oldalépítő (page builder) plusz a rá épített kiegészítők hegye. Az Elementorral például gyorsan lehet mutatós oldalt összerakni — erre való, és erre jó is. Nagyobb, éles oldalon viszont gyakran ő maga lesz a szűk keresztmetszet: felduzzasztott HTML-t generál, és minden kiegészítő tovább lassít. Ha az átvilágítás azt mutatja, hogy a builder a fő fék, arra létezik célzott megoldás: Elementor-kiváltás.

Ide tartozik a gondozatlanság is: mikor frissült utoljára bármi, van-e működő, visszaállítható mentés. Ha kiderül, hogy az oldalra évek óta senki nem néz rá, az önmagában a legnagyobb kockázat — erre való a rendszeres karbantartás.

Ez nem marketing-elemzés. Technikai szemmel megyek végig azon az úton, amin a látogatóból vásárló lenne: főoldal, termék- vagy szolgáltatás-oldal, kosár vagy ajánlatkérő űrlap, beküldés. Ahol ez az út technikailag akad, ott pénz folyik el.

• Csendben hibázó űrlap: a látogató „sikeres küldés” üzenetet lát, az e-mail viszont sosem érkezik meg hozzád. A legalattomosabb hiba, mert hetekig-hónapokig észrevétlen maradhat.
• Lassú vagy hibázó pénztár (checkout): webshopban gyakran itt csúcsosodik ki minden korábbi probléma — a fizetés pillanatában elakadó oldal a legdrágább hibatípus, amit ismerek.
• Mobilhibák: eltakart gomb, a fő felhívás (CTA) fölé úszó cookie-sáv, nem kattintható elemek — asztali gépről nézve minden rendben, mobilról használhatatlan.
• JavaScript-hibák: a böngészőkonzolban csendben elszálló szkript, ami épp a terméklista-szűrőt, a kosárgombot vagy a variáció-választót töri el.

A folyamat szándékosan egyszerű, és nem kér tőled se hozzáférést, se elköteleződést:

1. 01Beadod az oldalad címét az audit-oldalon — fél perc.
2. 021–2 munkanapon belül megkapod az előzetes összefoglalót: mit találtam, prioritás szerint rendezve.
3. 03Ha szeretnéd, foglalsz egy rövid hívást, ahol átbeszéljük — kötelezettség nélkül.

A kézzelfogható eredmény egy prioritált problémalista, üzleti hatással: „ez rendelést veszít”, „ez Google-helyezést ront”, „ez biztonsági kockázat”. Nem 40 oldalas, generált PDF-halandzsa, amit senki nem olvas el, hanem egy lista, amiből nem technikai döntéshozóként is látod, mi éget és mi várhat. Azt is megírom, ha valamit házon belül vagy a meglévő fejlesztőddel egyszerűbben megjavíttathatsz.

És hogy mire nem való: ez nem marketing-audit, nem hirdetés-elemzés és nem tartalom-stratégia. Nem mondja meg, jó-e a szövegezésed, vagy hova költsd a hirdetési keretet — azt mondja meg, hogy a technikai alap, amire mindezt építed, stabil-e. Tapasztalatom szerint a legtöbb „valami nem oké az oldallal” érzés mögött két-három konkrét, mérhető és javítható ok áll. Az átvilágítás ezt a tünetszintű bizonytalanságot cseréli le okokra és sorrendre — onnantól már a te döntésed, mit javítasz, mit hagysz, és mihez kérsz segítséget.