WordPress + Web

WordPress trägt mehr, als die meisten denken. Wir betreiben rundum.dog mit einer Million Sessions pro Monat auf Standard-WordPress, ohne Headless. Voraussetzung: kein Page-Builder als Architektur, saubere Custom Post Types, klarer Pflegerhythmus.

§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

Schreib uns oder ruf an.
Wir antworten in der Regel innerhalb von 24 Stunden werktags.

Roger Klein
Geschäftsführer
E-Mail
info@dataloft.ch
Telefon
+41 52 511 05 05
Adresse
dataloft GmbH · Rietweg 1 · 8506 Lanzenneunforn TG