Let me start with a confession: I have a schema markup problem. Not in the way that suggests I’m bad at it — more in the way that suggests I need to talk about it less at dinner parties. My partner has genuinely asked me to stop bringing up JSON-LD in social situations. Apparently, explaining the difference between author and reviewedBy properties isn’t considered “light conversation.” Fair enough.
But here’s the thing — if you’re working with YMYL (Your Money or Your Life) content, schema markup isn’t just a nice-to-have technical flourish. It’s becoming one of the most important signals you can send to search engines about the credibility, expertise, and trustworthiness of your content. And with the rise of LLMs and AI-powered search experiences, it’s only going to get more important.
This guide is everything I’ve learned about implementing schema for YMYL content over the past few years, including the mistakes I’ve made (there have been several), the approaches that actually work, and the things I wish someone had told me before I spent three days debugging a schema implementation that turned out to have a misplaced comma.
What YMYL Content Actually Means (And Why Google Cares)
YMYL stands for “Your Money or Your Life,” and it’s Google’s classification for content that could significantly impact a person’s health, financial stability, safety, or overall wellbeing. Think medical advice, financial planning guidance, legal information, news about current events, or any content where getting it wrong could genuinely harm someone.
Google holds YMYL content to a substantially higher standard than, say, a blog post about the best hiking trails in the Lake District. The Search Quality Rater Guidelines — the document Google gives to its army of human quality evaluators — explicitly states that YMYL pages require the highest levels of E-E-A-T (Experience, Expertise, Authoritativeness, and Trustworthiness).
This makes intuitive sense. If someone searches for “symptoms of a heart attack” or “how to file for bankruptcy,” the consequences of serving them inaccurate, misleading, or poorly sourced content are genuinely serious. Google knows this, and they’ve built their algorithms to be particularly cautious about which YMYL content they surface prominently.
So where does schema markup fit in? It’s one of the most direct ways you can communicate E-E-A-T signals to search engines in a structured, machine-readable format. Rather than hoping Google’s algorithms can figure out that your article was written by a qualified medical professional and reviewed by a board-certified specialist, you can tell them explicitly.
Why Schema Markup Matters More Than Ever for YMYL
There’s been a noticeable shift in how Google treats structured data over the past couple of years, particularly for YMYL content. While Google has always maintained that schema markup isn’t a direct ranking factor (and technically, they’re probably right), the practical reality is more nuanced.
Schema markup helps Google understand your content more accurately. When Google understands your content better, it can match it more precisely to relevant queries. When it matches more precisely, your content appears for the right searches. When it appears for the right searches, engagement metrics improve. When engagement improves… well, you see where this is going. It’s not a direct ranking factor in the same way that backlinks are, but calling it irrelevant to rankings would be like saying the engine isn’t important to a car because technically the wheels are what touch the road.
For YMYL content specifically, schema markup serves several critical functions:
- Author identification and qualification. Schema lets you explicitly connect content to named authors with verifiable credentials, professional affiliations, and published body of work.
- Medical and professional review signals. The
reviewedByproperty allows you to indicate that content has been reviewed by a qualified professional — a powerful trust signal for health, legal, and financial content. - Source and citation attribution. Structured data can help search engines understand the sources your content references, adding another layer of credibility.
- Organisation authority. Connecting content to legitimate organisations through schema reinforces the institutional credibility behind individual pieces of content.
Why Schema Matters Since LLM Growth
Here’s something that doesn’t get discussed enough: the rise of Large Language Models (LLMs) and AI-powered search experiences has made structured data more important, not less.
When ChatGPT, Google’s AI Overviews, Perplexity, or any other AI-powered system generates answers, it needs to evaluate the trustworthiness of its sources. Structured data provides exactly the kind of machine-readable trust signals these systems need. An AI system can parse JSON-LD far more reliably than it can infer author credentials from an unstructured bio paragraph buried in a sidebar.
Think about it from the perspective of an AI system trying to answer a medical question. It has access to thousands of articles about the topic. How does it decide which ones to trust? Author credentials, review processes, organisational backing, publication dates — all things that schema markup communicates clearly and unambiguously.
If you’re creating YMYL content and you’re not implementing comprehensive schema markup, you’re essentially asking AI systems to guess at your credibility rather than telling them directly. In a world where AI-generated search results are becoming the norm, that’s an increasingly expensive gamble.
Setting Up Author Schema: The Right Way
Let’s get into the practical implementation. Author schema is the foundation of YMYL schema markup, and it’s where most people either get it right or go spectacularly wrong. There doesn’t seem to be much middle ground.
Here’s what a properly implemented author schema looks like for a YMYL article:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Understanding Type 2 Diabetes Management",
"author": {
"@type": "Person",
"name": "Dr. Sarah Mitchell",
"url": "https://example.com/authors/dr-sarah-mitchell",
"jobTitle": "Consultant Endocrinologist",
"worksFor": {
"@type": "Organization",
"name": "NHS Foundation Trust"
},
"alumniOf": {
"@type": "CollegeOrUniversity",
"name": "University of Edinburgh Medical School"
},
"sameAs": [
"https://www.linkedin.com/in/drsarahmitchell",
"https://twitter.com/drsarahmitchell",
"https://orcid.org/0000-0000-0000-0000"
]
},
"datePublished": "2026-02-01",
"dateModified": "2026-02-10",
"publisher": {
"@type": "Organization",
"name": "Example Health",
"url": "https://example.com"
}
}
Let’s break down what matters here and why.
What Actually Makes a Difference
The author object is where the magic happens. Notice it’s not just a name string — it’s a full Person entity with properties that establish expertise. The jobTitle, worksFor, and alumniOf properties all contribute to building a picture of the author’s qualifications.
The sameAs property is particularly powerful. It creates explicit connections between the author entity on your site and their presence on other authoritative platforms. This helps search engines build a more complete understanding of who this person is and verify their credentials across multiple sources. Include LinkedIn profiles, professional directory listings, ORCID identifiers for academic authors, and relevant social media profiles.
The url property should point to a dedicated author page on your site — not just the homepage or a generic “about” page. This author page should itself contain comprehensive information about the person’s qualifications, publications, and expertise. Google has explicitly stated that they look at author pages when evaluating E-E-A-T.
The Gotchas Nobody Tells You About
Here’s where it gets interesting (and by “interesting” I mean “the things that cost me several days of debugging”):
Consistency is everything. The author name in your schema must match the author name displayed on the page, which must match the name on the author’s dedicated page, which must match their name on the linked sameAs profiles. Any inconsistency creates ambiguity, and ambiguity is the enemy of trust signals. I once spent two days trying to figure out why an author’s schema wasn’t being picked up, only to discover that the schema used “Dr. Sarah Mitchell” while the byline on the page said “Dr S. Mitchell.” Don’t be me.
Don’t use generic author entities. I’ve seen sites use “Editorial Team” or “Staff Writer” as the author in their schema. For YMYL content, this is essentially meaningless. Google wants to know that a real, identifiable person with relevant expertise created or reviewed the content. “Editorial Team” tells them nothing about expertise.
Keep dates honest. The dateModified property should reflect genuine content updates, not cosmetic changes. If you update the date every time you fix a typo, you’re undermining the trust signal. Google has gotten quite good at detecting when content hasn’t meaningfully changed despite a new modification date.
Implementing ReviewedBy Schema: The Secret Weapon
If author schema is the foundation, reviewedBy is the secret weapon for YMYL content. It signals that your content has been reviewed by a qualified professional — a practice that mirrors the editorial standards of authoritative publications and medical journals.
Here’s how to implement it properly:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Understanding Type 2 Diabetes Management",
"author": {
"@type": "Person",
"name": "Jane Cooper",
"jobTitle": "Health Content Writer",
"url": "https://example.com/authors/jane-cooper"
},
"reviewedBy": {
"@type": "Person",
"name": "Dr. Sarah Mitchell",
"jobTitle": "Consultant Endocrinologist",
"worksFor": {
"@type": "Organization",
"name": "NHS Foundation Trust"
},
"url": "https://example.com/reviewers/dr-sarah-mitchell",
"sameAs": [
"https://www.linkedin.com/in/drsarahmitchell",
"https://orcid.org/0000-0000-0000-0000"
]
}
}
This pattern is particularly powerful for content where the writer is a skilled communicator but not necessarily the subject matter expert. Having a medical doctor review health content, a qualified financial adviser review money content, or a practising solicitor review legal content adds a layer of credibility that pure author expertise can’t always provide. For a deeper look at how these signals apply in practice, my guide to E-E-A-T for financial services walks through the specific trust requirements Google applies to financial content.
The key is that the reviewedBy person must have demonstrably relevant credentials. A cardiologist reviewing an article about heart disease is meaningful. A dermatologist reviewing the same article is less so. Be specific and honest about who’s reviewing what.
Putting It All Together: A Complete Implementation
Here’s what a comprehensive schema implementation looks like for a YMYL article, bringing together everything we’ve discussed:
{
"@context": "https://schema.org",
"@type": "MedicalWebPage",
"headline": "Understanding Type 2 Diabetes: Symptoms, Treatment, and Management",
"description": "A comprehensive guide to Type 2 diabetes...",
"url": "https://example.com/health/type-2-diabetes-guide",
"datePublished": "2025-09-15",
"dateModified": "2026-01-20",
"author": {
"@type": "Person",
"name": "Jane Cooper",
"url": "https://example.com/authors/jane-cooper",
"jobTitle": "Senior Health Writer",
"description": "Health journalist with 8 years of experience covering endocrinology.",
"sameAs": [
"https://www.linkedin.com/in/janecooperhealth"
]
},
"reviewedBy": {
"@type": "Person",
"name": "Dr. Sarah Mitchell",
"url": "https://example.com/reviewers/dr-sarah-mitchell",
"jobTitle": "Consultant Endocrinologist",
"worksFor": {
"@type": "Hospital",
"name": "Royal Free London NHS Foundation Trust",
"url": "https://www.royalfree.nhs.uk"
},
"alumniOf": {
"@type": "CollegeOrUniversity",
"name": "University of Edinburgh Medical School"
},
"sameAs": [
"https://www.linkedin.com/in/drsarahmitchell",
"https://orcid.org/0000-0000-0000-0000",
"https://www.gmc-uk.org/doctors/0000000"
]
},
"publisher": {
"@type": "Organization",
"name": "Example Health",
"url": "https://example.com"
},
"about": {
"@type": "MedicalCondition",
"name": "Type 2 Diabetes",
"code": {
"@type": "MedicalCode",
"code": "E11",
"codingSystem": "ICD-10"
}
},
"citation": [
{
"@type": "CreativeWork",
"name": "NICE Guidelines: Type 2 diabetes in adults",
"url": "https://www.nice.org.uk/guidance/ng28"
},
{
"@type": "CreativeWork",
"name": "Diabetes UK: Type 2 Diabetes",
"url": "https://www.diabetes.org.uk/type-2-diabetes"
}
],
"lastReviewed": "2026-01-20"
}
Yes, it’s comprehensive. Yes, it takes time to implement properly. But for YMYL content, this level of detail is what separates sites that build sustainable organic visibility from those that watch their traffic erode with every core update.
Best Practices That Actually Matter
After implementing schema markup across dozens of YMYL sites, these are the practices that consistently make the biggest difference:
1. Build dedicated author and reviewer pages. Every person referenced in your schema should have a corresponding page on your site that provides comprehensive information about their qualifications, experience, and published work. These pages should be internally linked, crawlable, and themselves contain Person schema. This creates a web of reinforcing trust signals that search engines can verify.
2. Use the most specific @type available. Don’t use generic Article when MedicalWebPage, FinancialProduct, or another specific type is more appropriate. Specificity helps search engines understand the nature of your content and apply the right evaluation criteria.
3. Include citations and sources. The citation property lets you formally reference the authoritative sources your content draws from. For YMYL content, referencing NICE guidelines, peer-reviewed studies, government publications, or other authoritative sources adds genuine credibility — and schema lets you communicate those references in a structured way.
4. Keep everything synchronised. Your schema markup, visible page content, author pages, and external profiles should all tell a consistent story. Contradictions between structured data and visible content can trigger manual reviews and potentially be treated as spam.
5. Validate regularly. Schema markup can break silently — a CMS update, a template change, or a well-meaning developer “tidying up” the code can introduce errors that go unnoticed for months. Set up regular validation checks using Google’s Rich Results Test and the Schema Markup Validator. I check client implementations monthly at minimum.
Common Mistakes That Will Kick You in the Goolies
I’ve made most of these myself at one point or another, so this section comes from a place of hard-won experience rather than judgement.
Stuffing Schema with Irrelevant Properties
More is not always better. I’ve seen implementations where every conceivable schema property has been filled in, regardless of whether the information is accurate or relevant. An author’s birthDate, nationality, and homeLocation aren’t relevant trust signals for YMYL content. Focus on the properties that communicate expertise and credibility: jobTitle, worksFor, alumniOf, sameAs, and knowsAbout.
Copy-Pasting Schema Without Customisation
Template schema that’s identical across every page on your site is almost worse than no schema at all. If every article claims to have been reviewed on the same date by the same person, it looks automated and potentially deceptive. Each piece of content should have schema that accurately reflects its specific authorship, review process, and publication history.
Forgetting to Update Schema When Content Changes
If you update an article’s content but don’t update the dateModified, reviewer information, or other schema properties, you create a mismatch between what your structured data claims and what the page actually contains. This is particularly problematic for YMYL content where review dates matter — a medical article claiming a 2024 review date when the content was substantially rewritten in 2026 is misleading.
Ignoring the Visible Content
Schema markup should reflect what’s actually on the page, not what you wish was on the page. If your schema claims the content was reviewed by a doctor but there’s no visible mention of medical review on the page itself, that’s a red flag. Google has been increasingly clear that structured data must be representative of the page content. The visible byline, review credits, and author information should match what’s in the schema.
The Technical Bits You Actually Need to Know
JSON-LD vs. Microdata vs. RDFa
Use JSON-LD. That’s it. That’s the subsection.
Alright, I’ll elaborate slightly. Google explicitly recommends JSON-LD as their preferred format for structured data. It’s easier to implement, easier to maintain, easier to debug, and doesn’t require you to litter your HTML with attributes. You place it in a <script type="application/ld+json"> block, typically in the <head> of your page, and it lives completely separately from your content markup. This separation of concerns makes it far less likely to be accidentally broken by template changes or CMS updates.
Microdata and RDFa still work, but they’re harder to maintain, more prone to breaking, and offer no advantages over JSON-LD for this use case. Save yourself the headache.
Where to Put Your Schema
Place your JSON-LD in the <head> of the page. While Google can process JSON-LD anywhere in the HTML, placing it in the head is the convention, makes it easier to find during audits, and ensures it’s parsed early in the rendering process. If you’re using a CMS like WordPress, plugins like Yoast SEO or Rank Math can inject schema into the head automatically, though I’d recommend reviewing what they generate rather than blindly trusting the defaults.
Validating Your Implementation
Use these tools in this order:
- Schema Markup Validator (validator.schema.org) — checks that your markup is syntactically valid and uses recognised schema.org properties.
- Google Rich Results Test — shows you exactly how Google interprets your structured data and whether it qualifies for any rich result types.
- Google Search Console — monitors your structured data performance over time and alerts you to errors or warnings that affect your pages in production.
Run validation after every significant change to your templates, CMS, or content structure. Schema errors are silent — they won’t break your page or throw visible errors, but they will quietly undermine your structured data strategy.
Moving Forward with YMYL Schema Markup
Schema markup for YMYL content isn’t a one-time implementation — it’s an ongoing commitment to communicating trust signals accurately and comprehensively. As search engines become more sophisticated in how they evaluate content credibility, and as AI-powered search experiences become the norm rather than the exception, the sites that invest in comprehensive, honest, and well-maintained structured data will have a significant advantage.
Start with author schema. Get it right for your most important YMYL content. Add reviewedBy where you have genuine professional review processes. Build out dedicated author pages. Validate regularly. And please, for the love of all that is holy, check your commas in the JSON-LD.
If you’re working with YMYL content and feeling overwhelmed by the technical side of schema implementation, that’s genuinely understandable. This stuff is detailed and the documentation can be dense. Feel free to get in touch — I’m always happy to talk about schema markup. Just ask my partner. They’ll confirm I literally never stop.