Build your lab website

Start with Lab Settings, then Website CMS

Open Lab Settings first and confirm the public lab slug. The slug creates the public path /labs/{slug}. Keep it short, recognizable, and stable once patients receive the link.

Then open Website CMS before using the visual builder. Confirm the published switch, website logo, phone, email, WhatsApp, address, SEO titles and descriptions, and theme colors.

Do not publish the site until the contact details and patient-facing language are approved. If the site is unpublished, patients cannot see it; that is useful while the team is still drafting.

Add fallback home sections

In Website CMS, add home sections for the core service messages. Each section needs a section key, enabled switch, sort order, English title/body, and Arabic title/body. Good starter sections include home visits, patient portal results, insurance support, branch services, preparation instructions, and contact instructions.

Keep each section focused on one promise. If the branch only serves home visits in certain areas, say so. If portal results appear only after release, say so. Public content should reduce reception questions, not create new ones.

Prepare catalogue and blog content

The public website can show featured tests and latest posts. Featured tests come from active tests in the lab company catalogue. Prices come from active catalogue pricing. Blog posts appear only when they are published.

Before publishing the website, search the public Tests page for common tests in both interface languages. Confirm that the English test names, codes, localized categories, sample types, turnaround hours, currency, and price ranges are correct. Then publish at least one useful blog post if the homepage should show educational content.

Open the Website Builder

If the visual page builder feature is enabled and the lab plan is eligible, open Website Builder from Admin. The builder edits the home page. It loads separate English and Arabic draft states and provides actions to save draft, publish, revert to published, and upload assets.

Draft edits do not change the public site. Publishing sanitizes the HTML and CSS, renders website widgets, and stores the published English and Arabic output. This separation lets marketing test layout changes safely before patients see them.

Design the homepage

Start with the lab name, one clear statement, and patient actions: Tests, Blog, and Patient Portal. Use builder blocks or fallback sections to explain services. Add featured tests only after the catalogue is accurate. Add latest posts only when the posts are helpful and approved.

Avoid promising services the lab cannot perform today. The public site should not advertise a branch, test, turnaround time, or home visit service that operations cannot support. Ask the owner or manager to approve medical wording before publishing.

Publish and review

Publish after reviewing English and Arabic content. Open the public homepage in both languages. Test the header navigation, patient portal button, tests link, blog link, contact details, mobile layout, and visual contrast. If builder content appears wrong, return to the builder, fix the draft, and publish again.

If the public site still shows fallback content, check that the builder home page has a published state and that the visual builder feature is enabled. If the site returns not found, check the published switch in Website CMS and the public slug in Lab Settings.

Connect patient workflows

The website becomes useful when the links lead to working patient workflows. The patient portal should let patients request OTP login, view released results, see loyalty information when enabled, and request home visits when the lab supports that service.

Run a test with a real released sample before advertising portal access. If reports are not released correctly, patients will sign in and see nothing. If home visit dispatch is not staffed, requests will sit unanswered.

Maintain the website

Review the public site whenever prices, branch contacts, service areas, portal policy, report release policy, or high-volume tests change. Keep blog posts current and remove old announcements when they are no longer true.

Assign one owner for public content and one reviewer for operational accuracy. Marketing can write the page, but operations must confirm the promise.