6

DeepCrawl – rozwiązanie chałupnicze w cenie enterprise

Recenzja narzędzia DeepCrawl

Zastosowanie: audyty SEO  serwisów internetowych

Zalety

  • Łatwe w obsłudze raporty
  • Opcja audytów powtarzanych wg harmonogramu
  • Tryb "ukryty", z losowymi IP i nagłówkami przeglądarki

Wady

  • Bardzo niska wydajność przetwarzania danych
  • Niskie limity w stosunku do ceny
  • Brak obsługi wielu kont użytkowników
  • Brak możliwości wykrycia problemów z testem przed jego zakończeniem.

Podsumowanie: DeepCrawl jest to aplikacja, działająca w chmurze, za pomocą której możemy przeprowadzić audyt techniczny serwisu internetowego. DeepCrawl potrafi przejść po wskazanym serwisie w podobny sposób jak robią to roboty wyszukiwarek, zbierając jednocześnie szereg informacji, które potem przekształcane są do postaci zbiorczych raportów.

DeepCrawl oferowany jest jako rozwiązanie klasy enterprise, ale nasze testy wykazały liczne niedociągnięcia, które sprawiają, że nie możemy polecić tego rozwiązania w cenie, której oczekuje producent.

W cenie od 60 EUR / 80 USD miesięcznie

DeepCrawl sprawdza podstawowe parametry wszystkich analizowanych stron, takie jak użyte tytuły, nagłówki H1, znaczniki alt przy obrazkach, itd.

Kontroluje też bardziej zaawansowane mechanizmy, np. przekierowania, linki kanoniczne, łączenie podstron paginacji znacznikami prev i next czy blokowanie indeksacji w robots.txt.

Większość osób parających się audytami SEO na pewno zna desktopowe aplikacje, które służą do podobnych zadań. Powszechnie uważa się dziś, że najlepszą z nich jest Screaming Frog i to właśnie ten program będzie dla nas punktem odniesienia przy ocenie zalet i wad usługi DeepCrawl.

Dla kogo jest DeepCrawl?

DeepCrawl jest sprzedawany jako narzędzie do kompleksowych audytów, w szczególności z myślą o bardzo dużych serwisach, które mogą sprawiać problemy aplikacjom desktopowym.

dc_raport

Właśnie ta cecha skłoniła nas do przetestowania tego rozwiązania. Pracujemy głównie z dużymi sklepami internetowymi, które mają rozbudowane serwisy. Liczba podstron w sitemapie często liczona jest w dziesiątkach tysięcy, a czasami w setkach tysięcy. Każde rozwiązanie, które mogłoby ułatwić audytowanie takich serwisów, potencjalnie ma dla nas bardzo dużą wartość.

Niewątpliwą zaletą DeepCrawl jest fakt, że narzędzie to działa w chmurze i nie obciąża lokalnych zasobów komputera czy sieci. To bez wątpienia wygodne, co potwierdzi każdy, kto na własnym komputerze uruchamiał duży projekt w ScreamingFrogu i próbował w tym samym czasie pracować – w pewnym momencie przestaje to być komfortowe, zakładając, że nasz komputer do pracy w miarę typowa maszyna, wyposażona w 4 czy 8 GB RAM.

Do testów przystąpiliśmy z dużymi nadziejami. Na pierwszy ogień poszły serwisy należące do naszych klientów – dwa duże sklepy internetowe i portal turystyczny.

Szybko okazało się, że jedną z największych bolączek DeepCrawl jest koszmarnie niska wydajność, przy czym dotyczy to głównie fazy, którą DC określa jako “przetwarzanie”. Jest to etap, który następuje po pobraniu każdego kolejnego poziomu podstron.

DC działa w ten sposób, że najpierw pobiera podstrony 1 poziomu (w praktyce stronę główną), potem wszystkie podstrony drugiego poziomu (czyli podlinkowane ze strony głównej), potem podstrony 3 poziomu (podlinkowane z 2 poziomu) itd.

