SEO-Audit: So gehe ich bei einem Audit Ihrer Website Schritt für Schritt vor

Ein SEO-Audit ist die Entscheidung, was auf der Website zuerst zu verbessern ist, mit einem Beleg bei jeder Empfehlung und mit einer Prüfung nach der Umsetzung. Die Fehlerliste aus einem Tool ist erst das Material für ein Audit. Das technische Audit ist der Teil, der prüft, ob die Crawler der Suchmaschinen und der KI-Assistenten die Website abrufen und lesen können und ob die Suchmaschine sie indexieren kann.

Ein Audit führe ich in acht Schritten durch:

1. Ich kläre Ziel und Lage der Website, bevor ich den Crawler starte, also das Programm, das die Website durchläuft wie ein Roboter der Suchmaschine.
2. Ich prüfe, ob die Crawler die Website überhaupt erhalten.
3. Ich sammle Daten aus mehreren Quellen und prüfe, was jede von ihnen nicht sieht.
4. Ich untersuche Suchbegriffe und Google-Ergebnisse, bevor ich mich mit der Technik befasse.
5. Ich gehe die Website nach einem Problemkatalog mit Bedingungen für die Priorität durch.
6. Ich zeige bei jedem Punkt einen Beleg.
7. Ich lege Reihenfolge, Aufwand und Varianten fest.
8. Ich gebe das Ergebnis in die Gegenprüfung, und nach der Umsetzung prüfe ich jeden Punkt.

Was ist ein SEO-Audit und wie unterscheidet es sich vom technischen Audit?

Ein SEO-Audit sagt, in welchem Zustand eine Website ist und was ihre Sichtbarkeit begrenzt, und ein technisches Audit prüft, ob die Suchmaschine die Website abrufen, rendern und indexieren kann. In einem vollständigen Audit prüfe ich Technik, Architektur und Inhalt der Seiten, Suchbegriffe, externe Links und Wettbewerb, und am Ende lege ich die Reihenfolge der Maßnahmen fest. Ein technisches Audit genügt, wenn die Frage technisch ist: Einbruch nach einem Release, Migration, Seiten, die aus dem Index fallen.

Das Audit ist der Input für die Strategie und nicht die Strategie. Die Strategie sagt, um welche Nachfrage Sie kämpfen und worauf Sie verzichten, und das Audit sagt, was dem heute im Weg steht. Im Text zur SEO-Strategie habe ich beschrieben, wie das eine in das andere übergeht.

Wie führe ich ein SEO-Audit Schritt für Schritt durch?

Die Reihenfolge der Schritte ist wichtig, denn die früheren Schritte entscheiden, ob die Zahlen aus den späteren glaubwürdig sind. An zwei Stellen halte ich den Prozess für eine Entscheidung an: Nach dem ersten Schritt lege ich den Umfang fest, und nach der Gegenprüfung, vor dem Versand an den Kunden, prüfe ich Prioritäten und Thesen.

Schritt 1. Ziel und Lage der Website, bevor ich den Crawler starte

Die erste Frage lautet, ob die Website Traffic verliert oder keinen aufbaut, denn von der Antwort hängt das ganze Audit ab. Eine Website ohne Sichtbarkeit braucht zuerst eine Zuordnung der Suchbegriffe zu den Seiten, die die jeweiligen Suchanfragen beantworten sollen. Eine Website mit Sichtbarkeit braucht zuerst den Schutz dessen, was bereits Positionen belegt, bevor jemand anfängt, sie zu verbessern.

Vor dem Start frage ich nach Dingen, die kein Tool zeigt. Welche Produkte oder Dienstleistungen verdienen Geld, ist ein Wechsel des Content-Management-Systems oder ein Umbau geplant, wer setzt die Empfehlungen um und wie viel Zeit hat er dafür. Aus den Antworten ergeben sich der Umfang des Audits und die Liste der Dinge, die ich nicht ausarbeite, weil sie niemand umsetzt.

