Skip to content
CheckMySites

Documentation

What CheckMySites checks, how it scores what it finds, and how to act on a report.

How scoring works

Category weights, severity deductions, and why a warning costs 40% of a failure.

Core Web Vitals

Where LCP, CLS and INP come from, and the difference between field and lab data.

AI readiness

Why blocking GPTBot and blocking OAI-SearchBot are different decisions.

API reference

Run audits and pull reports programmatically.

What happens when you run an audit

You enter a URL. We validate it, confirm it resolves to a public address, and fetch the page once. That single response feeds all ten analyzer suites.

Alongside the page we read your robots.txt and XML sitemap, inspect the TLS certificate, sample outbound links for broken ones, and request real-user Core Web Vitals from Google's PageSpeed Insights. Each of those runs independently — a site with no sitemap still produces a complete report, with the missing sitemap reported as a finding rather than as a failed audit.

Nothing is installed on your site. There is no script to add, no DNS change and no verification step. The audit works the same way a search engine does, which also means it only ever sees what a search engine would.

The ten categories

Each is scored out of 100 and weighted by how much it affects traffic and revenue in practice.

CategoryWeightWhat it covers
SEO18%Titles, descriptions, headings, canonicals, structured data, sitemaps, internal links, broken links
Performance14%Page weight, compression, caching, render-blocking resources, image delivery
Core Web Vitals12%LCP, CLS, INP and TTFB
Accessibility12%WCAG 2.2 AA: alt text, form labels, landmarks, ARIA, keyboard access, contrast
Security12%TLS health, security headers, cookie flags, mixed content, exposed secrets
Content quality10%Depth, structure, readability, keyword alignment, freshness, authorship
Mobile friendliness8%Viewport, tap targets, text sizing, responsive images
AI readiness6%AI crawler access, server-rendering, structured data, quotable structure
Technical health5%Status codes, redirects, encoding, markup validity, crawl efficiency
Conversion3%Calls to action, form friction, trust signals, analytics

How to read a report

The report is ordered so the most useful thing comes first. Read it in this order and you can stop whenever you have enough:

  1. The score and verdict. One number, and a sentence saying what it means.
  2. The executive summary. Three to five sentences written for someone who will not read the rest.
  3. Category scores. Ordered worst first, so the weakest area is at the top rather than wherever the alphabet put it.
  4. What to do next. Findings grouped into recommendations, ordered by value per hour of work, each with an estimated score gain and a time estimate.
  5. All findings. Every failing and warning check, with the evidence we found and the exact change that fixes it.

If you only act on one section, make it What to do next. It exists because a list of forty findings is not a plan, and the difference between the two is what makes an audit worth paying for.

What an audit cannot tell you

Stated plainly, because a tool that overstates its confidence is worse than one that admits its edges:

  • One page at a time. An audit covers the URL you submit, not your whole site. Site-wide problems show up only if the page you audited has them.
  • Colour contrast is partial. We evaluate every inline style, but colours applied through external stylesheets, CSS variables or a dark-mode media query cannot be resolved without a browser. The report says so rather than implying full coverage.
  • No JavaScript execution. We see what a non-rendering crawler sees. That is a feature for AI readiness — it is exactly what most AI crawlers see — but it means client-rendered content is reported as missing, which is the point.
  • Security checks are passive. No injection testing, no directory enumeration, no port scanning. An auditing tool has no business sending traffic a target would classify as an attack.