WordPress-SEO-UX-Audit: Probleme richtig priorisieren

Deine WordPress-Website erhält Impressionen, aber kaum Klicks? Besucher kommen auf die Seite, stellen jedoch keine Anfrage? Oder funktioniert mobil deutlich weniger als am Desktop? Dann reicht weder ein isolierter SEO-Check noch ein schneller Lighthouse-Test. Du brauchst ein WordPress-SEO-UX-Audit, das Sichtbarkeit, Bedienbarkeit, Technik und Conversion gemeinsam untersucht.

Entscheidend ist nicht, möglichst viele Fehler zu sammeln. Ein sinnvoller Audit klärt, welches Problem auf welchen URLs auftritt, wodurch es wahrscheinlich verursacht wird und welche Maßnahme den größten Nutzen verspricht. Dieser Leitfaden zeigt dir eine reproduzierbare Prüfreihenfolge – einschließlich Schnellaudit, Core Web Vitals, WordPress-Fehlerdiagnose, Priorisierung und Erfolgskontrolle.

SEO-, UX- und gemeinsame SXO-Probleme unterscheiden

Ein SEO-Problem erschwert es Suchmaschinen, eine Seite zu finden, zu verstehen oder für passende Suchanfragen auszuspielen. Dazu gehören unbeabsichtigte Nichtindexierung, unklare Seitenschwerpunkte, interne Konkurrenz und Inhalte, die nicht zur Suchintention passen. Ein UX-Problem hindert Menschen daran, ihr Ziel effizient zu erreichen – etwa eine unverständliche Navigation, schlecht erkennbare Bedienelemente oder ein problematisches Formular.

Viele Schwächen betreffen beide Bereiche. Diese Schnittmenge wird häufig als Search Experience Optimization, kurz SXO, bezeichnet. Eine langsame mobile Leistungsseite kann technisch erreichbar und relevant sein, Besucher aber vor dem Laden der wichtigsten Information verlieren. Googles Dokumentation zur Page Experience ordnet das differenziert ein: Gute technische Erfahrungswerte ersetzen keine relevanten Inhalte und garantieren keine Rankings.

Beginne deshalb immer mit einem konkreten Symptom. „Die Website braucht bessere SEO“ ist keine Diagnose. „Leistungsseiten erhalten mobil viele Impressionen, aber deutlich weniger Klicks und Interaktionen als am Desktop“ lässt sich dagegen untersuchen und später überprüfen.

Trenne außerdem Korrelation und Ursache. Eine hohe Absprungrate beweist weder ein Rankingproblem noch automatisch schlechte UX. Verknüpfe Verhaltensdaten deshalb mit Suchintention, Seitentyp und messbaren Zielhandlungen. Die allgemeinen Zusammenhänge vertieft der Beitrag über OnPage SEO und Nutzererlebnis.

Den 90-Minuten-Schnellaudit sinnvoll durchführen

Ein Schnellaudit ersetzt keine vollständige Analyse. Er zeigt dir jedoch, ob der größte Hebel wahrscheinlich bei Indexierung und Inhalt, mobiler Bedienung, WordPress-Technik oder Conversion liegt. Wähle vorab drei bis fünf wichtige URLs: Startseite, zentrale Leistungsseite, starken organischen Einstieg, auffällige Problemseite und Kontakt- oder Abschlussseite.

Arbeite mit echten Aufgaben statt mit einer abstrakten Bewertung. Prüfe beispielsweise, ob ein mobiler Besucher eine bestimmte Leistung versteht, Voraussetzungen findet und eine Anfrage abschließen kann. Öffne parallel die Search Console, deine Webanalyse und PageSpeed Insights.

Triff am Ende eine klare Vertiefungsentscheidung. Führen Indexstatus oder Suchanfragen zum Befund, prüfst du zuerst Inhalt und Suchintention. Scheitert eine zentrale Aufgabe auf dem Smartphone, folgt ein Bedienungs- und Conversion-Test. Zeigen URL-Gruppen schlechte reale Web Vitals, vertiefst du die technische Analyse. Sind Daten widersprüchlich oder unvollständig, hat die Messung selbst Vorrang.

