Technisches SEO für WordPress: Die Checkliste für Indexierung, URL-Signale und Sitemaps

Fachlich bedeutet das: Canonical-Tag, noindex-Meta, Redirects und Sitemap-Index müssen dieselbe Zielversion stärken, und die mobile sowie gerenderte HTML-Version muss vollständig sein. Ohne feste Prüfreihenfolge optimierst Du sonst schnell am Symptom statt an der Ursache.

Wenn Du erst Orientierung suchst, merke Dir drei Fragen: Welche URLs sollen in Google landen? Welche Signale stützen diese URLs? Und was blockiert Crawling oder Indexierung? Genau an diesen Punkten scheitern WordPress-Seiten am häufigsten.

Typische Fehler sind noindex auf der Live-Seite, offene Staging-Umgebungen, Attachment Pages oder Filter-URLs im Index und falsche Canonical-Tags. Deshalb ist dieser Leitfaden als Audit aufgebaut: erst Indexierung und Ziel-URLs, dann Signal-Konsistenz, danach Sitemaps, Rendering, JavaScript und Core Web Vitals.

Der Audit-Workflow: Technisches SEO in WordPress in 9 Schritten

Wenn Du konkret prüfen willst, geh die 9 Schritte von oben nach unten durch. Die ersten vier Schritte klären die Basis. Alles danach schärft Signale, Sitemaps und technische Auslieferung.

Wenn Du Anfänger bist, reichen für den ersten Durchgang drei Dinge: das WordPress-Backend, ein Browser und die Google Search Console. Crawl-Tools wie Screaming Frog oder Sitebulb helfen später, sind für den Einstieg aber nicht zwingend nötig.

Schritt	Was Du prüfst	Tool	Priorität	Typischer Fix
1	Einstellungen > Lesen, globale Sichtbarkeit, Staging-Domains	WordPress-Backend, Browser, Seitenquelltext	kritisch	Live-Seite entsperren, Staging per Passwort schützen
2	Indexierungsstatus wichtiger URLs	Google Search Console, URL-Prüfung	kritisch	noindex, falsches Canonical, Soft-404-Signale beheben
3	Statuscodes, Redirects, Host-Varianten	Screaming Frog, Sitebulb, Header-Checker, DevTools	kritisch	nur eine kanonische 200-Version zulassen
4	URL-Typen mit und ohne Suchwert	Crawl, Sitemap, CMS-Struktur	kritisch	Archive, Suche, Filter, Attachment Pages sauber steuern
5	interne Links und Orphan Pages	Crawl-Tool, manuelle Navigation	hoch	Navigation, Hubs, Breadcrumbs, Kontextlinks ergänzen
6	Canonical-Tag, noindex-Meta, robots.txt, Redirects	Crawl-Tool, Quelltext, HTTP-Header	hoch	widersprüchliche Signale entfernen
7	XML Sitemap und Sitemap-Index	Sitemap-Aufruf, Search Console	hoch	nur indexierbare kanonische URLs ausliefern
8	Rendering, mobile HTML-Version, JavaScript, Consent, Lazy Loading	URL-Prüfung, Chrome DevTools, PageSpeed Insights	hoch	kritische Inhalte serverseitig oder sofort im DOM ausliefern
9	strukturierte Daten, Core Web Vitals, Re-Check nach Deployments	Rich Results Test, PageSpeed Insights, Search Console	mittel	Markup bereinigen, Performance-Bremsen gezielt beheben

Nutze die Tabelle zuerst als Überblick. Für den Start reichen drei schnelle Checks: Ist die Website indexierbar? Sind 3 bis 5 wichtige URLs in der Search Console sauber? Hat jede wichtige Zielseite genau eine eindeutige 200-Version?

Danach ordnest Du die Funde in drei Stufen:

Kritisch: Alles, was eine URL komplett von Indexierung oder Crawling abschneidet. Beispiele: globale Suchmaschinen-Sperre, 5xx, falscher Redirect, noindex auf Zielseiten, Staging im Index.

Hoch: Alles, was Google widersprüchliche oder schwache Signale liefert. Beispiele: falsche Canonicals, Orphan Pages, irrelevante URLs in der Sitemap, doppelte Host-Versionen.

