WordPress ist nicht mein Problem. WooCommerce ist auch nicht mein Problem. Im Gegenteil: WooCommerce bleibt für meinen Shop weiterhin die richtige Grundlage. Das eigentliche Problem ist der technische Bewuchs, der sich über Jahre um einen Shop herum bildet.

Ein Theme hier. Ein SEO-Plugin dort. Dazu Customizer-Einstellungen, Template-Overrides, WooCommerce-Hooks, zusätzliche Optionen, Performance-Schalter, Social-Media-Metadaten, Breadcrumbs, Sitemaps, Schema-Ausgaben und Weiterleitungen. Irgendwann funktioniert der Shop zwar noch, aber man weiß nicht mehr zuverlässig, welche Funktion eigentlich woher kommt.

Genau diesen Zustand möchte ich auflösen.

Mein Ziel ist nicht, WordPress zu verlassen. Mein Ziel ist ein schlanker, kontrollierbarer WooCommerce-Shop mit einem eigenen Theme und einem eigenen kleinen SEO-Modul. Externe SEO-Plugins sollen am Ende nicht mehr Teil des produktiven Systems sein.

Codex Agent nutze ich dabei nicht als blinden Codegenerator, sondern als technischen Auditor, Mapper und Migrationsassistenten.

Warum ich SEO-Plugins loswerden will

SEO-Plugins sind oft nützlich. Sie nehmen einem viele Dinge ab, die bei WordPress sonst schnell vergessen werden: Meta-Titel, Meta-Descriptions, Canonicals, XML-Sitemaps, Open Graph, Schema.org, Breadcrumbs, Robots-Regeln und vieles mehr.

Aber genau darin liegt auch das Problem.

Ein SEO-Plugin wird irgendwann zur Blackbox. Es erzeugt HTML-Ausgaben, verändert Indexierungslogik, greift in Sitemaps ein, schreibt strukturierte Daten, setzt Canonicals und ergänzt Social-Media-Tags. Das ist bequem, solange man alles über das Plugin steuern möchte. Es ist weniger bequem, wenn man langfristig eine schlanke, versionierbare und exakt nachvollziehbare Shop-Architektur haben will.

Ich möchte nicht mehr darauf angewiesen sein, dass ein großes Plugin viele SEO-Entscheidungen implizit für mich trifft. Ich möchte die relevanten SEO-Funktionen selbst kontrollieren.

Das bedeutet aber nicht, ein SEO-Plugin einfach zu deaktivieren.

Das wäre fahrlässig.

Der richtige Ansatz: erst vermessen, dann ersetzen

Ein SEO-Plugin darf erst verschwinden, wenn klar ist, was es aktuell überhaupt tut.

Der erste Schritt ist deshalb kein Code. Der erste Schritt ist Audit.

Codex Agent soll mir helfen, die bestehende Installation systematisch zu vermessen:

Welche Meta-Titel werden erzeugt?
Welche Meta-Descriptions werden erzeugt?
Welche Canonicals stehen auf Produktseiten, Kategorien, Seiten und Beiträgen?
Welche Inhalte sind indexierbar?
Welche Inhalte stehen auf noindex?
Welche XML-Sitemaps existieren?
Welche Schema.org-Daten werden ausgegeben?
Welche Open-Graph- und Twitter-Metadaten erscheinen im Quelltext?
Welche Breadcrumbs kommen vom SEO-Plugin?
Welche Redirects sind eingerichtet?
Welche Taxonomien werden indexiert?
Wie werden Produktarchive, Kategorien, Tags, Pagination und Filter-URLs behandelt?

Erst wenn diese Dinge dokumentiert sind, kann entschieden werden, was davon ersetzt, übernommen oder bewusst gestrichen wird.

Der entscheidende Satz lautet:

Das SEO-Plugin wird nicht gelöscht. Es wird nachgebaut, ersetzt oder bewusst reduziert.

Mein Zielbild

Die neue Architektur soll klar getrennt sein.

Das eigene Theme ist für Darstellung zuständig:

