Technisches SEO-Audit: was es prüft, Schritt für Schritt, und was Sie am Ende bekommen

Was ein technisches SEO-Audit ist und worin es sich unterscheidet

Ein technisches SEO-Audit beantwortet eine einfache Frage: Kann Google Ihre Seiten erreichen, lesen und verstehen, welche davon wichtig sind? Es bewertet nicht, ob die Texte gut sind oder ob Sie genug Links von anderen Websites haben. Es schaut auf das Fundament. Ist das Fundament schief, arbeitet alles, was Sie darauf bauen, mit Verlust. Und anders als beim Inhalt betreffen technische Probleme meist Dutzende Seiten gleichzeitig, nicht nur eine.

Der Unterschied zu einem Content-Audit ist leicht erklärt. Ein Content-Audit fragt, ob die Seite gut beantwortet, wonach Menschen suchen. Ein technisches Audit fragt, ob die Seite überhaupt in der richtigen Form bei Google ankommt. In der Praxis ist das technische Audit der erste Schritt jedes Projekts zur SEO-Optimierung, weil es zeigt, was repariert werden muss, bevor Sie in neue Artikel investieren.

Im Folgenden gehen wir die Prüfungen einzeln durch, in der Reihenfolge, in der wir sie durchführen. Zu jeder gibt es ein echtes Beispiel von unserer eigenen Website. Nicht weil wir gern unsere Fehler zeigen, sondern weil es genau die Art von Problemen ist, die man mit bloßem Auge nicht sieht und die ein gutes Audit findet. Alle sind behoben, und die Lösungen beschreiben wir kurz bei jedem Schritt.

Schritt 1: Indexierung und Zugang für Crawler

Zuerst prüfen wir, ob die wichtigen Seiten im Google-Index sind. Die verlässliche Quelle dafür ist der Bericht zur Seitenindexierung in der Search Console, nicht eine site:-Suche bei Google. Der Bericht zeigt, welche Seiten indexiert sind, und für den Rest den Grund: ein 404-Fehler, eine mit noindex markierte Seite, durch robots.txt blockiert, ein Duplikat ohne vom Nutzer gewählte kanonische Seite oder „gecrawlt, zurzeit nicht indexiert“.

Google schreibt in der Dokumentation klar, dass man nicht erwarten sollte, dass alle URLs einer Website indexiert werden, sondern nur die kanonischen Seiten. Keine Panik also bei einer Liste nicht indexierter Seiten. Schauen Sie, ob eine Seite darunter ist, die Geld bringt. Dort beginnt die Arbeit. Steht Ihre wichtigste Leistungsseite auf „gecrawlt, zurzeit nicht indexiert“, ist das ein Problem. Tauchen Filterseiten oder URLs mit Parametern auf, ist das oft genau das gewünschte Verhalten.

Unser Beispiel: Am 16. September 2026 schickte uns die Search Console eine Mail mit dem Fehler „Not found (404)“ für eine Adresse der Form /blog/cat-costa-un-site-de-prezentare. Diese Seite existierte nicht und war weder im Menü noch im Text verlinkt. Die Ursache lag in den strukturierten Daten: Jeder Artikel gab im Breadcrumb-Schema eine Adresse /blog/artikelname an, obwohl die Artikel tatsächlich unter /blog-artikelname liegen. Google folgt auch den Adressen im Schema, nicht nur den sichtbaren Links. Wir haben die Adresse im Schema korrigiert, für jede alte Adresse dieser Art eine 301-Weiterleitung eingerichtet und unsere automatische Linkprüfung so erweitert, dass sie auch Adressen im JSON-LD liest.

Schritt 2: Canonicals, Weiterleitungen und doppelte Seiten

Fast jede Website hat mehrere Adressen, die zum selben Inhalt führen: mit und ohne www, mit und ohne abschließenden Schrägstrich, mit Tracking-Parametern. Google wählt eine davon als Hauptversion. Ihre Aufgabe ist es, Signale zu senden, die dasselbe sagen. Die Google-Dokumentation beschreibt eine Weiterleitung als starkes Signal, das Canonical-Tag ebenfalls als starkes Signal und die Sitemap als schwaches. Und sie warnt ausdrücklich davor, für dieselbe Seite über verschiedene Methoden unterschiedliche kanonische URLs anzugeben.