Mittel: Alles, was Sichtbarkeit schrittweise schwächt, aber nicht sofort blockiert. Beispiele: langsames Rendering, zu späte Links nach Consent, fehlerhaftes Schema, LCP-Probleme.

Wenn Du Dir nur eine Reihenfolge merken willst, dann diese: erst Blocker, dann Signal-Chaos, dann Performance. Solange Zielseiten auf noindex stehen oder falsch weiterleiten, optimierst Du sonst am falschen Ende.

Welche WordPress-URLs sollten in Google landen – und welche nicht?

In Google sollten nur die WordPress-URLs landen, die Du bewusst als Zielseiten haben willst. Wenn eine Seite nur automatisch entsteht, nur sortiert, filtert oder kaum eigenen Inhalt hat, ist sie meistens keine gute Google-Zielseite.

Für den Einstieg helfen drei einfache Fragen: Würdest Du diese URL aktiv intern verlinken? Hat sie einen eigenen Nutzen für Suchende? Und soll genau diese URL in Google erscheinen oder nur eine andere Hauptversion?

Problem: WordPress erzeugt viele URL-Typen automatisch. Bleibt davon zu viel indexierbar, füllst Du den Index mit schwachen Seiten und verwässerst Relevanzsignale.

Signal: Ein Warnsignal sind wiederkehrende Muster in der Search Console: Tags, Attachment Pages, Suchseiten, Filter-URLs oder dünne Archive. Spätestens dann enthält oft auch die Sitemap URLs, die nie als echte Zielseiten gedacht waren.

Prüfung mit Tool:
Wenn Du gerade ohne Profi-Tools arbeitest, starte mit der Sitemap, den WordPress-Seitentypen im Backend und dem Indexierungsbericht in der Search Console. Mit Screaming Frog oder Sitebulb kannst Du diese Muster später zusätzlich crawlen und sauber gruppieren. Entscheidend ist, nicht in Einzel-URLs, sondern in Seitentypen und Mustern zu denken.

Empfehlung: Lege vor jeder Optimierung eine URL-Matrix fest. Das kann am Anfang eine einfache Liste sein: Seitentyp, indexieren ja oder nein, in Sitemap ja oder nein, und welcher Standard gelten soll, etwa noindex, Weiterleitung oder normale Zielseite. So verhinderst Du, dass Theme, Builder oder SEO-Plugin später widersprüchliche Standards erzeugen.

Für die wichtigsten Sonderfälle gilt:

Attachment Pages

• Standardfall: nicht indexieren
• Lösung: auf Parent-Post oder auf die Datei weiterleiten
• Risiko: sehr dünne Seiten mit schwachem Nutzwert und unnötigem Duplicate-Risiko

Taxonomie-Archive

• Kategorien können stark sein, wenn sie als Hubs mit Intro, klarer interner Verlinkung und eigener Suchintention gebaut sind
• Tags sind oft nur alternative Sortierhilfen und deshalb selten gute Zielseiten

Author- und Date-Archive

• Author-Archive lohnen sich nur, wenn mehrere Autoren sichtbar Expertise aufbauen
• Date-Archive erzeugen meist keine eigenständige Suchintention

Filter- und Facetten-URLs

• Wenn dynamische Filterkombinationen nur Sortierung oder Produktmengen ändern, gehören sie nicht in den Index
• Bei WooCommerce sind das oft Attribut-, Preis-, Größen- oder Sortier-Parameter wie ?filter_color=blau, ?min_price=50 oder ?orderby=price
• Wenn ein Filter echte Nachfrage hat, baue lieber eine statische Kategorie- oder Landingpage statt tausende Parameter-URLs zu indexieren

Für Attachment Pages brauchst Du meist keinen Entwickler. In gängigen SEO-Plugins wie Yoast SEO oder Rank Math findest Du dafür in der Regel eine Medien- oder Anhangs-Einstellung. Wenn Dein Setup das nicht sauber abdeckt, leitest Du die URLs per Redirect-Plugin oder serverseitig auf den Parent-Post oder die Datei weiter.

Auch Taxonomie-Archive steuerst Du am besten pro Seitentyp. Entscheidend ist nicht der Plugin-Name, sondern dass noindex, Sitemap und interne Links dieselbe Entscheidung abbilden.

