A clinic spends money on booking software, then wonders why nobody finds the clinic online. The answer is usually that the only page describing what they offer is a single-page app that serves an empty <div id="root"> and renders the service list after JavaScript runs.
Google can run JavaScript. What it often does not do is come back, render, and re-index — particularly for small sites with limited crawl budget. So the version of your page that gets indexed is the one in the initial HTML response. If the service list is not in that response, the service list is not indexed.
Split the page by intent
The mistake is treating "the booking page" as one thing. It is at least four, with different rendering requirements:
Service index — the list of services, prices, durations, who offers them. Static. Generate at build time, one page per service. This is the page that should rank.
Location and provider pages — address, hours, staff bios, areas served. Also static, and also worth its own URL.
Availability — the calendar and open slots. Server-render the first screen of availability if you can, but this is genuinely dynamic; it is fine for the picker to be client-side as long as the surrounding content is not.
The booking form itself — client-only. Nobody needs this indexed.
Rendering all four as one client-side route is what costs you the ranking.
What must be in the initial HTML
For a service page, the things a customer actually searches for:
- Service name as an
<h1>, not a<div>styled to look like one - Price and duration in real text — not behind a hover or a modal
- Who provides it, and where
- Cancellation and rescheduling terms
- Three to five questions people ask, in a FAQ
That last one does disproportionate work. "How long is a dental cleaning?", "Can I cancel my salon appointment?" — these are the queries that bring people in, and a FAQ section answers them in the exact shape the search engine wants.
Structured data, but only what is true
JSON-LD is worth adding, and it is worth being careful with:
-
Servicewithprovider,areaServed, andoffers(price, currencyINR) -
LocalBusinessor a subtype (MedicalBusiness,HairSalon,BeautySalon) with address, geo, openingHours -
FAQPagematching the visible FAQ — do not mark up questions that are not on the page -
Personfor staff, if you list them
Avoid AggregateRating unless you genuinely display reviews on the page. Markup that doesn't match visible content is a manual-action risk, and recovering from one costs far more than the snippet enhancement was worth.
Pagination beats infinite scroll
If you have 40 services, do not render them in one endlessly scrolling container. Give Google crawlable pagination — /services/page/2 with real links — or split by category with an index page per category.
Infinite scroll hides inventory. A salon with a bridal-mehendi page that only appears after four scrolls has a bridal-mehendi page that does not rank.
Availability pages and crawl budget
Slot pages are a trap. ?date=2026-10-12 creates an effectively infinite URL space, and search engines will correctly decide to stop crawling it.
Keep availability behind a parameter or a client fetch, and canonicalise the service page to itself. If you want a shareable "next available" link, generate a small number of genuinely useful ones — the next three open slots — rather than every possible date.
Measuring it honestly
Two checks catch most problems:
-
Fetch the page with JavaScript disabled —
curlit, or use the browser with JS off. If the service names, prices and FAQ are missing, that is what a search engine sees first. - URL Inspection in Search Console — "View crawled page" shows the actual HTML Google retrieved. Compare it to what you see. If the crawled version is a script tag, you have your answer.
Then check the Coverage report for the difference between "submitted and indexed" and "discovered — currently not indexed". A large gap there, on a small site, usually means thin or unrendered content.
If the booking system is not yours
Most clinics buy booking software and embed it. That is exactly when this breaks: the marketing site is static, but every service, price and staff member lives inside a third-party widget that renders nothing to a crawler.
The fix is to publish the service catalogue on your own domain as real HTML — generated from the booking system's data if it has an API — and let the widget handle only the final selection step.
SWIQ exposes services, staff and availability as data, so a clinic's own pages can carry real server-rendered content while the booking flow stays interactive — see it on a free demo. Our clinic booking system guide covers multi-provider setups, and the salon booking system guide walks through salon-specific service catalogues.
Top comments (0)