Mapa witryny XML: co w niej umieścić i jak zgłosić ją do Google

Do czego naprawdę służy mapa witryny XML

Mapa witryny służy do jednego: podpowiada wyszukiwarce, które adresy w serwisie istnieją i które z nich właściciel uważa za ważne. Google opisuje ją w dokumentacji jako plik z informacjami o stronach, filmach i innych plikach w witrynie oraz o relacjach między nimi, odczytywany po to, by skuteczniej poznawać serwis. Wyjaśnienie znajduje się na stronie Informacje o mapach witryn w Centrum wyszukiwarki Google.

Warto od razu oddzielić fakty od oczekiwań. Mapa nie podnosi pozycji, nie zastępuje dobrej treści i nie zmusza Google do zaindeksowania czegokolwiek. Dokumentacja mówi o tym wprost: mapa pomaga rozpoznawać adresy, ale nie daje pewności, że wszystkie pozycje zostaną odwiedzone przez robota i trafią do indeksu. Samo zgłoszenie mapy Google nazywa wskazówką, z której może skorzystać, ale nie musi.

Po co więc ją przygotowywać? Robot Google trafia na nowe podstrony głównie po linkach. Jeżeli do jakiejś podstrony nie prowadzi żaden link albo prowadzi tylko jeden, głęboko ukryty, robot może znaleźć ją późno lub wcale. Mapa skraca tę drogę. Dokumentacja wymienia trzy sytuacje, w których jest szczególnie przydatna: serwis jest duży i trudno dopilnować, by każda podstrona była podlinkowana z innej, serwis jest nowy i prowadzi do niego niewiele linków z zewnątrz, albo serwis zawiera dużo filmów i obrazów bądź jest pokazywany w Wiadomościach Google.

Druga korzyść jest mniej oczywista, a w codziennej pracy równie ważna. Mapa zgłoszona w Search Console staje się punktem odniesienia do kontroli. Raport pokazuje, ile stron Google w niej wykrył, kiedy ostatnio ją odczytał i jakie błędy napotkał, a z tego miejsca można przejść do raportu o stanie indeksowania ograniczonego do adresów z tej jednej mapy. Dla właściciela sklepu z Poznania, który dodał trzysta nowych produktów, to najprostszy sposób, by ustalić, ile z nich Google faktycznie zna.

Trzeci, słabszy efekt dotyczy wyboru adresu kanonicznego, czyli tej wersji strony, którą Google ma pokazywać, gdy ta sama treść jest dostępna pod kilkoma adresami. W dokumentacji o określaniu adresu kanonicznego Google nazywa obecność adresu w mapie słabym sygnałem, wyraźnie słabszym niż przekierowanie czy znacznik rel="canonical". Mapa wspiera więc inne sygnały, ale ich nie zastąpi.

Kiedy mała strona może się obejść bez mapy witryny

Mała, dobrze podlinkowana strona może się obejść bez mapy witryny i nic na tym nie straci. Google podaje konkretne warunki. Serwis uznaje za mały, gdy ma do 500 stron, przy czym liczą się tylko te, które powinny pojawiać się w wynikach wyszukiwania. Drugi warunek to kompletne linkowanie wewnętrzne: robot, zaczynając od strony głównej, ma dojść po linkach do wszystkich ważnych podstron. Trzeci to brak dużej liczby filmów, obrazów lub wiadomości, które mają być widoczne w wyszukiwarce.

Weźmy stronę hydraulika z Łodzi: strona główna, sześć podstron usług, cennik, kontakt i kilka wpisów. Wszystko jest dostępne z menu i ze stopki. Taki serwis spełnia wszystkie trzy warunki i Google pozna go w całości bez żadnego dodatkowego pliku. Podobnie wygląda sytuacja niewielkiej kancelarii z Krakowa z kilkunastoma podstronami specjalizacji.

