Znacznik lastmod w mapie witryny. Jak ustawić go tak, by Google mu ufało?

Mapa witryny podaje Google listę adresów, a przy każdym z nich może podać także datę ostatniej zmiany. Służy do tego znacznik <lastmod>. Kłopot zaczyna się wtedy, gdy ta data nie odpowiada temu, co naprawdę dzieje się na stronie: wszystkie podstrony mają dzisiejszą datę, choć nikt ich nie ruszał od miesięcy, albo odwrotnie, poprawiony cennik od dawna czeka na ponowne odwiedziny robota, bo mapa nadal pokazuje starą datę.

Ten wpis jest instrukcją dla właścicieli firm, osób prowadzących sklepy i blogi oraz dla wszystkich, którzy sami opiekują się swoją stroną. Nie trzeba być programistą, żeby wykonać większość opisanych czynności. Tam, gdzie potrzebna będzie pomoc osoby technicznej, podaję gotowy opis zadania, który można jej przekazać.

Po lekturze czytelnik będzie umiał odczytać daty z własnej mapy, ocenić, czy są wiarygodne, znaleźć przyczynę błędu, poprawić ustawienia w WordPressie lub w innym systemie, zgłosić mapę ponownie i rozpoznać, czy Google zaczęło z tych dat korzystać.

Czym jest znacznik lastmod i do czego Google go używa?

Mapa witryny w formacie XML składa się z wpisów. Każdy wpis to jeden adres podstrony w znaczniku <loc> oraz, opcjonalnie, data w znaczniku <lastmod>. Data mówi robotowi: „ta podstrona zmieniła się ostatnio tego dnia”. Dzięki temu Google może zdecydować, które adresy odwiedzić ponownie w pierwszej kolejności, zamiast sprawdzać po kolei wszystkie.

Znacznik nie jest obowiązkowy. Mapa bez dat jest poprawna i Google ją przyjmie. Dokumentacja Google mówi jednak wyraźnie, na jakich warunkach data jest brana pod uwagę: wyszukiwarka używa wartości <lastmod>, jeśli jest ona spójna i daje się zweryfikować, na przykład przez porównanie z ostatnią modyfikacją strony. Inaczej mówiąc, robot porównuje to, co obiecuje mapa, z tym, co zastaje na miejscu.

Z tego zdania wynika cała reszta tej instrukcji. Jeżeli mapa regularnie podaje daty, które zgadzają się z rzeczywistymi zmianami, Google ma powód, żeby im wierzyć. Jeżeli mapa podaje daty przypadkowe, robot po odwiedzeniu kilku podstron stwierdza, że nic się na nich nie zmieniło, i przestaje zwracać uwagę na ten sygnał.

Ta sama dokumentacja wyjaśnia przy okazji sprawę dwóch innych znaczników, które często stoją obok dat. Google ignoruje wartości <priority> oraz <changefreq>. Nie trzeba ich usuwać, ale nie należy też poświęcać czasu na ich dopracowywanie. Z trzech dodatkowych znaczników tylko data ostatniej zmiany wpływa na pracę robota Google.

Trzeba też jasno powiedzieć, czego znacznik nie robi. Poprawna data nie podnosi pozycji strony i nie jest sposobem na „odświeżenie” starych treści w oczach wyszukiwarki. To informacja porządkowa, która pomaga robotowi szybciej trafić na podstrony, które faktycznie się zmieniły. Kto nie ma jeszcze mapy albo nie jest pewien, co powinno się w niej znaleźć, znajdzie opis w osobnym wpisie o tym, jak wygenerować mapę witryny XML.

Po czym rozpoznać, że daty w mapie są niewiarygodne?

Pierwsza czynność jest prosta: trzeba otworzyć własną mapę w przeglądarce. Najczęściej znajduje się ona pod adresem kończącym się na /sitemap.xml, /sitemap_index.xml albo /wp-sitemap.xml. Jeśli pod tymi adresami nic nie ma, adres mapy bywa podany w pliku robots.txt, w wierszu zaczynającym się od słowa Sitemap:.

