Technische SEO
Technische SEO, die Crawlbarkeit und Indexierung verbessert
Technische SEO verhindert, dass gute Inhalte unsichtbar bleiben, weil Statuscodes, Canonicals, Rendering, Geschwindigkeit oder interne Links einander widersprechen.
- Indexierung: Nur kanonische, wertvolle Seiten gehören in die Sitemap und die interne Linkstruktur.
- Rendering: Wichtige Texte und Metadaten müssen auch für Crawler verlässlich verfügbar sein.
- Nachweisbare Behebung: Eine Korrektur gilt erst als angewendet, wenn ein unveränderlicher Auslieferungszeitpunkt dokumentiert wurde.
Was prüft ein technisches SEO-Audit?
Ein Audit erfasst nicht nur Fehler, sondern bestimmt, welche davon tatsächlich Indexierung, Nutzererfahrung oder Conversions beeinflussen. Eine Liste mit Hunderten unpriorisierten Warnungen ist kein Plan.
- Statuscodes, Soft-404-Fehler und Weiterleitungsketten
- Canonical- und hreflang-Signale
- Robots-Anweisungen und Sitemap-Qualität
- JavaScript-Rendering und sichtbares HTML
- Interne Links, verwaiste Seiten und Crawling-Tiefe
- Core Web Vitals und mobile Nutzbarkeit
Von der Fehlermeldung zur Priorität
Wir bewerten Reichweite, Schwere, kommerziellen Wert und Umsetzungsrisiko. Ein Startseiten-Canonical auf jeder Leistungsseite hat Vorrang vor einem fehlenden Alt-Text bei einem dekorativen Bild.
- P0: blockiert die Indexierung oder verursacht weitreichend falsche Signale
- P1: beeinträchtigt wichtige Seiten oder die Messbarkeit
- P2: verbessert die Qualität, blockiert aber nicht unmittelbar das Wachstum
Technische SEO endet nicht nach dem Release
Neue Templates, Plugins und Inhalte können alte Fehler zurückbringen. Deshalb gehören Vertragstests, Überwachung und Search-Console-Prüfungen zur Lösung.
- Regressionstest für Titel und Canonicals
- Automatische Sitemap-Prüfung
- 404- und Weiterleitungsüberwachung
- Meldung bei plötzlichem Indexierungsrückgang
Eine technische SEO-Korrektur beginnt mit einem überprüfbaren Endzustand
Ein Auftrag wie „Behebe die Canonical-Probleme“ ist zu allgemein, um ihn sorgfältig umzusetzen oder zu prüfen. Ein brauchbarer Arbeitspunkt nennt die betroffenen URLs oder Templates, das aktuell falsche Signal und den erwarteten Zustand nach Veröffentlichung. Dazu gehören etwa gewünschter HTTP-Status, Canonical, Robots-Anweisung, interner Link und sichtbarer Hauptinhalt. Außerdem halten wir fest, wer veröffentlicht und in welcher Umgebung die Kontrolle stattfindet. So kann ein Entwickler gezielt arbeiten und jemand anderes unabhängig prüfen, ob das Live-Ergebnis dem Auftrag entspricht, statt sich nur auf ein geschlossenes Ticket zu verlassen.
Änderungen mit großer Reichweite benötigen außerdem einen Wiederherstellungsweg. Anpassungen an Routing, Weiterleitungen, Robots-Regeln, strukturierten Daten oder gemeinsamen Templates können viele Seiten gleichzeitig beeinflussen. Deshalb bestimmen wir vorab, welche Prüfung vor dem Release nötig ist, welche Signale nach Veröffentlichung betrachtet werden und wann Zurücksetzen sinnvoller ist als weiteres Nachbessern. Ziel ist nicht, technische Änderungen unmöglich zu machen, sondern Risiken erkennbar und behebbar zu halten. So wird technische SEO Teil des normalen Release-Managements. Es bleibt klar, welche Verbesserung live ist, welche noch getestet wird und welche von einer anderen Partei abhängt.
- Genaue URL-Menge oder genaues Template, auf das sich die Änderung bezieht
- Erwarteter Statuscode, Canonical, Robots-Signal und Hauptinhalt
- Prüfung vor und nach Veröffentlichung durch einen benannten Verantwortlichen
- Wiederherstellungsweg für Änderungen mit großer Reichweite
- Regressionstest, um Wiederholungen in einem späteren Release zu erkennen
Prüfe, was der Server ausliefert, bevor JavaScript ausgeführt wird
Eine Seite kann im Browser korrekt aussehen, während die ursprüngliche Serverantwort ein widersprüchliches Signal sendet. Eine nicht vorhandene URL kann etwa sichtbar eine Fehlermeldung anzeigen, technisch aber mit Status 200 und indexierbarem Inhalt antworten. Auch Titel, Canonical oder Haupttext können erst nach JavaScript erscheinen, sodass Crawler auf einen zusätzlichen Rendering-Schritt angewiesen sind. Deshalb vergleichen wir bei wichtigen Routen die rohe HTTP-Antwort und das Quell-HTML mit der endgültig gerenderten Seite. Wir prüfen, ob Inhalt, Status, Canonical und Indexierungsanweisung bereits ab der ersten Antwort zur Funktion der URL passen.
Unbekannte URLs sollten einen echten 404-Status liefern. Dauerhaft umgezogene Seiten sollten serverseitig auf ein festgelegtes Ziel weiterleiten. Private Bereiche werden durch Authentifizierung geschützt, statt nur über robots.txt verborgen zu werden. Für öffentliche Seiten, die nicht in den Index gehören, muss ein lesbares noindex-Signal erreichbar bleiben. Auch die Sitemap sollte ausschließlich kanonische, indexierbare URLs enthalten, die tatsächlich mit einem Erfolgsstatus antworten. Diese Prüfungen garantieren keine Indexierung, verhindern aber unnötig widersprüchliche Hinweise der Website an Google und andere Systeme, die Webseiten abrufen.
- Rohe Antwort und gerenderten DOM getrennt bewerten
- Echte 404 für unbekannte URLs und Serverweiterleitungen bei Umzügen
- Private Inhalte absichern; Crawling-Sperren nicht als Zugriffsschutz verwenden
- Nur kanonische und indexierbare URLs in der XML-Sitemap
Diese Nachweise gehören zu einem technischen Release
Ein Release-Nachweis macht den technischen Zustand zum Kontrollzeitpunkt nachvollziehbar. Pro untersuchter URL lassen sich Statuscode, endgültiges Weiterleitungsziel, Canonical, Robots-Anweisung, Titel und vorhandener Hauptinhalt erfassen. Bei der Sitemap-Prüfung ergänzen wir die Anzahl eindeutiger kanonischer URLs und gegebenenfalls ausgeschlossene private Routen. Beim Rendering vergleichen wir relevante Felder des Quell-HTML mit dem Browserergebnis. Der Bericht nennt außerdem die Build- oder Deployment-Kennung, sofern verfügbar, damit spätere Abweichungen nicht versehentlich der falschen Version zugeordnet werden. Ein Screenshot allein reicht dafür meistens nicht aus.
Dieses Material belegt, dass der vereinbarte technische Zustand live und überprüfbar war. Es belegt noch nicht, dass Google die Änderung verarbeitet hat oder Positionen steigen. Crawling-Aktivität, Indexierungsstatus, Suchtraffic und Conversions haben eigene Quellen und Zeitfenster. Sie werden später separat über einen vollständigen Vergleichszeitraum bewertet. Zeigt Search Console eine Verzögerung oder hat ein Crawl noch nicht stattgefunden, wird dies als offener Messpunkt genannt. So entsteht keine erzwungene Erfolgsgeschichte, sondern eine klare Kette aus Problem, Änderung, Release-Prüfung und erst danach einer belegten Bewertung möglicher Wirkungen.
- URL, HTTP-Status, Weiterleitungsziel und Canonical
- Robots-Signal, Titel und Hauptinhalt in der Quellantwort
- Sitemap- und interne Linkprüfung
- Deployment-Kennung, Prüfzeitpunkt und gegebenenfalls Rollback
- Spätere Crawling- und Indexierungsmessungen als separate Nachweisebene
Häufig gestellte Fragen
Was ist technische SEO?
Technische SEO verbessert Crawlbarkeit, Indexierbarkeit, Rendering, interne Struktur und Leistung einer Website.
Reicht eine Sitemap aus, um indexiert zu werden?
Nein. Eine Sitemap hilft beim Auffinden von URLs. Seiten müssen aber auch erreichbar, indexierbar und wertvoll sein sowie einheitliche Canonical- und Robots-Signale liefern.
Kann Google JavaScript-Websites indexieren?
Google kann viel JavaScript rendern, aber Rendering erfordert zusätzliche Schritte und nicht jeder Crawler verarbeitet es gleich. Wichtige Inhalte und Metadaten vorab zu rendern verringert das Risiko.
Können technische SEO-Änderungen meine Website beschädigen?
Dieses Risiko besteht besonders bei Änderungen an Routing, Weiterleitungen, Templates, Canonicals, Robots-Regeln und strukturierten Daten, die viele URLs gleichzeitig betreffen. Deshalb arbeiten wir mit einer abgegrenzten URL-Menge, vorab beschriebenen Abnahmekriterien, einer Prüfung nach Veröffentlichung und bei Bedarf einem Rollback-Weg. Umfang und Risiko bestimmen, ob eine Änderung direkt umgesetzt werden kann oder zunächst eine ausdrückliche technische Freigabe benötigt.
Was ist der Unterschied zwischen einer echten 404 und einer Soft 404?
Eine echte 404 teilt über den HTTP-Status mit, dass die angeforderte Ressource nicht existiert. Bei einer Soft 404 antwortet der Server etwa mit Status 200, obwohl die Seite leer, irrelevant oder eine Fehlermeldung ist. Das sendet Crawlern ein widersprüchliches Signal. Deshalb bewerten wir nicht nur, was Besucher sehen, sondern auch den Status und Inhalt, den der Server tatsächlich zurückgibt.
Reicht robots.txt aus, um eine private Seite aus Suchmaschinen fernzuhalten?
Nein. Robots.txt steuert Crawling, ist aber kein Zugriffsschutz und garantiert nicht, dass eine bekannte URL aus einem Index verschwindet. Sensible Inhalte gehören hinter eine Authentifizierung. Eine öffentliche Seite, die nicht indexiert werden darf, benötigt ein korrektes noindex-Signal, das der Crawler abrufen kann. Welche Maßnahme passt, hängt also davon ab, weshalb die Seite nicht öffentlich auffindbar sein soll.
Wann ist ein technisches SEO-Audit abgeschlossen?
Die Analyse ist abgeschlossen, wenn Feststellungen abgegrenzt, priorisiert und mit einem Verantwortlichen sowie einem Abnahmekriterium versehen sind. Die Umsetzung ist erst abgeschlossen, wenn die gewählte Änderung live ist und erneut geprüft wurde. Ein Auditbericht und eine umgesetzte Lösung sind somit zwei unterschiedliche Ergebnisse. Mögliche Auswirkungen auf Crawling, Indexierung oder Leistung werden danach in einer passenden Messperiode verfolgt.
Primärquellen
Von SEOJuice-Redaktion, Linktool B.V.. Inhalt zuletzt aktualisiert: .
Lass deine technischen Grundlagen prüfen