Mimo to w praktyce rzadko odradzamy przygotowanie mapy. Powody są trzy. Większość systemów do prowadzenia stron tworzy ją samodzielnie, więc nie wymaga to pracy. Mapa daje wspomniany wcześniej punkt kontroli w Search Console. Wreszcie mała strona rzadko pozostaje mała: dochodzi blog, realizacje, strony lokalizacji i po roku nikt już nie pamięta, czy do każdej podstrony prowadzi link. O tym, jak zadbać o same połączenia między podstronami, piszemy we wpisie o linkowaniu wewnętrznym, bo to ono, a nie mapa, pozostaje podstawową drogą robota po serwisie.

Sama dokumentacja Google ujmuje to podobnie: mapa nie jest obowiązkowa, ale w większości przypadków serwis na niej korzysta. Zdecydowanie warto ją mieć przy sklepach internetowych, serwisach z rozbudowanym blogiem, stronach z wieloma lokalizacjami oraz przy każdej nowej domenie, do której nie prowadzą jeszcze linki z innych stron. W takich przypadkach uporządkowana mapa jest stałym elementem prac, które wykonujemy w ramach SEO technicznego.

Mapy nie należy natomiast traktować jako sposobu na ratowanie słabej struktury. Jeżeli ważna podstrona jest dostępna wyłącznie z mapy, a nie prowadzi do niej żaden link w serwisie, Google może ją poznać, ale otrzymuje zarazem sygnał, że właściciel sam nie uważa jej za istotną. Taką podstronę trzeba najpierw podlinkować, a dopiero potem liczyć na jej widoczność.

Które adresy powinny trafić do mapy, a które nie

Do mapy powinny trafić wyłącznie adresy, które mają pojawiać się w wynikach wyszukiwania: kanoniczne, zwracające poprawną odpowiedź serwera i otwarte dla robotów. Google formułuje to w dokumentacji krótko: w mapie umieszcza się adresy, które właściciel chce widzieć w wynikach, a gdy ta sama treść jest dostępna pod kilkoma adresami, wpisuje się tylko wersję preferowaną. Każdy adres w mapie jest więc deklaracją, że to ważna strona. Jeżeli robot znajduje pod nim przekierowanie, zakaz indeksowania albo błąd, deklaracja przeczy rzeczywistości.

Adresy przekierowane

Adres, który przekierowuje pod inny, nie powinien znajdować się w mapie, ponieważ nie jest stroną, tylko drogowskazem. Najczęściej trafia tam po zmianie struktury serwisu, gdy stare adresy otrzymały przekierowania, a mapa nie została odświeżona. Drugie częste źródło to niezgodność wersji: mapa podaje adresy z przedrostkiem www albo z protokołem http, a serwis działa bez www i pod https. Wśród błędów opisanych w pomocy Search Console są zarówno adresy nieodwiedzone z powodu zbyt wielu przekierowań, jak i niezgodność ścieżki związana z przedrostkiem www. Po każdej przebudowie serwisu mapę trzeba więc wygenerować od nowa, o czym szerzej piszemy we wpisie o migracji strony bez utraty pozycji.

Strony z regułą noindex

Strona z regułą noindex w mapie to sprzeczny komunikat. Reguła ta, umieszczana w znaczniku meta albo w nagłówku odpowiedzi serwera, prosi wyszukiwarkę o niepokazywanie strony w wynikach, co Google opisuje w dokumentacji o blokowaniu indeksowania. Typowe przykłady to strony podziękowania po wysłaniu formularza, regulaminy, które właściciel wolał ukryć, albo archiwa tagów. Jeżeli wtyczka do SEO wyklucza dany typ treści z indeksowania, zwykle sama usuwa go też z mapy, ale przy ręcznych ustawieniach pojedynczych podstron warto to sprawdzić.

Adresy niekanoniczne i warianty z parametrami

