Entity Schema for Small Sites: Organization, LocalBusiness

Before a search engine or an AI assistant can describe your business, it has to work out which business you are. Entity structured data answers that question in a form a machine can read: a block of JSON-LD that says this site belongs to this organization, person or local business, here is what it is called, where it is, who runs it, and here are its profiles elsewhere on the web.

For a small site, it is the most useful piece of structured data you can publish, and the one most often missing or broken. This guide covers what an entity is, which type to choose, complete examples you can adapt, how to connect every page to the same entity, the mistakes that quietly undo the work, and how to test it. It is part of our guide to agent-ready websites.

Why entities matter more now

Search used to be about matching words. Since Google introduced its Knowledge Graph in 2012, it has increasingly been about matching things: a specific company, a specific person, a specific clinic, each with known facts attached. AI assistants push this further. When someone asks "who runs Kaya Dental in Izmir and do they speak English," the assistant is not looking for a page with those words. It is trying to identify one real business and report facts about it.

That creates a practical problem for small businesses. Names repeat. There are many companies called Beste, many clinics called Kaya, many consultants with the same name as you. An assistant that cannot tell them apart will mix them up, merge their details or skip you to avoid being wrong.

Entity data on your own site is your statement of identity. It does not guarantee anything, and Google is clear that structured data helps it understand a page rather than earning automatic placement. But it gives every system that reads your site the same unambiguous starting point, and everything else on the web can be matched against it.

The vocabulary: Schema.org and JSON-LD

Two terms come up constantly.

Schema.org is a shared vocabulary for describing things on the web, founded in 2011 by Google, Microsoft, Yahoo and Yandex. It defines types such as Organization, Person and LocalBusiness, and properties such as name, address and founder. Search engines and many AI systems understand it.

JSON-LD is the format Google recommends for adding Schema.org data to a page. It is a script block in the page's HTML that visitors never see. It sits apart from the visible content, which makes it easy to generate and maintain.

The Schema.org Organization type alone has dozens of properties. You need a small, accurate subset.

Choosing the right type

Pick the type a visitor would use to describe you, then go as specific as Schema.org allows.

Organization is for a company, a studio, a startup or a non-profit without a location customers visit. A software company, an online agency, an association.

LocalBusiness is for a business with a physical place customers come to, or a defined area it serves: a clinic, a restaurant, a salon, a plumber. It is a subtype of Organization that adds address, opening hours, phone and service area. Google's LocalBusiness documentation lists the properties it reads. Schema.org has more specific subtypes, and you should use one when it fits: Dentist, Restaurant, HairSalon, LegalService, RealEstateAgent, AutoRepair and many more.

Person is for an individual working under their own name: a freelancer, a consultant, an author, a photographer. Name, job title, the organization they work for if any, and profiles.

A short decision guide:

Situation	Type
Customers visit your premises	LocalBusiness, or a subtype like Dentist
You serve a local area but have no premises	LocalBusiness with areaServed
Company that works online or with clients anywhere	Organization
You trade under your own name	Person
Company with a well-known founder	Organization, with the founder as a Person
Several branches	One Organization, plus a LocalBusiness for each branch

Two common mistakes: a freelancer marking up as Organization because it sounds bigger, and a clinic marking up as plain Organization because it is legally a company. Use what the visitor would call you.

What to include

For an Organization, Google's Organization documentation recommends, among others: name, alternateName, url, logo, description, email, telephone, address, foundingDate, founder, sameAs, and identifiers such as a VAT or tax ID where relevant. None are strictly required, but name, url, logo and sameAs do most of the work.

For a LocalBusiness, add: address as a PostalAddress, telephone, openingHoursSpecification, geo coordinates, priceRange and areaServed if you travel to customers.

For a Person: name, jobTitle, worksFor, url, image and sameAs.

Every value must match what is visible on the site. Google's structured data guidelines are explicit that markup describing content users cannot see, or content that is misleading, can lead to a manual action. Practically: the name in the JSON-LD is the name in your footer, the address is the address on your contact page, the founder is a real person named on the site.

Complete examples

Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Northwind Studio",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "description": "Brand and web design studio for hospitality businesses.",
  "foundingDate": "2019-03-01",
  "founder": { "@id": "https://example.com/#founder" },
  "email": "hello@example.com",
  "sameAs": [
    "https://www.linkedin.com/company/northwind-studio",
    "https://www.instagram.com/northwindstudio"
  ]
}

LocalBusiness

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.com/#business",
  "name": "Kaya Dental Clinic",
  "url": "https://example.com/",
  "image": "https://example.com/clinic.jpg",
  "telephone": "+90 232 000 00 00",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Cemal Gürsel Cd. 100",
    "addressLocality": "Karşıyaka",
    "addressRegion": "İzmir",
    "postalCode": "35530",
    "addressCountry": "TR"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "09:00",
    "closes": "18:00"
  }],
  "sameAs": ["https://www.instagram.com/kayadental"]
}

Person

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/#founder",
  "name": "Deniz Arslan",
  "jobTitle": "Founder and Creative Director",
  "worksFor": { "@id": "https://example.com/#organization" },
  "url": "https://example.com/about",
  "sameAs": ["https://www.linkedin.com/in/denizarslan"]
}

Notice the @id values and how they point at each other. That is the subject of the next section, and the part most sites get wrong.

One entity, everywhere: the @id graph

Each entity gets an @id, a stable identifier, usually your site URL with a fragment such as #organization. The fragment does not have to be a real anchor on the page. It is a name, and the only rule is that it stays the same everywhere.