Häufiger Fehler: Alles, was WordPress oder ein SEO-Plugin automatisch erzeugt, bleibt indexierbar, weil niemand vorher entschieden hat, welche Seitentypen überhaupt Zielseiten sein sollen.

In WordPress gewinnt nicht die Website mit den meisten indexierbaren URLs, sondern die mit den sauber ausgewählten URL-Typen.

Indexierung scheitert meist an Signalen, Statuscodes oder Rendering, nicht am fehlenden Willen im CMS.

So prüfst Du Indexierung, Rendering und Statuscodes Schritt für Schritt

1. Einstellungen > Lesen und Staging-Umgebungen prüfen

• Öffne in WordPress Einstellungen > Lesen
• Prüfe, ob Suchmaschinen davon abhalten, diese Website zu indexieren aktiv ist
• Kontrolliere zusätzlich im Seitenquelltext, ob wichtige Seiten ein noindex-Meta ausgeben
• Suche nach offenen Staging-Domains wie staging.domain.de, dev.domain.de oder test.domain.de

Empfehlung:

• Die Live-Seite darf nicht global geblockt sein
• Eine Staging-Umgebung sollte per Passwortschutz oder IP-Restriktion abgesichert sein
• robots.txt allein schützt Staging nicht zuverlässig vor Indexierung

Für den schnellen Fix startest Du direkt im Backend unter Einstellungen > Lesen, prüfst dort die globale Sichtbarkeit und kontrollierst zusätzlich im Quelltext einer wichtigen URL, ob doch ein noindex-Meta ausgegeben wird. Staging schützt Du am sichersten im Hostingpanel oder per Passwortschutz, nicht nur per robots.txt.

2. Repräsentative URLs in der URL-Prüfung öffnen

Nimm nicht nur die Startseite. Prüfe pro Seitentyp mindestens:

• einen Beitrag
• eine Seite
• eine Kategorie
• eine Produkt- oder Archivseite
• eine potenzielle Problem-URL wie Tag, Filter oder Attachment Page

Achte in der Search Console URL-Prüfung auf:

• Ist die URL im Google-Index?
• Welche kanonische URL hat Google gewählt?
• Wann wurde die URL zuletzt gecrawlt?
• Gibt es Screenshot- oder Rendering-Hinweise?
• Werden Ressourcen blockiert?

Empfehlung:

• Wenn Google eine andere kanonische URL wählt als Du, ist das meist kein Zufall. Dann prüfen Canonical-Tag, interne Links, Redirects, Sitemap und Template-Ausgabe nicht dieselbe Zielversion.

Wenn Du die Search Console für Dein Projekt erst einrichtest oder Berichte zum ersten Mal systematisch nutzt, lies zuerst meinen Guide Google Search Console einrichten. Für technische Audits ist sie die verlässlichste Kontrollinstanz.

3. Statuscodes und Redirects sauber prüfen

Jede indexierbare Zielseite sollte genau eine öffentliche 200-Version haben. Alle Varianten müssen per 301 auf diese Version führen.

Statuscode	Praktische Bedeutung	SEO-Folge	Was Du in WordPress tun solltest
200	Seite ist erreichbar	nur diese Version sollte Zielseite sein	selbstreferenzielles Canonical, interne Links auf genau diese URL
301	dauerhaft umgezogen	Signal wird an neue URL weitergegeben	bei Permalink-Änderungen und Relaunches einsetzen, interne Links aktualisieren
302	temporär umgezogen	uneindeutig bei dauerhaften Änderungen	nicht für permanente URL-Wechsel verwenden
404	Seite nicht gefunden	okay, wenn es keinen Ersatz gibt	nur dann einsetzen, wenn die URL wirklich weg ist
410	Seite bewusst entfernt	schnellere Entfernung aus dem Index möglich	für dauerhaft gelöschte Inhalte ohne Ersatz sinnvoll
5xx / 503	Serverproblem oder Wartung	Crawling und Indexierung leiden sofort	Hosting, Caching, Plugin-Fehler, PHP-Fehler oder Wartungsmodus prüfen

Empfehlung:

• 301 für dauerhafte URL-Wechsel
• 302 nur für wirklich temporäre Fälle
• 404 oder 410, wenn kein sinnvoller Ersatz existiert
• 5xx sofort priorisieren, weil sie Crawling und Vertrauen direkt beschädigen

4. Rendering, mobile HTML-Version und JavaScript prüfen

Google verarbeitet die mobile Version. Wenn Inhalte, Links, strukturierte Daten oder Hauptnavigation mobil fehlen, ist das ein echter SEO-Fehler.

Prüfe mit URL-Prüfung, Chrome DevTools und PageSpeed Insights:

• Ist der Hauptinhalt im gerenderten HTML vorhanden?
• Sind interne Links ohne Nutzerinteraktion im DOM sichtbar?
• Wird die Navigation erst nach Consent oder JavaScript-Klick erzeugt?
• Werden Tabs, Akkordeons oder Produktinfos erst nach Interaktion geladen?
• Wird das LCP-Bild fälschlich lazy-loaded?

Empfehlung:

• Kritische Inhalte und Links sollten serverseitig oder sofort im DOM vorhanden sein
• Consent-Tools dürfen keine wichtigen internen Links oder Inhalte zurückhalten
• Das LCP-Bild sollte nicht lazy-loaded werden
• Unendliches Scrollen braucht eine crawlbare Paginierung

5. Host- und URL-Konsolidierung prüfen

Eine Zielseite darf nicht gleichzeitig unter mehreren Varianten erreichbar sein.

Prüfe diese Varianten systematisch:

• http und https
• www und non-www
• mit und ohne Trailing Slash
• Groß- und Kleinschreibung
• Umlaute, Umschriften und Encodings wie /über-uns/, /ueber-uns/ oder kodierte Varianten

Empfehlung:

• Wähle genau eine öffentliche Zielversion
• Leite alle Alternativen per 301 um
• Nutze in internen Links, Canonicals und Sitemaps nur die Zielversion
• Ändere bestehende URLs mit Umlauten nicht ohne Grund; konsolidiere nur echte Doppelvarianten

Wenn Du nicht nur einzelne URLs, sondern ganze Verzeichnisse, Permalinks oder die Domain änderst, reicht es meist nicht, nur ein paar Redirects zu setzen. Für genau diesen Fall findest Du hier meine Schritt-für-Schritt-Anleitung zum WordPress-Umzug mit Domainwechsel.

Bevor Du Canonicals, Sitemaps oder Performance bewertest, muss eine URL überhaupt als eindeutige, vollständig gerenderte 200-Zielseite existieren. Sonst baust Du Signale auf ein unsauberes Fundament.

Canonical, noindex oder robots.txt: Die richtige Entscheidung je URL-Typ

Für den Einstieg hilft eine einfache Merkhilfe: noindex bedeutet, dass eine Seite erreichbar bleibt, aber nicht in Google erscheinen soll. Canonical bedeutet, dass mehrere ähnliche URLs auf eine Hauptversion verweisen. robots.txt steuert vor allem das Crawling und ist keine sichere Methode, um eine HTML-Seite aus dem Index zu entfernen.

Entscheidend ist nicht, möglichst viele Signale zu setzen, sondern pro Ziel das richtige. Wenn eine URL nicht ranken soll, aber erreichbar bleiben muss, ist noindex richtig. Wenn mehrere Varianten denselben Inhalt zeigen, ist Canonical richtig. Wenn eine URL dauerhaft ersetzt wurde, ist 301 richtig.

Problem: Viele WordPress-Seiten senden gleichzeitig mehrere widersprüchliche Signale.

Signal: Eine URL steht in der Sitemap, trägt noindex, verweist per Canonical auf eine andere Variante oder ist zusätzlich in robots.txt blockiert.

Prüfung mit Tool:
Wenn Du ohne Crawl-Tool startest, prüfe zuerst den Seitenquelltext einer wichtigen URL, die URL-Prüfung in der Search Console und den direkten Aufruf der Sitemap. Mit einem Crawl-Tool kannst Du meta robots, Canonical-Tag, Statuscodes und Redirect-Ketten danach gesammelt prüfen. Vergleiche diese Daten immer mit interner Verlinkung und XML Sitemap.

