IndexChecker – sprawdzanie i monitorowanie stanu indeksacji w sklepach internetowych

Na wstępie wielu z Was zapyta, po co w ogóle sprawdzać zaindeksowanie. Klasyczni link builderzy mają na to gotową odpowiedź – aby zobaczyć, czy podstrona, na której umieścili backlink znajduje się w indeksie Google, a seowcy, którzy patrzą na SEO z szerszej perspektywy jaką odpowiedź podadzą? Odpowiedź znajdziesz w tym artykule. W niniejszej prezentacji omówię nowość na rynku oprogramowania serwerowego – narzędzie o nazwie IndexChecker, którego autorem jest Adam Piersa.

Narzędzie IndexChecker pojawiło się na rynku niespełna 3 tygodnie temu. Wielu z Was może powiedzieć, że tego typu narzędzie nie zrobi furory, jednak patrząc przez pryzmat swojego doświadczenia oraz po zapoznaniu się z funkcjonalnością narzędzia mam zupełnie inne zdanie.

Dlaczego sprawdzanie indeksacji w sklepach internetowych jest takie ważne?

Grubo ponad rok temu Google wypuściło fajną aktualizację algorytmu związaną z „Quality Update”, która z początku wydała się niepozorna i niegroźna, jednak z perspektywy kolejnych kilku miesięcy (najprawdopodobniej za sprawą wdrażanych poprawek do owej aktualizacji), dla części sklepów internetowych miała fatalne skutki. Właściciele, którzy monitorowali swoje strony i ruch z Google wiedzieli, że coś jest nie tak i reagowali konsultując się ze specjalistami w dziedzinie zdejmowania filtrów, z kolei właściciele e-sklepów, którzy nie interesowali się tymi sprawami, cóż… pewnie zainwestowali większą kasę w AdWords i Facebook Ads (bez uszczypliwości, po prostu inwestowanie w alternatywne kanały pozyskiwania klientów to naturalny odruch przy spadku sprzedaży).

Zapewne zastanawiasz się co było powodem spadków i dlaczego Twój sklep oberwał, a kolegi już nie – przynajmniej na pierwszy rzut oka. Powodem utraty ruchu w sklepach było… wyindeksowanie niektórych podstron kategorii, podstron produktowych oraz innych, na których nie było opisów lub były to opisy zapożyczone od producentów, bądź powielone w dziesiątkach na inne portale/sklepy (off-site duplicates). Mówiąc dosadnie, podstrony które dotychczas generowały ruch zostały wykopane z Google i nie miał kto generować tego ruchu.

Dobra, to dlaczego sąsiadowi nie spadło, a u Ciebie jak walnęło, to aż zatrzęsła się ziemia?

Analizy które przeprowadziłem dość jasno wskazały przyczynę – nieregularność, znaczy to, że Google tego celowo nie robiło w stylu – dobra weźmiemy wywalimy im po 10 podstron generujących ruch, przyjdą do nas i zareklamują się w AdWords. Tak nie było! U jednego poleciały podstrony, które miały dużo wyświetleń, ale mało przeklików, u innego wyleciały 2 czołowe podstrony kategorii generujące ruch, u kolejnego poleciały podstrony produktowe. Niestety miałem ograniczoną próbkę danych, aby dokładnie określić korelacje spadków, ale zebrane doświadczenie doprowadziło mnie do ważnej konkluzji – że sprawdzanie indeksacji w sklepach internetowych powinno być wykonywane cyklicznie, może nie aż tak często jak sprawdzanie pozycji czy monitorowanie ruchu, ale przynajmniej raz w miesiącu powinno zostać sprawdzone, szczególnie dla podstron, które w ujęciu historycznym generowały największy ruch w sklepie.

Wyłapywanie 404-ek w sklepie za pomocą IndexCheckera

Na pewno każdemu z Was zdarzyła się sytuacja, w której pozycjonowaliście podstronę w sklepie na konkretne frazy, wypozycjonowaliście ją, podstrona generowała super ruch, a tu nagle klient postanawia ową podstronę usunąć i stworzyć nową, z tym samym produktem ale z innym adresem URL (konkretnie mówię o zmianie ID w URLu). Gdyby zmienił URL istniejącego produktu, to jeszcze pół biedy, bo wiele skryptów potrafi automatycznie zrobić przekierowanie na nowy URL, ale gdy usunie produkt (podstronę) i stworzy w jego miejsce nowy landing, identyczny (opis, słowa kluczowe, cechy produktu, cena) – dochodzi do spadków ruchu. Dlaczego?