Pomiędzy każdym z tych etapów następuje faza przetwarzania, która jest naprawdę uciążliwa. W jednym z ostatnich projektów przetwarzanie poziomu, w którym było 150 tys. podstron, trwało prawie 30 godzin (sic!).

Było to tak uciążliwe, że zdecydowałem się napisać mail do supportu z pytaniem, czy to jakieś przejściowe problemy czy stała przypadłość. W odpowiedzi dowiedziałem się, że:

In the current version of the product there is a processing phase between levels. In the last level there were over 150K URLs found so it might take a while to process them.

We are aware of this and we have already addressed this issue in the new version which is much, much faster.

Czyli – DC zdaje sobie sprawę z problemu i podobno poprawiło sytuację w nowej wersji. Świetnie, tylko, po pierwsze, nowa wersja nie jest jeszcze publicznie dostępna, a po drugie, DC nie jest nowym narzędziem, tylko na rynku działa już kilka lat i pozycjonuje się jako rozwiązanie klasy enterprise, więc taka wpadka z wydajnością po prostu nie przystoi.

Mówiąc krótko, jeśli sądzicie, że z pomocą DC zrobicie szybki audyt, przynajmniej na razie nastawcie się na grube rozczarowanie. Lepiej zaplanować sobie kilka dni wyprzedzenia i uniknąć stresów, a do audytów ad hoc jak zwykle sięgnąć po ScreamingFroga.

Koszty alternatywnych narzędzi

Biorąc pod uwagę problemy z wydajnością, powstaje pytanie, czy w ogóle da się obronić teoretycznie podstawową zaletę tego rozwiązania, czyli uwolnienie lokalnych zasobów. Spójrzmy na cennik DeepCrawl i zastanówmy się, jak alternatywnie można przeznaczyć te same środki.

Pakiet Starter kosztuje 80 dolarów i nadaje się w zasadzie tylko do najmniejszych projektów – na pewno nie powalczymy z nim przy audytach dużych witryn ecommerce, ponieważ miesięcznie możemy przeskanować maksymalnie 100 tys. podstron, rozdzielonych między maksymalnie 5 domen.

Jeśli chcemy wyeliminować główny problem ze ScreamingFrogiem, to musimy po prostu uruchomić gdzieś w sieci dedykowany serwer lub serwer VPS, z którym będziemy się łączyć przez zdalny pulpit.

Jeśli skorzystamy z oferty OVH, to w ich chmurze możemy za 80 USD miesięcznie aktywować serwer wyposażony w 2 wirtualne procesory 2,4 GHz, 30 GB RAM i łącze 250 Mb/s.

ovh

Korzystając z maszyny w takiej konfiguracji, będziemy w stanie z pomocą ScreamingFroga crawlować miliony podstron miesięcznie zamiast skromnych 100 tys., a pojedynczy crawl z powodzeniem będzie mógł sięgać kilkuset tysięcy podstron, co powinno być wystarczające w zdecydowanej większości projektów.

Sprawa robi się jeszcze zabawniejsza, gdy pójdziemy o krok dalej w cenniku DeepCrawl. Kolejny poziom to “Basic”, który kosztuje 250 dolarów miesięcznie i podnosi limit do pół miliona podstron.

Wydając mniej, bo tylko 160 USD miesięcznie, możemy w OVH uruchomić maszynę, która ma 4 vCPU i 60 GB RAM. Ewentualnie (i to może być rozsądniejsze), możemy postawić dwie lub trzy instancje konfiguracji kosztującej 80 dolarów miesięcznie, dzięki czemu będziemy mogli realizować z pomocą ScreamingFroga kilka zupełnie niezależnych projektów w tym samym czasie.

Usterek i niedoróbek ciąg dalszy

Po kilku dniach pracy z DeepCrawl na jaw wyszły kolejne, zaskakujące niedociągnięcia.

