WordPress FAQ: Geschichte, Technik, Kosten, Hosting, SEO, Sicherheit und mehr

WordPress entstand 2003 als Nachfolger von b2/cafelog und war zunächst klar auf chronologische Blogbeiträge ausgerichtet. ^[1] Heute kann WordPress jedoch eine kleine Website mit Standard-Theme ebenso tragen wie ein System mit eigenen Inhaltsarten, Schnittstellen und klaren Redaktionsabläufen.

Wann wurde WordPress zum CMS? Einen offiziellen Stichtag gibt es nicht.

Pages und ein neues Theme-System schufen 2005 die Grundlage für dauerhafte Website-Strukturen. Die frei wählbare Startseite löste WordPress 2007 praktisch vom festen Blogaufbau.

Taxonomien und eigene Inhaltstypen machten das Modell zwischen 2007 und 2010 deutlich flexibler.

Vom Blog zur erweiterbaren Plattform

Das ursprüngliche WordPress-Modell war einfach: Neue Beiträge erschienen vorne, ältere wanderten in Archive. Kategorien, Kommentare und der zeitliche Verlauf prägten die Website. Für einen Blog ist das passend. Eine Unternehmenswebsite braucht dagegen Bereiche, die dauerhaft erreichbar bleiben, etwa Leistungen, Team, Referenzen und Kontakt.

Wer WordPress nur über eine fertige Oberfläche kennt, übersieht leicht, wie unterschiedlich zwei Installationen aufgebaut sein können. Die eine besteht aus einem gekauften Theme, einem Page Builder und mehreren Erweiterungen. Die andere verwendet eigene Inhaltstypen, Taxonomien, Templates, Felder und Schnittstellen. Beide nutzen WordPress, technisch liegen aber unterschiedliche Konzepte dahinter.

2004: Plugins öffnen die Architektur

Mit WordPress 1.2 „Mingus“ erhielt das System im Mai 2004 eine Plugin-Architektur. Entwickler konnten Funktionen über Hooks ergänzen, ohne den WordPress-Core für jedes Projekt zu verändern. ^[2] WordPress war damit noch kein umfassend ausgebautes CMS. Es entwickelte sich aber von einer abgeschlossenen Bloganwendung zu einer Software, die sich gezielt erweitern ließ.

Die bis heute übliche Arbeitsteilung hat hier ihren Ursprung: Themes kümmern sich vor allem um Darstellung und Templates, Plugins ergänzen Funktionen. In realen Projekten sind die Grenzen nicht immer so sauber. Als Orientierung hilft die Trennung dennoch, weil sich Änderungen, Updates und Abhängigkeiten besser nachvollziehen lassen.

Pages und die statische Startseite

2005: Dauerhafte, hierarchische Inhalte

WordPress 1.5 „Strayhorn“ brachte im Februar 2005 Pages und ein flexibleres Theme-System. Pages sind für dauerhafte Inhalte gedacht und lassen sich hierarchisch organisieren. ^[3] Aus einem reinen Beitragsstrom konnte damit eine Website mit festen Bereichen werden.

• Startseite
• Unternehmen
• —- Geschichte
• —- Team
• Leistungen
• Referenzen
• Kontakt

Damit war eine wesentliche CMS-Grundlage vorhanden: Inhalte mussten nicht mehr ausschließlich nach Veröffentlichungsdatum sortiert sein.

Der Blog blieb zunächst allerdings sehr sichtbar, weil die Startseite noch eng mit den neuesten Beiträgen verbunden war.

2007: Die Homepage löst sich vom Blog

Mit WordPress 2.1 „Ella“ im Januar 2007 konnte eine beliebige Page als Startseite dienen; aktuelle Beiträge ließen sich getrennt auf einer anderen Seite ausgeben. ^[4] Eine Website konnte nun eine feste Homepage besitzen und daneben einen News- oder Blogbereich führen.

