0

Sitemap.xml Ellenőrző – Valódi Protokoll Megfelelőség Vizsgáló

Illessze be vagy töltse fel a sitemap.xml (vagy oldaltérkép index) fájlt, és ellenőrizze a valódi sitemaps.org protokoll szerint: gyökér elem és névtér, abszolút <loc> URL-ek, a dokumentált 50 000 URL / 50 MB korlátok, <lastmod>, <priority>, <changefreq> – plusz frissességi hisztogram és duplikált URL-észlelés.

🔒 Teljesen a böngészőjében dolgozzák fel – soha semmi, amit itt beírt, nem kerül feltöltésre.

🗺️

Húzz ide bármilyen fájlt, vagy kattints a kiválasztáshoz

vagy kattintson ide egy .xml fájl tallózásához

Feldolgozás... 0%
XML feldolgozása
Oldaltérkép protokoll szabályok ellenőrzése
URL-ek elemzése
Kész

Eredmény

Egy sitemap.xml fájl lehet tökéletesen jólformált XML, mégis hibás oldaltérkép: a hiányzó xmlns névtér, egy relatív <loc> URL, a „1,5” értékű <priority>, vagy a „Daily” <changefreq> egy általános XML-ellenőrzőn gond nélkül átmegy, miközben halkan elbukik a tényleges oldaltérkép protokollon, amelyet a Google, a Bing és minden más fogyasztó elvár. Ez az eszköz a beillesztett vagy feltöltött oldaltérképet a böngésző natív DOMParser-ével elemzi, és ellenőrzi a sitemaps.org oldalon közzétett valódi szabályok szerint: a gyökér elemnek <urlset>-nek kell lennie normál oldaltérkép esetén, vagy <sitemapindex>-nek oldaltérkép index esetén (automatikusan észlelt), ideális esetben az http://www.sitemaps.org/schemas/sitemap/0.9 pontos névtérrel deklarálva, és minden <url> (vagy <sitemap> egy index fájlban) elemnek tartalmaznia kell egy <loc> elemet, amely valódi abszolút http/https URL-re hivatkozik.

A szerkezeten túl a protokoll dokumentál merev korlátokat és pontos mezőformátumokat is, amelyeket ez az eszköz mezőről mezőre ellenőriz. Egyetlen oldaltérkép fájl nem sorolhat fel 50 000-nél több URL-t, és nem haladhatja meg tömörítetlenül az 50 MB-ot – ezek a korlátok az oldaltérkép index fájlokra is vonatkoznak, ahol <url> bejegyzések helyett a <sitemap> bejegyzéseket kell számolni – és ez az eszköz a tényleges beillesztett/feltöltött tartalmat méri mindkettőhöz képest. Minden <lastmod>, ha van, ellenőrzésre kerül a specifikáció által elfogadott valódi W3C-datetime formátumok szerint: csupasz dátum (ÉÉÉÉ-HH-NN) vagy teljes időbélyeg órával, perccel, opcionális másodperccel és kötelező időzóna-jelöléssel. Minden <priority>, ha van, 0,0 és 1,0 közötti decimális kell legyen, és minden <changefreq> pontosan egy a specifikáció által definiált hét érték közül – always, hourly, daily, weekly, monthly, yearly, never – nem pedig egy hihető szinonima. Minden szabálysértés megnevezi az adott bejegyzés sorszámát és a tényleges értékét, szabályonként legfeljebb 50 megjelenített hibával és egy „+N további” megjegyzéssel, hogy a jelentés olvasható maradjon egy URL-korlát közelében lévő oldaltérkép esetén is.

Két ellenőrzés túlmegy az írott protokoll követelményein, de valós, gyakori problémákat fog meg: egy <lastmod> frissességi hisztogram minden érvényes utolsó módosítási dátumot hónapokra csoportosít, hogy egy pillantással látható legyen, egy webhely tartalma valóban naprakész-e, vagy a legtöbb URL évekkel ezelőtti, elavult időbélyeget hordoz; valamint egy duplikált <loc>-észlelő jelzi, ha ugyanaz az URL többször szerepel ugyanabban a fájlban – ez gyakori mellékhatása azoknak az oldaltérkép-generátoroknak, amelyek több forrást összefésülnek duplikátum-szűrés nélkül. Minden helyben fut: az elemzés, a szabályellenőrzés és a hisztogram mind a böngészőben kerül kiszámításra a beillesztett szövegből vagy a File API-n keresztül feltöltött fájlból, semmi sincs lekérve vagy feltöltve szerverre, és az oldaltérképben lévő egyetlen URL-t sem kérik le vagy indexelik le – ez az eszköz magát az oldaltérkép dokumentumot ellenőrzi, nem azt, hogy a felsorolt oldalak valóban léteznek-e, vagy 200 OK-t adnak-e vissza.