Technische SEO: Was im Code und im CMS geändert wird, damit Google Ihre Seiten sieht

Technische SEO ist die Infrastruktur unterhalb von Inhalten und Verlinkung. Sie beantwortet vier Fragen in einer festen Reihenfolge: Kann der Googlebot die URL abrufen? Kann er die Seite vollständig rendern? Darf und kann er sie indexieren? Und wie schnell und stabil wird sie an Nutzer ausgeliefert?

Diese Reihenfolge bestimmt auch die Umsetzung. Ein guter Inhalt kann keine Sichtbarkeit aufbauen, wenn wichtige Ressourcen blockiert sind, der Hauptinhalt beim Rendern verschwindet oder der Server für eine Fehlerseite den Statuscode 200 sendet.

Deshalb arbeiten wir bei technischer SEO direkt an CMS-Regeln, Templates, Frontend-Code, Routing und Serverkonfiguration. Nicht der Befund steht im Mittelpunkt, sondern die konkrete Änderung am System.

Was ist der Unterschied zwischen technischer SEO und Onpage-Optimierung?

Onpage-Optimierung bearbeitet die inhaltlichen Signale einer einzelnen Seite. Dazu gehören der Title-Tag, die Meta-Description, Überschriften, Keyword-Platzierung und Textformatierung. Diese Entscheidungen werden normalerweise im CMS-Editor getroffen und können sich von Seite zu Seite unterscheiden.

Technische SEO verändert dagegen, wie das System Seiten erzeugt, erreichbar macht und ausliefert. Dazu zählen:

• HTTP-Statuscodes und Weiterleitungen
• robots.txt und Robots-Anweisungen
• Canonical-Regeln
• XML-Sitemaps
• URL- und Parameterlogik
• serverseitiges Rendering und JavaScript-Hydration
• Ladeverhalten und Core Web Vitals
• strukturierte Daten in Templates

Die praktische Trennlinie verläuft zwischen Einzelentscheidung und Systemregel. Den Title einer Leistungsseite anzupassen ist Onpage-Optimierung. Die Logik zu ändern, mit der das CMS Titles für einen vollständigen Seitentyp erzeugt, ist technische SEO.

Technische Änderungen wirken deshalb oft auf viele URLs gleichzeitig. Ein korrigiertes Template kann mehrere hundert Seiten reparieren. Ein fehlerhaftes Template kann ebenso viele Seiten von der Indexierung ausschließen.

Die technische Reihenfolge: Crawling, Rendering, Indexierung, Auslieferung

Google verarbeitet eine Webseite nicht als fertiges Bild. Der Googlebot ruft zunächst die URL und ihre Ressourcen ab. Danach verarbeitet Google die empfangenen Daten und führt bei Bedarf JavaScript aus. Erst auf Grundlage des gerenderten Ergebnisses wird entschieden, welcher Inhalt unter welcher URL indexiert werden kann.

Daraus folgt die Reihenfolge für die Umsetzung:

1. Der Googlebot muss die URL und die erforderlichen Ressourcen abrufen können.
2. Der indexierungsrelevante Inhalt muss im gerenderten HTML vorhanden sein.
3. Statuscode, Canonical, Robots-Anweisung, interne Links und Sitemap müssen dieselbe Indexierungsentscheidung unterstützen.
4. Die Seite muss schnell und stabil ausgeliefert werden.

Wenn bereits der erste oder zweite Schritt scheitert, lösen spätere Performance-Änderungen das eigentliche Problem nicht.

Crawling im CMS und auf dem Server richtig steuern

Die robots.txt regelt, welche Bereiche ein konformer Crawler abrufen darf. Das zugrunde liegende Robots Exclusion Protocol ist seit September 2022 als RFC 9309 standardisiert. Die Datei ist öffentlich, gilt für ganze URL-Muster und ist keine Zugriffskontrolle. Vertrauliche Inhalte gehören hinter eine Anmeldung, nicht hinter eine robots.txt-Sperre.

