Co robimy

Porządki w indeksie z Search Console

W poradniku:

• dlaczego porządek w indeksie jest tak ważny
• jak wykorzystać Search Console by zlokalizować niechciane podstrony
• jakie możliwości ma nowe Search Console
• dobre praktyki przy porządkach w indeksie

Sytuacja danego serwisu w indeksie to dla mnie jedna z najważniejszych rzeczy, które sprawdzam podczas optymalizacji. W tekście pokazuję przykłady problemów z indeksacją, które można zweryfikować i usunąć co z nowym Search Console stało się dużo prostsze. Temat jest znacznie szerszy i przy każdym serwisie mogą występować inne problemy, ale starałem się przedstawić podstawowe elementy warte weryfikacji.

Dlaczego porządek w indeksie jest ważny?

Kopie, losowe adresy i inne błędy skryptów mogą spowodować, że zrobi się bałagan. Strona, która powinna składać się np. ze 100 podstron ma w indeksie 2000 podstron. Najczęściej są to podstrony o niskiej jakości (kopie, mało/zero treści) co wpływa na ocenę całej strony i ostatecznie może skończyć się nałożeniem kary jakościowej (Panda). Nieraz spotkałem się z sytuacją, że dobre posprzątanie indeksu pomogło wypracować spore wzrosty w ruchu.

Jest też drugi wariant, kiedy podstron w indeksie jest za mało, bo z jakiegoś powodu Google nie chce dodać je do indeksu (niska jakość, problemy ze skryptem, strukturą strony).

Od czego zacząć?

Przede wszystkim od sprawdzenia, czy jest problem i jak jest duży. Przydatna będzie dodana mapa strony. W WordPressie wygeneruje ją nam np. wtyczka Yoast, w innych CMSach trzeba szukać dedykowanego rozwiązania. Kroki są zawsze te same – nasz CMS powinien wygenerować mapę oraz umieścić ją w pliku. Wtedy wystarczy skopiować link do pliku i dodać go w Search Console.

Dzięki dodanej sitemapie wiemy mniej więcej, jak duża jest nasza strona (ile ma podstron). Na bazie tej informacji możemy dokonywać dalszej analizy mającej na celu weryfikację stanu indeksacji.

Ale może od początku.

Jak sprawdzić liczbę podstron w indeksie?

Są w zasadzie trzy sposoby, żeby sprawdzić poziom zaindeksowania, o których mówił ostatnio John:

Jak podkreśla John, określenie dokładnej liczby zaindeksowanych podstron nie jest tak łatwe jakby się wydawało. Jeśli skrypty generują adresy dynamiczne z parametrami to taka liczba podstron może stale się zmieniać. Jest jednak kilka sposobów, by określić mniej lub bardziej dokładnie liczbę zaindeksowanych podstron.

Możemy użyć trzech metod do określenia liczby podstron:

• Komenda site wpisywana w wyszukiwarce
• Stan indeksowania w Search Console
• Sprawdzenie indeksacji na podstawie przesłanej mapy

Komenda site

Bardzo prosta w użyciu, ale daje dość ogólne dane. Jak podkreśla John, nastawiona bardziej na szybkość prezentacji wyników niż dokładność.

Mimo wszystko prosta i szybka metoda, by sprawdzić czy czasem z indeksacją nie dzieje się nic złego. Użycie jest bardzo proste. Niżej przykład dla losowej strony. W polu wyszukiwania wpisujemy komendę site: i adres strony. Jak widać, zaraz nad wynikami mamy liczbę podstron (tutaj około 1080):

Przy okazji dobry przykład, że jednak warto rozważyć prezentację strony na subdomenie www (tak, www to subdomena).

Wiele osób rezygnuje z www, bo wydłuża to adres. Jednak czasem wersja www jest bardzo przydatna, szczególnie jak mamy rozbudowaną stronę o subdomeny. Dzięki temu jesteśmy w stanie sprawdzić stan indeksacji dla głównej wersji strony, z wykluczeniem subdomen.

