telc belső szerverhiba: az 500-as hiba okai és elhárítása

A telc weboldalán megjelenő „500 Internal Server Error” vagy „500.0 Internal Server Error” azt jelenti, hogy a szerver olyan váratlan hibába ütközött, amely megakadályozza a kérés teljesítését. A hiba általános jellegű, ezért önmagában nem mutatja meg, hogy konfigurációs fájl, PHP-kód, bővítmény, sablon, adatbázis, jogosultság vagy tárhelyoldali probléma áll-e a háttérben.

A felhasználó oldalán elsőként érdemes frissíteni az oldalt, megpróbálni a betöltést másik böngészőből, törölni a böngésző gyorsítótárát, illetve néhány perc múlva újra próbálkozni. Ha a hiba tartósan fennáll, minden látogatót érint, vagy a telc oldalán módosítás nélkül jelent meg, akkor valószínűleg szerveroldali hibáról van szó, amelynek kivizsgálásához naplókra és tárhely-hozzáférésre van szükség.

Mit jelent a telc belső szerverhiba?

Az 500-as belső szerverhiba egy HTTP státuszkód, amely arra utal, hogy a szerveren belül valamilyen hiba történt, de a szerver nem tudja pontosan meghatározni, hogy mi az oka. Ez a kód azt jelzi, hogy bár a kérés érvényes, a szerver képtelen volt azt teljesíteni a belső hibák miatt.

Az 500 internal server error gyakorlatilag azt jelenti, hogy a szerver olyan váratlan körülményekkel találkozott, amik megakadályozták a kérés teljesítését. Vagyis azt mondja, hogy valami nem működik rendesen, de nem részletezi a hiba pontos okát.

Amikor a felhasználó felkeres egy weboldalt, akkor a böngészője egy kérést küld a webszervernek, ahol a weboldal található. A szerver fogadja a kérést, feldolgozza, és a kívánt erőforrást (PHP, HTML, CSS, stb.) egy HTTP fejléc kíséretében visszaküldi.

A HTTP fejléc tartalmazza az úgynevezett HTTP státusz kódot is. Ez az állapotkód tájékoztat a lekérés eredményéről. A 200-as állapotkód, azt jelzi, minden rendben van, míg az 500-as hibakód azt jelenti, hogy valami nem sikerült.

Az „internal server error” (500-as belső szerverhiba) azt jelzi, hogy a webkiszolgáló váratlan hibába ütközött, ami megakadályozza a weboldal betöltését. Ez egy általános hiba, ami a szerver oldalán merült fel, a hiba pontos okát nem tudja a szerver megadni a felhasználónak, mert nem tudja végrehajtani a kérést.

Az 500-as hiba nem feltétlenül a tárhelyszolgáltató hibája

Bár szerverhibának van elnevezve, korántsem biztos, hogy a szerveren keresendő az ok, gyakran felhasználói oldalon keletkezik a probléma. Az 500 hibakód üzenetet általában társítani szokták a webszerver összeomlási problémájával, de ez a hibaüzenet nem feltétlenül jelenti a tárhelyszolgáltató felelősségét.

A hiba oka lehet a telc weboldalának valamelyik frissítése, hibás konfigurációs fájlja, PHP-kódja, bővítménye vagy sablonja, de előfordulhat adatbázis-, jogosultság-, erőforrás- vagy szerveroldali üzemzavar is.

Hogyan különbözik az 500-as hiba más hibakódoktól?

Fontos, hogy az 500-as internal server error nem keverendő össze a 404-es válaszkóddal, ami azt jelenti, hogy a kért oldal nem található: 404-es hiba.

Az 500-as hibakódnak sokféle fajtája van (501,502, 503, 504, stb.) és mindegyik egy kicsit mást jelent. A mi esetünkben az 500-as hibakód azt jelenti, hogy a szerver olyan váratlan hibába ütközött, ami miatt nem tudja teljesíteni a kérést.

Az 500-as hiba lehetséges megjelenései

Az 500-as hibakód pontos megjelenése és szövege változhat attól függően milyen böngészőt használsz, és milyen a szerver beállítása, vagy az milyen operációs rendszert használ.

