iSpider dla TYPO3

Uszkodzone linki kosztują pozycje w rankingu i zaufanie, ale prawie nikt ich regularnie nie sprawdza

Każda strona TYPO3 z więcej niż 200 podstron ma uszkodzone linki. Redaktorzy usuwają strony, przenoszą treści lub zmieniają sluggi URL bez sprawdzania wszystkich wewnętrznych linków. Rezultat: błędy 404, które Google traktuje jako sygnał jakości i które frustrują odwiedzających. iSpider to wewnętrzny web-crawler dla TYPO3, który crawluje własny frontend, identyfikuje uszkodzone linki i generuje sitemapę. Narzędzie wypełnia lukę między ręczną kontrolą a zewnętrznymi narzędziami SEO, które nie mają dostępu do obszarów chronionych.

Dla redakcji i kierowników projektów technicznych iSpider to instrument QA, który radzi sobie bez zewnętrznych zależności. Crawler działa w backendzie TYPO3, zna strukturę strony i może też sprawdzać obszary chronione hasłem, do których nie docierają zewnętrzne narzędzia jak Screaming Frog. Wyniki są dostępne bezpośrednio w backendzie TYPO3, co przyspiesza poprawianie uszkodzonych linków przez redaktorów, ponieważ nie muszą przełączać się między różnymi narzędziami.

Typowe scenariusze zastosowań sięgają od kontroli pre-launch do bieżącego monitoringu

Najczęstszy scenariusz to kontrola pre-launch przed relaunchem lub upgrade TYPO3. Zanim nowa wersja pójdzie live, iSpider crawluje środowisko stagingowe i dostarcza pełną listę wszystkich uszkodzonych linków, brakujących obrazów i łańcuchów przekierowań. Typowy relaunch średniej wielkości strony (500 do 1.000 podstron) z doświadczenia produkuje 30 do 80 uszkodzonych linków, które bez systematycznego crawlowania trafiłyby niezauważone na produkcję.

Drugi scenariusz: bieżący monitoring w codziennej pracy redakcji. Tygodniowe zadanie Scheduler crawluje stronę i wysyła raport do redakcji ze wszystkimi nowymi błędami 404 od ostatniego przebiegu. W ten sposób problemy są wykrywane i naprawiane w ciągu dni, a nie miesięcy.

Trzeci scenariusz: analiza SEO struktury wewnętrznych linków. iSpider pokazuje, które strony nie mają przychodzących linków wewnętrznych (strony osierocone) i które strony mają szczególnie wiele linków przychodzących. Te dane pomagają w strategii treści i optymalizacji wewnętrznego linkowania. Typowa analiza ujawnia, że 10 do 15% wszystkich stron jest osieroconych i w konsekwencji rzadko lub nigdy nie są crawlowane przez Google.

Architektura techniczna działa jako moduł backendu z integracją Schedulera

iSpider rejestruje się jako moduł backendu w TYPO3 i wykorzystuje Scheduler TYPO3 do automatycznych przebiegów crawlowania. Crawler startuje od konfigurowalnej strony wejściowej (zwykle root-page) i podąża rekurencyjnie za wszystkimi linkami wewnętrznymi do ustawialnej głębokości. Linki zewnętrzne są sprawdzane pod kątem dostępności, ale nie są dalej śledzone.

Wyniki są zapisywane w dedykowanej tabeli bazy danych: URL, kod statusu HTTP, czas odpowiedzi, strona referencyjna i znacznik czasu. Moduł backendu pokazuje wyniki jako filtrowaną listę z sortowaniem według kodu statusu, co ułatwia priorytetyzację napraw.

Prędkość crawlowania jest sterowana przez konfigurację: jednoczesne żądania, czas oczekiwania między żądaniami i maksymalna głębokość crawlowania. Dla dużych instalacji z ponad 5.000 podstron zalecany jest nocny crawl przez Scheduler, aby nie obciążać serwera w ciągu dnia. Wyniki pozostają zapisane w bazie danych i są dostępne przez moduł backendu w każdej chwili, również między przebiegami crawlowania. Pozwala to na historyczne porównanie rozwoju uszkodzonych linków przez tygodnie i miesiące.

Częste problemy to timeouty serwera, niepełne crawle i false positives

Najczęstszy problem: crawl przerywa się przy dużych stronach, ponieważ osiągany jest limit pamięci PHP lub max_execution_time. Rozwiązanie: podzielić crawl przez Scheduler na batche i zwiększyć limity PHP dla kontekstu CLI (zalecane: memory_limit 512M, max_execution_time 0 dla CLI).

Drugi problem: niepełne crawle przy treściach renderowanych w JavaScript. iSpider to crawler po stronie serwera, który nie wykonuje JavaScript. Single-Page-Applications lub treści doładowywane przez AJAX nie są wykrywane przez crawlera. Rozwiązanie: dla obszarów intensywnie używających JavaScript wdrożyć dodatkowo zewnętrzny crawler jak Screaming Frog.

Trzeci problem: false positives przy linkach zewnętrznych. Niektóre strony blokują crawlery przez wykrywanie User-Agent i dostarczają kod statusu 403, mimo że URL jest osiągalny dla przeglądarek. iSpider zgłasza to jako błąd. Rozwiązanie: skonfigurować listę wyjątków dla znanych false positives i ustawić String User-Agent na wartość typową dla przeglądarki. LinkedIn, Facebook i niektóre strony chronione CDN to typowe kandydaty na false positives.

Kolejny problem: łańcuchy przekierowań. iSpider podąża za przekierowaniami (301, 302), ale nie raportuje, ile hopów było potrzebnych. Potrójne lub poczwórne przekierowania to problem SEO, który bez szczegółowej analizy przekierowań pozostaje niewidoczny. Zewnętrzne crawlery jak Screaming Frog pokazują pełny łańcuch przekierowań włącznie z punktami pośrednimi, czego iSpider nie potrafi.

iSpider to narzędzie legacy, zewnętrzne alternatywy crawlerów są wydajniejsze

iSpider został opracowany dla TYPO3 v7 i v8 i nie ma oficjalnego wsparcia dla v12 lub v13. Kto migruje na aktualne wersje TYPO3, powinien ocenić zewnętrzne alternatywy. Screaming Frog (narzędzie desktopowe, do 500 URL bezpłatnie), Sitebulb lub zintegrowany TYPO3-Linkvalidator pokrywają funkcje rdzenia. Gosign w własnych projektach używa kombinacji TYPO3 Core-Linkvalidator do kontroli wewnętrznych i zautomatyzowanych crawlów Screaming Frog dla obszernych analiz SEO. Przy migracji z iSpider sprawdzamy, które konfiguracje i raporty w istniejącym setupie są krytyczne, i odwzorowujemy je w nowym rozwiązaniu.