Angular SEO

TL;DR — Angular builds the page in the browser with JavaScript by default, so the raw HTML a search engine first sees is nearly empty. The fix is to send real, finished HTML instead — using Angular’s built-in server-side rendering (@angular/ssr) or prerendering. Then handle the basics: a unique title and description on every page, clean URLs (no #), and real <a href> links.

The problem in one sentence

A default Angular app sends the browser a tiny HTML shell — basically one empty <div> — plus a big bundle of JavaScript. Your browser runs that JavaScript and then the page fills in with content. That’s called client-side rendering (CSR).

The trouble: when a search engine first downloads that URL, it sees the empty shell. Google can run the JavaScript to see the real content, but it does that later, in a separate step, and not always reliably. Evidence for this claim Google can render JavaScript but processes rendering as a stage after crawling. Scope: Google Search rendering; other crawler behavior is not covered by this record. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics Other crawlers — Bing, and the bots behind social previews — often can’t run the JavaScript at all. So they see nothing.

The fix: send finished HTML

Instead of making the browser (or the crawler) build the page, you build it ahead of time or on a server and send the complete HTML. Angular gives you two main ways:

• Server-side rendering (SSR) — a server runs Angular for each request and sends back the full page. Good for content that changes often. Evidence for this claim Angular supports server-side rendering and build-time prerendering through its SSR tooling. Scope: Current Angular SSR and prerender features. Confidence: high · Verified: 2026-07-14 Angular: Server-side and hybrid rendering
• Prerendering — Angular builds static HTML files for your pages at build time, so there’s no server needed. Fastest option, great for blog posts and marketing pages.

Modern Angular (version 17 and up) builds both of these right into the toolkit. You add it with one command: ng add @angular/ssr. (You may have heard the old name Angular Universal — that was the same idea as a separate add-on. Angular folded it into the core in v17 and renamed it.)

The other basics

• Give every page a unique title and description. Angular won’t do this for you — you set them in code using Angular’s built-in Title and Meta services. Without this, every page shares one title.
• Use clean URLs, not hash URLs. Angular’s default routing makes nice URLs like /products/shoes. Avoid the older “hash” style (/#/products) — search engines can’t reliably handle the part after the #.
• Use real links. Navigation has to be real <a href> links, not buttons or click handlers, or Google can’t follow them.

The thing most people get wrong

“Google can’t index Angular” is a myth — it can render JavaScript. But it’s slower and less reliable than just sending real HTML, and non-Google crawlers can’t do it at all. So for anything you want found, render on the server or prerender it.

Want the deeper version — hybrid rendering per route, hydration, the SEO services with code, and how to test what Google actually sees? Switch to the Advanced tab.

TL;DR — Angular SEO is one architectural decision wearing a lot of hats: get real HTML into the response instead of a client-rendered shell. Modern Angular (v17+) builds SSR into the CLI as @angular/ssr (the rebranded, integrated successor to Angular Universal). Prerender static routes, server-render dynamic ones, mix them with hybrid rendering, and hydrate so the server HTML is reused not rebuilt. Then do the blocking-and-tackling: unique titles/descriptions via the Title/Meta services (or the router’s TitleStrategy), HTML5 History routing — never HashLocationStrategy — real <a href> links, JSON-LD injected safely, and verification through URL Inspection. Dynamic rendering is a Google-acknowledged workaround, not a strategy.

The default is the problem: client-side rendering

A stock Angular build ships an index.html whose body is essentially <app-root></app-root> plus script tags. Without executing JavaScript, a crawler sees no headings, no copy, no links — the content is assembled in the browser after the bundle loads. This is the same core issue I describe in JavaScript SEO: the web moved off plain HTML, and CSR is the riskiest end of that spectrum.

(This guide’s implementation details — RenderMode APIs, hydrate triggers, event replay — reflect Angular v22. Version-specific features below are dated: the v17 SSR rename, v18 event replay, v19–v20 incremental hydration.)

CSR creates three distinct SEO problems:

1. Delayed, less-reliable indexing. Google processes JS apps in three phases — “Crawling, Rendering, and Indexing” — and rendering is deferred into a queue. Your content doesn’t exist for indexing until that render runs.
2. Worse Core Web Vitals. LCP suffers because the browser must download and execute a bundle before painting meaningful content.
3. Non-Google crawlers see the shell. Bingbot is far less consistent at JS rendering, and social/link-preview bots generally don’t render at all — so Open Graph tags and content injected client-side never reach them.

How Googlebot actually handles an Angular app

Googlebot is evergreen — it renders with a current version of Chrome’s V8 engine and updates alongside Chrome releases. Evidence for this claim Googlebot uses an evergreen version of Chromium for rendering. Scope: Google Search rendering engine; this does not remove application-level rendering risks. Confidence: high · Verified: 2026-07-14 Google: Evergreen Googlebot So it can run Angular. But the behavior has hard edges worth designing around:

• Rendering is queued, not immediate. Google documents distinct crawling, rendering, and indexing phases and doesn’t publish a fixed timetable for how long the rendering step takes to catch up to crawling. The industry shorthand for this is “two waves” — raw HTML indexed first (a blank shell for CSR Angular), rendered DOM indexed later, whenever that render runs. SSR/prerendering sidesteps the wait: the HTML is complete on the first fetch, so there’s no separate render pass for that content to wait on.
• The renderer is stateless. No cookies, no localStorage, no sessionStorage carried between loads; it declines permission prompts. Don’t gate content on client state.
• It doesn’t click or scroll, and it renders at a very tall viewport. Content behind an interaction won’t be seen.
• Resources are cached aggressively — use content-fingerprinted filenames (Angular’s default main.<hash>.js) so updated bundles aren’t served stale.

@angular/ssr — what it is and the naming history

Server-side rendering runs Angular on a Node server per request and returns fully rendered HTML, which the browser then hydrates (attaches event listeners to the existing DOM instead of re-rendering). Every crawler — Googlebot, Bingbot, social bots — gets complete HTML on the first request, no second wave required.

The naming trips people up, so be precise: “Angular Universal” was the historical SSR solution, shipped as an external package (@nguniversal/express-engine). With Angular v17 (November 2023), SSR was integrated directly into the Angular CLI and Application Builder and renamed @angular/ssr; the Angular Universal repository is now in maintenance mode. Evidence for this claim Modern Angular documents @angular/ssr as its server-side and hybrid rendering package. Scope: Current Angular documentation; historical Angular Universal details are not required for this claim. Confidence: high · Verified: 2026-07-14 Angular: Server-side and hybrid rendering The setup is now a one-liner:

# New project with SSR enabled
ng new my-app --ssr

# Add SSR to an existing project
ng add @angular/ssr

This replaces the old ng add @nguniversal/express-engine. Same idea, first-class tooling.

Prerendering (static generation / SSG)

Prerendering generates static HTML for routes at build time, so no server runs at request time — you can deploy to a CDN. It gives the fastest TTFB/FCP/LCP and the lowest operational cost. In v17+ you configure it per route via a server routes file (app.routes.server.ts) using RenderMode.Prerender, and outputMode: 'static' produces a fully static app.

The constraint: data must be available at build time, there’s no per-user content, and very large sites mean slow builds. It’s ideal for marketing pages, docs, and blog posts — exactly the content that most needs to rank and be cited.

Hybrid rendering — choose a mode per route

The big v17+ advancement is that rendering mode is a per-route decision, configured in app.routes.server.ts:

• RenderMode.Prerender — static routes (home, about, blog posts).
• RenderMode.Server — dynamic, per-request routes (search results, dashboards with fresh data).
• RenderMode.Client — internal-only routes you don’t want indexed anyway (admin UIs, authenticated-only screens). CSR is genuinely fine here.

This is the decision rule in practice: prerender what’s static, server-render what must be fresh, and only fall back to client rendering for things that shouldn’t be in the index.

Hydration — and the pitfall that wrecks CLS

Naive SSR has a flaw: the server sends HTML, then the browser throws it away and re-renders from scratch, causing a flash and wasted work. Hydration fixes that — the browser restores the server-rendered app and reuses the matching DOM instead of destroying and recreating it, only wiring up interactivity. Enable it in app.config.ts:

provideClientHydration()

Prerequisite: hydration is a client-side companion to SSR, not a standalone switch. provideClientHydration() only does something on a route that’s already server-rendered (or prerendered) — it can’t turn a RenderMode.Client route’s shell into server HTML. Enable SSR/prerendering for the route first.

Two newer capabilities matter for SEO-adjacent UX — neither changes Search indexing:

• Event replay (v18+): captures supported user interactions that happen before hydration finishes and replays them once it completes. It reduces lost clicks for the interaction types it supports; it’s a UX/interactivity feature, not an SEO one, and it has no effect on what Google indexes.
• Incremental hydration (v19 developer preview, stable in v20): depends on SSR, hydration, deferrable views, and event replay together — it isn’t a standalone feature. It’s powered by @defer blocks with hydrate triggers that control which boundaries stay dehydrated on the initial render; a hydrate never boundary stays dehydrated on first load but isn’t necessarily blocked from loading its dependencies on later client-side renders (e.g., after a route change). The SEO-relevant effect is indirect: less JavaScript hydrated upfront can help LCP, but the trigger config is a rendering detail, not a crawler-timing mechanism.

The critical pitfall: putting @if (isPlatformBrowser(...)) directly in a template causes the server and client to render different markup — a hydration mismatch — which produces layout shift and damages CLS. Use afterNextRender() for browser-only work instead of branching the template on platform.

Titles and meta tags — Angular’s built-in services

Angular can’t bind directly to the <title> element’s text, so you manage head tags through two services from @angular/platform-browser:

• Title — setTitle() / getTitle().
• Meta — addTag(), addTags(), updateTag(), getTag(), removeTag(), with selectors like name='description' or property='og:title'.

You do not need a third-party library for the basics. A shared SEO service is the clean pattern:

@Injectable({ providedIn: 'root' })
export class SeoService {
  private title = inject(Title);
  private meta = inject(Meta);

  updatePage(title: string, description: string) {
    this.title.setTitle(title);
    this.meta.updateTag({ name: 'description', content: description });
    this.meta.updateTag({ property: 'og:title', content: title });
  }
}

For titles specifically, the router’s TitleStrategy (Angular v14+) lets you set a title directly in the route config so the page title updates automatically on navigation — no per-component code. And don’t set document.title = ... by hand; use the Title service so it works correctly under SSR.

URL structure

• Use the default HTML5 History API routing (PathLocationStrategy) — clean URLs like /products/shoes. It needs <base href="/"> in index.html.
• Never use HashLocationStrategy / useHash: true for public content. Fragment identifiers after # are stripped before the HTTP request, so the server never sees them and Googlebot can’t reliably resolve #/products — your whole site can collapse to one URL.
• Real <a href> links for navigation, including to lazy-loaded routes. Lazy loading is fine for performance, but the links to those routes still have to be crawlable anchors, not click handlers.

Structured data (JSON-LD)

Google supports injecting JSON-LD with JavaScript. The robust Angular pattern is a service that creates a <script type="application/ld+json"> and appends it to document.head, using Angular’s DOCUMENT injection token rather than touching document globally (which breaks on the server). Keep all schema in one place — don’t split it between static HTML and the rendered DOM — and validate with the Rich Results Test plus URL Inspection.

Dynamic rendering — a legacy workaround, not a plan

Dynamic rendering serves a prerendered version to bots (via Puppeteer, Rendertron, or prerender.io) and the full SPA to users. Google is explicit that “dynamic rendering is a workaround and not a long-term solution,” and that there are “better solutions than dynamic rendering” — namely server-side rendering, static rendering, or hydration. It’s not automatically cloaking as long as you serve substantially similar content, but it adds an extra rendering server, risks content drift, and does nothing for real users’ Core Web Vitals. For a new Angular build, reach for @angular/ssr or prerendering instead.

Common Angular SEO mistakes

1. Hash routing (# URLs) — the whole site looks like one URL.
2. No Title/Meta calls — every page shares one title and description.
3. No SSR/prerendering — content only exists after the deferred render wave.
4. Blocking .js/.css in robots.txt — Google can’t render, indexes an empty shell.
5. Returning 200 on a not-found view — a soft 404; return a real 404 or add noindex.
6. document.title = ... instead of the Title service.
7. isPlatformBrowser() inside template @if — hydration mismatch → CLS.
8. Touching window/localStorage/document in code that runs on the server — SSR crashes.
9. Splitting schema between raw HTML and rendered DOM.
10. Testing in local dev instead of with URL Inspection — relying on assumptions, not Googlebot.

Testing Angular for SEO

• URL Inspection (Search Console) is the source of truth: the crawled-page view shows the rendered HTML — the DOM after Googlebot ran the JavaScript, which is what gets indexed — plus JS console messages and blocked resources. Run the Live Test for an on-demand render.
• curl the URL to see the raw, pre-JS HTML — an empty shell means CSR with no SSR.
• Rich Results Test validates structured data.
• Ahrefs Site Audit (JS rendering on) and Screaming Frog (JS mode) diff raw vs. rendered DOM at scale.
• Lighthouse / PageSpeed Insights for the Core Web Vitals impact of your rendering choice.

Angular is not bad for SEO — it’s just different. Get real HTML into the response, manage your head tags, keep URLs and links crawlable, and let Google’s own tools arbitrate what rendered. This topic sits alongside JavaScript SEO and the headless-CMS rendering questions in this cluster — the underlying lesson is the same across all of them: rendering mode decides almost everything.

AI summary

A condensed take on the Advanced version:

• Angular’s default is client-side rendering (CSR) — a near-empty HTML shell. That means delayed/unreliable indexing, worse LCP, and non-Google crawlers (Bing, social) seeing nothing.
• Googlebot is evergreen and renders JS, but rendering is queued (the “two waves” — raw HTML first, rendered DOM later, on no fixed timetable), stateless (no cookies/storage), doesn’t click/scroll, and caches resources hard. SSR/prerendering sidesteps the wait — the HTML is complete on first fetch, so there’s no separate render pass to wait on.
• @angular/ssr is the modern fix — SSR built into the Angular CLI since v17, replacing the externally maintained Angular Universal (@nguniversal/express-engine). Setup: ng new --ssr or ng add @angular/ssr.
• Prerendering (build-time static HTML) is fastest and CDN-deployable — best for static marketing/blog/docs content; limited to build-time data.
• Hybrid rendering sets the mode per route in app.routes.server.ts: RenderMode.Prerender (static), RenderMode.Server (dynamic), RenderMode.Client (non-indexed internal pages).
• Hydration (provideClientHydration()) reuses server HTML on an already-SSR/prerendered route — it doesn’t create server HTML for CSR. Event replay (v18+) captures supported pre-hydration interactions and replays them after; incremental hydration (v19 preview / v20 stable) depends on SSR + hydration + deferrable views + event replay together, using @defer hydrate triggers to control which boundaries stay dehydrated on the initial load (hydrate never doesn’t block later client-side loads). Neither changes Search indexing. Avoid isPlatformBrowser() in template @if — it causes hydration mismatch → CLS; use afterNextRender().
• Use the built-in Title and Meta services (no third-party lib needed); the router’s TitleStrategy (v14+) sets per-route titles automatically.
• Use HTML5 History routing, never hash (#) URLs; navigation must be real <a href> anchors. JSON-LD can be injected via the DOCUMENT token.
• Dynamic rendering is a workaround, not a strategy — Google recommends SSR/static/ hydration instead.
• Test with URL Inspection (rendered HTML), curl (raw HTML), Rich Results Test, and a JS-rendering crawler. AngularJS ≠ Angular — old AngularJS advice doesn’t apply.

Official documentation

Primary-source documentation from Google and Angular.

Google

• Understand the JavaScript SEO basics — the crawl → render → index phases, crawlable <a href> links, fragment-routing warnings, soft 404s, and JS-injected structured data.
• Dynamic Rendering (workaround) — why it’s a workaround, the cloaking nuance, and the SSR/static/hydration alternatives.
• Rendering on the Web (web.dev — Addy Osmani & Jason Miller) — canonical definitions of SSR, CSR, static rendering, and hydration, and their performance trade-offs.
• URL Inspection Tool — how to see the rendered HTML Google actually indexes, plus JS console messages.

Angular

• Angular — Server-side and hybrid rendering (SSR) — the official @angular/ssr guide, server routes, and RenderMode.
• Angular — Title service — setTitle() / getTitle().
• Angular — Meta service — addTag(), updateTag(), and selectors.
• Angular — Router reference — PathLocationStrategy vs. hash routing, TitleStrategy.
• Introducing Angular v17 (Angular team blog) — SSR becoming a first-class CLI feature.
• Angular Universal (maintenance mode) — the historical package, now superseded by @angular/ssr.

Quotes from the source

On-the-record statements from Google and from my own writing. Each search-engine link is a deep link that jumps to the quoted passage on the source page.

Google — how JavaScript apps are processed

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” — Google Search Central docs. Jump to quote
• “Google can only discover your links if they are <a> HTML elements with an href attribute.” — Google Search Central docs. Jump to quote

Google — dynamic rendering is a workaround

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” — Google Search Central docs. Jump to quote

web.dev — prefer SSR / static rendering (Addy Osmani & Jason Miller)

• “Rendering an app on the server to send HTML, rather than JavaScript, to the client.” — the definition of server-side rendering. Jump to quote

Patrick Stox (my own work — JavaScript SEO: A Definitive Guide)

• “JavaScript is not bad for SEO, and it’s not evil. It’s just different from what many SEOs are used to.”
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.”

Angular SEO checklist

A quick pass to confirm an Angular app is crawlable and indexable:

• Public content is served as real HTML via @angular/ssr (SSR) or prerendering, not full CSR.
• Rendering mode is set per route in app.routes.server.ts — prerender static routes, server-render dynamic ones, client-render only non-indexed internal pages.
• Hydration is enabled (provideClientHydration()), and no template uses isPlatformBrowser() inside @if (use afterNextRender() instead).
• Every page sets a unique title (via the Title service or router TitleStrategy) and a unique description (via the Meta service).
• Open Graph / Twitter Card tags are set with the Meta service for social previews.
• Routing uses the HTML5 History API (default) with <base href="/"> — not HashLocationStrategy / useHash: true.
• All navigation uses real <a href> anchors, including links to lazy-loaded routes.
• robots.txt does not block .js or .css resources.
• Client-side not-found views return a real 404 or carry noindex (no soft 404s).
• No window/localStorage/document access in code that runs on the server (use the DOCUMENT token / platform guards).
• JSON-LD is in one place and passes the Rich Results Test.
• You verified the rendered HTML in URL Inspection — not just local dev.

The mental models

1. Get real HTML into the response. Almost every Angular SEO problem reduces to one question: does the crawler get finished HTML on the first fetch, or a shell it has to render? SSR and prerendering answer “yes.” CSR answers “eventually, maybe.” Start every audit here.

2. The per-route rendering decision rule.

• Static content (home, about, blog, docs) → RenderMode.Prerender.
• Dynamic, must-be-fresh content (search, live data) → RenderMode.Server.
• Internal/authenticated pages you don’t want indexed → RenderMode.Client is fine.

3. “Angular Universal” and “@angular/ssr” are the same idea, different era. Universal was the external package; v17 absorbed SSR into the CLI and renamed it. If you’re on a modern Angular, you want @angular/ssr — the Universal repo is in maintenance mode.

4. Hydrate, don’t re-render. Naive SSR sends HTML and then throws it away. provideClientHydration() reuses it — but only on a route that’s already SSR/prerendered, it doesn’t create server HTML for a CSR route. Event replay and incremental hydration (@defer) shave upfront JavaScript. Never branch a template on isPlatformBrowser() — that’s how you get a hydration mismatch and a CLS hit.

5. Head tags are your job, not Angular’s. There’s no Yoast here. Set titles and descriptions deliberately with the Title/Meta services (or TitleStrategy), per page. “All pages share one title” is the default failure, not bad luck.

6. Design for a stateless bot on clean URLs. History-API routing, real <a href> links, no reliance on cookies/storage, no content behind a click. Then let URL Inspection — not your laptop — tell you what rendered.

Angular SEO — cheat sheet

Rendering modes

Setup commands

Head + routing fast rules

• Titles/descriptions: Angular’s Title + Meta services (no third-party lib needed).
• Auto per-route titles: router TitleStrategy (v14+) via the route title property.
• Routing: HTML5 History API + <base href="/">. Never useHash: true.
• Links: real <a href> anchors — even to lazy-loaded routes.
• JSON-LD: inject via the DOCUMENT token; keep it in one place.

Naming

• Angular Universal = old external package (@nguniversal/express-engine), maintenance mode.
• @angular/ssr = the same SSR, built into the CLI since v17.
• AngularJS (v1.x) ≠ Angular (v2+) — different frameworks; old AngularJS advice doesn’t apply.

Gotchas

• isPlatformBrowser() in template @if → hydration mismatch → CLS. Use afterNextRender().
• window/localStorage/document on the server → SSR crash.
• Blocking .js/.css in robots.txt → Google can’t render.

Check whether an Angular app is actually server-rendered

The fastest way to know if a URL is CSR or SSR/prerendered is to fetch the raw HTML (before any JavaScript runs) and look for your real content. A CSR Angular app returns an almost-empty <app-root>; an SSR/prerendered one returns finished markup.

macOS / Linux

# Raw HTML as the server sends it — this is the "first fetch", pre-JS
curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o raw.html

# Is your real headline in the raw HTML? Empty result = CSR with no SSR
grep -o "Your headline text" raw.html

# A near-empty <app-root> is the tell-tale CSR signature
grep -o "<app-root></app-root>" raw.html

Windows (PowerShell)

$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/page/" -UserAgent $ua -OutFile raw.html
Select-String -Path raw.html -Pattern "Your headline text"
Select-String -Path raw.html -Pattern "<app-root></app-root>"

If the headline is missing and you see a bare <app-root>, the content depends on rendering — add SSR or prerendering. (For the rendered DOM, use URL Inspection’s “View Crawled Page → rendered HTML”; a plain curl can’t run JS.)

Confirm you aren’t blocking Angular’s JS/CSS in robots.txt

macOS / Linux

curl -sL https://example.com/robots.txt | grep -iE "disallow.*\.(js|css)|Disallow:\s*/(assets|dist|main)"

A Disallow matching your bundle means Google can’t render the page properly — almost always a mistake.

Tools for debugging Angular SEO

• URL Inspection (Google Search Console) — the source of truth. Run a Live Test, then read the rendered HTML (the DOM after Googlebot ran your Angular JS), the screenshot, the page resources (what loaded vs. what was blocked), and JavaScript console messages.
• Rich Results Test — confirm your JSON-LD is present in the rendered output after any rendering change.
• curl — fetch the raw, pre-JS HTML to tell CSR (empty <app-root>) from SSR/prerendered.
• Ahrefs Site Audit (JS rendering enabled) — crawls with headless Chrome and diffs raw vs. rendered DOM, surfacing missing metadata, broken canonicals, and indexability issues at scale.
• Screaming Frog SEO Spider (JS-rendering mode) — compare raw vs. rendered content per URL.
• Lighthouse / PageSpeed Insights — measure the Core Web Vitals impact of your rendering strategy (CSR vs. SSR vs. prerender).
• Angular CLI / DevTools — confirm the build’s outputMode, server routes, and hydration are configured as you expect.

Resources worth your time

My related writing

• JavaScript SEO: A Definitive Guide — my full guide to rendering, DOM parity, the most-restrictive-directive rule, and which rendering setups are safe. Angular SEO is a specific application of everything here.
• The Beginner’s Guide to Technical SEO — where rendering and crawling fit in the bigger picture.

My speaking

• JavaScript SEO — Ungagged 2019 (SlideShare) — Googlebot’s stateless rendering behavior, viewport, and caching, plus the rendering approaches of the era. (Standing disclaimer: the dynamic-rendering recommendation in that deck is now outdated — Google has since called it a workaround.)

From around the industry

• Rendering on the Web (web.dev) — Addy Osmani & Jason Miller’s canonical piece on SSR, CSR, static rendering, and hydration trade-offs.
• Server-side and hybrid rendering (SSR) (angular.dev) — the official @angular/ssr guide: server routes, RenderMode, prerendering, and hydration.
• Introducing Angular v17 (Angular team blog) — the release that made SSR a first-class CLI feature and introduced the @angular/ssr package.
• Angular Universal (maintenance mode) (GitHub) — the historical SSR package that @angular/ssr replaced, useful for understanding the rename.
• Angular SEO Guide (Search Engine Journal, Jamie Indigo) — the classic two-wave-indexing walkthrough; strong on fundamentals though it predates the v17 rename.
• The Guide for Angular SSR (Angular Architects, Alexander Thalhammer, March 2025) — a code-heavy SSR setup guide; check code samples against the official @angular/ssr docs for API changes since publication.
• r/TechSEO — the community for rendering and indexing debugging.

Angular SEO anti-patterns

Concrete mistakes I see repeatedly in Angular apps — each one is a habit worth checking for directly, not just a theoretical risk.

Shipping a CSR-only build and calling it done

The default ng new output has no SSR or prerendering. It’s the fastest way to start a project and the easiest way to end up with an empty <app-root> on the first fetch. Why it’s wrong: the raw HTML a crawler sees has no content, so indexing depends entirely on Google’s deferred render pass — and other bots don’t get a second chance at all. Do instead: add @angular/ssr at the start of the project (ng new my-app --ssr), or run ng add @angular/ssr on an existing one, before you ship anything you want found.

Using HashLocationStrategy for public routes

Hash routing (useHash: true, URLs like /#/products/shoes) is still the default in some older Angular tutorials and boilerplate. Why it’s wrong: everything after the # is stripped client-side before the request ever reaches the server, so the server — and Googlebot — only ever sees one URL for the whole app. Do instead: use the default HTML5 History API routing (PathLocationStrategy) with <base href="/"> in index.html.

Branching a template on isPlatformBrowser()

Wrapping content in @if (isPlatformBrowser(platformId)) feels like the obvious way to guard browser-only code. Why it’s wrong: the server renders one branch and the client renders the other on hydration, which is a hydration mismatch — Angular has to reconcile the difference, and the visible result is layout shift that shows up as CLS. Do instead: use afterNextRender() for browser-only work so the template itself renders identically on server and client.

Setting document.title directly instead of using the Title service

It works in local dev, so it’s an easy shortcut to reach for. Why it’s wrong: direct DOM access like document.title = '...' doesn’t play well with SSR — the server has no document global in the same sense the browser does, and you lose the router-integration benefits of Angular’s own title handling. Do instead: inject Angular’s Title service (setTitle()) or configure titles per route with the router’s TitleStrategy.

Touching window, localStorage, or document in code that runs during SSR

A component or service that reads localStorage or checks window.innerWidth at construction time works fine in the browser and crashes the server render. Why it’s wrong: none of those globals exist on the Node server process running your SSR build, so the render throws and the request either 500s or silently falls back to an empty response. Do instead: gate that code behind afterNextRender() or inject Angular’s DOCUMENT token instead of the global, and test the SSR build locally (ng build + serving the SSR output), not just ng serve.

Treating dynamic rendering as a permanent fix

Standing up Puppeteer or a service like Rendertron to serve bots a prerendered snapshot solves the immediate symptom. Why it’s wrong: it’s an extra system to maintain, it can drift out of sync with what real users see, and Google has said directly that it’s a workaround rather than a long-term solution. Do instead: migrate to @angular/ssr or prerendering so every requester — bot or human — gets the same real HTML from the same pipeline.

Which rendering mode should this route use?

Angular v17+ lets you set rendering mode per route in app.routes.server.ts. The question isn’t “SSR or prerender” for the whole app — it’s this, asked per route.

Prompts for Angular SEO work

Ready-to-copy prompts for the specific Angular SEO tasks in this article. Paste in the described input and check the output against your own judgment — these save time on the mechanical parts, they don’t replace testing with URL Inspection.

1. Diff raw vs. rendered HTML for a route

Paste the output of curl -sL <url> (raw HTML) and the “rendered HTML” panel from a URL Inspection Live Test (or Ahrefs/Screaming Frog JS-rendering crawl) for the same URL.

Here is the raw HTML for [URL] (fetched with curl, before JavaScript runs):

[paste raw HTML]

Here is the rendered HTML for the same URL (from Google Search Console URL
Inspection's Live Test, or a JS-rendering crawler):

[paste rendered HTML]

Compare the two. List: (1) content present in rendered but missing from raw —
this is what depends on client-side rendering, (2) any <title>, meta description,
or JSON-LD that differs between the two versions, (3) whether the raw HTML shows
a near-empty <app-root> (a sign of CSR with no SSR/prerendering).

Expect back a short list of what’s CSR-dependent and any title/meta/schema drift between the raw and rendered versions — the two things worth fixing first.

2. Review a Title/Meta service implementation

Paste your Angular SeoService (or equivalent) that calls the Title and Meta services.

Here is an Angular service that sets page titles and meta tags:

[paste the service's TypeScript code]

Check it against these rules: (1) titles are set via the Title service's
setTitle(), never document.title directly, (2) description is set with
meta.updateTag({ name: 'description', ... }) not addTag() (which can duplicate
the tag on repeat calls), (3) Open Graph tags use the property selector, not
name, (4) nothing in this code reads window/localStorage/document directly in a
way that would break during SSR. Flag any line that violates one of these and
suggest the fix.

Expect back a line-by-line pass/fail against those four rules, with a corrected snippet for anything flagged.

3. Audit app.routes.server.ts for rendering-mode mistakes

Paste your server routes config file.

Here is my Angular app.routes.server.ts, which sets RenderMode per route:

[paste the file]

For each route, tell me: is RenderMode.Prerender used on anything that depends
on per-request or per-user data (a mistake — it would bake stale/wrong data into
the static build)? Is RenderMode.Client used on anything that looks like public,
indexable content (a missed-SEO-opportunity)? Is RenderMode.Server used on fully
static content where Prerender would be faster and cheaper? List each route with
its current mode and whether it matches the decision rule: static data →
Prerender, must-be-fresh → Server, non-indexed internal → Client.

Expect back a per-route verdict flagging any route whose RenderMode doesn’t match what the route actually needs.

Test yourself: Angular SEO

Five quick questions on making Angular apps crawlable and indexable. Pick an answer for each, then check.

Angular SEO

Angular SEO is the practice of making Angular single-page apps crawlable, renderable, and indexable — chiefly by serving real HTML through server-side rendering (@angular/ssr) or prerendering instead of relying on client-side rendering, plus managing titles, meta tags, and clean URLs.

Related: JavaScript SEO, Headless CMS SEO

Angular SEO

Angular SEO refers to the techniques required to make Angular applications — single-page apps (SPAs) built on Google’s Angular framework — discoverable, crawlable, and indexable by search engines. Because Angular renders its UI with JavaScript in the browser by default (client-side rendering), a default app ships a near-empty HTML shell, which creates indexing, performance, and non-Google-crawler problems that server-rendered HTML sites don’t have.

The core fix is to serve real HTML. Modern Angular (v17+) bakes server-side rendering directly into the CLI as @angular/ssr (the package that replaced the externally maintained “Angular Universal,” @nguniversal/express-engine). You can render per request (SSR), at build time (prerendering / static generation), or mix modes per route (hybrid rendering), then hydrate the server HTML in the browser so it isn’t thrown away and re-rendered.

The rest is conventional technical SEO adapted to Angular: set unique titles and descriptions with Angular’s built-in Title and Meta services (or the router’s TitleStrategy), use HTML5 History API routing rather than hash (#) URLs, keep internal navigation on real <a href> anchors, and verify what Googlebot actually renders with the URL Inspection tool.

Two things people get wrong: dynamic rendering (serving prerendered HTML to bots) is a Google-acknowledged workaround, not a recommended long-term solution; and AngularJS (v1.x, deprecated) is a different framework from modern Angular (v2+) — most “AngularJS SEO” advice doesn’t apply.

Related: JavaScript SEO, Headless CMS SEO

Changelog