Struktury map witryn zmierzone na 24 stronach: indeksy, podział, rozszerzenia i naruszenia

W małym serwisie mapa witryny jest listą. W dużym to budowla z plików: indeks wskazujący pliki podrzędne, podział według rodzaju treści, języka lub kolejnego numeru oraz rozszerzenia dla obrazów, wideo, newsów i wersji językowych. Każda z tych decyzji ma w protokole własny limit i przy każdej zdarzają się błędy, które nie psują widocznie żadnej strony.

Na potrzeby tego artykułu 1 października 2026 odczytano mapy witryn 24 domen i sprawdzono je rdzeniem nowego narzędzia Sitemap Checker & Validator: wyszukiwarki, infrastruktura, wiadomości, administracja, handel i podróże w trzech krajach, a do tego ta strona.

Jak przeprowadzono pomiar

Mapę szukano tak, jak znajduje ją crawler: najpierw pierwszy wiersz Sitemap: w robots.txt, w przeciwnym razie /sitemap.xml i /sitemap_index.xml. Jeśli plik był indeksem, pobierano trzy pliki podrzędne: pierwszy, jeden ze środka i ostatni. Pliki spakowane (.gz) rozpakowywano. Sprawdzał ten sam kod, który działa w narzędziu w przeglądarce, tutaj pod Node na własnym serwerze.

Nie sprawdzano, czy adresy z map są osiągalne. To osobne pytanie z własnymi pułapkami, a do niego służy audytor map witryn XML, który pobiera próbkę adresów. Tu chodzi o same pliki: budowę, format oraz reguły sitemaps.org i Google.

Sześć domen bez czytelnej mapy

Z 24 domen czytelną mapę dostarczyło 18. Cztery nie podają mapy w robots.txt i pod /sitemap.xml odpowiadają 404, jedna z nich dopiero po przekierowaniu. Dwie odprawiły pobierającego klienta kodem 403, jedna z nich przy pliku, który podaje jej własny robots.txt.

Jeden przypadek leży pośrodku. heise.de wymienia w robots.txt siedem map, a pierwsza z nich, /sitemapindex.xml, odpowiada 404. Adres standardowy /sitemap.xml dostarcza natomiast plik z 10 000 wpisów. Crawler, który czyta wszystkie wiersze, nic nie traci; narzędzie, które bierze tylko pierwszy, zgłasza brak mapy.

robots.txt jako spis treści

Protokół dopuszcza dowolną liczbę wierszy Sitemap: i właśnie tak działa kilka dużych serwisów: zamiast indeksu lista plików stoi od razu w robots.txt.

Ma to zaletę, o której nie mówi żadna specyfikacja: każdy wiersz jest zarazem dowodem, że operator hosta chce tego pliku. Według sitemaps.org mapa może zawierać adresy innego hosta tylko wtedy, gdy wskazuje na nią robots.txt tego hosta.

Pięć sposobów budowy

18 map da się przypisać do pięciu form, a niektóre serwisy łączą dwie z nich.

Ostatnia forma zasługuje na drugie spojrzenie. sitemaps.org opisuje indeks jako listę map, a przewodnik Google po dużych mapach nie mówi nic o zagnieżdżaniu. Indeks wskazujący kolejne indeksy polega więc na zachowaniu, którego nikt nie gwarantuje. Indeks główny Apple wymienia przy tym pliki na drugim hoście, co według protokołu pokrywa tylko robots.txt tamtego hosta.

Limit osiągany jako pierwszy

Mapa witryny może zawierać najwyżej 50 000 adresów i mieć najwyżej 50 MB bez kompresji. gov.uk zatrzymuje się na połowie z 25 000 adresów na plik, jeden plik Airbnb stoi z dokładnie 50 000 na samej granicy. U Ikei działa drugi limit.

Plik prod-et-EE_1.xml zawiera tylko 4617 adresów, ale ma 47,6 MB, czyli 95,3 procent dozwolonego rozmiaru. Każdy adres niesie średnio 69 wpisów xhtml:link dla wersji językowych, łącznie 319 635, a do tego 22 797 obrazów i 1585 filmów. Około 10,8 KB na wpis to już nie adres, lecz jego opis.

Taki rachunek przynosi hreflang w mapie witryny: każda wersja strony wymienia wszystkie pozostałe wersje i samą siebie. We wszystkich plikach łącznie liczba odnośników rośnie więc z kwadratem liczby wersji językowych, a nie z liczbą stron. Przy mapach z hreflang lepszą miarą podziału jest limit bajtów niż liczba adresów.

Gdzie tkwią naruszenia

