Technical SEO

Technical SEO bezeichnet den Teil der Suchmaschinenoptimierung, der sich nicht mit Inhalten oder Verweisen befasst, sondern mit der Frage, ob und wie eine Website von Suchmaschinen überhaupt verarbeitet werden kann. Es geht um Erreichbarkeit, Crawling, Indexierung, Rendering, Auslieferungsgeschwindigkeit und die Signale, mit denen eine Website ihre eigene Struktur erklärt.

Technische Optimierung erzeugt keine Rankings. Sie ist die Voraussetzung dafür, dass Inhalte und Verlinkung überhaupt wirken können — eine Seite, die nicht indexiert ist, rankt auch mit dem besten Text der Branche nicht.

Crawling: gefunden werden

Bevor eine Seite bewertet werden kann, muss der Googlebot sie abrufen. Gesteuert wird das über mehrere Ebenen, die häufig verwechselt werden.

Die robots.txt im Wurzelverzeichnis regelt, welche Pfade abgerufen werden dürfen. Sie verhindert das Crawlen, nicht die Indexierung: Eine gesperrte URL kann trotzdem in den Ergebnissen auftauchen, wenn andere Seiten auf sie verlinken — dann allerdings ohne Beschreibungstext. Die früher verbreitete Angabe noindex in der robots.txt wird von Google seit dem 1. September 2019 nicht mehr ausgewertet; sie war nie Teil des Standards und ist heute schlicht wirkungslos.

Für den Ausschluss aus dem Index ist das Robots-Meta-Tag beziehungsweise der X-Robots-Tag im HTTP-Header zuständig. Damit das greift, muss die Seite crawlbar sein — eine per robots.txt gesperrte URL mit noindex im Quelltext wird nie gelesen und bleibt deshalb im Index.

Eine XML-Sitemap meldet die URLs an, die in den Index sollen. Sie ist ein Hinweis, keine Anweisung, und ersetzt keine funktionierende interne Verlinkung. Ihr praktischer Wert liegt oft weniger im Crawling als in der Diagnose: Der Indexierungsbericht der Search Console lässt sich nach Sitemap filtern, wodurch sich „soll indexiert sein“ und „ist indexiert“ gegenüberstellen lassen.

Das Crawl-Budget — die Menge an URLs, die Google auf einer Domain in einem Zeitraum abruft — ist für die meisten Websites kein Thema. Google nennt es ausdrücklich erst ab einer Größenordnung von einigen zehntausend URLs relevant, dazu bei Seiten mit sehr häufig wechselnden Inhalten. Wo es zum Problem wird, sind die Ursachen meist gleich: Filter- und Sortierparameter, die kombinatorisch neue URLs erzeugen, endlose Kalenderarchive, interne Suchergebnisseiten, Session-IDs. Wo solche URL-Muster entstehen, hilft weniger eine Sperre in der robots.txt als die Frage, warum die Adressen überhaupt erzeugt werden.

Rendering: gesehen werden

Der Googlebot ruft nicht nur das HTML ab, sondern rendert Seiten in einem Chromium-Browser, der seit 2019 laufend auf dem aktuellen Stand gehalten wird — Google spricht vom „Evergreen Googlebot“. Was moderne Browser können, kann er in der Regel auch.

Verlässlich ist das trotzdem nicht in jedem Fall. Rendering kostet Rechenzeit und findet oft zeitversetzt zum ersten Abruf statt. Inhalte, die erst nach einer Nutzerinteraktion nachgeladen werden, sieht der Bot nicht — er klickt nicht und scrollt nicht. Blockierte JavaScript- oder CSS-Dateien führen dazu, dass eine Seite unvollständig gerendert wird. Und was clientseitig aus einer API zusammengesetzt wird, hängt an der Verfügbarkeit dieser API im Moment des Renderings.

Für Websites, die stark auf JavaScript setzen, sind serverseitiges Rendering oder Pre-Rendering deshalb die robustere Wahl. Prüfen lässt sich das Ergebnis mit der URL-Prüfung in der Search Console, die das gerenderte HTML und einen Screenshot ausgibt — der Blick in den ausgelieferten Seitenquelltext allein genügt hier nicht.

Eindeutigkeit: Doppelungen auflösen

