Medical practice website design

A practice website has one job: turn someone already looking for your kind of care into a booked appointment. To do that it must answer four questions fast (do you take my insurance, where are you, when are you open, who will I see), put booking or a call one tap away, load quickly on a phone, work for people using a screen reader or keyboard, handle health information with HIPAA in mind, and line up with the Google Business Profile that actually puts you in local results.

That is the whole list. Most of what agencies sell on top of it either does not move appointments or slows the site down. Below is the medical website checklist we work through on a review or rebuild, with the rules and numbers behind each item. It applies to web design for medical practices of any size, from a solo clinic to a group with several locations.

What patients check before they call

Patients arriving from a search work through a short list, and leave when a site does not answer it:

1. Insurance. Which plans you accept, and whether you are in network.
2. Location and hours. A map, parking, the entrance, today’s hours.
3. The specific service. Someone searching “vestibular therapy” wants a page about vestibular therapy, not a bullet under Services.
4. Who they will see. Name, photo, credentials, years in practice, languages.
5. How to book. Online booking if you have it, a tappable number if not.
6. New patient logistics. What to bring, what to fill in, how long the first visit takes, whether telehealth is an option.

Put insurance, location and the phone number above the fold on the home page. Give every service its own page, and every provider their own page written as prose rather than a CV dump, because that bio is often the last thing read before someone chooses between you and the practice down the road.

Speed and mobile: the numbers Google measures

Google publishes three metrics, the Core Web Vitals, with explicit thresholds. A page passes when it hits all three at the 75th percentile of real visits, measured separately for mobile and desktop.

Google says plainly that Core Web Vitals are used by its ranking systems, while warning that a perfect score guarantees nothing. Treat the thresholds as a floor.

The causes are boringly consistent. Rotating hero sliders load several large images before anything is readable. Page builders ship enormous CSS and JavaScript to render a layout plain HTML would handle. Photos go up at camera resolution, so a 4 MB JPEG becomes the LCP element. Then twenty plugins and five tracking scripts pile onto the main thread and INP goes past 200 ms on the first tap.

Fixes, in the order that usually pays: one static hero image and a clear heading instead of the slider; every photo compressed, resized and given width and height so nothing shifts; plugins and trackers nobody reads reports from removed; fonts hosted locally in two weights. Then test on a mid-range Android phone on mobile data.

Accessibility: WCAG, HHS and the ADA

Two separate things apply here, and vendors routinely blur them.

The HHS Section 504 rule

In May 2024, HHS finalized a rule adding web and mobile accessibility requirements to its Section 504 regulations at 45 CFR part 84. Recipients of federal financial assistance from HHS must make the web content and mobile apps they provide meet the Level A and Level AA success criteria of WCAG 2.1. There is an exception where compliance would fundamentally alter a program or impose an undue burden, and you must be able to demonstrate it.

The dates moved. The original deadlines were May 11, 2026 for recipients with fifteen or more employees and May 10, 2027 for smaller ones. On May 11, 2026, HHS published an interim final rule extending both by one year, to May 11, 2027 and May 10, 2028. HHS said it may propose changes to the substantive requirements in that window, and that if it does not, it fully anticipates implementing the rule at the new deadline. The standard is unchanged: you have one extra year, not a reprieve.

Whether you are a recipient depends on where your federal money comes from. Medicaid and CHIP participation generally puts a provider inside Section 504’s reach; a practice whose only federal payments are Medicare fee-for-service has historically been treated differently. Check with your health care attorney.

ADA Title III

Independent of any deadline, the Justice Department’s March 2022 guidance says the ADA applies to the services a public accommodation offers on the web, and its list of covered businesses includes hospitals and medical offices. DOJ has no regulation setting detailed technical standards for Title III sites; it points to WCAG and Section 508. So there is no date to wait for and no safe harbor, which is why WCAG 2.1 AA is the sensible build target for every practice, whatever your payer mix.

In practice, AA conformance means color contrast, real text instead of text baked into images, visible focus outlines, labeled form fields, descriptive alt text, captions on video, and keyboard operation of every menu and booking widget. Overlay widgets promising instant compliance do not fix the underlying markup.

HIPAA on a practice website

Nothing in HIPAA stops you having a good website. It governs what happens to health information once a patient hands it over.

Forms. A contact form that asks “how can we help?” will collect health information, because patients describe their symptoms in it. Once that information identifies the person and relates to their care, it is PHI. Do not let submissions land in a shared inbox or sit in a plugin’s database table on shared hosting. Send them somewhere access-controlled, keep retention short, and serve the whole site over HTTPS.

Business associate agreements. Any vendor that creates, receives, maintains or transmits PHI on your behalf is a business associate, and HIPAA generally requires a written contract with them: your form handler, your booking platform, your host if PHI sits on its servers, and any agency staff who can read submissions. Ask for the BAA before you sign. Our HIPAA compliance and BAA page sets out how we handle it.

Tracking pixels. This is where practices get caught. OCR’s bulletin on online tracking technologies says cookies, pixels, session-replay scripts and fingerprinting must not disclose PHI to vendors outside what the Privacy Rule permits, and is explicit that a line in your privacy policy does not authorize the disclosure and a cookie banner is not a HIPAA authorization. On user-authenticated pages, such as a patient portal or a telehealth platform, trackers generally can reach PHI and must be configured and safeguarded accordingly, including Security Rule measures such as encryption.

A June 2024 ruling narrowed one part of that. In American Hospital Association v. Becerra, the U.S. District Court for the Northern District of Texas declared unlawful and vacated the portion of the bulletin treating a visitor’s IP address combined with a visit to an unauthenticated public page about specific conditions or providers as triggering HIPAA. The court did not strike the bulletin as a whole, and HHS says it is evaluating next steps. That status note sits atop the OCR page today.

In short: the ruling removed OCR’s broadest theory about anonymous visits to public pages. It did not touch portals, login and registration pages, booking or symptom checkers, where a patient hands over identifiable health information. Keep Meta Pixel, Google Ads tags and session-replay scripts off those pages.

Local search and Google Business Profile

For a practice with a waiting room, the Business Profile usually outweighs the website for phone calls. Google ranks local results on three things: relevance, distance and prominence, and says businesses with complete, accurate information are more likely to show up. There is no way to pay for a better local ranking.

What that means week to week:

• Use your real-world practice name. Stuffing keywords into it is not permitted.
• Pick the most specific primary category and as few as possible. Categories answer “this business is a”, not “this business has a”.
• Keep regular and holiday hours current, with a number that reaches that location.
• Keep name, address and phone identical on your site, directory listings and payer panel profiles. Mismatched suite numbers and old tracking numbers are the most common reason a practice cannot be found.

On reviews, ask every patient and gate nothing. Google treats offering incentives such as free or discounted goods or services in exchange for posting reviews, changing them or removing negative ones as fake and misleading content, strictly prohibited. Asking only the patients you expect to be happy is the other half of that problem.

On the site itself, add structured data. Google supports LocalBusiness markup and says to use the most specific subtype available, with name and address required and hours, phone, URL and coordinates recommended. Mark up each location as its own LocalBusiness, on that location’s page.

The pages a small practice site needs

Twelve to twenty pages covers most single-location practices, and the shape barely changes between an internal medicine office, an NP-led clinic, a physical therapy practice and a behavioral health group.

• Home. Insurance, location, hours, phone, booking, top three services.
• One page per service, named the way patients search, covering what the visit involves and the self-pay cost if you publish it.
• One page per provider. Photo, credentials, board certification, languages, what they treat.
• Insurance and fees. Plans accepted, self-pay rates, what happens out of network.
• Locations. Map, parking, accessibility of the building itself, hours per site.
• New patients. What to bring, arrival time, what the first visit covers.
• Patient forms. Downloadable or, better, an intake form that submits securely.
• Telehealth. What it covers, which platform, how to join.
• Contact. Phone, fax, address, form, and who answers it.
• Privacy. Your notice of privacy practices and your website privacy policy are two different documents.

Keep each service page to one idea. A page listing eight services competes for nothing.

Medical website launch checklist

Before you hire anyone, get written answers to these:

1. Who owns the domain, the hosting account and the site files, and will they be in the practice’s name?
2. Where is it hosted, who takes backups, and how fast can you restore?
3. Who applies security updates to the platform and plugins, and how often?
4. Will you sign a BAA? If the answer is “our forms do not collect PHI”, ask what happens when a patient types their symptoms into the message box.
5. How do you test accessibility, with what tools, and will you hand over the report?
6. What speed targets are you committing to, measured on mobile?
7. How will old URLs be redirected so our search traffic carries over?
8. Can we speak to a practice you currently look after?

A vendor who does this work has clients willing to take that call. We put prospective clients in touch with a current one, with their permission.

What Reliable Care does

We design, write and build practice websites mobile-first, then keep them running: hosting, security updates and backups, online booking and intake forms, Google Business Profile and local search, support after launch. Builds are HIPAA-aware and we sign a BAA where forms carry patient information. We also build patient portals, secure intake and dashboards for collections and A/R, and run social media with monthly reporting. Details are on the web design, software and social media page.

Two things often sit behind a website problem rather than in it. If the phone rings and nobody answers, a medical virtual assistant books more appointments than a redesign will. If patients are booking and the money is not arriving, that is a workflow question for practice management consulting, usually starting with eligibility and benefits verification before the visit rather than after.

We do not quote a website price before looking. Send the link and we will tell you what we would change and in what order.