Making Akeneo-managed catalogs agent-readable

Akeneo is very good at making sure a product record is complete: every family attribute filled in, every identifier validated, every locale translated. None of that guarantees an AI agent or shopping crawler can actually read it once the record leaves the PIM and becomes a rendered page. This guide walks through the three places that gap usually opens — attribute/identifier completeness in Akeneo, the export/mapping layer into your storefront, and the JSON-LD you emit on the page — and how to close each one.

Why "complete in Akeneo" isn't "readable on the page"

Akeneo's completeness score is calculated per product, per family, per channel, based on which required attribute_requirements have a value — it says nothing about what happens to that value downstream (Akeneo, Understand product completeness). A product can sit at 100% completeness in Akeneo and still land on the storefront as a hero image, a price, and three bullet points, because the connector export job only mapped a handful of attributes, or the PDP template only renders what's in the visual layout. Agents (and Google's crawlers) read the rendered DOM and any embedded structured data, not your PIM. So "agent-readable" is really three jobs in sequence: get the data structurally complete in Akeneo, get all of it onto the storefront, and describe it in a machine-parsable format on the page.

Step 1: Make identifiers and attributes structurally complete in Akeneo

Two Akeneo mechanics matter most here:

Identifiers. Akeneo supports up to 20 attributes of type pim_catalog_identifier, one of which is designated the main identifier (SKU by default) (Akeneo, Manage your product identifiers). In current Akeneo versions SKU itself is optional and can even be removed from a family, since every product also carries an immutable system UUID — don't assume it's a guaranteed non-empty field. Use additional identifier attributes, or a validated text attribute, to hold GTIN/EAN/UPC and MPN as first-class fields rather than free text buried in a description. Akeneo's identifier and text attribute types support a built-in validation rule that checks an 8/12/13/14-digit GTIN against its checksum, which is the cheapest way to catch a mistyped barcode before it ever reaches the storefront (Akeneo, Manage your attributes).

Family requirements. Completeness is driven by each family's attribute_requirements object, which lists which attributes are required per channel (ecommerce, mobile, print, etc.). If GTIN, MPN, brand, and the core spec attributes aren't marked required for the channel that feeds your storefront, a product can reach 100% without them (Akeneo API, Concepts & resources). Audit your families: every family that maps to a sellable product type should require identifier and brand attributes for the storefront channel, not just for print or internal catalog channels.

{
  "code": "power_tools",
  "attribute_requirements": {
    "ecommerce": ["sku", "gtin", "mpn", "brand", "name", "short_description", "voltage"]
  }
}

Step 2: Carry the full attribute set through the connector, not just the "display" fields

Whether you use the Akeneo Connector for Adobe Commerce/Magento, the equivalent apps for Shopware/BigCommerce/Shopify, or a custom job against the REST API, the export step is where completeness silently narrows. The Adobe Commerce connector, for example, exports every attribute by default and handles native type mapping for attributes with matching codes automatically — but once a team turns on attribute filtering to trim the export, it's easy to forget to add a newly-required attribute later, and custom attribute types still need explicit type mapping (Akeneo, Adobe Commerce Connector — Mapping Products; Akeneo, Filtering and mapping attributes). Two rules help: if filtering is on, audit it against the whole required-attribute set for the channel, not the subset your current PDP template happens to render — templates change more often than integrations get revisited. And if you're integrating directly against the API, prefer the Product (UUID) endpoint over the identifier endpoint for anything that persists a reference, since UUIDs don't change if a SKU is later renamed (Akeneo API, REST API reference).

Step 3: Render the attributes as real HTML, not just visual layout

A rendered PDP is what agents and crawlers actually see. Two things routinely break this even when the data made it to the storefront:

• Client-side-only rendering. If specs, identifiers, or descriptions are injected after page load via JavaScript with no server-rendered fallback, some crawlers and agent fetchers never see them. Compare curl output to what appears in DevTools' rendered DOM (see validation section below).
• Specs trapped in images or PDFs. Spec sheets and comparison tables rendered as images are invisible to text-based agents. If Akeneo holds the data as structured attributes, render it as an HTML table or definition list, and keep the PDF as a supplementary download, not the only copy.

A minimal, agent-friendly spec block looks like plain markup:

<dl class="specs">
  <div><dt>MPN</dt><dd>PX-4410</dd></div>
  <div><dt>GTIN</dt><dd>00812345678901</dd></div>
  <div><dt>Voltage</dt><dd>18V</dd></div>
  <div><dt>Weight</dt><dd>2.3 kg</dd></div>
</dl>

Step 4: Emit Product JSON-LD from the same enriched attributes

Structured data is the layer that turns "the page happens to mention 18V" into an unambiguous, typed fact. Google's guidance is to provide as much of the schema.org Product vocabulary as you have data for, since different surfaces (product snippets, merchant listings, shopping features) draw on different subsets, and Merchant Center feed data can supplement — but not replace — page-level structured data (Google, Intro to Product structured data). For a manufacturer/distributor PDP fed by Akeneo, map attributes straight through:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "18V Cordless Impact Driver",
  "sku": "PX-4410",
  "gtin13": "0812345678901",
  "mpn": "PX-4410",
  "brand": {
    "@type": "Brand",
    "name": "Praxis Tools"
  },
  "description": "18V brushless impact driver, 2.3 kg, 4-speed torque control.",
  "image": [
    "https://example.com/images/px-4410-1.jpg",
    "https://example.com/images/px-4410-2.jpg"
  ],
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Voltage", "value": "18V" },
    { "@type": "PropertyValue", "name": "Weight", "value": "2.3 kg" }
  ],
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/px-4410",
    "priceCurrency": "USD",
    "price": "149.00",
    "availability": "https://schema.org/InStock"
  }
}

Field notes: name is always required. Product snippet eligibility needs at least one of offers, review, or aggregateRating (Google, How to add product snippet structured data); merchant listing eligibility needs image and an Offer specifically, not an AggregateOffer (Google, How to add merchant listing structured data). description, sku, brand, mpn, and the GTIN properties are recommended on the page markup itself — but Google's Merchant Center feed rules are stricter: a product with a GTIN must also carry brand, and a product without one must carry both brand and mpn (Google Merchant Center, About unique product identifiers). Mirroring that pairing in your JSON-LD, not just your feed, keeps the two sources consistent. Use additionalProperty/PropertyValue pairs for spec attributes without a dedicated schema.org property — voltage, dimensions, materials — so an agent can answer "what's the torque rating" without guessing from prose. Multi-variant catalogs (color/size variants in one Akeneo family) should use ProductGroup with variesBy and hasVariant-nested Product entries, Google's documented preferred structure, rather than one Product node per variant page competing for the same query (Google, Product variant structured data).

How to validate

• View-source vs. rendered DOM: curl -s https://example.com/products/px-4410 | grep -A2 '"@type":"Product"' shows what non-JS fetchers see; compare against Chrome DevTools' Elements panel (the live DOM) to confirm client-side rendering isn't hiding attributes or JSON-LD from simple crawlers.
• JSON-LD syntax: run the page through Google's Rich Results Test and the Schema.org validator to catch malformed JSON or missing required fields.
• Data parity: spot-check a handful of PDPs against the Akeneo product record via the Product (Identifier) REST API endpoint to confirm the identifier, GTIN, and key attributes on the page match the PIM source, not a stale export.
• Family-to-page audit: for one representative product per family, list required attribute_requirements next to the rendered JSON-LD additionalProperty array; gaps here usually point back to an export job's attribute selection, not the PIM data itself.

Verified as of July 2026 against current Akeneo PIM/API documentation and Google Search Central structured data guidance; menu paths and connector options vary by Akeneo edition (Community/Growth/Enterprise) and connector version, so confirm field names in your instance before shipping.

This whole pipeline assumes the Akeneo side is actually filled in — complete attributes, valid identifiers, real specs instead of placeholder text. That's the part Anglera is built for: it enriches product data continuously (attributes, specs, use-cases, identifiers) directly against your PIM, so the mapping and JSON-LD work above has something rich to render rather than a half-empty family template.