Addiction Treatment Website Development: What Actually Gets Built

Ask three agencies what "website development" means for a treatment center and you will get three different proposals. One quotes a theme and some pages. One quotes a custom build with integrations you have never heard of. One sends a mood board. None of them tells you what the finished thing will contain, which is the only question that lets you compare them.

So we went and looked. On 27 September 2026 we read the code, the server headers and the XML sitemaps of the drug and alcohol rehab providers ranking in 12 large US metros, and wrote down what their developers had actually built. This article walks through what we found, layer by layer, and ends with a scope sheet you can hand to any developer, us included. We build treatment center websites, so read the section about us with that in mind. The census numbers are the same whoever you hire.

What gets built, in one paragraph

A treatment center website build has six layers: a page inventory, a platform and host, security headers, structured data, the call and form plumbing, and speed and accessibility work. The page inventory is the largest, and it is bigger than most owners expect. The median ranking rehab site in our sample lists 266 URLs in its sitemap, with pages for each level of care, insurance, and the substances it treats. Most sites run WordPress behind Cloudflare. Few send the basic security headers: 13 of 45 homepages sent HSTS and 4 sent a Content-Security-Policy. A good development contract names every layer, who owns each account, and what "done" means for each one.

The six layers of a treatment center build

Every build we looked at, from a 7-page site to one listing 1,414 URLs, is made of the same six parts. They differ in how much care each part received. Here is the stack, from the part a family reads to the part only an auditor notices.

A design proposal usually covers layer 1 and parts of layer 5. A development proposal should cover all six. When a quote is much cheaper than the others, the missing money is usually in layers 2, 3, 4 and 6, because those are the ones you cannot see in a screenshot of the homepage.

How we looked under the hood

We searched "drug and alcohol rehab" plus the city name in Atlanta, Austin, Boston, Chicago, Denver, Houston, Minneapolis, Nashville, Philadelphia, Phoenix, San Diego and Seattle. From the results we dropped directory listings, hospital systems, government sites, one national charity's program page and our own client, which left 56 treatment providers. Ten of them blocked automated requests and one timed out, so we could read 45 homepages. For each one we saved the delivered HTML and the final response headers, then fetched the XML sitemap the site publishes for search engines. Forty-three had a sitemap on their own domain.

Everything below comes from what those servers sent to an ordinary browser request. We did not log in, submit forms or run anything against the sites. Where a count relied on pattern matching, such as reading page types out of URLs, we checked samples by hand. The limits are real: a sitemap lists the pages a site asks Google to index, not every page it has, and a homepage is one page, not the whole site. Read them as a view of the field you compete in, not an audit of any single center.

Layer one: the page inventory is the real project

Pages are most of the work, and ranking rehab sites carry far more of them than a brochure site. The median sitemap in our sample listed 266 URLs. The smallest listed 7 and the largest 1,414. Only 7 of the 43 listed fewer than 100.

What those pages are matters more than how many there are. We sorted every sitemap URL by what its address names. Almost every site builds out its levels of care as separate pages: 38 of the 43 have detox pages, 38 have residential or inpatient pages, 39 have outpatient pages, 32 have intensive outpatient pages and 26 have partial hospitalization pages. Insurance pages appear on 39 sites, and 19 sites have at least five of them. Forty sites name a specific drug or alcohol in at least one URL, and the median site has 45 such addresses, a mix of treatment pages and articles answering the questions families type into search.

This is the part of a development quote to read most closely. "A 10-page website" and "a site structured to compete with these" are different projects, and the difference is not design. It is the information architecture: which program, insurance and substance pages exist, how they link to each other, and how new ones get added without a developer each time. Ask for the page list in the proposal, not after kickoff.

The trap in generated pages

One site in the sample listed 316 insurance URLs spread across 41 insurers. Reading them shows how: each insurer has a page, and under it sit pages pairing that insurer with a substance or a program, so a single insurer carries as many as 44 addresses. Another site had a separate alcohol and drug rehab page for dozens of cities and states. Developers build this on purpose, because a template and a spreadsheet can produce hundreds of pages very quickly.

Google has a name for the risky version. Its spam policies define scaled content abuse as many pages generated mainly to manipulate rankings rather than help people, and list pages that make little sense to a reader but contain search keywords as one example.

We are not saying the 316-page site breaks the policy. We did not read every page, and an insurer page that answers real questions about that insurer's coverage for a specific program can be useful. The development question is whether each generated page says something the parent page does not. If the only difference between two pages is the insurer's name, one page with a clear list serves the family better, and it carries less risk.

Layer two: the platform, and who patches it

WordPress won by a landslide, as it does on the wider web. Thirty-nine of the 45 homepages we read run on WordPress, one runs on Squarespace, and five run on other content systems or custom code. In HTTP Archive's 2025 Web Almanac, WordPress accounts for 64.3% of mobile CMS usage, and Elementor is the most common page builder on WordPress at 43% of mobile sites.

The platform choice is less important than the maintenance plan that comes with it, because WordPress's weak point is its add-ons. Patchstack's annual WordPress security report, updated in February 2026, puts the number of newly found WordPress vulnerabilities for 2025 at 11,334, up 42% on 2024. Plugins accounted for 91% of them, themes for 9%, and WordPress core for just 6 low-priority issues. Patchstack also found that 46% of vulnerabilities had no fix from the developer by the time they were disclosed, and that heavily exploited ones reached mass exploitation in a median of 5 hours.

Two practical conclusions follow. Every plugin in a proposal is a line of future maintenance, so ask the developer to list them and justify each one. And "we will keep it updated" is not a plan. A plan says who applies updates, how often, what happens when a plugin is abandoned, and what the monthly cost is.

In front of the platform, 31 of the 45 homepages answered through Cloudflare, identifiable from the cf-ray header on the response. A content delivery network like that caches pages close to visitors and filters some attacks, and it is now the default rather than the upgrade. It is not a substitute for patching, though. In Patchstack's large-scale test of popular web hosts, only 26% of vulnerability attacks were blocked by the hosts' own defenses.

Layer three: the security headers most sites skip

Security headers are short instructions a server sends with every page, telling the browser how to handle it, and most rehab sites in the sample do not send them. They carry no license fee, and adding them is server configuration rather than a rebuild, though each needs testing so it does not break a script the site relies on. They are one of the clearest signs of whether anyone touched the server after the theme was installed.

The one to insist on is Strict-Transport-Security, known as HSTS. MDN's reference explains that its max-age value tells the browser how many seconds to remember that the site must only be loaded over HTTPS. Only 13 of the 45 homepages sent it. X-Content-Type-Options, which stops browsers guessing file types, appeared on 12. A Content-Security-Policy, which limits which scripts a page may run, appeared on 4.

That last one deserves a note for treatment centers. A page with an inquiry form is exactly where you want control over which outside scripts run. A strict Content-Security-Policy is harder to set up on a site that loads tag managers and call tracking, which is why so few have one, but a developer should at least tell you whether it is in scope and why not if it is left out. Our piece on the anatomy of an admissions page covers what those tracking scripts can see.

Layer four: structured data, and five blocks that fail to parse

Structured data is the machine-readable summary of who you are, and nearly every ranking rehab site ships some. Forty-three of the 45 homepages carried JSON-LD, the format Google's structured data guide recommends in most cases, adding that every format is fine as long as the markup is valid and properly implemented.

What those blocks say is thinner than the count suggests. Much of it matches what SEO plugins write by default: 35 homepages describe an Organization and 35 describe a WebSite. Only 21 describe the center as a medical organization or clinic, and 20 include a street address. That gap matters for a local, licensed provider. A generic organization record does not tell a search engine or an AI assistant that you are a treatment facility at a specific address.

Then there is validity. Five of the 43 sites with JSON-LD shipped at least one block that fails a standard JSON parser. The causes were ordinary mistakes: a second script tag pasted inside the first, a property typed after the closing brace, a line break typed inside a quoted description, and comments written as if the block were JavaScript. Each looks fine in the page editor and is invisible to visitors. Google's guide makes validity the condition, so ask your developer to run every template through a validator before launch and to show you the result.

Layer five: calls, forms and what they connect to

This is the layer that turns a visit into an admission, and it is where treatment center development differs most from ordinary web work. Forty-four of the 45 homepages had a tap-to-call link, and 33 had a form in the homepage code. Those are the visible parts. The development work is behind them.

• Call tracking. In our census of rehab homepages the day before, more than half loaded CallTrackingMetrics, CallRail or Invoca, which swap the phone number per visitor to credit the right ad or search. A developer has to make sure the swapped number still works in the tap-to-call link, the schema and the footer.
• The form's destination. An inquiry form usually lands in email, a CRM or the admissions system. Each company the submission passes through needs a signed business associate agreement, and our comparison of builders for treatment centers shows how differently vendors handle that.
• Insurance verification. A verification form that writes plan details into your intake software is a small integration project with its own testing, not a contact form with extra fields. Budget for it separately.
• Paid search readiness. Google Ads restricts recovery-oriented addiction services to advertisers it has approved, in six countries including the US, as its addiction services policy sets out. In the US that means LegitScript certification first, and LegitScript reviews the website itself. Our guide to what LegitScript reviews walks through it page by page.