Diese Phase sollte man selbst durchlaufen, auch wenn viele Fachleute sie heute einem Sprachmodell überlassen. Ein Sprachmodell ist manchmal hilfreich, versteht aber das Geschäft des Kunden nicht. Den kreativen, einzigartigen Blick, den ein erfahrener SEO-Experte mitbringt, liefert es auch nicht.

Schritt 2. Erhalten die Crawler die Website überhaupt

Bevor ich eine Zahl aus einem Tool lese, prüfe ich, ob der Server Crawler hereinlässt, denn ein blockierter Crawler liefert Daten, die wie SEO-Probleme aussehen. In einer Woche im Juli 2026 erwiesen sich drei „SEO-Probleme“ auf drei verschiedenen Websites als Sperre von Crawlern:

1. Eine Website „verlor“ über 2.200 Links, weil die Seiten, von denen sie ausgingen, hinter einer Firewall lagen, die den Crawler des Tools zur Linkanalyse abwies.
2. Ein Shop hatte in einem Tool einen Gesundheitswert von 0 bei fast 42.000 Fehlern, weil der Crawler des Tools statt der Seiten die Antworten der Cloudflare-Firewall erhielt.
3. Auf einer dritten Website hielt eine Sperre den Crawler bei der ersten Adresse an, und drei Wochen lang bemerkte es niemand.

Dieselbe Adresse rufe ich als gewöhnlicher Browser und als Crawler von Google, Bing, OpenAI, Perplexity und Anthropic ab und vergleiche dann Antwortcodes und Größe der Seite. Der Unterschied zwischen Browser und Crawler ist das Erste, was ich klären muss, bevor ich irgendetwas zähle. Ein solcher Test sendet Anfragen von meiner IP-Adresse unter dem Namen des Crawlers, und Firewalls erkennen die echten Crawler von Google und Bing an der Adresse, von der sie kommen. Eine Sperre des „Googlebots“ im Test beweist also keine Sperre des echten Googlebots. Die Search Console, das kostenlose Google-Panel für Website-Betreiber, zeigt, wie der echte Googlebot die Website sieht.

Die Datei robots.txt lese ich bis zum Ende mit einem Parser, also einem Programm, das die Regeln wie ein Crawler anwendet, und nicht mit dem Auge. Der Google-Crawler wendet nur eine Gruppe von Regeln an, die mit dem am besten passenden Namen des Crawlers, und ignoriert die übrigen. Eine Regel Disallow: ohne Pfad blockiert nichts (Google Search Central). Im August 2026 ergab sich aus einem Ausschnitt der robots.txt einer Website, dass sie Google blockiert. Der Parser zeigte, dass der Googlebot vollen Zugriff hatte und die Crawler von Bing und der KI-Assistenten blockiert waren. Die Diagnose war also eine andere: Das Problem betraf Bing und die KI-Crawler und nicht Google.

Eine fehlende robots.txt blockiert Google nicht, aber nach jedem Release prüfe ich, ob die Datei nicht verschwunden ist. Google behandelt einen 4xx-Fehler bei der robots.txt (außer 429) so, als gäbe es die Datei nicht, also ohne Einschränkungen (Google Search Central). Meine Website lieferte im August 2026 einen 404-Fehler bei der robots.txt, bevor ich das korrigiert habe.

Schritt 3. Daten aus mehreren Quellen und das, was jede nicht sieht

Jede Zahl aus dem Crawler ist eine Hypothese, bis eine zweite Quelle sie bestätigt. Ich sammle einen Crawl mit und ohne JavaScript sowie Geschwindigkeitsdaten echter Nutzer aus dem CrUX-Bericht. Dazu nehme ich das Linkprofil und die Google-Ergebnisse für wichtige Suchbegriffe vom Tag der Messung. Im Text zum Linkbuilding habe ich beschrieben, wie ich das Linkprofil vor dem Plan einer Kampagne prüfe. Bei jeder Datei halte ich Quelle, Datum und Umfang fest, damit sich nach einem Monat jede Zahl nachvollziehen lässt.

