Clinic Website Must-Haves: What It Needs So Patients Book Instead of Searching On

A patient searches for “thyroid ultrasound” at half past ten at night, lying in bed with a phone. Reception closed hours ago. On the first site in the results they see a slider with a photo of the building, a “Learn more” button and a phone number you can’t tap. On the second, within a minute, they find the doctor, the price, the next free slot and a “Book now” button. They won’t wait until morning.

A clinic website does a very down to earth job: it helps a person who is in pain or worried to quickly understand three things. Do they do what I need here. Can I trust these people. How do I book right now. Everything else, from the animated logo to the “Our mission” section, either helps answer those questions or gets in the way.

We have already covered the basics of any business website (purpose, address, speed, analytics) in the article “Business Website: 10 Things a Company Website Can’t Work Without”. Here we talk about what is specific to medicine: the structure, features and requirements that appear as soon as a site starts handling health data. To avoid talking in abstractions, a fictional multidisciplinary “Clinic N” runs through the whole text: fourteen doctors, diagnostics, lab tests, two locations in one city.

Medicine is one of the topics Google calls YMYL (“Your Money or Your Life”): for topics that could significantly affect people’s health, Google gives even more weight to signals of experience, expertise, authoritativeness and trust, and trust matters most of all (Google Search Central). For a clinic website this means every claim has an author and can be checked.

There are seven essential blocks: contacts, online booking, doctor information, service pages, patient information, a mobile version and security. Drop any one of them, and the patient drops out of the chain along with it.

Contacts visible from every page

Phone, address and opening hours belong in the header or in a sticky bar on mobile, not only on the “Contact” page.

What to check on your own site:

• on a phone, the number starts a call with one tap (a tel: link) instead of just being shown as text;
• each location has its own address, hours, directions for driving or walking in, and phone number if it’s different;
• holiday hours and temporary changes are updated in one place, not in six blocks across the site;
• next to the phone there is a second option for people who don’t want to call: a messenger or a form.

Clinic N has two locations. Bad: one number in the footer, and the patient turns up at the wrong address. Good: every doctor page and every service page says exactly where the appointment takes place.

Online booking and doctors

A button for booking without a phone call belongs on every service page and every doctor page, not just on a separate “Book” page. And for a patient, the doctor matters more than the clinic’s brand. We go through both topics in detail below.

Service pages

Every service people actually search for separately deserves its own page: “thyroid ultrasound”, “cardiologist consultation”, “complete blood count”. One long list on a “Services” page serves neither the patient nor search.

Patient information

This is where everything lives that saves calls to reception: how to prepare for a procedure (a text approved by a doctor, with their name on it), what to bring, whether you work with private health insurance and which insurers, whether you accept referrals under public health insurance or referral schemes if your clinic takes part in them, and how to get results.

It helps to look at the site as a person’s route in three stages, each needing something different.

Stage 1: search

Patients search in words, not in codes from a reference book. They type “knee hurts after running”, “check my heart”, “thyroid hormone test”. A service page should name the procedure the way a person names it and give the medical term next to it for precision. Bad: “Ultrasound diagnostics of the endocrine system”. Good: “Thyroid ultrasound” in the heading, with an explanation of the examination in the text.

Stage 2: evaluation

The person has opened several tabs and is comparing. The site with less uncertainty wins: who will see me, how experienced they are, how much it costs, how long the appointment takes, whether there’s a ramp and a lift. Every “please call for details” at this stage sends the person to the next tab.

Stage 3: action

The decision is made, and now the site just has to stay out of the way. The booking button is visible on a phone without scrolling. After booking, the person sees what happens next: confirmation, a reminder, the address with directions, what to bring. Once a month someone on the team should book through the site on a phone themselves, like a normal patient, and time how many steps and minutes it took. A broken booking flow often goes unnoticed for months, because staff book through the internal system.

A doctor page answers a question patients rarely ask out loud: “Will I feel at ease with this person?” That takes both verifiable qualifications and a human face.

What every doctor page needs:

• a real, recent portrait, not a stock photo of someone in a white coat;
• name, speciality and professional grade or title, if they have one;
• education: university, graduation year, residency, specialisation;
• courses and certificates with the organiser’s name and the year;
• what exactly to come to this doctor for (adults or children, which areas);
• which location and which days they see patients;
• a button to book with this specific doctor.

Research showed long ago why photos matter. Back in 2010, Nielsen Norman Group described how users look closely at photos of real people who work at a company and ignore generic stock images and “decoration” (NN/g, 2010). A patient spots a smiling model with a stethoscope in a second, and after that the diplomas below come into doubt too.

Next to the doctors it should be clear that the clinic operates legally. In most countries medical practice needs a licence or registration, and the patient should be able to check it. In Ukraine, for example, medical practice is on the list of business activities that require a licence (Law of Ukraine “On Licensing of Types of Economic Activity”, Art. 7). On the site, an “About the clinic” page or a footer block with the legal name, registration number and licence details is enough. That answers the patient’s question “is this even a real clinic?”