Do mapy trafia jeden adres na jedną treść. W sklepach internetowych problem dotyczy głównie filtrów i sortowania: ta sama kategoria bywa dostępna pod dziesiątkami adresów z parametrami koloru, rozmiaru czy kolejności. Do mapy wpisuje się adres kategorii w podstawowej postaci, a warianty pomija. To samo dotyczy adresów z parametrami śledzącymi z kampanii reklamowych oraz produktu, który jest przypisany do kilku kategorii i przez to ma kilka adresów. O porządkowaniu takich przypadków piszemy we wpisie o pozycjonowaniu sklepu internetowego.

Format mapy witryny: budowa pliku i kodowanie

Mapa witryny XML ma prostą budowę określoną w protokole sitemaps.org: element główny urlset, a w nim po jednym elemencie url na każdą stronę, z obowiązkowym adresem w znaczniku loc. Google przyjmuje także mapy w postaci kanałów RSS i Atom oraz zwykłego pliku tekstowego z jednym adresem w wierszu i nie faworyzuje żadnego formatu, ale XML daje najwięcej możliwości i jest tworzony przez większość systemów. Wymagania zebrano na stronie Przygotowywanie i przesyłanie mapy witryny.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/</loc>
    <lastmod>RRRR-MM-DD</lastmod>
  </url>
  <url>
    <loc>https://www.example.com/uslugi/naprawa-instalacji/</loc>
    <lastmod>RRRR-MM-DD</lastmod>
  </url>
</urlset>

W miejscu zapisu RRRR-MM-DD podaje się rzeczywistą datę ostatniej zmiany strony w kolejności rok, miesiąc, dzień. Pomoc Search Console wymaga tu formatu W3C Datetime, a datę zapisaną inaczej zgłasza jako nieprawidłową.

Wymagania wobec adresów i kodowania

Plik musi być zapisany w kodowaniu UTF-8, a adresy muszą być pełne i bezwzględne, czyli zaczynać się od protokołu i nazwy domeny. Zapis w rodzaju /uslugi/ jest błędem, poprawny to https://www.example.com/uslugi/. Adresy względne Search Console zalicza do nieodwiedzonych.

Wartości znaczników muszą mieć poprawnie zamienione znaki specjalne. W praktyce chodzi najczęściej o znak & występujący w adresach z parametrami, który w pliku XML zapisuje się jako &amp;. Pomoc Search Console wymienia niezakodowane znaki, takie jak & i <, jako częstą przyczynę komunikatu o błędzie analizy składni. Przed pierwszym wierszem pliku nie powinno być też pustych znaków, bo raport odnotowuje to jako osobne ostrzeżenie.

Znaczniki lastmod, priority i changefreq

Spośród znaczników dodatkowych znaczenie dla Google ma tylko lastmod, czyli data ostatniej zmiany strony. Dokumentacja stwierdza jasno, że znaczniki priority (ważność strony) i changefreq (częstotliwość zmian) są pomijane. Nie warto więc tracić czasu na ustawianie ważności poszczególnych podstron, chociaż wiele wtyczek wciąż to umożliwia.

Z datą lastmod sprawa jest subtelniejsza. Google korzysta z niej tylko wtedy, gdy jest spójna i daje się potwierdzić, na przykład przez porównanie z faktyczną datą zmiany strony. Data ma odzwierciedlać istotną zmianę: głównej treści, danych strukturalnych lub linków. Zmiana roku w stopce się do nich nie zalicza. Serwis, który przy każdym generowaniu mapy wpisuje bieżącą datę do wszystkich adresów, uczy wyszukiwarkę, że tej informacji nie można ufać. Lepiej nie podawać daty wcale, niż podawać nieprawdziwą.

Limity mapy witryny i dzielenie jej na kilka plików

Jedna mapa witryny może zawierać najwyżej 50 tys. adresów i mieć najwyżej 50 MB po rozpakowaniu. Jeżeli serwis przekracza którykolwiek z tych limitów, listę dzieli się na kilka plików, a te łączy plikiem indeksu map. Plik mapy można skompresować w formacie gzip, ale limit wielkości dotyczy wersji rozpakowanej.

