What a 100-Point Technical Health Score Should Cover

Almost every SEO tool will hand you a number. Your site's technical health is 73 out of 100, or 88, or — on a bad day — 41. The number is reassuring because it is simple: one figure, a colour, a sense of progress when it moves up. But a health score is only as good as what it measures and how it weights what it measures. A score of 90 can hide a serious problem; a score of 60 can flag a dozen issues that barely matter. If you are going to trust a number, you should understand what a good one is actually made of.

This article breaks down what a genuinely useful 100-point technical health score should cover. Not the marketing version — the analytical version: the categories that belong in it, roughly how much each should weigh, and why a flat checklist of equally-weighted items produces a misleading score. The goal is not to give you a formula to copy. It is to make you a more critical reader of any health score you are shown.

Why a health score needs structure, not just a checklist

The naive way to build a health score is to make a long list of technical checks, give each one a point, and add them up. Two hundred checks, each worth half a point, sum to 100. It feels rigorous. It is actually misleading, for one decisive reason: technical SEO issues are not equally important, so a score that treats them equally does not measure what you care about.

Consider two sites both scoring 85. Site A lost fifteen points to a scatter of minor issues — a few missing meta descriptions, some images without alt text, a handful of long title tags. Site B lost the same fifteen points to one catastrophic issue: a noindex tag on its main content template, removing whole sections from Google's index. Same score. Wildly different situations. Site A is basically fine. Site B is bleeding traffic. A flat, equally-weighted score cannot tell them apart, which makes it worse than useless — it provides false confidence.

So a useful health score must be weighted. Issues that determine whether pages can be found and indexed at all must count for far more than issues that are cosmetic polish. The score must also be structured into categories, so a single number can be decomposed into "where is the problem," not just "how bad overall." With that principle established, here are the categories a serious score should contain, in rough order of weight.

Category one: indexability and crawlability — the heaviest weight

This category answers the most fundamental question in technical SEO: can search engines find, crawl, and index your pages at all? If the answer is no, nothing else matters — the most beautifully optimised page on earth contributes zero traffic if it is blocked or noindexed. This category should carry the largest single share of the score, plausibly a quarter to a third of it.

What belongs here: robots.txt correctness — no rule blocking pages that should be crawled. The presence of unintended noindex tags. The ratio of indexed pages to pages that should be indexed, in both directions. Canonical tag correctness — pages canonicalising to themselves or to the right URL, not to the wrong one. The XML sitemap's existence, accuracy, and freshness. Crawl errors reported in Search Console.

A failure in this category is an emergency. A noindexed template, a robots.txt blocking a key directory, a sitewide canonical bug — each of these can erase a large fraction of a site's organic visibility. A health score that does not weight indexability far above everything else is mismeasuring the thing that matters most. When you read a score, the first question should be: how much of this number reflects whether my pages can even be indexed?

Category two: site architecture and internal linking

The second category covers how the site is structured and connected — whether crawlers and link value can flow efficiently to every important page. It deserves a substantial weight, perhaps a fifth of the score, because architecture problems silently suppress pages that are otherwise perfectly fine.

What belongs here: click depth — how many clicks from the homepage it takes to reach important pages, with anything buried too deep flagged. Orphan pages — pages with no internal links pointing to them, effectively invisible to crawlers following links and to the link-value flow of the site. Broken internal links pointing to 404s. Redirect chains and loops. The overall internal linking density on important pages.

Architecture issues are insidious because the affected pages look healthy in isolation — good content, valid markup, fast load. They underperform purely because the site's structure does not support them. A health score that includes a strong architecture category surfaces problems that page-by-page checks miss entirely. For the conceptual foundation here, our guide on internal linking strategy covers why this category carries the weight it does.

Category three: performance and Core Web Vitals

The third category measures how fast and stable the site is for real users. Speed is a genuine ranking factor and a genuine experience factor, so this category earns a real share — perhaps a sixth of the score — though notably less than indexability, because a slow page that ranks still earns traffic, while an unindexed page earns none.

What belongs here: the Core Web Vitals metrics measured on real-user data — loading, interactivity, and visual stability — and the share of URLs falling into "good," "needs improvement," and "poor." Lab-tool diagnostics on key templates: oversized images, render-blocking resources, layout shifts from unreserved space. Server response time.

The analytical subtlety here is that performance should be scored on the basis of real-user field data where available, not only lab scores. A lab tool measures one synthetic load under controlled conditions; field data reflects what actual visitors on actual devices and networks experience. A health score weighted toward field data measures reality. One weighted toward lab scores measures a simulation. Ask which your score uses.

Category four: on-page technical hygiene

The fourth category covers the per-page technical elements: title tags, meta descriptions, heading structure, image alt text, and similar. These matter — but this is where weighting discipline is most often abused. This category should carry a modest share, perhaps a tenth of the score, not a dominant one.

What belongs here: missing or duplicate title tags, missing meta descriptions, missing or poorly-structured headings, images without alt text, title tags that are too long or too short. These are real issues worth fixing. But notice their nature: they are page-level polish, and a flaw in one page rarely affects another. A site can have hundreds of these and still perform well, because they are individually minor.

