Schema Markup for Small Organisations on WordPress: a Marketing Manager’s Guide

What schema markup should a small organisation use on WordPress?

Schema markup is structured data: machine-readable information that describes what a page or entity represents. For a small organisation, the practical question is rarely “do we have schema?” It is “does the markup describe the right entity, is it accurate, and is one maintainable system responsible for it?”

Google says Organization structured data on a home page or a single page about the organisation can help it understand administrative details and disambiguate the organisation in Search. Google currently lists no required properties for Organization; the goal is to provide the relevant properties that genuinely apply, rather than filling every possible field. See Google’s Organization structured data guidance.

On WordPress, first inspect what the live page already outputs. An SEO plugin, ecommerce plugin, theme, page builder, or custom code may already generate JSON-LD. Adding a second implementation without checking the first can create duplicate or conflicting statements about the same business.

What schema can — and cannot — do for search visibility

Structured data can make information more explicit to Google and can make eligible content available for richer search features. It is not a switch that guarantees a rich result, a knowledge panel change, a higher ranking, or more clicks. Google explicitly says that even correctly marked-up pages are not guaranteed to receive a rich result.

• It can clarify entities and page content. For example, organisation markup can provide a name, URL, logo, telephone number, address, and other relevant administrative details.
• It can create eligibility for supported search features. Eligibility depends on the specific structured data type, the required fields for that feature, the page content, and Google’s policies.
• It does not guarantee display. Google may choose a normal text result even when the markup is valid. Its general structured data guidelines make that distinction clear.
• It is not a special AI-search shortcut. Google’s 2026 guidance says there is no special schema.org markup required for its generative AI search features. Structured data still matters as part of normal SEO because it can support rich-result eligibility, not because it unlocks a separate AI ranking layer. See Google’s generative AI Search guidance.

This is an important management distinction: the success criterion is not “we installed schema”. It is “the live markup truthfully represents the business and the relevant page, passes the right validation checks, and remains maintainable when business details change”.

Choose the schema type from the business model, not from an SEO checklist

The most common mistake is starting with a generic type and adding properties until the markup looks complete. Start with the real-world entity instead.

• General company, charity, association, or service organisation without a customer-facing physical branch: use the most specific appropriate subtype of Organization that genuinely fits. For many small organisations, plain Organization is a reasonable site-level entity. Google recommends placing organisation details on the home page or a single page that describes the organisation rather than repeating the same block everywhere.
• Physical shop, restaurant, clinic, office, or branch that customers visit: use the most specific applicable LocalBusiness subtype. LocalBusiness is already a subtype of Organization; it is not simply an extra label to bolt onto an unrelated organisation block. Google says each local business location should be defined as its own local business entity, and its Local Business rich-result documentation requires at least name and address. Review Google’s LocalBusiness structured data requirements.
• Online retailer: Google recommends a more specific Organization subtype such as OnlineStore where it accurately describes the business. Product and merchant markup are separate page- or commerce-level concerns.
• Articles, products, events, videos, breadcrumbs, and other page content: add the relevant page-specific type only when that content is actually present. Multiple structured data items on one page are not inherently a problem; Google can understand multiple related or distinct items when they accurately represent visible content.

Do not invent a physical address to satisfy LocalBusiness requirements. If the organisation does not have a customer-facing location that the page genuinely represents, forcing local-business markup creates a data-quality problem rather than an SEO advantage. If local search visibility is the real task, structured data should sit alongside accurate business information and a maintained Google Business Profile, not replace it.

Diagnostic checklist: audit the WordPress output before changing it

Before installing a new plugin or pasting JSON-LD into a template, capture the current state. A marketing manager should be able to answer the following questions before a developer starts work.

1. What structured data is already present? Test the live URL and inspect the rendered source for JSON-LD. Record each top-level type, such as Organization, WebSite, Article, Product, or LocalBusiness.
2. Which WordPress component owns each item? Identify whether the output comes from an SEO plugin, ecommerce plugin, theme, page builder, or custom code. If nobody knows where it comes from, future changes will be fragile.
3. Are duplicate items describing the same entity? Two systems may both emit organisation data. Duplication is not automatically invalid, but conflicting names, URLs, logos, telephone numbers, addresses, or identifiers create ambiguity and maintenance risk.
4. Does the type match the real organisation? A local branch and a national online-only service are not the same entity. Do not use LocalBusiness merely because “local SEO” is a target.
5. Are the facts current? Check business name, canonical website URL, logo, contact details, location, opening hours, and official profile links against the information users actually see.
6. Are required and recommended properties being confused? Google currently has no required fields for its Organization guidance, while LocalBusiness has required fields for rich-result eligibility. A warning about a recommended field is not the same as a blocking error.
7. Does the markup represent visible, relevant content? Google’s quality guidelines say structured data should be a true representation of the page and should not be used for hidden, irrelevant, or misleading claims.

