Agentisk produktdatasida

Syfte: ge en AI-shoppingagent tillräckligt med exakt, aktuell, maskinläsbar information för att identifiera en vara, utvärdera ett erbjudande, beräkna om den kan levereras, förklara returrisken och överlämna eller slutföra en transaktion utan att gissa.

Primär fråga: “Kan jag köpa den här exakta produkten för den här kunden, till det här priset, på den här platsen, under dessa leverans- och returvillkor?”

En agentisk produktdatasida är en stabil offentlig representation av en produkt eller variantfamilj byggd för både inspektion och åtgärd. Till skillnad från en konventionell produktsida , som kan förlita sig på visuell hierarki och övertalande kontext, behandlar denna typ identitet, erbjudande, tillgänglighet, leverans och returer som explicita fält med omfattning. De två formaten bör normalt samexistera på en kanonisk URL: människor får förklaring och bevis; agenter får samma fakta i synlig text, strukturerad märkning och pålitliga handelsgränssnitt.

Frågor den besvarar

Sidan måste låta en shoppingagent besvara alla dessa utan att härleda ett saknat värde:

• Vilken exakt produkt och variant beskriver denna post?
• Vilken handlar-SKU, global identifierare, varumärke, modell, storlek, färg, kapacitet och skick identifierar den?
• Vad är det aktuella priset, valutan, enheten, skattebehandlingen och giltiga erbjudandeperioden?
• Är den valda varianten faktiskt tillgänglig, restnoterad, förbeställningsbar eller utgången?
• Kan den levereras till kundens destination, till vilken kostnad, genom vilken metod och inom vilket leveransfönster?
• Vem säljer och uppfyller den, och var övergår ansvaret?
• Vad kan returneras, inom hur många dagar, genom vilken metod, på vems bekostnad och med vilka undantag?
• Vilken åtgärd är giltig nu: köpa, reservera, begära offert, gå med i väntelista eller välja ett annat erbjudande?

Sidan är redo för agentisk användning först när frånvaro är explicit. “Leverans ej angiven” är annorlunda än fri frakt; “tillgänglighet okänd” är annorlunda än i lager.

När du ska använda denna posttyp

Använd den när en produkt kan väljas eller handlas med och en automatiserad klient behöver mer än en marknadsföringsbeskrivning. Den är särskilt värdefull där varianter, säljare, destinationer eller policyundantag gör svaret villkorat.

Skapa inte en separat indexerbar “AI-version” som upprepar den mänskliga sidan. Duplicering skapar konkurrerande kanoniska URL:er och två ställen där volatila fakta kan divergera. Använd en separat representation endast när innehållsnegotiering, en dokumenterad ändpunkt eller ett icke-indexerbart datasvar tjänar ett verkligt klientbehov.

Bäst för dessa företagstyper

1. E-handel . Den starkaste passformen eftersom pris, variant, lager, leverans och returer redan finns i operativa system. Uppgiften är att exponera dem med samma identifierare och omfattning som används i kassan.
2. Marknadsplatser . Väsentlig när en produkt har flera säljare eller skick. Produktidentitet måste förbli separat från erbjudandeidentitet så att en agent inte kopplar en säljares pris till en annan säljares leverans- eller returvillkor.
3. Tillverkare och industriella företag . Värdefullt för modellnummer, teknisk kompatibilitet, förpackningskvantiteter, regionala distributörer, ledtider och offertbaserad tillgänglighet. “Kontakta oss” bör fortfarande visa vad som kan offereras och vilka fakta som varierar.
4. SaaS . Användbar när en plan, tillägg, sittplats-paket eller användningspaket verkligen är köpbart. Ersätt fysiska fraktfält med aktiveringstidpunkt och regional eller kontobaserad behörighet, samtidigt som prisbasis, förnyelse, avbokning och säljaridentitet hålls explicita.

Sökavsikt

Avsikten ligger vid gränsen mellan beslut och transaktion. Sökfrågor kombinerar en känd produkt eller modell med “pris”, “i lager”, “leverans till”, “returer”, en storlek eller färg, eller en köpinstruktion. En AI-prompt kan lägga till begränsningar i en mening: “Hitta den svarta 256 GB-modellen under €900, levererad till Bratislava nästa vecka, med minst 30 dagars returrätt.”

