Sitemap, robots.txt és canonical: mit érdemes tudnia a vállalkozónak?

Három fogalom egy táblázatban: mit csinálnak, és mit nem?

Ha a fejlesztőd a sitemapet, a robots.txt-t vagy a canonical címkét említi, valójában három különböző kérdésről beszél. A sitemap segít a keresőnek a fontos URL-ek felfedezésében; a robots.txt megadott robotok feltérképezését szabályozhatja; a canonical az egymáshoz hasonló URL-ek közül jelzi a preferált verziót. Egyik sem „kerülj az első helyre” kapcsoló.

A lényeg nem az, hogy mind az öt eszközt „beállítsuk”, hanem hogy a webhely tényleges problémájához a megfelelő megoldást válasszuk. Ha egy konkrét aloldalad nem indexelt, a 12 állapotos indexelési diagnosztika segít elkülöníteni a hibát a szándékos kizárástól.

XML sitemap: mely oldalaidat érdemes megmutatni a Google-nek?

Az XML webhelytérkép egy gépek számára olvasható lista azokról a webcímekről, amelyeket a webhely üzemeltetője fontosnak és preferáltnak tart. Nem helyettesíti a normális belső linkelést: az oldalt attól is könnyebb megismerni és használni, hogy a menüből vagy más releváns cikkből oda lehet jutni. Egy sitemapben szereplő URL-t a Google nem köteles feltérképezni vagy indexbe venni.

Kell sitemap egy kis céges weboldalhoz?

Egy néhány oldalas, jól belinkelt webhely esetén a Google a webhelytérkép nélkül is felfedezheti a lapokat. Az XML ettől még hasznos karbantartási eszköz: a CMS sokszor automatikusan generálja, és a Search Console-ban ellenőrizhető a feldolgozása. Nagyobb, gyakran bővülő vagy nehezen felfedezhető tartalomnál a jelentősége nőhet. Nem az a cél, hogy minden létező technikai variáns szerepeljen benne.

Mi kerüljön bele, és hogyan ellenőrizd?

Általában a végleges, hasznos, elérhető és indexelésre szánt canonical URL-ek szerepeljenek benne. Ne sorolj fel próbaverziókat, paraméteres duplikátumokat vagy régi átirányított címeket pusztán a darabszám növelése érdekében. A <lastmod> elem valódi, lényeges módosítást tükrözzön, ha egyáltalán megadod; nem segít, ha minden nap automatikusan új dátumot kap a változatlan tartalom.

Minimális, fiktív XML-példa — nem telepítendő fájl:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://pelda.test/szolgaltatas/</loc>
    <lastmod>2026-10-20</lastmod>
  </url>
</urlset>

A pelda.test dokumentációs példa, a dátum kitalált. A Google figyelmen kívül hagyja a sitemap <priority> és <changefreq> elemeit.

A Google Search Console Webhelytérképek jelentésében ellenőrizhető, hogy a Google feldolgozta-e a beküldött fájlt és jelzett-e hibát. Feldolgozva nem azt jelenti, hogy a benne lévő összes URL biztosan indexelt. A Google sitemapkészítési útmutatója további technikai részleteket ad.

Robots.txt: engedélyezett-e a feltérképezés?

A robots.txt általában a webhely gyökerében elérhető, például https://pelda.test/robots.txt címen. A szabályai robotokra és útvonalakra vonatkoznak, ezért egy rosszul felírt Disallow akár fontos szakaszok feltérképezését is akadályozhatja. A fájl lehet egy CMS által előállított virtuális válasz is; nem feltétlenül találsz külön kézzel szerkeszthető fájlt a tárhelyen.

Szemléltető részlet, nem másolandó élő konfiguráció:

User-agent: *
Disallow: /nem-fontos-pelda-utvonal/
Sitemap: https://pelda.test/sitemap.xml

Ez csak a szabályok formáját mutatja. A példabeli útvonal nem a Kaluzsa webhelyének valódi oldala. Egy általános Disallow: / sokkal szélesebb tiltás lehet; ezért soha ne írj felül ismeretlen produkciós robots-beállítást sablon alapján.

Miért nem lehet ezzel bizalmas tartalmat elrejteni?

A robots.txt a feltérképezési kérést korlátozhatja, nem jogosultságellenőrzés. Egy letiltott URL külső hivatkozásokból továbbra is ismertté válhat. Ha szerződés, személyes adat vagy belső fájl nem lehet publikus, valós hozzáférésvédelemre van szükség, nem arra, hogy megkérjük a robotot, ne nézze meg.

Az indexből való kizárásnak külön eszköze lehet a noindex metaadat vagy HTTP-fejléc, de ennek megismeréséhez a Googlebotnak el is kell tudnia érni az oldalt. A robots.txt-tiltás és a benne elrejtett noindex együtt ezért félrevezető, hibás kombináció lehet. Részletek a Google robots.txt ismertetőjében.

Fiktív noindex-példa, nem éles Tudástár-beállítás:

<meta name="robots" content="noindex">

Ez csak a jelzés alakját mutatja. A most készülő, később publikálandó Tudástár-cikkekbe nem kerül ilyen tiltás; a staging hozzáférésének védelme külön üzemeltetési feladat.

Canonical: ha ugyanaz a tartalom több címen érhető el

Egy webáruház szűrőparaméterei, egy cikk több technikai URL-je vagy a www/nem-www változatok is létrehozhatnak nagyon hasonló címeket. A rel="canonical" jelzés azt mondja a keresőnek: ha ezek közül választasz, ezt a verziót tekintsd előnyben részesítettnek. A Google azonban más URL-t is választhat, ha a jelzések vagy a tartalom szerinte mást indokolnak.

