SEO Playbook · Element

Tilgængelighedsblokke: Lager, Levering og Opfyldelse

Byg en tilgængelighedsblok, der gør lager, levering, opfyldelse, restordre og udgåede varer tydelige for købere, søgemaskiner og AI-agenter i dag.

12 min read

En tilgængelighedsblok besvarer køberens sidste operationelle spørgsmål: kan jeg få denne vare, med hvilken metode, og hvornår? Den samler lager, levering, afhentning, restordre og udgåede varer i én udtrækkelig enhed i stedet for at sprede dem mellem et badge, et værktøjstip i betalingsprocessen og en forsendelsespolitikside.

Hvorfor dette element er vigtigt

Tilgængelighed er ikke beroligende tekst. Det er en købsbegrænsning. En køber, der har valgt et produkt, kan stadig opgive beslutningen, hvis siden ikke kan besvare, om den valgte variant er salgbar, om leveringen når den ønskede lokation, eller om den ankommer før en reel deadline. Præcis tilgængelighed reducerer usikkerhed i det øjeblik, hvor usikkerhed er dyrest.

Psykologien handler om kontrol, ikke kunstigt hastværk. “Kun 2 tilbage” kan hjælpe nogen med at vurdere risiko, når tallet er sandt og aktuelt. Det samme budskab skader tilliden, når det fortsætter i dagevis, nulstilles efter genindlæsning, eller refererer til et lager, der ikke kan betjene køberen. En nyttig blok giver læseren de fakta, der er nødvendige for at handle: aktuel status, destination, metode, timing, betingelser og den næste tilgængelige handling.

Machinekstraherbarhed betyder, at en crawler, shoppingagent, feed eller hjælpeteknologi kan bevare forholdet mellem en variant og dens opfyldelsesfakta. En grøn prik ud for “Tilgængelig” er semantisk svag: tilgængelig for hvilken farve, lokation, metode og tid? En mærket blok kan indeholde det komplette svar.

Friskhed betyder noget, fordi lagerbeholdning er volatil. Indholdssystemet bør hente status fra handelens sandhedskilde, mens det synlige tidsstempel og reservepolitik gør forældede eller utilgængelige data detekterbare. Søgemaskiner og AI-systemer skal se den samme materielle tilstand som en køber; strukturerede data kan ikke reparere en modstridende side.

Hvornår skal det bruges

Brug en tilgængelighedsblok, når lager eller opfyldelse ændrer, om en læser kan gennemføre den tilsigtede handling. Den hører til på fysiske produktsider, produktlister hvor lager påvirker valg, billetter eller lagerbegrænsede tilbud og handelsdata-endpoints designet til agenter. Den fungerer også til afhentning, lokal levering, produktionstider for specialfremstillede varer, restordre, forudbestillinger og udgåede produkter.

Render blokken pr. købbar variant, når størrelse, farve, pakke, stand, sælger eller lokation ændrer svaret. “På lager” for produktfamilien er vildledende, når den valgte størrelse ikke er tilgængelig. Hvis en markedsplads har flere sælgere, skal hvert tilbud have sin egen pris, tilgængelighed, leveringsløfte og sælgeridentitet.

Almindelige næsten-missere bør forblive uden for dette element:

  • En serviceteams næste aftale er en bookingtid, ikke lagertilgængelighed.
  • Åbningstider hører under åbningstider og kontaktinformation; “åben nu” betyder ikke, at en vare er til stede.
  • En softwarefunktions frigivelsesstatus hører til i produkt- eller frigivelsesdokumentation, medmindre adgangen reelt er kapacitetsbegrænset.
  • Et tilbuds udløb er en tilbudsbetingelse, ikke en lagerstatus.
  • En generel forsendelsespolitik forklarer regler på tværs af ordrer; tilgængelighedsblokken anvender disse regler på denne vare, destination og tid.
  • En forhandlers markedsføringspåstand som “sender hurtigt” er ikke et estimat og bør ikke optage et leveringsfelt.

Skriveregler for elementer har forrang: vælg blokken efter formål, ikke efter dens badge, kort eller accordeon-styling. Hvis det primære job er at angive, om og hvordan den valgte vare kan skaffes, er det en tilgængelighedsblok.

Hvor skal det placeres

