Ellentmondó indexelési jelek: noindex, canonical és sitemap egyszerre

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

Egy URL indexelését nem egyetlen beállítás dönti el. A Google egyszerre veszi figyelembe a robots.txt-t, a meta robots címkét vagy az X-Robots-Tag HTTP-fejlécet, a rel=canonical hivatkozást, az átirányításokat, a sitemapet, a hreflang-jelölést és a belső linkeket. Amíg ezek egy irányba mutatnak, az indexelés jól tervezhető. Ha ellentmondanak egymásnak, a keresőnek kell döntenie helyetted, és ez a döntés idővel változhat is. Ebben a cikkben sorra vesszük a leggyakoribb ütközéseket, adunk hozzájuk egy auditmátrixot, és megmutatjuk, milyen sorrendben érdemes javítani őket.

A szövegben három jelölést használunk. (Hivatalosan igazolt) az, ami a Google Search Central dokumentációjában vagy a Search Console súgójában szerepel. (Saját tapasztalat) az, amit technikai auditok során rendszeresen látunk, de a Google így nem írja le. (Szakmai feltételezés) az, ami a dokumentált működésből logikusan következik, de közvetlenül nem igazolható.

Miért lesz kiszámíthatatlan az indexelés, ha a jelek ütköznek?

Azért, mert a jelek egy része kötelező utasítás, más része csak javaslat, és a javaslatok közti döntést a Google a saját súlyozása alapján hozza meg. A robots.txt a feltérképezést szabályozza, a noindex az indexelést tiltja. A canonical, a sitemap és a belső linkek viszont csak azt jelzik, melyik URL-t tartod elsődlegesnek egy duplikált csoportban.

(Hivatalosan igazolt) A Google kanonikalizálásról szóló dokumentációja szerint az átirányítás és a rel=canonical erős jel, a sitemapben való szereplés gyenge jel. A Google ezeket együtt mérlegeli, és ha ellentmondanak egymásnak, maga választ kanonikus URL-t. Ezt a Search Console URL-ellenőrzője meg is mutatja, külön kiírja a felhasználó által megadott és a Google által kiválasztott kanonikus URL-t.

A feldolgozásnak sorrendje is van. Előbb a robots.txt dönt arról, letöltheti-e a Googlebot az oldalt. Ha igen, akkor olvassa el a noindexet, és csak az indexelhető oldalaknál számít, melyik URL lesz a kanonikus. Ha egy korábbi lépés megakad, a későbbi jelek el sem jutnak a Google-hoz. Az ütközések többsége ebből a sorrendből érthető meg.

Mi történik, ha egy noindex oldal a sitemapben szerepel?

A Google a sitemap alapján feltérképezi az oldalt, látja a noindexet, és nem indexeli, a Search Console pedig hibaként jelzi. A jelentésben ez „Az elküldött URL-en noindex címke van” jellegű állapotként jelenik meg.

(Hivatalosan igazolt) A Google szerint a sitemapbe azokat az URL-eket érdemes felvenni, amelyeket a keresési találatok között szeretnél látni. A noindex oldal ennek ellentmond. Önmagában ez nem katasztrófa, de feltérképezési kapacitást visz el, és zavarossá teszi a Search Console riportjait, mert a valódi hibák elvesznek a zajban.

(Saját tapasztalat) A tipikus ok WordPressen az, hogy a sitemapet az egyik bővítmény generálja, a noindexet pedig egy másik beállítás vagy a téma teszi ki. Például a címke-archívumok noindexesek, de a sitemapben is benne vannak. Van egy szándékos kivétel is. Ha sok oldalt most tettél noindexre, és szeretnéd, hogy a Google hamarabb újra feltérképezze őket, átmenetileg bent hagyhatod őket egy külön sitemapben friss lastmod dátummal, majd a kiesésük után kiveszed őket.

Mi a gond a robots.txt-ben tiltott, de noindex címkés oldallal?

Ha a robots.txt tiltja az oldalt, a Google nem tölti le, így a noindexet sem látja, és az URL tartalom nélkül is bekerülhet az indexbe. Ez a leggyakoribb és legfélreértettebb ütközés.

