SitecoreAI for hospital websites: doctors, bookings and medical content

7 October 2026
Arcsen

Many patients meet a hospital on its website before they call. They filter doctors by specialty, language and gender, read a profile and ask for an appointment. On many hospital sites in the Gulf and Egypt that path breaks in familiar places: a doctor who has left is still bookable, the Arabic profile trails the English one, the request form lands in a shared inbox, and a condition page has not been reviewed since it was written.

Patients also ask AI assistants, which answer from the pages they can read. SitecoreAI, which Sitecore launched in November 2025 as the evolution of XM Cloud, runs this kind of site well once three things are settled: which system owns each fact, where each request goes, and who signs off medical content. Our healthcare outlook sets out the wider picture.

Decide which system owns what

Start with an ownership map that marketing, the clinical content owners and the HIS and CRM teams all sign. This is the version we start from:

Content or data	System of record	What SitecoreAI holds	How it reaches the page
Doctor facts: specialty, clinic, languages, gender, new patients	Provider directory or HIS provider master	The provider ID	Read by the front end from the directory feed, refreshed when a record changes
Doctor profile: biography, photo, video	Marketing, approved by the doctor	Editorial fields linked to the provider ID, in Arabic and English	Published to Experience Edge
Clinics and departments	Marketing and the clinical lead	Services, location, hours and directions	Published to Experience Edge
Appointment slots and bookings	Booking system or HIS	Nothing	An embedded booking flow, or a request form sent to the CRM
Condition and treatment pages	Clinical owners, through workflow	Versioned pages with reviewer and review dates	Published after clinical approval
Results and records	Patient portal	Nothing	A link to the portal

The first row settles most arguments. If doctor facts are typed into the CMS, the website and the booking system disagree the day a doctor changes clinic or leaves.

Find-a-doctor and clinic pages from the directory

Build doctor pages from the directory, with SitecoreAI holding the editorial layer. Each doctor gets one page per language, keyed by the provider ID. The front end reads specialty, clinic, languages, gender and booking status from the directory when it builds the page, and refreshes the page when the record changes. When a doctor leaves, the same event removes the profile from search, takes down the booking button and redirects the old address to the department page.

Plan the listing around Experience Edge. It serves a static snapshot taken at publish time, a single request returns at most 1,000 entities, and the delivery API allows 80 requests per second, so a filter page that queries Edge on every click will hit those limits on a busy morning. Serve the listing from a search index or a cached copy of the feed. Sitecore said customers moving from XM Cloud would receive baseline entitlements for Search, with features rolling out in phases, so check what your subscription includes.

Give patients the filters they use: specialty, location, language, gender and new patients. Index names in Arabic script and the usual English spellings, because patients search for the same doctor in more than one way.

Appointment requests that reach the right system

An appointment request carries health information as soon as a patient types it. In the UAE, Federal Law No. 2 of 2019 covers every use of information and communications technology in health and requires those who handle patient information to keep it confidential, so a request should go straight to the system that acts on it. Two patterns work:

Real-time booking where the booking system or HIS exposes slots: embed its booking flow or call its API, and keep SitecoreAI to the content around it.
A request form where it does not. Forms in SitecoreAI send each submission to a webhook, which your integration layer passes to the CRM, such as Salesforce Health Cloud, or to the booking queue. Since May 2024, option fields can send custom values to the webhook in place of the labels visitors see, so Arabic and English forms deliver the same clinic and specialty codes.

Ask only for what the booking team needs: name, mobile number, preferred language, clinic or specialty and a preferred time. Leave out free-text symptoms unless a clinician asks for them. Show the consent wording in both languages, and test the whole path from form to CRM record to callback in Arabic and English.

Medical content: review dates and two languages

Sitecore’s workflow guidance recommends a workflow for all content items, with separate workflows for pages and for their components, so editing a component on an approved page puts both back into workflow as new versions. For medical content, add a clinical review state before approval, give clinical reviewers a role that can approve or reject, and use a Webhook Submit Action to notify them when an item reaches their state. Administrators bypass workflow by default, so editors should never hold the admin role.

Review dates need fields of their own: the clinical reviewer, the last review and the next one, with the reviewer and last review date shown on the page and a weekly list of overdue pages sent to owners. Scheduled availability will not retire an outdated page by itself. A version can have start and end dates, and Sitecore says you must still publish the page or site when each date starts. AI drafts from Agentic Studio, the workspace SitecoreAI launched with, go through the same clinical review.

Arabic needs its own reviewer. Add an Arabic review step and publish both languages together. The Glossary and Localization section of the brand kit tells SitecoreAI how specific terms should be handled across languages when pages are translated, which suits department names, procedures and medicines. Link each pair with hreflang annotations: Google says each version must list itself and every other version, and ignores tags that do not point both ways. Our Arabic-first Sitecore guide lists the right-to-left checks.

Rule of thumb: doctor facts come from the directory, slots from the booking system, and medical wording from a clinician who signed it off, in both languages.

Pages that patients, screen readers and AI search can read

Hospital sites serve people who are unwell, older or anxious, often on a phone. Design and test against the W3C’s Web Content Accessibility Guidelines (WCAG) from design sign-off to go-live: text alternatives for images, labelled form fields with clear errors, keyboard use for the whole booking flow, enough contrast, and captions on video. Test with screen readers in Arabic and English, because right-to-left layouts break in their own ways.

The same discipline helps with AI search. Google says there are no additional requirements to appear in AI Overviews or AI Mode: a page must be indexed and eligible to be shown with a snippet, and no special schema.org markup is needed. Its advice is familiar: allow crawling, link pages internally, keep important content in text, make structured data match the visible text, and keep Business Profile information up to date. So each doctor page states specialty, languages, clinic and how to book in plain text, and each clinic page matches its Business Profile. Check that robots.txt and CDN rules let in the AI crawlers you want, then ask patients’ questions in both languages and see which pages the answers cite. See our approach to AI visibility.

Where to start

Compare the site with the directory and fix the gaps in doctor profiles before you build anything.
Sign the ownership map with marketing, clinical owners and the HIS and CRM teams.
Route every appointment form to the CRM or booking system, and retire any that send requests to email.
Set up clinical review: the workflow state, the reviewer role and the review-date fields, then a first pass over your most visited medical pages.
Test with patients’ questions in Arabic and English, with a screen reader and an AI assistant.

Still on Sitecore XP? Build these patterns into the move: Arcsen Ascend is our migration route to SitecoreAI.

Running a hospital website on Sitecore? Start with the free Sitecore Health Check. See our healthcare work and our Sitecore practice, or talk to our healthcare team.

Frequently asked questions

Should doctor profiles live in SitecoreAI?

Only the editorial layer, such as biography, photo and video, linked to the provider ID. Specialty, clinic, languages and booking status come from the provider directory, so the website and the booking system agree.

Can SitecoreAI Forms send appointment requests to a CRM?

Yes. Each submission goes to a webhook that your integration layer passes to the CRM or booking system, and option fields can send custom values, so Arabic and English forms deliver the same codes.

How should a hospital manage medical review dates in SitecoreAI?

With reviewer and review-date fields on medical templates, a clinical review state in workflow and a regular report of overdue pages. Scheduled availability still needs a publish when each date starts.

Does a hospital site need special markup to appear in AI search?

Google says no: a page must be indexed and eligible for a snippet, and no special schema.org markup is required. Clear text, internal links and structured data that matches the page are among its best practices.

How do we keep Arabic and English pages in step?

Give Arabic its own review step, publish both languages together, define medical terms in the brand kit glossary, and link each pair with hreflang annotations that point both ways.