Naar de inhoud

Hoe je een hoeveelheidskortingtabel op je Shopify-productpagina toont (zonder SEO te beschadigen)

By Stackable TeamPublished on August 5, 2026Shopify How-To#quantity-breaks#volume-discounts
Hoe je een hoeveelheidskortingtabel op je Shopify-productpagina toont (zonder SEO te beschadigen)

Om een hoeveelheids- of volumekortingtabel op een Shopify-productpagina weer te geven, voeg je een thema-app-blok van een kortingsapp in de thema-editor toe, of codeer je de tabel handmatig in Liquid in je productsjabloon. De app-blok route is het no-code-pad: je plaatst het blok onder de toevoegen-aan-winkelwagen knop en het rendert een "koop meer, bespaar meer" niveautabel zonder themabestanden aan te raken. Het gedeelte dat werkelijk telt is wat er daarna gebeurt. De weergegeven tabel moet gesynchroniseerd blijven met de korting die zich bij het afrekenen voordoet, en het moet SEO-veilig weergegeven worden, zonder prijzen in koppelinglabels in te pakken die extra H1's creëren en stilletjes je rangschikking beschadigen. Zorg dat die twee dingen goed gaan en een niveautabel is een van de meest impactvolle toevoegingen die je aan een productpagina kunt maken. Zorg dat het fout gaat en je toont klanten prijzen die het afrekenen niet eert, op een pagina waarvan je koppelingstructuur je zojuist hebt verbroken.

Deze gids behandelt waarom een zichtbare niveautabel de gemiddelde orderwaarde verhoogt, de DIY Liquid-benadering en de onderhoudsvalkuilen die het verbreken, thema-app-blokken tegenover hardcodering, het echte SEO-gevaar van het weergeven van prijzen als koppelinglabels, Core Web Vitals overwegingen en een volledig uitgewerkt voorbeeld met een "hoeveelheid, prijs elk, je spaard" tabel die je kunt kopiëren.

Waarom een hoeveelheidskortingtabel op de productpagina weergeven?

Een hoeveelheidskortingsbreuk is een gestapelde korting: koop 3 en bespaar 10 procent, koop 6 en bespaar 15 procent, koop 12 en bespaar 20 procent. De korting kan perfect zonder enige storefront-weergave bestaan. Shopify zal het bij het afrekenen toepassen ongeacht of de klant het ooit ziet aankomen. Dat is precies het probleem. Een korting die de winkelier niet kan zien is een korting die hun gedrag niet kan veranderen.

De niveautabel is het merchandisering gedeelte van het aanbod. Het verandert een stille prijsregel in een zichtbare uitnodiging. Een klant die één eenheid wil kopen ziet, in duidelijke getallen, dat het kopen van drie de prijs per eenheid verlaagt, en het kopen van zes verlaagt het verder. Dat is een nudge naar een grotere winkelwagen, geplaatst op het exacte moment van beslissing, direct onder de toevoegen-aan-winkelwagen knop.

Er is een goed begrepen gedragsmatige reden waarom dit werkt. Een niveautabel stelt een anker in en toont dan het "je spaard" verschil ertegenaan. De winkelier evalueert niet langer één prijs in isolatie; ze vergelijken hun huidige keuze met een zichtbaar betere die één of twee eenheden weg is. Voor verbruiks-, stapelbare of geschenkvriendelijke producten beweegt die vergelijking betrouwbaar eenheden. Groothandels- en B2B-kopers verwachten een prijsbreekraster zonder meer en de afwezigheid ervan leest als een ontbrekende functie.

De valkuil is dat de tabel alleen helpt als winkeliers het vertrouwen. De eerste keer dat een klant "6 voor 34 dollar elk" op de productpagina ziet en dan 40 dollar elk bij het afrekenen wordt aangerekend, heb je niet alleen die bestelling verloren. Je hebt hun geleerd dat je prijzen niet echt zijn. Daarom kunnen de weergave en de kortingsmotor niet twee afzonderlijke systemen zijn die vandaag toevallig overeenkomen.

