LocalBusiness and Service Schema for UAE Websites: A Practical Setup Guide

Structured data is a machine-readable description of information that is already represented on a page. For a UAE AC maintenance, pest control, cleaning or plumbing company, it can help clarify which organisation operates the site, what service a page describes and which area the service genuinely covers. It is not a shortcut for missing content, a substitute for accurate business details or a ranking guarantee.

This guide separates three concepts that are often mixed together: the business entity, the service being offered and the Google search features that may consume structured data. Examples use placeholders; replace them with facts that are true for the specific business and page.

Choose the type that matches the real entity

Organization: describe the company

Organization is a useful way to describe the company behind a website: its real name, official URL, logo and verified public profiles. It is a sensible starting point when a business operates remotely or does not have a customer-facing location that can accurately be represented as a local branch.

LocalBusiness: describe a genuine local business or location

LocalBusiness represents a particular physical business or branch. Google's LocalBusiness structured-data documentation requires a business name and physical address for eligibility for its Local Business rich-result feature. Use the most specific valid subtype only when it really fits the operation.

For a company that visits customers, be careful not to invent a shopfront or publish an address that misleads visitors. If the company has no suitable public customer-facing address, do not force a LocalBusiness example just because a plugin asks for one. Use an accurate Organization description and describe individual services where appropriate; review Google's current documentation before attempting to qualify for a location-specific search feature.

Service: describe one actual service

Service describes a service provided by an organisation or person. It can identify the offering, its provider and the area served. For example, an AC maintenance page may describe AC maintenance, while a pest-control page describes the treatments the company genuinely offers. Schema.org defining a type does not mean Google provides a dedicated rich result for that type.

Start with a clear business entity

Before writing JSON-LD, prepare one approved record of the business's real name, canonical website URL, public phone number, logo, and official social or platform profiles. Check that the same facts appear in visible site content and that each linked profile belongs to the company.

• Use the business's real trading name, not a string of keywords.
• Use a canonical HTTPS URL that resolves successfully.
• Use only official profiles in sameAs; do not add directories or profiles that are unrelated or not controlled by the business.
• Keep the visible contact details consistent with the data in the markup.
• Only include opening hours, coordinates, price information, ratings or other details when they are accurate and supported.

Do not add a separate LocalBusiness entity for every service page if all of them describe the same company. Where a company has several real branches, model the branches only when the locations and their details are genuinely distinct.

Example 1: LocalBusiness for a real public location

The following is a structural example, not a ready-to-publish profile. Replace each placeholder and remove any property that does not apply. The address must be the real physical location represented by the page. Do not invent a street, postal code or map coordinate. Google's eligibility rules and required properties take precedence over a generic example.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/#business",
  "name": "[Replace with the exact real business name]",
  "url": "https://example.com/",
  "telephone": "[Replace with the public business phone number]",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "[Real public street address, if applicable]",
    "addressLocality": "[Actual city or emirate]",
    "addressRegion": "[Actual emirate, if appropriate]",
    "addressCountry": "AE"
  }
}

Keep the address visible and consistent wherever the site claims customers can visit the business. If the business is service-area-only and does not receive customers at its address, do not publish private or misleading location information simply to complete this example. Review the platform's current requirements with the developer before adding location markup.

Example 2: Service markup for a service page

This example describes a service and its provider. Change the service name and service area to match the page. Do not say a company covers all of the UAE if it only takes jobs in Dubai, or list a service the team does not actually perform.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/ac-maintenance/#service",
  "name": "AC maintenance",
  "serviceType": "Air-conditioning maintenance",
  "url": "https://example.com/ac-maintenance/",
  "provider": {
    "@type": "Organization",
    "name": "[Exact real business name]",
    "url": "https://example.com/"
  },
  "areaServed": {
    "@type": "AdministrativeArea",
    "name": "Dubai, United Arab Emirates"
  }
}

Use areaServed only for the genuine coverage area. Keep the service page useful for people as well: explain what is included, how the process works, what information a customer should provide and how to enquire. Markup cannot compensate for a thin or misleading page.

Where should the JSON-LD go?

For a Next.js site, a JSON-LD script can be rendered on the page that the data describes. Keep the data in a maintainable object or helper rather than copying slightly different versions across dozens of pages. Escape or serialize values safely, and make sure the canonical URL and page entity stay in sync.

Use a stable identifier such as the company's canonical URL plus a fragment for the business entity, for example a business ID ending in #business. Refer to that same entity from related service markup where appropriate. Stable IDs help avoid accidentally describing the same business as several unrelated entities.

Common schema mistakes on service websites

• Invented locations: do not use a virtual office or private address as if it were a customer-facing branch.
• Wrong business type: choose a type that matches the real operation, not the keyword you want to rank for.
• Unsupported ratings: never invent stars, review counts, awards or testimonials. Only use review markup when it meets the relevant guidelines and matches the visible page.
• Keyword stuffing: names and descriptions should identify the real entity and service, not repeat a list of search phrases.
• Duplicate entities: keep a consistent business ID instead of creating a new business identity on every URL.
• Markup without visible support: do not add prices, opening hours, service coverage or claims that the page does not substantiate.
• Assuming a rich result: valid structured data does not guarantee that Google will show a special search feature.

Validate before and after publishing

1. Check the page's visible details against the JSON-LD property by property.
2. Validate general Schema.org syntax with the Schema Markup Validator.
3. For a type supported by Google rich results, use Google's Rich Results Test and fix errors that affect eligibility.
4. Confirm the page is crawlable, indexable and uses the intended canonical URL.
5. After deployment, inspect the URL in Google Search Console and monitor relevant enhancement reports if available.
6. Repeat the checks after changing business details, page URLs, service coverage or the schema implementation.

Google notes that structured data features may look different in results and are not guaranteed to appear. Use its structured data introduction for general principles and the specific LocalBusiness guide for feature eligibility.

How this fits into local SEO

Schema is one part of a complete setup. The website still needs useful service pages, clear contact paths, accurate business information, internal links and technical access for search engines. If the site is new, begin with our first-30-days local SEO checklist. For the business listing itself, read the Google Business Profile guide for service-area companies, and use the service pages versus area pages guide before building lots of near-duplicate URLs.

Frequently asked questions

This guide is informational, not a guarantee of eligibility or search appearance. Check current Schema.org and Google documentation before deploying markup for a real business.