Daten aus der Search Console rufe ich über die API ab, also die Schnittstelle für den automatischen Datenabruf, weil der Export aus dem Panel die Liste auf 1.000 Zeilen kürzt. Die API liefert bis zu 50.000 Zeilen pro Tag für jeden Ergebnistyp, zum Beispiel getrennt für Ergebnisse von Seiten, Bildern und Videos (Google, Search-Console-Hilfe). Im Text zu KI-Tools für SEO habe ich gezeigt, wie ein gekürzter Export die CTR einer Website zu hoch erscheinen ließ.

Ein Crawler kann die Größe einer Website zu niedrig ausweisen, deshalb prüfe ich die Zahl der Seiten und Produkte in einer zweiten Quelle. In zwei Shops kam der Crawler bis zur ersten Seite der Produktliste in einer Kategorie und ging nicht weiter, obwohl die folgenden Seiten der Liste funktionierten und nicht blockiert waren. In einem Shop fand er weniger als die Hälfte der Produkte, im anderen weniger als ein Drittel. Hätte ich diese Zahlen als Zustand der Shops genannt, hätte das Audit Lücken im Angebot beschrieben, die es nicht gab.

Plötzliche Änderungen in den Tagesdaten beschreibe ich, bevor ich ihnen eine Ursache zuschreibe. Das tue ich für Klicks, Impressionen, Positionen, Sitzungen und Abrufe des Google-Crawlers. Ich suche Tage, ab denen sich der Median aus sieben aufeinanderfolgenden Tagen um mindestens 25 % vom Median der vierzehn Tage davor unterscheidet. Zu jedem solchen Datum halte ich eine Erklärung fest: Release, Google-Update, Ausfall, Änderung der Messung oder „Ursache unbekannt“. Die Beschreibung der Daten liefert Hypothesen, und die Ursache nenne ich erst, nachdem ich andere mögliche Erklärungen geprüft habe.

Schritt 4. Suchbegriffe und Google-Ergebnisse vor der Technik

Zuerst suche ich Chancen, danach behebe ich Fehler. Ein Teil der technischen Probleme lässt sich nur vor dem Hintergrund der Suchbegriffe beurteilen: ob ein Filter im Shop indexiert werden sollte, ob ein Tag eine eigene Seite verdient, ob zwei Seiten wirklich um dasselbe konkurrieren. Im Katalog sind 32 Problemtypen so gekennzeichnet, dass sie sich ohne Analyse der Suchbegriffe und der Google-Ergebnisse nicht beurteilen lassen.

Eine fehlende Seite für einen wichtigen Suchbegriff ist eines der häufigeren Probleme in meinen Audits: 15 von 63 Audits, auf 14 von 50 Websites. Der Crawler meldet es nicht von allein, denn er ruft nur Seiten ab, die existieren. Sichtbar wird es erst, wenn ich die Nachfrage mit der Liste der Adressen abgleiche und damit, welche Seiten der Wettbewerber in den Ergebnissen erscheinen.

Schritt 5. Durchsicht nach dem Katalog mit Bedingungen für die Priorität

Derselbe Fehler hat eine hohe oder niedrige Priorität, je nachdem, wo er auftritt. Ein interner Link auf eine Adresse mit Weiterleitung in einer Vorlage, die sich auf Tausenden von Seiten wiederholt, hat eine hohe Priorität. Derselbe Link im Text eines einzelnen Beitrags hat eine mittlere Priorität und in archivierten Beiträgen eine niedrige.

Jeder Problemtyp im Katalog hat eine Erkennungsregel, eine Bedingung für die Meldung, den erforderlichen Beleg, eine Priorität mit Bedingungen und eine Prüfung nach der Umsetzung. Von den 256 Typen beginnen 86 die Regel zur Priorität mit „hoch“, fast immer aber mit einer Bedingung: wenn der Suchbegriff Nachfrage hat, wenn die Seite Traffic hat, wenn der Fehler in der Vorlage liegt.

