Was ist WordPress?

WordPress entstand 2003, als Mike Little und Matt Mullenweg eine Abspaltung des älteren Blogprogramms b2/cafelog anlegten. Heute läuft darauf weit mehr als Blogs: Unternehmensseiten, Nachrichtenportale, Onlineshops mit Erweiterungen wie WooCommerce. Die Lizenz GPLv2 oder später erlaubt, das Programm für jeden Zweck zu nutzen, seine Funktionsweise zu untersuchen, es zu verändern und weiterzugeben.

Zwei Namen werden oft verwechselt. WordPress.org ist die Website des Open-Source-Projekts, dort lädt man die Software herunter und installiert sie bei einem eigenen Hoster. WordPress.com ist ein kommerzieller Dienst, der Websites mit derselben Software betreibt. Im ersten Fall entscheidet man selbst, was auf dem Server läuft; im zweiten trifft ein Teil dieser Entscheidungen der Anbieter.

Der Marktanteil ist hoch, die Zahl hängt aber davon ab, wer misst. W3Techs veröffentlicht einen täglichen Bericht mit eigener, offengelegter Methode und kam am 8. Oktober 2026 auf 40,1 % aller Websites und 58,6 % der Websites mit erkennbarem CMS. Die offizielle Projektseite nennt „über 43 %“, ohne zu erklären, wie sie zählt. Wer eine Zahl braucht, nimmt besser die Messung mit veröffentlichter Methode.

Eine WordPress-Installation besteht aus drei Schichten. Der Kern verwaltet Benutzer, Inhalte, Medien und die Datenbank. Das Theme legt fest, wie diese Inhalte dargestellt werden. Plugins ergänzen Funktionen wie Formulare, Shop, Cache oder SEO. Bei jedem Seitenaufruf liest WordPress den Inhalt aus der Datenbank, verbindet ihn mit den Vorlagen des Themes und erzeugt daraus HTML. Ein Cache-Plugin oder ein Cache auf dem Server kann dieses Ergebnis speichern, damit die Arbeit nicht bei jedem Besuch neu anfällt.

Seit Version 5.5 erzeugt der Kern standardmäßig eine XML-Sitemap unter /wp-sitemap.xml. Ist in den Einstellungen die Option gesetzt, Suchmaschinen von der Indexierung abzuhalten, wird diese Sitemap abgeschaltet. Viele SEO-Plugins ersetzen sie durch eine eigene. Was der Kern nicht mitbringt, ist ein Feld für die Meta-Description: Dafür braucht es ein Plugin oder eigenen Code.

Außerdem bietet WordPress eine REST-API, die Inhalte als JSON ausliefert. Darüber kann ein anderes Programm Beiträge und Seiten auslesen und die Website selbst bauen. Das nennt man Headless-WordPress: WordPress bleibt die Redaktionsoberfläche, die öffentliche Website erzeugt ein anderes System.

Wenn laut W3Techs vier von zehn Websites auf WordPress laufen, lohnt es sich, die Fehler zu kennen, die aus seiner Konfiguration entstehen, denn man findet sie auf jeder WordPress-Seite an denselben Stellen. Drei sind Klassiker: die nach dem Livegang vergessene Option gegen die Indexierung, zwei gleichzeitig aktive Sitemaps, weil Kern und Plugin je eine liefern, und Plugins, die ihren Code auf allen Seiten laden, obwohl sie nur auf einer gebraucht werden.

Für die KI-Suche gilt dasselbe wie für Google. Crawler lesen das HTML, das der Server ausliefert, nicht das, was die Verwaltungsoberfläche anzeigt. Verändern ein Cache-Plugin, das Theme oder ein getrenntes Frontend dieses HTML, belegt die Einstellung im Backend nicht mehr, was Suchmaschinen tatsächlich sehen.

Diese Website ist selbst ein Beispiel. zds.es pflegt seine Inhalte in WordPress, die Seiten erzeugt aber Astro, das die Inhalte über die REST-API abruft; im Quelltext jeder Seite steht „Astro“ als Generator. Deshalb liefert /wp-sitemap.xml auf zds.es einen Fehler 404 (geprüft am 8. Oktober 2026), und die Sitemap, auf die die robots.txt verweist, stammt aus dem Frontend. Bei einer Headless-Installation sagt die Sitemap des Plugins also nichts über die Sitemap, die Google und KI-Crawler lesen.

• Direkt nach dem Livegang prüfen, dass die Option gegen die Indexierung durch Suchmaschinen ausgeschaltet ist.
• Nur eine Sitemap aktiv lassen, die des Kerns oder die des SEO-Plugins, und nur diese in robots.txt und Search Console angeben.
• Kern, Theme und Plugins aktuell halten. Laut W3Techs nutzten am 8. Oktober 2026 noch 35,2 % der WordPress-Websites nicht Version 7.
• Nur Plugins installieren, die wirklich gebraucht werden, und prüfen, ob zwei dieselbe Aufgabe erledigen, besonders bei SEO und Cache.
• Title, Meta-Description, Canonical und strukturierte Daten im ausgelieferten HTML prüfen, nicht im Editor.
• Die Ladezeit nach einem Theme-Wechsel oder neuen Plugins mit Felddaten messen, nicht nur mit einem Labortest.

• Eine Testumgebung mit aktivierter Option gegen die Indexierung in den Livebetrieb übernehmen.
• Zwei aktive Sitemaps mit unterschiedlichen URL-Listen betreiben.
• Die SEO-Einstellungen für korrekt halten, weil das WordPress-Backend sie anzeigt, ohne das ausgelieferte HTML anzusehen. Mit Cache oder bei einer Headless-Installation können beide auseinanderliegen.
• Zwei SEO-Plugins gleichzeitig installieren, die am Ende doppelte Tags ausgeben.
• WordPress.com buchen in der Annahme, man habe dieselbe Kontrolle über den Server wie bei einer eigenen Installation.