Check your website's health in two minutes.

What does a website health check include?

A website health check reviews your site's underlying technology, performance and technical configuration, usually across security, page speed, accessibility, technical SEO and usability. You can see part of it now. Open your homepage, view your source, and look at your title tag, your headings, your structured data and every script your pages load (the script list is often the surprise). A good report lists your findings in each area, with recommended actions beside them.

Providers draw the boundary differently, so check what your report covers. Some add your metadata, indexing and sitemap setup, your internal and broken links and your schema signals, then your tracking, hosting and conversion issues. Others insist on a manual review. A generic automated scan won't do for them. So before you compare results, find out which kind you hold and whether it fits your site.

The assessment is automated. It reads your homepage plus up to eight sampled pages, then scores your site on eight pillars: your architecture, performance and security; your search, schema and AI readiness; and your editorial experience and operational health. Each score comes with its evidence. And you can check that evidence on your own pages.

What does a free website health check actually measure?

Your free website health check measures what your site shows to anyone who requests it: your response headers, your markup, structured data, headings, your script and image weight, and your robots and canonical signals. Look at your own homepage headers and you will find the security settings the assessment reads. Your page source holds your schema and headings. Nothing here is hidden from you, and that is the point.

It does not log in, read your analytics, pull your field performance data or interview anyone. So it cannot see your checkout flow behind a login, your conversion rate, how your real visitors experience load times, or why your team made a choice. Anything outside your public pages goes unread. And unread is not the same as passing.

Your sample is the homepage plus up to eight pages, so a problem on one of your unsampled pages can go unseen. But where several sampled pages share the same flaw, you are looking at a pattern in your templates, and templates are cheaper to fix than pages (one edit, many pages). Open your report and you will see the evidence for each pillar. Check it yourself.

How is a website health check different from PageSpeed Insights?

A health check reads more of your site than PageSpeed Insights, which tests the one URL you enter for four categories: Performance, Accessibility, Best Practices and SEO. Paste your homepage address into it and you get your Lighthouse scores. Treat 90 or above as good, 50 to 89 as needing improvement, and anything below 50 as poor. But that one URL is a narrow window, and your other pages go untested.

Your PageSpeed Insights report shows field data from the Chrome User Experience Report, covering FCP, INP, LCP, CLS and TTFB over a trailing 28-day period. If CrUX holds no data for your URL or origin, you see No Data, though your lab results still appear. You get only the latest daily aggregation. So the report cannot show a trend in your numbers.

The assessment gives you no field data, because it reads your public markup and headers. Performance counts as one of eight pillars, at 15% of your score. Use both tools and compare what each shows on your homepage. PageSpeed Insights gives you a closer look at one page, while the assessment gives you a read across your pillars. Google notes lab tools are often better when you are finding and fixing issues. So you have a fair reason to trust your evidence over your number.

How often should you run a website health check?

Run your website health check at least quarterly, and run it sooner after any significant change to your site. Put a date in your calendar for the first week of each quarter. A recurring reminder beats good intentions every time (I've watched plenty of good intentions die in a backlog). After you ship a redesign or a new feature, check again. And the same goes for a large batch of new content.

Published guidance varies, so match it to your site. Several sources set quarterly as the minimum, which makes it your floor, not your target. One suggests every six months if your site is small or static, monthly to quarterly if it's active, and continuous checks if it's large or high-traffic. Traffic or rankings drop suddenly? Run a check right away. And if you change your site often, move to monthly.

Re-scan your site after each fix. If your score moves, the fix worked. If it stays put, you've learned something too. Your audit tells you what to fix, but only your tracking tells you whether the fix did anything. Keep each report link so you can compare this quarter with your last one. So space out your re-scans, because the assessment allows you three checks per hour per connection.

What does a health score out of 100 tell you?

Your score out of 100 puts your site in one of four bands: 80 to 100 is good standing, 60 to 79 constrained, 40 to 59 at risk, and 0 to 39 legacy condition. Open your report and read your lowest pillar line first. That is where the evidence earns its keep.

Your score is weighted: architecture 15%, performance 15%, security 12%, search 12%, schema 10%, AI readiness 10%, editorial experience 10% and operational health 16%. One number hides detail. You can land in the constrained band with strong search and schema while your security and operational health both sit low. The average looks fine, yet it buries your two weak pillars.

Your report reads your public pages, not your business, so it tells you nothing about your traffic, your revenue or how your visitors feel. Take your number as a starting point. Use it to find your pages. Then judge the evidence under each pillar, because the number alone proves little.

What should you do with a low website health score?

Read your two lowest pillars before you touch anything, then fix the cheapest evidence-backed item in each. Open your report, sort your pillars from lowest to highest, and note what you find under each: perhaps your pages lack a header, your script is heavy, or your structured data is absent. Small, specific fixes beat big, vague ones.

Weigh each pillar by its share of your score. Operational health carries 16%, so a weak result there moves your total more than a weak schema result at 10%. Fix one item, re-scan your site, and check that your score moved. Then repeat with the next item. You do not need to buy anything to start. Change your header, resize your image, add structured data, or hand the edit to whoever maintains your site. These small edits are yours to make (none of them needs a budget meeting).

Some of your pillars need deeper work than a public read can show, such as your logins, your analytics or your real-user speed. The public read cannot see them, so you need someone who can look at them directly. Paid reviews exist, and some are manual. But decide that after you hold your free evidence, not before.

Questions, answered.

Your next read.

1. 01Website repairDown, hacked or broken: what survives, what to rebuild.
2. 02Core Web Vitals testLCP, INP and CLS from what the page ships.
3. 03Website audit checklistThe eight pillars as a list you can run yourself.