Deshalb legt der Gesundheitswert eines Tools die Prioritäten nicht fest. Das Tool zählt Fehler und nicht den Traffic, der von ihnen abhängt. Eine Empfehlung zu Seiten mit unbekanntem Traffic bekommt keine hohe Priorität, bevor ich die Daten geprüft habe.

Schritt 6. Ein Beleg bei jedem Punkt

Ein Punkt ohne Beleg bleibt im Audit als „zu prüfen“ und nicht als Empfehlung. Als Beleg dient ein Screenshot der Stelle im Code oder das HTML vom Server neben der Version nach der Ausführung von JavaScript. Es kann auch ein Diagramm aus der Search Console sein oder eine Geschwindigkeitsmessung mit dem Namen des Elements, das sie verschlechtert. Ein Element, das das Laden verschlechtert oder das Layout der Seite verschiebt, benenne ich so, wie die Messung es zeigt, und nicht so, wie es zu meiner Hypothese passt.

Jeden Punkt beschreibe ich in vier Teilen, vom Problem bis zur Prüfung der Behebung. Ich schreibe, worin das Problem besteht, warum es schadet und worauf es sich auswirkt, wie man es Schritt für Schritt behebt und wie wir prüfen, dass die Behebung gewirkt hat. Den zu korrigierenden Code kopiere ich wörtlich von der Website, damit der Entwickler genau die Stelle sieht, die er ändern soll.

So sieht eine Meldung zu Links auf Weiterleitungen in Kurzform aus:

• Problem: Links im Menü führen auf Adressen ohne Schrägstrich am Ende, die auf die Version mit Schrägstrich weiterleiten.
• Warum es schadet: Das Menü steht auf jeder Seite, deshalb läuft jeder Klick und jeder Abruf durch einen Crawler über eine zusätzliche Weiterleitung. In den Berichten der Tools erschweren Tausende solcher Links das Finden wichtigerer Fehler.
• Behebung: In der Menüvorlage die Adressen durch die Zieladressen ersetzen, mit einem Codeausschnitt vor und nach der Änderung.
• Prüfung: Nach der Umsetzung zeigt der Crawl in der Vorlage keine Links auf Adressen mit Weiterleitung.

Schritt 7. Reihenfolge, Aufwand und Varianten

Das Ergebnis des Audits ist eine Reihenfolge und keine Zahl von Befunden. Am Anfang des Dokuments steht eine Tabelle aller Punkte mit Priorität und Aufwand. Den Aufwand beschreibe ich in vier Kategorien: einige Stunden, ein bis zwei Tage, eine Woche oder ein ganzes Projekt. Ein Team mit begrenzten Ressourcen erhält neben der vollständigen eine Minimalvariante, mit einer klaren Beschreibung dessen, was es verliert, wenn es den kürzeren Weg wählt.

Die Umsetzung folgt genau dem Audit. Taucht bei der Kostenschätzung für die Umsetzung eine günstigere Variante auf, wählt sie der Kunde, und ich halte das ausdrücklich fest, statt die Empfehlung ohne sein Wissen auszutauschen.

Schritt 8. Gegenprüfung und Prüfung nach der Umsetzung

Bevor das Audit zum Kunden geht, prüft es jemand, der es nicht geschrieben hat. Ich mache zwei Kontrollrunden: die erste über das ganze Dokument, die zweite nur über das, was sich nach der ersten geändert hat. Die Kontrolle rechnet die Zahlen von Grund auf neu und sucht Thesen, die sich nicht mit einem Beleg verteidigen lassen. Zum Schluss prüfe ich selbst die Prioritäten und Thesen, die von der Situation des Kunden abhängen.

Nach der Umsetzung prüfe ich jeden Punkt auf der laufenden Website und kennzeichne ihn als korrekt, teilweise oder nicht umgesetzt. Diese Prüfung ist im Preis des Audits enthalten. Ohne diesen Schritt endet das Audit beim Dokument und nicht bei der Änderung auf der Website.

Was prüfe ich im technischen SEO-Audit?