Przykładowo SS ma subdomenę kariera, dla której łatwo możemy sprawdzić poziom indeksacji:

Dzięki wersji www możemy też sprawdzić poziom indeksacji dla samej strony SS, z wykluczeniem podstrony kariera:

Stan indeksowania w Search Console

To dokładniejsza metoda niż site, choć nadal może pomijać pewne adresy. Zazwyczaj daje jednak dobre rozeznanie w poziomie indeksacji i co ważne w historii zmian w indeksie.

Stan indeksowania na podstawie mapy

Wymaga przesłania mapy w Search Console. Dzięki temu mamy szybki i dokładny podgląd tego co zostało przesłane w mapie, a co zostało zaindeksowane.

Jeśli jest problem z indeksacją to widać go od razu jak na przykładzie niżej:

problemy z indeksacją

Natomiast jak jest w porządku to liczba przesłanych adresów pokrywa się z liczbą tych dodanych do indeksu:

poprawna indeksacja

Nowe Search Console

Jest jeszcze jeden sposób na sprawdzenie stanu indeksacji. Z pomocą przychodzi nowa wersja Search Console. Szerzej o niej w dalszej części. W skrócie, po przesłaniu sitemapy widzimy dokładnie ile przesłanych podstron zostało zaindeksowanych, ale mamy też informacje o podstronach zaindeksowanych, a nie przesłanych w mapie.

Te i inne informacje mogą być pomocne w sprawdzaniu stanu indeksacji i przy robieniu porządków.

Nowe Search Console, nowe możliwości

Tak, nowe Search Console jest jeszcze w mocno rozwojowej fazie, ale już teraz ma informacje związane z indeksem, które mogą nam bardzo pomóc.

Przejście do nowego SC jest bardzo proste. Będąc zalogowanym na starej wersji mamy link w lewym górnym rogu:

Tu interesuje nas najbardziej sekcja Stan indeksu:

Po wybraniu której mamy cztery bloki:

Blok Błąd

Tutaj dostajemy różne błędy takie jak:

• błąd 404
• podstrona zawiera noindex
• podstrona blokowana przez robots.txt
• błędy serwera 5..
• inne

Często zdarza się, że jakaś podstrona jest zgłoszona w sitemapie, ale blokuje ją robots.txt albo ma ustawione noindex. Wtedy dostajemy ostrzeżenie. Taki błąd można zignorować, ew. poprawić sitemapę.

Warto się dokładniej przyjrzeć błędom serwera czy 404. Przeważnie będzie to chwilowy błąd, wyłapany przez crawlera. Są jednak sytuacje, że to pierwszy znak świadczący o większych problemach z hostingiem lub skryptem.

Blok prawidłowe, prawidłowe z ostrzeżeniem

Po wybraniu bloku:

sprawdzamy co jest zaindeksowane. Nazwa Prawidłowe jest nieco myląca. Nie oznacza, że te adresy powinny być w indeksie, bo są prawidłowe. Oznacza jedynie, że prawidłowo zostały zaindeksowane (nie było błędów serwera, instrukcji noindex czy innej blokującej indeksację). Indeksacja przebiegła ok.

Na tym etapie, by ocenić czy rzeczywiście to jest to co chcieliśmy mieć w indeksie, pomocna będzie wspomniana wcześniej mapa strony.

Niżej widać, że coś poszło nie tak. Liczba podstron nieprzesłanych w mapie, a zaindeksowanych jest dużo większa niż podstron zgłoszonych w mapie.

Coś tu tworzy albo kopie albo śmieciowe adresy. Klikamy adresy nieprzesłane i sprawdzamy:

Powyżej fragment, ale przegląd wszystkich adresów pokazał, że skrypt generuje adresy z dopiskiem addtorepository.html i tworzą one wiele kopii i śmieciowych adresów. Trzeba napisać do devów ;).

Najczęściej prawidłowa sytuacja to taka, kiedy mamy:

• dużo adresów zgłoszonych i zaindeksowanych
• mało adresów niezgłoszonych i zaindeksowanych

