WordPress ist eine starke Zielplattform, wenn das Projekt eine flexible CMS-Grundlage, redaktionelle Kontrolle, Kontrolle über Inhalte, SEO-Kontinuität, Medienverwaltung, Plugin-Erweiterbarkeit und Freiheit bei der Implementierung benötigt. Die Eignung ist geringer, wenn native Commerce-Funktionen, eine exakte Designübernahme, stark Plugin-gesteuerte Geschäftsprozesse oder ein wartungsarmes Hosted-Modell erwartet werden, ohne die notwendige Implementierungsebene zu definieren.
Die Eignung sollte danach beurteilt werden, wie die WordPress-Zielseite nach der Migration betrieben wird. Eine Website mit überwiegend Seiten und Beiträgen kann sehr gut passen. Eine Website mit benutzerdefinierten Beitragstypen, Mitgliedschaften, Kursen, Events, Verzeichnissen, Page Buildern, Formularen, benutzerdefinierten Feldern, Benutzerrollen oder Integrationen kann ebenfalls gut passen, allerdings erst, nachdem die Zielstruktur definiert wurde. Erwartet ein Projekt, dass der WordPress-Kern wie eine vollständige E-Commerce-Plattform funktioniert, sollte die Planung auf WooCommerce, ein anderes Commerce-Plugin, eine externe Commerce-Architektur oder eine andere Zielplattform ausgerichtet werden.
Was Eignung für WordPress bedeutet
Die Eignung von WordPress hängt nicht nur davon ab, ob Inhalte importiert werden können. Entscheidend ist, ob Inhalte, Struktur, Benutzer, URLs, Plugins und Zielimplementierung nach dem Launch sicher gepflegt werden können. Ein gut geeignetes WordPress-Projekt besitzt ein klares Inhaltsmodell, einen realistischen Plugin-Stack, einen definierten Ansatz für URLs und SEO, einen Plan für Benutzer und Rollen sowie eine benannte Verantwortung für Hosting, Sicherheit, Backups, Updates und Performance.
| Eignungsdimension | Signal für gute Eignung | Signal für bedingte Eignung | Signal für geringere Eignung |
|---|---|---|---|
| Inhaltsmodell | Überwiegend Seiten, Beiträge, Medien, Menüs, Categories, Tags, Kommentare und gewöhnliche Benutzer. | Benutzerdefinierte Beitragstypen, Taxonomien, Feldgruppen, Beziehungen oder mehrsprachige Strukturen müssen geplant werden. | Die Quellstruktur kann ohne umfangreiche individuelle Logik oder eine noch unklare Zielarchitektur nicht abgebildet werden. |
| Geschäftslogik | Überwiegend CMS- und Content-Prozesse mit beherrschbarer Plugin-Abhängigkeit. | Mitgliedschafts-, LMS-, Buchungs-, Event-, Verzeichnis-, Formular- oder Commerce-Plugin-Logik muss zugeordnet werden. | Der Geschäftsprozess ist kritisch, aber es gibt kein definiertes Ziel-Plugin, keinen individuellen Build und kein externes System. |
| Layout und Design | Ziel-Theme oder Builder-Ansatz ist bekannt und Prioritätsseiten haben Abnahmekriterien. | Page-Builder-Datensätze, Shortcodes, wiederverwendbare Abschnitte oder Theme-Module müssen geprüft werden. | Eine exakte visuelle Kopie wird erwartet, ohne Plan für Designimplementierung oder Builder-Rekonstruktion. |
| Benutzer und Rollen | Autoren, Redakteure, Abonnenten oder Mitglieder haben eine klare Bedeutung im Ziel. | Rollen, Berechtigungen, Mitgliedschaften, Konten oder Plugin-spezifische Rechte müssen zugeordnet werden. | Die Benutzerbedeutung ist geschäftskritisch, aber undokumentiert oder außerhalb von WordPress gesteuert. |
| SEO und URLs | Slugs, Weiterleitungen, Metadaten, interne Links, Medienpfade und Prioritäts-URLs sind inventarisiert. | SEO-Plugin-Felder, mehrsprachige URLs, Archive, Schema-Einstellungen oder Weiterleitungslogik erfordern weitere Analyse. | Organischer Traffic hängt von URL-Verhalten ab, das mit den vorhandenen Informationen nicht validiert werden kann. |
| Technische Verantwortung | Hosting, Updates, Sicherheit, Backups, Caching, Plugins und Deployment sind klar zugeordnet. | Verantwortung ist vorhanden, aber Umgebung, Plugin-Kompatibilität oder Wartungsprozess müssen bestätigt werden. | Kein Team oder Dienstleister ist darauf vorbereitet, WordPress nach dem Launch zu betreiben. |
Die besten Eignungsentscheidungen benennen sowohl die Stärken der Plattform als auch den Implementierungsaufwand realistisch. WordPress kann viele Zielbilder unterstützen, doch Flexibilität ersetzt keine klare Architektur.
Besonders geeignete WordPress-Profile
WordPress ist in der Regel besonders geeignet, wenn das Zielprojekt inhaltsorientiert ist und das Unternehmen redaktionelle Kontrolle, flexibles Publishing, SEO-Steuerung und Plugin-basierte Erweiterbarkeit wünscht. Die besten Kandidaten können erklären, was eine Seite, was ein Beitrag, was strukturierter Inhalt werden soll und welche Plugin- oder Theme-Abhängigkeiten nach dem Launch relevant bleiben.
| Geeignetes Profil | Warum WordPress passt | Migrationsfokus |
|---|---|---|
| Inhaltsreiche Marketing-Website | WordPress unterstützt CMS Pages, Blog Posts, Medien, Menüs, Categories, Tags und redaktionelle Abläufe. | Seitenhierarchie, Publishing-Kontext des Blogs, Medienbeziehungen, interne Links, Metadaten und Weiterleitungen bewahren. |
| Publisher- oder Wissensdatenbank-Website | WordPress kann große Archive aus Beiträgen, Autoren, Categories, Tags und strukturierten redaktionellen Inhalten verwalten. | Autorschaft, Daten, Slugs, Taxonomiearchive, Beitragsbilder, Kommentare, Auszüge und SEO-Felder validieren. |
| Website eines Dienstleistungsunternehmens | WordPress eignet sich für Leistungsseiten, Landingpages, Fallstudien, Formulare, Medien, Testimonials und lokalisierte Inhalte. | Seiten, Formulare, Menüs, Medien, SEO-Metadaten und templateabhängige Seiten zuordnen. |
| Inhaltsorientierte Organisation mit flexibler Struktur | Benutzerdefinierte Beitragstypen und Taxonomien können Ressourcen, Events, Profile, Kurse oder Verzeichnisse abbilden. | Inhaltsmodelle, Felder, Beziehungen, Archivlogik und redaktionelle Abläufe vor der Migration definieren. |
| Inhalts-Website in Verbindung mit WooCommerce | WordPress kann die Inhaltsgrundlage rund um eine Commerce-Ebene übernehmen. | CMS-Inhalte und WooCommerce-Commerce-Datensätze getrennt halten und gemeinsame URLs, Benutzer, Medien und Navigation validieren. |
| SEO-sensitive Website mit bekanntem URL-Bestand | WordPress unterstützt gezielte Planung für Permalinks, Weiterleitungen, Metadaten und interne Links. | Prioritäts-URLs, Weiterleitungen, Taxonomiearchive, Medienpfade und SEO-Plugin-Felder vorbereiten. |
Auch ein sehr gut geeignetes WordPress-Projekt braucht Validierung. Der Unterschied besteht darin, dass das Validierungsziel klar ist. Das Team weiß, welche Datensätze in WordPress vorhanden sein müssen, welche Ausgabe vom Theme oder Builder abhängt, welche Plugins zum Zielbetrieb gehören und welche Bereiche Zielkonfiguration, Prüfung benutzerdefinierter Daten oder separate Implementierungsarbeit benötigen.
Bedingt geeignete WordPress-Profile
Bedingte Eignung bedeutet, dass WordPress geeignet sein kann, die Migration jedoch nicht als einfache CMS-Übertragung behandelt werden darf. Die Zielarchitektur muss vor der Launch-Planung definiert werden, weil wichtige Bedeutung in benutzerdefinierten Strukturen, Plugins, Layouts, Benutzern oder externen Systemen liegen kann.
| Bedingt geeignetes Profil | Was geklärt werden muss | Warum dies den Migrationsumfang beeinflusst |
|---|---|---|
| Website mit benutzerdefinierten Beitragstypen | Welche Quelldatensätze zu benutzerdefinierten Beitragstypen, Taxonomien, Feldern oder Beziehungen werden sollen. | Gewöhnliche Seiten erhalten möglicherweise weder Verwaltungsstruktur noch Archivlogik. |
| Stark Page-Builder-geprägte Website | Welche Seiten von Builder-Daten, Shortcodes, wiederverwendbaren Abschnitten oder Template-Modulen abhängen. | Inhaltsmigration kann das visuelle Layout ohne Implementierungsarbeit nicht reproduzieren. |
| Mitglieder- oder LMS-Website | Welche Benutzer, Rollen, Mitgliedschaften, Kurse, Lektionen, Fortschrittsdatensätze oder Berechtigungen wichtig sind. | Plugin-eigene Daten können die Prüfung benutzerdefinierter Daten, separate Implementierungsarbeit oder Ziel-Setup erfordern. |
| Event-, Buchungs-, Verzeichnis- oder formularbasierte Website | Welches Plugin die Datensätze besitzt und wie sie im Ziel dargestellt werden sollen. | Wichtige Daten können in benutzerdefinierten Tabellen, Postmeta, serialisierten Feldern oder externen Diensten liegen. |
| Mehrsprachige oder Multisite-Implementierung | Welche Sprach-/Website-Beziehungen, URLs, Taxonomien und Benutzer erhalten bleiben sollen. | Umfang und Validierung unterscheiden sich von einer einzelnen Inhalts-Website. |
| Stark SEO-Plugin-abhängige Website | Welche Metadaten, Weiterleitungen, Canonicals, Schema-, Breadcrumb- und Social-Felder relevant sind. | Plugin-Metadaten können gezielte Zuordnung oder separate Validierung benötigen. |
| Integrationsabhängige Website | Welches CRM-, Such-, Identitäts-, Marketing-, Analyse- oder externe System wichtige Datensätze besitzt. | Externe IDs und Synchronisationsannahmen können eine Prüfung benutzerdefinierter Daten erfordern. |
Bedingte Eignung ist kein Scheitern. Sie signalisiert, dass aus allgemeiner Plattformauswahl eine strukturierte Analyse werden muss. Werden die offenen Bereiche definiert, kann WordPress zu einer starken Wahl werden. Bleiben sie unklar, ist der Migrationspfad riskant.
Weniger geeignete oder nicht ideale WordPress-Profile
Ein Signal für geringere Eignung bedeutet, dass WordPress technisch dennoch möglich sein kann, die Zielerwartung aber durch gewöhnliche WordPress-Migrationsplanung nicht sicher abgedeckt wird. Das Projekt kann WooCommerce, einen anderen Plugin-Stack, eine individuelle Implementierung, einen engeren akzeptierten Umfang oder eine andere Zielplattform benötigen.
| Signal für geringere Eignung | Warum es die WordPress-Eignung schwächt | Bessere Planungsreaktion |
|---|---|---|
| Native E-Commerce-Funktionen werden vom WordPress-Kern erwartet | WordPress Core bietet kein vollständiges Modell für Katalog, Warenkorb, Checkout, Orders, Tax, Versand oder Zahlungen. | WooCommerce, ein anderes Commerce-Plugin, externe Commerce-Lösung oder eine andere Zielplattform definieren. |
| WordPress und WooCommerce werden als dasselbe Ziel betrachtet | WooCommerce besitzt innerhalb von WordPress ein eigenes Commerce-Datenmodell. | CMS-Grundlagenumfang vom WooCommerce-Umfang für Products, Orders und Customers trennen. |
| Exakte Designübernahme wird ohne Theme- oder Builder-Arbeit erwartet | Datenmigration reproduziert Templates, Animationen, Builder-Widgets oder responsive Logik nicht automatisch. | Designrekonstruktion, Ziel-Theme, Builder-Implementierung und visuelle Abnahme definieren. |
| Plugin- oder Custom-Table-Daten sind geschäftskritisch, aber undokumentiert | Wichtige Datensätze sind möglicherweise nicht als gewöhnliche WordPress-Inhalte verfügbar. | Speicherstruktur, verantwortliches Plugin, Zieläquivalent und benötigte individuelle Verarbeitung dokumentieren. |
| Es gibt keinen technischen Verantwortlichen | Selbst gehostetes WordPress erfordert Wartung, Sicherheit, Backups, Performance und Updates. | Agentur, Entwickler, Hoster, Wartungsplan und Betriebsverantwortung vor dem Launch festlegen. |
| Das Quellsystem ist Managed SaaS und das Ziel erwartet ähnlich geringen Wartungsaufwand | WordPress bietet Kontrolle, erzeugt aber zusätzliche Implementierungsverantwortung. | Managed WordPress, WooCommerce-spezifische Planung, Hosted SaaS oder akzeptierte Wartungsverantwortung prüfen. |
| Komplexe Enterprise-Abläufe werden ohne Entwicklungsbudget erwartet | WordPress kann komplexe Abläufe unterstützen, meist jedoch durch Plugins, individuellen Code oder Integrationen. | Plugin-Eignung, Entwicklungsbudget, akzeptierte Ausschlüsse oder alternative Plattformrichtung bestätigen. |
Geringere Eignung sollte früh besprochen werden, weil die Flexibilität von WordPress Umfangsrisiken verdecken kann. Ein Projekt kann technisch umsetzbar, aber wirtschaftlich oder operativ ungeeignet sein, wenn die Zielimplementierung nicht definiert ist.
WordPress für die richtige Betriebsrolle auswählen
WordPress passt am besten, wenn die Zielumgebung primär eine Content-, Publishing-, Website-Architektur- oder Plugin-erweiterte Implementierung ist. Die Entscheidung wird schwächer, wenn erwartet wird, dass WordPress Core wie eine vollständige Commerce-Plattform, ein wartungsarmer Hosted-Website-Builder oder eine individuelle Anwendung ohne Implementierungsarbeit funktioniert.
| Zielanforderung | Signal für bessere WordPress-Eignung | Auswirkung auf den Umfang |
|---|---|---|
| Inhaltsorientierte Website mit SEO-Kontinuität | Seiten, Blog Posts, Medien, Menüs, Benutzer, Rollen, Taxonomien und Weiterleitungen sind zentral. | WordPress kann die primäre Zielplattform sein, wenn das Inhaltsmodell definiert ist. |
| Commerce innerhalb von WordPress | Products, Orders, Coupons, Checkout-Felder, Taxes, Versand und Zahlungskontext sind zentral. | WooCommerce oder eine andere Commerce-Ebene muss getrennt von der CMS-Grundlage eingeplant werden. |
| Einfachheit im Stil von Hosted SaaS | Der Händler möchte einen plattformverwalteten Commerce-Betrieb mit weniger eigener Implementierungsverantwortung. | Shopify, BigCommerce, Wix, Squarespace oder eine andere Hosted-Option kann besser passen, wenn Content-Flexibilität nicht Priorität ist. |
| Commerce-first-Architektur | Katalog, Checkout, Orders, Kundengruppen, B2B- oder Enterprise-Commerce-Logik prägen das Projekt. | Eine Commerce-zentrierte Plattform kann geeigneter sein als WordPress allein. |
| Einzigartiger CMS- oder Anwendungsablauf | Das Quellsystem besitzt benutzerdefinierte Datensätze, Berechtigungen, Integrationen oder Datenbankstrukturen. | WordPress kann weiterhin passen, jedoch erst nachdem individuelle Strukturen, Plugin-Verantwortung und ausgeschlossene Funktionen definiert sind. |
Die praktische Entscheidung lautet nicht, ob WordPress theoretisch flexibel genug ist. Entscheidend ist, ob die Zielimplementierung genügend Verantwortung, Plugin-Eignung, technischen Support und Klarheit im Migrationsumfang besitzt, damit diese Flexibilität nach dem Launch tatsächlich nutzbar wird.
Nachweismuster zur Bestätigung der WordPress-Eignung
Eine repräsentative Validierung sollte die Einstufung belegen und nicht nur zeigen, dass Datensätze angelegt werden können. Das Sample-Set sollte Standardinhalte sowie die schwierigen Datensätze enthalten, die das Projektrisiko bestimmen.
| Sample-Typ | Warum er Eignung belegt | Gute Sample-Beispiele |
|---|---|---|
| Standardinhalte | Bestätigt die grundlegende Migration von WordPress-Datensätzen. | CMS Pages, Blog Posts, Autoren, Categories, Tags, Beitragsbilder, Kommentare, Auszüge und Slugs. |
| Benutzerdefinierte Struktur | Bestätigt, ob nicht standardmäßige Inhalte korrekt dargestellt werden können. | Datensätze benutzerdefinierter Beitragstypen, benutzerdefinierte Taxonomien, benutzerdefinierte Felder, Beziehungsfelder, Archivbeispiele und templategebundene Inhalte. |
| Plugin-abhängige Daten | Zeigt, ob Datensätze native Inhalte, Plugin-eigen, tabellenbasiert oder extern sind. | Mitgliedschaftsprofil, Kurs, Event, Buchung, Formularübermittlung, Verzeichniseintrag, Spenden- oder Commerce-Plugin-Beispiel. |
| Layout-sensitive Seiten | Prüft, ob Inhaltsablage und visuelle Darstellung zusammenpassen. | Builder-Layouts, wiederverwendbare Blöcke, Shortcode-Seiten, Formulare, Galerien, eingebettete Medien und Prioritäts-Landingpages. |
| SEO-sensitive Inhalte | Bestätigt, ob traffic-kritische Struktur die Migration übersteht. | Hochwertige URLs, Metadaten, Weiterleitungen, Canonical-Werte, Medienpfade, interne Links und URLs von Taxonomiearchiven. |
| Benutzer-/Kontobeispiele | Bestätigt, dass Kontobedeutung nicht abgeflacht wird. | Autoren, Redakteure, Mitglieder, Abonnenten, Lernende, Spender, Customers, Anbieter oder benutzerdefinierte Rollen. |
Kann die repräsentative Validierung die Datensätze, die die Plattformwahl bestimmen, nicht abbilden, sollte das Projekt bedingt eingestuft bleiben. Das ist besonders wichtig für Plugin-basierte WordPress-Websites, bei denen die wertvollsten Daten möglicherweise keine gewöhnlichen Seiten- oder Beitragsinhalte sind.
Entscheidungstore für die WordPress-Eignung
Die WordPress-Eignung muss zusammen mit der vorgesehenen Commerce-Erweiterung oder individuellen Anwendung bewertet werden. WordPress Core definiert nicht das vollständige Product-, Customer-, Order-, Checkout-, Pricing- oder Inventory-Modell.
| Eignungstor | Pass-Bedingung | Warnsignal |
|---|---|---|
| Plattformrollen-Tor | Die Organisation hat definiert, ob WordPress die Inhaltsgrundlage, Commerce-Grundlage oder beides ist. | WordPress wird gewählt, ohne das System festzulegen, das Commerce-Datensätze besitzt. |
| Inhaltsmodell-Tor | Seiten, Blog Posts, benutzerdefinierte Beitragstypen, Taxonomien, Felder, Medien und redaktionelle Abläufe haben definierte Zielzwecke. | Jede Quell-Inhaltsstruktur wird ohne zukünftigen Verwendungszweck erhalten. |
| Commerce-Erweiterungs-Tor | Die gewählte Erweiterung oder individuelle Anwendung unterstützt die erforderlichen Products, Customers, Orders, Checkout- und Betriebsregeln. | Eignung wird allein aus Vertrautheit mit WordPress abgeleitet. |
| Plugin- und Theme-Tor | Kritische Plugins, Themes, Builder und individueller Code haben Verantwortliche und Lebenszykluspläne. | Website-Funktion hängt von unbekannten oder aufgegebenen Komponenten ab. |
| Integrations-Tor | CRM-, Mitgliedschafts-, Lern-, Marketing-, ERP-, Zahlungs- und Auftragsabwicklungssysteme haben klare Zuständigkeiten. | Mehrere Plugins und Systeme verwalten dieselben Identitäten oder Transaktionen. |
| Tor für technische Verantwortung | Hosting, Sicherheit, Updates, Backups, Performance und Deployment haben benannte Verantwortliche. | Die Organisation möchte Erweiterbarkeit ohne Wartungsverantwortung. |
WordPress ist stark geeignet, wenn Inhaltsarchitektur und ausgewähltes Commerce-Modell einander ergänzen. Die Eignung ist bedingt, wenn Entscheidungen zu Erweiterungen oder Verantwortlichkeiten offen sind, und geringer, wenn eine Commerce-first Hosted-Plattform besser zum Betriebsmodell passen würde.
Fazit
WordPress ist eine starke Zielplattform, wenn das Migrationsziel in der Kontrolle über Inhalte, einer flexiblen CMS-Struktur, SEO-Kontinuität, redaktionellen Abläufen, Plugin-Erweiterbarkeit und kontrollierter Implementierung liegt. Die Eignung ist bedingt, wenn das Ziel von Buildern, benutzerdefinierten Inhaltsmodellen, Plugin-Datensätzen, benutzerdefinierten Feldern, benutzerdefinierten Tabellen, mehrsprachigen Strukturen, Benutzern mit geschäftsspezifischen Rollen oder Integrationen mit tieferem Zuordnungsbedarf abhängt. Sie ist geringer, wenn erwartet wird, dass WordPress Core native Commerce-Funktionen, eine exakte Designkopie oder einen wartungsarmen Hosted-Betrieb ohne Implementierungsverantwortung liefert.
Die beste Eignungsentscheidung entsteht aus einer ehrlichen Klassifizierung des Projekts. Eine starke WordPress-Eignung hat ein definiertes Inhaltsmodell, einen Plugin-Stack, ein Benutzermodell, einen SEO-Plan und einen technischen Verantwortlichen. Bedingte Eignung braucht mehr Analyse, bevor der Umfang sicher ist. Bei geringerer Eignung kann WooCommerce-spezifische Planung, eine andere Zielplattform, akzeptierte Ausschlüsse, Implementierungsarbeit oder eine Prüfung benutzerdefinierter Daten erforderlich sein, bevor die Launch-Planung fortgesetzt werden sollte.
Häufige Fragen
Welcher Projekttyp passt gewöhnlich am besten zu WordPress?
WordPress eignet sich besonders für inhaltsorientierte Projekte, die CMS Pages, Blog Posts, Medien, Benutzer, Categories, Tags, Menüs, SEO-Kontrolle, redaktionelle Abläufe, Plugin-Erweiterbarkeit und eigene Implementierungsverantwortung benötigen.
Ist WordPress eine gute Wahl für eine E-Commerce-Migration?
WordPress allein ist gewöhnlich nicht die vollständige E-Commerce-Lösung. Sind Products, Warenkorb, Checkout, Orders, Coupons, Taxes, Versand, Zahlungskontext und Commerce-Customers relevant, sollte WooCommerce oder eine andere Commerce-Ebene separat geplant werden.
Wann ist WordPress nur bedingt geeignet?
WordPress ist bedingt geeignet, wenn das Ziel von benutzerdefinierten Beitragstypen, Taxonomien, Feldgruppen, Page Buildern, Shortcodes, Plugin-Datensätzen, benutzerdefinierten Tabellen, mehrsprachiger Logik, Mitgliedschaften, LMS-Datensätzen, Buchungen, Events, Verzeichnissen oder externen Integrationen abhängt.
Wann sollte ein Händler WordPress als Zielplattform überdenken?
Ein Händler sollte WordPress überdenken, wenn das Projekt native Commerce-Funktionen ohne Commerce-Plugin, eine exakte visuelle Kopie ohne Implementierungsarbeit, wartungsarmen SaaS-Betrieb oder komplexe Geschäftsprozesse ohne Unterstützung durch Plugins, individuellen Code oder Integrationen benötigt.
Wie wirken sich Zielkonfiguration sowie Prüfung benutzerdefinierter Daten oder separate Implementierungsarbeit auf die WordPress-Eignung aus?
Zielkonfiguration kann klar begrenzte Darstellungsanforderungen lösen. Eine Prüfung benutzerdefinierter Daten oder separate Implementierungsarbeit ist sinnvoll, wenn geschäftskritische Informationen in Plugin-Tabellen, benutzerdefinierten Feldern, benutzerdefinierten Beitragstypen, externen Kennungen oder einer individuell entwickelten Quellplattform liegen.
Kann die WordPress-Eignung beurteilt werden, ohne eine Commerce-Erweiterung auszuwählen?
Nur auf hoher Ebene. Eine vollständige Eignungsentscheidung erfordert die vorgesehene Commerce-Erweiterung oder individuelle Anwendung, weil Products, Customers, Orders, Checkout, Pricing und Inventory nicht allein vom WordPress Core verwaltet werden.