Spring til indhold

Sådan viser du en rabattabel efter mængde på din Shopify-produktside (uden at ødelægge SEO)

By Stackable TeamPublished on August 5, 2026Shopify How-To#quantity-breaks#volume-discounts
Sådan viser du en rabattabel efter mængde på din Shopify-produktside (uden at ødelægge SEO)

For at vise en mængde- eller volumen-rabattabel på en Shopify-produktside, tilføjer du enten en tema-app-blok fra en rabatapp i tema-editoren, eller du koderer tabellen manuelt i Liquid i dit produktskabelon. App-blok-ruten er den kodeløse vej: du dropper blokken under tilføj-til-kurv-knappen, og den gengiver en "køb mere, spar mere" niveautabel uden at røre temafiler. Den del, der faktisk betyder noget, er hvad der sker efter du placerer det. Den viste tabel skal forblive synkroniseret med den rabat, der udløser ved checkout, og den skal gengives SEO-sikker, uden at omslutter priser i overskriftsmærker, der skaber ekstra H1'er og stillevolist skader dine rangeringer. Få disse to ting rigtige, og en niveautabel er en af de højest-influence tilføjelser, du kan lave til en produktside. Få dem forkert, og du viser kunder priser, som checkout ikke vil honorere, på en side, hvis overskriftsstruktur du lige har brudt.

Denne guide dækker hvorfor en synlig niveautabel øger gennemsnitlig ordreværdi, gør-det-selv Liquid-tilgangen og vedligeholdelsesfalder, der bryder den, tema-app-blokke versus manuel-kodning, den rigtige SEO-fare ved at gengive priser som overskriftsmærker, Core Web Vitals-overvejelser, og et fuldt udarbejdet eksempel med en "mængde, pris hver, du sparer" tabel, du kan kopiere.

Hvorfor vise en rabattabel efter mængde på produktsiden overhovedet?

En rabat efter mængde er en niveaurabat: køb 3 og spar 10 procent, køb 6 og spar 15 procent, køb 12 og spar 20 procent. Rabatten kan eksistere perfekt uden nogen butiksfrontvisning. Shopify vil anvende det ved checkout uanset om kunden nogensinde ser det kommer. Det er præcis problemet. En rabat, som kunden ikke kan se, er en rabat, der ikke kan ændre deres adfærd.

Niveautabellen er merchandising-halvdelen af tilbuddet. Den omdanner en stille prisregel til en synlig invitation. En kunde, der kom for at købe en enhed, ser i almindelige tal, at køb af tre falder prisen pr. enhed, og køb af seks falder det yderligere. Det er en nudge mod en større kurv, placeret på det nøjagtige tidspunkt for beslutning, direkte under tilføj-til-kurv-knappen.

Der er en velforståelse atfærdsmæssig grund til, at dette virker. En niveautabel sætter et anker og viser derefter "du sparer" delta mod det. Shopperen evaluerer ikke længere en pris isoleret; de sammenligner deres aktuelle valg med et synligt bedre, der er en eller to enheder væk. For forbrugbar, lagerbar eller gavevenlig produkter, at sammenligning pålideligt flytter enheder. Engros- og B2B-køber forventer et prisnedbrydelsesgitter som en naturlig sag, og fraværet af det læses som en manglende funktion.

Fangen er, at tabellen kun hjælper, hvis handlende stoler på den. Første gang en kunde ser "6 til 34 dollar hver" på produktsiden og derefter bliver opkrævet 40 dollar hver ved checkout, har du ikke bare mistet den ordre. Du har lært dem, at dine priser ikke er virkelige. Hvilket er hvorfor displayet og rabat-motoren ikke kan være to separate systemer, der bare tilfældigvis er enige i dag.

BILLEDE PLACEHOLDER (Billede 1): En rabattabel efter mængde på en produktside
Foreslået billede: En ren 16:9 butiksfrontmockup af en Shopify-produktside. Højre kolonne viser produkttitel, pris og en tilføj-til-kurv-knap. Direkte under knappen sidder en 4-rækket niveautabel med kolonner "Mængde," "Pris hver," og "Du sparer." Tabelrække tre (6 til 11) er fremhævet i violet som det aktive niveau, med en lille note "Du sparer 15 procent." Neutral produktfoto placeholder til venstre. Brand-farver violet og guldaccenter, fladt moderne UI, ingen rigtige logoer.

Hvad er måderne at vise en niveautabel på en Shopify-produktside?

