Tillgänglighetsblock: Lager, Leverans och Uppfyllelse

Ett tillgänglighetsblock besvarar köparens sista operativa fråga: kan jag få denna artikel, med vilken metod och när? Det samlar lager-, leverans-, upphämtnings-, restorders- och utgångna fakta i en extraherabar enhet istället för att sprida dem mellan en märkning, ett kassaverktygstips och en leveranspolicy-sida.

Varför detta element är viktigt

Tillgänglighet är ingen trygghetsskapande text. Det är ett köpbegränsande villkor. En köpare som har valt en produkt kan fortfarande avbryta beslutet om sidan inte kan svara på om den valda varianten är säljbar, om leveransen når den önskade platsen eller om den anländer före en verklig deadline. Exakt tillgänglighet minskar osäkerheten i det ögonblick då osäkerheten är som mest kostsam.

Psykologin handlar om kontroll, inte konstlad brådska. “Endast 2 kvar” kan hjälpa någon att bedöma risk om siffran är sann och aktuell. Samma meddelande skadar förtroendet när det kvarstår i dagar, återställs efter uppdatering eller hänvisar till ett lager som inte kan betjäna köparen. Ett användbart block ger läsaren fakta som behövs för att agera: aktuell status, destination, metod, tidpunkt, villkor och nästa tillgängliga åtgärd.

Maskinutvinningsbarhet innebär att en crawler, shoppingagent, feed eller hjälpmedelsteknik kan bevara relationen mellan en variant och dess uppfyllelsefakta. En grön prick bredvid “Available” är semantiskt svag: tillgänglig för vilken färg, plats, metod och tid? Ett märkt block kan behålla det fullständiga svaret.

Aktualitet är viktigt eftersom lager är föränderligt. Innehållssystemet bör hämta status från handelns sanningskälla, medan den synliga tidsstämpeln och reservpolicy gör föråldrade eller otillgängliga data upptäckbara. Sökmotorer och AI-system måste se samma materiella tillstånd som en köpare ser; strukturerad data kan inte reparera en motsägelsefull sida.

När du ska använda det

Använd ett tillgänglighetsblock när lager eller uppfyllelse påverkar om en läsare kan slutföra den avsedda åtgärden. Det hör hemma på fysiska produktsidor, produktlistningar där lager påverkar val, biljetter eller lagerbegränsade erbjudanden samt handelsdataslutpunkter utformade för agenter. Det fungerar även för upphämtning, lokal leverans, ledtider för tillverkning på beställning, restorder, förbeställningar och utgångna produkter.

Rendera blocket per köpbar variant när storlek, färg, förpackning, skick, säljare eller plats ändrar svaret. “I lager” för produktfamiljen är missvisande när den valda storleken inte är tillgänglig. Om en marknadsplats har flera säljare behöver varje erbjudande sitt eget pris, tillgänglighet, leveranslöfte och säljaridentitet.

Vanliga missar som bör hållas utanför detta element:

• En serviceteams nästa tid är en bokningsbar tid, inte lagertillgänglighet.
• Öppettider hör hemma i öppettider och kontaktinformation; “öppet nu” betyder inte att en artikel finns på plats.
• En programvarufunktions releasedatum hör hemma i produkt- eller releasedokumentation om inte åtkomsten verkligen är kapacitetsbegränsad.
• En kampanjs utgångsdatum är ett erbjudandevillkor, inte ett lagertillstånd.
• En allmän leveranspolicy förklarar regler över beställningar; tillgänglighetsblocket tillämpar dessa regler på denna artikel, destination och tid.
• En återförsäljares marknadsföringspåstående som “snabba leveranser” är inte en beräkning och bör inte uppta ett leveransfält.

Reglerna för element har företräde: välj blocket efter syfte, inte efter dess märkning, kort eller accordeon-stil. Om den primära uppgiften är att ange om och hur den valda artikeln kan erhållas, är det ett tillgänglighetsblock.

Var du ska placera det

Placera det primära blocket i köpregionen, efter att köparen har valt alla varianter som påverkar lagret och omedelbart före kvantitetskontrollen och köpaktionen. Denna ordning låter sidan beräkna ett sanningsenligt tillstånd innan “Lägg i varukorg” presenteras. Om variantkontrollerna sitter ovanför priset, placera blocket efter dessa kontroller och uppdatera dess tillgängliga namn med valet.

På en kategori- eller listningssida, använd en kompakt status direkt i den matchande produktkortet. Länka till detaljsidan för destinationsspecifika datum om inte kortet kan beräkna dem korrekt. I en köparguide eller recension, placera en redaktionellt kvalificerad status bredvid återförsäljaren och verifieringstiden; antyd inte att utgivaren kontrollerar lagret.

