Which LocalBusiness fields does Google require?

Google lists name and address as required LocalBusiness properties for rich-result eligibility. The address is the physical location of the business. Other fields can add useful detail when they apply, but a longer list should not obscure those two required entries. Compare both with the visible location page and the actual branch before publishing markup; a valid JSON shape cannot make a wrong address true[1][3].

Should I choose a subtype of LocalBusiness?

Use the most fitting type supported by the business's actual activity. Schema.org defines LocalBusiness as a particular physical business or branch, and Google's examples use specific types such as Restaurant. For this grooming shop, use `LocalBusiness` unless a narrower subtype is established from the actual service. Google says to use the most specific LocalBusiness subtype possible[1][2].

How should separate branches appear in structured data?

Represent each physical branch as its own `LocalBusiness` entity, then assess its page separately. Google says to define each local business location as a LocalBusiness type; schema.org's definition includes a particular branch. Do not paste one head-office address across distinct service pages. For departments with their own hours or phone numbers, Google documents a nested department property with the differing details attached to that department[1][2].

Must opening hours and phone numbers match the page?

The markup should describe details readers can verify on the visible page. Google's general structured data guidelines say not to mark up content that readers cannot see. Its LocalBusiness guide documents openingHoursSpecification and telephone as available properties. Check the actual shop schedule and contact number against both the rendered page and JSON-LD, especially after a holiday or phone change[1][3].

Can my business mark up its own review rating?

Do not assume that a rating gathered on the shop's own page qualifies for Google's local rich result. The LocalBusiness guide says aggregateRating and review are recommended only for sites that capture reviews about other local businesses, and points to review rules. Check that condition before adding either field. An attractive rating displayed by a plugin is not enough to establish eligibility[1].

Does a passing rich-result test guarantee ranking?

No. Google's guide recommends validating code with the Rich Results Test, then checking deployed pages with URL Inspection. Those steps examine markup and how Google sees the page; they do not promise a ranking or an AI citation. Google's structured data policies also require relevant, non-misleading content. Preserve the test result, review the live page and observe outcomes separately[1][3].

Local Business Schema: Fields, Locations and Page Checks

Quick Answer: Local business schema needs a shop's name and physical address for Google's rich-result eligibility¹. Choose a fitting subtype, separate branches and departments, and match hours, phone and address to the visible page¹^,2^,3. Test published markup, but validity does not guarantee a search ranking or AI citation¹.

Summary in a mind map

Local Business Schema: Fields, Locations and Page Checks
│
├─ Identify the place
│   ├─ Name and physical address are required
│   └─ Select a defensible shop subtype
│
├─ Represent the structure
│   ├─ Give each real branch its own record
│   ├─ Nest departments with distinct details
│   └─ Avoid invented locations
│
├─ Match visible details
│   ├─ Hours and phones reflect the live page
│   └─ Review markup needs a separate rule check
│
└─ Validate then observe
    ├─ Test code and inspect the published URL
    └─ Valid markup does not promise ranking

Start with name and address

Google's LocalBusiness guide marks name and address as required properties for rich-result eligibility. Its description calls the address the physical location of the business. A Sacramento pet-grooming shop should therefore start with its real trading name and the street location customers visit, not with an optional field copied from a plugin example¹.

The first artefact is a short location record: name as shown to customers, full postal address, page URL and the person who confirms them. This is an editorial control. It lets the owner compare structured data with the contact page without treating a passing syntax check as proof of factual accuracy¹^,3.

If the shop has moved, update the visible page and the markup together. Google's general policy says structured data must not mark up content invisible to readers and must not be misleading. A former address hidden in JSON-LD would create a mismatch even if the code parses³.

Field	Google status	Owner's check
`name`	Required¹	Same business identity as visible page
`address`	Required physical location¹	Current branch address in page content
`telephone`	Documented property¹	Number reaches this location
`openingHoursSpecification`	Documented property¹	Schedule matches what customers see

Select the precise shop type

Schema.org defines LocalBusiness as a particular physical business or branch of an organisation. Google uses more specific business types in its examples, including Restaurant. For this grooming shop, choose LocalBusiness as the defensible @type until a more specific subtype is established. Google says to use the most specific LocalBusiness subtype possible; the shop should not copy an unrelated type from a sample payload¹^,2.

