When a crawler lands on your contact page, it sees a string of characters reading "Bağdat Caddesi No 122". That string could be your address, an example given in a blog post, or even a competitor's address. The phone number on the same page could be your sales line or your supplier's number. The question a machine cannot answer by looking at the page is this: does this page describe a business, and if so, which one?
LocalBusiness markup is exactly the answer to that question. With a data block placed in the page's source code and invisible to the reader, you say "this page describes the business with this name at this address". Google requires only two fields in this markup: name and address. Everything else is a recommended field. The value of the markup comes not from the number of fields but from how exactly the fields you write match the information actually visible on the page.
What does LocalBusiness schema do?
Structured data is a machine-readable summary of page content. The LocalBusiness type is the version of that summary dedicated to business information, and it does two jobs. First, it removes ambiguity: it does not leave it to guesswork which text fragment on the page is the name, which is the address and which is the opening hours. Second, it can make the page eligible for rich result displays in Google Search.
The phrase "can make eligible" was chosen carefully. Google's structured data guidelines state clearly that there is no guarantee the markup will be shown in search results. Even if your page passes the Rich Results Test without issue, Google may decide a plain text result is better for the user. Markup produces eligibility; it does not promise a display.
The second, more often overlooked limit is this: LocalBusiness markup describes your web page. It does not describe your Maps listing, your business card or your position in the local pack. The practical consequences of this distinction are explained later in the article.
Which fields are required and which are recommended?
Google's LocalBusiness documentation splits the fields in two. Only two are required.
- name: the business name, as plain text.
- address: the business's physical location, as a
PostalAddressobject. Google asks you to include as many subfields as possible in this object: street, district, city or region, postal code and country.
The list of recommended fields includes: telephone, openingHoursSpecification, geo, url, priceRange, department, menu, servesCuisine, review and aggregateRating. Google states that the more recommended properties you provide, the higher the quality of the result for users, and that additional information is taken into account in rich result ranking. So recommended fields are not decoration, but this is not a "more fields, better ranking" rule either. Every field you fill in needs a counterpart on the page.
There are also fields that do not appear in the list but are valid. In the schema.org hierarchy, LocalBusiness is a subtype of Organization. For that reason, Google also recommends following the Organization fields. In practice, this means you can use organization-level fields such as sameAs in your LocalBusiness block.
A warning is needed for review and rating fields: according to Google's definition, aggregateRating is a recommended field for sites that collect reviews about other local businesses. Marking up your own business's stars on your own site and expecting stars in search results is not correct usage, and ratings that do not come from real users are considered spam.
Choosing the right subtype is half the job
Google's documentation gives a clear instruction: use the most specific LocalBusiness subtype possible. Restaurant for a restaurant, Store for a shop, DaySpa for a beauty center, HealthClub for a gym, and so on. The generic LocalBusiness type is not the option to choose when a more specific type is defined for your business. The same principle is repeated in the general structured data guidelines: try to use the most specific applicable type and property names defined by schema.org.
If your business does several things at once, you write the types as an array. Google does not support using additionalType in this case.
{
"@context": "https://schema.org",
"@type": ["Electrician", "Plumber", "Locksmith"]
}Choosing a subtype is not a cosmetic preference, because some fields only make sense for certain subtypes. servesCuisine and menu are right for a restaurant, not for an auto repair shop. Once you choose the type correctly, which fields you need to fill in is also largely decided.
A working LocalBusiness JSON-LD example
The block below is a sample markup prepared for the location page of a single-location auto repair shop in Istanbul. It is placed in the page's <head> section as a script of type application/ld+json.
{
"@context": "https://schema.org",
"@type": "AutoRepair",
"name": "Kadıköy Oto Servis",
"url": "https://example.com/kadikoy-service",
"image": "https://example.com/images/service.jpg",
"telephone": "+902165550142",
"priceRange": "TRY 500 - TRY 4000",
"address": {
"@type": "PostalAddress",
"streetAddress": "Bağdat Caddesi No 122",
"addressLocality": "Kadıköy",
"addressRegion": "İstanbul",
"postalCode": "34710",
"addressCountry": "TR"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 40.985412,
"longitude": 29.056781
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:30",
"closes": "18:30"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "09:00",
"closes": "14:00"
}
],
"sameAs": [
"https://www.instagram.com/exampleservice",
"https://tr.linkedin.com/company/exampleservice"
]
}This block contains the two required fields (name and address), and all the rest are chosen from the recommended fields. Whichever page the block is placed on, it describes the business that page is about. The general structured data guidelines ask for this too: put structured data on the page it describes.
How should hours, location and phone fields be written?
Most accuracy errors show up in these three fields, because all three demand formatting discipline.
Phone. Writing the number in international format is the safest approach: the country code, followed by digits without spaces. You obviously need to show the number in a readable format on the page, but the value inside the markup must be resolvable by a machine to a single number. If there are several numbers on the page, put the main line for that location in the markup, not the call center.
Opening hours. openingHoursSpecification lets you write hours split into groups of days. Weekdays can be one block and Saturday a separate block. The real risk here is operational, not technical: forgetting to update the markup when hours change means showing the correct hours on the page while carrying the old hours in the source code. Feeding the hours from a single data source in the page template and printing both the visible text and the markup from there removes this risk entirely.
Location. The latitude and longitude in the geo field should point to where the business entrance actually is. Coordinates rounded to the district center or picked carelessly off a map are of no use to the page, because they send users to the wrong spot.
The priceRange field is also a frequent question. The information expected here is a short expression telling the reader the business's price class. Rather than writing a made-up range, the right approach is to carry the real range you already state on the page; if there is no such information on the page, leaving the field empty is better than marking up information that does not exist.
Does schema update your Google Business Profile?
No. This is the most common false expectation on the subject, and it comes from mixing up two different systems.
LocalBusiness markup lives in your site's code and relates to how your page appears in Google Search. Google Business Profile, on the other hand, is a separate product; information such as address, category, opening hours and service area is edited from the verified profile's own management screen. When you change the JSON-LD block on your site, the information in the profile does not change. The reverse is also true: updating the hours in your profile does not fix the hours in your site's source code.
This distinction also holds on the ranking side. Google Business Profile's help documentation says local results are mainly determined by three factors: relevance, distance and prominence. Relevance refers to how well the profile matches the query, distance to how far the searcher is from the business, and prominence to how well known the business is; for prominence, Google gives examples such as the number of websites linking to the business and the number of reviews it has received. A detailed breakdown of these three signals is in our local SEO guide.
LocalBusiness markup is not on that list. Schema is not a lever that moves you up in Maps. It is a supporting layer: it makes the business information on your site's page clearly readable for machines and helps you make sure that information does not contradict how it appears in your profile, in directories and on the page. Consistency itself is valuable; the mere presence of markup is not.
NAP consistency determines the value of schema
The strictest rule of structured data is the accuracy rule. Google's general guidelines say two things clearly: your structured data must be an accurate representation of the page content, and you must not mark up content that is not visible to readers of the page. So putting an address that is not written on the page into JSON-LD is a guideline violation, even if it produces technically valid code.
This rule ties markup directly to the issue of NAP consistency. The name, address and phone number on your site's contact page and the values in the JSON-LD block must be the same. A difference that amounts to just an abbreviation (such as "Cad." on the page and "Caddesi" in the code, the Turkish equivalent of "St." versus "Street") does not weaken the markup but is a sign of neglect; the real problem is differences that change the meaning, such as a branch number, floor information or a different phone line.
The right order is this: first make the visible information on the page accurate and current, then generate the markup from that information. Doing it the other way around leaves you carrying a business record in your source code that does not match reality.
How do you mark up multiple branches or departments?
Google's rule is simple: define each local business location as a separate LocalBusiness item. In practice, this means creating a separate location page for each branch and placing only that branch's markup on that page. Piling the information of five branches into a single block on the homepage does not help either users or machines.
If a single location contains departments with their own opening hours or their own phone number, the department field comes into play. In cases such as a pharmacy inside a store or a restaurant inside a hotel, each department is marked up as a separate item, and only the fields that differ from the main business are defined inside the department item. There is no need to repeat shared information inside the department.
Common LocalBusiness schema mistakes
- Marking up a virtual office or an address that does not exist. The
addressfield declares the business's physical location. An address used only for correspondence, or a record in a district where you have no presence, contradicts the reality the markup describes. - Embedding information in the code that is not visible on the page. The guidelines explicitly prohibit this. A field that sits in the code with no counterpart on screen lowers the trustworthiness of the entire markup.
- The phone number differing between the page and the code. This is the most common inconsistency and usually comes from updating the visible text during a site redesign while forgetting the markup in the template.
- Sticking with the generic type. Leaving it as
LocalBusinesswhen a defined subtype exists for the business needlessly blurs the information you give the machine. - Copying the same block onto every page. Structured data goes on the page it describes. Attaching a business block to the bottom of blog posts does not strengthen the markup.
- Giving yourself stars on your own site. Ratings and reviews that do not come from real users are considered spam.
- Writing hours and coordinates once and forgetting them. Markup is a live record that needs updating when the information changes.
Validating the markup and monitoring it afterwards
The first step is a syntax check. The Rich Results Test shows whether your block can be parsed, whether the required fields are present and which warnings come up. But the tool's limit is also clear: Google states that this tool cannot identify the problem when it is not caused by syntax. So even if the test gives you a green check, the tool will not tell you if your address is wrong or if the information you marked up is not visible on the page.
The second step is site-level monitoring. Search Console's structured data reports reveal errors that repeat at the template level rather than on individual pages. Since a single template error can affect hundreds of pages at once, this is the type of error you really need to find.
The third step is understanding the enforcement side correctly. When a manual action related to structured data is applied, the page is no longer eligible to appear as a rich result, but Google states that in this case the page's ranking in web search is not affected. If there is a manual action, the structured data on the page is ignored; once the problem is fixed, a reconsideration request can be submitted. This is the real answer to the question "will wrong schema penalize my site": the risk is not losing your rankings but losing your rich result eligibility.
Finally, patience is needed. After the markup is fixed, it takes time for Google to recrawl and reindex the page. Checking the search results a few hours after changing the code and drawing conclusions is misleading.
Frequently Asked Questions
Can a service-area business without a physical address use LocalBusiness?
In Google's LocalBusiness markup, address is a required field, so it is not possible to implement this markup completely without declaring an address. For businesses that do not serve customers at their own premises, hiding the address is something managed on the profile side; the markup on the site, however, must reflect the information you actually publish on the page.
Can I write the markup with microdata instead of JSON-LD?
Yes, Google supports more than one format. However, because a JSON-LD block sits in a single place independent of the HTML body, it is noticeably easier to maintain; microdata attributes are scattered through the body and break easily during theme updates.
I added the schema but nothing changed in search results. Did I do something wrong?
Not necessarily. Structured data does not always produce a visible change in results, and Google offers no such guarantee. First check whether the test shows any errors, then check whether the information you marked up is visible on the page. If both are clean, the markup is doing its job; the display decision is on Google's side.
