„SEO-barát” weboldalt ígér az ajánlat? Mit jelentsen ez pontosan?

Scheo · 2026-11-13 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A weboldal-ajánlatok jó részében ott áll a „SEO-barát” jelző, egy sorban a „reszponzív” és a „modern” szavakkal. A baj vele annyi, hogy senki nem tudja számon kérni. Ha az átadás után nem jönnek a keresések, a fejlesztő nyugodtan mondhatja, hogy az oldal SEO-barát, hiszen a szónak nincs mérhető tartalma. Ez a cikk lefordítja a jelzőt ellenőrizhető tételekre, és ad egy listát, amit bemásolhatsz az ajánlatkérésbe vagy a szerződés mellékletébe.

A szövegben három jelölést használunk. A hivatalosan igazolt állítás a Google Search Central vagy más elsődleges dokumentáció tartalma. A saját tapasztalat az, amit weboldalak átvételénél és átadásánál rendszeresen látunk. A szakmai feltételezés olyan következtetés, amit jó okkal gondolunk, de nem bizonyítható minden esetre.

Mit jelent valójában a „SEO-barát” weboldal?

A „SEO-barát” kifejezésnek nincs hivatalos meghatározása, ezért csak akkor ér valamit, ha az ajánlat felsorolja mögötte a konkrét tételeket, és mindegyikről az átadáskor eldönthető, hogy megvan-e. A Google a saját útmutatójában leírja, mit érdemes egy oldalon rendben tartani (hivatalosan igazolt), de „SEO-barát” minősítést nem ad ki, és tanúsítvány sincs róla.

A gyakorlatban a jelző két egészen különböző dolgot takarhat. Az egyik a technikai alap, vagyis az, hogy a keresőrobot el tudja érni, értelmezni és indexelni az oldalt. A másik a folyamatos keresőoptimalizálás, ami tartalomírásból, kulcsszókutatásból, linképítésből és mérésből áll. Az induló weboldal elkészítése jellemzően csak az elsőt fedi le, a második külön munka. Ha az ajánlat ezt nem választja szét, könnyen lehet, hogy mindkét fél mást ért alatta (saját tapasztalat).

Miért kell egyedi title és meta leírás minden oldalra?

Minden aloldalnak saját, a tartalmát leíró title tagje és meta leírása legyen, mert a Google ezekből is dolgozik, amikor a találati listában megjeleníti az oldalt. A Search Central útmutatója kifejezetten azt kéri, hogy a címek egyediek és leíróak legyenek (hivatalosan igazolt).

A leggyakoribb hiba, amit átvételkor látunk, hogy minden aloldal címe ugyanaz, például csak a cégnév, vagy a sablon alapértelmezett szövege maradt benne (saját tapasztalat). Egy jól kitöltött cím így néz ki egy kazánszervizes aloldalon.

<title>Kazánszerviz és karbantartás Győrben | Példa Kft.</title>

<meta name='description' content='Gázkazánok éves karbantartása és javítása Győrben és környékén. Időpontot telefonon vagy az űrlapon kérhetsz.'>

A Google a meta leírást nem mindig használja, sokszor a kereséshez jobban illő részletet emel ki az oldalról, és a címet is átírhatja (hivatalosan igazolt). A jól megírt cím és leírás ettől még jó eséllyel többször jelenik meg változatlanul, ezért az ajánlatban elvárható, hogy a fejlesztő kitöltse és szerkeszthetővé tegye őket.

Hogyan ellenőrizd a címsorszerkezetet?

Minden oldalon egy fő címsor (H1) legyen, amely kimondja, miről szól az oldal, alatta pedig H2 és H3 címsorok tagolják a tartalmat logikus sorrendben. A címsor a szöveg szerkezetét jelöli, a betűméretet a dizájn állítja be.

A Google szerint a címsorok sorrendje önmagában nem rangsorolási tényező, a jó szerkezet viszont segíti a tartalom megértését (hivatalosan igazolt). A W3C akadálymentességi irányelvei is a logikus címsor-hierarchiát kérik, mert a képernyőolvasók erre építenek. Gyakori sablonhiba, hogy a logó vagy a lábléc szövege kap H1-et, a valódi cím pedig egy egyszerű bekezdés nagy betűvel (saját tapasztalat).

Böngészőben jobb kattintással nyisd meg az „Elem vizsgálata” nézetet, és keresd meg a <h1> elemet. Ha több van, vagy egy sincs, kérdezz rá.

Milyen legyen az URL-felépítés?

Az URL legyen rövid, olvasható, ékezet nélküli, kötőjellel tagolt, és tükrözze az oldal helyét a szerkezetben. A Google azt javasolja, hogy az URL-ben értelmes szavak álljanak azonosítószámok helyett (hivatalosan igazolt).

• Jó példa a /kazanszerviz/gazkazan-karbantartas/ forma.
• Rossz példa a /?page_id=482 vagy a /uj-oldal-2-masolat/, ami a szerkesztőben véletlenül maradt így.

Az URL-szerkezetet érdemes még a tartalom feltöltése előtt rögzíteni, mert az utólagos átnevezés minden esetben újabb átirányítást igényel. A www és a www nélküli változat közül is egyet kell kiválasztani, a másik arra irányítson, és az oldal kizárólag HTTPS-en legyen elérhető.

Kell-e átirányítási terv, ha már van régi weboldalad?

Igen, ha a régi oldalad már kap forgalmat a keresőből, az új oldal indulásához átirányítási terv kell, amely minden régi URL-hez megmondja, melyik új címre visz 301-es átirányítással. Enélkül a régi címek 404-es hibát adnak, és a korábban felépült helyezések jó része elveszhet.

A Google webhely-áthelyezési útmutatója az állandó (301-es vagy 308-as) átirányítást javasolja, és azt kéri, hogy ezeket legalább egy évig tartsd fenn (hivatalosan igazolt). Ha közben domain is változik, a Search Console címváltoztatási eszközét is érdemes használni.

A terv a gyakorlatban egy kétoszlopos táblázat, a bal oldalon a régi URL, a jobb oldalon az új. Apache szerveren egy sor így néz ki a .htaccess fájlban.

Redirect 301 /kazan-javitas.html /kazanszerviz/

A régi URL-ek listáját a Search Console Teljesítmény jelentéséből, a régi oldaltérképből és a GA4 céloldal-riportjából lehet összeszedni. Saját tapasztalatunk, hogy ez a tétel marad ki leggyakrabban az ajánlatokból, és ez okozza a legnagyobb forgalomvesztést új oldal indulásakor. Mindent ráirányítani a főoldalra rossz megoldás, a Google ezt sokszor puha 404-ként kezeli (hivatalosan igazolt).

Mennyire számít a sebesség, és hogyan kérd számon?

A sebességet a Core Web Vitals mutatókkal érdemes számon kérni, mert ezekre a Google nyilvános küszöbértékeket közöl. A jónak számító határ az LCP-nél legfeljebb 2,5 másodperc, az INP-nél legfeljebb 200 ezredmásodperc, a CLS-nél legfeljebb 0,1 (hivatalosan igazolt).

A Google szerint ezek a mutatók a rangsorolásban is szerepet kapnak, de a releváns tartalom fontosabb náluk (hivatalosan igazolt). A lassú oldal ettől még elküldi a látogatót. Az ajánlatban érdemes rögzíteni, hogy az átadáskor a PageSpeed Insights a főoldalra és két fő aloldalra mobilnézetben milyen eredményt mutasson, és hogy a képek tömörítve, modern formátumban (WebP vagy AVIF) kerüljenek fel.

Friss oldalnál a laboradat a mérvadó, mert valós felhasználói adat csak elég látogatottság után gyűlik. Szakmai feltételezésünk, hogy egy kevés látogatót kapó új oldal hónapokig nem kap terepi adatot, ezért a labormérést csatold az átadási jegyzőkönyvhöz.

Elég, ha az oldal „reszponzív”?

Az kevés, ha a mobilnézet csak összenyomja az asztali oldalt. A mobilos változatnak ugyanazt a tartalmat kell tartalmaznia, mint az asztalinak, mert a Google az oldalakat elsősorban a mobilos nézet alapján indexeli (hivatalosan igazolt).

