Structured Data (Schema Markup)

← Back to glossary · Category: Technical

Structured data, often called schema markup, is extra labelling added to a page in a format search engines can read precisely. It states facts about the page in a structured way, for example that a page is an article, what its headline is, who wrote it, and when it was published, instead of leaving the search engine to guess from the visible text alone. The visible page stays exactly as the reader sees it; the structured data sits alongside it, in code, as a clear statement of what the page is. Think of it as the difference between handing someone a book and handing them the same book with a catalogue card tucked inside it: the book is unchanged, but the librarian no longer has to guess what it is.

What structured data is, and what it is not

In plain language, structured data is labelling for machines. Human readers understand a page from its headings, its layout, and its context. Machines need more explicit help, because the same visible text can mean different things: a name might be an author, a person mentioned in the story, or a company, and a date might be the publication date, an event date, or a date discussed in the text. Structured data removes that ambiguity by naming each fact and its role, using a shared vocabulary so that every search engine reads the label the same way.

The shared vocabulary most often used is Schema.org, a collaborative project that defines types, such as Article, Product, and Event, and properties, such as headline, author, and datePublished. A page declares its type and fills in the properties that apply, and a search engine can then treat those statements as facts about the page rather than as guesses drawn from the prose. The format most commonly recommended for adding this labelling is JSON-LD, a small block of script that sits in the page and is separate from the visible content, which keeps the labelling easy to maintain without disturbing the article itself.

Structured data is not visible content, and it is not a way to hide extra text from readers. Search engines expect the labelled facts to match what the page actually shows, and labelling that contradicts the visible page, or describes content that is not there, is a misuse of the system. It is also not a ranking trick. Google's own guidelines describe structured data as a route to eligibility for richer results, not as a direct lever on position, and a page can be perfectly labelled and still not receive a richer display, because eligibility is not a promise of display.

It is also not the same as a title tag or a meta description, though all three help search engines understand a page. The title and description are the page's own summary, written for the search result. Structured data is a formal statement of the page's facts, written for the machine reading the page. The two complement each other: the title promises, the description summarises, and the structured data confirms the details.

How structured data works: the key mechanics

The mechanics start with choosing the right type. A blog post is typically an Article, or a more specific subtype for a blog posting, while a product page is a Product, an event page is an Event, and a frequently asked questions section can be marked as a set of questions and answers. Choosing the wrong type is worse than choosing none, because it states a false fact about the page. The rule is simple: describe what the page actually is, not what you wish it were, and use the most specific type that genuinely fits.

Next come the properties: the facts that type carries. For an article, the important ones are the headline, the description, the author, and the date published, along with the page's address. Each property has an expected kind of value: a headline is text, an author is a person or an organisation, a date is a date. Filling in properties with the wrong kind of value, or with vague text where a specific value belongs, weakens the labelling, because the machine cannot use a fact it cannot parse.

Then comes placement and format. In the JSON-LD approach, the labelling lives in a script block in the page, separate from the article text, which means it can be added, checked, and updated without editing the article itself. That separation is a practical advantage for a small business: the person maintaining the site can check the labelling in one place, and a mistake in the labelling does not break the visible page. The other formats, microdata and RDFa, weave the labelling into the visible HTML instead, which works but is harder to maintain, and is one reason JSON-LD is the format Google recommends.

After placement comes validation. Before publishing, the labelling should be tested with a validation tool, which checks that the format is correct, that required properties are present, and that values are of the expected kind. A validation pass catches the small errors, a missing comma, a misspelled property, a date in the wrong shape, that would otherwise make the whole block unreadable. Validation is not a one-time step: whenever a template changes, the labelling should be re-checked, because a template change can silently break every page that uses it.

The final mechanic is eligibility, which is often misunderstood. Correct structured data makes a page eligible for a richer result, such as extra details shown under a listing, but eligibility is not display. Search engines decide, page by page and query by query, whether a richer display is useful, and they may show the ordinary result instead. A site owner who adds structured data expecting a richer display on every page will be disappointed. The honest benefit is different: the page is understood correctly, which is a precondition for any richer display, and a foundation for being understood by other systems that read structured facts too. Results pages themselves are covered in our glossary entry on the SERP, where the difference between an ordinary listing and an enhanced one becomes visible.

Why it matters for a blog post and for search

For a single blog post, structured data is the difference between being read and being understood. A well-written post can be read by a search engine perfectly well without any labelling, but the labelling settles the questions that prose leaves open: what kind of page is this, what is its headline, who wrote it, when was it published, and what is it about? Those settled facts help the post be categorised correctly, shown with the right details, and connected to the right kind of result. For a small blog, where every post must work hard, that clarity is worth the small effort of adding it.

