SEO WISSEN · TECHNIK

Technisches SEO für Crawling, Rendering und Indexierung.

Ich prüfe technisches SEO nicht als Sammlung einzelner Häkchen. Entscheidend ist, ob Suchmaschinen wichtige Seiten zuverlässig finden, rendern, verstehen und als richtige URL indexieren können.

Vom Crawling bis zur Indexierung: drei unterschiedliche Schritte

Eine Seite kann erreichbar sein und trotzdem nicht sauber indexiert werden. Google beschreibt für JavaScript-Seiten drei Phasen: Crawling, Rendering und Indexierung. Genau diese Trennung ist wichtig, wenn ich technische SEO-Probleme analysiere.

Beim Crawling geht es zunächst um Erreichbarkeit und Links. Beim Rendering wird die Seite mit Chromium ausgeführt. Erst danach kann Google den gerenderten Inhalt für die Indexierung verwenden. Wenn Inhalte erst nach einer Nutzeraktion erscheinen, kann das problematisch werden, weil Google nicht wie ein Mensch durch die Seite klickt oder scrollt.

Praxis

Ich teste nicht nur den Quellcode. Bei JavaScript-Seiten prüfe ich auch das gerenderte HTML mit URL-Prüfung oder Rich Results Test.

Die technischen Signale, die zuerst stimmen müssen

Statuscodes

200 für echte Seiten, 301/308 für dauerhafte Umzüge und 404/410 für entfernte Inhalte.

Canonical

Hilft Google, bei ähnlichen oder doppelten URLs die bevorzugte Version zu verstehen.

robots.txt & noindex

Steuern unterschiedliche Dinge: Crawling und Indexierung dürfen nicht verwechselt werden.

Interne Links

Wichtige Seiten brauchen echte crawlbare Links und dürfen nicht nur über JavaScript-Aktionen erreichbar sein.

JavaScript SEO: Google kann viel rendern, aber das ist kein Freifahrtschein

Google führt JavaScript mit einer Evergreen-Version von Chromium aus. Trotzdem empfehle ich, wichtige Inhalte und Links möglichst robust auszuliefern. Serverseitiges oder statisches Rendering kann Nutzer und Crawler entlasten und verhindert, dass Kerninhalte von einem fehlerfreien Client-Rendering abhängen.

Besonders kritisch sind Inhalte, die erst nach Klick, Scroll oder anderen Interaktionen geladen werden. Lazy Loading sollte so umgesetzt sein, dass relevante Inhalte geladen werden, sobald sie in den Viewport kommen – nicht erst nach einer Nutzeraktion.

Modernes Rendering: robuste HTML-Basis statt Bot-Sonderlösung

Für öffentliche SEO-relevante Inhalte bevorzuge ich SSR, statisches Rendering oder Hydration, wenn eine Anwendung technisch darauf angewiesen ist. Das reduziert Abhängigkeiten und macht die Ausgabe leichter testbar.

Für NutzerWeniger Wartezeit bis zum sichtbaren Inhalt und weniger Risiko, dass kritische Bereiche bei Skriptfehlern fehlen.

Für SuchmaschinenWichtige Inhalte und Links sind früher und zuverlässiger verfügbar.

Typische technische SEO-Fehler, die ich regelmäßig sehe

  • Canonicals zeigen auf falsche oder nicht erreichbare URLs.
  • Interne Links führen über Redirect-Ketten oder auf 404-Ziele.
  • robots.txt blockiert Ressourcen, die für Rendering gebraucht werden.
  • Soft-404-Seiten liefern weiterhin HTTP 200.
  • Filter- und Parameter-URLs erzeugen unnötig viele Varianten.
  • Wichtige Inhalte existieren nur im Client und fehlen bei Rendering-Fehlern.

Was im technischen SEO heute veraltet ist

  • Dynamic Rendering als Standardlösung: Google bezeichnet es nur noch als Workaround und empfiehlt SSR, Static Rendering oder Hydration.
  • „Google kann kein JavaScript“: falsch. Google rendert JavaScript, aber robuste Auslieferung bleibt sinnvoll.
  • robots.txt verhindert Indexierung sicher: falsch. Eine blockierte URL kann unter Umständen trotzdem als URL bekannt sein; für Indexierungssteuerung ist noindex das passende Signal, sofern Google die Seite crawlen darf.
  • Crawl Budget für jede kleine Website optimieren: meist unnötig. Bei kleinen und mittleren Websites liegen die größeren Hebel oft bei Architektur, Qualität und technischen Fehlern.

Häufige Fragen

Ist JavaScript schlecht für SEO?

Nein. Entscheidend ist, ob wichtige Inhalte und Links nach dem Rendering zuverlässig sichtbar sind und die Seite technisch sauber ausgeliefert wird.

Was ist besser: SSR oder CSR?

Das hängt vom Projekt ab. Für öffentliche SEO-relevante Inhalte ist serverseitige oder statische Ausgabe oft robuster, besonders wenn Kerninhalte nicht von Client-JavaScript abhängen sollen.

Was prüfe ich zuerst?

Statuscodes, Indexierbarkeit, Canonicals, interne Links, Sitemap, robots-Regeln und das tatsächlich gerenderte Ergebnis.

RESSOURCEN

Weiterführende Links