Drew Systems
Referenciák

Átépítés · WordPress

Jánoskert: szövegfalas sablonoldalból gyors, ajánlatkérésre épülő kertépítő oldal

Egy solymári kertépítő cég elavult, általános sablonra épült oldalát a saját drew-core rendszeremben építettem újra, a cég saját képeivel, ajánlatkérő motorral, hozzájárulás-alapú méréssel és egy olyan élesítéssel, amelyben a régi URL-ek és a mérés is átköltöztek.

Nézd meg az élő oldalt

63 → 97

mobil teljesítmény

67 → 100

asztali teljesítmény, mind a négy kategória 100

13,8 → 2,3 mp

mobil LCP

23 / 23

régi URL megőrizve, 301-es átirányítással

Előtte és utána

A régi oldal
Az új oldal

A kihívás

A Jánoskert Solymáron működő kertépítő vállalkozás, kerttervezéssel, kertépítéssel, kertfenntartással és térkőburkolással foglalkozik Budapest környékén és Pest vármegyében. A régi oldal egy általános célú WordPress-sablonra épült, hosszú szövegfalakkal, fotókra írt, nehezen olvasható blokkokkal és egy főelemmel, amely mobilon 13,8 másodperc alatt jelent meg. A kertépítő cég legerősebb érve, a saját munkáinak látványa, elveszett a szöveg között. A cég marketingjét gondozó Kluge Marketing az oldal teljes újjáépítésére kért fel.

Az oldalcserének két rejtett csapdája is volt. Az egyik a mérés volt. A Kluge Marketing által kezelt Google Tag Manager-konténer (GA4, Google Ads, Meta Pixel) a fő konverziót a régi köszönőoldal egyetlen CSS-szelektorára mérte, így egy egyszerű sablonváltás csendben nullázta volna a leadek mérését. A másik a tárhely, 3 GB hellyel és egyetlen adatbázissal, miközben a régi oldalnak az élesítés pillanatáig működnie kellett, és vissza is kellett tudni állni rá.

A megoldás

1. Nem sablont telepítettem, hanem rendszert építettem

A vizuális irányt egy kertépítő cégekre tervezett prémium HTML-arculat adta, de ezt nem telepítettem, hanem a teljes felületet a saját drew-core sablonrendszeremben építettem újra. Kilenc újrafelhasználható szekciótípus készült (hero-slider, univerzális tartalomlista négy kártyastílussal, videós média-szöveg blokk, GYIK, ajánlatkérő panel és a többi), ezekből az oldalak admin felületről szabadon összerakhatók.

  • Szolgáltatások és referenciák saját tartalomtípusként: a négy szolgáltatás és a négy referencia saját, rendezett oldalt kapott, a referenciák összesen 54 képes galériával.
  • A cég saját anyagai a középpontban: a Jánoskert Google-dokumentumaiból és Drive-mappáiból 71 saját fotót és videót válogattam és illesztettem be. A bemutatóvideó saját tárhelyről, hang nélkül, előnézeti képpel fut, YouTube-beágyazás nélkül.
  • Egyedi ikonok: a négy szolgáltatás kézzel rajzolt, a márka színére hangolt SVG-ikont kapott.
  • Blog színkódolt kategóriákkal: hét kategória saját színnel és egy kattintható szűrősáv, amellyel a látogató témák szerint válogathat.
  • GYIK-oldal strukturált adatokkal (FAQPage) jelölve, és rendbe tett címsor-hierarchia minden fő oldalon.

2. Ajánlatkérésre építve

  • Két űrlaptípus egyetlen konfig-vezérelt motorban: kapcsolatfelvétel és ajánlatkérés, utóbbi szolgáltatás-választóval, amely automatikusan a szolgáltatás-oldalakból töltődik.
  • Leadek az adminban: minden beküldés típus szerint rendezve tárolódik, nem kell e-mailek között keresgélni.
  • Megbízható levelezés: értesítő a cégnek (a válasz gomb egyből az érdeklődőnek szól), visszaigazolás az érdeklődőnek. A levelek a cég Google Workspace fiókjából mennek ki, Gmail API-n át, DKIM-aláírással.
  • Külön köszönőoldal mindkét űrlaphoz, így a kapcsolatfelvétel és az ajánlatkérés külön konverzióként mérhető.
  • Spamvédelem CAPTCHA nélkül: rejtett csapdamező, időzár és beküldési korlát, a látogatónak semmit nem kell kattintgatnia.

3. Mérés és adatvédelem, a látogató döntése szerint

  • A Kluge Marketing teljes mérését átvittem (GTM-konténer, GA4, Meta Pixel), a konverziós triggereket pedig a régi CSS-szelektor helyett URL-alapúra állítottam, így a mérés már nem függ a markuptól.
  • Süti-hozzájárulás a márka stílusában, Google Consent Mode v2-vel, így a statisztika és a marketing csak a látogató döntése szerint fut.
  • Hibát javítottam a hozzájárulás-kezelő bővítményben is: a Facebook és az Instagram beépített böngészőjében a süti-ablak soha nem jelent meg, vagyis a Meta-hirdetésekről érkező látogatók mérése észrevétlenül elveszett volna.
  • Az adatkezelési tájékoztatót a valós, élőben ellenőrzött adatkezelések alapján írtam újra, süti-táblázattal és adatfeldolgozói listával.
  • Search Console: domain-szintű ellenőrzés, beküldött oldaltérkép, GA4-összekötés.

4. Élesítés szűkös tárhelyen, észrevehetetlen kieséssel

  • Az új oldal a régi mellett épült fel, ugyanabban az egy adatbázisban, külön táblaelőtaggal. A régi az utolsó pillanatig élt, és egy mozdulattal vissza lehetett volna állni rá.
  • A régi oldal teljes mentése fájlonkénti ellenőrzőösszeggel került biztonságba.
  • A régi képek linkjei sem törtek el: a korábbi feltöltések extra tárhely nélkül (hardlinkkel) kerültek át az új oldal alá.
  • Mind a 23 korábbi URL egyetlen átirányítással éri el az új megfelelőjét.
  • Maga a csere egyetlen könyvtárművelet volt, a látogatók számára észrevehetetlen kieséssel.
  • Élesítés után: GitHub-alapú deploy (minden módosítás verziókövetve kerül ki), heti karbantartás és heti mentés.

5. Teljesítmény, 97 és 100 úgy, hogy a mérés is fut

A PageSpeed-kör végén a mobil teljesítmény 97, az asztali 100 lett, a Google Tag Managerrel és a GA4-gyel együtt:

  • LCP-mentés: a hero-kép magas prioritású előtöltéssel, külön mobil és asztali változatban tölt, a telefon csak a saját képét tölti le.
  • Képdiéta: a széles sávokba álló fotók helyett középre vágott fekvő változatok, AVIF/WebP kiszolgálás. A mobil hero-kép 153 KB-ról 63 KB-ra fogyott.
  • Csak ami kell, amikor kell: a szekció-hátterek csak a képernyő közelébe érve töltenek, a betűtípusok a magyar karakterkészletre szűkítve (86 KB → 55 KB) és előtöltve érkeznek.
  • Mérés a kritikus útvonalon kívül: a mérőkódok az oldal betöltése után indulnak, így a statisztika megmarad, de a főelem festését nem lassítják.
  • Stabil elrendezés: a slider alapstílusa kritikus CSS-ként érkezik, így betöltéskor semmi nem ugrál (CLS 0).

Az eredmény

MutatóElőtteUtána
Mobil teljesítmény6397
Asztali teljesítmény67100
Mobil LCP13,8 mp2,3 mp
Asztali LCP5,2 mp0,8 mp
Mobil FCP3,8 mp1,2 mp
Mobil Speed Index5,5 mp1,6 mp
Teljes blokkolási idő (asztali)220 ms40 ms
Teljes blokkolási idő (mobil)80 ms120 ms
CLS00
Kisegítő lehetőségek95100
Bevált módszerek100100
SEO100100
Ügynöki böngészés (AI-ügynökök)1/42/2
Előtte: mobil 63
Utána: mobil 97
Előtte: asztali 67
Utána: asztalin mind a négy kategória 100

Nyolc mért kategóriából hét 100 pontos, egy 97, a mobil főelem pedig 13,8 helyett 2,3 másodperc alatt jelenik meg. Közben semmi nem tűnt el, ami addig működött. A régi linkek, a mérés és a leadek útja is megmaradt, csak most gyorsan, rendezetten és a látogató döntése szerint.

Két őszinte megjegyzés a számokhoz

Az „előtte” mérés a régi oldal archivált, bitre azonos másolatán készült, mert a régi oldal az élesítéskor megszűnt. Ez a másolat erősebb szerveren és mérőkódok nélkül futott, vagyis a valódi kiinduló állapot inkább még lassabb volt. Ugyanezért nőtt papíron a mobil blokkolási idő 80-ról 120 ms-ra, mert az új oldalon már fut a hozzájárulás-alapú mérés, az archív példányon nem. A 120 ms bőven a Google által jónak tartott 200 ms-os határ alatt van.

Tech stack

WordPress · drew-core (saját fejlesztésű sablonrendszer, ACF) · egyedi lead-motor · Yoast SEO Premium · WP Rocket · Imagify (AVIF/WebP) · Google Consent Mode v2 · Google Tag Manager, GA4 · WP Mail SMTP (Gmail API, DKIM) · GitHub Actions deploy · Együttműködés és marketing: Kluge Marketing

Lecserélnéd a régi oldalad, de félsz, hogy elvész a mérés és a Google-helyezés?

Nem kell választanod. Nézzük meg együtt, mit kell megőrizni, és mit érdemes újraépíteni.