Statische Website, SSR oder CMS: Was passt für ein kleines Unternehmen (mein echter Fall)

Wenn mich ein Unternehmen nach einer Website fragt, steht noch vor dem Design eine Entscheidung an, die jahrelang nachwirkt: statische Website, serverseitiges Rendering (SSR) oder CMS? Statt sie abstrakt zu erklären, erzähle ich sie anhand des Projekts, das ich am besten kenne: dieser Website.

Die drei Optionen in zwei Zeilen

• Statische Website: Die Seiten sind fertige HTML-Dateien, einmal erzeugt und auf ein Hosting hochgeladen. Sehr schnell, günstig, kaum angreifbar. Aber jede Änderung erfordert eine neue Veröffentlichung.
• SSR (Server-Side Rendering): Ein Server erzeugt die Seite bei jeder Anfrage, mit stets aktuellen Daten. Flexibel und hervorragend für SEO, aber man braucht einen Server, der immer läuft, und jemanden, der ihn wartet.
• CMS (WordPress oder ein Headless-CMS): Der Inhaber bearbeitet Texte und Artikel in einem Dashboard, ganz ohne Entwickler. Bequem, bringt aber Updates, Plugins und eine Angriffsfläche mit sich, um die man sich kümmern muss.

Mein Fall: eine Angular-Website, statisch ausgeliefert

Diese Website ist eine Angular-Anwendung mit konfiguriertem SSR, einem separaten NestJS-Backend mit MongoDB und einem Blog in sieben Sprachen, dessen Artikel in der Datenbank liegen. Auf dem Papier der perfekte Fall für SSR. In der Praxis wird das Frontend aus Kosten- und Einfachheitsgründen gebaut und als statische Dateien auf einem Plesk-Hosting veröffentlicht, während das Backend auf einem separaten Dienst läuft.

Es funktioniert – aber ich habe am eigenen Leib erfahren, was diese Entscheidung bedeutet.

1. Ohne Server gibt es kein SSR

Bei einem statischen Deployment läuft das serverseitige Rendering nie: Wird eine Seite nicht beim Build erzeugt, bekommt Google nur die leere „Hülle“ der Anwendung. Als ich das bemerkte, hatte Google 4 von 32 URLs aus meiner Sitemap indexiert – und keinen einzigen Artikel. Die ganze Fehlersuche habe ich in diesem Artikel beschrieben. Die Lösung war Prerendering: das HTML jeder Seite beim Build erzeugen, Artikel für Artikel und Sprache für Sprache.

2. Hunderte Seiten bei jedem Build

Jeder Artikel existiert in sieben Sprachen, also sind Hunderte Seiten vorzurendern. Die ersten Builds fragten für jede Seite die Produktions-API ab: Das Rate-Limit griff, und manche Seiten wurden mit der Meldung „Artikel nicht gefunden“ erzeugt. Gelöst habe ich das, indem ich alle Artikel vor dem Build einmalig in eine Cache-Datei lade, aus der das Prerendering liest:

// Before the build: download every published post once
const posts = await fetchAllPublishedPosts();
fs.writeFileSync('.prerender-cache/blog-posts.json', JSON.stringify({ posts }));
// The prerender reads this file instead of calling the API hundreds of times

3. Jeder neue Artikel braucht eine neue Veröffentlichung

Das ist der offensichtlichste Kompromiss: Veröffentliche ich einen Artikel im Dashboard, ist der Inhalt sofort über die API verfügbar – die HTML-Seite, die Google liest, existiert aber erst nach dem nächsten Build und Upload. Für einen Blog, der ab und zu aktualisiert wird, ist das in Ordnung; für eine Nachrichtenseite nicht.

4. Hosting-Details zählen

Selbst mit erzeugten Seiten antwortete Apache auf jede mit einer 301-Weiterleitung: Jede vorgerenderte Seite ist ein Ordner mit einer index.html darin, und der Server hängte der URL einen abschließenden Slash an. Die Lösung waren ein paar Zeilen in der .htaccess – aber ohne Prüfung mit curl -I wäre es mir nie aufgefallen:

<IfModule mod_dir.c>
  DirectorySlash Off
</IfModule>

Genau wegen dieser Kompromisse bereite ich den Umstieg auf einen Node-Container auf Plesk mit echtem SSR vor: Die Komplexität steckte ohnehin schon im Projekt, dann kann ich sie auch voll nutzen.

Was ich kleinen Unternehmen empfehle

Meine Website ist kein typischer Fall: Sie ist auch ein Labor. Für ein echtes Unternehmen hängt die Wahl fast immer von drei Fragen ab: wie oft sich Inhalte ändern, wer sie pflegt und wie viele Seiten nötig sind.

Für viele lokale Unternehmen sind Öffnungszeiten, Bewertungen und Anfahrt wichtiger als die Website selbst: Ein gepflegtes Google-Unternehmensprofil ist oft mehr wert als eine zusätzliche Funktion.

Fragen, die man vor der Wahl stellen sollte

1. Wer pflegt die Inhalte, und wie oft? Lautet die Antwort „der Inhaber, jede Woche“, braucht es ein Dashboard.
2. Wie wichtig ist Google? Lebt die Website von organischer Suche, muss jede Seite als vollständiges HTML beim Crawler ankommen: statisch oder SSR, nie eine Single-Page-App ohne Prerendering.
3. Wer wartet den Server? Ein SSR-Setup oder CMS ohne Updates altert schlecht; eine statische Website kann jahrelang unverändert laufen.
4. Wie stark kann sie wachsen? Statisch starten und später auf SSR umsteigen ist möglich – sofern die Architektur es erlaubt, so wie bei mir mit Angular.

Die häufigsten Fehler, die ich sehe

• Ein schweres CMS für fünf Seiten, die sich nie ändern: Plugins zum Aktualisieren und Sicherheitsrisiken ohne jeden Nutzen.
• Eine Single-Page-App ohne Prerendering für eine Website, die gefunden werden soll: angenehm zu bedienen, unsichtbar für Suchmaschinen.
• SSR wählen, ohne Budget für die Wartung: Ein Server muss überwacht, aktualisiert und jeden Monat bezahlt werden.

Fazit

Die absolut beste Technologie gibt es nicht – nur die, die dazu passt, wie Inhalte gepflegt werden und wer sie verwaltet. Für die meisten kleinen Unternehmen ist eine gut gemachte statische Website die solideste Wahl; ein CMS lohnt sich, wenn der Inhaber unabhängig sein will; SSR braucht man bei vielen, häufig wechselnden Inhalten. Meine Website hat mich gelehrt, dass jede Entscheidung versteckte Kosten hat – wichtig ist, sie vorher zu kennen. Wenn du ein Projekt planst, schreib mir, und wir starten bei diesen Fragen.