Tool
Check a website through a client’s eyes
Enter an address and we will show what stops a client from getting in touch: broken scripts and files, weight and response time, mobile layout, HTTPS, forms without a privacy policy and the domain mail records that send enquiries to spam. No sign-up, nothing written to a database.
What this check cannot see
- JavaScript errors that happen while the page runs. A script can load and still break — only a browser shows that.
- Real form submission. We send nothing, so we cannot tell whether an enquiry arrives.
- Widgets added by scripts: chats, quizzes, call tracking. Their weight and errors are not counted here, so the real page is usually heavier.
Full check in a browser
We open the site in a browser the way a client on a phone would: script errors, forms and calculators, speed on mobile data. You get a write-up of what is broken and how long a fix takes. Free.
Request a full checkHow others are doing
We checked 170 small-business websites in Moscow: one in four throws a JavaScript error on the home page.
Read the study (in Russian) →How we measure
- Our server downloads the page and the files it requests straight away: scripts, styles and images that are not lazy-loaded (up to 60). Weight is bytes over the wire, compressed.
- Response time is from the request to the first byte of the page, measured from our server in Moscow.
- A broken file is one that answers with a 4xx or 5xx error. A broken script almost always means part of the page does not work.
- Policy near a form means a link to a privacy policy or consent next to a form that asks for a phone, email or name.
- Mail means the domain’s public DNS records: MX (who receives mail), SPF (which servers may send mail for the domain), DMARC (what to do with messages that fail the check).