Indeks map to plik XML o podobnej budowie, który zamiast adresów stron zawiera adresy poszczególnych map. Zgodnie z dokumentacją o plikach indeksu map witryny może on wskazywać do 50 tys. map, a w jednej usłudze w Search Console można zgłosić do 500 takich indeksów. Dla ogromnej większości firm są to wartości czysto teoretyczne.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/mapa-strony.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/mapa-produkty.xml</loc>
  </sitemap>
</sitemapindex>

Obowiązują przy tym dwie zasady, o których łatwo zapomnieć. Indeks nie może wskazywać innego indeksu, bo Search Console zgłasza to jako błąd zagnieżdżonych indeksów. Mapy wymienione w indeksie muszą też znajdować się w tym samym serwisie, w tym samym katalogu co indeks lub w katalogu niższym.

Gdzie umieścić plik

Mapę najlepiej umieścić w katalogu głównym serwisu, czyli pod adresem w rodzaju https://www.example.com/sitemap.xml. Google dopuszcza dowolne miejsce, ale zastrzega, że mapa, która nie została zgłoszona w Search Console, obejmuje tylko katalog, w którym leży, i jego podkatalogi. Plik położony w katalogu /blog/ nie powinien więc wymieniać adresów spoza bloga. Położenie w katalogu głównym usuwa ten problem.

Czy dzielić mapę, gdy limity są daleko

Podział mapy na części bywa przydatny także wtedy, gdy do limitów jest bardzo daleko. Osobny plik dla podstron usług, osobny dla wpisów, osobny dla produktów i kategorii pozwala w Search Console oglądać stan indeksowania każdej grupy z osobna. To obserwacja z naszej praktyki, a nie wymóg Google: sklep z Poznania, w którym produkty mają własną mapę, szybciej zauważy, że kłopot dotyczy właśnie kart produktów, a nie całego serwisu.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Jak powstaje mapa witryny w WordPressie i w sklepach

W większości przypadków mapy nie pisze się ręcznie, ponieważ tworzy ją system, na którym działa strona. Warto więc najpierw ustalić, czy mapa już istnieje i pod jakim adresem, a dopiero potem myśleć o jej samodzielnym przygotowaniu.

WordPress ma mapę wbudowaną. Jak opisano we wpisie zespołu rozwijającego WordPressa, indeks map jest dostępny pod adresem /wp-sitemap.xml i powstaje na bieżąco, a nie jako plik zapisany na serwerze. Obejmuje publiczne typy treści i taksonomie, archiwa autorów oraz stronę główną. Jedna mapa mieści domyślnie do dwóch tysięcy pozycji, a WordPress sam dopisuje jej adres do pliku robots.txt. Wbudowana mapa podaje wyłącznie adresy, bez daty ostatniej zmiany, i wyłącza się, gdy w ustawieniach zaznaczono prośbę o nieindeksowanie witryny.

Wtyczki do SEO zwykle zastępują mapę wbudowaną własną, pod innym adresem, i dają więcej kontroli: pozwalają wyłączyć z mapy wybrane typy treści, pojedyncze podstrony czy archiwa. Ważne, by w serwisie działała jedna mapa i by to właśnie jej adres był zgłoszony w Search Console i podany w robots.txt. Zdarza się, że po zmianie wtyczki w Search Console zostaje stary adres, który zwraca błąd 404.

Sklepy na WooCommerce korzystają z mapy WordPressa lub wtyczki, a platformy takie jak PrestaShop czy Shopify mają własne mechanizmy. Niezależnie od systemu trzeba sprawdzić to samo: czy do mapy nie trafiają produkty wycofane i ukryte, adresy z filtrami, strony koszyka i konta klienta. Automat wie, jakie adresy istnieją, ale nie wie, które z nich mają być w wynikach. Tę decyzję musi podjąć człowiek, najlepiej już na etapie projektu, o czym piszemy we wpisie o nowej stronie firmowej pod SEO.

