The four schema types a local business actually needs, written correctly and validated. Everything else is decoration.
Structured data is the explicit, machine-readable layer of information on a page, embedded as JSON-LD. It tells the search engines and the AI assistants what the page is about, who wrote it, what it is for, and which entity it represents. Without structured data, the search engine has to infer everything from the page content, which is unreliable and easy to get wrong. With structured data, the search engine has an explicit map of the page.
The four types that matter for local businesses are ProfessionalService, WebPage, Place, and FAQPage. The other 200+ schema types are mostly noise. I write the four that matter and skip the rest.
Schema markup is the formal name for the structured data format that Google, Bing, and the major search engines agree on. The current format is JSON-LD (a block of JavaScript-style object notation embedded in the page). The format is not the hard part. The hard part is choosing the right schema types, filling in the right fields, and getting the cross-references right.
A common mistake is to over-engineer schema. I have seen local business sites with 15 different schema types on a single page, half of them wrong. The right answer is four types, fully populated, cross-referenced correctly, and validated before the page ships.
ProfessionalService is the schema.org type for a service-oriented business that does not fit a more specific category. It is the right root @type for solo consultants, agencies, law firms, accounting practices, financial advisers, marketing consultancies, and similar professional services. It is a subclass of LocalBusiness in the schema.org hierarchy, which is why it carries the address and the opening-hours-like fields.
Use ProfessionalService on the homepage of a professional service business, and reference the same entity from every other page. The reference is what makes the entity layer work; the same ProfessionalService block on every page reinforces it.
LocalBusiness is the broader schema.org type for any business with a physical location. ProfessionalService is a subclass of LocalBusiness. For a solo consultant or an agency, ProfessionalService is the more accurate type. For a restaurant, a shop, or a hotel, a more specific subclass (Restaurant, Store, Hotel) is the right choice.
Most local business sites that I am asked to fix have LocalBusiness where they should have ProfessionalService, or a generic type where they should have a specific subclass. The fix is a one-line change, but it is the right change.
Add a FAQPage block at the bottom of the page, with the questions as the @graph nodes and the answers as the @graph node text. The block is JSON-LD, embedded in the page. Validate it with Google's Rich Results Test before the page goes live. If the test returns errors, the block is wrong; if it returns warnings, the block is fine but could be tightened.
Most FAQPage blocks I see in the wild are wrong in one of three ways: the question is in the answer field instead of the question field, the answer is in the question field instead of the answer field, or the block is missing the @graph wrapper. I fix all three as part of the schema engagement.
BreadcrumbList is the schema for the breadcrumb trail at the top of a page. Google uses it to confirm the page's position in the site hierarchy. It is not a major ranking factor, but it is a quick win: the breadcrumb shows up in the search result, the schema validates cleanly, and the implementation is a 10-line block per page.
I add a BreadcrumbList block to every page on a website as part of the schema engagement. The block references the same ProfessionalService entity as the root @type, which reinforces the entity layer across the site.
Two tools, in this order. Google's Rich Results Test (search.google.com/test/rich-results) for the Google-specific types (FAQPage, BreadcrumbList, Product, Recipe, and a few others). Schema.org's validator (validator.schema.org) for the schema.org types in general. If both pass, the block is correct. If either fails, the block is wrong; do not ship it.
I validate every block before a page goes live. The validation is part of the schema engagement, not an optional add-on.
Four. ProfessionalService (the business itself), WebPage (the page), Place (the location, on city pages), and FAQPage (the questions and answers on the page). The four together cover 90% of what a local business site needs. The remaining 10% is breadcrumbs, organisation markup, and the occasional Product or Review block for specific page types.
Most local business sites either under-engineer (no schema, or only the root @type) or over-engineer (15 types, half of them wrong). The right answer is the four that matter, fully populated, cross-referenced correctly, validated before launch.
Yes, indirectly. Wrong schema does not trigger a manual action the way wrong backlinks do, but it confuses the search engine. The engine cannot use the structured data to confirm the entity, so the entity layer is weaker, so the AI assistants are less likely to cite the page. The compounding effect is a slow loss of ground to competitors with cleaner schema.
The fix is a schema audit, a 1-2 week project that identifies the wrong blocks, rewrites them to the right four types, and validates the result. I run the audit as a standalone deliverable.
Three rules. First, the block is a single script tag of type application/ld+json, embedded in the page head or at the end of the body. Second, the block contains one @graph array, with the entity nodes as array members. Third, each entity node has its own @context, @type, and properties, and references the other entity nodes by @id.
The @id pattern is what makes the cross-references work. Every entity on the page has a unique @id, and every other entity that references it uses the @id rather than repeating the properties. The pattern is the same for every page, which makes the schema easy to maintain.
I do schema work for established local businesses across the Costa del Sol (Marbella, Estepona, Puerto Banus, San Pedro de Alcantara, Mijas, Fuengirola, Benalmadena, Torremolinos, Malaga) plus international clients. Reply within 24 hours.
Pick the option that fits. I read every message and reply within 24 hours, every working day.
Structured data is the explicit, machine-readable layer on a page, embedded as JSON-LD. It tells the search engines and AI assistants what the page is about, who wrote it, what it is for, and which entity it represents. The four types that matter for local businesses are ProfessionalService, WebPage, Place, and FAQPage. The other 200+ schema types are mostly noise.
Schema markup is the formal name for the structured data format that Google, Bing, and the major search engines agree on. The current format is JSON-LD. The hard part is choosing the right schema types, filling in the right fields, and getting the cross-references right. Most sites over-engineer it; the right answer is four types, fully populated, cross-referenced correctly, and validated before the page ships.
ProfessionalService is the schema.org type for a service-oriented business that does not fit a more specific category. It is the right root @type for solo consultants, agencies, law firms, accounting practices, and similar professional services. Use ProfessionalService on the homepage and reference the same entity from every other page on the site.
LocalBusiness is the broader schema.org type for any business with a physical location. ProfessionalService is a subclass of LocalBusiness. For a solo consultant or an agency, ProfessionalService is the more accurate type. Most local business sites I am asked to fix have LocalBusiness where they should have ProfessionalService. The fix is a one-line change, but it is the right change.
Add a FAQPage block at the bottom of the page, with the questions as the @graph nodes and the answers as the @graph node text. Validate it with Google's Rich Results Test before the page goes live. Most FAQPage blocks I see in the wild have the question in the answer field, the answer in the question field, or a missing @graph wrapper. I fix all three as part of the schema engagement.
BreadcrumbList is the schema for the breadcrumb trail at the top of a page. Google uses it to confirm the page's position in the site hierarchy. The breadcrumb shows up in the search result, the schema validates cleanly, and the implementation is a 10-line block per page. I add a BreadcrumbList block to every page as part of the schema engagement.
Two tools. Google's Rich Results Test for the Google-specific types (FAQPage, BreadcrumbList, Product, Recipe). Schema.org's validator for the schema.org types in general. If both pass, the block is correct. I validate every block before a page goes live; the validation is part of the schema engagement, not an optional add-on.
Four. ProfessionalService (the business itself), WebPage (the page), Place (the location, on city pages), and FAQPage (the questions and answers on the page). The four together cover 90% of what a local business site needs. The remaining 10% is breadcrumbs, organisation markup, and the occasional Product or Review block.
Yes, indirectly. Wrong schema does not trigger a manual action but it confuses the search engine, weakens the entity layer, and reduces the likelihood of AI citations. The fix is a schema audit, a 1-2 week project that identifies the wrong blocks, rewrites them to the right four types, and validates the result.
Three rules. The block is a single script tag of type application/ld+json. The block contains one @graph array, with the entity nodes as array members. Each entity node has its own @context, @type, and properties, and references the other entity nodes by @id. The @id pattern is what makes the cross-references work.