Pre-Flight validation
Find out what breaks the import before you run it.
Nineteen deterministic rules, run against the supplier file as it arrived. Every blocker is named with the row it is on, warnings are kept separate from blockers, and a rule that could not run says so instead of passing.
The target is a grammar, not a table
A Shopify product CSV looks like a spreadsheet and is not one. Meaning is carried between rows: a handle groups rows into a product, the first row of a group owns fields the others must leave blank, an image-only row is a row with almost nothing in it, and a row that acquires the wrong field is silently promoted into a variant that nobody created.
That is why a generic CSV checker cannot help here and why a language model cannot either. Neither has a model of the grammar, so neither can tell you that row 4,812 will be absorbed into the product above it. Ours is written down as rules, each with a passing and a failing fixture, and each fires with the row number attached.
The failure modes we have pages for — most of them produce no error message at all.
Three verdicts, not two
- Blocker
- The import will fail, or will succeed and be wrong. Named, with its rows.
- Warning
- Worth fixing; we do not expect the import to fail. Deliberately not painted the same colour as a blocker — that is how a report teaches people to ignore it.
- Not run
- The rule could not evaluate, because the column it needs is missing or unreadable. Reported as not run.
Why “not run” earns its own verdict
On a clean baseline file all nineteen rules return zero findings — and nine of them never reach their own logic to do it. They return early, because the column they check is not present.
A silence from an early return is indistinguishable, on screen, from a rule that examined the data and approved it. A report that shows both as green is telling you something it does not know. So the third verdict is not a nicety: it is the difference between “we checked and it is fine” and “we could not check”, and those are the two answers a person about to import ten thousand products actually needs to tell apart.
We know this because we ran the suite and counted, not because we assumed it.
Tested against files nobody designed to pass
The rules are exercised against 21 real supplier catalogues — not synthetic fixtures written by the same person who wrote the rules.
5 to 614 columns
Across 6 source platforms, in Latin and Cyrillic, including one workbook that crashes the reader — reported as a file we could not read, which is a different answer from a file with no problems.
4 defects those files caught
That our own tests did not. 2 of them would have corrupted a catalogue without reporting anything, while 140 hand-written tests were passing.
Free, and account-free
Every rule above runs on the free report, on any number of files. The paid plans are for turning the file into an import, not for finding out what is wrong with it.
See a report rendered from a real file on the homepage, or read where this sits in the pipeline.
Run the file you trust least.
No account, nothing stored, and the report is the same one a paying customer sees.
Check a file free