Doku

SEO-Audit

Crawle die Website eines Kunden mit unserem eigenen Crawler, sieh zuerst, ob KI-Crawler sie erreichen und lesen können, und behebe die Probleme in der Reihenfolge dessen, was die betroffenen Seiten wert sind.

Was das SEO-Audit macht

Das SEO-Audit crawlt die eigene Website eines Kunden und prüft jede Seite, die es erreicht, mit 189 Prüfungen. Öffne einen Kunden und wähle SEO-Audit unter Website & Crawler. Die KI-Suche kommt zuerst: ob KI-Crawler die Seiten laut robots.txt abrufen dürfen, ob eine Firewall sie abweist, obwohl robots.txt sie erlaubt (wir senden dazu eine Testanfrage an die Startseite mit dem veröffentlichten User-Agent jedes KI-Crawlers), ob die Server-Logs zeigen, dass sie abgewiesen werden, und ob die Seiten, die KI-Antworten schon zitieren, noch funktionieren. Danach folgen die klassischen Prüfungen: Crawlbarkeit und Indexierbarkeit, Weiterleitungen, Canonicals, Titel und Meta-Angaben, Inhalt, interne Links, Sitemaps, HTTPS, internationale Einstellungen, strukturierte Daten, Performance und HTML. Jedes Problem wird danach geordnet, was die betroffenen Seiten dem Kunden wert sind, nicht danach, wie viele Seiten es trifft. Jede Prüfung nennt die Grundlage, auf der sie steht (ein Standard oder die Dokumentation einer Plattform, eine sich herausbildende Konvention oder eine Heuristik), und eine Quelle zum Nachlesen; nur dokumentiertes Verhalten kann einen Fehler ergeben. Eine korrekte Konfiguration ist nie ein Befund, und eine Seite, die wir nicht messen konnten, gilt als nicht ausgewertet statt als fehlerhaft. Das GEO-Audit bleibt ein eigenes Werkzeug: Es bewertet in Sekunden eine kleine Auswahl von Seiten auf ihre Bereitschaft für die KI-Suche. Das SEO-Audit ist ein vollständiger Crawl.

Ein Audit starten

Klick auf Audit starten. Beim ersten Mal bestätigst du, dass du berechtigt bist, die Website im Auftrag ihres Inhabers zu prüfen; die Bestätigung wird mit Person, Zeitpunkt und Host gespeichert und erneut verlangt, wenn sich die Website des Kunden ändert. Gecrawlt wird nur die eigene Website des Kunden, mit und ohne www. Die Start-URL kann jede https-Seite darauf sein; leitet die Startseite auf eine andere Website weiter, endet der Crawl. Unter Einstellungen listet „Ignorierte Parameter“ bis zu 100 Namen von URL-Parametern, einen pro Zeile, wie eine Parameterregel in anderen Crawlern. Findet der Crawler eine URL mit einem davon, in einem Link, einer Sitemap, der Search Console oder anderswo, crawlt er sie ohne ihn: Steht topic in der Liste, sind /contact/?topic=a und /contact/?topic=b eine Seite, /contact/, einmal abgerufen und einmal gezählt. Groß- und Kleinschreibung spielt bei den Namen keine Rolle, der Wert nie, page entfernt also page=1, page=2 und jeden anderen Wert. Die URL fällt nie weg, nur der Parameter, und die Start-URL wird so gecrawlt, wie du sie eingegeben hast. „Gängige Tracking-Parameter hinzufügen“ trägt die UTM-Parameter und die Klick-IDs von Google, Meta und Microsoft ein. Die Liste ist standardmäßig leer, ignoriert wird also nur, was du einträgst; sie kostet nichts, gilt ab dem nächsten Crawl, und jeder Crawl behält die Liste, mit der er gelaufen ist. Unser Crawler gibt sich als CrunchJunkieSiteAudit zu erkennen, liest robots.txt vor jeder Seite, hält sich daran (es gibt keine Ausnahme), ruft höchstens eine Seite pro Sekunde ab und folgt einem Crawl-delay von bis zu 10 Sekunden. Er speichert, was das Audit braucht, etwa Statuscodes, Titel und Links, und nie den Text der Seiten. Nach den Seiten prüft er die Skripte, Stylesheets und Bilder, die sie verwenden, und die externen Seiten, auf die sie verlinken, mit je einer leichten Anfrage, auf einer anderen Website nur, was deren robots.txt erlaubt. Unter crunchjunkie.io/bot beschreiben wir den Crawler für Website-Inhaber und wie man ihn zulässt oder sperrt. Antwortet die Firewall einer Website mit 429 oder 503, wird der Crawler langsamer und wartet, wie die Website es verlangt, jeweils bis zu 10 Minuten, und der laufende Crawl sagt das: Bleibt er langsam, bitte den Hoster, den User-Agent CrunchJunkieSiteAudit vom Rate-Limit auszunehmen; der Abschnitt zum Zulassen unseres Crawlers auf dieser Seite hilft dabei. Ein Crawl, der die Website nicht messen kann, endet und sagt warum: robots.txt antwortet mit einem Serverfehler (nach RFC 9309 gilt die ganze Website dann als gesperrt), statt der Website erscheint eine Platzhalterseite des Hosters, oder mehr als 20 % der letzten Anfragen werden abgewiesen. Stoppen beendet einen laufenden Crawl und behält und analysiert, was er bis dahin abgerufen hat. Die Seiten sind in deinem Tarif enthalten, berechnet wird nichts. Jeder Workspace hat ein Seitenkontingent pro Abrechnungszeitraum (ohne Abonnement der Kalendermonat in UTC): Solo 5.000, Starter 25.000, Pro 100.000, Agency 250.000, Scale 1.000.000 Seiten. Eine Testphase hat 1.000 Seiten, höchstens 500 pro Crawl. Jede interne Seite, die wir abrufen, zählt, egal was sie antwortet; URLs, die robots.txt sperrt, Skripte, Stylesheets, Bilder, externe Links und der Test mit den KI-Crawlern zählen nicht. Ein Crawl reserviert beim Start sein Seitenlimit und gibt am Ende zurück, was er nicht gebraucht hat; ein Crawl, der nicht in den Rest passt, kann also nicht starten. Ein Crawl ruft höchstens 5.000 Seiten ab und ein Kunde kann 5-mal pro Tag (UTC) geprüft werden; der Dialog von Audit starten zeigt das Seitenlimit, das restliche Kontingent und das Ende des Zeitraums.