2007 ist deshalb ein plausibler praktischer Wendepunkt, kein offiziell festgelegtes Datum für den Status „vollwertiges CMS“. Pages machten WordPress bereits 2005 CMS-fähig. Die statische Startseite nahm 2007 eine der sichtbarsten Bindungen an den klassischen Blogaufbau weg.

Der Kipppunkt

Eine kleine Zeitreise, die den praktischen Wendepunkt zeigt.

1. 2005

   Pages

   WordPress 1.5 bringt Pages – der Grundstein für statische Inhalte.

2. 2007

   Statische Startseite

   Die frei wählbare Startseite trennt Website und Blog – ein entscheidender Schritt in der Praxis.

3. 2009

   register_post_type()

   Eigene Inhaltstypen werden möglich – WordPress wird flexibler und mächtiger.

4. 2010

   WordPress 3.0

   Ein allgemeineres Taxonomie-System kommt. WordPress etabliert sich als vollwertiges CMS.

Taxonomien und eigene Inhaltstypen

2007: Inhalte systematisch gruppieren

WordPress 2.3 „Dexter“ führte im September 2007 native Tags und ein allgemeineres Taxonomie-System ein. ^[5] Kategorien und Tags waren damit nicht länger bloß einzelne Blogfunktionen, sondern Teil einer Struktur, mit der Inhalte klassifiziert werden können.

Eine Taxonomie ist dabei nicht automatisch eine fertige Liste wie „Branche“ oder „Standort“. Sie beschreibt das technische Prinzip der Gruppierung. Für ein konkretes Projekt lassen sich passende Taxonomien definieren: etwa Branche, Leistung und Technologie für Referenzen oder Standort und Beschäftigungsart für Stellenangebote.

2009 und 2010: Eigene Inhaltsobjekte

Mit WordPress 2.9 „Carmen“ im Dezember 2009 stand eine reguläre API für eigene Post Types zur Verfügung. Die Funktion register_post_type() ist seit Version 2.9.0 dokumentiert. ^{[6] [7]} WordPress 3.0 baute Post Types und Taxonomien weiter aus, ergänzte Custom Menus und führte WordPress MU mit dem Core zur heutigen Multisite-Funktion zusammen. ^[8]

Ein Projekt musste nun nicht mehr nur in „Beiträge und Seiten“ denken. Es konnte eigene Objekte erhalten: Referenzen, Standorte, Mitarbeiter, Veranstaltungen oder Stellenangebote. Das ist mehr als Ordnung im Backend. WordPress kennt dann die Art eines Inhalts und kann daran Templates, Archive, Eingabefelder, Berechtigungen und Schnittstellenausgaben knüpfen.

Die wichtigsten WordPress-Meilensteine im Überblick

Die folgende Übersicht fasst weitere Versionssprünge und technische Erweiterungen zusammen.

WordPress: Wichtige Meilensteine der Entwicklung

Vom Blogsystem zum flexiblen Content-Management-System: Einige Releases haben WordPress technisch und redaktionell grundlegend verändert.

Alle

Was ein strukturiertes WordPress-CMS ausmacht

Bei strukturiert aufgebauten WordPress-Projekten greifen meist drei Ebenen ineinander.

Sie werden oft verwechselt, erfüllen aber unterschiedliche Aufgaben.

Ebene	Frage	Beispiel bei Referenzen
Post Type	Was ist dieser Inhalt?	Referenz
Taxonomie	Wie wird der Inhalt gruppiert?	Branche, Leistung, Technologie
Metadaten	Welche Eigenschaft hat dieses Objekt?	Projektjahr, Kunde, URL, Bild

Ein Post Type beschreibt also den Inhaltstyp. Taxonomien verbinden mehrere Inhalte über gemeinsame Begriffe. Metadaten speichern Eigenschaften eines einzelnen Objekts. Zusammen entsteht daraus ein Inhaltsmodell, das Redaktion und Darstellung voneinander trennt.

