Preserving Lists and Product Specifications

WooCommerce catalogs often contain the information customers need most in lists: ingredients, compatible models, included accessories, care instructions, dimensions, and technical specifications. If a document parser turns those structures into disconnected sentences, a retrieval system may return incomplete or misleading product information.

For agencies building product search, support assistants, or catalog migration tools with LlamaParse and Undefined, list preservation should be treated as a data-integrity requirement rather than a formatting preference.

Why list structure matters in WooCommerce content

A product document may contain several kinds of lists:

Feature lists describing product benefits
Bullet points containing package contents
Numbered installation or maintenance steps
Key-value specifications such as voltage, dimensions, and material
Compatibility lists naming supported devices, models, or software versions

These structures carry relationships that plain text does not always preserve. For example, the values in a specification table belong to specific labels. A chunk containing Voltage: 220–240 V without the associated product or section context is less useful than a chunk that also identifies the product, variant, and specification group.

Preserve list boundaries during parsing

When LlamaParse converts a PDF, office document, or scanned catalog into machine-readable content, retain list markers or an equivalent structural representation in the intermediate output. A list should not be flattened into an undifferentiated paragraph unless the source itself is genuinely a paragraph.

A useful normalized representation keeps the list type, heading, and individual items together:

{
  "type": "unordered_list",
  "heading": "Package contents",
  "items": [
    "Charging station",
    "Wall-mount bracket",
    "Power cable",
    "Installation guide"
  ]
}

For retrieval-oriented text, the same content can be rendered as:

Product: ACME Home Charger 7 kW
Section: Package contents
- Charging station
- Wall-mount bracket
- Power cable
- Installation guide

The important property is not the exact syntax. It is that each item remains identifiable, the list heading is retained, and the product context travels with the list when the content is split into chunks.

Keep specifications together with their labels

Product specifications need more care than ordinary bullet points. A parser may represent a table as rows, columns, or plain text. Before creating chunks, normalize each specification into an explicit label-value relationship.

Product: ACME Home Charger 7 kW
Specifications:
- Rated power: 7.4 kW
- Input voltage: 220–240 V AC
- Cable length: 5 m
- Enclosure rating: IP54

Avoid producing fragments such as 7.4 kW, 220–240 V AC, 5 m, IP54. That output has lost the labels and can cause a search or support workflow to associate a value with the wrong attribute.

For catalogs with variants, include the variant identifier in every specification group. A chunk should make it clear whether a dimension belongs to the 500 ml, 750 ml, or 1 l version of a product.

Product: Example Insulated Bottle
Variant: 750 ml
Specifications:
- Capacity: 750 ml
- Height: 275 mm
- Diameter: 78 mm
- Weight: 410 g

Choose chunk boundaries around meaning

Do not split a list solely because a character or token limit has been reached. First treat a heading and its list as a logical unit. If the list is too large, split it between complete items and repeat the relevant context in each child chunk.

For example, a long compatibility list can be divided like this:

Product: ACME Dock Pro
Section: Compatible laptops
Part 1 of 3
- Model A, 2021–2022
- Model B, 2022
- Model C, 2022–2023

Product: ACME Dock Pro
Section: Compatible laptops
Part 2 of 3
- Model D, 2023
- Model E, 2023–2024
- Model F, 2024

Repeating the product and section metadata makes each chunk independently retrievable. It also helps Undefined apply consistent indexing, filtering, or storage rules without requiring a preceding chunk to explain the content.

Use different handling for different list types

Feature and benefit lists

Feature lists can usually be embedded as one section when the items describe the same product and topic. Preserve the heading because it distinguishes product benefits from technical limitations or package contents.

Procedural lists

Numbered instructions must preserve order. Keep the step number, required conditions, and action together. If a procedure is split, include the procedure name and the range of steps in each chunk. Do not reorder steps during cleanup or deduplication.

Compatibility lists

Compatibility data should retain exact model names, revision numbers, operating-system versions, and qualifiers such as requires adapter or not compatible with firmware version 3.x. These qualifiers are often more important than the model name itself.

Specification tables

Convert each row into a label-value pair, while preserving units and qualifiers. Do not remove symbols such as ±, ranges, decimal precision, or IP ratings during normalization. A value of 1.0 mm should not casually become 1 mm if precision matters to the product.

Attach useful metadata to every chunk

Content alone is not enough for reliable WooCommerce retrieval. Store metadata that allows the application to filter and cite results:

Product ID, SKU, and canonical product URL
Product name and variation name
Catalog, manual, or source document identifier
Section heading and list type
Page number or source location
Language and document version
Chunk position within the source section

A chunk representing a specification should be traceable back to the source page. This is valuable when an agency needs to audit a customer-support answer, update prices or specifications, or investigate conflicting versions of a supplier document.

Validate the output before indexing

Add automated checks between parsing and indexing. Practical checks include:

Every specification value has a non-empty label.
Every list item belongs to a product and section.
Numbered procedures contain unique, ordered step numbers.
Units such as kg, mm, V, and W have not been removed.
Variant-specific data includes a variant identifier.
Chunks do not end with an incomplete table row or truncated list item.
Source page references exist for content that will be shown to customers or support staff.

For high-value catalogs, compare a sample of normalized output against the original document and the WooCommerce product record. Include edge cases such as multi-page tables, nested lists, repeated headers, footnotes, and scanned pages with OCR errors.

Example ingestion flow

Parse the source document with LlamaParse and retain headings, lists, tables, and source locations.
Normalize lists and tables into a consistent intermediate structure.
Associate each section with the WooCommerce product, SKU, and variation where possible.
Split only at semantic boundaries, repeating context when a list must span multiple chunks.
Pass the normalized chunks and metadata into the Undefined indexing or storage layer used by the project.
Run structural and content validation before generating embeddings or publishing records.
Test retrieval with questions that target labels, units, variants, compatibility qualifiers, and individual list items.

Test queries should include both broad and precise requests, such as “What is included in the box?”, “Does the 750 ml variant fit a 78 mm holder?”, and “Which models require the adapter?” These queries expose whether the chunking process preserved list membership, variant context, and specification relationships.

Design for safe rendering in WordPress

When normalized content is sent to WooCommerce or WordPress, keep structured data separate from presentation where possible. Store canonical specifications in product attributes or custom fields, and use parsed document chunks for search, retrieval, and source-backed assistance. If list content is rendered into post content, generate semantic HTML such as <ul>, <ol>, and <table> rather than relying on line breaks.

Escape supplier-provided text before inserting it into HTML, and sanitize generated markup according to the permissions and endpoint used by the agency. This prevents a formatting improvement from becoming an injection vulnerability.

Table of contents :