Nach-oben-Button: Ein winziges UX-Detail, das überraschend wichtig ist

Aktualisiert im Juni 2026, die Umsetzungshinweise gelten für PrestaShop 1.7, 8 und 9. Das Standard-Theme Classic enthält weiterhin keinen Nach-oben-Button; der Code unten ist Vanilla-JS mit einer 44px großen Tippfläche auf Mobilgeräten.

Der Nach-oben-Button ist genau die Art Detail, die niemand bemerkt, bis sie fehlt, ein kleiner Pfeil in der Ecke, der einen Kunden nach langem Scrollen am Ende einer Seite zurück in den Kopfbereich bringt. Er wirkt zu unbedeutend, um sich lange damit zu beschäftigen. In einem PrestaShop-Shop, in dem Kategorie- und Produktseiten regelmäßig mehrere Tausend Pixel hoch sind, macht es jedoch einen echten Unterschied, ob dieser Button vorhanden ist: Der Kunde ist entweder einen Fingertipp von Ihrer Suchleiste entfernt oder er scrollt mühsam mit dem Daumen über den Handybildschirm, bis er aufgibt. In diesem Beitrag geht es darum, diesen Button speziell in PrestaShop richtig in Ihren Shop einzubauen: wo er im Theme hingehört, wie Sie ihn hinzufügen, ohne Dateien zu forken, die Sie beim nächsten Update bereuen, und welche wenigen Fehler aus einem hilfreichen Button ein Element machen, das Ihren „In den Warenkorb“-Button verdeckt.

Wenn Sie wissen möchten, warum dieser Button spürbar etwas bewegt, von Engagement-Daten bis zum Abbruchrisiko, haben wir das in Nach-oben-Button: kleine UX-Verbesserung, überraschende Wirkung ausführlich erklärt. Hier bleiben wir auf der praktischen Seite: Umsetzung, PrestaShop-Mechanik und die Entscheidungen, die über Gelingen oder Scheitern entscheiden.

Hat Ihr Theme bereits einen? Prüfen Sie das, bevor Sie bauen

Das erste PrestaShop-spezifische Detail: Viele moderne Themes bringen bereits einen Nach-oben-Button mit, und Sie sind möglicherweise kurz davor, einen zweiten einzubauen. Das Standard-Theme Classic in PrestaShop 1.7, 8 und 9 enthält keinen solchen Button ab Werk. Eine unveränderte Classic-Installation braucht ihn also zusätzlich. Die meisten kostenpflichtigen Themes (und Warehouse-abgeleitete Themes) haben ihn jedoch, meist als Option in der Theme-Konfiguration unter Design → Theme & Logo oder im Einstellungsmodul des Themes. Bevor Sie eine Zeile Code schreiben, scrollen Sie in Ihrem Live-Shop bis zum Ende einer langen Kategorieseite und beobachten Sie die Ecke. Wenn bereits ein Button eingeblendet wird, geht es um Konfiguration, nicht um Entwicklung.

Um zu prüfen, woher ein vorhandener Button stammt, öffnen Sie den Quelltext und suchen Sie nach typischen Markern: einem #back-to-top- oder .scroll-to-top-Element oder einem Template-Fragment in Ihrem Theme unter themes/<yourtheme>/templates/ (häufig in _partials/footer.tpl oder einer eigenen scroll-top.tpl). Wenn der Button dort vorhanden ist, aber nicht erscheint, ist die Theme-Option schlicht deaktiviert. Das ist ein Kontrollkästchen im Backoffice, kein Entwicklerticket.

Die drei Wege, einen Button in PrestaShop hinzuzufügen, und welchen Sie wählen sollten

Wenn Ihr Theme wirklich keinen Nach-oben-Button besitzt, haben Sie drei realistische Wege. Sie unterscheiden sich vor allem in einem Punkt, der in PrestaShop wichtiger ist als Bequemlichkeit: ob Ihre Änderung ein Theme- oder Core-Update übersteht.