Placer den primære blok i købsområdet, efter at køberen har valgt alle varianter, der påvirker lageret, og umiddelbart før antalskontrollen og købshandlingen. Denne rækkefølge lader siden beregne én sandfærdig tilstand, før den præsenterer “Læg i kurv.” Hvis variantkontroller sidder over prisen, placer blokken efter disse kontroller og opdater dens tilgængelige navn med valget.

På en kategori- eller listeside skal du bruge en kompakt status direkte inde i det matchende produktkort. Link til detaljesiden for destinationsspecifikke datoer, medmindre kortet kan beregne dem præcist. I en købsguide eller anmeldelse skal du placere en redaktionelt kvalificeret status ved siden af forhandleren og verifikationstidspunktet; lad være med at antyde, at udgiveren kontrollerer lagerbeholdningen.

Blokken kan sidde ved siden af pris, når begge refererer til samme variant og sælger. Den må ikke sidde ved siden af et modstridende badge, en aktiveret købsknap for en utilgængelig vare, en ikke-relateret nedtællingstimer eller et leveringskrav baseret på en anden destination. Placer ikke et testimonium, en salgsfremmende karrusel eller krydssalg mellem status og dens næste handling. Skjul ikke udgået status under anmeldelser, mens den tidligere købskontrol forbliver synlig.

Mobilrækkefølgen skal forblive: valgt variant, lagerstatus, leverings- eller afhentningsmuligheder, betingelser, derefter handling. En klæbrig købslinje kan gentage en kort status, men den skal stamme fra samme kilde og aldrig modsige den fulde blok.

Anatomi

  1. Kontekst: identificerer det præcise produkt, variant, sælger og lokation, som faktaene gælder for.
  2. Lagerstatus: bruger én kontrolleret tilstand såsom På lager, Lavt lager, Udsolgt, Restordre, Forudbestilling eller Udgået.
  3. Mængdeangivelse: giver et verificeret antal eller en ikke-numerisk tærskel-etiket; den skaber aldrig kunstig knaphed.
  4. Destination: angiver landet, regionen, postnummeret eller den valgte butik, der bruges til estimatet.
  5. Opfyldelsesmetode: adskiller forsendelse, lokal levering, afhentning og digital levering.
  6. Leverings- eller klarhedsinterval: viser en absolut dato eller et afgrænset interval, ikke “snart.”
  7. Bestillingsfrist og betingelser: angiver tidszone, bestillingsfrist, antagelse om hverdage, medlemskabskrav eller minimumsordre, når det er væsentligt.
  8. Politik for utilgængelighed og handling: forklarer genopfyldning, substitution, restordre, notifikation eller arkiveringsadfærd.
  9. Friskhed og kilde: registrerer, hvornår tilstanden blev opløst, og hvilken autoritativ tjeneste der leverede den.
  10. Handelshandling: matcher tilstanden: køb, forudbestilling, tilmeld venteliste, find en anden butik eller se efterfølger.

Designeksempler

Hver variant bruger tekst såvel som farve, bevarer konteksten for den valgte vare og eksponerer et tidsstempel eller en live-kildekontrakt.

På lager med opfyldelsesmuligheder. Brug når varen kan sælges nu. Adskil onlinelager fra butiklager, og vis ét estimat pr. berettiget metode.

Lavt lager. Brug kun når en styret tærskel er overskredet. Vis et præcist antal kun, hvis det er sikkert og tilstrækkeligt aktuelt; sig ellers “Lavt lager” og behold tidsstemplet.

Udsolgt, genopfyldning forventet. Deaktiver den umiddelbare købshandling, medmindre restordre accepteres. Angiv det forventede interval kun når merchandising- eller forsyningsdata understøtter det.

Restordre eller forudbestilling. Hold disse tilstande adskilte. Angiv hvornår betaling autoriseres eller hæves, den forventede afsendelses- eller frigivelsesdato, annulleringsvilkår, og om blandede kurve sendes separat.

Udgået. Fjern aktive købskontroller og aktiv-offert-markering. Bevar nyttige specifikationer og supportinformation, identificér derefter en officiel efterfølger kun når forholdet er verificeret.

