Medical website design: what those 18 agencies run themselves

A doctor's site has exactly one job

A patient does not arrive to read about the equipment in your clinic. They arrive to establish three things: that you have the speciality they need, where you are, and how to book. Anything sitting between them and those three is a cost, not a feature.

On a phone that means the phone number and the booking button belong above the fold. It means the address should be copyable and linked to a map. And it means opening hours have to be text, not an image that a search engine cannot read and a user cannot zoom into comfortably.

This sounds obvious and is followed less often than you would expect. The reason is structural: the agency prices the build by feature count, and the patient judges it by how fast they reach a phone number.

Why layout shift is worse here than elsewhere

CLS measures how much elements jump around after the page starts drawing. Google's acceptable threshold is 0.1, and the site above sits at 0.128.

On a blog, a shifting layout is irritating. On a page carrying a Book an appointment button, it means the user clicks a button that was somewhere else half a second earlier.

We have watched this play out on contact forms more than once. The misclick rate climbs, the patient concludes the site is broken, and they go and search for the phone number instead. At that moment your site stopped being a tool and became an obstacle. The three Core Web Vitals metrics spell out where that number comes from.

Patient data: collect less of it

Twelve of eighteen sites send no security headers at all. On its own that is not a catastrophe, but it reads differently on a site with a booking form, because that form is taking a name, a phone number and sometimes a description of what is wrong.

The simplest defence is not technical. Ask for less. A booking form needs a name, a contact number and a preferred time. It does not need a national ID, a date of birth or a symptom description. Every field you delete is one row of sensitive data less on a server that may one day leak. If a field genuinely is required, put the reason next to it.

Then come the technical parts: HTTPS across the whole domain, the security headers, and keeping whatever plugin builds the form up to date. The signs a site is in trouble is a list of what tends to be visible before the incident, not after.

Booking: build it or link to it

If your clinic already runs on a booking platform and patients reserve there, building a second system on the website is a mistake. The right move is for the site to link to that platform and spend the remaining effort on what the platform does not produce: speciality pages, a real introduction to the practitioner, and answers to what patients ask before they call.

A custom booking system earns its cost when you have several practitioners, several locations, or scheduling rules that off-the-shelf platforms do not cover. Even then, the first decision to make is where the calendar is stored and what happens to it when the website goes down.

One page per speciality, not one page for all of them

Patients do not search for "specialist". They search for the name of their problem. A site with a single Services page listing every speciality ranks for none of those searches. A site with a real page per speciality, saying who should come in and who should not, has a chance at all of them.

Alongside that, get the structured data right. There is a correct type for a practice or a clinic, and it hands the address, opening hours and phone number to search engines exactly as you wrote them on the page. The condition that matters is that it agrees with the visible text. Structured data claiming something the page does not say is worse than none.

When you do not need a site at all

A web design company does not usually write this paragraph, so here it is. If every one of your patients arrives by colleague referral or through a hospital's own intake system, and your capacity is full, a website is not your priority. That money returns more when it goes into keeping your profile accurate on the platforms where patients are already looking.

A site earns its place when you want new patients from search, or when you want to answer repeat questions before the phone rings and take load off reception. With neither of those goals, spend the budget elsewhere. What a website actually costs shows how much real money that decision is.

Does a medical site cost more than any other?

The real difference comes from the booking system and the number of speciality pages, not from the word medical. A site with a simple form and five content pages costs about what a corporate site of the same size costs.

What changes for a dental practice?

The search pattern is close, but images carry more weight because the patient wants to see the result. That is also where the common mistake lives: a heavy gallery that pushes the page past two megabytes.

Where should SEO for a clinic start?

One page per speciality, address and opening hours as text, and page speed. Those three move the needle before any other content work, and they all show up in page speed work and in how the pages are structured.

Does a practice need a blog?

Only if somebody will actually keep writing one. An abandoned blog with three posts from two years ago adds nothing to a site's credibility and dilutes the speciality pages while it sits there.

If new patients are meant to arrive from Google, the structure has to be built around those searches from week one. Building a site where a patient books an appointment is not the same exercise as adding a form to an off-the-shelf template, and the difference is visible in the four numbers measured above.

Method: Google organic results for the Persian query, depth 20, on 16 August 2026 from a server in Helsinki. 18 URLs answered 200; HTML weight, headers and tag counts were taken from those responses. Four URLs were then opened separately in headless Chrome with an empty cache and their requests, bytes, LCP and CLS recorded. The server is not in Iran, so do not read the timings as an Iranian visitor's experience; byte and request counts are location-independent.

The layout shift metric is defined on the CLS page at web.dev, and the right structured data type for a practice is at schema.org's Physician definition.