Schema.org structured data is a way of writing, in a page’s code, information that a person takes in at a glance but that a program can’t always interpret with certainty: who the business is, where it is, what its opening hours are, what a product is, how much it costs, when an event takes place. It is like putting a machine-readable label next to what you already write for people.
It is not a trick for climbing the results, nor a mandatory requirement. It is there to reduce ambiguity: it helps Google and AI assistants understand what the page is about and, in some cases, show it in a richer way. For an owner with no technical skills, the useful question is knowing what it is, where it really matters and how to check that it has been done properly.
What Google and AI read, without you seeing it
{ "@context": "https://schema.org", "@type": "LegalService", "name": "Example Firm", "areaServed": "Padova", "telephone": "+39 …" }
An example to understand it without technical jargon
Imagine a restaurant’s window. Passers-by see the sign, the menu, the opening hours written on the door. A program reading the restaurant’s web page sees only text: “Open Tuesday to Sunday, for lunch and dinner”. With structured data you state explicitly that this line contains the opening hours of a restaurant, that this address is its premises and that this number is the phone line for bookings. Nothing changes for the visitor, but the machine no longer has to guess.
What it is made of: types and properties
Schema.org is a vocabulary shared by the main search engines. For everything that exists in the real world it provides a type, and for each type a list of properties. Some of the most useful types for local businesses and professionals:
- Organization or LocalBusiness, and their subtypes such as restaurant, law firm, estate agency, gym: it describes who you are, your name, logo, address, opening hours, phone number and social profiles.
- Person: useful for a professional who presents themselves by name, role and area of expertise.
- Service and Product: they describe a service or a product, with name, description and, when it makes sense to show it, the price.
- Article: for blog posts, with title, author and publication date.
- FAQPage: for pages that gather questions and answers.
- Event: for courses, evenings, special openings, with date, place and how to sign up.
- BreadcrumbList: the navigation path, which helps show how the pages are organised.
Where they go and who writes them
The format Google recommends today is JSON-LD, a block of text inserted in the page, separate from the visible content. You don’t have to write it by hand: on WordPress many SEO plugins generate the basic data automatically, and for the more specific parts there are dedicated extensions, or you can ask whoever looks after the site. What matters is that the data is consistent with what the page really says.
What to expect, and what not to
Structured data guarantees nothing. Google decides case by case whether and how to use it, and some special presentations, such as rating stars or blocks of questions and answers, are reserved for certain categories of site and change over time. You can get more clarity for search engines without seeing any obvious change in your results listing. It is good underlying practice, not a shortcut.
It matters for generative AI too: stating name, services and contact details explicitly lowers the risk of an assistant reporting wrong information about your business. It is the same principle: less ambiguity, fewer errors.
Mistakes to avoid
The most important rule is that structured data must describe what is visible on the page. Marking up ratings as reviews that the visitor can’t read, inventing opening hours, declaring products you don’t sell or copying a competitor’s data breaks Google’s guidelines and can lead to exclusion from rich results. Out-of-date data does harm too: if you change phone number or address and the structured block stays the old one, you are communicating wrong information exactly where it is most likely to be picked up.
How to check that it works
You need free tools and no changes to the code. The first is Google’s Rich Results Test: you enter the address of a page and the tool tells you which structured data it recognises, and whether there are errors or warnings. The second is the Schema.org validator, which checks the general correctness of the markup even when it isn’t tied to a particular result. The third is Google Search Console, which in the section on enhancements lists, by type, the pages with valid data and those with problems, and also flags changes over time. A red error must be fixed; a yellow warning indicates a recommended field is missing, to be considered without hurry.
If you want someone to keep an eye, week after week, on how your site is read by Google and by AI assistants, Trovavio is the Italian tool that repeats this check every week.
Where to start tomorrow
Pick three pages on your site: the home page, the page of a main service and the contact page. Run each address through the Rich Results Test and note what is recognised. If the home page doesn’t declare that you are a local business with an address, opening hours and phone number, that is the first thing to do, through the SEO plugin you use or by asking whoever looks after the site. Then check that the data shown matches the real details and those on your Google listing. Only after that, if the site has a blog or pages with frequently asked questions, think about the more specific types. Stopping at the basic data, correct and up to date, is already a far sturdier result than rich but inaccurate markup.
