Mapa witryny jest listą adresów, które właściciel serwisu poleca wyszukiwarce do pokazywania w wynikach. Kłopot zaczyna się wtedy, gdy na tej liście znajdują się podstrony z dyrektywą noindex, adresy przekierowujące w inne miejsce albo dawno usunięte. Google dostaje wtedy dwa sprzeczne komunikaty jednocześnie: „proszę to zindeksować” i „proszę tego nie indeksować”.
Sytuacja dotyczy przede wszystkim serwisów, które przeszły przebudowę, zmianę adresów, wymianę wtyczki SEO albo przez lata rosły bez porządków. Zdarza się w małych stronach firmowych, w sklepach z tysiącami produktów i w blogach z rozbudowanymi archiwami.
Ta instrukcja prowadzi przez całą pracę: od odczytania raportów w Google Search Console, przez ustalenie, skąd niechciane adresy biorą się w mapie, po naprawę każdej przyczyny i sprawdzenie, czy Google przyjął zmiany. Po lekturze właściciel strony będzie umiał samodzielnie ocenić każdy adres i zdecydować, czy ma zostać w mapie, czy z niej zniknąć.
Po czym rozpoznać, że mapa witryny zawiera niewłaściwe adresy?
Pierwszym sygnałem jest zwykle wiadomość e-mail z Search Console o nowych przyczynach niezindeksowania stron. Drugim jest wyraźna różnica między liczbą adresów w mapie a liczbą stron zindeksowanych. Sama różnica nie przesądza jeszcze o błędzie, ponieważ Google nie gwarantuje zindeksowania każdego przesłanego adresu, ale jest powodem, żeby zajrzeć głębiej.
Pewność dają dopiero dwa raporty. W raporcie „Mapy witryn” widać, czy plik został odczytany i ile adresów Google w nim znalazł. W raporcie „Indeksowanie stron” widać, co stało się z tymi adresami: ile trafiło do indeksu, a ile zostało pominiętych i z jakiego powodu.
Dwa powody interesują nas tutaj szczególnie. Pierwszy nosi nazwę „URL zawiera tag „noindex””, drugi „Strona zawierająca przekierowanie”. Jeśli pojawiają się przy adresach przesłanych w mapie, mapa wymaga porządków.
Dlaczego noindex i przekierowania w mapie są problemem?
Dokumentacja Google mówi jasno, że w mapie witryny podaje się adresy, które mają być widoczne w wynikach wyszukiwania, czyli adresy kanoniczne. Jeżeli ta sama treść jest dostępna pod kilkoma adresami, do mapy trafia jeden, preferowany. Adres z noindex z definicji nie ma być widoczny w wynikach, a adres z przekierowaniem nie jest kanoniczny, bo odsyła gdzie indziej.
Pojedynczy taki adres nie wyrządzi szkody i nie jest podstawą żadnej kary. Kłopot rośnie razem ze skalą. Robot Google odwiedza adresy z mapy, trafia na zakaz indeksowania albo na przekierowanie i wraca z niczym. W dużym serwisie oznacza to wiele zmarnowanych odwiedzin, które mogłyby objąć nowe lub zmienione podstrony.
Uważam, że czysta mapa ma jeszcze jedną zaletę praktyczną: staje się narzędziem kontroli. Skoro znajdują się w niej wyłącznie adresy, które powinny być w Google, to każdy niezindeksowany adres z mapy jest od razu sygnałem do sprawdzenia.
Jak sprawdzić w Search Console, które adresy z mapy są wykluczone?
Do tej czynności potrzebny jest dostęp do usługi w Google Search Console oraz mapa przesłana w raporcie „Mapy witryn”. Jeżeli mapa nie została jeszcze przesłana, najpierw trzeba to zrobić, a sposób opisałem we wpisie o tym, jak zgłosić mapę witryny w Google Search Console.
- Po zalogowaniu do Search Console należy wskazać właściwą usługę, a następnie w menu po lewej stronie otworzyć raport „Indeksowanie stron”.
- Nad wykresem znajduje się filtr mapy witryny, domyślnie ustawiony na „Wszystkie znane strony”. Należy zmienić go na „Wszystkie przesłane strony”. Raport pokaże wtedy tylko adresy pochodzące z map przesłanych w raporcie „Mapy witryn” lub wskazanych w pliku robots.txt.
- Pod wykresem znajduje się tabela „Dlaczego strony nie są indeksowane”. Trzeba odszukać w niej wiersze „URL zawiera tag „noindex”” oraz „Strona zawierająca przekierowanie” i zanotować liczbę stron przy każdym z nich.
- Kliknięcie wiersza otwiera stronę ze szczegółami i tabelę z przykładowymi adresami. Lista jest ograniczona do 1000 wierszy, więc w dużym serwisie pokazuje próbkę, a nie komplet.
- Przyciskiem eksportu w prawym górnym rogu raportu pobiera się listę adresów do arkusza. To będzie lista robocza do dalszych decyzji.
- Te same czynności powtarza się dla drugiego wiersza, a przy okazji dla wiersza „Nie znaleziono (404)” i obu wierszy zaczynających się od słowa „Duplikat”, jeśli występują.
Jeżeli serwis ma kilka map, wygodniej jest sprawdzać je pojedynczo. W raporcie „Mapy witryn” przy każdej mapie znajduje się odnośnik „Zobacz stan w indeksie”, który otwiera raport „Indeksowanie stron” zawężony do adresów z tej jednej mapy. Ten sam efekt daje wybranie konkretnej mapy w filtrze nad wykresem.
Na tym etapie nie należy jeszcze niczego naprawiać. Lista z Search Console pokazuje skutek, a nie przyczynę. Ten sam wiersz raportu może oznaczać podstronę, która słusznie ma noindex i tylko niepotrzebnie trafiła do mapy, albo podstronę oferty, która przez pomyłkę została ukryta przed Google.
Skąd w mapie biorą się adresy, których nie powinno w niej być?
Przyczyn jest kilka i każdą naprawia się inaczej, dlatego rozpoznanie źródła oszczędza najwięcej czasu.
Mapa i noindex pochodzą z dwóch różnych narzędzi
Wtyczki SEO do WordPressa zwykle same pomijają w mapie podstrony, którym w tej samej wtyczce ustawiono noindex. Mechanizm przestaje działać, gdy mapę tworzy jedno narzędzie, a noindex ustawia inne. Typowy przykład: mapa wbudowana w WordPressa pod adresem /wp-sitemap.xml albo osobna wtyczka do map, a obok wtyczka SEO, motyw lub ręcznie wklejony znacznik w kodzie.
Mapa jest plikiem statycznym i nikt jej nie odświeża
Mapa wygenerowana jednorazowo w zewnętrznym programie i wgrana na serwer nie zmienia się razem z serwisem. Po każdej zmianie adresu, usunięciu podstrony lub ustawieniu przekierowania w pliku pozostaje stary wpis. Im starszy plik, tym więcej w nim adresów, które już nie odpowiadają kodem 200.
W Search Console pozostała stara mapa po przebudowie strony
Po zmianie systemu, wtyczki albo struktury adresów w raporcie „Mapy witryn” często pozostaje poprzedni plik. Google nadal go odczytuje, o ile plik wciąż istnieje pod dawnym adresem. Zdarza się też, że stary adres mapy jest nadal wpisany w pliku robots.txt.
Adresy w mapie różnią się od adresów docelowych drobiazgiem
Mapa podaje adres z przedrostkiem http, a serwis działa pod https. Mapa podaje wersję bez www, a serwis przekierowuje na www. Mapa podaje adres bez ukośnika na końcu, a serwer dokłada ukośnik przekierowaniem. Każda taka różnica oznacza, że Google dostaje z mapy adres, który od razu odsyła go dalej.
Do mapy trafiają typy treści, które z założenia nie mają być w Google
Chodzi o archiwa tagów, strony autorów, załączniki multimediów, wyniki wewnętrznej wyszukiwarki, koszyk, stronę zamówienia, panel klienta czy podziękowania po wysłaniu formularza. Jeśli generator mapy obejmuje wszystkie typy treści, a część z nich ma noindex, sprzeczność jest gotowa.
Noindex został ustawiony przez pomyłkę
To przypadek najgroźniejszy. Podstrona powinna być w Google, słusznie znajduje się w mapie, ale po pracach nad serwisem został na niej zakaz indeksowania. Najczęściej jest to pozostałość po wersji testowej albo skutek zaznaczenia opcji dla całego typu treści zamiast dla jednej podstrony.
Jak ocenić pojedynczy adres: zostawić w mapie czy usunąć?
Każdy adres z listy roboczej wymaga jednej decyzji, a pytanie zawsze brzmi tak samo: czy ta podstrona ma być widoczna w wynikach Google? Odpowiedź wyznacza kierunek naprawy.
- Podstrona ma być w Google i ma noindex: adres zostaje w mapie, a z podstrony zdejmuje się noindex.
- Podstrona nie ma być w Google i ma noindex: noindex zostaje, a adres znika z mapy.
- Adres przekierowuje na stałe do innej podstrony: stary adres znika z mapy, a w mapie ma się znaleźć adres docelowy, o ile jeszcze go tam nie ma.
- Adres zwraca błąd 404, bo podstrona została usunięta: adres znika z mapy.
- Adres wskazuje tagiem kanonicznym inną podstronę: znika z mapy, zostaje w niej wyłącznie adres kanoniczny.
Przy większej liczbie adresów nie ocenia się ich po kolei. Wystarczy posortować listę w arkuszu i poszukać wzorców: wspólnego katalogu w adresie, parametru po znaku zapytania, przedrostka http. Jeden wzorzec zwykle oznacza jedną przyczynę i jedną poprawkę dla całej grupy.
Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: porównam mapę z raportami Search Console, wskażę każdy adres do usunięcia lub odblokowania i doprowadzę mapę do stanu, w którym zawiera wyłącznie podstrony przeznaczone do wyników Google.
Jak potwierdzić, że adres naprawdę ma noindex albo przekierowanie?
Raport „Indeksowanie stron” pokazuje stan z ostatniej wizyty robota, a ta mogła mieć miejsce dawno. Zanim cokolwiek zostanie zmienione, trzeba sprawdzić stan bieżący. Dokumentacja Google opisuje tę kontrolę dla noindex krok po kroku.
- W tabeli z przykładami, obok wybranego adresu, należy kliknąć ikonę inspekcji w kształcie lupy. Otworzy się narzędzie do sprawdzania adresów URL.
- W sekcji „Indeksowanie stron” trzeba odszukać pozycję „Czy indeksowanie jest dozwolone”. Przy podstronie z zakazem raport wskazuje, że indeksowanie uniemożliwia dyrektywa noindex. W części opisującej wykrycie adresu widać, w których mapach witryn Google go znalazł.
- Następnie należy kliknąć „Sprawdź URL wersji opublikowanej”. Narzędzie pobierze podstronę w jej obecnym kształcie.
- Po zakończeniu testu ponownie odczytuje się pozycję „Czy indeksowanie jest dozwolone”. Jeżeli noindex nadal jest wykrywany, zakaz wciąż obowiązuje. Jeżeli już go nie ma, raport pokazywał stan nieaktualny.
Przy przekierowaniach trzeba znać jedno ograniczenie. Test wersji opublikowanej podąża za przekierowaniem i bada adres końcowy, ale nie informuje, że przekierowanie nastąpiło. Do sprawdzania przekierowań lepiej więc użyć innej metody.
Sprawdzenie przekierowania w przeglądarce i w wierszu poleceń
Najprostszy sposób to wklejenie adresu z mapy do paska przeglądarki i porównanie go z adresem, który pozostaje w pasku po załadowaniu strony. Różnica oznacza przekierowanie. Dokładniejszy wynik daje wiersz poleceń, w którym wpisuje się:
curl -I https://example.pl/stara-podstrona/
W odpowiedzi pierwszy wiersz podaje kod, na przykład 301 lub 302, a wiersz zaczynający się od słowa location podaje adres docelowy. Kod 200 oznacza, że adres nie przekierowuje. To samo polecenie pokaże zakaz indeksowania wysyłany w nagłówku, czyli wiersz X-Robots-Tag: noindex.
Gdzie w kodzie strony szukać noindex?
Zakaz indeksowania może być zapisany na dwa sposoby. Pierwszy to znacznik w sekcji head kodu strony, widoczny po otwarciu źródła strony w przeglądarce i wyszukaniu słowa noindex:
<meta name="robots" content="noindex">
Drugi to nagłówek odpowiedzi serwera X-Robots-Tag, którego w źródle strony nie widać. Stosuje się go często dla plików PDF i innych dokumentów. Jeżeli w kodzie nie ma znacznika, a Search Console uparcie zgłasza noindex, przyczyną jest zazwyczaj nagłówek ustawiony w konfiguracji serwera albo przez wtyczkę.
Jak usunąć z mapy podstrony z noindex?
Sposób zależy od tego, co tworzy mapę. Zasada jest wspólna: zmienia się źródło, z którego mapa powstaje, a nie sam plik wynikowy. Ręczna poprawka w pliku generowanym automatycznie zniknie przy najbliższym odświeżeniu.
Mapa tworzona przez wtyczkę SEO w WordPressie
W ustawieniach wtyczki, w części dotyczącej map witryn, wyłącza się całe typy treści i taksonomie, które nie mają być w Google: tagi, archiwa autorów, załączniki, formaty wpisów. Pojedyncze podstrony wyklucza się w edytorze danej podstrony, w panelu wtyczki SEO, ustawiając dla niej noindex. Wtyczka powinna wtedy sama pominąć ją w mapie.
Nazwy opcji różnią się między wtyczkami i zmieniają się z wersjami, dlatego nie podaję ich tutaj dosłownie. Po każdej zmianie należy otworzyć mapę w przeglądarce i sprawdzić, czy adres rzeczywiście z niej zniknął. Jeżeli serwis korzysta z pamięci podręcznej, przed sprawdzeniem trzeba ją wyczyścić, bo mapa bywa w niej przechowywana.
Dwie mapy jednocześnie
W WordPressie zdarza się, że działa mapa wbudowana w system pod adresem /wp-sitemap.xml, a obok niej mapa wtyczki SEO pod innym adresem. Większość wtyczek SEO wyłącza mapę systemową, ale warto to potwierdzić, wpisując oba adresy w przeglądarce. Docelowo powinna działać jedna mapa i tylko ona powinna być zgłoszona w Search Console oraz w pliku robots.txt.
Mapa statyczna lub generowana przez własny skrypt
Plik statyczny najlepiej zastąpić mapą tworzoną automatycznie przez system strony. Jeżeli to niemożliwe, mapę generuje się od nowa po wprowadzeniu wszystkich poprawek i podmienia plik na serwerze. Przy własnym skrypcie programista powinien dodać warunek: do mapy trafiają tylko podstrony opublikowane, bez zakazu indeksowania, odpowiadające kodem 200 i wskazujące same siebie jako adres kanoniczny. Więcej o samej budowie pliku znajduje się we wpisie o tym, jak wygenerować mapę witryny XML i co powinno się w niej znaleźć.
Co zrobić, gdy noindex znalazł się na ważnej podstronie przez pomyłkę?
W tym przypadku mapa jest w porządku, a błąd tkwi w podstronie. Adres zostaje w mapie, a naprawa polega na zdjęciu zakazu. Trzeba ustalić, skąd zakaz pochodzi: z ustawień pojedynczej podstrony we wtyczce SEO, z ustawień całego typu treści, z szablonu motywu albo z nagłówka serwera.
W WordPressie należy sprawdzić także ustawienie ogólne. W panelu, w sekcji „Ustawienia”, w zakładce „Czytanie”, znajduje się pole „Proś wyszukiwarki o nieindeksowanie tej witryny”. Zaznaczone pole nakłada zakaz na cały serwis i bywa pozostałością po okresie budowy strony.
Po zdjęciu zakazu wraca się do narzędzia do sprawdzania adresów URL, klika „Sprawdź URL wersji opublikowanej” i upewnia się, że noindex nie jest już wykrywany. Dopiero wtedy należy kliknąć „Poproś o zindeksowanie”. Taką prośbę składa się dla najważniejszych podstron, a pozostałe Google odwiedzi ponownie we własnym tempie.
Trzeba też wykluczyć drugą blokadę. Jeżeli adres jest jednocześnie zablokowany w pliku robots.txt, robot nie pobierze podstrony i nie dowie się, że noindex zniknął. Zasady działania tego pliku opisałem we wpisie o tym, jak ustawić plik robots.txt.
Jak zastąpić w mapie adresy z przekierowaniem adresami docelowymi?
Przy przekierowaniach zasada jest prosta: w mapie ma się znaleźć adres, na którym użytkownik ostatecznie ląduje, zapisany dokładnie w takiej postaci, w jakiej odpowiada kodem 200. Adres pośredni z mapy znika.
W systemach, które same tworzą mapę, przekierowany adres zwykle wypada z niej automatycznie, ponieważ stara podstrona przestaje istnieć jako opublikowana treść. Jeżeli mimo to pozostaje, oznacza to najczęściej, że stara podstrona nadal jest opublikowana, a przekierowanie zostało nałożone osobno, na przykład w pliku .htaccess lub we wtyczce do przekierowań. Wtedy trzeba zdecydować, czy starą podstronę usunąć lub przenieść do szkiców.
Różnice w protokole, www i ukośniku
Gdy cała mapa zawiera adresy z http albo w niewłaściwej wersji www, przyczyną jest adres serwisu zapisany w ustawieniach systemu. W WordPressie sprawdza się go w sekcji „Ustawienia”, w zakładce „Ogólne”, w polach „Adres WordPressa (URL)” i „Adres witryny (URL)”. Oba powinny mieć postać docelową, czyli tę, pod którą serwis faktycznie się otwiera.
Zmiana tych pól jest ryzykowna. Błędny wpis potrafi odciąć dostęp do panelu i wyłączyć stronę dla odwiedzających. Przed zmianą należy wykonać pełną kopię zapasową i upewnić się, że certyfikat SSL działa dla wpisywanej wersji adresu. Bezpieczniej jest powierzyć tę czynność osobie, która ma dostęp do serwera i potrafi cofnąć zmianę z poziomu bazy danych.
Przekierowania wieloetapowe
Podczas porządków często wychodzi na jaw, że adres z mapy prowadzi do celu przez dwa lub trzy kolejne przekierowania. Poprawienie mapy to jedno, a skrócenie takiej ścieżki to osobne zadanie, które opisałem we wpisie o tym, jak wykryć łańcuch przekierowań i skrócić go do jednego kroku.
Wyjątek na czas przenosin serwisu
Jest jedna sytuacja, w której stare, przekierowane adresy w mapie mają uzasadnienie: zmiana domeny lub całej struktury adresów. Pozostawienie na pewien czas mapy ze starymi adresami pomaga Google szybciej odkryć przekierowania. To rozwiązanie tymczasowe. Gdy Google przetworzy przenosiny, starą mapę należy usunąć i pozostawić wyłącznie mapę z nowymi adresami.
Dane dodatkowe i limity mapy
Przy okazji porządków z mapy usuwa się także adresy z parametrami po znaku zapytania, adresy zablokowane w pliku robots.txt oraz strony wymagające logowania. Można też uporządkować dane dodatkowe. Google pomija w mapie wartości priority i changefreq, więc ich ustawianie nie przynosi efektu. Wartość lastmod jest brana pod uwagę tylko wtedy, gdy jest wiarygodna, czyli odpowiada dacie ostatniej istotnej zmiany treści. Data zmieniana automatycznie przy każdym wygenerowaniu mapy uczy wyszukiwarkę, że tej informacji nie należy ufać.
Trzeba też znać limity. Jedna mapa może zawierać najwyżej 50 000 adresów i mieć najwyżej 50 MB po rozpakowaniu. Większy serwis dzieli mapę na kilka plików i łączy je indeksem map. Adresy w mapie muszą być pełne, z protokołem i domeną, a plik zapisany w kodowaniu UTF-8.
Jak przesłać oczyszczoną mapę i usunąć stare mapy z Search Console?
Google odczytuje przesłaną mapę ponownie bez żadnej prośby, we własnym rytmie. Po większych porządkach można jednak przesłać ją jeszcze raz, żeby szybciej zobaczyć nową liczbę wykrytych stron i mieć datę odniesienia.
- Najpierw otwiera się mapę w przeglądarce i sprawdza kilka adresów, które miały z niej zniknąć. Jeżeli nadal w niej są, trzeba wyczyścić pamięć podręczną serwisu i odświeżyć mapę.
- W Search Console należy otworzyć raport „Mapy witryn”.
- W polu „Dodaj nową mapę witryny” wpisuje się adres mapy i klika „Prześlij”.
- Po odczytaniu pliku w kolumnie „Stan” powinna pojawić się wartość „Sukces”, a w kolumnie „Wykryte strony” nowa, mniejsza liczba adresów.
- Jeżeli na liście znajdują się stare mapy, należy kliknąć taką mapę, na stronie szczegółów otworzyć menu z trzema kropkami i wskazać „Usuń mapę witryny”.
Usunięcie mapy z raportu nie wystarcza. Dokumentacja Google zaznacza, że nie sprawia ono, iż Google zapomina o mapie i jej adresach. Jeżeli stary plik nadal istnieje na serwerze, robot może dalej go odczytywać. Stary plik trzeba więc usunąć z serwera, tak aby jego adres zwracał błąd 404.
Ostatnim miejscem do sprawdzenia jest plik robots.txt. Powinien wskazywać wyłącznie aktualną mapę, w wierszu o takiej postaci:
Sitemap: https://example.pl/sitemap.xml
Wiersze prowadzące do starych map należy z pliku wykreślić. Warto wiedzieć, że mapy odkryte przez Google wyłącznie dzięki plikowi robots.txt nie są pokazywane w raporcie „Mapy witryn”, choć ich adresy liczą się w filtrze „Wszystkie przesłane strony”. To częste wyjaśnienie zagadki, skąd w raporcie biorą się adresy, których nie ma w żadnej widocznej mapie.
Po czym poznać, że porządki zadziałały, i ile to trwa?
Efekt widać w tym samym miejscu, w którym zaczęła się diagnoza. W raporcie „Indeksowanie stron”, przy filtrze „Wszystkie przesłane strony”, liczby w wierszach „URL zawiera tag „noindex”” i „Strona zawierająca przekierowanie” powinny stopniowo maleć. Stopniowo, ponieważ Google aktualizuje dane dopiero wtedy, gdy ponownie odwiedzi dany adres.
Spadek nie nastąpi z dnia na dzień także z innego powodu. Google zapamiętuje informacje z wcześniejszych odczytów mapy i późniejszy odczyt nie powoduje, że o nich zapomina. Adres usunięty z mapy może więc przez pewien czas nadal być liczony jako przesłany.
Kiedy użyć przycisku „Sprawdź poprawkę”?
Przycisk znajduje się na stronie szczegółów danego problemu. Służy do poinformowania Google, że problem został usunięty we wszystkich wystąpieniach. Ma sens wtedy, gdy noindex został zdjęty z podstron, które powinny być w Google. Weryfikacja trwa zazwyczaj do 2 tygodni, czasem znacznie dłużej, a o wyniku Google informuje wiadomością e-mail.
Nie ma sensu uruchamiać weryfikacji dla podstron, które celowo zachowały noindex i jedynie zostały usunięte z mapy. Zakaz nadal na nich jest, więc weryfikacja zakończy się niepowodzeniem już na pierwszym takim adresie. W tym przypadku wystarczy poczekać, aż liczby w raporcie spadną same.
Trzeba też uważać na filtr. Jeżeli raport jest zawężony do konkretnej mapy, weryfikacja obejmie tylko adresy z tej mapy według stanu z chwili kliknięcia. Przycisku nie należy klikać ponownie, dopóki trwająca weryfikacja się nie zakończy.
Co zrobić, gdy liczby w raporcie nie spadają?
Jeżeli po kilku tygodniach raport wygląda tak samo, przyczynę da się zwykle znaleźć w jednym z poniższych miejsc.
- Mapa nadal zawiera stare adresy, bo serwer lub sieć dostarczania treści podaje jej zapamiętaną kopię. Należy otworzyć mapę w oknie prywatnym przeglądarki i porównać z oczekiwaną zawartością.
- Istnieje druga mapa, o której nikt nie pamięta: stary plik na serwerze, mapa systemowa albo wpis w robots.txt.
- W raporcie „Mapy witryn” kolumna „Ostatni odczyt” pokazuje dawny termin. Google jeszcze nie pobrał nowej wersji i trzeba przesłać mapę ponownie.
- Stan mapy to „Nie udało się pobrać” albo „Zawiera błędy”. Kliknięcie mapy otwiera stronę z opisem błędu, który trzeba usunąć w pierwszej kolejności.
- Oglądana jest niewłaściwa usługa. Mapy przypisane do wersji z http lub bez www nie są widoczne w usłudze dla https z www i odwrotnie.
Jeżeli żadna z tych przyczyn nie zachodzi, należy sprawdzić pojedynczy oporny adres w narzędziu do sprawdzania adresów URL. Pozycja opisująca mapy witryn pokaże, w której mapie Google ten adres znalazł. To najszybsza droga do odkrycia zapomnianego pliku.
Jakich błędów unikać podczas czyszczenia mapy?
Najpoważniejszym błędem jest zdejmowanie noindex ze wszystkich zgłoszonych adresów tylko po to, żeby raport wyglądał czyściej. Strony koszyka, wyniki wewnętrznej wyszukiwarki czy ubogie w treść archiwa nie powinny trafiać do Google. Raport ma odzwierciedlać dobrze ustawiony serwis, a nie być celem samym w sobie.
Drugim błędem jest blokowanie w pliku robots.txt adresów, które mają noindex. Robot, który nie może pobrać podstrony, nie odczyta zakazu indeksowania, a adres może mimo wszystko pojawić się w wynikach bez opisu. Dokumentacja Google wprost zaleca, żeby do zapobiegania indeksowaniu używać noindex, a nie blokady w robots.txt.
Trzecim błędem jest próba usuwania adresów narzędziem „Usunięcia” w Search Console. To narzędzie tymczasowo ukrywa adres w wynikach wyszukiwania i nie ma nic wspólnego z zawartością mapy. Użyte nieostrożnie potrafi ukryć podstrony, które powinny być widoczne.
Radzę też nie traktować porządków jako czynności jednorazowej. Po każdej większej zmianie w serwisie, czyli po usunięciu grupy podstron, zmianie adresów albo wymianie wtyczki, przegląd raportu z filtrem „Wszystkie przesłane strony” zajmuje kilka minut i pozwala wychwycić nowe rozbieżności, zanim urosną.
Najczęstsze pytania
Czy adresy z noindex w mapie witryny obniżają pozycje strony w Google?
Google nie opisuje takiej sytuacji jako podstawy do obniżenia pozycji. Jest to sprzeczny sygnał i strata odwiedzin robota, która w dużych serwisach może opóźniać odkrywanie nowych treści. Większym ryzykiem jest to, że wśród takich adresów ukrywa się ważna podstrona z noindex ustawionym przez pomyłkę.
Czy po usunięciu adresu z mapy Google usunie go też z indeksu?
Nie. Mapa jest wskazówką, co warto odwiedzić, a nie listą dozwolonych adresów. Podstrona usunięta z mapy pozostanie w wynikach, jeśli jest dostępna i nie ma zakazu indeksowania. Do usunięcia z wyników służy dyrektywa noindex albo usunięcie samej podstrony.
Jak często Google odczytuje mapę witryny?
Google próbuje pobrać mapę zaraz po jej przesłaniu, a potem wraca do niej we własnym tempie, niezależnym od rytmu odwiedzin samych podstron. Termin ostatniego pobrania pokazuje kolumna „Ostatni odczyt” w raporcie „Mapy witryn”.
Czy trzeba ponownie przesyłać mapę po każdej zmianie w serwisie?
Nie ma takiej potrzeby. Mapa tworzona automatycznie aktualizuje się sama, a Google odczytuje ją cyklicznie. Ponowne przesłanie ma sens po dużych porządkach, po zmianie adresu mapy albo wtedy, gdy wcześniejsze próby pobrania kończyły się niepowodzeniem.
Dlaczego raport pokazuje adresy, których nie ma już w mapie?
Najczęściej dlatego, że Google pamięta wcześniejsze odczyty mapy albo zna drugą mapę, wskazaną w pliku robots.txt lub pozostawioną na serwerze. Trzeba też pamiętać, że adres jest uznawany za przesłany nawet wtedy, gdy Google odkrył go również inną drogą.
Czy mała strona firmowa w ogóle potrzebuje mapy witryny?
Według dokumentacji Google mały serwis, liczący do 500 stron i dobrze połączony linkami od strony głównej, zwykle poradzi sobie bez mapy. Uważam jednak, że poprawna mapa jest przydatna także w małym serwisie, ponieważ pozwala filtrować raport „Indeksowanie stron” i szybko wychwytywać podstrony, które wypadły z indeksu.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
Porządkowanie mapy witryny wymaga cierpliwości i porównywania kilku źródeł naraz, a nie każdy ma na to przestrzeń obok prowadzenia firmy. Mogę wykonać tę pracę w całości: pobiorę dane z Search Console, ustalę, skąd w mapie biorą się adresy z noindex i przekierowaniami, oddzielę podstrony ukryte celowo od ukrytych przez pomyłkę, poprawię ustawienia mapy, usunę stare pliki i zgłoszę poprawki do Google. Na koniec przekażę krótkie podsumowanie tego, co zostało zmienione i jak samodzielnie kontrolować stan mapy w przyszłości.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widzę w mapie i od czego należałoby zacząć.