A separate word of caution about wording. In most countries advertising for medical services is strictly regulated, and the limits usually hit exactly the things clinics like to write: promises of results, superlatives, patient stories. Take Germany as an example: the Heilmittelwerbegesetz (HWG, the law on advertising in the healthcare sector) counts it as misleading advertising, among other things, to falsely create the impression that success can be expected with certainty, or to make untrue or deceptive claims about the training, qualifications or successes of the people involved (§ 3). For advertising to the general public, § 11 restricts, among other things, case histories and statements by third parties, such as letters of thanks or recommendation, when they are presented in an abusive, offensive or misleading way, and for cosmetic surgery without medical necessity it bans before and after comparisons (HWG, § 3 and § 11). For a clinic in Ukraine, the equivalent is Article 21 of the Law “On Advertising”, which, among other things, bans claims of a guaranteed effect, testimonials and doctors taking part in such advertising (Law of Ukraine “On Advertising”, Art. 21). Whether a specific page of your site counts as “advertising” in the legal sense depends on its content and context, and that’s a question for a lawyer, not for a developer. The practical takeaway is simple: on a doctor page, write facts about education and experience, not promises of results, and show your treatment texts and review blocks to a lawyer before publishing.

Typical mistakes: the page of a doctor who left six months ago still takes bookings; one doctor has ten paragraphs, three others only a name; “over 20 years of experience” without a single fact.

People often land on a service page straight from search and never open the homepage at all. So every such page has to work on its own.

A working structure for a Clinic N service page, using thyroid ultrasound as the example:

1. A heading with the name of the service in plain language.
2. Two or three sentences: what this examination is and in which cases a doctor usually refers patients for it. No promises and no self-diagnosis.
3. How it works: how long it takes, whether preparation is needed, when the report will be ready.
4. Who performs it: links to the pages of the doctors who do this examination.
5. The price, or an honest explanation of what it depends on.
6. Where: the locations that offer the service.
7. A button to book exactly this service.
8. Short answers to the questions reception hears most often.

It’s better to collect the texts from the reception call log than from other people’s sites: whatever people ask about most often is what belongs on the page.

Online booking comes in several levels. The choice depends on how the clinic already manages its schedule, how many doctors and locations it has, and who will keep the slots up to date.

About the last option. Many clinics already run their schedule and patient records in a medical information system or practice management software; in Ukraine, for example, the national e-health system is built so that users work with the central database through such a system, called an MIS (ehealth.gov.ua). If the clinic already works in one, the first question goes to its vendor: is there a ready online booking module or an API for the website, and what patient data does it pass on. The second question goes to the website developer: how will the site behave if the system is temporarily not responding. A good solution shows the person a fallback (phone, form), not an empty calendar.

It makes sense to start with the simplest option that covers evening and weekend requests and add complexity once you can see how many bookings the site brings. Either way, keep the form to a minimum of fields: name, phone, service or doctor, preferred time.

People open a clinic website on their phone in a queue, in a car park, at night when something hurts. So the mobile version is the main site. Google uses the mobile version for indexing and ranking and explicitly recommends having the same content on mobile as on desktop (Google Search Central). Hiding doctors’ education on mobile “so it doesn’t feel cluttered” means hiding it from search as well.

What to check on a real phone, not just in the browser’s emulation mode:

• the phone number dials with one tap, the address opens in maps;
• the booking button is visible on the first screen of a service page;
• text is readable without zooming, and buttons are big enough that you don’t hit the neighbouring one (the WCAG 2.2 accessibility standard sets a minimum target size of 24 by 24 CSS pixels at level AA, W3C);
• there is no horizontal scrolling, and price tables don’t spill over the edge;
• the form opens the right keyboard: numeric for the phone number, with the @ sign for email;
• the menu behind the burger button contains booking and contacts, not just “About us”.

About speed. People often repeat “a site must load in 3 seconds”, but Google measures it differently: for the main content of a page (LCP), up to 2.5 seconds counts as good, and it’s assessed at the 75th percentile of real page loads, separately for mobile and desktop (web.dev). In other words, it has to be fast for patients on mobile data, not for you on the office Wi-Fi. How to check this without a developer is covered in our article on Core Web Vitals.

Most clinic searches are local: “cardiologist near me”, “ultrasound” plus the name of a district. Google writes that local results depend mainly on relevance, distance and prominence, and prominence is influenced by, among other things, the number of links to the business and reviews (Google Business Profile Help).

For a clinic website this leads to a few simple things: a separate page for each location with the address, hours, directions and a list of the doctors who see patients there; the name, address and phone number identical on the site, in the Google Business Profile and in medical directories. How to set up the Business Profile, how to work with reviews and why a medical practice’s site often brings no patients even with good design is covered in detail in the article “Why Your Dental Website Brings No Patients”. The logic there is the same for any clinic.

