A Guide on How to Make Structured Data: Part 1
STRUCTURED DATA FOR THE WEB
Part 1: A Guide on How to Make Structured Data
A practical guide for web developers and content creators — 28 July 2026
1. What Is Structured Data?
Structured data is a standardised format for providing information about a web page and classifying its content.
Rather than leaving search engines and other automated systems to infer what a page contains, structured data provides explicit, machine-readable information about the entities described on that page.
Consider this text on a restaurant website:
Margherita Pizza — £12.50
A machine can read the words, but the text alone may not clearly indicate whether “Margherita Pizza” is a menu item, a product, an article title or something else.
Structured data can clarify that:
Margherita Pizza is a product or menu item.
£12.50 is its price.
GBP is the currency.
The item is offered by a particular restaurant.
It is currently available.
Key definition: Structured data is machine-readable metadata that uses a shared vocabulary—most commonly Schema.org—to describe entities, properties and relationships represented on a web page.
1.1 Why does structured data matter?
The practical benefits fall into three main categories.
Search understanding and rich-result eligibility
Search engines use structured data to understand page content and determine whether it may be eligible for supported search features.
Depending on the page type and search engine, these features can include:
Product prices and availability.
Recipe information.
Event dates and venues.
Job details.
Breadcrumb trails.
Review information.
Business details.
Correct structured data does not guarantee that a rich result will appear. Search engines decide which presentation is most appropriate for each query, user, device and location.
Structured data is also not, by itself, a ranking guarantee.
Machine-readable entity information
Structured data can help automated systems distinguish between entities such as:
A company and its website.
A product and the offer used to sell it.
An article and its author.
A vacancy and its hiring organisation.
An event and its venue.
This can reduce ambiguity and make information easier to reuse.
Third-party processing and data exchange
Some aggregators, search tools, data platforms and knowledge systems process structured data when indexing or importing web content.
Support varies between services, so publishers should not assume that every platform will use every Schema.org property.
1.2 How structured data fits into the web stack
Structured data complements good HTML and useful visible content. It does not replace either.
The information in structured data should accurately represent what users can see on the page. Do not use it to add hidden:
Prices.
Reviews.
Products.
Services.
FAQs.
Events.
Vacancies.
Claims.
For Google rich-result eligibility, structured data should normally be included on the page to which it relates.
JSON-LD can be placed inside the <head> or <body> of the HTML document. Microdata and RDFa are added directly to the visible HTML markup.
2. The vocabulary: Schema.org
Schema.org is the most widely used shared vocabulary for structured data on the web.
It was launched in 2011 through collaboration between Google, Microsoft, Yahoo and Yandex. It defines types and properties that can be used to describe people, organisations, products, services, articles, events, jobs and many other entities.
Schema.org can be expressed using several formats, including:
JSON-LD.
Microdata.
RDFa.
Other vocabularies exist, including Dublin Core and FOAF, but Schema.org has broad support across major search engines and web tools.
2.1 Understanding types and properties
Every Schema.org entity has a type.
Examples include:
ProductArticleOrganizationPersonEventJobPosting
Each type supports a set of properties.
For example, a JobPosting may use properties including:
titledescriptiondatePostedvalidThroughhiringOrganizationjobLocationbaseSalary
Types form a hierarchy.
For example:
ThingCreativeWorkArticleSoftwareApplication
OrganizationLocalBusiness
Product
A more specific type should be used when it accurately describes the entity.
For example:
Use
Restaurantrather than the broaderLocalBusinesswhen the entity is a restaurant.Use
BlogPostingrather thanArticlefor a conventional blog post.Use
WebApplicationrather thanSoftwareApplicationwhen describing an application specifically delivered through a web browser.
Do not choose an overly specific type merely because it appears more descriptive. The type must accurately represent the visible content.
2.2 Schema.org properties versus search-feature requirements
Schema.org defines which properties can be used with each type. It does not generally classify properties as universally required or recommended.
Search engines and other consumers publish their own requirements.
For example, Google may specify:
Properties required for a particular rich result.
Recommended properties that improve the result.
Content and technical policies.
Types that Google supports for that feature.
A Schema.org-valid object is not necessarily eligible for a Google rich result.
Always check both:
The Schema.org definition for the type.
The documentation for the search feature you are targeting.
2.3 Common Schema.org types
| Type | Common use |
|---|---|
Article | Editorial articles and general written content |
BlogPosting | Blog posts |
Product | Products or services presented as products |
Offer | Price, currency, availability and seller details |
Recipe | Recipes with ingredients, instructions and cooking times |
Event | Concerts, webinars, exhibitions and other events |
FAQPage | A publisher-controlled list of visible questions and answers |
LocalBusiness | A business with a genuine physical location |
Organization | Company or organisation details |
WebSite | Information about a website |
WebPage | Information about a particular page |
BreadcrumbList | A page’s position in the site hierarchy |
Person | Authors, team members and other people |
Review | A review of an eligible item |
AggregateRating | A genuine combined rating |
JobPosting | Individual vacancy pages |
SoftwareApplication | Software products and applications |
3. Structured data formats
Google supports three formats for structured data:
JSON-LD.
Microdata.
RDFa.
They can express similar information, but they place that information in different parts of the document.
3.1 JSON-LD
JSON-LD stands for JavaScript Object Notation for Linked Data.
It is Google’s recommended format for structured data. It is usually included in a script element that is separate from the visible page layout.
<script type="application/ld+json">{ "@context": "https://schema.org", "@type": "Article", "headline": "How to Create Structured Data", "author": { "@type": "Person", "name": "Jane Smith" }, "datePublished": "2026-07-01", "image": "https://example.com/images/structured-data-guide.jpg"}</script>Advantages of JSON-LD
It is relatively easy to read and maintain.
It does not require structured-data attributes throughout the visible HTML.
Multiple related entities can be connected in one graph.
It can be generated by a CMS or application.
It is supported by major search engines.
It is Google’s recommended format.
JSON-LD can also be generated using JavaScript. However, for fast-changing information such as product prices and availability, server-generated markup may be more dependable because dynamically generated data introduces additional rendering and crawling dependencies.
3.2 Microdata
Microdata adds structured-data attributes directly to HTML elements.
Common Microdata attributes include:
itemscopeitemtypeitemprop
<div itemscope itemtype="https://schema.org/Product"> <span itemprop="name">Wireless Headphones</span> <span itemprop="description"> Over-ear noise-cancelling headphones </span> <div itemprop="offers" itemscope itemtype="https://schema.org/Offer"> <meta itemprop="priceCurrency" content="GBP"> <span itemprop="price" content="89.99">£89.99</span> </div></div>In this example, the price belongs to the nested Offer, not directly to the Product.
Microdata remains valid and supported, but it is tightly coupled to the page markup. This can make it harder to maintain when templates or layouts change.
3.3 RDFa
RDFa stands for Resource Description Framework in Attributes.
Like Microdata, it adds structured information to visible HTML. RDFa is more closely aligned with the RDF data model and can express complex linked-data relationships.
<div vocab="https://schema.org/" typeof="Event"> <span property="name">Annual Technology Conference</span> <time property="startDate" datetime="2026-09-15T09:00:00+01:00"> 15 September 2026 at 9:00 am </time> <span property="location" typeof="Place"> <span property="name">Birmingham Conference Centre</span> </span></div>RDFa is commonly encountered in publishing, government, academic and linked-data environments.
3.4 Which format should you choose?
Use JSON-LD for most new implementations.
It is generally:
Easier to create.
Easier to review.
Easier to update.
Less dependent on page layout.
Recommended by Google.
Use Microdata or RDFa when:
Your existing CMS already produces it.
A legacy system requires it.
You need structured information tightly connected to individual HTML elements.
Your wider linked-data architecture uses RDFa.
Avoid publishing the same entity repeatedly in several formats unless the implementations are deliberately linked and kept consistent.
4. Building your first structured-data block
This section walks through a basic product-page implementation.
4.1 Start with the type
First, identify the Schema.org type that most accurately represents the page’s main subject.
For an individual retail product page, the main entity is usually:
"@type": "Product"A JSON-LD block usually begins with:
{ "@context": "https://schema.org", "@type": "Product"}@context identifies the vocabulary.
@type identifies the kind of entity being described.
4.2 Check the requirements for the intended feature
Before adding properties, decide what the markup is intended to support.
For example:
A product snippet.
A merchant listing.
An article result.
A job-search result.
A breadcrumb trail.
A local-business result.
Then check the relevant search-engine documentation.
Required and recommended properties vary between features. Do not assume that a property is required simply because it appears on Schema.org.
4.3 Add accurate properties
Here is a simplified product example:
<script type="application/ld+json">{ "@context": "https://schema.org", "@type": "Product", "@id": "https://example.com/products/headphones-pro-x#product", "name": "Noise-Cancelling Headphones Pro X", "image": [ "https://example.com/photos/headphones-front.jpg", "https://example.com/photos/headphones-side.jpg" ], "description": "Premium over-ear headphones with a 40-hour battery.", "sku": "NCH-PROX-001", "brand": { "@type": "Brand", "name": "AudioPeak" }, "offers": { "@type": "Offer", "url": "https://example.com/products/headphones-pro-x", "priceCurrency": "GBP", "price": "149.99", "availability": "https://schema.org/InStock", "itemCondition": "https://schema.org/NewCondition", "seller": { "@type": "Organization", "name": "Example Shop" } }}</script>Every value should match the visible product page.
Do not mark a product as in stock when the page says it is unavailable.
Do not place one price in the markup and another on the page.
Do not add a rating unless the rating is genuine, visible and based on reviews that comply with the relevant search-engine policies.
4.4 Nesting types
The example contains several related types:
ProductBrandOfferOrganization
This is called nesting.
A real-world entity often has relationships with other entities. A product has an offer, an offer has a seller and a product has a brand.
Structured data is therefore better understood as a graph of connected entities rather than a flat list of unrelated fields.
4.5 Connecting entities with @id
An @id provides a stable identifier for an entity.
For example:
{ "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Shop"}Another entity can refer to it without repeating all its properties:
"publisher": { "@id": "https://example.com/#organization"}Using consistent IDs can prevent the same company, website or product from being interpreted as several unrelated entities.
4.6 Expressing multiple related entities with @graph
Use @graph when a page describes several related entities.
<script type="application/ld+json">{ "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Shop Ltd", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" } }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Example Shop", "publisher": { "@id": "https://example.com/#organization" } } ]}</script>@graph is not required merely because a page contains more than one property. It is useful when modelling several distinct but connected entities.
5. Common Schema.org types in depth
5.1 Article
Use Article or one of its subtypes for editorial content.
Common subtypes include:
BlogPostingNewsArticleTechArticle
Useful properties include:
headlineauthordatePublisheddateModifiedpublisherimagemainEntityOfPagearticleSection
<script type="application/ld+json">{ "@context": "https://schema.org", "@type": "BlogPosting", "@id": "https://devweekly.com/guides/schema-markup#article", "headline": "Getting Started with Schema Markup", "author": { "@type": "Person", "name": "Alex Johnson" }, "datePublished": "2026-03-10", "dateModified": "2026-07-01", "publisher": { "@type": "Organization", "name": "Dev Weekly", "logo": { "@type": "ImageObject", "url": "https://devweekly.com/logo.png" } }, "image": "https://devweekly.com/images/schema-article.jpg", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://devweekly.com/guides/schema-markup" }}</script>Only include publication and modification dates that accurately reflect the visible article.
5.2 FAQPage
Use FAQPage when:
The publisher provides the questions and answers.
The questions and complete answers are visible to users.
Users cannot submit competing answers to each question.
If users can submit answers, QAPage may be the more appropriate type.
<script type="application/ld+json">{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is structured data?", "acceptedAnswer": { "@type": "Answer", "text": "Structured data is machine-readable metadata used to describe the entities and content represented on a web page." } }, { "@type": "Question", "name": "Do I need to know JSON to use JSON-LD?", "acceptedAnswer": { "@type": "Answer", "text": "Basic JSON knowledge is useful, but structured-data generators and CMS tools can help create the markup." } } ]}</script>FAQPage remains a valid Schema.org type.
However, Google stopped displaying FAQ rich results in Search on 7 May 2026. FAQ markup should therefore be used for accurate semantic description, not with the expectation of receiving expanded FAQ listings in Google Search.
5.3 LocalBusiness
Use LocalBusiness or a relevant subtype for a business with a genuine physical location.
Examples of subtypes include:
RestaurantHotelMedicalClinicStoreLegalService
<script type="application/ld+json">{ "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://example.com/#restaurant", "name": "The Coded Kitchen", "url": "https://example.com/", "telephone": "+44 1509 000000", "priceRange": "££", "address": { "@type": "PostalAddress", "streetAddress": "42 High Street", "addressLocality": "Loughborough", "addressRegion": "Leicestershire", "postalCode": "LE11 2AA", "addressCountry": "GB" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "https://schema.org/Monday", "https://schema.org/Tuesday", "https://schema.org/Wednesday" ], "opens": "12:00", "closes": "22:00" } ]}</script>Do not use LocalBusiness merely because a company serves a particular area. The entity should have a genuine business location relevant to the markup.
5.4 BreadcrumbList
BreadcrumbList describes a page’s position within the website hierarchy.
<script type="application/ld+json">{ "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" }, { "@type": "ListItem", "position": 2, "name": "Products", "item": "https://example.com/products" }, { "@type": "ListItem", "position": 3, "name": "Headphones", "item": "https://example.com/products/headphones" } ]}</script>The breadcrumb should reflect the logical navigation path shown to users.
5.5 Review and AggregateRating
Use Review for an individual review and AggregateRating for a combined rating.
Only add rating markup when:
The rating is genuine.
The rating is visible on the page.
The reviewed item is clearly identified.
The rating total is current.
The markup complies with the search engine’s review policies.
The reviewed entity is eligible for the intended search feature.
Do not copy an aggregate score from another platform and present it as though the reviews were collected on your own page.
Do not add a rating merely to try to obtain stars in search results.
5.6 JobPosting
Use JobPosting on an individual vacancy page.
The marked-up information should match the visible vacancy, including:
Job title.
Description.
Date posted.
Closing or expiry date, where applicable.
Hiring organisation.
Job location.
Employment type.
Salary, when shown.
Application route.
Each live job should normally have its own crawlable URL.
Expired jobs should be removed or updated correctly, and their structured data should not continue to describe a vacancy as open when applications are no longer accepted.
6. Validation and testing
Use both of the following tools.
Google Rich Results Test
Use this to determine:
Whether Google recognises a supported structured-data feature.
Whether required feature properties are missing.
Whether the page contains errors affecting Google rich-result eligibility.
Schema Markup Validator
Use this to:
Validate general Schema.org syntax.
Inspect types and properties not supported as Google rich results.
Find properties that are not expected for a particular Schema.org type.
A result can be valid in the Schema Markup Validator but ineligible for a Google rich result.
Similarly, a page can pass the Rich Results Test without being guaranteed a rich result in live search.
After deployment:
Test the code.
Inspect the page using Google Search Console’s URL Inspection tool.
Confirm that Google can access the page.
Check that the structured data matches the visible content.
Monitor enhancement reports and search performance where applicable.
Update prices, availability, dates, reviews and other time-sensitive information when the page changes.
7. Part 1 checklist
Before publishing structured data, confirm that:
The selected type accurately describes the page.
The markup represents visible content.
URLs are absolute and correct.
Prices and availability are current.
Dates use valid formats.
Reviews and ratings are genuine and visible.
Related entities use consistent
@idvalues.The page is not blocked from crawling or indexing.
Required properties for the intended search feature are included.
The code passes the appropriate validators.
Old or duplicate structured-data blocks have been removed.
The implementation does not promise or assume a rich result.
Structured data is most effective when it accurately describes useful, accessible page content. It can improve machine understanding and make a page eligible for supported search features, but it cannot compensate for weak content, inaccurate information or poor technical accessibility.
Website Plans
Start-Up Recruiter Plan — £149 + VAT per month
Launch your agency with enterprise-grade technology on a bootstrap budget. This plan delivers our most robust features at an entry-level price point, ensuring you don't have to compromise on tech while managing cash flow. It provides the credibility needed to win the attention of clients and candidates without the capital expenditure of a custom build.
This plan has no build cost and no upfront fees, just a simple, recurring monthly fee.
Template Website Designs — £199 + VAT per month
Start with a proven theme, then tailor it and build truly unique internal pages with Design Studio.
This plan has no build cost and no upfront fees, just a simple, recurring monthly fee.
Semi-Bespoke Design — £299 + VAT per month
Get a homepage that’s designed uniquely for your agency, then build unlimited internal pages using Design Studio. It’s the hybrid option for recruiters who want more than a theme, without the cost and timelines of a fully bespoke design.
This plan has no build cost and no upfront fees, just a simple, recurring monthly fee.
Fully Bespoke Design — £599 + VAT per month
Our designers hand-draw every layout to align with your agency’s specific goals for every page of your website. We do not simply modify a theme; we build a pixel-perfect representation of your unique design goals.
This plan has no build cost and no upfront fees, just a simple, recurring monthly fee.
Get a Demo
Talk to a Recruitment Website Specialist
If you’re tired of rebuilding, replatforming, or being boxed in by your website provider, it’s time for something built properly. Use the link below. Or you can:
Call 01223 655278
Email darren@recruiterweb.co.uk
Connect on LinkedIn