(Hivatalosan igazolt) A Google dokumentációja kifejezetten leírja, hogy a noindex csak akkor működik, ha az oldalt a robots.txt nem tiltja. Ha más oldalak linkelnek a tiltott URL-re, az leírás nélkül is megjelenhet a találatok között, a Search Console pedig „Indexelve, bár a robots.txt letiltja” állapotot mutat. Ugyanez igaz a canonicalra. A tiltott oldal canonical hivatkozását a Google nem tudja elolvasni, ezért a dokumentáció külön kimondja, hogy a robots.txt nem kanonikalizálásra való.

A javítás iránya egyértelmű. Ha egy oldalt ki akarsz venni az indexből, engedd feltérképezni, tedd rá a noindexet, és várd meg, amíg kiesik. A robots.txt-tiltás ott hasznos, ahol a feltérképezést akarod megfogni (például végtelen szűrőkombinációknál vagy belső keresési oldalaknál), és elfogadod, hogy a már ismert URL-ek egy része csupaszon megmaradhat.

Mit kezd a Google a noindex és a más oldalra mutató canonical kombinációjával?

Ez két ellentétes üzenet egy oldalon. A noindex azt mondja, hogy ne indexeld, a canonical azt, hogy ez egy másik oldal másolata, és a jeleket oda vond össze. A Google ilyenkor maga dönti el, melyiket veszi komolyabban.

(Hivatalosan igazolt) A Google nem javasolja a noindexet arra, hogy egy webhelyen belül a kanonikus oldal kiválasztását befolyásold, mert az az oldalt teljesen kizárja a keresésből. Erre a rel=canonical a javasolt eszköz.

(Szakmai feltételezés) A Google képviselői korábban lehetőségként említették, hogy ha a noindexes oldal és a canonical-cél egy csoportba kerül, a noindex elvben a célra is átterjedhet. Ezt dokumentáció nem rögzíti, de elég ok arra, hogy ne kockáztasd.

A gyakorlati szabály ezért egyszerű, egy URL-en egy szándék legyen. Ha az oldal egy másik oldal változata (paraméteres URL, nyomtatási nézet, rendezett listanézet), akkor csak canonical kell a fő változatra. Ha az oldalnak egyáltalán nem kell a keresőben lennie (vékony tartalom, köszönőoldal, belső keresés), akkor csak noindex kell, canonical pedig önmagára mutasson, vagy hiányozzon.

Mi történik, ha a canonical átirányított, hibás vagy noindex URL-re mutat?

A canonical-cél ilyenkor nem alkalmas kanonikus URL-nek, ezért a Google jó eséllyel figyelmen kívül hagyja a jelet, vagy más URL-t választ. A Search Console-ban ez gyakran „Ismétlődő oldal, a Google a felhasználótól eltérő kanonikust választott” állapotként jelenik meg.

• Átirányított cél (3xx). Ha az A oldal canonicalja B-re mutat, B pedig C-re irányít, a jelek végül jó eséllyel C-nél kötnek ki, de a lánc gyengíti őket. (Saját tapasztalat) Ez szinte mindig migráció után jön elő, amikor a http-ről https-re, www-ről www nélkülire vagy a záró perjel kezelésének változásakor a canonicalokat nem frissítették.
• Hibás cél (4xx, 5xx). A nem létező oldalra mutató canonical érdemi jelet nem ad. (Szakmai feltételezés) A Google ilyenkor a többi jel alapján választ, ami gyakran maga a forrásoldal.
• Noindex cél. A forrás azt mondja, hogy a cél az elsődleges, a cél pedig azt, hogy ne indexeld. Előfordulhat, hogy egyik sem kerül be, vagy a Google a forrást indexeli a canonical ellenére.
• Robots.txt-ben tiltott cél. A Google a célt nem tudja letölteni és értékelni, így a konszolidáció bizonytalanná válik.

A javítás minden esetben ugyanaz. A canonical végleges, 200-as státuszú, indexelhető és önmagára kanonikus URL-re mutasson, láncolás nélkül.

Milyen kevésbé feltűnő ütközéseket érdemes még keresni?

A leggyakoribb rejtett ütközések a dupla canonical, a HTML és a HTTP-fejléc eltérése, a JavaScripttel módosított jelek és a hreflang hibás céljai.

