Legal
Disclaimer
A health score is a measurement of your markup against a published set of checks. It is not a ranking prediction, a guarantee, or a substitute for judgement.
Effective 21 August 2026 · Applies to PixyScan
1. What this tool is
PixyScan is a diagnostic crawler. It fetches the pages of a site you connect, evaluates the server-rendered HTML against 100+ published checks, and reports what it found and what has changed since the previous crawl.
It is not an SEO consultancy, not professional advice, and not a replacement for a person who understands your site and your market. It tells you what is measurably true of your markup. What to do about it is a judgement it does not make.
2. What the health score is not
The score is a weighted count of checks passed against checks that apply, out of 100. That is all it is. In particular:
- It does not predict rankings. No search engine uses this score, and there is no relationship between it and your position for any query.
- It does not predict traffic. A rising score does not entail rising visits, and a falling one does not entail lost ones.
- It does not predict whether an answer engine will cite you. The AI readiness score measures signals under your control — crawler access, content shape, machine-readable meaning. Whether any model quotes you is decided by that model.
- 100 does not mean “no SEO problems”. It means every applicable check in our catalogue passed. Content quality, search intent, information architecture, brand authority and everything else that decides how a site performs are outside what a crawler can see.
- Two sites’ scores are not directly comparable. Which disciplines are enabled, what kind of site it is, and how many pages were crawled all move the number.
3. Why a check can be wrong
We build the catalogue carefully and test it, and it will still be wrong sometimes. The honest reasons:
- The crawler reads server-rendered HTML. If your title, canonical or structured data is injected by JavaScript after load, we will report it missing. That is deliberate — a search crawler sees the same first response — but it means a page can fail a check while looking correct in your browser.
- Some checks depend on inferring what a page is for. Whether a page is a how-to, an FAQ or a comparison is inferred from its content, and a check that only applies to comparison pages can fire on a page that is not one.
- Sites change while they are being crawled. A deploy mid-scan produces a report covering two versions of the site.
- Search engine guidance moves. A check that reflected best practice when it was written can become outdated before we revise it.
- Not everything is reachable. Rate limiting, geo-blocking, bot protection, timeouts and robots.txt rules all shape what a crawl can see, and a page we could not fetch is not a page we can assess.
Every check is documented, including how it is evaluated, so you can tell a real finding from a misfire. If you find one that is wrong, please tell us — see section 8.
4. What we do not measure
A passing report says nothing at all about any of the following, because none of it is measured:
- Page speed and Core Web Vitals. No Lighthouse run, no LCP, INP or CLS.
- Rankings, keywords, backlinks and competitors. None of it is collected.
- Accessibility. A handful of checks touch semantics and alt text as SEO signals. That is not a WCAG audit and must not be relied on as one.
- Security. We report on a small set of HTTP response headers. That is not a penetration test, a vulnerability scan or a security assessment.
- Legal compliance. Nothing here assesses whether your site complies with privacy, accessibility, advertising or any other law.
- Content quality and factual accuracy. Readability is measured as a grade level. Whether the writing is good, correct or useful is not.
5. Acting on the output
Decisions you make on the basis of a report are yours. Before making a change with real consequences — altering canonicals, changing robots.txt, removing pages, failing a deployment — verify the finding against your own understanding of the site.
This matters most for the CI integration. Configuring a pipeline to fail a build on a score threshold is a choice you make, and where that blocks a release the responsibility for the threshold and for the pipeline’s behaviour is yours. We report a number; your pipeline decides what it means.
To the extent the law allows, we accept no liability for loss arising from decisions taken on the basis of the service’s output. The limits in section 11 of the Terms of Service apply.
6. Third-party sites and content
Reports name and link to URLs found while crawling, including external destinations. Those links are reported because your site points at them, not because we endorse or have reviewed what is there.
You are responsible for having the right to scan any site you connect. See section 4 of the Terms.
7. Availability
The service is provided “as is” and “as available”. Scans can fail, be delayed, or return partial results — sometimes because of us, frequently because of the site being crawled. A scan that ran and found nothing is not the same as a site with nothing wrong, and the product distinguishes the two: a failed run never replaces the last good report.
8. Tell us when we get it wrong
A check that misfires on your site is the single most useful thing you can send us. Email [email protected] with the check’s name, the URL it flagged and what you believe is correct. We read every one, and checks have been corrected and retired on exactly this basis.