• HTTP 500
• 500 Internal Server Error
• Internal Server Error
• HTTP 500 - Internal Server Error
• 500 Error
• HTTP Error 500
• 500 - Internal Server Error
• 500 Internal Server Error. Sorry something went wrong.
• 500. That’s an error. There was an error. Please try again later. That’s all we know.
• The website cannot display the page - HTTP 500.
• Is currently unable to handle this request. HTTP ERROR 500.

Az is előfordulhat, hogy egy teljesen üres képernyőt látsz csak a képernyőn. Gyakori jelenség az úgynevezett “White Screen of Death” vagyis a fehér halál képernyője.

Ilyenkor a böngésző semmilyen kódot nem jelenít meg, csak egy üres oldalt. Ez legtöbbször azért történik, mert a biztonsági beállítások tiltják a részletes hibaüzenetek megjelenítését a végfelhasználók számára.

Mit tehet a látogató, ha a telc oldalán 500-as hibát lát?

Az oldal frissítése

Frissítsd az oldalt! Ez meglehetősen nyilvánvaló megoldásnak tűnik, de sokszor beválik.

Van, hogy mondjuk túlterhelés miatt egy adott pillanatban a szerver nem tudja teljesíteni a kérést, de néhány másodperccel később már igen. Próbáld meg a böngészőt az F5, vagy Control + F5 billentyűvel frissíteni.

Másik böngésző vagy inkognitó mód használata

Ezzel párhuzamosan megpróbálhatod elérni a keresett oldalt egy másik böngésző alól is. Az első és legegyszerűbb lépés a böngésző gyorsítótárának ürítése vagy az oldal tesztelése inkognitó módban.

Bár a 500.0 hiba alapvetően szerveroldali, a helyi cache néha egy korábbi hibaállapotot tárol el, ami megtévesztheti a fejlesztőt.

A böngésző gyorsítótárának törlése

Gyakran jön jól, ha a böngésződ gyorsítótárját töröld. Ezt megteheted a már írt f5 vagy Control + F5 paranccsal egy konkrét URL esetében.

Ha egy weboldal egészére vonatkozóan akarod, akkor a Chrome esetében a beállítások, további eszközök, böngészési adatok törlése parancsot keresd, ahol egyszerre tudsz több adatot törölni.

A gyorsítótár törlése szintén javíthatja a webhely válaszképességét és megoldhatja a 500-as hibát, ha az ideiglenes fájlok korruptak voltak. Töröld a böngésző cache-t, valamint a webalkalmazások által használt gyorsítótárakat.

Annak ellenőrzése, hogy másoknál is fennáll-e a hiba

Szintén jó próbálkozás, ha megnézed, hogy csak neked, vagy másnak sem elérhető az adott oldal. Próbáld ki a downforeveryoneorjustme.com oldalt, ami megnézi, hogy csak neked, vagy más számára sem elérhető az adott oldal.

Ezek az eszközök a keresett weboldal HTTP fejlécének válaszkódját ellenőrzik. Ha a hiba másoknál is megjelenik, a probléma nagy valószínűséggel nem a látogató számítógépén van.

Ha ezek a megoldások nem segítenek, akkor jó eséllyel szerveroldali hibával van dolgod, amit felhasználóként nem fogsz tudni javítani. Ilyenkor várnod kell, amíg a weboldaltulajdonos javítja a hibát.

A leggyakoribb szerveroldali okok

Az 500.0 hiba ritkán jelentkezik véletlenszerűen. Legtöbbször valamilyen konkrét módosítás, frissítés vagy konfigurációs váltás áll a háttérben.

• Hibás vagy rosszul formázott .htaccess fájl.
• PHP-kódban található szintaktikai vagy végzetes hiba.
• Nem kompatibilis PHP-verzió.
• Hibás bővítmény vagy sablon.
• Adatbázis-kapcsolati probléma.
• Helytelen fájl- vagy könyvtárjogosultság.
• Túl alacsony PHP memória-limit.
• Szervererőforrások túllépése.
• Sérült vagy hiányzó WordPress-fájlok.
• Helytelen szerverkonfiguráció vagy modulszintű hiba.
• Átmeneti tárhelyszolgáltatói üzemzavar.

