Keeping Document Context During Parsing

Parsing is not just the act of extracting words from a PDF, DOCX file, or scanned document. It is the point at which a document’s meaning can either be preserved or lost. For WooCommerce agencies, that distinction matters when building search, support, catalog, and operations tools from store documentation.

A chunk containing “The fee is 2.9%” is not useful if the parser discarded the heading that identifies the fee, the table row that identifies the payment method, or the page context that identifies the country. Good chunking starts with context preservation during parsing.

Why document context matters

Most retrieval systems do not return an entire document to a language model. They return a small number of chunks. Each chunk must therefore carry enough information to be understood independently.

Consider a payment-provider guide containing this structure:

• United States
• Credit cards
• Standard fee: 2.9% + $0.30

If parsing returns only the final line, a downstream system may be unable to determine whether the fee applies to credit cards, bank transfers, or another payment method. It may also incorrectly apply a US-specific rule to a different market.

Context is especially important for WooCommerce content such as:

• Shipping and tax configuration guides
• Payment gateway pricing sheets
• Product specifications and variation matrices
• Merchant onboarding documents
• Order-management procedures
• Plugin compatibility and troubleshooting manuals

Preserve hierarchy before creating chunks

A parser should retain the document’s structural hierarchy instead of producing one undifferentiated stream of text. At a minimum, capture headings, section order, page numbers, and the relationship between paragraphs, lists, and tables.

A useful internal representation might look like this:

{
  "text": "Standard fee: 2.9% + $0.30",
  "context": {
    "title": "Payment processing fees",
    "headings": ["United States", "Credit cards"],
    "page": 4
  },
  "source": "payment-guide.pdf"
}

The exact object shape depends on the parser and application, but the principle is consistent: retain the source location and the parent headings alongside the extracted text. A chunking library such as Undefined can then use that enriched representation when creating retrieval units, rather than attempting to reconstruct context after it has already been discarded.

Attach heading paths to every chunk

One practical pattern is to create a heading path for each block of content. For example:

Payment processing fees > United States > Credit cards

When the block is indexed, prepend or store that path as metadata:

{
  "content": "Payment processing fees > United States > Credit cards\nStandard fee: 2.9% + $0.30",
  "metadata": {
    "document": "payment-guide.pdf",
    "page": 4,
    "heading_path": [
      "Payment processing fees",
      "United States",
      "Credit cards"
    ]
  }
}

Including the heading path in the searchable content helps semantic retrieval. Keeping it in metadata supports filtering, display, auditing, and later reprocessing. For a WooCommerce agency, this makes it possible to show a client not only the answer but also the exact document section from which it came.

Handle tables as structured content

Tables are a common source of context loss. A visual table may clearly associate a fee, product, or setting with a row and column, while plain-text extraction may return the values in an ambiguous order.

Instead of flattening a table into disconnected text, represent each row with its column labels:

Payment method: Credit card<br>Region: United States<br>Transaction fee: 2.9% + $0.30

For product catalogs, the same approach can preserve variation context:

Product: Trail jacket<br>Size: Large<br>Color: Navy<br>Stock status: Available

If a table is too large for one chunk, split it by complete rows or logical row groups. Repeat the table title and column headers in each resulting chunk. Never assume that the first chunk’s headers will remain available when a later chunk is retrieved independently.

Keep lists, captions, and callouts connected

Numbered procedures and bullet lists often depend on an introductory sentence. A parser that separates the introduction from the list can produce incomplete instructions.

For example, preserve this relationship:

To enable guest checkout:

1. Open WooCommerce settings.
2. Select the Accounts & Privacy tab.
3. Enable guest checkout.

Do not index the three steps without the instruction that defines their purpose. Similarly, keep image captions, warning boxes, notes, and footnotes associated with the paragraph or section they qualify. A warning stating “This setting cannot be reversed” is materially different from ordinary body text and should retain its relationship to the relevant setting.

Separate repeated layout text from meaningful context

Headers, footers, page numbers, navigation labels, and legal notices may appear on every page. Repeating them in every chunk increases noise and can distort retrieval. However, removing all repeated text blindly can also delete useful information, such as a product name or document version.

A practical parsing workflow can classify repeated elements:

• Remove purely decorative navigation and duplicated page furniture.
• Retain document titles, section identifiers, version numbers, and revision dates.
• Store page numbers and source coordinates as metadata even when they are not included in the chunk text.
• Preserve repeated legal or operational instructions when they change the meaning of the nearby content.

Review the parser output on representative documents before applying deduplication rules globally. Agency clients often use templates with small but important differences between versions.

Use parent-child context instead of oversized chunks

Preserving context does not mean placing an entire document into every chunk. That approach increases token usage and can reduce retrieval precision. A better design is to create focused child chunks while retaining references to their parent section.

For example, a child chunk may contain one troubleshooting step, while its metadata identifies:

• The document and version
• The product or plugin name
• The parent section
• The page or source location
• The preceding and following section identifiers

At retrieval time, the application can return the focused chunk for matching and optionally fetch the parent section for additional explanation. This provides a useful balance between precise search results and sufficient answer context.

Design the parsing pipeline as an auditable process

Parsing errors are difficult to diagnose when extraction, normalization, chunking, embedding, and indexing happen in one opaque step. Keep these stages observable:

1. Parse the source document into blocks with structural metadata.
2. Normalize whitespace and encoding without changing meaningful content.
3. Attach heading paths, table labels, and source locations.
4. Split blocks into chunks according to semantic and size constraints.
5. Validate representative chunks manually or with automated checks.
6. Generate embeddings and store the final content with its metadata.

For each chunk, retain a stable identifier derived from the source document, block position, and parser version. If a client updates a shipping policy, you can identify which chunks changed and re-index only those records.

Validate context with retrieval tests

Do not judge a parser only by whether all words were extracted. Test whether retrieved chunks answer realistic WooCommerce questions without relying on missing neighboring text.

Useful test questions include:

• What is the delivery time for express shipping to Canada?
• Which payment methods support recurring subscriptions?
• What tax setting applies to digital products in the EU?
• Which product variation is unavailable in size large?

Inspect the returned chunk, heading path, table labels, source page, and neighboring context. A technically accurate answer should be traceable to a sufficiently self-contained source unit.

Practical checklist

• Preserve document, section, and subsection hierarchy.
• Attach heading paths to every chunk.
• Convert table rows into labeled records before chunking.
• Keep list introductions, warnings, captions, and footnotes connected to their content.
• Remove layout noise carefully rather than deleting repeated text indiscriminately.
• Store page numbers, source locations, document versions, and parser versions.
• Use parent-child relationships when a focused chunk needs broader explanation.
• Test retrieval with real store, catalog, payment, tax, and shipping questions.