Ändere während des Audits noch nichts. Sonst vermischst du Diagnose und Umsetzung. Ein technischer Hinweis ohne betroffene Zielseite, Nutzerwirkung und Nachweis ist noch keine priorisierte Aufgabe. Für Indexierung, Canonicals und interne Verlinkung helfen die Grundlagen eines SEO-Audits.

Search Console, Webanalyse und Core Web Vitals richtig lesen

In der Google Search Console sind für den Audit vor allem Suchanfragen, Seiten, Geräte, Länder, Klicks, Impressionen, durchschnittliche Position und CTR relevant. Vergleiche nicht nur Gesamtwerte, sondern gleiche Segmente: dieselbe URL oder URL-Gruppe, vergleichbare Suchanfragen, dasselbe Gerät und einen passenden Zeitraum.

Durchschnittliche Position und CTR sind keine isolierten Qualitätsnoten. Eine CTR kann wegen anderer Suchanfragen, veränderter Positionen oder saisonaler Nachfrage schwanken. Frage deshalb zuerst: Hat sich die Sichtbarkeit für relevante Suchanfragen verändert, oder hat sich nur die Zusammensetzung des Traffics verschoben?

Die Webanalyse beantwortet eine andere Frage: Was geschieht nach dem Klick? Definiere dafür aussagekräftige Ereignisse wie abgeschickte Formulare, Klicks auf Telefonnummern, Downloads oder erreichte Bestätigungsseiten. Prüfe außerdem, ob Cookie-Einwilligung, interne Zugriffe, fehlende Consent-Signale oder fehlerhafte Ereignisse deine Daten verzerren.

PageSpeed Insights verbindet – sofern verfügbar – Felddaten realer Chrome-Nutzer mit einem Labortest. Die Felddaten zeigen, was Besucher unter unterschiedlichen Geräten und Verbindungen tatsächlich erleben. Lighthouse simuliert dagegen einen einzelnen Testlauf unter festgelegten Bedingungen. Das Labor eignet sich zur Ursachensuche und zum Vergleich kontrollierter Änderungen, ist aber kein Beweis für die Erfahrung aller Nutzer.

Für die Core Web Vitals gelten als gute Orientierungswerte LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1. Bewertet wird am 75. Perzentil der Seitenaufrufe. LCP betrifft das größte sichtbare Inhaltselement, INP die Reaktionsfähigkeit bei Interaktionen und CLS unerwartete Layoutverschiebungen.

Weichen Feld- und Labordaten voneinander ab, behandle mögliche Erklärungen als Hypothesen. Unterschiede können etwa durch Gerätemix, Netzbedingungen, Seitentypen, externe Skripte oder Interaktionen entstehen, die der einzelne Labortest nicht abbildet. Prüfe betroffene URL-Gruppen gezielt weiter. Eine ausführlichere Einordnung findest du unter Core Web Vitals verbessern.

WordPress-Ursachen nach technischer Ebene eingrenzen

WordPress-Probleme entstehen häufig als Fehlerkette. Ein Theme lädt ein großes Hero-Bild, der Page Builder erzeugt zusätzliche Container, ein Slider-Plugin bindet JavaScript ein und ein externes Consent- oder Tracking-Skript beansprucht den Hauptthread. Ein Cache-Plugin kann Symptome abmildern, beseitigt diese Architektur aber nicht.

Prüfe zuerst den Umfang des Problems. Betrifft es die komplette Installation, vergleiche Hosting-Antwortzeiten, globale Theme-Ressourcen, Header, Footer, Fonts, Consent-Lösung und siteweit aktive Plugins. Betrifft es nur einen Seitentyp, untersuche dessen Template, Abfragen, dynamische Elemente und Builder-Widgets. Bei einer einzelnen URL stehen Medien, Einbettungen, Inhaltsmodule und individuelle Skripte im Vordergrund.

