Wer mit WordPress arbeitet, begegnet früher oder später Dateinamen wie single.php, archive.php oder header.php. Lange Zeit war das die vertraute Grammatik nahezu jedes Themes. Und ja: Diese Struktur gilt bis heute. Aber sie erzählt inzwischen nur noch die halbe Geschichte.
Denn WordPress ist längst nicht mehr nur das System klassischer PHP-Themes. Neben diesen vertrauten Strukturen gibt es heute Block-Themes, hybride Ansätze und mit theme.json eine zusätzliche Ebene, die für moderne Projekte immer wichtiger geworden ist. Wer also verstehen will, wie WordPress Inhalte im Frontend ausgibt, sollte nicht nur die alte Template-Hierarchie kennen, sondern auch wissen, wie das System heute tatsächlich funktioniert.
Templates bilden die Ausgabeschicht eines WordPress-Themes. Sie bestimmen, wie Inhalte im Frontend erscheinen, also etwa einzelne Beiträge, Seiten, Archive, Suchergebnisse oder Fehlerseiten.
In klassischen Themes bestehen diese Templates aus PHP-Dateien, in denen HTML, WordPress-Funktionen und PHP zusammenspielen. In modernen Block-Themes kommen stattdessen HTML-Dateien mit Block-Markup zum Einsatz, die WordPress beim Rendern interpretiert. Der Grundgedanke bleibt jedoch derselbe: WordPress erkennt, welche Art von Inhalt gerade aufgerufen wird, und sucht dann in einer festgelegten Reihenfolge nach der passenden Vorlage.
Genau hier kommt die sogenannte Template-Hierarchie ins Spiel.
WordPress lädt nicht einfach irgendeine Datei, sondern folgt einer klaren Logik. Beim Aufruf einer URL prüft das System zunächst, ob es sich um eine Startseite, einen Einzelbeitrag, ein Archiv, eine Suche oder eine Fehlerseite handelt. Anschließend sucht WordPress entlang der Template-Hierarchie nach der spezifischsten passenden Datei.
Wird keine spezialisierte Vorlage gefunden, greift WordPress auf allgemeinere Templates zurück. Im klassischen Theme endet diese Kette bei der index.php, im Block-Theme bei der index.html.
Diese Hierarchie ist einer der Gründe, warum WordPress-Themes so flexibel sind. Sie ist aber auch der Punkt, an dem ältere oder gewachsene Projekte schnell unübersichtlich werden, wenn man nicht genau weiß, welche Datei gerade wirklich greift.
Wer mit einem klassischen WordPress-Theme arbeitet, trifft in der Regel auf eine Reihe bekannter PHP-Dateien. Einige davon bilden das Rückgrat fast jedes Themes.
Die index.php ist das universelle Fallback-Template. Sie wird dann verwendet, wenn WordPress keine speziellere Vorlage findet. Rein technisch genügt diese Datei bereits, damit ein Theme grundsätzlich funktioniert. In der Praxis wäre das allerdings eher ein Notbehelf als eine tragfähige Lösung.
Die home.php steuert die Ausgabe der Beitragsübersicht, also der Blog-Seite. Das wird häufig mit der eigentlichen Startseite verwechselt, ist aber nicht dasselbe. Wenn in den Einstellungen eine statische Startseite definiert wurde, kann home.php trotzdem weiterhin für die Blog-Übersicht zuständig sein.
Die front-page.php ist für die Startseite besonders wichtig. Existiert sie, hat sie Vorrang – ganz gleich, ob dort eine statische Seite oder die letzten Beiträge angezeigt werden. Viele Irritationen in WordPress-Projekten entstehen schlicht dadurch, dass diese Datei vorhanden ist und unbemerkt andere Templates übersteuert.
Für einzelne Inhalte kommen vor allem single.php und page.php ins Spiel. Die single.php steuert einzelne Beiträge, die page.php statische Seiten. Daneben gibt es mit singular.php noch ein gemeinsames Fallback für einzelne Inhalte, falls weder single.php noch page.php vorhanden sind.
Archive werden meist über die archive.php ausgegeben. Dazu zählen Kategorien, Schlagwörter, Datums- oder Autorenarchive. Wer genauer differenzieren möchte, kann dafür eigene Templates wie category.php, tag.php, date.phpoder author.php anlegen.
Auch search.php für Suchergebnisse und 404.php für Fehlerseiten gehören zu den klassischen Kern-Dateien eines Themes. Gerade die 404-Seite wird oft unterschätzt. Dabei ist sie ein wichtiger Ort, um Orientierung zu schaffen und Nutzer nicht einfach im Leeren stehen zu lassen.
Eine der großen Stärken von WordPress liegt darin, dass sich die Template-Hierarchie sehr fein ausdifferenzieren lässt. Es gibt nicht nur allgemeine Templates, sondern auch spezifischere Dateinamen, mit denen sich einzelne Inhalte gezielt anders darstellen lassen.
So kann eine bestimmte Kategorie über category-allgemein.php eine eigene Ausgabe erhalten. Für einzelne Seiten sind Varianten wie page-3.php oder page-ueber-uns.php möglich. Auch für Autoren lassen sich spezifische Vorlagen anlegen, etwa author-horst.php.
Besonders relevant ist dieses Prinzip bei Custom Post Types. Wer mit Veranstaltungen, Jobs, Publikationen, Rezepten oder anderen individuellen Inhaltstypen arbeitet, kann dafür eigene Templates wie archive-rezept.php oder single-rezept.php anlegen. Genau an solchen Stellen zeigt sich, dass WordPress längst weit mehr ist als ein klassisches Blogsystem.
Neben den eigentlichen Templates spielen auch die sogenannten Template Parts eine zentrale Rolle. Dabei handelt es sich um wiederverwendbare Bausteine, die in andere Templates eingebunden werden.
Zu den klassischen Template Parts gehören header.php, footer.php, sidebar.php, comments.php und searchform.php. Sie kapseln bestimmte Bereiche der Website und sorgen dafür, dass sich wiederkehrende Strukturen nicht an zig Stellen doppelt pflegen lassen.
In kleinen Projekten wirkt das zunächst wie reine Ordnungsliebe. In größeren oder länger gewachsenen Websites ist es allerdings ein entscheidender Wartungsvorteil. Wer Navigation, Footer, Content-Module oder Kommentarbereiche sauber strukturiert, spart sich später unnötige Mehrfacharbeit.
WordPress besteht heute nicht mehr nur aus klassischen PHP-Themes. Neben den lange etablierten Strukturen haben sich Block-Themes durchgesetzt, die an mehreren Stellen einer eigenen Logik folgen.
Hier liegen Templates typischerweise als HTML-Dateien im Ordner /templates, wiederverwendbare Teilbereiche im Ordner /parts. Der technische Fallback ist dann nicht mehr die index.php, sondern die index.html. Hinzu kommt mit theme.json eine zentrale Konfigurationsdatei, über die globale Designregeln wie Farben, Typografie, Abstände oder Layoutvorgaben gebündelt gesteuert werden.
Für Gestalter, Entwickler und Redakteure ist das keine Nebensache. Es verändert die Arbeit am Theme spürbar. Wo früher vieles direkt in einzelnen Template-Dateien gelöst wurde, verlangt WordPress heute stärker nach Struktur, Konsistenz und einem systematisch gedachten Aufbau.
Ein weiterer Unterschied: Bei Block-Themes können Templates inzwischen direkt im Site Editor bearbeitet werden. Das bedeutet, dass sichtbare Änderungen nicht zwangsläufig in der ursprünglichen Datei auf dem Server landen. Stattdessen speichert WordPress diese Anpassungen teilweise als eigene Inhalte in der Datenbank.
Für die Praxis heißt das: Wer ein WordPress-Projekt übernimmt oder Fehler sucht, sollte nicht vorschnell davon ausgehen, dass die Datei im Theme-Verzeichnis automatisch auch die aktuell sichtbare Ausgabe bestimmt. Gerade bei neueren Setups lohnt sich deshalb ein genauer Blick darauf, ob ein Template im Backend bereits überschrieben wurde.
Auch wenn sie keine klassischen Templates sind, gehören einige weitere Dateien in jeden vollständigen Überblick.
Die style.css ist weiterhin Pflicht. Sie enthält nicht nur CSS, sondern auch die Theme-Metadaten, also etwa Name, Version oder Autor. WordPress liest diese Informationen aus, um das Theme im Backend korrekt anzuzeigen.
Die functions.php ist ebenfalls zentral, auch wenn sie keine Ausgabedatei ist. Dort werden Menüs, Widgets, Theme-Supports, Scripts, Styles und viele weitere Funktionen registriert. Während Templates also das Erscheinungsbild steuern, regelt die functions.php oft die technische Grundlage.
Die screenshot.png wiederum ist das Vorschaubild des Themes im Administrationsbereich. Sie ist kein funktionaler Bestandteil der Ausgabe, aber dennoch wichtig für Übersicht und Pflege.
Die klassische WordPress-Logik mit single.php, page.php, archive.php und index.php ist keineswegs verschwunden. Sie bleibt für viele Websites und bestehende Projekte hochrelevant. Gleichzeitig wäre es heute zu kurz gegriffen, WordPress nur noch durch die Brille klassischer PHP-Themes zu betrachten.
Moderne WordPress-Projekte bewegen sich je nach Setup zwischen klassischen Templates, Block-Themes, theme.json, Template Parts und editorbasierten Anpassungen. Genau deshalb lohnt es sich, die Theme-Struktur eines Projekts vor jeder Weiterentwicklung sauber zu lesen, statt nur auf Verdacht an Dateien herumzuschrauben.
Wer versteht, welche Vorlage tatsächlich greift, spart Zeit, vermeidet Fehler und kann WordPress deutlich präziser an die eigenen Anforderungen anpassen. Und genau darin liegt bis heute eine der großen Stärken des Systems: nicht in magischer Einfachheit, sondern in einer erstaunlich belastbaren, gewachsenen Logik.