Angular ist ein Framework für Webanwendungen, das von Haus aus im Browser rendert. Der Server schickt eine fast leere HTML-Seite, und erst JavaScript baut den sichtbaren Inhalt auf. Für Nutzer ist das kaum zu unterscheiden, für Suchmaschinen schon. Google kann JavaScript ausführen, aber das kostet einen zusätzlichen Schritt, und laut Google können nicht alle Bots JavaScript ausführen [1]. Angular SEO dreht sich deshalb vor allem um eine Frage: Steht der Inhalt im HTML, bevor JavaScript läuft? Dieser Ratgeber zeigt, welche Werkzeuge Angular dafür mitbringt und worauf Sie bei Routing, Meta-Daten und Links achten.
Wie Google JavaScript-Seiten verarbeitet
Google beschreibt die Verarbeitung von JavaScript-Webanwendungen in drei Hauptphasen: Crawling, Rendering und Indexierung [1]. Alle Seiten mit dem HTTP-Statuscode 200 werden an die Rendering-Warteschlange gesendet [1]. Erst nach dem Rendern sieht Google, was JavaScript auf die Seite geschrieben hat. Google schreibt zugleich, serverseitiges Rendering oder Pre-Rendering sei trotzdem eine sehr gute Option, weil es die Website für Nutzer und Crawler schneller macht und nicht alle Bots JavaScript ausführen können [1]. Die Grundlagen dazu beschreibt der Ratgeber JavaScript-SEO Grundlagen, den Ablauf auf Googles Seite der Ratgeber Rendering durch Google.
Die drei Render-Modi in Angular
Angular kennt in seiner aktuellen Dokumentation drei Render-Modi, die sich je Route festlegen lassen [2]:
| Modus | Beschreibung in der Angular-Dokumentation | passt für |
|---|---|---|
| Client (CSR) | rendert die Anwendung im Browser, das Standardverhalten von Angular | Bereiche hinter einer Anmeldung, die nicht in die Suche sollen |
| Server (SSR) | rendert die Anwendung bei jeder Anfrage auf dem Server und schickt eine vollständige HTML-Seite | Seiten mit häufig wechselnden Inhalten, etwa Lagerbestand oder Suchergebnisse |
| Prerender (SSG) | rendert beim Build und erzeugt statische HTML-Dateien für jede Route | Seiten, die für alle Besucher gleich sind, etwa Ratgeber, Leistungen, Produktbeschreibungen |
Die Spalte "passt für" ist unsere Einordnung. Die Angular-Dokumentation hält fest, dass serverseitiges Rendern im Allgemeinen eine sehr gute Suchmaschinenoptimierung hat und Seiten schneller lädt als reines Rendern im Browser [2]. Vorrendern liefert laut Angular statisches HTML und eignet sich vor allem für Inhalte, die für alle Nutzer gleich sind [2].
Eingerichtet wird serverseitiges Rendern bei neuen Projekten mit ng new --ssr, bei bestehenden mit ng add @angular/ssr [2]. Die Grundsatzfrage zwischen Rendern im Browser und auf dem Server behandelt der Ratgeber Client-side oder Server-side Rendering.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Hydration: der Schritt nach dem Server
Wenn der Server eine fertige Seite liefert, muss Angular sie im Browser übernehmen, damit sie interaktiv wird. Diesen Schritt nennt Angular Hydration: Er stellt die serverseitig gerenderte Anwendung auf dem Client wieder her [3]. Ohne Hydration baut Angular die Seite im Browser neu auf. Laut Angular kann das zu Flackern führen und sich negativ auf Core Web Vitals wie den LCP auswirken und eine Layoutverschiebung verursachen [3]. Mit Hydration wird das vorhandene DOM wiederverwendet [3].
Wer serverseitiges Rendern über die Angular CLI hinzugefügt hat, findet den Code für Hydration laut Dokumentation bereits in der Anwendung [3]. Bei eigenen Setups muss provideClientHydration() von Hand ergänzt werden [3]. Wichtig für SEO: Server und Browser müssen dasselbe HTML erzeugen. Rendern Server und Browser unterschiedliche Inhalte, nennt Angular als Folge Hydration-Fehler und Layoutverschiebungen [2].
Adressen ohne Raute
Angular kann den Zustand des Routers auf zwei Arten in der Adresse abbilden. Die HashLocationStrategy speichert ihn im Fragment der Adresse, also hinter einer Raute [4]. Die PathLocationStrategy bildet ihn im Pfad der Adresse ab [5]. Für die Suche ist das ein großer Unterschied. Google empfiehlt für Single-Page-Apps die History API und schreibt, man solle zum Laden anderer Seiteninhalte keine Fragmente verwenden [1]. Adressen wie example.com/#/leistungen sind deshalb für SEO ungeeignet, example.com/leistungen ist richtig.
Bei der PathLocationStrategy braucht die Anwendung ein base-Element oder APP_BASE_HREF, die mit einem Schrägstrich enden sollten [5]. Der Server muss außerdem für jede Route antworten, nicht nur für die Startseite. Sonst liefert ein direkter Aufruf von /leistungen einen Fehler.
Titel und Beschreibung je Route
Jede Seite braucht einen eigenen Titel und eine eigene Beschreibung. Google bestätigt, dass sich das title-Element und die Meta-Beschreibung per JavaScript festlegen oder ändern lassen [1]. Angular stellt dafür Services bereit. Der Meta-Service ist laut Dokumentation ein Service zur Verwaltung von HTML-meta-Tags und bietet Methoden wie addTag und updateTag [6]. Den Seitentitel setzt der Title-Service, laut Dokumentation ein Service, mit dem sich der Titel des aktuellen HTML-Dokuments lesen und setzen lässt [9].
Mit serverseitigem Rendern oder Vorrendern stehen Titel und Beschreibung dann schon im ausgelieferten HTML. Das kann auch für Vorschauen beim Teilen relevant sein, denn nicht jeder Dienst führt JavaScript aus, bevor er og:title und og:image liest. Ein Sonderfall ist noindex: Google warnt, dass beim Fund eines noindex-Tags das Rendern und die JavaScript-Ausführung möglicherweise übersprungen werden [1]. Ein noindex im HTML, das JavaScript später entfernen soll, funktioniert also nicht.
Echte Links statt Klick-Handler
Google kann einen Link im Allgemeinen nur crawlen, wenn es sich um ein a-Element mit href-Attribut handelt [7]. Angular erfüllt das, wenn die Direktive RouterLink auf einem a-Element sitzt: Laut Dokumentation setzt sie dann ein href-Attribut am Element [8]. Problematisch sind Navigationen über (click)-Handler auf div- oder button-Elementen, die per JavaScript die Route wechseln. Solche Elemente sind für Google keine Links. Google nennt selbst Beispiele wie ein a-Element mit onclick-Aufruf oder ein span mit href als nicht empfohlene Formen [7].
Fehlerseiten in Single-Page-Apps
Eine Angular-Anwendung liefert beim Rendern im Browser oft für jede Adresse den Status 200, auch für Seiten, die es nicht gibt. Google nennt für solche Soft-404-Fehler zwei Lösungen: eine JavaScript-Weiterleitung auf eine Adresse, für die der Server mit 404 antwortet, oder ein per JavaScript hinzugefügtes noindex auf der Fehlerseite [1]. Mit serverseitigem Rendern lässt sich der richtige Statuscode direkt vom Server senden. Das ist die sauberste Lösung.
Prüfen, was Google sieht
Prüfen Sie nach jeder größeren Änderung drei Dinge: den Quelltext, den der Server liefert, mit Titel, Beschreibung und Hauptinhalt; das gerenderte HTML im URL-Prüftool der Search Console; und eine Liste aller Links, die ein Crawler ohne JavaScript findet. Weichen diese drei Ansichten stark voneinander ab, liegt dort die Ursache für Indexierungsprobleme. Andere Frameworks behandeln die Ratgeber React und SEO und Vue und SEO, die Begriffe das Glossar unter Server-Side Rendering.
Ihre Angular-Anwendung ist in Google kaum sichtbar, und Sie wissen nicht, ob es am Rendering liegt? Stellen Sie die Frage in der gratis Sprechstunde, dort sehen wir uns gemeinsam den ausgelieferten Quelltext an.
- Organisation Grundlagen von JavaScript-SEO. Google Search Central. Stand 04.03.2026. abgerufen am 31.10.2026
- Organisation Server and hybrid rendering. Angular (angular.dev). Stand v22. abgerufen am 31.10.2026
- Organisation Hydration. Angular (angular.dev). Stand v22. abgerufen am 31.10.2026
- Organisation HashLocationStrategy. Angular (angular.dev). Stand v22. abgerufen am 31.10.2026
- Organisation PathLocationStrategy. Angular (angular.dev). Stand v22. abgerufen am 31.10.2026
- Organisation Meta. Angular (angular.dev). Stand v22. abgerufen am 31.10.2026
- Organisation Best Practices für Links. Google Search Central. Stand 31.12.2025. abgerufen am 31.10.2026
- Organisation RouterLink. Angular (angular.dev). Stand v22. abgerufen am 31.10.2026
- Organisation Title. Angular (angular.dev). Stand v22. abgerufen am 31.10.2026
Häufige Fragen
Kann Google Angular-Seiten indexieren?
Ja, Google rendert JavaScript in einer eigenen Phase nach dem Crawling. Serverseitiges Rendern oder Vorrendern ist laut Google trotzdem eine sehr gute Option, weil der Inhalt dann sofort im HTML steht.
SSR oder Prerender: was ist besser für SEO?
Beides liefert fertiges HTML. Vorrendern beim Build ist am schnellsten und passt für Seiten, die für alle Besucher gleich sind. Serverseitiges Rendern bei jeder Anfrage passt für Inhalte, die sich häufig ändern.
Warum sollte ich keine Adressen mit Raute verwenden?
Google empfiehlt für Single-Page-Apps die History API und rät davon ab, Seiteninhalte über Fragmente zu laden. Die PathLocationStrategy von Angular erzeugt Adressen ohne Raute.
Ist routerLink ein Link, den Google crawlen kann?
Auf einem a-Element setzt die Direktive RouterLink ein href-Attribut. Dann ist es ein normaler, crawlbarer Link. Auf anderen Elementen ohne href erkennt Google keinen Link.
Wie setze ich Titel und Beschreibung in Angular?
Über den Title-Service mit setTitle und über den Meta-Service mit updateTag. Mit serverseitigem Rendern stehen beide dann schon im ausgelieferten HTML.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Haben Sie einen Fehler entdeckt? Schreiben Sie uns.