Butiksafhentning. Angiv butikken, tidspunkt for klar, reservationsvarighed og eventuelle identifikationskrav. “Tilgængelig i nærheden” er ikke tilstrækkeligt, når køberen skal rejse.

Parametre

“Kilde” nedenfor betyder, hvor rendereren henter værdien. Handelssystemer forbliver ansvarlige for det underliggende krav.

Interfaceparametre for tilgængelighedsblok
NavnTypePåkrævetMin/maksStandardKilde
titleAlmindelig strengNej1–5 ordTilgængelighedFørste overskrift i brødtekst
statusStyret enumJaPræcis 1 tilstandIngenAttribut
skuAlmindelig identifikatorJa for varianter1–64 tegnEjende produktAttribut
sellerAlmindelig identifikatorJa for markedspladser1 værdiSiteejerAttribut
quantityIkke-negativt heltalNej0–systemmaksimumSkjultAttribut
destinationLand, region, postnummer eller butiks-IDJa for et estimat1 destinationErklæret webstedsmarkedAttribut
methodEnum-listeJa1–4 metodershippingAttribut
earliestISO 8601 dato-tidBetinget1 værdiIngenAttribut
latestISO 8601 dato-tidBetinget1 værdi; ikke før earliestSamme som earliestAttribut
cutoffISO 8601 dato-tid med offsetNej1 værdiFraværendeAttribut
checkedISO 8601 dato-tid med offsetJa1 værdiIngenAttribut
sourceStyret systemnavnJa1–2 kilderIngenAttribut
policyAlmindelig tekstPåkrævet hvis ikke på lager10–45 ordIngenBrødtekst
actionEtiket og URL eller kontrolmålJa2–6 ord; 1 målAfledt af statusBrødtekst

Den styrede status knytter sig til handelens sandhed, ikke præsentation: in-stock, limited, out-of-stock, backorder, preorder eller discontinued. En kanalspecifik værdi som collection-only hører til method, fordi en vare kan være på lager, mens den kun er tilgængelig via afhentning.

Syntaks og kodeeksempler

De tre former koder den samme valgte SKU, tilstand, leveringsinterval, kilde og handling. Et projekt skal registrere den tilsvarende Hugo- eller WordPress-adapter, før den syntaks bruges i produktion.

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"}
## Tilgængelighed

