Scenario: product data for a food e-shop

An application example — not based on a specific client.

QUICK ANSWER

A food e-shop organises its products properly when each item is built from one shared set of verified data: what the product is, which characteristics it has, which mandatory food information must be shown, which identifiers recognise it, its price and availability, and how the same information is represented on the product page, in Product/Offer structured data and in catalogue feeds. AI can help organise this data; it should not invent what is missing.

An e-shop can work perfectly well for cart, payments and shipping while still having weak product information.

A customer may see a title, an image, a weight and a price, but still struggle to understand:

exactly what they are buying,
which ingredients it contains,
whether there are allergens they need to know about,
what its verified origin is,
which pack size or variant they are viewing,
whether the product is available,
which identifier belongs to the product,
whether the page agrees with the information machines are reading.

The same problem affects Google, merchant systems and AI systems.

If the underlying product data is incomplete, inconsistent or wrong, a longer description will not solve the problem.

The foundation needs to be fixed first.

The starting point

Current state:

The e-shop has an active catalogue and works correctly for cart, payments and shipping.

Product information has been collected from several sources: suppliers, spreadsheets, ERP systems, older descriptions or manual entries.

Some products have rich data while others contain little more than a title, weight, price and short description.

Identifiers, attributes, food information, price, availability and structured data do not always follow the same model across the catalogue.

The problem is not simply “missing copy”.

The same product may be described differently across different systems.

For example:

the page may show a different quantity from the feed,
a GTIN may be missing even though it exists on the packaging,
availability may have changed while the structured data still shows the old status,
allergen information may exist on the label but not on the online page,
different pack sizes may not be clearly distinguished,
a description may include characteristics that were never verified.

This is a product-data problem.

What isn’t working today

There is no shared data model across the catalogue. Different categories or suppliers may provide different fields, naming conventions and levels of detail.

Important food information may be missing from the online product page. For prepacked foods, mandatory information is not simply optional extra content; it generally needs to be available before the purchase is completed under the applicable framework.

Identifiers and variants are not always organised correctly. GTIN/EAN, brand, MPN where applicable, internal SKU and different pack sizes can be mixed up or missing.

The page, structured data and catalogue feeds may disagree. Price, availability, quantity and identifiers should describe the same product and the same offer.

AI may be used in the wrong way. If it is simply asked to “fill in the gaps”, it can produce unverified information about origin, use, ingredients or other product characteristics.

The right approach starts with one principle:

We do not fill every possible field. We fill the right fields with real data.

What we’d do

The work is organised around the product-data model and the consistency with which it is used across every relevant system.

1. Define a shared product-data model.

We identify which fields are needed for each major product category.

Depending on the product, this may include:

product name,
brand,
GTIN/EAN where available,
MPN where applicable,
internal SKU,
net quantity or weight,
ingredients,
allergens,
nutrition information,
origin where required or verified,
storage or usage conditions,
images,
price,
currency,
availability,
category-specific attributes,
relationships between variants or pack sizes.

Not every product needs the same fields.

The data model should match the real category without manufacturing information simply to populate a database.

2. Separate verified data from gaps.

For each field, we need to know the source.

That source may be:

the official packaging or label,
the producer or supplier,
an ERP or PIM,
an official product sheet,
another internally verified source.

If a fact cannot be verified, it should not become a product claim simply because it seems plausible.

This is especially important for:

ingredients,
allergens,
nutrition data,
origin,
GTIN,
product claims,
flavour characteristics presented as factual attributes.

3. Organise mandatory food information.

For prepacked foods sold online in the EU, mandatory food information generally needs to be available before the purchase is completed, subject to the specific exception for the date of minimum durability or use-by date.

The exact implementation depends on the product and the regulatory framework in force.

For the e-shop, the practical requirement is a process that prevents required information from being lost as a product moves from supplier or ERP data into the page the customer sees.

4. Organise identifiers and variants.

A commercial product should be represented with the real identifiers assigned to it.

Where a GTIN/EAN exists, we use the actual GTIN.

We do not use an internal SKU as a GTIN and we do not create identifiers just to fill an empty field.

Where a product has genuine variants — for example different pack sizes or quantities — each version should carry the correct information for that specific commercial option.

5. Connect the product page to Product/Offer structured data.

The product page should be the clear human-readable presentation of the same information the systems use.

Depending on the case, Product and Offer structured data can represent:

name,
image,
brand,
SKU,
GTIN or another appropriate identifier,
price,
currency,
availability,
offer information and other supported facts.

Schema should not introduce information that does not belong to the actual product or offer.

