Was sind WordPress Shortcodes? Ein praktischer Leitfaden

WordPress Shortcodes sind kurze Text-Snippets in eckigen Klammern (wie [contact-form] oder [gallery ids="1,2,3"]), die WordPress beim Rendern eines Beitrags oder einer Seite durch dynamische Inhalte ersetzt. Eingeführt wurden sie in WordPress 2.5 (2008) und waren über ein Jahrzehnt lang die dominierende Methode, mit der Plugins komplexere Ausgabe in den Content brachten. Seit dem Rollout des Gutenberg-Block-Editors in WordPress 5.0 (2018) haben Shortcodes einen Nachfolger: Blöcke. Aber Shortcodes verschwinden nicht. Sie funktionieren weiterhin, Millionen Seiten hängen daran, und viele Plugins liefern sie zusätzlich oder anstatt Blöcken aus.

Wie sieht ein WordPress-Shortcode aus?

Der Basis-Shortcode ist ein Name in eckigen Klammern:

[gallery]

WordPress sieht das im Beitragstext, schlägt den registrierten Handler für gallery nach, ruft die PHP-Funktion auf und ersetzt das Tag durch das HTML, das der Handler ausgibt. Der Besucher sieht eine Galerie; der Editor sieht [gallery].

Shortcodes können Parameter (Attribute) annehmen:

[gallery ids="42,43,44" columns="3" link="file"]

Und sie können Inhalt einschließen (sogenannte enclosing Shortcodes):

[highlight color="yellow"]Wichtiger Text[/highlight]

Der Shortcode-Handler bekommt die Attribute und den inneren Content, verarbeitet sie in PHP und gibt das HTML zurück, das in die Seite eingefügt wird. Der Besucher sieht nie die Klammern, sondern die fertige Ausgabe.

Was ist der Unterschied zwischen einem Shortcode und einem Gutenberg-Block?

Beide erzeugen dynamische Inhalte; sie unterscheiden sich darin, wo und wie dieser Inhalt entsteht.

• Shortcodes sind serverseitig. Das Bracket-Tag bleibt im in der Datenbank gespeicherten Beitragstext. Wenn die Seite aufgerufen wird, parst WordPress den Content, findet den Shortcode, ruft den PHP-Handler auf und ersetzt die Ausgabe. Die Editor-Ansicht zeigt immer die rohe Bracket-Syntax.
• Blöcke werden als gerendertes HTML gespeichert (mit Metadaten-Kommentaren). Wenn du einen Beitrag im Block-Editor speicherst, erzeugt das Block-Plugin das finale HTML und speichert es in der Datenbank. Der Editor zeigt eine Live-Vorschau des gerenderten Blocks, kein Tag. Im Frontend läuft für die meisten Blöcke kein PHP zum Rendern; das HTML wird direkt ausgeliefert.

Praktische Konsequenzen:

• Performance. Blöcke sind im Frontend schneller, weil es keinen Parse-und-Ersetz-Schritt gibt. Shortcodes lösen bei jedem Rendern einen Regex-Scan über jeden Beitrag aus.
• Bearbeitungserlebnis. Blöcke zeigen beim Editieren, wie das gerenderte Ergebnis aussehen wird. Shortcodes zeigen nur das Tag; das Ergebnis siehst du erst in der Vorschau.
• Portabilität. Wenn du das Plugin deaktivierst, das einen Block bereitstellt, bleibt das gespeicherte HTML meist sichtbar (eingefroren auf dem Stand beim letzten Speichern). Deaktivierst du das Plugin, das einen Shortcode bereitstellt, bleibt das Bracket-Tag als Klartext im Content stehen, was meistens kaputt aussieht.
• Wiederverwendbarkeit. Shortcodes können überall eingesetzt werden, wo PHP läuft, also auch in Widgets, Templates und Excerpts. Blöcke sind für den Block-Editor-Bereich gedacht, auch wenn "Wiederverwendbare Blöcke" und die FSE-Entwicklung (Full Site Editing) diese Lücke zunehmend schließen.

Welche eingebauten WordPress-Shortcodes gibt es noch im Core?

Im WordPress-Core gibt es historisch eine Handvoll Shortcodes. Stand 2026 sind diese noch im Codebase enthalten:

• [gallery] — Bildergalerie. Wird weiterhin vom Classic Editor genutzt und als Fallback, wenn der Gallery-Block konvertiert wird.
• [caption] — Umschließt ein Bild mit einer Bildunterschrift. Meistens vom Image-Block ersetzt, wird aber in manchen Workflows noch ausgegeben.
• [audio] und [video] — Nativer HTML5-Player für selbst gehostete Medien.
• [embed] — Erzwingt, dass eine URL über den oEmbed-Handler eingebettet wird. Selten nötig, weil WordPress die meisten URLs automatisch einbettet.
• [playlist] — Audio- und Video-Playlists. Nischenanwendung.

Die überwältigende Mehrheit der Shortcodes auf einer echten WordPress-Seite stammt aus Plugins und Themes, nicht aus dem Core.

Welche Arten von Plugins nutzen Shortcodes?

Fünf Kategorien decken nahezu jede reale Shortcode-Nutzung ab:

• Kontaktformulare. Contact Form 7 ([contact-form-7 id="123"]), WPForms, Gravity Forms und Formidable bieten Formulare alle über Shortcodes an. Selbst wenn diese Plugins zusätzlich Gutenberg-Blöcke anbieten, bleibt der Shortcode aus Gründen der Rückwärtskompatibilität unterstützt.
• E-Commerce. WooCommerce nutzt Shortcodes für Warenkorb, Checkout, Mein Konto und Produktlisten ([products limit="4"]). Der Block-Editor hat inzwischen Äquivalente, aber Shortcodes dominieren weiterhin, weil die meisten Themes drumherum gebaut wurden.
• Page Builder (im Legacy-Modus). Altes Visual Composer, WPBakery und Ähnliches erzeugen im Classic Editor massive verschachtelte Shortcodes. Schaltet man den Page Builder ab, bleibt eine Wand aus [vc_row][vc_column]...-Tags als Klartext im Beitrag stehen — ein berühmter Lock-in.
• Preistabellen, Slider, Akkordeons. Die meisten "Content-Widget"-Plugins (Soliloquy, Smart Slider, Easy Pricing Tables) wurden historisch als Shortcodes ausgeliefert. Viele werden weiter aktiv gepflegt, haben aber Blöcke ergänzt.
• Mitglieder- und Lernseiten. MemberPress, LearnDash und Ähnliches schränken Content mit Shortcode-Wrappern ein, etwa [restrict role="member"]...[/restrict].

Wie funktioniert ein Shortcode unter der Haube?

Drei Zeilen Plugin-Code erzeugen einen Shortcode. Dieses minimale Beispiel registriert einen Shortcode, der gelbes Highlighting ausgibt:

add_shortcode('highlight', function ($atts, $content = null) {
    $atts = shortcode_atts([
        'color' => 'yellow',
    ], $atts, 'highlight');

    return '<mark style="background:' . esc_attr($atts['color']) . '">' . do_shortcode($content) . '</mark>';
});

Was passiert, wenn WordPress [highlight color="pink"]Hallo[/highlight] rendert:

1. WordPress führt den Filter the_content aus, der do_shortcode() beinhaltet.
2. do_shortcode() sucht über eine Regex im Beitragstext nach Shortcode-Tags.
3. Für jeden Treffer wird der registrierte Handler mit den Attributen (['color' => 'pink']) und dem inneren Content ('Hallo') aufgerufen.
4. Der Handler gibt einen String zurück, der das Shortcode-Tag in der Ausgabe ersetzt.
5. Der Beitragstext wird mit ersetztem Tag an den Browser ausgeliefert.

Der Regex-Parse bei jedem Beitragsrender ist der Performance-Kostenpunkt. Auf einer Seite mit Tausenden Beiträgen, ohne Caching und mit Shortcodes in jedem Beitrag summiert sich das. Ein Page Cache (Redis, WP Super Cache) löst das, indem das fertig gerenderte HTML gespeichert und das Parsing übersprungen wird.

Wann sollte ich 2026 noch Shortcodes nutzen?

Drei legitime Fälle:

