iSpider for TYPO3

Broken Links kosten Rankings und Vertrauen, aber kaum jemand prüft sie regelmässig

Jede TYPO3-Website mit mehr als 200 Seiten hat Broken Links. Redakteure löschen Seiten, verschieben Inhalte oder ändern URL-Slugs, ohne alle internen Verlinkungen zu prüfen. Das Ergebnis: 404-Fehler, die Google als Qualitätssignal wertet und die Besucher frustrieren. iSpider ist ein interner Web-Crawler für TYPO3, der das eigene Frontend crawlt, Broken Links identifiziert und eine Sitemap generiert. Das Werkzeug schliesst die Lücke zwischen manueller Prüfung und externen SEO-Tools, die keinen Zugriff auf geschützte Bereiche haben.

Für Redaktionen und technische Projektleiter ist iSpider ein QA-Instrument, das ohne externe Abhängigkeiten auskommt. Der Crawler läuft im TYPO3-Backend, kennt die Seitenstruktur und kann auch passwortgeschützte Bereiche prüfen, die externe Tools wie Screaming Frog nicht erreichen. Die Ergebnisse sind direkt im TYPO3-Backend verfügbar, was die Korrektur von Broken Links durch Redakteure beschleunigt, weil sie nicht zwischen verschiedenen Tools wechseln müssen.

Typical use cases range from Pre-Launch-Checks bis zum laufenden Monitoring

Das häufigste Szenario ist der Pre-Launch-Check vor einem Relaunch oder TYPO3-Upgrade. Bevor eine neue Version live geht, crawlt iSpider die Staging-Umgebung und liefert eine vollständige Liste aller Broken Links, fehlenden Bilder und Redirect-Ketten. Ein typischer Relaunch einer mittelgrossen Website (500 bis 1.000 Seiten) produziert erfahrungsgemäss 30 bis 80 Broken Links, die ohne systematischen Crawl unentdeckt in Produktion gehen würden.

Zweites Szenario: Laufendes Monitoring im Redaktionsalltag. Ein wöchentlicher Scheduler-Task crawlt die Website und sendet einen Report an die Redaktion mit allen neuen 404-Fehlern seit dem letzten Durchlauf. So werden Probleme innerhalb von Tagen statt Monaten erkannt und behoben.

Drittes Szenario: SEO-Analyse für interne Verlinkungsstruktur. iSpider zeigt, welche Seiten keine eingehenden internen Links haben (verwaiste Seiten) und welche Seiten besonders viele eingehende Links besitzen. Diese Daten helfen bei der Content-Strategie und der internen Link-Optimierung. Eine typische Analyse deckt auf, dass 10 bis 15% aller Seiten verwaist sind und von Google folglich selten oder nie gecrawlt werden.

Technical architecture works als Backend-Modul mit Scheduler-Integration

iSpider registriert sich als Backend-Modul in TYPO3 und nutzt den TYPO3-Scheduler für automatisierte Crawl-Durchläufe. Der Crawler startet von einer konfigurierbaren Einstiegsseite (typischerweise die Root-Page) und folgt allen internen Links rekursiv bis zu einer einstellbaren Tiefe. Externe Links werden auf Erreichbarkeit geprüft, aber nicht weiterverfolgt.

Die Ergebnisse werden in einer eigenen Datenbanktabelle gespeichert: URL, HTTP-Statuscode, Antwortzeit, referenzierende Seite und Zeitstempel. Das Backend-Modul zeigt die Ergebnisse als filterbare Liste mit Sortierung nach Statuscode, was die Priorisierung von Fixes erleichtert.

Die Crawl-Geschwindigkeit ist über die Konfiguration steuerbar: Gleichzeitige Requests, Wartezeit zwischen Requests und maximale Crawl-Tiefe. Für grosse Installationen mit über 5.000 Seiten empfiehlt sich ein nächtlicher Crawl über den Scheduler, um die Server-Last tagsüber nicht zu beeinträchtigen. Die Ergebnisse bleiben in der Datenbank gespeichert und sind über das Backend-Modul jederzeit abrufbar, auch zwischen den Crawl-Durchläufen. Das erlaubt einen historischen Vergleich der Broken-Link-Entwicklung über Wochen und Monate.

Common problems include Server-Timeouts, unvollständige Crawls und false Positives

Das häufigste Problem: Der Crawl bricht bei grossen Websites ab, weil das PHP-Memory-Limit oder die max_execution_time erreicht wird. Die Lösung: Den Crawl über den Scheduler in Batches aufteilen und die PHP-Limits für den CLI-Kontext erhöhen (empfohlen: memory_limit 512M, max_execution_time 0 für CLI).

Zweites Problem: Unvollständige Crawls bei JavaScript-gerenderten Inhalten. iSpider ist ein serverseitiger Crawler, der kein JavaScript ausführt. Single-Page-Applications oder Inhalte, die erst per AJAX nachgeladen werden, erfasst der Crawler nicht. Die Lösung: Für JavaScript-lastige Bereiche einen externen Crawler wie Screaming Frog ergänzend einsetzen.

Drittes Problem: False Positives bei externen Links. Manche Websites blockieren Crawler per User-Agent-Erkennung und liefern einen 403-Statuscode, obwohl die URL für Browser erreichbar ist. iSpider meldet das als Fehler. Die Lösung: Eine Ausnahmeliste für bekannte False Positives konfigurieren und den User-Agent-String auf einen Browser-typischen Wert setzen. LinkedIn, Facebook und einige CDN-geschützte Websites sind typische Kandidaten für False Positives.

Ein weiteres Problem: Redirect-Ketten. iSpider folgt Redirects (301, 302), meldet aber nicht, wie viele Hops nötig waren. Dreifach- oder Vierfach-Redirects sind ein SEO-Problem, das ohne detaillierte Redirect-Analyse unsichtbar bleibt. Externe Crawler wie Screaming Frog zeigen die vollständige Redirect-Kette inklusive Zwischenstationen, was iSpider nicht leistet.

iSpider ist ein Legacy-Tool, externe Crawler-Alternativen include leistungsfähiger

iSpider wurde für TYPO3 v7 und v8 entwickelt und hat keine offizielle Unterstützung für v12 oder v13. Wer auf aktuelle TYPO3-Versionen migriert, sollte externe Alternativen evaluieren. Screaming Frog (Desktop-Tool, bis 500 URLs kostenlos), Sitebulb oder der integrierte TYPO3-Linkvalidator decken die Kernfunktionen ab. Gosign nutzt in eigenen Projekten eine Kombination aus dem TYPO3-Core-Linkvalidator für interne Prüfungen und automatisierten Screaming-Frog-Crawls für umfassende SEO-Analysen. Bei einer Migration von iSpider prüfen wir, welche Konfigurationen und Reports im bestehenden Setup kritisch sind, und bilden diese in der neuen Lösung ab.