AFBEELDING PLACEHOLDER (Afbeelding 1): Een hoeveelheidskortingniveautabel op een productpagina
Voorgesteld visueel: Een schone 16:9 storefront mock-up van een Shopify-productpagina. Rechter kolom toont producttitel, prijs en een toevoegen-aan-winkelwagen knop. Direct onder de knop zit een 4-rij niveautabel met kolommen "Hoeveelheid," "Prijs elk" en "Je spaard." Rij drie (6 tot 11) is gemarkeerd in violet als het actieve niveautarief, met een kleine "Je spaard 15%" notitie. Neutrale product foto placeholder aan de linkerkant. Merkkleur violet en gouden accenten, plat modern design, geen echte logo's.

Wat zijn de manieren om een niveautabel op een Shopify-productpagina weer te geven?

Er zijn drie praktische routes, ruwweg in volgorde van meest handmatig tot meest onderhoudbaar.

Optie 1: codeer de tabel handmatig in Liquid

Je bewerkt je productsjabloon (of een sectie of snippet die het weergeeft) en schrijft de tabel markup zelf. Je codeert de niveauwaarden hardmatig als statische HTML, of je leest ze uit een productmetaveld en loop erover in Liquid zodat het gegevensgestuurd is. Dit geeft je totale controle over de markup en styling, en het is werkelijk het juiste antwoord voor een winkel met één of twee producten en een ontwikkelaar bij de hand.

De kost is onderhoud, en het is hoger dan het lijkt. Een hardmatig gecodeerde tabel is een tweede kopie van je prijzen die in je thema leeft, losgekoppeld van de korting die werkelijk draait. Elke keer dat je een niveautarief wijzigt, wijzig je het op twee plaatsen: de korting en het thema. Mis er één en de tabel liegt. Handelaren op de Shopify forums beschrijven exact dit patroon, het bouwen van een handgebouwde HTML-tabel voor de niveautarief weergave en het vervolgens strijden om het aangeligt met een kortingregel die ergens anders volledig leeft. Het werkt totdat het stilletjes niet doet.

Optie 2: een metaveld-gestuurde Liquid-tabel

Een robuustere DIY-versie slaat de niveaugegevens in een productmetaveld op en geeft het weer met een Liquid-lus, dus de tabel is gegevensgestuurd in plaats van hardmatig per product. Dit is beter; je bewerkt niveaus op één gestructureerde plaats. Maar je bezit nog steeds de rendering, de responsieve styling, de live-update JavaScript en cruciaal de taak om de metaveld waarden gelijk aan de waarden je korting gebruikt. Niets dwingt die gelijkheid af voor jou.

Optie 3: een thema-app-blok van een kortingsapp

De no-code route gebruikt Shopify's thema-app-extensie framework. Volgens Shopify's thema-app-extensie documentatie stellen deze extensies "kooplieden in staat om gemakkelijk dynamische elementen aan hun thema's toe te voegen zonder thema Liquid-sjablonen of code te hoeven interacteren," en de docs vermelden "prijzen, beoordelingen" onder de dynamische elementen waarvoor ze zijn gebouwd. Een niveautabel is precies dit soort element.

De app verzendt een app-blok. In de thema-editor open je je productsjabloon, klik op Blok toevoegen in een sectie, kies het app-blok van het niveautarief van de app en plaats het waar je wilt, meestal direct onder de toevoegen-aan-winkelwagen knop. Je bewerkt themacode nooit. Shopify's docs bevestigen dat kooplieden "app-blokken toevoegen, verwijderen en opnieuw ordenen op sectiëniveau" rechtstreeks in de editor kunnen, en dat app-blokken "stylingprop's erven van het thema, zoals typografie en kleuren," dus de tabel komt overeen met je lettertypen en design zonder aangepaste CSS.

Het belangrijkste structurele voordeel is dat een goed gebouwde app-blok zijn niveauwaarden leest uit dezelfde waarheidsbon als de korting, dus de weergave en de cassawiskunde kunnen niet drijven. Dat is het hele spel, en het is de reden waarom deze route voor de meeste winkels wint.