The type choice is a classification step, not an opportunity to add services that the shop does not provide. A team member can record why the chosen subtype describes the premises and visible offer. If none is defensible, the broad LocalBusiness type still describes a physical business. The cited sources do not prescribe a special search reward for choosing an ever narrower term¹^,2^,3.

That decision should precede coding. It keeps the page's main claim about the business stable even if a developer later changes the JSON-LD syntax or the site template. It also gives a reviewer a plain-language question: “Does this type describe the shop a visitor would find at this address?”²^,3

Map branches and departments

A branch is a particular physical business under schema.org's definition. For each physical location, create a separate LocalBusiness entity and compare its address with that location's visible page. Google says to define each local business location as a LocalBusiness type. Copying one address into every branch's markup defeats the purpose of a location-specific description¹^,2.

Google also documents department for a business with internal departments that have distinct properties, such as different telephone numbers or opening hours. Those differing values belong on the department element. A grooming shop might later operate a genuinely separate counter, but it should not invent a department merely to create more markup. This example is conditional; whether a counter qualifies depends on the actual business¹.

Situation	Representation to assess	Verification question
One physical shop	One `LocalBusiness` entity¹^,2	Does the address identify that shop?
Two physical branches	One `LocalBusiness` entity per location¹^,2	Which page belongs to each address?
Real department with distinct hours	Nested department¹	Are those hours visible to customers?

The site may have service-area copy as well as a shop address. This article's required-address rule concerns Google's LocalBusiness rich-result documentation. It does not settle eligibility for every service-area model. Where there is no customer-facing physical location to describe, the owner should not invent one to pass this checklist¹^,3.

Match hours and contact details

Google lists openingHoursSpecification and telephone among its LocalBusiness properties. Its examples show how schedules can vary by day and how seasonal changes can be represented. A shop should enter the actual timetable it publishes to customers, rather than pasting the sample hours into production¹.

Before release, read the rendered contact page as a customer. Does the address include the right street and city? Does the number connect to that shop? Are the hours for the current season? Then inspect the generated JSON-LD from the live page. The two surfaces should describe the same place. Google's visibility guideline makes this comparison substantive rather than cosmetic¹^,3.

A change log can record the date, page, field and approver for a phone or hours update. That is a practical quality control, not a requirement claimed for Google. It prevents the website text and the structured data from drifting apart when one team edits a page and another maintains the plugin³.

Check review claims separately

The LocalBusiness guide has a specific limitation for review and aggregate rating properties: it recommends them for sites capturing reviews about other local businesses. An owner should not assume its self-published testimonials become an eligible Google review display because a plugin provides a rating field¹.

This is a separate check from name and address. The shop can still show genuine customer feedback on its page, subject to its own editorial process. Whether to add review markup requires the cited Google rule to be checked against the site's role. A software warning that a rating field is absent does not override that rule¹.

For the worked shop example, leave rating markup out until the owner can explain how the page meets Google's conditions. The decision avoids a misleading claim while preserving the location details customers actually need. Google's general guidelines also say not to mark up irrelevant or misleading content¹^,3.

Test code and the live page

Google recommends the Rich Results Test for structured data, followed by URL Inspection on deployed pages. This is a two-stage procedure: test the data format, then check how Google sees the published URL. Save the tested URL and date so the result can be tied to a particular version of the page¹.

A test can expose errors in required properties. It cannot verify that a phone number reaches the right desk or that the shop opens at the hours stated. Those facts need a business check. Nor does passing the test guarantee that Google will show a rich result for a query or cite the page in a generated answer¹^,3.

The workflow below keeps the factual and technical checks together. Its last step is a review of observed results after publication, not a promise about placement.

A correct place record and a valid test answer different questions.

In words, the tree branches like this: confirm a real physical location; enter its name and address; choose an accurate subtype and optional details; compare those details with the visible page; test the markup and inspect the live URL before observing any search result.

Where this procedure stops

This procedure cannot classify a business without a physical location under Google's LocalBusiness rich-result requirements. It cannot promise ranking or an AI citation from valid markup. It also does not decide whether a specific self-published review qualifies; that requires the review rule and the site's actual role to be assessed¹^,3.

What to do next

Prepare one location record for the grooming shop, check the visible contact page, then validate the published URL. Repeat the record only for genuine other branches or departments. For the separate question of whether ChatGPT recommends your business, observe answers rather than inferring them from schema. Check AI mentions of your brand, read the wider generative engine optimisation context and examine why a competitor may be recommended. Use AI Answer Audit to check how AI answers describe and recommend the business.