Jeder Redirect, jeder Header, jede robots.txt. Dazu eine Matrix mit 56 bekannten Crawlern, die dir pro Bot zeigt: erlaubt oder blockiert? Server-seitig in PHP, kein Login, keine Werbung, keine Tracker.
Jeder einzelne Hop wird separat ausgeführt. Du siehst Status (200, 301, 302, 307, 308, 4xx, 5xx), HTTP-Version (1.1, 2, 3), TTFB, Total-Time, Response-Size, Server-IP, das emittierte Location-Header sowie die TLS-Issuer und Restlaufzeit pro https-Hop. Loops werden erkannt, die Maximaltiefe ist auf 10 Stufen begrenzt.
Alle Response-Header pro Hop. Farbcodiert nach Funktion: Security (HSTS, CSP, XFO, COOP, CORP), Caching (Cache-Control, ETag, Vary), Cookies (Set-Cookie mit Flags) und Meta (Server, Content-Type, Encoding). Du erkennst auf einen Blick, welche Stufe in der Kette ein Sicherheitsheader vergisst oder ein zu langes Cache-TTL setzt.
Jede einzigartige Domain in der Redirect-Chain bekommt ihre robots.txt abgerufen, geparst und nach RFC 9309 ausgewertet. Sitemap-Verweise werden extrahiert, Crawl-Delay wird angezeigt, Wildcard-Regeln (* und $) werden korrekt aufgelöst.
Suche (Googlebot, Bingbot, DuckDuckBot, Yandex, Baidu, Applebot, Naver, Seznam), AI/LLM (GPTBot, Claude, Perplexity, Gemini via Google-Extended, Apple Intelligence, Bytespider, CCBot, Cohere, Mistral), SEO (Ahrefs, Semrush, Majestic, Moz, BLEX, DataForSEO), Social (Facebook, X, LinkedIn, Slack, Discord, Telegram, WhatsApp, Pinterest, Reddit, TikTok), Archive, Monitoring und Security-Scanner. Pro Bot: erlaubt oder blockiert, mit der konkreten Regel, die das Verdict ausgelöst hat.
Du kannst die URL mit oder ohne Schema eingeben. Ohne https:// wird automatisch das sichere Protokoll vorangestellt. Subdomains, Pfade und Query-Strings sind erlaubt.
Bevor irgendein Request rausgeht, wird die Zieladresse aufgelöst und gegen private IP-Bereiche geprüft. Verweist die Domain auf 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1, IPv6-Loopback oder andere reservierte Bereiche, bricht der Trace ab. Das verhindert, dass das Tool als Sprungbrett zu internen Diensten missbraucht wird.
Pro Hop ein eigener Request mit explizitem CURLOPT_RESOLVE, damit Host und IP konsistent bleiben. Auto-Redirect ist deaktiviert, damit jeder Hop einzeln sichtbar wird. Bei jedem Schritt: Status, Header, TTFB, TLS-Info. Kommt ein Status 3xx mit Location-Header, geht die Reise zur nächsten Stufe.
Für jeden in der Chain besuchten Host wird die robots.txt einmalig abgeholt, geparst und auf den Final-Pfad angewendet. Anschließend wird jeder von 56 Crawlern in der Datenbank gegen die parsed Regeln gematcht. Die Bot-Matrix zeigt pro Bot: erlaubt, blockiert, welche Regel gegriffen hat und welche User-Agent-Gruppe ihn betroffen hat.
Du hast die Site auf eine neue Domain oder Struktur umgezogen und willst sicherstellen, dass alte URLs sauber per 301 auf die neue Final-URL gehen, ohne mehrfache Zwischenstationen oder Loops.
Vor jedem größeren Release prüfst du die wichtigen Landing-Pages. trace zeigt dir, ob HSTS, CSP und Co. korrekt gesetzt sind, ob die Cache-Header sinnvoll konfiguriert sind und ob keine Cookies an unerwarteten Stellen gesetzt werden.
Du willst Klarheit, ob GPTBot, ClaudeBot, PerplexityBot und Bytespider deine Inhalte trainieren dürfen. trace zeigt dir den Ist-Zustand, die Bot-Datenbank unter /bots hilft dir, eine bewusste Entscheidung zu treffen.
Wenn ein Set-Cookie auf dem falschen Host gesetzt wird oder das SameSite-Flag fehlt, sieht man das in der Chain sofort. Auch versehentlich doppelt gesetzte Cookies werden sichtbar.
Du willst wissen, was eine Konkurrenz-Site macht: welche Crawler sie zulässt, ob sie Sitemaps publiziert, ob sie HTTP/3 nutzt, ob sie sauber 301 statt 302 redirectet.
Im Recon: Welche TLS-Cert-Issuer? Welche Server-Banner? Welche security-relevanten Header fehlen? trace gibt dir die Antworten ohne Browser-Setup, mit klassifizierter Header-Tabelle.
Wenn dir einer der Begriffe in der Ergebnisansicht fremd ist, hier die Kurzdefinition. Im Zweifel ist die Quelle immer der jeweilige RFC oder die MDN-Doku.
Webserver leiten aus vielen Gründen weiter: HTTP zu HTTPS, www zu non-www (oder umgekehrt), Sprachversion, Login-Wall, Mobile-Variante, alte URL auf neue Struktur, Tracking-Parameter normalisieren. Jede dieser Stufen ist ein eigener HTTP-Request mit eigenen Headern und eigener Antwortzeit. trace zeigt jede Stufe einzeln, damit du sehen kannst, ob eine davon unnötig ist (jeder zusätzliche Hop kostet Ladezeit, Crawl-Budget bei Suchmaschinen und Klick-Verluste auf Mobile).
301 ist die permanente Weiterleitung. Suchmaschinen übernehmen die neue URL in den Index und droppen die alte. 302 ist temporär. Die alte URL bleibt im Index, weil der Server sagt: "kommt gleich zurück". 307 ist wie 302, aber zwingt den Client, die HTTP-Methode beizubehalten (ein POST bleibt ein POST, statt zu GET zu werden). 308 ist wie 301, ebenfalls mit Methoden-Erhalt. Faustregel: Wer dauerhaft umzieht, nimmt 301 oder 308. Wer nur kurzzeitig umleitet, 302 oder 307. Eine 302 dort einzusetzen, wo eigentlich 301 hingehört, kostet messbar Sichtbarkeit.
curl -L -v zeigt dir die Kette und die Header. trace zeigt dir zusätzlich pro Hop die TLS-Info (Issuer, Restlaufzeit), klassifiziert die Header farblich (Security, Cache, Cookie, Meta), erkennt Loops, holt auf jeder besuchten Domain die robots.txt und wertet sie automatisch gegen 56 bekannte Bots aus. Du sparst dir das Parsen von Hand und siehst sofort, wo Probleme stecken.
Nein. Es gibt keinen Cache, kein Logging der eingegebenen URLs, keinen Account, keine Cookies, keine Tracker. Der Server führt jeden Trace frisch aus und vergisst ihn danach. Falls du die Anfrage nochmal sehen willst, ist sie als URL-Parameter in der Adresszeile, kopierbar und teilbar.
Aus Sicherheitsgründen (SSRF-Schutz). Würde das Tool private IPs aufrufen, könnte jemand es als Proxy missbrauchen, um aus dem Internet auf interne Server-Endpunkte zuzugreifen, die normalerweise nicht erreichbar sind. trace lehnt deshalb 127.0.0.1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, IPv6-Loopback und alle reservierten Bereiche ab.
Google folgt bis zu 10 Hops, danach gilt die URL als nicht erreichbar und fällt aus dem Index. Aus User-Sicht: jeder Hop kostet zwischen 50 und 400 ms je nach Verbindung. Ab drei Stufen merkst du das messbar im Lighthouse-Score. Ideal ist genau eine Stufe: nicht-kanonische URL leitet einmal direkt auf die kanonische Final-URL, ohne Zwischenstationen.
Drei Fälle: (1) Es gibt eine User-agent: *-Gruppe mit Disallow: / und keine bot-spezifische Allow-Regel. (2) Der Bot hat eine eigene Gruppe, die ihn explizit blockiert. (3) Die Pfad-Regel matcht über Wildcards (zum Beispiel Disallow: /api/ blockiert auch /api/v2/data). trace zeigt in der Spalte "Regel" genau, welche Zeile der robots.txt für das Verdict verantwortlich ist.
Ja. Das Tool nutzt curl mit aktuellem Protokoll-Auto-Negotiation. In jedem Hop steht in der HTTP-Spalte, welches Protokoll tatsächlich verwendet wurde (HTTP/1.1, HTTP/2 oder HTTP/3). HTTP/3 (QUIC) wird unterstützt, sofern der Zielserver es per Alt-Svc-Header anbietet und curl die Verbindung nicht im Voraus festlegt.
Nein. trace ist ein reiner HTTP-Client wie curl. Kein Cookie-Jar, kein Browser, kein JavaScript. Du siehst die Set-Cookie-Header genau so, wie der Server sie sendet, aber sie werden nicht persistiert oder beim nächsten Hop mitgeschickt. Für Audits, die Browser-Verhalten brauchen (Web Vitals, Render-Pfad), ist das Schwester-Tool unter dev.crawlerbase.de zuständig.
Aktuell nicht. Die Eingabe läuft über den GET-Parameter url, das Ergebnis ist HTML. Eine JSON-Schnittstelle ist geplant, sobald sich das Tool stabilisiert. Wenn du das brauchst, schreib eine Mail an info@crawlerbase.de.