Produktdetaljsida

Syfte: ge en köpare allt som behövs för att avgöra om en exakt produkt är rätt, i samma ordning som deras tvivel uppstår.

Läsarfråga: “Är detta rätt produkt för min situation, vad exakt kommer jag att få, vad kommer det att kosta och när kommer det att anlända, och vad händer om det är fel?”

En produktdetaljsida är beslutssidan för en säljbar produkt eller en snävt hanterad variantfamilj. Den måste identifiera artikeln, förklara passform, visa exakta fakta, visa levererad kostnad och tillgänglighet, presentera trovärdig köparupplevelse och klargöra risken med ett felaktigt val. Följ tvivlets ordning: vad det är → om det passar → innehåll och specifikationer → pris och leverans → vad köpare fann → vad som händer om det är fel.

Frågor den besvarar

Sidan bör besvara dessa frågor utan att kräva en recensionssida, policy-sida eller ytterligare produktflik:

• Är detta den exakta modellen eller paketet, och passar det mitt fall?
• Vad ingår; vilka är dess dimensioner, sammansättning, kompatibilitet, begränsningar och skötselbehov?
• Vad kommer den valda varianten att kosta, och när kommer den att anlända?
• Vad fann verifierade ägare, inklusive begränsningar?
• Vad kan jag returnera, byta, reparera eller göra anspråk på under garanti?
• Är en annan variant, ett paket eller en produkt en bättre passform?

Sidan lyckas när en kvalificerad köpare kan genomföra ett köp och en okvalificerad köpare kan utesluta produkten. Att förhindra en felaktig beställning förbättrar konverteringskvaliteten.

När denna posttyp ska användas

Välj denna typ när en produkt, modell eller väsentligt distinkt variant är beslutsobjektet och användaren kan köpa, begära en offert, starta en provperiod, reservera eller gå med i en lagerbevakning.

Skapa en indexerbar sida för ett distinkt köparbeslut, inte bara ytterligare en lageridentifierare. Kosmetiska varianter hör vanligtvis ihop; produkter med olika passform, användning eller säkerhetskrav gör det inte.

Bäst för dessa företagstyper

1. E-handel. Exakta varianter, lager, levererat pris, specifikationer, sammansättning, returer och original-SKU-bevis avgör om en katalog blir användbart sortiment eller skalat dubblettinnehåll.
2. Marknadsplatser. Bibehåll en stabil produktidentitet medan varje erbjudande bevarar skillnader i säljare, skick, pris, uppfyllelse och returer.
3. SaaS. Produkt- eller plansidor måste ange passform, ingående kapacitet, begränsningar, prisbas, introduktion, support och uppsägning utan att skapa tunna sidor för mindre funktioner.
4. Medieutgivare och affiliates. Handelsfärdiga poster kräver tydligt ägarskap och kommersiell redovisning. Oberoende testning hör hemma i ett recensions- eller jämförelseformat.

Tjänster bör endast använda denna typ för en standardiserad, valbar produkt med fasta fakta och en åtgärd på produktnivå.

Sökavsikt

Avsikten är transaktionsbaserad: ett produktnamn, modell, SKU, funktion-plus-produktförfrågan eller begäran att köpa en exakt artikel. Sökresultat visar bilder, pris, tillgänglighet, betyg, frakt och returer; AI-svar komprimerar dessa till passform, specifikationer, erbjudandedetaljer, avvägningar och alternativ.

Granska den levande resultatuppsättningen för den exakta modellen och marknaden. Registrera land, enhet, datum, kommersiella fält, vanliga frågor och variantförvirring; täpp till dess beslutsgap snarare än att kopiera rubriker.

Använd denna svarsform:

1. Identifiera den exakta produkten och vald variant.
2. Ange dess bästa passform och avgörande undantag.
3. Visa produkten genom original, användbar media.
4. Presentera sammansättning, ingående artiklar och specifikationer som strukturerad fakta.
5. Visa pris, valuta, lagerstatus, uppfyllelseägare, utskickningsuppskattning och leveransuppskattning för aktuellt val.
6. Sammanfatta trovärdig ägarupplevelse utan att dölja återkommande begränsningar.
7. Förklara retur-, garanti-, avboknings- och ersättningsalternativ.
8. Erbjud relaterade produkter först när passformen är tydlig.