Rätt svar är inte en allmän rekommendation. Det är ett begränsningsbevarande erbjudande: exakt variant, exakt säljare, aktuellt totalpris, destinationsbehörighet, leveransuppskattning, returvillkor och en stabil åtgärd. Om ett villkor inte kan verifieras måste svaret identifiera luckan istället för att tyst släppa på det.

Sidstruktur

Ordbälten håller förklaring proportionerlig. Det mest kritiska innehållet är fältdata, inte prosa, och måste genereras från styrda källor snarare än kopieras in i redaktionell text.

Obligatoriska element

Positionering följer beroende: ett erbjudande kan inte utvärderas förrän identiteten är stabil, och ett leveranslöfte kan inte utvärderas förrän erbjudande och destinationsomfattning är kända.

Frontmatter

Följ frontmatter-specifikationen . På denna specifikationssida, använd entity = "post-type-agentic-product-data" och schemaTypes = [ "Article", "FAQPage" ] eftersom sidan förklarar en posttyp snarare än att sälja det fiktiva exemplet.

På en producerad handelssida måste entity identifiera den stabila produkten, till exempel northstar-travel-charger-65w, medan SKU och globala identifierare identifierar säljbara varianter. Använd Product för produkten och Offer för en säljares köpbara erbjudande; använd AggregateOffer endast när den synliga sidan verkligen sammanfattar flera erbjudanden. Lägg till tillämpliga frakt- och handlar-returpolicyegenskaper. En produktsida som innehåller synligt FAQ-innehåll kan också kvalificera för FAQPage, med förbehåll för aktuella sökmotorregler, men FAQ-märkning ersätter inte Product- och Offer-data.

Sanningskällan bör också styra flöden, API:er och kassa. Obligatoriska operativa fält inkluderar valuta, marknad, säljare, uppfyllelseägare, vald SKU, prisgiltighet, tillgänglighetstidsstämpel, leveransdestinationsomfattning, returpolicyomfattning, kanonisk URL och dataägare. Schemafullständighet innebär att obligatoriska beslutsfält både är ifyllda och korrekta – inte att varje möjlig egenskap förekommer.

Fullständigt exempel

Denna fiktiva sida visar det lägsta transaktionsavtalet. Dess värden är exempel, inte påståenden om en verklig handlare.

# Northstar 65 W reseadapter — EU, svart

Northstar 65 W reseadapter, SKU NS-65-EU-BLK och GTIN 09506000134352, säljs som ny av Northstar Direct för €49,00 inklusive moms. Denna EU-svarta variant finns i lager. Standardleverans till Slovakien kostar €4,90 och beräknas till 1–3 september 2026 vid beställning före 14:00 CEST den 27 augusti.

## Produktidentitet

| Fält | Värde |
|---|---|
| Varumärke | Northstar |
| Modell | Travel Charger 65 W |
| Handlar-SKU | NS-65-EU-BLK |
| GTIN-14 | 09506000134352 |
| Variant | EU-kontakt, svart |
| Skick | Ny |
| Ingår | Laddare och 1 m USB-C-kabel |

## Erbjudande

| Säljare | Pris | Valuta | Skatt | Tillgänglighet | Giltig till |
|---|---|---|---|---|---|
| Northstar Direct | 49,00 | EUR | Moms inkluderad | I lager | 31 augusti 2026, 23:59 CEST |

Priset gäller för en NS-65-EU-BLK-enhet. Maximal onlinekvantitet är fyra per beställning. Säljare och uppfyllelseleverantör är Northstar Direct.

## Leverans till Slovakien

| Metod | Kostnad | Hantering | Transport | Beräknad leverans |
|---|---|---|---|---|
| Standard spårbar | €4,90 | Samma arbetsdag före 14:00 CEST | 2–4 arbetsdagar | 1–3 september 2026 |
 | Express spårbar | €12,90 | Samma arbetsdag före 14:00 CEST | 1–2 arbetsdagar | 31 augusti–1 september 2026 |

Litiumbatterier ingår inte. Leveransuppskattningar exkluderar adresskorrigeringar och transportörsstörningar. Omberäkna frakt efter att destination eller varukorgskvantitet ändras.