Blocket får sitta bredvid priset när båda avser samma variant och säljare. Det får inte sitta bredvid en motstridig märkning, en aktiverad köpknapp för en otillgänglig artikel, en orelaterad nedräkningstimer eller ett leveranspåstående baserat på en annan destination. Placera inget vittnesmål, reklamkarusell eller korsförsäljning mellan statusen och dess nästa åtgärd. Dölj inte utgången status nedanför recensioner medan den tidigare köpkontrollen fortfarande är synlig.

Mobil ordning måste vara: vald variant, lagertillstånd, leverans- eller upphämtningsval, villkor, sedan åtgärd. En fast köprad kan upprepa ett kort tillstånd, men måste härledas från samma källa och aldrig motsäga det fullständiga blocket.

Anatomi

1. Kontext: identifierar den exakta produkt, variant, säljare och plats som fakta gäller.
2. Lagerstatus: använder ett kontrollerat tillstånd som In stock, Low stock, Out of stock, Backorder, Pre-order eller Discontinued.
3. Kvantitetsangivelse: ger ett verifierat antal eller en icke-numerisk tröskelbenämning; det skapar aldrig konstlad brist.
4. Destination: anger det land, region, postnummer eller vald butik som används för beräkningen.
5. Uppfyllelsemetod: separerar frakt, lokal leverans, upphämtning och digital leverans.
6. Leverans- eller beredskapsfönster: visar ett absolut datum eller avgränsat intervall, inte “snart”.
7. Sista beställningstid och villkor: anger tidszon, beställningsdeadline, antagande om arbetsdagar, medlemskrav eller minimumorder när det är relevant.
8. Policy och åtgärd vid otillgänglighet: förklarar påfyllnad, ersättning, restorder, avisering eller arkiveringsbeteende.
9. Aktualitet och källa: registrerar när tillståndet fastställdes och vilken auktoritativ tjänst som tillhandahöll det.
10. Handelsåtgärd: matchar tillståndet: köp, förbeställ, gå med i väntelista, hitta annan butik eller visa efterföljare.

Designexempel

Varje variant använder text såväl som färg, behåller den valda artikelns kontext och exponerar en tidsstämpel eller ett avtal om levande källa.

I lager med uppfyllelseval. Använd när artikeln är säljbar nu. Separera onlinelager från butikslager och visa en beräkning per berättigad metod.

Lågt lager. Använd endast när en styrd tröskel har passerats. Visa exakt antal endast om det är säkert och tillräckligt aktuellt; säg annars “Low stock” och behåll tidsstämpeln.

Slut i lager, påfyllnad förväntad. Inaktivera den omedelbara köpaktionen om inte restorder accepteras. Ange det förväntade intervallet endast när marknadsförings- eller leveransdata stödjer det.

Restorder eller förbeställning. Håll dessa tillstånd åtskilda. Ange när betalning auktoriseras eller tas, förväntat utskicknings- eller releasedatum, avbeställningsvillkor och om blandade varukorgar skickas separat.

Utgången. Ta bort aktiva köpkontroller och aktivt erbjudandemärkning. Bevara användbara specifikationer och supportinformation, identifiera sedan en officiell efterföljare endast när relationen är verifierad.

Butiksupphämtning. Namnge butiken, klartid, reservationslängd och eventuella identifieringskrav. “Tillgänglig i närheten” är inte tillräckligt när köparen måste resa.

Parametrar

“Källa” nedan anger var renderaren hämtar värdet. Handelssystemen förblir ansvariga för det underliggande påståendet.

Den kontrollerade statusen mappar till handelns sanning, inte presentation: in-stock, limited, out-of-stock, backorder, preorder eller discontinued. Ett kanalspecifikt värde som collection-only tillhör method, eftersom en artikel kan vara i lager men endast tillgänglig via upphämtning.

Syntax och kodexempel

De tre formerna kodar samma valda SKU, tillstånd, leveransintervall, källa och åtgärd. Ett projekt måste registrera motsvarande Hugo- eller WordPress-adapter innan syntaxen används i produktion.

Portabel Markdown-anvisning

