Tilgjengelighetsblokk: Lager, Levering og Oppfyllelse

En tilgjengelighetsblokk besvarer kjøperens siste operasjonelle spørsmål: kan jeg få tak i denne varen, med hvilken metode, og når? Den samler fakta om lager, levering, henting, restordre og utgåtte produkter i én uttrekkbar enhet i stedet for å spre dem mellom et merke, et kasseverktøytips og en fraktpolitiside.

Hvorfor dette elementet betyr noe

Tilgjengelighet er ikke betryggende tekst. Det er en kjøpsbegrensning. En kjøper som har valgt et produkt, kan likevel forlate beslutningen hvis siden ikke kan svare på om den valgte varianten er salgbar, om levering når ønsket sted, eller om den ankommer før en reell deadline. Presis tilgjengelighet reduserer usikkerhet i det øyeblikket usikkerhet er dyrest.

Psykologien handler om kontroll, ikke kunstig hastverk. «Bare 2 igjen» kan hjelpe noen med å vurdere risiko når tallet er sant og oppdatert. Det samme budskapet skader tilliten når det vedvarer i flere dager, tilbakestilles etter oppdatering, eller refererer til et lager som ikke kan betjene kjøperen. En nyttig blokk gir leseren fakta som trengs for å handle: nåværende status, destinasjon, metode, tidspunkt, betingelser og neste tilgjengelige handling.

Maskinuttrekkbarhet betyr at en crawler, handleagent, feed eller hjelpeteknologi kan bevare forholdet mellom en variant og dens oppfyllelsesfakta. En grønn prikk ved siden av «Tilgjengelig» er semantisk svak: tilgjengelig for hvilken farge, lokasjon, metode og tid? En merket blokk kan opprettholde det fullstendige svaret.

Ferskhet betyr noe fordi lagerbeholdning er volatil. Innholdssystemet bør hente status fra handelens sannhetskilde, mens det synlige tidsstemplet og reservepolicyen gjør utdaterte eller utilgjengelige data detekterbare. Søkemotorer og AI-systemer må se den samme materielle tilstanden som en kjøper ser; strukturerte data kan ikke reparere en selvmotsigende side.

Når du skal bruke det

Bruk en tilgjengelighetsblokk når lager eller oppfyllelse påvirker hvorvidt en leser kan fullføre den tiltenkte handlingen. Den hører hjemme på fysiske produktsider, produktlister der lager påvirker valg, billetter eller beholdningsbegrensede tilbud, og handelsdatapunkt utformet for agenter. Den fungerer også for henting, lokal levering, ledetider for bestillingsvarer, restordre, forhåndsbestillinger og utgåtte produkter.

Render blokken per kjøpbar variant når størrelse, farge, pakke, tilstand, selger eller lokasjon endrer svaret. «På lager» for produktfamilien er misvisende når den valgte størrelsen er utilgjengelig. Hvis en markedsplass har flere selgere, trenger hvert tilbud sin egen pris, tilgjengelighet, leveringsløfte og selgeridentitet.

Vanlige nære bom bør holde seg utenfor dette elementet:

• En tjenestes neste avtale er en bookingtime, ikke lagertilgjengelighet.
• Åpningstider hører hjemme i åpningstider og kontaktinformasjon; «åpent nå» betyr ikke at en vare er til stede.
• En programvarefunksjons lanseringsstatus hører hjemme i produkt- eller lanseringsdokumentasjon med mindre tilgangen virkelig er kapasitetsbegrenset.
• Et kampanjeutløp er en tilbudsbetingelse, ikke en lagerstatus.
• En generell fraktpolicy forklarer regler på tvers av ordrer; tilgjengelighetsblokken anvender disse reglene på denne varen, destinasjonen og tidspunktet.
• En forhandlers markedsføringspåstand som «sender raskt» er ikke et estimat og bør ikke okkupere et leveringsfelt.

element-skrivereglene har forrang: velg blokken etter formål, ikke etter dens merke, kort eller accordeon-stil. Hvis hovedoppgaven er å angi om og hvordan den valgte varen kan skaffes, er det en tilgjengelighetsblokk.

Hvor du skal plassere den

Plasser den primære blokken i kjøpsområdet, etter at kjøperen har valgt alle varianter som påvirker lager, og umiddelbart før antallskontrollen og kjøpshandlingen. Denne rekkefølgen lar siden beregne en sannferdig tilstand før den presenterer «Legg i handlekurv». Hvis variantkontroller sitter over prisen, plasser blokken etter disse kontrollene og oppdater dens tilgjengelige navn med valget.

