Dieser Artikel wird laufend ergänzt. Zuletzt aktualisiert: Juni 2026.

Wer sich mit WordPress-Wartung, Datenbankbereinigung oder Performance-Optimierung beschäftigt, stößt schnell auf Begriffe, die im WordPress-Backend oder in Fachartikeln auftauchen, aber selten erklärt werden. Dieses Glossar sammelt die wichtigsten technischen Begriffe rund um WordPress-Datenbank, Systemarchitektur und Wartung – kompakt, aber vollständig genug, um sie wirklich zu verstehen.

A


Autoload

Autoload bezeichnet einen Mechanismus in der WordPress-Datenbanktabelle wp_options, der festlegt, ob ein gespeicherter Wert bei jedem Seitenaufruf automatisch in den Arbeitsspeicher geladen wird.

Jeder Eintrag in wp_options hat eine Spalte autoload mit dem Wert yes oder no. Steht dort yes, lädt WordPress diesen Wert beim Start jeder Seite – unabhängig davon, ob er auf der aktuellen Seite tatsächlich gebraucht wird. Das ist für häufig benötigte Einstellungen sinnvoll, etwa den Seitentitel oder die aktive Theme-Konfiguration.

Das Problem entsteht, wenn Plugins viele oder große Datensätze mit autoload=yes speichern. Diese werden dann bei jedem einzelnen Seitenaufruf mitgeladen – auch wenn das Plugin auf der jeweiligen Seite gar nicht aktiv ist. Bei einer WordPress-Installation mit vielen Plugins kann die Summe aller Autoload-Daten mehrere Megabyte erreichen, was die initiale Datenbankabfrage spürbar verlangsamt.

Nach der Deinstallation eines Plugins bleiben dessen Autoload-Einträge oft in der Datenbank stehen und werden weiterhin bei jedem Seitenaufruf geladen – obwohl das zugehörige Plugin nicht mehr existiert.

Attachment (verwaist)

In WordPress wird jede hochgeladene Mediendatei – Bild, PDF, Video – intern als Beitrag des Typs attachment in der Tabelle wp_posts gespeichert. Jede Mediendatei hat dabei einen übergeordneten Beitrag, dem sie zugeordnet ist.

Ein verwaister Attachment-Eintrag entsteht, wenn eine Mediendatei hochgeladen, aber nie in einem Beitrag oder einer Seite eingebunden wurde – oder wenn der übergeordnete Beitrag gelöscht wurde, ohne die zugehörigen Mediendateien zu entfernen. Der Datenbankeintrag bleibt dann bestehen, obwohl die Datei keine Verwendung mehr hat.

Verwaiste Attachments belegen nicht nur Speicherplatz in der Datenbank, sondern auch auf dem Server – denn WordPress speichert beim Upload automatisch mehrere Bildgrößen (Original, Thumbnail, Medium, Large sowie theme-spezifische Formate), die ebenfalls auf dem Server verbleiben.

Illustration einer Datenbanktabelle mit hervorgehobener autoload-Spalte in Orange und einem verblassten Puzzle-Icon als Symbol für Plugin-Reste.
Die autoload-Spalte in wp_options entscheidet, welche Einträge bei jedem Seitenaufruf geladen werden – auch Reste deinstallierter Plugins.

M


MD5-Hash

Ein MD5-Hash ist ein kryptografischer Fingerabdruck einer Datei. Der MD5-Algorithmus berechnet aus dem Inhalt einer Datei eine eindeutige Zeichenkette mit fester Länge (32 hexadezimale Zeichen). Zwei identische Dateien erzeugen immer denselben MD5-Hash – zwei auch nur minimal unterschiedliche Dateien erzeugen völlig verschiedene Hashes.

Im WordPress-Kontext wird MD5-Hashing verwendet, um doppelt hochgeladene Mediendateien zu erkennen. Wenn zwei Bilddateien denselben MD5-Hash haben, sind ihre Inhalte bitgenau identisch – unabhängig davon, ob sie unterschiedliche Dateinamen haben oder in verschiedenen Verzeichnissen liegen.

Diese Methode ist zuverlässiger als ein reiner Dateinamen-Vergleich, da WordPress beim mehrfachen Upload derselben Datei automatisch einen neuen Dateinamen vergibt (z.B. bild-1.jpg, bild-2.jpg). Der MD5-Vergleich erkennt dennoch, dass der Inhalt identisch ist.

Illustration zweier identischer Bilddateien mit je einem Fingerabdruck-Icon und übereinstimmender Hex-Zeichenkette darunter, verbunden durch ein Gleichheitszeichen.
Zwei Dateien mit identischem Inhalt erzeugen denselben MD5-Hash – unabhängig von Dateiname oder Speicherort.

P


Post-Meta

Post-Meta bezeichnet zusätzliche Datenfelder, die WordPress zu jedem Beitrag, jeder Seite oder jedem anderen Inhaltstyp speichern kann. Diese Metadaten werden in der Tabelle wp_postmeta abgelegt und bestehen aus einem Schlüssel-Wert-Paar, das einem bestimmten Beitrag zugeordnet ist.

WordPress selbst nutzt Post-Meta für verschiedene Zwecke, etwa um das Featured Image eines Beitrags zu speichern oder um SEO-Daten von Plugins wie Yoast abzulegen. Plugins können Post-Meta frei verwenden, um beliebige zusätzliche Informationen zu Beiträgen zu speichern.

Verwaiste Post-Meta-Einträge entstehen, wenn ein Plugin Metadaten zu Beiträgen geschrieben hat und anschließend deinstalliert wird, ohne seine Datenbankeinträge zu bereinigen. Die Metadaten bleiben dann in wp_postmeta stehen und verweisen auf Schlüssel, die keine aktive Funktion mehr haben. Bei viel genutzten Websites mit langer Plugin-Geschichte können so zehntausende verwaiste Zeilen entstehen.

Illustration eines Dokuments mit fünf Key-Value-Tag-Paaren: drei aktiv in Teal und Orange, zwei ausgegraut als Symbol für verwaiste Post-Meta-Einträge.
Jeder WordPress-Beitrag kann beliebig viele Metadaten tragen – aktive in Farbe, verwaiste nach Plugin-Deinstallation ausgegraut.

R


Revision

Eine Revision ist eine automatisch erstellte Sicherungskopie eines WordPress-Beitrags oder einer Seite. Jedes Mal, wenn Inhalte gespeichert werden – manuell oder durch die automatische Speicherfunktion –, legt WordPress eine Kopie des bisherigen Zustands in der Datenbank an.

Revisionen werden in derselben Tabelle wie Beiträge gespeichert (wp_posts), aber mit dem Post-Status revision. Jede Revision enthält den vollständigen Inhalt des Beitrags zum Zeitpunkt der Speicherung sowie alle zugehörigen Metadaten in wp_postmeta.

Der Sinn von Revisionen ist die Möglichkeit, frühere Versionen eines Beitrags wiederherzustellen. Das ist besonders nützlich, wenn Änderungen rückgängig gemacht werden sollen.

Das Problem: WordPress begrenzt die Anzahl der aufbewahrten Revisionen standardmäßig nicht. Bei einem Beitrag, der über Monate immer wieder überarbeitet wird, können Dutzende oder Hunderte Revisionen entstehen. Multipliziert mit der Anzahl aller Beiträge auf einer aktiven Website ergibt das schnell tausende Datenbankzeilen, die keinen aktiven Zweck mehr erfüllen.

Die Anzahl der aufzubewahrenden Revisionen lässt sich in der Datei wp-config.php mit dem Parameter WP_POST_REVISIONS begrenzen oder vollständig deaktivieren.

Illustration eines Dokumentenstapels aus mehreren Kopien desselben Beitrags neben einem orangen Uhrsymbol mit Pfeil als Symbol für wiederholte Speichervorgänge.
Jede Speicherung erzeugt eine Revisionskopie – ohne Begrenzung wächst der Stapel unbegrenzt in der Datenbank.

T


Transient

Ein Transient ist ein temporär in der WordPress-Datenbank gespeicherter Wert mit einer definierten Ablaufzeit. Das Transient-System ist ein einfacher Caching-Mechanismus, der es Plugins und Themes erlaubt, das Ergebnis aufwendiger Berechnungen oder externer API-Abfragen zwischenzuspeichern und für eine bestimmte Zeit wiederzuverwenden.

Transients werden in der Tabelle wp_options gespeichert, mit einem speziellen Präfix (_transient_ bzw. _transient_timeout_). Neben dem eigentlichen Wert speichert WordPress auch den Ablaufzeitpunkt.

Das zentrale Problem: Abgelaufene Transients werden nicht automatisch aus der Datenbank gelöscht. WordPress bereinigt einen Transient erst dann, wenn erneut auf ihn zugegriffen wird und dabei festgestellt wird, dass er abgelaufen ist. Transients von Plugins, die deinstalliert wurden oder die ihren Cache nie mehr abrufen, bleiben dauerhaft als inaktive Einträge in der Datenbank stehen.

Auf stark frequentierten Websites oder nach dem Einsatz von Plugins, die intensiv von Transients Gebrauch machen, können sich mit der Zeit Tausende abgelaufener Transient-Einträge ansammeln, ohne dass sie noch einen Nutzen haben.

Illustration eines verschlossenen Glases mit verblassenden Datenpunkten im Inneren, einem Datenbank-Icon links und einem Countdown-Timer rechts als Symbol für ablaufende Transients.
Transients haben eine Ablaufzeit – abgelaufene Einträge bleiben jedoch in der Datenbank stehen, bis sie aktiv überschrieben werden.

W


wp_options

wp_options ist eine der zentralen Datenbanktabellen von WordPress. Sie speichert siteweite Einstellungen und Konfigurationsdaten – von grundlegenden WordPress-Kerneinstellungen (Sitetitel, Zeitzone, aktives Theme) bis hin zu Plugin-Konfigurationen, Widget-Einstellungen und temporären Daten.

Die Tabelle hat eine einfache Struktur: Jeder Eintrag besteht aus einem eindeutigen Schlüssel (option_name) und dem zugehörigen Wert (option_value), ergänzt um die autoload-Spalte.

wp_options ist anfällig für unkontrolliertes Wachstum, weil praktisch jedes Plugin dort seine Einstellungen ablegt – und diese Einträge nach der Deinstallation des Plugins oft nicht entfernt werden. Zusätzlich landen dort Transients, Plugin-Caches und andere temporäre Daten. Bei einer WordPress-Installation mit langer Geschichte kann wp_options mehrere tausend Zeilen umfassen, von denen ein erheblicher Teil keine aktive Funktion mehr hat.

wp_posts / wp_postmeta

wp_posts ist die Haupttabelle für alle Inhalte in WordPress. Sie speichert nicht nur Beiträge und Seiten, sondern auch Mediendateien (als Attachments), Menüeinträge, Revisionen, Entwürfe und benutzerdefinierte Inhaltstypen, die Plugins definieren. Der Inhaltstyp eines Eintrags wird durch die Spalte post_type unterschieden.

wp_postmeta ist die zugehörige Metadatentabelle. Sie speichert beliebige zusätzliche Informationen zu jedem Eintrag in wp_posts als Schlüssel-Wert-Paare. Jede Zeile in wp_postmeta ist über die Spalte post_id mit einem Eintrag in wp_posts verknüpft.

Beide Tabellen wachsen im Betrieb kontinuierlich: wp_posts durch Revisionen, Entwürfe und verwaiste Attachments; wp_postmeta durch Plugin-Daten, SEO-Felder und andere Metadaten, die zu jedem Beitrag gespeichert werden. Verwaiste Einträge in wp_postmeta entstehen, wenn Beiträge gelöscht werden, ohne dass die zugehörigen Metadaten mitgelöscht werden.

WP-Cron

WP-Cron ist das interne Aufgabenplanungssystem von WordPress. Es ermöglicht es, wiederkehrende Aufgaben zeitgesteuert auszuführen – etwa das automatische Leeren des Papierkorbs nach 30 Tagen, das Versenden geplanter Beiträge oder Plugin-spezifische Wartungsaufgaben.

Im Unterschied zu einem echten Server-Cronjob läuft WP-Cron nicht zu einem festen Zeitpunkt. Stattdessen wird er bei jedem Seitenaufruf ausgelöst: WordPress prüft dabei, ob geplante Aufgaben fällig sind, und führt sie dann aus. Das bedeutet, dass WP-Cron nur dann zuverlässig läuft, wenn die Website regelmäßig besucht wird.

Auf wenig frequentierten Websites oder wenn WP-Cron durch Hosting-Konfigurationen deaktiviert ist, können geplante Aufgaben stark verzögert oder gar nicht ausgeführt werden. Das wirkt sich auf automatische Bereinigungsroutinen aus: Papierkorb-Inhalte bleiben länger als geplant bestehen, Plugin-Updates werden nicht geprüft, und geplante Veröffentlichungen verzögern sich.

Für produktive WordPress-Installationen empfiehlt es sich, WP-Cron in der wp-config.php zu deaktivieren (DISABLE_WP_CRON = true) und stattdessen einen echten Server-Cronjob einzurichten, der wp-cron.php zu einem festen Zeitpunkt aufruft.

Illustration dreier Datenbank-Zylinder in Teal, Blau und Orange mit Pfeilen zwischen ihnen und einem Zahnrad-Uhr-Symbol in der oberen rechten Ecke als Symbol für WP-Cron.
Die drei zentralen WordPress-Tabellen stehen in ständigem Austausch – WP-Cron sorgt für zeitgesteuerte Wartungsaufgaben im Hintergrund.

Weitere Begriffe werden bei Bedarf ergänzt. Fehlt ein Begriff? Hinweise gerne über das Kontaktformular.

Nach oben scrollen