Városoldalak gyűjtőoldala és belső linkelése

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

Ha több városban dolgozol, előbb-utóbb felmerül, hogy minden településnek legyen saját landing oldala. Ez jó irány, de sok weboldalon a városoldalak végül sehonnan nem kapnak linket. A menüben nincsenek, a blogcikkek nem hivatkoznak rájuk, és csak az XML oldaltérképben léteznek. Az ilyen lapokat a kereső nehezebben találja meg, kevésbé érti, hova tartoznak, és az AI-alapú válaszmotorok is ritkábban jutnak el hozzájuk. Ebben a cikkben végigmegyünk azon, hogyan épül fel egy „Ahol dolgozunk” gyűjtőoldal, hogyan linkeljenek egymásra a szomszédos városok oldalai, mi kerüljön a menübe és mi a láblécbe, a végén pedig kapsz egy ellenőrzőlistát.

A szövegben három jelölést használunk. Hivatalosan igazolt, ha a Google Search Central vagy a Schema.org dokumentációja kimondja. Saját tapasztalat, ha helyi szolgáltatók weboldalain rendszeresen ezt látjuk. Szakmai feltételezés, ha logikus következtetés, de nincs rá hivatalos megerősítés.

Miért kell gyűjtőoldal a városoldalak fölé?

Röviden: a gyűjtőoldal közös szülőt ad a városoldalaknak, ahonnan a látogató és a keresőrobot is eljut minden településhez, és amelyből kiderül, hogy ezek a lapok egy szolgáltatási terület részei.

Gyűjtőoldal nélkül a városoldalak általában két rossz helyzet egyikébe kerülnek. Vagy mind a főmenüben lógnak egy harmincelemes legördülő listában, vagy egyáltalán nem kapnak belső linket. Az első zsúfolt, és mobilon szinte használhatatlan. A második miatt a lapok árvák lesznek, vagyis egyetlen másik oldal sem mutat rájuk.

Hivatalosan igazolt: a Google Search Central leírása szerint a Google az oldalak többségét úgy találja meg, hogy a már ismert oldalakon lévő linkeket követi. Az oldaltérkép segít, de a belső linkeket nem helyettesíti, és a linkek horgonyszövege kontextust ad arról, miről szól a céloldal.

Saját tapasztalat: ahol a városoldalak csak az oldaltérképben szerepelnek, a Search Console-ban gyakran „Felfedezve, jelenleg nincs indexelve” vagy „Feltérképezve, jelenleg nincs indexelve” állapotban ragadnak hetekig. Amikor ugyanezek a lapok belső linkeket kapnak a gyűjtőoldalról és a szomszédos városoktól, az indexelés jellemzően elindul, bár ennek időzítése oldalanként eltér.

Hogyan épüljön fel egy „Ahol dolgozunk” gyűjtőoldal?

Röviden: a jó gyűjtőoldal önálló, hasznos tartalmú lap, amely régiók szerint csoportosítva, szöveges linkekkel mutat minden városoldalra, és elmondja, mit csinálsz, hol, és hogyan dől el, hogy egy településre kimész-e.

Gyakori hiba, hogy a gyűjtőoldal csak egy beágyazott térkép és egy névlista. A térkép a látogatónak hasznos lehet, de ha a városnevek csak a térkép JavaScript-rétegében kattinthatók, a robot jó eséllyel nem lát bennük linket. Hivatalosan igazolt: a Google akkor tudja megbízhatóan követni a linket, ha az <a> elem href attribútummal, valódi URL-lel szerepel a HTML-ben. A csak onclick eseményre épülő „linkeket” nem tekinti követhetőnek.

Mintaszerkezet

1. Bevezető (2-4 mondat): milyen szolgáltatást végzel, melyik térségben, és honnan indulsz (telephely, iroda).
2. Régiók szerinti csoportok: alcím régiónként, például „Fejér megye” vagy „Budapest és agglomeráció”, alatta szöveges linkek a városoldalakra.
3. Egy-két mondat városonként: ami megmutatja a különbséget (kiszállás módja, helyi sajátosság, telephely közelsége), nem csak a nevet ismétli.
4. A kiszolgálás feltételei: hogyan dől el, hogy egy listán nem szereplő településre is mész-e. Elég a folyamatot leírni.
5. Térkép (opcionális): kiegészítésként, a szöveges lista alatt, soha nem helyette.
6. GYIK: három-öt valós kérdés a kiszolgálási területről.
7. Kapcsolat: egyértelmű következő lépés, ugyanazzal az űrlappal vagy telefonszámmal, mint a többi oldalon.

