A szerverleállás nem SEO-kérdésként indul: kiesik egy adatbázis, elfogy a memória, lejár egy tanúsítvány, vagy a tárhelyszolgáltatónál van üzemzavar. Néhány óra múlva viszont már mindenki azt kérdezi, hogy ebből mennyi látszik majd a Google-ben. A tapasztalat az, hogy a válasz sokkal kevésbé függ a kiesés hosszától, mint attól, hogy a szerver mit mondott a bejáró robotoknak, amíg nem működött. Ugyanaz a négy órás leállás lehet teljesen következmény nélküli, és lehet olyan, aminek a nyomát hetekig takarítod. Ez a cikk azt járja körbe, mit lát a Google 500-as és 503-as hiba alatt, hogyan állítsd be a karbantartási módot, és mit csinálj a visszatérés után.
Mit lát a Google, amikor a szervered nem válaszol?
Röviden: a Googlebot ugyanazt látja, mint bármelyik böngésző, csak sokkal szigorúbban értelmezi. A státuszkód a jelzés, nem a hibaoldal szövege.
Tovább a témában: Soft 404 és a hibás oldalak · Cache-Control és Vary fejlécek helyes beállítása magyar tárhelyen
Hivatalosan igazolt: a Google dokumentációja szerint az 5xx családba tartozó válaszokat és a 429-et (túl sok kérés) a Googlebot átmeneti hibaként kezeli. Ilyenkor csökkenti a bejárási sebességet, és később újrapróbálkozik. Ha a hiba tartósan fennáll, az érintett URL végül kikerülhet az indexből. A hálózati időtúllépés és a DNS-hiba szintén hibaként rögzül, de ott a Google kevesebb információt kap: nem tudja megkülönböztetni a rövid üzemzavart a végleges megszűnéstől.
Fontos részlet, amit sokan kihagynak: a robots.txt külön elbírálás alá esik. Ha a robots.txt kérése 5xx hibát ad vissza, a Google úgy tekinti, hogy a site bejárása korlátozott, és visszafogja vagy leállítja a feltérképezést, még akkor is, ha maguk az oldalak elérhetők lennének. A dokumentáció szerint 30 napon túli elérhetetlenség esetén a legutóbbi gyorsítótárazott változatot használja, ennek hiányában feltételezi, hogy nincs korlátozás. Ez azt jelenti, hogy egy rosszul beállított karbantartási mód, amely a robots.txt-re is 503-at ad, gyakorlatilag befagyasztja az egész site bejárását a leállás idejére.
Meddig tolerálja a Google az átmeneti hibát?
Nincs nyilvánosan közölt óraszám. A gyakorlatban a néhány órás kiesés általában nyom nélkül elmúlik, a több napos viszont már látszik a bejárási grafikonon és az indexelt oldalak számán.
Szakmai feltételezés: a Google nem publikál konkrét küszöböt, és jó okkal nem teszi, mert a viselkedés site-onként eltér. Egy naponta többször bejárt hírportálnál a hiba órák alatt feltűnik a rendszernek, egy havonta egyszer meglátogatott aloldalnál akár az is előfordulhat, hogy a Googlebot a teljes leállást átaludta, és soha nem is találkozott a hibával. Ez az aszimmetria magyarázza, miért mesél két webmester ugyanarról a hosszúságú kiesésről teljesen mást.
Saját tapasztalat: az ügyfélprojektekben látott mintázat az, hogy a néhány órás, helyesen jelzett kiesés után a bejárási aktivitás pár napon belül visszaáll a korábbi szintre, és a pozíciókban nem marad tartós nyoma. Az egy-két napos leállásnál már látszik a Search Console Feltérképezési statisztikáiban a hiba-arány megugrása, és jellemzően lassabb, egy-két hetes visszaállás jön. A tartós, hetekig fennálló hiba viszont már valódi index-fogyást okoz, és onnan a visszaépülés hónapokban mérhető. Ez a tapasztalat nem garancia, csak irány: a saját site-od bejárási gyakorisága felülírhatja.
Miért jobb az 503-as válasz, mint az időtúllépés vagy a 200-as hibaoldal?
Mert az 503 az egyetlen olyan válasz, amely pontosan azt közli, ami történik: az oldal létezik, de most nem elérhető, és később érdemes visszajönni.
Három forgatókönyvet érdemes szembeállítani. Az időtúllépés esetén a kapcsolat egyszerűen elhal. A Googlebot nem kap kódot, nem kap becslést, ezért a saját, óvatos logikája szerint lassít. Ez nem katasztrófa, de információszegény, és a kapcsolódási hibák a bejárási költségvetést is pazarolják. Az 500-as válasz már beszédesebb: belső szerverhiba, tehát valami elromlott. Átmeneti hibaként kezeli a Google, de nem tudja, meddig tart, és a hosszan tartó 500 azt sugallja, hogy a site karbantartás nélkül maradt.
Az 503-as ezzel szemben szándékos, kezelt állapotot jelez, és mellé tehető a Retry-After fejléc, amely megmondja, mikor érdemes visszatérni. A HTTP-szabvány szerint ez lehet másodpercben megadott érték (Retry-After: 3600) vagy konkrét időpont HTTP-dátum formában. A Google dokumentációja kifejezetten a 503-at javasolja tervezett karbantartásra.
A legrosszabb megoldás pedig az, amit a legtöbb bővítmény alapból csinál: 200-as státusszal kiszolgált karbantartási oldal. Ilyenkor a Google azt látja, hogy az oldal rendben van, és a tartalma az, hogy "Hamarosan visszatérünk". Ha ebből az állapotból újraindexel egy sablonoldalt, a keresési találatban a valódi tartalom helyére kerülhet a karbantartási szöveg, és az azonos szövegű aloldalak tömegesen minősülhetnek gyenge vagy duplikált tartalomnak. A helyreállítás itt nem a szerver visszakapcsolásával ér véget, hanem akkor, amikor a Google újra bejárta és lecserélte a rossz pillanatképet.
Hogyan állítsd be a karbantartási módot WordPressben?
A cél mindig ugyanaz: 503-as státusz, reális Retry-After, ember számára olvasható rövid tájékoztatás, és érintetlen robots.txt.
Webszerver szintjén
Ha hozzáférsz a szerver konfigjához, ez a legmegbízhatóbb, mert akkor is működik, ha maga a PHP vagy az adatbázis fekszik. Apache alatt a .htaccess így néz ki:
RewriteEngine OnRewriteCond %{DOCUMENT_ROOT}/.karbantartas -fRewriteCond %{REQUEST_URI} !^/(karbantartas\.html|robots\.txt)$RewriteCond %{REMOTE_ADDR} !^11\.22\.33\.44$RewriteRule ^ /karbantartas.html [R=503,L]ErrorDocument 503 /karbantartas.htmlHeader always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 503"
Nginx alatt a logika hasonló: egy jelzőfájl megléte esetén return 503;, mellé add_header Retry-After 3600 always;, és a robots.txt kiszolgálása kivételként a feltétel elé kerül. A saját IP-d kizárása azért kell, hogy te közben lásd az oldalt.
WordPress szintjén
A WordPress beépített frissítési karbantartási módja (a gyökérben létrejövő .maintenance fájl) magától 503-at és rövid Retry-After értéket küld, tehát az önmagában rendben van. A gond a bővítményekkel van: sok "coming soon" és karbantartás-bővítmény 200-assal szolgál ki. Mielőtt élesben bekapcsolod, ellenőrizd egy paranccsal: curl -I https://pelda.hu/, és nézd meg a válasz első sorát és a fejléceket.
Ha saját megoldást raksz össze, egy mu-plugin elég: a send_headers horgon nézd meg, létezik-e a jelzőfájl, a bejelentkezett adminokat engedd át, a többieknek pedig küldj status_header(503) hívást, header('Retry-After: 3600') fejlécet és nocache_headers() hívást. Ez utóbbi azért fontos, hogy egy CDN vagy proxy ne cache-elje be a hibaállapotot arra az időre, amikor már rég visszaállt a site. A cache-réteg beragadt 503-a jóval gyakoribb hiba, mint hinnéd.
A Retry-After értékét reálisan add meg. Ha kétórás migrációt tervezel, a 3600 másodperc kevés, a 86400 pedig fölöslegesen sok. Inkább mondj kicsit többet a becsültnél, és ha korábban végzel, egyszerűen kapcsold ki a módot.
Mit tegyél váratlan leállás közben?
Váratlan hibánál az első cél nem a hibajavítás, hanem az, hogy a szerver határozott, értelmezhető választ adjon a látogatóknak és a robotoknak is.
- Nézd meg, milyen kódot ad most a site:
curl -Ia főoldalra és két-három fontos aloldalra. Külön ellenőrizd arobots.txtés asitemap.xmlválaszát. - Ha időtúllépés vagy 500 van, és a hiba nem oldódik meg perceken belül, tereld át az egészet szándékos 503-ra a fenti módszerrel. Egy statikus HTML-oldal a webszerverről akkor is kiszolgálható, ha a PHP feküdt.
- A robots.txt maradjon elérhető és változatlan. Ne írd át "Disallow: /" tartalomra, mert azt a Google gyorsítótárazza, és a visszakapcsolás után is hatni fog egy ideig.
- Ha van CDN-ed, kapcsold be az általa kínált statikus mentést, de ellenőrizd, hogy a hibaállapotot nem cache-eli hosszú TTL-lel.
- Jegyezd fel az időpontot percre pontosan, mielőtt belekezdesz a javításba. Utólag ezt már senki nem tudja rekonstruálni.
Mit nézz meg a Search Consoleban a visszatérés után?
A visszatérés utáni ellenőrzés nem a pozíciók nézegetéséről szól, hanem arról, hogy a Google technikailag újra rendben látja-e a site-ot.
- Beállítások, Feltérképezési statisztikák: itt látod a gazdagép állapotát, a válaszok kódonkénti megoszlását és az átlagos válaszidőt. Az 5xx arány csúcsa mutatja a kiesés valódi hatását a bejárásra. Ha a visszaállás után is magas a válaszidő, a szerver még nem heverte ki a dolgot.
- Oldalak (indexelés) jelentés: keresd a "Szerverhiba (5xx)" és a "Feltérképezés közben történt hiba" kategóriákat. Ha nőtt a bennük lévő URL-ek száma, a listát exportáld, és a javítás után használd az "Ellenőrzés" gombot.
- URL-ellenőrző eszköz: néhány kulcsoldalra (főoldal, fő szolgáltatásoldalak, legfontosabb kategóriák, a leglátogatottabb cikkek) futtass élő tesztet, és ha rendben van, kérj indexelést. Ne tömegesen: napi néhány URL az értelmes nagyságrend, a többit a Google magától bejárja.
- Sitemap: nézd meg, mikor olvasta be utoljára, és hogy hibamentes-e. Ha a sitemap is 5xx-et adott, küldd be újra.
- Teljesítmény jelentés: a kiesés napját hasonlítsd össze az előző hét azonos napjával, hogy legyen számod a megjelenések és kattintások eséséről.
Ha 200-as státuszú karbantartási oldal ment ki, egy plusz lépés jön: az URL-ellenőrzővel nézd meg a Google által tárolt változatot néhány fontos oldalon. Ha ott a karbantartási szöveg szerepel, azokra kérj célzottan újraindexelést, mert ezek maguktól lassabban cserélődnek.
Hogyan dokumentáld a kiesést?
Egy egyszerű incidensnapló hónapokkal később többet ér, mint bármilyen utólagos nyomozás. Vezess külön táblázatot, és minden kiesésnél töltsd ki ugyanazt a néhány mezőt.
- Kezdet és vég, percre pontosan, magyar idő szerint (és jelöld, ha nyári időszámítás van, mert a szervernaplók gyakran UTC-ben írnak).
- Milyen státuszkódot kaptak a látogatók és a robotok, és mikor váltottál 503-ra.
- Mi volt érintve: az egész site, csak a webshop kosár, csak egy aldomain.
- Az uptime-figyelő riasztásának képernyőképe vagy exportja, mert ez független bizonyíték.
- A Feltérképezési statisztikák exportja a kiesés hetéről.
- Egy mondat arról, mi okozta, és mi lett a javítás.
Ha van analitikád, tedd oda az annotációt vagy a jegyzetet ugyanarra a napra. Amikor negyedév végén valaki megkérdezi, miért esett a szeptemberi forgalom, nem kell találgatni. Ez a fajta dokumentáció azért is hasznos, mert mintázatot mutat: ha három hónap alatt négy kiesés volt, az már nem véletlen, hanem tárhely- vagy architektúra-kérdés.
Miért nem a kiesés hossza a fő kockázat?
A saját nézőpontunk ez: az egynapos kiesés ritkán okoz tartós kárt, a rosszul jelzett kiesés viszont igen.
A Google rendszerei fel vannak készülve arra, hogy a szerverek időnként nem működnek. Az újrapróbálkozás, a bejárási sebesség visszafogása és a fokozatos visszaállás mind ezt szolgálja. Amit a rendszer nehezebben kezel, az a félrevezető jelzés: a 200-as hibaoldal, a hetekig kint felejtett karbantartási mód, a CDN-ben beragadt 503, vagy a leállás alatt átírt és aztán visszaállítani elfelejtett robots.txt. Ezekben az a közös, hogy nem a leállás idejére vonatkoznak, hanem utána is hatnak.
Ebből következik a gyakorlati sorrend is. Amikor leáll a szerver, a technikai javítás mellett a második legfontosabb teendő a helyes jelzés beállítása, a harmadik pedig a naplózás. A pozíciók nézegetése ráér: az első két-három napban úgysem mond semmi értelmeset. Ha a jelzés rendben volt, a visszaállás jó eséllyel magától megtörténik, és a te dolgod csak annyi, hogy ne akadályozd. Ha nem volt rendben, akkor viszont a takarítás az igazi munka, és minél előbb kezded, annál rövidebb.
Források és további olvasnivalók
- Google Search Central dokumentáció: HTTP-státuszkódok, hálózati és DNS-hibák a Google Kereső szemszögéből
- Google Search Central Blog: tervezett karbantartás és átmeneti leállás kezelése
- Google Search Central: a robots.txt értelmezése és a robots.txt hibakezelése
- Google Search Console Súgó: Feltérképezési statisztikák, Oldalak (indexelés) jelentés, URL-ellenőrző eszköz
- RFC 9110 (HTTP Semantics): 503 Service Unavailable és a Retry-After fejléc
- RFC 9309 (Robots Exclusion Protocol)
- WordPress Developer Resources: karbantartási mód, maintenance drop-in, nocache_headers
- MDN Web Docs: 503 Service Unavailable, Retry-After
- Az 500-as és 503-as válasz átmeneti hibát jelez, ezért a Google újrapróbálkozik ahelyett, hogy azonnal törölné az oldalt.
- A legrosszabb megoldás a 200-as státusszal kiszolgált karbantartási oldal, mert a Google ezt valódi, indexelhető tartalomnak veszi.
- Tervezett karbantartásnál 503-as státusz + reális Retry-After fejléc kell, és a robots.txt se adjon vissza 5xx-et.
- Visszatérés után a Feltérképezési statisztikák, az Oldalak jelentés és néhány kulcs-URL célzott újraindexelése a teendő.
- A kiesést naplózd időbélyeggel és státuszkóddal, különben hónapokkal később nem tudod megmagyarázni a forgalmi esést.
Gyakori kérdések
Hány óra kiesés után esik ki az oldalam a Google indexéből?
A Google nem közöl konkrét küszöböt. A dokumentáció annyit mond, hogy az 5xx hibát átmenetinek tekinti, újrapróbálkozik, és csak tartósan fennálló hiba esetén ejtheti ki az URL-t. A néhány órás kiesés a gyakorlatban általában nyom nélkül elmúlik, a több napos már látszik a bejárási statisztikákban.
Mi a különbség az 500-as és az 503-as válasz között SEO szempontból?
Mindkettőt átmeneti hibaként kezeli a Google, de az 503 szándékos, kezelt állapotot jelez, és mellé tehető a Retry-After fejléc, amely megmondja, mikor érdemes visszatérni. Tervezett karbantartásra a Google kifejezetten az 503-at javasolja.
Miért baj, ha a karbantartási oldal 200-as státusszal jön vissza?
Mert akkor a Google azt hiszi, hogy ez az oldal valódi tartalma. A karbantartási szöveg bekerülhet az indexbe a valódi tartalom helyére, és sok azonos szövegű aloldal gyenge vagy duplikált tartalomnak minősülhet. A visszaállás után ezeket az oldalakat külön újra kell indexeltetni.
Milyen értéket adjak meg a Retry-After fejlécben?
Reális becslést, másodpercben vagy HTTP-dátumként. Kétórás migrációra a 7200 körüli érték jó, egy egész napos munkára a 86400. Ha korábban végzel, egyszerűen kapcsold ki a karbantartási módot, a fejléc nem kötelezettség.
Át kell írnom a robots.txt fájlt leállás idejére?
Nem, sőt kifejezetten kerüld. A Disallow: / bejegyzést a Google gyorsítótárazza, és a visszakapcsolás után is hatni fog egy ideig. A robots.txt maradjon változatlan és elérhető, akkor is, ha minden más oldal 503-at ad.
Kérjek újraindexelést minden oldalra a visszatérés után?
Nem érdemes. Néhány kulcsoldalra (főoldal, fő szolgáltatásoldalak, legfontosabb tartalmak) futtass URL-ellenőrzést és kérj indexelést, a többit a Google magától bejárja. A sitemap újraküldése és az Oldalak jelentésben az Ellenőrzés gomb használata hatékonyabb tömeges eszköz.
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.