W formacie podstawowym z loc, lastmod, changefreq i priority walidator znalazł niewiele: kilka zdublowanych wpisów, w heise.de trzy adresy z fragmentem (#) i dwa na innym hoście oraz puste pliki podrzędne w Shopify i Ikei. Naruszenia o znaczeniu niemal w całości tkwią w przestrzeniach nazw i rozszerzeniach.

• Indeks główny Google: stoi w starej przestrzeni nazw Google http://www.google.com/schemas/sitemap/0.84 zamiast w http://www.sitemaps.org/schemas/sitemap/0.9. Przestrzenie nazw porównuje się znak po znaku; dla ścisłego czytnika to nie jest indeks map witryny.
• Mapa Gmaila: 166 adresów z 9075 odnośnikami hreflang, z czego 165 z kodem es-419 dla hiszpańskiego z Ameryki Łacińskiej. Strona pomocy Google o wersjach językowych podaje właśnie ten kod jako przykład nieobsługiwanego, bo liczą się tylko regiony według ISO 3166-1. Sama strona pomocy ma w nagłówku HTML wersję z hreflang="es-419".
• Cloudflare: przestrzenie nazw mapy i xhtml zapisano z https://. Przestrzeń nazw jest identyfikatorem, nie adresem; z https to inny identyfikator, a 10 263 odnośników hreflang leży w przestrzeni, której żaden czytnik nie oczekuje.
• wordpress.org: żaden z 62 filmów w mapie wideo nie ma video:description, które Google prowadzi jako pole obowiązkowe. Mapa obrazów tego samego serwisu wymienia strony wielokrotnie, raz na obraz, samą stronę główną 91 razy; 521 z 693 wpisów powtarza już wymieniony adres, choć jeden wpis url może nieść do 1000 obrazów.
• New York Times: 13 z 745 wpisów mapy newsów ma news:language o wartości en-US. Wymagany jest kod ISO 639 z dwóch lub trzech liter, wyjątki dotyczą tylko zh-cn i zh-tw.
• BBC: indeks wymienia trzy mapy dotyczące wyborów z 2014 roku, jedną z nich z 204 adresami, wszystkimi nadal na http://.

Czy Google odrzuca te przypadki pojedynczo, czy czyta je wyrozumiale, z zewnątrz zmierzyć się nie da. Wykazać da się tylko, że przeczą one regułom samych formatów i że ścisły czytnik się na nich zatrzymuje.

lastmod: jedna data dla wszystkiego

Z pól dobrowolnych Google korzysta tylko z lastmod, i to tylko wtedy, gdy da się je zweryfikować. priority i changefreq Google ignoruje; mimo to stoją one na 9 z 18 stron.

Na 7 stronach co najmniej jeden plik ma przy każdym wpisie tę samą datę, w tym Cloudflare (933 wpisy, jedna data), plik Ikei (4617 wpisów, jedna data) i Booking (3032 wpisy na plik językowy, jedna data). Taka wartość opisuje przebieg generatora, nie strony. Na 6 stronach żaden zmierzony plik nie zawiera lastmod. Wiarygodnie wyglądają wartości w heise.de (8913 różnych na 10 000), w New York Timesie (736 na 745) i w wordpress.org (51 na 52).

Przypadek, którego żaden walidator nie widzi w obrębie jednego pliku, znalazł się na tej stronie. W dniu pomiaru indeks Yoast podawał dla post-sitemap.xml 28 września jako ostatnią zmianę, a najnowszy wpis w tym pliku miał datę 1 października. lastmod w indeksie ma opisywać zmianę pliku podrzędnego; sprawdzenie tego wymaga obu plików obok siebie.

Reguła lokalizacji i XSD

Dwie reguły protokołu duże serwisy łamią niemal bez wyjątku. Pierwsza to reguła lokalizacji: według sitemaps.org mapa pod /sitemaps/sitemap.xml może zawierać tylko adresy poniżej /sitemaps/. Na dziesięciu z 18 stron co najmniej jeden zmierzony plik narusza tę regułę, zwykle dlatego, że leży w podfolderze takim jak /sitemaps/ i wymienia adresy powyżej. W gov.uk, Ikei, Otto, MDN i trzech serwisach informacyjnych dotyczy to każdego adresu zmierzonych plików. Google uwzględnia takie pliki mimo to, jeśli zgłoszono je w Search Console. Walidator zgłasza więc regułę lokalizacji jako uwagę i tylko wtedy, gdy podany jest adres pliku.

Druga to schemat. XSD z sitemaps.org dopuszcza elementy z obcych przestrzeni nazw tylko z processContents="strict". Poprawna mapa obrazów z jednym image:image nie przechodzi więc samej walidacji XSD; libxml2 2.9.14 zgłosił „No matching global element declaration available, but demanded by the strict wildcard”. Walidacja względem XSD wymaga więc wczytania także schematów rozszerzeń. Równie ścisłe jest XSD w kwestii czasu: 2026-10-01T14:05 bez sekund jest tam niepoprawne, z sekundami, ale bez strefy czasowej poprawne, choć nie w formacie W3C, do którego odsyła sitemaps.org.

Sprawdzenie mapy przed publikacją

Łańcucha z poprawności składni, protokołu i rozszerzeń nie obejmie jedno polecenie. Sitemap Checker & Validator w zestawie narzędzi przyjmuje wklejony XML albo plik, także spakowany, i sprawdza w przeglądarce:

• poprawność składni z wierszem i kolumną, np. niezamaskowane & albo ucięty koniec pliku,
• przestrzeń nazw, kodowanie oraz limity 50 000 wpisów i 50 MB,
• loc, lastmod, changefreq, priority i ich kolejność według XSD,
• hreflang z poprawnymi kodami, odwołaniem do siebie i odnośnikami zwrotnymi w obrębie pliku,
• pola obowiązkowe i limity rozszerzeń dla obrazów, wideo i newsów wraz z wycofanymi tagami,
• przy podanym adresie pliku regułę lokalizacji.

Plik nie opuszcza przy tym przeglądarki. Co adresy odpowiadają na żywo, czy przekierowują, mają noindex albo canonical wskazujący gdzie indziej, sprawdza audytor map witryn XML na opublikowanej wersji.

Kontekst i ograniczenia

Zmierzono 24 domeny jednego dnia, po trzy pliki podrzędne na indeks. Sama Ikea ma 2166 plików; o reszcie pomiar nic nie mówi. Sześć domen pozostało nieczytelnych, dwie z nich z powodu odmowy, której crawler o znanej nazwie być może nie dostaje. Pomiar opisuje też naruszenia formatów, nie ich skutki w wyszukiwarce: jak wyrozumiale Google traktuje błędną przestrzeń nazw albo en-US, nie jest udokumentowane.