## Returer och garanti

Oanvända produkter kan returneras inom 30 kalenderdagar från leverans via online-returformuläret. Kunden betalar returporto om inte produkten är felaktig eller felaktigt levererad. Öppnad förpackning accepteras när laddaren, kabeln och dokumentationen är kompletta och oskadade. Återbetalningar går tillbaka till ursprunglig betalningsmetod efter inspektion. En tvåårig begränsad garanti täcker tillverkningsfel men inte olycksfalls- eller vätskeskador.

## Transaktionsstatus

Verifierad mot katalog-, lager-, leverans- och retursystem kl. 10:00 CEST den 27 augusti 2026. Omvalidera pris, lager, destinationsbehörighet, leveransuppskattning och returomfattning omedelbart före kassa.

[Köp den EU-svarta varianten]

Exemplet håller pris och giltighet tillsammans, separerar hantering från transport, namnger returbetalaren och avgränsar varje volatilt påstående. En människa kan läsa det; en agent kan mappa det till fält utan att tolka ett reklamuttryck.

Designgalleri

Använd samma produkt, variant, säljare, destination och tidsstämpel i varje design så att granskningen testar dataförståelse snarare än olika exempel.

Kvalitetskontrollista

• En kanonisk produktidentitet är separerad från SKU-nivåns varianter och säljarnivåns erbjudanden.
• SKU-, GTIN-, ISBN- eller tillverkarens artikelnummer-värden tillhör den exakta varianten; ingen identifierare är härledd eller påhittad.
• Produktnamn, varumärke, modell, skick, valda attribut och kanonisk URL överensstämmer i synligt innehåll, schema, flöde och kassa.
• Pris inkluderar valuta, enhet eller faktureringsbasis, skatteomfattning, säljare, kvantitetsregel och giltighet där relevant.
• Tillgänglighet beskriver den valda SKU:n och säljaren, inte den överordnade produkten eller en angränsande lagerpost.
• Leverans anger destinationsomfattning, kostnad, tröskel, hanteringstid, transporttid, beräknad leverans och begränsningar utan att behandla en uppskattning som en garanti.
• Returer anger tidsfönster, starttidpunkt, accepterat skick, metod, avgifter, återbetalningsväg och produkt- eller regionala undantag.
• Okända värden identifieras som okända; tomma celler innebär aldrig gratis, inkluderat eller tillgängligt.
• Volatila fakta kommer från operativa system och visar en meningsfull verifieringstid.
• JavaScript-inaktiverade och renderade svar exponerar båda de kritiska identitets- och erbjudandefakta som behövs av avsedda klienter.
• Product- och Offer-märkning matchar synligt innehåll och använder korrekt variant, säljare, valuta och policyomfattning.
• Köp- eller överlämningsåtgärden bevarar variant, erbjudande, destination, kvantitet och attribution.
• Slut i lager, förbeställning, endast-offert och utgångna tillstånd ändrar både meddelandet och den tillåtna åtgärden.
• Automatiserade tester upptäcker avvikelser mellan sida, schema, flöde, API och kassa innan ett inaktuellt erbjudande når en agent.
• Manuell granskning kontrollerar undantagsformuleringar, reglerade påståenden och ovanliga leverans- eller returfall som fältvalidering inte kan bedöma.

Vanliga misstag

Att behandla schema som dold produktkopiering. Strukturerad data beskriver synliga fakta; den får inte introducera ett bättre pris, annat betyg, bredare tillgänglighet eller returlöfte än vad sidan visar.

Att använda en överordnad SKU för varje variant. Ett blått medium-plagg och ett svart stort plagg är olika säljbara val. Bind identifierare, pris, bild, lager och åtgärd till den valda varianten.

Att publicera pris utan omfattning. “€49” är ofullständigt när skatt, enhet, prenumerationsperiod, säljare, minimikvantitet, marknad eller utgångsdatum ändrar beloppet.

Att kalla okänd frakt gratis. Frakt måste beräknas eller uttryckligen anges som otillgänglig för destinationen. Ett nollvärde är ett kommersiellt löfte, inte en platshållare.

