Why did my website score change when I did not change anything?
The four causes of an unexplained score movement, and how to tell which one you are looking at in under a minute.
Something changed, and it was probably not you. In order of likelihood: something on the infrastructure changed without a deploy, a check that used to succeed is now undetermined because the audit was blocked, the ruleset was updated, or content on the page shifted. The version field and the undetermined list distinguish them immediately.
Cause one: something changed without a deploy
By far the most common, and the reason worth monitoring for. Plenty of things alter your site's responses without anyone touching your repository.
- A certificate renewed. New expiry date, possibly a different issuer or chain.
- Your CDN or host updated its edge configuration. Headers added, removed or rewritten in transit.
- A WAF rule was enabled. Suddenly some paths return challenges to automated clients.
- DNS propagated. An edit made days ago finally visible everywhere.
- A third-party script changed what it loads. Your tracker vendor added a new domain, altering your third-party inventory.
- A platform updated your
robots.txtor headers at the edge. Common on managed hosting, and invisible in your source.
These are real changes to what the public receives, so the score moving is correct behaviour, not noise.
Cause two: a check became undetermined
The sneaky one. If bot protection started intercepting the audit, checks that previously produced verdicts now produce none. The site may be unchanged and entirely healthy.
The signature is unmistakable once you know to look: new entries in the undetermined array, usually with reason blocked or timeout, appearing at the same time as the score moved.
curl -s "https://outrings.com/api/v1/summary?url=example.com" \
| jq '[.undetermined[]? | {id, reason}]'Cause three: the ruleset changed
Checks get added, thresholds get revised, weights get corrected. When that happens, an unchanged site scores differently — legitimately, because it is being measured against a different standard.
Every response carries a version stamp for exactly this:
curl -s "https://outrings.com/api/v1/score?url=example.com" | jq '.versions'If ruleset differs between the two runs you are comparing, the comparison is not like for like and the difference is at least partly the rules.
Cause four: the content changed
Content-derived checks — readability, heading structure, word counts, internal link density, filler-likelihood signals — respond to editing. A new blog post, an updated homepage, a changed hero paragraph will all move these slightly. This produces small movements, typically under a point or two, and is the least interesting cause.
Diagnosing it in under a minute
- Compare
versions.rulesetbetween the two runs. Different? At least part of the movement is the rules. - Check the
undeterminedarray. New entries? The audit is being partly blocked, and that is your explanation. - Run
/api/v1/changesand readnewProblemsandresolved. This names the specific checks that flipped. - Look at which category moved. Infrastructure or security shifting without a deploy points squarely at the CDN or host.
Step three is normally decisive on its own — it converts "the score dropped four points" into "HSTS is no longer present in the response", which is a fact you can act on.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- A changes endpoint naming exactly which findings appeared and which cleared, rather than reporting a score delta alone.
- Ruleset, schema and collector versions on every response, so rule changes are distinguishable from site changes.
- An undetermined array with a reason per check, so partial blocking is visible instead of being mistaken for a regression.
- Snapshot history per site, so a movement can be placed against a timeline rather than a single previous run.
For agents and scripts, the same measurement is at
/api/v1/summary?url=yoursite.com —
see the API documentation.
Related questions
Does the score change randomly?
No. The same observations under the same ruleset produce the same result. If the number moved, an observation changed, a check stopped producing a verdict, or the ruleset was revised — and all three are reported.
My score dropped and no findings are new. How?
Usually a check moved from passing into the undetermined bucket, so it stopped contributing. Compare the undetermined arrays between the two runs — this is the standard explanation for a drop with no new problems.
How far apart should comparisons be?
Snapshots are stored at most once per site every six hours, so daily comparison is the natural cadence. Comparing runs minutes apart mostly measures caching behaviour.
Can I see the history?
Yes — /api/v1/history returns the stored snapshots for a site. It reads history only and never fetches the target, so it works even while the site is down.
Read next
What is a deterministic website audit?
Why running the same audit twice should give the same answer, what breaks that property, and why it matters more than accuracy.
ReadHow do I track website changes over time?
Building a history of what your site actually served, so you can answer "when did this break" instead of guessing.
ReadHow do I monitor a website for regressions automatically?
Catching the silent breakages — an expired certificate, a stripped header, a robots.txt that started blocking Google — before anyone reports them.
ReadWhat does a website score actually mean?
How a score out of 100 is built, what it can honestly tell you, and the four things it cannot.
Read