Der er tre praktiske ruter, i ret rækkefølge fra mest manuel til mest vedligeholdelig.

Mulighed 1: Manual-kodér tabellen i Liquid

Du redigerer dit produktskabelon (eller en sektion eller snippet det gengiver) og skriver tabellen markup selv. Du enten hard-kodér niveau værdierne som statisk HTML, eller læs dem fra en produkt metafield og løkke over dem i Liquid, så det er datadrevet. Dette giver dig total kontrol over markup og styling, og det er ægte det rigtige svar for en butik med et eller to produkter og en udvikler på standby.

Omkostningen er vedligeholdelse, og den er højere end den ser ud. En hard-kodet tabel er en anden kopi af din prissætning, der lever i dit tema, afbrudt fra den rabat, der faktisk køres. Hver gang du ændrer et niveau, ændrer du det to steder: rabatten og temaet. Gå glip af en, og tabellen løgner. Handlende på Shopify-forumene beskriver præcis dette mønster, bygger en håndbygget HTML-tabel til niveau-displayet og kæmper derefter for at holde den justeret med en rabat-regel, der bor et helt andet sted. Det virker indtil dagen, det stille ikke gør.

Mulighed 2: en metafield-dreven Liquid-tabel

En mere robust gør-det-selv version gemmer niveau-dataene i en produkt metafield og gengiver det med en Liquid-løkke, så tabellen er datadrevet i stedet for hard-kodet pr. produkt. Dette er bedre; du redigerer niveauer på et struktureret sted. Men du ejer stadig renderingen, responsiv styling, live-update JavaScript, og afgørende jobbet med at holde metafield-værdierne lige med værdierne dine rabat bruger. Intet håndhæver denne lighed for dig.

Mulighed 3: en tema-app-blok fra en rabatapp

Den kodeløse rute bruger Shopify's tema-app-udvidelsesframework. Ifølge Shopify's tema-app-udvidelsesdokumentation, disse udvidelser "gør det muligt for handlende at nemt tilføje dynamiske elementer til deres temaer uden at skulle interagere med Liquid-skabeloner eller kode," og dokumenterne viser "priser, ratings" blandt de dynamiske elementer de er bygget til. En niveautabel er præcis denne slags element.

Appen leverer en app-blok. I tema-editoren åbner du dit produktskabelon, klikker Tilføj blok i en sektion, vælger appens niveautabel-blok, og placerer det hvor du vil, typisk direkte under tilføj-til-kurv-knappen. Du redigerer aldrig temakode. Shopify's dokumenter bekræfter handlende kan "tilføje, fjerne og omordne app-blokke på sekationsniveau" direkte i editoren, og at app-blokke "arver styling-egenskaber fra temaet, såsom typografi og farver," så tabellen matcher dine skrifttyper og design uden brugerdefineret CSS.

Den vigtige strukturelle fordel er, at en vel bygget app-blok læser sine niveau værdier fra samme sandhedskilde som rabatten, så displayet og checkout-matematik ikke kan forlade sig. Det er hele spillet, og det er grunden til, at denne rute vinder for de fleste butikker.

App-blokke vs app-embed-blokke: hvilken er niveautabellen?

Shopify's tema-app-udvidelsesframework har to slags blokke, og det er værd at vide, hvilken der er hvilken, fordi niveautabellen er en af dem og ikke den anden.

En app-blok bruger target: section i dets skema. Det er et synligt, placeret element, som en handlende dropper ind i et specifikt sted i en sektion, og det kan pege på dynamiske kilder som det aktuelle produkt. Per Shopify's konfigurationsdokumentation, app-blokke tilføjes, fjernes og omordnes i tema-editoren og kan "pege på en dynamisk kilde til at vise data for forskellige produkter, når de vises på siden." Det sidste bit er præcis hvad en niveautabel skal bruge: det skal vise niveauer for uanset hvilket produkt siden gengiver. Så niveautabellen er en app-blok.

En app-embed-blok bruger target: head, compliance_head, eller body. Shopify "gengiver og injicerer app-embed-blokke før de lukkende head og body mærker," og de er beregnet til flydende eller overlaid elementer som chatbobler, badges og analyse eller SEO-mærker, ikke til indhold placeret på et præcist punkt i layoutet. App-embed-blokke er deaktiverede som standard og handlende slår dem til under Tema-indstillinger, App-embeds. En niveautabel er ikke en embed-blok, fordi den skal leve på et specifikt sted i produktlayoutet, ikke svæve over siden.