Im technischen Audit gehe ich über ein Dutzend Bereiche durch, und Probleme melde ich am häufigsten bei Weiterleitungen, der Architektur der Website und den Inhalten. Die letzte Spalte zeigt, in wie vielen der 63 Audits aus dem Archiv der Autor mindestens ein Problem aus dem jeweiligen Bereich gemeldet hat. Die Spalte „Was ich prüfe“ nennt Beispiele und nicht den vollen Umfang des Bereichs. Die Tabelle zeigt ausgewählte Bereiche, der Katalog teilt die Probleme in 22 ein.

Ein selten gemeldetes Problem muss nicht selten vorkommen. Geschwindigkeit und JavaScript haben in dieser Tabelle wenige Meldungen, aber die Audits aus dem Archiv hatten einen unterschiedlichen Umfang. Eine niedrige Zahl von Meldungen sagt also nicht, wie oft diese Probleme auf Websites vorkommen.

Wie prüfe ich die Indexierung einer Website?

Die Indexierung prüfe ich anhand von drei Listen: was in der Sitemap steht, was Google indexiert hat und was der Crawler über Links findet. Die Abweichung zwischen diesen drei Listen zeigt das Problem besser als jede einzelne. Eine Sitemap mit Adressen, die eine Weiterleitung oder einen Fehler liefern oder vom Index ausgeschlossen sind, wurde in 20 von 63 Audits gemeldet, auf 18 von 50 Websites. Für einzelne Adressen nutze ich die URL-Prüfung in der Search Console, die auch die Seite nach der Ausführung von JavaScript zeigt.

Beeinflussen die Core Web Vitals die Positionen?

Die Core Web Vitals sind Teil der Rankingsysteme von Google, aber die Relevanz des Inhalts hat Vorrang. Google schreibt ausdrücklich, dass die Rankingsysteme die Core Web Vitals verwenden. Google schreibt auch, dass es immer versucht, den relevantesten Inhalt zu zeigen, selbst bei schwacher Nutzererfahrung auf der Seite (Google Search Central). Im Audit nutze ich Daten echter Nutzer aus dem CrUX-Bericht und nicht einen einzelnen Test in einem Labor-Tool. Wo Google solche Daten für einzelne Seitentypen hat, nenne ich sie getrennt. Lücken in diesen Daten beschreibe ich im Audit. Seit dem 12. März 2024 ist INP das Maß für die Reaktion der Seite und hat FID ersetzt (web.dev).

Welche Fehler finde ich am häufigsten in SEO-Audits?

Am häufigsten wiederholen sich Ordnungsfehler, also solche, die Tools leicht erkennen: Links auf Weiterleitungen und auf 404-Fehler, Sitemaps mit falschen Adressen und doppelte Seitentitel und Beschreibungen. Interne Links auf Adressen mit Weiterleitung kamen in 24 von 63 Audits vor, auf 20 von 50 Websites. Tools erkennen sie gut, und die Kosten der Behebung hängen von der Vorlage und vom System der Website ab.

Seltener gemeldete Probleme der Struktur können größere Auswirkungen auf den Traffic haben als Ordnungsfehler. Fehlende Seiten für wichtige Suchbegriffe wurden in 15 von 63 Audits gemeldet, und ebenso oft ein Blog, der nicht auf die Seiten des Angebots und der Kategorien verlinkt. Der Katalog gibt einer fehlenden Seite eine hohe Priorität, wenn für den Suchbegriff Nachfrage besteht und Wettbewerber mit eigenständigen Seiten dafür ranken. Ein Blog ohne Links bekommt eine hohe Priorität, wenn die Zielseiten Traffic oder Umsatz haben und der Blog Autorität besitzt. Diese Bedingungen prüfe ich an den Daten, bevor ich die Priorität vergebe.

