Telehealth Landing Pages: Which Ones Book Visits

The telehealth page that gets the most ad traffic is rarely the page that books visits. On most telehealth sites the pages that sit right before a booking are pricing, insurance, and "how it works", and the team running the ads cannot see that because their analytics either cannot join a page to a booking or cannot legally run on the site at all. Curve was built to answer this kind of question inside a BAA, and Curve Analyst now lets you ask it in plain language: which landing pages book visits, at what rate, from which source.

TL;DR

• "Top pages" ranks pages by how many people saw them. It says nothing about which pages produced a booked visit, so it rewards whatever your ads happen to point at.
• Three views tell the real story: landing page by booking rate, landing page by traffic source, and the pages that appear in a session before a booking.
• On telehealth sites, pricing, insurance, and "how it works" pages are usually where the decision gets made. Condition pages bring people in. They often do not close.
• If your booking flow lives on a separate domain and the handoff is not measured, bookings vanish from every page report and your best landing page looks like a bounce.
• Page paths on a telehealth site can name a condition. That is why this analysis has to stay inside a BAA and aggregate only, which rules out GA4.
• Curve Analyst answers landing page and booking questions from your own account data, by page and by source, and tells you when a number is empty, stale, or still syncing.

Why "top pages" is the wrong report for a telehealth site

A top pages report is a popularity contest. It ranks URLs by pageviews or sessions, and on a telehealth site the winners are predictable: the homepage, whichever condition pages your ads point at. Nobody learns anything from it, but it is the first report everyone opens because it is the first report every tool shows.

The question a practice owner actually asks is different. Which pages turned a visitor into a booked visit? That requires joining a page to a goal completion in the same session, and most reporting either cannot do the join or was never configured to. So the team reports traffic by page and bookings as a single total, and guesses at the relationship between them.

The guess is usually wrong in the same direction. Ad traffic lands on condition pages, so condition pages dominate the top pages report, so the team assumes condition pages are where bookings come from. Then they build more condition pages, send more spend to them, and wonder why bookings move less than traffic.

Entry pages are the report you wanted

The entry page (the first page of a session) is the page your ad, your search result, or your referral actually delivered someone to. Curve's web analytics report entry pages alongside top pages, bounce rate, and sources, and can join any of those pages to goal completions. A landing page report without bookings attached is a traffic report wearing a costume.

The three views that show which landing pages book visits

Three cuts of the same data, in this order.

Landing page by booking rate

For each entry page: how many sessions started there, how many ended in a booked visit, and the rate between them. Sort by rate, not by sessions. On telehealth sites it is common for a pricing page or an insurance page to have a fraction of the traffic and a much higher booking rate, because the person who searched "does telehealth take my insurance" is already trying to book. The person who searched for the condition is still trying to understand it.

Read this view with bounce rate next to it. A condition page with high traffic, high bounce, and a low booking rate is not a bad page. It is an education page being asked to do a sales page's job.

Landing page by traffic source

Now split each landing page by where the session came from: paid search, paid social, organic, referral, direct, and the UTM campaigns underneath them. The same page can book well from one source and bounce from another.

This view is where you find the expensive mismatch: the paid campaign pointed at the page with the highest traffic and the lowest booking rate for that source. It is almost always a condition page. Fixing that one destination URL is the cheapest optimization most telehealth accounts have available.

Pages that appear before a booking

The third view flips the direction. Start from sessions that ended in a booking and look backward: which pages showed up before the booking step? This is the view that vindicates pricing, insurance, and "how it works". They appear in booked sessions far more often than in sessions that leave. The decision is being made on those pages, whatever page the visitor started on.

Curve's goals and funnels view gives you the step version of this: how many people reached each stage and where they dropped, so the gap between "read pricing" and "started booking" becomes a number you can act on.

What each pattern means and what to change

Each shape below has a fix that is mostly a routing or layout change, not a redesign.

High traffic, low booking rate on condition pages

Your ads are landing people on education. Either send paid traffic to the page that books (often pricing, insurance, or "how it works", or a page that combines them for a single condition), or make the condition page do the closing work by putting the booking CTA, the price, and the insurance answer above the fold.

Pricing and insurance pages book well but get little traffic

These pages are hard to find. Link to them from every condition page, put them in the primary menu, and consider running search campaigns straight at the insurance question, since the searcher's intent already matches the page.

The booking CTA is not where people read

The pages-before-booking view tells you where attention is. If people read provider pages before booking, put the booking button next to the provider. Most telehealth sites put the booking CTA on the homepage hero and the condition page hero and nowhere else, which is the equivalent of putting the front desk in the parking lot.

Everything books at roughly the same rate

Be suspicious. Either the booking goal fires on the wrong step (a page load instead of a completed booking), or the handoff to the booking domain is broken and what you are counting is "clicked the book button", which is a different thing.

