Zum Inhalt springen

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.

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.

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 bis 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, also 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.

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, 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, Bedingte 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. Das ist in Ordnung, weil JetEngine den Code nicht ersetzt, sondern ergĂ€nzt.

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.

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.

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 dich ein, sobald die Site Traffic bekommt. Plus: bei Sicherheits-VorfÀllen ist die ReaktionsfÀhigkeit oft mangelhaft.

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

Was die Wartung kostet, hÀngt vom Umfang deiner Website ab. Wir machen ein Angebot, sobald wir dein Projekt verstanden haben.

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 du aus echtem Grund umsteigst: 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 bis 12 Wochen, ab Briefing-Freigabe. Komplexe Mandate mit WooCommerce, JetEngine-Datenmodell, Migration aus Bestand: 12 bis 20 Wochen. Schneller geht auch, dann fÀllt aber Detailarbeit unter den Tisch.

Wer pflegt die Site nach Live-Schaltung?

StandardmĂ€ssig wir, im Retainer. Aber: Du kannst selbst pflegen. Wir bauen so, dass das Backend fĂŒr deine Marketing-/Kommunikations-Person ohne dauerhafte Agentur-Hilfe bedienbar ist. Wartung+Updates bleiben bei uns, Inhalte kannst du selbst.

Was kostet eine Standard-Webseite ungefÀhr?

Wir nennen auf der Site bewusst keine Preise. Jedes Projekt ist anders. Im ErstgesprĂ€ch bekommst du eine konkrete Spanne mit BegrĂŒndung. Was wir sagen können: keine Lockangebote, eine saubere Webseite braucht ihre Zeit.

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 findest du in der Werkstatt:

→ Zur Werkstatt-Übersicht · → Direkt zum Kontakt

Schreib uns oder ruf an.
Meist antwortet ein Mensch innerhalb eines 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