Adres URL jest prawie taki sam, zmienia się jedynie ID podstrony, ale to w zupełności wystarczy do wygenerowania 404-ki, a skrypt nie ma jak ogarnąć przekierowania, bo to dla niego nowa podstrona „bez pamięci”. Klient w natłoku pracy zapomni o manualnym przekierowaniu 301, a też często wdrożenie przekierowania jest utrudnione przez samą obsługę platformy e-commerce… i problem gotowy – z czasem następuje wyindeksowanie starej podstrony, która generowała spory ruch w sklepie, z kolei nowa nie jest w stanie szybko wspiąć się na szczyty rankingu, ze względu na brak przekierowania 301.

Podstrona zwracająca 404 potrafi bardzo szybko wylecieć z indeksu. To kolejny powód do cyklicznego sprawdzania indeksacji w sklepie. Niestety klienci są różni, jedni stosują się do zaleceń, inni niestety nie, jako specjaliści musimy stale monitorować poczynania klienta, w przeciwnym wypadku kiedyś może on do nas zapukać i obarczyć winą za sytuację, którą tak w rzeczywistości sam sprokurował. Zarówno w naszym interesie (specjalistów SEO), jak i w interesie naszego klienta jest cykliczne monitorowanie indeksacji w sklepie internetowym – tutaj do gry wkracza wspomniany IndexChecker.

IndexChecker – proces instalacji

Procesu przedwstępnego nie będę dokładnie opisywał, tematem podpinania domen i stawiania stron zajmiemy się w innym artykule. Aby postawić IndexCheckera rejestrujemy domenę internetową, następnie konfigurujemy DNS-y (o ile domena została zarejestrowana u innego dostawcy niż mamy hosting). U niektórych dostawców propagacja DNS-ów może potrwać nawet 24h!

Podpinamy domenę na hostingu, na serwerze automatycznie zostanie utworzony katalog domeny, logujemy się na serwer FTP, przechodzimy do katalogu domeny, wchodzimy najczęściej do public_html (alternatywnie – www, htdocs) i kopiujemy pliki IndexCheckera na serwer.

Do instalacji potrzebna nam jeszcze baza danych, więc korzystając z opcji dostępnych w panelu administracyjnym hostingu, utwórz nową bazę danych, zapisz następujące informacje: nazwę bazy danych, host (zazwyczaj localhost), nazwę użytkownika bazy danych oraz hasło.

Aby ruszyć z instalacją usuwamy jeszcze z serwera plik config.php i w pasku adresu przeglądarki wpisujemy adres: http://domena.pl/install.php

W pierwszym oknie kreatora instalacji podaj dane bazy danych SQL, którą wcześniej stworzyłeś i kliknij „Instaluj”.

Otrzymasz informację: Plik config.php został skonfigurowany prawidłowo. Po kliknięciu „Dalej” pojawi się info: Baza danych została wgrana prawidłowo, kliknij „Dalej” i w tym momencie zakończyłeś proces instalacji.

Usuń teraz z serwera plik install.php, następnie przejdź do strony logowania podając dane domyślne, login: admin, hasło: admin. Gdyby coś w przyszłości zmieniło się i hasło nie wchodziło, przed kontynuowaniem zerknij do pliku pomocy narzędzia.

Aby aplikacja robiła swoje, musisz jeszcze dodać do crona odpowiednie wpisy, szczegóły znajdują się w załączonej do aplikacji dokumentacji. Poniżej przykładowy zrzut ekranu z wpisami…

Aby rozpocząć sprawdzanie indeksacji wpierw dodaj grupę (nowy projekt).

Następnie musisz skonfigurować proxy, przejdź do sekcji „Proxy API” i dodaj adres URL serwisu udostępniającego świeże proxy.

Narzędzie testowałem ze swoim prywatnym API oraz na proxy, z serwisu ProxyLive. Dodając proxy ustaw czas rotacji, dla ProxyLive jest to 2 minuty. Oczywiście możesz ustawić 5, 10 minut – to już od Ciebie zależy, jednak w tym systemie rotacja następuje przeciętnie co 120 sekund – mowa o pakietach proxy pod Google.