Ask the developer to draw the path one inquiry takes, from the button to the person who calls the family back, and to name every system on it. If they cannot, the plumbing has not been designed yet.

Layer six: speed and accessibility you can defend

The basics are mostly in place across the sample, and the gaps are the ones you would expect from sites nobody has audited. Every one of the 45 homepages declared a page language and a mobile viewport. Thirty-six used native lazy loading for images, and 26 referenced modern WebP or AVIF files. The median homepage delivered about 228 KB of HTML and referenced 22 script files, before counting the scripts those scripts load.

The failures are small and specific. Thirteen of the 45 homepages had at least one image with no alt attribute at all, ranging from 1 image to 32. Eight had more than one top-level heading, one had sixteen. And one homepage carried a robots meta tag telling search engines not to index it or follow its links, a setting that usually belongs to a staging copy and is easy to carry over to the live site by accident.

For scale, WebAIM's 2026 scan of a million home pages found missing alternative text on 53.1% of them and a missing document language on 13.5%. The rehab sites in our sample did better on both counts, though our check read raw HTML rather than running WebAIM's tool, so the numbers are not directly comparable.

Two targets belong in the contract. For speed, Google's Core Web Vitals ask for the largest content to appear within 2.5 seconds and for interactions to respond in 200 milliseconds or less, with at least three in four real page loads meeting both, which Google calls the 75th percentile. For accessibility, WCAG 2.1 AA is the standard HHS's section 504 rule applies to websites of providers that receive its funding, and a May 2026 interim final rule pushed compliance to 11 May 2027 for organizations employing 15 people or more, and to 10 May 2028 for the rest. Many treatment centers take Medicaid, so that date belongs on the project plan.

The scope sheet: what to put in writing

Take this table into every proposal meeting. The middle column is the question to ask. The right column is what we found on sites already ranking, so you know what normal looks like.

If a proposal is silent on a row, that is not a sign the work is included. It is usually a sign it has not been thought about, and it will come back later as a change request.

How long it takes, and what drives the price

Scope drives both. For a single landing page, we commit to going live 14 business days after your materials reach us. A site with a few hundred program, insurance and article pages takes considerably longer, and most of that time goes to writing and review rather than code. Our breakdown of how long a website build takes goes through where the calendar goes, and the article on what a treatment center website costs covers the price ranges.

Plan for content to be the slow part: clinical review of program pages, a medical director signing off on substance pages, and photos of the facility that nobody has taken yet. Ask any developer how their schedule handles waiting on you. The honest ones build in feedback windows and say what happens when they are missed.

Where KhanWork fits, and who should look elsewhere

We are one of many teams that do this work, and our prices sit in public on our pricing page. There are three monthly plans with no minimum term, and you can pause or cancel any of them whenever you like. Foundation, at $1,000 a month, refreshes your brand, has one landing page live 14 business days after your content and assets land, then ships one new page a month. Growth, at $2,500 a month, covers the whole site, with as many requests as you want queued and one in progress at any moment. Scale, at $5,000 a month, runs two requests at once for groups with several locations. Your hosting account is yours and we do not bill for it, and everything we build belongs to you.

Our studio has shipped more than 200 projects, including websites for 5 treatment centers. After our redesign, Cornerstone Healing Center recorded 20% more website conversions. That is their number, not a forecast of yours. More on how we approach recovery websites is on our addiction treatment and recovery page.

Look elsewhere if you need a developer to build custom software inside your EHR, if you want a one-time project with no ongoing relationship, or if your program is small enough that a builder and a phone number would do. For that last group, the builder comparison linked above is the better next read.

Before launch, count the keys

Here is one thing to do this week, whoever builds your site. Make a list of every account the website depends on and write the owner's name next to each one. Domain registrar. DNS and Cloudflare. Hosting. The content system's admin login. Google Search Console and Analytics. The call tracking account. The form service and the agreement it signed. The code repository, if there is one.

Every line should say your organization, with the developer invited as a user. Any line that says an agency, a freelancer or "not sure" is a key someone else holds to your admissions channel. Fix those before you start a new build, not during one. If you want someone outside your team to look at the first page most visitors reach, our free funnel review does exactly that, and the key list is yours to keep either way.