Wann TYPO3 für eine WordPress-Website infrage kommt
TYPO3 ist ein Kandidat, wenn mehrere Marken- und Länderauftritte gemeinsam verwaltet werden sollen, lokale Teams nur bestimmte Bereiche bearbeiten dürfen und Änderungen vor der Veröffentlichung eine Freigabe brauchen. Seitenbaum, Sprachverwaltung, Zugriffsrechte und konfigurierbare Workspaces lassen sich dafür kombinieren.
Wir prüfen diese Abläufe mit der Redaktion an eigenen Inhalten. Ein langsames Frontend oder eine lange Plugin-Liste allein rechtfertigen den Wechsel nicht: Liegt das Problem im Theme, im Hosting oder in einzelnen Erweiterungen, kann eine Überarbeitung von WordPress wirtschaftlicher sein. In den Vergleich gehören auch Schulung, Wartung und künftige Updates.
Inhalte, Plugins und Schnittstellen erfassen
Zuerst erfassen wir, was die Website heute leistet: Seiten und Beiträge, Downloads, Formulare, Nutzerkonten, Sprachversionen und Schnittstellen. Dazu kommt der Blick hinter die Oberfläche: Welche Daten stecken in eigenen Inhaltstypen, Plugin-Tabellen oder individuellen Feldern? Welche Aufgaben erledigen zeitgesteuerte Prozesse?
Bei Gutenberg, Elementor, WPBakery oder ACF prüfen wir die gespeicherten Blöcke, Layoutdaten und Felder. Dynamische Gutenberg-Blöcke können beispielsweise nur einen Platzhalter samt Einstellungen speichern; die Ausgabe erzeugt WordPress erst beim Aufruf. Für solche Funktionen und für Shortcodes braucht es eine Umsetzung in TYPO3. Auch SEO-Metadaten aus Plugins und die Zuordnung zwischen Übersetzungen nehmen wir in die Bestandsaufnahme auf.
WordPress-Inhalte dem neuen Datenmodell zuordnen
Wir beginnen mit einer kleinen Probemigration: einem längeren Beitrag, einer verschachtelten Landingpage und einem Datensatz mit Downloads und Übersetzungen. Daran legen wir die TYPO3-Inhaltselemente und Eingabefelder fest. Die Redaktion kann damit prüfen, ob sich ihre Seiten im neuen Backend tatsächlich pflegen lassen.
- Beiträge und Kategorien
- Titel, Autor, Veröffentlichungsdatum und Inhalt erhalten passende Felder. Kategorien, verwandte Beiträge sowie Seitentitel und Beschreibungen für Suchmaschinen werden zugeordnet. Entwürfe und private Beiträge dürfen beim Import nicht versehentlich veröffentlicht werden.
- Eigene Inhaltstypen und Felder
- Standorte, Produkte oder Personen werden als passende Datensätze modelliert. Feldtypen, Pflichtangaben und Verknüpfungen bestimmen, wie die Informationen später gepflegt und verwendet werden.
- Blöcke und Page-Builder-Layouts
- Wiederkehrende Bausteine werden auf neue Inhaltselemente abgebildet. Layoutdaten übernehmen wir nicht ungeprüft als HTML; für Sonderfälle entscheiden Redaktion und Gestaltung, was erhalten oder neu aufgebaut wird.
- Bilder und Downloads
- Wir übernehmen die Dateien in die TYPO3-Dateiverwaltung und stellen ihre Verknüpfung zu den Inhalten her. Dazu prüfen wir Alternativtexte, Bildunterschriften und Bildnachweise – auch dann, wenn dasselbe Bild an mehreren Stellen unterschiedlich verwendet wird.
- Sprachversionen
- Übersetzungen werden ihrer Ausgangsseite zugeordnet. Mit der Redaktion legen wir fest, was bei fehlenden Übersetzungen angezeigt wird und welche Inhalte in einzelnen Ländern bewusst abweichen.
Was der WordPress-Export tatsächlich liefert
WordPress liefert mit WXR eine XML-Datei für Beiträge, Seiten, Kommentare, Felder und Taxonomien. Der Umfang hängt von Exportfiltern und der Exportfreigabe eigener Inhaltstypen ab. Bei Medien enthält die Datei Verweise, nicht die Bild- oder PDF-Dateien selbst. Theme, Plugin-Code und Daten aus eigenen Plugin-Tabellen brauchen einen gesonderten Übertragungsweg.
Auch TYPO3s eingebauter Import ist kein WXR-Konverter: Er übernimmt Exporte aus anderen TYPO3-Installationen. Für WordPress müssen Quelldaten auf die TYPO3-Strukturen abgebildet werden. Ob dafür WXR, eine API oder ein gezielter Datenbankexport geeignet ist, prüfen wir am tatsächlichen Datenbestand.
Der Import erhält eine Zuordnung alter und neuer Datensätze. Weitere Durchläufe aktualisieren bereits übernommene Inhalte, statt Dubletten anzulegen. Fehlende Dateien, ungültige Beziehungen und nicht unterstützte Bausteine sammeln wir in einem Fehlerbericht, den wir vor der Umstellung abarbeiten.
Logins, Formulare und angebundene Systeme
Autorennamen unter Beiträgen sind etwas anderes als Benutzerkonten mit Zugriffsrechten. Die Autorenangaben im WXR-Export enthalten keine Login-Passwörter. Für Redakteure und angemeldete Websitebesucher legen wir getrennt fest, welche Konten und Rollen übernommen werden und wie der erste Login funktioniert – etwa über vorhandenes Single Sign-on oder eine Passwort-Neuvergabe.
Bei Formularen prüfen wir Validierung, Empfänger, Bestätigungsmails und die Übergabe ans CRM. Für Shop-, Buchungs- oder Mitgliederfunktionen planen wir einen eigenen Migrationsumfang. Ein Inhaltsimport überträgt weder Bestellabläufe noch Zahlungsanbindungen. Tests laufen gegen Testsysteme oder abgefangene E-Mails, damit keine echten Buchungen oder Nachrichten ausgelöst werden.
Bestehende URLs mitnehmen
Vor dem Wechsel erfassen wir bestehende Adressen aus einem Website-Crawl, der Sitemap, Search Console und Serverprotokollen – einschließlich Bilder und PDFs. Für wichtige Einstiegsseiten halten wir Suchzugriffe und relevante Suchanfragen als Vergleichsbasis fest. Zusätzliche Änderungen an Domain und Design planen wir nach Möglichkeit in getrennten Schritten.
Unveränderte Adressen bleiben bestehen. Geänderte URLs leiten wir serverseitig mit 301 oder 308 direkt zum passenden Inhalt weiter. Ohne Ersatz erhält eine entfernte Seite 404 oder 410 statt einer pauschalen Weiterleitung zur Startseite. Interne Links, Canonicals, hreflang-Verweise und Sitemap werden angepasst. Google empfiehlt, Weiterleitungen in der Regel mindestens ein Jahr zu erhalten.
Die neue Website mit der Redaktion abnehmen
Nach dem vollständigen Testimport vergleichen wir Datensätze, Medien und Sprachzuordnungen. Automatisierte Prüfungen kontrollieren Links und wiederkehrende Funktionen. Die Redaktion erstellt und übersetzt Inhalte, spielt Freigaben durch und prüft Vorschau und Veröffentlichung. Dazu kommen mobile Darstellung, Tastaturbedienung und Ladezeiten der wichtigsten Seitentypen.
Die Testumgebung ist zugriffsgeschützt; personenbezogene Testdaten beschränken oder anonymisieren wir. Zum Start prüfen wir auf der öffentlichen Website ausdrücklich, ob eine versehentlich übernommene noindex-Anweisung oder Crawling-Sperre die Indexierung verhindert. Die Testumgebung bleibt geschützt.
Letzten Datenstand übernehmen und den Start begleiten
Zwischen Testimport und Veröffentlichung arbeitet die bisherige Website weiter. Für dieses Zeitfenster vereinbaren wir eine kurze Redaktionspause oder einen abschließenden Abgleich aller Änderungen – einschließlich neuer Dateien und gelöschter Inhalte. Verantwortliche und Abnahmekriterien für die Umstellung werden vorher festgelegt.
Ein vollständiges Backup umfasst Datenbank und Dateien. Den Rückfallweg proben wir vorab; neue Anfragen nach dem Start müssen auch bei einer Rückkehr zur alten Website erhalten bleiben. Anschließend kontrollieren wir Fehlerprotokolle, Formulare, Schnittstellen und Suchsichtbarkeit. Rankings können vorübergehend schwanken. Auffällige Verluste prüfen wir seitenweise anhand des vorher erfassten Bestands.
Drupal, Neos, Craft und Headless-CMS als Alternativen
Für einen Wechsel von WordPress kommen auch Drupal, Neos, Craft, Storyblok oder Payload infrage. Ein Magazin mit maßgeschneiderten Eingabemasken stellt andere Anforderungen als eine internationale Plattform oder ein Portal mit eigener Geschäftslogik. Unser CMS-Vergleich hilft, diese Unterschiede einzuordnen.
Unsere Aufwandsschätzung trennt Datenübernahme, neue Inhaltselemente, Funktionsentwicklung, SEO-Umstellung und Schulung. Wartung und Betrieb kommen als laufende Kosten dazu. So lässt sich eine Migration mit der Weiterentwicklung von WordPress vergleichen, bevor das gesamte Projekt beauftragt wird.
Für die Aufwandsschätzung zählen die unterschiedlichen Inhaltstypen und Funktionen: 500 ähnlich aufgebaute Beiträge können leichter zu übertragen sein als 20 individuell gestaltete Seiten mit Formularen und Schnittstellen.