Website-Zustand und Zustand in der KI-Suche lesen

Der Website-Zustand ist der Anteil der Seiten ohne Fehler: Seiten ohne Fehler geteilt durch die ausgewerteten Seiten, einmal über den ganzen Crawl gerechnet und immer mit beiden Zahlen und dem Datum des Crawls angezeigt („1.018 von 1.240 Seiten ohne Fehler“). Eine Seite ist ausgewertet, wenn wir sie abgerufen haben und sie geantwortet hat, mit welchem Status auch immer. URLs, die robots.txt für uns sperrt oder die unseren Crawler abweisen, bleiben draußen und werden neben dem Wert gezählt, denn eine Seite, die wir nicht sehen konnten, ist nicht durchgefallen. Warnungen und Hinweise verändern den Wert nie. Der Zustand in der KI-Suche ist derselbe Anteil, nur über die Fehler der KI-Suche. Die beiden werden nie zu einer Zahl gemittelt, und mit dem GEO-Score auch nicht. Fehler, die die ganze Website betreffen, etwa ein abgelaufenes Zertifikat, robots.txt mit einem Serverfehler oder eine Firewall, die KI-Crawler abweist, stehen neben den Werten, statt als Seiten gezählt zu werden; in der Liste der Probleme kommen sie immer zuerst.

Prioritäten und was die Seiten wert sind

