Warum ich für KMU kein WordPress mehr baue.

Was Next.js überhaupt ist.

Next.js ist ein Web-Framework, das auf React basiert und von Vercel entwickelt wird. Statt eine Seite erst im Browser zu bauen (wie klassisches React) rendert Next.js die fertige HTML auf dem Server — und liefert sie an Google und den Nutzer als eine statische, extrem schnelle Seite aus.

Für KMU heißt das konkret: keine Datenbank, die angegriffen werden kann, keine Plugins, die sich in die Quere kommen, kein Admin-Panel, das gehackt wird. Stattdessen eine Website, die in unter einer Sekunde lädt und bei Google sauber indexierbar ist.

Drei WordPress-Probleme, die Next.js einfach nicht hat.

1. Ladezeit = Ranking-Faktor.

Google misst seit 2021 die Core Web Vitals und nutzt sie direkt als Ranking-Faktor. Eine durchschnittliche WordPress-Seite mit Elementor und 12 Plugins schafft 3–5 Sekunden Ladezeit auf Mobile. Der Sonnenhof in der alten Version: 4,2 s. Die Next.js-Version seit Februar 2026: 0,8 s. Google sieht den Unterschied.

2. Wartungsaufwand = laufende Kosten.

WordPress braucht permanente Updates — Core, Theme, Plugins. Vergisst man ein Update, ist die Seite angreifbar. Vergisst man ein Plugin-Update, kracht beim nächsten Core-Update der halbe Seiten-Aufbau. Für 5-Personen-Betriebe realistisch: 2–4 Stunden Wartung pro Monat oder ein Agentur-Wartungsvertrag ab 49 € / Monat.

Next.js-Seiten haben keine Plugins, keine Datenbank-Updates, keinen Admin-Login. Die Seite wird einmal gebaut und deployed — und läuft. Updates betreffen nur den Code-Stand, den ich kontrolliere.

3. Sicherheit = Reputation.

Etwa 40 % aller WordPress-Sites weltweit sind in irgendeiner Form infiziert oder enthalten veraltete verwundbare Versionen (Sucuri Report 2025). Ein gehacktes Kontaktformular oder ein eingeschleustes Ads-Skript kann in wenigen Stunden das Google-Ranking ruinieren.

Eine Next.js-Seite auf Vercel hat keine solche Angriffsfläche. Kein Login, keine Datenbank, keine Plugins. Das einzige Eindringtor wäre der GitHub-Account meiner Firma — der mit 2FA + Hardware-Key gesichert ist.

Was Next.js besser macht — technisch.

• Statisches HTML: Google liest alles direkt aus, kein JavaScript-Rendering nötig.
• Server-Komponenten: Datenbank-Abfragen laufen auf dem Server, Browser sieht nur fertige Inhalte.
• Automatische Bildoptimierung: WebP, AVIF, responsive — für alle Viewport-Größen.
• Schema.org-Markup wird direkt in JSX geschrieben und typisiert — keine Plugins.
• SEO-Tags über next/metadata — typsicher und zentral verwaltet.
• Deployment in 15 Sekunden via Git-Push. Rollback in 10 Sekunden.
• next-intl für mehrere Sprachen — beim Sonnenhof DE + EN mit ~600 Übersetzungs-Keys.

„Aber ich will selbst Inhalte ändern können.“

Der berechtigteste Einwand. Next.js-Seiten haben standardmäßig kein CMS. Für KMU mit wöchentlichen Content-Änderungen ist das ein Problem — für die meisten Dienstleister-Websites eher nicht: Inhalte ändern sich alle 3–6 Monate und das macht der Dienstleister ohnehin besser als der Inhaber.

Wenn es doch ein redaktionelles CMS braucht, kombinieren wir Next.js mit Headless-Lösungen wie Sanity oder Payload — bleiben aber beim modernen Stack.

Kurz: wann Next.js — und wann nicht.