← Blog

We rescanned the same stores — here is what moved and what did not

Prefero

Three scans of the same store, eighteen days apart: 68, then 84, then 87. Its structured-data score was 91 in all three runs. The machine-readable record never changed, and the overall score still moved 19 points.

Between June 21 and July 30 we completed 32 scans across 25 stores, and four of those stores were scanned more than once — 11 scans in total across them. Those rescans answer the question every merchant asks after reading a first report: if I scan again, what will actually move?

A readiness score is a snapshot, not a constant. The three layers of the score move at three different speeds. Structured data is the slow layer — it changes only when someone edits the template. Crawlability is the fast layer: one store gained 12 points in 21 hours when its llms.txt and agents.md appeared. And the AI-preference layer is not really a property of your store at all — across three runs of one unchanged store it was scored 40, then 80, then excluded.

Slope chart of three rescanned stores: 68 → 84 → 87 over three runs while AI preference swung 40 → 80 → neutral; 82 → 94 in 21 hours when llms.txt and agents.md appeared; and a flat 13 across four scans in six minutes
Slope chart of three rescanned stores: 68 → 84 → 87 over three runs while AI preference swung 40 → 80 → neutral; 82 → 94 in 21 hours when llms.txt and agents.md appeared; and a flat 13 across four scans in six minutes

The store that did not change and moved 19 points

A tech-accessories DTC brand was scanned three times: June 25, June 26 and July 13. Across all three runs the structured-data score was 91 and crawlability was 80, with the same single issue each time (agents.md missing). The overall score still went 68 → 84 → 87 — and every point of that movement came from the AI-preference layer, the part of the pipeline that simulates an AI buyer choosing between the store and a competitor.

RunOverallStructured dataCrawlabilityAI preference
Jun 2568918040
Jun 2684918080
Jul 13879180neutral — excluded

In the first run the preference score was 40, and the issues attached to it were exactly the trust fields: shippingDetails, hasMerchantReturnPolicy, aggregateRating. In the second run, 31 hours later, the issues list came back empty and the preference score rose to 80. In the third, no comparable product could be matched on the competitor side, so the preference dimension was excluded and the overall score was recomputed over the remaining 60% of the weights — which is why the total rose even though the comparison never happened.

None of this is noise or a bug. It is what the dimension measures: the outcome of a simulated choice, which depends on the comparison as much as on the store. The store's own scores did not move a single point. The context around it moved 40.

The 21-hour fix: 82 → 94

A second store was scanned twice, 21 hours apart. The first run scored 82: structured data 86, crawlability 40, with two issues — llms.txt missing and agents.md missing. The next run, before 06:30 the following morning, scored 94: same structured data, crawlability 100, no issues.

The data cannot tell us whether the store shipped the two files that evening or the earlier scan caught a transient state. What it shows is that the moment both intent files were readable, the score reflected it in the very next run. Crawlability is the fastest layer to change — two text files at the domain root, no template work, no code — and the fastest layer to register. Fixes here do not wait for a theme deploy; they land on the next scan.

For what those two files are and what belongs in them, we wrote a separate guide: llms.txt and the other file AI crawlers look for.

The store that never moved: 13, 13, 13, 13

The control group, so to speak. A children's book store was scanned four times within six minutes and scored 13 every time — structured data 0, crawlability 40, identical issues (llms.txt and agents.md missing, nothing more). A fourth store, scanned twice a day apart, reproduced its score as well: 33 both times.

This is the reassuring half of the story. The score is deterministic. It is not a lottery you play once and hope to win on a rerun: change nothing and you get the same number back. If your rescan returns the same score, it is not because the scanner was in a bad mood. It is because nothing an agent can see has changed.

A flat 13 also means both failure modes at once: no machine-readable product data, and none of the intent files an AI crawler would look for. We covered what that looks like across a whole cohort in 11 of 30 stores have zero AI-readable product data.

How to read your score across scans

Three practical conclusions follow from the rescans.

  1. Fix the access layer first, then rescan immediately. llms.txt, agents.md, robots.txt — hours of work, and the next scan registers it. The 21-hour case is the proof.
  2. Do not chase the AI-preference swing. It moved 40 points between runs while the store's own scores did not move at all. That dimension answers "how did you do in this comparison", not "how good is your store". One run is a data point, not a verdict — and a neutral result is not a penalty, it is the scanner admitting it could not find a fair comparison. More on how the dimension works in the AI preference dimension that decides the winner.
  3. Read the category scores, not just the total. When the preference dimension is excluded, the overall score is recomputed over the remaining 60% of the weights — which can make the total rise without any change to your store. Two scans can show 84 and 87 and mean exactly the same thing about your structured data and crawlability. The breakdown is on the methodology page.

The score you get today is a measurement of your store as an agent sees it today. The way to make the next measurement higher is to change one of the layers — and the data shows the scanner will tell you the moment you have.

See which of your layers is moving. Run a free scan at prefero.me, fix one thing, and scan again.