Wei runs an outdoor-gear store, and the audit report he bought was beautiful. Clean layout, confident typography, and the headline that closed the sale: 142 issues found — 129 fixable.
One hundred twenty-nine. The word did exactly what it was designed to do: it converted a wall of problems into a purchase decision. He upgraded to the plan with auto-fix.
Three weeks later the dashboard glowed: 117 issues fixed. And Wei — who by then had read the earlier files in this series — did the thing dashboards hate. He pulled a product page at the wire. Same missing identifiers. Same hardcoded availability. Same single Offer against fourteen variants. The delivered response was byte-for-byte the store it had been in March, wearing a report that said otherwise.
The issues hadn't been fixed. They'd been relabeled — a status flag flipped in the tool's own database, a number moved from one column to another. The most consequential word in the report, the one that priced the plan, had never been defined.
This file defines it. "Fixable" is a claim about capability — whose capability, using what information, provable how — and once you ask those three questions, most audit reports stop surviving contact.
The three dishonest meanings of "fixable"
In the wild, the word gets used three ways that have nothing to do with fixing.
Fixable = "a fix exists somewhere." The issue is fixable in the sense that plumbing is fixable: someone, somewhere, could do it. The tool's contribution is a tutorial link. Counting these in a "129 fixable" banner is counting the existence of knowledge as a product feature.
Fixable = "we can change our own record of it." The relabel. The tool marks the issue resolved in its dashboard — sometimes after you click a button that does nothing beyond the marking. Wei's 117. The fix happened to the report, not the store, and unless you verify at the wire you cannot tell the difference, which is precisely what the pattern relies on.
Fixable = "we can generate something that claims it's fixed." The most modern and the most dangerous: the tool writes content — a description, an attribute value, a spec — and publishing generated text over a gap gets counted as remediation. Sometimes it is. And sometimes the gap was a fact the tool didn't have, which brings us to the question the whole word turns on.
The honest question: who can fix this, with what information?
Every genuine issue in a catalog has an honest answer to one question: who is capable of resolving this, and where does the required information live? There are exactly four answers, and an honest report tells you which one applies to every issue it counts.
The engine alone. The fix is deterministic from data already present in the store. Barcodes sitting in admin, unmapped into markup. Availability derivable from inventory state. Offers derivable from variants. These are real auto-fixes: no judgment, no new facts, just transformation of information the merchant already owns. This category is narrower than every sales page implies — and a tool that's honest about how narrow it is has told you something important about everything else it says.
The engine, with the merchant's confirmation. The fix is computable but consequential — it rewrites live records, touches things customers see, or involves a judgment call the data can't settle. The capability is real; the authority isn't the tool's to assume. (What confirmation must come with — the ability to undo — is the next file's entire subject.)
Only the merchant. The fix requires a fact that exists nowhere in the store's data: the real GTIN of an unbarcoded product, actual shipping dimensions, whether the ceramic is dishwasher-safe. No engine can fix these, because fixing them means knowing them. A tool that auto-fills them anyway hasn't fixed anything — it has invented a fact and published it under your name. This is the line that should never be crossed, and it deserves stating as a standard: a tool may express, map, suggest, and summarize — it may never assert an unverified fact into a published record. An invented GTIN doesn't fail quietly, either; it's checkable, and machines check.
Guided manual work. Structural fixes — theme surgery, information architecture, content that needs a human's knowledge and voice. Honest tools say so and provide the map. Dishonest ones file these under "fixable" and let the banner do the lying.
Four answers. Notice what asking the question does to Wei's report: "129 fixable" is not a finding, it's a refusal to answer — four materially different capabilities laundered into one number.
FIG.02 — Who can fix this, with what? Every genuine issue has one of four honest answers; a report that will not say which is refusing the question.
The proof standard: a fix is a diff at the wire
Here's the standard that makes the word mean something, and it follows directly from the measurement file: a "fixable" claim is a promise of code, and a "fixed" claim is a before/after in the delivered response.
Before the fix: this request, this response, this check failing. After: same request, changed bytes, check passing on re-run. Not a dashboard state — a diff any skeptic can pull themselves with curl. If a tool claims a class of issue is fixable and cannot demonstrate that diff on your store's actual data, the word is marketing. If it marks something fixed and the wire disagrees, you've learned what its other numbers mean.
This standard has a corollary that separates serious tools from theater: the fix category an issue belongs to should be determined by code, not by copywriting. Whether something is engine-resolvable is a property of where the required information lives — which is checkable — not a label someone chose because it converts.
FIG.03 — Relabel versus remediation. A fix is a diff at the wire; everything else is a change to the report.
Five red flags in any audit report
Fifteen minutes with a report, five things to look for:
1. Fixable count ≈ issue count. Genuine engine-alone fixes are a minority of any real audit, because most gaps involve facts or judgment. A report where nearly everything is "fixable" is describing its pricing page, not your store.
2. "Fixed" without a wire diff. If resolution is shown as a dashboard state rather than a before/after response, assume relabel until proven otherwise.
3. Fixes that are generation. Scan the "fixed" items for freshly written content where a fact was missing. Generated prose over a factual gap is the fact-invention line wearing a helpful face.
4. Auto-filled merchant-only facts. Identifiers, dimensions, materials, compatibility claims appearing without you supplying them. This is the worst flag on the list — it's not a weak fix, it's a fabrication liability published under your brand.
5. No undo. A tool confident enough to rewrite your live catalog should be confident enough to reverse it. Fixes offered without versioned rollback tell you the vendor has thought hard about the sale and not at all about being wrong. That one gets the full treatment next.
FIG.04 — Five red flags, fifteen minutes. Number four is the one that stops being a weak fix and starts being a liability published under your brand.
The fifteen-minute interrogation
You don't argue with a report; you cross-examine it. Pick three items it calls fixable and ask, in writing: which of the four answers applies — engine alone, engine with my confirmation, me, or guided? Then, for anything marked fixed, run the verification yourself — every command you need is already in FILE 02 and FILE 04: pull the delivered response, check whether the specific claim changed at the wire, re-run the failing check. Ten minutes of curl outranks any dashboard's green.
And ask the vendor one last question: if this fix is wrong, how do I get back to yesterday? The answer — or the silence — is the next file.
We hold ourselves to everything above, and we'd rather publish the standard and be held to it than sell a banner: fixable means engine-resolvable, determined by code; fixed means the diff exists; facts we don't have, we ask for — we never invent. Wei's real number, once the four-answer question was applied to his 129? A much smaller count of true auto-fixes — barcodes he already owned, availability his inventory already knew — and every one of them provable in bytes. Smaller number. True sentence. That trade is the entire discipline.
Sources & further reading
- Google — Structured data policies (accuracy and content requirements): https://developers.google.com/search/docs/appearance/structured-data/sd-policies
- Google — Spam policies: scaled content abuse: https://developers.google.com/search/docs/essentials/spam-policies
- schema.org — Product identity and offer vocabulary: https://schema.org/Product
- Rank Sniper Field Notes — FILE 02 declared vs delivered: /blog/ai-agent-declared-vs-delivered-product-page · FILE 04 the legibility layer: /blog/product-attributes-ai-systems-refuse-to-guess · FILE 06 scoring: /blog/ai-visibility-score-eligible-implemented-weighted
Rank Sniper — Field Notes. Catalog legibility and AI-visibility verification for Shopify. We verify what AI agents actually receive from your store; we don't generate content and hope. Verifier, not generator.
