Documents Have Structure: Use It

Why flat text creates weak search results

WooCommerce projects depend on documents whose meaning is tied to structure. A return policy, product catalog, installation guide, and shipping matrix do not communicate information in the same way. If each document is converted into one uninterrupted stream of text and split every 500 words, important relationships are lost.

A chunk might contain a heading without the section it describes, a table row without its column labels, or a product specification separated from the product name. The resulting search result may contain the right words but still be unusable to an agency team, store manager, or support specialist.

Chunk by document boundaries

Start with the structure already present in the source document. Useful boundaries include:

• Document title and section headings
• Paragraph groups that explain one policy or procedure
• Bullet and numbered lists
• Tables, including their headers and row relationships
• Product records and specification blocks
• Callouts, notes, warnings, and appendices

A shipping policy, for example, should not be split into arbitrary pieces that separate the delivery region from the delivery time. A better chunk contains the relevant heading, the qualifying paragraph, and the associated list or table.

Preserve context in every chunk

Each chunk should be understandable when retrieved on its own. Add the document title and meaningful heading path as metadata or as a short context prefix.

Document: Store Shipping Policy
Section: International Orders > Duties and Taxes
Content: Customers are responsible for import duties, customs fees, and local taxes...

This approach helps distinguish similarly worded sections such as domestic shipping, international shipping, and wholesale fulfillment. It also gives editors and support staff enough context to verify an answer before using it.

Handle WooCommerce tables as data, not prose

Tables often contain the most operationally important information in a commerce implementation. Shipping zones, dimensional rates, warranty periods, compatibility matrices, and product attributes should retain their headers when chunked.

Instead of storing a row such as Large | 5-10 kg | $14.95, store it with the table context:

Table: Domestic Shipping Rates
Columns: Package size | Weight range | Rate
Row: Large | 5-10 kg | $14.95

For complex tables, create one chunk per logical row or group of rows and repeat the table title and column names. Do not split a row across chunks. If a table spans multiple pages, verify that repeated headers are retained and that page breaks have not changed the row order.

Keep product records together

For product documentation, the product name, SKU, variation details, attributes, and relevant descriptions should remain connected. Separating the SKU from the compatibility information can produce incorrect matches, especially when several products share similar names.

A practical product chunk might include:

• Product name and SKU
• Parent product or category
• Variation attributes such as size, color, or voltage
• Compatibility and exclusion statements
• Dimensions, weight, and care instructions
• Short excerpts from the product description

Long marketing copy can be split into additional semantic chunks, but every such chunk should retain the product identifier and variation context.

Use different rules for different documents

There is no single ideal chunk size for every WooCommerce knowledge source. Apply rules based on the document type:

Use overlap only where a concept genuinely continues across a boundary. Excessive overlap increases storage and retrieval noise without repairing poor boundaries.

Attach metadata that supports filtering

Structural context should be available as metadata, not only embedded in the text. For a WooCommerce implementation, useful fields include site_id, storefront, document_type, category, sku, locale, customer_region, and effective_date.

Metadata filters can prevent a retrieval from mixing policies between client stores or returning an expired promotion as current guidance. Keep dates in a consistent format and define how superseded documents are marked or removed.

Build and test a structure-aware pipeline

1. Parse the source while retaining headings, lists, tables, page references, and document order.
2. Normalize formatting without removing labels that provide meaning.
3. Identify document-specific boundaries and create chunks from those units.
4. Add parent context such as the document title, heading path, and product or site identifier.
5. Store searchable text separately from structured metadata where appropriate.
6. Test retrieval with real agency questions, including questions about exceptions and variations.

For example, test queries such as “Can the 240V model be shipped to Canada?” or “What is the return window for clearance footwear?” The expected result should contain the relevant product or policy section, its conditions, and any exception language—not merely a matching phrase from another section.

Review the chunks before publishing

Inspect a sample from every document type. Look specifically for orphaned headings, detached table headers, broken list numbering, duplicated footer text, missing SKU values, and chunks that combine content from different products or stores.

When a policy changes, reprocess the affected document and confirm that old chunks are no longer eligible for retrieval. Store the source location and revision date with each chunk so an agency can trace a result back to the page, section, or table row that produced it.