Prepare product data for voice assistants and smart speakers

Publish a one‑line product lead and a short ‘Short specs’ list at the top of each product page, and emit matching Product + Offer JSON‑LD in the initial HTML so voice agents read consistent facts.

A pale mint editorial illustration showing an off‑white product card with short spec bars beside a smart speaker and a phone with abstract waveform — implies product facts prepared for voice assistants.

Put the most useful facts where a voice assistant can read them: a one‑line lead (1–2 sentences), a short bullet list of specs, a visible price and a clear availability statement — and make sure the page’s structured data contains the same values. That combination makes it practical for assistants and search features to extract reliable answers while you keep control of what the public hears.

Contents

What to publish on the page (minimum facts)

Place these visible text elements near the top of the product page in plain text (not only images):

  • Product name (exact shop name for the SKU or variation).
  • One‑line lead — 1–2 short sentences that say what the product is and the single fact most customers ask for (e.g. “Compact rechargeable torch, 1200 lm, USB‑C”).
  • Short specs — a 2–4 bullet list named “Short specs” with machine‑friendly facts (size, weight, battery life, material, model numbers).
  • Price — clearly visible and matching your public price value.
  • Availability statement — plain text (In stock / Low stock / Out of stock / Made to order) and consistent with inventory fields.
  • Clear CTA — Add to cart, Request quote or Contact for availability.

These visible facts are the things a voice assistant will most likely try to read. Schema.org defines how to express a Product and a nested Offer for price and availability; see schema.org/Product and Google’s guidance on product structured data Product structured data for examples and required fields.

Why visible text must match structured data

Search engines recommend putting structured data in the initial HTML (server‑rendered) or ensuring client rendering is reliable so the values crawled match the visible page. Mismatches confuse extractors and can cause a crawler or assistant to ignore your markup. See Google’s note on generating structured data with JavaScript and the product snippet guidance: Generate structured data with JavaScript and Product snippet best practices.

Map WooCommerce stock to Offer.availability

Map your platform fields to schema.org availability URIs so the structured data and visible text say the same thing. For WooCommerce the REST API documents the relevant fields (manage_stock, stock_status, stock_quantity). Review the field meanings at the WooCommerce developer docs: WooCommerce REST API products and the product editor settings: WooCommerce managing products.

Suggested mapping (implementation depends on your setup):

  • If manage_stock is true and stock_status is instock, publish https://schema.org/InStock and show “In stock” on the page.
  • If stock_status is onbackorder or you explicitly allow backorders, publish https://schema.org/PreOrder or show an explicit “Available on backorder” phrase — pick the one that honestly describes delivery expectations.
  • If manage_stock is false but you sell continuously (no stock tracking), you may still show “In stock” in plain text; make sure the Offer JSON‑LD reflects the same public state.

Do not rely on a database field alone to be correct — verify important SKUs by checking the admin settings and the public page text before publishing structured data.

Add JSON‑LD in WordPress (copyable example)

Emit Product + nested Offer JSON‑LD in the page HTML (ideally server‑rendered). In WordPress you can output it from the product template or hook it into wp_head so it appears in the initial HTML. See the WordPress theme hooks guide: WordPress hooks.

Copy and adapt this minimal example (replace placeholders with your values). Place it in the template output so it appears in the page source rather than only after client rendering:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "EXAMPLE PRODUCT NAME",
  "description": "One-line lead: compact rechargeable torch, 1200 lm.",
  "sku": "EXAMPLE-SKU-123",
  "offers": {
    "@type": "Offer",
    "price": "PRICE_VALUE",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "url": "https://yourshop.example/product/example-sku-123"
  }
}

After adding the JSON‑LD, open the page source (not just the rendered view) and confirm the snippet appears in the initial HTML and the visible text on the page matches the values in the JSON‑LD.

Short Q&A and FAQ guidance

Put short plain‑text Q&A lines near the top for the questions customers actually ask (e.g. “Does this come in X size?” → “Yes — small and medium”). Keep answers one sentence and factual. Do not use QAPage structured data unless your page meets the QAPage rules (single question with community answers). Google documents QAPage eligibility: QAPage structured data. For product pages, a visible FAQ block in plain text is usually enough for voice extraction without invoking QAPage markup.

Practical verification checklist (do these yourself)

  1. Open the product page and read the top paragraph aloud or paste it into a text‑to‑speech tool — does it state name, price, availability and one short spec clearly?
  2. View page source (or use DevTools → Elements) and find the JSON‑LD Product/Offer. Confirm price, currency and availability match the visible text.
  3. Run the page through your platform’s structured data validator or follow Google’s product snippet guidance to check for errors: see Product snippet best practices.
  4. If your JSON‑LD is generated by JavaScript, verify the rendered DOM contains the JSON‑LD and that search engines can fetch it (see Generate structured data with JavaScript).
  5. Confirm that the short specs block answers the top 2–3 buyer questions; remove private data and PII from content that may be read aloud.

Quick 15‑minute experiment (one product)

  1. Pick one product page that matters to sales.
  2. Add a single lead sentence and a “Short specs” 2–3 bullet block near the top of the page.
  3. Emit a matching Product + Offer JSON‑LD snippet in the template (use the copyable example above with your values).
  4. Run the verification checklist above and correct any mismatch between visible text and structured data.
  5. Record what you changed and check the page again after an hour; if your site uses aggressive caching, clear or bypass caches to view the fresh HTML.

Example: checking an imagined shop

Fictional example: A candle shop adds this one-line summary at the top of a product page: “Soy blend candle, 40‑hour burn, citrus scent.” They add a “Short specs” block with three bullets: “Burn time: 40 hours”, “Net weight: 220 g”, “Fragrance: citrus blend”. The theme emits matching Product + Offer JSON‑LD (price, USD, availability https://schema.org/InStock) in the initial HTML. When they read the lead aloud or paste it into a TTS tool it produces a short natural answer that includes scent, price and burn time. This is an illustrative example, not a recorded test.

Cautions and expectations

Structured data makes your pages eligible for richer treatments, but it does not guarantee a voice assistant or search feature will use your snippet; platforms choose sources algorithmically and apply their own rules. See Google’s structured data policy for limitations and requirements: Structured data policies. Avoid including private or PII in public snippets intended for voice outputs.

Finish by applying the 15‑minute experiment to one product and running the verification checklist. If you want guidance for WooCommerce‑specific JSON‑LD plugins and compatibility checks, see our related guides: Add the product structured data search engines expect (WooCommerce) and Turn repeated customer questions into useful product‑page FAQs.