For search, the honest scope is eligibility without promise. Structured data can make a post eligible for richer results, and richer results can make a listing more informative and more inviting to click, but neither step is under the site owner's control. What is under the owner's control is accuracy: labelling that is correct, complete for the page's type, and consistent with the visible content. Accuracy is also a trust matter. A site whose labelling matches its content looks careful, and a site whose labelling invents facts looks careless at best. The canonical URL plays a similar clarifying role, settling which address is the page's real address when several addresses could lead to it.

Common mistakes

The most common mistake is marking up content that is not on the page. Labelling a page as carrying reviews, prices, or answers that it does not actually contain is misleading, and it risks the page losing its eligibility for richer results altogether. The rule is strict and simple: label only what the reader can see.

The second mistake is choosing the wrong type. A blog post labelled as a product, or a guide labelled as an event, states a false fact about the page, and a false fact confuses every system that reads it. When no specific type fits, the general type that does fit is the right choice, and forcing a specific type that does not is always worse.

The third mistake is adding labelling once and never checking it again. Templates change, authors change, dates change, and a block of structured data written for an old template can quietly become wrong across a whole site. A validation check after any template change, and a periodic check of a sample of pages, catches this before it spreads.

The fourth mistake is expecting a richer result and treating its absence as failure. A page can be correctly labelled, fully eligible, and still shown as an ordinary listing, because display is decided per query. The correct response is to check that the labelling is valid and accurate, and then leave the display decision alone, rather than adding more labelling in the hope of forcing a result.

How to apply it step by step to a small-business blog

Start with your article template, not with individual posts. Decide the type your posts will use, and the properties every post will carry: headline, description, author, date published, and address. Building the labelling into the template means every new post carries it automatically, and every fix to the template fixes every post at once.

Next, fill in the properties from the post itself, not from a separate source. The headline in the labelling should be the post's actual headline, the description its actual summary, and the date its actual publication date. Deriving the labelling from the post guarantees consistency, while typing it separately guarantees drift. Our guide to writing title tags that get clicks and our guide to meta descriptions that improve click-through rate cover the visible side of the same discipline: the promise in the result should match the page.

Then validate before publishing. Run the labelling through a validation tool, fix any errors, and check that the facts it states match the visible page. If your blog uses a metadata generator for titles and descriptions, keep the labelling consistent with what that tool produces, so the three descriptions of the page, title, description, and structured facts, all agree.

Finally, check a sample of live posts after any template change, and revisit the labelling when a post is substantially updated, since a new headline or a new publication date should be reflected in the facts. How to write blog posts that rank on Google shows how this technical step fits into the full journey from research to published post, and it is worth reading as the frame that holds the labelling in its proper place: a supporting discipline, not the article itself.

Chart: what a search engine sees, with and without structured data

The diagram below is a qualitative comparison, not a measurement. It shows the same blog post as a search engine reads it twice: once from visible text alone, where facts must be guessed, and once with structured data, where the same facts are stated plainly.

Source note: qualitative illustration of the labelling concept described in Google Search Central's structured data documentation and the Schema.org vocabulary. See Sources below.

How this looks on Rankenza

Rankenza's own article pages carry their own structured information, including title, description, and publication date, so search engines can read the basics without guessing. The comparison below is method against method, with no claim about traffic or results, and it uses a real Rankenza page as the example: the title-tag guide below is a page whose visible promise and labelled facts are meant to agree.

Structured data is not something Rankenza sells as a separate feature; it is part of the same care that goes into a finished article page, where the title, the description, and the labelled facts all describe the same page. Your first article is free, then $3.60 per article or $89 for 50 credits.

What the research says

According to Google's Search Central documentation on structured data, structured data is a standardised format for providing information about a page and classifying its content, and Google recommends JSON-LD as the format for adding it. The same documentation sets out general guidelines that must be followed for a page to be eligible for a rich result appearance, including that the labelling must not violate Google's content policies, and that it should describe content actually on the page. Schema.org's own vocabulary defines the types and properties used in that labelling, with Article carrying properties such as headline, author, and datePublished. Together, these sources support the method on this page: choose the true type, state only true facts, validate the labelling, and treat richer display as possible, never promised.

Sources

• Google Search Central, General Structured Data Guidelines: developers.google.com/search/docs/appearance/structured-data/sd-policies
• Schema.org, Article type: schema.org/Article

Frequently asked questions

Does structured data improve a page's position in results?

Not directly. It makes a page eligible for richer results and helps search engines understand the page correctly, but it does not by itself change where a page appears. Content quality, relevance, and intent match remain the main considerations.

Which format should a small business use?

JSON-LD, the script-block format Google recommends. It sits apart from the visible content, so it is easier to add, check, and maintain than formats woven into the page's HTML, and a mistake in it does not break the article itself.

Can I add structured data to a page that has no matching content?

No. Label only what the reader can see on the page. Labelling absent content is misleading and risks the page losing eligibility for richer results.

How do I know if my structured data is correct?

Validate it before publishing, and re-validate after any template change. A validation tool checks the format, the required properties, and the shape of each value, and it catches the small errors that would otherwise make the labelling unreadable.