Po otwarciu mapy wystarczy przejrzeć kolumnę z datami. Na problem wskazują następujące objawy:

• wszystkie adresy mają tę samą datę, zwykle dzisiejszą lub wczorajszą,
• po odświeżeniu mapy w przeglądarce daty przeskakują na bieżącą godzinę,
• data przy podstronie, na której nic się nie zmieniło od dawna, jest świeża,
• data przy podstronie niedawno poprawionej jest stara albo nie ma jej wcale,
• daty wyprzedzają dzień dzisiejszy,
• w raporcie „Mapy witryn” w Google Search Console przy mapie widnieje stan „Zawiera błędy”, a w szczegółach pojawia się błąd „Nieprawidłowa data”.

Pięć pierwszych objawów oznacza, że data jest technicznie poprawna, ale nieprawdziwa. Google przyjmie taką mapę bez żadnego komunikatu, a mimo to przestanie korzystać z dat. Ostatni objaw oznacza błąd zapisu: data ma zły format lub niemożliwą wartość. Oba przypadki naprawia się inaczej, dlatego w dalszej części są omówione osobno.

Jest też objaw pośredni, widoczny dopiero po czasie. Zmienione podstrony długo pokazują się w wynikach wyszukiwania w starej wersji: ze starym tytułem, starą ceną albo nieaktualnym opisem. Przyczyn takiego stanu może być wiele, ale niewiarygodne daty w mapie są jedną z tych, które najłatwiej sprawdzić i usunąć.

Co Google uznaje za istotną zmianę podstrony?

Dokumentacja Google podaje wprost, że wartość <lastmod> powinna odzwierciedlać datę i godzinę ostatniej istotnej aktualizacji strony. Jako przykłady zmian istotnych wymienia aktualizację głównej treści, uporządkowanych danych lub linków na stronie. Jako przykład zmiany nieistotnej podaje aktualizację daty praw autorskich, czyli typowej notki w stopce.

Tę zasadę łatwo przełożyć na codzienną pracę przy stronie. Data powinna się zmienić, gdy odwiedzający zobaczy po zmianie coś innego niż przedtem w głównej części podstrony: nowy akapit, poprawioną cenę, inny zakres usługi, nowe zdjęcia produktu, dopisane pytania i odpowiedzi, zmienione godziny otwarcia. Data nie powinna się zmieniać, gdy zmienia się wyłącznie otoczenie tej treści.

W praktyce najwięcej fałszywych dat powstaje przy zmianach wspólnych dla całego serwisu. Wymiana logo, nowa pozycja w menu, inny kolor przycisków, zmiana numeru telefonu w stopce czy aktualizacja szablonu dotyczą każdej podstrony naraz, ale nie zmieniają tego, o czym dana podstrona mówi. Jeśli po takiej operacji cała mapa dostaje nową datę, robot odwiedza setki adresów i na żadnym nie znajduje nowej treści.

Zdarzają się sytuacje graniczne. Poprawienie literówki albo przecinka jest zmianą treści, ale nie wnosi niczego nowego. Uważam, że w takich przypadkach lepiej zostawić starą datę. Zasada, którą stosuję, brzmi: datę zmienia się wtedy, gdy podstronę warto przeczytać ponownie. Drobna korekta językowa tego warunku nie spełnia, a dopisany rozdział lub nowa cena już tak.

Jak zapisać datę, żeby mapa nie zgłaszała błędu?

Data w znaczniku musi mieć format W3C Datetime. Pomoc Search Console opisuje to przy błędzie „Nieprawidłowa data”: godzina jest opcjonalna, ale jeśli zostanie podana, trzeba podać również strefę czasową. W praktyce używa się jednego z dwóch zapisów.

