Sprachen

WordPress-SEO

Ein Leitfaden für technische SEO-Praktiker zu WordPress — zu schädlichen Standardeinstellungen, der tatsächlichen Funktionsweise der Core-Sitemap und Canonicals, der Regel, genau ein SEO-Plugin einzusetzen, und den von WordPress selbst erzeugten Duplicate-Content-Quellen.

Erstveröffentlicht: 27. Juni 2026 · Zuletzt aktualisiert: 20. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

WordPress ist SEO-fähig, aber nicht fertig für SEO. Seit Version 2,9 setzt es selbstreferenzierende Canonicals für Beiträge und seit 5,5 eine native XML-Sitemap ein — seine Standardeinstellungen lassen jedoch auch ?p=123-Permalinks, Anhangseiten, Datums-, Schlagwort- und Autorenarchive, Feeds sowie interne Suchergebnisse indexierbar; außerdem kann eine einzige Option unter Einstellungen → Lesen unbemerkt die gesamte Website blockieren. Entscheidend sind: /%postname%/ vor der Veröffentlichung festlegen, genau ein SEO-Plugin verwenden (Yoast, Rank Math oder AIOSEO — niemals zwei, weil der wp_head-Konflikt doppelte Metadaten erzeugt), dünne Archive mit noindex versehen statt sie zu sperren und nur kanonische, indexierbare URLs in die Sitemap aufnehmen. WordPress 6,4+ deaktiviert Anhangseiten bei neuen Installationen standardmäßig und leitet direkt zur Datei statt zum übergeordneten Beitrag weiter; bestehende Websites behalten sie jedoch und müssen manuell migriert werden. Google hat nie erklärt, WordPress ranke besser oder schlechter als ein anderes CMS — Inhalte und Links entscheiden, nicht die Plattform.

TL;DR — WordPress ist SEO-fähig, aber nicht fertig für SEO. Seit Version 2,9 setzt es selbstreferenzierende Canonicals für einzelne Beiträge und seit 5,5 eine native XML-Sitemap ein. Die Standardeinstellungen lassen jedoch ?p=123-Permalinks, Anhangseiten, Datums-, Schlagwort- und Autorenarchive, Feeds sowie ?s=-Suchseiten indexierbar; außerdem kann die Option unter Einstellungen → Lesen unbemerkt die gesamte Website blockieren. Wirklich wirksam sind: /%postname%/ vor der Veröffentlichung, genau ein SEO-Plugin (der wp_head-Konflikt bei zweien ist real), noindex für dünne Archive statt einer Crawling-Sperre sowie eine Sitemap ausschließlich mit kanonischen, indexierbaren URLs. WordPress 6,4+ deaktiviert Anhangseiten bei neuen Installationen standardmäßig und leitet auf die Datei selbst statt auf den übergeordneten Beitrag weiter; bestehende Websites behalten sie und müssen manuell migriert werden. Google hat nie erklärt, WordPress sei für SEO besser oder schlechter als ein anderes CMS. Evidence for this claim WordPress added core XML sitemaps in 5.5 and attachment-page redirects for new sites in 6.4. Scope: Core version history; existing sites can retain prior attachment behavior. Confidence: high · Verified: WordPress 5.5 XML sitemaps WordPress 6.4 attachment pages

WordPress ist SEO-fähig, aber nicht fertig für SEO

Die ehrliche Einordnung liegt zwischen den beiden Marketingaussagen, die man gewöhnlich hört. WordPress ist nicht in einem umfassenden Sinn „von Haus aus SEO-freundlich“ — aber es ist auch nicht schlecht für SEO. Es bietet eine starke, kontrollierbare Grundlage und lässt zugleich jede Menge indexierbaren Ballast standardmäßig aktiviert. Die eigentliche Aufgabe besteht darin, zu wissen, welche Vorgaben geändert und welche automatisch erzeugten URLs unterdrückt werden müssen.

Um es gleich klarzustellen: Google hat nie erklärt, WordPress ranke besser oder schlechter als ein anderes CMS. In der Google-Dokumentation heißt es: “if you’re using a CMS such as WordPress, Wix, or Blogger, it’s likely that your CMS has already made a sitemap available to search engines” — (Übersetzung) „Wenn Sie ein CMS wie WordPress, Wix oder Blogger verwenden, hat Ihr CMS Suchmaschinen wahrscheinlich bereits eine Sitemap bereitgestellt.“ Die Plattform wird wie jede andere behandelt. Rankings entstehen durch Inhalte und Links, nicht durch das Logo in Ihrer Admin-Leiste. Evidence for this claim Google says common CMS platforms often generate sitemaps and does not prescribe a CMS-specific ranking advantage. Scope: Google sitemap guidance; absence of a CMS ranking advantage is an editorial inference from platform-neutral requirements. Confidence: medium · Verified: Google: Build and submit a sitemap

Schädliche Standardeinstellungen — und warum sie schaden

Die Option „Suchmaschinen davon abhalten, diese Website zu indexieren“ (Einstellungen → Lesen) erzeugt ein websiteweites noindex und eine restriktive virtuelle robots.txt. Bei jedem WordPress-Audit prüfe ich sie zuerst, denn diese einzelne Einstellung kann die Indexierung einer gesamten Website unbemerkt auf null setzen — meist, weil sie aus der Staging-Phase aktiviert blieb.

Der standardmäßige ?p=123-Permalink vermittelt kein Themensignal und ist keine saubere URL. Wechseln Sie zu /%postname%/ — und zwar vor der Veröffentlichung. Bei einer etablierten Website bedeutet eine Änderung der Permalink-Struktur geänderte URLs. WordPress leitet die alten numerischen URLs bei Standard-Beitragstypen automatisch per 301 weiter, doch benutzerdefinierte Beitragstypen und Seiten werden nicht immer sauber weitergeleitet; testen Sie deshalb. Ich würde die Kategorie nicht in den Permalink aufnehmen (/%category%/%postname%/): Sobald Sie die Taxonomie neu ordnen, lösen Sie eine massenhafte URL-Änderung aus und verlieren Rankinghistorie ohne verhältnismäßigen Nutzen.

Anhangseiten sind der WordPress-spezifische Fallstrick, den viele vergessen. Historisch erzeugte jeder Medien-Upload eine eigenständige URL, die nur die Datei und einige automatisch erzeugte Metadaten enthielt — dünne Seiten, die mit den eigentlichen Seiten konkurrieren können. WordPress 6,4 änderte die Standardeinstellung: Neue Installationen deaktivieren Anhangseiten vollständig; eine Anfrage wird nun direkt auf die Datei selbst statt auf den übergeordneten Beitrag weitergeleitet. Bei bestehenden, aktualisierten Websites bleiben Anhangseiten aktiviert. Dafür gibt es keinen Schalter in den Einstellungen, sondern nur wp option set wp_attachment_pages_enabled 0 über WP-CLI oder die direkte Bearbeitung der Option unter wp-admin/options.php. In der Praxis fassen die meisten Websitebetreiber diese Option nie an, sondern lösen das über ihr Plugin: Die Anhangseite erhält noindex oder wird besser noch über das SEO-Plugin auf den übergeordneten Beitrag weitergeleitet. Gehen Sie nicht davon aus, dass eine ältere Website die WordPress-6,4-Vorgabe übernommen hat — das hat sie nicht.

Archive, Feeds und Suchseiten. WordPress erzeugt standardmäßig indexierbare Kategorie-, Schlagwort-, Datums- und Autorenarchive, paginierte Archivseiten (?page=2), Feed-URLs (/feed/), Anhangseiten und interne Suchergebnisse (/page=search, also ?s=). Das ist die maßgebliche Liste der von WordPress erzeugten Duplicate-Content-Quellen — fast keine davon haben Sie bewusst angelegt.

Duplicate Content, den WordPress selbst erzeugt

Es lohnt sich, das deutlich zu sagen: WordPress erzeugt standardmäßig strukturellen Duplicate Content. Die wiederkehrenden Quellen sind:

QuelleBeispielTypische Lösung
Kategoriearchive/category/news/Beibehalten oder bei dünnem Inhalt noindex
Schlagwortarchive/tag/wordpress/Meist noindex (dünn, Überschneidungen)
Autorenarchive/author/admin/Bei Websites mit nur einem Autor noindex
Datumsarchive/2023/04/Noindex (fast immer dünn)
Paginierung/page/2/Selbstreferenzierendes Canonical (nicht Seite 1)
Feed-URLs/feed/Feeds auf noindex setzen
Anhangseiten/photo-of-cat/Über das SEO-Plugin zum übergeordneten Beitrag weiterleiten (WP 6.4+ leitet bei neuen Installationen stattdessen zur Datei selbst)
Suchergebnisse/?s=keywordNoindex

Die Lösung besteht fast nie darin, eine Abstrafung zu fürchten — Google führt Duplikate unter einem Canonical zusammen, statt strukturelle Duplizierung abzustrafen. Setzen Sie dünne Inhalte auf noindex und halten Sie die Sitemap sauber. Entscheidend ist die Unterscheidung: noindex ≠ nicht crawlen. Eine nicht indexierbare Seite muss crawlbar bleiben, damit Google das noindex überhaupt lesen kann. Wenn diese URLs stattdessen in der robots.txt gesperrt werden, kann Google die Anweisung nicht sehen. Deshalb erhalten dünne Archive noindex, statt blockiert zu werden.

Die XML-Sitemap: Core oder Plugin

WordPress 5.5 (August 2020) führte eine native XML-Sitemap unter /wp-sitemap.xml ein. Sie funktioniert, ist jedoch rudimentär: Sie nimmt alle öffentlichen Beitragstypen, alle öffentlichen Taxonomien und Autorenarchive auf — also genau die dünnen Seiten, die Sie aus dem Index heraushalten möchten. Sie unterstützt keine Bild-Sitemap und bietet nur begrenzte Kontrolle. In der Praxis verwenden die meisten Websites daher die Sitemap von Yoast oder Rank Math. Damit können bestimmte Beitragstypen und Taxonomien ein- oder ausgeschlossen werden, sodass nur kanonische, indexierbare URLs enthalten sind. Yoast deaktiviert die Core-Sitemap und ersetzt sie; das ist beabsichtigt.

Zwei Dinge erledigt die Sitemap nicht für Sie: Google ignoriert <priority> und <changefreq> vollständig (laut eigener Dokumentation), und WordPress übermittelt die Sitemap nicht automatisch an Google. Reichen Sie die Sitemap in der Search Console und den Bing Webmaster Tools ein; zusätzlich lässt sie sich mit einer Sitemap:-Anweisung in der robots.txt zur passiven Erkennung angeben. Die Spezifikationsgrenze von 50 000 URLs beziehungsweise 50 MB gilt weiterhin. Oberhalb dieser Grenze müssen Sie einen Sitemap-Index verwenden.

Canonicals: Core, Plugin und die Konfliktfalle

Der Core gibt rel=canonical über rel_canonical() seit WordPress 2.9 (2009) aus — einzelne Beiträge und Seiten kanonisieren sich selbst. WordPress 4.6 führte das Tag nicht erst ein, sondern stellte die Funktion auf das filterbare wp_get_canonical_url() um. Darauf beziehen sich gewöhnlich Aussagen wie „Canonicals seit 4.6“. Das ist eine gute Grundlage, doch der Core behandelt benutzerdefinierte Beitragstypen nicht in allen Themes einheitlich, fügt auf 404-Seiten keine Canonicals ein und löst URL-Varianten (?utm_source=, www oder kein www, abschließende Schrägstriche) nicht selbst auf. SEO-Plugins ersetzen die Core-Ausgabe durch eine umfassendere Behandlung: Canonicals für benutzerdefinierte Beitragstypen, selbstreferenzierende Canonicals bei Paginierung (nicht Seite 2 und folgende auf Seite 1 verweisen lassen — dadurch verschwinden tiefere Seiten aus dem Index), domainübergreifende Canonicals für Syndizierung und Überschreibungen auf Seitenebene.

Hier liegt die Falle, die mit der Plugin-Frage zusammenhängt: Das von Ihrem SEO-Plugin gesetzte Canonical-Tag ist das maßgebliche Signal. Wenn Ihr Theme jedoch zusätzlich ein Title-Tag oder eigene SEO-Metadaten einfügt, entsteht ein Konflikt. Einige Theme-Frameworks wie Genesis und Thesis geben eigene SEO-Tags aus. Wenn Sie ein SEO-Plugin aktivieren, deaktivieren Sie die SEO-Funktionen des Themes und prüfen Sie den gerenderten <head>: genau ein Canonical, ein Titel und eine Meta-Description.

Ein SEO-Plugin. Niemals zwei.

Dieses Thema verdient eine eigene Überschrift, weil es die häufigste selbst verursachte WordPress-SEO-Verletzung ist. Verwenden Sie niemals zwei SEO-Plugins gleichzeitig. Yoast, Rank Math und AIOSEO hängen sich alle in wp_head() ein, um Titel, Meta-Description, Canonical, Open-Graph-/Twitter-Tags, Robots-Meta und JSON-LD auszugeben. Bei zwei Plugins werden beide ausgeführt — doppelte Meta-Descriptions, doppelte und widersprüchliche Canonical-Tags, widersprüchliche Open-Graph-Angaben und konkurrierende Sitemaps. Die Search Console meldet doppelte Metadaten. Entscheiden Sie sich für eines und deinstallieren Sie das andere vollständig; beim bloßen Deaktivieren bleiben Datenbankeinträge zurück.

Bei der Frage, welches Plugin Sie wählen sollten, gilt: Alle decken die Kernaufgaben ab; die Entscheidung hängt von Anwendungsfall und Budget ab:

  • Yoast SEO — die größte Installationsbasis, die bekannte Ampelbewertung und eine gute Wahl für Einsteiger und Content-Teams, die einen geführten Workflow möchten. (WooCommerce-Schema ist ein kostenpflichtiges Add-on.)
  • Rank Math — der großzügigste kostenlose Tarif: unbegrenzt viele Fokus-Keywords, Weiterleitungsverwaltung, 404-Monitoring, GSC- und GA4-Integration sowie ein leistungsfähiger Schema-Builder (mehr als 16 Typen kostenlos). Meine Wahl für Entwickler und Power-User.
  • All in One SEO (AIOSEO) — starke WooCommerce-Integration, Assistent für interne Links und gutes Local SEO. Geeignet für Agenturen und große Shops.

Ein Hinweis zu den grünen Ampeln von Yoast: Eine höhere Yoast-Bewertung bedeutet keine besseren Rankings. Es handelt sich um eine Heuristik für grundlegende On-Page-Formatierung — Keyword-Vorkommen, Titellänge und Lesbarkeitsnäherungen. Ein Beitrag mit roter Ampel rankt regelmäßig besser als einer mit ausschließlich grünen Ampeln. Inhaltsqualität, Suchintention, Autorität und Links sind wesentlich wichtiger.

Schema: Was WordPress ausgibt — und was nicht

Der WordPress-Core gibt im Wesentlichen nichts aus, das für Rich Results nützlich ist — sauberes HTML, das Google auswerten kann, aber kein JSON-LD. Google erklärt dazu: “if you use a CMS, such as Wix, WordPress, or Shopify, you might not be able to edit your HTML directly… you may be able to install a plugin that allows you to specify structured data.” — (Übersetzung) „Wenn Sie ein CMS wie Wix, WordPress oder Shopify verwenden, können Sie Ihr HTML möglicherweise nicht direkt bearbeiten … eventuell können Sie ein Plugin installieren, mit dem Sie strukturierte Daten angeben können.“ Das ist der Weg:

  • Yoast ergänzt automatisch Organization/Person-, WebSite- (mit SearchAction), WebPage-, BreadcrumbList- und Article-Schema als JSON-LD.
  • Rank Math ergänzt diese sowie mehr als 16 Schema-Typen im kostenlosen Tarif (FAQ, HowTo, Product, Review, Event …) und einen Builder für benutzerdefinierte Typen.
  • WooCommerce allein gibt grundlegende Open-Graph-Produktmetadaten aus, aber kein Product-JSON-LD. Für vollständiges Product-Schema mit Preis, Verfügbarkeit und Bewertungsaggregat brauchen Sie Yoast WooCommerce SEO (kostenpflichtig) oder Rank Math Pro.

WooCommerce in Kürze

WooCommerce erweitert die SEO-Fläche von Standard-WordPress. Wiederkehrende Probleme sind die URL-Basen /product/ und /product-category/ (bei bestehenden Websites entfernbar, aber nur mit Weiterleitungen), nahezu identische Seiten durch Produktvarianten und — am wichtigsten — die facettierte Navigation, die Tausende dünne URLs aus Filterkombinationen erzeugt. Behandeln Sie Facetten wie auf jeder anderen Plattform: idealerweise JavaScript-basierte Filter ohne URL-Änderung; andernfalls rel=canonical zur Basiskategorie und/oder noindex, follow auf Filterseiten. Das Crawling muss zulässig bleiben, damit die Anweisung gelesen wird. Shop- und Kategoriepaginierung benötigt selbstreferenzierende Canonicals. Google hat rel=prev/next bereits 2019 eingestellt — vorhanden ist es harmlos, aber verlassen Sie sich nicht darauf. Die facettierte Navigation wird im Ecommerce-SEO-Pillar ausführlich behandelt.

robots.txt und Core Web Vitals — zwei kurze Hinweise

WordPress liefert eine virtuelle robots.txt aus — keine Datei auf dem Datenträger —, die standardmäßig /wp-admin/ sperrt und admin-ajax.php erlaubt. Eine physische Datei im Stammverzeichnis überschreibt die virtuelle Version vollständig; SEO-Plugins ermöglichen die Bearbeitung der virtuellen Fassung im Dashboard. Ein klassischer Fehler ist das Sperren von /wp-content/, wodurch CSS, JavaScript und Bilder blockiert werden und das Rendering beschädigt wird. Tun Sie das nicht.

Bei der Performance gilt: „WordPress ist langsam“ beschreibt ein Konfigurationsproblem, kein Core-Problem. LCP-Probleme gehen meist auf TTFB zurück (billiges Shared Hosting, kein Opcode-Cache) sowie auf nicht optimierte Hero-Bilder; INP-Probleme auf JavaScript-Ballast durch Page-Builder wie Elementor oder Divi; CLS auf Bilder ohne Abmessungen und Webfonts ohne font-display: swap. Schlanke Themes wie GeneratePress, Kadence oder Astra bringen eine gut gebaute WordPress-Website zusammen mit einem Caching-Plugin, einem CDN und modernen Bildformaten komfortabel durch die Core Web Vitals. Die Einzelheiten stehen im Web-Performance-Cluster.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.