Sitemap-beolvasási hibák a Search Console-ban és a javításuk

Scheo · 2026-10-27 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A Search Console Webhelytérképek jelentése egy sorban jelzi, ha a Google nem tudta feldolgozni a beküldött XML-fájlt, az okot viszont ritkán mondja ki. A hibaüzenetek egy része a fájl tartalmára utal, más része arra, hogy a Googlebot el sem jutott a tartalomig. Ha tudod, melyik üzenet mögött mi szokott állni, a hibakeresés jó eséllyel gyorsan leszűkíthető. Az alábbiakban minden ponton jelölöm, mi hivatalosan igazolt Google-információ, mi saját tapasztalat és mi szakmai feltételezés.

Mit mutat a Webhelytérképek jelentés, és mit nem?

A jelentés azt mutatja meg, hogy a Google mikor olvasta be utoljára a beküldött webhelytérképet, sikerült-e feldolgoznia, és hány URL-t talált benne. Az egyes oldalak indexelési állapotát nem ez mutatja, arra az Oldalak jelentés és az URL-ellenőrzés való.

Hivatalosan igazolt. A Google dokumentációja szerint a webhelytérkép csak jelzés a feltérképezéshez. Egy hibátlanul beolvasott sitemap sem jelenti, hogy minden benne szereplő URL bekerül az indexbe, és a hibás sitemap sem zárja ki az oldalakat a keresőből, ha a Google más úton, belső vagy külső linkekből megtalálja őket. A Google a priority és a changefreq mezőt figyelmen kívül hagyja, a lastmod értéket pedig akkor veszi figyelembe, ha az következetesen pontos.

Saját tapasztalat. Kis webhelyen a sitemap-hiba ritkán okoz látható kárt, mert a belső linkelés elvezeti a robotot a fontos oldalakhoz. Nagy webshopnál, sok új vagy gyakran frissülő oldallal a hibás sitemap már lassíthatja az új tartalom felfedezését, ezért ott érdemes hamar foglalkozni vele.

Mit jelent a „Nem sikerült lekérni” állapot?

Ez az állapot azt jelenti, hogy a Google nem kapott értelmezhető választ a sitemap URL-jére. A leggyakoribb okok a 404-es vagy 5xx-es válasz, a robots.txt általi tiltás, a tűzfal 403-as tiltása, az időtúllépés és a DNS-hiba.

Az angol felületen ez a „Couldn't fetch” állapot, a magyar felületen a változattól függően „Nem sikerült lekérni” vagy hasonló felirattal látod, a köznyelvben sokan „nem sikerült beolvasni” néven emlegetik.

Saját tapasztalat. Frissen beküldött sitemapnél ez az állapot néha akkor is megjelenik, ha a fájl hibátlan, és egy-két nap után magától „Sikeres” lesz. Ezért első lépésként azt nézd meg, hogy a fájl kívülről tényleg elérhető-e. Ha a curl-teszt 200-as választ ad helyes XML-lel, érdemes kivárni egy-két napot, mielőtt mélyebb nyomozásba kezdesz.

Szakmai feltételezés. A tartósan, egy héten túl megmaradó állapot mögött szinte mindig szerveroldali ok van, amely a böngésződből nem látszik. A te IP-címed és a böngésződ ugyanis más elbírálás alá eshet a tűzfalnál, mint a Googlebot kérései.

Miért írja a Search Console, hogy a webhelytérkép HTML?

A HTML formátumra figyelmeztető hiba azt jelzi, hogy a beküldött URL XML helyett weboldalt adott vissza. Ez jellemzően hibaoldal, bejelentkezési képernyő, karbantartási oldal, sütihozzájárulás-oldal vagy egy tűzfal ellenőrző (challenge) oldala.

Hivatalosan igazolt. A Google XML-, RSS-, Atom- és egyszerű szöveges webhelytérképet fogad el. HTML-oldalt nem tud webhelytérképként feldolgozni, akkor sem, ha az linkeket tartalmaz.

Gyakori félreértés, hogy a Yoast vagy a Rank Math sitemapje a böngészőben formázott táblázatként jelenik meg, és ettől HTML-nek tűnik. A táblázatot egy XSL-stíluslap rajzolja ki, a forráskód (Ctrl+U) ilyenkor is <?xml sorral kezdődik, és a szerver XML-típust küld a Content-Type fejlécben. Valódi gond akkor van, ha a forrás <!DOCTYPE html> sorral indul.