Genau das hatten wir auf der alten Version unserer Website gefunden, im Audit vom 6. September 2026. Alle Seiten in der Sitemap außer der Startseite waren ohne abschließenden Schrägstrich aufgeführt. Der Server leitete sie per 301 auf die Version mit Schrägstrich weiter. Und die Seite mit Schrägstrich hatte ein Canonical-Tag, das zurück auf die Version ohne zeigte. Drei Signale, zwei Richtungen. Für Google ist das, als würde man sagen „geh dorthin“ und bei der Ankunft „eigentlich, geh zurück“.

Die Lösung ist nicht kompliziert, muss aber an allen drei Stellen gleichzeitig erfolgen: Die Adresse in der Sitemap, das Ziel der Weiterleitung und das Canonical müssen dieselbe URL sein, Zeichen für Zeichen. Auf der neu gebauten Website haben wir alle drei an eine einzige Regel zum Erzeugen der Adressen gebunden, damit sie nicht mehr auseinanderlaufen können. Danach haben wir auf der veröffentlichten Website geprüft, dass jede Adresse aus der Sitemap direkt mit 200 antwortet, ohne Weiterleitung unterwegs.

Schritt 3: Geschwindigkeit und Core Web Vitals

Core Web Vitals sind drei Messwerte, mit denen Google die tatsächliche Nutzererfahrung auf einer Seite beschreibt. Die von Google empfohlenen Schwellenwerte sind: LCP, also der Moment, in dem das Hauptelement erscheint, unter 2,5 Sekunden; INP, also wie schnell die Seite auf einen Klick reagiert, unter 200 Millisekunden; CLS, also wie stark der Inhalt beim Laden springt, unter 0,1. Laut Google entsprechen diese Messwerte dem, was die Ranking-Systeme zusammen mit anderen Aspekten der Seitennutzung belohnen wollen.

In einem Audit bleibt man nicht beim PageSpeed-Wert stehen. Man misst auf dem Smartphone, mit leerem Cache und gedrosselter Verbindung und CPU, auf mehreren Seitentypen, nicht nur auf der Startseite. Dann sucht man die Ursache jedes Problems, denn ein Wert allein repariert nichts. Eine Website kann auf der Startseite gut abschneiden und bei Artikeln oder Produktseiten ernste Probleme haben. Deshalb wählen wir aus jedem Vorlagentyp eine Seite und messen alle mehrfach, um keine Schlüsse aus einem einzigen Durchlauf zu ziehen.

Unser Beispiel aus dem September 2026: Das Laden war gut, aber der Inhalt sprang. Auf der Startseite haben wir einen CLS von 0,117 gemessen, über dem Grenzwert von 0,1. Die Ursache war das Cookie-Banner, das vor dem Laden der Schriften erschien und sich dann neu anordnete, wodurch der Text verschoben wurde. Web.dev nennt genau diese Art von Ursache unter den häufigen: Schriften, die größer oder kleiner dargestellt werden als die Ersatzschrift, und Elemente, die vor bestehendem Inhalt in die Seite eingefügt werden. Wir haben das Banner so verschoben, dass es erst nach dem Laden der Schriften erscheint. Gemessen auf der Live-Website nach der Veröffentlichung sank der CLS auf 0,023.

Schritt 4: strukturierte Daten, Überschriften und Sprachversionen

Strukturierte Daten sind Code, der Google ausdrücklich sagt, was auf der Seite ist: ein Unternehmen, eine Leistung, ein Artikel, häufige Fragen, ein Navigationspfad. Im Audit prüft man drei Dinge: ob sie vorhanden sind, ob der Typ zur Seite passt und ob die Adressen darin zu echten Seiten führen. Zur Validierung empfiehlt Google den Test für Rich-Suchergebnisse. Auf unserer alten Website hatten die Leistungsseiten nur ein allgemeines Schema für ein lokales Unternehmen, ohne jede Beschreibung der Leistung, obwohl es kommerzielle Seiten waren.

Auch die Struktur der Überschriften gehört hierher. Jede Seite sollte eine einzige Hauptüberschrift haben, die H1, die sagt, worum es auf der Seite geht. Auf der alten Website hatte jede Seite zwei: die echte Überschrift und eine weitere, auf der ganzen Website identisch, übrig geblieben in einem versteckten Teil des Codes. Besucher sahen sie nie. Der Crawler schon. Das ist kein schwerer Fehler, aber genau die Art gemischter Signale, die sich mit anderen summiert und eine Seite schwerer verständlich macht.