• 938Befunde in 63 Audits auf 50 Websites, aus denen ich den Katalog mit 256 Problemtypen aufgebaut habeArchiv der Audits 2020-2026, Katalog vom 11.10.2026
• 38 %der Audits mit internen Links auf Adressen mit Weiterleitung, dem am häufigsten gemeldeten Problem im Archiv (24 von 63)Katalog vom 11.10.2026
• 15 von 63Audits mit fehlenden Seiten für wichtige Suchbegriffe, was der Crawler nicht von allein meldetKatalog vom 11.10.2026
• 14Typen von Empfehlungen, die der Katalog heute als veraltet kennzeichnet, und weitere 30 als geänderte PraxisKatalog vom 11.10.2026

Was hat sich in SEO-Audits seit 2020 geändert?

In den Audits aus den Jahren 2023-2026 kommen strukturierte Daten und Paginierung häufiger vor als in den Jahren 2020-2022, Weiterleitungen, Canonical-URLs und Indexierung dagegen seltener. Probleme mit strukturierten Daten wurden in 23 von 33 neueren Audits gemeldet gegenüber 16 von 30 älteren. Weiterleitungen und Antwortcodes: 23 von 33 gegenüber 27 von 30. Sperren von KI-Crawlern tauchen erst in Audits aus dem Jahr 2026 auf. Das Jahr des Audits ist das Datum der Datei im Archiv, also nicht immer das Jahr, in dem die Arbeit gemacht wurde.

Der Rückgang beweist nicht, dass die Probleme mit Weiterleitungen verschwunden sind. Die Zusammensetzung der Audits hat sich geändert: Die neueren betrafen häufiger strukturierte Daten, Inhalte und Sichtbarkeit in der KI, und auch die Arbeitsweise hat sich geändert. Aus diesem Diagramm ergibt sich, womit sich die Audits befassten, und nicht, wie sich die Websites in Polen verändert haben.

Welche SEO-Empfehlungen sind heute veraltet?

Einige Empfehlungen tauchen weiterhin in Audits und Ratgebern auf, obwohl es sich heute nicht lohnt, sie umzusetzen. Ein Teil von ihnen funktionierte vor einigen Jahren; von anderen riet Google schon lange ab oder ignorierte sie. In der Tabelle nenne ich bei jeder Praxis den Grund und das, was man stattdessen tun sollte.

Quellen zur Tabelle: Google zur Paginierung, Google zu fünf Fehlern mit rel=canonical, Google zu FAQ- und HowTo-Ergebnissen, Matt Cutts zu nofollow und zur Verteilung der Linkkraft, John Mueller zu Weiterleitungen auf die Startseite, nach Search Engine Roundtable, Google zur robots.txt, Google zu nicht unterstützten Regeln in der robots.txt, Google zu Sitemaps, Google zu den Feldern lastmod, changefreq und priority, web.dev zu INP, Google zum Suchfeld in den Ergebnissen.

Deshalb hat jede Empfehlung in meinem Katalog ein Feld zur Aktualität mit Begründung. Der Katalog kennzeichnet heute 14 Typen von Empfehlungen als veraltet und 30 als geänderte Praxis. Eine Empfehlung, die vor einigen Jahren richtig war, kommt nicht ins Audit, nur weil sie einmal funktioniert hat.

Wie prüfe ich im Audit den Zugang von KI-Crawlern?

Den Zugang von KI-Crawlern prüfe ich im selben Schritt wie den Zugang des Googlebots, denn dieselbe Einstellung der Firewall oder des CDN kann sie blockieren. Ein CDN ist ein Netz vermittelnder Server, zum Beispiel Cloudflare. Im September 2026 habe ich 12 Domains meiner Kunden geprüft, die hinter Cloudflare laufen. Allein die Datei robots.txt zeigte:

• 3 Domains blockierten denselben Satz von sieben Crawlern, die Daten für das Training von Modellen sammeln, mit identischer Liste der Namen. Eine identische Liste deutet auf eine gemeinsame Quelle hin, zum Beispiel eine fertige Einstellung im Cloudflare-Panel. Von außen ist diese Einstellung nicht zu sehen, man muss sie also im Panel selbst bestätigen.
• 1 Domain blockierte Crawler, die Seiten für Antworten von ChatGPT, Perplexity und Claude abrufen. Sie tat das nicht ausdrücklich, sondern mit einer allgemeinen Regel für alle Crawler, die nicht namentlich genannt sind. Dieselbe Domain zeigte dem GPTBot eine Schutzseite ohne die Markierung noindex, die eine Seite vom Index ausschließt. Hätte einen solchen Inhalt ein indexierender Crawler erhalten, hätte statt des Inhalts die Sperrseite in den Index gelangen können.
• 8 Domains hatten keine Sperren in der robots.txt.

Über Crawler, die Seiten für Antworten abrufen, und über Crawler, die Daten für das Training sammeln, entscheiden Sie getrennt. Im Text zu GEO und KI-SEO habe ich beschrieben, wie man sie unterscheidet. Seit dem 31. August 2026 gibt es zudem eine eigene Einstellung in der Search Console, die eine Website von AI Overviews, vom KI-Modus und von generativen Funktionen in Discover ausschließt. Nach Angaben von Google wirkt sie sich nicht auf die übrigen Suchergebnisse aus (Search-Console-Hilfe). Eine solche Einstellung prüfe ich im Audit genauso wie die robots.txt, denn jemand könnte sie ohne Wissen der für SEO zuständigen Person aktiviert haben. Ob die Marke nach der Öffnung des Zugangs in den Antworten erscheint, ist eine eigene Messung, die ich im Text zur KI-Sichtbarkeit beschrieben habe.

Ein Test von einer einzigen IP-Adresse zeigt nur einen Teil der Situation und kann selbst einen Fehlalarm auslösen. In derselben Durchsicht meldete eine Serie von Anfragen bei zwei Domains eine Sperre nach Überschreiten eines Limits. Diese Sperre lösten meine eigenen früheren Anfragen aus. Eine Kontrolle einige Minuten später, mit einer einzigen Kennung des Crawlers und einzelnen Anfragen, ergab fünf und sieben korrekte Antworten hintereinander. Ohne diese Kontrolle hätten zwei Kunden die Meldung über eine Sperre erhalten, die es nicht gab. Erst die Server-Logs zeigen, ob ChatGPT die Seite tatsächlich abruft. Im Text zur Datei llms.txt zeige ich, was in den Logs meiner Website zu sehen ist.

Der Code 200 bedeutet nicht, dass der Crawler den Inhalt erhalten hat. Bei einem Kunden mit einer JavaScript-Anwendung erhielten Googlebot und Bingbot fertiges HTML von einem Prerender-Dienst, die Crawler der KI-Assistenten dagegen eine leere Seite. Der Dienst erkannte Crawler am Namen und hatte die KI-Crawler nicht auf der Liste. Mein Test ergab „in Ordnung“, weil er den Antwortcode maß und nicht den Inhalt. Seitdem vergleiche ich den Inhalt, den der Crawler erhält, mit dem Inhalt nach der Ausführung von JavaScript im Browser.

Reicht ein kostenloser SEO-Check?

Ein kostenloses Tool zeigt eine Liste von Fehlern, aber aus dem Bericht allein ergibt sich nicht, welche davon Sie Traffic kosten. Bei der Suchanfrage „audyt seo“ im polnischen Google sind 7 von 9 organischen Ergebnissen auf der ersten Seite Tools oder Angebote für ein kostenloses Audit (Ergebnisse vom 17. Oktober 2026). Ein solcher Bericht zählt Fehler nach den Regeln des Tools und nicht danach, wie viel Traffic und Umsatz von ihnen abhängen. Man muss auch prüfen, ob das Ergebnis nicht aus der Sperre eines Crawlers stammt, wie im Fall des Shops mit dem Gesundheitswert 0.

