DEV Community: DigeeSell Team

Building a Clinic Website for the UAE: A Developer's Checklist

DigeeSell Team — Wed, 28 Oct 2026 12:31:14 +0000

Healthcare websites look simple from the outside: a few service pages, a doctor list, a contact form. Building one that patients in the UAE actually use, and that search engines understand, takes a few deliberate decisions. This checklist comes from the patterns we see again and again on clinic and hospital sites, and it's written for developers rather than marketers.

1. Model the domain before you design pages

Clinics have a natural data model: locations → departments → services → practitioners. Build that into your CMS or database as related entities rather than free-text pages. It pays off quickly:

Doctor profiles can list the services and branches they cover automatically.
Service pages can show "available at these branches" without manual upkeep.
You can generate structured data from the same source of truth.

When content editors later add a new doctor, the right pages update without a developer touching templates.

2. Structured data: describe the clinic, not the marketing

Schema.org has healthcare types that help search engines understand what a page is about. A minimal example for a single-branch clinic:

{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "name": "Example Clinic",
  "url": "https://example.ae/",
  "telephone": "+971-4-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Office 000, Example Tower",
    "addressLocality": "Dubai",
    "addressCountry": "AE"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],
    "opens": "09:00",
    "closes": "21:00"
  }],
  "medicalSpecialty": "Dentistry"
}

Guidelines that keep it honest:

Generate one MedicalClinic (or Hospital) block per location page, not a single block copied site-wide.
Use Physician on doctor profiles, linking back to the clinic with memberOf or worksFor.
Do not mark up reviews or ratings that are not visible on the page. Self-serving review markup can lead to a manual action.
Validate with Google's Rich Results Test and the Schema Markup Validator before release.

3. Arabic is a layout, not a translation toggle

For UAE audiences, a bilingual site is the norm. Some practical points:

Serve Arabic on its own URLs (/ar/...) with lang="ar" and dir="rtl" on the <html> element.
Use CSS logical properties (margin-inline-start, padding-inline-end) so one stylesheet works in both directions.
Mirror icons that show direction (arrows, "next" chevrons), but leave logos, phone numbers and media controls unmirrored.
Add hreflang pairs between English and Arabic versions, plus an x-default.
Load an Arabic web font subset only on Arabic pages to keep weight down.

4. Performance budget: phones on mobile data

Most patients will open the site on a phone, often straight from a map result. Set a budget and enforce it in CI:

Keep Largest Contentful Paint under 2.5 s on a mid-range Android device over 4G.
Serve hero images as AVIF or WebP with explicit width and height to avoid layout shift.
Defer chat widgets, heatmaps and marketing pixels until after user interaction, or load them through a consent manager.
Watch third-party booking iframes, which are often the heaviest thing on the page. Lazy-load them below the fold or open them on tap.

5. Booking is the main conversion: make it reachable

Patients come to do one thing. Make sure they can:

Keep a sticky "Book / Call / WhatsApp" bar on mobile service and doctor pages.
Use tel: and https://wa.me/ links with a prefilled, non-sensitive message.
Keep forms short (name, phone, preferred branch, preferred time) and never ask for symptoms or medical history in an unencrypted marketing form.

6. Security and privacy are table stakes

Health data is sensitive, and UAE law has specific provisions on health information. Developers should at least:

enforce HTTPS with HSTS, and keep the CMS, plugins and dependencies patched,
store form submissions only where needed, with access control and retention rules,
keep analytics free of personal or health information (no symptoms in URLs or event names),
document where data is hosted. The client's legal or compliance team should confirm the requirements for their licence.

7. Content governance hooks

Healthcare content needs review before it's published. Build that into the CMS:

add a "medically reviewed by" field and a "last reviewed" date on clinical pages,
add a publishing workflow with an approval step,
add a simple flag for pages that contain advertising claims, so the marketing team can check them against the relevant authority's rules.

Wrapping up

A good clinic website comes from a clean data model, honest structured data, a properly built Arabic experience, a strict performance budget and a booking path that is never more than one tap away. Get those right and the marketing work on top has something solid to stand on.