Ein hypothetisches Beispiel: Eine Agentur verwaltet 150 Referenzen. Jede Referenz könnte als normale Seite angelegt werden, inklusive Text, Bild und Buttons. Bei einem Post Type Referenz gibt es dagegen einen Datensatz mit definierten Feldern und Zuordnungen. Dieselbe Referenz kann auf ihrer Detailseite, auf einer Leistungsseite und in einer Branchenübersicht erscheinen. Ändert sich das Projektjahr, erscheint der neue Wert an allen dafür vorgesehenen Stellen.

Diese Trennung hilft vor allem bei wiederkehrenden Inhalten. Eine Referenz ist dann nicht einfach eine Seite, die zufällig unter einem bestimmten Menüpunkt liegt. Sie ist im System ausdrücklich als Referenz hinterlegt. Das schafft eine Grundlage für Filter, Archive, interne Verlinkungen oder eine Ausgabe über Schnittstellen.

Ist WordPress seit 2007 ein vollwertiges CMS?

Man kann es als praktische Einordnung so formulieren, mit einer Einschränkung: WordPress wurde nicht durch ein einzelnes Release zum CMS. Pages brachten 2005 dauerhafte, hierarchische Seiten. Die frei wählbare Startseite machte 2007 die klassische Trennung zwischen Unternehmenswebsite und Blog möglich. Eigene Post Types und Taxonomien erweiterten das Inhaltsmodell in den folgenden Jahren.

Phase	WordPress konnte bereits	Bedeutung
2003–2004	Beiträge, Kategorien, Kommentare, Plugins	erweiterbares Blogsystem
ab 2005	Pages, Hierarchien, flexiblere Themes	erste echte CMS-Strukturen
ab 2007	statische Homepage, getrennte Blogseite, Taxonomien	klassische Websites und strukturiertere Inhalte
ab 2009/2010	Custom Post Types, eigene Taxonomien, Menüs, Multisite	flexibel modellierbares CMS
ab 2015/2016	REST API und Content Endpoints	CMS auch als Daten- und API-Plattform
ab 2018	Block Editor	neues Inhalts- und Komponentenmodell
ab 2022	Full Site Editing	blockbasierte Templates und Site-Strukturen

Deshalb wäre es historisch zu spät angesetzt, erst Custom Post Types zum Beginn von WordPress als CMS zu erklären. Treffender ist: Pages legten die Grundlage, die statische Startseite machte WordPress als klassische Website-Plattform praktikabel, und die spätere Modellierung eigener Inhalte vergrößerte den Spielraum erheblich.

WordPress-Seite oder WordPress-System?

Von außen sehen beide Varianten oft gleich aus. Im Backend unterscheiden sie sich deutlich. Bei einzeln gebauten Seiten liegen wiederkehrende Informationen an vielen Stellen im visuellen Aufbau. Bei strukturierten Datensätzen wird ein Inhalt einmal gepflegt und nach festen Regeln an mehreren Stellen ausgegeben.

Das ist keine pauschale Kritik an Page Buildern. Sie passen gut, wenn Redaktionen regelmäßig unterschiedliche Landingpages zusammenstellen müssen.

Bei vielen gleichartigen Inhalten kann zu viel Freiheit aber zu Uneinheitlichkeit führen: Ähnliche Seitentypen werden unterschiedlich aufgebaut, Felder fehlen oder Informationen lassen sich später nur schwer filtern.

• Für feste Leistungs- oder Produktseiten passen häufig Templates mit klaren Feldern.
• Für wiederkehrende Objekte wie Jobs, Standorte oder Referenzen sind eigene Post Types meist nachvollziehbar.
• Für variable Kampagnenseiten können definierte Blöcke, Patterns oder ein Page Builder sinnvoll sein.
• Die Redaktion braucht Spielraum, aber auch Leitplanken für Layout und Inhalte.

Klassische Themes, Block Themes und individuelle Blöcke

WordPress führt mehrere Entwicklungsansätze parallel. Klassische Themes arbeiten vor allem mit PHP-Templates, Template-Hierarchie und Hooks. Block Themes nutzen unter anderem Block Templates, Patterns, globale Einstellungen und den Site Editor. Beide Ansätze lassen sich mit eigenen Plugins, Post Types, Taxonomien und individuellen Blöcken kombinieren.

Der Block Editor wurde mit WordPress 5.0 Ende 2018 zum Standard. Sein Konzept geht über einen neuen Texteditor hinaus: Absätze, Bilder und Galerien sind Blöcke. Das gilt ebenso für individuell entwickelte Komponenten wie Referenzteaser, Produkttabellen, Ansprechpartner oder FAQ-Bereiche.

Mit Full Site Editing wurde das Block-Prinzip 2022 auf weitere Bereiche wie Templates, Header, Footer und globale Styles ausgedehnt. Das heißt nicht, dass jede Website diese Bereiche vollständig offenlegen sollte. Bei einer Unternehmenswebsite kann es sinnvoll sein, Templates fest vorzugeben und nur Inhalte zugänglich zu machen, die tatsächlich regelmäßig gepflegt werden.

Mehr Flexibilität ist nicht automatisch besser. Ein Backend, in dem theoretisch alles überall verändert werden kann, wirkt zunächst attraktiv. Nach längerer Redaktionsarbeit entstehen daraus manchmal fünf Varianten derselben Seite. Ein gutes CMS definiert deshalb auch, welche Freiheiten an welcher Stelle sinnvoll sind.

Was WordPress für SEO mitbringt

Für SEO bringt WordPress technische Grundlagen mit, etwa sprechende Permalinks, kanonische URLs und seit WordPress 5.5 auch XML-Sitemaps im Core. Diese Funktionen helfen Suchmaschinen, Inhalte und ihre bevorzugten Adressen einzuordnen. Sie ersetzen jedoch weder eine saubere technische Einrichtung noch die redaktionelle Arbeit an einer Website. ^[7]

Die Inhaltsstruktur wirkt hier sehr konkret: Ein sauber angelegter Post Type für Stellenangebote kann gleichartige Detailseiten, nachvollziehbare URLs und eine Übersichtsseite schaffen. Taxonomien können passende Verbindungen zwischen Stellen, Standorten oder Beschäftigungsarten abbilden. Das unterstützt eine verständliche Navigation und interne Links, erzeugt aber für sich genommen keine Platzierung in Suchergebnissen.

Ein SEO-Plugin kann Einstellungen und redaktionelle Hinweise bündeln, zum Beispiel für Seitentitel, Beschreibungen oder die Indexierungssteuerung. Eine Strategie kann es nicht liefern. Entscheidend bleiben die Fragen, welche Inhalte eine Seite beantworten soll, wie sie im Verhältnis zu anderen Seiten steht und ob sie für Besucher verständlich gepflegt wird.

Das WordPress-Datenmodell

Drei Bausteine, die zusammen ein flexibles System ergeben.

1. Post Type

   Definiert, welche Inhalte gespeichert werden.

2. Taxonomie

   Strukturiert und klassifiziert Inhalte.

3. Metadaten

   Erweitert Inhalte um zusätzliche Informationen.

REST API und Headless WordPress

Über die REST API kann WordPress Inhalte strukturiert für andere Anwendungen bereitstellen. WordPress muss dann nicht selbst das sichtbare Frontend ausliefern. Denkbar sind JavaScript-Frontends, Apps, externe Portale oder interne Anwendungen. Diese Architektur wird meist als Headless WordPress bezeichnet.

Headless ist kein Qualitätsmerkmal für sich. Mit einem getrennten Frontend kommen zusätzliche Aufgaben hinzu: Preview, Routing, Caching, Formulare, Authentifizierung, Weiterleitungen, Metadaten, Sitemap und Deployment müssen zwischen den Systemen sauber zusammenspielen. Ob dieser Aufbau passt, hängt von Integrationen, Ausgabekanälen und den vorhandenen technischen Abläufen ab.

Für eine überschaubare Unternehmenswebsite kann ein klassisches WordPress-Frontend leichter zu betreiben sein, weil weniger Systeme miteinander abgestimmt werden müssen.