.htaccess hiba

Az egyik leggyakoribb oka az 500-as hibának, hogy hibás a .htaccess fájl. Az 500‑as hiba általában akkor jelentkezik, ha szintaxis‑hiba van a .htaccess fájlban a webtárhelyeden.

A .htaccess fájlban elhelyezett hibás RewriteRule vagy egy végtelen átirányítási hurok azonnal 500.0 hibát eredményez. A .htaccess fájl helytelen konfigurációja gyakran vezet 500-as hibákhoz.

.htaccess fájlok hibája akkor fordulhat elő, ha az oldalad kompromittálódott, vagy ha te vagy a CMS‑ed érvénytelen parancsokat helyezett el benne. Gyakran az új bővítmények is használják a .htaccess filet, így ezek is eredményezhetik a .htacces file sérülését.

A .htaccess tesztelése

Nevezd át a .htaccess fájlt, hogy megerősítsd, ez okozza‑e a problémát. FTP-n átnevezed és megnézed a honlapodat.

Ha eltűnik az 500 error, akkor készíthetsz új .htaccess fájlt. Mentsd el a régi .htaccess fileodat, majd tölts fel egy teljesen új „tiszta” .htaccess filet

Ha az oldal alapfunkciói visszatérnek, tudod, hogy a konfigurációs fájlban kell keresned a hibát. Próbáld ki a fájl tartalmának ideiglenes kikommentelését vagy alaphelyzetbe állítását, hogy izoláld a hibás direktívát.

Ezután ellenőrizd és javítsd a fájlt a hibákra, majd fokozatosan állítsd vissza a szükséges beállításokat.

PHP-kódhiba és programozási hiba

A hiba szintén előfordulhat, ha PHP‑kódhiba van a webtárhelyen (és a PHP‑hibák megjelenítése le van tiltva); ez többek között akkor jelentkezik, ha a webtárhelyed megtelt, vagy ha kódmódosításokat végeztél.

Fejlesztői oldalon általában úgy sikerül ezt a hibát előidéznünk, hogy írunk egy funkciót és sikerül egy elütést eszközölnünk, pl. kettőspontot a pontosvessző helyett vagy lemarad egy funkció lezárás, pl. egy kapcsos zárójel záró tagja.

Ha egy PHP program futása végzetes hibával leáll, akkor az szintén eredményezhet 500-as internal server error-t. A PHP kódokban előforduló szintaktikai hibák azonnal 500-as hibát okozhatnak.

Ezen hibák azonosítása általában a hibaüzenetben megjelenő sorokban található, ami segít a probléma gyors lokalizálásában és kijavításában.

PHP-verzióváltás és kompatibilitási problémák

Hasonlóan kritikus pont a PHP verziók közötti inkompatibilitás. Ha a kódod régebbi függvényeket használ, vagy a tárhelyeden egy elavult motor fut, a rendszer nem tudja értelmezni az utasításokat.

PHP verzióváltás: Ha nemrégiben változtattad meg a tárhelyen használt PHP-verziót, ez összeütközéshez vezethet a meglévő kódokkal, ami szintén 500-as hibát eredményezhet.

WordPress esetében ez akkor fordulhat elő leggyakrabban, ha a WordPress frissül, de a bővítmények nem. Vagy ha a tárhelyszolgáltatónál PHP verzióváltás történik és a régi verzióban megírt kódok már nem futnak az új PHP verzió alatt

Ma már a legtöbb szerveren a PHP 7.x verziók is telepítve vannak. Azonban, ha régi telepítésű a honlapod, előfordulhat, hogy a honlapod még 5.x verzión fut.

A PHP verzióváltásnál körültekintően kell eljárnod. Érdemes végignézned a használt bővítmények, sablon kompatibilitását a PHP verzióval.

Ma már a sablonokat, bővítményeket a 7-es verziókra írják, és a 7-es verziókban sok funkció nincs már, ami az 5-ösben volt.

PHP-beállítások ellenőrzése

Amennyiben a PHP verzió frissítése okozta a problémát, fontolja meg a korábbi, stabil verzióra való visszaállást.

