Schema markup for small sites: a practical guide

Schema markup is extra information added to a web page that tells search engines what the content is: an article, a product, a local business, an event, a recipe. Visitors do not see it. It is written in a standard vocabulary and is most often added as a block of data called JSON-LD. Done properly, it can make a page eligible for richer results, such as star ratings or event details. Done carelessly, it can be ignored or even cause problems. This guide explains what it is for, which types small sites usually need, shows a worked example, covers the rules that keep markup honest, and explains how to check it and what to expect.

By Valtrinity. Updated 18 October 2026.

What schema markup does and does not do

Search engines are good at reading text, but they have to infer what the text means. Structured data states it directly. A price is labelled as a price, a date as a date, an author as an author. This helps a search engine understand the page and, where its rules allow, show extra detail in the result.

What it does not do is guarantee a rich result, or make a page rank higher. Search engines decide for themselves when to show enhanced results, and they have been narrowing the types they show. For example, the special display for FAQ sections is now limited to a small set of sites, so adding FAQ markup to an ordinary business site is unlikely to change how it looks in results.

So the realistic benefit is clarity and eligibility. It is a good habit for important pages, but it is not a quick route to better results. Fix the basics of the page first: clear content, fast loading and sensible titles.

The formats: JSON-LD is the usual choice

There are three ways to write structured data: JSON-LD, microdata and RDFa. JSON-LD is a separate block in the page, so it does not need to be mixed into the visible HTML. It is the format that search engines recommend for most sites and the easiest to add and maintain.

A JSON-LD block sits inside a script tag with the type application/ld+json. It contains a context line, which says the vocabulary used is schema.org, a type, and a set of properties. You can place it in the head or the body of the page.

Many content management systems and plugins can produce it for you. Even so, it is worth knowing how it looks, so that you can check what is being output and fix mistakes.

The types small sites usually need

Organization, or LocalBusiness for a business with a physical location, describes who you are: name, address, phone number, opening hours and logo. Put it on the home page or the contact page. Article, or BlogPosting, describes a guide or news item with a headline, author, publication date and image.

Product describes something for sale, with a name, image, description, price and availability. Add ratings only if they are real reviews that visitors can see on the page. BreadcrumbList describes the path to the page, such as Home, Guides, Paint, which can appear in results in place of a plain address.

Others suit particular sites: Recipe, Event, JobPosting, Course. Choose the most specific type that fits the page. Do not add every type to every page. Use only what the page really is.

A worked example for a guide page

Here is the structure for an article, written out in words. The context is https://schema.org. The type is Article. The headline is 'How to calculate how much paint you need for a room'. The author is an Organization named 'Example Editorial Team'. The datePublished is 2026-10-18. The image is the full address of the main picture. The mainEntityOfPage is the full address of the guide.

In the page, this appears as a script block with these properties inside curly braces, written as pairs of names and values, with commas between them and the whole thing valid JSON. A missing comma or an unclosed bracket makes the block unreadable, so test it.

Dates should use the format year, month, day, such as 2026-10-18, optionally followed by a time. Keep the date published and the date modified accurate, because search engines compare them with the page. Do not change the modified date unless the content has really changed.

Rules that keep markup honest

The markup must describe content that is visible to visitors on the same page. Do not mark up reviews that are not on the page, prices that are not shown, or a business address you do not have. Search engines can apply manual actions to sites with misleading markup, which can remove rich results across the whole site.

Do not mark up content that is hidden, irrelevant or generated just to appear. Do not copy another site's ratings. Self-serving reviews of your own business, written on your own page, are not eligible for star ratings in many cases.

Keep the data consistent with the page: if the price changes, update the markup at the same time. A template that fills the markup from the same data as the visible page avoids mismatches.

Testing and monitoring

After adding markup, check it with a structured data validator, which reads a page address or a pasted snippet and lists the types and properties it finds, with errors and warnings. Errors need fixing. Warnings are about optional properties that could make the markup more complete.

Check a few pages of each template, not just one. Then watch your search reports over the next weeks for errors flagged on live pages. It can take days or weeks for changes to be picked up.

If something goes wrong, the usual causes are a stray character that breaks the JSON, a property with the wrong kind of value such as a price with a currency symbol in the number field, or a plugin that outputs the same type twice with different data.

A sensible plan for a small site

Start with the home page: Organization or LocalBusiness with your name, logo, address and contact details. Add breadcrumbs sitewide. Then add Article to guides and blog posts, and Product to product pages if you sell things.

Test each type once, publish, and leave it. Check it again after any redesign or plugin change. You do not need to chase every property. A short, accurate block is better than a long one with errors.

Remember the real aim: helping search engines and visitors understand your page. If the content is clear and useful, markup can support it, but it cannot make up for thin content.

Tools mentioned in this guide

Frequently asked questions