App-blokken tegenover app-embed-blokken: welke is de niveautabel?

Shopify's thema-app-extensie framework heeft twee soorten blokken, en het is het waard om te weten welke welke is, omdat de niveautabel één van hen is en niet de ander.

Een app-blok gebruikt target: section in zijn schema. Het is een zichtbaar, gepositioneerd element dat een koopman op een specifieke plaats in een sectie plaatst, en het kan wijzen naar dynamische bronnen zoals het huidige product. Volgens Shopify's configuratie docs worden app-blokken toegevoegd, verwijderd en opnieuw geordend in de thema-editor en kunnen "wijzen naar een dynamische bron om gegevens voor verschillende producten weer te geven naarmate ze op de pagina worden weergegeven." Dat laatste gedeelte is precies wat een niveautabel nodig heeft: het moet de niveaus voor welk product dan ook de pagina geeft weergeven. Dus de niveautabel is een app-blok.

Een app-embed-blok gebruikt target: head, compliance_head, of body. Shopify "geeft app-embed-blokken weer en voegt ze in vóór de afsluitende head- en body-tags," en ze zijn bedoeld voor zwevende of overlaid elementen zoals chatbubbles, badges en analyse- of SEO-tags, niet voor content die op een precieze plaats in de layout wordt geplaatst. App-embed-blokken zijn standaard uitgeschakeld en kooplieden schakelen ze in onder Thema-instellingen, App-embed-blokken. Een niveautabel is geen embed-blok, omdat het op een specifieke plaats in de productlay-out moet leven, niet over de pagina zweven.

Één voorbehoud dat in elke eerlijke gids hoort: app-blokken worden alleen ondersteund in Online Store 2.0 thema's, de thema's die JSON-sjablonen gebruiken. Shopify's onboarding docs stellen dat "app-blokken alleen worden ondersteund in thema's die JSON-sjablonen bevatten, ook bekend als Online Store 2.0 thema's." Als je op een veel ouder vintage thema bent, is de drag-and-drop blokplaatsing niet beschikbaar en ben je terug naar een Liquid-benadering of een thema-upgrade. De meeste winkels op een modern Shopify thema zijn al op Online Store 2.0.

AFBEELDING PLACEHOLDER (Afbeelding 2): Het app-blok van de niveautabel toevoegen in de thema-editor
Voorgesteld visueel: Een 16:9 screenshot-stijl mock-up van de Shopify thema-editor. Het linker deelvenster toont de sectiontree voor een productsjabloon met een "Blok toevoegen" affordance uitgevouwen, wat een app's "Hoeveelheid pauseringstrap" blok optie onder een Apps-kop onthult. Het midden toont de live productpreview met de niveautabel onder de toevoegen-aan-winkelwagen knop. Polaris-stijl adminchrome, violet accent op het geselecteerde blok. Raadpleeg het docs/screenshot-manifest.md sleuf volume-discounts-step-3 om het echte scherm later vast te leggen.

Waarom hardmatig gecodeerde niveautabellen stilletjes breken (de verzamelingsval)

Hier is de foutenmodus die de meest gefrustreerde forum berichten genereert, en het is geen bug in je tabelmarkup. Het is een mismatch tussen hoe je denkt dat de korting is bereikt en hoe Shopify werkelijk telt.

Zeg dat je een hardmatig gecodeerde tabel op een eettafelproductpagina bouwt: 3 tot 5 stoelen besparen 15 procent, 6 tot 9 besparen 18 procent, 10 of meer besparen 20 procent. Je ondersteunt het met een native Shopify-korting bereikt op je "Stoelen" verzameling. De tabel ziet er correct uit. Dan gaan twee dingen stilletjes fout.

Ten eerste tellen native verzameling-scoped kortingen totale eenheden in elk product in de verzameling, niet eenheden van de ene stoel op de pagina. Dus een winkelier kan je "koop 3" niveautarief activeren door één van elk van drie verschillende stoelen toe te voegen, wat niet wat de tabel op één enkele stoelpagina impliceert. De weergegeven tabel wordt geschreven vanuit het perspectief van één product; de korting doet verzamelingsrek. Ze beschrijven verschillende aanbiedingen.