Ellenőrizd a PHP konfigurációs fájlokat (php.ini), és győződj meg róla, hogy minden beállítás megfelelő és kompatibilis a webhelyen futtatott alkalmazásokkal.

A PHP által generált hibák a tárhely error_log állományában kerülnek rögzítésre. Ezek a log fájlok különösen hasznosak, ha a hiba a PHP kódokban keletkezik.

WordPress-bővítmények hibái

WordPress alapú oldalaknál a pluginok és témák közötti konfliktusok a leggyakoribb bűnösök. Egy frissítés után előfordulhat, hogy két bővítmény ugyanazt a funkciót próbálja meghívni, ami szerverösszeomláshoz vezet.

A második leggyakoribb 500 hiba ok valamelyik bővítmény hibája. Egyesével kapcsold be a bővítményeket és minden bővítmény bekapcsolása után ellenőrizd a honlapod működését.

Így megtalálod a hiba okozóját. És majd eldöntöd, hogy mit kezdesz vele. Például leggyakrabban PHP verzió váltásnál fordul elő, hogy egy-egy régebbi bővítmény nem kompatibilis az új PHP verzióval, így hibát okoz.

Vagy sikerül hibás bővítményt telepítened. A hibásan telepített PHP modulok vagy a hiányzó kiterjesztések, mint például a GD könyvtár vagy az mbstring hiánya, szintén megállíthatják a végrehajtást.

A bővítmények kikapcsolása FTP-n keresztül

Ha FTP-n átnevezed a plugins mappát, az automatikusan a bővítmények kikapcsolásával jár.

Az ftp-n történő átnevezés után lépj be az adminba a bővítmények részhez. Ezután írd vissza a plugins mappa nevet és gyorsan kapcsold ki az admin felületen az összes bővítményt.

Ha nem ebben a sorrendben csinálod, könnyen lehet, hogy visszakapod az 500-as üzenetet, mielőtt át tudnál lépni a bővítmények részbe.

WordPress oldalaknál a leggyorsabb diagnosztikai módszer a pluginok deaktiválása. Ha nem éred el az admin felületet, FTP-n vagy a cPanel fájlkezelőjében nevezd át a wp-content/plugins mappát.

Ha az oldal betölt, egyenként aktiváld a bővítményeket a bűnös megtalálásához.

Sablonhibák

A harmadik gyakori 500-as hiba ok - új sablonnál vagy sablonfrissítésnél szokott leginkább előfordulni -, hogy sablon okozza.

Ha idáig eljutsz a hibakeresésben, akkor valamelyik Twenty sablont érdemes bekapcsolni. Hasonlóan járj el a témákkal is: állítsd vissza az alapértelmezett WordPress témát a hiba kizárásához.

Ha a sablonváltás megoldja a problémádat, akkor eldöntheted, hogy lecseréled a sablont, értesíted a sablon fejlesztőjét, javítod vagy javíttatod.

WordPress hibakeresés engedélyezése

FTP-n keresztül a wp-config.php fájlt töltsd le, nyisd meg egy fájlkezelővel (NEM szövegszerkesztővel!).

Keresd meg ezt a sort: define( „WP_DEBUG”, false ); írd át a false értéket true értékre, mentsd el és töltsd vissza a fájlt a szerverre.

Ellenőrizd a honlapodat. Ha „Fatal error” üzenet látsz, akkor bővítmény vagy sablon okozza a hibát.

Ki kell kapcsolnod (ftp-n átnevezed) az érintett bővítményt. Utána valószínűleg be tudsz lépni az adminba.

Ne felejtsd el a true értéket visszaírni false értékre a konfig fájlban.

Hibanaplók ellenőrzése

A diagnosztizálás első lépése a szerver naplófájlok ellenőrzése. Ezek a naplók tartalmazzák az összes kérés és hiba részleteit, amelyek segíthetnek azonosítani a probléma forrását.

Megtekintheted a naplófájlokat, hogy vannak‑e bejegyzett hibák; ez a „Website” > „Webserver logs” menüpont alatt érhető el a Vezérlőpultunkban.