Eine häufige Fehlkonfiguration ist noindex in der robots.txt. Google hat die Unterstützung dieser und anderer nicht dokumentierter Regeln zum 1. September 2019 eingestellt. Soll eine HTML-Seite nicht indexiert werden, gehört noindex in den Robots-Meta-Tag. Für PDFs und andere Dateien ohne HTML-Head wird die Anweisung über den X-Robots-Tag im HTTP-Header gesendet. Das ist in den aktuellen Google-Dokumentationen zu noindex eindeutig beschrieben.

Besondere Vorsicht verlangt die Kombination aus Disallow und noindex. Ist eine URL per robots.txt gesperrt, kann der Googlebot sie nicht abrufen und die Indexierungsanweisung deshalb nicht lesen. In der Umsetzung erlauben wir zunächst den Abruf, damit Google das noindex verarbeiten kann. Ob danach noch eine Crawling-Sperre erforderlich ist, wird getrennt entschieden.

Auch JavaScript- und CSS-Ressourcen dürfen nicht pauschal blockiert sein, wenn sie für den sichtbaren Inhalt benötigt werden. Regeln für alte Theme-, Asset- oder Build-Verzeichnisse werden entfernt oder präzisiert. Andernfalls rendert Google eine unvollständige Seite.

XML-Sitemaps aus den Indexierungsregeln generieren

Eine XML-Sitemap sollte den gewünschten indexierbaren Bestand widerspiegeln. Sie wird deshalb aus dem Veröffentlichungsstatus und den Indexierungsregeln des CMS generiert, nicht manuell gepflegt.

Aufgenommen werden nur URLs, die:

• mit Statuscode 200 antworten
• indexiert werden dürfen
• die gewünschte URL-Variante verwenden
• keinen widersprüchlichen Canonical enthalten

Weiterleitungen, Fehlerseiten, noindex-URLs und unwichtige Parametervarianten gehören nicht in die Sitemap. Eine einzelne Sitemap darf laut Google Search Central höchstens 50.000 URLs oder 50 MB unkomprimiert enthalten. Größere Bestände werden auf mehrere Dateien verteilt und können über eine Sitemap-Indexdatei zusammengefasst werden.

Crawl-Budget ist nicht für jede Website ein relevantes Optimierungsziel. Googles aktueller Leitfaden zum Crawl-Budget richtet sich vor allem an Websites mit mehr als einer Million Seiten, die regelmäßig aktualisiert werden, sowie an Bestände ab etwa 10.000 Seiten mit täglichen Änderungen. Diese Zahlen sind Orientierungspunkte, keine festen Grenzwerte.

Bei einer Unternehmenswebsite mit einigen hundert Seiten entstehen Crawling-Probleme häufiger durch unnötige URLs. Parameter, Kalender, interne Suchergebnisse oder fehlerhafte Router können nahezu unbegrenzt neue Adressen erzeugen. Solche URLs verhindern wir an ihrer Entstehungsquelle. Eine nachträgliche Sperre in der robots.txt beseitigt die zugrunde liegende URL-Logik nicht.

JavaScript-Rendering: Entscheidend ist das gerenderte HTML

Googlebot führt JavaScript mit einer laufend aktualisierten Chromium-Version aus. Die pauschale Aussage, Google könne kein JavaScript verarbeiten, ist deshalb falsch. Trotzdem bleibt Rendering eine zusätzliche Verarbeitungsstufe. Seiten mit Statuscode 200 können zunächst in einer Render-Warteschlange landen, bevor Chromium das JavaScript ausführt und Google das gerenderte HTML erneut verarbeitet. Diesen Ablauf beschreibt Google in den Grundlagen der JavaScript-SEO.

Für die Umsetzung gilt deshalb: Inhalte und Signale, von denen die Indexierung abhängt, sollten möglichst bereits in der ersten HTML-Antwort stehen. Dazu gehören insbesondere:

• Hauptüberschrift und Hauptinhalt
• interne Links als echte a-Elemente mit href
• Robots-Anweisung
• Canonical-Tag
• grundlegende Seitendaten

