Structured Data for Business Profile Pages

A business profile page is written for people. A person reads the name, the description and the address and understands them without effort. A machine reading the same page has to guess: is this string a company name or a slogan? Is that number a phone number or a postcode? Structured data removes the guesswork by labelling the facts in a standard way.

This article explains what structured data is, which properties matter for business profiles, how to keep markup honest and how to maintain it. It is written for editors and for developers who work with them.

What structured data is

Structured data is a way of describing the content of a page using a shared vocabulary, so that software can understand it. The most widely used vocabulary is schema.org. On a profile page, it tells machines: this is an organisation, its name is this, its website is that, its address is this, its founding date is that and these other pages are about the same organisation.

It is usually added to the page as a block of text in a standard format, separate from the visible content, or embedded in the page's markup. Readers do not see it. Search engines and other tools read it.

Why bother

Structured data is not magic, and it does not guarantee any special treatment. But it can help in several ways.

Clarity. It states facts unambiguously, reducing misreadings.

Connection. It links the profile to the organisation's other pages and profiles, helping systems understand that they refer to the same entity.

Consistency. It encourages you to keep the visible facts and the underlying data aligned.

Reuse. The same facts can feed search features, assistants and other tools that read the page.

Google's documentation on organisation markup says that no properties are strictly required, and it suggests adding as many relevant ones as apply, prioritising those that indicate real-world presence and online visibility. That is a good principle to follow: be complete about what is true, and silent about what is not.

Choose the right types

Schema.org offers many types. Two matter most for business profiles.

Organization

Described as a school, NGO, corporation, club or similar, the Organization type suits businesses and other bodies in general. It includes properties such as name, legal name, URL, logo, description, address, telephone, email, founding date, founder, number of employees and same-as links.

LocalBusiness

A more specific type, described as a particular physical business or branch of an organisation, such as a restaurant or a medical practice. It adds properties such as opening hours, geographic coordinates, area served and price range. Use it for businesses that customers visit or that serve a defined area.

There are also more specific subtypes for particular kinds of business. Choose the most accurate type, and do not use a type that does not fit. For a profile of a company with several branches, consider describing the company as an Organization and each branch as a LocalBusiness linked to it.

The properties that matter

For a typical profile, these are the most valuable.

name. The name the business uses publicly, matching the page.

legalName. The registered name, if different, as described in schema.org: the official name of the organisation, for example the registered company name.

url. The business's main website.

logo. A representative image. Google's documentation recommends a logo of a minimum size and suitable for use in search features.

description. A short description matching the visible text.

address. A postal address with street, locality, postal code and country, expressed in the parts schema.org defines. Use the visiting address if customers visit.

telephone and email. Public contact details. Google describes the telephone property as a business phone number meant to be the primary contact method.

foundingDate. The date the business started, in the sense your profile defines.

founder. Named founders, where they agree, ideally linked to their own pages.

numberOfEmployees. A value or range, if you show it with a date.

sameAs. Links to other pages that identify the same organisation, such as official social and professional profiles. Schema.org describes this property as a URL of a reference page that unambiguously indicates the item's identity.

openingHours, areaServed, geo. For local businesses.

You do not need all of them. Include those you can fill accurately.

Rule one: match what is visible

The most important principle is that markup must describe what is on the page. If your markup says the business opened in 2012 and the visible text says 2014, you have created a conflict, and search systems may distrust both. If your markup includes a phone number that is not shown, a reader cannot verify it.

Practical consequences:

• Generate markup from the same data that produces the visible page, so that they cannot drift apart.
• Do not add claims that appear only in markup, such as ratings or awards.
• Do not mark up content that is hidden from users.
• Update both together when facts change.

Google's guidance on helpful content stresses honesty about who is behind a page and about what is claimed. Matching markup to the page is the technical form of that honesty.

Rule two: be accurate about what you do not know

If you do not know a value, leave the property out. Do not fill it with a guess or a placeholder. A missing property is neutral. A wrong one is misleading. Where your profile uses labels such as "not stated" or "not disclosed", do not turn them into data.

Format and publish

The most common format is a block of structured text in a standard notation, placed in the page's head or body. Developers will know the details. A few cautions:

• Valid syntax. A missing comma or bracket can make the whole block unreadable.
• Correct types for values. Dates in standard format, URLs as full addresses, country codes as recommended.
• One main entity per profile page, clearly identified, with related entities linked.
• Stable identifiers. Where you can, give the entity an address that stays the same, so that other pages can refer to it.
• Avoid duplication. Do not add the same block twice.

Test it

Test every template and a sample of real pages.

• Use the validators provided by search engines and the schema.org community to check syntax and types.
• Read the warnings, not only the errors. Warnings often point to missing recommended properties.
• View the rendered page and the markup side by side and compare every value.
• Test after changes to templates or data.
• Monitor reports from search tools, such as Search Console, which Google describes as a service that helps you monitor and troubleshoot your site's presence in search results.

Treat testing as part of maintenance, not a one-off.

Maintain it

Markup goes stale like any data. Build maintenance into your routine.

• Review templates when the schema vocabulary or search guidelines change.
• Audit a sample of pages every quarter, comparing markup with the page and with reality.
• Correct errors openly and update dates.
• Remove markup for businesses that have closed or asked to be removed.
• Keep a short document explaining which properties you use and why.

Think about accessibility and performance

Structured data does not replace accessible, fast pages. Make sure the visible content is real text, with clear headings, alternative text and good contrast. Keep the markup light, so that it does not slow the page. Google's Core Web Vitals give targets for loading and stability that apply to the page as a whole.

Respect privacy

Markup is public. Do not include personal data that is not already public on the page, and do not publish private contact details. For sole traders and home-based businesses, consider whether to show an address at all. The Information Commissioner's Office offers advice for small organisations on handling personal information.

A worked example

A directory builds a template for business profile pages. The data model has fields for name, legal name, description, website, logo, address, phone, email, founding date, team size range, social links and last-checked date. The template renders the visible fact box from those fields, and the same fields generate a block of markup of type Organization or LocalBusiness.

Where the business has no public phone, the property is omitted. Where the founding date is just a year, the markup carries a year. Social links appear in both the page and the same-as property only if they have passed checks for being official and active. The team size range is marked up only with its date shown on the page.

The developers test with a validator, fix two warnings about missing logos and add a check to the build that fails if any value in the markup does not appear in the page. Each quarter, an editor spot-checks twenty pages. After a few months, the directory sees fewer inconsistencies between what the pages say and what search results show.

Common mistakes

1. Markup that disagrees with the page.
2. Invented values.
3. Wrong type for the business.
4. Hidden content in markup.
5. Never testing.
6. Forgetting to update.
7. Publishing private data.

A checklist

• Correct type chosen
• Key properties filled from the same data as the page
• Unknowns omitted
• Valid syntax and types
• Validated and reviewed warnings
• Quarterly sample audits
• Privacy considered
• Documentation kept

The developers page here describes the free API and MCP server that expose listing data in structured form, the categories and search pages show how profiles are found and the submit page starts a profile, and the facts behind it are edited from the account.

Frequently asked questions

Does structured data improve rankings? It can help systems understand a page, but it is not a ranking shortcut. Do it because it makes your information clearer.

Can I add reviews to markup? Only if the guidelines allow and the reviews are genuine and visible on the page. Take care.

Who should own the markup? Someone who understands both the data and the templates, with an editor to check the content.