Pierwszy zapis to sama data: cztery cyfry roku, dwie cyfry miesiąca i dwie cyfry dnia, rozdzielone dywizami. Wzór wygląda tak: RRRR-MM-DD. Miesiąc i dzień zawsze mają dwie cyfry, więc trzeci dzień marca to „03-03”, a nie „3-3”. Drugi zapis zawiera także godzinę i strefę czasową. Wzór: RRRR-MM-DDTGG:MM:SS+01:00. Litera „T” oddziela datę od godziny, a końcówka „+01:00” lub „+02:00” oznacza przesunięcie względem czasu uniwersalnego. Zamiast przesunięcia można podać literę „Z”, jeśli godzina jest zapisana w czasie uniwersalnym.

Poprawny wpis w mapie ma następującą budowę. W miejsce wzoru należy wstawić rzeczywistą datę ostatniej istotnej zmiany podstrony:

<url>
  <loc>https://www.przyklad.pl/oferta/</loc>
  <lastmod>RRRR-MM-DD</lastmod>
</url>

Błąd „Nieprawidłowa data” wywołują najczęściej zapisy przyjęte w Polsce, ale niezgodne ze standardem. Chodzi o kolejność dzień, miesiąc, rok, o kropki lub ukośniki zamiast dywizów, o godzinę bez strefy czasowej, o spację zamiast litery „T” i o nazwę miesiąca zapisaną słownie. Błędem jest też data, która nie istnieje w kalendarzu, na przykład trzydziesty dzień lutego.

Który zapis wybrać? W serwisie firmowym, blogu i większości sklepów w zupełności wystarcza sama data. Zapis z godziną przydaje się w serwisach, w których ta sama podstrona zmienia się kilka razy dziennie, na przykład w portalach z wiadomościami. Niezależnie od wyboru cała mapa powinna trzymać się jednego zapisu.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: sprawdzę daty w mapie, ustalę, skąd biorą się błędne wartości, i doprowadzę ustawienia do stanu, w którym znacznik pokazuje wyłącznie rzeczywiste zmiany.

Skąd biorą się błędne daty? Najczęstsze przyczyny

Daty w mapie prawie nigdy nie są wpisywane ręcznie. Wstawia je system, na którym działa strona, albo dodatek, który tworzy mapę. Błędna data jest więc zwykle skutkiem sposobu, w jaki ten system ustala moment ostatniej zmiany. W mojej praktyce powtarza się kilka przyczyn.

Mapa wstawia datę swojego wygenerowania

Część generatorów, zwłaszcza prostych skryptów i narzędzi działających poza stroną, wpisuje przy każdym adresie moment utworzenia pliku. Jeśli mapa powstaje co noc, wszystkie podstrony codziennie dostają nową datę. To najczęstszy powód, dla którego Google przestaje brać daty pod uwagę.

System zmienia datę przy każdym zapisie

W WordPressie i w wielu innych systemach data modyfikacji wpisu zmienia się po każdym kliknięciu przycisku aktualizacji, nawet gdy w treści nie zmieniono ani jednego znaku. Podobnie działają operacje hurtowe: masowa edycja kategorii, import produktów z pliku, zmiana autora wielu wpisów naraz. Po takiej operacji setki adresów mają świeżą datę bez żadnej zmiany widocznej dla odwiedzającego.

Data nie zmienia się, choć zmienia się treść

To odwrotna sytuacja. Treść podstrony pochodzi z miejsca, którego system nie wiąże z jej datą modyfikacji. Typowe przykłady to strona kategorii, na której przybywa produktów, strona z listą wpisów, podstrona zbudowana z bloków wspólnych dla wielu miejsc oraz cena aktualizowana przez zewnętrzny program magazynowy. Odwiedzający widzi nową treść, a mapa nadal podaje dawną datę.

Pamięć podręczna podaje starą wersję mapy