Zawsze jakieś niezgłoszone w sitemapie, zaindeksowane się znajdą (jak np. stronicownie itp.), ale jednak nie powinno być ich dużo. Jeśli widzimy, że jest ich sporo to trzeba zlokalizować problem.

A jak to wygląda, gdy nie zgłosimy mapy? Ano tak:

Prawie 80,000 adresów, tylko że nie wiadomo, które powinny być przesłane, a które mogą być kopiami. Owszem, przekopując się przez przykłady może się znajdzie potencjalne problemy, ale to nie jest zalecane działanie. Prawidłowo:

• zgłaszamy mapę
• sprawdzamy czy mapa prawidłowo się indeksuje
• sprawdzamy co poza mapą trafia jeszcze do indeksu

Blok wykluczone

O ile w sekcji Prawidłowe wszystko było dość przejrzyste, bo sprawdzaliśmy co nie jest w mapie a jest zaindeksowane, o tyle w wykluczonych sprawy się nieco komplikują.

Przejdźmy na wykluczone:

Przede wszystkim jest dużo różnych powodów, dlaczego dane adresy zostały wykluczone z indeksacji. Poniżej tylko część możliwych powodów:

Pod kątem ważności można podzielić stany na dwie grupy:

• grupy adresów wymagające tylko pobieżnego sprawdzenia
• grupy adresów wymagające większej uwagi

Grupy adresów wymagające tylko pobieżnego sprawdzenia

Tutaj mowa o grupach adresów jak:

• Podstrony zawierające tag kanoniczny
• Wykluczone z pomocą noindex
• Podstrony zawierające przekierowanie
• Strona zablokowana przez plik robots.txtWykluczone z pomocą noindex

Czyli mowa o całej grupie adresów, gdzie podjęliśmy świadome działanie mające na celu wykluczenie ich z indeksacji czy to przez noindex czy inne działanie (choć zawsze preferuję noindex). Tu wystarczy przejść do przykładów adresów i sprawdzić czy tagi kanoniczne czy przekierowania działają dokładnie tak jak to było założone.

Grupy adresów wymagające większej uwagi

Mowa tu o grupach adresów, które powinny budzić większe podejrzenie, że coś jest nie tak. Przykładowo:

• Nie znaleziono – 404
• Duplikat strony, który nie zawiera tagu kanonicznego
• Pobrano, ale jeszcze nie zaindeksowano
• Nieprawidłowość związana z indeksowaniem
• Wyszukiwarka wybrała inna stronę kanoniczną niż użytkownik

Nie będę rozwijał każdego z tych przypadków. Trzeba wejść i dokładniej przeanalizować większą pulę adresów. Najczęściej będzie to fałszywy alarm – na przykład strony 404 to będą strony rzeczywiście usunięte (np. wycofanych produktów). Czasem jednak natrafimy na większe problemy jak choćby duplikaty strony. Świetne w nowej wersji jest właśnie to grupowanie według problemów. Kawa na ławę – tu jest duplikat bez ustawionego canonicala, tu wyszukiwarka wybrała inną podstronę niż wskazany canonical.

W codziennej pracy seowca jest to naprawdę duże ułatwienie.

Czy to tylko przydatne ułatwienia dla pozycjonerów?

Zdecydowanie nie. Sposób prezentacji grup adresów, nazewnictwo, przykłady – wszystko to od razu pozwala stwierdzić, gdzie może być potencjalny problem. Nie jest to idealne. Wiele rzeczy trzeba weryfikować, jak choćby wspomniane komunikaty o błędach czy wykluczone adresy. Na pewno jednak jest to duże ułatwienie przy analizie tego co jest w indeksie a co nie. Wiele osób, które mają nawet podstawowe pojęcie o SEO jest w stanie zauważyć potencjalny problem i odpowiednio zareagować prosząc np. o pomoc web developera albo specjalistę SEO.

Porozmawiajmy

Powiedz nam czego potrzebujesz

Kontakt