SPA, Suchmaschinen und KI-Lesbarkeit

Why modern web applications are often invisible — and how to fix it properly

SPA, Search Engines and AI Readability

Abstract (Deutsch)

Single Page Applications sind leistungsfähig und flexibel, aber ohne zusätzliche Maßnahmen schlecht lesbar für Suchmaschinen, KI-Crawler und automatisierte Auswertungssysteme. Klassische Ansätze wie Server-Side-Rendering oder statische Seitengenerierung verlagern Komplexität und Last zurück auf den Server oder heben die Vorteile von SPAs weitgehend auf.

Self-Hosted Prerendering bietet einen pragmatischen Mittelweg: Die Anwendung bleibt eine SPA für Nutzer, während Suchmaschinen und KI-Systeme vollständig gerendertes, semantisch sauberes HTML erhalten. In Kombination mit einem kleinen VPS in Deutschland und ISO-27001-zertifizierter Infrastruktur entsteht eine technisch saubere, kostengünstige und DSGVO-konforme Lösung mit voller Kontrolle und ohne Abhängigkeit von externen Cloud-Prerender-Diensten.

Abstract (English)

Single Page Applications (SPAs) offer high performance and flexibility, but they are inherently difficult to read for search engines, AI crawlers, and automated analysis systems. Traditional solutions such as server-side rendering or static site generation often negate the core advantages of SPAs by shifting complexity and load back to the server or by reducing runtime flexibility.

Self-hosted prerendering provides a pragmatic middle ground: the application remains a SPA for users, while search engines and AI systems receive fully rendered, semantically complete HTML. When operated on a small virtual private server within Germany using ISO 27001–certified infrastructure, this approach combines technical clarity, low operational cost, full control, and strong GDPR compliance without reliance on external cloud prerendering services.

Why Modern Web Applications Are Often Invisible

Single Page Applications (SPAs) have become a standard in modern web development. Frameworks such as React, Vue, or Angular enable fast, interactive user interfaces, clean separation of frontend and backend, and good scalability.

The problem: for search engines, AI crawlers, and automated readers, SPAs are often poorly readable or completely opaque.

This article explains:

why SPAs are structurally problematic for crawlers
which solution approaches exist
why many of them undermine the original SPA concept
how the problem can be solved pragmatically with minimal effort

The Core Problem: SPA Equals Empty HTML

A typical SPA initially delivers only a minimal HTML skeleton:

<html>
  <head>...</head>
  <body>
    <div id="app"></div>
    <script src="bundle.js"></script>
  </body>
</html>

The actual content is generated only inside the browser via JavaScript.

Consequences

Search engines see little or no meaningful content
AI crawlers (e.g. ChatGPT, Claude, Perplexity) index incompletely
Social media previews are unreliable
Accessibility and long-term readability suffer

Google can render JavaScript to some extent, but:

with delay
inconsistently
at high resource cost
and many crawlers cannot do it at all

Classical Countermeasures – and Their Drawbacks

1. Server-Side Rendering (SSR / MPA)

Examples: traditional server templates, Next.js SSR, Nuxt SSR.

Advantages

Excellent for SEO
Immediately readable for crawlers

Disadvantages

Increased server load
Higher architectural complexity
Loss of CDN and caching benefits
Often over-engineered for small and medium projects

➡️ Responsibility and workload move entirely back to the server.

2. Static Site Generation (SSG)

Examples: build-time rendering, static export.

Advantages

Extremely fast
Very search-engine friendly
Low runtime cost

Disadvantages

Content only updates on rebuild
Dynamic behavior is hard to model
The SPA concept is effectively abandoned

➡️ Ideal for content sites, unsuitable for dynamic applications.

3. Cloud-Based Prerendering (e.g. prerender.io)

Principle:

Crawlers receive prerendered HTML
Users still see the SPA

Advantages

Minimal changes required
Generally reliable

Disadvantages

Ongoing costs
Vendor dependency
Token and rate limits
Quickly expensive with multiple domains

The Pragmatic Solution: Self-Hosted Prerendering

Concept

The prerendering mechanism is operated in-house:

Headless Chromium renders the page
Fully rendered HTML is delivered
Only for bots or defined triggers
Users continue to see the SPA

Result

Search engines and AI systems see real content
No frontend changes required
Full technical and data control
Significantly lower operating costs

Architecture (Practical Overview)

Browser (User) ──────► SPA (Origin)
                         ▲
Bot / AI / UTM ──► Proxy ├──► Prerender (Headless Chrome)

Components

Reverse Proxy (Node.js or Nginx)
- detects bots via User-Agent
- detects triggers (e.g. utm=chatgpt)
- decides between ORIGIN and PRERENDER
Prerender Server
- Headless Chromium
- server-side HTML rendering
- isolated service
Firewall / Network Segmentation
- prerender service accessible only internally

Cost Reality

A typical setup:

1 small VPS
2 vCPU
2–4 GB RAM
≈ €6 per month

Sufficient for:

multiple domains
thousands of render requests
SEO and AI visibility

No token model. No vendor lock-in.

What Is Needed at a Glance

Software

Linux (Debian / Ubuntu)
Node.js
Chromium
prerender (open source)
Reverse proxy
PM2 or systemd

Logic

Bot detection
API request exclusion
Never prerender assets
Hard rendering timeouts

GDPR, German VPS Hosting, and ISO 27001

Operating a prerender and proxy system on a Germany-based VPS significantly simplifies GDPR compliance. All data remains within the EU legal jurisdiction, eliminating third-country transfers under Art. 44 et seq. GDPR and allowing clear contractual arrangements for data processing.

Many German hosting providers operate data centers certified under ISO/IEC 27001, often complemented by ISO 27017/27018 or BSI baseline protection. This ensures structured controls for access management, availability, logging, and incident response.

For self-hosted prerendering, the key point is that no personal user data is permanently processed. Only publicly accessible web pages are technically rendered. With short log retention, firewall restrictions, and TLS encryption, the overall data protection risk is very low.