We build and maintain healthcare websites at DigeeMed. Questions about any of the points above are welcome in the comments.

Designing a WhatsApp Chatbot for a Small Business: The Hand-off Rules Matter More Than the Model

DigeeSell Team — Wed, 28 Oct 2026 12:29:27 +0000

Most WhatsApp chatbot demos look great for about ninety seconds. Someone asks for opening hours and the bot answers. Someone asks for a price and the bot answers. Then a real customer types "my order came broken and I want a refund now", the bot replies cheerfully with a product suggestion, and the business has a problem.

After building and reviewing a fair number of these for small businesses, my view is that the model is rarely what decides whether a chatbot helps or hurts. What decides it is the plumbing around the model: what the bot is allowed to answer, where its answers come from, and above all when it gets out of the way. Here's the blueprint I'd use.

1. Start from conversations, not features

Before writing a line of code, export a month of real WhatsApp chats and sort them into buckets. In most service businesses you'll find:

Repetitive FAQs: hours, location, prices, documents needed.
Lead questions: "Do you do X? How much? When can you start?"
Transactional requests: bookings, rescheduling, order status.
Sensitive conversations: complaints, refunds, anything medical, legal or financial.

The first three are where automation pays off. The fourth is where it gets you into trouble. Write the buckets down, because they become your routing rules.

2. Route before you generate

Don't send every message straight to the LLM. Put a cheap classification step in front of it:

incoming message
  -> intent = classify(message, history)
  -> if intent in [complaint, refund, human_request, low_confidence]: hand_off()
  -> elif intent == order_status: answer_from_database()
  -> elif intent == booking: run_booking_flow()
  -> else: answer_from_knowledge_base()

Order status should come from your database, not from a model's guess. Bookings should come from your calendar API. The LLM handles the open-ended middle.

3. Ground answers in your own content

A knowledge base bot is only as good as what you feed it. Chunk your FAQ, service pages, price list and policies into small passages, store the source URL with each chunk, and tell the model to answer only from the retrieved text. If nothing relevant comes back, it should say so and offer a human. "I don't know, let me connect you with the team" is a perfectly good answer. A confident wrong price isn't.

4. Make lead qualification feel like a conversation

For lead-driven businesses such as real estate, clinics or consultancies, the bot's most valuable job is qualification. Ask your best salesperson which three questions they always ask first (usually budget or scope, timing, and location), then have the bot ask exactly those, one at a time. Write the answers into your CRM as structured fields, not as a transcript blob, so the sales team can sort and follow up.

5. Design the hand-off before anything else

This is the part most builds skip. A good hand-off:

stops the bot from replying once a human takes over,
passes a summary (who, what they want, what has been answered),
tells the customer that a person is now handling it,
works after hours, with a clear promise of when someone will reply instead of silence.

Trigger it on explicit requests ("agent", "human"), on negative sentiment, on topics the bot shouldn't touch, and when retrieval comes back empty.

6. Respect the platform rules

On the WhatsApp Business Platform, free-form replies are allowed inside the customer-service window that opens when the customer messages you. Outside that window you need approved templates. Meta's business messaging policies also expect clear escalation paths, and they've tightened what kinds of AI assistants are allowed on the API, so keep your bot scoped to your own business's customers and check Meta's current policy before you launch.

7. Log everything, then improve weekly

Log every question, the retrieved sources, the answer and any hand-off reason. Once a week, read the hand-offs and the "I don't know" answers. Each one is either a missing FAQ entry or a routing rule to add. That loop is what turns a demo into a 24/7 assistant your team actually trusts.

Where website and voice fit

The same architecture works for a website chatbot, with the bonus that you can collect lead details in a form and book meetings directly. Voice AI bots that answer calls use the same routing and hand-off logic, plus speech-to-text at the front. Building it once with clean routing means you can add channels later without rewriting the brain.

I work on AI chatbot development at DigeeX, where we build website, WhatsApp and voice assistants for businesses in the UAE. Happy to answer questions about routing or hand-off design in the comments.