Mikor érdemes új weboldalt készíteni a régi javítása helyett?
Akkor, ha a baj az oldal szerkezetében van, nem a felületén. Ha a hibalistád olyan elemekből áll, amelyeket a meglévő rendszeren belül ki lehet javítani (túl nagy képek, hiányzó címsorok, gyenge szövegek, elavult bővítmények), a javítás a racionális út. Ha viszont maga a technológia, az URL-szerkezet vagy a sablon akadályozza a fejlődést, a foltozás minden körben visszahozza ugyanazt a problémát.
A döntést mérésre érdemes alapozni, nem érzésre. Az alábbi öt jelből ha kettő vagy több egyszerre igaz, saját tapasztalatom szerint az újraépítés a kisebb kockázat. Ha egy sem igaz, szinte biztosan felesleges nulláról kezdeni.
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.
Mikor NEM éri meg új weboldalt készíteni?
Három esetben szinte biztosan rossz döntés az újraépítés: ha csak a dizájn nem tetszik, ha nincs, aki a tartalmat megírja, és ha a forgalom hirtelen esett, de nincs diagnózis.
1. Csak a dizájn nem tetszik
Az esztétikai elégedetlenség rendszerint két-három konkrét dologra vezethető vissza: elavult betűtípusra, szűk sorközre, gyenge képekre, mobilon összecsúszó menüre. Ezek külön-külön javíthatók. Írd le pontokba, mi zavar, és nézd meg, hány pont igényel valóban új alapot. A tapasztalatom szerint általában nulla.
2. Nincs, aki a tartalmat megírja
Az új weboldal nem termel szöveget. Ha a mostani oldalon azért nincs érdemi tartalom, mert senkinek nincs rá ideje, akkor az új oldalon ugyanennyi tartalom lesz, csak szebb keretben. Előbb a tartalmi folyamatot érdemes megoldani, utána jöhet a technika.
3. A forgalom hirtelen esett, de nincs diagnózis
Az esésnek sokféle oka lehet: mérési hiba, indexelési probléma, algoritmusfrissítés, szezonalitás, egy elveszett hivatkozás. Ha ilyenkor új oldalt indítasz, a diagnózis lehetőségét dobod el, és az új oldalra viszed át az ismeretlen okot. Előbb a Search Console lefedettségi és teljesítményjelentése, a mérőkód épsége és a szerverlogok, csak utána a döntés.
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; }
Milyen ellenőrzőlistán menj végig az indulás napján?
- A robots.txt nem tiltja-e véletlenül az egész oldalt (a fejlesztői beállítás gyakran bennmarad).
- Minden oldalon egyedi title és meta leírás van.
- A sitemap.xml csak élő, indexelhető URL-eket tartalmaz.
- A Search Console-ban beadtad az új sitemapet, és figyeled a lefedettségi hibákat.
- Az átirányítások mintavételes tesztje lefutott (legalább húsz régi URL kézzel).
- A strukturált adat érvényes, és valóban azt írja le, ami az oldalon látszik.
- Az oldal JavaScript nélkül is olvasható.
- Az elérhetőségek, nyitvatartás és cégadatok minden felületen egyeznek.
Az első négy-nyolc hét ingadozó adatokat fog mutatni, ez normális. A javulás nem garantált, és nem is automatikus: az új alap csak a lehetőséget teremti meg, a tartalom és a hivatkozások dolgoznak tovább. Egy budapesti vagy székesfehérvári helyi szolgáltatónál például a helyi találatok visszarendeződése önmagában sem gyorsaság, sem sorrend szempontjából nem ígérhető előre.
Források és további olvasnivalók
- Google Search Central dokumentáció (Search Essentials, oldalélmény, átirányítások és költöztetés)
- Google Search Console súgó (lefedettségi és teljesítményjelentés)
- web.dev: Core Web Vitals mérőszámok leírása
- Schema.org szótár (LocalBusiness, Service, FAQPage típusok)
- OpenAI dokumentáció: crawlerek és robots.txt kezelése
- W3C HTML szabvány és WAI akadálymentesítési útmutatók
- PHP hivatalos támogatott verziók (Supported Versions) oldala
- Az újraépítés melletti döntést mérésre érdemes alapozni, nem az esztétikai elégedetlenségre.
- Ha az öt szerkezeti jelből kettő vagy több egyszerre igaz, jó eséllyel az új oldal a kisebb kockázat.
- A hirtelen forgalomesés önmagában nem indok új oldalra, előbb diagnózis kell.
- Az átállás legkritikusabb technikai része az egyugrásos 301-es átirányítási terv.
- Az új oldalnál a szerveroldalon kiadott, szemantikus HTML a gépi olvashatóság alapfeltétele.
Gyakori kérdések
Honnan tudom biztosan, hogy javítható-e a régi oldalam?
Készíts két listát: az egyikbe azok a hibák kerülnek, amiket a jelenlegi rendszerben is meg lehet oldani (képek, szövegek, meta adatok, bővítmények), a másikba azok, amik a technológiából, az URL-szerkezetből vagy a sablonból fakadnak. Ha a második lista rövid, javíts. Ha hosszabb, mint az első, jó eséllyel az újraépítés a kisebb kockázat.
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.
Elég-e csak a dizájnt lecserélni a régi rendszerben?
Ha a szerkezet, az URL-ek és a technológiai alap rendben van, akkor gyakran igen, és ez a gyorsabb út. Ha viszont a sablon keretrendszere okozza a lassúságot vagy korlátozza a strukturált adatot, a dizájncsere önmagában nem oldja meg a problémát.
Mit jelent az, hogy az oldalnak gépi olvasásra alkalmasnak kell lennie?
Azt, hogy a fő tartalom szerveroldalon kiadott, szemantikus HTML-ben elérhető: valódi címsorokkal, szövegként kiírt állításokkal és érvényes strukturált adattal. Kapcsold ki a JavaScriptet a böngésződben, és ha eltűnik a szöveg, akkor egy válaszmotor is jóval kevesebbet lát az oldaladból.
Új domainre költözzek, vagy maradjak a régin?
Ha nincs kényszerítő üzleti ok (névváltás, egyesülés, teljes profilváltás), maradj a régi domainen. A domainváltás egy extra kockázati réteget tesz az amúgy is összetett átállásra, és a kettőt nem érdemes egyszerre elvégezni.
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.