Van WordPress error.log, van szerver error.log (ez utóbbit többnyire nem látod osztott tárhelyen), de van access.log is, sőt, egyik-másik sablonnak, bővítménynek is láttam már saját error.logját.

Néha a leggyorsabban itt lehet megtalálni az okot, de nem feltétlenül tudja bárki értelmezni. Általában látod az elérési útvonalból, hogy melyik bővítményben van hiba.

Az access.log-ban kereshetsz kifejezetten az 500 értékre, ahol azt is látod, hogy mire vonatkozott a kérés.

Éppen ezért érdemes ezeket mielőbb átnézni vagy hozzáértővel átnézetni, hiszen akár hosszú hibakeresési órákat meg lehet spórolni.

Hibanaplók cPanelben

A cPanel felületen belépve a Fájlkezelő menüpont alatt található error_log fájlok áttekintése alapvető. Itt a keresés funkcióval gyorsan megtalálhatók az adott mappában lévő naplófájlok, amelyek részletes információt nyújtanak a hibák okairól.

Linuxos tárhelyen a cPanel felülete sokat segít. Az “Errors” vagy “Hibák” menüpont alatt az utolsó 300 hibaüzenet azonnal látható, így nem kell SSH-n keresztül keresgélni a logokat.

Jellegzetes hibanapló-bejegyzés

PHP Fatal error: Uncaught Error: Access to undeclared static property: Themify_Builder::$builder_active_id in /home/domain/public_html/wp-content/plugins/themify-builder-pro/includes/class-tbp-utils.php:667

Az ilyen bejegyzésből gyakran látható a hibát okozó bővítmény neve, a fájl elérési útja és a kódsor száma.

Fájljogosultságok és tulajdonjog

A jogosultságok, vagyis a CHMOD beállítások szintén gyakori hibaforrások. Ha egy fájl vagy mappa nem rendelkezik a megfelelő olvasási vagy futtatási joggal, a szerver biztonsági okokból megtagadja a hozzáférést.

Gyakori hibaforrás a fájlrendszer jogosultságainak helytelen beállítása. A szerverek biztonsági protokolljai szigorúak.

A fájlokat általában 644 -re, a könyvtárakat pedig 755 -re kell állítani. A mappák esetében a 755, a fájloknál pedig a 644 érték az iparági sztenderd.

Győződj meg róla, hogy a webhely fájljai és könyvtárai megfelelő jogosultságokkal rendelkeznek. Ellenőrizze és módosítsa ezeket a beállításokat a cPanel vagy FTP kliens segítségével, hogy biztosítsa a megfelelő hozzáférést.

Ha ezek az értékek eltérnek, például egy mappa 777-es (teljesen nyitott) jogosultságot kap, sok modern szerverkörnyezet biztonsági okokból azonnal 500-as hibát dob.

Memória- és erőforrás-korlátok

Az erőforrás-korlátok túllépése a harmadik nagy terület. Ha egy szkript több memóriát igényel, mint a beállított memory_limit, vagy a futási ideje meghaladja a max_execution_time értékét, a folyamat váratlanul megszakad.

Az is előfordulhat, hogy a weboldalad túl sok memóriát használ(na) és ez 500-as hibára fut.

Gyors segítség a wp-config.php-ban a memória limit emelése legalább 128MB-ra [kód: define ( ‘WP_MEMORY_LIMIT’, ‘128M’ );] vagy - szervertől függően - php.ini fájl létrehozása/módosítása, de ez nem biztos módszer.

A memory_limit és max_execution_time értékek növelése is segíthet, ha a hiba a szkript végrehajtási idő túllépése vagy memóriahiány miatt következett be.

A háttérben itt is rosszul kódolt, memória zabáló bővítmények vagy sablonok szokták a hibát okozni, tehát az átmeneti megoldás ellenére át kell nézni a honlapot a végleges megoldásért.

Ugyanakkor ne felejtsd el azt sem, hogy szerveroldalon globálisan meg van határozva egy adott mennyiségű memóriakorlát, amit nem tudsz túllépni.

Ha a hibát rendszeres erőforráshiány okozza, érdemes megfontolni egy skálázható VPS szerver használatát.