:::availability{status=in-stock sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api"}
## Tillgänglighet

I lager online och redo att skickas.
Åtgärd: [Lägg marin Trail Jacket, storlek M i varukorgen](https://example.com/cart/add/TJ-NV-M)
:::

Hugo shortcode

{{< availability status="in-stock" sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api" >}}
## Tillgänglighet

I lager online och redo att skickas.
Åtgärd: [Lägg marin Trail Jacket, storlek M i varukorgen](https://example.com/cart/add/TJ-NV-M)
{{< /availability >}}

Alla parametrar är namngivna. Exemplet undviker avsiktligt att blanda positionella och namngivna parametrar.

WordPress

[availability status="in-stock" sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api"]
I lager online och redo att skickas.
Åtgärd: <a href="https://example.com/cart/add/TJ-NV-M">Lägg marin Trail Jacket, storlek M i varukorgen</a>
[/availability]

Ett inbyggt WordPress-block bör lagra dessa värden som typade attribut snarare än en enda rich-text-klump. Serverrendering är att föredra för initialt tillstånd; klientbaserad personalisering kan förfina destinationen och beräkningen efter samtycke eller inmatning.

Bra och dåliga exempel

Bra

Marin Trail Jacket, storlek M — i lager online. Leverans till 10001 beräknas till 31 augusti–1 september med standardfrakt. Beställ senast 14:00 ET den 28 augusti. Tillgänglighet för butiksupphämtning kontrolleras separat. Lager- och leveransberäkning kontrollerad kl 09:42 ET den 27 augusti 2026.

Detta fungerar eftersom det binder tillståndet till en vald variant, destination, metod, datumintervall, tidszon och verifieringstid. Läsaren kan agera utan att tolka en ikon eller öppna en generisk policy.

Dåligt

🟢 Skynda! Finns nu — säljer snabbt. Leverans snart. Endast ett fåtal kvar!

Detta misslyckas eftersom “finns” saknar variant, säljare eller kanal; “snart” saknar destination eller datum; “ett fåtal” saknar en styrd tröskel; och brådskan kan inte granskas. Den gröna ikonen bär också en innebörd som saknas i texten. Att ersätta ikonen med en röd skulle inte åtgärda de saknade fakta.

Schema-märkning och tillgänglighet

För en äkta köpbar artikel kan blocket mata Product.offers genom ett Offer eller AggregateOffer. Mappa det kontrollerade synliga tillståndet till motsvarande Schema.org-tillgänglighets-URL, såsom InStock, OutOfStock, BackOrder, PreOrder, Discontinued eller LimitedAvailability. Pris, valuta, säljare, skick och URL måste beskriva samma erbjudande. Använd inte InStock bara för att en annan variant eller säljare har lager.

Leveransfakta kan mata OfferShippingDetails: destination, hanteringstid, transporttid, avgift och berättigad metod måste överensstämma med det synliga löftet. Skicka inte ut ett aktivt Offer för en utgången artikel eller lämna kvar föråldrad erbjudandemärkning när den synliga åtgärden blir en väntelista.

Strukturerad data är en utdata från handelstillståndet, inte en andra lagerdatabas. Generera det synliga blocket, feeden och JSON-LD från samma lösta erbjudande när det är möjligt. Om de inte kan uppdateras enligt samma schema, publicera det minst tillåtande försvarbara tillståndet tills synkronisering är slutförd.

Tillgänglighet kräver en textetikett för varje status; färg, animation och ikoner kan förstärka men aldrig definiera den. Associera uppdateringar med den valda varianten. När en variant- eller destinationsändring uppdaterar blocket asynkront, flytta varken fokus eller läsaren oväntat; meddela ett koncist resultat via en lämpligt konfigurerad live-region. Undvik att upprepa nedräkningsmeddelanden varje sekund.

Leveranskontroller behöver explicita etiketter som “Leveranspostnummer” och “Byt upphämtningsbutik.” Datum måste inkludera månaden i ord där numerisk ordning kan vara tvetydig, och sista beställningstid behöver en tidszon. Inaktiverade köpkontroller behöver närliggande text som förklarar varför och erbjuder den giltiga nästa åtgärden. Håll det fullständiga tillståndet tillgängligt utan hovring och tillhandahåll en serverrenderad reservlösning när JavaScript misslyckas.

Skrivregler

Inled med den kontrollerade statusen i två till sex ord: “I lager online,” “Restorder tillgänglig” eller “Utgången.” Följ med konsekvensen: redo att skickas, förväntat releasedatum eller säljs inte längre. Använd ett block per valt erbjudande, inte ett block per lagerpost.

Använd absoluta leveransdatum eller ett avgränsat tvådagarsintervall. Om beräkningen ändras beroende på destination, ange destinationen. Om ingen beräkning är tillförlitlig, säg vad som måste hända innan en kan beräknas. “Vanligtvis,” “snart,” “snabbt” och “borde komma fram” är inte ersättningar för ett källbaserat intervall.

Håll det primära blocket till en statusrad, en till fyra uppfyllelserader, en policymening på 10–45 ord vid behov och en primär åtgärd. En lågt-lager-etikett behöver en godkänd tröskel; ett exakt antal behöver en aktuell källa. Granska tillståndet kontinuerligt genom systemintegration och testa dess reservlösning under varje innehålls-QA-cykel.

Använd lugnt, operativt språk. Inkludera aldrig fabricerad brist, anonyma popularitetspåståenden, orelaterade rabatter, vittnesmål, garantidetaljer, fullständiga returvillkor eller generisk leveranspolicytext. Kalla aldrig en förbeställning för “i lager,” framställ aldrig en otillgänglig artikel som “tillgänglig för beställning” utan att säga restorder och lova aldrig ett datum som uppfyllelsesystemet inte kan stödja.

För utgångna artiklar, säg “Utgången” istället för “För närvarande inte tillgänglig.” Förklara om support, reservdelar, manualer eller en officiell efterföljare fortfarande finns tillgängliga.

Posttyper som använder det

Fältet postTypes i front matter är källan för denna implementeringsmatris.

Checklista för kvalitetssäkring

• Statusen gäller den valda SKU:n, säljaren, kanalen och platsen snarare än produktfamiljen i allmänhet.
• Lager, säljbarhet, uppfyllelsemetod och leveranstid är separata fält och motsäger inte varandra.
• Källorna för lager och uppfyllelse är auktoritativa, övervakade och namngivna i komponentavtalet.
• Kontrolltiden finns, inkluderar en tidszon och uppfyller verksamhetens krav på aktualitet.
• Exakta antal och etiketter för lågt lager använder styrda regler snarare än reklambaserad brådska.
• Varje leveransberäkning anger eller ärver en synlig destination och använder ett absolut datum eller avgränsat intervall.
• Tillstånd för restorder och förbeställning förklarar betalningstidpunkt, förväntat utskicknings- eller releasedatum och avbeställningsvillkor.
• Tillstånd för slut i lager och utgången tar bort eller ersätter den omedelbara köpaktionen.
• Synligt innehåll, feeddata, kassabeteende och Offer-strukturerad data beskriver samma tillstånd.
• Status förmedlas i text, dynamiska ändringar meddelas på lämpligt sätt och kontroller har explicita etiketter.
• Blocket förblir meningsfullt utan färg, hovring, animation, personalisering eller JavaScript.
• Mobil och fasta köpbehandlingar härleds från samma källa och bevarar den korrekta läsordningen.
• Alla tre syntaxexempel mappar till samma typade fält utan att förlora käll- eller aktualitetsdata.

FAQ

Ska ett tillgänglighetsblock visa exakt lagersaldo?

Endast när lagersystemet är auktoritativt, antalet uppdateras tillräckligt snabbt och exponeringen inte skapar någon operativ eller säkerhetsrisk. Använd annars en kontrollerad status som In stock, Low stock, Backorder eller Out of stock. Hitta aldrig på brådskande budskap med ett overifierat antal.

Vad ska blocket säga när en artikel är slut i lager?

Ange Out of stock, förklara om påfyllnad förväntas, ge ett verifierat datum eller intervall när sådant finns, och erbjud en relevant nästa åtgärd som en påfyllnadsavisering. Visa inte ett köpbart Offer eller en aktiv Add to cart-knapp när kassan inte kan ta emot beställningen.

Hur ska restorder och förbeställningar skilja sig åt?

En restorder är en etablerad artikel som tillfälligt inte är tillgänglig för omedelbar uppfyllelse; en förbeställning är en artikel som ännu inte släppts för vanlig försäljning. Märk tillståndet korrekt, ange när betalning tas och ge det förväntade utskicknings- eller releasedatum med eventuell osäkerhet.

Kräver ett tillgänglighetsblock Offerschema?

Nej. Det synliga blocket måste vara korrekt även utan strukturerad data. När sidan beskriver ett äkta köpbart erbjudande ska dess synliga tillstånd överensstämma med Offer-availability-värdet och eventuella leveransuppgifter. Redaktionella omnämnanden och otillgängliga katalogposter får inte markeras som aktiva erbjudanden.

Kan leveransberäkningar personaliseras efter plats?

Ja, om destinationen är identifierad och en icke-personaliserad reservlösning finns tillgänglig. Meddela dynamiska ändringar till hjälpmedelsteknik, använd inte IP-plats som en säkerhet och håll det serverrenderade lagertillståndet korrekt för crawlers och användare utan JavaScript.