Schema Markup for a Local Business

Schema markup is a way to say, in a format a machine can read, what a page is about. For a local business the useful type is LocalBusiness, or a more specific subtype when you truly are one: a dentist, a restaurant, a plumber, an HVAC business. The page people should read first is still written in sentences. The markup does not replace the phone number a person can tap.

Google's introduction to structured data describes it as explicit clues about the meaning of a page. The LocalBusiness documentation says those clues can tell Google about hours, departments, and, in a narrow case, reviews. It also says Google does not guarantee that a feature which consumes structured data will show. Treat markup as eligibility work. Treat a screenshot of a rich result on someone else's site as their result, not a forecast of yours.

This sits next to the Google Business Profile checklist. The profile is the listing. The schema is on your site. They should describe the same business. The broader system is local SEO, and the long version is the local SEO guide.

What Google lists as required

On the LocalBusiness page, Google lists two required properties: name and address. The address is a PostalAddress. The documentation says to include as many address properties as you can, because a fuller address is more useful, and it shows street, city, region, postal code, and country in the example.

Recommended properties include telephone, url, openingHoursSpecification, geo with latitude and longitude, priceRange, and, for a food business, menu and servesCuisine. Geo coordinates, when you provide them, are specified to at least five decimal places. Hours use OpeningHoursSpecification with a day, an opening time, and a closing time. Seasonal closures can use validFrom and validThrough. A department with its own phone or hours can be nested. None of that is a reason to publish a detail you do not actually keep.

Use the most specific subtype that is true. A dental office is a better type than a generic local business. A restaurant is a better type than a store. Google's example of multiple types is an array, for a business that really offers more than one trade. An array is not a place to list every service you wish you sold.

If you have more than one real door, each location needs its own details. One block that mixes two cities into a single address is how the markup starts lying. A business with one office should not publish a second block for a suburb where it merely drives. That mistake has a twin in doorway pages, which the local SEO guide already argues against.

Service-area businesses and invented addresses

A company that goes to the customer may not publish a street address, and should not mint one for schema. Google's required address field describes a physical location. If you do not have a public location you are willing to put on the site, leave the rich-result ambition alone rather than invent a suite. The Google Business Profile is where a service-area business states the area it serves, subject to Google's current rules for that listing type. The website should match the area you will actually cover.

An Austin company and a dental office have the same duty here. The city page explains how we work remotely in that market. It is not a claim that CodeHunterz keeps a chair in Austin, and your schema should not claim a chair you do not have either.

Reviews are the easy way to get this wrong

Google's LocalBusiness table says review and aggregateRating are recommended only for sites that capture reviews about other local businesses. The words "other" are doing the work. A directory can mark up reviews it hosts about a restaurant. A restaurant marking up a five-star average about itself is the pattern those guidelines are written to limit. Follow the review snippet rules if you are the directory. If you are the business, do not add a rating you wrote, a count you guessed, or a testimonial you paraphrased into a star value.

We do not publish fake reviews on this site, and we will not tell you to hide them inside JSON-LD. Stars that are not backed by reviews you are allowed to mark up are a policy problem, not a growth tactic. If you want social proof, earn reviews on the profile and reply to them as yourself. The profile checklist covers that habit.

Presence is not validity, and validity is not a display

The free website audit looks for a JSON-LD script, tries to parse it, and lists the types. That is a useful first pass. It will catch a script that is not JSON. It will not tell you that Google considers the address complete, that the hours match the door, or that a rich result is approved. Google's own rollout instructions are to validate with the Rich Results Test, fix critical errors, then use URL Inspection on a page Google can fetch. A noindex tag or a robots.txt disallow means the markup is never seen. The technical SEO checklist is the page-level list that has to be true before schema matters.

JavaScript can inject JSON-LD. Google says it can render pages, and also that rendering is not guaranteed for every extraction. If the markup only appears after a widget loads, prefer having it in the HTML you ship. The audit tool does not run the page in a browser, so it will miss a block that does not exist until a script runs. If the tool says there is no JSON-LD and you know a plugin adds it later, view the source the crawler is likely to get, not only the finished screen.

Hours, phone, and the page have to match

Markup that disagrees with the visible page is worse than no markup. If the site says you close at 5 and the JSON says 9, you have published two stories. If the telephone in the script is an old tracking number nobody answers, the "clue" is a wrong number. Write the hours in one place your staff can edit, show those hours as text, and generate the specification from that same source if you generate it at all.

url should be the fully qualified URL of that location, and Google says it must be a working link. A canonical on the page should agree. After a redesign, update the URL in the markup when the address changes. A structured data block that still points at a retired path is a small version of a bad redirect.

priceRange is a short relative range, and Google says a value of 100 characters or more will not be shown as a price range. It is not a place for a paragraph about financing. If you do not want a price hint in search, leave it off.

What we will not put in the script

Do not mark up a medical outcome, a legal result, or a guaranteed rank. Do not copy a competitor's address "as a test." Do not add aggregateRating because a plugin offered a field. Do not list every neighborhood as its own LocalBusiness. One honest block, on the page that describes the real location, is the whole job for most firms.

A restaurant can use a food-specific subtype and a menu URL when the menu page is real. A med spa or a clinic should be careful about claims the markup implies. Your license and your counsel still own the words. Schema does not make a claim compliant.

Where this sits in the budget

Structured data is a few hours when the facts are already written down, and a mess when the hours, the phone, and the address are not. It is not a separate retainer with a promised map pin. Public ranges for local SEO work are in the SEO pricing guide. They are not a CodeHunterz quote and not a ranking guarantee. Growth starts at $2,400 per month after a 20% launch offer (regular starting price $3,000 per month). Limited-time launch offer, final quote after free strategy call.

Run the website checker if you want to know whether any JSON-LD is on the URL today. Then book a call if you want the visible page and the markup brought into agreement with the profile. The measurement is free. The cleanup is scoped in writing.