When price or availability changes, the entire chain needs to stay in sync.

6. Keep page data, structured data and feeds consistent.

The same product may appear in:

the product page,
category pages,
structured data,
merchant or catalogue feeds,
ERP/PIM systems,
internal search,
other applications that consume product data.

The goal is to avoid multiple versions of the truth.

We define which source is authoritative for each core field and how changes flow into the other systems.

7. Use AI for scale, not for guessing.

In a large catalogue, AI can be highly useful.

It can:

normalise titles and units,
classify products,
identify missing fields,
turn verified attributes into natural-language descriptions,
generate FAQs from real product facts,
suggest internal links,
flag inconsistencies across different data sources.

It should not fill factual gaps without a source.

Automation adds value when it increases speed without reducing reliability.

What could change in 180 days

Higher coverage of core product fields. More products can have the correct identifiers, attributes and food information for their category.

Fewer inconsistencies across systems. Product pages, structured data and catalogue feeds can rely on the same authoritative data.

Cleaner variant management. Different pack sizes or commercial versions can be represented correctly without improvised duplicates or incorrect identifiers.

Fewer structured-data issues. Errors and warnings can be identified systematically and fixed at source rather than patched page by page.

A stronger foundation for Search and AI. Machines receive more consistent and specific information about which product is being sold, which offer applies and which characteristics can genuinely be verified.

Measurable catalogue quality. Field coverage, data consistency, Search Console visibility, internal search behaviour and key purchase actions can be tracked against common baselines.

The goal of the 180-day period is not to populate as many fields as possible.

The goal is to create a product-data system that can be maintained as the catalogue changes:

prices,
availability,
pack sizes,
suppliers,
products,
regulatory information,
channels that consume the data.

A sound product-data layer does not end on the product page.

It becomes the shared foundation for the e-shop, structured data, catalogue feeds, internal search and any system that needs to understand exactly what is being sold.

Why this needs ongoing work

Product data changes. Prices, availability, new variants, new packaging and supplier updates all need continuous synchronisation.

The 180-day horizon allows the data model to be defined, field coverage and quality to be audited, identifiers and variants to be organised, and the most important catalogue categories to be improved progressively.

If the existing e-shop or ERP cannot support the required fields, variant relationships or reliable synchronisation, a separate technical intervention or connector may be needed. This example focuses on organising the information rather than any specific platform.

Three takeaways

Completeness does not mean populating every possible field. It means the right fields for each product contain real, verified data.
Structured data and feeds cannot repair bad source data. Reliable product information comes first; consistent distribution comes second.
AI is a scaling tool, not the source of truth. It can organise and transform verified information, but it should not invent critical product facts.

Product information should be based on real, verified data and checked against the regulatory framework in force where required. The interventions described do not guarantee a specific ranking, appearance or mention by search engines or AI systems, nor a specific increase in conversions or sales.

FREQUENTLY ASKED

Frequently asked questions

The page should clearly explain what the product is and show the real information a customer needs before buying. Depending on the product, this may include the food name, quantity, ingredients, allergens, nutrition information, origin where required or verified, storage conditions, price, availability, brand and appropriate product identifiers.

For prepacked foods sold online in the EU, mandatory food information generally needs to be available before the purchase is completed, except for the date of minimum durability or use-by date, which must be available at delivery. The exact information required depends on the product and the regulatory framework in force.

Correct identifiers help systems distinguish the exact commercial product being sold and match it with other product records. Where an official GTIN exists, the real GTIN should be used rather than an internal SKU or a number created simply to fill the field.

Product structured data describes real product information in a machine-readable format and, where an offer exists, the Offer associated with it. It can include details such as name, image, identifiers, price, currency and availability, provided they match the actual product and page.

Yes. Price, currency, availability and other core details should remain consistent across the page, structured data and any catalogue or merchant feeds being used. Differences can create outdated or conflicting information for customers and machines.

Genuine variants should be modelled as distinct commercial options with the correct identifiers, quantities, prices and availability for each version. We do not simply duplicate the same information across multiple pages when the variants can be represented more clearly in the product model.

AI can help organise, normalise and generate text from product data that already exists and has been verified. It should not invent ingredients, allergens, origin, nutrition data, GTINs, flavour characteristics or other facts that have not been confirmed by a reliable source.

Product-field coverage, structured-data errors and warnings, price and availability consistency, product-page visibility in Search Console, internal search behaviour and key purchase actions can all be tracked. The data shows where product information improved and where gaps remain, without proving on its own that a specific change caused a sale.

How a food e-shop organises product data for Search and AI