Tartalomleltár készítése: hogyan mérd fel, mi van most az oldaladon

Scheo · 2026-08-24 · Frissítve: 2026-09-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha megkérdezem egy vállalkozótól, hány oldal van a weboldalán, a válasz általában egy tétova szám, plusz-mínusz ötven. Ha azt kérdezem, ezekből melyik hozott az elmúlt fél évben egyetlen érdeklődőt is, akkor jön a csend. Pedig ez a két kérdés minden tartalomstratégia kiindulópontja, és ez a cikk arról szól, hogyan válaszold meg őket egy táblázattal.

A saját álláspontom (saját tapasztalat): leltár nélkül minden tartalomstratégia találgatás. Nem rossz, nem buta, csak megalapozatlan. Aki leltár nélkül tervez tartalomnaptárt, az olyan cikkeket ír meg újra, amik már megvannak, olyan témákat hagy ki, amikre az oldal fele hivatkozna, és olyan aloldalakat tart életben, amik hat éve semmit nem csinálnak, csak eszik a crawl budgetet és hígítják a témabeli tekintélyt.

Mi az a tartalomleltár, és miért nem ugyanaz, mint egy sitemap?

A tartalomleltár egy soronkénti táblázat az oldalad összes nyilvános URL-jéről, amiben minden sorhoz tartozik legalább egy adat a tartalomról (mi ez), egy adat a teljesítményéről (mit csinál) és egy döntés (mi legyen vele). A sitemap ezzel szemben csak egy lista: azt mondja meg, mi létezik, de semmit nem mond arról, hogy éri-e meg léteznie.

Tovább a témában: AI SEO tartalomstratégia 2026 · Tartalmi kannibalizáció felismerése és feloldása Search Console-alapon

A különbség gyakorlati. A sitemapból nem derül ki, hogy két aloldalad ugyanarra a kulcsszóra pályázik (kannibalizáció), hogy egy 2019-es blogbejegyzésed még mindig egy megszűnt szolgáltatásra hivatkozik, vagy hogy a legtöbb belső linket egy olyan cikk kapja, ami senkit nem visz sehova. A leltár pont ezeket teszi láthatóvá.

Miért lett ez fontosabb az AI-válaszok korában (szakmai feltételezés): a válaszmotorok jellemzően nem egész oldalakat, hanem konkrét, jól körülhatárolt szövegrészleteket emelnek ki. Egy vékony, elavult, félig kész aloldal korábban legfeljebb nem hozott forgalmat. Ma ennél többet kockáztatsz vele: ha egy motor pont abból a részletből idéz, egy hibás vagy elavult információt fog rólad terjeszteni. A leltár az egyetlen módszer, amivel egyáltalán tudod, hány ilyen oldalad van.

Honnan szedd össze az összes URL-t, hogy tényleg az összes legyen?

Rövid válasz: legalább három forrásból, mert egyik sem teljes. A sitemap azt mutatja, amit te akarsz mutatni, a crawler azt, ami linkelve van, a Search Console pedig azt, amit a Google talált (beleértve azt is, amiről te nem tudtál).

A gyakorlatban ezt a négy forrást szoktam összefésülni:

1. XML sitemap. A legtöbb oldalon a /sitemap.xml vagy /sitemap_index.xml címen érhető el. WordPressen a Yoast, a Rank Math vagy a beépített WP sitemap generálja. Ez a leggyorsabb induló lista.
2. Crawler. Screaming Frog SEO Spider (500 URL-ig ingyenes), Sitebulb vagy hasonló. Ez végigmegy a belső linkeken, és megtalálja azt is, ami nincs benne a sitemapban. Egyúttal rögtön hozza a címet, a meta leírást, a státuszkódot, a szöveghosszt és a belső link-számokat, tehát több oszlopot is kitölt helyetted.
3. Google Search Console. A Teljesítmény jelentés Oldalak fülén exportáld a megjelenéseket és kattintásokat, az Oldalak (indexelés) részen pedig nézd meg a kizárt URL-eket is. Itt bukkannak fel a paraméteres, duplikált és elfelejtett címek.
4. A CMS saját listája. WordPressen a bejegyzések és oldalak listája exportálható, és ez adja a legpontosabb dátumokat és szerzőket. Adatbázisból egy egyszerű lekérdezéssel is kinyerhető: SELECT ID, post_title, post_type, post_date, post_modified, post_status FROM wp_posts WHERE post_status = 'publish';

A négy listát URL alapján fésüld össze, és normalizáld őket, különben ugyanaz az oldal háromszor fog szerepelni. Egységesítsd a protokollt (https), a www-változatot, a záró perjelet, és vágd le az UTM-paramétereket. Ez az a pont, ahol egy tíz soros szkript órákat spórol.

Hivatalosan igazolt: a Google Search Central dokumentációja külön kiemeli, hogy a Search Console adatai csak arról az ingatlanról (property) érkeznek, amit igazoltál, és hogy a jelentések nem tartalmaznak minden lekérést. Tehát a GSC-export sem tekinthető teljes listának, csak egy erős kiegészítésnek.

Milyen oszlopok kellenek a táblázatba?

Rövid válasz: annyi, amiből döntés születik, és egy sem több. Az alábbi tizenhárom oszloppal az esetek nagy részében el lehet dönteni minden sor sorsát.

Azonosító és tartalmi oszlopok

• URL: normalizált, teljes cím. Ez a táblázat elsődleges kulcsa.
• Cím (title tag): crawlerből. Ha üres vagy duplikált, az már önmagában jelzés.
• Típus: főoldal, szolgáltatásoldal, blogcikk, kategória, termék, referencia, jogi oldal, landing. Ezt kézzel vagy URL-minta alapján töltsd (pl. minden /blog/ kezdetű sor blogcikk).
• Célkulcsszó vagy fő kérdés: mire pályázik ez az oldal. Ha nem tudod egy mondatban leírni, az már a válasz.
• Szószám: crawlerből jön. Nem minőségi mutató, de a 300 szó alatti oldalak érdemesek egy külön ránézésre.

Frissesség és szerkezet

• Publikálás dátuma és utolsó érdemi frissítés. A kettő nem ugyanaz, és a CMS post_modified mezője megtévesztő: egy elütés javítása is frissítésnek számít benne. Érdemi frissítés az, amikor a tartalom állítása változott.
• Belső bejövő linkek száma: hány másik oldalról mutat rá link. Screaming Frogban ez az Inlinks oszlop.
• Belső kimenő linkek száma: mennyire köti be magát a többi tartalomba.
• Státusz és indexelhetőség: 200 / 301 / 404, noindex, canonical célja.

Teljesítmény és üzleti szerep

• Megjelenés és kattintás (12 hónap): GSC-exportból.
• Munkamenetek és bejáratként betöltött szerep: GA4-ből, Oldalak és képernyők jelentés.
• Konverziós szerep: ez a legfontosabb és a leggyakrabban kihagyott oszlop. Négy értékkel dolgozom: közvetlen (itt történik az ajánlatkérés), támogató (a konverziós út egy korábbi lépése), bizalomépítő (rólunk, referencia, jogi), nincs.
• Döntés: megtartás, frissítés, összevonás, törlés. Erről szól a következő szakasz.

Két oszlopot szoktak feleslegesen felvenni: a becsült keresési volument minden sorhoz (elavul, mire végzel, és a döntéshez ritkán kell), és a hangulati minősítést csillagokkal. Utóbbi látszólag hasznos, valójában két hét múlva senki nem tudja, mit jelentett a három csillag.

Hogyan döntsd el soronként, hogy megtartod, frissíted, összevonod vagy törlöd?

Rövid válasz: haladj felülről lefelé, és az első illeszkedő szabálynál állj meg. Így a döntés reprodukálható lesz, nem hangulatfüggő.

1. Jogi vagy működési kényszer? (adatkezelés, ÁSZF, kapcsolat, impresszum) → megtartás, teljesítménytől függetlenül. Ezeket nem forgalom alapján ítéljük meg.
2. Közvetlen konverziós szerep, és ténylegesen hoz érdeklődőt? → megtartás, és tedd fel a prioritási listára karbantartásra. A pénzt hozó oldalakhoz akkor nyúlj, ha tudod, mit csinálsz.
3. Van két vagy több oldalad ugyanarra a szándékra? (ugyanaz a célkulcsszó, a GSC-ben ugyanarra a lekérdezésre váltakozva jelennek meg) → összevonás. A jobbik marad, a másikból átemeled az értékes részeket, a régi URL-t pedig 301-gyel az újra irányítod.
4. Van forgalma vagy releváns témája, de az információ elavult, vékony, vagy megszűnt dolgokra hivatkozik? → frissítés. Ez a leltár leggyakoribb és legjobban megtérülő kimenete.
5. 18 hónapja gyakorlatilag nulla megjelenés, nulla konverzió, nulla belső link, és a téma sem kapcsolódik ahhoz, amivel ma foglalkozol? → törlés, 410-es státusszal vagy 301-gyel a legközelebbi releváns oldalra.
6. Minden más → megtartás változtatás nélkül, és nézd meg a következő leltárnál.

Fontos figyelmeztetés (saját tapasztalat): a tömeges törlés kockázatos, és önmagában nem javítja a láthatóságot. Láttam olyan oldalt, ahol a kigyomlálás után javult a helyzet, és olyat is, ahol nem történt semmi mérhető. Amit biztosan tudok: a rossz irányítás fáj. Ha törölsz, mindig legyen 301-es átirányítás oda, ahol a felhasználó megkapja, amit keresett, és soha ne a főoldalra tereld tömegesen a törölt aloldalakat. A Google Search Central külön jelzi, hogy a tömeges, nem releváns célra mutató átirányítást lágy 404-ként kezelheti.

Az összevonásnál pedig ne feledd: a 301-es átirányítást akkor is meg kell tartani, ha az új oldal remekül teljesít. Az átirányítás nem ideiglenes mankó, hanem a régi cím végleges címváltozása.

Mennyi idő ez reálisan, és mit lehet belőle delegálni?

Rövid válasz (saját tapasztalat, nem hivatalos benchmark): 50 oldalnál 4-6 óra egy ülésben, 500 oldalnál 3-5 munkanap, több részletben. A különbség nem tízszeres, mert az adatgyűjtés fixköltségű, viszont a soronkénti döntés lineárisan nő.

Az 50 oldalas bontás nálam így néz ki: URL-gyűjtés és összefésülés 60-90 perc, adatok betöltése a táblázatba 60 perc, soronkénti döntés 2-3 óra, a következő lépések összeírása 30 perc. Az 500 oldalas verzióban az első két lépés alig hosszabb (2-3 óra összesen), viszont a döntési kör 15-20 óra, mert oldalanként átlagosan másfél-két percet elvisz, plusz a kannibalizáció-vizsgálat.

Mit adj ki a kezedből, és mit ne:

• Jól delegálható: URL-gyűjtés, normalizálás, a crawler futtatása, a GSC- és GA4-adatok bemásolása, a típus-oszlop kitöltése URL-minta alapján, a belső linkek megszámolása. Ez a munka 60-70 százaléka, és nagyrészt gépies.
• Részben delegálható: a célkulcsszó megnevezése és az elavultság jelzése. Egy gyakornok vagy egy nyelvi modell kiszűri, hogy egy cikk 2020-as adatokra hivatkozik, de a súlyát nem tudja megítélni.
• Ne add ki: a konverziós szerep és a végső döntés oszlopát. Ezekhez tudni kell, hogyan vásárolnak nálad, mit ígértél ügyfeleknek, és melyik oldal miért készült. Aki ezt nem tudja, az forgalmi számok alapján fog dönteni, és ki fogja vágni azt a három oldalt, amit a legjobb ügyfeleid olvasnak elalvás előtt.

Nyelvi modellel érdemes kísérletezni a típus-besorolásnál és az elavultság-jelzésnél, de a kimenetet mintavételesen ellenőrizd. A modell magabiztosan sorolja be tévesen azt, amiről nincs elég információja a szövegben, és a leltárban egy rossz besorolás rossz döntéssé válik.

Mit csinálj, amikor kész a táblázat?

Rövid válasz: a leltár nem cél, hanem munkasorrend. Ha a kész táblázatot lemented és nem nyúlsz hozzá, ugyanott vagy, mint előtte, csak fáradtabban.

A gyakorlati sorrend, amit követni szoktam:

1. Szűrd le a frissítés sorokat, és rendezd őket megjelenés szerint csökkenően. A legtöbb megjelenést kapó, de elavult oldal a legjobb első feladat: itt van kész kereslet, csak a tartalom nem tartja már.
2. Utána jöjjön az összevonás. Ez a legkényesebb, mert átirányítással jár, ezért csoportosan, dokumentáltan csináld, és jegyezd fel minden régi URL mellé az új célt.
3. A törlés menjen utoljára, és ne egyszerre. Kisebb adagokban, és a 404-es hibákat figyelve.
4. Végül nézd meg, mi hiányzik. A leltár nemcsak arról szól, mid van: ha a táblázatban nincs egyetlen sor sem egy fontos szolgáltatásodra vagy egy visszatérő ügyfélkérdésre, akkor megvan a következő cikk témája, méghozzá bizonyítottan.

A leltárt érdemes élő dokumentumként kezelni. Nálam évente egy teljes újrafutás és negyedévente egy gyors ránézés vált be: az újonnan megjelent URL-ek felvétele és a döntési oszlop átnézése ilyenkor egy-két óra, nem napok. Egy jól karbantartott leltár nem garantál jobb helyezést vagy több AI-idézést, de azt jó eséllyel megakadályozza, hogy a következő fél évben rossz dolgon dolgozz.

Források és további olvasnivalók

• Google Search Central: Search Console súgó (Teljesítmény jelentés, Oldalak indexelése)
• Google Search Central: Átirányítások és a Google Kereső (Redirects and Google Search)
• Google Search Central: Sitemapok létrehozása és beküldése
• Google Search Central: Hasznos, megbízható, elsősorban embereknek készült tartalom készítése
• Google Analytics 4 súgó: Oldalak és képernyők jelentés
• Schema.org: Article, WebPage és FAQPage típusok dokumentációja
• W3C: URL és HTTP állapotkódok vonatkozó specifikációi (RFC 9110)
• Screaming Frog SEO Spider hivatalos felhasználói útmutató