Mapa bywa przechowywana w pamięci podręcznej wtyczki, serwera lub sieci dostarczania treści. System tworzy wtedy poprawne daty, ale robot dostaje plik sprzed wielu dni. Rozpoznaje się to po tym, że mapa otwarta w przeglądarce nie zawiera wpisu opublikowanego przed chwilą.

Zegar serwera lub strefa czasowa są źle ustawione

Jeśli serwer ma źle ustawiony czas albo system zapisuje godzinę w innej strefie, niż deklaruje w mapie, daty mogą wyprzedzać rzeczywistość o kilka godzin. Data z przyszłości jest dla robota wyraźnym sygnałem, że wartościom z tej mapy nie można ufać.

W serwisie działają dwie mapy naraz

Zdarza się, że jedną mapę tworzy sam system, drugą wtyczka, a trzecią dawno zapomniany dodatek. Każda podaje inne daty dla tych samych adresów. Google dostaje sprzeczne informacje i żadna z nich nie jest spójna.

Jak sprawdzić, która przyczyna dotyczy danej witryny?

Rozpoznanie zajmuje kilkanaście minut i nie wymaga żadnych płatnych narzędzi. Wystarczy przeglądarka, dostęp do panelu strony i do Google Search Console. Czynności należy wykonać w podanej kolejności, bo każda kolejna zawęża listę możliwych przyczyn.

1. Otwarcie mapy w przeglądarce i zanotowanie dat przy trzech podstronach: jednej zmienionej niedawno, jednej niezmienianej od dawna i stronie głównej.
2. Odświeżenie mapy po kilku minutach. Jeśli daty zmieniły się na bieżącą godzinę, mapa wstawia moment swojego wygenerowania.
3. Porównanie zanotowanych dat z rzeczywistością. W panelu strony, na liście wpisów lub stron, należy odszukać te same trzy podstrony i odczytać datę ich ostatniej modyfikacji.
4. Próba kontrolna na jednej podstronie o małym znaczeniu: otwarcie jej w edytorze, zapisanie bez żadnej zmiany i ponowne otwarcie mapy. Jeśli data się przesunęła, system zmienia ją przy każdym zapisie.
5. Opublikowanie rzeczywistej poprawki na innej podstronie i sprawdzenie mapy. Jeśli nowa data nie pojawia się przez dłuższy czas, mapa pochodzi z pamięci podręcznej albo system nie wiąże tej treści z datą.
6. Otwarcie pliku robots.txt oraz raportu „Mapy witryn” w Search Console i policzenie zgłoszonych map. Więcej niż jeden zestaw map dla tych samych adresów oznacza dublowanie.
7. W Search Console wklejenie adresu jednej z trzech podstron w pole wyszukiwania na górze ekranu i otwarcie sekcji „Indeksowanie strony”. Pole „Ostatnie indeksowanie” pokazuje, kiedy robot naprawdę odwiedził tę podstronę.

Ostatni krok mówi najwięcej. Jeżeli podstrona została zmieniona, mapa od dawna podaje nową datę, a robot wciąż jej nie odwiedził, Google najpewniej nie korzysta z dat tej witryny. Jeżeli natomiast robot odwiedza zmienione podstrony w ciągu kilku dni, znacznik działa i wystarczy pilnować, żeby tak zostało. Więcej o samym odczytywaniu stanu podstrony w wyszukiwarce opisałem we wpisie o tym, jak sprawdzić, czy Google zaindeksował stronę.

Wynik rozpoznania warto zapisać w jednym zdaniu, na przykład: „mapa tworzona przez wtyczkę, daty zmieniają się przy każdym zapisie wpisu, mapa nie jest przechowywana w pamięci podręcznej”. Takie zdanie wskazuje od razu, którą z poniższych napraw zastosować.

Jak naprawić daty w mapie witryny w WordPressie?

