- Először mérj, aztán dönts: leltár nélkül minden felújítás-vagy-új vita ízlésvita marad.
- Felszíni hibát (szöveg, kép, dizájn) érdemes felújítani, szerkezeti hibát (rendszer, URL-káosz, sebesség) általában nem.
- Az új oldal legnagyobb kockázata nem a fejlesztés, hanem a rosszul kezelt URL-átállás.
- Egy egri vállalkozásnál a helyi keresési szándék és a Google Cégprofillal való összhang gyakran többet hoz, mint a látvány.
- Az AI-válaszmotorok stabil URL-t, tiszta szerkezetet és egyértelmű tényeket idéznek szívesen, nem effekteket.
Ez a kérdés szinte sosem technikai kérdésként érkezik. Mögötte az van, hogy a tulajdonos ránéz a saját oldalára, és érzi, hogy valami nem stimmel, de nem tudja, hogy egy hétvégényi ráncfelvarrás elég-e, vagy hónapokra szóló projektbe kezd. A válasz attól függ, hogy a baj a felszínen van-e, vagy a szerkezetben.
Mit keres pontosan az, aki beírja, hogy megéri-e felújítani a régi weboldalát?
Rövid válasz: nem árlistát keres, hanem döntési szempontot, amivel maga is el tudja dönteni, melyik irány a reális. A keresés mögött általában három félelem áll egyszerre: nehogy feleslegesen költsön egy foltozásra, nehogy elveszítse azt a kevés forgalmat, ami most van, és nehogy fél év múlva ugyanitt tartson.
A szétválasztás egyszerű logika mentén megy. A felszíni hibák a tartalomhoz és a megjelenéshez tartoznak: régi szövegek, rossz vagy hiányzó képek, elavult referenciák, nem létező szolgáltatás, gyenge kapcsolatfelvételi rész. A szerkezeti hibák mélyebben ülnek: nem támogatott rendszer vagy sablon, kaotikus URL-ek, mobilon szétcsúszó elrendezés, olyan sebesség, amit már nem lehet tuningolással megfogni, és olyan felépítés, ami nem tud bővülni.
Saját tapasztalat: az esetek jó részében az ügyfél a látványra panaszkodik, miközben a mérhető problémák máshol vannak. Ezért az első lépés soha nem a dizájn, hanem a leltár. Amíg nem tudod, mire jelenik meg most az oldalad a keresőben és milyen technikai állapotban van, addig a felújítás-vagy-új vita ízlésvita marad.
Mikor éri meg felújítani a meglévő weboldalt?
Rövid válasz: akkor, ha az alap stabil, és a hiányzó dolgok hozzáépíthetők anélkül, hogy az oldal szerkezetéhez hozzá kellene nyúlni. Ilyenkor a felújítás jellemzően gyorsabb, kevesebb kockázattal jár, és a meglévő keresési teljesítmény sem kerül veszélybe.
Ezek a jelek szólnak a felújítás mellett:
- A rendszer (például a WordPress és a sablon) még kap frissítést, és nincs benne évek óta érintetlen, elhagyott bővítmény.
- Az oldal mobilon használható: nem csúszik szét, a menü nyílik, a gombok ujjal is elérhetők.
- Az URL-ek beszédesek és következetesek, nincs belőlük több változat ugyanarra a tartalomra.
- Van már némi keresési teljesítmény: a Search Console-ban látszanak megjelenések olyan kifejezésekre, amiket tényleg akarsz.
- A fő hiány a tartalom: kevés az oldal, gyenge a szolgáltatásleírás, nincsenek kérdés-alapú részek.
Szakmai feltételezés: ha ezekből legalább négy teljesül, a felújítás jellemzően jobb döntés, mert a meglévő oldal bizalmi előzményét (kor, hivatkozások, indexelt tartalom) nem dobod el. Ez nem szabály, hanem tapasztalati arány, egyedi eseteknél máshogy is alakulhat.
Mikor jobb nulláról új weboldalt csináltatni?
Rövid válasz: akkor, ha a javításhoz úgyis a szerkezetet kellene átírni, vagy ha az oldal biztonsági szempontból már nem tartható. Ilyenkor a felújítás csak elhalasztja a döntést, és közben elköltöd rá azt az energiát, ami az új alapra kellene.
Ezek a jelek szólnak az új oldal mellett:
- A rendszer vagy a sablon már nem kap biztonsági frissítést, és a szerkesztéshez fejlesztőre van szükség minden apróságnál.
- Az oldal nem mobilbarát, és a mobilnézet nem beállítás kérdése, hanem újratervezésé.
- Régi, egyedi fejlesztésű rendszer fut rajta, amihez nincs dokumentáció és nincs, aki karbantartsa.
- Az üzleti modell változott: más szolgáltatást adsz el, más célcsoportnak, más földrajzi területen.
- Az oldal nem képes olyan funkciót fogadni, ami most már alap: időpontfoglalás, kereshető szolgáltatáslista, webshop, több nyelv.
Hivatalosan igazolt: a Google mobilelső indexelést használ, vagyis alapvetően az oldal mobilváltozatát dolgozza fel. Ha a mobilnézeted lényegesen szegényesebb, mint az asztali, az nem kozmetikai kérdés.
Hogyan döntöd el konkrétan, felújítás vagy új oldal legyen?
Ezt a sorrendet érdemes végigmenni, mielőtt bárkitől bármit kérsz. Papíron egy délelőtt alatt elvégezhető.
- Nyisd meg a Google Search Console-t, és nézd meg az elmúlt 12 hónap kereséseit: mire jelensz meg egyáltalán, és hol.
- Listázd ki, hány oldal van indexelve, és hány olyan van köztük, aminek semmi értelme (paraméteres URL, üres kategória, régi verzió).
- Mérd meg a főoldal és két aloldal betöltési élményét mobilon, valódi telefonon is, nemcsak asztali böngészőben.
- Írd le, milyen funkciókra lesz szükséged 24 hónapon belül. Ha ebből három nem megy a mostani rendszeren, az új oldal felé billen a mérleg.
- Nézd meg, ki tudja szerkeszteni az oldalt. Ha csak egyetlen külső ember, az önmagában kockázat.
- Ellenőrizd a hozzáféréseket: domain, tárhely, adminfelület, Search Console, Google Cégprofil. Ami hiányzik, azt még a döntés előtt szerezd meg.
- Kérj két megközelítést ugyanarra a célra: egy felújítási és egy újraépítési tervet, azonos elvárásokkal.
Milyen technikai jelekből látszik, hogy a szerkezettel van baj?
Rövid válasz: abból, hogy ugyanaz a tartalom több címen is elérhető, és hogy az oldal alapbeállításai nincsenek rendben. Ezek nem vélemények, hanem néhány perc alatt ellenőrizhető tények.
Írd be a böngészőbe a domained négy változatát, és nézd meg, mind ugyanoda visz-e: http://pelda.hu, http://www.pelda.hu, https://pelda.hu, https://www.pelda.hu. Ha nem, akkor a keresők több oldalt látnak ott, ahol egy van.
Ezután nézd meg, létezik-e és értelmes-e a https://pelda.hu/robots.txt, illetve az oldaltérkép, jellemzően https://pelda.hu/sitemap.xml vagy /sitemap_index.xml címen. Egy elfelejtett Disallow: / sor évekig el tud rejteni egy oldalt.
Hivatalosan igazolt: a Google dokumentációja szerint a HTTPS könnyű súlyú rangsorolási jel, és a Search Console-ban jelzett indexelési hibák érdemi információt adnak arról, mit lát a kereső. Saját tapasztalat: a régi oldalak jelentős részénél a legnagyobb gond nem a dizájn, hanem az, hogy ugyanaz a szolgáltatásleírás négy különböző címen fut, és egyik sem elég erős.
Miben más ez a döntés egy egri vállalkozásnál?
Rövid válasz: Egerben a helyi keresési szándék és a Google Cégprofillal való összhang gyakran többet hoz, mint bármilyen látványelem. Egy egri szolgáltatónál a legtöbb érdeklődés néhány konkrét kifejezés köré épül, és ezek szinte mindig helyhez kötöttek.
Eger sajátossága, hogy több, egymástól eltérő logikájú kereslet fut párhuzamosan. Van erős turisztikai réteg (vár, termálfürdő, Szépasszony-völgy, borvidék), van egyetemi jelenlét az Eszterházy Károly Katolikus Egyetem miatt, és van a hétköznapi helyi kereslet, ami a városban és a környező Heves vármegyei településeken élőkből jön. Ez a három közönség nem ugyanazt írja be a keresőbe, és nem ugyanazt várja el az oldaltól.
Szakmai feltételezés: ha a vállalkozásod elsősorban a helyi, visszatérő keresletből él, a felújítás gyakran elég, mert a döntést nem a látvány viszi el, hanem a nyitvatartás, az elérhetőség és a szolgáltatás pontos leírása. Ha viszont az egri turistaforgalomból akarsz érdemi részt, ott már foglalás, mobilhasználat és gyors betöltés kell, és ez sokszor szerkezeti kérdés.
Praktikus egri szempont: a Google Cégprofilodban szereplő cím, nyitvatartás és szolgáltatásnév egyezzen meg azzal, ami az oldalon van. Ha a profilban Eger belvárosi cím szerepel, az oldalon pedig egy régi, elköltözés előtti, az önmagában rontja a bizalmat, és a felújítás keretében is javítható.
Hogyan előzheted meg, hogy az új oldallal elveszítsd a meglévő forgalmat?
Rövid válasz: minden régi címhez tartozzon egy pontos, tartalmilag megfelelő új cím, és ezt még az élesítés előtt írd meg. Ez a lépés dönti el, hogy az új oldal fellendülés vagy visszaesés lesz.
A gyakorlat: exportáld a régi oldal összes indexelt címét (Search Console és oldaltérkép alapján), és készíts egy két oszlopos táblát, régi cím és új cím. Ne mindent a főoldalra irányíts, mert az a legtöbb esetben elveszíti a tartalmi kapcsolatot. Apache-alapú tárhelyen egy sor így néz ki:
Redirect 301 /szolgaltatasaink.html https://pelda.hu/szolgaltatasok/
Élesítés után három dolgot tegyél meg: küldd be az új oldaltérképet a Search Console-ba, ellenőrizd a lefedettségi jelentést néhány nap múlva, és nézd át a 404-es hibákat. Hivatalosan igazolt: a Google Search Central költözéssel foglalkozó útmutatója a tartós (301-es) átirányítást ajánlja címváltozásnál, és azt is leírja, hogy az átállás után átmeneti ingadozás előfordulhat.
Saját tapasztalat: a legtöbb bukott újraindítás nem azért bukik, mert az új oldal rossz, hanem mert a régi címek a semmibe futnak, és a korábban jól teljesítő aloldalak egyszerűen eltűnnek. Ez a munka nem látványos, de ez menti meg a projektet.
Mire figyelj, ha azt akarod, hogy az AI-válaszmotorok is idézzék az oldaladat?
Rövid válasz: stabil címekre, egyértelmű tényekre és gépileg értelmezhető adatokra. A nyelvi modellekre épülő válaszmotorok akkor tudnak rád hivatkozni, ha a lényeg szövegben van, nem képen vagy effektben.
Négy dolog számít a leginkább:
- Ne változtasd a hivatkozott oldalak címét feleslegesen, mert az idézhetőség a cím állandóságán is múlik.
- Minden fontos tény (mit csinálsz, hol, kinek, milyen feltétellel) legyen kiírva rendes mondatban.
- Használj kérdés-alapú alcímeket, és a válasz a szakasz elején álljon, ne a végén.
- Adj strukturált adatot a Schema.org szótára szerint, például
"@type": "LocalBusiness"és"areaServed": "Eger"mezőkkel.
Szakmai feltételezés: a strukturált adat önmagában nem tesz idézhetővé, de segítheti, hogy a rendszerek pontosan társítsák a vállalkozásodat a városhoz és a szolgáltatáshoz. Ez nem eredményígéret, hanem a valószínűség javítása.
Milyen sorrendben érdemes belevágni?
Akár felújítasz, akár újat építtetsz, ez a sorrend csökkenti a kockázatot:
- Hozzáférések rendezése (domain, tárhely, admin, Search Console, Cégprofil).
- Teljes mentés a régi oldalról, fájl és adatbázis szinten is.
- Leltár: mely oldalak hoznak forgalmat, melyek nem.
- Döntés a felújítás és az új oldal között, írásban rögzített indokkal.
- Tartalom előkészítése, mert a szöveg szokott csúszni, nem a fejlesztés.
- Átirányítási tábla megírása még az élesítés előtt.
- Élesítés, majd 30 napig heti ellenőrzés a Search Console-ban.
Ha egyetlen dolgot viszel el ebből: a döntés nem az oldal koráról szól, hanem arról, hogy a mostani szerkezet elbírja-e a következő két évet.
Hogyan döntsd el lépésről lépésre?
- Exportáld az összes URL-t (sitemap vagy crawler segítségével), és jelöld, melyik hozott forgalmat az elmúlt tizenkét hónapban.
- Jelöld meg, hány URL szerkezetileg hibás (nincs önálló oldala annak, aminek kellene, vagy fordítva).
- Futtass sebességmérést három reprezentatív oldalon, és írd fel, hogy sablon- vagy tartalomprobléma-e a szűk keresztmetszet.
- Nézd meg JavaScript nélkül az oldalt.
- Ellenőrizd a PHP- és sablonverziót, valamint az utolsó frissítés dátumát.
- Hasonlítsd össze a mostani menüt azzal, amit ma tényleg árulsz.
- Számold meg, hány szerkezeti jel igaz. Kettőtől felfelé az újraépítés a védhetőbb döntés.
Mit kell mindenképp átmenteni az új oldalra?
Az értéket a régi URL-ek és a bevált tartalom hordozza, nem a dizájn. Átállás előtt készíts teljes URL-párosítási táblázatot: minden régi cím mellé kerüljön az új megfelelője.
Néhány szabály, amit érdemes betartani:
- Minden régi URL-nek legyen 301-es párja, és lehetőleg egy ugrással érjen célba. A régi cím ne mutasson egy másik átirányításra.
- A megszűnő oldalakat a legközelebbi tematikus oldalra irányítsd, ne a nyitóoldalra. Ha nincs ilyen, a 410-es státusz őszintébb.
- Az űrlapok, mérőkódok és konverziós események átvitele az indulás előtt legyen kész, ne utána.
- A jól teljesítő szövegeket vidd át, ne írasd újra elvből.
Egyszerű szerveroldali példa:
location = /regi-szolgaltatas-oldal { return 301 /szolgaltatasok/burkolas; }
Mi az öt objektív jel, ami után az új oldal a jobb döntés?
Öt jel: (1) a technológiai alap már nem kap biztonsági támogatást, (2) az információs architektúra és az URL-szerkezet alapból rossz, (3) a lassúság a sablonból jön, nem a tartalomból, (4) az oldal HTML-je gépi olvasásra alkalmatlan, (5) a vállalkozásod már mást csinál, mint amit az oldal kommunikál.
1. jel: a technológiai alap elérte az életciklusa végét
Hivatalos információ: a PHP hivatalos kiadási naptára szerint minden főverzió körülbelül két év aktív támogatást, majd további egy év biztonsági javítást kap. Ami ezen túl van, nem kap hibajavítást. Ugyanez igaz a CMS-ekre és a sablonokra is.
Nézd meg konkrétan:
- Milyen PHP-verzión fut az oldal, és támogatott-e még?
- A sablon és a fő bővítmények kaptak-e frissítést az elmúlt egy évben?
- Van-e olyan egyedi kód, amihez már nincs meg a fejlesztő, és nincs dokumentáció sem?
- Frissítéskor eltörik-e valami, ezért senki nem meri frissíteni?
Ha az utolsó pontra igen a válasz, az oldal befagyott állapotban van. Az ilyet nem lehet javítani, csak halogatni.
2. jel: az információs architektúra alapból rossz
Tipikus eset egy kivitelező vagy szolgáltató oldalán: minden szolgáltatás egyetlen Szolgáltatásaink aloldalon szerepel, nyolc bekezdésben, egymás alatt. Ilyenkor nincs mit optimalizálni, mert nincs önálló URL, amire a keresés vagy egy válaszmotor hivatkozni tudna.
Az arány dönt. Ha negyven oldalból három rossz, azt egyesével rendbe teszed. Ha negyvenből harmincöt rossz, a javítás gyakorlatilag újraírás, csak nehezebb körülmények között. A saját tapasztalatom szerint a töréspont valahol a szerkezetileg hibás oldalak felénél van.
3. jel: a lassúság a sablonból jön, nem a tartalomból
Hivatalos információ: a Google Search Central a Core Web Vitals mutatóit (LCP, INP, CLS) az oldalélmény részeként kezeli, ugyanakkor egyértelműen közli, hogy a jó technikai mutató nem pótolja a releváns tartalmat.
A különbségtétel egyszerű. Nyiss meg egy aloldalt PageSpeed Insightsban, és nézd meg, mi blokkolja a megjelenítést:
- Ha képek, betűtípusok, egy-két külső szkript a szűk keresztmetszet, ez javítható, és nem indok új oldalra.
- Ha a render-blokkoló JavaScript a sablon saját keretrendszere, és tíz bővítmény függ tőle, akkor a sablon cseréje gyakorlatilag új oldal, csak nem hívjuk annak.
4. jel: az oldal HTML-je gépi olvasásra alkalmatlan
Hivatalos információ: az OpenAI dokumentációja külön néven sorolja fel a crawlereit (GPTBot, OAI-SearchBot, ChatGPT-User), és leírja, hogyan lehet őket robots.txt-ben szabályozni. Szakmai feltételezés a részemről, hogy JavaScript-renderelésben ezek jelenleg nem érik el a Googlebot szintjét, ezért a szerveroldalon kiadott HTML biztonságosabb.
Kapcsold ki a böngésződben a JavaScriptet, és töltsd újra az oldalt. Ha nem marad ott a szöveg, akkor amit egy válaszmotor lát, az egy üres váz.
Ellenőrizd ezeket is:
- A címsorok valódi
h2ésh3elemek, vagy csak nagyra állított bekezdések? - A fontos állítások szövegként vannak kiírva, vagy képbe égetve?
- Van strukturált adat az oldalon, és érvényes-e?
Egy szolgáltató alapszintű jelölése így néz ki:
{"@context": "https://schema.org", "@type": "LocalBusiness", "name": "Cégnév", "areaServed": "Székesfehérvár", "url": "https://pelda.hu"}
Ha a sablon nem enged saját script blokkot a fejlécbe, és bővítménnyel sem megoldható, az szerkezeti korlát.
5. jel: a pozicionálás megváltozott
Ez a legkevésbé technikai, mégis a leggyakoribb valódi ok. Ha három éve általános szolgáltatóként indultál, ma pedig egy szűk szegmensre fókuszálsz, akkor az oldal minden szövege, menüpontja és belső linkje a régi logikát követi. Ilyenkor nem szövegcsere kell, hanem másik váz.
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: Structured data general guidelines
- Google Search Console súgó: Index coverage jelentés
- Schema.org: LocalBusiness típus dokumentációja
- W3C: Web Content Accessibility Guidelines (WCAG)
- web.dev: Core Web Vitals dokumentáció
Gyakori kérdések
Honnan tudom, hogy a régi oldalam rendszere még támogatott-e?
Nézd meg az adminfelületen, mikor jelent meg utoljára frissítés a rendszerhez és a sablonhoz, illetve mikor frissítették utoljára a bővítményeket. Ha egy fő elem több éve nem kapott frissítést, vagy a fejlesztője megszűnt, az szerkezeti kockázat, és az új oldal felé billenti a mérleget.
Elveszítem a Google-helyezéseimet, ha új oldalt csináltatok?
Nem szükségszerűen, de a kockázat valós. Ha minden régi cím pontos, tartalmilag megfelelő új címre mutat tartós (301-es) átirányítással, és az oldaltérképet is beküldöd, a legtöbb esetben átmeneti ingadozás után rendeződik a helyzet. Ha viszont mindent a főoldalra irányítasz, jó eséllyel veszítesz.
Elég, ha csak új dizájnt teszek a régi oldalra?
Akkor elég, ha a probléma tényleg a megjelenés. Ha az oldal lassú, mobilon szétesik, vagy nem tud fogadni olyan funkciót, ami kell, a dizájn csak elfedi a hibát. Előbb mérj, és csak a mérés után dönts a látványról.
Mennyi ideig tart egy weboldal felújítása vagy újraépítése?
Ez elsősorban a tartalomtól függ, nem a fejlesztéstől. Egy tartalmilag rendben lévő, néhány oldalas bemutatkozó oldal felújítása hetekben mérhető, egy nulláról épülő, funkciókkal bővülő oldal jellemzően hónapokban. A csúszás oka szinte mindig a hiányzó szöveg és fotó.
Mit tegyek, ha nincs meg minden hozzáférésem a régi oldalhoz?
Ezt még a döntés előtt rendezd. Kérd el a domain regisztrátori belépést, a tárhely adminját és az oldal adminfelületét, és állítsd be a saját Search Console-hozzáférésedet. Hozzáférések nélkül sem a mentés, sem a biztonságos átállás nem elvégezhető.
Egri vállalkozásként számít, hogy hol tárolják az oldalamat?
A fizikai tárhely helye önmagában ritkán döntő, a mérhető betöltési sebesség és a rendelkezésre állás viszont igen. Helyi ügyfélkörnél inkább az számít, hogy a Google Cégprofilod adatai és az oldalon szereplő cím, nyitvatartás, szolgáltatásnevek egyezzenek.
Elveszítem-e a meglévő keresési pozícióimat, ha új oldalt csinálok?
Nem szükségszerűen, de kockázat mindig van. A Google hivatalos költöztetési útmutatója egyugrásos 301-es átirányításokat, egyező tartalmat és a Search Console-ban követett átállást javasol. Ezzel a veszteség jellemzően minimalizálható, de sem a megőrzés, sem a javulás nem garantálható előre.
Mennyi idő, mire kiderül, hogy jó döntés volt-e az új oldal?
Az adatok általában négy-nyolc hét után kezdenek stabilizálódni, teljesebb kép pedig három-hat hónap múlva áll össze. Ez alatt az időszak alatt az ingadozás normális, és önmagában nem jelzi, hogy a döntés hibás volt.
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.