Adatbázis-kapcsolati problémák

Valószínűleg találkoztál már az „Error establishing a database connection” hibaüzenettel. Ez azt jelenti, hogy a weboldalad nem tud kapcsolatot létesíteni az adatbázissal.

Ennek egy wordpress oldal esetén több oka is lehet: rossz adatbázis adatokat adtál meg a wp-config.php fileban valamilyen sablon, vagy bővítmény telepítése vagy törlése egy-egy adattábla hibát eredményezett és ezért jelentkezik a hiba.

Próbáld meg a sablonokat, vagy a bővítményt inaktívvá tenni! töröltél, vagy sérült egy fontos WordPress file.

Ez gyakran előfordul akkor is, ha a weboldaladat feltörték. adatbázis szerver hiba. A tárhelyszolgáltatódnál lépett fel valamilyen szerverhiba, ami az adatbázist is kiszolgálja.

Sérült WordPress-fájlok

Ritkán, de előfordulhat, hogy sérült fájlok vannak a WordPressben. A megoldás egyszerű.

Letöltöd, kicsomagolod a WordPresst és ftp-n felmásolod, felülírva a meglévő fájlokat.

Ha a fentiek nem segítettek, akkor a WordPress újratelepítése is segíthet az 500-as hibakód orvosolásában.

A WordPress újratelepítése nem érint az oldal tartalmát, hiszen az adatbázisban van tárolva, míg a bővítmények és sablonok a wp-content mappában helyezkednek el, így ezt biztonsággal megteheted.

Cache- és gyorsítótár-problémák

A gyorsítótárazás (caching) is trükkös lehet. Néha a cache elavult adatokat tárol, ami elrejti a tényleges hibát, vagy éppen maga a gyorsítótár generálása okoz túlterhelést a szerveren.

A gyorsítótár (cache) tisztítása szintén javíthatja a webhely válaszképességét és megoldhatja a 500-as hibát, ha az ideiglenes fájlok korruptak voltak.

Töröld a böngésző cache-t, valamint a webalkalmazások által használt gyorsítótárakat. Ezáltal a rendszer újraépíti a cache fájlokat, ami potenciálisan megszüntetheti a hibát.

Összetett hibák és kompromittált oldal

Ugyan fehér holló, de előfordulhat, hogy bizonyos lépéseknek a fentiekből párhuzamosnak kell lenni.

Pl. egy bővítmény ír a .htaccess fájlba, így egy hibás bővítmény hibássá tudja tenni a .htaccess fájlt is.

Ilyenkor csak akkor van megoldás, ha a bővítményt is kikapcsoljuk és a .htaccess-ből is kivesszük a hibás sor(oka)t.

Ha az oldalad kompromittálódott, a hibás fájlok, módosított konfigurációk vagy sérült WordPress-fájlok szintén 500-as hibát okozhatnak.

IIS és Apache környezet eltérései

Bár a HTTP 500 Internal Server Error egy univerzális kód, a diagnózis menete gyökeresen eltér attól függően, hogy Windows vagy Linux alapú környezetben dolgozunk.

A webszerverek különböző módon naplózzák és tálalják a hibákat, ezért az első lépés mindig az operációs rendszer és a kiszolgáló szoftver azonosítása.

A Windows-alapú IIS (Internet Information Services) sokkal beszédesebb az alkódok tekintetében. Itt a 500.0 gyakran csak a kiindulópont, amit olyan specifikus jelzések követnek, mint a 500.19 (hibás konfigurációs adat) vagy a 500.21 (a modul nem ismerhető fel).

A Windows eseménynaplója (Event Viewer) ilyenkor nélkülözhetetlen, mivel a rendszer szintű hibákat is rögzíti.

Ezzel szemben az Apache vagy Nginx futtató Linux szerverek szűkszavúbbak. Itt szinte minden válasz a szerver error_log fájljában rejlik, amit általában az /var/log/apache2/ könyvtárban vagy a felhasználó saját mappájában találunk meg.

Hibakeresés IIS-környezetben

