WordPress 2026: megtartsd, javítsd vagy cseréld a meglévő oldalad?

Ha már működik a céges WordPress-oldalad, a döntés nem egy üres lapról indul. Van rajta tartalom, kialakult szerkesztési rutin, keresőből érkező forgalom és esetleg üzletileg fontos bővítmény. Ezek értékét a rendszer cseréjénél ugyanúgy számba kell venni, mint az új megoldás ígért előnyeit.

A WordPress és az egyedi fejlesztés nem kizáró kategóriák: WordPressre is készülhet egyedi sablon, bővítmény vagy külön frontend. Az érdemi kérdés az, hogy a jelenlegi rendszer megtartása, javítása vagy kiváltása ad-e jobb működést elfogadható teljes költséggel.

Ez a cikk meglévő oldalak döntését segíti. Nem rangsorol technológiákat általános sebességpontszám vagy piaci népszerűség alapján. Ugyanaz a technológia jól és rosszul felépített rendszert is kiszolgálhat.

Ne technológiából, hibajegyzékből indulj

Írd le a három legfontosabb problémát konkrét következménnyel. Például az ajánlatkérő űrlap nem küld megbízhatóan, a szerkesztő nem tud önállóan új szolgáltatást felvenni, vagy mobilon túl nehéz végigmenni a rendelésen. Ezek különböző beavatkozást indokolnak.

Kérj felmérést a tárhelyről, sablonról, aktív bővítményekről, egyedi kódról és külső kapcsolatokról. Legyen hozzáférési leltár és mentés is. Egy ismeretlen eredetű lassulást nem lehet pusztán a WordPress nevéből diagnosztizálni.

Nincs általános határ, amely felett egy bizonyos oldalszám szükségszerűen lelassítja az adminisztrációt. A tartalomszerkezet, lekérdezések, bővítmények és infrastruktúra együtt számítanak. Az oldalak előállítási ideje pedig attól függ, hogyan működik a konkrét rendszer; nem minden WordPress-oldalnál van statikus építési folyamat.

Mikor érdemes megtartani?

A megtartás mellett szól, ha a szerkesztők önállóan dolgoznak, a fontos funkciók működnek, és a fenntartási költség vállalható. Egy bevált többnyelvű tartalmi folyamat vagy üzletileg kritikus foglalási bővítmény kiváltása komoly projekt lehet. A csere ilyenkor könnyen újra megoldja azt, ami már működött.

Szemléltető helyzet: egy tanácsadó cég csapata rendszeresen publikál szakmai cikkeket, a kapcsolati űrlap megbízható, a mobilos felület használható. Ha csak a nyitóoldal megjelenése elavult, először a sablon módosítását érdemes vizsgálni. Ez nem ügyféleset és nem megtérülési ígéret, hanem döntési ellenpélda az automatikus teljes cserére.

Maradás esetén is legyen terv a felesleges bővítmények, túl széles jogosultságok és elavult összetevők rendezésére. A WordPress biztonsági útmutatója külön kezeli ezeket a feladatokat. A platform megtartása nem jelentheti a felügyelet elhagyását.

Mikor elég célzott javítás?

Ha a problémának azonosítható oka van, kérj körülhatárolt javítási ajánlatot. Nagy képek, szükségtelen külső szkriptek, hibás gyorsítótárazás vagy rosszul működő űrlap külön is kezelhető lehet. A javítás után ugyanazon feladaton, összehasonlítható körülmények között mérj újra.

A teljesítményvizsgálat fedje le a fontos oldaltípusokat és a valódi használatot. A főoldal laborpontszáma nem mondja meg, mennyi idő alatt küldhető el egy ajánlatkérés, vagy működik-e a bejelentkezett ügyfél pénztára. Rögzítsd az eszközt, hálózatot, mérési időpontot és azt, labor- vagy valós felhasználói adatról van-e szó.

A javítás költségét a várható élettartammal együtt értékeld. Ha egy elhagyott bővítmény helyett csak átmeneti kerülőmegoldás készül, az időt nyerhet, de nem szünteti meg a későbbi cserét. Ezt a műszaki ajánlatnak világosan jeleznie kell.

Mikor lehet értelme külön frontendnek?

A WordPress tartalomkezelőként megtartható, miközben a látogatói felület külön készül. A hivatalos REST API lehetőséget ad a tartalmak programozott elérésére. Ez akkor lehet hasznos, ha a szerkesztési oldal bevált, de a megjelenítés vagy több felület kiszolgálása más megoldást kíván.

Az API azonban nem varázsolja át automatikusan minden bővítmény felületét. Az előnézet, keresés, űrlap, belépés és egyedi mezők összekötése külön munka lehet. Ha a jelenlegi oldalépítő összetett elrendezést tárol, azt is meg kell vizsgálni, hogyan használható fel az új oldalon.

A headless változat két rendszer fenntartását is jelentheti. A szerkesztő nem veszítheti el a megbízható előnézetet és a publikálási visszajelzést. Ezek részletes követelményeit a headless CMS-ről szóló cikk tárgyalja; itt a döntő kérdés az, hogy a megőrzött szerkesztési érték ellensúlyozza-e az új integrációt.

Mikor indokolt teljes csere?