On structured data. schema.org has special types for medicine: MedicalClinic (a facility focused on particular diagnostics or medical care) and Physician, with properties such as medicalSpecialty and availableService (schema.org/MedicalClinic, schema.org/Physician). Two details. First: schema.org describes Physician as a doctor’s office or practice treated as a medical organization, so it’s an organization type, not a person. For a doctor’s profile as an individual, Person makes more sense. Second: in its local business documentation Google recommends using the most specific LocalBusiness subtype, but it doesn’t promise a separate “medical” rich result and states plainly that it doesn’t guarantee features based on markup will show (Google Search Central). How markup works in general is covered in the article on schema.org and rich snippets.

As soon as a form asks “describe what’s bothering you”, the site is collecting data concerning health.

In the EU, data concerning health is a special category of personal data. Article 9 of the GDPR prohibits processing it and then lists exceptions. Among them are the person’s explicit consent for one or more specified purposes, and processing needed for medical diagnosis or the provision of health care when the data is handled by or under the responsibility of a professional bound by professional secrecy. Article 9 also lets member states add their own conditions for health data. Article 32 requires technical and organisational measures that ensure a level of security appropriate to the risk, and Article 35 requires a data protection impact assessment for large scale processing of such data (GDPR, Regulation (EU) 2016/679). Outside the EU the wording differs, but health data is protected especially strictly almost everywhere; in Ukraine, for example, this is covered by Articles 7, 9 and 24 of the Law “On Personal Data Protection” (Law of Ukraine “On Personal Data Protection”).

What this means for the site in practice (check the legal side with your own lawyer):

• HTTPS across the whole site, not just on the form page. It encrypts data between the browser and the server (web.dev).
• Minimum data in the form. Booking needs a name, a phone number and a service. Make the free text field for symptoms optional or remove it altogether: the doctor will ask anyway at the appointment.
• Separate consent to data processing next to the submit button, with a link to a clear privacy policy: who the data controller is, what the data is for, how long it’s kept, how to ask for deletion.
• Where requests go. A typical situation: form emails go to the personal inbox of an administrator who left long ago. Requests should land in the clinic’s working system with personal logins.
• Who has access. A list of the people who see requests, the site admin and the booking service, each with their own account, not one shared password for everyone.
• Third party scripts. Chat widgets, ad pixels and click heatmaps on a page with a form see more than you’d think. Keep only what’s needed there.

Information on a clinic website changes all the time: a new doctor, holidays, public holidays, a new procedure, an updated price list. If every change needs an email to the developer, the site goes stale, and on a medical site stale means untrue.

Staff should be able to change, on their own and without code, location hours and holiday closures, doctor cards (add, hide, update photos and certificates), service pages and prices, patient information, who receives requests, and downloadable documents.

Just as important is who can change what. In WordPress, for example, the standard roles are set out like this: the Administrator has access to all the features of a single site, the Editor publishes and manages posts, including other users’ posts, the Author only their own, and the Super Admin exists only in a multisite network (WordPress.org). That gives Clinic N a working setup: the head receptionist has the Editor role and changes hours, doctors and texts; one responsible person with the Administrator role can install plugins and touch settings; everyone works under their own account. Most content management systems have a similar split of roles, and it’s worth looking at it already when you choose a CMS.

A simple test before launch: give the head receptionist three tasks in the admin with no hints (change the hours for a holiday, add a doctor, hide a service). If even one of them needs a call to the developer, the admin needs more work before launch.

A template and custom development solve different problems. Don’t compare the price, compare what each option gives the clinic and what dependencies it creates.

Template problems usually start when it’s loaded with features its author never planned for. If you already need several locations and booking from a medical information system at launch, a template often stops being the fast route.

What affects the scope of work and the timeline regardless of the approach: the number of doctors, services and locations; the online booking method; how many texts the clinic prepares itself and how many need to be written and approved with the doctors; the site’s languages; moving from an old site while keeping page addresses; a legal review of the texts. Collecting content and getting it approved by the doctors usually eats up the most time.

How to check a contractor before signing a contract, which questions to ask and what the contract should contain is covered in the article “How to Choose a Website Developer and Not Pay for the Same Site Twice”.

The most expensive mistakes are rarely visual: a beautiful site where you can’t book from a phone loses to a modest one where you can. Check yours:

1. The phone number is there but can’t be tapped, or it’s only visible on the contact page.
2. You can only book by calling during opening hours.
3. Stock photos instead of the doctors, or one group photo of the team.
4. Doctors who no longer work there, with booking still open.
5. Service names in reference book language, not in the patient’s language.
6. Promises of results and “the best methods” in treatment texts, without a legal review.
7. No licence details and no legal name of the clinic.
8. A booking form with ten fields and a mandatory description of symptoms.
9. A mobile version with cut down content and buttons that are hard to hit.
10. Only the developer can change the site, so the holiday hours get updated after the holiday.

If three or more points describe your site, take a fresh look at it before thinking about a redesign. That’s what our free website check is for: SEO, AI search and trust.

A clinic website has to lead a person from search to booking without unnecessary doubts or steps: visible contacts, booking without a phone call, doctors with verifiable facts, services in plain language, a full mobile version, careful handling of health data and an admin reception can manage on its own. Design matters, but it’s the wrapping around all of this.

If you’d like to go through your clinic website against this list or plan a new one, write to us, and we’ll work out together where to start.