Schema markup sounds technical, and it is often explained in a way that makes it seem harder than it is. At its core, it is a standard way of labelling the facts on a page so that software can read them without guessing. A person looking at a recipe page sees ingredients and cooking times. A machine sees a block of text. Schema markup is the label that tells the machine which part is the ingredient list, which part is the time and who wrote it.
AI tools can help you draft this markup, explain errors and plan which types to use, but they also make confident mistakes that can leave you with invalid or misleading code. This guide explains what schema markup is, which types matter for most sites, how to plan and write it, where AI genuinely helps, how to test it and what to avoid. It is written for non-developers, and it points out where you should involve someone technical.
Key takeaways
- Schema markup labels the real content of a page in a standard format so that machines understand what it contains.
- It should describe only what is visible and true on the page. Marking up content that is not there breaks guidelines and trust.
- Start with a few relevant types, such as organisation, article, breadcrumb, product or FAQ where honestly applicable, instead of marking up everything.
- AI is useful for drafting and explaining markup, but you must validate it with testing tools and check it against the page.
- Markup does not guarantee special treatment in search results or AI answers. Treat it as good housekeeping.
What schema markup is
Schema markup is structured data, a way of adding extra information to a page that describes its content in a shared vocabulary. The vocabulary is a public standard that many search engines and other tools understand. It defines types of things, such as an organisation, a person, an article or a product, and properties for each, such as a name, a description or a date.
A plain language analogy
Imagine a filing cabinet with no labels. Everything is inside, but you must open every folder to find what you need. Schema markup adds labels to the folders. Nothing about the contents changes, but anyone, or any machine, can find what they want faster and with fewer errors.
What it does not do
- It does not change how the page looks to visitors.
- It does not replace good content.
- It does not guarantee any extra display in search results.
- It does not make false claims true.
Why it is worth doing
Machines are better at reading structured facts than at interpreting loose text. Marking up your pages reduces ambiguity, which is useful for traditional search, for answer tools and for any system that tries to summarise your business.
| Benefit | Explanation | Caution |
|---|---|---|
| Clearer understanding | Systems can tell what kind of page and entity they are looking at | Only helps if the markup is accurate |
| Possible enhanced results | Some types are eligible for richer displays in search | Eligibility depends on the engine’s rules and is not guaranteed |
| Consistent identity | Your name, logo, contact details and profiles are stated explicitly | Must match what is shown elsewhere |
| Better housekeeping | Forces you to check that your facts are consistent | Takes upkeep |
For how structured facts fit into the wider picture of answer focused content, see our guide to answer engine optimisation.
Common types and when to use them
There are hundreds of types in the shared vocabulary. Most sites need only a handful. Choose types that describe what your pages truly are.
| Type | Describes | Typical page |
|---|---|---|
| Organisation | Your business: name, logo, contact details, official profiles | Home or about page |
| Website | The site as a whole and its name | Home page |
| Article or blog post | Headline, author, dates, image | Blog posts and guides |
| Person | An author or team member | Author pages |
| Breadcrumb list | The page’s position in the site hierarchy | Most inner pages |
| Product and offer | An item for sale and its terms | Product pages |
| Local business | A physical business with a location and opening hours | Location pages |
| Frequently asked questions | Questions and answers visible on the page | Pages with genuine question and answer sections |
| How to | Steps for a task | Tutorials with clear steps |
A note on eligibility
Search engines publish guidelines about which types can lead to enhanced results, and these change over time. Some types that were once widely displayed are now shown rarely or only for certain kinds of site. Check the current guidance of the search engines you care about before investing effort, and use markup mainly to be accurate, not to chase a display feature.
How markup is written
There are a few formats for writing structured data. The most common recommendation today is JSON-LD, a block of text placed in the page that lists the facts in a labelled structure. It sits separately from the visible content, which makes it easier to add and maintain than older approaches woven through the page itself.
What a block contains, in words
- A statement of which vocabulary is being used.
- The type of thing being described, such as an article.
- A set of properties and values, for example the headline, the author’s name, the publication date and the main image address.
- Nested items where needed, for example an author who is a person with a name and a profile link.
You do not have to write this by hand. Many content systems and plugins generate common markup automatically. Your job is to check what they produce and to fill gaps where the plugin cannot. If your site is custom built, ask a developer to add the block to the right templates, using values pulled from your actual content.
Planning your markup
Planning before writing prevents a patchwork. Make a simple inventory of your page types and decide what each should say.
A planning method
- List your page types: home, about, service, product, blog post, author, contact and so on.
- For each type, choose the one or two markup types that honestly describe it.
- List the properties you can fill accurately from visible content.
- Decide where the values come from, such as fields in your content system.
- Decide who owns the markup and who checks it.
| Page type | Suggested markup | Source of facts |
|---|---|---|
| Home | Organisation, website | Company details held in one place |
| Blog post | Article, breadcrumb, person for the author | Post title, author profile, dates |
| Service page | Service or organisation reference, breadcrumb | Service description on the page |
| Product page | Product, offer, breadcrumb | Product data from the catalogue |
| Contact or location | Local business where it applies | Verified address and hours |
Where AI can help
AI is most useful as an explainer and first draft writer. Used this way, it can turn a confusing topic into manageable tasks.
- Explaining terms. Ask it to explain a property or type in plain English.
- Mapping pages to types. Describe your site and ask for a table of page types and suitable markup types, then check the choices.
- Drafting a block. Give it the facts from a page and ask for a first draft of the markup, for a developer to review.
- Reviewing a block. Paste existing markup and ask it to list anything that looks incomplete, inconsistent or unusual.
- Decoding error messages. Paste a validator message and ask what it means and how to fix it.
- Writing documentation. Ask for a short internal guide for your team on how and when to update markup.
Where AI goes wrong
Language models are good at producing code that looks right. That is not the same as code that is correct, current or appropriate for your page. Be alert to these problems.
- Invented properties. The model may use property names that do not exist in the vocabulary.
- Outdated advice. It may describe search features that have changed or been withdrawn.
- Fabricated content. It may fill in ratings, prices, reviews or awards that you never supplied. Never publish these. Marking up reviews or ratings that are not real and visible breaks guidelines and can mislead people.
- Mismatch with the page. Markup must reflect what visitors can see. A model cannot see your live page unless you give it the text.
- Syntax errors. A missing comma or bracket can invalidate a whole block.
These are specific cases of the general problem explained in our article on AI hallucinations. The remedy is the same: supply real facts, ask for only what you provided and verify the result.
Prompts for drafting and reviewing
Clear instructions give better results. The principles in our guide to writing better prompts apply: state the role, give the context, say what to do and what not to do, and ask for a specific format. Adapt these examples.
Drafting prompt
You are helping prepare structured data for a developer to review. Here are the facts on a blog post page: headline, author name, author profile address, publication date, last modified date and image address. Draft JSON-LD for an article using only these facts. Do not add any property for which I have not supplied a value. List any assumptions you made.
Review prompt
Here is a block of structured data and the visible text of the page it belongs to. List every statement in the markup that is not supported by the visible text. List any property names you are not sure exist. Do not rewrite the markup.
Plain explanation prompt
Explain this validator message to a non-technical person in three sentences, then list the likely fix and who should make it.
Testing and validating
Never publish markup untested. Use the free validation tools provided by search engines and by the vocabulary’s maintainers. They check syntax, flag missing recommended fields and in some cases show whether a page is eligible for particular enhanced displays.
A testing routine
- Test the draft markup in a validator before it goes live.
- Fix errors first, then review warnings and decide which matter.
- Compare the markup with the visible page, line by line.
- Publish, then test the live page address.
- Check the reports in your search console tools over the following weeks for detected issues.
- Test a sample of each page type, not just one page.
| Result | Meaning | Action |
|---|---|---|
| Error | The markup is broken or missing required fields | Fix before relying on it |
| Warning | A recommended field is missing | Add it if you have an accurate value |
| Valid but unused | Markup is correct but no special display appears | Normal. Valid markup does not force a display |
Keeping markup accurate over time
Markup goes stale like any content. If your opening hours change but your markup does not, you have created a contradiction. Where possible, generate markup from the same data that fills the visible page so they cannot drift apart.
- Review markup when you redesign, change plugins or switch platforms.
- Update it whenever business details change.
- Check reports in your search tools regularly for new errors.
- Keep a short record of what is marked up and where.
Common mistakes
- Marking up content that is not visible on the page.
- Adding review or rating markup without genuine, visible reviews.
- Using the same block across unrelated pages.
- Copying markup from another site without changing the facts.
- Stacking several plugins that each output conflicting markup.
- Treating markup as a ranking trick instead of an accurate description.
- Publishing AI drafted code without validation or review.
Be mindful of any data protection or consumer rules that apply to the information you publish, such as personal details of staff. This is general information, not legal advice.
Implementation checklist
- List page types and choose honest markup types for each.
- Check what your content system or plugins already output.
- Gather accurate facts from the visible pages.
- Draft markup, using AI only with supplied facts.
- Have a developer or technically confident colleague review it.
- Validate the draft and fix errors.
- Compare against the visible content.
- Publish, then validate live pages.
- Monitor search console reports for issues.
- Set a date for the next review and assign an owner.
Who does what: a simple split of responsibilities
Structured data sits between content, marketing and development, which is why it is often owned by nobody. Agree roles early so that errors do not sit unnoticed.
| Role | Responsibility |
|---|---|
| Content owner | Confirms that the facts on the page are accurate and current |
| Marketer or SEO lead | Chooses types, writes the plan and reviews validator reports |
| Developer | Adds templates, fixes syntax and prevents conflicting output |
| Reviewer | Compares markup with the visible page before launch |
On a small team one person may hold all four roles. Even so, write the list down and tick each item for every release. It takes minutes and catches the most common errors, such as an old phone number or a missing author name, before visitors or machines see them.
Frequently asked questions
Do I need schema markup to rank?
No. Pages can rank without it. Markup helps machines understand a page, and may make it eligible for certain displays, but it does not substitute for useful content.
Can I let a plugin handle everything?
Plugins are a sensible starting point and cover many common types. Still check the output, because defaults can be incomplete or wrong for your site.
Is FAQ markup a good idea?
Only when the page carries a genuine set of questions and answers visible to readers. Search engines have changed how they treat this type, so do not add it solely to try to gain extra space in results.
Can AI write the whole thing for me?
It can produce a first draft, but it needs real facts, and the result must be validated and reviewed. Treat it as a helpful assistant, not an authority. Our guide to checking AI output for mistakes sets out a review process.
Will schema markup get me into AI answers?
There is no reliable evidence that it guarantees this. It can make your facts clearer to systems that read it, which is useful, but it is one small part of being a clear and trustworthy source.
Who should own schema markup in a small team?
Someone who understands both the content and the site, often a marketer working with a developer. The key is to give one person responsibility for accuracy and review.
Conclusion
Schema markup is a tidy, honest way to label the facts on your pages so that machines can read them correctly. Start with a few well chosen types, base every value on what is visible and true, test everything and keep it up to date. AI can explain, draft and review, but it should never invent content or replace validation.
Begin with your home page and one blog post template. Check what is already being output, correct any gaps, validate and monitor. Once that is working, extend to other page types. For more context on how structured content supports answer tools, read our AEO guide, and for a refresher on giving clear instructions to AI tools, see how to write better prompts.
