GEO-044·Issue 04·Technical Foundation·44 / 132
A GEO Component Library for Product Page Templates
A page-by-page GEO fix does not survive two thousand SKUs. Six template components, the field order that makes them extractable, and where reuse breaks.
Issue focusAnswer Units: Writing Category and Product Pages for GEO
Consider a composite example. A DTC espresso-machine brand reprices in the US and Germany the same day. Ops asks a chat assistant which semi-automatic machine under $500 steams milk well; the answer puts them fourth, with specs “on the product page.” The engineer opens the source: nine bars of pump pressure and a 58 mm portafilter are there — inside a rich-text block that last year’s template refresh folded into “Learn more.” The German page still carries a plug note copied from the English site.
Product-page GEO does not scale page by page. It scales when the answer lives in template components with named fields, a fixed order, and disclosure that keeps content in the DOM — one fix reaches every SKU, one mistake does too.
A fact without a slot is only a sentence
Extractors cut pages into blocks; block boundaries come from markup. Markup follows the component library, the one place that sets visual and source edges together. A spec in a table row is a key–value pair in source; the same spec in rich text is one clause in three hundred words.
That is why single-page rewrites stall around two hundred SKUs: one operator can fix a page; nobody fixes two thousand. One template field speaks for all of them; a hardcoded unit is wrong everywhere.
The test: CSS off, JavaScript off, second locale. A fact still appearing as a pair has a slot; otherwise it is copy.
Six components, each answering one question
| Component | Question it answers | Required fields and source | Position and disclosure |
|---|---|---|---|
| Answer block | What is it, for whom, why this one | Category, use case, 3–5 hard specs, one differentiator; PIM plus one line | Above the fold; never collapsed |
| Spec table | Can it meet my conditions | Key–value, unit, test condition; PIM and lab reports | After the answer; open |
| Comparison | How it differs from the tier above | Same-method fields, competitor models named | After specs; collapsible |
| Reviews | How it performs for others | Rating, sample size, use-case tags, negative summary | Mid page; open |
| Shipping and returns | When it arrives, can it go back | Market lead time, cost, return window, conditions | Near the price; collapsible |
| Compatibility and limits | When it does not apply | Exclusions, compatible models, certifications | Last; never collapsed |
Sort and fold by the buyer’s judgment — works, works well, worth trusting — but never let content disappear. Collapsing is fine; content fetched on click is invisible. Use details/summary, or render then hide with CSS. Put that in the component spec, not the design notes.
Same slots in the second market, different evidence
A second market makes one fact obvious: fields travel, evidence does not.
Voltage and plug type, certification scope — CE, FCC, and PSE cover different ground — warranty, return window, and units are local facts, not translation. Machine-translating a 30-day return window into German produces a promise the warehouse will not honor, and a wrong promise is more citable than a missing one. Store value and unit separately, compose at render; keep model numbers and certificate IDs out of translation. Each locale needs its own URL and hreflang, or the model cannot tell which price belongs where.
Five steps, and the first produces no design file
| Step | Do | Owner | Passes when |
|---|---|---|---|
| 1 Inventory facts | List buyer questions on 20 SKU pages; mark each fact’s field | Content and category ops | Every fact points to a component, or gets its own row |
| 2 Define slots | Fields, types, required flags, sources for the six components | Frontend and master data | Every field has an owner; gaps render “pending” |
| 3 Order and disclose | Sort by decision order; keep collapsed content in the DOM | Design and frontend | CSS off, text still paired |
| 4 Run regression | Fixed 20 questions against 20 SKUs, answers against page values | Growth and engineering | A wrong value traces to a component |
| 5 Govern | Component changes go through review; missing fields enter a weekly report | Product | No new free-text spec area in 90 days |
Step 1 gets skipped because it produces no mockup; teams that start from the design file build a visual system, not a fact system. Step 5 decides how long the library lives: without a named owner, a second rich-text block returns within six months.
Start where facts are thinnest and questions loudest, not by revenue — the page priority matrix ranks them; HTML semantics and paragraph boundaries covers why a fact stays in one block.
Example: a coffee-machine template cut to twelve fields
Example — a hypothetical home coffee-equipment brand, two markets, about 60 SKUs; no real brand, no figures. Its template had forty-plus visual components, with answer facts scattered across rich text, a spec image, and a FAQ.
The rebuild fixed six components and twelve fields. The answer block assembles from PIM category, pump pressure, basket size, and use case, with ops adding one differentiator. The spec table stores value and unit separately, with the test condition on the same row. Reviews gain use-case tags and a negative summary; shipping and returns pull from market configuration; compatibility lists excluded models and plugs.
Acceptance is three checks, none a ranking: the source with JavaScript off shows all six components; the question set returns no value contradicting the page; the German answer cites the German URL.
Where this breaks
Few pages. Under fifty product pages, editing each page beats a library; governance costs more than it returns.
Marketplace-only sales. Amazon and Shopee templates are not yours; fix listing attributes and feed.
Unstable master data. The library replicates “pending” and a wrong unit across the catalog. Unify taxonomy and units.
Configurable products. Price, dimensions, and accessories move with configuration; a single-value field states something false. Solve option ranges first.
The library amplifies whatever goes in: answer units make the catalog quotable; marketing copy makes it equally vague. Success shows less in one cited page than in the share of SKUs AI recognizes — the entity coverage metric measures it; the technical foundation line holds the rest.
This month, take your twenty best-selling SKUs, list every buyer-needed fact on one twelve-row sheet, and mark which component and field holds each row. Rows you cannot place are the next component.