Ordne mögliche Ursachen anschließend von unten nach oben: Hosting und Serverkonfiguration, WordPress-Kern und Datenbank, Theme, Page Builder, Plugins, Medien, Drittanbieter-Skripte und redaktioneller Inhalt. Nutze Browser-Entwicklerwerkzeuge, ein Performance-Profil und eine Staging-Kopie, um Abhängigkeiten kontrolliert zu testen.

Bei Page Buildern solltest du besonders auf verschachteltes Markup, doppelte Überschriften, global geladene Widgets, große DOM-Strukturen und Ressourcen achten, die auf der jeweiligen Seite nicht benötigt werden. Der Beitrag Page-Builder-Seiten für SEO optimieren zeigt passende Ansatzpunkte.

Plugins bleiben nützliche Werkzeuge, sollten aber jeweils einen klaren Zweck, aktive Pflege und einen messbaren Vorteil haben. Ergänzende Hinweise zur kontrollierten Auswahl liefert der Beitrag über WordPress-Optimierungsplugins.

Suchintention, Navigation und Conversion gemeinsam prüfen

Technische Optimierung hilft wenig, wenn eine Seite die falsche Aufgabe erfüllt. Notiere für jede wichtige URL die primäre Suchintention, die zentrale Nutzerfrage und den gewünschten nächsten Schritt. Vergleiche diese drei Punkte mit dem tatsächlich sichtbaren Inhalt.

Eine Leistungsseite sollte beispielsweise nicht erst nach einer langen Unternehmensdarstellung erklären, was angeboten wird, für wen die Leistung geeignet ist und wie der Ablauf aussieht. Prüfe die Informationsarchitektur aus Sicht eines neuen Besuchers: Sind Menüpunkte eindeutig benannt? Ist die aktuelle Position erkennbar? Führen interne Links zu sinnvollen Vertiefungen?

Mobil musst du nicht nur die Darstellung verkleinern, sondern die Hauptaufgabe neu bewerten. Teste Navigation, Akkordeons, Tabellen, Cookie-Banner, Sticky-Elemente und Formulare auf einem echten Gerät. Navigiere außerdem per Tastatur, prüfe einen sichtbaren Fokus, ausreichende Kontraste und verständliche Fehlerzusammenfassungen nach dem Absenden eines Formulars.

Bewerte Conversion-Elemente nicht isoliert nach ihrer Klickrate. Ein auffälliger Button kann mehr Klicks, aber zugleich unpassende Anfragen erzeugen. Messe deshalb möglichst den ganzen Weg: Einstieg, relevante Inhaltsnutzung, Beginn des Formulars, erfolgreicher Abschluss und – soweit datenschutzkonform erfassbar – die Qualität des Kontakts.

Weitere Grundlagen für Nutzerführung und Informationsarchitektur liefert der Leitfaden Website-Benutzererfahrung verbessern.

Maßnahmen nach Wirkung, Evidenz und Risiko priorisieren

Eine gute Audit-Liste unterscheidet Blocker, strukturelle Hebel und lokale Verbesserungen. Ein versehentlich nicht indexierter wichtiger Seitentyp ist ein Blocker. Ein überladenes Template, das sämtliche Leistungsseiten betrifft, ist ein struktureller Hebel. Die Komprimierung eines einzelnen Bildes auf einer selten besuchten Unterseite ist eine lokale Verbesserung.

Für eine nachvollziehbare Reihenfolge kannst du dieses Modell verwenden: Priorität = Reichweite der betroffenen URLs × Nutzer- und Geschäftsauswirkung × Evidenzstärke ÷ Umsetzungsaufwand und Änderungsrisiko. Bewerte jeden Faktor einheitlich als niedrig, mittel oder hoch und begründe die Einschätzung kurz.

Ein ausgefülltes Beispiel macht die Skala greifbar: Ein blockierendes Hero-Skript auf allen Leistungsseiten kann bei Reichweite, Auswirkung und Evidenz jeweils hoch liegen. Sind Aufwand und Änderungsrisiko mittel, gehört die Maßnahme weit nach oben. Ein einzelnes Bild auf einer selten besuchten Unterseite kann dagegen trotz einfacher Umsetzung niedriger priorisiert werden.