Sidstruktur

Ordintervaller styr betoning; specifikationer tillhör rader.

Specifikationer är strukturerad data, inte prosa

En rad som Bredd — 61 cm är sökbar, jämförbar, flödesklar och extraherbar. Samma fakta begravda i “dess kompakta ram passar många utrymmen” är det inte.

Definiera varje attributs etikett, enhet, värdetyp och SKU-omfattning. Lagra det en gång för sida, flöde och markup. Använd prosa för konsekvenser: “61 cm får plats i en 65 cm alkov.”

Använd aldrig “en storlek”, “standard”, “kompatibel”, “naturlig” eller “snabb” utan en gräns. Namnge mått, versioner som stöds, ingrediensprocentandelar där kända, testförhållanden och undantag.

Obligatoriska element

Systemet för unikt innehåll

Det största problemet med produktsidor är strukturellt: tillverkartext går in i en mall, vilket producerar hundratals sidor som endast skiljer sig åt i namn, färg eller några siffror. Att be skribenter att “göra beskrivningar unika” åtgärdar inte systemet.

Dela in fält i tre ägandeskapsnivåer:

Använd en kanonisk förälder för kosmetiska varianter. Stabila parametrar kan bevara val, men kombinationer får inte bli konkurrerande indexerbara sidor. En variant förtjänar sin egen sida endast med distinkt efterfrågan och väsentligt annorlunda passform, specifikationer, sammansättning, användning eller erbjudandebevis.

Paket behöver en materialförteckning, SKU, pris, tillgänglighetsregel och ärlig besparingsgrund. Skapa en sida endast när den kombinerade uppgiften och vägledningen skiljer sig; behandla annars paketet som ett erbjudande på föräldrasidan.

Slut i lager och utgångna produkter

Vid tillfällig brist, håll sidan aktiv, ange “slut i lager”, ta bort markup för ej tillgängligt köp, bevara innehåll och recensioner, och erbjud ett känt återlanseringsdatum, bevakning eller alternativ.

En utgången URL med länkar, efterfrågan, recensioner, manualer eller supportvärde bör förbli en produktpost med specifikationer och en förklarad ersättning. Omdirigera endast till en genuint likvärdig efterföljare. En 404 på en länkad produkt kastar bort auktoritet och lämnar ägare utan vägledning.

Recensioner och användargenererade bevis

Recensionsinnehåll tillhandahåller användningsfall, hållbarhetsobservationer, passformsdetaljer och feltillstånd som ett katalogteam inte kan uppfinna. Visa antal, betygsfördelning, datum, variant, verifieringsmetod och sammanhang. Lyft fram negativa mönster lika tydligt som beröm.

Utan recensioner, säg det. Använd legitima bevis: originalmått och fotografier, installationsanteckningar, skillnader mot närliggande modeller, tester, policyer och besvarade frågor. Plantera aldrig betyg, omformulera aldrig personalkommentarer som kunder, importera aldrig en annan modells recensioner eller påstå kundkärlek utan bevis.

Moderera övergrepp och personuppgifter, inte åsikter. Redovisa incitament och kräv aldrig positivitet.

Frontmatter-specifikation och schema

Följ den gemensamma Frontmatter-specifikationen och sätt entity = "product-page". Kräv titel, sex till åtta nyckelord, 150–160 teckens beskrivning, kanonisk URL, datum, handboksfält, ägare, granskningsintervall, identifierare, varumärke, variantpolicy, marknad, schematyper och fem till åtta matchande [[faq]]-poster.

Använd schemaTypes = [ "Product", "Offer", "AggregateRating", "FAQPage" ] endast som en berättigandeinventering. Schema-markup måste matcha synligt innehåll:

• Product identifierar den exakta produkten eller varianten med samma namn, bild, varumärke, SKU, GTIN eller MPN, beskrivning och attribut som användare ser.
• Offer tillhör ett verkligt köpbart eller beställningsbart erbjudande. Dess pris, valuta, tillgänglighet, skick, säljare och URL måste återspegla den valda artikeln och aktuellt synligt tillstånd.
• AggregateRating är villkorligt. Lägg till det endast när det synliga betygsvärdet och antalet avser denna exakta produkt och är beräknade från genuina recensioner.
• FAQPage är villkorligt baserat på en synlig, matchande FAQ. Markera inte dolda svar eller reklampåståenden som frågor.

Sida, flöde, utcheckning och markup måste dela en sanningskälla. Ett synligt pris på 129 € med en markup på €119 gör erbjudandet otillförlitligt.

Fullständigt exempel

Detta kopierbara fiktiva skelett använder produktionsbevis-platshållare inom hakparenteser.

# Northstar Trail 28 ryggsäck

> **Bäst för:** dagsvandringar och övernattningsturer. **Välj en annan modell om:** du behöver ett laptopfack eller flerdagars vinterkapacitet.

**Vald variant:** Slate / M–L bål  
**Pris:** [aktuellt pris och valuta]  
**Tillgänglighet:** [lagerstatus för vald variant och destination]  
**Leverans:** [utskickningsuppskattning och daterad ankomstintervall]  
**Betyg:** [synligt värde och genuint recensionsantal, eller "Inga kundrecensioner än"]

## Är Northstar Trail 28 rätt för dig?

[Tre underbyggda användningsfall, avgörande undantag och nödvändig passformskontroll.]

## Produktgalleri

[Fram, bak, skala, justering, öppna fack, etikett och ingående artiklar; var och en med beskrivande alt-text och en bevisande bildtext.]

## Vad som ingår

- Northstar Trail 28 ryggsäck
- [ingående avtagbar komponent]
- [dokumentation eller verktyg]
- Ingår inte: [tillbehör som vanligtvis antas ingå]

## Material och sammansättning

| Del | Material eller sammansättning | Varför det är viktigt |
|---|---|---|
| Huvudkropp | [verifierat material och behandling] | [hållbarhets-, skötsel- eller känslighetskonsekvens] |
| Kontaktytor | [verifierat material] | [komfort- eller skötselkonsekvens] |

## Specifikationer

| Attribut | Vald variant | Omfattning eller testförhållande |
|---|---|---|
| Kapacitet | 28 L | [mätstandard] |
| Produktvikt | [verifierat värde och enhet] | Tom, inklusive [namngivna avtagbara delar] |
| Mått | [höjd × bredd × djup] | Uppackad, fickor tomma |
| Bålpassform | [intervall] | M–L variant; förklara hur man mäter |
| Vätskekompatibilitet | [reservoarstorlek och dragning] | Reservoar ingår inte |
| Garanti | [period och materialundantag] | [marknad] |

## Pris, lager och leverans

[Pris för vald variant, valuta, skattebas, lager, utskickningsplats och -fönster, destination, daterad ankomstintervall och fraktavgift. Uppdatera alla fält samtidigt när valet ändras.]

## Installation, användning och skötsel

1. Mät [passformsdimension] med [metod].
2. Justera och packa enligt [verifierade instruktioner och gräns].
3. Rengör enligt [verifierad metod och varning].

## För- och nackdelar

**Fördelar:** [Tre bevisunderbyggda fördelar med användningsvillkor.]

**Nackdelar:** [Två meningsfulla begränsningar och berörda köpare.]

## Vad ägare fann

[Betygsfördelning, antal, verifieringspolicy, variantkontext och underbyggda positiva och negativa teman; eller ett ärligt tomt tillstånd utan AggregateRating-markup.]

## Returer, garanti och support

[Returperiod, skick, kostnad, undantag, bytesväg, garanti och support för denna marknad.]

## FAQ
### Följer vätskereservoaren med ryggsäcken?
[Fakta om ingående artiklar och kompatibel storlek.]

