cheng zhang

Posted on Jul 31

How to Generate E-commerce Product Pages in Bulk with AI

#ai #beginners #productivity #tutorial

Article Summary

Bulk-generating product pages with AI looks simple: send product attributes to a model and ask it to write persuasive copy. In practice, this approach often creates invented claims, mismatched specifications, repetitive content, prohibited wording, and formats that cannot be published across different sales channels. A production-ready system is not a loop that repeats one prompt. It is a content pipeline that combines product-data cleaning, factual constraints, structured generation, rule-based validation, human review, and multi-channel publishing. This guide provides a practical data model, prompt template, JSON output schema, Python batch-processing example, and quality-control checklist.

Why Direct AI Product-Copy Generation Often Fails

A common workflow is to copy a product name and a few attributes from a spreadsheet, then ask:

Write an attractive product detail page.

The model may produce fluent text, but fluent text is not necessarily accurate product content. Five problems appear repeatedly.

The source data is incomplete

Many product spreadsheets contain only:

SKU;
product name;
price;
one or two specifications.

A useful product page may also require target users, use cases, materials, dimensions, packaging, warnings, warranty terms, and verified benefits. When these facts are absent, a language model may fill the gaps with plausible but unsupported details.

Facts and marketing claims are mixed together

“Made with 304 stainless steel” is a factual attribute. “Designed for everyday durability” is a restrained interpretation. “The safest and most durable cup on the market” is an unverified claim.

If the system does not distinguish facts from acceptable marketing language, the model may present assumptions as product truth.

Every channel has different requirements

The same product may need:

an SEO title and meta description for a direct-to-consumer website;
marketplace-style feature sections;
Amazon bullet points;
a short video script;
social-media captions;
ad copy with strict character limits.

One generic paragraph creates more editing work downstream.

Batch processing amplifies errors and repetition

A single generated page may look good. A batch of 5,000 SKUs can reveal systemic failures:

repetitive title patterns;
clichés such as “crafted with care” on every page;
altered units and measurements;
mismatched model numbers and colors;
dirty data contaminating many outputs;
missing records after API timeouts;
duplicates created by retries.

There is no publishing gate

If model output is published immediately, the company is delegating content risk to the model. The model should generate a candidate. Rules, code, and human reviewers should decide whether that candidate is publishable.

The Right Architecture: A Six-Layer Content Pipeline

A production workflow can be divided into six layers:

Product master data
↓
Cleaning and normalization
↓
Fact locking and content policy
↓
Structured AI generation
↓
Validation and risk scoring
↓
Human review / automated publishing

Each layer has a different responsibility.

Layer 1: Product master data

Product facts should come from a PIM, ERP, product database, or approved spreadsheet—not from model inference.

Layer 2: Data cleaning

Normalize units, null values, enumerations, color names, dimensions, and brand terminology.

Layer 3: Fact locking

Define which fields may be copied, which may be paraphrased, and which claims are prohibited.

Layer 4: Structured generation

Require JSON rather than an uncontrolled block of prose.

Layer 5: Validation

Use code to inspect length, prohibited terms, specification consistency, duplication, and completeness.

Layer 6: Review and publishing

Allow low-risk content to pass automatically. Route high-risk categories and low-confidence outputs to a review queue.

Design the Product Data Table First

A useful source table should include at least the following fields:

FieldPurposeExamplesku_idUnique product identifierCUP-500-BLKproduct_nameCanonical product name500 ml vacuum insulated bottlebrandBrandExamplecategoryProduct categoryDrinkware / insulated bottlematerialMaterials304 stainless steel, food-contact PPsizeDimensions7.2 × 22.5 cmcapacityCapacity500 mlcolorColorObsidian blackpackage_contentsPackage contentsBottle ×1, manual ×1verified_featuresApproved featuresDouble-wall vacuum design, non-slip basetarget_usersIntended usersCommuters, studentsusage_scenariosUse casesOffice, commuting, short tripsrestrictionsProhibited claimsNo medical claims; no “permanent insulation”warrantyWarranty informationSeven-day returns; one-year quality warrantykeywordsSEO keywordsinsulated bottle, 500 ml bottle, commuter bottlechannelPublishing channelDTC site, Amazon, marketplace

Add three operational fields as well.

source_of_truth

Record where each fact came from: ERP, test report, supplier confirmation, or manual entry. This supports later audits and updates.

missing_fields

Identify missing information before generation. A SKU with critical missing fields should not enter an auto-publishing flow.

content_version

Increment the version whenever content is regenerated so that new and old copy cannot be confused.

Define Three Classes: Allowed, Inferable, and Prohibited

