Weboldal készítés székesfehérvár: gyakorlati útmutató Székesfehérváron

Scheo · 2026-08-14 · Frissítve: 2026-10-03 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha azt írod a keresőbe, hogy weboldal készítés Székesfehérváron, valószínűleg nem a reszponzív dizájn elméletére vagy kíváncsi. Sokkal inkább arra, hogy kihez fordulj, mi lesz a te dolgod a projektben, meddig tart az egész, és mi az a néhány pont, aminél ha engedsz, később fizetsz érte időben és bosszúságban. Ez a cikk végigmegy a teljes folyamaton, a döntés előkészítésétől az élesítés utáni harmadik hónapig.

A szövegben végig jelölöm, mi az, ami hivatalosan igazolt (gyártói vagy szabványdokumentáció alapján), mi a saját tapasztalat a fehérvári és Fejér vármegyei munkából, és mi a szakmai feltételezés. Ez a három nem ugyanannyit ér, és egy weboldalprojektben pont az a drága, ha összekevered őket.

Mit keres pontosan az, aki weboldal készítést keres Székesfehérváron?

Aki ezt beírja, nem cikket keres, hanem kivitelezőt és biztonságérzetet: azt akarja tudni, kire bízhatja az oldalt, mi lesz a saját feladata, és mikorra lesz kész. A településnév a keresésben szinte mindig bizalmi jelzés, nem feltétlenül szó szerinti földrajzi elvárás.

A gyakorlatban három tipikus helyzet áll a keresés mögött. Az első a most induló vállalkozás, akinek egyáltalán nincs weboldala, csak egy Facebook-oldala vagy egy fél mondat a cégjegyzékben. A második az, akinek van oldala, de évek óta nem nyúlt hozzá senki: mobilon szétesik, a nyitvatartás elavult, az űrlap pedig egy olyan email-címre megy, amit már nem néz senki. A harmadik pedig az, aki már kapott két-három ajánlatot, és azt próbálja megérteni, miért különböznek annyira.

Saját tapasztalat: a harmadik csoport a legnagyobb. Az ajánlatok közti eltérés általában nem a dizájnból jön, hanem abból, hogy ki mit ért bele: tartalomírást, fotót, mérést, karbantartást, vagy csak a puszta legyártást.

Mielőtt bárkinek írnál, öt dolgot érdemes összeszedned. Ezekkel az első beszélgetés is másfél óráról húsz percre rövidül:

• Egy mondatban: mit csinálsz, és kinek.
• Mit tegyen a látogató az oldalon (hívjon, írjon, foglaljon, jöjjön be).
• Mely szolgáltatásaidat akarod külön kiemelni.
• Kinél van most a domain és a tárhely, és be tudsz-e lépni.
• Van-e valódi fotód a munkádról, a csapatról vagy az üzletről.

Miért kérnek sokan helyi fejlesztőt, ha a munka távolról is elvégezhető?

Egy weboldal technikailag távolról is elkészíthető, a helyi kötődés viszont két ponton mégis számít: a tartalom hitelességében és a felelősségvállalásban.

A tartalom oldalán egy székesfehérvári vállalkozásnál nem mindegy, hogy az oldal tud-e valamit a valóságról. Hogy a vevőid nagy része a belvárosból, Öreghegyről vagy Maroshegyről jön-e, hogy a kiszolgálási területed belefér-e Móron, Bicskén, Polgárdiban, Velencén és Gárdonyban élőkbe, hogy az ipari parkban dolgozó cégek ügyfelek-e vagy sem. Ezek a mondatok azok, amiket egy sablonszöveg soha nem ír le helyetted, és pont ezek különböztetik meg az oldaladat a másik ötven hasonlótól.

A felelősségvállalás oldalán pedig egyszerű a képlet: ha baj van, van-e kit hívni. Saját tapasztalat: a leggyakoribb ügyfélpanasz nem az, hogy csúnya lett az oldal, hanem hogy a készítő elérhetetlenné vált, és senkinél nincs meg a domain vagy a tárhely belépője.

A távoli együttműködés akkor működik jól, ha három feltétel teljesül: van rendszeres, kiszámítható egyeztetés, írásban rögzített feladatlista, és az átadás pillanatában tényleg megkapod az összes hozzáférést. Ha ebből bármelyik hiányzik, a földrajzi közelség sem ment meg.

Hogyan néz ki egy weboldal készítés folyamata lépésről lépésre?

Egy jól vezetett projekt hét jól elkülöníthető szakaszból áll, és ebből csak kettő az, amit a legtöbben weboldalkészítésnek hívnak.

1. Célmeghatározás: mit csináljon a látogató (hívjon, űrlapot küldjön, időpontot foglaljon, boltba jöjjön). Egy fő cél legyen, a többi másodlagos.
2. Keresleti felmérés: milyen kifejezésekre keresnek a szolgáltatásodra, és ezek közül melyekre van reális esélyed. Itt derül ki, hány aloldal kell.
3. Oldaltérkép és tartalomváz: minden oldalhoz egy mondat arról, kinek szól és mi a célja. Ez az a lépés, amit a legtöbb projektben kihagynak, és utána a fejlesztés közben improvizálnak.
4. Tartalom: szövegek, valódi fotók, referenciák, adatok. Ez a leglassabb szakasz, és általában rajtad múlik.
5. Dizájn és fejlesztés: a látvány és a működés összerakása, mobilról indulva.
6. Technikai átvizsgálás: sebesség, mobilnézet, űrlapteszt, hibás linkek, mérőkódok, jogi oldalak.
7. Élesítés és mérés: átirányítások a régi címekről, Search Console és analitika beállítás, majd figyelés.

Szakmai feltételezés: ha egy ajánlatban a 2., 3. és 6. pont nem szerepel semmilyen formában, akkor azok a lépések nagy valószínűséggel nem is fognak megtörténni.

Egy gyakorlati példa a 3. lépésre. Egy fehérvári szerelővállalkozásnál a tartalomváz nem több egy táblázatnál: az egyik oszlopban az oldal címe, a másikban egy mondat arról, kinek szól, a harmadikban az, mit tegyen az olvasó a végén. Amikor ez a táblázat kész, a szövegírás fele már megvan, és a fejlesztő is tudja, hány sablon kell.

Milyen technikai alapokat érdemes még a megrendelés előtt kikötni?

Öt dolgot érdemes írásban rögzíteni: a tulajdonjogot, a hozzáféréseket, a mentést, a mérést és azt, hogy mi történik a projekt után.

• Domain és tárhely a te nevedre. A regisztrációnál a te céged legyen a tulajdonos, a fejlesztő legfeljebb technikai kapcsolattartó.
• Admin hozzáférés átadása az élesítéskor, jelszókezelőben, nem chatben.
• HTTPS mindenhol, működő átirányítással a régi címekről.
• Mobil nézet elsődlegesen. Hivatalosan igazolt: a Google dokumentációja szerint az indexelés a mobil változat alapján történik, tehát ami mobilon nincs ott, az gyakorlatilag nincs.
• Betöltési sebesség. Hivatalosan igazolt: a Core Web Vitals mérőszámok a Google publikus dokumentációjában szereplő oldalélmény-jelzések közé tartoznak, bár önmagukban nem döntik el a helyezést.
• Automatikus mentés és visszaállítási lehetőség, dokumentálva.
• Mérés: analitika és Google Search Console már az élesítés napján.
• Jogi minimum: adatkezelési tájékoztató, sütikezelés, impresszum, működő elérhetőség.
• Szerkeszthetőség: a nyitvatartást és a szolgáltatáslistát fejlesztő nélkül is tudd átírni.

Ezeket nem kell jogi nyelven megfogalmazni. Elég, ha az ajánlat elfogadásakor egy emailben felsorolod őket, és a fejlesztő írásban visszaigazolja. Saját tapasztalat: ez a néhány soros levél többször mentett már meg projektet, mint bármilyen hosszú szerződésminta.

Milyen aloldalakból álljon egy székesfehérvári szolgáltató oldala?

Egy helyi szolgáltatónál általában öt oldaltípus fedi le a valós igényeket: nyitóoldal, szolgáltatásonként egy-egy oldal, bemutatkozás, részletes kapcsolat oldal, és néhány kérdésre válaszoló tartalom. A menü hosszát ne a divat, hanem a szolgáltatásaid száma döntse el.