• Több canonical egy oldalon. (Hivatalosan igazolt) Ha egy oldal több, eltérő canonicalt ad meg, a Google mindegyiket figyelmen kívül hagyhatja. WordPressen ez akkor fordul elő, amikor a téma és egy SEO-bővítmény is kiírja.
• HTML és HTTP-fejléc eltérése. Az X-Robots-Tag: noindex fejléc a forráskódban nem látszik, ezért gyakran senki sem tud róla. Ugyanez érvényes a fejlécben megadott Link: rel=canonical értékre.
• JavaScripttel módosított jelek. (Hivatalosan igazolt) Ha a Google az eredeti HTML-ben noindexet talál, előfordulhat, hogy nem rendereli az oldalt, így a noindexet JavaScripttel eltávolítani nem működik. A canonicalt sem javasolt JavaScripttel átírni.
• Lapozás. (Hivatalosan igazolt) A Google szerint a lapozott sorozat oldalai ne az első oldalra kanonikalizáljanak, hanem mindegyik önmagára.
• Hreflang. (Szakmai feltételezés) A nem kanonikus vagy noindexes URL-re mutató hreflang-párok jó eséllyel nem érvényesülnek, mert a Google a nyelvi változatokat a kanonikus URL-ekhez köti.
• Belső linkek. Ha a webhely menüje és belső linkjei tömegesen a nem kanonikus változatra mutatnak, ez erősebb lehet, mint egyetlen canonical címke.

Hogyan néz ki a jel × jel auditmátrix?

Az auditmátrix minden URL-hez egy sorban rögzíti az összes indexelési jelet, majd jelpáronként szűri ki az ütközéseket. A forrásadat egy teljes feltérképezés (például Screaming Frog vagy Sitebulb), amelybe a sitemapet is betöltöd, és bekapcsolod a robots.txt-tiltott URL-ek jelentését.

Exportáld URL-enként a következő oszlopokat:

• státuszkód és végső URL átirányítás után,
• robots.txt-tiltás (igen vagy nem),
• meta robots és X-Robots-Tag érték,
• canonical (HTML-ből és fejlécből külön), és hogy önmagára mutat-e,
• a canonical-cél státuszkódja és indexelhetősége,
• szerepel-e a sitemapben,
• hreflang-célok és belső bejövő linkek száma.

Ezután az alábbi párokra szűrj. Mindegyiknél megadjuk, mit lát ilyenkor a Google, mi a javítás, és milyen prioritású (P1 a legsürgősebb).

1. Robots.txt-tiltás × noindex (P1). A noindex nem olvasható. Engedd a feltérképezést, amíg az oldal ki nem esik.
2. Robots.txt-tiltás × canonical (P1). A tiltott oldal canonicalja nem olvasható, vagy a canonical-cél tiltott. Oldd fel a tiltást, vagy cseréld a célt.
3. Noindex × más oldalra mutató canonical (P1). Ellentétes szándék. Válassz egyet a fenti szabály szerint.
4. Canonical × 4xx/5xx cél (P1). Nincs érvényes cél. Mutass létező, 200-as URL-re.
5. Canonical × noindex cél (P1). Lehet, hogy egyik oldal sem kerül be. Vagy a noindexet vedd le a célról, vagy a canonicalt cseréld.
6. Canonical × 3xx cél (P2). Gyengített jel. Írd át a végső URL-re.
7. Dupla canonical vagy HTML × fejléc eltérés (P2). A Google mindkettőt figyelmen kívül hagyhatja. Hagyj meg egyetlen forrást.
8. Robots.txt-tiltás × sitemap (P2). Elküldött, de nem letölthető URL. Vedd ki a sitemapből, vagy oldd fel a tiltást.
9. Noindex × sitemap (P2). Elküldött, de kizárt URL. Vedd ki a sitemapből.
10. Canonical × hreflang (P2). A hreflang csak kanonikus, indexelhető URL-ekre mutasson.
11. Más oldalra kanonikalizált URL × sitemap (P3). Gyenge, ellentétes jel. A sitemapben csak a kanonikus URL maradjon.
12. Canonical × belső linkek (P3). A belső linkek a nem kanonikus változatra mutatnak. Frissítsd a menüt, a sablonokat és a tartalmi linkeket.

Táblázatkezelőben egy-egy szűrő a fentiekből néhány perc alatt elkészül. A noindex × sitemap párhoz például a sitemapben = igen ÉS meta robots tartalmazza: noindex feltétel kell, a canonical × 3xx párhoz a canonical-cél státusz 300 és 399 között feltétel.

Milyen sorrendben javítsd az ütközéseket?

A jelek feldolgozási sorrendjében, a robots.txt-től a sitemapig, mert amíg egy korábbi jel blokkol, a későbbiek javítása el sem jut a Google-hoz.