Templates
Layout
CSS
WooCommerce-Darstellung
Menüs
Sidebars
Bildgrößen
Produktseiten
Archivseiten
Warenkorb- und Checkout-Darstellung

Das eigene SEO-Modul ist für SEO-Ausgaben zuständig:

Meta-Titel
Meta-Descriptions
Canonical URLs
Robots-Tags
Open Graph
Twitter Cards
strukturierte Daten
Breadcrumb-Daten
XML-Sitemap-Logik
Indexierungsregeln
Redirects, falls nötig

WooCommerce bleibt für Shop-Funktionen zuständig:

Produkte
Preise
Steuern
Versand
Warenkorb
Checkout
Kundenkonto
Bestellungen
Zahlungsfluss

Geschäftslogik gehört nicht ins Theme, sondern in ein kleines eigenes Plugin.

Damit entsteht eine Struktur, die ich verstehe, versionieren und testen kann.

Der Prompt für Codex Agent

Damit Codex Agent nicht in allgemeine WordPress-Ratschläge abgleitet, bekommt er eine klare technische Rolle und einen engen Auftrag.

Der Prompt definiert ihn als Senior WordPress-/WooCommerce-Architekt und Technical Lead für Custom Theme Development, SEO-Migration und risikoarme Replatforming-Projekte.

Das Ziel ist ein präziser Migrationsplan für zwei Dinge:

Erstens: Die relevanten Einstellungen und Funktionen meines aktuellen WooCommerce-Themes sollen in ein eigenes Theme überführt werden.

Zweitens: Die relevanten Funktionen des bisherigen SEO-Plugins sollen analysiert und durch ein eigenes schlankes SEO-Modul ersetzt werden.

Wichtig sind dabei die Einschränkungen:

Codex darf keine Fakten über meine Installation erfinden.
Unsichere Punkte müssen als Annahme markiert werden.
Direkte Änderungen an Produktion sind ausgeschlossen.
Alles muss zuerst in Staging passieren.
SEO-kritische und umsatzkritische Funktionen brauchen Validierungschecks.
Theme, SEO-Modul, WooCommerce und WordPress-Core müssen sauber getrennt werden.
Änderungen müssen reversibel sein.
Rollback muss von Anfang an mitgedacht werden.

Das ist der Unterschied zwischen „KI schreibt mir ein Theme“ und „KI unterstützt eine kontrollierte technische Migration“.

Phase 1: Audit

Im Audit wird der Ist-Zustand aufgenommen.

Für das Theme betrifft das zum Beispiel:

Customizer-Einstellungen
Theme-Optionen
theme.json
globale Styles
WooCommerce-Template-Overrides
registrierte Menüs
registrierte Sidebars
Widgets
Bildgrößen
CSS- und JavaScript-Dateien
WooCommerce-Hooks
Produktarchiv-Einstellungen
Darstellung von Produktseiten
Checkout-Anpassungen
Performance-Funktionen des alten Themes

Für das bisherige SEO-Plugin betrifft das:

Titel-Templates
Meta-Description-Templates
individuelle SEO-Titel
individuelle Meta-Descriptions
Canonical-Ausgabe
Robots-Ausgabe
Noindex-Regeln
XML-Sitemaps
Schema.org-Ausgabe
Breadcrumbs
Open Graph
Twitter Cards
Redirects
Taxonomie-SEO
Produktarchiv-SEO
Pagination
mehrsprachige hreflang-Logik, falls vorhanden

Das Ergebnis des Audits ist eine Tabelle. Jede Funktion bekommt eine Herkunft, eine aktuelle technische Quelle, eine Zielentscheidung und einen Validierungscheck.

Phase 2: Mapping

Nach dem Audit wird nicht sofort gebaut. Erst wird gemappt.

Die wichtigste Frage lautet: Wohin gehört welche Funktion?

Funktion	Ziel
Layout und Darstellung	eigenes Theme
WooCommerce-Templates	eigenes Theme, aber nur notwendige Overrides
Meta-Titel	eigenes SEO-Modul
Meta-Descriptions	eigenes SEO-Modul
Canonicals	eigenes SEO-Modul
Robots-Regeln	eigenes SEO-Modul
XML-Sitemaps	eigenes SEO-Modul oder angepasste WordPress-Core-Sitemap
Schema.org	eigenes SEO-Modul
Breadcrumb-Daten	eigenes SEO-Modul
Breadcrumb-Ausgabe	Theme, gespeist aus SEO-Modul
Open Graph	eigenes SEO-Modul
Twitter Cards	eigenes SEO-Modul
Redirects	eigenes Redirect-Modul oder eigenes SEO-Modul
Bildgrößen	Theme, wenn darstellungsbezogen
Geschäftslogik	eigenes Plugin
WooCommerce-Logik	WooCommerce

Diese Trennung ist entscheidend. Ein häufiger Fehler wäre, alles in functions.php zu werfen. Dann hat man zwar ein großes SEO-Plugin entfernt, aber gleichzeitig ein neues monolithisches Problem erzeugt.

Das Ziel ist nicht weniger Plugins um jeden Preis. Das Ziel ist weniger fremder Ballast und mehr eigene, klar abgegrenzte Verantwortung.

Phase 3: eigenes Theme

Das eigene Theme soll schlank sein.

Es braucht keine zwanzig Layout-Modi, keine eingebauten Slider, keine Theme-eigenen SEO-Funktionen, keine Pagebuilder-Abhängigkeit und keine überladene Optionsseite.

Die Basis besteht aus:

style.css
functions.php
theme.json
Template-Dateien
Template Parts
WooCommerce-Unterstützung
gezieltes CSS
gezieltes JavaScript
notwendige Bildgrößen
registrierte Menüs
registrierte Sidebars, falls wirklich gebraucht

theme.json ist sinnvoll für globale Gestaltungsregeln: Farben, Typografie, Abstände, Layout-Breiten und Block-Editor-nahe Einstellungen.

functions.php bleibt schlank. Dort werden Theme Supports, Menüs, Bildgrößen und Assets registriert. Dauerhafte Logik gehört dort nicht hinein.

WooCommerce-Template-Overrides werden nur verwendet, wenn Hooks und Filter nicht ausreichen. Jeder Override wird dokumentiert, weil er bei WooCommerce-Updates zur Wartungslast wird.

Phase 4: eigenes SEO-Modul

Der kritischere Teil ist der Ersatz des bisherigen SEO-Plugins.

Ein eigenes SEO-Modul muss nicht alles können, was große SEO-Plugins können. Es muss genau das können, was mein Shop wirklich braucht.

Für einen WooCommerce-Shop sind typischerweise relevant:

Meta-Titel für Produkte
Meta-Descriptions für Produkte
Meta-Titel für Kategorien
Meta-Descriptions für Kategorien
Meta-Titel für Seiten
Canonical URLs
Robots-Meta-Tags
Open-Graph-Tags
Twitter-Card-Tags
Produkt-Schema
Organisation- oder Website-Schema
BreadcrumbList-Schema
XML-Sitemaps
Noindex-Regeln für interne Suchseiten
Noindex-Regeln für Warenkorb, Checkout und Kundenkonto
Indexierungsregeln für Produktarchive
Regeln für Filter- und Parameter-URLs
Redirects, falls sie bisher im SEO-Plugin liegen

Das Modul sollte möglichst deterministisch arbeiten. Also keine „magischen“ Automatismen, die später niemand mehr versteht.

Beispiel:

Produktseiten bekommen einen Titel aus Produkttitel, Shopname und optionaler Kategorie.
Produktseiten bekommen eine Description aus einem definierten Feld oder einer sauberen Fallback-Regel.
Warenkorb, Checkout, Kundenkonto und interne Suche bekommen noindex.
Canonicals werden eindeutig aus der WordPress-Permalink-Struktur erzeugt.
Produktkategorien werden nur dann indexiert, wenn sie sinnvoll gepflegt sind.
Filter-URLs werden nicht unkontrolliert indexiert.
Open-Graph-Bilder kommen aus dem Produktbild oder einem definierten Standardbild.
Schema-Ausgaben werden nicht doppelt erzeugt.