• Nyitóoldal: az első képernyőn derüljön ki, mit csinálsz, hol csinálod, és mi a következő lépés. Ha valakinek görgetnie kell ahhoz, hogy megtudja, Székesfehérváron dolgozol, az oldal már veszített.
• Szolgáltatásoldalak: minden fő szolgáltatásnak saját címe, saját szövege és saját kérdései legyenek. Két majdnem egyforma oldal helyett jobb egy alapos.
• Bemutatkozás: ki dolgozik nálad, mióta, milyen végzettséggel vagy engedéllyel. Sok esetben itt dől el a bizalom.
• Kapcsolat: cím, térkép, megközelítés, parkolás, nyitvatartás, kattintható telefonszám, rövid űrlap.
• Kérdés-válasz tartalmak: azok a kérdések, amiket telefonon amúgy is naponta megkapsz.

Saját tapasztalat: a legtöbb helyi vállalkozásnak nem több oldal kell, hanem kevesebb és alaposabb. Egy húszoldalas, félig üres menü rosszabbul teljesít, mint hat oldal, amelyeken valódi információ van.

Hogyan készítsd fel az oldalt a székesfehérvári helyi keresésre?

A helyi kereséshez három dolog kell: következetes cégadatok, valódi helyi tartalom, és gépi olvashatóság. A településnév ismételgetése nem tartozik ide.

A cégadatoknál a legfontosabb az egyezés. A név, a cím és a telefonszám pontosan ugyanabban a formában szerepeljen az oldaladon, a Google Cégprofilodban és minden olyan katalógusban, ahol megtalálható vagy. Egy 8000 Székesfehérvár és egy Székesfehérvár, 8000 írásmód nem katasztrófa, de a következetesség segíti az egyértelmű azonosítást. Írd össze egyszer egy dokumentumba a pontos cégnevet, címet és telefonszámot, és onnantól mindenhova onnan másold.

A tartalomnál a kapcsolat oldal kevés. Legyen egy oldalad, ami leírja, hol vagy pontosan, hogyan lehet odajutni, hol lehet parkolni, mikor vagy nyitva, és melyik környező településekre vállalsz munkát. Ha több szolgáltatásod van, azoknak külön oldal jár, de csak akkor, ha valóban különböző tartalommal tudod megtölteni őket.

A gépi olvashatóságot strukturált adattal éred el. Hivatalosan igazolt: a Schema.org szókészlete és a Google strukturált adatokra vonatkozó dokumentációja is támogatja a helyi vállalkozás jelölését. Egy egyszerű példa:

{"@context":"https://schema.org","@type":"LocalBusiness","name":"A vallalkozasod neve","address":{"@type":"PostalAddress","streetAddress":"Utca es hazszam","addressLocality":"Szekesfehervar","postalCode":"8000","addressCountry":"HU"},"telephone":"+3622000000","url":"https://azoldalad.hu","areaServed":["Szekesfehervar","Fejer varmegye"],"openingHours":"Mo-Fr 08:00-16:00"}

A jelölés önmagában nem hoz helyezést, csak azt éri el, hogy amit leírtál, azt félreértés nélkül lehessen kiolvasni.

Mi kell ahhoz, hogy az AI-válaszmotorok is idézzék az oldalt?

A gépi válaszokban az az oldal jelenik meg jó eséllyel, amelyik konkrét, ellenőrizhető tényt fogalmaz meg röviden, azon a helyen, ahol keresik. Garancia erre nincs, és nem is ígérhető.

Néhány dolog, ami a gyakorlatban segítheti ezt:

• Kérdés formájú címsorok, alattuk azonnal egy tömör, önmagában is értelmes válasszal. A hosszú felvezetés a gépi kivonatolásnak nem kedvez.
• Tényszerű adatok kiírása szövegként: szolgáltatási terület, nyitvatartás, mire vállalsz munkát és mire nem.
• Konzisztencia az oldalad és a külső felületeid (cégprofil, közösségi oldalak, szakmai katalógusok) között.
• A keresőrobotok és az AI-crawlerek ne legyenek véletlenül kizárva a robots.txt fájlban, ha idézést szeretnél. Hivatalosan igazolt: az OpenAI és több más szolgáltató publikus dokumentációban közli a crawlereinek nevét, így ezek célzottan engedhetők vagy tilthatók.
• A fontos információ ne kizárólag képen vagy PDF-ben legyen. Ha a nyitvatartásod csak egy plakátképen szerepel, gépi szemmel nem létezik.

Szakmai feltételezés: arról, hogy egy AI-asszisztens pontosan miért idéz egy adott forrást, nincs nyilvános, ellenőrizhető rangsorolási leírás. Amit tudunk, az inkább mintázat, mint szabály, ezért érdemes óvatosan bánni minden olyan ígérettel, ami biztos AI-megjelenést kínál.