Vieles können Sie kostenlos tun, wenn Sie wissen, wo Sie hinschauen müssen. Die Search Console zeigt Daten von Google zur Indexierung, zu den Core Web Vitals und die Seite nach der Ausführung von JavaScript. Die kostenlose Version von Screaming Frog durchläuft bis zu 500 Adressen in einem Crawl (Screaming Frog), was für eine kleine Unternehmenswebsite genügt. Ein Audit mit einem Berater ist sinnvoll, wenn ein Fehler viel kostet (Migration, Einbruch des Traffics, großer Shop) oder wenn Sie keine Zeit haben, die Daten zusammenzustellen und zu bewerten.

Kann ChatGPT ein SEO-Audit durchführen?

Weder ChatGPT noch ein anderes KI-Modell kann ein vollständiges Audit allein durchführen, denn es sieht die Website nicht so wie ein Crawler der Suchmaschine. Meist sieht es sie über ein Tool, das sie abruft und in Text umwandelt. Das Modell liest die Daten, die Sie ihm geben, und schlägt vor, was zu prüfen ist. Das Abruf-Tool kann aber einen Teil der Seite verlieren: Im September 2026 stellte ich fest, dass das Tool zum Abrufen von Seiten in Claude Code beim Umwandeln der Seite in Text strukturierte Daten herausschneidet. Das Modell antwortete, die Information gebe es nicht, obwohl sie in einer Markierung auf derselben Seite stand. Ein auf diese Weise erstelltes Audit würde das Fehlen strukturierter Daten melden, die nicht fehlen. In meinem Prozess ist KI ein Werkzeug, vor allem zur Aggregation von Daten aus dem Crawl, der Search Console und anderen Quellen. Umfang, Bewertung und Prioritäten lege ich selbst fest.

Was kostet ein SEO-Audit?

Ein Audit rechne ich wie eine Beratung ab: 70 EUR netto pro Arbeitsstunde, mit einer Obergrenze der Stunden, die vor dem Start festgelegt wird. Die Zahl der Stunden hängt davon ab, was geprüft werden muss:

• ein Diagnose-Audit zu einem oder zwei konkreten Problemen (Einbruch, Migration, Indexierung) erfordert meist 10-16 Stunden, also 700-1.120 EUR netto;
• ein vollständiges Audit mit der Reihenfolge der Maßnahmen erfordert meist 32-50 Stunden, also 2.240-3.500 EUR netto;
• eine kleine Website bis 500 Adressen liegt näher an der unteren Grenze, ein Shop mit Tausenden Adressen und Filtern näher an der oberen;
• Sprachversionen kosten meist 3-5 Stunden zusätzlich, eine laufende Krise, die diagnostiziert werden muss, 4-8 Stunden.

Im Preis enthalten sind die Analyse, ein Bericht mit Empfehlungen, ein Gespräch, in dem wir ihn besprechen, und die Prüfung nach der Umsetzung. Die Umsetzung selbst übernimmt Ihr Team, oder ich kalkuliere die Kosten dafür separat.

Ohne Zugang zur Search Console, zum CDN-Panel und zum Hosting kann ich den technischen Teil nicht vollständig prüfen, und das sage ich vor der Kostenschätzung. Ich nenne dann, was ich ohne diese Zugänge nicht verifizieren kann, und grenze den Umfang entsprechend ein. Im Text zur SEO-Beratung habe ich beschrieben, wann statt eines Audits ein Gespräch über eine einzelne Entscheidung genügt.

Häufige Fragen zum SEO-Audit

Womit fange ich an?

Beginnen Sie mit der Frage, ob die Website Traffic verliert oder keinen aufbaut. Von der Antwort hängt ab, ob Sie zuerst die Seiten schützen, die Positionen haben, oder Suchbegriffe suchen, für die Seiten fehlen. Machen Sie danach die drei kostenlosen Prüfungen aus der Antwort zum Audit in Eigenregie: robots.txt, Bericht zur Indexierung in der Search Console und ein Crawl mit der kostenlosen Version von Screaming Frog. Wenn Sie das Ergebnis überrascht oder Sie nicht wissen, was zuerst zu beheben ist, ist das ein gutes Thema für eine Beratung.