Przykładowo, plan, za który płacimy, wg cennika pozwala założyć konta dla 3 użytkowników. Chciałem skorzystać z tej funkcji i założyć konto dla klienta, przypisując mu prawa dostępu tylko do jego projektu.

Wydawało mi się oczywiste i intuicyjne, że tak to właśnie działa. Okazuje się jednak, że nie. Bo wbrew temu, co mówi cennik, w DC po prostu nie ma obsługi wielu użytkowników, niezależnie od planu. Znowu cytat maila od supportu:

We don’t actually have the functionality to support multiple users in the current version, so you can just share your login with as many people as you want.

We are building this functionality into the new version which is due for release early next year.

It might not get exposed on the initial release but is being prioritised so it should happen very quickly.

Czyli po pierwsze, DC dość ordynarnie wprowadza w błąd na stronie cennika, a po drugie, nie ma podstawowego mechanizmu (ale znowu obiecuje, że już wkrótce będzie). Nie tego się spodziewałem po narzędziu klasy (pozornie) enterprise. A już sugestia, żeby udostępnić klientowi własny login (i tym samym dostęp do wszystkich projektów na koncie) jest po prostu przezabawna.

Czasami braki w DC są wręcz zadziwiające. Przykładowo, DC w domyślnej konfiguracji nie pobiera nagłówków H2. Jeśli chcemy się dowiedzieć, jaka jest ich treść, musimy sobie ręcznie skonfigurować, korzystając z wyrażeń regularnych, dodatkowy wzorzec, który DC zastosuje przy przeglądaniu podstron.

Crawl_Settings___DeepCrawl

Niemal każdy raport z DC można w taki czy inny sposób odtworzyć w Screaming Frogu, a w wielu przypadkach to właśnie po stronie SF jest przewaga.

Prosty przykład – DC pozwala podłączyć konto Google Analytics i zaciągnąć do projektu informacje o stronach docelowych z ruchu organicznego. Świetnie, ale mechanizm jest bardzo ograniczony – jedyne, co możemy wybrać, to czy okres ma wynieść ostatnie 7 czy 30 dni.

SF pozwala bardzo elastycznie określić nie tylko zakres dat, ale także dodatkowe segmenty, które chcemy nałożyć na pobierane dane. Co więcej, SF pozwoli także pobrać dane z Search Console, co przekłada się na jeszcze bardziej kompletną analizę.

Błędów crawla w trakcie nie zobaczysz...

Niskie limity liczby podstron, które możemy przeanalizować, stają się szczególnie dotkliwe, gdy odkryjemy, że zakończony właśnie projekt przyniósł kompletnie bezsensowne wyniki, bo crawler DC zawiesił się np. na jakimś mechanizmie, który przełącza widoki podstron i wygenerował sobie tam 200 tys. podstron.

Z jednej strony to jest jakaś wartość, bo pokazuje, że w taką samą pętlę może wpaść Google (choć raczej nie wpadnie), ale z drugiej strony, niekoniecznie o taki crawl chodziło, a zużytych kredytów w żaden sposób nie odzyskamy.

Dlatego w tym miejscu mam dobrą poradę praktyczną – zanim uruchomisz duży projekt w DC, wykonaj najpierw mały crawl testowy, np. na 10 tys. podstron, i dokładnie przeanalizuj wyniki. Możesz też taki crawl zrobić z pomocą ScreamingFroga, Xenu lub dowolnego narzędzia, z którego korzystasz.

Warto też spojrzeć w Search Console, w raport parametrów w adresach URL.

Na podstawie tej analizy wypisz sobie wszystkie parametry, które powinny być w crawlu ignorowane – np. id sesji, parametry zmieniające sortowanie, itd. Dodaj je w konfiguracji projektu w DC do listy parametrów pomijanych i dopiero wtedy uruchamiaj duże crawle. Zaoszczędzisz sobie w ten sposób nie tylko frustracji, ale i kosztów.