This is the category that flat, equally-weighted scores inflate. There are many on-page checks, so a one-point-per-check model lets this category dominate the score by sheer count — a site loses thirty points to missing meta descriptions while a noindexed template costs the same thirty, and the score treats them as equivalent. They are not. On-page hygiene belongs in the score; it does not belong near the top of it. A score that lets hygiene outweigh indexability is structurally broken.

Category five: structured data

The fifth category checks whether the site's structured data is present, valid, and accurate. It deserves a modest share — perhaps a tenth of the score — and the way it should be scored is itself instructive.

What belongs here: the presence of structured data on page types that can genuinely use it; the validity of that markup against Google's requirements; and, critically, whether the markup accurately describes content actually visible on the page. That last point is the one a good score handles well. A naive score rewards the mere presence of schema. A good score recognises that invalid or inaccurate schema is not a positive — it is wasted effort at best and a guideline violation at worst — and scores accordingly. Presence of schema should not earn points; presence of valid, accurate schema should.

Category six: security and mobile

The final category covers two foundational items: HTTPS and mobile-friendliness. They are usually fine, which argues for a small weight — but they are catastrophic when wrong, which argues for being present in the score at all.

What belongs here: a valid, non-expiring SSL certificate; the whole site served over HTTPS; HTTP-to-HTTPS redirects working; no mixed content. And on mobile: the mobile version serving the full content (Google indexes mobile-first), with a usable layout and nothing important hidden on small screens.

These items are usually a pass, so they should not dominate a score. But "usually" is not "always," and an expired certificate or a mobile version serving truncated content is a serious problem. The category earns its place by catching the rare catastrophe, even if most weeks it simply confirms all is well.

The trap of optimising for the score instead of the site

There is a failure mode that even a well-built health score can produce, and it is worth naming before you start chasing a number upward. The score is a proxy. The thing you actually care about is a healthy site that ranks and earns traffic. When the proxy and the goal align, raising the score raises the outcome. When they diverge — and they always diverge somewhere — optimising the score becomes optimising the wrong thing.

The clearest example is the on-page hygiene category. Because hygiene checks are numerous and easy to fix, a team under pressure to "raise the score" will rationally attack hygiene first: write three hundred missing meta descriptions, add alt text everywhere, trim long titles. The number climbs satisfyingly. But if the site also has a canonical bug quietly splitting its authority, the team has spent its week moving the proxy while the real problem — harder to fix, less visible in the point total — sits untouched. The score went up. The site did not get meaningfully healthier. This is the proxy diverging from the goal, and a poorly-weighted score makes the divergence worse by rewarding exactly the wrong order of work.

The defence is to treat the score as a diagnostic, never as a target. Its job is to point you toward the category that needs attention so you can apply judgement — not to be a number you maximise. The moment "raise the health score" becomes a goal in itself, you have created an incentive to clear cheap points and avoid expensive problems, which is the precise opposite of what a health score exists to encourage. Use the score to find the work. Decide the work by impact. Never let the work be chosen by which items move the number fastest.

How to read any health score critically

Pull the analysis together into a practical lens. When a tool shows you a technical health score, do not just read the number — interrogate how it was built.

Ask what is weighted heaviest. If indexability and architecture do not dominate, the score is mismeasuring importance. Ask whether issues are weighted by severity or merely counted; a flat count lets trivial issues drown serious ones. Ask whether performance uses real-user field data or only lab scores. Ask whether structured data is scored for accuracy or just presence. And always decompose the number into its categories — a 78 that is "indexability perfect, on-page hygiene weak" is a healthy site with a to-do list, while a 78 that is "on-page hygiene perfect, indexability failing" is a site in trouble wearing a reassuring number.

The single number is a starting point for a conversation, never the conclusion of one. Its job is to point you at the category that needs attention. A score read without its breakdown is a score that can comfortably mislead you.

Where an SEO AI agent fits

Building and maintaining a genuinely weighted, category-structured health score is a lot of continuous measurement. Every category needs its checks run regularly, every issue needs to be classified by severity rather than just logged, and the whole picture needs to stay current as the site changes. Done by hand, it collapses into either an occasional manual audit or blind trust in whatever number a tool happens to print.

This is measurement and classification at volume, which is what an SEO AI agent does well. Orova can monitor these categories continuously, weight issues by genuine severity rather than counting them flat, and decompose the result so you see not just a number but where the number comes from and what to fix first. The analytical judgement in this article — how categories should be weighted, what a score is hiding — still belongs to you. The agent supplies the constant, structured measurement that makes the score honest. To connect this to content structure, see our guide on topic clusters.

A technical health score can be a genuinely useful instrument or a comforting fiction, and the difference is entirely in how it is built. Demand a score that weights indexability above hygiene, grades severity rather than counting issues, uses real-user data, and decomposes into categories. A number built that way earns your trust. Any other number is just a number.