På en kategori- eller listeside bruker du en kompakt status direkte inni det matchende produktkortet. Lenk til detaljsiden for destinasjonsspesifikke datoer med mindre kortet kan beregne dem nøyaktig. I en kjøpsguide eller omtale plasserer du en redaksjonelt kvalifisert status ved siden av forhandleren og verifiseringstidspunktet; ikke antyd at utgiveren kontrollerer beholdningen.

Blokken kan sitte ved siden av pris når begge refererer til samme variant og selger. Den kan ikke sitte ved siden av et motstridende merke, en aktivert kjøpsknapp for en utilgjengelig vare, en urelatert nedtellingstidtaker, eller et leveringskrav basert på en annen destinasjon. Ikke plasser en anbefaling, en salgsfremmende karusell eller kryssalg mellom statusen og dens neste handling. Ikke skjul utgått status under omtaler mens du lar den tidligere kjøpskontrollen være synlig.

Mobilrekkefølgen må forbli: valgt variant, lagerstatus, leverings- eller hentingsvalg, betingelser, deretter handling. En klebrig kjøpslinje kan gjenta en kort status, men den må stamme fra samme kilde og aldri motsi hele blokken.

Anatomi

1. Kontekst: identifiserer det eksakte produktet, varianten, selgeren og lokasjonen faktaene gjelder for.
2. Lagerstatus: bruker én kontrollert tilstand som På lager, Lavt lager, Utsolgt, Restordre, Forhåndsbestilling eller Utgått.
3. Mengdeangivelse: oppgir et verifisert antall eller en ikke-numerisk terskeletikett; den fabrikerer aldri knapphet.
4. Destinasjon: navngir landet, regionen, postnummeret eller den valgte butikken som brukes for estimatet.
5. Oppfyllelsesmetode: skiller frakt, lokal levering, henting og digital levering.
6. Leverings- eller klarhetsvindu: viser en absolutt dato eller avgrenset periode, ikke «snart».
7. Frist og betingelser: oppgir tidssone, bestillingsfrist, antatt virkedag, medlemskapskrav eller minimumsordre når det er relevant.
8. Utilgjengelig policy og handling: forklarer påfyll, erstatning, restordre, varsling eller arkiveringsatferd.
9. Ferskhet og kilde: registrerer når statusen ble fastslått og hvilken autoritativ tjeneste som leverte den.
10. Handling: samsvarer med tilstanden: kjøp, forhåndsbestilling, bli med i venteliste, finn en annen butikk, eller se etterfølger.

Designeksempler

Hver variant bruker tekst i tillegg til farge, bevarer konteksten for den valgte varen, og eksponerer et tidsstempel eller en live-kildekontrakt.

På lager med oppfyllelsesvalg. Bruk når varen er salgbar nå. Skill nettlagertilgjengelighet fra butikklager, og vis ett estimat per kvalifisert metode.

Lavt lager. Bruk bare når en styrt terskel er krysset. Vis et nøyaktig antall kun hvis det er trygt og tilstrekkelig oppdatert; ellers si «Lavt lager» og behold tidsstempelet.

Utsolgt, påfyll forventet. Deaktiver den umiddelbare kjøpshandlingen med mindre restordre aksepteres. Oppgi forventet periode bare når merchandising- eller forsyningsdata støtter det.

Restordre eller forhåndsbestilling. Hold disse tilstandene distinkte. Oppgi når betaling autoriseres eller trekkes, forventet forsendelses- eller lanseringsdato, kanselleringsvilkår, og om blandede handlekurver sendes separat.

Utgått. Fjern aktive kjøpskontroller og aktiv-tilbud-markering. Bevar nyttige spesifikasjoner og supportinformasjon, og identifiser en offisiell etterfølger bare når forholdet er verifisert.

Butikkhenting. Navngi butikken, klart-klokkeslett, reservasjonsvarighet og eventuelle identifikasjonskrav. «Tilgjengelig i nærheten» er ikke tilstrekkelig når kjøperen må reise.

Parametere

«Kilde» nedenfor betyr hvor rendrer henter verdien. Handelssystemer forblir ansvarlige for det underliggende kravet.

Den kontrollerte statusen kartlegges til handelens sannhet, ikke presentasjon: in-stock, limited, out-of-stock, backorder, preorder eller discontinued. En kanalspesifikk verdi som collection-only hører til method, fordi en vare kan være på lager samtidig som den kun er tilgjengelig via henting.

Syntaks og kodeeksempler

De tre formene koder samme valgte SKU, tilstand, leveringsområde, kilde og handling. Et prosjekt må registrere den tilsvarende Hugo- eller WordPress-adapteren før syntaksen brukes i produksjon.

Bærbar Markdown-direktiv

:::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"}
## Tilgjengelighet

