Why foundations are assessed separately from content
Clinic websites tend to be assessed as a single undifferentiated thing. Somebody looks at the site, forms an impression, and reports that it needs work. That impression blends design, writing, structure and technical behaviour into one judgement, and the judgement is not actionable because it does not say which of those four is failing.
Separating the technical layer is useful because it is the only layer with objective pass conditions. A page either returns a proper response or it does not. A canonical either points somewhere sensible or it does not. Structured data either validates or it does not. These are not matters of taste, and they can be checked by anyone willing to open developer tools, which is why this instrument can be scored by a clinic without hiring anybody.
It is also the layer where failures are silent. A badly written treatment page announces itself: somebody reads it and winces. A page excluded from indexing by a stray directive announces nothing at all. It simply never appears, and the clinic concludes that search does not work for its sector.
The ordering of the criteria is deliberate. Indexability and canonical clarity come first because they determine whether anything else matters. There is no value in optimising the loading behaviour of a page that has instructed every automated reader to ignore it.
How to score this instrument
Score from the live site, not from a staging copy and not from a report. Reports summarise; this instrument asks you to look.
For indexability, view the robots file at the site root, then check the robots meta directive on a representative page from each template. For canonical clarity, request the home page with and without the leading subdomain and with and without a trailing slash, and confirm each request ends at one address. For rendering, disable JavaScript in your browser and reload three different page types.
For internal linking, start at the home page and try to reach three specific deep pages by clicking only. If you cannot, score 0 regardless of what a sitemap contains: a sitemap is a hint, not a structure.
For performance, use your browser's network throttling at a slow mobile profile and watch what happens in the first three seconds. You are not measuring a score out of a hundred. You are asking whether a person on a train would still be there.
Score 0 to 3 per criterion against the descriptors. Where a fault affects some templates but not others, score by the worst affected template that a patient would realistically land on. Averaging across templates hides exactly the problem the audit exists to find. Google's documentation on search fundamentals is the reference for most of these behaviours.
Common scoring errors
Trusting an automated report in place of looking. Automated crawlers report what they can see. If the site blocks or defeats them, the report is clean and the site is broken. Open the pages.
Scoring structured data by quantity. More markup is not better markup. Structured data that describes a page as something it is not is a defect, not an asset. Validity and accuracy are the test, per the Schema.org documentation.
Confusing a redesign with a repair. A new visual design does not fix canonical confusion, orphan pages or redirect chains, and it frequently introduces them. Score the site you have.
Scoring performance from a fast office connection. The connection you audit on is not the connection your patients use. Throttle deliberately.
Treating a not-found page as a design opportunity rather than a response code. A pretty page that returns a success response for a missing address is a fault. Check the response, not the picture.
Turning the score into a work order
The purpose of this instrument is to produce a defensible list of tasks, in order, that a clinic can hand to whoever maintains the site. That list should be written from the criteria that scored 0 and 1, in the order they appear here.
Write each item as a condition to be satisfied rather than as a task to be performed. "Every page reachable from the home page within three clicks" is testable by the person who scored it. "Improve internal linking" is not, and it will be reported as done while nothing verifiable has changed.
Attach the evidence you used to score each row. If you scored rendering 0 because disabling scripts emptied the treatment pages, say so, and name a page. The person fixing it needs the reproduction, not the verdict.
Set a re-score date at the point the work is accepted, and re-score against the same descriptors. A supplier who has fixed the foundations will welcome that; a supplier who has not will explain why the instrument is unfair.
When the foundations hold, the next question is whether the site says anything. That belongs to the treatment page quality rubric and, before it, to the intent coverage gap analysis.