Wciąż jednak możesz wpaść w inną pułapkę, którą również napotkaliśmy podczas korzystania z DeepCrawl. Tym razem problem polegał na tym, że testowany serwis nie poradził sobie z obciążeniem, jakie wygenerował DeepCrawl. W związku z tym wiele żądań kolejnych podstron kończyło się komunikatem błędu 503. Niestety, nie ma żadnego sposobu, żeby zauważyć taką sytuację, dopóki DeepCrawl nie zakończy pracy.

W związku z tym również w tym przypadku otrzymaliśmy projekt, który zużył ponad 100 tys. kredytów (1 kredyt = 1 podstrona), a wyniki były bezużyteczne (jedyna wartość polegała na wskazaniu problemu z wydajnością, ale są dużo prostsze i lepsze sposoby, żeby się o tym przekonać).

Wady oczywiste, a zalety?

Żeby jednak zachować obiektywizm, musimy w tym miejscu wspomnieć o kilku ważnych zaletach, które ma DC. Jedną z nich jest harmonogram raportów.

Scheduling___DeepCrawl

W skrócie, możemy zdefiniować, że dany crawl ma być powtarzany w zadanych odstępach czasu, a wyniki poszczególnych przebiegów możemy porównać między sobą.

Dzięki temu możemy sprawdzić, czy nie zwiększyła się gwałtownie liczba błędów 404, czy nie pojawiły się dziwne przekierowania lub inne błędy, których wcześniej nie było.

To bez wątpienia dobre rozwiązanie diagnostyczne, ale też niezła podkładka w relacjach klient – agencja. Ułatwia i przyspiesza wykrycie ewentualnych niekorzystnych zmian technicznych w serwisie i pomaga uniknąć sytuacji, gdy takie zmiany przez wiele miesięcy przechodzą niezauważone, bo klient “zapomniał poinformować”, a “agencja nie sprawdziła”.

Właśnie w tej funkcji upatrywałbym głównej wartości DeepCrawl i jednego z nielicznych, mocnych argumentów, przemawiających za ewentualnym zakupem tej usługi.

Ciekawy mechanizm analityczny, który ma DeepCrawl, a którego nie ma ScreamingFrog, to wskaźnik DeepRank, wyliczany na zasadzie podobnej jak PageRank.

Reports_-_All_URLs___DeepCrawl

DeepRank pozwala ocenić, ile mocy z linkowania wewnętrznego dopływa do każdej podstrony w serwisie i na tej podstawie wykryć ewentualne wąskie gardła. Akurat to rozwiązanie mi się podoba i chętnie bym je zobaczył w jednej z przyszłych wersji ScreamingFroga, bo obecnie można je tylko symulować, przetwarzając w Excelu lub bazie danych dane zbierane przez SF (poziom, na którym jest dana podstrona, liczba linków wychodzących i przychodzących).

W niektórzych przypadkach istotnym udogodnieniem może być również wbudowana w DeepCrawl obsługa kilku różnych adresów IP, z których możemy wykonywać analizy serwisów.

Crawl_Settings___DeepCrawl_ip

Domyślnie DeepCrawl dynamicznie przypisuje jeden adres IP do projektu, ale możemy także wymusić konkretny, statyczny adres IP lub – co jest najciekawszą opcją – włączyć tryb “stealth”, w którym DeepCrawl udaje normalny ruch – pomiędzy kolejnymi żądaniami zmienia adresy IP oraz nagłówki identyfikacyjne (które są skopiowane z popularnych przeglądarek).

Ten ostatni tryb jest godny uwagi, gdy testujemy serwisy konkurencji i nie chcemy przyciągać uwagi administratorów, ewentualnie w sytuacji, gdy próby normalnego crawlowania napotykają na blokady IP.

