Angular SEO in der Praxis: Prerender, Canonical, Hydration und echte 404-Seiten

„Angular ist schlecht für SEO“ ist ungefähr so präzise wie „Autos sind schlecht für den Stadtverkehr“.

Es kommt darauf an, wie man sie baut und benutzt.

Eine Angular-Anwendung, die dem Crawler zunächst nur ein leeres `<app-root>` liefert und alle wichtigen Inhalte erst später über mehrere Requests nachlädt, macht Suchmaschinen die Arbeit unnötig schwer. Eine vollständig prerenderte Angular-Marketingseite kann dagegen sehr sauberes HTML ausliefern – ohne dass auf dem Produktionsserver überhaupt ein Node-Runtime laufen muss.

Genau dieser Unterschied ist entscheidend.

CSR, SSR und SSG sind nicht dasselbe

Client-Side Rendering

Beim klassischen SPA-Modell liefert der Server im Wesentlichen das App-Shell-HTML und JavaScript.

Der Browser baut die eigentliche Seite auf.

Für komplexe interne Anwendungen ist das völlig legitim. Für eine öffentliche Marketingseite mit SEO-Schwerpunkt würde ich es nicht als erste Wahl verwenden.

Server-Side Rendering

Beim SSR wird die Seite bei einem Request auf dem Server gerendert.

Das ist leistungsfähig, benötigt aber einen Server-Runtime, zum Beispiel Node.

Wenn das Hosting nur statische Dateien ausliefert, fällt dieses Modell weg.

Static Site Generation / Prerender

Beim Prerender wird die Seite bereits während des Builds erzeugt.

Aus:

`/de/seo-wien/`

wird beispielsweise:

`dist/.../browser/de/seo-wien/index.html`

Der Produktionsserver muss danach kein Angular rendern. Apache oder ein CDN liefert nur fertige Dateien aus.

Für eine Unternehmenswebsite oder einen Blog mit bekannten Routen ist das oft ein sehr gutes Modell.

Was Google tatsächlich bekommt

Bei einer sauber prerendered Seite sollte der initiale HTML-Response bereits enthalten:

• Title
• Meta Description
• Canonical
• hreflang
• H1
• Hauptinhalt
• interne Links
• strukturierte Daten

JavaScript ist danach für Interaktivität zuständig, nicht dafür, ob der zentrale Inhalt überhaupt existiert.

Hydration: statisches HTML wird interaktiv

Prerender bedeutet nicht, dass die Website „kein Angular mehr ist“.

Der Nutzer bekommt zunächst fertiges HTML. Anschließend übernimmt Angular durch Hydration die bereits vorhandene Struktur und macht Komponenten interaktiv.

Das ist eine gute Kombination:

• schneller sichtbarer Inhalt
• crawlbares HTML
• Angular-Komponenten
• clientseitige Interaktivität

Canonical muss zur echten URL passen

Ein kleines Detail kann erstaunlich viel Unordnung erzeugen.

Angenommen, der statische Host verwendet:

`/de/seo-wien/`

aber der Canonical lautet:

`/de/seo-wien`

und interne Links verwenden mal die eine, mal die andere Variante.

Google kann solche Signale normalerweise konsolidieren. Trotzdem ist es unnötig, ihm widersprüchliche Versionen anzubieten.

Darum sollte dieselbe URL-Form verwendet werden in:

• Canonical
• Sitemap
• hreflang
• internen Links
• JSON-LD
• OpenGraph

Bei statisch erzeugten Verzeichnissen ist ein abschließender Slash oft die natürlichste Form.

Warum interne Redirects vermieden werden sollten

Wenn ein interner Link auf:

`/de/seo-wien`

zeigt und Apache anschließend auf:

`/de/seo-wien/`

weiterleitet, funktioniert die Seite.

Aber die Website erzeugt selbst einen unnötigen Redirect.

Besser:

`href="/de/seo-wien/"`

und direkt 200.

Das lässt sich in einem Build-Validator automatisiert prüfen.

Der unterschätzte SPA-Fallback

Viele Angular-Deployments verwenden:

```apache RewriteRule ^ index.html [L] ```

Das ist für ein Client-Side-SPA sinnvoll.

Bei einem vollständig prerendered Marketingauftritt kann es aber einen unerwünschten Effekt haben:

`/de/diese-seite-gibt-es-nicht/`

existiert nicht, Apache liefert trotzdem `index.html`, Angular zeigt optisch eine 404-Komponente – aber der HTTP-Status kann weiterhin `200 OK` sein.

Das ist keine echte 404.

Für reines SSG bevorzuge ich:

• vorhandener statischer Pfad → 200
• unbekannter Pfad → Server-404
• eigenes 404-Template über `ErrorDocument`

Build-Validierung statt Hoffnung

Ein großer Vorteil von SSG ist, dass man den tatsächlichen Output vor dem Deployment prüfen kann.

Ein Validator kann jede erzeugte HTML-Datei öffnen und testen:

• genau ein H1
• Title vorhanden
• Description vorhanden
• Canonical entspricht erwarteter URL
• robots korrekt
• hreflang vorhanden
• interne Links kanonisch
• strukturierte Daten vorhanden
• Sitemap-URL besitzt tatsächlich eine HTML-Datei

Damit wird SEO teilweise zu einem automatisierten Build-Test.

Das gefällt mir deutlich besser als „nach dem Deployment schauen wir mal, was Google sagt“.

Wann ich Angular für eine SEO-Seite einsetzen würde

Angular ist sinnvoll, wenn das Team Angular wirklich beherrscht und die Website mehr als nur fünf statische Seiten werden soll.

Ich würde es aber nur einsetzen, wenn:

• Prerender/SSR sauber eingerichtet ist
• Inhalte im initialen HTML stehen
• Routing und Canonicals kontrolliert werden
• Performance gemessen wird
• unnötige Client-Bundles vermieden werden
• echte HTTP-Statuscodes funktionieren

Wenn eine einfache statische Website mit zehn Seiten das Ziel ist und niemand im Team Angular kennt, wäre Angular nur zusätzliche Komplexität.

Technologie sollte zum Projekt passen – nicht zum Lebenslauf des Entwicklers.

Fazit

Angular und SEO schließen sich nicht aus.

Für einen statisch gehosteten Unternehmensauftritt ist Prerender/SSG + Hydration + konsistente Canonicals + echte 404 eine robuste Architektur.

Die wichtigste Frage lautet nicht „Kann Google Angular?“, sondern: Welches HTML und welchen HTTP-Status liefert meine Produktion tatsächlich aus?

Wer eine technische SEO-Prüfung für eine bestehende Anwendung benötigt, findet unter SEO Wien den allgemeinen Ablauf.