You have thousands of product and category pages, and most of them are quietly going stale. Specs changed. A material changed. A category picked up twelve new products and the intro paragraph still describes last year's range. If you want to automate product page refresh work without hiring a rewriting team, this guide gives you the workflow, step by step.
It is for ecommerce marketing leads who own the content but not the commerce system. By the end you will have a page inventory, a field contract that says what AI may never touch, a trigger queue, templates, validators, and a safe release loop.
Feeling behind? That is normal. Almost every catalog is behind. You only need one page family to start.
The short answer
Use AI for the language layer, not for the source of truth.
Detect a real product or page change. Pass the model only approved facts and brand rules. Generate a structured copy patch. Validate every locked field against the source system and the rendered page. Release a small, representative batch. Then watch the feed, the schema, the crawl, and the page performance before you expand.
That single boundary is what makes ecommerce content automation safe. A refresh changes the presentation and editorial layer of a page that already exists. It does not create products, set prices, assign SKUs, invent identifiers, or replace your PIM, ERP, pricing service, or commerce platform. Your pipeline can read those systems and react to them. It must never ask a language model to become one.
Here is how the four layers stack up:
- Commercial source of truth. Identifiers, price, currency, availability, variant values, materials, compatibility, warranty, shipping, returns, legal claims. AI gets read access only.
- Page and template layer. URL, canonical, layout, product-card fields, category hierarchy, filter behavior, locale. AI may propose copy inside an allowlist. Structural changes stay deterministic.
- AI language layer. Descriptions, benefits, category introductions, buying guidance, FAQs, metadata, anchor text. Generated only from the supplied record.
- Validation and release layer. Feed, page, and schema comparison, render and crawl checks, canary release, rollback, monitoring. AI cannot override a failed check.
Keep those four straight and the rest of this guide is mechanics.
Step 1: Inventory and classify the pages you will refresh
Start with the site you already have, not with a prompt.
Crawl it and create one record for every canonical product and category URL. Label each one: product page, product group, variant page, category page, subcategory page, editorial block, or a utility page you will never refresh.
For each record, capture the template, locale, canonical URL, parent category, identifier, variant model, last content refresh, last commercial-data change, and indexing state. Add business fields too: revenue band, conversion importance, seasonal status, regulated category, and whether a price or availability change is pending. Those are your prioritization inputs.
Separate canonical pages from search results, session URLs, tracking URLs, sort URLs, and filter combinations. And record the real link path from menus to categories, categories to subcategories, and subcategories to the products you want indexed. Google's ecommerce guidance asks for a crawlable path built on normal anchor links, not search-box submissions or arbitrary JavaScript events.
This is also where a content map earns its keep. DeepSmith's Content Map crawls your site and your competitors' sites, classifies every page onto a topic and a funnel stage, and rechecks sitemaps every 24 hours so new pages fold in without a re-import. Use it as your editorial inventory layer, not as the source of price, stock, variant, or identifier truth.
Done means: every refreshable canonical page has one stable record, one page type, one source record, one template, and a named release owner. Every excluded URL has a reason.
Common mistake: sending every URL a crawler returns straight into an AI model. Faceted navigation can spin up thousands of near-duplicate combinations. Use standard key-value parameters, strip unnecessary ones, avoid linking to empty refinements, canonicalize the preferred version, and keep only canonical URLs in your sitemaps. A
nofollowreduces discovery but does not block crawling. Robots rules are the crawl-control mechanism.
Step 2: Lock the facts AI is not allowed to change
The most important decision in this whole build is what AI cannot touch.
Write a field contract for every page type, before you generate anything. Map each visible field and each structured-data property back to the system that owns it.
Locked fields: product ID, SKU, GTIN, MPN, brand, price, currency, sale price, availability, variant ID and attributes, category, dimensions, ingredients, material, compatibility, safety information, warranty, shipping, returns, legal text, and effective dates.
AI-editable fields: product description, benefit bullets, use-case prose, category introduction, buying guidance, FAQ wording, meta description, title suggestions, and anchor copy. Give each one a maximum length, a required tone, an allowed evidence set, and a fallback for when the evidence is missing.
Deterministically derived fields: Product or ProductGroup structured data, breadcrumb markup, canonical tags, price display, availability labels, feed fields, sitemap membership, and variant URLs. These come from the validated record, never from model prose.
Then set the release rules. Locked fields need an exact match. A missing or conflicting locked field blocks publication and the model returns a review flag instead of a guess.
A few limits are hard numbers, not opinions. Google Merchant Center caps the product ID at 50 characters, and asks you to keep it unique and stable for the same product across updates, countries, and languages. Feed titles cap at 150 characters and descriptions at 5,000. MPN caps at 70 alphanumeric characters and must be manufacturer-assigned. Supply a GTIN only when you know it is correct. Never manufacture one, borrow one from a similar item, or let a model fill the gap.
Prices deserve their own rule. Your pipeline may format a number for display. It may never recalculate or paraphrase one. Availability gets a fixed mapping from the source status, and nothing else.
Done means: every locked field has an owner, a null policy, an allowed value set, a timestamp, and a fail action. A test record proves that a conflicting price or a missing GTIN stops the job.
Pro tip: ask the model for a patch, not a page. A patch says which approved copy fields changed and leaves price, stock, identifiers, URLs, and schema untouched. It is also far easier to review and reverse.
Step 3: Trigger refreshes from real changes, not a calendar
Rewriting everything on a timer is how teams burn budget and introduce errors at the same time. Trigger on evidence instead.
Useful triggers include:
- A webhook or change event from your commerce platform when a product, variant, category assignment, or content record changes.
- A scheduled comparison of source-data versions for systems without webhooks.
- A price, currency, or availability change, which gets an immediate deterministic page and feed update, with a copy review only if the wording changes.
- A launch, discontinuation, seasonal date, material change, compatibility update, warranty update, or policy change.
- A taxonomy or merchandising change that alters a category's product set.
- A stale-copy signal, a shifting search query, a broken internal link, a schema error, or a competitor covering something your category page does not.
Score the queue on business importance, factual risk, freshness, search opportunity, and confidence in the source data. That score is your operating choice, not a search-engine standard. Put the reason on the record so anyone can see why a page is in line. A price or safety conflict should outrank a wording tidy-up every time, even when the tidy-up has more impressions.
Each queue record needs the URL, page type, identifier, trigger, changed fields, old and new source versions, risk class, priority, template, locale, editable fields, required validators, and current state.
Platform details matter here. Shopify's docs note that a product webhook includes full variant details for the first 100 records, and not for the ones after that. So a worker handling a high-variant product must enqueue the event, then read the complete record before generating anything. Shopify also documents asynchronous GraphQL bulk operations for reading data in volume. Other platforms have their own rules. Check yours.
Done means: a real source change creates one idempotent job. The same event delivered twice does not produce two refreshes. A page with no meaningful reason is not regenerated just because a timer fired.
Common mistake: treating an AI visibility or SEO tool as a live price and availability feed. Editorial data tells you which page deserves attention. It cannot replace the system that owns the commercial facts.
Step 4: Write separate product and category page refresh templates
A product page and a category page answer different shopper questions, so they need different inputs, prompts, and validators. Building one template for both is where most projects wobble.
Product-page template
From the approved product record, generate a concise description of what the item is and who it is for, benefits that restate or carefully imply approved features, use-case and compatibility language the record supports, variant-aware wording, FAQ answers built only from approved facts, metadata suggestions, and anchor text pointing at real category or support pages.
Keep the spec table, price, currency, availability, variant selector, product ID, shipping, returns, warranty, and legal claims deterministic. Always.
Category-page template
From the current category definition and product set, generate a short introduction explaining shopper intent, buying guidance based on real attributes, subcategory descriptions and links, filter explanations where the facets exist, and FAQs about choosing.
Keep product cards, prices, stock labels, filter values, counts, and sort behavior data-driven. Avoid sentences like "all products here are" when the product set moves weekly. Never let generated prose claim a price range, stock level, material, or feature that the current category data does not prove.
One structural note. A category page is not a giant product page. Product markup belongs on product-detail pages, and breadcrumb markup expresses the hierarchy. Your category copy should support the link path down to products, not bury it under a wall of text.
Brand guardrails
Every batch needs your positioning, differentiators, claims to make and claims to avoid, approved product names, audience and buying stage, tone and banned phrases, required legal language, and good and bad copy examples.
Store that once, as structured context, instead of a PDF each prompt has to rediscover. This is exactly what DeepSmith's Deep IQ holds: company positioning, product profiles, buyer personas, brand voice, visual guidelines, and reusable content types that shape every draft the system produces. It keeps your terminology consistent across thousands of pages. It does not verify live price, stock, GTIN, or variant data, and you should not ask it to.
Done means: a test prompt cannot invent a feature, number, identifier, material, compatibility statement, price, or guarantee when the input omits it. The same product record produces the same terminology across versions and locales.
Step 5: Generate copy patches in small, bounded batches
Now you can generate. This is the step that lets you automate product page refresh work in volume, and the model earns that trust by getting a complete, constrained brief and returning machine-readable output.
Pass it the page type and template version, the page identity and product or category ID, the approved source fields with their effective dates, the existing copy and the reason for the refresh, the audience and locale, your brand voice and claim restrictions, the exact fields it may edit, maximum lengths, an instruction to preserve anything unsupported as unknown, and an instruction to raise an exception when source fields conflict.
Ask it to return proposed values for editable fields, the source facts it used, any claims the rewrite introduced, missing or conflicting inputs, a risk label, and a diff against the old copy.
Run it in two passes. Validate the deterministic payload first. Generate the approved language fields second. Then merge the patch into the payload and run the validators again.
Batch by page family, locale, risk, and template version. Your first batch should be small and deliberately awkward: a simple product, a product with many variants, a sale item, a backordered item, more than one locale, and a category with filters. There is no universal safe batch size. Expand only when the sample passes.
A production platform saves real hours where the content is editorial. DeepSmith's Content Studio and the Writer turn an approved idea into researched, brand-grounded content with internal links, metadata, and a cover image built in during production, and Autowrite schedules that production to run on a set date without anyone in the app. That helps most with category buying guides and supporting editorial blocks. It is a production capability, not a live catalog synchronizer, so keep your commerce facts flowing from your commerce system.
Done means: every generated record carries a diff, a source-data version, a template version, a validator result, and either a publishable state or an explicit exception. Replaying the batch produces the same result.
Common mistake: asking a model to "improve this product page" with only a URL. A URL is not a reliable fact set. The model needs the record, the allowed fields, the brand rules, the page type, and a way to say no.
Step 6: Validate facts, schema, links, and the rendered page
Validation is the control that turns ecommerce content automation into a safe system instead of a fast one. Take this step seriously and the rest gets much calmer.
Product and feed checks. Compare title and description where the feed requires them to match the landing page, plus price, currency, sale price and effective dates, availability, the identifier set, and every variant's name, ID, selected option, image, price, availability, and add-to-cart behavior. Merchant Center expects the landing page to show the key product elements and expects them to match your submitted data, held consistent across device, browser, user agent, location, and cookies. A variant-specific page should open with the right variant already selected.
When a price mismatch appears, do not diagnose it from the AI output. Compare the source record, the feed payload, the server response, the rendered page, and the structured data. The cause is usually a stale cache, an out-of-sync feed, a currency mismatch, or the wrong selected variant. Merchant Center can update some product information automatically from landing-page data, but treat that as a backstop, never as your architecture.
Structured-data checks. For variants, use ProductGroup with variesBy, hasVariant, and productGroupID alongside Product data. Give every variant a unique identifier where one is known and valid, and give the group a parent identifier. For separate variant pages, each variant needs its own URL that opens directly with the correct image, price, availability, and purchase action. Put markup in the initial HTML where you can, especially for price and availability, because JavaScript-generated markup can make shopping crawls less reliable for fast-changing fields. Validate with the Rich Results Test, fix critical errors, and check a few live pages with URL Inspection. For hierarchy, BreadcrumbList needs at least two ListItems, each with its name and position, following a typical user path rather than a copy of the URL.
Crawl and link checks. The canonical is unchanged unless a deterministic rule changed it. The page is live. Product links are real anchors that resolve. No links point at empty filter results. Sitemaps hold canonical URLs only. And the visible HTML, the JSON-LD, the feed, and the client-rendered UI never disagree with each other.
Brand and copy checks. No unsupported feature, number, comparison, guarantee, or superlative. No banned term. No locked field altered inside the patch. Every category page refresh reflects the current product set instead of freezing a temporary merchandising state into permanent prose.
Pro tip: make these hard failures, not warnings: price or currency mismatch, availability mismatch, invalid identifier, missing selected variant, missing required feed field, critical schema error, canonical mismatch, page error, and any AI claim with no supporting source field. Send style preferences and minor wording differences to a low-risk review queue instead.
Step 7: Release a canary, publish through the owning system, and keep rollback data
Never move a whole page family from generated to live in one step. Not once. Not even when the sample looked perfect.
Freeze the patch and record the source and template versions. Pick a small canary set that includes high-variant products, several locales, sale and unavailable states, and category pages with facets. Render those pages in the same contexts shoppers and crawlers use, checking load consistency, mobile behavior, variant selection, price, currency, availability, the buy action, and the structured data. Then run the feed comparison, the Rich Results Test, URL Inspection, and the link and brand checks.
Then publish through the commerce or CMS API that owns the page. An editorial tool is never the authority for price or stock. Update the feed and the sitemap through the systems that own them, keeping only canonical URLs in the sitemap.
Store the previous payload and copy so a rollback happens by page ID, not by someone reconstructing last month's paragraph from memory. Expand only after the canary clears every hard failure and a human has looked at representative renders.
For the editorial pieces of the workflow, DeepSmith's Produced Content is where you review, edit, and publish, straight to WordPress, Webflow, Strapi, Sanity, or Contentful, or to your own webhooks, with Markdown and HTML export as a fallback. The destination still owns the page fields and the commerce facts. That division is the point.
Done means: the canary is live, reversible, and observable. Every published page traces back to its input version and validation record. One failed page rolls back without touching the others.
Common mistake: using one good-looking page as proof the batch is safe. A simple product passes easily while a multi-variant, backordered, localized, filtered page falls over.
Step 8: Monitor the loop and stop rewriting when the evidence says stop
A refresh pipeline is only finished when it watches its own results.
After every release, track job completion, failure, and exception rates, plus pages generated, published, skipped, blocked, and rolled back. Track locked-field mismatches, price and availability and variant mismatches, critical structured-data errors, broken links, accidental noindex or robots blocks, and feed disapprovals. Then track the business signals: clicks, impressions, conversion, add-to-cart, revenue, and support or return volume, all against a defined baseline and a comparable page cohort.
Search Console's Shopping section can surface Merchant opportunities and rich-result reports for Product snippets and Merchant listings when Google identifies your site as an online merchant. Use those reports to find invalid or missing markup. Valid structured data is never a promise of a rich result, and recrawling can take several days, so give a release time to settle before you judge it.
Run the loop on a cadence. Event-driven for deterministic price, availability, identifier, and variant repairs. Queue-driven for copy, only where a real trigger exists. Post-release checks on every run. Periodic reviews of page cohorts, stale-copy age, category link coverage, and schema health. And template revision whenever the same failure keeps appearing, because asking editors to fix one defect page by page is how a system quietly becomes a job again.
Here is the part people skip: there is no universal refresh frequency, batch size, word count, or traffic uplift. Set yours from your product lifecycle, your data-change rate, your risk, and what you observe. Do not pad a thin page with repetitive text to hit a number, and do not publish an improvement percentage you cannot evidence.
Done means: you can name which pages improved, which failed, and why, and your templates get better instead of your queue getting longer.
What to do next
Pick one page family. Just one. A single category and the products inside it.
Write the field contract for that family, build the two templates, run ten pages through generation and validation, and release five as a canary. That is a week of work, not a quarter, and it teaches you more than any planning document will. Once the loop holds for one family, expanding is mostly copying the contract.
You do not need a bigger team to scale product content. You need one boundary between facts and language, and one loop you trust. Every team that has learned to scale product content safely got there the same way, one page family at a time.
If the brand-context and content-production parts are what is slowing you down, start a DeepSmith free trial and set up your product, persona, voice, and content types once. Your commerce platform keeps owning the commercial facts, exactly as it should.