Az URL-eknél két bevált minta van. Az egyik a gyűjtő alá rendezett szerkezet, például /ahol-dolgozunk/szekesfehervar/. A másik a szolgáltatás szerinti szerkezet, például /villanyszereles/szekesfehervar/, ahol a gyűjtőoldal a /villanyszereles/ lap vagy egy külön /ahol-dolgozunk/ lap. Szakmai feltételezés: a hierarchikus URL önmagában jó eséllyel nem rangsorolási tényező, de a morzsamenüt és a belső linkelés logikáját könnyebb vele következetesen tartani. Ha több szolgáltatásod és sok városod van, ne gyárts automatikusan minden párosítást. Csak ott legyen külön lap, ahol a településen tényleg érdemben mást tudsz mondani.

Hogyan linkeljenek egymásra a szomszédos városok oldalai?

Röviden: minden városoldal linkeljen vissza a gyűjtőoldalra, és három-hat közeli városoldalra, leíró horgonyszöveggel, egy „A környéken is dolgozunk” blokkban.

Mi számít szomszédnak?

A szomszédság nem csak légvonalbeli távolság. Számít az útvonal (melyik főúton vagy autópályán vagy kint), az ingázás iránya, és hogy honnan érkeznek valójában az érdeklődők. Egy Székesfehérváron működő villanyszerelő oldalán például a székesfehérvári lap jó eséllyel Mórra, Gárdonyra, Bicskére, Várpalotára és Dunaújvárosra linkel. A gárdonyi lap viszont Székesfehérvárra, Velencére és Martonvásárra, mert a Velencei-tó környékéről így logikus a továbblépés.

Így kölcsönös háló alakul ki. Minden lapra legalább két-három másik városoldal mutat, a gyűjtőoldal pedig mindegyikre. Ha egy település csak egy irányból kap linket (például csak a gyűjtőoldalról), az még nem árva lap, de gyenge pontja a szerkezetnek.

Milyen legyen a horgonyszöveg?

Hivatalosan igazolt: a Google linkekre vonatkozó ajánlása szerint a horgonyszöveg legyen leíró, rövid, és utaljon a céloldal tartalmára. A „kattints ide” vagy a „tovább” semmit nem mond a céloldalról. Jó példa a „villanyszerelés Móron” vagy a „kiszállás Bicskére”. A helyes ragozásra figyelj: Móron, Gárdonyban, Dunaújvárosban, Budapesten. A rosszul ragozott városnév a látogatónak azonnal gépies szöveget jelez.

Szakmai feltételezés: ha mind a negyven városoldalra ugyanazzal a mintájú horgonnyal linkelsz minden lapról, az sablonos jelet ad, és a látogatónak sem segít. Változatos, természetes megfogalmazás mellett a kereső jobban látja, mi a lapok közti valódi kapcsolat.

Egy egyszerű blokk HTML-je így nézhet ki:

<section><h2>A környéken is dolgozunk</h2><ul><li><a href="/villanyszereles/mor/">Villanyszerelés Móron</a></li><li><a href="/villanyszereles/gardony/">Gárdony és a Velencei-tó környéke</a></li></ul><p><a href="/ahol-dolgozunk/">Az összes település, ahol dolgozunk</a></p></section>

Mi kerüljön a menübe, és mi a láblécbe?

Röviden: a főmenübe egyetlen „Ahol dolgozunk” menüpont kerüljön, legfeljebb a három-öt legfontosabb városra mutató almenüvel, a láblécbe pedig a fő régiók vagy a kiemelt városok, és nem a teljes lista.