Derselbe Inhalt unter mehreren Adressen ist der häufigste Befund in technischen Audits. Auslöser sind Varianten mit und ohne www, HTTP neben HTTPS, Adressen mit und ohne abschließenden Schrägstrich, Parameter für Tracking und Sortierung, Druckansichten und Paginierungen.

Gelöst wird das mit einer festgelegten Vorzugsvariante, dauerhaften 301-Weiterleitungen und dem Canonical-Tag. Wichtig ist dabei, dass Canonical ein Hinweis ist, dem Google folgen kann, aber nicht muss — widersprüchliche Signale, etwa ein Canonical auf eine Seite, die intern nirgends verlinkt und in keiner Sitemap steht, werden regelmäßig ignoriert. Was dabei sonst schiefgehen kann, beschreibt der Beitrag zu Duplicate Content.

Bei mehrsprachigen oder mehrländrigen Websites kommt hreflang hinzu. Die Auszeichnung muss wechselseitig sein: Jede Sprachvariante verweist auf alle anderen und auf sich selbst. Fehlende Rückverweise sind der klassische Fehler.

Auslieferung: Statuscodes, Protokolle, Geschwindigkeit

HTTP-Statuscodes sind das direkteste Signal an einen Crawler. Eine gelöschte Seite gibt 410 oder 404 zurück, keine Weiterleitung auf die Startseite und keine Fehlerseite mit Status 200 — solche „Soft 404“ verbrauchen Crawling-Kapazität und verwirren die Indexierung. Weiterleitungsketten über mehrere Stationen gehören auf einen Sprung reduziert.

HTTPS ist Standard und ein bestätigtes, wenn auch schwaches Signal. HTTP/2 und HTTP/3 wickeln mehrere Anfragen parallel über eine Verbindung ab; damit sind die alten Ratschläge zur Reduktion von Requests, zu CSS-Sprites und zum Zusammenlegen von Dateien weitgehend überholt. Das Gesamtgewicht der Seite bleibt entscheidend, die Anzahl der Dateien nicht mehr.

Die Ladezeit ist über die Core Web Vitals in die Bewertung eingezogen. Was dort gemessen wird und wie Feld- und Labordaten zusammenhängen, beschreibt der Eintrag zu Page Speed. Die Indexierung selbst erfolgt inzwischen ausschließlich über den Smartphone-Crawler; Inhalte, die nur in der Desktop-Variante ausgeliefert werden, existieren für Google nicht.

Werkzeuge

Die Google Search Console und die Bing Webmaster Tools liefern die Daten, die von der Suchmaschine selbst stammen: Indexierungsstatus, Crawling-Statistiken, Core Web Vitals, erkannte strukturierte Daten, manuelle Maßnahmen. Sie sind der Ausgangspunkt, weil kein Drittanbieter diese Perspektive rekonstruieren kann.

Dazu kommen Crawler, die eine Website wie ein Bot durchlaufen und Statuscodes, Titel, Canonicals, Weiterleitungen und interne Verlinkung in einer Tabelle ausgeben, sowie PageSpeed Insights für die Ladezeit. Aussagekräftig, aber selten genutzt, sind Server-Logfiles: Sie zeigen, welche URLs der Googlebot tatsächlich abgerufen hat — und nicht, welche er nach Meinung eines Werkzeugs abrufen sollte.

Googles Mobile-Friendly-Test wurde Ende 2023 eingestellt, nachdem mobile Darstellung zum Normalfall geworden war. Die entsprechenden Prüfungen sind heute Teil der allgemeinen Werkzeuge.

Womit man anfängt

Die Reihenfolge ergibt sich aus der Abhängigkeit: erreichbar, crawlbar, indexierbar, eindeutig, schnell. Ein Audit, das mit der Optimierung von Bilddateien beginnt, während die Hälfte der Kategorieseiten auf noindex steht, arbeitet in der falschen Reihenfolge.

Technische Arbeit greift dabei ins Fundament ein und braucht Zugriff auf Server, Template und Deployment — sie ist eher Sache der Entwicklung als der Redaktion. Wie sie mit inhaltlicher und struktureller Optimierung zusammenspielt, beschreibt unsere Leistungsseite zur Suchmaschinenoptimierung.