Sitemap-index nagy oldalon: bontás típusonként, hogy lásd, mi nincs indexelve

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

Egy pár tucat oldalas bemutatkozó weboldalon az indexelési gondok szemmel is jól követhetők. Egy több ezer URL-es webshopnál vagy egy több száz városoldalt futtató szolgáltatói oldalnál már nem. Ott a Search Console egy összesített számot mutat, és ez a szám könnyen megnyugtat, miközben egy teljes tartalomtípus kimarad a Google indexéből. Ebben a cikkben megmutatom, hogyan lesz a webhelytérképből (sitemap) diagnosztikai eszköz: típusonként bontott sitemapok egy sitemap-index alá fűzve, a Search Console-ban pedig szegmensenként kiolvasott indexelési arány.

Miért rejti el a problémát az egyetlen, közös sitemap?

A monolit sitemap egyetlen átlagot ad, és az átlag elfedi a rosszul teljesítő tartalomtípust. A szegmentált sitemap viszont típusonként kimondja, hol van a baj.

Ha minden URL egy fájlban van, a Search Console azt mutatja, hogy beküldtél 2000 oldalt, és ebből 1430 indexelt. A 72 százalék nem tűnik katasztrófának, sok oldaltulajdonos itt meg is áll. Csakhogy ez a szám úgy is összejöhet, hogy a termékek és a blog rendben vannak, a városoldalak kilenctizede viszont nincs az indexben. Ez a cikk saját nézőpontja: a monolit sitemap nem hazudik, csak hallgat. Nem rossz adatot ad, hanem túl durva felbontásút.

Az Oldalak jelentésben ugyan látod az okokat (például „Crawled - currently not indexed”), de a példalista legfeljebb 1000 sort mutat, és nem csoportosít tartalomtípus szerint. Egy nagy oldalon ebből kézzel kibogozni, melyik sablon a gyenge, órákig tartó exportálás és táblázatozás.

Mi az a sitemap-index, és milyen korlátai vannak?

A sitemap-index egy olyan XML-fájl, amely nem oldalakat, hanem további sitemapokat sorol fel. Így egyetlen címet küldesz be, a Google pedig onnan éri el az összes részfájlt.

Hivatalosan igazolt: a sitemaps.org protokoll és a Google Search Central dokumentációja szerint egy sitemap legfeljebb 50 000 URL-t tartalmazhat, és tömörítetlenül legfeljebb 50 MB lehet. Ha több URL-ed van, több fájlra kell bontanod, ezeket pedig egy index fogja össze, amely legfeljebb 50 000 sitemapra hivatkozhat. A Google azt is közölte, hogy a priority és a changefreq mezőt figyelmen kívül hagyja, a lastmod értéket pedig akkor használja, ha az következetesen pontos.

Egy minimális index így néz ki:

<?xml version="1.0" encoding="UTF-8"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <sitemap><loc>https://example.hu/sitemap-szolgaltatasok.xml</loc><lastmod>2026-09-01</lastmod></sitemap> <sitemap><loc>https://example.hu/sitemap-varosok.xml</loc></sitemap> </sitemapindex>

A protokoll nem ír elő semmilyen logikát a részfájlok tagolására. A legtöbb rendszer méret szerint darabol, pedig ugyanilyen könnyen lehet tartalomtípus szerint is.

Milyen bontást érdemes választani?

Úgy bonts, ahogy a sablonjaid különböznek: egy sitemap jusson minden olyan oldalcsoportra, amelynek ugyanaz a sablonja, ugyanúgy készül a tartalma, és ugyanaz a célja.

• Szolgáltatások: kevés, de üzletileg a legfontosabb oldal. Itt a 100 százalék körüli indexelés a reális elvárás.
• Blog: sok, eltérő minőségű cikk. A régi, elavult bejegyzések gyakran kiesnek.
• Termékek: a legnagyobb tömeg. A változatok, a kifutott termékek és a gyártói leírások miatt itt gyakori a duplikáció.
• Kategóriák: kevés oldal, erős belső linkeléssel. Ha itt esik az arány, az gyakran arra utal, hogy szűrős vagy lapozós URL-ek kerültek be.
• Városoldalak: a legkockázatosabb szegmens, mert gyakran ugyanaz a szöveg fut más településnévvel.

Saját tapasztalat: ha egy típuson belül nagyon eltérő oldalak vannak (például kiemelt és hosszú farkú termékek), azokat is érdemes külön fájlba tenni. Túl finomra viszont ne bonts: ha egy szegmensben tíznél kevesebb URL van, az arány egyetlen oldal miatt is nagyot ugrik, és a jelből zaj lesz.

Hogyan állítsd be a WordPress beépített sitemapjával?

A WordPress az 5.5-ös verzió óta maga készít sitemap-indexet a /wp-sitemap.xml címen, alapból tartalomtípusonként és taxonómiánként külön fájlokkal. A bontás tehát adott, csak a tartalomtípusokat kell jól előkészíteni.

Hivatalosan igazolt: a beépített megoldás a nyilvános bejegyzéstípusokhoz, a nyilvános taxonómiákhoz és a felhasználókhoz készít részfájlokat, például wp-sitemap-posts-post-1.xml, wp-sitemap-posts-page-1.xml vagy wp-sitemap-taxonomies-category-1.xml. Egy fájlba alapból legfeljebb 2000 URL kerül, ezt a wp_sitemaps_max_urls szűrővel módosíthatod. WooCommerce esetén a termékek (product) és a termékkategóriák (product_cat) is külön fájlt kapnak, mert nyilvános típusok.

Városoldalak és szolgáltatások saját tartalomtípusként

A gond ott kezdődik, hogy a szolgáltatás- és városoldalak sok webhelyen sima oldalként (page) vannak felvéve, így egy fájlba kerülnek a Kapcsolat és az Adatvédelem oldallal. A legtisztább megoldás, ha saját bejegyzéstípust kapnak. Egy egyszerű regisztráció egy saját bővítményben vagy a gyermektéma functions.php fájljában:

add_action( 'init', function() { register_post_type( 'varos', array( 'label' => 'Városoldalak', 'public' => true, 'has_archive' => false, 'rewrite' => array( 'slug' => 'varos' ) ) ); } );

Ugyanígy készíthetsz egy szolgaltatas típust is. Ezután a WordPress automatikusan létrehozza a wp-sitemap-posts-varos-1.xml és a wp-sitemap-posts-szolgaltatas-1.xml fájlt.

Figyelem: ha meglévő oldalakat költöztetsz új típusba, megváltozik az URL-jük. Ilyenkor 301-es átirányítás kell a régi címről az újra, és a belső linkeket is frissítsd. Ha az URL-ek megváltoztatását nem vállalhatod, a bővítményes megoldás vagy egy saját sitemap-szolgáltató (wp_register_sitemap_provider()) a járhatóbb út.

Felesleges részfájlok kikapcsolása

A felhasználói (szerzői) sitemap a legtöbb céges oldalon csak zajt ad. A fejlesztői dokumentáció szerint így kapcsolhatod ki:

add_filter( 'wp_sitemaps_add_provider', function( $provider, $name ) { return ( 'users' === $name ) ? false : $provider; }, 10, 2 );

Egyes bejegyzéstípusokat a wp_sitemaps_post_types, taxonómiákat a wp_sitemaps_taxonomies szűrővel vehetsz ki.

Hogyan csináld Yoast SEO vagy Rank Math bővítménnyel?

Mindkét bővítmény kikapcsolja a WordPress saját sitemapját, és a /sitemap_index.xml címen saját indexet ad, benne tartalomtípusonként és taxonómiánként külön fájllal.

Yoast SEO: a részfájlok neve a típus nevét követi, például page-sitemap.xml, product-sitemap.xml, product_cat-sitemap.xml, egy saját varos típusnál pedig varos-sitemap.xml. Hogy egy típus bekerül-e, azt a tartalomtípusok beállításánál az dönti el, megjelenhet-e a keresési találatok között. Ami ott ki van kapcsolva, az noindexet kap, és a sitemapból is kimarad. Egy fájlba alapból 1000 bejegyzés kerül, e fölött számozott folytatás készül (például post-sitemap2.xml).

Rank Math: a Sitemap beállításainál minden bejegyzéstípusnál és taxonómiánál külön kapcsolóval veheted fel a típust a sitemapba, és a fájlonkénti linkszám is állítható. Mentés után nyisd meg az indexet böngészőben, és nézd végig, milyen fájlok szerepelnek benne, mert könnyű felesleges típust is bekapcsolni.

Saját tapasztalat: gyakori hiba, hogy két sitemap fut egyszerre (például egy régi bővítményé és a Yoasté), vagy a Search Console-ban még a korábbi, már nem használt cím van beküldve. Ilyenkor a jelentés régi és új adatot kever. Egy oldalnak egy élő indexe legyen, és csak az legyen beküldve.

Hogyan küldd be a sitemap-indexet a Search Console-ba?

A Search Console Webhelytérképek jelentésében elég egyszer beküldeni az index URL-jét, a Google onnan dolgozza fel a benne felsorolt részfájlokat.

1. Nyisd meg a tulajdont, lehetőleg domain-tulajdonként, hogy minden aldomain és protokollváltozat benne legyen.
2. Az Indexelés csoportban válaszd a Webhelytérképek jelentést.
3. Írd be az index címét (sitemap_index.xml vagy wp-sitemap.xml), és küldd be.
4. Ha az állapot sikeresre vált, kattints az indexre: a részletekben megjelennek a részfájlok, mindegyik a saját felderített URL-számával.
5. A robots.txt fájlba is írd be: Sitemap: https://example.hu/sitemap_index.xml.
6. A Bing Webmaster Toolsban is küldd be ugyanazt az indexet.

Hivatalosan igazolt: a Google 2023-ban megszüntette a sitemapok „ping” végpontját, így a változásokról a Search Console-beküldés, a robots.txt hivatkozás és a pontos lastmod érték alapján értesül.

Saját tapasztalat: a típusonkénti szűrés kényelmesebb, ha a legfontosabb részfájlokat (például a szolgáltatásokét és a városoldalakét) az index mellett külön is beküldöd. Így biztosan önálló szűrőként jelennek meg, és külön látod a feldolgozásuk dátumát is.

Hogyan olvasd ki típusonként az indexelt és beküldött arányt?

Az Oldalak jelentés tetején lévő szűrőben válaszd ki az adott sitemapot: ekkor csak az abban felsorolt URL-ek indexelt és nem indexelt száma látszik. Az indexelt szám osztva a kettő összegével adja a szegmens arányát.

1. Nyisd meg az Indexelés alatt az Oldalak jelentést.
2. A bal felső szűrőt állítsd át a „Minden ismert oldal” értékről a konkrét sitemapra, vagy a Webhelytérképek jelentésben a sitemap részleteinél nyisd meg az oldalindexelést.
3. Írd fel az indexelt és a nem indexelt oldalak számát.
4. Nézd meg, milyen okok között oszlanak meg a nem indexelt oldalak.
5. Ismételd meg minden szegmensre, és vezesd egy dátumozott táblázatban.

Hivatalosan igazolt: a jelentés szűrhető az összes beküldött oldalra, a nem beküldött oldalakra és egy konkrét sitemapra. Az adatok késve frissülnek, és a példalista legfeljebb 1000 URL-t mutat.

Az arány önmagában nem cél, a mintázat számít: melyik szegmens tér el a többitől, és merre mozdul hétről hétre. Szakmai feltételezés: szolgáltatás- és kategóriaoldalaknál 90 százalék fölött, blognál és termékeknél valamivel lejjebb is egészséges lehet a kép, ha a kimaradó URL-ek valóban gyengék vagy elavultak. Ezek nem hivatalos küszöbök, csak kiindulópontok a saját méréseidhez.

Hogyan derül ki így, hogy csak egy tartalomtípus nem indexelődik?

Úgy, hogy a szegmensek arányai szétválnak. Ha négy típus rendben van, egy pedig messze elmarad, akkor nem az egész domainnel van gond, hanem annak az egy típusnak a sablonjával, tartalmával vagy belső linkelésével.

Nézzünk egy szemléltető példát kitalált, kerekített számokkal (nem valós ügyfél adatai). Egy webshop egyetlen sitemapban 1986 URL-t küld be, ebből 1429 indexelt, ez nagyjából 72 százalék. Közepesnek tűnik, a tulajdonos pedig általános technikai hibát keres. Típusonként bontva viszont ez a kép:

• Szolgáltatások: 24 beküldött, 24 indexelt (100%)
• Kategóriák: 42 beküldött, 40 indexelt (95%)
• Blog: 210 beküldött, 180 indexelt (86%)
• Termékek: 1400 beküldött, 1150 indexelt (82%)
• Városoldalak: 310 beküldött, 35 indexelt (11%)

Innentől a kérdés nem az, hogy mi baja van az oldalnak, hanem hogy mi baja van a városoldalaknak. A szűrt jelentésben ilyenkor jellemzően a „Crawled - currently not indexed” vagy a „Duplicate, Google chose different canonical than user” ok van túlsúlyban. Az első azt jelzi, hogy a Google feltérképezte az oldalt, de nem vette fel az indexbe. A második azt, hogy egy másik URL-t tart a tartalom fő változatának. Ha a „Discovered - currently not indexed” a jellemző, az inkább arra utal, hogy a feltérképezés maradt el.

Saját tapasztalat: városoldalaknál ennek leggyakoribb oka, hogy a szöveg csak a településnévben tér el (Budapesten, Győrben, Székesfehérváron ugyanaz a bekezdés), nincs helyi referencia, kiszállási információ vagy saját kép, és az oldalak csak a láblécből vagy egy hosszú listaoldalról kapnak linket. Szakmai feltételezés: a Google jó eséllyel csoportosan is értékeli az egymáshoz nagyon hasonló oldalakat, ezért egy szegmens gyengesége többnyire nem oldalanként, hanem együtt jelentkezik. Ezt a Google így nem erősítette meg, de a szegmentált mérés pont ezt a mintázatot teszi láthatóvá.