### Hur väljer jag bålstorlek?
[Mätmetod, intervall och bytesalternativ.]

### Är den lämplig som handbagage på flyg?
[Packade mått och varning om flygbolagsregler.]

### Vad är den maximalt rekommenderade lasten?
[Värde, källa och komfortvarning.]

### Kan jag returnera den efter att ha provat passformen?
[Skick, period, kostnad och undantag.]

## Relaterade produkter

- [Större modell] — för [anledning].
- [Mindre modell] — för [anledning].
- [Tillbehör] — för [kompatibilitetsbehov].

**Primär åtgärd:** [Köp vald variant / Gå med i lagerbevakning / Se den verifierade ersättaren]

Designexempel

Fånga köpbara desktop-, mobil-, variantövergångs- och icke-köpbara tillstånd. Annotera pris- och lagerkällor, vald SKU, specificeringsomfattning och markup för synliga recensioner.

Krav för agentisk handel

En AI-handelsagent behöver exakt identitet, identifierare, variantrelationer, dimensioner, sammansättning, kompatibilitet, ingående artiklar, pris, valuta, säljare, skick, destionsmedvetet lager och leverans, returer, betyg och en stabil åtgärds-URL.

Semantisk HTML, märkta kontroller och handelsdata måste exponera samma fakta som den visuella sidan. AmICiteds granskning av AI-tillgänglighet och agentberedskap kontrollerar agentåtkomst; använd guiden för att kontrollera agentisk handelsberedskap. Protokollstöd kan inte reparera saknade storleks-, lager- eller returdata.

Kvalitetskontrollista

Godkänn sidan för publicering endast när varje tillämpligt påstående är sant:

• Hjälteidentitet, vald variant, pris, lager och CTA överensstämmer.
• Passform anger bästa fall och avgörande undantag.
• Originalinnehåll täcker skillnader, begränsningar, media, innehåll och verifierade fakta.
• Specifikationer använder kontrollerade etiketter, enheter, SKU-omfattning och källor; sammansättning stöder säkerhetsbeslut.
• Gallerivyer visar skala, kritiska detaljer och ingående artiklar med användbara alternativ och bildtexter.
• Recensioner är äkta, avgränsade, synligt räknade och känsloneutrala; ett tomt tillstånd förblir ärligt.
• Leverans, returer, garanti, avbokning och undantag visas före den slutliga CTA:n.
• Kanoniska regler förhindrar att mindre varianter skapar indexerbara nära-duplikat.
• Ej tillgängliga produkter bevarar användbara webbadresser och presenterar korrekta nästa steg.
• Product-, Offer-, AggregateRating- och FAQPage-markup matchar synliga fakta.
• Mobilanvändare och agenter kan identifiera, utvärdera och agera på den valda artikeln utan att tappa sammanhang.

Vanliga misstag

• Ambition före identitet: en slogan försenar modell, variant, pris och passform.
• Tillverkarprosa i skala: omordnade meningar är inte produktbevis.
• Adjektiv som specifikationer: “lättvikt” döljer vikt och testgrund.
• Partiella variantuppdateringar: bilden ändras medan SKU, lager, pris, URL eller markup inte gör det.
• Generiska fraktlöften: produktspecifika undantag förblir dolda.
• Tvärproduktbetyg: en familjetotal maskerar sig som exakt SKU-bevis.
• Falska lanseringsrecensioner: tillverkade bevis döljer bevisgapet.
• En URL för varje kombination: storlek, färg, paket och säljarparametrar blir nära-duplikat.
• Radering av otillgängliga produkter: användbar historik och ersättningsvägar försvinner.
• Osynlig markup: betyg, pris eller tillgänglighet motsäger gränssnittet.
• Oförklarade rekommendationer: en marginalstyrd karusell åtgärdar inte köparens felmatchning.

Internlänkning

En produktsida bör ta emot länkar från sin primära kategori, underkategorier, kompatibla produkter, guider, jämförelser, användningsfall och support. Ankartext bör identifiera produkten och relevant anledning, inte generiskt “handla nu.”