Att kombinera hantering och transport. En tvådagars transportörstjänst som skickas efter fem dagar är inte tvådagars leverans. Lagra och visa båda intervallen, beräkna sedan ett uppskattat datumintervall.

Att endast länka till en generisk retursida. Agenten behöver det tillämpliga fönstret och undantagen på erbjudandesidan, plus en stabil policy-URL för detaljer. Kategoriundantag får inte döljas bakom länken.

Att cachelagra lager som redaktionellt innehåll. Lagerstatus kan ändras mellan crawlning och kassa. Använd lämpliga cache-livslängder, ogiltigförklaring, tidsstämplar och obligatorisk omvalidering före åtagande.

Att skapa en andra “AI-produktsida.” Parallella indexerbara sidor driver isär och splittrar signaler. Föredra en kanonisk människa-och-maskin-källa med alternativa representationer endast för ett dokumenterat tekniskt behov.

Att låta CTA:n ljuga. En produkt som är slut i lager kan inte ha en aktiv “Köp nu”-knapp. Ersätt den med en lageravisering, förbeställning, offert eller ett alternativ som speglar det verkliga tillståndet.

Internlänkning

Länka uppåt till kategorisidan när en agent måste välja bland produkter, och i sidled till specifikationen för den kanoniska produktsidan när produktionsgruppen behöver mänskliga bevis och övertalningsregler. Länka till en dokumentationsartikel för installation, kompatibilitetsdetaljer, skötsel eller användning efter köp istället för att fylla transaktionsfält med instruktioner.

Inom produktposten, håll länkar intill den förutsättning som skapar nästa fråga: den fullständiga returpolicyn bredvid den sammanfattade returregeln, leveransbegränsningar bredvid frakt, och kompatibla tillbehör bredvid den relevanta specifikationen. Använd en intern länkmodul endast för en liten uppsättning förklarade alternativ eller stödjande sidor. Låt inte en agent navigera flera vaga “lär dig mer”-länkar för att rekonstruera en transaktion.

Varje länkat erbjudande måste bevara variant- och säljarkontext. Parametriserade val bör lösas förutsägbart, och kanoniska regler bör förhindra att filter-, valuta- och destinationstillstånd multipliceras till duplicerade indexerbara webbadresser.

Hur man mäter resultat

Mät tillförlitlig produktidentifiering och transaktionsförlopp, inte enbart sidtrafik. Upprätta en baslinje per marknad, enhet, klient, produkt, variant och säljare där volymen tillåter.

Spåra:

• giltiga produkter och säljbara varianter med fullständiga identifierare;
• Product- och Offer-poster som klarar teknisk validering och kommersiell avstämning;
• avvikelser i pris, valuta, lager, säljare, frakt, returer och vald SKU mellan sida, schema, flöde, API och kassa;
• crawl- eller agentförfrågningar som får användbar kritisk data utan skript-, samtyckes-, autentiserings- eller timeout-fel;
• shopping-svar och citat som bevarar variant, säljare, pris, tillgänglighet, destination, leverans och policyvillkor;
• produktval, lägg-i-varukorg, kassastart, offert, reservation och slutförda orderevent som attribueras till den ursprungliga klienten eller överlämningen;
• misslyckade överlämningar orsakade av inaktuellt lager, ändrat pris, ej stödd destination, ogiltig variant, utgången session eller policyavvikelse;
• avbokningar, returer och kundservicekontakter orsakade av en uppgift som agenten presenterade felaktigt eller utelämnade;
• tid från ändring i källsystem till korrigerad offentlig representation.

Använd AI-tillgänglighet och agentberedskap för att testa om automatiserade klienter kan nå och tolka handelsytan. Öppna AmICited Cockpit för att jämföra synlighet, citerade källor, landningsaktivitet och kommersiella utfall över samma observationsperiod.

Följ hur vi mäter resultat för att separera upptäckt, korrekt representation, engagemang, transaktionsförlopp och intäkter. Kommentera katalogmigreringar, priskampanjer, lagerhändelser, policyändringar och protokollsläpp innan du attribuerar förändringar. Ett citerat produktsvar är inte en framgång om dess erbjudande inte överlever kassavalidering.

FAQ

Vanliga frågor