IIS környezetben a leghatékonyabb eszköz a Failed Request Tracing (FREB). Ez a funkció részletes XML jelentést készít minden olyan kérésről, ami hibával végződik, így pontosan látható, melyik modulnál akadt el a folyamat.

Érdemes ellenőrizni a Handler Mapping beállításokat is, mert ha a szerver nem tudja, melyik motorhoz (például a PHP-hoz vagy az ASP.NET-hez) rendelje a kérést, azonnal leáll.

A hibakeresés javasolt sorrendje

0. lépés: biztonsági mentés

Mindig ezzel kezdj mindent. Lépj be a cpanelbe, directadminba vagy amilyen tárhelykezelő felületed van és csinálj egy biztonsági mentést a honlapod fájljairól és az adatbázisodról.

Érdemes a frissítések előtt biztonsági másolatot készíteni. Ne felejts el biztonsági mentést készíteni, mielőtt módosítasz a fájlokon!

1. lépés: alapvető kliensoldali ellenőrzések

Frissítsd az oldalt, töröld a gyorsítótárat, próbáld ki másik böngészőben, majd ellenőrizd, hogy mások számára is elérhetetlen-e a telc oldal.

2. lépés: hibanaplók átnézése

Ellenőrizd a szerver error_log, a PHP error_log, a WordPress error.log és szükség esetén az access.log fájlokat.

A hiba valódi forrása gyakran a naplófájlban található, amely pontosan megmutatja, melyik szkript vagy konfigurációs sor okozta a leállást.

3. lépés: a .htaccess ideiglenes átnevezése

Nevezd át a .htaccess fájlt, például .htaccess_old névre, majd ellenőrizd az oldalt.

Ha az oldal működni kezd, a hibát a konfigurációs fájlban kell keresni, és új, tiszta .htaccess fájlt kell létrehozni.

4. lépés: a bővítmények kikapcsolása

FTP-n vagy a cPanel fájlkezelőjében nevezd át a wp-content/plugins mappát, majd ellenőrizd, hogy betöltődik-e az oldal.

Ha a hiba megszűnik, nevezd vissza a mappát, és egyenként kapcsold be a bővítményeket.

5. lépés: alapértelmezett sablon bekapcsolása

Állítsd vissza az alapértelmezett WordPress-témát, hogy kizárd a sablon vagy annak frissítése által okozott hibát.

6. lépés: memória- és PHP-beállítások ellenőrzése

Ellenőrizd a memory_limit és max_execution_time értékeket, valamint a PHP-verzió kompatibilitását.

7. lépés: WordPress-fájlok újratelepítése

Sérült WordPress-fájlok esetén töltsd le és telepítsd újra a WordPress magfájljait.

8. lépés: összetett hibák vizsgálata

Vizsgáld meg együtt a bővítményeket, a .htaccess fájlt, a PHP-verziót, a jogosultságokat és az adatbázis-kapcsolatot, mert egyetlen hibás bővítmény több területen is problémát okozhat.

9. lépés: PHP-verzió váltása

A PHP-verzió módosítása előtt ellenőrizd a használt bővítmények és sablonok kompatibilitását.

10. lépés: tárhelyszolgáltató megkeresése

Ha a fenti lépések nem vezetnek eredményre, akkor jön szóba a szerveroldal.

Néha az is előfordul, hogy szerveroldalon frissítenek és valami elcsesződik a beállításokban. Ilyenkor csak a tárhelyszolgáltató tudja megoldani a problémát.

Mikor kell a tárhelyszolgáltatóhoz fordulni?

Ha a 500.0 hiba az összes fájlt és aloldalt érinti, miközben nem végeztél módosítást, valószínűleg globális szerverprobléma vagy hardveres hiba áll a háttérben.

Végül az is előfordulhat, hogy a tárhelyszolgáltatónál jelentkezik valamilyen probléma. A tárhelyszolgáltatódnál lépett fel valamilyen szerverhiba, ami az adatbázist is kiszolgálja.

Ilyenkor nyiss hibajegyet, és pontosan írd le, mikor tapasztaltad először a hibát, illetve milyen lépéseket tettél eddig.

