Czym mapa witryny jest, a czym nie

To plik z listą adresów, które chcesz zgłosić wyszukiwarce, wraz z opcjonalnymi informacjami dodatkowymi. Najczęściej w formacie XML, ale dopuszczalny jest też kanał RSS lub Atom oraz zwykły plik tekstowy z jednym adresem na wiersz.

Teraz to, czego mapa nie robi, bo tu rodzi się najwięcej rozczarowań.

• Nie gwarantuje indeksowania. To sugestia, nie polecenie. Google decyduje samodzielnie, czy dany adres warto zaindeksować, i obecność w mapie tej decyzji nie przesądza.

• Nie wpływa na pozycje. Mapa pomaga odkryć adres, nie ocenia jego jakości. Dodanie strony do mapy nie poprawi jej rankingu.

• Nie zastępuje nawigacji. Strona osiągalna tylko z mapy, bez żadnego odnośnika wewnętrznego, jest dla Google stroną bez znaczenia. Mapa uzupełnia strukturę odnośników, nie zastępuje jej.

Najkrócej: mapa witryny rozwiązuje problem odkrywania adresów. Jeśli Twój problem polega na tym, że Google zna adresy, ale ich nie indeksuje, mapa nie jest lekarstwem i trzeba szukać dalej.

Kto naprawdę jej potrzebuje

Google sam wskazuje sytuacje, w których mapa ma wyraźną wartość, i warto do nich uczciwie przyłożyć własny serwis.

Duże serwisy, w których część podstron jest słabo podlinkowana i robot może do nich nie dotrzeć przy zwykłym przechodzeniu po odnośnikach. Serwisy nowe, do których prowadzi jeszcze niewiele odnośników z zewnątrz. Serwisy z bogatymi treściami specjalnymi — wideo, obrazami, materiałami informacyjnymi — gdzie mapa przenosi dodatkowe informacje. Serwisy o rozbudowanym archiwum, w którym starsze wpisy nie są nigdzie linkowane.

Mały serwis wizytówkowy z kilkudziesięcioma podstronami i sensownym menu prawdopodobnie zostanie odkryty w całości bez mapy. To nie znaczy, że nie warto jej mieć — praktycznie każdy system zarządzania treścią generuje ją automatycznie, więc koszt jest zerowy. Znaczy natomiast, że nie ma sensu szukać w niej rozwiązania problemów z widocznością.

Budowa pliku i limity

Podstawowa struktura jest prosta: element opakowujący, wewnątrz zestaw wpisów, w każdym wpisie obowiązkowy adres i opcjonalne informacje dodatkowe.

Zasady, które trzeba zachować.

Adresy muszą być pełne, z protokołem i domeną, a nie względne. Plik musi być w kodowaniu UTF-8, a znaki specjalne w adresach zakodowane. Mapa może zgłaszać wyłącznie adresy z tej samej witryny, w której leży — plik w katalogu głównym obejmuje całą domenę, plik w podkatalogu tylko ten podkatalog.

Limity są dwa i dotyczą jednego pliku: nie więcej niż pięćdziesiąt tysięcy adresów i nie więcej niż pięćdziesiąt megabajtów przed kompresją. Plik można spakować, ale limit rozmiaru dotyczy wersji rozpakowanej. Przy większych serwisach dzieli się mapę na kilka plików i tworzy plik indeksu, który je wymienia — a indeks też ma limit pięćdziesięciu tysięcy pozycji.

W praktyce rzadko piszę mapy ręcznie. Częściej sprawdzam, co wygenerował system: czy podział na pliki jest logiczny, czy nie ma pustych plików i czy adresy w mapie zgadzają się z adresami kanonicznymi. Ta ostatnia rzecz jest najczęstszym błędem w sklepach — mapa zgłasza adresy z parametrami, a wersją kanoniczną jest adres czysty.

lastmod, changefreq i priority

Trzy opcjonalne znaczniki, o których krąży najwięcej nieporozumień.