Hat die Website mehrere Sprachen, prüft man auch hreflang, das Tag, das die Versionen derselben Seite miteinander verbindet. Google verlangt, dass jede Version sich selbst und alle anderen aufführt, und wenn die Verweise nicht gegenseitig sind, können sie ignoriert werden. Google empfiehlt außerdem eine x-default-Version für Besucher, deren Sprache zu keiner passt. Auf unserer Website in fünf Sprachen fanden wir eine subtilere Variante des Problems: Die englischen Seiten hatten im Schema einen Breadcrumb, der auf die rumänischen Adressen zeigte.

Schritt 5: interne Links und die Reihenfolge der Prüfungen

Der letzte Teil ist, wie die Seiten miteinander verbunden sind. Man sucht wichtige Seiten, auf die kein Link führt, interne Links zu Adressen, die weiterleiten oder einen Fehler liefern, und Seiten, die in der Sitemap fehlen. Auf der alten Website wurde die Seite für Terminbuchungen erzeugt und war verlinkt, fehlte aber in der Sitemap. Ein kleines Problem, aber genau die Seite, die Menschen finden sollen.

Diese Prüfung erledigt man am besten automatisch, über die ganze Website, nicht Seite für Seite, denn ein Mensch ermüdet nach den ersten paar Dutzend Links. Bei jeder Veröffentlichung lassen wir ein Skript laufen, das allen internen Links folgt, auch denen in den strukturierten Daten, und wir veröffentlichen nichts, wenn es einen defekten findet. Kurz gesagt sieht die Reihenfolge, in der wir ein technisches Audit durcharbeiten, so aus:

• 01Indexierung: der Bericht zur Seitenindexierung in der Search Console, robots.txt, Sitemap, 404- und Soft-404-Fehler.
• 02Adressen: Weiterleitungen, Canonicals, Versionen mit und ohne www oder abschließenden Schrägstrich, Parameter.
• 03Geschwindigkeit: LCP, INP und CLS auf dem Smartphone gemessen, auf mehreren Seitentypen, mit der Ursache jedes Problems.
• 04Code: validierte strukturierte Daten, eine einzige H1 pro Seite, eindeutige Titel und Beschreibungen.
• 05Sprachen: gegenseitiges hreflang, x-default, korrekte Adressen in jeder Sprache.
• 06Links: defekte interne Links, Seiten ohne eingehende Links, wichtige Seiten, die in der Sitemap fehlen.

Wie lange es dauert, was Sie am Ende bekommen und wann es sich lohnt

Die Dauer hängt fast nur von Größe und Komplexität der Website ab. Eine Unternehmenswebsite mit einigen Dutzend Seiten ist viel schneller geprüft als ein Onlineshop mit Tausenden Produkten, Filtern und URL-Varianten. Auch der Zugang zur Search Console zählt: Ohne ihn wird ein guter Teil der Prüfungen zum Raten, weil man nicht sieht, was Google sieht. Von außen lassen sich Adressen, Geschwindigkeit und Code trotzdem prüfen.

Was Sie am Ende bekommen sollten, ist keine Punktzahl und auch kein 80-seitiges PDF aus einem Tool. Es ist eine nach Wirkung sortierte Liste von Problemen, jedes mit drei Angaben: wo es auftritt, der Beleg, also ein Screenshot, eine Messung oder eine Zeile aus einem Bericht, und die konkrete Lösung. Idealerweise gibt es auch eine Prüfung nach den Korrekturen, denn viele Probleme wirken gelöst und sind es erst, wenn die Search Console es bestätigt.

Ein technisches Audit lohnt sich, wenn Sie Ihre Website neu gebaut oder umgezogen haben, wenn Sie eine neue Sprache hinzugefügt haben, wenn der organische Traffic ohne offensichtlichen Grund sinkt oder wenn gute Seiten auf der zweiten Google-Seite feststecken. Es lohnt sich nicht, es monatlich bei einer kleinen Website zu wiederholen, die sich nicht verändert. Dort reicht ein regelmäßiger Blick in die Search Console.

Quellen und weiterführende Lektüre.

• 01Google Search Central — Understanding Core Web Vitals and Google search results
• 02Google Search Central — How to specify a canonical URL with rel="canonical" and other methods
• 03Google Search Central — Tell Google about localized versions of your page
• 04Google Search Console Help — Page indexing report
• 05Google Search Central — Breadcrumb (BreadcrumbList) structured data
• 06web.dev — Cumulative Layout Shift (CLS)

Häufige Fragen

Das Team von The Niche SocietyKI- und Software-Ingenieure aus Bukarest · LinkedIn

veröffentlicht 2026-09-28