A New Look Does Not Fix a Slow, Unreadable Site
Most practice website projects are sold as a redesign. What actually needs fixing is usually three specific things: load speed, whether someone can book from a phone in under a minute, and whether the page can legally be used by a patient with a disability. A new visual theme touches none of them by itself.
We build the site around those three problems first, then design it — not the other way around.
Free. No card. About 40 seconds.
A Redesign and a Rebuild Are Not the Same Project
Most agencies sell a website project as a look. New colors, a new template, updated photography. That work is real, but it does not change how fast the page loads, how many taps a patient needs to book, or whether the site can be read by someone using a screen reader.
Those three things are what a redesign is usually blamed for not fixing, because they were never part of the brief.
| What it is | What that means | Does a visual redesign fix it? |
|---|---|---|
| A visual refresh | New colors, new photography, a template swap | No. Looks different, measures the same. |
| Page speed | How long a patient waits before the page is usable, measured by Google's Core Web Vitals | Yes, if the underlying code changes, not just the theme on top of it. |
| The booking path | How many taps it takes to request an appointment on a phone | Yes, and it is usually the single most valuable fix on the whole site. |
| Accessibility | Whether a patient using a screen reader or keyboard-only navigation can actually use the site | Only if it is built in, not layered on after launch. |
| AI and search readability | Whether the code structure lets a crawler or an AI system parse who you are and what you treat | Only if the technical foundation is rebuilt, not just the layout. |
Accessibility Is a Legal Question, Not a Style Choice
Most web design agencies treat accessibility as a nice-to-have. For a healthcare practice, it is closer to a compliance requirement, and it shows up in real litigation. Four situations come up constantly.
A screen reader cannot use your intake form
The Americans with Disabilities Act's Title III has been applied to business websites, including medical practice sites, in a large and growing volume of real lawsuits. WCAG 2.1 Level AA is the standard most often cited in the settlements. Most template-based practice sites do not meet it.
A form asks for symptoms before anyone has agreed to anything
A "tell us what's bothering you" field on a public contact form collects health information before any treatment relationship, consent, or secure handling exists. That data usually lands in a plain inbox, not a system built for it.
The site cannot be operated by keyboard alone
Booking a visit should not require a mouse. A patient tabbing through the page should reach every link and form field in a visible, logical order — most page builders do not guarantee this by default.
Color is the only way information is shown
A red outline on a form field means nothing to a patient who cannot see red. Every state needs a second signal — text, an icon, a pattern — not color alone.
This is not legal advice. Whether your current site creates real exposure is a question for your own counsel. We build to WCAG 2.1 AA as a working standard because it is the one most consistently referenced in actual settlements, not because any single law names it for every practice.
By What’s Actually Broken, Not by Age
A site that measurably fails
Slow on mobile, a booking path with more than a few steps, or genuinely unusable with a keyboard or screen reader. These are checkable, not opinions, and each one costs patients directly.
A site that just looks dated
If the site is fast, the booking path is short, and it works for every patient, an old-looking design is a preference, not a problem. A visual refresh can be scoped on its own, separately from a rebuild.
We check the first list before we ever discuss the second one.
What Actually Happens, in Order
The steps below run in this order for every build. Design starts after the foundation is fixed, not before.
Audit speed, booking path, and accessibility
We measure your current site against Core Web Vitals, count the steps to request an appointment on a phone, and run it against WCAG 2.1 AA. Three scores, not an opinion.
Fix the technical foundation first
Page structure, schema markup, and load performance get rebuilt before any visual design starts. A fast page with the wrong layout is still a fast page. A beautiful page that fails Core Web Vitals is not.
Design the booking path deliberately
The shortest real path from landing on the page to a submitted appointment request, tested on an actual phone, not a desktop preview.
Build in accessibility, not layer it on after
Keyboard navigation, screen-reader labels, and color-independent states are part of the build from the first template, not a fix applied after launch.
Launch, then measure again
Same three scores, checked again after launch. If a number did not move, we say so.
What We Will Not Do
Naming what we refuse is the cheapest real credibility a new agency can buy.
We do not collect health information through a contact form.
A form field is not a secure system. If your practice needs patients to submit clinical details online, that belongs in a system built and configured for it, not a website contact form we design.
We do not ship a site that fails Core Web Vitals to hit a launch date.
A slow launch is not a finished launch. If the choice is ship late or ship slow, we tell you before either happens.
We do not treat accessibility as a post-launch fix.
Bolting a screen-reader patch onto a finished site after a complaint is worse and more expensive than building it in from the first template.
The Booking Path Differs by Buyer, Not Just by Service
Dental
An emergency patient in pain needs a phone number and an office address in two taps, nothing more. An elective patient comparing an Invisalign timeline wants pricing context and a longer read before they book. The same homepage cannot serve both without a deliberate split in the booking path.
See our dental marketing approachDermatology
A medical dermatology visit is often insurance-driven and time-sensitive — the booking path should be short. A cosmetic visit involves more comparison and higher spend, and the patient expects to see pricing ranges and real detail before requesting a consultation. We build both paths into the same site, not one path for both patients.
See our dermatology marketing approachProject Work, Not a Monthly Tier
The monthly retainer tiers on this site cover ongoing work: AI visibility, SEO, reputation, and social media. A website build is a fixed scope with a defined end, not an ongoing monthly service, so it is quoted separately.
If you are already on a monthly tier, a website build sits alongside it. It does not replace it, and it is not included in it.
The exact price depends on how much of the current site can be kept, how many page templates the practice needs, and how much of the accessibility and speed work above the current site already passes.Full tier pricing for the ongoing services is on our pricing page.
We Turn Down More Practices Than We Take On
Your current site already passes on speed, booking, and accessibility
You do not need this. A visual refresh alone is a smaller, separate project.
You want the cheapest possible build
There are template sites for a few hundred dollars. They will not be built to WCAG 2.1 AA or pass Core Web Vitals reliably.
You need it live next week
A real audit, rebuild, and accessibility pass takes real weeks, not days.
You want us to guarantee a specific patient-volume increase from the redesign alone
A website removes friction. It does not manufacture demand — that is what the AI visibility and SEO work on this site is for.
More on who we are and how we work is on our about page.
Before You Ask
Can you keep our current site and just fix the problems?
Sometimes. If the underlying code can meet Core Web Vitals and WCAG 2.1 AA with real work, we keep it. Most page-builder templates cannot, and a rebuild is the honest answer at that point.
Do you guarantee an accessibility lawsuit will never happen?
No one can guarantee that. We build to WCAG 2.1 AA as a working standard and can show you the audit. Whether that fully protects your specific practice is a question for your own counsel.
Will this help us show up in AI answers like the AI visibility page describes?
A correct technical foundation is necessary for that, but not sufficient by itself. The entity consistency, structured data, and citation-building work is covered on our AI visibility page, not repeated here.
How long does a rebuild take?
It depends on how many page templates the practice needs and how much of the current site can be kept. We give a specific timeline after the audit, not before it.
What if we already have a marketing agency doing SEO?
We can build the site on its own without touching your existing SEO or ad accounts. Tell us what's already in place before the audit so nothing gets duplicated or undone.
What happens after launch?
We re-run the same speed, booking-path, and accessibility checks and show you the before-and-after numbers. Ongoing monitoring is a separate, smaller engagement, not automatic.
See What AI Says About Your Practice
We send three real patient questions to a live AI answer engine and show you the exact answers it gives back — who gets named, and who does not. No call required, and the report is yours either way.
It also tells you whether a slow or hard-to-book website is actually costing you patients, or whether the gap is somewhere else entirely.
Free. No card. About 40 seconds.
See the technical side of visibility on our AI search visibility page, or the foundation it depends on at healthcare SEO.