The homepage declares the full entity once. Every other page refers to it by that id:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to choose a dental implant",
  "author": { "@id": "https://example.com/#founder" },
  "publisher": { "@id": "https://example.com/#organization" },
  "datePublished": "2026-10-01"
}

The result is a connected graph instead of separate blocks. A machine reading this post can follow the ids back to the organization, its founder, its address and its profiles. Without the ids, the post is an anonymous page with a name typed into it.

Most hand-built sites break this quietly. The homepage has an Organization block from one plugin, the posts have an author block from another, product pages have a brand from a third, and nothing connects them. Each block validates on its own. Together they describe three slightly different businesses.

sameAs: proving you are you

sameAs lists URLs that are about the same entity. It is how a machine confirms that the business on your site is the same one on LinkedIn, Instagram or a public registry. The Schema.org definition describes it as a reference page that unambiguously indicates the item's identity.

Good candidates, roughly in order of strength:

Wikidata and Wikipedia, if an entry exists. Wikidata is a structured knowledge base that many systems, including search engines, draw on. Do not create an entry for a business that does not meet its notability rules; it will be removed.
Official registries such as a company register or a professional body listing your practice.
Social profiles you control: LinkedIn, Instagram, X, YouTube, Facebook.
Industry profiles: Crunchbase for startups, GitHub for developer tools, Behance for designers.

Three rules:

Only profiles that are clearly yours. A directory page with your old address is not confirmation; it is a contradiction you have just endorsed.
Link back. Each profile should link to your site. Two-way links are much stronger evidence than one-way.
Keep it current. A link to a deleted account weakens the claim. Five accurate links beat twenty doubtful ones.

Consistency off your site

Entity data is a claim. Systems check it against everything else they can find. For a local business the most important outside source is your Google Business Profile, followed by maps, review sites and directories.

The old local SEO principle of consistent NAP, meaning name, address and phone, applies directly. If your site says "Kaya Dental Clinic," your Google profile says "Kaya Diş Kliniği," and a directory lists a phone number you stopped using in 2021, an assistant has three versions of you to reconcile. It may pick the wrong one, or describe you with low confidence.

A useful exercise is to list every place your business appears and make the core facts identical. If the name genuinely differs by language, say so in the markup with alternateName.

Multilingual and multi-location sites

Multiple languages. The entity is the same business in every language, so it should keep the same @id across all versions. Translate the description; keep the name, address and identifiers identical. Two different ids for the English and Turkish pages tell a machine you are two businesses. The language side is covered in Multilingual Sites and AI Search.

Multiple locations. Declare the parent Organization once. Give each branch its own LocalBusiness with its own @id, address and hours, a parentOrganization pointing at the parent, and ideally its own page on the site.

Mistakes that quietly undo the work

Several conflicting blocks. Theme, SEO plugin and a reviews widget each output their own Organization. Pick one source and switch the others off.
A generic type. "Organization" for a restaurant throws away the most useful information.
Missing or changing @id. No id, or a different one on each page, means no graph.
Logo problems. Google asks for a logo at least 112 by 112 pixels that is crawlable and indexable. A logo in an SVG sprite or behind a login is invisible.
Facts the page does not show. Opening hours in the markup that appear nowhere on the site.
Rating stars for yourself. Since a 2019 change, reviews a business collects and marks up about itself on its own site are not eligible for star rich results when the type is LocalBusiness or Organization. The markup is not penalized, it simply earns nothing. Ratings that are made up or copied from other sites are a different matter and do break Google's review snippet guidelines.
Set and forget. The business moves, changes its phone number or adds a branch, and the markup still describes 2022.

How to test it

Schema Markup Validator. Paste your homepage URL into the Schema Markup Validator. It shows every Schema.org block, including types Google does not use for rich results.
Rich Results Test. Google's Rich Results Test shows what Google itself can read and flags errors that affect its features.
Check the graph. Open a blog post in the validator and confirm the author and publisher are references to the same ids as your homepage, not repeated names.
Compare with the page. Every value in the markup should be visible somewhere on the site.
Search Console. After publishing, the Enhancements section of Google Search Console reports errors over time for the structured data types it covers. Not every type has a report, so if yours is not listed there, the two validators above remain the check.
Ask an assistant. Ask "who runs [your business]" and "where is [your business]" in two or three assistants. Compare the answers with your entity data. The full method is in How to Audit What ChatGPT Says About Your Business.

What entity data will not do

It will not make an unknown business famous, put you in a knowledge panel on demand or force an assistant to cite you. Google says plainly that structured data does not guarantee any feature. What it does is remove ambiguity. For a small business that shares a name with others, or has inconsistent details scattered across the web, removing ambiguity is often the difference between being described correctly and being described as someone else.

How this works in Beste

Every Beste site publishes an entity graph in JSON-LD on every page. You declare the entity once in Entity Identity in Studio: Organization, Person or LocalBusiness, with legal name, founder, founding date, job title, contact point, postal address and sameAs links. If you fill in nothing, a default Organization is created from the site name, so there is always a consistent entity to read.

The entity has one canonical @id, and pages, posts and products all reference it, so the graph described above is built for you and cannot fall out of sync. The same entity appears in your /llms.txt, covered in llms.txt Explained, and carries unchanged across every language of a multilingual site. The agent-ready websites page and the SEO-friendly structure page describe the rest of what is published.

Sources

Checked in October 2026.