Google kann Canonicals und strukturierte Daten auch nach der JavaScript-Ausführung verarbeiten. Eine frühe serverseitige Ausgabe reduziert jedoch Abhängigkeiten und verhindert widersprüchliche Zustände zwischen Roh-HTML und gerendertem Ergebnis.

Ein normaler Blick in den Browser reicht für die Kontrolle nicht aus. Der Browser zeigt bereits den Zustand nach der JavaScript-Ausführung. Technisch vergleichen wir deshalb:

1. die ursprüngliche HTML-Antwort des Servers
2. das gerenderte HTML nach der JavaScript-Ausführung
3. die Ressourcen und Fehlermeldungen, die während des Renderings entstanden sind

Die URL-Prüfung der Google Search Console zeigt laut Googles Dokumentation zur JavaScript-Fehlersuche den gerenderten DOM, geladene Ressourcen, Konsolenausgaben und JavaScript-Ausnahmen. Damit lässt sich direkt prüfen, ob Google den vorgesehenen Inhalt erhält.

Fehlt der Hauptinhalt, suchen wir nicht nur im Seitentemplate. Häufig liegt die Ursache in einer blockierten JavaScript-Datei, einem nicht erreichbaren API-Endpunkt, einem Timeout oder einem Fehler, der die weitere Ausführung abbricht.

Hydration ohne Inhaltsverlust umsetzen

Viele moderne Frontends liefern zunächst serverseitig erzeugtes HTML aus. Anschließend übernimmt JavaScript die vorhandenen Elemente und ergänzt Interaktivität. Dieser Vorgang wird Hydration genannt.

Problematisch wird es, wenn Server und Browser unterschiedliche Zustände berechnen. Der Client kann das bereits ausgelieferte HTML dann verwerfen und durch eine leere, unvollständige oder abweichende Ansicht ersetzen. Nutzer sehen möglicherweise nur ein kurzes Flackern. Im gerenderten HTML des Googlebot kann der Hauptinhalt dagegen vollständig fehlen.

Die Korrektur findet im Frontend statt:

• Server und Client erhalten dieselbe Datenbasis.
• Der erste Renderdurchlauf hängt nicht von Browserwerten wie Fenstergröße oder lokalem Speicher ab.
• Zufallswerte, lokale Zeitangaben und wechselnde Datenstände werden nicht direkt in den ersten Renderzustand geschrieben.
• Hydration-Fehler bleiben während der Fehlerbehebung in der Konsole sichtbar.
• Fehlgeschlagene API-Abfragen führen nicht zu einem leeren Hauptbereich.

Ein tragfähiges Muster ist serverseitiges oder statisches Rendering für den indexierungsrelevanten Inhalt. JavaScript ergänzt danach Formulare, Filter, Akkordeons und andere Interaktionen, ohne den vorhandenen Inhalt auszutauschen.

Soft 404 und clientseitige Weiterleitungen beseitigen

Soft 404 entstehen häufig in Single-Page-Anwendungen. Der Server antwortet auf eine nicht vorhandene URL mit Statuscode 200. Erst das Frontend erkennt den fehlenden Datensatz und zeigt eine Fehlermeldung an. Google beschreibt eine solche Kombination aus Erfolgscode und Fehlerinhalt ausdrücklich als Soft 404.

Die saubere Lösung liegt im Router, CMS-Controller oder Backend:

• Nicht vorhandene Inhalte erhalten den Statuscode 404.
• Dauerhaft entfernte Inhalte ohne Ersatz können mit 410 antworten.
• Für entfernte Inhalte mit eindeutigem Nachfolger wird ein permanenter Redirect eingerichtet.
• Die gestaltete Fehlerseite wird zusammen mit dem korrekten Statuscode ausgeliefert.

Eine sichtbare Meldung wie „Seite nicht gefunden“ ersetzt keinen HTTP-Statuscode.