Sobald Inhalte dagegen mehrere Anwendungen versorgen oder sich in eine umfangreichere Plattform einfügen, kann eine getrennte Architektur sinnvoll werden.

Was kostet eine WordPress-Website?

Die WordPress-Software selbst ist frei lizenziert. Kosten entstehen trotzdem, denn eine Website besteht aus mehr als dem Core: Sie muss geplant, gestaltet, eingerichtet und betrieben werden. Eine seriöse Pauschalsumme lässt sich ohne Umfang, Inhaltsmenge, Integrationen und Zuständigkeiten nicht nennen. ^[5]

• Einmalige Projektkosten können Konzeption, Design, Entwicklung, Einrichtung von Templates und Feldern sowie die Migration bestehender Inhalte umfassen.
• Laufende Betriebskosten entstehen für Domain, Hosting, Backups, Wartung und redaktionelle oder technische Betreuung.
• Optionale Kosten fallen an, wenn kostenpflichtige Themes, Plugins, externe Dienste oder Schnittstellen eingesetzt werden.

Bei einer kleinen Website mit wenigen festen Seiten liegt der Aufwand oft in Gestaltung und sauberer Einrichtung. Bei einem System mit Referenzen, Stellenangeboten, mehreren Rollen oder Anbindungen an andere Dienste prägen Datenmodell, Schnittstellen und spätere Pflege den Aufwand stärker. Es lohnt sich daher, den Projektstart und den laufenden Betrieb getrennt zu betrachten.

Worauf kommt es beim WordPress-Hosting an?

Hosting ist mehr als Speicherplatz und ein Tarifname. Die Umgebung sollte eine aktuell unterstützte PHP- und Datenbankversion, HTTPS sowie genügend Ressourcen für die tatsächliche Website bieten. WordPress empfiehlt mit Stand September 2026 PHP 8.3 oder höher sowie MariaDB 10.11 oder MySQL 8.0 oder höher. ^[3]

Für den Alltag zählen auch Staging, Caching, Ressourcenlimits und ein erreichbarer Support. Besonders wichtig ist die Wiederherstellung: Backups sind erst dann hilfreich, wenn klar ist, wer sie kontrolliert, wie lange sie vorliegen und wie eine Rücksicherung getestet wird. Der Hoster betreibt die Serverumgebung; für Inhalte, Benutzerkonten, Erweiterungen und viele Einstellungen bleibt der Website-Betreiber oder ein Wartungspartner verantwortlich.

Betrieb: Sicherheit, Plugins, Größe und Wartung

WordPress-Core wird gepflegt und erhält Sicherheitsupdates. Eine pauschale Antwort auf die Frage nach Sicherheit wäre dennoch wenig hilfreich. Das Risiko einer konkreten Installation hängt unter anderem von der Pflege der Erweiterungen, der PHP-Version, den Zugangsdaten, Rollen und Berechtigungen sowie den Backup-Routinen ab.

Sicherheit als feste Betriebsroutine

Diese Faktoren wirken erst im Zusammenspiel: Ein aktuelles Plugin hilft wenig, wenn ein ehemaliges Redaktionskonto weiter Zugriff hat; ein Backup hilft wenig, wenn es im Ernstfall nicht lesbar oder unvollständig ist. Deshalb gehören regelmäßige Updates, geschützte Zugänge, sparsam vergebene Rollen, HTTPS und getestete Wiederherstellungen in denselben Betriebsablauf. ^[4]

Auch für die Plugin-Zahl gibt es keine brauchbare feste Grenze. Zwanzig gepflegte Erweiterungen können weniger problematisch sein als fünf schlecht gewartete. Vor jeder Erweiterung helfen konkrete Fragen:

• Welches Problem löst das Plugin genau?
• Wird es noch gepflegt und passt es zur verwendeten WordPress- und PHP-Version?
• Welche Daten, Skripte oder externen Dienste bringt es mit?
• Ist die Funktion so speziell, dass sie eine Erweiterung rechtfertigt?
• Was geschieht, wenn das Plugin künftig nicht mehr verfügbar ist?

Die Zahl der Seiten entscheidet ebenfalls nicht allein über die technische Eignung. Bei großen Inhaltsbeständen zählen Datenmodell, Datenbankabfragen, Caching, Suche, interne Verlinkung, Redaktionsprozesse und Infrastruktur. Eine Website hat auch kein festes Ablaufdatum. Sie kann lange nutzbar bleiben, wenn Architektur und Wartung spätere Änderungen nicht unnötig erschweren.

Für welche Projekte eignet sich WordPress?

Chancen und Grenzen auf einen Blick – für eine fundierte Entscheidung.

WordPress spielt seine Stärken aus bei

• Unternehmenswebsites und Corporate Content
• Blogs, Magazinen und redaktionellen Plattformen
• Marketing-Websites und Kampagnen-Landingpages
• Kleinen bis mittelgroßen E-Commerce-Projekten, z. B. WooCommerce

Kritisch prüfen sollte man WordPress bei

• Sehr komplexen, stark individualisierten Webanwendungen
• Projekten mit hohen Performance-Anforderungen in Echtzeit
• Streng regulierten Umgebungen, z. B. kritischer Infrastruktur
• Projekten, bei denen ein Headless-Ansatz oder eine andere Technologie besser passt

Wann WordPress passt – und wann nicht

WordPress passt häufig zu Unternehmenswebsites, Magazinen und redaktionellen Plattformen, bei denen Inhalte strukturiert gepflegt, wiederverwendet und in verschiedenen Bereichen ausgegeben werden. Es kann auch als Inhaltszentrale dienen, wenn weitere Systeme Daten abrufen.

Für eine sehr einfache Microsite kann WordPress unnötig umfangreich sein. Bei einer hochspezialisierten Anwendung, deren Kern fast vollständig aus individueller Geschäftslogik besteht, kann ein eigenes Framework besser passen. Bestehende Plattformen mit eng gekoppelten Daten, Nutzern und Workflows sollten ebenfalls zuerst als Gesamtsystem betrachtet werden.

Fazit

WordPress wurde nicht an einem Tag zum CMS. Die Plugin-Architektur machte es 2004 erweiterbar. Pages und Themes legten 2005 die Basis für dauerhafte Website-Strukturen. Die frei wählbare Startseite löste das System 2007 praktisch vom festen Blogaufbau. Taxonomien und eigene Inhaltstypen erweiterten die Modellierung von Inhalten bis 2010.

REST API, Block Editor und Full Site Editing haben diese Grundlage später weiterentwickelt. Ob eine WordPress-Website gut wartbar, redaktionell sinnvoll und technisch passend ist, hängt weniger am Namen des CMS als an Datenmodell, Erweiterungen und den Regeln, nach denen Inhalte gepflegt und ausgegeben werden. Kosten, Hosting, SEO und Sicherheit gehören zu denselben Entscheidungen, weil sie den Betrieb und die Weiterentwicklung der gewählten Architektur mitbestimmen.

Quellen und Einordnung

• Ordne den Übergang zum CMS als Entwicklung in mehreren Stufen ein: Pages und Themes schufen 2005 die Grundlage, die frei wählbare Startseite löste WordPress 2007 praktisch vom festen Blogaufbau, und eigene Inhaltstypen erweiterten das Modell ab 2009. ^{[3] [4] [6]}
• Unterscheide bei eigenen Inhaltstypen zwischen der ersten API-Unterstützung in WordPress 2.9 und dem weiteren Ausbau in WordPress 3.0. ^{[7] [8]}

1. Learn about WordPress origins and version history (WordPress.org Documentation)
2. WordPress 1.2 (WordPress News)
3. Announcing WordPress 1.5 (WordPress News)
4. WordPress 2.1 Ella (WordPress News)
5. WordPress 2.3 (WordPress News)
6. WordPress 2.9, oh so fine (WordPress News)
7. register_post_type() – Function (WordPress Developer Resources)
8. WordPress 3.0 „Thelonious“ (WordPress News)