1. Szándék rögzítése URL-csoportonként. Minden sablonra (termék, kategória, szűrő, címke, keresés, lapozás) döntsd el, hogy indexelni, konszolidálni, kizárni vagy megszüntetni akarod.
2. Robots.txt. Vedd ki a tiltásból azokat az oldalakat, amelyeknek a noindexét vagy canonicalját a Google-nak látnia kell.
3. Státuszkódok és átirányítások. Számold fel a láncokat, és javítsd a hibás oldalakat, mert a canonical-célok erre épülnek.
4. Noindex vagy canonical. Minden URL-en egyetlen szándék maradjon.
5. Canonical-célok. Végleges, 200-as, indexelhető, önmagára kanonikus URL, egy forrásból (HTML vagy fejléc).
6. Sitemap. Csak az 1-5. lépés után takarítsd, és csak indexelhető, kanonikus URL maradjon benne.
7. Hreflang és belső linkek. Igazítsd őket a végleges kanonikus URL-ekhez.
8. Ellenőrzés. Mintavétellel a Search Console URL-ellenőrzőjében, majd az oldalindexelési jelentés „Javítás ellenőrzése” funkciójával.

Hogyan ellenőrizd, hogy a javítás működik?

A Search Console URL-ellenőrzőjében nézd meg, egyezik-e a felhasználó által megadott és a Google által kiválasztott kanonikus URL, és hogy az oldal indexelhetőként jelenik-e meg. Ez URL-szintű visszajelzés, nem a teljes webhelyre érvényes ítélet.

(Saját tapasztalat) A változások az oldalindexelési jelentésben jellemzően hetek alatt rendeződnek, és nem egyenletesen. A ritkán feltérképezett oldalak lassabban mozdulnak. A javítás jó eséllyel stabilabb indexelést hoz, de konkrét helyezést vagy forgalomnövekedést nem garantál, mert a kanonikus URL kiválasztása után a rangsorolás már más tényezőkön múlik.

Egy rövid ellenőrzőlista az átadás előtt:

• Egyetlen URL sem tiltott a robots.txt-ben, amelyen noindex vagy fontos canonical van.
• Egyetlen URL-en sincs egyszerre noindex és más oldalra mutató canonical.
• Minden canonical-cél 200-as, indexelhető és önmagára kanonikus.
• Oldalanként egy canonical van, és a HTML meg a fejléc nem mond mást.
• A sitemapben nincs 3xx, 4xx, noindex vagy más oldalra kanonikalizált URL.
• A hreflang-párok és a belső linkek kanonikus URL-ekre mutatnak.
• A noindex a nyers HTML-ben van (vagy éppen nincs), nem JavaScript dönti el.

Miért számít ez az AI-alapú keresésben is?

Mert a Google AI-funkciói ugyanarra az indexre épülnek, így az ellentmondó jelek miatt kiesett vagy rossz változatban indexelt oldal ott sem jelenik meg jó eséllyel.

(Hivatalosan igazolt) A Google szerint az AI-alapú találati funkciókban való megjelenéshez az oldalnak indexeltnek és kivonatként megjeleníthetőnek kell lennie, külön technikai követelmény nincs. Az OpenAI dokumentációja szerint a keresési botja a robots.txt-t tiszteletben tartja.

(Szakmai feltételezés) A különböző AI-feltérképezők a noindexet és a canonicalt nem feltétlenül a Google-lal azonos módon értelmezik. Ha egy oldal a Google-nél a canonical miatt egy másik URL-be olvad, egy másik rendszer még a nem kanonikus változatot is idézheti. Ezért különösen érdemes, hogy a kanonikus változat a belső linkekben és a sitemapben is egyértelműen az elsődleges legyen.

Források és további olvasnivalók

• Google Search Central, Duplikált URL-ek összevonása (kanonikalizálás)
• Google Search Central, Indexelés letiltása a noindex használatával
• Google Search Central, Bevezetés a robots.txt használatába
• Google Search Central, Sitemapek áttekintése
• Google Search Central, A JavaScript SEO alapjai
• Google Search Central, Lapozás bevált gyakorlatai webáruházaknál
• Google Search Central, AI-funkciók és a webhelyed
• Search Console súgó, Oldalindexelési jelentés és URL-ellenőrző eszköz
• OpenAI dokumentáció, Az OpenAI feltérképezőinek áttekintése
• IETF RFC 9309, Robots Exclusion Protocol
• IETF RFC 6596, The Canonical Link Relation