Et forbehold, der hører til i hver ærlig guide: app-blokke understøttes kun i Online Store 2.0 temaer, dem der bruger JSON-skabeloner. Shopify's onboarding-dokumentation angiver at "app-blokke kun understøttes i temaer, der indeholder JSON-skabeloner, også kendt som Online Store 2.0 temaer." Hvis du er på et meget ældre tema, vil træk-og-slip-blok-placeringen ikke være tilgængelig og du er tilbage til en Liquid-tilgang eller en tema-opgradering. De fleste butikker på et moderne Shopify-tema er allerede på Online Store 2.0.

BILLEDE PLACEHOLDER (Billede 2): Tilføjelse af niveautabel-app-blokken i tema-editoren
Foreslået billede: En 16:9 screenshot-stil mockup af Shopify tema-editoren. Venstre panel viser sektion-træet for et produktskabelon med en "Tilføj blok" affordance udvidet, der afslører en apps "Rabattabel efter mængde" blok mulighed under en Apps overskrift. Center viser live produktforhåndsvisning med niveautabellen dukker op under tilføj-til-kurv-knappen. Polaris-stil admin chrome, violet accent på den valgte blok. Referér til dokumenter/screenshot-manifest.md slot volume-discounts-step-3 til at fange det virkelige skærmbillede senere.

Hvorfor manuel-kodede niveautabel stille bryder (samlings-fælden)

Her er fejltilstanden, der genererer de mest frustrerede forumposter, og det er ikke en bug i dine tabellen markup. Det er et mismatch mellem hvordan du tror rabatten er omfattet og hvordan Shopify faktisk tæller.

Sig at du bygger en manuel-kodet tabel på en spisestol produktside: 3 til 5 stole sparer 15 procent, 6 til 9 sparer 18 procent, 10 eller mere sparer 20 procent. Du ens det tilbage med en indfødt Shopify rabat omfattet til din "Stole" samling. Tabellen ser korrekt ud. Derefter stille to ting gå helt forkert.

For det første tæller indfødt samlings-begrænsede rabatter samlede enheder på tværs af alle produkter i samlingen, ikke enheder af den ene stol på siden. Så en shopper kan udløse din "køb 3" niveau ved at tilføje en hver af tre forskellige stole, hvilket ikke er hvad tabellen på nogen enkelt stol side indebærer. Den viste tabel er skrevet fra perspektivet for et produkt; rabatten gør samlings matematik. De beskriver forskellige tilbud.

For det andet ændres rabattens medlemskab under dig. Øjeblikket du tilføjer et nyt produkt til denne samling, eller øjeblikket et produkt falder ud af det, skiftet sæt af varer, der tæller mod tærsklen. Handlende har signaleret netop dette på forumene: tilføjelse af et produkt til en samling ændrer stille rabat logikken, og intet advarer dig. Din manuel-kodet tabel viser stadig de gamle niveauer. Det beskriver nu en rabat, der ikke længere eksisterer i den form kunden ser.

Dette er kerneårsagen til, at en niveautabel ikke skal være en statisk artefakt, du vedligeholder manuelt. Tabellen er en visning af en rabat. Hvis rabatten kan ændre omfang eller medlemskab uden at røre tabellen, vil de to forlade sig, og forladelsen er usynlig indtil en kunde eller din egen testordre overflader det. Reparationen er strukturel: displayper-produkt niveauer fra samme definition som rabatten bruger, og tæl på den måde tabellen hævder at tælle, pr. produkt og dets varianter, ikke samlet på tværs af en hel samling. Det er tællemodellen dækket i per-produkt volumen rabatter, og det er forskellen mellem en tabel, der altid er sand og en der er sand til tirsdag.

SEO-fælden: gengivelse aldrig priser som overskriftsmærker

Denne er en ægte, dokumenteret minefelt, og det kommer lige fra app-anmeldelserne. En handlende signalerede, at en populær rabatapp gengivet sine priser på siden inden for overskriftsmærker, hvilket skabte flere konkurrerende H1-elementer på hver produktside, og support nægtede at reparere det. Det er ikke en kosmetisk klage. Det er en SEO-regression bagt ind i widgetten.

Her er hvorfor det betyder noget. Søgemaskiner bruger din overskriftshierarki til at forstå en side. H1 er beregnet til at være den enkelte, primære titel på siden, næsten altid produktnavnet. Resten af overskrifterne, H2 og H3, beskriver strukturen under det. Når en rabat-widget omslutter "6 til 34 dollar" i et

