HTML-Blöcke: Eigene Inhalte überall in Ihrem PrestaShop-Shop einfügen

Zuletzt aktualisiert im Juni 2026, die Hook-Namen und die Tabelle der nativen Module unten gelten für PrestaShop 1.7, 8 und 9. Positionen werden in modernen Backoffices unter Design → Positionen verwaltet.

Früher oder später stößt jeder PrestaShop-Shop an dieselbe Grenze: Sie brauchen einen Inhalt, für den das Theme nie vorgesehen war. Eine Leiste für kostenlosen Versand oberhalb des Produktrasters. Einen Hinweis im Header wie „Versand vor Weihnachten, wenn Sie bis zum 19. Dezember bestellen“. Ein paar Trust-Badges direkt unter dem In-den-Warenkorb-Button. Nichts davon gehört in eine Produktbeschreibung, auf eine CMS-Seite oder in eine Kategorie. Es muss an einer bestimmten Stelle auf bestimmten Seiten erscheinen und Theme-Updates überstehen. Genau dafür ist ein eigener HTML-Block gedacht: Er fügt beliebiges Markup an einer benannten Position in Ihrem Shop ein, ohne dass Sie auch nur eine Template-Datei öffnen müssen.

In diesem Leitfaden geht es genau um diese eine Aufgabe, eigenes HTML in PrestaShop an die richtige Stelle zu bringen und zu steuern, wo es angezeigt wird. Es geht nicht um Styling (das ist ein eigenes Thema; siehe eigenes CSS und JavaScript in PrestaShop ohne Update-Probleme) und auch nicht darum, statische Seiten in Ihrem Menü umzubenennen (das behandelt Anzeigenamen für CMS-Seiten). Hier bleiben wir bei der Mechanik der Platzierung.

Warum HTML-Blöcke statt Theme-Bearbeitung

Sie könnten themes/your-theme/templates/catalog/product.tpl öffnen und das Badge fest einprogrammieren. Es gibt zwei Gründe, das nicht zu tun. Erstens kann das nächste Theme-Update, oder eine erneute Synchronisierung des Child-Themes, Ihre Änderung überschreiben, und das Badge verschwindet unbemerkt. Zweitens ist eine Template-Änderung für alle unsichtbar, die keine Entwickler sind: Sie können sie nicht für eine Wochenendaktion deaktivieren oder den Text im Backoffice austauschen. Wenn der Inhalt über ein Modul wie ps_customtext oder ein spezielles HTML-Block-Modul erstellt wird, liegt er in der Datenbank und wird über das Hook-System von PrestaShop ausgegeben. Er übersteht also Updates, und Sie verwalten ihn unter Module oder Design, ohne eine Datei anzufassen. Was bringt Ihnen das konkret? Sie ändern eine Aktionsbotschaft morgens um 9 Uhr vor einem Blitzangebot und entfernen sie um Mitternacht wieder selbst, ohne Risiko für das Theme.

Die nativen Module, die das bereits können

Bevor Sie etwas kaufen, sollten Sie wissen: PrestaShop liefert drei kostenlose Module mit, die die häufigsten Fälle abdecken. In Standardinstallationen auf Basis von Classic sind sie in der Regel verfügbar und können, falls sie fehlen, über den Modulmanager installiert oder aktiviert werden:

Für die meisten Aufgaben nach dem Muster „Ich brauche nur einen Absatz HTML irgendwo im Shop“ ist ps_customtext die richtige Antwort. Öffnen Sie Module → Modulmanager, suchen Sie nach „custom text“, klicken Sie auf Konfigurieren, fügen Sie Ihr HTML in den Editor ein (wechseln Sie mit dem <>-Button in die Quellcode-/Codeansicht, wenn Sie sauberes Markup möchten) und speichern Sie. Standardmäßig wird es in displayHome ausgegeben. Der Haken, und der Grund, warum Händler irgendwann darüber hinauswachsen, ist: ps_customtext bietet Ihnen einen bearbeitbaren Block, der an einen Hook gebunden ist, ohne gezielte Ausspielung pro Seite und ohne Zeitplanung.

Positionen verstehen: die Hooks, die „überall“ bestimmen

„Überall“ bedeutet in PrestaShop nicht buchstäblich jedes Pixel, sondern jeden registrierten Hook. Ein Hook ist ein benannter Einfügepunkt, den das Theme beim Rendern einer Seite aufruft. Ein Modul, das an diesem Hook eingehängt ist, gibt dort seinen Inhalt aus. Jede Position sehen Sie unter Design → Positionen (ältere Versionen: Module → Positionen); dort werden alle Hooks und die aktuell darin transplantierten Module in Ausgabereihenfolge aufgelistet. Für eigene Inhalte sind vor allem diese Positionen wichtig:

• displayBanner, vollbreiter Streifen ganz oben, oberhalb des Headers. Der richtige Ort für shopweite Hinweisleisten und Meldungen zum Mindestbestellwert für kostenlosen Versand. Sichtbar vor dem Scrollen, auf jeder Seite.
• displayNav1 / displayNav2 / displayTop, im Header-Bereich (links/rechts der Navigation, obere Servicezeile). Gut für eine kurze Telefonnummer, einen Länder-/Versandhinweis oder eine schmale USP-Zeile.
• displayHome, der Inhalt der Startseite, zwischen Produktkarussells und Kategorie-Kacheln. Für Nutzenversprechen und hervorgehobene Aktionsbereiche.
• displayProductAdditionalInfo, auf der Produktseite direkt unter dem In-den-Warenkorb-Bereich. Hier verdienen Lieferzusagen, Garantie-Badges und Symbole für Zahlungsarten ihren Platz, weil der Käufer sie genau in dem Moment liest, in dem er noch zögert.
• displayFooterBefore / displayFooter, oberhalb und innerhalb des Footers, auf jeder Seite. Trust-Badges, Newsletter-Hinweise, sekundäre Links.
• displayLeftColumn / displayRightColumn, Seitenleisten (sofern Ihr Theme sie verwendet). Filterhilfen, Kategorieaktionen, Support-Hinweise.

Der praktische Weg, wenn Sie den Positionsnamen nicht kennen: Öffnen Sie die Seite, die Sie bearbeiten möchten, und nutzen Sie unter Design → Positionen die Funktion Modul transplantieren (Button „Ein Modul einhängen“), das Dropdown zeigt alle einhängbaren Positionen, und der Hilfetext beschreibt, wo sie ausgegeben werden. Innerhalb eines Hooks können Sie ein Modul außerdem nach oben oder unten ziehen, um zu steuern, ob Ihr Block zum Beispiel über oder unter dem Kategoriebanner steht.

Was native Blöcke nicht können, und warum Händler zu einem spezialisierten Modul greifen

Das native ps_customtext reicht aus, bis Sie etwas von dem brauchen, was echte Shops tatsächlich benötigen:

• Zielsteuerung pro Seite / pro Controller. „Diese Größentabelle nur in der Kategorie Schuhe anzeigen, nur auf Produktseiten.“ Native Blöcke werden überall dort ausgegeben, wo ihr Hook feuert; sie haben keinen Seitenfilter.
• Mehrere Platzierungen und Aktivierungssteuerung. Eine Leiste „Letzter Tag für Weihnachtslieferung“ sollte ein benannter Block sein, den Sie aktivieren, deaktivieren und verschieben können, ohne ein Template zu bearbeiten. Zeitfensterplanung ist eine separate Funktion; gehen Sie nicht davon aus, dass ein Block-Modul sie hat, wenn Sie im Backoffice keine Datumsfelder sehen.
• Mehrere unabhängige Blöcke im selben Hook. Eine ps_customtext-Instanz ist ein Block; fünf verschiedene Botschaften über fünf Positionen hinweg zu jonglieren, wird schnell unübersichtlich.
• Multishop-fähige Inhalte. Unterschiedliche Blockinhalte pro Shop/Sprache anzeigen, sofern das Modul Sprach- und Shop-Zeilen speichert. Zielsteuerung nach Kundengruppen ist eine separate Regelschicht, die der Standard-Textblock nicht bereitstellt.
• Einwilligungsbewusste Blöcke. Wenn der Block Tracking oder eingebettete Medien enthält, sorgt eine Cookie-Kategorie-Sperre dafür, dass er nur gerendert wird, wenn der Besucher diese Kategorie nicht abgelehnt hat.

Genau diese Lücke schließt ein spezialisiertes HTML-Block-Modul: eine Bibliothek benannter Blöcke, die jeweils einem oder mehreren Hooks zugewiesen werden, mit Platzierung nach Seitentyp, Layoutauswahl, mehrsprachigen und shopbezogenen Inhalten, Cookie-Kategorie-Steuerung und, in Modulen wie MPR HTML Blocks, Template-Injection für Positionen, an denen das Theme keinen brauchbaren Hook bereitstellt. Was haben Sie davon? Sie hören auf, Templates zu bearbeiten, und installieren nicht jedes Mal ein neues Modul, wenn das Marketing ein Banner möchte; Sie erstellen einen Block einmal und richten ihn auf den Hook oder Seitenbereich aus, in den er gehört. Wenn Sie seitenbewusste Inhalte und sauberere Platzierung brauchen, ist genau diese Fähigkeit der Schritt vom nativen Block zum spezialisierten Modul, dasselbe Prinzip, aber mit mehreren Blöcken, Platzierungsdatensätzen und Template-Injection, die im Backoffice verwaltet werden.