Mire figyelj, ha egy meglévő oldalt cserélsz le újra?

Csere esetén a legnagyobb kockázat nem a dizájn, hanem az elveszett címek: ha a régi aloldalak új webcímre kerülnek átirányítás nélkül, a korábban megszerzett láthatóság egy része eltűnhet.

1. Élesítés előtt mentsd ki a régi oldal teljes címlistáját (oldaltérkép, Search Console, tárhely).
2. Készíts párosítást: melyik régi cím melyik új címnek felel meg. Ahol nincs pontos megfelelő, a legközelebbi tematikus oldalra mutass, ne mindent a nyitóoldalra.
3. Állíts be tartós (301) átirányításokat, és élesítés után kattints végig legalább a tíz legfontosabb régi címet.
4. Ellenőrizd, hogy a fejlesztés alatt használt kereső-tiltás (noindex vagy tiltó robots.txt) tényleg lekerült-e.
5. Mentsd le a régi szövegeket, mielőtt törlöd őket. Sokszor a régi tartalom pontosabb, mint amit sietve újraírnak helyette.
6. Élesítés után küldd be az új oldaltérképet a Search Console-ba, és nézd meg egy hét múlva az indexelési jelentést.

Saját tapasztalat: a fejlesztés idejére beállított kereső-tiltás bent felejtése az egyik leggyakoribb és legkellemetlenebb hiba. Hetekig lehet várni az eredményre úgy, hogy közben az oldal gépi szemmel gyakorlatilag láthatatlan.

Milyen kérdéseket tegyél fel a fejlesztőnek az első egyeztetésen?

A jó kérdések nem technikaiak, hanem a felelősségről és a projekt utáni időszakról szólnak.

• Kinek a nevére kerül a domain és a tárhely?
• Mikor és milyen formában kapom meg az összes hozzáférést?
• A tartalmat (szöveg, fotó) én adom, vagy benne van a munkában?
• Ki felel a régi oldalról az átirányításokért?
• Milyen rendszerre épül, és tudom-e majd más fejlesztővel folytatni?
• Mi történik, ha élesítés után hibát találok, és meddig?
• Beállítod a Search Console-t és az analitikát?
• Milyen frissítési és mentési rend lesz az átadás után?
• Mutatsz olyan korábbi munkát, ami ma is él és mobilon is rendben van?

A válaszok tartalmánál majdnem ugyanolyan fontos a válaszadás módja. Ha valaki a hozzáférések kérdésére kitérően felel, az nem technikai részletkérdés, hanem előrejelzés arról, hogyan fog kinézni az átadás.

Mit csinálj az élesítés utáni első 90 napban?

Az élesítés nem befejezés, hanem a mérés kezdete: az első három hónap arról szól, hogy kiderüljön, működik-e az oldal üzletileg.

Az első héten ellenőrizd a Search Console-ban, hogy indexelődnek-e az oldalak, és nem maradt-e bent tiltás a fejlesztés idejéből. Küldj magadnak tesztüzenetet minden űrlapon, mobilról is, és hívd fel a saját számodat az oldalon lévő linkről. A második héttől nézd meg, milyen keresésekre jelensz meg, és hol vagy nagyon hátul: ott jellemzően hiányzik egy oldal vagy egy alaposabb tartalom.

A második hónaptól bővítsd az oldalt olyan témákkal, amiket az ügyfeleid tényleg kérdeznek tőled telefonon, és frissítsd a cégprofilodat is. A harmadik hónap végén már van annyi adatod, hogy megnézd: melyik oldalra érkeznek a legtöbben, melyikről indul valódi megkeresés, és melyik az, amit senki nem olvas. Az utóbbit vagy javítsd, vagy vond össze egy másikkal.

Saját tapasztalat: a leggyakoribb néma hiba az űrlap. Szép az oldal, jön a forgalom, csak éppen az üzenet sehova nem érkezik meg, mert a levelek a spam mappába esnek. Ezt havonta egyszer érdemes tesztelni, mert magától soha nem derül ki.

Források és további olvasnivalók

• Google Search Central dokumentáció (Search Essentials, mobil elsődlegű indexelés, strukturált adatok)
• Google Cégprofil (Google Business Profile) hivatalos súgó
• web.dev: Core Web Vitals dokumentáció
• Schema.org: LocalBusiness és PostalAddress típusok
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• OpenAI dokumentáció: crawlerek és robots.txt kezelés
• Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) tájékoztatói