WordPress tworzy własną mapę pod adresem /wp-sitemap.xml, a popularne wtyczki do pozycjonowania zastępują ją swoją. W obu przypadkach źródłem daty jest ta sama wartość: data ostatniej modyfikacji wpisu lub strony zapisana w bazie. Naprawa polega więc na uporządkowaniu tego, co i kiedy tę wartość zmienia.

Jedna mapa zamiast kilku

Najpierw trzeba ustalić, która mapa ma obowiązywać. Jeśli w serwisie działa wtyczka do pozycjonowania z własną mapą, to właśnie ta mapa powinna być zgłoszona w Search Console i wpisana w pliku robots.txt. Pozostałe generatory map należy wyłączyć w ich ustawieniach, a nieużywane dodatki do map odinstalować. Po tej zmianie pod starymi adresami map nie powinien otwierać się żaden plik z listą podstron.

Zapis tylko wtedy, gdy jest co zapisywać

Skoro każde kliknięcie przycisku aktualizacji przesuwa datę, najprostszą naprawą jest zmiana nawyku. Podstronę otwartą tylko do podglądu należy zamknąć bez zapisywania. Dotyczy to zwłaszcza osób, które zaglądają do edytora, żeby coś sprawdzić, i z przyzwyczajenia zapisują stronę przy wyjściu.

Część wtyczek do pozycjonowania i osobnych dodatków pozwala wykonać drobną poprawkę bez przesuwania daty modyfikacji. Taka opcja pojawia się zwykle w panelu bocznym edytora, w pobliżu przycisku zapisu. Jej nazwa zależy od wtyczki i wersji, dlatego trzeba jej poszukać w dokumentacji używanego dodatku, zamiast polegać na opisach z innych źródeł. Jeśli opcja jest dostępna, nadaje się do literówek i poprawek technicznych.

Operacje hurtowe z rozwagą

Przed masową edycją, importem produktów lub uruchomieniem narzędzia, które przepisuje wiele wpisów naraz, należy wykonać kopię zapasową bazy danych. Po operacji daty modyfikacji można przywrócić tylko z kopii albo za pomocą bezpośrednich zmian w bazie, a to praca dla osoby technicznej. Ręczne poprawianie dat w bazie bez kopii jest ryzykowne, bo pomyłka w jednym poleceniu zmienia wszystkie wpisy.

Jeśli hurtowa zmiana już się wydarzyła, a kopii nie ma, najbezpieczniej niczego nie cofać. Daty same wrócą do zgodności z rzeczywistością w miarę kolejnych prawdziwych zmian, a Google ocenia spójność w dłuższym czasie, nie na podstawie jednego zdarzenia.

Mapa poza pamięcią podręczną

W ustawieniach wtyczki do pamięci podręcznej oraz w panelu sieci dostarczania treści adresy map powinny być wyłączone z przechowywania. Zwykle robi się to przez dopisanie do listy wyjątków adresów zawierających słowo sitemap i rozszerzenie .xml. Po zmianie trzeba wyczyścić pamięć podręczną i sprawdzić, czy nowy wpis pojawia się w mapie od razu po publikacji.

Strefa czasowa witryny

W panelu WordPressa, w menu „Ustawienia” i dalej „Ogólne”, znajduje się pole „Strefa czasowa”. Powinno w nim być wybrane miasto, na przykład „Warszawa”, a nie ręcznie ustawione przesunięcie godzinowe. Wybór miasta sprawia, że system sam uwzględnia zmianę czasu z zimowego na letni i daty w mapie nie wyprzedzają rzeczywistości.

Jak ustawić lastmod w sklepie i w serwisie pisanym na zamówienie?

W sklepach i w serwisach tworzonych przez programistę mapa powstaje według reguł zapisanych w kodzie. Właściciel nie zmieni ich sam, ale może dokładnie opisać, czego oczekuje. Poniżej znajduje się zestaw wymagań, który można przekazać wykonawcy bez zmian.