• Főmenü: a gyűjtőoldal, mert onnan minden város elérhető egy kattintással. Almenübe csak az a néhány település kerüljön, ahonnan a legtöbb megkeresés jön.
• Lábléc: a régiók gyűjtőpontjai vagy a kiemelt városok, plusz a gyűjtőoldal. A harminc-negyven városnevet felsoroló lábléc nehezen olvasható, és minden oldalon ugyanazt ismétli.
• Morzsamenü: minden városoldalon látszódjon a Főoldal, az Ahol dolgozunk, majd a város neve, kattintható szülőkkel.
• Szolgáltatásoldalak: a szövegben, ahol természetes, linkelj a releváns városoldalra („Fejér megyében több településre is kijárunk”).
• Blogcikkek: ha egy cikk helyi témáról szól, linkeljen az érintett városoldalra.

Hivatalosan igazolt: a Google mobilelső indexelést használ, vagyis elsősorban az oldal mobilos változatát nézi. Ha a mobilos hamburgermenüből kimarad az „Ahol dolgozunk” menüpont, vagy a mobil lábléc rövidített, akkor ezek a linkek a Google szemében is hiányozhatnak.

Saját tapasztalat: a tartalmi, szövegközi linkek a látogatók részéről láthatóan több kattintást kapnak, mint a lábléc linkjei. Szakmai feltételezés: a szövegkörnyezet több jelentést ad a linkhez, ezért a városoldalak közti kapcsolatot ne csak a láblécre bízd.

Hogyan kerülhető el, hogy a városoldalak elszigetelt lapok legyenek?

Röviden: minden városoldalnak legyen legalább három belső bejövő linkje különböző helyekről, a főoldaltól legfeljebb három kattintásra legyen, és ezt negyedévente mérd újra.

Lépésről lépésre így ellenőrizheted:

1. Exportáld a városoldalak URL-jeit az XML oldaltérképből.
2. Futtass feltérképezést a főoldalról indulva egy crawler eszközzel, és nézd meg, hogy a robot mely URL-eket ért el linkeken keresztül.
3. Vesd össze a két listát. Ami az oldaltérképben benne van, de a feltérképezés nem érte el, az árva lap.
4. Nézd meg minden városoldal kattintási mélységét. Ha négy-öt kattintásnál mélyebben van, emeld feljebb a gyűjtőoldalon vagy a menüben.
5. A Search Console Linkek jelentésében ellenőrizd a belső linkek számát oldalanként.
6. Nézd meg a renderelt HTML-t is (például az URL-ellenőrzés eszközzel), mert ha a „Több település” gomb JavaScripttel tölti be a listát, a linkek a forráskódból hiányozhatnak.
7. Ellenőrizd, hogy a városoldalon nincs-e noindex, és hogy a canonical címke a saját URL-re mutat. Ha a városoldal canonicalja a gyűjtőoldalra mutat, azzal gyakorlatilag te kéred, hogy ne a városoldal legyen az indexelt változat.

Saját tapasztalat: az árvaság leggyakrabban egy oldal-újratervezés után jön elő, amikor az új menüből kimarad a gyűjtőoldal, vagy amikor a városoldalakat egy oldalépítő sablonnal hozzák létre, de a „Környéken is dolgozunk” blokk nem kerül bele a sablonba.

Milyen strukturált adat segíti a gyűjtőoldalt?

Röviden: a látható morzsamenü mellé tett BreadcrumbList jelölés leírja a hierarchiát, a vállalkozás adatainál pedig az areaServed tulajdonság a kiszolgált területet.

Hivatalosan igazolt: a Google dokumentálja a BreadcrumbList strukturált adatot, és a keresési találatban megjelenítheti a morzsamenüt. A jelölésnek a látható tartalommal kell egyeznie. Egy városoldal morzsamenüje JSON-LD-ben:

{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Főoldal","item":"https://example.hu/"},{"@type":"ListItem","position":2,"name":"Ahol dolgozunk","item":"https://example.hu/ahol-dolgozunk/"},{"@type":"ListItem","position":3,"name":"Székesfehérvár","item":"https://example.hu/ahol-dolgozunk/szekesfehervar/"}]}

Hivatalosan igazolt: az areaServed a Schema.org szótárban létező tulajdonság (például a Service és a LocalBusiness típusnál), értéke lehet település vagy terület. Szakmai feltételezés: a Google erre nem ad külön találati megjelenést, de a gépi feldolgozásnak, így az AI-alapú válaszmotoroknak is egyértelműbbé teheti, hol dolgozol, ha összhangban van a lap szövegével.

Mikor árt több városoldal, mint amennyit használ?

Röviden: amikor a lapok csak a városnévben különböznek, és arra készültek, hogy a keresőből ugyanoda tereljék a látogatót. Ezt a Google spam-irányelvei átjáróoldalként (doorway) kezelik.

Hivatalosan igazolt: a Google spam-irányelveiben példaként szerepel, ha valaki konkrét régiókra vagy városokra célzott oldalakat hoz létre, amelyek a felhasználót egyetlen oldal felé terelik, illetve ha a lapok jellemzően egymás közeli másolatai. A jó belső linkelés ezen nem segít, sőt egy sűrűn összelinkelt, egyforma lapokból álló háló még feltűnőbbé teheti a mintát.

Ami egy városoldalt valódivá tesz:

• a kiszállás tényleges módja és feltételei az adott településre,
• helyi sajátosságok, amelyek a munkát befolyásolják (például régi bérházak, családi házas övezet, ipari park),
• a településre jellemző, valóban beérkező kérdések és rájuk adott válaszok,
• ha van, a helyi telephely vagy átvételi pont adatai,
• valós, ott elvégzett munkák leírása, kitalált részletek nélkül.

Saját tapasztalat: ha egy településről nincs mit érdemben írni, jobb, ha a gyűjtőoldalon egy mondatban felsorolod a többi kiszolgált település között, mint egy üres városoldalt gyártani. Szakmai feltételezés: a válaszmotorok jellemzően olyan forrást idéznek, amelyben konkrét, ellenőrizhető helyi információ van, ezért a sablonlapok AI-válaszokban is kevésbé jó eséllyel jelennek meg.

Mit nézz át az ellenőrzőlistán, mielőtt élesíted?

Röviden: a lista a gyűjtőoldal elérhetőségét, a városoldalak közti kölcsönös linkeket, a mobilos menüt, a technikai jelöléseket és a tartalom egyediségét ellenőrzi.

• A gyűjtőoldal a főmenüből és a láblécből is elérhető, mobilon is.
• A gyűjtőoldalon minden városoldal szöveges, href attribútumos linkként szerepel, nem csak a térképen.
• A városok régiók szerint csoportosítva vannak, mindegyik mellett egy-két egyedi mondat áll.
• Minden városoldal visszalinkel a gyűjtőoldalra.
• Minden városoldalon van „A környéken is dolgozunk” blokk három-hat valóban közeli településsel.
• A horgonyszövegek leírók és helyesen ragozottak (Székesfehérváron, Móron, Budapesten).
• Minden városoldalnak legalább három belső bejövő linkje van, és legfeljebb három kattintásra van a főoldaltól.
• Nincs árva lap az oldaltérkép és a feltérképezés összevetése alapján.
• A városoldalakon nincs noindex, a canonical a saját URL-re mutat.
• A morzsamenü látható, és a BreadcrumbList jelölés egyezik vele.
• Az areaServed és a lap szövege ugyanazt a területet írja le.
• Egyik városoldal sem csak a városnévben tér el a többitől.
• A renderelt HTML-ben is megvannak a linkek, nem csak a böngészőben látszanak.
• Negyedévente újrafuttatod a feltérképezést és a Linkek jelentés átnézését.

Ez a szerkezet nem ad biztos helyezést, de jó eséllyel eléri, hogy a városoldalak feltérképezhetők, érthetők és a látogató számára is használhatók legyenek, ami minden további helyi SEO-munka alapja.

Források és további olvasnivalók

• Google Search Central: Keresőoptimalizálás (SEO) kezdőknek útmutató
• Google Search Central: Linkekkel kapcsolatos ajánlott eljárások (feltérképezhető linkek, horgonyszöveg)
• Google Search Central: A Google Kereső spam-irányelvei (átjáróoldalak)
• Google Search Central: Morzsamenü (BreadcrumbList) strukturált adatok
• Google Search Central: Mobilelső indexelés ajánlott eljárásai
• Google Search Console súgó: Linkek jelentés és URL-ellenőrzés eszköz
• Schema.org: BreadcrumbList, Service, LocalBusiness, areaServed
• W3C / WHATWG: HTML szabvány, az a elem és a href attribútum