Government and free zone websites on SitecoreAI: what to design for

1 October 2026
Arcsen

A government website is judged on one question: can a resident or an investor find the right service, see what it needs, and start it? Behind each answer sit a department that owns the facts, a portal that runs the transaction and a chain of approvers, with Arabic as the first language. When a fee changes on one page and stays old on another, people stop trusting the site and phone the call centre.

Free zones add a sales job, because investors compare setup steps and costs across zones. This guide covers how a government or free zone website on SitecoreAI (formerly XM Cloud) handles Arabic-first content, the accessibility standards the UAE and Saudi governments publish, service catalogues, approval workflows, and content that AI search engines can cite.

Arabic first, in the content and in the workflow

Arabic-first starts with authoring order: when Arabic is the version of record, it is written and approved first, and English follows. SitecoreAI holds each language as its own version of an item. Its AI translation creates language versions of a page and its data sources, guided by a brand kit, and with Keep workflow state cleared, as Sitecore recommends, each translation starts in the initial state, typically Draft, and waits for a reviewer. Put the official names of the entity, its services and programmes in the brand kit first.

Three rules keep the languages in step. Publish both languages of a service page together. Keep English off Arabic pages, using fallback only between Arabic variants. And design layout, typography, digits and search in Arabic from the start; our guide to Arabic-first Sitecore sets out the checks.

Accessibility: what the UAE and Saudi standards ask

Both governments set the bar at the same level. In the UAE, the National Policy for Digital Accessibility requires public service sites to comply with WCAG 2.1 Level AA. In Saudi Arabia, the Digital Government Authority’s web accessibility guideline requires government entities to meet at minimum WCAG 2.1 Level AA. Confirm which rules bind your entity, and treat AA as the floor for every page in every language.

On a headless platform, accessibility lives in three places:

Components. The front-end application renders every page, so build each component once to AA and test it in Arabic and English, with screen readers in right-to-left layouts.
Content. Alternative text, headings, link text, tables and documents are editors’ work. AI translation includes image alt text, so review it in both languages. Publish service requirements as page text, with any PDF as an extra.
Workflow. Add an accessibility check before approval. A webhook validation action lets a third-party service approve or reject a change of workflow state; if the endpoint does not validate the command, the item keeps its state.

Service catalogues that hand off to portals

The website explains a service and the portal delivers it. Model each service once, as an item with its own fields: name, summary, who can apply, documents, fees, processing time, channels, steps, owning department, review date and portal link. The catalogue, the service page, site search and structured data then read the same fields, so each fee is stated once. For a free zone, the same model carries licence activities, packages and costs.

Two details decide whether the model holds. In Sitecore, a Shared field has the same value in every language and version, and workflow and publishing restrictions do not apply to it, which suits a service code. Fees, documents and eligibility belong in versioned fields, so every change is approved. And Experience Edge does not enforce security constraints on Sitecore content, so treat everything published as public and keep staff notes out of the content model. A single request returns at most 1,000 entities, so a large catalogue pages through results or uses search.

The hand-off is a deep link. The “Start service” button carries the service code and language, and the portal handles sign-in with UAE PASS or Nafath, then payment and status. Agree with the portal team what the page shows when the portal is down, in both languages.

Approval workflows that stand up to audit

Government content needs a named approver for every change and a record of who approved what. SitecoreAI workflows are built from states and commands. Items in a final state are publishable, commands can send an item directly to any state, and editing an approved item creates a new version in the initial state, so every change is approved again. A typical path for a service page:

Stage	Who acts	What they check	What SitecoreAI enforces
Draft in Arabic	Arabic author	Facts supplied by the service owner	New items start in the workflow’s initial state
Service owner review	The department that runs the service	Fees, documents, eligibility and time	Commands appear only to users with access to that state and command
English version	Translator or AI translation, then a reviewer	Meaning and official names	Translations start in Draft when Keep workflow state is cleared
Accessibility and quality	Digital team	Alt text, headings, links and documents	A webhook validation action can hold the item until a checker approves
Approval and publish	An approver with no administrator account	Both languages ready together	Only items in a final state can be published
Change after go-live	Any editor	The change itself	Editing an approved item creates a new version for approval

Two cautions. Sitecore advises that workflow users should not have an administrator account, because administrators and members of some client roles can ignore workflow restrictions or grant themselves more rights. And plan the audit trail before go-live: commands can prompt for a comment at each step, and a webhook submit action reports each change of workflow state to an outside system such as a records store. SitecoreAI does not resend a request when the endpoint fails, so that service must be reliable. The history table, which records changes to items, is off by default and carries a performance penalty when enabled. Route any AI agent’s drafts through the same workflow; our Agentic Studio explainer covers the approvals.

Rule of thumb: codes in Shared fields, facts and fees in versioned fields, Arabic approved first, approvers without administrator rights, and one owner and review date for every service.

Structured content that AI search can cite

Residents now ask AI assistants which documents a service needs or what a licence costs, and the answers quote pages that state it plainly. Google says there are no additional requirements to appear in its AI Overviews or AI Mode, and no special schema.org markup to add. A page must be indexed and eligible to show with a snippet, and structured data must match the visible text. Its other advice reads like a content checklist: allow crawling in robots.txt and the CDN, link pages internally, and keep important content in text.

The service model does most of the work. Put the answer first on every service page, in both languages: who can apply, what to bring, what it costs and how long it takes. Generate structured data from the fields the page shows, so markup and text cannot disagree, show the date of the last review, and state fees on the page, since a scanned PDF hides them. See how we approach AI visibility for Sitecore sites.

Where to start

List every service with its owner, portal link, fees and documents, and where each fact lives today.
Design the service content type, with codes in Shared fields, approved facts in versioned fields, and a review date.
Map the approval path for each content type and language, with named roles, and take administrator rights away from approvers.
Run an accessibility baseline against WCAG 2.1 Level AA on your busiest service pages, in Arabic and English, including documents.
Test AI search readiness: crawling allowed, answers in text, and structured data that matches the page.

Planning a government or free zone website? See our public sector work and public sector outlook, start with the free Sitecore Health Check if you run Sitecore today, and talk to our public sector team or send us your RFP.

Choosing a Sitecore partner in your country? See how we deliver SitecoreAI in Saudi Arabia, the UAE, Egypt and Qatar.

Frequently asked questions

Which accessibility standard applies to government websites in the UAE and Saudi Arabia?

In the UAE, the National Policy for Digital Accessibility requires public service sites to comply with WCAG 2.1 Level AA. In Saudi Arabia, the Digital Government Authority’s guideline requires government entities to meet at minimum WCAG 2.1 Level AA.

Can people complete government services on a SitecoreAI website?

The website explains each service and links to it. The transaction runs on the service portal, where people sign in with UAE PASS or Nafath and pay.

How do approvals work in SitecoreAI?

Items move through workflow states, and only items in a final state can be published. Editing an approved item creates a new version for approval, and approvers should not be administrators, who can ignore workflow restrictions.

Does SitecoreAI keep an audit trail of approvals?

Commands can prompt for a comment, and a webhook submit action can send each workflow change to an outside records system. The history table is off by default and costs performance when enabled.

Do government sites need special markup to appear in AI answers?

Google says no special optimization or schema.org markup is needed for AI Overviews or AI Mode. Pages must be indexed and eligible for a snippet, with structured data that matches the visible text.