Jede Seite bekommt eine Wertstufe. Eine Schlüsselseite (V1) ist die Startseite, eine Seite, die eine KI-Antwort in den letzten 30 Tagen zitiert hat, eine der kleinsten Gruppe von Seiten, die 80 % der Google-Klicks des Kunden in 28 Tagen bringt, oder eine Seite in den Top 10 für ein verfolgtes Keyword im letzten Lauf des Rank-Trackers. V2 ist jede Seite mit Impressionen in der Search Console, einer Position in den Top 20, Besuchen von KI-Crawlern in den Server-Logs oder einem Platz in einer Sitemap; V3 ist der Rest. Ohne Search Console oder Daten zur KI-Sichtbarkeit ergeben sich die Stufen nur aus der Struktur der Website, und die Seite sagt das. P1 ist ein Fehler auf einer Schlüsselseite oder ein Fehler, der die ganze Website betrifft, P2 ein Fehler auf einer anderen Seite oder eine Warnung auf einer Schlüsselseite, P3 alles andere. Ein Problem bekommt die beste Priorität seiner Seiten, und die Probleme sind nach Priorität sortiert, dann nach den Google-Klicks auf den betroffenen Seiten, dann nach den KI-Antworten, die sie zitieren, dann nach der Zahl der betroffenen Seiten. Jedes Problem sagt in einer Zeile, warum es dort steht. Die Wertspalten beziehen sich auf die betroffenen Seiten und sind nie das, was eine Behebung zurückbrächte: Google-Klicks und Impressionen aus der Search Console über 28 Tage (pazifische Tage, mit den gelesenen Properties), KI-Antworten, die die Seiten zitieren, über die letzten 30 ganzen UTC-Tage (jede Antwort einmal gezählt, auch wenn sie zwei betroffene Seiten zitiert; es zählen nur Engines, die Seiten nennen, Gemini nennt Websites und bleibt deshalb draußen) und verfolgte Keywords in den Top 20 im letzten Lauf des Rank-Trackers. Jeder Wert trägt sein Zeitfenster und seine Basis. Eine nicht verbundene Quelle zeigt „Nicht verbunden“, nie null. Die Daten werden ohne die Parameter zugeordnet, deshalb werden die Zahlen einer Seite einmal gezählt, auf einer URL: der URL ohne Parameter oder, wenn nur Parameter-Varianten gecrawlt wurden, einer davon. Jede andere Parameter-Variante (etwa /check?domain=x), ob abgerufen oder durch robots.txt gesperrt, und eine Seite, die auf eine andere URL derselben Seite kanonisiert ist, zeigen keine eigenen Zahlen; die Seite nennt die URL, auf der sie gezählt werden. Eine solche Variante ist nie eine Schlüsselseite und löst kein Problem aus, das auf ihrem Wert beruht, etwa „Durch robots.txt gesperrt, aber mit Such- oder KI-Traffic“; eine einfache Sperre durch robots.txt wird weiter gemeldet.

Probleme, Seiten und Vergleich

Die Übersicht zeigt beide Werte, die Fehler der ganzen Website, was sich seit dem vorherigen Crawl geändert hat, die Klicks auf Seiten mit Fehlern, die Probleme, die zuerst zu beheben sind, und eine Karte pro Kategorie. Probleme listet jedes Problem mit Filtern nach Kategorie, Schweregrad und Priorität; öffne eines, um zu sehen, was es ist, warum es wichtig ist, wie man es behebt, worauf die Prüfung beruht und ihre Quelle, dazu die betroffenen Seiten mit ihren Werten und dem Detail jedes Befunds, etwa Ziel und Ankertext eines defekten Links oder die Schritte einer Weiterleitungskette. Hinweise sind Information und zählen in keinem Wert. Seiten listet jede URL des Crawls mit Status, Indexierbarkeit, Klicktiefe, Links auf sie, Problemen, Wertstufe und Werten, mit Filtern und einer Seitenansicht, die zeigt, welche robots.txt-Regel jeder KI-Crawler auf ihr trifft. Beide Listen lassen sich als CSV exportieren, mit den Zeitfenstern der Werte in der Datei. Auch die gemeldeten Probleme lassen sich exportieren, alle im Tab „Probleme“ oder ein einzelnes Problem in seinem eigenen Bereich, als CSV, Excel oder PDF. Die CSV- und Excel-Dateien führen jede betroffene Seite mit dem auf, was der Crawl dort gefunden hat, und behalten stummgeschaltete und ignorierte Probleme, mit ihrem Grund gekennzeichnet. Das PDF ist ein lesbarer Bericht in deiner Sprache: die ersten 20 Seiten jedes Problems (bei einem einzelnen Problem bis zu 500), jeder Wert mit seinem Zeitraum und ein Hinweis, dass die vollständige Liste im CSV oder in der Excel-Datei steht. Vergleich stellt einen Crawl dem vorherigen Crawl desselben Umfangs gegenüber, also mit derselben Start-URL, demselben Gerät und denselben ignorierten Parametern. Dieser vorherige Crawl ist der letzte, der zu Ende gelaufen ist; ein gestoppter Crawl zählt nur, wenn es keinen vollständigen gibt. Auch Übersicht, Berichte und der Assistent zeigen den letzten vollständigen Crawl, und die Übersicht weist darauf hin, wenn ein späterer gestoppt wurde. Ein Problem gilt nur als behoben, wenn seine Seite in beiden Crawls geprüft wurde und jetzt besteht; eine Seite, die der neue Crawl nicht geprüft hat, ist nicht erneut geprüft, nie behoben, und ein Problem auf einer Seite, die der frühere Crawl nie erreicht hat, steht auf neu geprüften Seiten, nie als neu. Crawls mit anderem Umfang sind nicht vergleichbar, und die Seite nennt den Grund statt Zahlen. Die Seitendetails werden für die letzten Crawls aufbewahrt; ältere Crawls behalten ihre Zusammenfassung.