Gerade Schema.org ist kritisch. WooCommerce erzeugt teilweise selbst strukturierte Daten. SEO-Plugins erzeugen ebenfalls strukturierte Daten. Das eigene Modul darf hier nicht einfach zusätzlich alles ausgeben, sonst entstehen doppelte oder widersprüchliche Daten.

Phase 5: Migration

Die Migration erfolgt nicht in einem Schritt.

Zuerst wird das neue Theme in Staging gebaut.
Dann wird das SEO-Modul in Staging entwickelt.
Dann werden die Ausgaben mit dem alten Zustand verglichen.
Dann wird das bisherige SEO-Plugin in Staging deaktiviert.
Dann wird erneut verglichen.
Erst danach kommt ein Launch infrage.

Für die SEO-Migration ist ein Vorher-Nachher-Vergleich notwendig.

Verglichen werden müssen mindestens:

HTML-Title
Meta-Description
Canonical
Robots-Meta
Open Graph
Twitter Cards
Schema.org
Breadcrumbs
XML-Sitemaps
HTTP-Statuscodes
Redirects
Indexierungsregeln
Produktarchiv-URLs
Kategorie-URLs
Pagination
Filter-URLs

Das Ziel ist nicht zwingend, jeden bisherigen Ausgabewert bytegenau zu kopieren. Das Ziel ist, keine unbeabsichtigten SEO-Veränderungen zu erzeugen.

Bewusste Änderungen sind erlaubt. Unbemerkte Änderungen sind das Risiko.

Phase 6: QA

Die QA besteht aus drei Blöcken: SEO, WooCommerce und Performance.

SEO-QA

Geprüft werden:

Permalinks
Redirects
Canonicals
Meta-Titel
Meta-Descriptions
Robots-Tags
XML-Sitemaps
Schema.org
Breadcrumbs
Open Graph
Twitter Cards
hreflang, falls vorhanden
Produktseiten
Produktkategorien
Archive
Pagination
Filter-URLs
interne Suche
404-Seiten
robots.txt
Google Search Console

Wichtig ist die Prüfung im Quelltext. Nicht nur im Browser. SEO passiert im HTML.

WooCommerce-QA

Geprüft werden:

Produktdetailseiten
Produktbilder
Varianten
Preise
Steueranzeige
Lagerstatus
Kategorie- und Archivseiten
Sortierung
Filter
Suche
Warenkorb
Gutscheine
Checkout
Versandkosten
Zahlungsarten
Kundenkonto
Login
Registrierung
Passwort vergessen
Bestellbestätigung
transaktionale E-Mails
mobile Darstellung
Fehlerzustände

Ein Shop ist erst dann funktionsfähig, wenn eine Testbestellung sauber durchläuft.

Performance-QA

Geprüft werden:

Core Web Vitals
LCP
CLS
INP
Bildgrößen
srcset
Lazy Loading
CSS-Ladeverhalten
JavaScript-Ladeverhalten
nicht benötigte Assets
Caching
Template-Renderkosten
Datenbankabfragen
Crawlability
Server-Logs

Der Vorteil eines eigenen Themes liegt vor allem darin, nur noch das zu laden, was wirklich gebraucht wird.

Phase 7: Launch

Der Launch darf nur erfolgen, wenn Staging bestanden ist.

Vor dem Launch müssen vorhanden sein:

Git-Stand des alten Systems
Git-Stand des neuen Systems
Datenbankbackup
Dateibackup
Liste geänderter Optionen
Export der bisherigen SEO-Plugin-Konfiguration, falls möglich
Dokumentation der alten SEO-Konfiguration
altes Theme weiterhin verfügbar
Rollback-Plan
Testplan
Wartungsfenster
Caching-Strategie
Monitoring nach Launch

Nach dem Launch werden sofort geprüft:

Startseite
wichtigste Produktseiten
wichtigste Produktkategorien
Warenkorb
Checkout
Sitemap
robots.txt
Canonicals
Meta-Titel
Schema
Open Graph
HTTP-Statuscodes
404-Fehler
Server-Logs
Google Search Console

