Sitemap.xml Валидатор – Реална проверка за съответствие с протокола

Един файл sitemap.xml може да бъде перфектно формално валиден XML и въпреки това да е неработещ sitemap: липсващ xmlns namespace, релативен <loc> адрес, <priority> със стойност „1.5“ или <changefreq> зададено като „Daily“ вместо като „daily“ – всички те ще преминат през стандартен XML валидатор, но тихо ще се провалят пред реалния протокол за sitemap, който Google, Bing и всеки друг потребител на файла очаква. Този инструмент обработва въведения или качен от вас sitemap чрез вградения DOMParser на браузъра и го проверява спрямо действителните правила, публикувани на sitemaps.org: кореновият елемент трябва да бъде <urlset> за обикновен файл или <sitemapindex> за индексен файл (автоматично разпознаване), като в идеалния случай е деклариран с точния namespace http://www.sitemaps.org/schemas/sitemap/0.9, а всеки <url> (или <sitemap> в индексен файл) трябва да съдържа <loc>, което да сочи към реален абсолютен http/https адрес.

Освен структурата, протоколът документира и твърди лимити и точни формати за полета, които този инструмент проверява поле по поле. Един отделен sitemap файл не трябва да съдържа повече от 50 000 URL адреса и не трябва да надвишава 50 MB в некомпресиран вид – лимити, които важат и за индексните файлове, като там се броят <sitemap> записи вместо <url> записи – а този инструмент измерва действителното въведено или качено съдържание спрямо двете стойности. Всеки <lastmod>, ако присъства, се проверява спрямо истинските W3C-datetime формати, които спецификацията приема: само дата (ГГГГ-ММ-ДД) или пълен времеви печат с часове, минути, опционални секунди и задължителен указател за часова зона. Всяко <priority>, ако присъства, трябва да бъде десетично число между 0.0 и 1.0, а всяко <changefreq> трябва да бъде точно една от седемте стойности, които спецификацията дефинира – always, hourly, daily, weekly, monthly, yearly, never – а не някой правдоподобен синоним. Всяко нарушение посочва конкретния номер на засегнатия запис и неговата действителна стойност, като се показват максимум 50 проблемни записа за правило с бележка „+N още“, така че докладът да остане четим дори при sitemap, близък до лимита за брой адреси.

Две проверки надхвърлят изискванията на писания протокол, но улавят реални и често срещани проблеми: хистограмата на актуалността на <lastmod> групира всяка валидна дата на последна промяна по месеци, за да видите с един поглед дали съдържанието на сайта наистина се поддържа актуално, или повечето адреси носят стара дата от преди години, а детекторът за дублирани <loc> маркира всеки URL, посочен повече от веднъж в същия файл – чест страничен ефект от генератори на sitemap, които обединяват множество източници без премахване на повторенията. Всичко работи локално: обработката, проверката по правилата и хистограмата се изчисляват изцяло във вашия браузър от текста, който сте поставили, или от файла, който сте качили чрез File API, нищо не се извлича или качва на сървър и никой отделен URL от вашия sitemap не бива заявяван или обхождан – този инструмент проверява самия sitemap документ, а не дали страниците, които той изброява, действително съществуват или връщат код 200 OK.