• Data w mapie pochodzi z daty ostatniej zmiany głównej treści podstrony, a nie z daty wygenerowania pliku ani z bieżącego czasu serwera.
• Dla produktu datą zmiany jest ostatnia zmiana opisu, ceny, dostępności, zdjęć lub parametrów.
• Dla strony kategorii i listy wpisów datą zmiany jest data dodania lub zmiany najnowszej pozycji widocznej na tej liście.
• Zmiany szablonu, menu, stopki i innych części wspólnych nie zmieniają daty żadnej podstrony.
• Jeśli system nie potrafi wiarygodnie ustalić daty dla danego typu podstron, znacznik dla tego typu jest pomijany.
• Wszystkie daty mają format W3C Datetime, jeden zapis w całej mapie, z poprawną strefą czasową.

Piąty punkt bywa pomijany, a jest bardzo ważny. Brak daty jest lepszy niż data nieprawdziwa. Mapa bez znacznika pozostaje poprawna, a robot ustala częstotliwość odwiedzin na podstawie własnych obserwacji. Mapa z datami zmyślonymi podważa wiarygodność także tych dat, które są prawdziwe.

Co z datą w pliku indeksu map?

Większe serwisy dzielą mapę na kilka plików i łączą je plikiem indeksu. W indeksie także występuje znacznik daty, ale znaczy co innego: według dokumentacji Google określa czas modyfikacji odpowiedniego pliku mapy witryny. Powinien więc zmieniać się wtedy, gdy w danym pliku mapy przybył adres, ubył adres albo zmieniła się któraś z dat, i tylko wtedy.

Przy podziale mapy trzeba pamiętać o limitach z dokumentacji: jeden plik mapy może zawierać najwyżej 50 tysięcy adresów i mieć najwyżej 50 MB po rozpakowaniu. Przy okazji prac nad datami opłaca się przejrzeć samą listę adresów. Daty przy podstronach, których w mapie w ogóle nie powinno być, niczego nie poprawią, dlatego wcześniej należy oczyścić mapę z adresów z noindex i przekierowaniami.

Jak zgłosić poprawioną mapę i po czym poznać, że naprawa działa?

Google odczytuje zgłoszone mapy okresowo, we własnym tempie. Po drobnych zmianach nie trzeba niczego zgłaszać ponownie. Po większej zmianie, a taką jest uporządkowanie dat w całym serwisie, pomoc Search Console zaleca ponowne przesłanie mapy. Kto nie zgłaszał jeszcze mapy w ogóle, znajdzie pełny opis we wpisie o tym, jak zgłosić mapę witryny w Google Search Console.

1. Otwarcie adresu mapy w przeglądarce i upewnienie się, że plik się wczytuje, a daty są już poprawne.
2. Zalogowanie się do Google Search Console i wybranie właściwej usługi z listy w lewym górnym rogu.
3. Otwarcie raportu „Mapy witryn” z menu po lewej stronie.
4. W polu „Dodaj nową mapę witryny” wpisuje się adres mapy, a następnie należy kliknąć „Prześlij”.
5. Po chwili w tabeli zgłoszonych map trzeba odszukać wiersz tej mapy i odczytać kolumny „Ostatni odczyt” oraz „Stan”.
6. Jeśli stan jest inny niż „Sukces”, należy kliknąć wiersz mapy. Na stronie szczegółów pojawi się lista błędów z opisem.

Stan „Sukces” oznacza, że Google pobrało plik i nie znalazło w nim błędów zapisu. Stan „Zawiera błędy” z pozycją „Nieprawidłowa data” oznacza, że przynajmniej jedna data ma zły format lub niemożliwą wartość. Wtedy trzeba wrócić do sekcji o formacie daty, poprawić zapis i przesłać mapę jeszcze raz. Stan „Nie udało się pobrać” nie dotyczy dat: plik jest niedostępny dla robota i najpierw należy usunąć tę przeszkodę.

