DEV Community: Joan Winter

Why Google keeps disapproving your Shopping products — and how to spot it in 10 seconds

Joan Winter — Sun, 05 Jul 2026 17:48:14 +0000

If you run Google Shopping ads for a Shopify or WooCommerce store, you've seen it: products quietly marked Disapproved in Merchant Center, silently cutting your reach and wasting spend. The frustrating part is that the causes are almost never interesting — they're boring data problems in your product feed.

Here are the ones that bite most often in 2026, and a free tool I built to find them instantly.

The usual suspects

1. Invalid GTIN. Every barcode number ends in a check digit computed from the others. One mistyped digit fails validation and disapproves the item. And here's the trap: never invent a GTIN to make the error go away — fabricated identifiers can get your whole account suspended. If a product genuinely has no barcode (handmade, custom, own-brand), set identifier_exists = no instead.

2. Price format. Google wants a number plus an ISO currency code: 24.99 GBP. A currency symbol (£24.99) or a comma decimal (24,99) gets rejected. The feed price also has to match the landing page.

3. Availability values. It must be exactly in_stock, out_of_stock, preorder, or backorder. Friendly-looking values like available, in stock, or yes are rejected.

4. Titles. Promotional text (Free shipping, Sale, Best price), ALL-CAPS titles, and titles over 150 characters are all common triggers. Titles should describe the product, not advertise it.

5. Missing fields. Every item needs a unique id, title, description, link, image_link, price, and availability. A blank description (common when a Shopify product's body is empty) is enough to disapprove it.

Finding yours without reading diagnostics row by row

Merchant Center will tell you that something is wrong, but digging through it product by product is slow. So I built Feed Doctor — a single page where you drop your product feed (a Shopify CSV export or a Google feed, CSV/TSV/XML) and it validates every row against Google's product-data spec, returning a ranked, plain-English list of what will be disapproved and why.

The part I care about most: it runs entirely in your browser. Your product data is never uploaded anywhere — there's no backend to send it to. Close the tab and it's gone. For something touching your store's catalogue, that mattered to me.

It checks GTIN check digits, price/availability formatting, title issues, missing fields, and the identifier logic above. There's a one-click paid fixer if you want the corrected feed generated for you, but the audit itself is free and needs no signup.

Try it: https://yoonustaji.github.io/feed-doctor/

If you want to go deeper on any single error, I wrote up the full list of disapproval reasons and a dedicated guide to fixing invalid GTINs the safe way.

Built with a small, dependency-free JS validation engine — happy to talk about how the GTIN check-digit and rule layer work if anyone's interested.

Stop prompting, start encoding: turning engineering discipline into Claude Code skills

Joan Winter — Sat, 04 Jul 2026 23:01:41 +0000

Claude Code is remarkably capable. But out of the box it does what you prompt — and most prompts quietly skip the checks a senior engineer would never skip. Ask it to "fix the slow endpoint" and it will happily eager-load a relation and call it done, without ever proving the slowness was an N+1 or measuring the result. The capability is there. The discipline is not — because you did not ask for it.

The fix is not a bigger prompt. It is encoding the workflow as a skill.

What a skill actually is

A Claude Code skill is a Markdown file (SKILL.md) with a little frontmatter and a body of instructions. The frontmatter is what makes it discoverable:

---
name: n-plus-one-hunter
description: "Find and fix N+1 query problems and hot-path database waste. Use when pages are slow, DB CPU is high, or before traffic events."
---

That description is load-bearing: it is how Claude decides when to reach for the skill. Write it as "use when X" and the model matches it to the situation on its own.

The body is where discipline lives. The difference between a skill that works and one that produces confident nonsense comes down to one principle.

Verification gates beat goal descriptions

Compare two ways of writing the same step.

Goal description: "Remove dead code carefully."

Verification gate: "A symbol is provably dead only if ALL hold: no references in code, templates, configs, or string literals (grep with and without word boundaries — dynamic languages call things by string); not part of any public API surface; not framework-magic (signals, fixtures, tasks); and the test suite passes with it removed. Anything failing a criterion is quarantined, not deleted."

The first is a vibe. The second is a checklist the model cannot skip without noticing. Same goal — wildly different reliability, especially on the tenth run when the novelty has worn off.

A worked example

Here is the spine of an N+1 hunting skill, compressed:

Locate suspects statically. Identify the ORM and its lazy-loading idioms; grep for relation access inside loops, .map, and template iteration.
Confirm with query counts — never fix an unconfirmed suspect. Set up query counting (assertNumQueries, an engine event listener, Prisma $on('query')). Exercise the endpoint at realistic N (20+, not 2). A real N+1 shows the query count scaling with N. Record: endpoint, N, count, statement.
Fix in preference order: eager-load, then annotate/aggregate in the DB, then restructure, then cache (last resort — and say so, because it hides the problem).
Prove it. Re-run the counter, record before/after in the commit ("queries: 142 → 4 at N=50"), run the full suite (eager loading changes queryset semantics — a test change is a red flag, not a rubber stamp).

Notice step 2. Without the "confirm before fixing" gate, an eager assistant optimizes things that were never slow and never measures whether it helped. The gate is the whole ballgame.

Try it

I packaged two of these as a free repo you can drop into any project:

readme-refresh — treat every claim in a README as something to verify against the code
pr-description — write the PR description from the actual diff, not from memory

https://github.com/joanwinter333-rgb/claude-code-skills-free

Install is a copy into .claude/skills/, then type / in Claude Code.

If they are useful, there is a full set of 10 (legacy audit, migration safety, security sweep, perf baseline, incident postmortem, and more) here: https://winterjoy1.gumroad.com/l/qnrbr

Honest note: these skill docs were authored with AI assistance and shaped by real production experience maintaining live systems. Every workflow was tested in Claude Code before release.