Kolejnym krokiem jest dodanie adresów URL do sprawdzenia, w tym celu przejdź do sekcji „Dodaj listę” i wybierz plik z adresami URL lub wklej wszystkie w dostępnym polu tekstowym, przypisz również do listy grupę, po czym kliknij „Dodaj”.

W sekcji „Start” pojawi się grupa, którą dodałeś oraz informacja z postępem sprawdzania. Znajdziesz tam również opcje do pobrania plików z zaindeksowanymi/niezaindeksowanymi/wszystkimi adresami URL. Formaty zapisu na tę chwilę to CSV i TXT.

W tej sekcji ciekawą rzeczą jest historia sprawdzania, dzięki której możesz prześledzić jak kształtowało się zaindeksowanie na przestrzeni czasu, szkoda tylko, że to są same statystyki liczbowe, bez konkretów która podstrona wyleciała.

Historia sprawdzania znajduje się pod przyciskiem pobierz (ikonka wykresu). Na ekranie „Start” znajdziesz również opcje do ponownego sprawdzenia poziomu zaindeksowania dla wybranego projektu/grupy oraz możliwość dodania kolejnych adresów URL.

Poniżej zrzut ekranu ze szczegółami sprawdzania. Ekran dostępny w podglądzie konkretnej listy.

Harmonogram – sprawdzanie indeksacji co X dni

Narzędzie posiada bardzo fajną funkcję, która pomaga cyklicznie sprawdzać zaindeksowanie wybranej grupy adresów URL. W sekcji „Harmonogram” możesz określić, która lista, co ile dni będzie sprawdzana.

W wersji 2.0 IndexCheckera dodano również zakładkę „Ustawienia”, w której to możesz określić po ilu błędach dane proxy zostanie usunięte z listy oraz ile razy skrypt ma wykonać zapytań do wyszukiwarki w ciągu minuty. Czym mniej proxy masz, tym mniejszą wartość musisz ustawić w polu „Ilość sprawdzeń na minutę”.

Skuteczność sprawdzania indeksacji

Po przeprowadzonych testach skuteczność sprawdzania zaindeksowania jest na poziomie 98% (w wersji 2.01 dla przyjaznych adresów URL). Nie wiem z czego to wynika, czy z proxy – jeżeli w kolejnych próbach nie udało się wysłać zapytania przez proxy, to skrypt raportuje niezaindeksowanie, czy też wynika to z innych problemów. Myślę, że przy błędzie sprawdzania operatorem site powinien zostać dodany dodatkowy: info, inurl, który pozwoli dokładniej zweryfikować indeksację. Opcje powinny być dostępne w Ustawieniach, tak aby użytkownik sam mógł zdecydować, czy chce angażować dodatkowe zasoby w re-weryfikację indeksacji.

Podsumowanie

Stabilność – podczas 3 tygodni użytkowania nie zauważyłem większych problemów z działaniem.

Użyteczność – aplikacja, aby była w pełni użyteczna wymaga kilku poprawek – między innymi historia sprawdzania, która moim zdaniem powinna informować o konkretnych adresach URL, które wyleciały z indeksu na przestrzeni czasu, powiadomienia mailowe – aby nie trzeba było ciągle logować się do panelu, poprawki związane z zarządzaniem proxy oraz kilka innych dotyczących już samego sposobu sprawdzania zaindeksowania.

Wygląd – interfejs przyjemny dla oka, ale wymaga paru drobnych poprawek, na przykład takie niepozorne przyciski powrotu do poprzedniego ekranu. Na urządzeniach mobilnych ekran ze szczegółowymi wynikami jest przycinany, na urządzeniach z niską rozdzielczością ekranu wygląda to kiepsko, ale na tabletach już jest okej.

Cena – adekwatna do aktualnie oferowanych funkcjonalności.

Każdej ocenianej aplikacji przyznaję punktację od 0 do 100 w poszczególnych kategoriach. Poniżej moja subiektywna ocena dla IndexChecker w wersji 2.01

Gdzie można kupić aplikację IndexChecker?

Aplikacja dostępna jest na stronie autora…

Przejdź do sklepu