Googles Sicht und der Monitor

Die Core Web Vitals stammen aus dem Chrome UX Report: das 75. Perzentil echter Chrome-Nutzer über 28 Tage, für die URL oder, wenn sie zu wenig Traffic hat, den ganzen Origin, und jeder Wert sagt, welche Ebene und welche Daten er meint. Verlauf zeigen liest die Historie live und speichert sie nicht; PageSpeed Insights läuft auf Klick (20 am Tag pro Kunde), und nur der Wert wird behalten. Ohne eingerichteten Schlüssel sagt das Audit das und zeigt keinen Wert. Die URL-Prüfung liest Googles Urteil und Canonical über die eigene Search Console des Kunden, bis zu 100 der wertvollsten Seiten pro Crawl und mehr auf Klick. Sie nutzt die 2000 Prüfungen am Tag dieser Property, die sich der Kunde mit seinen anderen Tools teilt. Bings aktuelle Crawling-Probleme kommen aus den Bing Webmaster Tools, wenn sie verbunden sind. All diese Prüfungen beruhen auf einer Stichprobe oder einem anderen Dienst, sie werden also gelistet und priorisiert, zählen aber nie in der Site Health oder AI Search Health; was nicht lief, gilt als nicht geprüft, nie als behoben. Der Monitor für Schlüsselseiten ist standardmäßig aus und prüft ausgewählte Seiten täglich (ab Pro stündlich) gegen ihre letzte Antwort, unter derselben robots.txt und im selben Tempo, außerhalb des Seitenkontingents. Ein verlorener Status, ein neues noindex, ein geänderter Canonical oder eine neu durch robots.txt gesperrte Seite löst ein Signal aus, ein geänderter Titel oder eine geänderte H1 ein leiseres; eine Prüfung ohne Antwort ändert nichts, und ein Serverfehler zählt erst, wenn die nächste Prüfung ihn wiederholt. Prüfungen bleiben 90 Tage gespeichert.

Wenn die Website das Audit bremst oder abweist

Eine Website kann sich gegen einen Crawler wehren. Antwortet sie auf unsere Anfragen mit 429 (zu viele Anfragen) oder 503 und lässt den Crawler warten, wird das Audit langsamer und pausiert wie verlangt, dauert also länger, und der Crawl führt zur Information „Die Website hat unseren Crawler gebremst“ (site_rate_limited) auf. Der Website wird auf den Seiten dafür nichts angerechnet, und das Audit kann nicht sehen, welches Limit KI-Crawler bei derselben Website erreichen. Eine abgewiesene oder mit einer Challenge beantwortete Anfrage erscheint als abgewiesen, nie als defekte Seite, und ein Crawl hält an, wenn mehr als 20 % der letzten Anfragen abgewiesen werden. Damit unser Crawler durchkommt, erlaube in der Firewall, dem CDN oder dem Sicherheits-Plugin, das das Limit setzt, Anfragen, deren User-Agent CrunchJunkieSiteAudit enthält (zum Beispiel Imunify360, Cloudflare oder ein WordPress-Sicherheits-Plugin). Unsere Anfragen kommen von wechselnden Cloud-Adressen, erlaube also nach User-Agent, nicht nach IP-Adresse. So erlaubst oder sperrst du unseren Crawler zeigt den User-Agent, den Umgang mit der robots.txt und die Regel, die du ergänzt.

Mit den Ergebnissen arbeiten

