Travel services (non-healthcare) · 2026
A page for every service, and an enquiry button that follows you
Not a clinic, and not a client either. A sample built to test whether the method holds outside healthcare: a page for every service, named after what people search, and an enquiry button that follows you down all of them.
Divyam Tours and Taxi Services · A sample business, written as Varanasi
A sample site. The company and every number in it are invented.
- Pages, taxi, airport, sightseeing
- One per service
- Pages, taxi, airport, sightseeing
- Found by, not the business name
- Service searches
- Found by, not the business name
- Enquiry, never more than one tap away
- On every page
- Enquiry, never more than one tap away
- Languages, both spoken by the customers
- EN + HI
- Languages, both spoken by the customers
Before the build
Does any of this work outside a clinic?
A studio that only builds for healthcare should be able to say why, and "we have only ever done healthcare" is not an answer. So this is the method taken somewhere else entirely: a local operator competing with national booking sites, which cannot win on spend and has to win by being the specific answer to a specific search. The structure held. What did not transfer is the care a worried patient needs, which is the part that makes clinic work its own discipline, and the reason this remains the only non-healthcare thing on the site.
This is a sample, and it is not a clinic either.
Two things about this one, both said before anything else.
There is no Divyam Tours. The company, its fleet, its routes and every number on the site are invented, the same way they are on our dermatology and physiotherapy samples. Only Pramukh Multispeciality Dental Clinic is a real practice with a real website we built for it.
And it is not healthcare. We build for clinics only, so this sits here as the one deliberate exception: the method taken somewhere it does not belong, to see whether it survives.
Why keep a non-healthcare sample at all?
Because “we specialise in healthcare” is easy to say and worth nothing unless you can show what the specialisation actually is.
The structure transfers almost exactly. Where this site has a page for “airport transfer”, a clinic has a page for “root canal treatment”. Same discipline, same reasoning about what people type.
What does not transfer is the reader. Somebody booking a car is mildly inconvenienced; somebody searching a symptom at two in the morning is frightened, and every decision about tone, order and reassurance changes because of it. That difference is the specialisation, and it is easier to point at with a counter-example sitting next to the clinic work than without one.
What did we build, and why?
A page for every service
Taxi hire, airport transfer, local sightseeing and multi-day tours each have their own page, targeting what people genuinely type, instead of one thin page trying to rank for everything at once. It is the same reasoning behind a page per treatment on a clinic website: one page cannot answer four different questions, and search engines will not pretend it can.
Structured data from the first commit
LocalBusiness JSON-LD ships in the base layout, so every page states plainly what the business is, where it works and how to reach it. On a clinic this is the same groundwork that decides whether a search engine can describe you correctly, including in the summary it now writes above the results.
An enquiry that never disappears
A call-to-action follows the visitor down every page. Somebody ready to book should never have to scroll back up to find out how. On a clinic site that button is WhatsApp, and it matters more, because the person tapping it is often in pain.
Two languages, because the customers have two
English and Hindi, for a customer base that includes both pilgrims and foreign visitors. The same argument as Gujarati on the dental clinic: a language toggle that only translates the menu promises something it does not deliver.
What this sample does not show
The build, and nothing beyond it. There is no business behind this site, so there are no bookings, no Google listing, no ads and no results, and we will not imply otherwise by leaving the question open.
What a real engagement adds is the half you cannot see in a screenshot: the listing kept correct month after month, the reviews answered, the words that come from the practice rather than from us. The one project here with all of that is Pramukh Multispeciality Dental Clinic, and it is a clinic, which is the point.
Inside the build
Three decisions, and what they look like
Every screenshot below is the deployed sample, not a drawing of one. The note beside each is the decision it shows, and each of those decisions carries over to a real build.
The page is named after the search, not the company
Nobody types "Divyam Tours". They type "taxi in Varanasi", so that is the sentence the page leads with. The panel underneath answers the four things a visitor was going to ask anyway, namely how soon, how far, what vehicle and how to book, before they have to ask any of them. A clinic's treatment page is built exactly this way, with the symptom in place of the route.
Sorted by the question, not by the inventory
The obvious way to build a fleet page is a list of car models. Nobody chooses a car model; they know how many people and how much luggage they have. So the page sorts by that instead, and says plainly that exact models are confirmed on WhatsApp rather than promising a specific vehicle it might not have that day.
The enquiry button follows you down every page
Most visitors arrive on a phone, often mid-trip and on a weak connection. Booking is one tap from anywhere on any page, and it opens WhatsApp with the message already written so the customer only has to send it. This is the same enquiry flow we build for clinics, doing the same job for a different kind of hurry.