Why bookings vanish from page reports when the handoff breaks

Most telehealth sites do not book on the marketing site. The marketing site sells, then hands the visitor to a booking or intake flow, and that flow often lives on a separate domain. The moment the visitor crosses that line, they are a new session to any analytics tool that was not told the two domains are one site.

The consequences are worse than they sound. The booked visit gets recorded on a session whose entry page is the booking domain's first screen and whose source is "direct" or a referral from your own site. Your marketing site sessions, the ones with the real landing pages and the real sources, all end at the button. Every landing page now has a booking rate of zero. The pricing page that was quietly closing visits looks like a dead end.

Teams then "fix" this by counting the button click as the conversion. That survives the handoff, so it feels better, but it is not a booking. The pages that lead to a click and the pages that lead to a completed booking are not the same set. That gap is the subject of a separate piece on where telehealth intake forms leak.

Keeping the handoff measurable

The requirement is simple to state: the booking domain has to be tracked as part of the same site, under the same account, and the visitor has to be carried across the link so the booking session and the marketing session are one session. When that holds, the booking goal completes on the same visitor who entered on the pricing page from the paid search campaign, and all three views light up.

The tell is in the source report: if a large share of your booking completions arrive with a source of your own marketing domain, the handoff is broken and your landing page report is fiction.

Why this analysis has to stay inside a BAA

A page path on a telehealth site can name a condition. A URL for an anxiety program, an ED treatment, a weight management plan, or an STI test is a fact about what the visitor came looking for, and once it is attached to an identifier and a timestamp it stops being harmless web analytics. Under HIPAA, a vendor that handles that kind of data on your behalf is a business associate and needs a BAA, and the FTC has pursued health data disclosures to ad platforms on unfairness grounds.

So the landing page analysis that would answer the booking question is the same analysis many telehealth teams have been told not to run. Google does not sign a BAA for Google Analytics 4, and a GA4 landing page report on a site with condition-named URLs is a page-by-page record of health interest sitting with a vendor that has not agreed to protect it. If you have been avoiding page-level reporting for that reason, you were right to, and the fix is to change where the analysis runs, not to give up on the question. The comparison of GA4's HIPAA position and the alternatives covers the vendor side in depth.

Curve signs a BAA with every customer on every plan, events go to Curve's US-hosted infrastructure first, and Curve strips what should not leave before anything is forwarded to an ad platform. Curve Analyst runs on Claude through Amazon Bedrock inside infrastructure covered by Curve's BAA with AWS; customer data is not exported to a separate AI product and is not used to train models. And Analyst does not look up individuals and does not answer person-level questions. You get the booking rate of the insurance page for paid search. You do not get the list of people who read it. Aggregate is the only shape this report should take, and we built the tool so it cannot take another.

What to ask Curve Analyst

Analyst keeps the date range and filters of the screen you opened it from, so open it from your web analytics or goals view. Every number comes from a query against your account, and if the booking goal has no completions for a page it says so rather than estimating. These three prompts produce the three views from this article:

• Which landing pages had the highest visit booking rate this month?
• For paid traffic, which landing pages book visits and which ones bounce?
• How do the pricing and insurance pages perform versus the condition pages on bookings?

The Curve Analyst announcement covers what it can and cannot see, what Curve Analyst is explains the feature in general, and there is a longer walkthrough of diagnosing a telehealth consult funnel with Analyst if you want to go past landing pages into the intake steps.

Frequently asked questions

What is a good landing page conversion rate for telehealth?

There is no useful universal number, because specialties, insurance models, and booking flows have nothing in common. Compare your pages to each other and to their own prior period. The pricing page's booking rate for paid search this month against last month is a number you can act on. A benchmark from a blog post is not.

Should paid ads point at condition pages or at pricing and "how it works"?

Test it per source with the landing page by source view. Condition pages tend to win for people who are still learning, which is more common in organic search. Pricing, insurance, and "how it works" tend to win for people who have decided and are checking whether you fit.

Can landing page booking rate be measured if booking happens on another domain?

Yes, but only if the booking domain is tracked as part of the same site and the visitor is carried across the handoff. Without that, the booking completes on a new session with no landing page, and the report shows your marketing pages booking nothing. Fix the handoff first, then read the report.

Why does GA4 not work for this on a telehealth site?

Because Google does not sign a BAA for Google Analytics 4, and a landing page report on a site whose URLs name conditions is health data by any reasonable reading. The analysis needs to run inside a BAA, on infrastructure that strips what should not leave before anything reaches an ad platform.

Does Curve Analyst show which patients booked from which page?

No. Analyst does not look up individuals or answer person-level questions. It reports booking rates by page, source, and period, in aggregate. That is a limit we chose on purpose.

If your landing page report cannot tell you which pages book visits, or cannot be run on your site at all, book a Curve demo and ask Analyst the three questions above against your own data.