Breaking down a prompt for LocalBusiness Schema.org markup
LocalBusiness markup is written once, but it is easy to get wrong. Here is a prompt that assembles it from your data, and the fields people most often falsify.
The full prompt text
"You are a structured data specialist. Generate valid JSON-LD following Schema.org for a local business. Choose the type from LocalBusiness or a more specific subtype if one fits. Required fields: name, image, url, telephone, priceRange, address (PostalAddress with streetAddress, addressLocality, addressRegion, postalCode and ISO addressCountry), geo (GeoCoordinates), openingHoursSpecification as an array of days, sameAs as an array of social links. Requirements: phone in international format starting +998, addressCountry UZ, 24-hour time, weekdays as the specification's English abbreviations. Do not add fields I have not supplied data for and do not invent coordinates. Return only the JSON-LD inside a script tag, with no commentary. Data: [your list]."
The last two sentences carry the weight. Without an explicit ban the model confidently fills in fictional coordinates and ratings — exactly the fields that attract a manual penalty.
Type selection matters most
LocalBusiness is the generic type. For a dental clinic, restaurant, garage or salon, the precise subtype gives search engines more understanding and unlocks extra fields such as menus or service lists.
Do not declare several types at once to 'cover more'. That common improvisation produces invalid markup. One entity, one type.
If you have several branches, each needs its own page with its own markup and address. One page carrying five addresses is a low-quality signal, not an advantage.
Address fields for Uzbekistan
addressCountry is always the two-letter code UZ, never the word. addressLocality is the city — Toshkent or Tashkent, but spelled identically across every source. addressRegion is the province or city of republican significance.
Write streetAddress exactly as it appears in Google Maps and local directories: same abbreviations, same order. Inconsistent spelling between site, maps and directories is the main reason local results fail to connect a page to a business.
Fill postalCode only if you genuinely have one. An empty or invented field is worse than an absent one.
Phone, hours and pricing
Use only the +998 XX XXX XX XX format, with no letters or extensions in the same field. The local 71-200-00-00 style is not parsed unambiguously.
Provide openingHoursSpecification as an array of objects, not a string. Break out short days and days off separately rather than collapsing the week into one entry.
Do not invent priceRange. If you would rather not disclose a bracket, use a symbolic indicator or drop the field. A range in UZS is fine, but it must match the prices on the site.
What must never be marked up
The most dangerous mistake is marking up reviews and ratings that do not exist on the page. AggregateRating is only acceptable when reviews are genuinely published on that same page and came from customers.
Do not mark up promotions you are not running or services you do not offer. These fields get reviewed manually, and a penalty takes months to lift.
Do not duplicate markup: if both the CMS template and your inserted script emit it, you end up with two conflicting entities. Check the page source before adding anything.
Validating the result
Run the finished JSON-LD through a structured data validator and through the rich results report in Google Search Console. The validator catches syntax; the report shows what search actually recognised.
Check the page separately in Yandex.Webmaster: its validator is stricter about some fields and flags what Google's tool lets through.
After deployment, wait two or three weeks and review the rich results report. If the entity never appears, the cause is usually an incomplete address or two competing markup blocks on the page.