Mapa witryny XML to lista adresów, które świadomie oddajecie do indeksowania, a nie inwentarz wszystkiego, co potrafi wygenerować CMS. W 2026 roku Google traktuje ją jako sygnał wspierający wykrywanie adresów, nie jako obietnicę indeksacji, więc cała jej wartość zależy od tego, co do niej wpuścicie i co z niej wyrzucicie.
W skrócie
- Mapa witryny pomaga w wykrywaniu adresów, nie podnosi pozycji ani nie wymusza indeksacji.
- Do mapy trafiają tylko adresy kanoniczne, zwracające kod 200 i bez znacznika
noindex. - Jeden plik mieści maksymalnie 50 000 adresów i 50 MB po rozpakowaniu; powyżej tego progu potrzebny jest indeks map.
- Znacznik
lastmoddziała tylko wtedy, gdy jest prawdziwy: automatyczne odświeżanie daty przy każdym przebudowaniu cache sprawia, że Google go ignoruje. - Raport map w Search Console pokazuje liczbę wykrytych adresów, a nie zaindeksowanych, dlatego skuteczność mierzy się na stałym panelu URL.
Do czego mapa witryny naprawdę służy
Mapa witryny rozwiązuje jeden problem: informuje wyszukiwarkę o istnieniu adresów, do których trudno dojść linkami. To narzędzie wykrywania, a nie rankingu.
Dlatego najbardziej zyskują na niej serwisy z płaską, ale szeroką strukturą (sklepy z tysiącami kart produktów, serwisy ogłoszeniowe, duże archiwa wpisów) oraz nowe domeny, które nie mają jeszcze linków zewnętrznych.
Mapa nie naprawia problemów z selekcją. Jeśli robot pobiera adres, ocenia go i decyduje, że nie warto go indeksować, dopisanie go do mapy niczego nie zmieni. Sposób, w jaki Google waży te decyzje, opisujemy szerzej w tekście o tym, jak rozumieć główne aktualizacje algorytmów.
Warto pamiętać, że mapy czytają dziś także roboty dostawców modeli językowych, które budują własne zbiory adresów. Kompletna i czysta mapa to tańszy sposób na wejście do tych zbiorów niż liczenie na przypadkowe odkrycie, co ma znaczenie przy walce o cytowania marki w odpowiedziach AI.
Adresy, które nie powinny się w niej znaleźć
W mapie siedzą wyłącznie adresy, które chcecie zobaczyć w wynikach. Każdy inny wpis to szum, który obniża zaufanie do całego pliku.
| Typ adresu | Dlaczego pominąć |
|---|---|
Strony z noindex |
Sprzeczny sygnał: mapa prosi o indeksację, nagłówek jej zabrania. |
| Adresy z przekierowaniem 301 lub 302 | Marnują pobranie; do mapy wchodzi wyłącznie cel przekierowania. |
| Adresy niekanoniczne (parametry sortowania, filtry, UTM) | Konkurują z wersją kanoniczną i rozmywają sygnały. |
| Strony 404 i 410 | Typowy efekt nieaktualizowanej mapy statycznej; psują wskaźnik poprawności pliku. |
| Strony logowania, koszyka, podziękowania za zamówienie | Brak wartości w wynikach, często zablokowane w robots.txt. |
| Cienkie archiwa tagów | Jeśli tag ma jeden wpis, archiwum tylko kanibalizuje ten wpis. |
Strony blokowane w robots.txt |
Robot nie pobierze treści, więc wpis jest pusty z definicji. |
Osobno traktujcie paginację: strony /strona/2/ i dalsze zwykle nie powinny trafiać do mapy, choć muszą pozostać dostępne dla robota w nawigacji, bo przez nie prowadzi droga do starszych wpisów.
Data ostatniej modyfikacji: kiedy szkodzi
Znacznik lastmod jest użyteczny tylko wtedy, gdy odzwierciedla rzeczywistą zmianę treści. Google wielokrotnie potwierdzał, że korzysta z niego przy ustalaniu kolejności ponownych pobrań, ale ignoruje go w serwisach, w których data rośnie bez powodu.
Najczęstsze źródła fałszywych dat w WordPressie:
- Wtyczka cache, która przy czyszczeniu pamięci podbija datę modyfikacji wszystkich wpisów.
- Masowe operacje w bazie (zmiana kategorii, podmiana linków), zapisujące
post_modifiedw całym zbiorze. - Generowanie mapy z dynamicznych bloków, w których data bierze się z momentu renderowania, a nie z treści.
Reguła: jeżeli zmiana nie uzasadnia ponownego przeczytania artykułu, nie powinna podbijać lastmod. Poprawka literówki to nie modyfikacja. Dopisany rozdział, zaktualizowana tabela cenowa albo wymieniony zrzut ekranu już tak.
Alternatywa jest zaskakująco bezpieczna: pominięcie znacznika w ogóle. Brak lastmod oznacza po prostu, że wyszukiwarka oprze się na własnej historii pobrań, co i tak robi w większości serwisów.
Podział map w dużych serwisach
Limity formatu są twarde: 50 000 adresów i 50 MB na plik przed kompresją. Powyżej tego progu tworzy się indeks map (sitemap_index.xml), który wskazuje na pliki składowe.
Podział warto zrobić tak, aby każdy plik odpowiadał jednemu typowi treści lub jednej sekcji serwisu: osobno wpisy, osobno strony, osobno karty produktów, osobno archiwa kategorii. Powód jest diagnostyczny, nie techniczny.
Przy jednej mapie z 48 000 adresów raport w Search Console pokaże jedną liczbę i nic więcej. Przy ośmiu mapach po 6 000 adresów od razu widać, że problem z wykrywaniem dotyczy wyłącznie kart produktów z jednej kategorii. To różnica między godziną i trzema dniami diagnozy.
Mapa obrazów i wideo
Rozszerzenia image:image i video:video mają sens tylko wtedy, gdy obraz lub film jest samodzielnym elementem oferty. Sklep z własną fotografią produktową i serwis z materiałami wideo faktycznie zyskują ekspozycję w Grafice Google i w wynikach wideo.
Blog ilustrowany grafikami generowanymi do nagłówków nie ma tu czego szukać: te obrazy nikogo nie interesują jako samodzielny wynik, a dopisanie ich do mapy tylko puchnie plik. Szczegóły dotyczące obsługiwanych znaczników i formatów są opisane w dokumentacji Google Search Central.
Weryfikacja w Search Console
Raport „Mapy witryn” odpowiada na jedno pytanie: czy plik został pobrany i poprawnie sparsowany. Liczba w kolumnie wykrytych adresów to wynik parsowania, a nie liczba zaindeksowanych stron.
Procedura kontrolna po zmianie struktury:
- Pobierzcie mapę narzędziem zewnętrznym i sprawdźcie kody odpowiedzi wszystkich adresów; każdy wynik inny niż 200 wymaga usunięcia wpisu.
- Porównajcie liczbę adresów w mapie z liczbą opublikowanych treści w bazie; rozbieżność powyżej 5% wskazuje błąd generatora.
- Wybierzcie stały panel 15–20 adresów i sprawdzajcie je w narzędziu do sprawdzania adresu URL co dwa tygodnie, zawsze ten sam zestaw adresów.
Najczęstsze błędy
Pierwszy: mapa statyczna wygenerowana raz, podczas migracji, i nigdy nieodświeżona. Po pół roku zawiera adresy, które już nie istnieją, i nie zawiera połowy nowych treści.
Drugi: wrzucanie do mapy wszystkiego w nadziei, że indeksacja przyspieszy. Przy serwisie z cienkimi archiwami efekt jest odwrotny, bo robot zużywa pobrania na strony, których nie zaindeksuje.
Trzeci: brak odwołania do mapy w robots.txt. Dyrektywa Sitemap: z pełnym adresem to jedna linia, a działa dla wszystkich robotów, nie tylko dla tych, w których panelu zgłosiliście plik.
Czwarty: konfigurowanie znaczników priority i changefreq, ignorowanych przez Google od lat.
FAQ
Czy mapa witryny poprawia pozycje w wynikach?
Nie. Mapa wpływa wyłącznie na etap wykrywania adresów, czyli na to, czy wyszukiwarka dowie się, że dana strona istnieje. Pozycja zależy od oceny treści, linków i dopasowania do zapytania. Serwisy, które po zgłoszeniu mapy notują wzrost widoczności, zyskują na tym, że wcześniej część wartościowych podstron po prostu nie była w ogóle pobierana.
Ile adresów powinna zawierać mapa witryny?
Dokładnie tyle, ile macie adresów kanonicznych, zwracających kod 200 i przeznaczonych do indeksowania. Jeden plik mieści maksymalnie 50 000 wpisów i 50 MB po rozpakowaniu. W praktyce przy serwisach powyżej kilku tysięcy adresów lepiej dzielić mapę na pliki po 1 000–2 000 wpisów i spiąć je indeksem map, bo ułatwia to diagnostykę.
Czy usuwać z mapy strony, które Google oznaczył jako „Wykryta, obecnie niezaindeksowana”?
Nie od razu. Ten status oznacza, że adres został wykryty, ale nie został jeszcze pobrany, więc mapa wykonała swoje zadanie. Jeśli stan utrzymuje się dłużej niż kilka tygodni, problem leży w selekcji: strona jest zbyt cienka, duplikuje inną treść albo nie ma żadnych linków wewnętrznych. Wtedy trzeba naprawić stronę, a nie mapę.
Co zrobić, gdy wtyczka cache podbija daty modyfikacji?
Najprostsze rozwiązanie to wyłączenie znacznika lastmod w konfiguracji generatora mapy. Drugie wyjście to wygenerowanie mapy z własnego zapytania do bazy, które bierze datę z pola przechowującego rzeczywistą edycję treści, a nie z czasu ostatniego zapisu rekordu. Fałszywa data jest gorsza niż jej brak, bo zużywa pobrania na strony, w których nic się nie zmieniło.
Czy zgłaszać mapę osobno w Bing Webmaster Tools?
Tak, i warto to zrobić, zwłaszcza jeśli część ruchu pochodzi z wyszukiwarek opartych na indeksie Bing. Dyrektywa Sitemap: w robots.txt jest czytana przez oba systemy, ale zgłoszenie w panelu daje dostęp do raportu błędów parsowania. Przy okazji działa to także na korzyść narzędzi AI korzystających z indeksu Bing.
Co dalej
Zacznijcie od audytu kodów odpowiedzi w obecnej mapie, bo to najszybszy sposób na znalezienie wpisów, które psują cały plik. Gdy mapa jest już czysta, kolejnym ograniczeniem zwykle przestaje być wykrywanie, a staje się ocena jakości, dlatego warto przejść do praktycznych sygnałów autorytetu w modelu EEAT i sprawdzić, czy zgłaszane adresy mają czym zasłużyć na indeksację.