Fiktív HTML-minta, amelyet a preferált oldal <head> részében lehetne alkalmazni:

<link rel="canonical" href="https://pelda.test/szolgaltatas/">

Ez nem küldi tovább a látogatót. Ha egy régi webcímet valóban végleg újra cserélsz, és a látogatót is az új helyre kell irányítani, inkább megfelelő 301 vagy 308 állandó átirányítás jöhet szóba. A két módszert nem szabad összekeverni.

Miért nem elég egyszerűen beírni a címkét?

Vizsgáld meg, hogy a canonical célja működik-e, illik-e a tartalomhoz, szerepel-e a preferált változat a sitemapben és arra mutatnak-e a belső hivatkozások. A redirect, a kanonikus jelzés és a belső linkek lehetőleg ugyanarra a logikára épüljenek. Azt sem helyes beállítani, hogy minden független szolgáltatásoldal canonicalja a főoldal legyen: így éppen az önálló fontos tartalmakra küldesz ellentmondásos jelzést.

Mit tegyek, ha a Google más canonicalt választott?

Nyisd meg a Search Console URL-ellenőrzését, és hasonlítsd össze a saját jelzésedet a Google által kijelölt URL-lel. Nézd meg a két oldal tartalmát, a belső linkeket, az átirányításokat és a sitemapet. Nem feltétlenül hiba, ha a rendszer egy valódi duplikátumnak másik főváltozatot választott. A Google canonical dokumentációja szerint ez preferenciát jelző megoldás, nem kényszer.

Canonical, noindex, robots vagy 301: melyiket mikor kérd?

Az alábbi kérdéseket használd a fejlesztővel folytatott egyeztetéshez. Egy problémának nem feltétlenül egyetlen technikai gomb a megoldása; a választott eszköz mellett a tényleges tartalom, a felhasználói út és az üzleti cél is számít.

1. Új, fontos oldal alig felfedezhető? Ellenőrizd a belső linkeket és a sitemapet, valamint hogy az URL valóban publikus, preferált és indexelésre szánt-e.
2. A robot számára nem elérhető? Nézd meg a robots- és HTTP-szabályokat. Egy sitemap nem old fel feltérképezési tiltást.
3. Nyilvános oldal, de nem akarod Google-indexben? Megfelelő helyzetben a noindex lehet indokolt. Ha érzékeny az információ, előbb valódi hozzáférésvédelmet alkalmazz.
4. Több szinte azonos URL van? Vizsgáld a canonicalt, a tartalmi különbségeket, a belső linkeket és szükség esetén az átirányítást.
5. A régi URL végleg megszűnt, és új, releváns helye van? A 301/308 állandó redirect alkalmas lehet a tényleges költöztetésre.
6. Feldolgozott a sitemap, de egy URL hiányzik? Egyenként vizsgáld az URL állapotát; nem a sitemap újraküldése az automatikus javítás.

Öt üzleti helyzet, öt eltérő jó kérdés

Az alábbi helyzetek ugyanannak a fiktív, helyi szolgáltató vállalkozásnak a webhelyén játszódnak. Nem valós Kaluzsa-projektek. A cél a fejlesztőnek feltehető kérdés pontosítása, nem valamely kódrészlet vak alkalmazása.

Három gyors ellenőrzés és a legveszélyesebb ellentmondások

1. Ugyanarról az oldalról beszél-e minden technikai jelzés?

Egy fontos szolgáltatásoldalt ne úgy hirdess a sitemapben, hogy közben a robots-szabály blokkolja és az oldal noindex-et kapott. Nem minden eltérés feltétlenül hiba, de a szándék és a tényleges konfiguráció közötti ellentmondást tisztázni kell.

2. Valódi végleges cím szerepel a belső linkekben?

Ha a menü következetesen a régi címre mutat, miközben az új cím lenne a kanonikus, a látogatónak és a keresőnek fölösleges kerülőutat adsz. Ugyanígy ne szerepeljen a sitemapben régi redirectelt URL, ha már van helyette egy megfelelő preferált változat.

3. Nem próbálod-e a robots.txt-t adatbiztonság helyett használni?

A robots-direktíva nem véd meg attól, hogy valaki közvetlenül megnyisson egy nyilvános URL-t. A valóban privát anyagot beléptetéssel vagy más hozzáférésvédelemmel kell elzárni. A hibás tiltás akár azt is megakadályozhatja, hogy a Google egy noindex jelzést beolvasson.

Mikor elég a felülvizsgálat, és mikor indokolt szakember?

Ha a webhely fontos oldalai működnek, a CMS helyes webhelytérképet állít elő, az oldalak belső linkekkel elérhetők és a Search Console nem jelez lényeges akadályt, nem kell mindenáron újabb technikai szabályokat gyártani. A karbantartás és időnkénti felülvizsgálat hasznosabb lehet, mint egy túltervezett SEO-beavatkozás.

Ha élesítéskor véletlenül tömeges noindex maradt a webhelyen, összetett átirányítások alakultak ki, rossz canonical-halmazt választ a rendszer vagy fontos oldalak feltérképezése akad el, indokolt technikai vizsgálat. A technikai SEO helyét a teljes munkában külön cikkben magyarázzuk el. Szükség esetén konkrét URL-ekkel és hibajelzésekkel érdemes SEO-felmérést kérni; garantált indexelés vagy helyezés itt sem ígérhető.

Gyakori kérdések

Források és szakmai háttér

Kapcsolódó Tudástár-cikkek