Der Weg, den Sie vermeiden sollten, ist der verlockende: footer.tpl im aktiven Theme öffnen und Markup einfügen. Das funktioniert genau so lange, bis der Theme-Entwickler ein Update ausliefert; danach ist Ihre Änderung weg und Sie wissen nicht, warum. Wenn Sie Templates anfassen müssen, tun Sie das in einem Child-Theme. Warum diese Regel nicht verhandelbar ist, erklären wir in Child-Themes: Warum Sie das Parent-Theme niemals direkt bearbeiten sollten. Für die saubereren Ansätze ohne Template-Bearbeitung lesen Sie weiter.

Der saubere Weg: ein individueller HTML-Block plus ein paar Zeilen JS

Der Ansatz, bei dem Sie die Finger von Theme-Dateien lassen, besteht darin, das Markup des Buttons über einen HTML-Inhaltsblock einzufügen und sein Verhalten über die custom.js des Themes zu laden. Das Classic-Theme enthält themes/<yourtheme>/assets/js/custom.js (und daneben custom.css) für seitenweites JavaScript. Beachten Sie jedoch: Ob diese Dateien existieren und wie sie sich bei Updates verhalten, hängt vom jeweiligen Theme ab. Sie im aktiven Parent-Theme zu bearbeiten, ist weiterhin eine Bearbeitung von Theme-Dateien, und ein Theme-Update kann sie überschreiben, sofern Theme oder Anbieter sie nicht gezielt beibehalten. Für echte Update-Sicherheit nutzen Sie besser ein Child-Theme oder Assets, die über ein Modul registriert werden. Die komplette Disziplin für den sicheren Umgang damit, und warum sie besser ist als Änderungen an kompilierten Theme-Bundles, finden Sie in eigenes CSS und JavaScript in PrestaShop ohne Update-Probleme.

Für das Markup selbst sollten Sie kein <div> fest in ein Template schreiben. Ein eigener HTML-/Modulblock im Footer-Bereich erledigt die Aufgabe, verwenden Sie einen, der den Ziel-Hook unterstützt (für einen im Footer verankerten Button etwa ein Modul mit Hook auf displayFooter oder displayBeforeBodyClosingTag), oder bauen Sie ein kleines eigenes Modul. Denken Sie daran: Markup kann nur in Hooks eingefügt werden, die ein Modul unterstützt und die das Theme tatsächlich rendert, nicht buchstäblich überall im Shop. Die Mechanik zum Platzieren eigener Blöcke behandeln wir in HTML-Blöcke: eigene Inhalte überall in Ihrem PrestaShop-Shop einfügen. Der Button selbst ist nur ein zugänglicher Anker oder ein Button-Element; JavaScript steuert, wann er erscheint, und übernimmt das sanfte Scrollen.

Eine minimale, zugängliche Umsetzung besteht tatsächlich aus rund fünfzehn Zeilen. Sie ist kein Performance-Problem und sollte Vanilla-JS sein (das Classic-Theme bündelt zwar weiterhin jQuery, aber sich darauf zu verlassen ist fragil, viele schlankere Drittanbieter-Themes entfernen oder verzögern es, gehen Sie also nicht davon aus, dass $() verfügbar ist):

• Markup: ein echtes <button type="button" id="back-to-top" aria-label="Back to top"> mit Pfeilzeichen oder SVG darin. Niemals ein bloßes <div>, denn ein div ist weder fokussierbar noch wird es Screenreadern korrekt angekündigt.
• Nach dem Scrollen anzeigen: ein Scroll-Listener, der eine visible-Klasse hinzufügt, sobald window.scrollY ungefähr 300–500px überschreitet (etwa eine Viewport-Höhe). Drosseln Sie den Listener, damit er nicht bei jedem einzelnen Pixel auslöst.
• Sanft zurückkehren: window.scrollTo({ top: 0, behavior: 'smooth' }) beim Klick, eine Zeile, nativ, ohne Animationsbibliothek.

Hier ist die komplette Variante, Markup, gedrosseltes Ein-/Ausblenden und natives sanftes Scrollen. Sie ist Vanilla, hängt von nichts ab und respektiert die Bewegungseinstellungen des Besuchers:

<!-- markup: a real button, focusable and announced -->
<button type="button" id="back-to-top" aria-label="Back to top">↑</button>

#back-to-top {
  position: fixed;
  right: 1rem;
  bottom: 1rem;           /* raise this if a cookie bar / chat sits here */
  width: 48px;
  height: 48px;          /* 44px+ tap target on mobile */
  opacity: 0;
  visibility: hidden;
  transition: opacity .2s ease;
  z-index: 1030;       /* deliberate, below banner/chat – test it */
}
#back-to-top.is-visible { opacity: 1; visibility: visible; }

const btn = document.getElementById('back-to-top');
let ticking = false;

window.addEventListener('scroll', () => {
  if (ticking) return;            // throttle to one check per frame
  ticking = true;
  window.requestAnimationFrame(() => {
    btn.classList.toggle('is-visible', window.scrollY > 400);
    ticking = false;
  });
}, { passive: true });

btn.addEventListener('click', () => {
  const reduce = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
  window.scrollTo({ top: 0, behavior: reduce ? 'auto' : 'smooth' });
});

passive: true beim Scroll-Listener und die Drosselung über requestAnimationFrame sind die zwei Details, die diese Funktion vom Haupt-Thread Ihres Shops fernhalten; die Prüfung auf reduzierte Bewegung beim Klick ist eine Barrierefreiheitsrücksicht, die nur eine Zeile kostet. Registrieren Sie dieses JS über einen Modul-Hook als externe Datei, statt es inline einzufügen.

Das Ganze in ein kleines, gezielt gebautes Modul zu verpacken statt in lose Dateien, hat einen wichtigen Vorteil: Es begleitet Sie über mehrere Shops hinweg und ist nicht an den Lebenszyklus eines einzelnen Themes gebunden. Das ist derselbe Grund, aus dem man Scroll-Animationen besser als verwaltete Ebene umsetzt statt als verstreute Inline-Skripte, der Button und dezente Scroll-Bewegungen gehören zur gleichen Familie von Frontend-Feinschliff, der Ihr Theme nicht forken sollte.

Die PrestaShop-spezifischen Stolperfallen, die wirklich Probleme machen

Ein runder Zurück-nach-oben-Button sitzt in der unteren rechten Ecke einer Produktseite im Shop.

Der Button selbst ist trivial. Was in echten PrestaShop-Shops kaputtgeht, ist alles, womit er sich die untere rechte Ecke teilt. PrestaShop-Installationen sammeln schwebende Widgets an, und sie alle beanspruchen denselben Raum.

• Cookie-Einwilligung und DSGVO-Banner. Die in PrestaShop-Shops üblichen Einwilligungs- und Cookie-Law-Module, ob rechtliches Compliance-Add-on oder Drittanbieter-CMP, docken typischerweise am unteren Rand des Viewports an. Ein Nach-oben-Button, der sie ignoriert, landet entweder hinter dem Banner oder liegt über dem „Akzeptieren“-Button. Positionieren Sie den Button unten rechts und geben Sie dem Banner den vollbreiten unteren Streifen, oder heben Sie den Button um die Bannerhöhe an, solange das Banner sichtbar ist.
• Live-Chat-Widgets (Crisp, Messenger, tawk.to). Diese sitzen fast immer unten rechts, genau dort, wo die Konvention den Nach-oben-Button erwartet. Kämpfen Sie nicht dagegen an: Stapeln Sie den Button oberhalb der Chat-Blase mit zusätzlichem bottom-Abstand, damit ein Kunde nie zwischen „mit uns sprechen“ und „nach oben gehen“ wählen muss.
• Der z-index-Stapelkonflikt. Das ist der mit Abstand häufigste Fehler. Chat-Widgets und Einwilligungsmodule setzen oft sehr hohe z-index-Werte, sodass Ihr Button darunter gerendert werden kann. Sichtbar, aber nicht anklickbar, was schlimmer ist als gar kein Button. Setzen Sie bewusst einen z-index und testen Sie den Button wirklich per Klick auf dem Handy, während Cookie-Banner und Chat gleichzeitig aktiv sind, nicht auf einer sauberen Staging-Seite, auf der beides fehlt.
• Sticky Header ändern die Rechnung. Viele PrestaShop-Themes (und die Sticky-Header-Optionen kostenpflichtiger Themes) halten Navigation, Suche und Warenkorb beim Scrollen oben angeheftet. Wenn Ihr Theme das tut, ist der Button weniger zwingend, Suche und Warenkorb bleiben bereits erreichbar, , aber er lohnt sich trotzdem, um schnell zurück zum Hero-Bereich, zu den Filtern am Anfang einer Kategorie oder zum Anfang eines langen Blogbeitrags zu springen. In einem Theme mit Sticky Header sollte der Button etwas kleiner und zurückhaltender sein; er ist eine Komfortfunktion, keine Rettungsleine.

Wo er sich in einem PrestaShop-Shop wirklich bezahlt macht

Nicht jede Seite braucht ihn gleichermaßen. Der Button bringt genau dort am meisten, wo PrestaShop-Seiten am längsten werden. Es lohnt sich zu wissen, welche Seiten das sind, damit Sie ihn dort prüfen, wo es zählt:

• Mobilgeräte, vor allem. Der kleinere Viewport bedeutet mehr Scrollen für denselben Inhalt. Ein Nutzer am Handy legt auf derselben Kategorieseite deutlich mehr Bildschirmhöhen zurück als ein Desktop-Nutzer. Wenn der Button nur auf einem Gerät perfekt sein kann, dann auf Mobilgeräten, und halten Sie dort die Mindest-Tippfläche von 44–48px ein.
• Lange Kategorieseiten mit über 30 Produkten, facettierter Suche, Endlos-Scrollen oder tiefer Paginierung. Wenn ein Kunde Produkt Nr. 35 erreicht, ist der Kopfbereich tatsächlich Tausende Pixel entfernt.
• Inhaltsreiche Produktseiten mit langen Beschreibungen, Spezifikationstabellen, Bewertungen und Cross-Selling-Karussells, solche Seiten überschreiten regelmäßig 5.000px.
• Blog- und CMS-Seiten. Ihre statischen und redaktionellen Inhalte haben oft den tiefsten Scrollbereich der gesamten Website. Wenn Sie diese Seiten verbessern, lohnt sich auch ein Blick auf die CMS-Navigation selbst: Klarere Menübezeichnungen für statische Seiten helfen Kunden, die nach oben zurückscrollen, tatsächlich den nächsten sinnvollen Einstieg zu finden. Das behandeln wir in CMS-Seiten-Anzeigenamen: bessere Navigation für Ihre statischen Seiten.

Das Verhalten richtig einstellen

Welchen Weg Sie auch wählen: Dieselben kleinen Details trennen einen Button, der sich nativ anfühlt, von einem, der nachträglich angeklebt wirkt:

• Erst nach dem Scrollen anzeigen. Ganz oben auf der Seite ist er bedeutungsloses Durcheinander. Blenden Sie ihn ein, sobald der Kunde ungefähr eine Viewport-Höhe nach unten gescrollt hat.
• Sanft scrollen, nicht teleportieren. Ein sofortiger Sprung nach oben ist desorientierend. Der Kunde erkennt nicht, ob er gescrollt hat oder auf einer neuen Seite gelandet ist. Ein sanftes Scrollen über 300–500 ms erhält das räumliche Gefühl.
• Einblenden statt hüpfen. Ein dezentes Ein- und Ausblenden über etwa 200 ms wirkt sauber. Hüpfende, gleitende oder pulsierende Animationen ziehen Aufmerksamkeit auf sich, die der Button nicht verdient; er soll auffindbar sein, nicht ablenken.
• Von Anfang an barrierefrei. Ein echtes <button> oder <a> (fokussierbar und angekündigt), ein aria-label, ein sichtbarer Tastatur-Fokusring und genügend Kontrast zum jeweiligen Seitenhintergrund, über dem der Button schwebt. Das kostet beim Aufbau nichts und ist später mühsam nachzurüsten.

Sollten Sie ihn messen?

Sie können das tun, und in einem gut besuchten Shop lohnt sich der geringe Aufwand: Lösen Sie bei jedem Klick auf den Button ein Analytics-Event aus. So sehen Sie, welcher Anteil der Sitzungen auf langen Seiten ihn tatsächlich nutzt und welche Seiten die meisten Klicks erzeugen. Meist ein nützlicher Hinweis auf „das sind meine tiefsten, am stärksten genutzten Seiten“. Betrachten Sie jeden Prozentsatz, den Sie anderswo lesen, als grobe Orientierung, nicht als Zielwert; die ehrliche Zahl hängt vollständig davon ab, wie lang Ihre Seiten sind und wie sich Ihre Kunden verhalten. Lesen Sie sie also in Ihrem eigenen Shop ab, statt einer Blog-Zahl zu vertrauen.

Der Nach-oben-Button ist eine seltene Sache in der Shop-UX: eine Verbesserung mit nahezu keinem Nachteil. Er kostet ein paar Zeilen, verbraucht vernachlässigbare Ressourcen, hilft den Kunden, die ihn brauchen, und bleibt für alle anderen unsichtbar. In PrestaShop kann man ihn eigentlich nur falsch umsetzen, wenn man ihn sorglos anklebt, indem man das Parent-Theme bearbeitet, sodass er beim nächsten Update verschwindet, oder ihn in eine Ecke setzt, die bereits von Cookie-Banner und Chat-Widget beansprucht wird. Fügen Sie ihn sauber hinzu, an einer Stelle, die Updates übersteht, und testen Sie ihn dort, wo die schwebenden Widgets tatsächlich aktiv sind. Danach können Sie ihn vergessen, und genau das sollte ein gutes UX-Detail ermöglichen.

Häufig gestellte Fragen

Enthält das Standard-Theme von PrestaShop einen Nach-oben-Button?

Nein. Das Classic-Theme in PrestaShop 1.7, 8 und 9 wird ohne einen solchen Button ausgeliefert; eine unveränderte Classic-Installation braucht ihn also zusätzlich. Viele kostenpflichtige und Warehouse-abgeleitete Themes enthalten ihn jedoch, meist als Option in den Theme-eigenen Einstellungen. Bevor Sie etwas bauen, scrollen Sie in Ihrem Live-Shop bis zum Ende einer langen Kategorieseite, wenn bereits ein Button eingeblendet wird, müssen Sie im Backoffice ein Kontrollkästchen aktivieren, keinen Code schreiben.

Wie füge ich ihn am saubersten hinzu, ohne Updates zu gefährden?

Legen Sie das Markup in einen HTML-Block im Backoffice an einem Footer-Hook wie displayFooter oder displayBeforeBodyClosingTag ab und registrieren Sie das JavaScript über ein kleines Modul als externe Datei. Im Theme-Baum wird nichts bearbeitet, also kann ein Theme-Update es nicht löschen. footer.tpl im aktiven Parent-Theme zu bearbeiten, ist der Weg, den Sie vermeiden sollten; wenn Sie Templates anfassen müssen, tun Sie es in einem Child-Theme.

Sollte ich jQuery für die Scroll-Logik verwenden?