Ziel	Richtiges Signal	Wann einsetzen?	Nicht so	Typischer WordPress-Fall
URL soll ranken	200, indexierbar, selbstreferenzielles Canonical, in Sitemap	für echte Zielseiten	nicht zusätzlich noindex setzen	Beitrag, Seite, starke Kategorie
URL soll erreichbar bleiben, aber nicht ranken	noindex	wenn Seite nützlich, aber keine Zielseite ist	nicht zusätzlich in Sitemap lassen	interne Suche, dünne Archive
Mehrere Varianten zeigen denselben Inhalt	Canonical auf Zielversion	bei Duplikaten oder nahen Varianten	nicht als Ersatz für Redirects bei alten Permalinks nutzen	Sortierung, Druckversion, Tracking-Parameter
URL wurde dauerhaft ersetzt	301 auf neue Zielseite	bei Relaunch, Permalink-Wechsel, Merge	nicht 302 für dauerhafte Änderungen	alte Beitrags-URL auf neue URL
Bereich soll gar nicht öffentlich sein	Zugriffsschutz / Passwort	bei Staging, internen Tools	nie nur über robots.txt absichern	Staging-Subdomain
Unwichtige URL-Muster sollen seltener gecrawlt werden	robots.txt sehr gezielt	nur wenn Indexierung dort nicht mehr relevant ist	nicht zur Deindexierung einzelner HTML-Seiten missbrauchen	bestimmte Parameter-Muster

Für typische WordPress-Fälle gilt:

Tag-Archive ohne Suchwert

• noindex, nicht in Sitemap
• alternativ komplett deaktivieren

Attachment Pages

• nicht indexieren
• besser auf Parent-Post oder Datei umleiten

Sortier- und Tracking-Parameter

• nicht indexieren
• Canonical auf die saubere Basis-URL

Filter- und Facetten-URLs

• nicht pauschal mit Canonical „wegoptimieren“, wenn sie inhaltlich deutlich abweichen
• Standardfall: nicht indexieren und nicht in Sitemap
• bei WooCommerce gilt das oft für Preis-, Farb-, Größen- oder Sortier-Parameter
• wenn echte Nachfrage besteht: statische Landingpage bauen statt dynamische Kombinations-URL indexieren

Pagination

• nicht in Sitemap aufnehmen
• nicht pauschal auf Seite 1 canonicalisieren
• crawlbar lassen, wenn Google weitere Elemente darüber finden muss

Nutze pro Ziel genau das Signal, das zur Aufgabe passt. Canonical, noindex, Redirects und robots.txt ergänzen sich nur dann sinnvoll, wenn ihre Funktion klar getrennt ist.

Sitemaps in WordPress richtig einsetzen

Die XML Sitemap ist nicht die Liste aller Seiten Deiner Website. Sie ist die kuratierte Liste der URLs, die Google als echte Zielseiten finden und ernst nehmen soll.

Eine gute XML Sitemap enthält deshalb nur indexierbare, kanonische 200-URLs. Alles andere verschmutzt das Signal.

Problem: Viele WordPress-Sitemaps listen automatisch Archive, Parameter, Umleitungen oder URLs ohne Suchwert.

Signal: In der Search Console tauchen Meldungen wie Seite mit Weiterleitung, Alternative Seite mit richtigem Canonical oder durch noindex ausgeschlossen für eingereichte URLs auf.

Prüfung mit Tool:
Starte einfach im Browser mit dem direkten Aufruf des Sitemap-Index. Öffne die einzelnen Sitemaps und prüfe stichprobenartig, ob dort wirklich nur Seiten stehen, die in Google landen sollen. Im zweiten Schritt vergleichst Du das mit dem Search-Console-Sitemaps-Bericht und, wenn vorhanden, mit Crawl-Daten.

Empfehlung:

In die Sitemap gehören:

• Zielseiten mit Status 200
• indexierbare Beiträge, Seiten, starke Kategorien, Produkte oder sinnvolle Custom Post Types
• nur die kanonische Host- und URL-Version

Nicht in die Sitemap gehören:

• noindex-Seiten
• Redirect-URLs
• 404– oder 410-URLs
• interne Suchseiten
• Tag-Archive ohne Suchwert
• Attachment Pages
• Filter-, Facetten- und Sortier-URLs
• paginierte URLs als Zielseiten