Ten tweede verandert het lidmaatschap van de korting onder je. Op het moment dat je een nieuw product aan die verzameling toevoegt, of op het moment dat een product eruit valt, verschuift de set items die naar de drempel tellen. Handelaren hebben dit exact op de forums gemarkeerd: het toevoegen van een product aan een verzameling verandert stilletjes de kortinglogica, en niets waarschuwt je. Je hardmatig gecodeerde tabel toont nog steeds de oude niveaus. Het beschrijft nu een korting die niet langer in de vorm bestaat die de klant ziet.

Dit is de kernreden waarom een niveautabel geen statisch artefact mag zijn dat je handmatig onderhoudt. De tabel is een weergave van een korting. Als de korting bereik of lidmaatschap kan veranderen zonder de tabel aan te raken, zullen de twee afdrijven, en de afdrijving is onzichtbaar totdat een klant of je eigen testorder het oppervlakt. De fix is structureel: weergave per-product niveaus uit dezelfde definitie de korting gebruikt, en tel de manier waarop de tabel claimt te tellen, per product en zijn varianten, niet samengevoegd in een hele verzameling. Dat is het telmodus behandeld in per-product volumekortingen, en het is het verschil tussen een tabel die altijd waar is en één die waar is tot dinsdag.

De SEO val: geef nooit prijzen als koppelinglabels weer

Deze ene is een echt, gedocumenteerd mijnenveld, en het komt rechtstreeks uit de app-reviews. Een koopman merkte op dat een populaire kortingsapp zijn pagina-prijzen in koppelinglabels weergaf, wat meerdere conflicterende H1 elementen op elke productpagina creëerde, en ondersteuning weigerde het op te lossen. Dat is geen cosmetische klacht. Het is een SEO-regressie die in de widget is ingebakken.

Hier is waarom het telt. Zoekmachines gebruiken je koppelingstructuur om een pagina te begrijpen. De H1 is bedoeld om de enkele, primaire titel van de pagina te zijn, bijna altijd de productnaam. De rest van de koppelingen, H2 en H3, beschrijven de structuur eronder. Wanneer een kortingswidget "6 voor 34 dollar" in een

of

omdat dat een luie manier was om het getal groot en vet te maken, voegt het koppelingen in die semantisch niets betekenen en verdunnen de koppelingen die doen. Meerdere H1's op een pagina vertroeblelen het signaal over waar de pagina werkelijk over gaat. Prijzen en "je spaard" figuren zijn gegevens, geen documentstructuur. Ze horen in tabelcellen, spannen of paragrafen met CSS, nooit in koppelingelementen.

De juiste manier om een niveautabel weer te geven is vervelend correct HTML: een echte

(of een stijlvolle lijst) waarvan cellen de hoeveelheden en prijzen bevatten, met visueel gewicht toegepast via CSS, niet via koppelinglabels. De getallen kunnen er zo groot en vet uitzien als je ontwerper wil. Ze mogen gewoon niet doen alsof ze paginakoppelingen zijn. Shopify's eigen richtlijnen voor storefront-widgets in het thema-app-extensie framework wijzen in dezelfde richting, en intern is de regel die we onszelf inzetten eenvoudig: storefront-widgets moeten SEO-veilig zijn, zonder geïnjecteerde koppelinglabels en geen lay-outshift.

Als je een kortingsapp evalueert, is dit iets concreets om te controleren voordat je installeert. Bekijk de bron op een demoproductpagina, of voer het uit via je browser's toegankelijkheids- of SEO-inspecteur, en bevestig dat de widget geen koppelingelementen toevoegt. Het is een vijf-minuten test die je van een langzaam, moeilijk-te-diagnose rangschikking verlies redt. Het ontbreken van dit probleem marketing is eerlijk spel, omdat zoveel widgets het fout krijgen.

Core Web Vitals: een niveautabel mag je snelheid niet kosten