Länka uppåt till en kategori, i sidled till jämförbara produkter och nedåt till kompatibla delar. Länka till passforms-, skötsel-, installations-, ingrediens-, policy- eller supportmaterial endast när det löser en invändning. Förklara varför varje relaterad produkt är bättre för ett specifikt fall.

Duplicera inte en kategoriöversikt, oberoende recension eller symmetrisk jämförelse. Om två produkter kräver gemensamma dimensioner och ett avgörande, publicera den jämförelsen separat och länka båda vägarna.

Konsolidera variant-URL:er om inte en variant klarar regeln om unikt innehåll. Utgångna sidor bör förklara och länka till närmaste efterföljare.

Hur man mäter resultat

Koppla upptäckt till produktsekonomi: baslinjevisningar, klick, AI-citat, engagemang, lägg i varukorg eller leads, beställningar, intäkter, returer, avbokningar och support. Ökande konvertering tillsammans med returer kan indikera dålig passformskvalificering.

Använd AmICiteds Produktrapport för beställningar, enheter, intäkter, bidrag, lager och katalogmatchning per SKU; öppna app.amicited.com/reports/products. Segmentera per sida, variant, enhet, marknad och lager där möjligt. Sluta inte om orsakssamband från en enda före-efter-förändring: säsongsvariationer, kampanjer, pris, lager, rankningar och kanalmix påverkar också utfallen.

Fråga om kvalificerade köpare och agenter hittade rätt produkt, förstod passformen, valde korrekt, köpte och behöll den. Använd hur vi mäter SEO-resultat för att separera synlighetssignaler från utfall.

FAQ

Hur mycket unikt innehåll behöver varje produktsida?

Det finns ingen användbar universell ordräkning. Varje indexerbar SKU behöver originalbeslutsinformation: dess passform, differentieringsfaktorer, exakta specifikationer, ingående artiklar, begränsningar, tillgänglighet och bevis. Gemensamma policyer kan ärvas när de fortfarande är korrekta.

Ska varje produktvariant ha sin egen webbadress?

Endast när varianten har distinkt efterfrågan eller beslutsvärde och kan bära en väsentligt annorlunda sida. Mindre färg- eller förpackningsstorleksval hör vanligtvis hemma på en kanonisk produkt-URL, medan väsentligt olika modeller kan motivera separata indexerbara sidor.

Vad bör hända när en produkt permanent utgår?

Behåll webbadressen aktiv när den har efterfrågan, länkar, recensioner eller användbart supportvärde. Markera produkten som utgången, ta bort köpbarhet, bevara specifikationer och recensioner, och rekommendera den närmaste genuina ersättaren. Omdirigera endast när en tydlig motsvarighet finns.

Kan Product-schema inkludera recensioner som endast visas i en widget?

Endast om användare kan se samma betyg och recensionsinformation på sidan och markeringen korrekt beskriver produkten. Dolda, importerade eller felaktiga betygsvärden bör inte markeras upp.

Vad bör en ny produktsida visa när det inte finns några recensioner?

Ange att produkten ännu inte har några kundrecensioner, minska sedan osäkerheten med originalfotografier, fullständiga specifikationer, kompatibilitetsvägledning, testbevis, tydliga leverans- och returvillkor samt en ärlig inbjudan att recensera efter köp.

Vilka fakta behöver AI-handelsagenter från en produktsida?

De behöver en tydlig produktidentitet, SKU eller identifierare, variantrelationer, pris och valuta, tillgänglighet, skick, fraktdestination och -tid, returpolicy, specifikationer, kompatibilitet, betyg och en stabil köpväg.

Förvandla produktdata till en pålitlig beslutssida

Granska en prioriterad SKU mot denna specifikation, verifiera sedan om agenter kan läsa dess produktidentitet, erbjudande, varianter, tillgänglighet, policyer och köpåtgärd i AmICited.

Kontrollera AI-tillgänglighet och handelsberedskap