A „ki tud modernizálni egy elavult céges honlapot?" kérdést jellemzően nem fejlesztő írja be a keresőbe, hanem cégvezető vagy marketinges, aki egy konkrét falba ütközött: az oldal mobilon szétcsúszik, a régi fejlesztő nem válaszol, a tárhelyszolgáltató PHP-verziót vált, vagy évek óta nem érkezik az oldalról megkeresés. A kérdés valódi tartalma tehát nem az, hogy létezik-e ilyen szakma, hanem az, hogy kire lehet ezt rábízni úgy, hogy ne legyen belőle nagyobb baj, mint amekkora most van.
Az alábbiakban végigmegyünk a szóba jöhető kivitelező-típusokon, a döntés előtti ellenőrzéseken, a modernizálás menetén, és azon, hogyan tartható meg közben a meglévő keresőforgalom.
Mit jelent pontosan az, hogy elavult egy céges honlap?
Rövid válasz: egy honlap akkor elavult, ha a mögötte álló technológia már nem kap biztonsági frissítést, vagy ha a felhasználói és keresőmotoros elvárások átléptek rajta. A kettő gyakran együtt jár, de nem ugyanaz a probléma, és nem ugyanaz a megoldásuk sem.
Tovább a témában: Honlap felújítás Várpalota · Építőipari kivitelező weboldal
Mielőtt bárkit megkeresel, érdemes végigmenni ezen a listán, mert a válaszok határozzák meg, milyen munkát kérsz majd:
- Milyen rendszer hajtja az oldalt, és kap-e még frissítést (WordPress, Joomla, Drupal, egyedi PHP, statikus HTML)?
- Milyen PHP-verzión fut, és támogatott-e még az a verzió?
- Van-e HTTPS, és minden aloldal azon keresztül érhető-e el?
- Mobilon használható-e valóban, vagy csak nagyítás után olvasható?
- Te magad tudsz-e szöveget, képet, aloldalt módosítani, vagy minden apróságért külsőst kell hívni?
- Van-e működő űrlap, és hova érkeznek az onnan jövő adatok?
- Van-e Search Console és analitika, és látod-e bennük az adatokat?
- Megvan-e minden hozzáférés: domain, tárhely, CMS-admin, e-mail fiókok?
Hivatalosan igazolt: a Google dokumentációja szerint az indexelés elsődlegesen a mobil változat alapján történik, tehát ha a mobil megjelenés hiányos, az a keresőben látott tartalmat is korlátozza.
Saját tapasztalat: a hozzáférések kérdése szokott a legfájdalmasabb lenni. Sok cégnél a domain a valamikori fejlesztő magánfiókjában van, és ez a modernizálás első valódi akadálya, nem a design.
Ki tud modernizálni egy elavult céges honlapot?
Rövid válasz: négy szereplő-típus jön szóba (szabadúszó fejlesztő, webstúdió, marketinges szemléletű ügynökség, illetve platformváltás sablonos rendszerre), és a különbség nem a technikai tudásban van, hanem abban, hogy ki felel az eredményért az átadás után.
Szabadúszó fejlesztő
Gyors, rugalmas, közvetlen kommunikáció. Akkor jó választás, ha a feladat körülhatárolt: sablonfrissítés, mobilra igazítás, PHP-verzió emelése, biztonsági rendbetétel. Kockázat, hogy egy ember kiesése az egész projektet megállítja, és a tartalmi, keresőoptimalizálási szempont gyakran kimarad, mert nem az ő szakterülete.
Webstúdió, webfejlesztő cég
Több ember, dokumentált átadás, szerződéses keret. Nagyobb, összetettebb oldalaknál (több nyelv, termékkatalógus, egyedi rendszerkapcsolat) ez a reális irány. Kockázat, hogy a stúdió a látványra és a funkcióra optimalizál, és a régi oldal keresőben felépített értéke nem kap külön figyelmet, ha nem kéred külön.
Marketinges szemléletű ügynökség
Itt a kiindulás nem az, hogy „milyen legyen az oldal", hanem az, hogy „miből lesz megkeresés". Ez a megközelítés akkor hoz többet, ha a cél nem pusztán a technikai felújítás, hanem a látogatóból érdeklődő. Kockázat, hogy a fejlesztést alvállalkozó végzi, ezért érdemes rákérdezni, ki írja a kódot, és kihez fordulhatsz hiba esetén.
Platformváltás sablonos rendszerre
Ha az oldal lényegében néhány bemutatkozó aloldal, egy karbantartott sablonrendszerre költöztetés is elég lehet. Kevesebb technikai teher, cserébe kevesebb szabadság. Szakmai feltételezés: egy tíz aloldalnál kisebb bemutatkozó honlapnál ez az út gyakran arányosabb, mint az egyedi fejlesztés, de ezt mindig a konkrét tartalom és a tervezett bővítés dönti el.
Saját tapasztalat: a legtöbb elakadás nem abból ered, hogy rossz típust választottak, hanem abból, hogy senki nem tette fel a kérdést, mi történik az oldallal az átadás utáni hatodik hónapban.
Modernizálni kell, vagy inkább újat építeni?
Rövid válasz: ha a tartalom és a szerkezet nagyjából rendben van, csak a technológia és a megjelenés maradt le, akkor modernizálás a jó irány. Ha az oldal szerkezete sem tükrözi már a cég szolgáltatásait, az újraépítés általában olcsóbban jön ki időben és energiában.
Döntési támpontok a modernizálás mellett: karbantartott CMS-en fut, van indexelt, forgalmat hozó tartalom, a szolgáltatási kör nem változott, az adminfelület elérhető. Az újraépítés mellett szól: nem frissíthető, elhagyott rendszer, feltört vagy kártékony kóddal fertőzött oldal, teljesen megváltozott üzleti profil, hiányzó forráskód.
Fontos, hogy a kettő nem zárja ki egymást. Sok esetben működik a szakaszos út: először a biztonsági és mobil problémák rendezése, utána a tartalmi szerkezet újragondolása, végül a design. Ez lassabb, de nem áll le közben a meglévő forgalom.
Mit kérj be a kivitelezőtől, mielőtt döntesz?
Rövid válasz: írásos felmérést a jelenlegi állapotról, egy átállási tervet az URL-ekre, és egy egyértelmű nyilatkozatot arról, kinél maradnak a hozzáférések. Aki ezt a hármat nem tudja megadni, annál a projekt kockázata magas.
- Állapotfelmérés írásban: mi fut most a szerveren, mi a legfőbb kockázat, mit javasol és miért. Ez akkor is hasznos marad, ha végül mással dolgozol.
- URL-leltár és átirányítási terv: a régi oldalak listája, és mi lesz belőlük az új szerkezetben.
- Hozzáférési nyilatkozat: a domain, a tárhely, a CMS-admin és az analitikai fiókok a cég nevén, a cég e-mail címére legyenek regisztrálva.
- Átadási csomag: mit kapsz a végén (belépési adatok, rövid használati leírás, mentés).
- Hibakezelés: mennyi ideig javítja a saját munkájában talált hibát, és milyen csatornán jelezheted.
Saját tapasztalat: a fizetett, néhány oldalas felmérés általában többet mond a leendő partnerről, mint bármelyik referencia. Abból látszik, hogy tényleg megnézte-e az oldalt, vagy sablonszöveget küldött.
Hogyan zajlik egy modernizálás lépésről lépésre?
Rövid válasz: mentés, leltár, fejlesztői másolat, átépítés, tesztelés, éles váltás, majd utókövetés. A sorrend fontosabb, mint a felhasznált technológia.
- Teljes mentés a fájlokról és az adatbázisról, letöltve, nem csak a szerveren.
- Leltár: minden létező URL, űrlap, e-mail cím, külső beépülő elem (térkép, foglalórendszer, hírlevél) összeírása.
- Fejlesztői másolat létrehozása külön címen, keresőmotorok elől lezárva.
- Átépítés: rendszerfrissítés, sablon, mobil nézet, tartalmi szerkezet.
- Tesztelés: űrlapok kipróbálása valós címre, mobil és asztali ellenőrzés, betöltési sebesség mérése, hibás linkek keresése.
- Éles váltás alacsony forgalmú időszakban, az átirányításokkal együtt élesítve.
- Utókövetés: a Search Console lefedettségi és teljesítmény-adatainak figyelése legalább néhány hétig.
Hogyan kerülhető el, hogy a megújult oldal forgalmat veszítsen?
Rövid válasz: a régi címek maradjanak elérhetők 301-es állandó átirányítással az új megfelelőjükre, és a fontos aloldalak tartalma ne olvadjon bele egy általános oldalba.
A leggyakoribb hiba az, hogy az új oldal szép, de a régi /szolgaltatasaink.php típusú címek hibaoldalra futnak. Apache-alapú tárhelyen ez egyetlen sorral kezelhető a .htaccess fájlban:
Redirect 301 /szolgaltatasaink.php https://pelda.hu/szolgaltatasok/
Nagyobb oldalnál táblázatban érdemes vezetni a régi és az új cím párokat, és minden sort ellenőrizni élesítés után. Hivatalosan igazolt: a Google Search Central dokumentációja a költöztetéseknél a 301-es átirányítást és a régi URL-ek leképezését javasolja, és jelzi, hogy az újrafeldolgozás időt vesz igénybe. Szakmai feltételezés: egy közepes méretű céges oldalnál a stabilizálódás jellemzően hetekben mérhető, de ez a méret és a látogatottság függvénye, és nem garantálható, hogy a korábbi pozíciók változatlanul visszatérnek.
Amit még érdemes átvinni: a címsor-szerkezet (egy H1 aloldalanként), az oldalcímek és leírások, a képek alt szövegei, a sitemap.xml és a robots.txt tartalma. Élesítés előtt ellenőrizd, hogy a fejlesztői másolat lezárása nem került-e át az éles oldalra, mert egy ottfelejtett noindex a teljes láthatóságot leveheti.
Mit jelent ma az, hogy egy honlap fel van készítve az AI-keresésre?
Rövid válasz: azt, hogy a tartalom géppel is egyértelműen értelmezhető: tiszta HTML-szerkezet, kérdésre válaszoló szövegrészek, és strukturált adat a cég alapinformációiról.
A válaszmotorok és az AI-asszisztensek nem böngészik végig a képekbe írt információt, és nehezen boldogulnak a kizárólag JavaScriptből felépülő tartalommal. Egy modernizálásnál ezért érdemes kérni, hogy a lényeges szöveg a HTML-forrásban is benne legyen, és a cég adatai schema.org jelöléssel is szerepeljenek:
{ "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Példa Kft.", "url": "https://pelda.hu/", "telephone": "+3622000000", "address": { "@type": "PostalAddress", "addressLocality": "Székesfehérvár", "addressCountry": "HU" } }
Hivatalosan igazolt: a strukturált adat formátumát a schema.org szótára írja le, a Google pedig külön dokumentálja, mely típusokat használja fel a találati megjelenítéshez. Szakmai feltételezés: a jelölés önmagában nem hoz idézettséget az AI-válaszokban, de az egyértelmű géppel olvasható adat jó eséllyel csökkenti a félreértelmezés kockázatát, például a nyitvatartás vagy a szolgáltatási terület kérdésében.
Milyen jelekből ismerhető fel a rossz kivitelező?
Rövid válasz: ha az oldal megnézése nélkül ad kész választ, ha nem kérdez rá a meglévő forgalomra, és ha a saját nevén tartaná a domaint.
- Nem kérdez az üzleti célról, csak a design ízléséről.
- Nem kér Search Console vagy analitikai hozzáférést a felméréshez.
- Nem beszél az átirányításokról, mielőtt te szóba hoznád.
- Konkrét helyezést vagy garantált érdeklődő-számot ígér.
- A karbantartást és a mentést nem tisztázza, csak az átadásig gondolkodik.
- A domaint és a tárhelyet a saját fiókjában tartaná meg kényelmi okból.
Kinél maradjon a tulajdonjog és a hozzáférés?
Rövid válasz: mindig a cégnél. A domain a cég nevén, a tárhely a cég szerződésével, az adminfiókok a cég e-mail címeire regisztrálva, a fejlesztő pedig külön felhasználót kapjon.
Ez a pont dönti el, mennyire lesz sebezhető a következő öt évben. Ha a fejlesztő elérhetetlenné válik, a saját nevedre regisztrált domain és tárhely mellett néhány óra alatt tovább lehet lépni, ellenkező esetben viszont hónapokba telhet a helyzet rendezése. Érdemes írásban rögzíteni azt is, hogy az elkészült egyedi kód és a feltöltött tartalom felhasználási joga a megrendelőé, valamint hogy a projekt zárásakor teljes mentést kapsz.
Saját tapasztalat: a hozzáférések rendezése a modernizálás legkevésbé látványos, de leginkább megtérülő része. Egy táblázat, amelyben minden fiók, felhasználónév és jelszókezelői bejegyzés szerepel, később több munkát spórol, mint bármelyik technikai finomhangolás.
Források és további olvasnivalók
- Google Search Central: Site moves with URL changes
- Google Search Central: Mobile-first indexing best practices
- Google Search Central: Introduction to structured data markup
- Schema.org: LocalBusiness és Organization típusok dokumentációja
- W3C: Web Content Accessibility Guidelines (WCAG)
- web.dev: Core Web Vitals
- WordPress.org: Hardening WordPress és Updating WordPress
- Nemzeti Adatvédelmi és Információszabadság Hatóság: adatkezelési tájékoztatókkal kapcsolatos állásfoglalásai
- Az „elavult" két külön problémát takar: a nem frissülő technológiát és a lemaradt tartalmi-felhasználói elvárásokat, és a kettőnek más a megoldása.
- A kivitelező kiválasztásánál a fizetett felmérés, a hozzáférések rendezettsége és az átállási terv többet árul el, mint a portfólió.
- Domain, tárhely, CMS-admin és analitika mindig a cég saját fiókjaiban legyen, ne a fejlesztőében.
- A régi URL-ek 301-es átirányítása és a szerkezet leltára nélkül a megújult oldal jó eséllyel forgalmat veszít.
- A strukturált adat és a tiszta, gépi olvasásra alkalmas HTML ma a válaszmotorokban való megjelenés esélyét is befolyásolja.
Gyakori kérdések
Ki tudja átvenni a honlapot, ha a régi fejlesztő nem elérhető?
Bármely másik fejlesztő vagy webstúdió, feltéve, hogy megvan a domain és a tárhely feletti rendelkezés. Ha ezek a régi fejlesztő fiókjában vannak, először azok visszaszerzésével vagy a domain regisztrátoránál indított átírással érdemes kezdeni, és csak utána a technikai munkával.
Meddig tart egy céges honlap modernizálása?
Ez a terjedelemtől függ. Egy néhány aloldalas bemutatkozó oldal mobilra igazítása és rendszerfrissítése jellemzően napokban mérhető, egy több tucat aloldalas, több nyelvű oldal átépítése hetekben. Az átirányítások ellenőrzése és az utókövetés az élesítés után is folytatódik.
Elveszítem a Google-helyezéseimet, ha megújítom az oldalt?
Nem szükségszerű, de a kockázat valós. A régi címek 301-es átirányítása, a tartalom megőrzése és a címsor-szerkezet átvitele csökkenti a visszaesés esélyét. Ingadozás az első hetekben így is előfordulhat, és a korábbi pozíciók változatlan visszatérése nem garantálható.
Jobb a WordPress, vagy egyedi fejlesztés?
Bemutatkozó és szolgáltatás-oldalaknál a karbantartott, széles körben ismert rendszer előnye, hogy sok szakember tudja folytatni a munkát. Egyedi fejlesztés akkor indokolt, ha olyan folyamatot kell leképezni, amire nincs jól működő kész megoldás. A döntést a tervezett bővítés és a belső üzemeltetési képesség határozza meg.
Mit vigyek magammal az első egyeztetésre?
A domain és tárhely adatait, a meglévő adminhozzáféréseket, a Search Console és az analitika elérését, valamint egy listát arról, mit szeretnél elérni az oldallal. Ha van korábbi szerződés vagy átadási dokumentum, azt is érdemes elővenni.
Elég a designt lecserélni, vagy a tartalmat is át kell írni?
A design csere önmagában ritkán változtat a megkeresések számán. Ha a szövegek nem válaszolnak azokra a kérdésekre, amiket az érdeklődők valóban feltesznek, a megújult megjelenés mögött ugyanaz a hiány marad. A tartalmi átnézés általában a modernizálás legnagyobb hozadéka.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.