Niewątpliwie bardzo wygodny jest też mechanizm udostępniania linków do konkretnych raportów. Dzięki temu można np. wygenerować unikalny odnośnik do raportu błędów 404 i przekazać go do programistów. Będą mogli zapoznać się z tym raportem bez potrzeby zakładania konta w DeepCrawl i usunąć usterki. Jest to znacznie wygodniejsze niż eksportowanie raportów w Screaming Frogu i przesyłanie ich jako załączników.

Czy warto?

DeepCrawl ma kilka cech, które sprawiają, że jest to narzędzie przyjemne w codziennej pracy, pod warunkiem, że uda się wygenerować poprawne raporty. Wtedy możemy docenić ładne wizualizacje i zestawienia, mechanizmy udostępniania danych czy szybkie wyszukiwanie konkretnych informacji.

Niestety, dwa kluczowe problemy rujnują obraz sytuacji.

Po pierwsze, wydajność przy dużych projektach, a do takich DeepCrawl jest podobno stworzony, jest katastrofalna.
Po drugie, stosunek ceny do zasobów, jakie otrzymujemy (liczba podstron, które możemy crawlować), jest z mojego punktu widzenia nie do obrony, zwłaszcza wliczając w to nieudane projekty, które wymagają powtórnego uruchomienia.

Dlatego z żalem (głównie ze względu na nadzieje, jakie mieliśmy na początku korzystania z DeepCrawl) zdecydowaliśmy, że nie będziemy przedłużać abonamentu na to narzędzie, pozostając przy sprawdzonym rozwiązaniu, czyli aplikacji Screaming Frog.

Shares 0
Marcin Lejman
 

Jestem współwłaścicielem Critical.pl. Prowadzę przede wszystkim projekty związane z analityką internetową, optymalizacją konwersji i budową strategii online, a nadzoruję działania SEO i PPC prowadzone przez naszą firmę. Jeśli czujesz, że Twój biznes ma niewykorzystany potencjał i chcesz go rozwinąć, skontaktuj się ze mną - chętnie porozmawiam o możliwościach.

Click Here to Leave a Comment Below 6 comments
Sławek Borowy - 15/01/2016

za jeden abo można kupić 16GB ramu, wtedy Frog nie marudzi ;)

Reply
    Marcin Lejman - 15/01/2016

    No tak, ale ja nie lubię trzymać SF na swoim komputerze – tylko do małych analiz ad hoc. Inaczej mnie denerwuje, że w tle zjada zasoby, jest też problem z udostępnieniem komuś wyników. A jak stoi sobie na VPSie, to jest wygodniej.

    Reply
Tomek Jordan - 15/01/2016

no to nie jest zdecydowanie artykuł sponsorowany :) oby takich więcej

Reply
Damian - 16/01/2016

Pod SF najlepiej postawić jeden osobny komputer, połączenie zdalnego pulpitu i może chodzić 24h nie przeszkadzając w pracy. Co do samych porównań cenowych, można znaleźć tańszą alternatywę do OVH :)

Reply
Piotr - 22/01/2016

nie zgadzam się z argumentem, że postawienie SF na serwerze we/zew jest lepszym rozwiązaniem. Trzeba to tego jeszcze dodać koszt i czas potrzebny na konfigurację i obsługę serwerów – nie wszyscy mają na to ochotę. Sam korzystam z DP (setki stron, ale każda ma mniej niż 10k podstron) i przy regularnych skanach nie widzę problemów z wydajnością. Robienie skanów ad-hoc na mniejszych serwisach (<10k) nie nastręcza problemów.

Reply
    Marcin Lejman - 22/01/2016

    Nie ma problemu z konfiguracją zewnętrznych serwerów – kupujemy gotową, działającą maszynę, do której łączymy się z pomocą zdalnego pulpitu. Od decyzji do uruchomienia – jakieś 10 minut, zero problemów.

    Reply

Leave a Reply:

0 Shares