Das bisherige SEO-Plugin wird nicht „einfach gelöscht“. Es wird erst deaktiviert, wenn das eigene SEO-Modul in Staging stabil ist. Danach wird beobachtet, ob die produktive Seite dieselben SEO-kritischen Ausgaben liefert.

Mapping-Tabelle

Quelle	Aktuelle Position	Ziel	Methode	Risiko	Validierung
Theme-Optionen	Customizer / Theme-Panel	eigenes Theme	relevante Werte übernehmen oder ersetzen	mittel	visueller Vergleich wichtiger Seiten
theme.json / globale Styles	altes Theme	eigenes Theme	neu definieren	niedrig	Layout- und Block-Test
WooCommerce-Templates	altes Theme /woocommerce/	eigenes Theme	nur notwendige Overrides übernehmen	hoch	Produkt, Warenkorb, Checkout testen
WooCommerce-Hooks	functions.php / Theme-Dateien	eigenes Theme oder Plugin	Hook für Hook prüfen	hoch	HTML- und Funktionsvergleich
Menüs	WordPress-Menüs	eigenes Theme	Menüpositionen registrieren	niedrig	Navigation prüfen
Widgets / Sidebars	Theme / WordPress	eigenes Theme	nur benötigte Sidebars registrieren	mittel	Frontend-Vergleich
Bildgrößen	Theme / WooCommerce	eigenes Theme	benötigte Größen registrieren	mittel	Produktbilder, srcset, Performance prüfen
Meta-Titel	SEO-Plugin	eigenes SEO-Modul	Regeln nachbauen	hoch	Quelltextvergleich
Meta-Descriptions	SEO-Plugin	eigenes SEO-Modul	Regeln und Felder nachbauen	hoch	Quelltextvergleich
Canonicals	SEO-Plugin	eigenes SEO-Modul	eindeutige Canonical-Logik	sehr hoch	Canonical-Prüfung je Seitentyp
Robots-Regeln	SEO-Plugin	eigenes SEO-Modul	index/noindex-Regeln nachbauen	sehr hoch	Quelltext und Crawling prüfen
XML-Sitemaps	SEO-Plugin	eigenes SEO-Modul oder Core-Sitemap	Sitemap ersetzen	hoch	Sitemap erreichbar und vollständig
Schema.org	SEO-Plugin / WooCommerce	eigenes SEO-Modul	nur notwendige strukturierte Daten	sehr hoch	Rich Results Test / Quelltext
Breadcrumbs	SEO-Plugin / Theme	SEO-Modul + Theme-Ausgabe	Datenlogik ins Plugin, Ausgabe ins Theme	mittel	Breadcrumb-Pfad und Schema prüfen
Open Graph	SEO-Plugin	eigenes SEO-Modul	Tags nachbauen	mittel	Sharing Debugger / Quelltext
Twitter Cards	SEO-Plugin	eigenes SEO-Modul	Tags nachbauen	niedrig	Quelltext prüfen
Redirects	SEO-Plugin, falls genutzt	eigenes Redirect-Modul	exportieren und übernehmen	sehr hoch	HTTP-Status und Ziel-URL prüfen
Produktarchive	Theme / WooCommerce / SEO-Plugin	Theme + SEO-Modul	Darstellung und SEO trennen	hoch	Kategorie, Pagination, Filter prüfen
Filter-URLs	WooCommerce / Theme / SEO-Plugin	SEO-Modul	noindex/canonical-Regeln definieren	sehr hoch	Crawl-Test
interne Suche	WordPress / SEO-Plugin	SEO-Modul	noindex setzen	hoch	Robots-Meta prüfen
Warenkorb / Checkout / Konto	WooCommerce / SEO-Plugin	SEO-Modul	noindex setzen	hoch	Quelltext prüfen

Risiken

Das größte Risiko sind unbeabsichtigte SEO-Änderungen. Wenn Canonicals, Robots-Regeln oder Sitemaps falsch sind, kann das Ranking kosten.

Das zweite Risiko ist ein defekter Checkout. Ein Themewechsel darf niemals den Kaufprozess beschädigen.