Die Evidenzstärke verhindert, dass Vermutungen zu Großprojekten werden. Hoch ist sie bei reproduzierbaren Formularfehlern oder eindeutig blockierten URLs. Mittel ist sie bei konsistenten Geräte- und Seitentypmustern. Niedrig bleibt sie, wenn nur ein einzelner Labortest oder eine allgemeine Plugin-Empfehlung vorliegt.

Berücksichtige außerdem Wartbarkeit. Ein zusätzliches Plugin kann kurzfristig weniger Aufwand bedeuten, erhöht aber möglicherweise Abhängigkeiten und Testbedarf. Eine Template-Anpassung kostet anfangs mehr, kann dafür Hunderte URLs verbessern.

Dokumentiere solche Zielkonflikte, statt Ladezeit, Gestaltung, Funktionsumfang und Conversion getrennt zu optimieren. So bleibt nachvollziehbar, warum eine Maßnahme umgesetzt, verschoben oder verworfen wurde.

Änderungen in Staging testen und sicher ausrollen

Änderungen an Theme, Templates, Plugins, Caching, JavaScript, Formularen oder strukturierten Daten gehören zunächst in eine Staging-Umgebung. Sie sollte die produktive Installation ausreichend abbilden, aber weder indexierbar sein noch echte Formulare, Tracking- oder Zahlungsprozesse unbeabsichtigt auslösen.

Prüfe vor dem Test, ob Datenstand, PHP-Version, aktive Erweiterungen und Konfiguration vergleichbar sind. Berücksichtige bewusst mögliche Abweichungen bei CDN, Caching, externen Diensten und serverseitiger Konfiguration, denn sie können Ergebnisse zwischen Staging und Live-System verändern.

Lege für jede Änderung einen Ausgangswert fest. Erstelle Screenshots, notiere betroffene URLs und erfasse relevante Performance- sowie Conversion-Metriken. Teste nicht nur die veränderte Komponente, sondern auch angrenzende Funktionen wie Navigation, Suche, Consent, Formulare und responsive Darstellung.

Rolle größere Maßnahmen möglichst in überschaubaren Paketen aus. Wenn du gleichzeitig Theme, Hosting, Navigation und Inhalte änderst, kannst du Wirkungen schwer zuordnen und Fehler schlechter zurücknehmen. Eine Ausnahme sind akute Blocker, bei denen eine sofortige Korrektur wichtiger ist als ein sauberer Einzelvergleich.

Erfolg nach der Umsetzung gemeinsam messen

Ein Audit endet nicht mit einer abgearbeiteten Aufgabenliste. Er endet mit der Prüfung, ob sich Suchleistung, Nutzung und Geschäftsergebnis tatsächlich verbessert haben. Lege pro Änderung und Seitentyp ein Vorher-nachher-Messblatt an.

Vergleiche möglichst gleiche URL-Gruppen, Geräte und Suchanfragen in gleich langen Zeitfenstern. Halte fest, ob Tracking, Consent, Kampagnen, Inhalte oder technische Rahmenbedingungen verändert wurden. Bei wenigen Conversions sind einzelne Ausschläge kein belastbarer Beweis; verlängere den Beobachtungszeitraum und bewerte die Entwicklung zusammen mit qualitativen Aufgabentests.

Beobachte in der Search Console Klicks, Impressionen, CTR, Positionen und betroffene Suchanfragen. Prüfe in der Webanalyse abgeschlossene Ziele und die einzelnen Schritte im Conversion-Pfad. Ergänze technische Werte um einfache Aufgabentests: Finden Nutzer die richtige Leistung, können sie das mobile Menü bedienen und verstehen sie Fehlermeldungen?

Wenn eine Kennzahl besser und eine andere schlechter wird, kehre zur ursprünglichen Hypothese zurück. Ein besserer LCP bei sinkenden Formularabschlüssen ist kein eindeutiger Erfolg. Ziel ist nicht die Maximierung jeder Einzelmetrik, sondern eine bessere Website für relevante Suchende und dein Geschäft.