Mit csinálj, ha megtaláltad a gyenge szegmenst?

Először vegyél mintát, utána dönts: bővíted a tartalmat, összevonod az oldalakat, vagy tudatosan kiveszed a szegmens egy részét az indexelésből.

1. Válassz ki 10-20 URL-t a szegmensből, és az URL-vizsgálat eszközzel nézd meg a Google által választott kanonikus URL-t és az utolsó feltérképezés dátumát.
2. Hasonlíts össze egy indexelt és egy nem indexelt városoldalt: mennyi rajtuk az egyedi szöveg, és van-e helyi adat.
3. Nézd meg a belső linkelést: hány kattintásra vannak a főoldaltól, és kapnak-e linket a kapcsolódó szolgáltatásoldalról.
4. Döntsd el településenként, van-e valós, egyedi mondanivalód. Ahol nincs, ott egy regionális oldalba való összevonás gyakran tisztább megoldás, mint a vékony oldalak megtartása.
5. A változtatás után ne a teljes oldal, hanem ennek az egy szegmensnek az arányát kövesd hetente.

Ha oldalakat noindexre állítasz, azokat a sitemapból is vedd ki. A sitemapba csak indexelhető, kanonikus, 200-as státuszkódú URL való, különben a szegmens aránya a saját döntésed miatt romlik, és a jel ismét elmosódik.

Milyen hibák rontják el a diagnosztikát?

A szegmentált sitemap csak akkor mond igazat, ha tiszta: minden fájlban csak indexelésre szánt, kanonikus URL-ek vannak, és minden URL pontosan egy szegmensben szerepel.

• Átirányított, 404-es vagy noindex URL a sitemapban.
• Ugyanaz az URL két fájlban is szerepel.
• Szűrős, lapozós vagy paraméteres URL-ek a kategória-sitemapban.
• Gyorsítótárból kiszolgált, elavult sitemap, amely nem követi a törléseket.
• Minden oldalon a mai dátum áll a lastmod mezőben, ami hiteltelenné teszi az értéket.
• Csak az egész oldalas nézetet figyeled, a sitemap-szűrőt nem használod.

Ellenőrzőlista a beállítás után

• Az index böngészőben megnyílik, és minden részfájl 200-as kóddal válaszol.
• Minden üzletileg fontos tartalomtípusnak saját fájlja van.
• A robots.txt a helyes indexre mutat, és csak egy index van beküldve.
• A Webhelytérképek jelentésben minden részfájl sikeres állapotú.
• Van egy táblázatod szegmensenként a beküldött és az indexelt számmal, az aránnyal és a dátummal.
• Havonta legalább egyszer frissíted, változtatás után hetente.

Mi köze ennek az AI-alapú kereséshez?

Az AI-alapú keresők válaszaiban jellemzően olyan oldal jelenik meg forrásként, amelyet valamelyik keresőrendszer már feltérképezett és feldolgozott. Amit egyik rendszer sem ismer, azt nehéz idézni.

Hivatalosan igazolt: az OpenAI dokumentációja szerint a ChatGPT keresési funkciójához az OAI-SearchBot térképezi fel az oldalakat, a Microsoft Copilot pedig a Bing keresési eredményeire támaszkodik. Szakmai feltételezés: ha egy tartalomtípus sem a Google-nél, sem a Bingnél nem indexelődik, az AI-válaszokban is jó eséllyel alulreprezentált lesz. A szegmentált sitemap így a GEO-munkában is az első ellenőrzési pont: mielőtt az idézhetőségen dolgozol, győződj meg róla, hogy az adott típus egyáltalán bekerül az indexbe. Ez nem garantál AI-említést, de kizár egy gyakori, láthatatlan akadályt.

Források és további olvasnivalók

• Google Search Central: Sitemaps overview
• Google Search Central: Build and submit a sitemap
• Google Search Central: Manage your sitemaps with a sitemap index file
• Google Search Console súgó: Sitemaps report, Page indexing report
• Google Search Central Blog: Sitemaps ping endpoint is going away (2023)
• sitemaps.org: Sitemaps XML format
• WordPress Developer Resources: wp_sitemaps_add_provider, wp_sitemaps_post_types, wp_sitemaps_max_urls
• Yoast SEO dokumentáció: XML sitemaps
• Rank Math Knowledge Base: Sitemap settings
• OpenAI dokumentáció: Overview of OpenAI Crawlers
• Bing Webmaster Tools súgó: Sitemaps