Jak wskazać mapę witryny w pliku robots.txt

Mapę wskazuje się w pliku robots.txt jednym wierszem zaczynającym się od słowa Sitemap, po którym następuje pełny adres pliku. To najprostszy sposób poinformowania o mapie wszystkich wyszukiwarek jednocześnie, a przy tym nie wymaga uprawnień właściciela usługi w Search Console.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.example.com/sitemap.xml

Dokumentacja Google o tworzeniu pliku robots.txt podaje kilka szczegółów. Wiersz ten jest nieobowiązkowy. Adres musi być pełny, razem z protokołem i domeną, ponieważ Google nie zakłada ani nie sprawdza wariantów z http i https czy z www i bez www. Można podać kilka map, każdą w osobnym wierszu, a w adresie mapy nie działa znak gwiazdki, który w pozostałych regułach zastępuje dowolny ciąg znaków. Jeżeli serwis ma indeks map, wystarczy wskazać sam indeks.

Trzeba przy tym dopilnować, aby robots.txt nie blokował samej mapy ani adresów, które ona wymienia. Oba przypadki pomoc Search Console opisuje jako błędy: w pierwszym mapy nie da się pobrać, w drugim raport informuje, że mapa zawiera adresy zablokowane przez robots.txt. Jeżeli w tym samym pliku ustawiają Państwo reguły dla robotów asystentów AI, warto przeczytać także wpis o robotach AI i robots.txt.

Jak zgłosić mapę witryny w Search Console

Mapę zgłasza się w Search Console w raporcie Mapy witryn, dostępnym w menu po lewej stronie w grupie Indeksowanie. U góry raportu znajduje się pole do wpisania adresu nowej mapy oraz przycisk przesłania. Całą procedurę opisuje strona pomocy Zarządzanie mapami witryn przy użyciu raportu Mapy witryn. Do przesłania mapy potrzebne są uprawnienia właściciela usługi.

1. Publikacja pliku na serwerze

   Mapa musi być dostępna pod publicznym adresem, najlepiej w katalogu głównym, i nie może wymagać logowania.

2. Sprawdzenie dostępności

   Pomoc Google zaleca wpisanie adresu mapy w narzędziu do sprawdzania adresów URL i wykonanie testu wersji opublikowanej. Pobranie musi się powieść.

3. Przesłanie adresu w raporcie

   W raporcie Mapy witryn wpisuje się adres pliku w polu nowej mapy i zatwierdza przyciskiem przesłania.

4. Odczytanie stanu

   Mapa powinna zostać pobrana od razu. Odwiedzenie i zaindeksowanie adresów, które zawiera, może potrwać dłużej.

Jak czytać raport Mapy witryn

Tabela przesłanych map pokazuje adres mapy, jej typ, datę przesłania, datę ostatniego odczytu, stan oraz liczbę wykrytych stron i filmów. Ostatnia kolumna prowadzi do raportu o stanie indeksowania zawężonego do adresów z tej jednej mapy.

Stan przyjmuje jedną z trzech wartości. Sukces oznacza, że mapa została pobrana i odczytana bez błędów. Stan informujący o błędach oznacza, że plik pobrano, ale co najmniej jeden wpis jest wadliwy, przy czym poprawne adresy i tak trafiają do kolejki. Komunikat o nieudanym pobraniu oznacza, że Google w ogóle nie dostał pliku. Pomoc wymienia jako możliwe przyczyny blokadę w robots.txt, błędny adres lub odpowiedź 404, chwilową niedostępność serwera, ręczne działania nałożone na witrynę, a także niewielkie zapotrzebowanie na odwiedzanie serwisu przez robota.

Warto pamiętać, że liczba wykrytych stron nie jest liczbą stron zaindeksowanych. Mówi tylko, ile adresów Google odczytał z pliku. To, co dzieje się z nimi dalej, pokazuje raport o stanie indeksowania, którego statusy omawiamy we wpisie o tym, dlaczego Google nie indeksuje strony.