Nein, schreiben Sie sie in Vanilla-JavaScript. Das Classic-Theme bündelt zwar weiterhin jQuery, aber viele schlankere Drittanbieter-Themes entfernen oder verzögern es, daher können Sie nicht davon ausgehen, dass $() verfügbar ist. Der gesamte Button braucht rund fünfzehn Zeilen reines JS: einen gedrosselten Scroll-Listener, der ab etwa 400px eine Sichtbarkeitsklasse umschaltet, und window.scrollTo({ top: 0, behavior: 'smooth' }) beim Klick. Keine Bibliothek nötig.

Mein Button ist sichtbar, aber ich kann ihn nicht anklicken. Warum?

Das ist der häufigste Fehler, ein z-index-Stapelkonflikt. Chat-Widgets und Einwilligungsbanner setzen oft sehr hohe z-index-Werte, sodass Ihr Button darunter gerendert wird: sichtbar, aber nicht anklickbar, was schlimmer ist als gar kein Button. Setzen Sie bewusst einen z-index und testen Sie den Button wirklich per Klick auf dem Handy, während Cookie-Banner und Chat gleichzeitig aktiv sind, nicht auf einer sauberen Staging-Seite, auf der beides fehlt.

Wie verhindere ich, dass er mein Cookie-Banner oder die Chat-Blase verdeckt?

Alle drei wollen in die untere rechte Ecke. Geben Sie dem Einwilligungsbanner den vollbreiten unteren Streifen und lassen Sie den Button in der Ecke, oder erhöhen Sie den bottom-Abstand des Buttons, solange das Banner sichtbar ist. Bei einer Chat-Blase platzieren Sie den Button mit zusätzlichem Abstand darüber, damit ein Kunde nie zwischen „mit uns sprechen“ und „nach oben gehen“ wählen muss. Prüfen Sie das immer mit beiden aktiven Widgets.

Ab welcher Scroll-Distanz sollte der Button erscheinen?

Ungefähr nach einer Viewport-Höhe, also etwa 300–500px weiter unten. Ihn ganz oben auf der Seite anzuzeigen, ist bedeutungsloses Durcheinander; ihn erst nach dem Scrollen einzublenden, lässt ihn bewusst wirken. Drosseln Sie den Scroll-Listener (ein requestAnimationFrame-Guard plus ein passiver Listener), damit die Prüfung höchstens einmal pro Frame läuft und den Haupt-Thread nicht belastet.

Muss er barrierefrei sein, und wie?

Ja, und das lässt sich beim Aufbau mit wenig Aufwand richtig machen. Verwenden Sie ein echtes <button> oder <a> statt eines gestylten <div>, damit es fokussierbar ist und angekündigt wird, ergänzen Sie ein aria-label="Back to top", behalten Sie einen sichtbaren Tastatur-Fokusring bei, sorgen Sie für ausreichend Kontrast zum Seitenhintergrund und respektieren Sie prefers-reduced-motion, indem Sie auf einen sofortigen Sprung zurückfallen. Das später nachzurüsten ist deutlich mühsamer, als es von Anfang an einzubauen.

Lohnt sich der Button noch, wenn mein Theme einen Sticky Header hat?

Er ist weniger unverzichtbar, aber weiterhin nützlich. Ein Sticky Header hält Suche und Warenkorb erreichbar, daher ist der Button keine Rettungsleine, aber er hilft Kunden weiterhin, zurück zum Hero-Bereich, zu den Filtern am Anfang einer Kategorie oder zum Anfang eines langen Blogbeitrags zu springen. In einem Theme mit Sticky Header sollte der Button etwas kleiner und zurückhaltender sein, damit er als Komfortfunktion wirkt und nicht als konkurrierendes fixiertes Element.

Verwandte Leitfäden

• Nach-oben-Button: kleine UX-Verbesserung, überraschende Wirkung
• Eigenes CSS und JavaScript in PrestaShop ohne Update-Probleme
• Scroll-Animationen: dezente Bewegung auf Ihren Shop-Seiten hinzufügen