Schema markup for a small business website

How should visible text and schema agree?

The service name, author and FAQ answers should match what a reader can see. Publication and modification dates should reflect the content record. If a claim is missing from the page or unverified, omit it from structured data instead of hiding it in JSON-LD.

How do you validate a template?

Inspect its JSON-LD, parse it as JSON and compare important fields with the page. Use Google’s Rich Results Test for supported result types. Generic schema types can be valid without generating a supported Google rich result; the test is not a guarantee of search appearance.

Which rating claims should be avoided?

Do not invent an AggregateRating from selected testimonials or imply that a video is a star-rated review. Keep the identity and consent needed for any published review. This website presents customer feedback without claiming an aggregate rating.

What changes need a retest?

Retest after editing FAQ answers, author details, URLs or templates. A shared component can affect many pages at once. WordPress launch checks include metadata and page structure alongside form and mobile tests.

Begin with the information visitors can already verify

Schema markup describes information in a structured format. For a small business, the starting point is the content already present on the website: the organisation, its services, articles, products or locations. Markup should describe those facts accurately rather than introduce claims that are missing from the visible page.

Before choosing a schema type, review the site's business information. Is the name consistent? Are contact details current? Does the page explain the service or product clearly? If the underlying content is incomplete, adding more structured data can simply formalise the confusion. Fix the visible information first.

It also helps to identify the purpose of the page. A homepage describing a business has a different role from a guide or a product page. You do not need every available schema type on every URL. Choose a small, appropriate set and understand who will maintain it when the business or content changes.

Distinguish vocabulary from search eligibility

Schema.org provides a vocabulary for describing entities and relationships. Search engines support particular uses of structured data for specific features. Those are related ideas, but they are not identical. A type existing in the vocabulary does not mean a search engine will show a special result for it.

Read the documentation for the feature you intend to support. Check the relevant requirements, content rules and limitations. Some features have eligibility conditions beyond technically valid markup. This is why a test showing no syntax errors cannot be interpreted as a guarantee that the search result will change.

For small businesses, restraint is useful. Accurate organisation, article or product information can be maintained more reliably than a complicated collection of unsupported types. The proposal should explain what each block describes and why it belongs on that page, rather than presenting schema quantity as a performance metric.

Organisation and business identity

Business identity markup should use the correct public name, website and relevant information that the site can support. Links to official public profiles can provide context when they belong to the same organisation. A link to an unrelated company with a similar name is not a credibility signal.

Review addresses carefully. A business may operate from a storefront, serve customers at their locations or work remotely. The public site should not expose a private address simply because a template has an address field. Describe the real operating model and use only information approved for public display.

Ownership and maintenance matter here. If the business changes its contact details, the visible page and structured data should be updated together. A hidden block can remain outdated after the design has been refreshed, so add identity information to the site's normal review process rather than treating it as a one-time installation.

Articles and the people responsible for them

Article markup should reflect the actual article, its title, relevant dates and responsible author or organisation. The byline should make sense to a reader, and any author profile should describe real experience. Fabricated expert profiles weaken trust rather than improve it.

Dates need a sensible editorial process. Changing a publication date simply to make an article look recent can misrepresent the content. When a guide receives a substantial revision, the visible update information and the structured data should remain aligned. A spelling correction does not necessarily justify presenting the entire piece as newly published.

Images used in article descriptions should represent the page and be usable according to the feature's requirements. Review the actual output after a theme or plugin change. A content-management field may look correct while the page emits an old title, missing image or conflicting author block.

Product information and customer expectations

Product markup needs accurate facts about the offer, such as the product identity and information supported by the page. Price and availability are particularly sensitive to change. A store displaying one value while its structured data reports another creates an inconsistent expectation.

If the ecommerce platform already generates product markup, inspect that output before installing another tool. Multiple integrations can emit duplicate or conflicting blocks. More markup is not automatically better, especially if two systems disagree about the product or offer.

Reviews and ratings require care. Do not create a rating because a product needs stronger proof, or convert unrelated business feedback into product reviews. The visible review context, genuine source and applicable platform rules need to support the use. When permission or evidence is unavailable, leave the claim out rather than filling the gap with invented data.

FAQs, services and realistic expectations

Frequently asked questions can improve the page for readers when they address genuine uncertainty. That benefit exists independently of whether a search engine displays an expanded result. Write the questions to explain the offer, not to create a large block of repeated keywords.

Service descriptions should similarly reflect the actual scope. If the business offers an audit and continuing management, explain those roles on the page. Structured data can describe the information, but it cannot turn an unclear offer into a persuasive service page.

Search presentation changes over time and may vary by site or query. Avoid a proposal that promises a guaranteed FAQ result or claims a special schema block will force inclusion in AI answers. Ask what the markup represents, which feature is being considered and how the output will be validated. Those questions keep the work concrete.

Test the output, not just the editor settings

Validation begins with the live page. Check the generated block, its syntax and the relationship to visible content. Use the relevant tools for the schema vocabulary and the search feature. A plugin's successful-save message proves that the setting was saved, not that every public page now emits the intended data.

Review representative page types after implementation. A homepage, article and product may use different templates. If one template is correct, the others can still contain conflicts. Check again after major theme, plugin or catalogue changes that could affect the output.

When a test reports an issue, distinguish an error from an optional recommendation. The business impact depends on what the field describes and the feature being supported. Keep a record of what was changed and why, so future maintenance does not undo the implementation or add a second competing block.

A practical small-business rollout

Begin with an inventory of page types and existing markup. Identify inaccurate blocks, unsupported claims and duplicate generators. Correct those before adding new types. Then choose the information worth maintaining and agree who will confirm changes in business details, authorship or products.

Implement a representative page first, validate it and review the visible content. Once the approach is sound, apply it to the relevant templates and test several examples. This staged process makes it easier to catch a platform-specific problem before it affects the entire website.

Document the configuration and the review schedule. Structured data should be part of a coherent website, alongside useful content, technical discovery and a clear customer journey. Its value comes from accurately describing the business and pages, not from promising a shortcut to rankings, rich results or sales.

Create a small structured-data acceptance checklist

Write down what each markup block describes and which visible page supports it. Check the business name, URLs, author information and relevant dates. If a fact is not approved for public display, it should not be introduced through hidden markup. This is especially important for addresses, customer information and client performance claims.

Test the rendered output after implementation. A plugin can generate markup in several places, so check for contradictory business identities or duplicated blocks. If the site has a product system or SEO plugin, understand what it already produces before adding another custom implementation. The goal is a clear representation of the page, not a larger volume of code.

Record the test result and the maintenance owner. When a page changes, review whether its structured data needs to change as well. New authors, updated product details and altered contact information can otherwise leave the visible page and markup out of sync.

Keep expectations realistic in the handover. A technically valid result confirms a particular check, not guaranteed search presentation. The business should understand what was added, why it fits and how it will be maintained. That is a more useful deliverable than promising a special result that an external platform ultimately controls.

Primary reference

What should you explore next?

Explore the connected services and reference guides.

• SEO services
• AI SEO and GEO services
• Technical SEO audit checklist