W raporcie indeksowania w Google Search Console pojawia się wiersz „Strona wykluczona za pomocą tagu noindex”, a obok niego liczba adresów. Dla właściciela firmy oznacza to jedno: tych podstron nie ma w wynikach wyszukiwania i nie będzie ich tam tak długo, jak długo strona sama prosi Google o pominięcie. Kłopot polega na tym, że raport mówi, co się stało, ale nie mówi, gdzie dokładnie ta prośba została zapisana.
Blokada noindex może znajdować się w kilku zupełnie różnych miejscach: w ustawieniach systemu zarządzania treścią, we wtyczce SEO, w szablonie, w konfiguracji serwera, w usłudze pośredniczącej albo w skrypcie, który działa dopiero w przeglądarce. Szukanie na ślepo zabiera godziny. Szukanie w ustalonej kolejności zajmuje zwykle kilkanaście minut.
Ta instrukcja jest przeznaczona dla osób, które prowadzą stronę firmową lub sklep i chcą samodzielnie ustalić, skąd pochodzi blokada. Po lekturze czytelnik będzie umiał odróżnić blokadę zamierzoną od przypadkowej, wskazać jej źródło, usunąć ją w bezpieczny sposób i potwierdzić w Search Console, że Google widzi już stronę bez przeszkód.
Co oznacza stan „Strona wykluczona za pomocą tagu noindex”?
Noindex to reguła, którą strona przekazuje wyszukiwarce. Jej treść jest prosta: tego adresu nie należy pokazywać w wynikach. Google stosuje się do niej w pełni. Według dokumentacji robot, który odczyta taką regułę, usuwa stronę z wyników wyszukiwania niezależnie od tego, ile linków do niej prowadzi z innych witryn.
Stan w raporcie oznacza więc, że Google odwiedził adres, pobrał go bez przeszkód i znalazł w nim regułę noindex. Nie jest to awaria po stronie wyszukiwarki ani kara. Kolumna „Źródło” pokazuje przy tym wierszu wartość „Witryna”, co według opisu raportu oznacza problem, który właściciel może rozwiązać sam.
W pomocy Search Console ten sam stan bywa opisany pod nazwą „URL zawiera tag noindex”. Chodzi o to samo zjawisko, a różnica wynika wyłącznie z tłumaczenia. Opis Google jest krótki: przy próbie zindeksowania strony wyszukiwarka napotkała dyrektywę noindex i nie wykonała indeksowania.
Dwie postacie tej samej reguły
Dokumentacja Google wymienia dwa sposoby przekazania reguły i oba dają taki sam skutek. Pierwszy to znacznik w kodzie strony, umieszczony w sekcji head: <meta name="robots" content="noindex">. Drugi to nagłówek odpowiedzi serwera: X-Robots-Tag: noindex. Znacznik widać w źródle strony, nagłówka w źródle nie ma wcale, bo serwer wysyła go obok treści.
Ta różnica wyjaśnia najczęstsze nieporozumienie. Właściciel przegląda kod strony, nie znajduje słowa noindex i uznaje, że raport się myli. Tymczasem reguła jest wysyłana w nagłówku, czyli w miejscu, do którego trzeba zajrzeć innym narzędziem.
Istnieją też odmiany, które łatwo przeoczyć. Znacznik z nazwą googlebot zamiast robots dotyczy wyłącznie robotów Google. Wartość none działa jak połączenie noindex z nofollow. Wielkość liter nie ma znaczenia, więc zapis NOINDEX działa tak samo.
Kiedy ten stan jest prawidłowy, a kiedy oznacza stratę?
Sam wiersz w raporcie nie jest powodem do niepokoju. Google pisze wprost: jeśli strona miała nie być indeksowana, cel został osiągnięty. Wiele podstron powinno pozostać poza wynikami wyszukiwania i ich obecność w tym wierszu świadczy o porządku w serwisie.
Blokada jest zwykle zamierzona w następujących przypadkach:
- koszyk, strona zamówienia i konto klienta w sklepie internetowym,
- wyniki wewnętrznej wyszukiwarki serwisu,
- strony z podziękowaniem po wysłaniu formularza,
- archiwa dat, autorów lub tagów, jeśli tak zdecydowano w ustawieniach wtyczki SEO,
- strony logowania, regulaminy techniczne i materiały przeznaczone tylko dla osób z bezpośrednim linkiem.
Problem zaczyna się wtedy, gdy na liście znajdują się adresy, które mają zarabiać: strona główna, strony usług, kategorie i produkty, wpisy na blogu. Drugi sygnał ostrzegawczy to nagły wzrost liczby adresów na wykresie w tym wierszu, zwłaszcza po zmianie szablonu, aktualizacji wtyczek albo przeniesieniu serwisu.
Radzę zacząć od prostego podziału listy na dwie grupy. Do pierwszej trafiają adresy, których w Google być nie powinno, i nimi nie trzeba się zajmować. Do drugiej trafiają adresy ważne dla sprzedaży i tylko dla nich warto wykonywać dalsze czynności.
Jak znaleźć w Search Console adresy objęte blokadą?
Lista adresów znajduje się w raporcie „Indeksowanie stron”. Raport pokazuje przykłady, a nie zawsze komplet: tabela jest ograniczona do 1000 wierszy. W małym i średnim serwisie to wystarcza, żeby zobaczyć wzór, czyli typ podstron, których dotyczy blokada.
- Po zalogowaniu do Search Console należy wybrać właściwą usługę, a następnie w menu po lewej stronie otworzyć „Indeksowanie”, a potem „Strony”.
- Pod wykresem znajduje się tabela „Dlaczego strony nie są indeksowane”. Trzeba w niej odszukać wiersz „Strona wykluczona za pomocą tagu noindex” i go kliknąć.
- Otwiera się strona ze szczegółami: wykres liczby adresów w czasie oraz tabela z przykładami. Datę skoku na wykresie dobrze jest zestawić z historią zmian w serwisie.
- Przycisk eksportu w prawym górnym rogu pozwala pobrać listę do arkusza. W arkuszu łatwiej posortować adresy i oznaczyć te, które powinny być widoczne w Google.
- Przy wybranym adresie z tabeli należy kliknąć ikonę lupy. Otwiera ona ten adres w narzędziu do sprawdzania adresów URL.
- W wyniku sprawdzania trzeba rozwinąć część dotyczącą indeksowania strony i odczytać wiersz „Czy indeksowanie jest dozwolone”. Wartość zaczyna się od słowa „Nie” i zwykle wskazuje, czy regułę wykryto w metatagu robots, czy w nagłówku HTTP.
Ostatni krok jest najcenniejszy, bo od razu zawęża poszukiwania. Informacja o metatagu kieruje do systemu zarządzania treścią, wtyczek i szablonu. Informacja o nagłówku kieruje do serwera, plików konfiguracyjnych i usług pośredniczących.
Warto też spojrzeć na filtr nad wykresem. Wybranie opcji „Wszystkie przesłane strony” ogranicza raport do adresów zgłoszonych w mapie witryny. Jeśli po takim zawężeniu wiersz z noindex nadal zawiera adresy, serwis wysyła sprzeczne sygnały: w mapie prosi o indeksowanie, a na stronie go zabrania. Takie adresy należy naprawić w pierwszej kolejności albo usunąć je z mapy, jeśli blokada jest zamierzona.
Wersja zapisana i wersja opublikowana to nie to samo
Raport i pierwszy ekran narzędzia do sprawdzania adresów pokazują stan z ostatniej wizyty robota. Jeśli wizyta odbyła się dawno, obraz może być nieaktualny. Dlatego przed szukaniem przyczyny trzeba kliknąć „Sprawdź URL wersji opublikowanej”. Narzędzie pobierze stronę w tej chwili i pokaże, czy reguła noindex nadal jest wykrywana.
Możliwe są dwa wyniki. Jeżeli test na żywo nie wykrywa już blokady, problem został wcześniej usunięty i pozostaje tylko poprosić o ponowne zindeksowanie. Jeżeli blokada nadal jest wykrywana, źródło wciąż działa i trzeba je odnaleźć.
Skąd bierze się noindex? Miejsca, w których powstaje blokada
Reguła noindex nigdy nie pojawia się samoistnie. Zawsze ktoś lub coś ją ustawia: człowiek w panelu, wtyczka zgodnie ze swoimi ustawieniami albo serwer zgodnie z konfiguracją. Z mojej praktyki wynika, że przyczyny układają się w kilka powtarzalnych grup.
Ustawienie całej witryny pozostawione po budowie
Podczas tworzenia strony wykonawca często ukrywa ją przed wyszukiwarkami, żeby niedokończona wersja nie trafiła do wyników. To rozsądne postępowanie, o ile po uruchomieniu serwisu ktoś tę blokadę zdejmie. W WordPressie odpowiada za to jedno pole wyboru w ustawieniach czytania. Objawem jest blokada na wszystkich adresach jednocześnie, łącznie ze stroną główną.
Wtyczka SEO i jej ustawienia dla typów treści
Wtyczki SEO pozwalają wyłączyć z wyników całe grupy adresów: wpisy, strony, produkty, kategorie, tagi, archiwa. Jedno przesunięcie przełącznika obejmuje setki podstron. Objawem jest blokada na adresach jednego rodzaju, na przykład na wszystkich kategoriach sklepu, przy poprawnie działającej reszcie serwisu.
Ustawienie pojedynczej podstrony
Ta sama wtyczka ma zwykle ustawienia zaawansowane w edytorze każdego wpisu i każdej strony. Wystarczy, że ktoś kiedyś zaznaczył tam ukrycie podstrony przed wyszukiwarkami. Objawem są pojedyncze, niepowiązane ze sobą adresy na liście.
Szablon lub własny kod
Znacznik bywa wpisany na stałe w pliku nagłówka szablonu albo dodawany przez fragment kodu w pliku funkcji. Zdarza się to w szablonach pisanych na zamówienie oraz w serwisach, w których kilka wtyczek naraz zarządza tym samym znacznikiem. Objawem jest blokada, której nie widać w żadnym panelu ustawień.
Serwer, pamięć podręczna i usługi pośredniczące
Nagłówek X-Robots-Tag może dodawać plik konfiguracyjny serwera, panel hostingu albo usługa pośrednicząca między serwerem a odwiedzającym. Osobną grupą jest pamięć podręczna, która przechowuje starą wersję strony i podaje ją robotom długo po tym, jak blokadę usunięto w panelu.
Skrypt działający w przeglądarce
Część serwisów buduje stronę za pomocą JavaScriptu i tym samym skryptem zmienia znacznik robots. Dokumentacja Google ostrzega, że po napotkaniu noindex robot może pominąć renderowanie i wykonanie skryptu. Jeśli więc pierwotny kod strony zawiera noindex, a skrypt ma go dopiero usunąć, strona pozostanie poza indeksem.
Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a ja przejmę sprawę: ustalę, w którym miejscu serwisu powstaje reguła noindex, usunę ją z adresów, które mają być widoczne, i zgłoszę poprawkę w Search Console.
Jak ustalić, czy blokada jest w kodzie strony, czy w nagłówku serwera?
Od odpowiedzi na to pytanie zależy cała dalsza praca, dlatego nie należy go pomijać nawet wtedy, gdy przyczyna wydaje się oczywista. Najpewniejszym źródłem jest test na żywo w Search Console, ponieważ pokazuje dokładnie to, co otrzymuje narzędzie Google, a nie to, co widzi zalogowany administrator w swojej przeglądarce.
- W narzędziu do sprawdzania adresów URL należy wkleić pełny adres podstrony w polu u góry ekranu i zatwierdzić klawiszem Enter.
- Po wyświetleniu wyniku trzeba kliknąć „Sprawdź URL wersji opublikowanej” i poczekać na zakończenie testu.
- Następnie należy kliknąć „Wyświetl przetestowaną stronę”. Po prawej stronie otworzy się panel z kartami.
- Na karcie z kodem HTML trzeba wyszukać słowo noindex. Jeśli występuje w znaczniku meta o nazwie robots lub googlebot, blokada znajduje się w kodzie strony.
- Na karcie „Więcej informacji” znajduje się odpowiedź HTTP z nagłówkami. Jeśli wśród nich jest X-Robots-Tag z wartością noindex lub none, blokadę wysyła serwer albo usługa pośrednicząca.
- Wynik należy zapisać dla każdego typu podstron osobno: strony usługi, wpisu, kategorii, produktu. Różne typy mogą mieć różne źródła blokady.
Zdarza się, że noindex występuje w obu miejscach naraz. Wtedy trzeba usunąć oba, bo dokumentacja mówi jasno: przy sprzecznych regułach obowiązuje ta bardziej restrykcyjna. Jeden pozostawiony zapis wystarcza, żeby strona nadal była wykluczona.
Szybka kontrola w przeglądarce
Wstępne rozpoznanie można wykonać bez Search Console. Kombinacja klawiszy Ctrl+U otwiera źródło strony, a Ctrl+F pozwala wyszukać w nim słowo noindex. Nagłówki odpowiedzi pokazują narzędzia deweloperskie przeglądarki, otwierane klawiszem F12: po odświeżeniu strony na karcie z ruchem sieciowym trzeba kliknąć pierwszy wiersz, czyli sam dokument, i przejrzeć nagłówki odpowiedzi.
Ta kontrola ma dwa ograniczenia. Po pierwsze, administrator zalogowany do panelu często otrzymuje inną wersję strony niż robot, bo pamięć podręczna pomija zalogowanych. Najlepiej więc sprawdzać w oknie prywatnym. Po drugie, serwer może wysyłać inne nagłówki robotom, a inne zwykłym odwiedzającym. Dlatego ostateczny głos ma zawsze test wersji opublikowanej w Search Console.
Jak czytać wynik?
Blokada w znaczniku meta na wszystkich adresach wskazuje na ustawienie całej witryny. Blokada w znaczniku meta na jednym typie treści wskazuje na wtyczkę SEO. Blokada w nagłówku wskazuje na serwer. Brak blokady w teście na żywo przy jej obecności w raporcie oznacza, że Google po prostu nie odwiedził jeszcze strony po naprawie.
Jak usunąć blokadę ustawioną w WordPressie?
W serwisach opartych na WordPressie przyczynę znajduje się najczęściej w panelu, bez dotykania plików. Przed zmianami radzę zanotować stan wyjściowy każdego ustawienia. Jeśli po zmianie coś pójdzie nie tak, powrót zajmie chwilę.
- W panelu administracyjnym należy otworzyć „Ustawienia”, a następnie „Czytanie”.
- Na dole ekranu znajduje się pozycja „Widoczność dla wyszukiwarek” z polem „Proś wyszukiwarki o nieindeksowanie tej witryny”. Pole ma pozostać odznaczone.
- Zmianę trzeba potwierdzić przyciskiem „Zapisz zmiany”.
- Następnie należy przejść do ustawień używanej wtyczki SEO i odszukać część poświęconą wyglądowi w wyszukiwarce lub tytułom i metadanym. Dla każdego typu treści i każdej taksonomii trzeba sprawdzić, czy wyświetlanie w wynikach wyszukiwania jest włączone.
- W edytorze konkretnej podstrony należy rozwinąć pole wtyczki SEO, przejść do ustawień zaawansowanych i sprawdzić, czy podstrona nie ma własnego zakazu indeksowania.
- Na koniec trzeba wyczyścić pamięć podręczną we wtyczce, która za nią odpowiada, oraz w panelu hostingu, jeśli hosting ma własny mechanizm.
Nazwy zakładek we wtyczkach SEO zmieniają się między wersjami, dlatego nie podaję ich dosłownie. Zasada pozostaje ta sama w każdej z nich: są ustawienia ogólne dla typów treści oraz ustawienia pojedynczej podstrony, a ustawienie podstrony ma pierwszeństwo przed ogólnym.
Gdy w panelu wszystko wygląda poprawnie
Jeśli ustawienia są prawidłowe, a znacznik nadal jest w kodzie, należy sprawdzić, czy w serwisie nie działają dwie wtyczki SEO jednocześnie. Każda z nich potrafi dodać własny znacznik robots, a przy dwóch sprzecznych Google zastosuje ostrzejszy. Rozwiązaniem jest pozostawienie jednej wtyczki.
Kolejnym miejscem jest szablon. Wyszukanie słowa noindex w plikach motywu, zwłaszcza w pliku nagłówka i w pliku funkcji, pokazuje zapisy dodane ręcznie. Zmian w plikach szablonu nie należy wykonywać na działającej stronie bez kopii zapasowej, bo błąd składni potrafi wyłączyć cały serwis. Bezpieczniejszą drogą jest praca na kopii testowej albo zlecenie poprawki osobie, która szablon przygotowała.
Warto też przejrzeć wtyczki trybu konserwacji, wtyczki członkowskie i wtyczki ograniczające dostęp do treści. Część z nich oznacza chronione podstrony regułą noindex i robi to zgodnie ze swoim przeznaczeniem.
Jak usunąć noindex wysyłany poza kodem strony?
Jeśli test pokazał nagłówek X-Robots-Tag, żadna zmiana w edytorze treści nie pomoże. Trzeba ustalić, który element po drodze między serwerem a odwiedzającym dopisuje nagłówek.
Pliki konfiguracyjne serwera
Na serwerach Apache nagłówek najczęściej pochodzi z pliku .htaccess w katalogu głównym serwisu. Szukany wiersz wygląda zwykle tak:
Header set X-Robots-Tag "noindex, nofollow"Na serwerach NGINX odpowiednik znajduje się w pliku konfiguracyjnym witryny i ma postać:
add_header X-Robots-Tag "noindex";Przed usunięciem wiersza trzeba sprawdzić, czego dotyczy. Jeśli stoi wewnątrz bloku ograniczonego do plików PDF lub grafik, jest to zapis celowy i dotyczy wyłącznie tych plików. Jeśli stoi poza takim blokiem, obejmuje cały serwis i to on jest źródłem blokady. Przed każdą zmianą pliku .htaccess należy pobrać jego kopię na dysk, ponieważ jeden błędny znak powoduje błąd serwera na wszystkich podstronach.
Na wielu hostingach właściciel nie ma dostępu do konfiguracji NGINX. Wtedy właściwą drogą jest zgłoszenie do pomocy technicznej. Treść może być krótka: Proszę o usunięcie nagłówka X-Robots-Tag: noindex z odpowiedzi serwera dla domeny [nazwa domeny] i o informację, w którym pliku konfiguracyjnym był ustawiony.
Panel hostingu, środowisko testowe i usługi pośredniczące
Część firm hostingowych automatycznie dodaje noindex do adresów tymczasowych i środowisk testowych. Po przeniesieniu wersji testowej na domenę docelową blokada potrafi przenieść się razem z nią. Jeśli wykluczenie pojawiło się tuż po zmianie serwera lub domeny, warto przejść całą listę kontrolną z tekstu o tym, jak przeprowadzić migrację strony bez utraty pozycji w Google.
Usługi przyspieszające i chroniące serwis pozwalają dopisywać własne nagłówki do odpowiedzi. Jeśli w konfiguracji serwera nagłówka nie ma, a test nadal go pokazuje, należy przejrzeć w panelu takiej usługi reguły modyfikujące nagłówki odpowiedzi.
Pamięć podręczna, która podaje starą wersję
Po usunięciu blokady w panelu robot może nadal otrzymywać wersję zapisaną wcześniej. Trzeba wyczyścić pamięć podręczną we wszystkich warstwach: we wtyczce, na serwerze i w usłudze pośredniczącej. Dopiero potem ma sens ponowny test wersji opublikowanej.
Skrypty zmieniające znacznik robots
W serwisach opartych na JavaScripcie należy porównać dwie rzeczy: pierwotny kod wysyłany przez serwer oraz kod po wykonaniu skryptów. Zalecenie Google jest jednoznaczne: jeśli strona ma zostać zindeksowana, noindex nie może występować w pierwotnym kodzie. Poprawka polega więc na zmianie tego, co wysyła serwer, a nie na dopisaniu kolejnego skryptu.
Jak zgłosić poprawkę w Search Console i po czym poznać, że zadziałała?
Usunięcie blokady nie zmienia raportu od razu. Google musi ponownie odwiedzić każdy adres, żeby zobaczyć, że reguły już nie ma. Dokumentacja uprzedza, że w zależności od znaczenia strony ponowna wizyta robota może nastąpić nawet po kilku miesiącach. Można ten czas skrócić.
- Dla jednego adresu z każdej naprawionej grupy należy wykonać test „Sprawdź URL wersji opublikowanej” i upewnić się, że w części dotyczącej indeksowania nie ma już informacji o noindex.
- Przy najważniejszych adresach trzeba kliknąć „Poproś o zindeksowanie”. Obowiązuje dzienny limit takich próśb, dlatego warto przeznaczyć je na strony usług, kategorie i stronę główną.
- Następnie należy wrócić do raportu „Indeksowanie stron”, otworzyć wiersz z noindex i kliknąć „Sprawdź poprawkę”.
- Przycisku nie należy klikać ponownie do czasu zakończenia weryfikacji. Postęp pokazuje link „Sprawdź szczegóły” na stronie problemu.
- Po zakończeniu Google wysyła wiadomość e-mail z wynikiem. Według dokumentacji weryfikacja zajmuje zazwyczaj do 2 tygodni, a w niektórych przypadkach znacznie dłużej.
Przed kliknięciem „Sprawdź poprawkę” trzeba zwrócić uwagę na jedną rzecz. Weryfikacja zatrzymuje się, gdy Google znajdzie choć jedno pozostałe wystąpienie problemu. Jeżeli w wierszu są także adresy zablokowane celowo, na przykład koszyk, wynik „Niepowodzenie” jest spodziewany i nie świadczy o błędzie naprawy.
W takiej sytuacji pomaga sposób opisany w pomocy Google. Należy przygotować i przesłać mapę witryny zawierającą wyłącznie ważne adresy, a potem przefiltrować raport według tej mapy i dopiero wtedy uruchomić weryfikację. Obejmie ona tylko adresy z mapy. Sposób przesłania mapy opisałem w tekście o tym, jak przebiega zgłoszenie mapy witryny w Google Search Console.
Oznaki, że naprawa się powiodła
Pierwszą oznaką jest wynik testu na żywo bez informacji o blokadzie. Drugą jest spadek liczby adresów w wierszu z noindex i jednoczesny wzrost liczby stron zindeksowanych na wykresie raportu. Trzecią jest status „Powodzenie” przy adresach na stronie szczegółów weryfikacji.
Obecność konkretnej podstrony w wynikach można potwierdzić samodzielnie. Opis kilku sposobów znajduje się w tekście wyjaśniającym, jak sprawdzić, czy Google zaindeksował stronę. Zniknięcie blokady nie oznacza jeszcze, że strona na pewno trafi do indeksu. Oznacza tylko, że właściciel przestał tego zabraniać, a decyzję podejmuje Google.
Co zrobić, gdy komunikat nie znika mimo poprawki?
Jeśli po kilku tygodniach adresy nadal widnieją w wierszu z noindex, przyczyna leży zwykle w jednym z czterech miejsc. Warto sprawdzić je po kolei, zaczynając od najprostszego.
Pierwsza możliwość: Google nie odwiedził jeszcze strony. Narzędzie do sprawdzania adresów pokazuje datę ostatniego skanowania. Jeśli jest wcześniejsza niż data poprawki, raport pokazuje stan sprzed naprawy i wystarczy poczekać albo poprosić o zindeksowanie.
Druga możliwość: po usunięciu blokady ktoś zablokował adresy w pliku robots.txt. Google nie pobierze wtedy strony, więc nie dowie się, że reguła noindex zniknęła. Dokumentacja podkreśla, że znaczniki i nagłówki są odczytywane wyłącznie podczas skanowania. Zasady działania tego pliku opisuje tekst o tym, jak ustawić plik robots.txt.
Trzecia możliwość: blokada wraca. Dzieje się tak, gdy aktualizacja szablonu przywraca stary plik, gdy wtyczka po aktualizacji odtwarza ustawienia domyślne albo gdy przywrócono kopię zapasową sprzed naprawy. Pomaga powtórzenie testu na żywo co kilka dni przez pierwsze tygodnie.
Czwarta możliwość: naprawiono tylko jedno z dwóch źródeł. Usunięto znacznik, a pozostał nagłówek, albo odwrotnie. Test wersji opublikowanej z przeglądem obu kart, czyli kodu HTML i odpowiedzi HTTP, rozstrzyga tę wątpliwość w kilka minut.
Jakich błędów unikać przy usuwaniu blokady?
Najpoważniejszy błąd to zdejmowanie noindex ze wszystkiego. Strony koszyka, wyników wyszukiwania wewnętrznego i panelu klienta nie powinny trafiać do Google. Ich zindeksowanie wprowadza do wyników zbędne adresy, a czasem ujawnia treści, które miały pozostać niewidoczne.
- Nie należy zastępować noindex blokadą w pliku robots.txt. Google podaje, że taka blokada nie zapobiega indeksowaniu i adres może pojawić się w wynikach bez opisu.
- Nie należy wpisywać reguły noindex do pliku robots.txt. Google takiego zapisu nie obsługuje.
- Nie należy klikać „Sprawdź poprawkę” przed wykonaniem testu na żywo. Nieudana weryfikacja niczego nie psuje, ale odsuwa wynik w czasie.
- Nie należy edytować plików serwera i szablonu bez kopii zapasowej oraz bez dostępu do menedżera plików lub FTP, przez który da się cofnąć zmianę.
- Nie należy uznawać sprawy za zamkniętą po jednej poprawce. Każdy typ podstron wymaga osobnego testu.
Częstym nieporozumieniem jest także mylenie noindex z nofollow. Pierwsza reguła dotyczy obecności strony w wynikach, druga dotyczy linków na tej stronie. Usunięcie samego nofollow nie przywróci strony do Google.
Uważam też, że po każdej większej zmianie w serwisie warto wykonać krótki przegląd kontrolny: nowy szablon, nowa wtyczka SEO, zmiana hostingu i uruchomienie wersji po przebudowie to chwile, w których blokada pojawia się najczęściej. Jeden test na żywo dla strony głównej i jednej strony usługi wystarcza, żeby wykryć problem w dniu jego powstania, a nie po kilku tygodniach spadku ruchu.
Najczęstsze pytania
Czy wiersz z noindex w raporcie zawsze wymaga działania?
Nie. Google wyraźnie zaznacza, że jeśli strona miała nie być indeksowana, cel został osiągnięty. Działanie jest potrzebne tylko wtedy, gdy na liście znajdują się adresy, które powinny być widoczne w wynikach wyszukiwania, albo gdy liczba adresów w tym wierszu rośnie bez znanej przyczyny.
W kodzie strony nie ma słowa noindex, a raport nadal je zgłasza. Dlaczego?
Najczęściej z jednego z dwóch powodów. Reguła może być wysyłana w nagłówku odpowiedzi serwera, którego nie widać w źródle strony, albo raport pokazuje stan z ostatniej wizyty robota, sprzed naprawy. Obie możliwości rozstrzyga test wersji opublikowanej w narzędziu do sprawdzania adresów URL.
Jak długo po usunięciu blokady strona wraca do Google?
Nie ma jednego terminu. Google podaje, że indeksowanie po prośbie trwa zwykle kilka dni, weryfikacja poprawki do 2 tygodni, a ponowna wizyta robota na mniej ważnych stronach może nastąpić po kilku miesiącach. Prośba o zindeksowanie i aktualna mapa witryny skracają oczekiwanie, lecz nie dają gwarancji terminu.
Czy usunięcie noindex gwarantuje zindeksowanie strony?
Nie gwarantuje. Usunięcie blokady sprawia, że strona może zostać zindeksowana, ale o tym, czy trafi do indeksu, decyduje Google na podstawie jakości i unikalności treści. Strona bez blokady może przejść do innego stanu w raporcie, na przykład zeskanowanej, lecz jeszcze niezindeksowanej.
Czy można poprosić o zindeksowanie wielu stron naraz?
Przycisk „Poproś o zindeksowanie” działa dla jednego adresu i ma dzienny limit. Przy większej liczbie stron Google zaleca przesłanie mapy witryny. Mapa powinna zawierać wyłącznie adresy przeznaczone do indeksowania, bez podstron z celową blokadą.
Czy noindex na jednej podstronie szkodzi całemu serwisowi?
Reguła dotyczy wyłącznie adresu, na którym została umieszczona. Pozostałe podstrony są oceniane niezależnie. Szkoda powstaje dopiero wtedy, gdy blokada obejmuje strony, które przyciągają klientów, albo gdy przez błąd w ustawieniach rozszerza się na całą grupę adresów.
Co oznacza status „Inne” przy weryfikacji poprawki?
Według pomocy Search Console taki status otrzymuje adres, który z jakiegoś powodu stał się niedostępny dla Google, na przykład został usunięty albo wymaga logowania. Google uznaje wtedy problem tego adresu za rozwiązany, choć strona nie została zindeksowana. Jeśli adres miał być widoczny w wynikach, trzeba sprawdzić, co obecnie się z nim dzieje.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
To zrozumiałe, bo szukanie jednej linijki w panelach, wtyczkach i plikach serwera nie jest zajęciem, dla którego prowadzi się firmę. Mogę wykonać całość: przejrzę raport indeksowania, oddzielę adresy zablokowane celowo od zablokowanych przez pomyłkę, ustalę, czy reguła pochodzi z kodu strony, czy z serwera, usunę ją we właściwym miejscu i zgłoszę poprawkę w Search Console. Na koniec sprawdzę, czy najważniejsze podstrony wróciły do wyników wyszukiwania.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widzę w raporcie i co należy zrobić w pierwszej kolejności.