eller

fordi det var en doven måde at få tallet stort og fed på, injicerer det overskrifter, der betyder ingenting semantisk og fortynder dem der gør. Flere H1'er på en side sløre signalet om hvad siden faktisk handler om. Priser og "du sparer" tal er data, ikke dokument struktur. De tilhører tabelceller, intervaller eller afsnit stiliseret med CSS, aldrig i heading-elementer.

Den rigtige måde at gengive en niveautabel er kedeligt korrekt HTML: en rigtig

(eller en stiliseret liste) hvis celler indeholder mængderne og priserne, med visuelt vægt påført gennem CSS, ikke gennem overskriftsmærker. Tallene kan se så store og fede ud som din designer vil. De skal bare ikke foregive at være side overskrifter. Shopify's egen vejledning for butiksfrontwidgetter i tema-app-udvidelsesframework peger samme retning, og internt er reglen vi holder os til enkel: butiksfrontwidgetter skal være SEO-sikker, med ingen injiceret overskriftsmærker og ingen layout skift.

Hvis du vurderer en rabatapp, er dette en konkret ting at kontrollere før du installerer. Se kilde på en demo produktside, eller kør det gennem din browsers tilgængeligheds- eller SEO-inspektor, og bekræft widgetten ikke tilføjer heading-elementer. Det er en fem-minutters test, der sparer dig fra et langsomt, hårdt-til-diagnosticeren ranking-nedgang. Markedsføring af fraværet af dette problem er fair game, fordi så mange widgetter får det forkert.

Core Web Vitals: en niveautabel skal ikke koste dig fart

En produktside niveautabel er lille, men den gengives på dine højeste-hensigt, højeste-trafik sider, så dens ydelses omkostninger sammentræder. To Core Web Vitals metrikker er dem at holde øje med.

Cumulative Layout Shift (CLS) er den første. En tabel, der dukker op et øjeblik efter resten af siden er malet, skubber tilføj-til-kurv-knappen ned og stacker layout skift. Reparationen er at gengive tabellen server-side i den indledende HTML hvor muligt, så pladsen er reserveret fra første maling, i stedet for at injicere det sent med JavaScript efter siden lægger sig. En niveautabels værdi er kendt ved render tid; der er ingen grund til at det skal ankomme sidst.

Largest Contentful Paint (LCP) og den generelle vægt budget er den anden. En widget, der indlæser et tungt JavaScript bundt, sit eget web-font eller en chunk framework-kode at tegne hvad er grundlæggende en lille tabel er at bruge din fart budget uopmærksomt. Shopify's tema-app-udvidelsesframework hjælper her: når en app-blok er til stede på en side, indlæses dens stylesheet og script en gang via frameworkets egen mærker, og hvis en handlende tilføjer flere blokke, der refererer til samme fil, Shopify inkluderer denne fil kun en gang pr. side. En god niveautabel læner sig på det, leverer minimal CSS og JS og gør det tunge løfte server-side.

Live-update-adfærden fortjener en note også. En pæn niveautabel fremhæver det aktive niveau som shopperen ændrer mængde, uden side genindlæsning. Den interaktion er billig når det er nogle få linjer vanilla JavaScript skiftende en klasse, og dyr når det er et framework re-render. Hold det let. Pointen med tabellen er at sælge flere enheder, og en side der er langsom at interagere med sælger færre.

Arbejdet eksempel: en "mængde, pris hver, du sparer" tabel

Lad os bygge en konkret. En supplements-mærke sælger en protein-tub til 40 dollar. De vil belønne oplagring af samme tub, tællet pr. produkt på tværs dets smagsvariatorer, med disse niveauer:

  • 1 til 2 enheder: fuld pris
  • 3 til 5 enheder: 10 procent rabat
  • 6 til 11 enheder: 15 procent rabat
  • 12 eller flere enheder: 20 procent rabat

Tabellen på produktsiden, placeret direkte under tilføj-til-kurv-knappen, læser sådan. "Du sparer" kolonne er hvad der gør overtalelse.

En shopper som tilføjer 6 tubs ser "6 til 11" rækken fremhæve som deres aktive niveau, til 34 dollar hver, sparer 48 dollar mod at købe seks til fuld pris. Rækken ovenfor og nedenfor forbliver synlig, så næste niveau ("bare seks mere og det falder til 32 hver") er altid i visning. At synligt næste trin er mekanismen. Det er samme grund som grossist prisgrids altid er blevet trykt som grids.