Trzeba pamiętać, że raport ocenia wyłącznie poprawność zapisu. Nie pokaże komunikatu o tym, że daty są nieprawdziwe. O tym, czy Google im ufa, świadczy dopiero zachowanie robota, a to sprawdza się inaczej.

Próba na jednej podstronie

Po uporządkowaniu dat warto przeprowadzić prosty test. Na jednej podstronie wprowadza się rzeczywistą zmianę treści, sprawdza się, czy mapa pokazuje przy niej nową datę, i nie zgłasza się tej podstrony ręcznie do zindeksowania. Po kilku dniach należy wkleić jej adres w pole wyszukiwania na górze Search Console i odczytać pole „Ostatnie indeksowanie” w sekcji „Indeksowanie strony”.

Jeśli data odwiedzin robota jest późniejsza niż data zmiany, sygnał z mapy najpewniej zadziałał. Taką próbę dobrze jest powtórzyć kilka razy na różnych podstronach, bo pojedynczy wynik może być przypadkiem. Ogólny obraz pracy robota pokazuje też raport „Statystyki indeksowania”, dostępny w Search Console w menu „Ustawienia”.

Na efekty trzeba poczekać. Google ocenia spójność dat w czasie, więc zaufanie nie wraca dzień po naprawie. Dokumentacja nie podaje żadnego terminu, dlatego nie należy wierzyć zapewnieniom o konkretnej liczbie dni. Z mojego doświadczenia wynika, że potrzeba na to tygodni regularnej, poprawnej pracy mapy.

Co zrobić, gdy Google nadal nie odwiedza zmienionych podstron?

Poprawne daty pomagają robotowi, ale nie zastąpią pozostałych warunków. Jeżeli po kilku tygodniach zmienione podstrony wciąż czekają na odwiedziny, należy sprawdzić po kolei kilka rzeczy.

Po pierwsze, czy zmieniona podstrona w ogóle znajduje się w mapie i czy jej adres w mapie jest dokładnie tym adresem, pod którym się otwiera, bez przekierowania. Po drugie, czy plik robots.txt nie blokuje robotowi dostępu do mapy lub do samych podstron. Po trzecie, czy serwer odpowiada szybko i bez błędów, bo przy częstych błędach serwera Google ogranicza liczbę odwiedzin. Po czwarte, czy do zmienionej podstrony prowadzą linki z innych miejsc serwisu.

W pilnych przypadkach, na przykład po poprawieniu błędnej ceny albo danych kontaktowych, nie trzeba czekać na mapę. W Search Console po wklejeniu adresu podstrony w górne pole wyszukiwania dostępny jest przycisk „Poproś o zindeksowanie”. To droga dla pojedynczych adresów, objęta limitem zgłoszeń, więc nie nadaje się do zgłaszania całego serwisu.

Błędy, których należy unikać

Najpoważniejszym błędem jest celowe ustawianie bieżącej daty przy wszystkich adresach w nadziei, że robot częściej odwiedzi stronę. Skutek jest odwrotny: Google szybko stwierdza, że daty nie odpowiadają zmianom, i przestaje z nich korzystać. Odradzam też dodatki, które automatycznie „odświeżają” daty wpisów bez zmiany treści. Wprowadzają w błąd zarówno wyszukiwarkę, jak i czytelników.

Drugim błędem jest wielokrotne usuwanie i ponowne przesyłanie mapy w krótkich odstępach. Nie przyspiesza to niczego, a utrudnia odczytanie historii w raporcie. Wystarczy jedno przesłanie po zakończeniu naprawy. Trzecim błędem jest rozbieżność między datą w mapie a datą aktualizacji pokazywaną czytelnikowi na samej podstronie lub podaną w danych uporządkowanych. Te trzy miejsca powinny mówić to samo.