Wenn ein Seitentyp nicht indexiert werden soll, entferne ihn aus der Sitemap. Die Sitemap darf nicht gegen Deine Indexierungslogik arbeiten.

Typische WordPress-SEO-Fehler durch Plugins, Themes und Builder

Bis hierhin hast Du vor allem geprüft, ob Google saubere Signale bekommt. Dieser Abschnitt ist der Fortgeschrittenen-Block des Audits: Wenn Indexierung, Ziel-URLs, Signale und Sitemap noch nicht sauber sind, geh zuerst dorthin zurück.

In WordPress sitzt die eigentliche Ursache oft eine Ebene tiefer: im Theme, im Builder, im SEO-Plugin oder direkt in der Template-Ausgabe. Genau dort entstehen doppelte Canonicals, leere Archive, verspätet geladene Inhalte, fehlerhafte Schema-Ausgabe und schwache interne Links.

Für diesen Abschnitt arbeitest Du deshalb eher mit Crawl-Daten, Seitenquelltext, gerendertem HTML, Rich Results Test und PageSpeed Insights zusammen. Er ist nicht für den allerersten Durchgang gedacht, aber wichtig, wenn die Basics sauber sind und Probleme trotzdem bleiben.

Schwache interne Verlinkung

Wichtige Seiten brauchen stabile Crawlpfade. Sie dürfen nicht nur über Suche, Filter oder einzelne Blogbeiträge erreichbar sein.

Prüfung

• Inlinks und Klicktiefe im Crawl-Tool prüfen
• Navigation, Breadcrumbs, Kategorien, Related Posts und Hub-Seiten kontrollieren
• Orphan Pages identifizieren

Empfehlung

• Jede wichtige URL sollte mindestens über Navigation, Themenhub oder Kontextlinks erreichbar sein
• Wichtige Kategorien und Kernseiten nicht tiefer als nötig vergraben
• Interne Links auf kanonische Ziel-URLs setzen, nicht auf Redirects oder Parameter

SEO-Plugin-Konflikte

Relevant wird dieser Punkt vor allem dann, wenn mehrere SEO-Funktionen parallel aktiv sind. Dann entstehen doppelte oder widersprüchliche Signale.

Prüfung

• Seitenquelltext auf doppelte canonical, meta robots und Schema-Markup-Blöcke prüfen
• Plugins wie Yoast, Rank Math, AIOSEO oder Theme-eigene SEO-Funktionen nicht parallel dieselben Felder ausgeben lassen

Empfehlung

• Nur eine Quelle für Canonicals, meta robots und zentrale Schema-Ausgabe
• Nach Plugin-Wechsel alle Templates neu prüfen

Themes, Builder und PHP-Templating

Viele SEO-Fehler sitzen in der technischen Vorlage einer Seite, nicht im Artikeltext. Mit PHP-Templating ist hier gemeint, wie Theme oder Builder Titel, Archive, Canonicals und andere Elemente pro Seitentyp ausgeben.

Prüfung

• Werden Titel, H1, Canonical, Pagination, Breadcrumbs und strukturierte Daten pro Template korrekt ausgegeben?
• Erzeugt das PHP-Templating leere oder dünne Archivseiten?
• Gibt es Custom Post Types oder Taxonomien, die indexierbar sind, aber keinen echten Suchwert haben?

Empfehlung

• Template-Ausgabe pro Seitentyp prüfen: Beiträge, Seiten, Kategorien, Produkte, CPTs, Archive
• Leere Archive nicht indexieren
• Unnötige Seitentypen deaktivieren oder noindex setzen

Consent-Tools, Lazy Loading und JavaScript

Was im Browser sichtbar ist, wird nicht automatisch suchmaschinenfreundlich ausgeliefert. Kritisch wird es, wenn wichtige Links oder Inhalte erst nach Zustimmung, Klick oder JavaScript-Nachladen erscheinen.

Prüfung

• Erscheinen interne Links, Menüs oder Teaser erst nach Cookie-Zustimmung?
• Werden Tabs, Akkordeons, FAQ-Module oder Produktvarianten erst nach Interaktion geladen?
• Wird das LCP-Bild lazy-loaded?
• Haben Facetten-Filter in WooCommerce crawlbare Links oder erzeugen sie nur JavaScript-Zustände?