Das dritte Risiko sind doppelte strukturierte Daten. Wenn WooCommerce und das eigene SEO-Modul gleichzeitig widersprüchliches Schema ausgeben, wird die Seite technisch unsauber.

Das vierte Risiko sind verlorene Redirects. Wenn alte URLs nicht mehr korrekt weitergeleitet werden, entstehen 404-Fehler und Rankingverluste.

Das fünfte Risiko sind Filter- und Parameter-URLs. Ein Shop kann sehr viele technisch unterschiedliche URLs erzeugen. Ohne klare Indexierungsregeln kann daraus ein Crawl- und Duplicate-Content-Problem entstehen.

Das sechste Risiko ist falsche Zuständigkeit. Wenn SEO-Logik im Theme landet, entsteht später wieder Abhängigkeit. Deshalb gehört dauerhafte SEO-Logik in ein eigenes Plugin.

Rollback

Der Rollback wird vor dem Launch vorbereitet.

Die Schritte sind:

1. Git-Stand des alten Themes sichern.
2. Git-Stand des neuen Themes taggen.
3. Datenbankbackup unmittelbar vor Launch erstellen.
4. Dateibackup erstellen.
5. alte SEO-Plugin-Konfiguration dokumentieren oder exportieren.
6. altes Theme installiert lassen.
7. bisheriges SEO-Plugin installiert lassen, aber erst nach erfolgreicher Migration deaktivieren.
8. geänderte WordPress-Optionen dokumentieren.
9. Feature Flags für neue SEO-Ausgaben vorsehen.
10. bei Fehler altes Theme reaktivieren.
11. bisheriges SEO-Plugin wieder aktivieren.
12. Caches leeren.
13. Permalinks neu speichern, falls nötig.
14. Produktseiten, Kategorien, Checkout, Sitemap und Canonicals prüfen.
15. Server-Logs und Search Console kontrollieren.

Rollback ist kein Zeichen von Scheitern. Rollback ist Teil einer seriösen Migration.

Warum Codex Agent hier sinnvoll ist

Codex Agent ist für diese Aufgabe nützlich, weil er große technische Zusammenhänge strukturiert erfassen kann.

Er kann Theme-Dateien analysieren.
Er kann Hooks finden.
Er kann Template-Overrides auflisten.
Er kann SEO-Ausgaben mit neuen Ausgaben vergleichen.
Er kann Migrationsmatrizen erstellen.
Er kann Testfälle ableiten.
Er kann Risiken dokumentieren.
Er kann Vorschläge für kleine, reversible Änderungen machen.

Aber er darf nicht unbeaufsichtigt entscheiden.

Die Verantwortung bleibt bei mir.

Gerade bei SEO und WooCommerce geht es nicht um hübschen Code, sondern um Umsatz, Sichtbarkeit und technische Stabilität. Deshalb ist der Prompt so streng: keine erfundenen Fakten, keine Produktionsänderungen, keine unklaren Annahmen, keine Vermischung von Theme, SEO und Shop-Logik.

Fazit

Ich möchte meinen WooCommerce-Shop nicht neu erfinden. Ich möchte ihn entkernen.

WooCommerce bleibt. WordPress bleibt. Aber das schwere Theme und externe SEO-Plugins sollen nicht dauerhaft die Architektur bestimmen.

Der Weg dahin ist kein radikaler Schnitt, sondern eine kontrollierte Migration: Audit, Mapping, eigenes Theme, eigenes SEO-Modul, Staging, Vergleich, QA, Launch und Rollback.

Codex Agent hilft mir dabei, diese Arbeit systematisch und nachvollziehbar zu strukturieren. Nicht als Ersatz für technisches Verständnis, sondern als Werkzeug, um Komplexität beherrschbar zu machen.

Das Ziel ist ein Shop, dessen zentrale Funktionen ich wieder selbst verstehe:

Was gibt der Shop aus?
Warum gibt er es aus?
Wo ist es implementiert?
Wie wird es getestet?
Wie kann ich es zurückrollen?

Erst wenn diese Fragen beantwortet sind, ist ein externes SEO-Plugin wirklich ersetzbar. Nicht vorher.