På lager online og klar til afsendelse.
Handling: [Læg marineblå Trail Jacket, str. M i kurv](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" >}}
## Tilgængelighed

På lager online og klar til afsendelse.
Handling: [Læg marineblå Trail Jacket, str. M i kurv](https://example.com/cart/add/TJ-NV-M)
{{< /availability >}}

Alle parametre er navngivne. Eksemplet undgår bevidst at blande positionelle og navngivne parametre.

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 online og klar til afsendelse.
Handling: <a href="https://example.com/cart/add/TJ-NV-M">Læg marineblå Trail Jacket, str. M i kurv</a>
[/availability]

En native WordPress-blok bør gemme disse værdier som typede attributter frem for en enkelt rich-text-klump. Server-side-rendering foretrækkes til den indledende tilstand; klient-side-personalisering kan forfine destinationen og estimatet efter samtykke eller input.

Gode og dårlige eksempler

Godt

Marineblå Trail Jacket, str. M — på lager online. Levering til 10001 estimeres til 31. august–1. september med standardforsendelse. Bestil senest kl. 14:00 ET den 28. august. Tilgængelighed for butiksafhentning kontrolleres separat. Lager- og leveringsestimat kontrolleret kl. 09:42 ET den 27. august 2026.

Dette virker, fordi det binder tilstanden til en valgt variant, destination, metode, datointerval, tidszone og verifikationstidspunkt. Læseren kan handle uden at fortolke et ikon eller åbne en generisk politik.

Dårligt

🟢 Skynd dig! Tilgængelig nu — sælger hurtigt. Levering snart. Kun få tilbage!

Dette fejler, fordi “tilgængelig” ikke har nogen variant, sælger eller kanal; “snart” har ingen destination eller datoer; “få” har ingen styret tærskel; og haster kan ikke revideres. Det grønne ikon bærer også en betydning, der er fraværende i teksten. At erstatte ikonet med et rødt ville ikke løse de manglende fakta.

Skemaopmærkning og tilgængelighed

For en ægte købbar vare kan blokken fodre Product.offers gennem et Offer eller AggregateOffer. Kortlæg den styrede synlige tilstand til den tilsvarende Schema.org-tilgængeligheds-URL, såsom InStock, OutOfStock, BackOrder, PreOrder, Discontinued eller LimitedAvailability. Pris, valuta, sælger, varens stand og URL skal beskrive samme tilbud. Brug ikke InStock blot fordi en anden variant eller sælger har lager.

Leveringsfakta kan fodre OfferShippingDetails: destination, ekspeditionstid, transittid, takst og berettiget metode skal være i overensstemmelse med det synlige løfte. Udsted ikke et aktivt Offer for en udgået vare, eller efterlad forældet tilbudsopmærkning, når den synlige handling bliver en venteliste.

Strukturerede data er et output af handelstilstanden, ikke en anden lagerdatabase. Generér den synlige blok, feed og JSON-LD fra samme afklarede tilbud, når det er muligt. Hvis de ikke kan opdateres på samme tidsplan, publicér den mindst tilladende forsvarlige tilstand, indtil synkronisering er fuldført.

Tilgængelighed kræver en tekstetiket for hver status; farve, animation og ikoner kan forstærke, men må aldrig definere den. Associer opdateringer med den valgte variant. Når en variant- eller destinationsændring opdaterer blokken asynkront, flyt hverken fokus eller læseren uventet; annoncér et kortfattet resultat gennem et passende konfigureret live-område. Undgå at gentage nedtællingsmeddelelser hvert sekund.

Leveringskontroller har brug for eksplicitte etiketter som “Leveringspostnummer” og “Skift afhentningsbutik.” Datoer skal inkludere måneden med bogstaver, hvor numerisk rækkefølge kunne være tvetydig, og bestillingsfrister har brug for en tidszone. Deaktiverede købskontroller har brug for tilstødende tekst, der forklarer hvorfor og tilbyder den gyldige næste handling. Hold den fulde tilstand tilgængelig uden hover, og sørg for et server-renderede alternativ, når JavaScript svigter.

Skriveregler

Indled med den styrede status i to til seks ord: “På lager online,” “Restordre tilgængelig” eller “Udgået.” Følg op med konsekvensen: klar til afsendelse, forventet frigivelsesdato eller ikke længere i salg. Brug én blok pr. valgt tilbud, ikke én blok pr. lagerpost.

Brug absolutte leveringsdatoer eller et afgrænset todato-interval. Hvis estimatet ændres efter destination, angiv destinationen. Hvis intet estimat er pålideligt, sig hvad der skal ske, før et kan beregnes. “Normalt,” “snart,” “hurtigt” og “bør ankomme” er ikke erstatninger for et kildedækket interval.

Hold den primære blok til én statuslinje, én til fire opfyldelsesrækker, én politiksætning på 10–45 ord når nødvendigt, og én primær handling. En lavt-lager-etiket kræver en godkendt tærskel; et præcist antal kræver en aktuel kilde. Gennemgå tilstanden løbende gennem systemintegration og test dens reserve under hver indholds-QA-cyklus.

Brug roligt, operationelt sprog. Inkludér aldrig fabrikeret knaphed, anonyme popularitetspåstande, ikke-relaterede rabatter, testimonier, garantidetaljer, fulde returbetingelser eller generisk forsendelsespolitiktekst. Kald aldrig en forudbestilling “på lager,” fremstil ikke en utilgængelig vare som “tilgængelig til bestilling” uden at nævne restordre, eller lov en dato, som opfyldelsessystemet ikke kan understøtte.

For udgåede varer, sig “Udgået” frem for “I øjeblikket utilgængelig.” Forklar om support, dele, manualer eller en officiel efterfølger forbliver tilgængelige.

Posttyper, der bruger det

postTypes-frontmatter-feltet er kilden til denne implementeringsmatrix.

Brug af tilgængelighedsblok efter posttype
PosttypeRollePlaceringPåkrævet tilpasning
ProduktsidePrimær købsbegrænsningEfter variantvalg, før antal og købshandlingAfklare pr. SKU, sælger, destination og metode
KategorisideKompakt udvælgelsessignalInde i hvert matchende produktkortVis en kanalniveau-status; udskyd præcis levering indtil destination er kendt
KøbsguideTidsfølsomt forhandlerfaktumVed siden af det anbefalede produkt og forhandlerAngiv sælger og verifikationstidspunkt; undgå at antyde udgiverkontrol
AnmeldelsessideAktuel købsvejNær vurdering eller forhandlerhandlingAdskil testede produktfakta fra aktuel forhandlerlager
Agente produktdataMaskinhandlingsbar tilbudstilstandInden for hver tilbudspostEksponér stabile identifikatorer, tidsstempler, destinationer, metoder og synkroniseret skema

QA-tjekliste

  • Status gælder for den valgte SKU, sælger, kanal og lokation frem for produktfamilien generelt.
  • Lager, salgbarhed, opfyldelsesmetode og leveringstidspunkt er separate felter og modsiger ikke hinanden.
  • Lager- og opfyldelseskilderne er autoritative, overvågede og navngivet i komponentkontrakten.
  • Tjekket-tidspunktet er til stede, inkluderer en tidszone og opfylder virksomhedens friskhedstolerance.
  • Præcise antal og lavt-lager-etiketter bruger styrede regler snarere end salgsfremmende hastværk.
  • Hvert leveringsestimat angiver eller arver en synlig destination og bruger en absolut dato eller et afgrænset interval.
  • Restordre- og forudbestillingstilstande forklarer betalingstidspunkt, forventet afsendelse eller frigivelse og annulleringsbetingelser.
  • Udsolgte og udgåede tilstande fjerner eller erstatter den umiddelbare købshandling.
  • Synligt indhold, feeddata, betalingsadfærd og Udbud-strukturerede data beskriver samme tilstand.
  • Status formidles i tekst, dynamiske ændringer annonceres passende, og kontroller har eksplicitte etiketter.
  • Blokken forbliver meningsfuld uden farve, hover, animation, personalisering eller JavaScript.
  • Mobile og klæbrige købsbehandlinger stammer fra samme kilde og bevarer den korrekte læserækkefølge.
  • Alle tre syntakseksempler knytter sig til de samme typede felter uden at miste kilde- eller friskhedsdata.

FAQ

Bør en tilgængelighedsblok vise et præcist lagertal?

Kun når lagerstyringssystemet er autoritativt, tallet opdateres hurtigt nok, og eksponeringen ikke udgør nogen operationel eller sikkerhedsmæssig risiko. Ellers brug en kontrolleret status som På lager, Lavt lager, Restordre eller Udsolgt. Opfind aldrig hastværk med et uverificeret tal.

Hvad skal blokken sige, når en vare er udsolgt?

Angiv Udsolgt, forklar om genopfyldning forventes, giv en verificeret dato eller datointerval, når en sådan findes, og tilbyd en relevant næste handling såsom en genoplagringsalarm. Vis ikke et købbart Udbud eller en aktiv Læg i kurv-handling, når betalingsprocessen ikke kan tage imod ordren.

Hvordan bør restordre og forudbestillinger adskille sig?

En restordre er en etableret vare, der midlertidigt ikke er tilgængelig til øjeblikkelig opfyldelse; en forudbestilling er en vare, der endnu ikke er frigivet til normalt salg. Mærk tilstanden præcist, angiv hvornår betaling opkræves, og giv den forventede afsendelses- eller frigivelsesdato med eventuel usikkerhed.

Kræver en tilgængelighedsblok Udbudsskema?

Nej. Den synlige blok skal være præcis, selv uden strukturerede data. Når siden beskriver et ægte købbart tilbud, bør dens synlige tilstand være i overensstemmelse med Udbud’s tilgængelighedsværdi og eventuelle forsendelsesdetaljer. Redaktionelle omtaler og utilgængelige katalogposter må ikke markeres som aktive tilbud.

Kan leveringsestimater personaliseres efter lokation?

Ja, hvis destinationen er identificeret, og et ikke-personaliseret alternativ forbliver tilgængeligt. Annoncér dynamiske ændringer til hjælpeteknologi, undgå at bruge IP-placering som sikkerhed, og hold den server-renderede lagerstatus præcis for crawlere og brugere uden JavaScript.

← All SEO Playbook guides

Klar til at føre det ud i livet?

Gratis tjek · 7-dages prøveperiode · intet kreditkort