Medical Website Design: What a Practice Site Must Do

A practice website has a few jobs to do on a patient's phone, and none of them shows up in a gallery of attractive designs. The decision that matters is how you buy it: who owns it, what its forms may collect, and what you count once it is live.

Quick answer

Test the five jobs the site must do on a phone, listed below. Choose a build route by what you own at the end and who edits it, not by the template. Register the domain yourself. Put forms on a tool whose vendor signs a business associate agreement (BAA, the HIPAA contract for a vendor that handles patient information for you), and keep them short. Ask counsel whether HHS's accessibility rule covers you. Count call taps and finished bookings from day one.

What does a practice site have to do on a phone?

Picture a patient on a phone in a parking lot: each job should take one tap from the first screen. Try each on your own phone today.

• Call: a tap-to-call number at the top of every page.
• Book or request: a visible button to a booking tool or a short request form.
• Check insurance: a page listing the plans you accept and what to do if yours is missing.
• Location and hours: address, map link, parking and open hours, in text and not only inside an image.
• New patient forms: where to find them and how long they take.

A gallery of "best healthcare website designs" shows pictures. It cannot show whether the number is tappable, the form sends, or a screen reader can follow the page.

Which way should you build it?

I read three vendors' own pages on 2026-10-15; where a page is silent, the table says so, and the gap becomes a question to ask.

This describes pages, not a ranking. A builder gives you control and leaves you the upkeep; a template platform edits for you but, by Officite's terms, keeps the design; a custom build puts the most weight on the contract.

What should you own, and what should you get in writing?

Ownership matters the day a designer or agency leaves. Put your name beside each of these.

• The domain name, registered in an account under the practice's name and a mailbox you control.
• The hosting account, or a written statement of where the site lives and how to move it.
• The text, photos and provider bios, with a right to take them with you.
• Google Analytics and any tag manager account (the tool that loads tracking code), created under the practice's login with the designer as a user, never the reverse.
• The Google Business Profile, owned by the practice's own Google account, not by whoever set it up.

Put three sentences in the contract: you own the content and the domain, you receive every login at launch, and you can export the site on request. If a vendor will not agree to those, treat that as an answer.

What may your forms collect?

A form that asks "What brings you in?" or lists symptoms collects patient information, the thing HIPAA protects when a covered practice handles it. A short form can count too: HHS's online tracking bulletin treats an email address typed while booking an appointment as protected health information (HHS, checked 2026-10-15). So in the US, use a form tool whose vendor signs a BAA, keep the form to a name, a phone number and a time, and take the details on the phone. Even with a BAA, Wix's help page notes, you remain responsible for how you configure the site.

On tracking tags (code that tells Google, Meta or another vendor what visitors do), the same bulletin says identifiable health information collected on a covered practice's website or app generally is protected health information. In June 2024 a federal court in Texas vacated (set aside) one piece of it: that HIPAA duties arise when a tag ties a visitor's IP address to a visit to a login-free public page about a specific condition or provider (AHA v. Becerra, opinion filed 2024-06-20, checked 2026-10-15).

The court added that its order does not limit the bulletin's other guidance, which says tags on pages behind a patient login generally have access to protected health information. My own line, explained in HIPAA-conscious conversion tracking, is to send a bare event and never a name or a visit reason.

Does your website have to be accessible?

Two US rules matter. The ADA's Title III prohibits discrimination "by businesses open to the public," and the Justice Department's guidance says that extends to what they offer on the web, while leaving businesses flexibility in how they comply (ADA.gov, checked 2026-10-15).

The second is HHS's Section 504 rule of May 2024, which requires recipients of HHS federal financial assistance to make their web content and mobile apps meet WCAG 2.1 levels A and AA (WCAG is the technical accessibility standard: text contrast, screen reader labels and the like) (Federal Register, checked 2026-10-15). In a separate rule that month, HHS said Medicare Part B payments count as federal financial assistance for section 504 too, so in HHS's view a practice paid through Part B is a recipient (Federal Register, checked 2026-10-15). Ask your lawyer how that applies to you.

An interim final rule effective May 7, 2026 pushed its deadlines back a year: recipients with 15 or more employees must comply starting May 11, 2027, and those with fewer than 15 starting May 10, 2028 (Federal Register, checked 2026-10-15). It adds that the existing section 504 duty to make online services accessible still applies, and that HHS may propose changes. In Ontario, the AODA requires a business or non-profit with 50 or more employees to make its public websites meet WCAG 2.0 Level AA, except live captions and pre-recorded audio descriptions, for content posted after January 1, 2012 (Ontario, checked 2026-10-15). This is not legal advice, and I am not a lawyer.

Ask the designer to test with a keyboard alone and a free automated checker, and fix the findings before launch.

What should you count from the first day?

Set up three counts before the site goes live: call taps, booking started, and booking finished (or request form sent). GA4 key events for leads covers the event setup, and online appointment booking for doctors the booking side. I set up this counting, including for an anonymized New York medical practice: one event per action, no patient details.

Illustrative: every number below is made up for an imaginary primary care practice with two doctors, and none comes from a client. Its first month, by page:

The formulas: actions per 100 visits is (call taps + finished bookings) divided by visits, times 100. Here (121 + 32) / 2,400 is about 6.4. Finish rate is finished divided by started: 32 / 55 is about 58 percent.

By page, Contact makes 8.0 call taps per 100 visits (40 of 500) and Providers 3.0 (9 of 300). Read it this way: a patient who reaches Contact wants the phone, and a provider page that sends few people onward needs a button. The number to chase first is bookings that start and do not finish, 23 of 55 here.

How do you redesign without losing search traffic?

A rebuild can change page addresses, and a changed address with no pointer sends a patient and Google to an error. List every current address that gets visits, keep each address if the new site can, and where it cannot, map the old one to its closest new page. Google's guidance says to use server-side permanent redirects from the old addresses to the new ones, with 301 or 308 as the preferred codes (Google Search Central, checked 2026-10-15). After launch, open ten old addresses and confirm each lands on the right page.

What should you ask a designer before you sign?

• Who holds the domain, hosting and analytics logins at launch, and in whose name?
• Can I export my pages and text without paying?
• Which form tool is used, where is its vendor's BAA page, and does any form ask about symptoms?
• Which tests for accessibility will you run, and will you send me the results?
• Which old addresses will you redirect, and who checks them after launch?
• Who updates a doctor's bio or the hours, how fast, and at what price?
• Which call, booking and request events will be counting on day one?

For a dental practice, the patient path differs; see dental website design.