Priority, czyli deklarowany priorytet adresu, oraz changefreq, czyli deklarowana częstotliwość zmian, są przez Google ignorowane. Potwierdzano to wielokrotnie i nie ma sensu tracić czasu na ich ustawianie. Wtyczki, które oferują suwak priorytetu dla każdej podstrony, dają poczucie kontroli nad czymś, co nie ma wpływu.

Lastmod, czyli data ostatniej modyfikacji, jest natomiast wykorzystywany — ale pod jednym warunkiem: musi być prawdziwy. Jeśli system wpisuje w to pole bieżącą datę przy każdym generowaniu mapy, to informacja przestaje cokolwiek znaczyć i zostaje pominięta. Odwrotnie, jeśli data faktycznie odpowiada momentowi rzeczywistej zmiany treści, pomaga wyszukiwarce zdecydować, co warto odwiedzić ponownie.

Co powinno się w mapie znaleźć, a co nie

Zasada jest jedna i wynika prosto z sensu tego pliku: w mapie są adresy kanoniczne, zwracające kod 200, przeznaczone do indeksowania. Nic więcej.

Czego więc w niej nie chcę: adresów z przekierowaniami, adresów zwracających błędy, wersji niekanonicznych — czyli takich, dla których kanoniczny jest inny adres — stron oznaczonych jako niewskazane do indeksowania, adresów zablokowanych w pliku robots (to sprzeczność sama w sobie: zgłaszasz adres i zabraniasz go odwiedzić), stron wyników wyszukiwania w serwisie, koszyka i stron technicznych, adresów z parametrami sortowania i filtrowania.

W sklepach dodam jedno: produkty wycofane trwale nie powinny zostawać w mapie. Jeśli strona ma zostać, powinna dostać sensowną treść, a jeśli ma zniknąć, mapa musi to odzwierciedlić.

Do sprawdzenia spójności wystarczy raport stanu indeksowania w Search Console z filtrem po mapie witryny. Pokazuje wprost, ile zgłoszonych adresów jest zaindeksowanych, ile wykluczonych i z jakiego powodu. To najlepszy raport diagnostyczny, jaki mamy, i pierwsza rzecz, do której zaglądam po zgłoszeniu nowej mapy.

Zgłaszanie i częstotliwość aktualizacji

Mapę zgłaszam na dwa sposoby jednocześnie. Pierwszy to raport map witryny w Search Console — daje potwierdzenie odczytania, informację o błędach i liczbę odkrytych adresów. Drugi to wiersz wskazujący lokalizację mapy w pliku robots, dzięki któremu znajdą ją także inne wyszukiwarki. Istnieje też adres służący do powiadamiania o aktualizacji, przydatny przy własnych skryptach, ale przy poprawnie zgłoszonej mapie nie jest potrzebny.

I odpowiedź na pytanie z tytułu: mapa powinna aktualizować się automatycznie, w momencie zmiany treści. Nie „raz w tygodniu” i nie „raz w miesiącu” — po prostu wtedy, gdy powstaje nowa podstrona albo zmienia się istniejąca. Każdy współczesny system to potrafi i jeśli Twój tego nie robi, to jest właśnie zadanie do wykonania.

Ponownego zgłaszania w Search Console po każdej zmianie nie trzeba robić. Google sam wraca do znanej mapy. Zgłaszam ją ponownie tylko wtedy, gdy zmienia się jej adres albo gdy wprowadzam dużą zmianę i chcę mieć w raporcie datę odniesienia.

Co natomiast robię regularnie: raz na kwartał otwieram mapę i sprawdzam liczbę adresów. Gwałtowny wzrost oznacza zwykle, że system zaczął generować adresy, których nie planowałem. Gwałtowny spadek oznacza, że coś przestało trafiać do mapy — i widziałem przypadki, w których wtyczka po aktualizacji zaczęła pomijać całą sekcję serwisu, o czym nikt nie wiedział przez wiele tygodni. Ten jeden przegląd wyłapuje więcej problemów niż wszystkie ustawienia priorytetów razem.