HTML so schreiben, dass es den Editor übersteht

Ein vermeidbarer Stolperstein: TinyMCE und die HTML-Filterung von PrestaShop können je nach Konfiguration nicht unterstütztes Markup umschreiben oder entfernen, der Rich-Text-Editor „räumt“ Markup auf, das er nicht erkennt, und Sicherheitsfilter können Inline-Styles entfernen oder Tags beim Speichern neu formatieren. Wenn Ihr Block nach dem Speichern verschwindet oder sein Styling verliert, ist das meist die Ursache. Die Lösungen, in der empfohlenen Reihenfolge:

Halten Sie das Markup des Blocks schlicht und klassenbasiert. Diese Art von Inhalt in der Quellcodeansicht übersteht die Bereinigung durch den Editor und überlässt das gesamte Styling dem Stylesheet des Themes.

<section class="promo-bar promo-bar--shipping">
  <p><strong>Free delivery this weekend.</strong> Orders over 75 EUR ship free until Monday.</p>
  <p><a href="/delivery">See delivery conditions</a></p>
</section>

Eine Storefront-Produktseite mit Inhalt im Tab Beschreibung.

• Schalten Sie im Editor in die Quellcode-Ansicht (Button <> / „Werkzeuge → Quellcode“) und fügen Sie das Markup dort ein, nicht in den WYSIWYG-Bereich.
• Legen Sie Styling in einer Klasse ab, nicht inline. Setzen Sie eine Klasse wie promo-bar auf Ihren Block und definieren Sie .promo-bar im benutzerdefinierten Stylesheet Ihres Themes, der Editor lässt Klassenattribute in Ruhe, und Sie erhalten den Vorteil updatefester Gestaltung, der in eigenem CSS und JavaScript ohne Update-Probleme beschrieben wird.
• Wenn ein Block JavaScript ausführen muss, binden Sie es über den passenden Asset-Hook ein, statt ein <script>-Tag in den Editor zu kopieren. Inline-Skripte in Inhaltsblöcken sind fragil und gehen beim Speichern leicht kaputt. Dieser Mechanismus ist ein eigenes Thema und wird im selben CSS/JS-Leitfaden behandelt.

Blöcke schnell und markenkonform halten

Zwei Design-Grundsätze entscheiden, ob ein Block hilft oder stört. Erstens: zum Theme passen. Verwenden Sie dieselbe Schriftfamilie, dieselbe Akzentfarbe und denselben Abstandsrhythmus, den Ihr Theme bereits nutzt, damit der Block wie ein Teil des Shops wirkt und nicht wie nachträglich angeklebt. Zweitens: kurz bleiben. Ein Banner ist ein Satz plus Handlungsaufforderung; eine Trust-Leiste besteht aus wiedererkennbaren Symbolen, nicht aus einem Absatz. Der Wert eines Blocks liegt darin, was er im richtigen Moment ergänzt, nicht darin, wie viel Sie hineinpacken.

Zur Performance: Jeder Block ist zusätzliches Markup, und bildlastige Blöcke sind meist die größten Gewichtstreiber. Liefern Sie korrekt dimensionierte, komprimierte Bilder aus, setzen Sie für Layout und Effekte auf CSS statt auf eine zusätzliche Bibliothek, und prüfen Sie bei mehreren gleichzeitig aktiven Blöcken deren gemeinsame Wirkung im Netzwerk-Panel Ihres Browsers. Seitengeschwindigkeit ist ein Signal, das Google berücksichtigt; ein Stapel aufgeblähter Banner kann also still gegen den Rest Ihrer On-Page-Arbeit arbeiten. Halten Sie das Markup schlank, dann bleibt der Vorteil ein Vorteil.

Eine schnelle Entscheidungshilfe

HTML-Blöcke lohnen sich deshalb, weil sie genau das ermöglichen, womit sie begonnen haben: Ein Shopbetreiber, nicht ein Entwickler, kann die richtige Botschaft zur richtigen Zeit an der richtigen Stelle platzieren und sie ebenso leicht wieder entfernen, ohne jemals das Theme zu riskieren. Lernen Sie die Positionsnamen, nutzen Sie für einfache Aufgaben die kostenlosen nativen Blöcke, greifen Sie zu einem spezialisierten Modul, sobald Sie mehrere Blöcke, seitenbewusste Platzierung oder theme-sichere Injection brauchen, und halten Sie jeden Block leicht und markenkonform. Dann beginnt eine Standardinstallation von PrestaShop genau in den Momenten mit der eigenen Stimme Ihres Shops zu sprechen, die einen Verkauf voranbringen.

Häufig gestellte Fragen

Bedeutet „überall“ wirklich jede beliebige Stelle auf der Seite?

Nicht buchstäblich. Gemeint ist jeder registrierte Hook. Ein Hook ist ein benannter Einfügepunkt, den das Theme beim Rendern einer Seite aufruft, und die Ausgabe Ihres Blocks erscheint dort, wo dieser Hook ausgeführt wird. Alle verfügbaren Positionen sehen Sie unter Design → Positionen. Wenn die exakte Stelle, die Sie möchten, keinen Hook hat, spielt die Template-Injection-Funktion eines spezialisierten Moduls ihre Stärke aus, weil sie Positionen ansprechen kann, die das Theme nie als Hook bereitgestellt hat.

Welches native Modul sollte ich für einen einfachen HTML-Block verwenden?

Für einen Absatz HTML verwenden Sie ps_customtext, suchen Sie im Modulmanager nach „custom text“, klicken Sie auf Konfigurieren und fügen Sie Ihr Markup ein (für sauberen Code nutzen Sie die <>-Quellcodeansicht). Für ein Bannerbild mit Link am oberen Rand jeder Seite verwenden Sie ps_banner; für Linklisten im Footer ps_linklist. Alle drei werden mit Classic-basierten Installationen kostenlos ausgeliefert und speichern Inhalte in der Datenbank, sodass sie Theme-Updates überstehen.

Wo platziere ich ein Trust-Badge oder ein Lieferversprechen auf der Produktseite?

Im Hook displayProductAdditionalInfo, der direkt unter dem In-den-Warenkorb-Bereich ausgegeben wird. Dort verdienen Garantie-Badges, Lieferzusagen und Symbole für Zahlungsarten ihren Platz, weil der Käufer sie genau in dem Moment liest, in dem er noch zögert. Hängen Sie Ihren Block dort über Design → Positionen → Modul transplantieren ein, statt product.tpl zu bearbeiten.

Mein Block hat nach dem Speichern sein Styling verloren oder ist verschwunden. Warum?

Fast immer liegt es daran, dass TinyMCE oder die HTML-Filterung von PrestaShop das Markup beim Speichern „aufräumt“, der Editor schreibt Tags um, die er nicht erkennt, und Sicherheitsfilter können Inline-Styles entfernen. Die Lösung: Fügen Sie Inhalte in die Quellcode-Ansicht des Editors ein, nicht in den WYSIWYG-Bereich, und legen Sie Styling in einer CSS-Klasse ab (definieren Sie .promo-bar im Stylesheet Ihres Themes), statt es inline zu setzen. Der Editor lässt Klassenattribute in Ruhe.

Wann reicht ps_customtext nicht mehr aus und ich brauche ein spezialisiertes Modul?

Sobald Sie eines davon benötigen: Zielsteuerung pro Seite oder pro Controller (z. B. eine Größentabelle nur in der Kategorie Schuhe), mehrere unabhängige Blöcke mit zentraler Verwaltung, Multishop- oder mehrsprachige Blockinhalte, Cookie-Einwilligungssteuerung für Blöcke mit Tracking oder eine Platzierung an einer Stelle, für die das Theme keinen Hook bereitstellt. ps_customtext gibt Ihnen einen Block an einem Hook ohne Seitenfilter, völlig in Ordnung, bis diese Anforderungen auftauchen.

Kann ich JavaScript in einem HTML-Block ausführen?

Kopieren Sie kein rohes <script>-Tag in den Editor. Inline-Skripte in Inhaltsblöcken sind fragil, gehen beim Speichern leicht kaputt und umgehen das Asset-Management von PrestaShop. Binden Sie das Verhalten stattdessen als externe .js-Datei über den passenden Asset-Hook ein, genau wie in eigenes CSS und JavaScript ohne Update-Probleme beschrieben. Beschränken Sie den Block auf Markup und eine CSS-Klasse.

Bremsen zu viele Blöcke den Shop aus?

Das kann passieren. Jeder Block ist zusätzliches Markup, und bildlastige Blöcke sind meist die größten Gewichtstreiber. Liefern Sie korrekt dimensionierte, komprimierte Bilder aus, setzen Sie für das Layout auf CSS statt auf eine zusätzliche Bibliothek, und prüfen Sie bei mehreren gleichzeitig aktiven Blöcken deren gemeinsame Kosten im Netzwerk-Panel Ihres Browsers. Seitengeschwindigkeit ist ein Signal, das Google berücksichtigt; ein Stapel aufgeblähter Banner kann also den Rest Ihrer On-Page-Arbeit still untergraben.

Verwandte Leitfäden

• Eigenes CSS und JavaScript in PrestaShop ohne Update-Probleme
• Anzeigenamen für CMS-Seiten: Bessere Navigation für Ihre statischen Seiten
• Child-Themes in PrestaShop: Warum Sie das Parent-Theme nie bearbeiten sollten