Empfehlung

• Kritische Links und Hauptinhalte nicht hinter Consent oder Interaktion verstecken
• Facetten-Filter technisch sauber steuern und nur gezielt indexierbare Landingpages bauen
• Bei Infinite Scroll immer eine crawlbare Paginierung vorhalten

Strukturierte Daten

Strukturierte Daten sind Zusatzinformationen für Suchmaschinen. Sie helfen nur, wenn sie zur sichtbaren Seite passen und sauber ausgegeben werden. Sie garantieren aber keine Rich Results.

Prüfung

• Rich Results Test und Quelltext prüfen
• Werden FAQ, Product, Article, Organization oder Breadcrumb korrekt und nur einmal ausgegeben?
• Sind ausgezeichnete Inhalte wirklich sichtbar?

Empfehlung

• Nur passende Markup-Typen nutzen
• Keine unsichtbaren Inhalte auszeichnen
• Schema-Ausgabe nicht parallel über Plugin, Theme und Custom Code duplizieren

Mobile First und Core Web Vitals

Core Web Vitals sind nicht der erste Prüfpunkt, aber sie werden relevant, wenn Indexierung und Signale sauber sind. Gemeint sind vor allem Ladezeit des Hauptinhalts, Reaktionsfähigkeit und Layout-Stabilität.

Prüfung

• PageSpeed Insights und reale Gerätetests
• LCP, INP, CLS
• große Hero-Bilder, blockierende Skripte, Webfonts, Slider, Chat-Widgets, Builder-Skripte

Empfehlung

• LCP-Element priorisieren
• unnötige JavaScript-Pakete entfernen
• Layout-Sprünge reduzieren
• Scripts und Drittanbieter nur dort laden, wo sie gebraucht werden

Wenn diese Basis sauber ist und Du dann an Ladezeit, Interaktivität oder Layout-Stabilität arbeiten willst, geh tiefer in meine Leitfäden Core Web Vitals in WordPress optimieren und LCP in WordPress verbessern. Dort geht es um die operative Behebung, nicht mehr um die Audit-Reihenfolge.

Spätestens ab hier zeigt Dir die Search Console, welche dieser Muster Google an echten URLs und Seitentypen tatsächlich sieht.

Search-Console-Meldungen in WordPress richtig deuten und beheben

Die Search Console zeigt Dir nicht nur einzelne URLs, sondern was Google mit Deinen Seitentypen tatsächlich macht. Für Einsteiger ist sie deshalb kein Spezialtool, sondern nach dem WordPress-Backend die wichtigste Kontrollstelle im Audit. Wenn Du ihre Berichte noch nicht sauber nutzt, starte mit meinem Guide Google Search Console einrichten und arbeite danach meldungsbasiert weiter.

Starte jede Meldung gleich: Öffne 2 bis 5 Beispiele, prüfe, ob es derselbe Seitentyp ist, und leite daraus erst die eigentliche Ursache ab. So vermeidest Du, an Einzelfällen herumzuoptimieren, obwohl das Problem im Template, im Archivtyp oder in der internen Verlinkung sitzt.

Meldung	Was sie meist bedeutet	Typische WordPress-Ursache	Was Du tun solltest
Gecrawlt – zurzeit nicht indexiert	Google kennt die URL, sieht aber keinen ausreichenden Grund zur Indexierung	dünne Archive, Orphan Pages, schwache interne Links, sehr ähnliche Templates	Suchwert prüfen, interne Links stärken, Duplikate und dünne Seitentypen reduzieren
Gefunden – zurzeit nicht indexiert	Google kennt die URL, priorisiert das Crawling aber nicht	zu viele schwache URLs, aufgeblähte Sitemap, Server langsam	URL-Rauschen reduzieren, Sitemap säubern, interne Links verbessern, Server prüfen
Alternative Seite mit richtigem Canonical	Google akzeptiert eine andere URL als Hauptversion	Parameter, Slash-Varianten, Filterseiten, doppelte Archive	wenn ungewollt: Canonical, interne Links, Redirects und Sitemap bereinigen
Soft 404	Seite liefert technisch 200, wirkt inhaltlich aber wie „nichts da“	leere Kategorien, Suchseiten, gelöschte Produkte, schwache Attachment Pages	Inhalt ausbauen oder sauber 404/410/noindex verwenden
Durch „noindex“-Tag ausgeschlossen	Google sieht ein Deindexierungs-Signal	gewolltes oder versehentlich gesetztes noindex	prüfen, ob die URL wirklich keine Zielseite sein soll

Wirklich nützlich werden Search-Console-Meldungen erst dann, wenn Du sie nach URL-Mustern und Seitentypen auswertest statt nur einzelne URLs wegzuklicken.

Wenn Du priorisieren musst, behebe zuerst alles, was wichtige Zielseiten aus der Indexierung drückt oder technisch unbrauchbar macht. Danach erst löst Du alles, was Signale nur verwässert.

Checkliste: In welcher Reihenfolge Du technische SEO-Probleme in WordPress behebst

Nutze die folgenden Punkte als Kurz-Checkliste. Wenn Du Anfänger bist, konzentriere Dich im ersten Durchgang vor allem auf die Punkte 1 bis 4 und springe nicht vorzeitig zu Performance-Themen.

1. Live-Seite und Staging prüfen

• Einstellungen > Lesen
• globale noindex-Signale
• öffentliche Staging-Hosts

2. Repräsentative URLs technisch prüfen

• Search Console URL-Prüfung
• Status 200
• prüfen, ob Google dieselbe kanonische URL wählt wie Du

3. Host- und URL-Konsistenz herstellen

• https
• www oder non-www
• Slash, Groß-/Kleinschreibung, Umlaut-Varianten

4. URL-Typen entscheiden

• Beiträge, Seiten, Kategorien, Produkte
• Tags, Author-Archive, Date-Archive
• interne Suche, Attachment Pages, Parameter, Facetten-Filter

5. Interne Verlinkung und Orphan Pages beheben

• Navigation
• Hubs
• Breadcrumbs
• Kontextlinks
• keine wichtigen URLs nur über Suche oder Filter erreichbar lassen

6. Signale bereinigen

• Canonical-Tag
• noindex-Meta
• robots.txt
• 301/302
• alle diese Signale müssen dieselbe Zielversion stärken

7. XML Sitemap säubern

• nur kanonische 200-URLs
• keine Redirects, keine noindex-Seiten, keine Filter-URLs

8. Rendering, mobile HTML-Version und JavaScript prüfen

• Menüs
• Tabs
• FAQ-Module
• Product-Elemente
• Consent-Tools
• Lazy Loading

9. Strukturierte Daten und Core Web Vitals optimieren

• Schema nur einmal und passend
• LCP, INP, CLS gezielt verbessern

10. Nach jedem größeren Eingriff neu prüfen

• Theme-Wechsel
• Plugin-Wechsel
• Builder-Update
• Permalink-Anpassung
• Relaunch
• Domainwechsel

Technisches SEO wird in WordPress nicht besser, weil Du mehr Optionen anfasst, sondern weil jede Ziel-URL sauber indexierbar, intern gestützt und widerspruchsfrei signalisiert ist. Prüfe diese Reihenfolge nach jedem größeren Eingriff erneut.

Fazit

Wenn eine WordPress-Seite nicht rankt, prüfe nicht zuerst Ladezeit oder Plugin-Menüs. Prüfe zuerst, ob die richtigen URL-Typen indexierbar sind, ob Zielseiten genau eine eindeutige 200-Version haben, ob Canonical-Tag, noindex-Meta, Redirects und Sitemap-Index dieselbe Logik abbilden und ob die mobile, gerenderte HTML-Version vollständig ist.

Technisches SEO für WordPress heißt im Kern, Zielseiten, Signale und Crawlpfade sauber zu steuern. Deshalb folgen im FAQ keine allgemeinen Theoriefragen, sondern typische Grenzfälle aus dem WordPress-Alltag.

FAQ zu technischem SEO in WordPress

Die FAQ zeigt: Die wichtigsten WordPress-SEO-Fragen sind selten Tool-Fragen, sondern Entscheidungsfragen zu URL-Typen, Signalen und technischer Auslieferung. Wenn diese Logik sauber bleibt, wird technisches SEO in WordPress planbarer und deutlich weniger reaktiv.