Schalte ein Problem stumm oder ignoriere es (Stummschalten oder ignorieren), für die ganze Website oder eine Seite, mit einer Begründung, die dein Team lesen kann. Ein stummgeschaltetes Problem verschwindet aus den Listen, aus den zuerst zu behebenden Problemen und aus seinen Signals; im Website-Zustand und im Zustand in der KI-Suche zählt es weiter. „Aufgabe anlegen“ macht aus einem Problem eine Aufgabe unter Freigaben, mit Verantwortlichem, Fälligkeit und den Seiten, die sie nennt; es wird nichts verschickt. „Lösung mit Crunch entwerfen“ schreibt die genaue Lösung für ein Problem auf einer Seite (ein Tag, einen JSON-LD-Block, robots.txt-Zeilen, eine Weiterleitungsregel) aus dem, was der Crawl gespeichert hat, und nur, wenn du klickst. Der Entwurf behauptet nie, dass die Lösung Rankings oder Zitate steigert, und markiert jeden Wert, den er nicht kennen kann, mit einem Platzhalter. Jeder Entwurf verbraucht eine Ask-Crunch-Nachricht aus dem Monatskontingent deines Tarifs und zählt nie gegen deine Checks. Als Sicherheitsgrenze gelten 60 Entwürfe pro Workspace und Tag; mit deinem eigenen KI-Schlüssel gibt es keinen Zähler. Ein Zeitplan ist aus, bis jemand ihn einschaltet. Du wählst wöchentlich oder monatlich, einen Tag und eine Stunde in UTC und bestätigst die Grenze pro Crawl und das Höchste, was ein Monat davon verbrauchen kann; die Einstellungen zeigen beides vor dem Speichern. Ein geplanter Crawl läuft innerhalb dieser Grenze und nie über das Seitenkontingent hinaus; ein Termin, den das restliche Kontingent nicht ganz abdeckt, fällt aus, statt gekürzt zu werden, und ein Hinweis sagt es dir. Nach jedem Crawl löst das Audit Signals aus, mit beiden Crawl-Daten und den ausgewerteten Seiten als Basis: neue Fehler auf Schlüsselseiten, ein Rückgang des Website-Zustands um 5 Punkte oder mehr zwischen zwei vollständigen Crawls desselben Umfangs mit jeweils mindestens 50 ausgewerteten Seiten, ein auf Schlüsselseiten gesperrter KI-Crawler, eine zitierte Seite, die nicht mehr funktioniert, ein Crawl, den die Website abgewiesen hat, ein bald ablaufendes Zertifikat und ein geplanter Crawl, der mangels Seiten ausgefallen ist. Ein anhaltender Zustand, den der nächste vollständige Crawl nicht mehr findet, wird aufgelöst. Automationen können auf alle reagieren.

In Berichten

SEO-Audit ist eine Berichtsquelle im Builder und in „Mit KI entwerfen“, gleich dargestellt in der App, über einen geteilten Link und im PDF, in der Sprache des Berichts und in einem White-Label-Bericht ohne unsere Marke. Die KPIs sind Website-Zustand und Zustand in der KI-Suche mit ihrem n, die ausgewerteten Seiten, die Probleme mit Fehler und mit Warnung, die seit dem vorherigen Crawl behobenen und neuen Probleme und die Google-Klicks auf Seiten mit Fehlern mit ihrem Zeitfenster. Das Diagramm zeigt den Website-Zustand pro Crawl, daneben den Zustand in der KI-Suche. Die Tabellen sind die wichtigsten Probleme, was seit dem vorherigen Crawl behoben wurde, der Zugang der KI-Crawler (robots.txt und unsere Testanfrage je Crawler) und zitierte Seiten mit Problemen. Ein Bericht startet nie einen Crawl. Er liest den letzten abgeschlossenen Crawl bis zum Ende des Berichtszeitraums und nennt dessen Datum mit „Stand“; eine Veränderung zeigt er nur gegenüber einem Crawl desselben Umfangs. SEO-Audit ist kein Kanal und gehört deshalb nie zu „Alle Kanäle“.

Mit einem Assistenten (MCP) oder der REST-API

Der Connector gibt einem Assistenten sieben lesende Tools: get_site_audit, list_site_audit_issues, get_site_audit_issue, list_site_audit_pages, get_site_audit_page, compare_site_audits und get_site_audit_history. get_site_audit_issue liefert außerdem die Fakten und Regeln, die der Entwurf in der App nutzt, sodass dein Assistent die Lösung selbst entwerfen kann, ohne einen zweiten KI-Aufruf. Fünf Tools ändern etwas und zeigen eine Vorschau, bevor etwas passiert: run_site_audit, stop_site_audit, update_site_audit_settings, set_site_audit_issue_status und create_site_audit_task. run_site_audit braucht zusätzlich den Schalter „Aktionen erlauben, die KI verbrauchen“ unter Einstellungen → KI-Assistenten verbinden (MCP), weil es einen Crawl startet, der dein Seitenkontingent verbraucht: Die Vorschau nennt die Seiten, das restliche Kontingent und das Ende des Zeitraums. Der geführte Prompt site_audit_triage macht aus dem letzten Crawl eine geordnete Liste der Lösungen. Die REST-API (v1, Lesezugriff) hat dieselben Abfragen unter /api/v1/clients/{id}/seo-audit: das Audit, die Probleme, ein Problem, die Seiten, eine Seite (pages/detail?url=), den Vergleich und den Verlauf.