Organisation schema for a clear business identity
A business website should make it obvious who is behind the service. Organisation structured data provides another way to describe the same facts for systems that process the page. It is especially useful when a trading brand and its legal operator have different names.
The starting point is accurate visible information. Markup cannot turn an invented office, unsupported certification or outdated telephone number into a reliable fact. It should describe the website, not contradict it.
What Schema.org and JSON-LD mean
Schema.org is a shared vocabulary for describing entities such as organisations, people and products. JSON-LD is one format used to express those descriptions. The Organisation type reference lists available properties; choose the ones that actually fit your business.
Google says Organisation markup can help it understand administrative details and distinguish an organisation. Its guidance explains supported properties and implementation considerations. That does not amount to a ranking or AI citation guarantee. Google Organisation guidance.
Decide which organisation you are describing
Record the legal company name, trading name, website, real address where appropriate and public contact details. A brand operated by another company should have that relationship modelled consistently rather than being assigned invented corporate details.
For ResaHost, the underlying operator is Resaco Oy, business ID 3259870-5, based in Rovaniemi, Finland. The server location is a separate fact. A data centre must not be presented as the company's customer-facing office.
Do not mechanically convert a local business registration number into a VAT identifier. Use the correct property and the actual identifier for each purpose. Likewise, only list languages in which the stated service is genuinely available.
Build a small, correct description
| Information | What to verify |
|---|---|
| Name and legal name | Match the actual brand and operator |
| Website URL | Use the public canonical destination |
| Contact details | Match the visible contact page |
| Address | Describe a real, relevant location |
| Logo | Use a public image that represents the organisation |
| Official profile links | Point to the same entity, not a similar name |
Use a stable identifier in the site's data model so different pages can refer to the same organisation. Have the developer integrate it with existing markup rather than generating a new disconnected entity on every page.
The sameAs relationship should point to genuine identity references. More links are not inherently better. Do not add a fabricated social profile or a loosely related directory category. An organisation does not need an encyclopedia entry to justify publishing accurate schema.
Choose related types for their actual purpose
A customer-facing local business may warrant a suitable LocalBusiness subtype and verified opening hours. A website itself can be described separately from the organisation that publishes it. An article can identify its real author and publisher.
Do not add every type to every page. A service business without walk-in premises should not invent a local storefront. FAQs should exist because customers need the answers, not because someone promises a guaranteed rich result or AI quotation.
Our AI search fundamentals guide explains how identity fits into the wider website work. Structured data is one supporting component.
Implement without duplicating old errors
WordPress themes and SEO plugins may already generate organisation data. Check the rendered page before adding another plugin or custom block. Two descriptions are not automatically invalid, but conflicting entities and duplicate contradictory facts make maintenance difficult.
For a static site or a custom application, centralise the organisation facts in the site's normal content or configuration model. Keep language-specific descriptions aligned with the same real organisation. Do not allow translation to create different telephone numbers, registration details or service promises.
Managed WordPress maintenance provides the technical maintenance context. Agree any schema implementation or content correction work explicitly so it has a responsible owner.
Validate facts as well as syntax
Run the published page through a schema validator and any relevant search testing tool. Read the warnings in context: a tool's missing-property message does not justify inventing a value.
Then inspect the visible page and every factual field. Check that the logo loads, official links resolve and contacts are current. Test again after plugin or template changes. A syntactically valid description with the wrong company address is still wrong.
Include the check in your AI visibility audit and normal website content review. If an assistant still confuses your company, follow the AI information correction process instead of repeatedly adding more markup.
Frequently asked questions
Is schema compulsory?
It is a useful implementation choice when appropriate, not a universal condition for operating a business website.
When should it change?
Whenever the underlying facts change, with verification after technical releases that can affect the generated markup.