Usuwanie starej mapy z raportu

Starą mapę usuwa się z raportu po wejściu w jej szczegóły: w menu dodatkowych opcji znajduje się polecenie usunięcia mapy witryny. Pomoc Google zastrzega jednak, że usunięcie wpisu z raportu nie sprawia, że Google zapomina o pliku ani o adresach, które zawierał. Jeżeli robot ma przestać odczytywać daną mapę, trzeba usunąć sam plik z serwera albo go zablokować.

Typowe błędy w mapach witryn i lista kontrolna

Najczęstsze błędy w mapach witryn nie dotyczą składni, tylko zawartości: plik jest technicznie poprawny, ale wymienia adresy, których nie powinno w nim być, albo pomija te najważniejsze. Składnię sprawdza i opisuje Search Console, natomiast dobór adresów wymaga przejrzenia pliku przez człowieka.

Spośród komunikatów, które raport pokazuje przy mapie, w praktyce najczęściej spotykamy kilka. Adresy niedostępne oznaczają, że Google nie mógł odwiedzić strony wymienionej w mapie. Niedozwolony adres pojawia się, gdy mapa wymienia strony z innej domeny albo z katalogu położonego wyżej niż ona sama. Niezgodność ścieżki wskazuje na różnicę w przedrostku www między adresem mapy a adresami w środku. Nieprawidłowa data dotyczy źle zapisanego znacznika lastmod, a błąd analizy składni najczęściej niezamienionych znaków specjalnych. Pusta mapa to plik bez żadnego adresu, co zdarza się po awarii wtyczki lub zmianie ustawień.

Osobną grupę stanowią pomyłki, których raport nie nazwie błędem. Mapa bywa nieaktualna, bo wygenerowano ją raz zewnętrznym narzędziem i wgrano na serwer jako zwykły plik, a od tamtej pory przybyło kilkadziesiąt podstron. Bywa też pozostałością po wersji testowej i wymienia adresy z domeny roboczej. W firmach z wieloma lokalizacjami zdarza się, że strony oddziałów powstały jako osobny typ treści, którego wtyczka domyślnie nie uwzględnia.

• Mapa otwiera się w przeglądarce pod publicznym adresem i nie wymaga logowania.
• Plik jest zapisany w UTF-8, a wszystkie adresy są pełne, z protokołem i domeną.
• Adresy w mapie mają tę samą postać co w serwisie: ten sam protokół i ten sam wariant z www lub bez.
• W mapie nie ma adresów przekierowanych, z regułą noindex, niekanonicznych, zablokowanych w robots.txt ani zwracających błąd.
• W mapie są wszystkie ważne podstrony: usługi, kategorie, produkty, wpisy, strony lokalizacji.
• Data lastmod zmienia się tylko przy rzeczywistej zmianie treści albo nie jest podawana.
• Plik nie przekracza 50 tys. adresów ani 50 MB, a większe serwisy korzystają z indeksu map.
• Adres mapy jest wskazany w robots.txt i przesłany w raporcie Mapy witryn, a raport pokazuje stan Sukces.
• Po każdej przebudowie serwisu lub zmianie wtyczki mapa została sprawdzona od nowa.

Samodzielna kontrola wystarcza przy małej stronie firmowej. Pomoc specjalisty przydaje się wtedy, gdy liczba stron wykrytych w mapie wyraźnie odbiega od liczby stron zaindeksowanych, gdy raport długo pokazuje nieudane pobranie mimo działającego pliku, gdy sklep generuje tysiące adresów z filtrami albo gdy serwis ma kilka wersji językowych. W takich sytuacjach mapa jest zwykle tylko objawem, a przyczyna leży w strukturze serwisu, przekierowaniach lub adresach kanonicznych. Wyjaśnia to dopiero pełny audyt SEO, którego zakres opisujemy we wpisie o tym, co powinien zawierać audyt SEO.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl