Technisches SEO prüfen: eine Checkliste für Ihre Website
Technisches SEO prüfen heißt: nachsehen, ob Google Ihre wichtigen Seiten abrufen, verstehen und indexieren kann. Die Checkliste führt in zwölf Prüfungen von Indexierung, robots.txt, Sitemap und Canonical über Weiterleitungen und Ladezeit bis zu strukturierten Daten, jeweils mit einem kostenlosen Werkzeug.
Gute Texte nützen nichts, wenn eine vergessene Sperre aus der Testphase sie vor Google versteckt. Die zwölf Prüfungen unten finden solche Fehler. Sie brauchen dafür Zugang zur Google Search Console, einen Browser und für einige Schritte die Kommandozeile mit curl. Die Befehle unten laufen im Terminal von macOS und Linux. Unter Windows nutzen Sie Git Bash oder WSL: Die Befehle brauchen grep und /dev/null, und in Windows PowerShell ist curl ein anderer Befehl (ein Alias für Invoke-WebRequest).
Die Reihenfolge folgt dem Weg einer Seite in den Index: Ist sie bekannt, darf sie abgerufen werden, ist sie die gewünschte Fassung, antwortet sie sauber und schnell, und versteht Google, was auf ihr steht? Welche Begriffe die Seiten tragen sollen, klärt vorher die Keyword-Recherche. Diese Liste prüft nur die Technik.
Prüfungen 1 und 2
Wird Ihre Seite überhaupt indexiert?
Prüfung 1: Bericht zur Seitenindexierung lesen
Werkzeug: Search Console, Bericht zur Seitenindexierung. Er zählt indexierte und nicht indexierte URLs und nennt Gründe, etwa „URL als noindex markiert“, „Seite mit Weiterleitung“, „Nicht gefunden (404)“ oder „Duplikat - vom Nutzer nicht als kanonisch festgelegt“. Google schreibt dort selbst, dass nicht jede URL indexiert sein muss. Ziel ist, dass von jeder wichtigen Seite die kanonische Fassung im Index steht. Prüfen Sie deshalb die Gründe gegen eine Liste Ihrer wichtigsten Seiten, nicht die Gesamtzahl.
Prüfung 2: Wichtige Seiten einzeln prüfen
Werkzeug: URL-Prüftool der Search Console. Es zeigt, ob eine URL indexiert ist, welche kanonische URL Google ausgewählt hat und, über „Live-URL testen“, ob die Seite im Moment indexierbar wäre. Nehmen Sie sich Startseite, die drei wichtigsten Leistungsseiten und je eine Seite jedes Seitentyps vor. Für jede Property gilt ein Tageslimit an Prüfanfragen, für hunderte URLs eignet sich das Werkzeug deshalb nicht.
Prüfungen 3 bis 7
Sitemap, robots.txt und Canonical
Prüfung 3: robots.txt abrufen
Werkzeug: Browser oder curl (Befehl unten). Die Datei muss im Hauptverzeichnis liegen. Google wertet einen 4xx-Status als „keine robots.txt“, also ohne Einschränkung; bei 5xx-Fehlern pausiert Google zunächst das Crawling. Prüfen Sie, ob ein Disallow wichtige Verzeichnisse oder CSS- und JavaScript-Dateien sperrt. Eine Seite aus dem Index nehmen kann die robots.txt nicht: Laut Google kann eine gesperrte URL weiter in den Ergebnissen stehen, dann ohne Beschreibung.
Prüfung 4: XML-Sitemap prüfen
Werkzeug: Sitemaps-Bericht der Search Console. Die Sitemap enthält nur kanonische URLs als vollständige Adressen, höchstens 50.000 URLs oder 50 MB unkomprimiert je Datei. Stichprobe: Zehn URLs aus der Sitemap müssen mit Status 200 antworten, ohne Weiterleitung und ohne noindex. Google ignoriert die Felder priority und changefreq; lastmod nutzt Google nur, wenn der Wert durchgängig stimmt.
Prüfung 5: noindex in Kopfzeilen und Quelltext suchen
Werkzeug: curl oder Quelltext im Browser. Ein noindex kann im Meta-Tag robots stehen oder als HTTP-Header X-Robots-Tag, den man im Quelltext nicht sieht. Ein Header aus der Staging-Konfiguration, der nach dem Livegang mitgewandert ist, nimmt die ganze Website aus dem Index. noindex wirkt nur, wenn die Seite nicht per robots.txt gesperrt ist, weil Google den Hinweis sonst nicht lesen kann.
Prüfung 6: Canonical prüfen
Werkzeug: Quelltext, curl und URL-Prüftool. Jede Seite trägt höchstens ein rel="canonical" mit absoluter URL, im Normalfall auf sich selbst. Varianten mit Parametern, Druckfassungen oder Sortierungen zeigen auf das Original. Weicht die von Google ausgewählte kanonische URL aus Prüfung 2 von Ihrer Angabe ab, suchen Sie nach einer zweiten, fast gleichen Seite. Solche Doppelungen lösen Sie auf, indem Sie jedem Suchbegriff genau eine zuständige Seite geben.
Prüfung 7: Sprachfassungen gegenseitig verweisen
Werkzeug: Quelltext oder Sitemap. Bei mehrsprachigen Websites nennt jede Sprachfassung laut Google sich selbst und alle anderen Fassungen per hreflang, mit vollständigen URLs. Verweisen zwei Seiten nicht gegenseitig aufeinander, ignoriert Google die Angaben laut Dokumentation. Bei der Corporate-Site von Blue Performance haben wir Deutsch und Englisch mit gespiegelter Struktur und gegenseitigen hreflang-Verweisen gebaut: Zu jeder deutschen Seite gibt es eine englische mit gleichem Aufbau. Damit hat jeder hreflang-Verweis ein Gegenstück, und die Prüfung reduziert sich auf eine Stichprobe je Seitentyp.
Prüfungen 8 und 9
Weiterleitungen und kaputte Links
Prüfung 8: Eine Adresse, ein Sprung
Werkzeug: curl. Rufen Sie die Startseite in vier Varianten auf: mit http und https, mit und ohne www. Drei davon sollen mit einer dauerhaften Weiterleitung (301 oder 308) direkt auf die vierte zeigen. Achten Sie auf zwei Sprünge hintereinander, etwa zuerst von http auf https und dann von der Adresse ohne www auf die mit www; Befehl 3 unten zeigt jeden Sprung einzeln. Googlebot folgt laut Google bis zu zehn Weiterleitungen, jeder Sprung ist aber eine zusätzliche Anfrage, die Besucher warten lässt.
Prüfung 9: Kaputte Links und Soft-404
Werkzeug: Bericht zur Seitenindexierung und curl. Unter „Nicht gefunden (404)“ stehen URLs, die Google kennt und die nicht mehr existieren. Kommen sie aus eigenen Menüs oder Texten, korrigieren Sie den Link; hat die Seite einen Nachfolger, bekommt sie eine Weiterleitung. „Soft 404-Fehler“ bedeutet: Die Seite antwortet mit 200, zeigt aber eine Fehlermeldung oder leeren Inhalt. Ihr Server muss für eine fehlende Seite den Status 404 senden.
# 1. Statuscode einer Seite (erwartet: 200)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/
# 2. Statuscode einer Adresse, die es nicht gibt (erwartet: 404, nie 200)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/gibt-es-nicht
# 3. Weiterleitungskette: jeder Sprung mit Status und Ziel
curl -sL -o /dev/null -D - http://example.com/ | grep -iE '^(HTTP/|location:)'
# 4. Zahl der Sprünge, Endadresse und Endstatus in einer Zeile
curl -sL -o /dev/null -w '%{num_redirects} Sprünge, Ziel: %{url_effective}, Status: %{http_code}\n' http://example.com/
# 5. Kopfzeilen X-Robots-Tag und Link (Canonical im Header) suchen
curl -s -o /dev/null -D - https://example.com/ | grep -iE '^(x-robots-tag|link):'
# 6. Canonical und robots-Meta-Tag im Quelltext
curl -s https://example.com/ | grep -ioE '<link[^>]*rel=.?canonical[^>]*>|<meta[^>]*name=.?robots[^>]*>'
# 7. robots.txt mit Statuscode
curl -s -w '\nStatus: %{http_code}\n' https://example.com/robots.txt
Prüfungen 10 und 11
Ladezeit und mobile Darstellung
Prüfung 10: Felddaten in PageSpeed Insights
Werkzeug: PageSpeed Insights. Oben stehen Felddaten echter Chrome-Nutzer aus den letzten 28 Tagen, darunter Labordaten aus Lighthouse. Für die Core Web Vitals zählen die Felddaten am 75. Perzentil, als gut gelten LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1. Prüfen Sie Startseite und die Seite mit den meisten Besuchern getrennt für Mobilgeräte und Desktop. Hat eine Seite zu wenig Besucher, fehlen die Felddaten; dann bleibt nur der Labortest. Wenn Klicks spürbar verzögert reagieren, hilft der Beitrag INP verbessern weiter.
Prüfung 11: Mobile Darstellung mit Lighthouse
Werkzeug: Lighthouse in den Chrome-Entwicklertools. Google hat den Test auf Optimierung für Mobilgeräte und den Bericht zur Nutzerfreundlichkeit auf Mobilgeräten am 01.12.2023 eingestellt. Prüfen Sie deshalb in Lighthouse im Mobilmodus und von Hand auf einem Smartphone: lesbare Schrift ohne Zoomen, Schaltflächen mit genug Abstand, kein waagerechtes Scrollen, dieselben Inhalte wie auf dem Desktop. Google nutzt laut eigener Dokumentation nur die mobile Fassung für die Indexierung; Inhalte, die mobil fehlen, kann Google nicht berücksichtigen.
Prüfung 12
Strukturierte Daten prüfen
Prüfung 12: Schema.org-Auszeichnung testen
Werkzeug: Test für Rich-Suchergebnisse und Schema Markup Validator. Der Test von Google zeigt, welche Rich-Suchergebnistypen er auf einer URL oder in einem eingefügten Code findet, mit Fehlern und Hinweisen, standardmäßig aus Sicht eines Smartphones. Der Schema Markup Validator prüft die Auszeichnung nach Schema.org allgemein, auch Typen, für die Google keine Rich-Suchergebnisse anzeigt, etwa WebPage. Prüfen Sie je Seitentyp ein Beispiel. Die Angaben im Markup müssen zum sichtbaren Inhalt passen: Ein Preis oder eine Bewertung, die nur im Code steht, ist ein Fehler.
Rhythmus
Wann Sie die Liste wieder durchgehen
Für einen vollständigen Durchgang rechnen wir bei einer Website mit wenigen Seitentypen mit einem halben Arbeitstag, weil die Prüfungen mit Stichproben je Seitentyp arbeiten und nicht jede Seite einzeln abrufen. Wiederholen Sie die Prüfungen 1, 3, 5 und 8 nach jedem größeren Update, nach einem Wechsel von Server oder CMS und nach dem Einspielen neuer Vorlagen; das sind die Stellen, an denen eine Konfiguration unbemerkt mitwandert. Den ganzen Durchgang einmal im Quartal.
Notieren Sie Datum, geprüfte URLs und Ergebnis je Prüfung in einer Tabelle. Beim nächsten Durchgang sehen Sie dann, ob ein Fehler neu ist oder liegen geblieben. Welche Rolle Technik neben Inhalten und Nutzersignalen spielt, ordnet SEO ohne Buzzword-Bingo ein. Wer die Befunde nicht selbst umsetzen will, findet auf unserer Seite zur Suchmaschinenoptimierung, wie wir Technik und Inhalte gemeinsam angehen.
Rückfragen zur Checkliste
Häufige Fragen
-
Einen vollständigen Durchgang einmal im Quartal, dazu einen kurzen Blick auf Indexierung, robots.txt, noindex und Weiterleitungen nach jeder größeren Änderung an Server, CMS oder Vorlagen. Nach einem Relaunch prüfen Sie in den ersten Wochen wöchentlich.
-
Alle zwölf Prüfungen kommen ohne Lizenz aus: Google Search Console, PageSpeed Insights, Lighthouse in Chrome, der Test für Rich-Suchergebnisse, der Schema Markup Validator und curl auf der Kommandozeile. Für eine Website mit wenigen Seitentypen reichen Stichproben je Seitentyp. Erst bei vielen hundert Seiten wird ein Crawler sinnvoll, der alle URLs in einem Lauf abruft.
-
Ein Verweis im Kopf einer Seite, der Google mitteilt, welche URL die bevorzugte Fassung eines Inhalts ist. Er steht bei Varianten derselben Seite, etwa mit Sortier- oder Tracking-Parametern, und zeigt auf das Original. Google wertet ihn als starkes Signal, entscheidet aber selbst und zeigt die gewählte Fassung im URL-Prüftool an.
Zwölf Prüfungen, ein Befund pro Zeile
Gehen Sie die Liste mit Ihrer Search Console durch und notieren Sie je Prüfung einen Befund. Die offenen Zeilen sind der Ausgangspunkt, wenn wir die Suchmaschinenoptimierung Ihrer Website übernehmen.
Nachweise
Quellen und Stand
Stand: 23.07.2026. Angaben zu Search Console, Indexierung, robots.txt, Sitemaps, Canonical, hreflang, Weiterleitungen und Core Web Vitals laut Google-Dokumentation. Die curl-Befehle wurden unter macOS im Terminal (zsh, mitgeliefertes curl) gegen example.com, github.com und www.marcodes.com ausgeführt; die Ausgaben entsprachen den Kommentaren. Der Zeitaufwand ist eine Einschätzung.
Artikel teilen