Sokszor a tárhelyszolgáltatók a WordPresst okolják a hiba miatt, ezért ne felejtsd el megírni a tárhelyszolgáltatódnak, hogy milyen lépéseket tettél a hiba kiderítésére, megoldására.

Az 500-as hiba hatása a keresőoptimalizálásra

Szinte minden weboldallal előfordul, hogy átmenetileg nem elérhető egy 500-as hibakód miatt. Ez természetes.

Ugyanakkor a Google-nak az a célja, hogy a találati listája jó minőségű legyen, és ezért azon csak olyan találatok jelenjenek meg, amelyek a felhasználó hasznos tartalmat talál.

A tapasztalat azt mutatja, hogy ha egy weboldal csak néhány órára nem elérhető, az semmiféle problémát nem okoz SEO szempontból.

Ha hosszabb időre, mondjuk 5 napra nem elérhető az oldal, annak már van negatív hatása a rangsorolásra.

John Mueller a Google szóvivője szerint ilyen időtartam esetén, ha az oldal újra helyreáll, akkor hetek kellenek mire az oldal visszanyeri korábbi helyezéseit.

John Mueller szerint: ha egy weboldal nem elérhető, akkor a Google azt újra és újra felkeresi és ellenőrzi. Ha a hiba „néhány napig” fennáll, akkor nem történik semmi, nem törlik sem az indexből, sem a találati listáról.

Ha hosszabb időtávról van szó, mondjuk napok és egy hét közötti időtartam és nem hónapok, akkor egyes oldalak kieshetnek az indexből és a találati listáról.

Amikor az oldal újra elérhetővé válik, először a fontosabb oldalak kerülnek vissza az indexbe, utána a kevésbé fontossak.

De időbe telik, amíg az összes szignál helyreáll, és a belső linkelést is újra tudja térképezni a Google. Emiatt hetekbe is belekerül, míg az oldal teljesen helyreáll.

Fontos ugyanakkor hangsúlyozni, hogy az 500-as HTTP hibákat a Google technikai hibaként kezeli, nem pedig minőségi problémaként.

Teendők hosszabb leállás után

Ha tartósabban, több napra esett ki az oldalad, érdemes lehet új webhelytérképet beküldeni a Search Console-n keresztül, ezzel fel tudod gyorsítani az indexből kiesett oldalak indexelését.

A Search Console Lefedettség menüpontját amúgy is érdemes követni, mert ott a Google kijelzi a 500-as szerverhibákat.

Megelőzés

A 500-as belső szerverhiba megelőzése érdekében fontos, hogy rendszeresen ellenőrizzük és karbantartsuk webhelyünket.

• Rendszeresen ellenőrizd a szerver- és PHP-naplókat.
• Készíts biztonsági mentést minden frissítés és jelentősebb módosítás előtt.
• Ellenőrizd a .htaccess fájl konfigurációját.
• Használj kompatibilis, stabil PHP-verziót.
• Rendszeresen ellenőrizd a kódot hibák, elírások és egyéb problémák szempontjából.
• Vizsgáld a bővítmények és sablonok kompatibilitását.
• Figyeld a memória-, CPU- és tárhelyhasználatot.
• Ellenőrizd a fájl- és könyvtárjogosultságokat.

Naplófájlok rendszeres ellenőrzése: Győződj meg róla, hogy rendszeresen áttekinted a szerver naplófájlokat, hogy azonnal észlelhesd a potenciális problémákat, mielőtt azok súlyosbodnának.

.htaccess fájl pontos beállítása: Ellenőrizd, hogy a .htaccess fájl helyesen van-e konfigurálva. Helytelen beállítások gyakran vezethetnek 500-as hibákhoz.

PHP verzió frissítése: Győződj meg róla, hogy a legfrissebb, stabil PHP verziót használod, amely kompatibilis a weboldaladon futtatott alkalmazásokkal.

Kódellenőrzés: Rendszeresen ellenőrizd a kód hibákat, elírások és egyéb problémák szempontjából, amelyek 500-as hibát okozhatnak.

A hiba pontos diagnosztizálásának és megoldásának képessége létfontosságú egy webhely zökkenőmentes működéséhez.

tags: #telc #belso #szerverhiba