Mit kezdj az érvénytelen dátum hibával?

Az érvénytelen dátum hiba azt jelenti, hogy a lastmod mező értéke nem felel meg a W3C dátumformátumnak. A javítás a dátumot előállító bővítmény vagy egyedi kód kimenetének átírása.

Hivatalosan igazolt. A sitemaps.org protokoll és a Google dokumentációja W3C Datetime formátumot vár. Elfogadott például a 2026-10-27 és a 2026-10-27T09:30:00+01:00 alak. Hibás a 27/10/2026, a 2026.10.27. és a T betű nélküli, szóközzel tagolt időpont, például 2026-10-27 09:30:00.

Saját tapasztalat. WordPressben ez a hiba főleg kézzel írt sitemap-generátoroknál és importált tartalomnál fordul elő, ahol a bejegyzés dátummezője üres maradt vagy 0000-00-00 értéket kapott. A bevett bővítmények helyes formátumot írnak, náluk inkább a sérült adatbázis-mező az ok.

Szakmai feltételezés. Ha a generátor minden URL-hez a lekérés pillanatát írja be, a dátum formailag helyes lesz, de tartalmilag semmit nem jelez. Valószínű, hogy a Google ilyenkor idővel a webhely összes lastmod adatát kevésbé veszi figyelembe, ezért a dátum mindig a tartalom érdemi módosítását kövesse.

Mi a teendő, ha túl nagy a sitemap-fájl?

Ha a fájl túllépi a korlátot, oszd több sitemapre, és ezeket egy sitemap-indexfájlban fogd össze. A Search Console-ba elég az indexfájlt beküldeni.

Hivatalosan igazolt. Egy webhelytérkép legfeljebb 50 000 URL-t tartalmazhat, és tömörítetlenül legfeljebb 50 MB lehet. A gzip-tömörítés csökkenti az átvitt adatot, a korlát viszont a kicsomagolt méretre vonatkozik. Egy indexfájl legfeljebb 50 000 webhelytérképre hivatkozhat.

Saját tapasztalat. WordPressben ez a hiba ritka, mert a Yoast, a Rank Math és a WordPress beépített wp-sitemap.xml megoldása is automatikusan lapoz. Inkább webshopnál, termékfeedből vagy egyedi kódból generált fájlnál jön elő. A bővítmények jóval a határ alatti lapméretet használnak, mert egy óriási fájl legenerálása a szervert is terheli, és időtúllépéshez vezethet, ami már a „Nem sikerült lekérni” állapotot okozza.

Miért mutat 0 felfedezett URL-t egy sikeresen beolvasott sitemap?

A 0 felfedezett URL azt jelenti, hogy a Google beolvasta a fájlt, de nem talált benne felhasználható URL-t. Az ok legtöbbször az üres sitemap, a rossz domainre vagy protokollra mutató cím, illetve a hibás XML-névtér.

• Üres a fájl. A bővítményben kikapcsoltál egy tartalomtípust, vagy a noindex beállítás miatt a bővítmény az adott al-sitemap összes URL-jét kihagyja.
• Más gazdagépre mutatnak az URL-ek. A sitemapben http:// vagy www nélküli címek szerepelnek, miközben a Search Console-tulajdon a https://www változat, vagy fordítva. Ez költözés után a WordPress általános beállításaiban bent maradt régi webhelycím miatt szokott előfordulni.
• Rossz a hatókör. A /blog/sitemap.xml helyen álló fájl a protokoll szerint csak a /blog/ alatti URL-eket fedheti le.
• Hibás a névtér. A gyökérelem xmlns attribútuma elírt vagy hiányzik, ezért az <url> elemek nem azonosíthatók.

A hatókör- és a gazdagép-szabály hivatalosan igazolt, a Google dokumentációja és a sitemaps.org is leírja. Saját tapasztalat, hogy indexfájl beküldésekor az indexsor néha kevesebb URL-t mutat, mint az al-sitemapek összege, amíg az összes gyermekfájl beolvasása le nem zajlik. Ilyenkor nyisd meg az indexsort, és nézd meg egyenként az al-sitemapek állapotát.

Melyek a leggyakoribb WordPress-okok?

WordPressben a sitemap-hibák zöme négy forrásra vezethető vissza, a gyorsítótárra, a biztonsági rétegre, a kimenet elejére kerülő PHP-üzenetre és az átirányításokra. Ezek mindegyike előidézheti a fenti hibaüzenetek bármelyikét.

