Use-Case

WordPress ist das falsche Werkzeug, sobald daraus ein Produkt wird

Eine Broschüre, ein Blog, ein Impressum: WordPress reicht. Sobald Kunden sich einloggen, Daten liegen, eine App dazukommt oder Plugins die Seite tragen, fehlt die restliche Kette. Genau die richtet MainPath ein.

WordPress bleibt sinnvoll für redaktionelle Seiten ohne eigene Anwendungslogik
MainPath übernimmt Repository, CI/CD, Server, Secrets und Releases
Mobile Apps und Store-Uploads gehören dazu, nicht als Plugin nachgerüstet

Kostenlos registrieren Von WordPress migrieren

Kostenlos starten. Keine Kreditkarte nötig.

CMS vs. Plattform WordPress verwaltet Inhalte. MainPath betreibt das Projekt dahinter.

Code statt Plugin Funktionen liegen im Repository, nicht in einem Marktplatz mit Update-Risiko.

EU Repos, Pipelines und Deployments in der EU, Server mit SSH-Zugang.

Projekte, Server und Releases in einer Oberfläche, nicht als Plugin-Sammlung.

Kurz gesagt

WordPress und MainPath lösen unterschiedliche Aufgaben. Der Wechsel lohnt, wenn die Seite eigentlich eine Anwendung ist.

WordPress passt, wenn Redakteure Inhalte pflegen und kaum eigene Logik nötig ist.
MainPath passt, wenn Backend, Login, Daten, Apps oder wiederholbare Deployments dazugehören.
Plugins ersetzen keine CI/CD, keine Server-Grundeinrichtung und keine Store-Releases.
Ein Hugo- oder Astro-Auftritt auf MainPath kann die öffentliche Website weiter abdecken.

WordPress und MainPath im direkten Vergleich

Die Einordnung gilt für den typischen Einsatz. Ein reines Content-Projekt bleibt in WordPress oft einfacher.

Redaktionelle Website / Blog

MainPath: Möglich als Hugo- oder Astro-Homepage im Projekt, kein CMS-Backend

WordPress: Dafür gebaut, inkl. Editor und Medien

Eigene Anwendungslogik

MainPath: Backend als NestJS, Laravel, FastAPI oder vergleichbar im selben Projekt

WordPress: Plugins und Custom PHP, oft ohne Tests und Pipeline

Repository und Versionskontrolle

MainPath: GitLab-Repository entsteht mit dem Projekt

WordPress: Optional, häufig nur Dateien auf dem Hosting

CI/CD bis zum Deployment

MainPath: GitLab-CI mit Test, Build, Publish und Release

WordPress: FTP, Hosting-Panel oder einzelne Deploy-Plugins

Eigene Server mit SSH

MainPath: Eigener Server oder Managed Server, Grundsetup inklusive

WordPress: Meist Shared Hosting ohne Maschinen-Zugang

Mobile Apps und Stores

MainPath: Flutter, Expo, native Projekte, Metadaten und Uploads

WordPress: Nicht Teil des Produkts

Secrets und Zugänge

MainPath: Credentials-Verwaltung, Weitergabe an Umgebungen

WordPress: wp-config, Hosting-Panel, oft geteilte Zugänge

Standort der Verarbeitung

MainPath: Betrieb in der EU, Auftragsverarbeitungsvertrag

WordPress: Hängt am Hoster, Core und viele Plugins sind US-lastig

Grün heißt abgedeckt, gelb teilweise, grau nicht vorgesehen. WordPress gewinnt beim reinen Content. Sobald daraus Software wird, fehlt der Rest.

Stand: 4. September 2026. Die Gegenüberstellung beschreibt typische Abläufe und kann je nach Projekt abweichen. Logos sind Marken der jeweiligen Rechteinhaber und dienen nur der Zuordnung.

Was statt Plugin-Stack dazukommt

Die Arbeit, die in WordPress-Projekten neben dem Theme liegen bleibt.

Lesbare Pipelines

Test und Release stehen im Repository. Kein Deploy per Plugin und kein Hoffen, dass das Hosting die PHP-Version hält.

Server, die dir gehören

Docker, Datenbank, Reverse-Proxy, SSL, Firewall und Backups werden eingerichtet. Du behältst SSH.

Apps bis in den Store

Dieselbe Organisation kann die native App bauen und veröffentlichen, ohne ein zweites Produkt daneben zu stellen.

Rechte und Audit

Zugänge pro Person, nachvollziehbare Änderungen. Keine geteilte wp-admin-URL für alle.

acme / kunden-app

kunden-app
Flutter-App für iOS, Android und Web
backend
API und Server-Logik mit Docker-Setup
homepage
Marketing-Seite und öffentliche Inhalte
e2e-tests
End-to-End-Tests gegen Dev und Staging
gitops-configuration
Deployment-Konfiguration für Dev und Prod
local-configuration
Workspace-, IDE- und Agent-Konfiguration
gitlab-profile
Projekt-Dokumentation und README

Der Code liegt im GitLab-Repository der Organisation, nicht in wp-content.

Wie du prüfst, ob WordPress noch passt

Kein Zwang zum Umzug. Die Fragen reichen oft, um die passende Seite zu schicken.

Ist es vor allem Content?

Wenn Redakteure Texte tauschen und sonst wenig passiert, bleibt WordPress das einfachere Werkzeug.
Hängt die Seite an Plugins?

Login, Shop, Formulare, Mitgliedschaft, API: Das ist Anwendungslogik. Die gehört in ein Backend, nicht in fünf Plugins.
Kommt eine App dazu?

Sobald iOS oder Android im Spiel ist, endet WordPress als Plattform. MainPath nimmt App und Backend in ein Projekt.
Umzug planen

Die Migrationsseite beschreibt, was sich übertragen lässt und was neu gebaut wird.

Häufige Fragen

Ist MainPath ein WordPress-Hoster?

Nein. Sie hostet keine wp-admin-Instanzen und spielt keine Themes ein. Sie richtet Softwareprojekte ein: Repos, Pipelines, Server, optional Apps.

Kann ich trotzdem eine öffentliche Website haben?

Ja, als Hugo- oder Astro-Homepage im Projekt. Redaktion läuft über Git oder den Homepage-Texteditor von MainPath, nicht über den WordPress-Editor.

Was ist mit WooCommerce?

Ein Shop in WordPress bleibt ein WordPress-Projekt. MainPath ersetzt ihn nicht 1:1. Wenn der Shop nur Anhängsel einer eigenen Anwendung ist, gehört die Logik ins Backend.

Verliere ich den visuellen Editor?

Den Block-Editor von WordPress gibt es hier nicht. Dafür liegen Inhalte und Layout im Repository und gehen denselben Review-Weg wie der restliche Code.

Für wen ist der Wechsel unnötig?

Für Blogs, Unternehmensseiten ohne Login und Kampagnen-Microsites. Dafür ist WordPress gebaut. Schick diese Seite nur, wenn aus der Website ein Produkt geworden ist.

Sieh dir MainPath selbst an

Registriere dich kostenlos und lege ein Projekt an. Die Kette entsteht mit. Ohne WordPress im Unterbau.

Kostenlos registrieren Mit uns sprechen