Niektóre starsze opisy zalecają też powiadamianie Google o zmianie mapy specjalnym adresem wywoływanym po każdej aktualizacji. Google wycofało tę możliwość, więc dodatki i skrypty, które nadal to robią, nie przynoszą żadnej korzyści. Obecnie mapę zgłasza się w raporcie „Mapy witryn” albo wierszem Sitemap: w pliku robots.txt.

Najczęstsze pytania

Czy znacznik lastmod jest obowiązkowy?

Nie. Mapa bez dat jest poprawna i Google ją przyjmie. Znacznik opłaca się stosować tylko wtedy, gdy system potrafi podać prawdziwą datę ostatniej istotnej zmiany. Jeśli nie potrafi, lepiej go pominąć, niż podawać wartości przypadkowe.

Czy poprawna data w mapie podnosi pozycję strony w Google?

Nie ma podstaw, żeby tak twierdzić. Dokumentacja opisuje ten znacznik jako informację, którą Google wykorzystuje przy planowaniu odwiedzin robota. Pośrednia korzyść polega na tym, że poprawione treści szybciej trafiają do wyników wyszukiwania w aktualnej wersji.

Czy trzeba podawać godzinę, czy wystarczy sama data?

W większości serwisów wystarczy sama data w zapisie rok, miesiąc, dzień. Godzina ma sens tam, gdzie podstrony zmieniają się kilka razy dziennie. Jeśli godzina jest podana, musi jej towarzyszyć strefa czasowa, inaczej raport „Mapy witryn” zgłosi błąd „Nieprawidłowa data”.

Co zrobić ze znacznikami changefreq i priority?

Google je ignoruje, co wynika wprost z dokumentacji. Mogą zostać w mapie, bo jej nie psują, ale nie ma powodu, żeby ustawiać je ręcznie dla poszczególnych podstron. Czas przeznaczony na te znaczniki lepiej poświęcić na sprawdzenie dat.

Czy nowy komentarz pod wpisem powinien zmieniać datę?

To zależy od roli komentarzy w serwisie. Jeśli są ważną częścią treści, jak odpowiedzi na forum albo opinie o produkcie, zmiana daty jest uzasadniona. Jeśli pod wpisem pojawia się krótka uwaga, która niczego nie wnosi, datę lepiej zostawić bez zmian.

Jak długo trzeba czekać, aż Google zacznie ufać datom?

Google nie podaje terminu. Wiadomo jedynie, że ocenia spójność dat z rzeczywistymi zmianami, a do takiej oceny potrzebuje wielu odwiedzin rozłożonych w czasie. Należy liczyć się z tygodniami, a przy rzadko odwiedzanych serwisach z dłuższym okresem.

Czy data w mapie musi zgadzać się z datą widoczną na podstronie?

Powinna. Jeśli wpis pokazuje czytelnikowi datę aktualizacji, a dane uporządkowane zawierają datę modyfikacji, wszystkie trzy wartości powinny wskazywać ten sam dzień. Rozbieżności utrudniają wyszukiwarce ustalenie, która informacja jest prawdziwa.

Czy po każdej zmianie na stronie trzeba przesyłać mapę ponownie?

Nie. Google samo odczytuje zgłoszoną mapę co pewien czas i zauważa nowe daty. Ponowne przesłanie ma sens po dużych zmianach, takich jak zmiana adresu mapy, przebudowa serwisu albo opisana tu naprawa dat.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Nie każdy chce zaglądać do plików XML i porównywać daty, i jest to w pełni zrozumiałe. Mogę zrobić to od początku do końca: odczytam mapę, porównam daty z rzeczywistymi zmianami na podstronach, ustalę, co je zniekształca, poprawię ustawienia systemu, wtyczek i pamięci podręcznej albo przygotuję jasny opis zadania dla programisty. Następnie prześlę mapę ponownie w Search Console i sprawdzę, czy robot zaczął odwiedzać zmienione podstrony.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widzę w mapie i co trzeba w niej zmienić.