• Rückwärtskompatibilität. Wenn deine Seite bereits Shortcodes von Contact Form 7, WooCommerce oder einem etablierten Plugin nutzt, weiter nutzen. Alte Beiträge massenhaft auf Blöcke umzustellen ist ein tagelanges Projekt mit wenig Ertrag.
• Außerhalb des Block-Editors. Widgets (in klassischen Widget-Bereichen), Excerpts, Custom-Post-Type-Loops, Page-Builder-Inhalte und Mails, die über Mailchimp-Templates verschickt werden, akzeptieren weiterhin Shortcodes, aber keine Blöcke. Shortcodes funktionieren in jedem Kontext, in dem do_shortcode() aufrufbar ist.
• Templates und Theme-Code. echo do_shortcode('[my-form id="3"]'); in ein PHP-Template zu setzen ist die einzeilige Methode, Plugin-Ausgabe einzubinden. Blöcke bräuchten serverseitiges Block-Rendering, was mehr Code bedeutet.

Für wirklich neue Funktionalität auf einer neuen Seite bevorzuge Blöcke. Sie sind die Richtung des WordPress-Cores, bieten ein besseres Editing-Erlebnis und vermeiden den Shortcode-Parse-Overhead.

Was ist "Shortcode-Bloat" und warum spielt das eine Rolle?

Shortcode-Bloat entsteht, wenn eine Seite an dutzenden Shortcodes aus inaktiven oder deaktivierten Plugins hängt. Zwei Fehlermodi sind die Folge:

• Plugin deaktiviert, Tags bleiben. Du deaktivierst ein Slider-Plugin, um etwas zu testen. Jede Seite, die [slider id="3"] hatte, zeigt jetzt buchstäblich den Text "[slider id="3"]" statt eines Sliders. Der Fix ist, das Plugin wieder zu aktivieren oder alle Shortcode-Tags manuell aus der Datenbank zu entfernen, was mühsam ist.
• Page-Builder-Migration. Eine in Visual Composer oder WPBakery gebaute Seite enthält verschachtelte Shortcodes wie [vc_row][vc_column width="1/2"][vc_column_text]Hallo[/vc_column_text][/vc_column][/vc_row]. Wechselt man das Theme oder deaktiviert man den Builder, kommt das alles als Klartext zum Vorschein. Genau das ist die Quelle des "Ich kann meine Seite nicht zu Gutenberg migrieren"-Frusts, in dem tausende Seiten festsitzen.

Die pragmatische Prävention: Plugins wählen, auf die du dich langfristig festlegst, und solche bevorzugen, die zusätzlich Blöcke unterstützen, damit du schrittweise migrieren kannst. Für vor 2018 gebaute Seiten ist eine echte Migration realistisch zu erwarten, kein sauberer Schnitt.

Kann ich einen eigenen Shortcode erstellen, ohne ein Plugin zu schreiben?

Ja, drei Wege:

1. In der functions.php eines Child-Themes. Den add_shortcode()-Aufruf hinzufügen. Der Shortcode steht überall auf der Seite zur Verfügung. Funktioniert, aber der Shortcode hängt am Theme; Theme-Wechsel und der Shortcode ist weg.
2. In einem eigenen MU-Plugin. wp-content/mu-plugins/my-shortcodes.php anlegen und die add_shortcode()-Aufrufe dort einbauen. Überlebt Theme-Wechsel und die meisten Updates. Die saubere Lösung.
3. Über ein "Code Snippets"-Plugin. Plugins wie Code Snippets oder WPCode erlauben PHP über die Admin-UI. Bequem, wenn du keine Dateien bearbeiten kannst, fügt aber eine Admin-Abhängigkeit für Code hinzu, der idealerweise in Dateien liegt.

Was sind häufige Shortcode-Fehler?

• do_shortcode() auf inneren Content vergessen. Wenn dein Shortcode Inhalt umschließt (enclosing Shortcode), solltest du auf dem inneren Teil do_shortcode($content) aufrufen, damit verschachtelte Shortcodes funktionieren. Ohne das rendert [outer][inner][/outer] nur den äußeren Shortcode und lässt [inner] als Klartext stehen.
• Im Handler echo nutzen. Shortcode-Handler müssen ihre Ausgabe zurückgeben, nicht echoen. Ein per echo ausgegebener Shortcode rendert vor dem Content, in den er eingebettet ist, und reißt das Layout subtil auseinander.
• esc_attr() auf Attributen vergessen. Ohne Escaping können nutzergesetzte Attributwerte aus dem HTML ausbrechen und XSS-Lücken aufreißen. Immer escapen, was ausgegeben wird.
• Shortcodes in Widgets, die sie nicht ausführen. Manche klassischen Widget-Typen (etwa das alte Text-Widget vor WordPress 4.9) führen Shortcodes nicht automatisch aus. Fix: add_filter('widget_text', 'do_shortcode');.
• Tags innerhalb anderer Tags, die den Parser verwirren. Ein Shortcode-Attribut, das ein Bracket-Zeichen enthält ([shortcode label="Click [here]"]), bringt den Parser durcheinander. WordPress fängt vieles, aber nicht alles ab; HTML-Entities ([ und ]) sind der sichere Workaround.
• Rekursives do_shortcode. Innerhalb eines Shortcode-Handlers do_shortcode() auf Inhalt aufzurufen, der denselben Shortcode enthält, erzeugt eine Endlosschleife. WordPress hat Schutzmechanismen, aber das Symptom ist eine leere Seite oder ein Memory-Exhausted-Fehler.

Wie finde ich jeden Shortcode, der auf meiner Seite verwendet wird?

Drei schnelle Wege:

1. Datenbank-Suche. Eine SQL-Abfrage auf wp_posts laufen lassen: SELECT DISTINCT REGEXP_SUBSTR(post_content, '\\[[a-z_-]+') FROM wp_posts WHERE post_status = 'publish';. Listet jedes Shortcode-Tag auf, das in veröffentlichten Inhalten vorkommt.
2. WP-CLI. wp shortcode list zeigt jeden registrierten Shortcode-Handler. Die Liste mit der Datenbank-Liste vergleichen, um Shortcodes zu finden, die genutzt werden, aber keinen aktiven Handler mehr haben (wahrscheinlich aus einem deaktivierten Plugin).
3. "Shortcode Cleaner"- oder "Find My Blocks"-Plugins. Scannen den Content auf Shortcode- und Block-Nutzung. Praktisch, bevor man ein Plugin deaktiviert, um zu sehen, wie weit dessen Shortcodes verbreitet sind.

Was ist mit Sicherheit?

Shortcodes an sich sind nicht unsicher; die Frage ist, was der Handler mit den Attributen macht. Zwei Bedrohungsmodelle:

• Ein nicht vertrauenswürdiger Nutzer reicht Content mit Shortcodes ein. Wenn ein Mitwirkender oder Abonnent Beiträge einreichen kann und der Shortcode serverseitigen Code ausführt (etwa [exec command="..."] aus einem Dev-Plugin), ist das ein Pfad für Arbitrary Code Execution. WordPress-Core entfernt Shortcodes standardmäßig aus Content, der von Nutzern mit niedrigen Rechten eingereicht wird; diesen Schutz nicht aushebeln.
• Shortcode-Attribute werden unsicher ausgegeben. Ein schlecht geschriebener Shortcode könnte [badge text="..."] ohne Escaping direkt in die Seite ausgeben und einem Admin erlauben, beim Bearbeiten eines Beitrags Script-Tags zu injizieren. Bearbeitung von Beiträgen Admins vorbehalten und beim Schreiben eigener Shortcodes Attributwerte immer escapen.

Was InspectWP prüft

Shortcodes sind nicht direkt Teil eines InspectWP-Security- oder Performance-Reports, aber ihre Auswirkungen tauchen an mehreren Stellen auf. Eine Seite mit Shortcodes aus deaktivierten Plugins hat typisch "kaputte Layouts"-Befunde (gerenderter Text mit eckigen Klammern). Eine Seite mit intensiver Shortcode-Nutzung ohne Page Cache fällt durch langsames TTFB auf. Und eine Seite, auf der Visual-Composer- oder WPBakery-Shortcodes ins gerenderte HTML durchschlagen (weil der Page Builder kaputt oder deaktiviert ist), erscheint mit Render-Fehlern und Accessibility-Verstößen. Das empfohlene Muster 2026 ist, Shortcodes aus Legacy-Gründen weiter zu nutzen, für neue Inhalte Blöcke zu bevorzugen und die Seite regelmäßig auf Shortcodes zu prüfen, deren Handler nicht mehr registriert sind.