Erős érv lehet a csere mellett, ha a kulcsfunkció támogatása megszűnt, a rendszer érdemben nem tartható karban, vagy az új üzleti folyamat aránytalan mennyiségű kerülőmegoldást igényelne. Egyedi partnerárak, összetett rendelésfeldolgozás vagy több rendszer közötti adatkapcsolat esetén a tényleges követelmények alapján kell választani.

A statikus bemutatkozó oldal, a szerkesztőségi webhely és a tranzakciókat kezelő webshop külön feladat. A kevés oldal önmagában nem indokol statikus megoldást, ahogyan a nagy termékszám sem jelöl ki automatikusan egy webáruház-platformot. A frissítési igény, az adminisztráció és az integráció fontosabb döntési tényező.

Új rendszerben sem automatikus a jó sebesség vagy az akadálymentesség. Egyedi kódban is lehet hibás fókuszkezelés, olvashatatlan kontraszt vagy elérhetetlen űrlap. A W3C szerint az automatizált ellenőrzés mellett emberi értékelés is szükséges. Egy technológianév és egy jó pontszám nem helyettesít teljes körű megfelelőségi vizsgálatot.

Hasonlíts össze teljes költséget

Lehetőség	Egyszeri munka	Tartós kötelezettség
Megtartás	Állapotfelmérés és szükséges rendbetétel	Frissítés, licencek, tárhely, támogatás
Célzott javítás	Konkrét hibák és szűk keresztmetszetek megszüntetése	Meglévő rendszer fenntartása
Külön frontend	Integráció, előnézet és új felület	CMS és frontend együttes karbantartása
Teljes csere	Új rendszer, adatköltözés, oktatás, átállás	Új szolgáltatások és fejlesztői támogatás

Válassz közös összehasonlítási időtávot, például három évet – ez tervezési választás, nem általános megtérülési szabály. Add össze az induló munkát, rendszeres díjakat, licenceket, szerkesztői ráfordítást és a szükséges változtatásokat. A csere oldalán az átmeneti párhuzamos működés és a belső betanulás is szerepeljen.

Külön értékeld a fejlesztőfüggőséget. Kié a forráskód, a domain, a tárhelyfiók és a licenc? Elérhető-e a telepítési leírás? Másik szolgáltató képes-e felállítani a rendszert? A nyílt forráskód előny lehet, de a dokumentálatlan egyedi működés így is nehezen átadható.

Költözés: a tartalom átvitele csak a kezdet

Készíts leltárt a régi címekről, képekről, letöltésekről, metaadatokról, űrlapokról és fontos kapcsolódásokról. Minden értékes URL kapjon megfelelő céloldalt vagy indokolt megszüntetést. Ne irányíts minden megszűnt címet válogatás nélkül a főoldalra.

Az átirányításokat, belső linkeket, kanonikus címeket és oldaltérképet indulás előtt ellenőrizni kell. A Google költözési útmutatója az URL-térképezést és tartós átirányításokat is tárgyalja, és számol átmeneti keresési ingadozással. A helyes átirányítás fontos, de nem garantál változatlan helyezést.

Webshopnál a nyitott rendelések, készletek, ügyféladatok és külső fizetési állapotok kezelése külön átállási tervet igényel. Legyen időpont, felelős, adatellenőrzés és visszalépési feltétel. A régi rendszer visszakapcsolása új rendelések után már adat-egyeztetést is igényelhet; ez nem mindig egyszerű kapcsoló.

A Neocart mint külön megvizsgálható lehetőség

A Conen Neocart-ajánlata a 2026. október 18-i állapot szerint ingyenes webáruház-motort és alapfunkciókat ad: nincs licencdíj, havi szoftverdíj vagy forgalmi jutalék. A tárhely 4 990 vagy 9 990 Ft/hó + áfa, az élesítés 49 900 Ft + áfa. A domain külön fizetendő. Az egyedi weboldalak ára ajánlat alapján alakul.

A motor Medusa 2 és Postgres alapú, Astro-kirakattal és boltonként külön motorpéldánnyal. A rendelkezésre álló funkciók között magyar adminisztráció, SimplePay-fizetés, Számlázz.hu-számlázás és GLS-kezelés szerepel. A tárhely ára nem jelenti automatikusan az adatköltözés, teljes karbantartás vagy minden egyedi fejlesztés díját.

Az ingyenes, regisztráció nélküli Neocart-tervező a megjelenés kipróbálását, tervmegosztást és ajánlatkérést teszi lehetővé. Nem indít saját domainen önkiszolgáló módon éles boltot. A Piactér készül; tervezett modulokra nem érdemes a jelenlegi migráció üzleti követelményeit alapozni.

A Neocartot ugyanazon saját termékeken, rendelési folyamatokon és átadási feltételeken vizsgáld, mint bármely más alternatívát. Egy már működő WordPress-oldal lecserélését önmagában az új ajánlat létezése nem indokolja.

Mi legyen a döntés kézzelfogható eredménye?

Kérj rövid döntési dokumentumot: jelenlegi hibák, megtartási és csereváltozat, teljes költség, felelősök, elfogadási próbák és visszaállítás. A szerkesztő próbálja ki a saját feladatait, az üzleti vezető pedig hagyja jóvá a kiesési és átállási kockázatot.

A jó döntés lehet maradás, célzott javítás vagy csere is. Akkor megalapozott, ha egy kimondott üzleti problémát old meg, és az új működés költsége, felelőssége és későbbi átadhatósága is érthető a vállalkozás számára.