If an audit reports missing or invalid structured data, separate “schema.org vocabulary is valid” from “Google supports a search feature for this type”. The two are not identical. ScanMySEO’s guide to missing required schemas can help you frame that audit finding before deciding whether it needs implementation work.

Red flags worth escalating

• The same organisation is emitted twice with different names, URLs, logos, or addresses.
• A plugin update has changed or removed a previously valid structured data item across many pages.
• LocalBusiness markup uses a made-up, private, or outdated address simply to satisfy a validator.
• The markup describes services, reviews, products, people, or locations that are not represented on the page.
• A page passes a generic schema validator, but the team assumes this means Google must show a rich result.
• The markup is technically valid but no one knows which WordPress component should be updated when the business details change.

Implementation workflow: fix the source of truth, not just the code snippet

Google supports JSON-LD, Microdata, and RDFa for rich-result eligibility and recommends JSON-LD. For most WordPress teams, JSON-LD is usually the easiest format to maintain because it can be managed separately from visible HTML. The more important decision, however, is ownership.

1. Choose one primary owner for site-level organisation data. If an existing plugin already emits accurate Organization data, configure that source rather than creating a second competing block.
2. Keep different entities separate when they really are different. It can be legitimate for an article page to contain an Article item plus site-level organisation or website information. The aim is not “one schema block per page”; it is coherent, non-conflicting data.
3. Choose the most specific accurate type. For a local location, follow the relevant LocalBusiness subtype guidance. For an online store, consider the appropriate Organization subtype. Do not select a type because it sounds commercially attractive.
4. Add only properties you can maintain. A short, accurate entity is better than a large JSON-LD object full of stale or speculative fields.
5. Make the visible site and structured data agree. If the footer, contact page, and schema contain different phone numbers or addresses, decide which source is correct before deployment.
6. Validate before and after release. Test the candidate markup, deploy to a small number of pages where possible, then inspect the live URL that Google can access.

A maintainable Organization JSON-LD example

This example is deliberately small. It demonstrates an organisation-level entity without pretending every possible property is necessary. Use real business details, and only add properties that apply.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Services Ltd",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "email": "hello@example.com",
  "telephone": "+44 20 7946 0123"
}
</script>

If the same business is genuinely a customer-facing local location, do not simply paste extra local fields into this example and assume the job is done. Select the most specific appropriate LocalBusiness subtype and follow Google’s Local Business requirements for that location. If the business has several locations, treat each location as its own local business entity.

What to ask your WordPress developer or agency

A useful handoff is more specific than “please add schema”. Provide a brief containing:

• Entity: the business or location being described.
• Target type: for example, Organization or the appropriate LocalBusiness subtype.
• Page: where the site-level entity should live, normally the home page or a dedicated organisation page unless feature-specific guidance says otherwise.
• Source of truth: which plugin, theme integration, or custom component will own the data after the change.
• Approved facts: name, canonical URL, logo, public contact details, address if applicable, and official profile URLs if used.
• Conflict rule: what existing duplicate output should be removed, disabled, or reconciled.
• Verification: which URLs must be tested before and after release and who owns Search Console monitoring.

This turns schema work into a maintainable publishing task rather than a one-off code paste.

Verification: prove the markup is correct after deployment

Validation should answer three different questions, because one tool cannot answer all of them.

1. Is the schema.org markup structurally valid? Use the Schema Markup Validator when you need generic schema.org validation, including types that Google may not use for a rich result.
2. Is the page eligible for a Google-supported rich result? Use Google’s Rich Results Test. Fix critical errors and assess warnings in the context of the specific feature; a recommended property is not automatically a blocker.
3. Can Google access and process the deployed page? After release, use URL Inspection in Search Console to inspect the live URL. Then monitor the relevant rich-result status report when Google provides one for that feature.

Keep a simple before-and-after record: the old structured data output, the new output, validation results, the live page inspected, and the date of deployment. That evidence makes future plugin or theme regressions much easier to diagnose.

Do not use “a rich result appeared” as the only acceptance test. Google does not guarantee rich-result display even when structured data is valid. A successful implementation is accurate, eligible where relevant, crawlable, consistent with visible content, and maintainable by the team responsible for the WordPress site.

What not to do

• Do not add Organization markup to every page simply because a plugin allows it; Google recommends a home page or one page that describes the organisation.
• Do not add every schema type you can find. Use types that accurately describe the page and the real-world entity.
• Do not treat warnings as equivalent to errors without checking the feature documentation.
• Do not claim that valid schema guarantees rankings, rich results, or AI-search visibility.
• Do not let multiple WordPress tools become competing sources of truth for the same organisation details.

For marketing managers, the best schema implementation is not the largest JSON-LD block. It is the smallest accurate model that describes the business and page correctly, is owned by a known WordPress component, follows the relevant Google feature guidance, and can be verified after every material site change.