På lager på nett og klar til forsendelse.
Handling: [Legg marineblå Trail Jacket, str. M i handlekurv](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" >}}
## Tilgjengelighet

På lager på nett og klar til forsendelse.
Handling: [Legg marineblå Trail Jacket, str. M i handlekurv](https://example.com/cart/add/TJ-NV-M)
{{< /availability >}}

Alle parametere er navngitte. Eksempelet unngår med vilje å blande posisjonelle og navngitte parametere.

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"]
På lager på nett og klar til forsendelse.
Handling: <a href="https://example.com/cart/add/TJ-NV-M">Legg marineblå Trail Jacket, str. M i handlekurv</a>
[/availability]

En native WordPress-blokk bør lagre disse verdiene som typede attributter i stedet for én enkelt rik tekst-blob. Server-side rendering foretrekkes for den opprinnelige tilstanden; personalisering på klienten kan forbedre destinasjonen og estimatet etter samtykke eller input.

Gode og dårlige eksempler

Godt

Marineblå Trail Jacket, str. M — på lager på nett. Levering til 10001 er estimert til 31. august–1. september med standard frakt. Bestill innen 14:00 ET 28. august. Butikkhentingstilgjengelighet sjekkes separat. Lager- og leveringsestimat kontrollert kl. 09:42 ET 27. august 2026.

Dette fungerer fordi det knytter statusen til en valgt variant, destinasjon, metode, datoperiode, tidssone og verifiseringstidspunkt. Leseren kan handle uten å tolke et ikon eller åpne en generisk policy.

Dårlig

🟢 Skynd deg! Tilgjengelig nå — selger raskt. Levering snart. Bare noen få igjen!

Dette mislykkes fordi «tilgjengelig» ikke har noen variant, selger eller kanal; «snart» har ingen destinasjon eller datoer; «noen få» har ingen styrt terskel; og hastverket kan ikke kontrolleres. Det grønne ikonet bærer også mening som mangler i teksten. Å erstatte ikonet med et rødt ville ikke fikse de manglende faktaene.

Skjemamarkering og tilgjengelighet

For en ekte kjøpbar vare kan blokken mate Product.offers gjennom et Offer eller AggregateOffer. Kartlegg den kontrollerte synlige tilstanden til den tilsvarende Schema.org-tilgjengelighets-URL-en, som InStock, OutOfStock, BackOrder, PreOrder, Discontinued eller LimitedAvailability. Pris, valuta, selger, varetilstand og URL må beskrive samme tilbud. Ikke bruk InStock bare fordi en annen variant eller selger har lagerbeholdning.

Leveringsfakta kan mate OfferShippingDetails: destinasjon, behandlingstid, transittid, sats og kvalifisert metode må samsvare med det synlige løftet. Ikke send ut et aktivt Offer for en utgått vare eller la utdatert tilbudsmarkering ligge igjen når den synlige handlingen blir en venteliste.

Strukturerte data er et resultat av handelstilstanden, ikke en andre lagerdatabase. Generer den synlige blokken, feeden og JSON-LD fra samme avgjorte tilbud når det er mulig. Hvis de ikke kan oppdateres på samme tidsplan, publiser den minst tillatte forsvarlige tilstanden inntil synkronisering er fullført.

Tilgjengelighet krever en tekstetikett for hver status; farge, animasjon og ikoner kan forsterke, men aldri definere den. Assosier oppdateringer med den valgte varianten. Når en variant- eller destinasjonsendring oppdaterer blokken asynkront, flytt verken fokus eller leseren uventet; annonser et konsist resultat gjennom et passende konfigurert live-område. Unngå å gjenta nedtellinger hvert sekund.

Leveringskontroller trenger eksplisitte etiketter som «Leveringspostnummer» og «Endre hentebutikk». Datoer må inkludere måneden i ord der numerisk rekkefølge kan være tvetydig, og frister trenger en tidssone. Deaktiverte kjøpskontroller trenger nærliggende tekst som forklarer hvorfor og tilbyr den gyldige neste handlingen. Hold full tilstand tilgjengelig uten hover og tilby en server-rendret reserve når JavaScript svikter.

Skriveregler

Led med den kontrollerte statusen på to til seks ord: «På lager på nett», «Restordre tilgjengelig» eller «Utgått». Følg opp med konsekvensen: klar til forsendelse, forventet lanseringsdato, eller selges ikke lenger. Bruk én blokk per valgt tilbud, ikke én blokk per lagerpost.

Bruk absolutte leveringsdatoer eller en avgrenset to-dagers periode. Hvis estimatet endres etter destinasjon, navngi destinasjonen. Hvis intet estimat er pålitelig, si hva som må skje før et kan beregnes. «Vanligvis», «snart», «raskt» og «bør ankomme» er ikke erstatninger for en kildetidsangivelse.

Hold den primære blokken til én statuslinje, én til fire oppfyllelsesrader, én policy-setning på 10–45 ord når nødvendig, og én primær handling. En lavt lager-etikett trenger en godkjent terskel; et nøyaktig antall trenger en oppdatert kilde. Gjennomgå tilstanden kontinuerlig gjennom systemintegrasjon og test reserven under hver innholdskvalitetssikringssyklus.

Bruk rolig, operasjonelt språk. Inkluder aldri fabrikkert knapphet, anonyme popularitetspåstander, urelaterte rabatter, attester, garantidetaljer, fulle returvilkår eller generisk fraktpolitikk-kopi. Kall aldri en forhåndsbestilling «på lager», fremstill aldri en utilgjengelig vare som «tilgjengelig for bestilling» uten å si restordre, og lov aldri en dato som oppfyllelsessystemet ikke kan støtte.

For utgåtte varer, si «Utgått» i stedet for «For øyeblikket utilgjengelig». Forklar om support, deler, manualer eller en offisiell etterfølger fortsatt er tilgjengelige.

Innholdstyper som bruker det

Feltet postTypes i frontmatter er kilden for denne implementeringsmatrisen.

QA-sjekkliste

• Statusen gjelder for den valgte SKU-en, selgeren, kanalen og lokasjonen, ikke produktfamilien generelt.
• Lager, salgbarhet, oppfyllelsesmetode og leveringstidspunkt er separate felt og motsier ikke hverandre.
• Lager- og oppfyllelseskildene er autoritative, overvåket og navngitt i komponentkontrakten.
• Kontrolltidspunktet er til stede, inkluderer en tidssone, og oppfyller virksomhetens ferskhetstoleranse.
• Nøyaktige antall og lavt lager-etiketter bruker styrte regler i stedet for salgsfremmende hastverk.
• Hvert leveringsestimat navngir eller arver en synlig destinasjon og bruker en absolutt dato eller avgrenset periode.
• Restordre- og forhåndsbestillingsstatus forklarer betalingstidspunkt, forventet forsendelse eller lansering, og kanselleringsbetingelser.
• Utsolgte og utgåtte tilstander fjerner eller erstatter den umiddelbare kjøpshandlingen.
• Synlig innhold, feeddata, kasseatferd og strukturerte Offer-data beskriver samme tilstand.
• Status formidles i tekst, dynamiske endringer annonseres hensiktsmessig, og kontroller har eksplisitte etiketter.
• Blokken forblir meningsfull uten farge, hover, animasjon, personalisering eller JavaScript.
• Mobil- og klebrige kjøpsbehandlinger stammer fra samme kilde og bevarer riktig leserekkefølge.
• Alle tre syntakseksempler kartlegger til de samme typede feltene uten å miste kilde- eller ferskhetsdata.

FAQ

Bør en tilgjengelighetsblokk vise nøyaktig antall på lager?

Kun når lagerstyringssystemet er autoritativt, antallet oppdateres raskt nok, og eksponeringen ikke utgjør noen operasjonell eller sikkerhetsrisiko. Ellers bruk en kontrollert status som På lager, Lavt lager, Restordre eller Utsolgt. Oppfinn aldri haster med et uverifisert antall.

Hva bør blokken si når en vare er utsolgt?

Oppgi Utsolgt, forklar om påfyll forventes, gi en verifisert dato eller periode når en slik finnes, og tilby en relevant neste handling som et varsel om nytt lager. Ikke vis et kjøpbart tilbud eller en aktiv Legg i handlekurv-handling når kassen ikke kan ta imot bestillingen.

Hvordan bør restordre og forhåndsbestilling skilles?

En restordre er en eksisterende vare som er midlertidig utilgjengelig for umiddelbar oppfyllelse; en forhåndsbestilling er en vare som ennå ikke er lansert for ordinært salg. Merk statusen nøyaktig, oppgi når betaling tas, og gi forventet forsendelses- eller lanseringsdato med eventuell usikkerhet.

Krever en tilgjengelighetsblokk tilbudsskjema (Offer schema)?

Nei. Den synlige blokken må være nøyaktig selv uten strukturerte data. Når siden beskriver et ekte kjøpbart tilbud, bør den synlige statusen samsvare med tilgjengelighetsverdien i tilbudet og eventuelle forsendelsesdetaljer. Redaksjonelle omtaler og utilgjengelige katalogoppføringer må ikke merkes opp som aktive tilbud.

Kan leveringsestimater personaliseres etter lokasjon?

Ja, hvis destinasjonen er identifisert og en ikke-personalisert reserve forblir tilgjengelig. Annonser dynamiske endringer til hjelpeteknologi, unngå å bruke IP-plassering som sikkerhet, og hold den server-rendrede lagerstatusen nøyaktig for crawls og brukere uten JavaScript.