Gyorsítótárazott sitemap

A gyorsítótár-bővítmény vagy a CDN eltárol egy régi, hibás vagy üres választ, és azt adja ki a Googlebotnak akkor is, amikor a sitemap már rendben van. Előfordul, hogy egy karbantartás közben eltárolt HTML-oldal ragad be a sitemap címére, ami a HTML formátumra figyelmeztető hibát okozza. A megoldás a sitemap URL-jeinek kizárása az oldalgyorsítótárból (a WP Rocket, a LiteSpeed Cache és a W3 Total Cache is enged URL-kizárást), majd a bővítmény és a CDN gyorsítótárának ürítése. Saját tapasztalat, hogy a régi válasz gyakran csak a CDN szintjén marad meg, ezért a bővítmény ürítése önmagában kevés.

Biztonsági bővítmény vagy WAF általi tiltás

A Wordfence, a Solid Security, az All In One WP Security, a tárhely saját tűzfala vagy a Cloudflare néha a Googlebot kéréseit is korlátozza. Tipikus ok az országalapú tiltás (a Googlebot zömében amerikai IP-címekről érkezik), a túl szigorú kérésszám-korlátozás és a JavaScript-alapú ellenőrző oldal, amelyet a robot nem tud teljesíteni. A böngésződből ilyenkor minden rendben látszik. Szakmai feltételezés, hogy a Cloudflare ellenőrzött botokra vonatkozó szabálya a valódi Googlebotot többnyire átengedi, egy egyedi tűzfalszabály vagy a hamisított user-agentek elleni szűrés viszont tévesen is fogni tud. A tűzfal naplójában keresd a sitemap címére érkezett, blokkolt kéréseket.

PHP-figyelmeztetés a fájl elején

Ha egy bővítmény vagy a sablon PHP-figyelmeztetést (warning, notice, deprecated) ír a kimenet elejére, az <?xml deklaráció elé szöveg kerül, és az XML érvénytelenné válik. Ugyanezt okozhatja egy üres sor vagy egy BOM-karakter a functions.php vagy egy bővítményfájl záró PHP-tagje után. A böngésző ilyenkor jellemzően azt írja, hogy az XML-deklaráció csak a dokumentum elején állhat. A végleges javítás a hibát okozó kód frissítése. Átmenetileg segíthet, ha a wp-config.php fájlban kikapcsolod a WP_DEBUG_DISPLAY beállítást, így az üzenet a naplóba kerül a kimenet helyett. Saját tapasztalat, hogy ez a hiba PHP-verzióváltás után szokott tömegesen előjönni.

Rossz átirányítás

Egy-egy átirányítást a Googlebot gond nélkül követ, a baj a láncnál, a huroknál és a rossz célpontnál kezdődik. Gyakori eset, hogy a Search Console-ba a régi /sitemap.xml címet küldted be, a bővítményváltás után viszont a /sitemap_index.xml él, és a régi cím a főoldalra irányít, ami HTML-t ad vissza. Hasonló gond, ha a http, https, www és nem-www változatok között többlépcsős átirányítás fut. Hivatalosan igazolt, hogy a Googlebot csak korlátozott számú átirányítási lépést követ. A legtisztább megoldás, ha a végső, 200-as választ adó URL-t küldöd be, és a robots.txt Sitemap sorát is erre frissíted.

Milyen sorrendben érdemes hibát keresni?

Haladj kívülről befelé, előbb a HTTP-választ, utána a tartalmat, végül a szerver naplóit nézd. Saját tapasztalat, hogy az esetek többségében már az első három-négy lépés megmutatja az okot.

