Structured Data in Practice: What Is Worth Marking Up and What Is a Waste of Time

Structured data attracts two opposite errors. One camp ignores it entirely and wonders why competitors' results have stars, prices and FAQ dropdowns while theirs is a plain blue line. The other marks up everything the vocabulary offers — WebPage, SiteNavigationElement, ImageObject, the lot — and is disappointed when nothing changes at all.

This article is about the useful middle: what structured data actually does, which types are worth the effort, and how to check what you have using the Semalt platform without turning it into a project.

What it does and does not do

Structured data is a machine-readable description of what a page contains. It removes ambiguity — this number is a price, this text is an author, these are opening hours — and that clarity has two consequences.

The first is eligibility for enhanced results: star ratings, prices, availability, event dates, FAQ dropdowns, recipe details, breadcrumbs in place of a raw URL. These change the appearance of your listing, which affects click-through rate, sometimes substantially.

The second is entity clarity — helping search engines understand what your organisation is, where it operates and how the pages relate. This matters more than it used to, because being understood as a coherent entity affects how you are represented in features that summarise rather than list.

What it does not do is improve your position. A page does not rank higher because it carries schema. It may receive more clicks at the same position, which is worth having and is a different mechanism.

Working parameters from the guidance below.

The types actually worth implementing

For a typical services business, the first two plus Article on the blog is the entire useful list. Everything beyond that is effort spent on markup nobody will ever see rendered.

LocalBusiness: the one most often wrong

For any business with a physical location, this is the most valuable markup available and also the one most frequently inconsistent.

The requirement is boring and absolute: the name, address, phone number and opening hours in your markup must match exactly what appears on the visible page, and both must match your business profile and the main directories. Not approximately — exactly. Differences in how the street is abbreviated, an old phone number left in a template, hours that changed last summer — each one reduces confidence in all of your information.

Add the fields that are specific rather than generic: the precise service area, the payment methods you accept, the languages spoken, the geo coordinates. These are the details that distinguish one entry from a hundred similar ones, and most sites leave them empty because the template did not ask for them.

There is a full walkthrough in Images and Video.

FAQ markup: useful, and easy to misuse

FAQ markup can turn a single result into a result with several expandable questions underneath it, which takes up considerably more space on the page. That is a real advantage where it applies.

The third item is the most common. A single FAQ block added site-wide by a plugin appears on two hundred pages, each declaring the same questions, none of which relate to the page they are on. That is not enhancement; it is noise, and it tends to result in the feature being withdrawn.

Implementing without creating a maintenance problem

Use JSON-LD in a script tag rather than inline attributes. It is the recommended format, it keeps markup separate from presentation, and — most importantly — it survives redesigns. Inline microdata woven into HTML disappears the moment someone rebuilds the template, which is exactly what happens two years later.

See also: Speed That Counts.

Generate it from the data the page already holds, rather than writing it by hand. Hand-written schema falls out of date the first time a price, an address or an opening hour changes, and nobody remembers it exists. Generated markup stays correct because it reads the same source as the visible page.

Three implementation checks worth doing once:

1. One primary entity per page

   A product page describes a product. Do not also declare it as an Article, a WebPage and a Service — competing declarations confuse rather than reinforce.

2. Connect the entities

   The Article should reference its publisher; the LocalBusiness should reference the organisation. Isolated fragments describe things; connected ones describe a business.

3. Validate after any template change

   Schema breaks silently during redesigns and plugin updates. It never announces itself; the enhanced result simply stops appearing one week.

Entities: the part that matters more each year

The rich-result side of structured data is the visible half. The other half — describing your organisation as a coherent entity — has quietly become the more consequential one, because features that summarise rather than list depend on understanding what a business is rather than what a page says.

The practical work is unglamorous and mostly consists of being consistent. Declare the organisation once, properly, with the legal name, the address, the contact details, the founding date if known, and the profiles you maintain elsewhere. Reference that same organisation from every article as publisher and from the local business entry as the parent. Use one identifier consistently rather than declaring a fresh unnamed organisation on every page.

The linking to external profiles deserves a specific note. Declaring the platforms where your organisation also exists helps connect scattered references into one recognised entity. Include only profiles you actually maintain and control — an abandoned account with an old address does the opposite of what you intended, because the inconsistency it introduces is exactly what reduces confidence.

We cover this in detail in Internal Links: The Free Lever Almost Every Site Leaves Unused.

For people, the same logic applies to authors. On sites where expertise is checkable — health, legal, financial advice — a named author with a real biography page, credentials and a consistent presence elsewhere is a materially stronger signal than an anonymous byline. Marking that person up and linking the article to them costs nothing and describes something true.

None of this produces a visible result you can screenshot for a report, which is precisely why it gets skipped. The effect shows up indirectly: in how the business is represented when something summarises it, and in whether a knowledge panel eventually contains correct information rather than whatever was scraped from an old directory.

Checking what you actually have

Two levels of checking, and both are quick.

Validity: does the markup parse, does it contain the required fields, are there errors. This is what a crawl reports across every page at once, which is how you discover that the product template has been emitting an invalid price format for eight months.

Eligibility: is the page actually receiving the enhanced result. This is separate and more important. A perfectly valid FAQPage schema on a page that does not merit the feature produces nothing, and validity reports will never tell you that. Search your own tracked terms and look at what your results actually show — that is the only reliable confirmation.

Practical notes for Portuguese sites

Two details that come up constantly on local implementations.

Address formatting: the markup should follow the local convention as it appears on the page, with the postal code in Portuguese format and the country stated explicitly. Templates built on international platforms frequently mangle this, splitting the address in ways that do not correspond to how it is written or displayed.

Language declaration on bilingual sites: each language version should declare its own language in the markup, and the entities should reference each other rather than each declaring itself as the only version. Sites where both language versions carry identical schema, including the same declared language, are common — and it undermines exactly the entity clarity the markup was added to provide.

A realistic scope

For most business sites the whole job is: Organization or LocalBusiness on the site, BreadcrumbList across the hierarchy, Article on editorial content, Product if you sell things, and FAQPage only where real questions are genuinely answered on the page. Generated from live data, validated once, re-validated after template changes.

That is an afternoon of work and it covers everything that produces a visible result. The remaining vocabulary exists for cases most businesses do not have.

If you have never checked whether your markup is valid across the whole site, that is a five-minute crawl. Open the dashboard, run it, and look specifically at whether the values in your markup match what the pages display.