§01 Warum WordPress 2026 noch trägt
Eine Plattform mit Million-Sessions-Realität.
Die Frage «WordPress oder etwas Modernes» wird seit etwa 2018 in Agentur-Blogs
diskutiert. Headless, Static-Site-Generator, JAMstack, Next.js — alle haben
ihre Berechtigung, alle haben ihre Spezialfälle. Was uns 2026 in der Praxis
auffällt: WordPress trägt mehr, als die meisten denken.
Wir betreiben mit rundum.dog eine Plattform mit ca. 1 Million Sessions
pro Monat, 17 Custom Post Types, eigenem KI-Plugin, automatisierten
Pipelines, einem Update-Server für unsere Plugin-Familie — alles auf
Standard-WordPress, ohne Headless. Es funktioniert
stabil, performant, planbar pflegbar.
Die Voraussetzungen, damit WordPress trägt, sind nicht trivial — aber sie sind
erfüllbar:
- Kein Page-Builder als Daten-Architektur
- Saubere Custom Post Types statt 20-Felder-Page-Templates
- Ein Drift-Register, das Pre-Live-Pflichten dokumentiert
- Hosting, das seinen Job macht — Schweizer Provider wie Infomaniak, Hostpoint, Cyon
- Pflegerhythmus mit klaren Verantwortlichkeiten
Wer das hat, braucht für 90 % der KMU-Projekte kein Headless. Wer es nicht
hat, scheitert auch mit Headless.
§02 Custom-Theme vs. Page-Builder
Wir bauen Custom-Themes — kein Elementor als Architektur.
Page-Builder wie Elementor, Divi, WPBakery oder Beaver Builder haben einen
Markt — sie ermöglichen es Personen ohne Code-Kenntnisse, Layouts zu bauen.
Für viele 5-Seiten-KMU-Sites funktioniert das. Für alles, was länger leben oder
grösser werden soll, ist es eine Sackgasse.
| Page-Builder |
Layouts in der Datenbank gespeichert (oft als JSON in _elementor_data).
Migrationen schwierig. Performance-Penalty durch Render-Overhead.
Plugin-Update kann Layouts brechen. Lock-In auf den Builder.
|
| Custom-Theme |
Layouts in PHP-Templates. Inhalt in Custom Post Types und Custom Fields.
Klar versionierbar via Git. Performance unter Kontrolle. Migrationen
geradlinig. Kein Lock-In.
|
Wir bauen Custom-Themes, weil wir die Sites
danach pflegen — und weil unsere Mandanten die Sites nach 5–10 Jahren noch
ohne unsere Hilfe lesbar finden sollen. Die dataloft.ch ist ein Custom-Theme,
rundum.dog ist ein Hello-Elementor-Child mit Custom-Templates (Elementor nur
dort, wo es schlicht das richtige Tool ist — selten).
Wenn wir bestehende Page-Builder-Sites übernehmen, ist die erste Frage immer:
«Können wir das migrieren?» Antwort: meistens ja, mit Aufwand. Manchmal
ist ein Relaunch günstiger als die Migration.
§03 JetEngine als Datenmodell
Custom Post Types und Meta-Felder ohne Code-Schmerzen.
Was Page-Builder im Frontend versuchen, machen wir im Datenmodell: strukturierte
Inhalte, die im Backend einfach pflegbar sind. Unser Standard dafür ist
JetEngine von Crocoblock.
Was JetEngine konkret leistet
- Custom Post Types via UI definieren (Trainer:in, Kurs, Eintrag, Pension, etc.) — ohne
register_post_type() in der functions.php zu schreiben
- Meta-Felder mit allen Typen: Text, Textarea, Image, Repeater, Map, Date, Dynamic-Field, Bedingten-Logik
- Custom Content Types (CCT) — eigene DB-Tabellen für strukturierte Daten, die nicht in
wp_posts gehören (z.B. Bestell-Items, Tracking-Logs)
- Listings — vorlagenbasierte Render-Logik, die Felder dynamisch ausgibt
- JetSmartFilters — URL-basierte Filter für Custom-Post-Type-Archive
Was wir damit auf rundum.dog gebaut haben
- 17 Custom Post Types: Hunderasse, Wiki, Eintrag, Saisoneintrag, Ausflugsziel, Standort, Gefahr, Unterkunft, Züchter, …
- 12 JetEngine-Tabellen für strukturierte Daten
- Custom-Trust-Stufen-System mit Migration-Hooks bei Pivots
- Drawer-Filter via
$_GET/pre_get_posts, kein Builder-Krücken-Pattern
JetEngine funktioniert für KMU- und Mittelstand-Mandate. Bei sehr grossen
oder sehr individuellen Datenmodellen geht der Code-Anteil hoch — was OK ist,
weil JetEngine den Code nicht ersetzt, sondern ergänzt.
§04 Headless? Nur wenn man muss.
Drei Fälle, wo Headless richtig ist — und drei, wo es überzogen wäre.
Wann Headless WordPress sinnvoll ist
- Mehrkanal-Publikation: gleicher Content auf Web + App + Newsletter + Smart-TV-App
- Sehr hohe Anforderungen an Frontend-Interaktivität (Real-Time-Daten, komplexe SPA-Logik)
- Gemischtes Tech-Team mit dediziertem Frontend-Kontingent (React/Next.js)
Wann Headless überzogen ist
- Standard-KMU-Site mit Blog, Service-Pages, Kontakt — WordPress monolithisch reicht
- Kleines Team, das die Site selbst pflegen muss — Headless erhöht den Pflege-Aufwand
- Anforderung «modern und schnell» — das ist mit Standard-WordPress + sauberem Custom-Theme + Caching auch erreichbar
Faustregel: Wer fragt, ob Headless richtig ist, braucht meist kein
Headless. Wer es klar braucht, weiss es schon. Wir machen sowohl
monolithisches WordPress als auch Headless mit Next.js — aber nur, wenn die
Aufgabe es trägt.
§05 Performance: Core Web Vitals
Mobil grün — alles andere ist Aufwand am falschen Ort.
Google misst seit 2021 Core Web Vitals als Ranking-Faktor. 2026 sind die
Schwellenwerte stabilisiert, die Messmethodik dokumentiert, die Tools
(PageSpeed Insights, Lighthouse, CrUX-Daten) ausgereift. Was wir in jedem
Mandat anpeilen:
| LCP (Largest Contentful Paint) |
Unter 2,5 Sekunden auf mobil. Der grösste Hebel: Hero-Bilder optimiert (WebP, korrekte Grösse, kein Lazy-Loading auf Above-the-Fold). |
| CLS (Cumulative Layout Shift) |
Unter 0,1. Bedeutet: Bilder mit expliziten width/height, keine Async-Inserts ohne Reservierung, Schriften mit font-display: swap sauber konfiguriert. |
| INP (Interaction to Next Paint) |
Unter 200ms. Bedeutet: JavaScript-Last unter Kontrolle, keine grossen Third-Party-Scripts ohne Anlass, kein render-blocking JS. |
Wie wir Performance in WordPress sichern
- WP Rocket als Caching-Layer (post-Live, nicht während Entwicklung)
- WebP/AVIF für alle Bilder via Image-Optimization-Plugin oder Build-Pipeline
- Self-hosted Fonts — keine Google-Fonts-Live-Einbindung
- Wenig Plugins, sauber konfiguriert, nicht 30 Stück die sich gegenseitig blockieren
- CDN wo sinnvoll (Cloudflare, Bunny, oder Hoster-CDN)
- Datenbank-Hygiene — Revision-Limit, Transients-Cleanup, Optimize-Tables im Wartungsfenster
Was wir nicht machen: «Optimierung um der Optimierung willen». Wer auf einer
KMU-Site versucht, von 95 auf 99 Lighthouse-Score zu kommen, verbrennt Zeit
ohne Geschäftswert. Grün ist genug.
§06 Hosting-Optionen Schweiz
Drei Empfehlungen, je nach Profil.
| Infomaniak |
Unsere Standardempfehlung. Schweizer Server, klare Preise, gute SSH-/CLI-Zugänge,
eingebautes Backup-System, faires PHP/MySQL-Setup. Wir betreiben rundum.dog
und dataloft.ch dort. Plus: Schweizer Datenschutz-Hosting ist DSG-tauglich
ab Werk.
|
| Hostpoint / Cyon |
Solide Schweizer Alternativen. Infomaniak hat mehr CLI-Komfort, Hostpoint
mehr Web-UI-Polish. Cyon mit guter Performance pro CHF.
|
| WP Engine / Kinsta |
Premium-WordPress-Hoster, US/EU. Schneller, teurer, mit Staging-Workflow
und Auto-Scaling. Empfehlenswert für hochfrequente Sites mit US-Anteil.
|
Was wir nicht empfehlen: Mass-Shared-Hosting der Allerbilligsten — die Bloat-Probleme
holen euch ein, sobald die Site Traffic bekommt. Plus: bei Sicherheits-Vorfällen
ist die Reaktionsfähigkeit oft mangelhaft.
§07 Wartung + Sicherheit als laufendes Mandat
Was wir im monatlichen Retainer machen — und was nicht.
WordPress-Sites sterben fast nie an einem grossen Crash. Sie sterben an
fehlender Pflege: nicht eingespielte Updates, abgelaufene SSL-Zertifikate,
verstopfte Backup-Quoten, Plugin-Inkompatibilitäten nach Major-Updates.
Im monatlichen Retainer
- WordPress-Core-Updates nach Pre-Live-Test
- Plugin-Updates priorisiert nach Sicherheits-Relevanz
- Theme-Updates kontrolliert (bei Custom-Themes meist intern, kein Auto-Update)
- Backup-Verifikation — monatlich ein Backup tatsächlich restoren testen
- Security-Monitoring (iThemes, Wordfence) Logs prüfen
- Kleinere Inhaltsanpassungen ohne Aufpreis (z.B. Adressänderung, neuer Mitarbeiter, Aktualisierungen)
- Quartalsweise Performance-Review
Was nicht im Retainer ist
- Neue Features oder grössere Layouts → Projekt-Mandat
- Inhaltsproduktion (Texte, Bilder) → eigenes Mandat oder Stundenbasis
- SEO/SEA-Optimierung → eigenes Mandat (siehe Auffindbarkeit)
- Migrationen auf neue Hoster oder Versionen → projektbasiert
Wartungs-Retainer typisch 80–250 CHF/Monat, je nach Komplexität.
§08 Häufige Fragen
Was wir oft gefragt werden — und ehrlich beantworten.
Sollen wir auf eine andere Plattform wechseln?
In den meisten Fällen: nein. WordPress ist 2026 reif, performant, gut gepflegt.
Wechsel lohnen sich, wenn ihr aus echtem Grund umsteigt — Headless wegen
Multi-Channel, Shopify wegen reinem E-Commerce-Fokus, statisches Hosting wegen
extremer Traffic-Spitzen ohne Daten-Backend.
Wie viele Plugins sind zu viel?
Es gibt keine harte Grenze. 20 saubere Plugins schlagen 12 schlechte. Wir
auditieren in jedem Mandat und entfernen, was sich überschneidet oder selten
genutzt wird. Plugin-Inflation ist ein typisches Symptom alter Sites.
Brauchen wir einen Page-Builder für Marketing-Pages?
Selten. Marketing-Pages, die wirklich konvertieren, sind meist nicht durch
Builder-Layouts entstanden. Was hilft: klare Hierarchie, gute Texte, starke
Bilder. Das ist Theme-Arbeit, nicht Builder-Arbeit.
Wie lange dauert ein WordPress-Relaunch?
Standard 8–12 Wochen, ab Briefing-Freigabe. Komplexe Mandate mit
WooCommerce, JetEngine-Datenmodell, Migration aus Bestand: 12–20 Wochen.
Schneller geht, wird aber unter den Tisch gehauenes Detail.
Wer pflegt die Site nach Live-Schaltung?
Standardmässig wir, im Retainer. Aber: ihr könnt selbst pflegen — wir bauen
so, dass das Backend für eure Marketing-/Kommunikations-Person ohne dauerhafte
Agentur-Hilfe bedienbar ist. Wartung+Updates bleiben bei uns, Inhalte könnt
ihr selbst.
Was kostet eine Standard-Webseite ungefähr?
Wir nennen auf der Site bewusst keine Preise — jedes Projekt ist anders. Im
Erstgespräch bekommt ihr eine konkrete Range mit Begründung. Was wir sagen
können: keine Lockangebote, eine saubere Webseite braucht ihre
Zeit.
§09 Was wir konkret bauen
Werkstatt-Übersicht — pro Branche und Format.
Diese Pillar-Page erklärt, warum WordPress trägt und wie wir
grundsätzlich bauen. Konkrete Patterns nach Branche und Format findet ihr in der
Werkstatt:
→ Zur Werkstatt-Übersicht ·
→ Direkt zum Kontakt