De to regler fra resten af denne guide gælder begge for netop denne tabel. For det første skal værdierne i "pris hver" kolonne være værdierne rabattan faktisk opkræver, tællet pr. produkt på tværs af tuben smags varianter, ikke samlet med urelaterede produkter. For det andet kan ingen af disse celler være et overskriftsmærke. 34 dollar er en tabelcelle stiliseret til at se prominent ud, ikke et

. Følg disse to regler og denne tabel er sikker at levere på hver produktside i katalogget.

Hvordan man sætter det op, trin for trin

Her er den pålidelige sekvens for app-blok-ruten, hvilket er den, de fleste butikker skal bruge.

1. Bekræft dit tema er Online Store 2.0

App-blokke kræver et JSON-skabelon tema. Hvis du er på et aktuelt Shopify-tema, kvalificerer du dig næsten helt sikkert. Hvis du er på et ældre tema, planlæg en tema-opgradering først, eller brug en Liquid-tilgang i mellemtiden.

2. Definer niveauer en gang, i rabatten

Sæt dine mængde brudpunkter i rabatten selv: dine brudpunkter, pr. enhed priserne eller procenter, og tælle tilstand (tæl denne produkts varianter sammen, ikke hele samlingen). Dette er den enkelt sandhedskilde. Alt kunden ser skal stamme herfra.

3. Tilføj niveautabel-app-blokken i tema-editoren

Åbn dit produktskabelon i tema-editoren, vælg Tilføj blok i produktinformation-sektionen, og vælg appens niveautabel-blok. Træk det direkte under tilføj-til-kurv-knappen. Fordi app-blokke arver temaets typografi og farver, skal det matche dit design øjeblikkeligt; justér kun mellemrum eller justering hvis blokken eksponerer disse indstillinger.

4. Bekræft displayet svarer til checkout matematik

Tilføj produktet til en rigtig test kurv på en mængde, der krydser et niveaugrænse, for eksempel 6 enheder, og bekræft prisen tabellen viste er prisen ved checkout, også gennem en accelereret checkout som Shop Pay. Dette er trinnet, der fanger drift før kunder gør.

5. Tjek overskriftsstrukturen og layout stabilitet

Se produktside kilden og bekræft widgetten tilføjede ingen overskriftsmærker og skubbede ikke tilføj-til-kurv-knappen omkring som den indlæstes. Et hurtigt pas i en SEO eller tilgængeligheds inspektor bekræfter et H1, produkttitlen, med niveautabellen levende i en tabel eller liste, ikke i overskrifter.

6. Test samling grænsetilfældet

Hvis din rabat er omfattet, tilføj og fjern et produkt fra den relevante samling eller gruppe og dobbelttjek at niveautabellen på dit mål produkt stadig viser niveauer du har til hensigt. Dette er hvor manuel-vedligeholdt tabeller fejler; en ordenligt per-produkt-omfattet tilbud gør ikke.

BILLEDE PLACEHOLDER (Billede 3): Displayet og checkoutet enig
Foreslået billede: En 16:9 split illustration. Venstre panel mærket "Produktside" viser niveautabellen med 6-enhed rækken fremhævet til $34.00 hver. Højre panel mærket "Checkout" viser samme 6 enheder opkrævet på $34.00 hver med et grønt flueben badge læsning "Samme pris." En enkelt ubroken kæde ikon linker de to paneler. Nedenfor, en tekst strip læsning "En sandhedskilde: display svarer til checkout." Brand-farver violet og guld, fladt vektor, ingen fotografi.

Kør dette pålideligt med Stackable

Hvis du hellere ikke vil vedligeholde en manuel-kodet tabel, der forlade sig fra din rabat, eller revidere en widgets HTML for forsvundne overskriftsmærker, er dette det specifikke problem Stackable blev bygget til at håndtere, ærligt og inden for Shopifys rigtige regler.

  • Butiksfronten niveautabel er en tema-app-blok du dropper under tilføj-til-kurv-knappen fra tema-editoren. Ingen temakode, og det arver dit tema-fonte og farver, så det ser indfødt ud.
  • Tabellen læser sine niveauer fra samme rabat definition, som checkoutet bruger, og tæller pr. produkt og dets valgte varianter i stedet for at samle en hel samling, så hvad shopperen ser er hvad checkout opkræver. Ændre samlingens indhold og per-produkt tabellen forbliver sand.
  • Det gengives SEO-sikker: priser sidder i en rigtig tabel, aldrig i overskriftsmærker, så du holder et H1 (din produkttitel) og skaber ikke konkurrerende-overskrifter problemet der har trukket app-anmeldelse klager andre steder.
  • Tabellen fremhæver det aktive niveau live, når mængden ændres, med server-beregnede værdier og ingen layout skift, så det forbliver inden for din Core Web Vitals budget.
  • Fordi Stackable aldrig omskriver dine produktpriser, eksisterer niveauer kun som checkout justeringer. Afinstallér og dit katalog og tema er præcis som de var, med blokken rent fjernet.