Een productpagina niveautabel is klein, maar het geeft op je hoogste-intentie, hoogste-verkeer pagina's samengesteld de prestatie kostencombinatie. Twee Core Web Vitals metreken zijn degenen om te kijken.

Cumulatieve Layout Shift (CLS) is de eerste. Een tabel die een moment na de rest van de pagina heeft geschilderd shooft de toevoegen-aan-winkelwagen knop omlaag en verzamelt lay-outshift. De fix is om de tabel server-side in de initiële HTML waar mogelijk weer te geven, dus de ruimte is gereserveerd van de eerste schildering, in plaats van het te injecteren laat met JavaScript nadat de pagina vereffent. Niveautabelwaarden staan vast bij render tijd; er is geen reden waarom het laatst hoeft aan te komen.

Largest Contentful Paint (LCP) en de algemene gewichtsbudget zijn de tweede. Een widget die een zware JavaScript-bundel laadt, zijn eigen webfont of een stuk framework code om wat fundamenteel een kleine tabel is te tekenen, geeft je snelheidsbudget zorgeloos uit. Shopify's thema-app-extensie framework helpt hier: wanneer een app-blok op een pagina aanwezig is, worden de stylesheet en het script eenmaal geladen via de framework's eigen tags, en als een koopman meerdere blokken toevoegt die naar hetzelfde bestand verwijzen, Shopify voegt dat bestand slechts eenmaal per pagina in. Een goede niveautabel leunt hierop, verzendt minimale CSS en JavaScript en doet het zware werk server-side.

Het live-update gedrag verdient ook een notitie. Een aardige niveautabel markeert het actieve niveautarief naarmate de winkelier de hoeveelheid wijzigt, zonder paginaherlaad. Die interactie is goedkoop wanneer het enkele regels vanilla JavaScript is die een klasse in- en uitschakelen, en duur wanneer het een framework re-render is. Houd het licht. Het doel van de tabel is meer eenheden te verkopen, en een pagina die langzaam is om mee te werken verkoopt minder.

Uitgewerkt voorbeeld: een "hoeveelheid, prijs elk, je spaard" tabel

Laten we een concrete bouwen. Een supplementmerk verkoopt een eiwittub voor 40 dollar. Ze willen opstapelen op dezelfde tub beloningen, geteld per product in haar smaken, met deze niveaus:

  • 1 tot 2 eenheden: volledige prijs
  • 3 tot 5 eenheden: 10 procent korting
  • 6 tot 11 eenheden: 15 procent korting
  • 12 of meer eenheden: 20 procent korting

De tabel op de productpagina, direct onder de toevoegen-aan-winkelwagen knop, leest als volgt. De "je spaard" kolom is wat de overtuiging doet.

Een winkelier die 6 tubes toevoegt ziet de "6 tot 11" rij markeren als hun actieve niveautarief, tegen 34 dollar elk, besparende 48 dollar tegen het kopen van zes tegen volledige prijs. De rij boven en beneden blijven zichtbaar, dus het volgende niveautarief ("gewoon zes meer en het daalt naar 32 elk") is altijd in beeld. Die zichtbare volgende stap is het mechanisme. Het is dezelfde reden waarom groothandels prijsrasters altijd als roosters zijn afgedrukt.

De twee regels uit de rest van deze gids zijn beide van toepassing op deze exacte tabel. Ten eerste moet de waarden in de "prijs elk" kolom waarden zijn die de korting werkelijk aanrekent, geteld per product in de smaken van de tub, niet samengevoegd met onverwante producten. Ten tweede mag geen van deze cellen een koppelinglabel zijn. De 34 dollar is een tabelcel gestijld om prominent uit te zien, niet een

. Volg die twee regels en deze tabel is veilig om op elke productpagina in de catalogus te verzenden.

Hoe je het instelt, stap voor stap

Hier is de betrouwbare volgorde voor de app-blok route, wat degene is die de meeste winkels zouden moeten gebruiken.

1. Bevestig dat je thema Online Store 2.0 is

App-blokken vereisen een JSON-sjabloon thema. Als je op een huidig Shopify thema bent, kom je bijna zeker in aanmerking. Als je op een vintage thema bent, plan je eerst een thema-upgrade, of gebruik je een Liquid-benadering in de tussentijd.