1. Státuszkód és fejlécek. Futtasd a curl -sI https://pelda.hu/sitemap_index.xml parancsot. 200-as kódot és XML-típusú Content-Type fejlécet kell látnod (application/xml vagy text/xml).
2. Átirányítások. A curl -sIL https://pelda.hu/sitemap.xml végigköveti a láncot, és minden lépést kiír. Ha egynél több átirányítást látsz, azt érdemes egyetlen lépésre rövidíteni.
3. Robots.txt. A curl -s https://pelda.hu/robots.txt kimenetében nézd meg, nincs-e Disallow szabály a sitemap útvonalára, és hogy a Sitemap sor a ténylegesen élő címre mutat-e.
4. A fájl eleje. A curl -s https://pelda.hu/sitemap_index.xml | head -c 300 kiírja az első karaktereket. Az első sornak <?xml kezdetűnek kell lennie, előtte nem állhat szóköz, figyelmeztetés vagy HTML.
5. Googlebot user-agenttel. A curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://pelda.hu/sitemap_index.xml megmutatja, másképp bánik-e a szerver a Googlebotnak látszó kéréssel. Ha itt 403-at kapsz, simán pedig 200-at, user-agent alapú szűrés fut. Az IP-alapú tiltást ez a teszt nem mutatja ki, mert a kérés a te címedről indul.
6. Böngésző és forráskód. Nyisd meg a sitemapet inkognitóablakban, majd a forrásnézetben (Ctrl+U) ellenőrizd az elejét és a névteret. A böngésző XML-hibaüzenete gyakran a hibás sor számát is megadja.
7. Egy al-sitemap. Indexfájlnál nyiss meg egy gyermekfájlt, és ellenőrizd, hogy a benne lévő URL-ek a helyes protokollal és domainnel szerepelnek-e.
8. URL-ellenőrzés élő teszttel. Másold be a sitemap címét a Search Console URL-ellenőrzőjébe, és indíts élő tesztet. Saját tapasztalat, hogy a lekérési állapot itt a Googlebot szemszögéből mutatja meg, elérhető-e a fájl, és ez az IP-alapú tiltást is leleplezi.
9. Szervernapló és tűzfalnapló. Keresd a sitemap címére érkező Googlebot-kéréseket és a hozzájuk tartozó státuszkódot. Ha a naplóban egyáltalán nincs ilyen kérés, a tiltás valószínűleg a szerver előtt, a CDN vagy a WAF szintjén történik (szakmai feltételezés).

Mikor érdemes újra beküldeni a webhelytérképet?

Akkor küldd be újra, ha javítottál egy hibát, megváltozott a sitemap címe, vagy új indexfájlra tértél át. Változatlan, hibátlan sitemapet nem kell rendszeresen újraküldeni.

Hivatalosan igazolt. A Google a már ismert webhelytérképeket magától is újraolvassa, és a robots.txt Sitemap sorát is figyelembe veszi. A korábbi sitemap-ping végpontot a Google 2023-ban kivezette, ezért a bővítmények automatikus „pingelése” már nem jut el hozzá.

Szakmai feltételezés. Az újrabeküldés valószínűleg előrébb hozza a javított fájl ellenőrzését, az oldalak indexelését viszont önmagában nem gyorsítja.

Saját tapasztalat. Javítás után az újrabeküldés jellemzően néhány órán vagy napon belül frissíti az állapotot. Ha a régi, hibás bejegyzés a listában marad, töröld, és küldd be a helyes címet. Ugyanazt a fájlt naponta többször újraküldeni felesleges, attól nem lesz gyorsabb a feldolgozás.

Mit nézz át, mielőtt beküldöd a sitemapet?

Egy rövid ellenőrzőlista a legtöbb hibát még a beküldés előtt kiszűri.

• A sitemap címe 200-as kódot ad, átirányítás nélkül.
• A Content-Type fejléc XML-típust jelez.
• A fájl első karakterei <?xml, előtte nincs szóköz vagy PHP-üzenet.
• Az URL-ek protokollja és domainje egyezik a Search Console-tulajdonnal.
• A lastmod értékek W3C formátumúak, és a tényleges módosítást tükrözik.
• A fájl 50 000 URL és tömörítetlenül 50 MB alatt van.
• A sitemap címe ki van zárva az oldalgyorsítótárból és a CDN-gyorsítótárból.
• A tűzfal és a biztonsági bővítmény nem korlátozza a Googlebot kéréseit.
• A robots.txt Sitemap sora a beküldött címre mutat.

Források és további olvasnivalók

• Google Search Central, Webhelytérkép létrehozása és beküldése
• Google Search Central, Nagy webhelytérképek kezelése sitemap-indexfájllal
• Search Console súgó, Webhelytérképek jelentés
• Google Search Central Blog, a sitemap-ping végpont kivezetése (2023)
• Sitemaps.org, Sitemap protokoll
• W3C, Date and Time Formats (W3C Datetime)
• WordPress Developer Resources, beépített webhelytérképek (wp-sitemap.xml)