Átadáskor nézd meg a saját telefonodon is. Olvasható-e a szöveg nagyítás nélkül, elég nagyok-e a gombok, nem csúszik-e ki semmi oldalra, és ott van-e mobilon is minden szövegrész, ami asztali gépen látszik. Gyakori, hogy a sablon mobilon elrejt szekciókat, és ezzel a tartalom egy része kikerül abból, amit a Google lát (saját tapasztalat).

Mi a strukturált adat, és mikor kell?

A strukturált adat egy géppel olvasható leírás az oldal tartalmáról (cégadatok, termék, cikk, GYIK), amelyet a Schema.org szókészletével, jellemzően JSON-LD formában teszünk az oldal kódjába. Egy helyi vállalkozásnál a LocalBusiness vagy annak szűkebb típusa, cikkeknél az Article, webshopnál a Product a szokásos kiindulás.

A Google leírja, hogy a strukturált adat segíti a tartalom megértését, és bizonyos kiemelt találati megjelenésekhez feltétel, de a megjelenést a megjelölés önmagában nem idézi elő (hivatalosan igazolt). A kódot a Google Rich Results Test eszközével és a Schema.org validátorával lehet ellenőrizni. Az ajánlatban elég annyit kérni, hogy a cégadatok (név, cím, telefonszám, nyitvatartás) strukturált adatként is szerepeljenek, és egyezzenek a Google Cégprofilban szereplőkkel.

Szakmai feltételezés, hogy az ellentmondásmentes cégadat a mesterséges intelligenciás keresőfelületeken is segítheti a vállalkozás helyes azonosítását. Erre nincs nyilvános mérés, ezért alapként kezeld, eredményt ne várj tőle.

Miért az induló oldal része a GA4 és a Search Console bekötése?

Mert mérés nélkül nem derül ki, működik-e az oldal a keresőben. A Google Search Console mutatja meg, mely oldalak vannak indexelve, milyen keresésekre jelensz meg, és milyen technikai hibát talált a Google. A GA4 azt mutatja meg, mit csinálnak a látogatók az oldalon.

Az átadáskor ezeknek kell meglenniük:

• A Search Console-tulajdon a te Google-fiókodon van, tulajdonosi jogosultsággal, a fejlesztő legfeljebb felhasználóként szerepel benne.
• Az oldaltérkép (sitemap.xml) be van küldve, és a Search Console sikeresnek jelzi.
• A GA4-tulajdon szintén a te fiókodon van, és be van állítva legalább a legfontosabb konverzió, például az űrlapküldés vagy a telefonszámra kattintás.
• A GA4 és a Search Console össze van kapcsolva.
• Az oldalon van süti-hozzájárulás kezelése, mert az EU-ban a mérőkódok jellemzően hozzájáruláshoz kötöttek.

Gyakran látjuk, hogy a fejlesztő a saját fiókjára regisztrálja ezeket, és a közös munka végén a megrendelő elveszíti az adatait (saját tapasztalat). A tulajdonjogot ezért mondd ki a szerződésben is.

Mi szokott még kimaradni az ajánlatból?

Néhány apróság csak akkor kerül elő, ha baj van. A fejlesztői (teszt) oldalon a fejlesztő gyakran beállítja, hogy a kereső ne indexelje. Ez helyes, de ha élesítéskor bent marad a noindex jelölés vagy a robots.txt tiltás, az oldal hetekig nem jelenik meg a Google-ben (saját tapasztalat). Ide tartozik még a képek alternatív szövege, a saját 404-es oldal, a kanonikus címek (rel='canonical') helyes beállítása, és több nyelv esetén a hreflang jelölés.

Mi tartozik az induló weboldalhoz, és mi a folyamatos SEO-munka?

Az induló weboldalhoz az a technikai és szerkezeti alap tartozik, ami egyszer elkészül és az átadáskor ellenőrizhető. A folyamatos SEO-munka minden, ami az indulás után ismétlődik, mérésre épül és hónapról hónapra változik. A két kört érdemes külön sorban szerepeltetni az ajánlatban.