Before calling a model, classify information into three categories.

Allowed facts

These fields have a verified source:

material;
specifications;
dimensions;
capacity;
package contents;
model number;
color;
validated functions;
warranty terms.

Fact-based expressions

These can be derived from verified facts without exaggeration:

“Double-wall vacuum design” may become “helps reduce heat transfer.”
“Non-slip base” may become “designed to sit more securely.”
“500 ml capacity” may become “sized for everyday commuting.”

The model is improving language, not inventing product capabilities.

Prohibited content

This includes:

certifications that were not provided;
medical or therapeutic benefits;
“best,” “number one,” “absolutely,” or “100% guaranteed” without evidence;
unverified ingredients or materials;
nonexistent gifts;
fabricated sales figures or reviews;
invented warranty terms;
claims that violate platform or regulatory policies.

These rules should be fixed in the system prompt.

Require Structured JSON Output

Do not ask for “a product page.” Define an output contract.

{
"sku_id": "CUP-500-BLK",
"seo_title": "500 ml Vacuum Insulated Bottle | Obsidian Black",
"short_title": "500 ml Black Insulated Bottle",
"summary": "A lightweight insulated bottle designed for office and commuting use.",
"selling_points": [
{
"title": "Double-wall vacuum design",
"description": "Helps reduce heat transfer for everyday drinking needs."
}
],
"specifications": [
{"name": "Capacity", "value": "500 ml"}
],
"usage_scenarios": ["Office", "Commuting", "Short trips"],
"care_instructions": ["Wash before first use"],
"meta_description": "A 500 ml obsidian-black vacuum bottle with a 304 stainless-steel interior for office, commuting, and short trips.",
"risk_flags": [],
"missing_information": []
}

Structured output offers four major advantages:

It can be written directly to a CMS or product database.
Every field can be validated independently.
Channel-specific templates can reuse the same source.
Failures are easier to diagnose.

A Reusable Prompt Template

The following structure is suitable for batch generation.

You are an e-commerce product content editor. Generate content only from
the supplied product facts. Do not add materials, functions,
certifications, gifts, sales figures, reviews, warranty promises, or
health claims that are absent from the input.

Objectives:
1. Produce clear, accurate, and restrained product content.
2. Preserve the exact model number, dimensions, capacity, material,
quantity, and unit precision.
3. Do not use unverifiable claims such as "best," "number one,"
"absolute," "permanent," or "100%."
4. If critical information is missing, add it to missing_information.
Do not guess.
5. Return valid JSON only. Do not wrap it in a Markdown code block.

Content requirements:
- seo_title: no more than 60 characters;
- short_title: no more than 30 characters;
- summary: 80 to 160 characters;
- selling_points: 3 to 5 items, each traceable to verified_features;
- specifications: preserve all input values;
- meta_description: no more than 160 characters;
- risk_flags: list possible data or compliance risks.

Product input:
{{PRODUCT_JSON}}

Output JSON Schema:
{{OUTPUT_SCHEMA}}

For consistent batch jobs, keep the system prompt stable and place the product record in the user message. This improves cache efficiency, version control, and consistency.

Python Batch-Processing Example

The following example uses an OpenAI-compatible API format. Environment variables can be changed to point to different providers.

import csv
import json
import os
import time
from pathlib import Path

import requests

API_BASE = os.environ["LLM_API_BASE"].rstrip("/")
API_KEY = os.environ["LLM_API_KEY"]
MODEL = os.environ.get("LLM_MODEL", "your-model")
INPUT_FILE = Path("products.csv")
OUTPUT_FILE = Path("generated-products.jsonl")
ERROR_FILE = Path("generation-errors.jsonl")

SYSTEM_PROMPT = """
You are an e-commerce product content editor.
Use only supplied facts. Do not invent materials, functions,
certifications, gifts, sales figures, reviews, warranty promises,
or health claims. Return valid JSON only.
"""

def call_model(product: dict, retries: int = 3) -> dict:
payload = {
"model": MODEL,
"messages": [
{"role": "system", "content": SYSTEM_PROMPT},
{
"role": "user",
"content": json.dumps(product, ensure_ascii=False)
}
],
"response_format": {"type": "json_object"},
"temperature": 0.2
}

for attempt in range(retries):
try:
response = requests.post(
f"{API_BASE}/chat/completions",
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
},
json=payload,
timeout=90
)
response.raise_for_status()
content = response.json()["choices"][0]["message"]["content"]
result = json.loads(content)
result["sku_id"] = product["sku_id"]
return result
except (requests.RequestException, KeyError, json.JSONDecodeError) as exc:
if attempt == retries - 1:
raise RuntimeError(f"Generation failed: {exc}") from exc
time.sleep(2 ** attempt)

