Local business schema: declare your business once, then refer to it

Your business should be described in your site's structured data exactly once, with a fixed identifier, and every other page should point back to that description instead of repeating it. When each page carries its own copy, the copies drift: different logos, different emails, different descriptions. Search engines then have to guess which version is true. We found this on most of the twelve sites we audited on 12 October, including our own.

What "declared once" means

Structured data on a page is usually a block of JSON-LD. A business can be described in it with a name, address, phone, logo and type. The part that matters here is the @id, a stable web address that names the entity. If the home page declares the business with @id of https://example.com.au/#business, any other page can say "the publisher of this article is #business" and a search engine understands it is the same thing, without a second description to disagree with the first.

The pattern that held up best on our sites used one identifier each for the organisation, the website and the business. A few others used a single /#business identifier on every page, which also worked.

What we found instead

Five sites had no @id on the main business at all, ours among them. On one builder's site an organisation and a construction business were declared separately on the same pages, two unconnected descriptions of one company, across the pages the audit sampled.

Our own site was the clearest example of drift. pagecog.com.au declared its organisation on 82 pages with no identifier and four properties that disagreed:

• the logo was one file on 82 pages and a different file on 54,
• the contact email was one address on 82 pages and another on 4,
• the address was just "AU" on 82 pages and a regional town address on 3,
• three different descriptions were in use.

Nobody decided on that mix. Pages were added at different times from different templates and each carried its own copy. Pagecog is a national business, so the regional address on three pages was also wrong for how we now describe ourselves.

Pointing back without breaking the checker

The obvious fix is to put a bare reference on every page: just {"@id": "…/#business"}. When we tested that against our audit tool, it failed. A bare reference used as an article's author or publisher gets flagged because the author needs a name. Declaring a full typed copy on every page tripped the "declared in full on every page" rule instead.

The shape that satisfied both, tested on a small local fixture and then on a live client site, was:

• a reference with the identifier and a name, and no type, wherever the business is the author, publisher or provider,
• the full typed description only on the home, about and contact pages,
• a website node on every page.

On that site the arrangement returned no entity findings across 116 pages.

A wrong type can steer the searches you appear for

Structured data does more than decorate a result. On an appliance repair site we declared the business as both a local business and a home and construction business. In schema.org that second type is the parent of plumbers, electricians, air conditioning contractors and roofers.

Search Console then showed searches such as tap maintenance, hot water repairs and air conditioning service in nearby suburbs landing on an appliance repair site. We searched the site's content for those words and found none of them for most of the queries. The only place they matched was the type declaration, so that is where we looked. The site is an appliance repairer, and schema.org has no appliance repair type, which leaves a choice between a broad correct type and a wrong specific one.

The way to handle it is to keep the broad type and carry the category in other fields, such as a short description of what the business does, a list of the topics it knows about, and a catalogue of its services. We have not measured a before and after on rankings, so treat this as a correction to what the markup claims, not a promise of movement.

A short check you can run

1. Open your home page source and your busiest service page, and search for application/ld+json.
2. Is the business described in both? Do the name, logo, email and address match exactly?
3. Does the markup use a type that matches what you actually do, and not a neighbouring trade?
4. Do blog posts name the business as publisher with the same name as the home page?

If the answers disagree, pick one set of facts for your business and make it the only set.

Where this fits

Structured data is tedious work that is easy to leave undone and hard to notice when it drifts, which suits a monthly arrangement better than a one-off job. Keeping markup consistent across a growing site is the kind of upkeep a monthly arrangement is for, and the SEO add-on is where the deeper audit sits. For the title and description side of the same audit, see what the check of twelve sites found.