2. Definieer de niveaus eenmaal, in de korting

Stel je hoeveelheid onderbrekingen in op de korting zelf: de onderbrekingspunten, de per-eenheid prijzen of percentages, en de telmodus (tel deze productsvarianten samen, niet de hele verzameling). Dit is de enige waarheitsbon. Alles wat de klant ziet zou hieruit afgeleid moeten worden.

3. Voeg het app-blok niveautabel in de thema-editor toe

Open je productsjabloon in de thema-editor, kies Blok toevoegen in de productinformatie sectie en selecteer het app-blok niveautabel van de app. Sleep het direct onder de toevoegen-aan-winkelwagen knop. Omdat app-blokken de typografie en kleuren van het thema erven, moet het onmiddellijk met je design overeenkomen; pas alleen afstand of uitlijning aan als het blok deze instellingen stelt.

4. Controleer of de weergave gelijk is aan de afrekeneringswiskunde

Voeg het product aan een echte testwinkelwagen op een hoeveelheid die een niveaugrens kruist, bijvoorbeeld 6 eenheden, toe en bevestig dat de prijs die de tabel toonde de prijs is bij het afrekenen, ook via een versnelde afrekening zoals Shop Pay. Dit is de stap die afdrijving vóór klanten vangt.

5. Controleer de koppelingstructuur en lay-outstabiliteit

Bekijk de broncode van de productpagina en bevestig dat de widget geen koppelinglabels toevoegde en de toevoegen-aan-winkelwagen knop niet ronddroogde terwijl het laadde. Een snelle pas in een SEO- of toegankelijkheids inspector bevestigt één H1, de producttitel, met de niveautabel die in een tabel of lijst leeft, niet in koppelingen.

6. Test de verzamelingsrandgeval

Als je korting is bereikt, voeg een product toe aan de relevante verzameling of groep toe en verwijder en controleer opnieuw of de niveautabel op je doelproduct nog steeds de niveaus toont die je beoogt. Dit is waar handmatig onderhouden tabellen mislukken; een correct per-product-scoped aanbod doet niet.

AFBEELDING PLACEHOLDER (Afbeelding 3): De weergave en het afrekenen gaan akkoord
Voorgesteld visueel: Een 16:9 split illustratie. Linker paneel met het label "Productpagina" toont de niveautabel met de 6-unit rij gemarkeerd op $34.00 elk. Rechter paneel met het label "Afrekenen" toont dezelfde 6 eenheden aangerekend op $34.00 elk met een groen vinkje badge dat "Dezelfde prijs" leest. Een enkel ongebroken ketening pictogram bindt de twee panelen. Hieronder wordt een onderschrift strip "Één waarheitsbon: weergave equals afrekenen." Brand kleuren violet en goud, plat vector, geen fotografie.

Voer dit betrouwbaar uit met Stackable

Als je liever geen hardmatig gecodeerde tabel onderhoudt die van je korting afdrijft, of audit van een widget HTML voor dwaalse koppelinglabels, dit is het specifieke probleem Stackable werd gebouwd om te behandelen, eerlijk en binnen Shopify's echte regels.

  • De storefront niveautabel is een thema-app-blok dat je uit de thema-editor onder de toevoegen-aan-winkelwagen knop sleept. Geen themcode, en het erft je thema's lettertypen en kleuren dus het ziet natief uit.
  • De tabel leest zijn niveaus uit dezelfde kortingdefinitie als het afrekenen gebruikt, en telt per product en de geselecteerde varianten in plaats van een hele verzameling samen te voegen, dus wat de winkelier ziet is wat het afrekenen aanrekent. Wijzig een verzameling's inhoud en de per-product tabel blijft waar.
  • Het geeft SEO-veilig weer: prijzen zitten in een echte tabel, nooit in koppelinglabels, dus je houdt één H1 (je producttitel) en creëert niet het conflicterende-koppelingenprobleem dat app-review klachten elders heeft aangetrokken.
  • De tabel markeert het actieve niveautarief live naarmate de hoeveelheid verandert, met server-berekende waarden en geen lay-outshift, dus het blijft binnen je Core Web Vitals budget.
  • Omdat Stackable je productprijzen nooit herschrijft, bestaan de niveaus alleen als afrekenaangelegenheden. Verwijder en je catalogus en thema zijn precies zoals ze waren, met het blok netjes verwijderd.

Installeer Stackable gratis en zie de productpaginatabel en het afrekenen totaal akkoord naar de cent op usestackable.com/pricing.

De kernstelling

  • Een hoeveelheidsbreuk bestaat bij afrekenen met of zonder weergave, maar een korting die de klant niet kan zien kan de winkelwagen niet vergroten. De productpagina niveautabel is de merchandisering gedeelte van het aanbod.
  • Je kunt de tabel in Liquid handmatig coderen, hem van een metaveld aansturen, of een thema-app-blok toevoegen in de thema-editor. De app-blok is de no-code route en, wanneer goed gebouwd, blijft automatisch gesynchroniseerd met de korting.
  • De niveautabel is een app-blok (target: section), geen app-embed-blok, omdat het op een precieze plaats in de productlay-out moet zitten en gegevens voor het huidige product moet weergeven.
  • Hardmatig gecodeerde tabellen drijven af. Native verzameling-scoped kortingen tellen in de hele verzameling en veranderen wanneer je producten toevoegt of verwijdert, dus een statische tabel beschrijft stilletjes een aanbod dat niet langer bestaat.
  • Geef nooit prijzen in koppelinglabels weer. Dat creëert conflicterende H1's en beschadigt SEO, een echte, gedocumenteerde klacht over sommige kortingswidgets. Zet prijzen in tabelcellen gestijld met CSS.
  • Kijk naar Core Web Vitals: geef server-side weer om lay-outshift te vermijden, houd de JavaScript licht en vertrouw op het framework dat gedeelde assets eenmaal per pagina laadt.
  • De niet-onderhandelbare test is dat de weergegeven prijs gelijk is aan de afrekeningsprijs, ook via Shop Pay. Controleer het met een echte testorder over een niveaugrens voordat je het lanceert.

Gerelateerde artikelen

Veelgestelde vragen

Vind antwoorden op veelgestelde vragen

  • Voeg een thema-app-blok van een kortingsapp in de thema-editor toe, plaats het onder de toevoegen-aan-winkelwagen knop, of codeer de tabel handmatig in Liquid in je productsjabloon. De app-blok route vereist geen code en leest, in een goed gebouwde app, dezelfde niveauwaarden als het kassamenu gebruikt. De essentiële eis beide manieren is dat de weergegeven prijzen overeenkomen met wat het kassamenu in rekening brengt en dat de tabel geen koppelinglabels gebruikt.

  • Ja, als je thema Online Store 2.0 is en je gebruikt een kortingsapp die een thema-app-blok verzendt. Shopify's thema-editor laat je app-blokken visueel toevoegen, verwijderen en opnieuw ordenen, zonder themecode. Handmatig coderen van een tabel in Liquid vereist wel ontwikkelaarscomfort, en het voegt doorlopend onderhoud toe omdat de tabel dan los van de korting staat en handmatig moet worden gesynchroniseerd.

  • Alleen als het slecht is gebouwd. Het echte gevaar is een widget die prijzen in koppelinglabels weergeeft, wat extra H1 of H2 elementen creëert en de koppelingstructuur van je pagina verdunt. Een correct gebouwde tabel plaatst prijzen in tabelcellen of spannen met CSS, met één H1 (je producttitel). Controleer elke app door de bron van een demopagina te bekijken en bevestig dat er geen koppelingelementen worden toegevoegd.

Stackable Team

The team building Stackable, the reliability-first bulk and volume discount app for Shopify. We write about discount stacking, Shopify Functions, and how to run promotions that hold up at checkout.

We gebruiken essentiële cookies om deze site te laten werken en, alleen met uw toestemming, analytische cookies om verkeer te begrijpen. Lees ons Cookiebeleid.