Ha a fejlesztőd nem veszi fel a telefont, nem válaszol az e-mailekre, és közben az oldalad megy tovább (vagy éppen nem megy), az első reakció általában a kapkodás. A helyzet a legtöbb esetben megoldható, csak a sorrend számít: előbb az irányítást kell visszaszerezned, és csak utána szabad bárkit hozzáengedni a kódhoz. Ez a cikk pontosan ezt a sorrendet írja le, olyan formában, hogy technikai tudás nélkül is végig tudd vinni, vagy legalábbis pontosan tudd, mit kérj attól, aki segít.
Mikortól számít tényleg elérhetetlennek egy fejlesztő?
Rövid válasz: akkor, ha két különböző csatornán (e-mail és telefon vagy üzenetküldő), legalább egy hét különbséggel megpróbáltad elérni, és sem választ, sem automatikus visszajelzést nem kaptál. Ilyenkor már nem várakozni kell, hanem párhuzamosan elindítani a hozzáférések visszaszerzését.
Tovább a témában: TTFB csökkentése magyar tárhelyen · WordPress vagy egyedi fejlesztés? Döntési szempontok
A gyakorlatban három nagyon különböző eset szokott ugyanígy kinézni kívülről, pedig teljesen más a megoldásuk. Az első: a fejlesztő él és virul, csak leterhelt vagy nyaral, és pár hét múlva jelentkezik. A második: felhagyott a szakmával, esetleg megszűnt a vállalkozása, és nem érzi feladatának, hogy lezárja a régi ügyfeleit. A harmadik, a legritkább, de a legnehezebb: tartós betegség vagy haláleset.
Saját tapasztalat: a legtöbb megkeresés, ami ilyen ügyben érkezik, a második esetbe tartozik. Az oldal működik, a domain még nem járt le, csak évek óta senki nem nyúlt hozzá, és most kellene egy módosítás, amit nincs kinek megrendelni. Ez a jó hír, mert ilyenkor az idő általában dolgozik neked: van néhány heted rendezni a dolgot, mielőtt bármi elromlana.
Szakmai feltételezés: a valódi határidőt szinte mindig a domain vagy a tárhely megújítási dátuma szabja meg, nem az oldal állapota. Ha ezek automatikus levonással, a fejlesztő kártyájáról újulnak meg, akkor a következő megújítási dátum a tényleges határidőd.
Mely hozzáférések döntik el, hogy tényleg a tiéd-e a weboldal?
Rövid válasz: a domain és a tárhely. Ez a kettő nélkül a WordPress admin-jelszó önmagában szinte semmit nem ér, ezzel a kettővel viszont akkor is menthető az oldal, ha minden más hozzáférés elveszett.
Írd össze egy papírra vagy egy táblázatba, melyikre van meg a belépésed, melyikre nincs. Ez a lista lesz az alapja mindennek, ami utána jön:
- Domain (a webcím maga): a regisztrátornál vezetett fiók, ahol a névszerverek és a lejárati dátum állítható. Ez a legfontosabb elem.
- Tárhely vagy szerver: a szolgáltató ügyfélfiókja, plusz a vezérlőpult (cPanel, Plesk, ISPmanager vagy hasonló).
- WordPress adminisztrációs felület: egy adminisztrátor jogú felhasználó a saját e-mail-címeddel.
- Adatbázis: általában a tárhelyfiókon keresztül érhető el, külön kezelni ritkán kell.
- E-mail-fiókok: ha a cég levelezése ugyanazon a domainen fut, ez legalább olyan kritikus, mint maga az oldal.
- Prémium bővítmények és sablonok licenckulcsai: ezek gyakran a fejlesztő saját fiókjában vannak, és a frissítéshez kellenek.
- Külső fiókok: Google Search Console, Google Analytics, hirdetési fiókok, hírlevélrendszer, online fizetési szolgáltató.
Saját tapasztalat: a leggyakoribb hiányzó elem nem a WordPress admin, hanem a licenckulcs. Az oldal működik, csak a fizetős bővítmények nem frissülnek, és ez fél év alatt komoly biztonsági kockázattá érik.
Hogyan derítheted ki, hol van egyáltalán az oldalad?
Rövid válasz: nyilvános lekérdezésekkel, ingyen, néhány perc alatt. A domain regisztrátora és a névszerverek nyilvános adatok, ezekből visszafejthető, kinél kell kopogtatnod.
A domain adatai a nyilvános nyilvántartásból kérdezhetők le. Terminálban ez így néz ki:
whois pelda.hu
A .hu domainek esetében a nyilvántartó felülete is megmutatja a regisztrátor nevét és a lejárati dátumot. Ha nincs kedved terminálhoz nyúlni, keresd a nyilvántartó nyilvános domainkereső oldalát, ott ugyanez kattintással kijön.
A névszerverek, vagyis hogy melyik szolgáltató kezeli ténylegesen a domain beállításait:
dig pelda.hu NS +short
Az pedig, hogy fizikailag melyik szerveren fut az oldal:
dig pelda.hu A +short
Hivatalosan igazolt: a domainregisztrációs adatok kezelését és a nyilvántartó szerepét a magyar domainek esetében az Internet Szolgáltatók Tanácsa domainregisztrációs szabályzata rendezi, a technikai lekérdezések működése pedig a DNS-re vonatkozó nyílt szabványokon (IETF RFC-k) alapul. Ezek nyilvános dokumentumok, bárki elolvashatja őket.
Ha a whois-ban a te neved vagy a cégneved szerepel domainhasználóként, akkor jogilag erős helyzetben vagy: a regisztrátornál kérheted a fiókhoz való hozzáférés rendezését, jellemzően cégiratos, aláírt igazolással. Ha a fejlesztő neve szerepel ott, az nehezebb ügy, de nem reménytelen: ilyenkor a szerződésed, a számláid és a korábbi levelezésed lesz a bizonyíték amellett, hogy a domain a te megrendelésedre, a te érdekedben lett bejegyezve.
Mit tegyél, ha egyetlen belépésed sincs?
Rövid válasz: haladj kívülről befelé. Előbb a domain, aztán a tárhely, végül a WordPress. Fordított sorrendben nem működik, mert a WordPress-hozzáférés a tárhelyről mindig visszaállítható, a domain viszont nem szerezhető meg a WordPressből.
- Domain: keresd meg a regisztrátort a fenti lekérdezéssel, és írj nekik a cég hivatalos e-mail-címéről. Készítsd elő a cégkivonatot, az aláírási címpéldányt és minden számlát, ami a domainhez köthető.
- Tárhely: a szolgáltatót gyakran a szerver IP-címéből vagy a régi számláidból lehet beazonosítani. Nézd át a könyvelésed: a tárhelydíj általában külön tételként fut évek óta.
- WordPress: ha a tárhelyfiók megvan, innen már technikai kérdés. A vezérlőpult fájlkezelőjében megtalálható a
wp-config.php, benne az adatbázis neve, és onnan új adminisztrátor létrehozható. Ha van parancssori hozzáférés, WP-CLI-vel ez egyetlen sor:
wp user create ujadmin te@pelda.hu --role=administrator
Szakmai feltételezés: ha se a domain, se a tárhely nincs a nevedre kiállítva, és a fejlesztő tartósan nem elérhető, akkor a legvalószínűbb kimenetel az, hogy a tartalmadat mented, és új domainre vagy új tárhelyre költözöl. Ez fájdalmas, mert a keresőkben felépített pozíciók egy része átmenetileg sérülhet, de sokszor gyorsabb, mint hónapokig várni egy olyan válaszra, ami talán soha nem jön. A döntést mindig konkrét helyzetismeret alapján érdemes meghozni.
Mit csináljon az új karbantartó az első héten?
Rövid válasz: ne fejlesszen. Az első hét az átvilágításról és a biztonsági alapok helyreállításáról szól, mert egy elárvult oldalnál senki nem tudja előre, mi van a motorháztető alatt.
Ez az a lista, amit érdemes kérned tőle, és amit vissza is kérhetsz írásban:
- Teljes mentés a saját tárhelyeden kívülre, még mielőtt bármihez hozzányúl. Fájlok és adatbázis egyben.
- Felhasználók átnézése: hány adminisztrátor van, mindegyiket ismered-e, van-e ismeretlen e-mail-címről létrehozott fiók.
- A WordPress mag épségének ellenőrzése. WP-CLI-vel:
wp core verify-checksums. Ez megmutatja, ha valaki módosította az alaprendszer fájljait. - Bővítmény- és sablonleltár: mi van telepítve, mi aktív, mi frissíthető, és melyik nem kapott frissítést hosszú ideje. Kiindulásnak:
wp plugin list. - PHP-verzió és adatbázis-verzió ellenőrzése, mert egy elhanyagolt oldal gyakran évekkel korábbi, már nem támogatott környezeten fut.
- Tanúsítvány és átirányítások: érvényes-e a HTTPS, és tényleg egyetlen címváltozatra fut-e össze minden verzió.
- Search Console-ellenőrzés: vannak-e indexelési hibák, kézi műveletek, biztonsági figyelmeztetések.
- Jelszócsere minden hozzáférésen, plusz kétlépcsős azonosítás bekapcsolása ott, ahol lehet.
Saját tapasztalat: egy régóta magára hagyott oldalnál nagyon gyakori, hogy a mentés vagy egyáltalán nem fut, vagy ugyanarra a tárhelyre készül, ahol az oldal is van. Ez utóbbi pontosan abban az esetben nem segít, amikor a legnagyobb szükség lenne rá.
Miről ismered fel, hogy jó kezekbe kerül az oldalad?
Rövid válasz: arról, hogy az első beszélgetésen nem a következő fejlesztésről beszél, hanem a hozzáférésekről, a mentésről és arról, mi történik akkor, ha ő is elérhetetlenné válik.
Néhány kérdés, amit érdemes feltenned, mielőtt megbízol valakit:
- Kinek a nevére kerül a domain és a tárhely? A helyes válasz: a tiédre.
- Kapok-e saját adminisztrátori hozzáférést az oldalhoz, és megtartom-e azt akkor is, ha a együttműködésünk véget ér?
- Hova készül a mentés, milyen gyakran, és mennyi ideig áll rendelkezésre?
- Ha holnap megszűnne az együttműködésünk, mit adsz át, és milyen formában?
- Ki fizeti a licenceket, és kinek a fiókjában vannak?
- Van-e olyan dokumentáció, amiből egy másik szakember dolgozni tud?
Ha valaki ezekre kitérően válaszol, vagy azt mondja, hogy „ezzel neked nem kell foglalkoznod”, az önmagában komoly figyelmeztető jel. Nem szakértelmi kérdés: pontosan ez a hozzáállás vezet oda, ahol most vagy.
Mennyit veszíthetsz, ha hónapokig nincs karbantartás?
Rövid válasz: jóval többet, mint amennyi az oldalon látszik. A kockázat nem csak a feltörés, hanem a lassú, észrevétlen leépülés is.
A frissítés nélkül hagyott bővítmények ismert sérülékenységeket hordoznak, és ezeket automatizált robotok keresik, nem célzott támadók. Ez azt jelenti, hogy a „minket úgysem keres senki” érvelés itt nem működik.
Hivatalosan igazolt: a Google dokumentációja szerint a feltört, kártékony tartalmat kiszolgáló oldalak biztonsági figyelmeztetést kaphatnak a keresési találatokban, ami közvetlenül csökkenti az átkattintást. Ugyanígy hivatalos információ, hogy a Google az oldalélmény-mutatókat (például a Core Web Vitals értékeit) a rangsorolásnál figyelembe vett jelek között tartja számon.
Szakmai feltételezés: az AI-alapú válaszmotorok korában ennek van egy további rétege is. Ezek a rendszerek friss, elérhető és gépileg jól értelmezhető oldalakat idéznek szívesebben. Egy hónapokig hibás, lassan betöltő vagy időnként leálló oldal jó eséllyel ritkábban kerül be a hivatkozott források közé. Ez nem bizonyított összefüggés, és semmilyen karbantartás nem garantál sem helyezést, sem említést, de a megbízható működés olyan alap, ami nélkül a többi munka sem tud érvényesülni.
Hogyan előzöd meg, hogy ez még egyszer megtörténjen?
Rövid válasz: egyetlen, karbantartott dokumentummal, amiben minden hozzáférés a tiéd, és amit rajtad kívül más nem birtokol egyedül.
Hozz létre egy hozzáférés-nyilvántartást, lehetőleg jelszókezelőben, és tarts benne minden fiókot: domain, tárhely, WordPress, e-mail, licencek, Search Console, hirdetési és mérési fiókok. Minden sorhoz írd oda, kinek a nevén van, mikor jár le, és ki fizeti. Évente egyszer nézd át.
Ezen felül három dolog ér sokat: a domain és a tárhely mindig a cég nevén és a cég e-mail-címén legyen; a mentés fusson az oldaltól független helyre; a fejlesztői hozzáférés pedig legyen külön felhasználó, amit az együttműködés végén egyetlen mozdulattal ki tudsz kapcsolni. Ez a három lépés nem véd meg minden bajtól, de azt a helyzetet, amiről ez a cikk szól, jó eséllyel megelőzi.
Források és további olvasnivalók
- Google Search Central: dokumentáció a feltört oldalakról és a biztonsági problémákról
- Google Search Central: az oldalélményre és a Core Web Vitals mutatókra vonatkozó útmutató
- WordPress.org: Hardening WordPress (biztonsági alapok) és a WordPress Backups fejlesztői dokumentáció
- WP-CLI hivatalos parancsreferencia
- Internet Szolgáltatók Tanácsa: Domainregisztrációs Szabályzat (.hu domainek)
- IETF RFC 1034 és RFC 1035: a DNS működését leíró alapszabványok
- Schema.org: strukturált adatok szótára
- W3C: webes akadálymentességi és technikai ajánlások
- Az oldalad tulajdonjogát nem a WordPress admin, hanem a domain és a tárhely feletti rendelkezés adja.
- Először gyűjtsd össze és írd át magadra a hozzáféréseket, csak utána bízz meg új karbantartót.
- Ha semmilyen belépésed nincs, a domain regisztrátora és a tárhelyszolgáltatója az a két pont, ahonnan írásbeli tulajdonosi igazolással el lehet indulni.
- Az új karbantartónak az első héten biztonsági és mentési átvilágítást kell csinálnia, nem új funkciókat fejlesztenie.
- Egy karbantartás nélkül hagyott oldal nemcsak biztonsági kockázat: a hibás, lassú vagy leálló oldal a keresőkben és az AI-válaszmotorokban is visszaeshet.
Gyakori kérdések
Kié a weboldal, ha a fejlesztő nevén van a domain?
A domainhasználó jogi helyzetét a nyilvántartás adatai és a köztetek lévő szerződés együtt döntik el. Ha a domaint a te megrendelésedre, a te cégneveddel regisztrálták, és erről vannak számláid és levelezésed, a regisztrátornál el tudod indítani a rendezést. Ha a fejlesztő a nyilvántartott használó, akkor ez jellemzően jogi kérdéssé válik, és érdemes ügyvéddel átnézetni a szerződést.
Hozzá tudok férni a WordPress adminhoz, ha nincs meg a jelszó?
Igen, ha a tárhelyhez van hozzáférésed. A tárhely vezérlőpultjából elérhető az adatbázis, és ott új adminisztrátori felhasználó hozható létre, vagy a meglévő jelszava átírható. Parancssoros hozzáférésnél a WP-CLI egyetlen paranccsal megoldja. Tárhely-hozzáférés nélkül viszont a WordPress admin önmagában nem visszaszerezhető.
Mennyi idő alatt lehet átvenni egy elárvult WordPress oldalt?
Ha minden hozzáférés megvan, az átvilágítás és a biztonsági rendrakás jellemzően néhány nap. Ha hozzáféréseket kell visszaszerezni a regisztrátortól vagy a tárhelyszolgáltatótól, az ügyintézés hetekre is nyúlhat, mert dokumentumokat kell benyújtani és azokat feldolgozzák. Ez az adminisztratív rész az, amit nem lehet felgyorsítani.
Kell-e új oldalt csináltatnom, ha a régi fejlesztő eltűnt?
A legtöbb esetben nem. Ha a domain és a tárhely a tiéd, és az oldal működik, akkor átvehető, frissíthető és tovább fejleszthető. Új oldal akkor indokolt, ha az alaptechnológia elavult, egyedi kód tartja életben, amihez nincs dokumentáció, vagy ha a hozzáférések véglegesen elvesztek.
Árt-e a keresőoptimalizálásnak, ha hónapokig nem nyúlt senki az oldalhoz?
A pihenő tartalom önmagában nem büntetés, de a nem frissített rendszer több ponton is árthat: biztonsági incidens, lassulás, hibás oldalak, lejáró tanúsítvány. Ezek mind ronthatják a keresőkben és az AI-válaszmotorokban való szereplés esélyét. A helyreállítás után a helyzet jó eséllyel javul, de ez nem garantálható és nem azonnali.
Mit adjak át az új karbantartónak elsőként?
A tárhely és a domain hozzáférését, egy saját adminisztrátori fiókot a WordPresshez, és minden olyan információt, amit a régi fejlesztőről tudsz: mikor volt az utolsó ismert munkája, milyen bővítmények voltak fizetősek, hol futott a mentés. Ha valamiről nincs adatod, azt is mondd meg, mert az önmagában is fontos információ a felméréshez.
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.