raise RuntimeError("Unexpected retry state")

def append_jsonl(path: Path, data: dict) -> None:
with path.open("a", encoding="utf-8") as file:
file.write(json.dumps(data, ensure_ascii=False) + "\n")

def main() -> None:
processed = set()
if OUTPUT_FILE.exists():
with OUTPUT_FILE.open("r", encoding="utf-8") as file:
for line in file:
if line.strip():
processed.add(json.loads(line)["sku_id"])

with INPUT_FILE.open("r", encoding="utf-8-sig", newline="") as file:
reader = csv.DictReader(file)
for product in reader:
sku_id = product.get("sku_id", "").strip()
if not sku_id or sku_id in processed:
continue

try:
result = call_model(product)
append_jsonl(OUTPUT_FILE, result)
print(f"OK: {sku_id}")
except Exception as exc:
append_jsonl(
ERROR_FILE,
{"sku_id": sku_id, "error": str(exc)}
)
print(f"FAILED: {sku_id}")

if __name__ == "__main__":
main()

This example includes three important production patterns:

Resumability: completed SKUs are not generated again.
Exponential backoff: temporary network failures do not immediately terminate the job.
Separate error logging: failed records can be reprocessed independently.

A production system should also add rate limiting, concurrency control, token logging, cost tracking, and idempotency keys.

Eight Validation Layers After Generation

JSON validity

Confirm that required fields exist, data types are correct, and arrays were not returned as strings.

Specification consistency

Dimensions, capacity, materials, model numbers, and quantities must match the product master data exactly. These values should be checked by code rather than by human reading alone.

Prohibited-term detection

Maintain separate dictionaries by country, industry, and marketplace. Food, supplements, cosmetics, medical devices, and children's products require different policies.

Hallucination detection

Extract materials, certifications, functions, and warranty statements from the output and compare them with the source record. Any fact that cannot be traced should enter review.

Similarity detection

Measure similarity across titles and selling points. If hundreds of pages differ only by color or model number, search engines and customers may see them as low-quality content.

Channel formatting

Set separate limits for titles, descriptions, bullet points, and keywords by channel. Do not apply one template to every marketplace.

Brand voice

Define prohibited expressions, preferred terminology, tone strength, and punctuation rules. The model should vary content within a brand system rather than improvise freely.

Human sampling

Use risk-based review:

ordinary low-risk categories: sample 5% to 10%;
high-value products: increase review coverage;
food, health, beauty, and children's products: require human approval;
new models, prompts, or data sources: review at least one full batch.

How to Reduce the Cost of 1,000 SKUs

The best optimization is not always switching to the cheapest model. It is reducing unnecessary tokens and rework.

Keep the system prompt stable

Use one shared policy for all SKUs. Providers that support prompt caching can charge much less for repeated input.

Use a model cascade

A practical three-stage flow is:

Low-cost model: cleaning, classification, missing-field detection
↓
Primary model: titles, benefits, and descriptions
↓
Low-cost model or code: compliance and risk checking

The strongest model does not need to perform every task.

Limit output length

Longer content is not automatically better. Define field-level maximums to prevent the model from producing text that cannot be published.

Use batch or asynchronous processing

Product content rarely needs an immediate response. Batch, Flex, or asynchronous tiers can cost less than standard real-time inference.

Regenerate only failed fields

If the title passes validation but the selling points fail, regenerate only selling_points. Do not pay to recreate the entire page.

Create a content fingerprint

Hash the product facts, prompt version, and model version. If none of them changed, do not call the model again.

Building the Same Workflow with n8n or Make

The pipeline can also be implemented without a custom Python service.

n8n workflow

Read Google Sheets / Excel
→ Split in Batches
→ Normalize data
→ Structured LLM generation
→ JSON Schema validation
→ Prohibited-term check
→ Risk branch
→ CMS or review table
→ Token and cost logging

n8n is a good choice when self-hosting, code nodes, databases, and detailed error handling are important.

Make scenario

Watch Rows
→ Iterator
→ Text / JSON Mapping
→ AI Module
→ Parse JSON
→ Router
→ Low risk: publish to CMS
→ High risk: create a review task

Make is often easier for operations teams and automation projects that benefit from a clear visual canvas.

Whichever platform you choose, “the model call succeeded” must never mean “the content is safe to publish.”

Conclusion

The real challenge in AI-generated product pages is not writing speed. It is ensuring that every statement can be traced to verified product data and remains reviewable, recoverable, and governable at scale.

A reliable system should: