The Loop: Rewriting Titles and Descriptions Across a Whole Catalog

Welcome to The Loop. Every Wednesday we take one real, repetitive workflow that someone does by hand and unwind it into something you can run. This week it is the catalog rewrite: opening product number 118 of 340, fixing the title, fixing the description, saving, and going back for number 119.

Here is the idea that makes this series worth your time. The boring task you repeat is a specification in disguise. Nobody rewrites three hundred listings by inventing three hundred new approaches. You settle on a shape in the first hour and then apply it, and that shape is the whole job. The moment you can write down what the shape is, you can hand the applying off and keep the deciding. Describing replaces doing.

So let us sit next to someone doing it by hand, add up what the pass really costs, and then turn the shape into a build you can run before the end of the day.

The Loop, in Full

Before you automate anything, you have to see the loop clearly. Picture Dani, who runs a 340-product outdoor gear store on her own. The listings came in from three suppliers over four years, so half the descriptions are manufacturer boilerplate, a quarter are two lines she typed in a hurry, and the titles are a museum of every naming idea she has ever had: some lead with the brand, some lead with the color, some carry a size in brackets and some do not.

She has decided this is the month she fixes it. Here is what the fixing actually looks like, and she has done it 118 times so far:

1. Open the product in the store admin, in one tab, and the supplier spec sheet in another to check the real materials and measurements.
2. Rewrite the title into the house format she settled on in hour one: brand, then product name, then the one detail that matters for this category.
3. Rewrite the description: what it is, who it suits, the specifications as a short list, and the care line at the bottom.
4. Fill in the meta description, check the handle is not still copy-of-untitled-2, save, and wait for the save to land.
5. Click back to the product list, scroll to find where she was, open the next one, and start over.

Twelve minutes a listing on a good one, twenty-five when the supplier sheet contradicts the current description and she has to work out which is true. Nothing on that list is difficult, and that is precisely why it is worth automating. The hard part happened once, in hour one, when she decided what a good listing looks like. Everything after that is transcription, which is the same reason a store owner ends up hand-copying orders and stock counts long after they could put an agent on the store operations instead.

The Manual Tax

The real cost of a loop is never just the minutes on the clock. It is the minutes, plus the mistakes, plus the time the work sits waiting. For a catalog rewrite all three are unusually easy to price, because the multiplication is right there: 340 listings at twelve minutes each is 68 hours, and 68 hours is a month of evenings.

The money on the other side of that number is not theoretical either. In its 2025 consumer research, a survey of nearly 2,000 shoppers in the US and UK, Salsify found that 77% of shoppers rate product titles and descriptions as very or extremely important to completing a sale, second only to pricing and availability at 84%. The listing text is not decoration around the buy button. For three quarters of the people on the page, it is the thing being judged.

Then add the two costs that hide behind the minutes:

• Errors. Style drift is guaranteed. Listings 1 to 40 got the full treatment, 41 to 100 got shorter as the evening wore on, and by 118 the care line has quietly disappeared. Worse, the copy and paste from the supplier sheet occasionally brings the wrong variant's measurements with it, and a wrong measurement is a return, not a typo.
• Latency. A month-long pass means the catalog is never consistent, only partly converted. Every category page mixes new listings with old ones, so the improvement you are paying for in evenings does not fully show up in search or in conversion until the very last product is done.

A catalog rewrite you do by hand is finished exactly once, on the last evening, and starts going stale the next morning when you add a product.

So the goal is not to get through the 340. The goal is to stop paying the tax: make the house style something the store applies to a listing, rather than something Dani applies with her hands, so that listing 341 arrives already correct. That is the difference between a rewrite weekend and being able to take the listing work off your plate for good.

Unwinding the Loop

Automating starts with description, not code. Describe the loop precisely enough that a machine could follow it without you in the room, and most of the work is done before a line is written. For this loop the description is unusually valuable on its own, because the thing you are writing down, your house style, has been living in your head where nobody else can use it.

Here is the catalog rewrite captured as a spec. The interesting parts are the decisions, not the steps:

That table is the build. Everything after this is choosing how hands-off you want it to be. If you would rather answer questions than fill in a table, that is exactly how BYOBot turns a task into a spec, one question at a time, and the two middle rows are the ones worth arguing about.

The Build: One Loop, Three Ways to Run It

The same described loop becomes three builds depending on how much you want running on its own. Start at the top and move down only when you are ready. For a catalog rewrite the first build pays for itself immediately, because it produces the style rules the other two depend on.

The Prompt

Paste this into any AI chat tool with two or three listings you are proud of. You are not asking for a rewrite yet. You are asking it to reverse-engineer the house style out of the examples, so the thing living in your head becomes a block of text you can hand to a script later.

Here are 3 product listings from my store that I consider correct.
[paste title + description + meta description for each]

Step 1. Infer my house style and write it as rules a stranger could follow:
  - the title template, in the form [SLOT] + [SLOT], with any length limit
  - the sections a description contains, in order, and roughly how long each is
  - the voice: person, tense, sentence length, and any words I clearly avoid
  - what never appears (hype claims, competitor names, unverifiable superlatives)

Step 2. Here is a listing that does NOT follow it:
[paste the messy title + description + any supplier spec text]

  a) Extract every hard fact from the source: measurements, materials,
     capacity, compatibility, care, warranty, certifications. List them.
  b) Rewrite the title, description and meta description to my rules,
     using ONLY the facts from (a). Invent nothing.
  c) List any fact in (a) that did not fit in the rewrite, and any place
     where the source contradicts itself.

Return the rules, the fact list, and the rewrite as three separate blocks.

Run it in ChatGPT, Claude or Gemini, because a good prompt is never locked to one vendor. Part (c) is the part people skip and the part that earns its keep: contradictions between a supplier sheet and an old description are exactly what a human misses at listing 118. Keep the rules block. That block is now a reusable asset for anything else you write, in the same way a documented tone of voice makes it possible to automate the content you produce on repeat without it reading like a stranger wrote it.

The Script

Here is where this loop differs from most of the ones in this series, and it is worth being straight about it. Plenty of Loop builds end with a plain script and no AI at runtime, because the work is moving data from A to B. This one is not that. Writing a description is judgment, so the model call belongs inside the script, once per listing. What does not belong there is anything else: the fetching, the fact extraction, the validation and the write-back are all ordinary code, and keeping them ordinary is what makes the run auditable.

The catalog comes out through your store's API. On Shopify that is the GraphQL Admin API, which will hand you titles, descriptions, product types, tags and variants in one query and take the drafts back as metafields. If you also feed a shopping channel, check your length ceilings against Google's product data specification before you generate rather than after: it caps a title at 150 characters and a description at 5,000, and a rewrite that quietly overruns gets truncated somewhere you will not see it.

// pseudo-shape of the catalog rewrite BYOBot generates for you
const STYLE = readFile('house-style.md');      // the rules block from Tier 1

for (const product of await store.listProducts({ since: lastRun })) {

  // 1. EXTRACT the facts that must survive, before any writing happens
  const facts = extractFacts(product);          // sizes, materials, care, compat
  if (facts.length === 0) { queue.hold(product, 'no source facts'); continue; }

  // 2. WRITE: the one place a model is allowed to make a decision
  const draft = await model.rewrite({ style: STYLE, facts, product });

  // 3. VALIDATE in plain code, not in the model
  const problems = [
    ...factsMissingFrom(draft, facts),          // every fact still present?
    ...factsAlteredIn(draft, facts),            // and unchanged?
    draft.title.length > 150 ? 'title too long' : null,
    containsBannedClaims(draft) ? 'unverifiable claim' : null,
  ].filter(Boolean);

  // 4. WRITE BACK as a draft with a diff. Never straight to the live listing.
  if (problems.length) queue.hold(product, problems);
  else                 queue.propose(product, draft, diff(product, draft));
}

Two details carry the weight. The facts are extracted before the rewrite, not checked for afterwards from memory, so the validator has something exact to compare against. And every path ends in a queue rather than a save, which means the worst possible run produces a pile of drafts nobody liked, not a store full of confident nonsense. You do not write this from a blank page: BYOBot generates the full version, including the API calls for your platform, the validators, and the review queue. The same skeleton then covers your other bulk store jobs, which is the point at which it makes sense to automate your Shopify store workflows as a set rather than one at a time.

The Schedule

The schedule is the smallest leap and the one that changes the economics. Point the same script at products created or edited since the last run, put it on a nightly timer, and the drift problem disappears: the twelve new products you added this week arrive at your review queue already in house style on Thursday morning. A cron job or a GitHub Actions workflow runs it for free, and if you would rather stay no-code, a scheduled scenario in a tool like Make keeps the same rhythm. The first pass is a one-off. The nightly sweep is what stops there ever being a second one.

Here is how the three builds stack up, so you can pick your stopping point:

Steal This Build

Here is the whole loop as a spec you can hand to BYOBot or build yourself this afternoon. Copy it, swap the platform names for your own, and you have your version.

• Trigger: the full catalog once, then anything created or edited since the last run.
• Extract: the load-bearing facts from the source listing, before any writing happens.
• Rewrite: title, description and meta description against one written house style, using only those facts.
• Validate: every fact present and unchanged, lengths inside the limits, no invented claims.
• Propose: a draft plus a readable diff, into a review queue, never onto the live listing.
• Report: how many passed, how many are held, and why, in one message a night.

The loop you just watched is a product catalog, but the shape is universal. Any job where you apply one settled format to a large pile of things you did not write, whether that is job descriptions, help center articles, asset filenames or property listings, wants the same three moves: pull the facts out first, apply the style second, and refuse to publish when the facts and the draft disagree. Learn that once and the entire category of "I just need to get through all of these" turns into something you can hand off instead of grinding through.

Frequently Asked Questions

• How do I rewrite hundreds of product listings without every one sounding identical? +
  Separate the two halves of the job. The house style is the part that should be identical: title format, sentence length, the order the information arrives in, the words you never use. The facts are the part that must be different, because they come from the product itself. When you feed the rewriter a fixed style block plus a fact list pulled from that specific listing, you get consistency in the shape and variety in the substance. Sameness happens when there is no fact list, so the model fills the gap with adjectives, which is the failure mode to watch for when you first automate the listing work across your store.
• Will AI-written product descriptions hurt my search rankings? +
  What gets penalized is thin, duplicated, unhelpful text, and that describes the supplier boilerplate already sitting on most catalogs better than it describes a careful rewrite. A rewrite that adds real specifications, answers the questions buyers actually ask, and stays unique per listing is an improvement on both counts. The risk is not the tool that wrote it, it is publishing three hundred pages of interchangeable filler in one afternoon. Ship in batches, read a sample from each batch, and watch impressions per listing rather than guessing.
• Which parts of a listing should the rewrite never be allowed to touch? +
  Anything a customer could act on and be wrong: measurements, materials, capacities, compatibility, care instructions, warranty terms, certifications, allergens, and every price or stock field. Pull those out of the source listing first, pass them to the rewriter as a locked fact list, then check the draft still contains them verbatim before anything gets written back. Any listing where a fact goes missing or changes value fails the check and waits for a person. That single rule is what makes an unattended catalog rewrite safe to run.
• How do I roll a catalog rewrite out without breaking my live store? +
  Never write straight to the live listing. The build produces drafts: a new title, description and meta description stored beside the product, along with a readable diff of what changed. You approve a batch, publish it, and watch that batch for a week before the next one goes. Start with twenty listings you know well, because that is where you find out your house style is missing a rule. Writing those rules down before the first run is the same discipline as writing the workflow spec before you build, and it saves the same afternoon.