Installer Stackable gratis og se produktside-tabellen og checkoutet totalt enig til cents på usestackable.com/pricing.

Bundlinjen

  • En rabat efter mængde eksisterer ved checkout med eller uden visning, men en rabat kunden ikke kan se kan ikke vokse kurven. Produktside niveautabellen er merchandising-halvdelen af tilbuddet.
  • Du kan manuel-kodere tabellen i Liquid, drive den fra et metafield, eller tilføje en tema-app-blok i tema-editoren. App-blokken er den kodeløse rute og når bygget godt, forbliver synkroniseret med rabatten automatisk.
  • Niveautabellen er en app-blok (target: section), ikke en app-embed-blok, fordi den skal sidde på et præcist punkt i produktlayoutet og vise data for det aktuelle produkt.
  • Manuel-kodede tabeller forlade sig. Indfødt samlings-begrænsede rabatter tæller på tværs af hele samlingen og ændres når du tilføjer eller fjerner produkter, så en statisk tabel stille starter beskriver et tilbud, der ikke længere eksisterer.
  • Gengivelse aldrig priser i overskriftsmærker. Det skaber konkurrerende H1'er og skader SEO, en rigtig, dokumenteret klage om nogle rabat-widgetter. Sæt priser i tabelceller stiliseret med CSS.
  • Hold øje med Core Web Vitals: gengiv server-side for at undgå layout skift, hold JavaScript lys, og stol på framework, der indlæser delte aktiver en gang pr. side.
  • Det non-negotiable test er at den viste pris svarer til checkout-pris, også gennem Shop Pay. Bekræft det med en rigtig testordre på tværs af en niveaugrænse før du lancerer.

Relaterede artikler

Ofte stillede spørgsmål

Find svar på almindelige spørgsmål

  • Tilføj en tema-app-blok fra en rabatapp i tema-editoren, placer den under tilføj-til-kurv-knappen, eller kodér tabellen manuelt i Liquid i dit produktskabelon. App-blok-ruten kræver ingen kode og læser i en vel bygget app de samme niveauværdier som checkout bruger. Det væsentligste krav er på begge måder, at de viste priser matcher hvad checkout opkræver, og at tabellen ikke bruger overskriftsmærker.

  • Ja, hvis dit tema er Online Store 2.0 og du bruger en rabatapp, der leverer en tema-app-blok. Shopify's tema-editor lader dig visuelt tilføje, fjerne og omordne app-blokke uden temakode. Manuelt at kodere en tabel i Liquid kræver udvikler-fortrolighed og tilføjer løbende vedligeholdelse, fordi tabellen derefter er adskilt fra rabatten og må holdes synkroniseret manuelt.

  • Kun hvis det er bygget dårligt. Den virkelige fare er en widget, der gengiver priser inden for overskriftsmærker, hvilket skaber ekstra H1 eller H2 elementer og fortynder din sides overskriftsstruktur. En korrekt bygget tabel placerer priser i tabelceller eller intervaller stiliseret med CSS, hvilket bevarer et enkelt H1 (din produkttitel). Kontroller enhver app ved at se kilde på en demosside og bekræft, at den ikke tilføjer overskriftselementer.

  • Søgemaskiner læser din overskriftshierarki for at forstå en side. H1 skal være siddens primære titel, normalt produktnavnet. Når en widget omslutter en pris i et H1 eller H2 for at få det til at se stort ud, injicerer det overskrifter uden real betydning og skaber flere konkurrerende overskrifter, der slører signalet om hvad siden handler om. Priser er data; stil dem med CSS, ikke overskriftsmærker.

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.

Vi bruger essentielle cookies til at drive dette site, og kun med din tilladelse, analysecookies til at forstå trafik. Læs vores Cookiepolitik.