Dasselbe gilt für Weiterleitungen. Google empfiehlt nach Möglichkeit permanente serverseitige Redirects mit 301 oder 308. JavaScript-Weiterleitungen werden erst beim Rendering erkannt und können ausfallen, wenn dieser Schritt nicht erfolgreich abgeschlossen wird. Dauerhafte URL-Wechsel werden deshalb in der Serverkonfiguration, im Backend oder in der Redirect-Logik des CMS umgesetzt.

Indexierung auf eine eindeutige URL ausrichten

Wenn mehrere URLs denselben oder sehr ähnlichen Inhalt ausliefern, braucht Google konsistente Signale für die bevorzugte Variante. Der Canonical-Tag beeinflusst diese Auswahl, erzwingt sie aber nicht allein.

Wir richten deshalb alle beteiligten Signale auf dieselbe Ziel-URL aus:

• Canonical-Tag
• interne Links
• XML-Sitemap
• permanente Weiterleitungen
• Protokoll und Host
• Regeln für Trailing Slash
• Groß- und Kleinschreibung in URLs

Google bewertet Redirects und Canonical-Auszeichnungen als starke Signale, die Sitemap dagegen als schwächeres Signal. Die Kombination erhöht die Wahrscheinlichkeit, dass Google die gewünschte URL auswählt. Das geht aus der aktuellen Canonical-Dokumentation hervor.

Parameter, die nur Sortierung oder Darstellung verändern, erzeugen keinen eigenständigen Inhalt. Solche Varianten werden nicht intern verlinkt und nicht in die Sitemap geschrieben. Bleiben sie erreichbar, verweist ihr Canonical auf die parameterlose Hauptversion.

Die mobile Ausgabe ist die Grundlage der Indexierung

Seit dem 5. Juli 2024 crawlt und indexiert Google Websites für die reguläre Suche mit dem Smartphone-Googlebot. Googlebot Desktop kann weiterhin in Serverprotokollen erscheinen, etwa für einzelne andere Suchfunktionen. Für die normale Indexierung ist jedoch die mobile Ausgabe maßgeblich. Google hat diese letzte Umstellungsstufe im Search Central Blog angekündigt.

Technisch prüfen wir deshalb nicht nur das responsive Layout. Hauptinhalt, interne Links, Canonical, Robots-Anweisung und strukturierte Daten müssen auch in der mobilen Ausgabe vorhanden sein.

Aufklappbare Inhalte sind unproblematisch, wenn sie bereits mit der Seite ausgeliefert und lediglich visuell verborgen werden. Werden sie erst nach einem Klick von einer Schnittstelle geladen, hängt ihre Sichtbarkeit von einer Interaktion ab, die der Googlebot nicht ausführen muss.

Core Web Vitals im Code verbessern

Für eine gute Bewertung gelten folgende Grenzwerte:

• LCP von höchstens 2,5 Sekunden
• INP von höchstens 200 Millisekunden
• CLS von höchstens 0,1

Die Bewertung erfolgt jeweils am 75. Perzentil der Seitenaufrufe. Diese Grenzwerte dokumentiert web.dev. Interaction to Next Paint hat am 12. März 2024 First Input Delay als Core Web Vital ersetzt.

Der Core-Web-Vitals-Bericht der Search Console basiert auf realen Nutzungsdaten aus dem Chrome User Experience Report. Die Werte beziehen sich auf die zurückliegenden 28 Tage und werden für Gruppen ähnlicher URLs zusammengefasst. Das bestätigt die aktuelle Search Console Hilfe.

Laborwerte aus Lighthouse oder PageSpeed Insights helfen bei der Diagnose. Sie sind aber nicht mit den Felddaten des Berichts gleichzusetzen. Nach einem Deployment verändert sich die Bewertung schrittweise, während alte und neue Nutzungsdaten im 28-Tage-Fenster zusammenkommen.

Die Umsetzung richtet sich nach der betroffenen Metrik:

• Beim LCP optimieren wir das größte sichtbare Element, seine Bildgröße, sein Format, seine Ladepriorität, die Serverantwortzeit und das Caching. Das LCP-Element sollte nicht erst durch clientseitiges JavaScript erscheinen.
• Beim INP reduzieren wir lange Aufgaben auf dem Hauptthread, teilen große JavaScript-Pakete auf und vereinfachen aufwendige Event-Handler.
• Beim CLS reservieren wir Platz für Bilder, Einbettungen und Banner. Webfonts erhalten passende Fallback-Metriken, damit sich das Layout beim Schriftwechsel nicht verschiebt.

HTTPS gehört zur technischen Basis. Google verwendet es seit August 2014 als nach eigener Aussage leichtgewichtiges Rankingsignal. Es ist eine Voraussetzung für eine saubere Auslieferung, aber kein Ersatz für Crawling, Rendering und Performance.

AMP ist dagegen keine Voraussetzung für das Top-Stories-Karussell mehr. Diese Beschränkung wurde mit dem Page-Experience-Update 2021 aufgehoben.

Strukturierte Daten zentral im Template erzeugen

Strukturierte Daten werden aus denselben CMS-Feldern erzeugt wie die sichtbaren Informationen. Dadurch bleiben Seiteninhalt und JSON-LD synchron. Manuell gepflegte Markup-Blöcke auf einzelnen Seiten führen dagegen schnell zu veralteten Angaben.

Wir implementieren nur Typen, die zum tatsächlichen Seiteninhalt passen. Google zeigt FAQ-Rich-Results seit August 2023 regulär nur noch für bekannte, autoritative Behörden- und Gesundheitsseiten. HowTo-Rich-Results werden seit dem 13. September 2023 auch auf Desktop-Geräten nicht mehr angezeigt. Google dokumentiert beide Änderungen im Search Central Blog.

Nicht verwendetes Markup verursacht laut Google zwar nicht automatisch ein Problem, erzeugt aber auch keinen sichtbaren Vorteil. Pflegezeit fließt deshalb in passende, weiterhin unterstützte Datentypen.

In welcher Reihenfolge wird technische SEO umgesetzt?

Die Priorisierung folgt den technischen Abhängigkeiten:

1. Wir bereinigen robots.txt, Robots-Anweisungen und blockierte Ressourcen.
2. Wir korrigieren Statuscodes, Soft 404, Weiterleitungsketten und clientseitige Redirects.
3. Wir verlagern indexierungsrelevante Inhalte in die erste HTML-Antwort und beheben Hydration-Fehler.
4. Wir vergleichen Roh-HTML und gerendertes HTML mit dem vorgesehenen Seitenzustand.
5. Wir vereinheitlichen Canonicals, interne Links, URL-Regeln und Weiterleitungen.
6. Wir generieren XML-Sitemaps ausschließlich aus den gewünschten indexierbaren URLs.
7. Wir gleichen die mobile Ausgabe an die vollständige Seitenfassung an.
8. Wir verbessern LCP, INP und CLS direkt an Bildern, Skripten, Layout und Serverantworten.
9. Wir ziehen strukturierte Daten in die zuständigen Templates und kontrollieren die ausgelieferte Fassung.

So werden zuerst die Probleme behoben, die Abruf, Rendering oder Indexierung vollständig verhindern. Performance und ergänzendes Markup folgen, sobald Google die richtige URL mit dem richtigen Inhalt verarbeiten kann.

Technische SEO mit Umsetzung in Hannover

Wir setzen technische SEO gemeinsam mit Ihrer Entwicklung um oder arbeiten direkt in CMS, Repository, Frontend und Serverkonfiguration. Jede Änderung erhält einen eindeutigen technischen Zielzustand und durchläuft die vorhandenen Staging-, Freigabe- und Deployment-Prozesse.

Für Unternehmen aus Hannover und der Region stimmen wir uns bei Bedarf auch vor Ort mit internen Entwicklern, IT-Verantwortlichen oder der betreuenden Webagentur ab. Der erste Schritt ist die Einordnung, an welcher Stelle Ihre Website Inhalte verliert: beim Abruf, beim Rendering, bei der Indexierungssteuerung oder bei der Auslieferung. Danach beginnt die Umsetzung direkt an der Ursache.