Induló weboldal (egyszeri, átadáskor ellenőrizhető)

• Egyedi title és meta leírás minden aloldalon, szerkeszthető formában.
• Oldalanként egy H1, logikus H2 és H3 szerkezet.
• Rögzített, olvasható URL-szerkezet, egységes www vagy www nélküli változat, HTTPS.
• Átirányítási táblázat a régi oldal minden forgalmat kapó URL-jére, élesítés napján bekapcsolva.
• PageSpeed Insights mérés mobilon az átadáskor, tömörített képekkel.
• Mobilon is teljes tartalom, kézzel átnézve.
• Strukturált cégadat, a Google Cégprofillal egyezően.
• Search Console és GA4 a megrendelő fiókján, oldaltérkép beküldve, alap konverzió beállítva.
• A teszt oldal indexelési tiltása élesítéskor eltávolítva.
• Képek alternatív szövege, saját 404-es oldal, kanonikus címek.

Folyamatos SEO-munka (külön megállapodás)

• Kulcsszókutatás és a tartalomterv ehhez igazítása.
• Új tartalmak, cikkek írása és a meglévők frissítése.
• A Search Console hibáinak és indexelési jelentéseinek rendszeres átnézése.
• Belső linkelés bővítése és hivatkozásszerzés.
• Google Cégprofil kezelése, értékelések megválaszolása.
• Havi mérés és riport arról, mely oldalak hoznak érdeklődőt.

Ha egy ajánlat a folyamatos munkát ígéri, de csak egyszeri tételként szerepel, kérdezz rá, ki és milyen gyakran végzi el. Ha pedig az induló tételek közül hiányzik több is, a „SEO-barát” jelző az ajánlatban nem fed le semmit.

Hogyan írd bele az ajánlatkérésbe vagy a szerződésbe?

A legegyszerűbb, ha a fenti induló listát szó szerint beteszed az ajánlatkérésbe, és azt kéred, hogy a fejlesztő tételenként jelölje, mit vállal, mit nem, és mit csak külön megrendelésre. A szerződés mellékleteként ugyanez a lista lehet az átadás-átvétel feltétele.

1. Küldd el a listát az ajánlatkéréssel együtt, és kérj tételes választ.
2. Kérd, hogy az ajánlat különítse el az egyszeri és a folyamatos munkát.
3. Rögzítsd, hogy a Search Console, a GA4 és a domain a te nevedre szól.
4. Ha van régi oldal, kérd az átirányítási táblázatot még élesítés előtt jóváhagyásra.
5. Az átadáskor menj végig a listán, és csak a pipák után írd alá az átvételt.

Egy ilyen lista nem jelent helyezést a Google-ben, arra senki nem tud felelősséget vállalni. Annyit ér el, hogy a későbbi keresőoptimalizálás nem az alapok javításával indul.

Mit tegyél, ha már kaptál egy ajánlatot?

Tedd a kapott ajánlat mellé ezt a listát, és nézd meg, hány tételt nevez meg kifejezetten. Ha az ajánlatban csak a „SEO-barát” szó szerepel, kérj tételes kiegészítést még a megrendelés előtt. Ha bizonytalan vagy abban, mit fed le egy megfogalmazás, szívesen átnézzük veled a kapott ajánlatot, és megmondjuk, mely pontokra kérdezz még rá a fejlesztőnél.

Források és további olvasnivalók

• Google Search Central, Keresőoptimalizálási (SEO) útmutató kezdőknek
• Google Search Central, Webhely áthelyezése URL-módosítással
• Google Search Central, Címlinkek és kivonatok szabályozása a keresési eredményekben
• Google Search Central, Mobilközpontú indexelés
• Google Search Central, Az oldalélmény és a Core Web Vitals
• Google Search Central, Bevezetés a strukturált adatokba
• web.dev, Core Web Vitals mutatók és küszöbértékek
• Schema.org, LocalBusiness típus
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2
• Google Analytics súgó, A GA4 és a Search Console összekapcsolása