TYPO3-Monitoring vom Inhaltselement bis zum Scheduler
XICTRAQ überwacht Frontend, Backend-Anmeldung und robots.txt Ihrer TYPO3-Website, per Heartbeat auch den Scheduler, und meldet ausgefallene Seiten, verpasste Scheduler-Läufe und eine robots.txt, die alle Crawler aussperrt. Der cookielose Tracker misst Seitenaufrufe, Web Vitals und JavaScript-Fehler auf den Seiten, in die Sie ihn einbinden.
Diese Pfade zuerst prüfen
- Uptime-MonitoringStartseite mit Schlüsselwort-Check
/ - Uptime-MonitoringBackend-Anmeldung am Standard-Einstiegspunkt
/typo3/ - SEO-Monitoringrobots.txt, etwa als statische Route der Site-Konfiguration
/robots.txt - SEO-MonitoringSitemap-Index der Systemerweiterung seo
/sitemap.xml - Security-ScanGit-Verzeichnis im Web-Verzeichnis
/.git/HEAD
Warum ein Check der Startseite bei TYPO3 nicht reicht
Eine TYPO3-Website besteht aus dem Core, Erweiterungen, einem Sitepackage mit TypoScript und Fluid-Vorlagen sowie der Site-Konfiguration je Website. Fehler zeigen sich dabei nicht nur als ausgefallene Seite: Ein einzelnes Plugin kann mit einer Fehlermeldung ausfallen, während die Seite mit HTTP 200 antwortet, und der Scheduler kann stillstehen, ohne dass im Frontend etwas davon zu sehen ist.
XICTRAQ verteilt die Prüfung deshalb auf mehrere Module: Uptime-Monitoring mit Unterseiten, Schlüsselwort-Check und Wartungserkennung, Heartbeats für den Scheduler, SEO-Monitoring für robots.txt und Sitemap, den Screenshot-Changelog für sichtbare Änderungen und den Security-Scan für offen liegende Dateien und Sicherheitsheader.
Die Pfade auf dieser Seite folgen den Standardwerten von TYPO3: das Backend unter /typo3/ und der Sitemap-Index der Erweiterung seo unter /sitemap.xml. Haben Sie den Einstiegspunkt des Backends geändert oder liegen Sprachfassungen unter eigenen Pfaden wie /en/, gilt die Adresse, die Ihre Installation tatsächlich verwendet.
Ist das Backend per IP-Sperre oder Zugangsschutz abgeschirmt, antwortet /typo3/ auch für XICTRAQ mit einem Fehler. Lassen Sie den Pfad dann aus den Unterseiten weg.
Was auf TYPO3-Websites typischerweise bricht
Ausnahmefehler nach einem Update
Bricht nach einem Core- oder Extension-Update die Seitenerzeugung mit einer nicht abgefangenen Ausnahme ab, zeigt TYPO3 im Produktivkontext die Seite „Oops, an error occurred!“ und antwortet in der Regel mit HTTP 500. Das Uptime-Monitoring wertet Statuscodes außerhalb von 200 bis 399 als Ausfall, sofern es keine Wartung und keine Bot-Abwehr erkennt, und meldet hinterlegte Unterseiten einzeln. So fällt auch eine einzelne Unterseite auf, etwa die mit der Suche oder einem Formular, sofern Sie sie hinterlegt haben.
Plugin fällt aus, die Seite antwortet mit 200
Wirft ein Plugin oder Inhaltselement eine Ausnahme, ersetzt TYPO3 im Produktivkontext nur diesen Teil der Seite durch die Meldung „Oops, an error occurred!“ samt Kennung und liefert den Rest mit HTTP 200 aus. Laut TYPO3-Dokumentation kann eine solche Seite zudem im Cache landen. Das Uptime-Monitoring sieht darin keinen Ausfall. Ein Schlüsselwort-Check auf der überwachten Adresse, sofern Ihr Tarif ihn enthält, meldet dagegen, wenn ein Wort fehlt, das nur dieses Plugin ausgibt; nach der Fehlermeldung selbst sucht er nicht.
Wartungsmodus von TYPO3 gilt als Ausfall
Mit der Einstellung pageUnavailable_force sperrt TYPO3 das Frontend für alle Besucher außerhalb von devIPmask und antwortet mit HTTP 503. XICTRAQ wertet eine 503-Antwort nur dann als Wartung, wenn der Seitentitel einen Hinweis wie „Wartungsmodus“ oder „maintenance mode“ trägt oder der Text „Wartungsarbeiten“ oder „Wartungsmodus“ enthält. Die Standardseite von TYPO3 trägt keinen solchen Hinweis, XICTRAQ meldet deshalb einen Ausfall. Hinterlegen Sie in der Site-Konfiguration für den Statuscode 503 eine eigene Fehlerseite mit einem solchen Hinweis oder legen Sie in XICTRAQ vorab ein Wartungsfenster an, sofern Ihr Tarif Wartungsfenster enthält.
Der Scheduler steht still
Aufgaben im Scheduler, etwa das Bereinigen alter Tabelleneinträge oder das Anonymisieren von IP-Adressen, führt TYPO3 automatisch nur aus, wenn ein Cronjob oder eine geplante Aufgabe des Servers regelmäßig scheduler:run aufruft. Fehlt dieser Eintrag nach einem Serverumzug oder bricht der Aufruf ab, bleibt die Website erreichbar und der Stillstand fällt im Frontend nicht auf. Hängen Sie an den Cronjob den Aufruf eines Heartbeats: Bleibt sein Ping über das erwartete Intervall samt Toleranz aus, meldet XICTRAQ den verpassten Lauf.
Staging-Sperre in der robots.txt
TYPO3 kann die robots.txt je Site als statische Route aus der Site-Konfiguration ausliefern. Wird dabei ein Eintrag aus der Staging-Umgebung mit Disallow: / übernommen, sperrt er Suchmaschinen aus, ohne dass Besucher etwas merken. XICTRAQ liest die robots.txt an der Domain-Wurzel, meldet ein Disallow: / für alle Crawler als kritischen Alarm und hält Änderungen der Datei im Changelog fest.
Sichtbare Änderung nach Upgrade oder Sitepackage-Wechsel
Ein Upgrade, geänderte Fluid-Vorlagen im Sitepackage oder eine überarbeitete Erweiterung können das Layout verschieben, während der Statuscode bei 200 bleibt. Der Screenshot-Changelog vergleicht Aufnahmen der Seite, legt bei einer deutlichen Abweichung Vorher-, Nachher- und Differenzbild im Changelog ab und löst bei einer großen Änderung einen Alarm aus. Den Verlauf dieser Bilder sehen Sie, sofern Ihr Tarif den Verlauf visueller Änderungen enthält. Ändert sich die Seitenhöhe stark oder ist der Inhalt senkrecht deutlich versetzt, kennzeichnet XICTRAQ den Eintrag als nicht direkt vergleichbar und gibt dafür keinen Alarm, auch wenn sich zugleich Inhalte geändert haben.
Woran XICTRAQ TYPO3 erkennt
Die Technikerkennung liest HTML und Antwortköpfe der überwachten Seite, der Security-Scan wertet dabei einige Merkmale mehr aus als die laufende Überwachung. Die Wartungserkennung wertet dagegen die Antwort selbst aus, unabhängig vom erkannten System.
- Die laufende Überwachung erkennt TYPO3 an Pfaden wie /typo3conf/, /typo3temp/ oder /typo3/ im Quelltext, an den Kennungen data-typo3-role oder t3js- oder am Antwortkopf X-TYPO3-Parsetime.
- Der Security-Scan liest zusätzlich das Generator-Tag und die Kennung typo3-extension im Quelltext sowie einen Verweis auf typo3.org in den Antwortköpfen. Eine Composer-Installation, die Dateien von Erweiterungen über /_assets/ ausliefert und keines der übrigen Merkmale zeigt, erkennt die laufende Überwachung womöglich nicht als TYPO3.
- Wartung erkennt XICTRAQ an einer 503-Antwort mit einem Wartungshinweis im Seitentitel oder im Text. Ein 503 ohne solchen Hinweis und ohne erkennbare Bot-Abwehr bleibt eine Störung, auch wenn TYPO3 ihn über pageUnavailable_force ausgibt.
- Erkennt XICTRAQ statt TYPO3 ein anderes CMS, etwa nach einem Umzug, schreibt es einen Eintrag „CMS gewechselt“ mit altem und neuem System in den Changelog. Bleibt das neue System unerkannt, entsteht kein solcher Eintrag.
- Kommt statt der Seite eine Fehlerseite wie „Oops, an error occurred!“ oder eine Bot-Abwehr zurück, bewertet XICTRAQ das CMS in diesem Lauf nicht und leitet daraus keinen Systemwechsel ab. Server- und CDN-Angaben aus den Antwortköpfen gelten weiter.
Was der Tracker in TYPO3 erfasst
Eigens für TYPO3 enthält der Tracker einen Zweig zur Zuordnung angemeldeter Besucher. Alles Übrige misst er wie auf jeder anderen Website, in die Sie ihn einbinden. Er setzt keine Cookies und legt im Standard-Tracking nichts im Browser-Speicher ab.
Erfasst der Tracker von selbst
- Seitenaufrufe mit Herkunft und UTM-Parametern, Web Vitals wie LCP, CLS und INP, soweit der Browser sie meldet, sowie JavaScript-Fehler mit Meldung, Datei und Zeile.
- Scrolltiefe in Stufen und Verweildauer je Seite.
- Klicks auf externe Links und auf Dateidownloads, etwa PDF-Dateien aus fileadmin.
- Klicks auf Elemente mit dem Attribut data-xictraq-event, etwa in Fluid-Vorlagen gesetzt. Weitere Attribute nach dem Muster data-xictraq-name gehen als Eigenschaften mit.
- Formularinteraktionen wie Ansicht, Fokus und Absenden, auch in Formularen der Formularerweiterung form, sofern die Formularanalyse für die Website eingeschaltet ist und Ihr Tarif sie enthält.
Nicht automatisch erfasst
- Angemeldete Frontend-Benutzer von selbst: TYPO3 gibt die Kennung des angemeldeten Benutzers nicht an Skripte weiter, und das Sitzungscookie fe_typo_user liest der Tracker nicht. Zugeordnet wird erst, wenn Ihre Fluid-Vorlage die Kennung ausgibt.
- Ob ein Formular auf dem Server verarbeitet wurde, etwa ob die Finisher der Formularerweiterung eine E-Mail versendet haben. Im Browser sieht der Tracker höchstens das Absenden.
- Vorgänge im TYPO3-Backend wie Anmeldungen von Redakteuren, Änderungen an Seiten und Inhalten oder das Leeren von Caches.
- Läufe des Schedulers und andere Befehle auf der Kommandozeile. Dafür gibt es die Heartbeats.
- Warenkorb, Kasse und Umsatz aus Shop-Erweiterungen für TYPO3 über einen eigenen Zweig: Den hat der Tracker nicht. Es greifen nur allgemeine Erkennungen, etwa E-Commerce-Einträge im dataLayer, Elemente mit add-to-cart im Klassennamen und Adressen mit „checkout“, „kasse“ oder „danke“. Sofern Ihr Tarif E-Commerce-Tracking enthält, kann dabei eine Seite unter einer Adresse mit „danke“ als Bestellabschluss ohne Betrag zählen, auch nach einem Kontaktformular.
Angemeldete Besucher ordnen Sie über xictraq.identify(kundennummer, { group }) zu, verbucht wird das, sofern Ihr Tarif die Besucher-Identifizierung enthält. Eigene Ereignisse, etwa die Bestätigungsseite eines Formulars, melden Sie mit xictraq.event(name, props), Beträge aus einer Shop-Erweiterung mit xictraq.revenue(betrag, "EUR", bestellnummer), verbucht, sofern Ihr Tarif E-Commerce-Tracking enthält.
Die passenden Module für TYPO3
Häufige Fragen
Wie binde ich den XICTRAQ-Tracker in TYPO3 ein?
Sie fügen das Skript-Tag mit Ihrer Website-Kennung im Attribut data-site in den Kopfbereich jeder Seite ein, in TYPO3 etwa über page.headerData im TypoScript Ihres Sitepackages oder direkt im Fluid-Layout. Das Skript lädt mit defer und setzt keine Cookies. Setzt Ihre Installation für das Frontend eine Content Security Policy, muss sie das Skript und seine Sendeadresse zulassen.
Löst der Wartungsmodus von TYPO3 einen Ausfallalarm aus?
In der Grundeinstellung ja. Mit pageUnavailable_force antwortet TYPO3 mit HTTP 503 und einer Standardseite ohne Wartungshinweis, und einen 503 ohne Wartungshinweis und ohne erkennbare Bot-Abwehr wertet XICTRAQ als Störung, weil auch ein überlasteter Server so antwortet. Hinterlegen Sie in der Site-Konfiguration unter errorHandling für den Statuscode 503 eine eigene Seite, etwa eine Fluid-Vorlage, deren Titel „Wartungsmodus“ oder deren Text „Wartungsarbeiten“ enthält: Dann pausieren Ausfall- und Inhaltsalarme, SSL-, Domain- und Blacklist-Alarme bleiben scharf. Alternativ legen Sie in XICTRAQ vorab ein Wartungsfenster an, sofern Ihr Tarif Wartungsfenster enthält.
Wie überwache ich den Scheduler von TYPO3?
Mit einem Heartbeat: Rufen Sie im Cronjob nach vendor/bin/typo3 scheduler:run, in klassischen Installationen nach typo3/sysext/core/bin/typo3 scheduler:run, die Ping-Adresse des Heartbeats auf. Bleibt der Ping über das erwartete Intervall samt Toleranz aus, meldet XICTRAQ den verpassten Lauf. Übergeben Sie den Rückgabewert des Befehls als exit_code, wertet XICTRAQ einen Wert ungleich 0 als Fehlschlag; scheduler:run liefert einen solchen Wert, wenn eine Aufgabe mit einer Ausnahme abbricht. Ob eine Aufgabe inhaltlich das Richtige getan hat, zeigt der Ping nicht.
Ordnet XICTRAQ angemeldete Frontend-Benutzer automatisch zu?
Nicht von selbst. TYPO3 gibt die Kennung des angemeldeten Benutzers nicht an Skripte weiter, und das Sitzungscookie fe_typo_user liest der Tracker nicht. Gibt Ihre Fluid-Vorlage für angemeldete Besucher ein Element mit data-fe-user-id oder data-felogin-user und der Benutzerkennung aus, ordnet der Tracker die Sitzung dieser Kennung zu; der Wert 0 gilt als nicht angemeldet. Ebenso gehen xictraq.identify(), window.xictraqUser, das Meta-Tag xictraq:user-id oder ein Attribut data-user-id mit einer Kennung, die Ihre Fluid-Vorlage ausgibt; verbucht wird die Zuordnung, sofern Ihr Tarif die Besucher-Identifizierung enthält.
Sucht der Security-Scan nach TYPO3-spezifischen Dateien?
Nein, er fragt allgemeine Dateien ab, etwa .git/HEAD, .git/config, .env, backup.sql, dump.sql, phpinfo.php oder adminer.php, und listet die, die mit HTTP 200 antworten. Antwortet ein Server auf jede Adresse mit 200, fragt der Scan nur die Dateien ab, deren Inhalt er prüfen kann. In einer Composer-Installation zeigt das Web-Verzeichnis in der Grundeinstellung auf public, Projektdateien liegen darüber; in einer klassischen Installation ist der Projektordner selbst das Web-Verzeichnis. Daneben bewertet der Scan Sicherheitsheader, eine Versionsangabe im Antwortkopf Server und jeden Antwortkopf X-Powered-By.
Welche Sitemap prüft XICTRAQ bei einer mehrsprachigen TYPO3-Website?
Der Sitemap-Check liest /sitemap.xml an der Domain-Wurzel, löst einen Sitemap-Index auf und meldet Adressen aus einer Stichprobe, die mit einem Fehlerstatus ab 400 antworten; er läuft für verifizierte Websites, sofern Ihr Tarif ihn enthält. In TYPO3 hat jede Sprache mit eigenem Einstiegspunkt eine eigene Sitemap, etwa /en/sitemap.xml, diese liest der Check nicht. Unter /sitemap.xml liefert die Erweiterung seo ihre Sitemap nur mit einer Route-Erweiterung aus; diese bringt seit TYPO3 14.1 das Site-Set typo3/seo-sitemap mit, vorher musste sie in der Site-Konfiguration eingetragen werden.