Schema Bible for News & Blog Publishing (WordPress Edition)
Structured data (schema markup) is a powerful SEO tool for news and blog publishers. By adding schema (in JSON-LD format) to your pages, you help search engines understand your content and unlock rich search features.
This guide covers the most effective schema types and practices for content formats common to sites like Ladbible, GeeksForGeeks, Search Engine Journal, and Sportskeeda. It is structured as a “schema bible”, detailing:
- The best schema types for various article formats
- The optimal properties to include for maximum impact
- Advanced techniques focusing on high-impact schema (80/20 approach)
- Automation strategies for WordPress
- Common pitfalls and implementation tips
- JSON-LD examples and code snippets
The focus is on WordPress integration, whether through plugins or custom code, ensuring that implementing structured data at scale is as seamless as possible.
Best Schema Types for Different Article Formats
Different types of articles benefit from specific schema.org types. Selecting the most specific and relevant schema type helps search engines interpret and display your content appropriately. Below are the recommended schema types for common content formats.
| Schema Type | Best For | SEO Benefits & Features | Example Use Case |
|---|---|---|---|
| NewsArticle | Time-sensitive news content | Eligible for Top Stories carousel | Breaking news on LadBible |
| BlogPosting | Opinion/editorial blog posts | No extra SEO benefit over Article | Editorials on Search Engine Journal |
| HowTo | Step-by-step guides | Used for voice search & structured content | “How to fix a PC issue” on GeeksForGeeks |
| Review | Product/service reviews | Enables star ratings in search results | A gadget review on Sportskeeda |
| ItemList | Ranked lists (e.g., “Top 10”) | Can enhance list-style rich snippets | “Top 10 NBA players” on Sportskeeda |
News Articles
For news content involving timely reporting of current events, the NewsArticle schema type is the best choice. It is a subtype of Article, specifically intended for journalistic content.
Google’s documentation supports the use of Article, NewsArticle, or BlogPosting for article markup, but if the content is definitively news, using NewsArticle is preferred. This schema is especially useful for sites in Google News or those appearing in Top Stories carousels, as it helps search engines identify the content as news, improving eligibility for news-specific search features (such as the “Top Stories” carousel).
Example: For the keyword “What movie won the Oscars in 2025?”, CBS News appears in a featured snippet and the Top Stories carousel. By analyzing their schema markup, we can see how they effectively use the NewsArticle schema to help search engines recognize their content as news. This structured data enhances visibility, making their article eligible for rich results, boosting its ranking and clickability in Google Search.
If your site publishes live coverage updates, use LiveBlogPosting, a specialized schema type for real-time news feeds. This schema is ideal for:
- Live sports play-by-play coverage
- Breaking news updates
- Event-based reporting
Using LiveBlogPosting enables the “live” badge in Google’s Top Stories. However, for standard news articles, stick with NewsArticle on each article page.
Google treats NewsArticle similarly to Article/BlogPosting in terms of rich result eligibility. While using NewsArticle does not directly change how an article appears in search results (since all are valid), it provides semantic clarity for news content.
For instance, Ladbible and Sportskeeda should use NewsArticle for their news content to explicitly identify it as news. Additionally, there are subtypes of NewsArticle that can provide further specificity:
- ReportageNewsArticle – Best suited for factual reports.
- OpinionNewsArticle – Used for opinion pieces and editorials.
While these subtypes do not offer any direct SEO advantages over NewsArticle, they can help categorize content more precisely.
Opinion Pieces
Opinion or editorial articles, those that primarily express the author’s perspective or analysis, can be marked up using the NewsArticle schema. For greater specificity, you can use the OpinionNewsArticle subtype, which explicitly identifies the content as an op-ed or opinion piece.
If your publication has a dedicated opinions section, applying the OpinionNewsArticle schema can help distinguish these articles from standard news reports. For example, an editorial in Search Engine Journal or a columnist’s piece on a news site could use this subtype. In JSON-LD markup, this simply means replacing “@type”: “NewsArticle” with “@type”: “OpinionNewsArticle”.
That said, using OpinionNewsArticle does not provide any special SEO advantages over NewsArticle. Google does not require this granular distinction, so it is entirely optional. The NewsArticle schema is sufficient for opinion pieces, as long as key properties—such as headline, author, and date—are included. These elements, along with the article’s tone, will naturally indicate its opinion-based nature to both readers and search engines.
In summary: While OpinionNewsArticle can improve clarity, it is not necessary for SEO purposes. Using NewsArticle with well-structured metadata will work just as effectively.
Guides / How-To Content
“How-to” guides and tutorials are best structured with the HowTo schema, a specialized markup designed for instructional content that outlines a series of steps. This schema is ideal for DIY guides, programming tutorials, and step-by-step articles. However, for cooking recipes, a separate Recipe schema exists—though HowTo can still apply to general cooking instructions.
One key benefit of using HowTo markup is its potential to make your guide eligible for rich results, displaying step-by-step instructions directly in search results, especially on mobile. Google previously showed HowTo rich snippets prominently in mobile search, enhancing visibility.
Important Update: Google’s Changes to HowTo Rich Snippets
As of August 2023, Google deprecated How-To rich snippets for most sites, now limiting their display to specific cases. While your HowTo schema may not currently trigger a visual rich result unless you fall into a trusted category, it still provides structural clarity and potential benefits for voice assistants or other platforms that process structured data.
When to Use HowTo Schema
If your content is truly a step-by-step tutorial, applying the HowTo schema is recommended. Examples include:
- GeeksForGeeks articles (e.g., “How to do X in Python”)
- A tech site’s “Guide to Fix Common PC Issues”
The HowTo schema organizes content as an instructional guide with nested steps, making it easier for search engines and voice interfaces to interpret.
However, if your content is more of a general article without clearly defined steps, it’s better to use the standard Article schema instead.
Key Requirements for a Valid HowTo Schema
To ensure your HowTo markup is correctly structured, it must include:
- A name (title of the guide)
- At least one or more steps (Google previously required at least two steps for rich results)
While HowTo rich results are currently less visible in search, using this schema can still future-proof your content for potential new interfaces and evolving search features.
Reviews / Product Comparisons
When publishing a review of a product or service, applying the Review schema helps search engines recognize the content as a review. This markup is essential for earning review snippet-rich results, which display star ratings in search results, significantly boosting click-through rates.
Common use cases include:
- A tech blog’s gadget review
- A book review on a news site
- A “Top 10 X Reviewed” listicle
Implementing Review Schema
There are two main ways to structure Review schema on an article page:
1. Using Review as the Main Entity
If the entire page is a single-product review, you should set “@type”: “Review” in JSON-LD. This approach works best when an article is solely focused on reviewing one item.
Example:
A smartphone review page might use:
"itemReviewed": {
"@type": "Product",
"name": "Smartphone XYZ"
}
For books, movies, or other items, adjust “@type” accordingly (e.g., “@type”: “Book” or “@type”: “Movie”).
2. Nesting a Review Inside an Article
If a review is part of a broader article (e.g., a news piece with a review segment), the page should remain an “@type”: “Article” or “@type”: “NewsArticle”, while the review details are nested within as a “review” object.
Alternatively, the “mainEntity” of the article can point to a Review item, ensuring both the article context (author, publish date, etc.) and the review details remain intact. Google’s rich result algorithms can still detect and display valid reviews, even when nested.
Handling Multi-Product Reviews
For “Top 5 X Reviewed” listicles where multiple products are evaluated:
- You can include multiple Review objects within an “ItemList” or “Article”.
- However, Google’s rich results generally display only one rating snippet per page.
- Some sites use AggregateRating for the list as a whole or accept that only one review may trigger a snippet.
- If individual star ratings are not provided, you might skip Review schema and use ItemList instead.
Example: If you compare two SEO tools and rate them separately, each tool can be marked as a Review in JSON-LD. Google may or may not display both, but structuring the data properly is always best practice for SEO.
For listicle articles, such as “10 Best Coding Practices” or “5 JavaScript Frameworks to Know”, the base content type remains Article or BlogPosting. There is no dedicated “Listicle” schema type for prose-based lists. However, you can enhance listicles by incorporating the ItemList schema alongside the Article markup.
The ItemList schema, a structured data type from schema.org, defines a list of items (which can be things, articles, or other entities). This schema explicitly marks up the elements of a listicle, providing search engines with structured data about the page’s content.
Why Use ItemList Schema?
While ItemList schema is optional, it offers several potential benefits:
- Improved search engine understanding – It clarifies that your content is a structured list.
- Potential for featured snippets – Google may use ItemList markup to better extract and display lists.
- Possible carousel results – In the past, Google has used ItemList to generate list-based search features.
- Low-effort enhancement – Since your content is already a list, adding ItemList metadata is straightforward.
It’s worth noting that Google does not directly generate rich snippets for ItemList (as it does for FAQs), but structuring your data properly can help with indexing and discoverability.
Key Guidelines for Using ItemList Schema
To implement ItemList, follow these best practices:
Set “@type”: “ItemList”
- This defines the content as a structured list.
Use itemListElement to create an array of ListItem entries
- Each ListItem should include:
- position (1, 2, 3, …)
- item (The list entry itself)
Define itemListOrder (Optional)
- “Ascending” – If the list is ranked from lowest to highest.
- “Descending” – For “Top 10” lists where #1 is the most important.
- “Unordered” – If ranking doesn’t matter.
Specify numberOfItems (Optional)
- Helps search engines understand the total number of items in the list.
Example: Implementing ItemList Schema
For a “5 JavaScript Frameworks to Know” listicle, the JSON-LD markup would look like this:
{
"@context": "https://schema.org",
"@type": "ItemList",
"itemListOrder": "Unordered",
"numberOfItems": 5,
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"item": { "@type": "Thing", "name": "React" }
},
{
"@type": "ListItem",
"position": 2,
"item": { "@type": "Thing", "name": "Vue.js" }
}
// ... etc for positions 3,4,5
]
}This tells Google that the page contains a list of 5 items (React, Vue.js, etc.). While ItemList doesn’t directly produce a visual change in the snippet by itself, it provides structured context. Google could use it behind the scenes or as part of a featured snippet extraction (for instance, sometimes Google might show a list of steps or items from your page in a featured snippet — having ItemList markup might make that extraction easier or more accurate). It’s an easy, low-effort enhancement for listicles since your content is already a list – you’re just explicitly marking it as such in the HTML metadata.
In summary, for evergreen content and listicles:
- Use BlogPosting or Article as the base type unless it fits another category.
- Optionally add ItemList schema if the content is a list/collection.
- Focus on writing high-quality list content; the schema is just icing on the cake.
Now that we’ve identified the right schema types for various content, let’s dive into the specific properties and values you should include in each to get the most SEO benefit.
Optimal Schema Properties and Values
Choosing the right schema type is step one; step two is populating your structured data with optimal properties and values. Each schema type has required or recommended properties. Providing complete and accurate metadata boosts your chances of rich results and ensures compliance with Google’s guidelines. In this section, we outline the key properties for each content type’s schema, along with best practices for each:
Article / NewsArticle / BlogPosting: Key Properties
For any article (news or blog), Google looks for core properties in your Article/NewsArticle/BlogPosting markup. These include:
Headline
The article’s title should match the on-page title or be a shortened version if too long. Keep it concise, as Google may truncate after ~110 characters.
Example: “headline”: “Premier League 2025: Season Preview and Predictions.” Ensure the schema headline mirrors the actual title.
Image
The image URL (or multiple URLs) that represents the article. Google recommends using at least one image. For news articles, three images with different aspect ratios (1:1, 4:3, and 16:9) are ideal for various display formats, like thumbnails or desktop previews. Each image URL must be a full link and accessible by search engines. High-resolution images (at least 1200px wide) increase the chances of appearing in Top Stories.
Example: “image”: [“https://example.com/images/prime-minister-interview.jpg“, “…/prime-minister-interview-4×3.jpg”, “…/prime-minister-interview-16×9.jpg”]. If only one image is available, include it, but multiple images are better for different crops.
DatePublished
The publication date/time in ISO 8601 format (e.g., “2025-03-05T13:00:00+05:30”). It should match the visible published date on the page for consistency. Google may display this date in search results.
DateModified
The last modified date/time in ISO 8601 format. Update this value if the article changes after publication. Google may display the more recent of the published or modified date.
Author
The article’s author, which can be a Person or an Organization. Provide the author’s name and ideally a URL linking to their profile page, Wikipedia, or social profile. If an editorial team writes the content, use an Organization as the author (e.g., “author”: {“@type”: “Organization”, “name”: “LADbible”}). Best practice: have an author page on your site and use its URL in the author property.
Publisher
The publisher (usually your website or company). It is typically an Organization with a name and logo. Though not required, including it enhances structured data and knowledge graph information. The logo should be marked as an ImageObject with a URL (including width & height, if available).
Google often deduces the publisher from your domain or site-wide Organization markup, but explicitly adding it in Article schema is beneficial.
Description
A brief summary of the article, similar to the meta description. While not required for rich results, it provides useful context for search features.
MainEntityOfPage
The page URL where the article is the main content. This property links the Article schema to the canonical URL, ensuring clarity when JSON-LD is extracted.
Example: “mainEntityOfPage”: {“@type”: “WebPage”, “@id”: “https://example.com/your-article-url”}.
(Optional) ArticleSection
The article’s category or section (e.g., “Sports”, “Technology”). Useful for news publishers to indicate content classification. Populate this from your CMS taxonomy.
(Optional) Keywords
Tags or keywords associated with the article (e.g., [“Premier League”, “2025 season”]). While not required for rich results, they add completeness.
(Rarely used) ArticleBody
The full text of the article. Though supported in schema.org, it is usually omitted from JSON-LD to avoid excessive markup size. Google crawls the page’s HTML to retrieve content.
In practice, the critical fields for Google’s article rich results are headline, image, datePublished, dateModified, and author. If you include those (and they’re all valid), your Article or NewsArticle schema will be eligible for rich result features (like appearing with image and date in Top Stories, or showing the date in a regular result, etc.).
Publisher is good to have, and mainEntityOfPage is strongly recommended. Description, section, and keywords are nice-to-haves when available.
To illustrate, here’s a simplified JSON-LD example for a news article with these properties:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/news/city-ordinance" },
"headline": "City Council Passes New Traffic Ordinance",
"image": [
"https://example.com/images/traffic-ordinance1.jpg",
"https://example.com/images/traffic-ordinance1-4x3.jpg",
"https://example.com/images/traffic-ordinance1-16x9.jpg"
],
"datePublished": "2025-03-01T10:00:00Z",
"dateModified": "2025-03-01T15:30:00Z",
"author": {
"@type": "Person",
"name": "Jane Reporter",
"url": "https://example.com/authors/jane-reporter"
},
"publisher": {
"@type": "Organization",
"name": "ExampleNews",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png",
"width": 300,
"height": 50
}
},
"description": "The city council introduced a new traffic congestion charge for downtown, aiming to reduce rush-hour jams. The policy will take effect next month..."
}
</script>(This JSON-LD would appear in the <head> of the article page. It includes the key fields discussed. In a WordPress context, much of this can be generated dynamically — which we’ll cover in the automation section.)
HowTo Properties
A HowTo schema has its own set of properties to describe an instructional guide. Important properties include:
- Name – The title of the how-to. For example: “name”: “How to Tie a Tie”. This should be the name of the task or process.
- Step – The steps to complete the how-to. This is the most critical part of HowTo markup. The step property is an array, and each item in it can be represented in a few ways:
- The simplest way is just an array of text strings (but that is not ideal for rich results).
- The recommended way is to use HowToStep items, which are entities that can have their own subproperties like name (title of the step) and text (detailed instructions), and optionally an image for that step.
- If your how-to is logically divided into sections (each with multiple steps), you can use HowToSection entities which contain their own steps. Each HowToSection could have a name, and then an array of steps (which could be HowToStep or plain text). Most straightforward: Use HowToStep for each step. At minimum, each HowToStep should have either a text or a name + text. Google’s examples typically show providing a name (like “Step 1: Do X”) and text (the instruction details). You can also include an image for each step if applicable (e.g., a step screenshot or illustration).
- Image (of the HowTo as a whole) – A representative image for the how-to, as a whole. This could be the final result or an image that encompasses the process. For example, if the how-to is “How to Bake a Chocolate Cake,” the main image might be of the finished cake. This image is separate from step-specific images. Include this as “image”: “https://example.com/path/to/overview-or-final-result.jpg”.
- TotalTime – The total time required to complete the how-to (if applicable). This should be in ISO 8601 duration format (e.g., “PT30M” for 30 minutes or “PT1H20M” for 1 hour 20 minutes. Not every how-to will have a meaningful total time (some tasks have variable time), but for things like recipes, DIY projects, etc., it’s useful to include.
- Tool – Tools required to complete the task (if any). This can be a simple text list or an array of HowToTool items. E.g., “tool”: [“Hammer”, “Nail puller”] or as structured objects. This property is optional and mainly for DIY type guides.
- Supply – Consumable supplies or materials needed (if any). For example, in a recipe this would be ingredients; in a DIY project, materials like lumber or glue. You can list them as text or as HowToSupply structured items.
- estimatedCost – The estimated cost of doing the how-to, if relevant. This can be given as a text string or a MonetaryAmount. For example: “estimatedCost”: “$10-15” or as structured JSON with currency and value.
- yield – The result produced by the how-to. This is mostly used in recipes (e.g., “serves 4”) or crafts (e.g., “makes 1 chair”). It describes what outcome or quantity to expect.
Minimum requirements: Google’s rich result guidelines for HowTo (when they were active) required at least a name and step with at least 2 steps (so that it’s not just a one-step thing). Each step should ideally have some description text. If you structure steps as HowToStep items, each should have a text field describing that step.
For example, the steps part of a HowTo JSON-LD might look like:
"step": [
{
"@type": "HowToStep",
"name": "Step 1: Fold the tie over collar",
"text": "Flip up your collar and drape the tie around your neck... (more instructions)",
"image": "https://example.com/images/tie-step1.jpg"
},
{
"@type": "HowToStep",
"name": "Step 2: Cross the wide end over the narrow end",
"text": "Take the wide end and cross it over the narrow end, just below your chin..."
}
]Here we gave each step a name and text, and even an image for step 1. This level of detail is great for completeness. Ensure that the text in the schema for each step matches (or is very close to) the instructional text visible in the article for that step. Discrepancies between step instructions in schema vs on-page could cause Google to ignore the markup or not trust it.
Tip: If using WordPress and you have a lot of how-tos, you might use a plugin or block for HowTo (Yoast provides a HowTo block) which automatically structures these steps for you. Or, you can parse your how-to content in PHP to generate the steps (for example, split content by headings or a specific delimiter).
Even though Google isn’t showing HowTo rich results broadly at the moment, still include these properties for future-proofing, and to benefit any other consumers of structured data. Google’s decision may change, and other platforms (e.g., voice assistants) could utilize your HowTo markup.
Review Schema Properties
When using Review schema (for product reviews, service reviews, etc.), important properties include:
IitemReviewed
The item that is being reviewed. This is typically a Product (if you’re reviewing a product), or it could be any other schema type depending on what’s being reviewed (could be Book, Movie, Game, SoftwareApplication, LocalBusiness, etc.).
At minimum, provide the item’s @type and name. If you have more details about the item, you can nest them here (for a Product, you might include the brand, model, etc., but it’s not mandatory).
For example: “itemReviewed”: { “@type”: “SoftwareApplication”, “name”: “SEO Pro Tool”, “applicationCategory”: “SEO software” }. The idea is to identify the thing being reviewed.
ReviewRating
The rating given in the review. This should be a Rating object with at least a ratingValue (the numeric score). You should also include bestRating and worstRating if your scale is not 5 or 1 respectively. By default, schema.org assumes worstRating is 1 and bestRating is 5 if you don’t specify them. But it’s good practice to include them for clarity, especially if you use a 10-point scale or something.
For example: “reviewRating”: {“@type”: “Rating”, “ratingValue”: 4, “bestRating”: 5} indicates a 4/5 rating. If your review has no numeric rating (some reviews are just text without stars), you might omit reviewRating entirely or use reviewRating with just an explanation. However, to get the star snippet in Google, a numeric rating is needed.
Author
The author of the review (the reviewer). This can be a Person or Organization. In most cases it will be a Person with a name (the name or username of who wrote the review). For editorial reviews on your own site, the author might be one of your writers.
For user-submitted reviews, it would be the user’s name/handle. Provide at least the name. (You could link to the author’s profile with sameAs or url if relevant, but that’s optional.)
ReviewBody
The textual content of the review – basically the review text itself or a summary of it. This is where you put the main text of what the reviewer said. If the review is identical to the article content, you might either use a summary here or not include it if redundant. But typically, if you have a dedicated review, you put the review text.
Name
The title of the review. Not all reviews have a title (often on blogs, the review’s title is just the article’s title which is the product name + “Review”). You can often omit this or just use something like “XYZ Review” if needed. It’s optional. For example, if your article is titled “SEO Pro Tool Review”, you might put “name”: “SEO Pro Tool Review”.
DatePublished
The date the review was published. If your article already has Article markup with datePublished, and you nest a Review, it doesn’t hurt to also include datePublished on the Review. But if the Review is the main entity, definitely give it a datePublished.
Publisher
If this review is published by an editorial source (like your website as a known source), you can include a publisher property referencing your Organization (the site).
This is more relevant for “Critic reviews” that Google sometimes shows (like in movie or book knowledge panels, Google distinguishes critic reviews and user reviews). It’s optional for most implementations, but for credibility you can include your site as the publisher of the review.
InLanguage
You can specify the language of the review content, e.g., “inLanguage”: “en” for English. This is optional and mostly for clarity if your site has multi-language content.
If your page is just a single review of one item (the common scenario), marking it up with all the above is fairly straightforward. Make sure the content on the page supports what the schema says: the itemReviewed name should match the product name mentioned on the page, the rating value should match any star rating displayed visually (if you show 4/5 stars on the page, make sure it’s 4 in the JSON). Consistency is key to avoid Google flagging it.
For example, here’s a snippet of a JSON-LD for an editorial review on a blog:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Review",
"name": "SEO Pro Tool Review",
"itemReviewed": {
"@type": "SoftwareApplication",
"name": "SEO Pro Tool",
"applicationCategory": "SEO software"
},
"reviewBody": "SEO Pro Tool is a comprehensive SEO platform offering keyword research, backlink analysis, and site auditing. In our tests, it performed exceptionally well in backlink discovery but fell short in UI intuitiveness...",
"reviewRating": {
"@type": "Rating",
"ratingValue": 3.5,
"bestRating": 5,
"worstRating": 1
},
"author": {
"@type": "Person",
"name": "John Doe"
},
"datePublished": "2025-03-01"
}
</script>This JSON-LD indicates that John Doe reviewed “SEO Pro Tool” and gave it 3.5/5 stars, with the review text provided. If this script is included on a page, Google could show a search result snippet with “★★★★★ 3.5 – 120 reviews” (if it had multiple reviews or an aggregate) or just stars with 3.5 if it’s a single review.
Now, if a page contains multiple reviews (e.g., “Top 5 Phones of 2025, each with a mini-review”), you could include multiple Review objects in your structured data (one for each phone). However, Google’s rich results typically only show one rating per page (usually associated with the main entity).
A workaround for lists of reviews is sometimes to use an AggregateRating instead of individual reviews, but that’s only if you are aggregating user ratings. For editorial “round-up” lists, AggregateRating isn’t usually applicable unless you calculated an average. It’s often fine to mark up multiple reviews, but be aware Google might only use one.
If your “Top 5” list doesn’t actually provide star ratings for each item (maybe it’s just pros/cons text), then don’t use Review at all; you might just use ItemList for the list and perhaps mention ratings in text.
Important guidelines for reviews (from Google’s rules): (We will cover more in the pitfalls section, but worth noting here)
- Don’t mark up content as a Review if it’s not actually a review. The page should contain a genuine review (an opinion and a rating/assessment).
- The ratingValue must be visible to users on the page if you include it in schema. You can’t hide a rating in JSON-LD that’s not shown in some form on the page.
- Only one review per item per page – don’t, for example, mark up the same product twice on one page.
- No self-serving reviews: If you (the site) are reviewing your own product or service and adding markup to your page, Google considers that “self-serving” and generally disallows those rich results. For example, if a business posts a “review” of their own product on their site with 5 stars, that violates Google’s rich snippet guidelines. They want reviews to be independent.
List / ItemList Properties
If you implement an ItemList schema (for listicle pages as discussed), the primary properties are:
- itemListElement – An array of items in the list. Typically these are ListItem objects when you want to provide an order. Each ListItem should include:
- position – the position/rank in the list (1 for the first item, 2 for second, etc.).
- item – the actual item. This could be just a generic Thing with a name, or it could be a more specific type (Article, Product, etc.), possibly with an @id or URL reference. Often, if each list item doesn’t have its own page, you’ll just use a Thing with a name. If each item does link to another page, you might do something like: “item”: {“@type”: “Article”, “@id”: “https://example.com/page-for-item1”, “name”: “Item Title”}.
- itemListOrder (optional) – Indicates whether the list is ordered in some way. Acceptable values: “Ascending”, “Descending”, or “Unordered”. For ranked lists like “Top 10”, you’d use “Descending” if position 1 is the top rank. If it’s just a list with no inherent order (like “5 JavaScript frameworks” in no particular order), you can specify “itemListOrder”: “Unordered” (or just omit this property, which implies no specific order).
- numberOfItems (optional) – The count of items in the list. It’s a good idea to include this as a double-check (though Google can count the elements anyway). E.g., “numberOfItems”: 5.
The example we gave above already demonstrates these. One more example in JSON form:
"@type": "ItemList",
"itemListOrder": "Descending",
"numberOfItems": 3,
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"item": { "@type": "Thing", "name": "Alpha Gadget" }
},
{
"@type": "ListItem",
"position": 2,
"item": { "@type": "Thing", "name": "Beta Gadget" }
},
{
"@type": "ListItem",
"position": 3,
"item": { "@type": "Thing", "name": "Gamma Gadget" }
}
]This would represent a list of 3 gadgets ranked 1 through 3.
As mentioned, ItemList on its own doesn’t give you a fancy rich snippet. But Google could use the structured info in other ways (for example, understanding that it’s a list might help if Google ever creates a “carousel” from your list, or just helps it identify the list items if returning a featured snippet).
Best practice: If you use ItemList, don’t include the current page itself as an item in its own list (that wouldn’t make sense). Only list the actual list entries.
Video Object Properties (for embedded videos)
If your article/page includes a video (e.g., an embedded YouTube video or self-hosted HTML5 video), you should use the VideoObject schema to mark it up. Google can generate video-rich results (with a video thumbnail, duration, etc.) if it detects a video on the page, especially if it’s marked up. This can be an additional enhancement alongside your article snippet.
Key VideoObject properties include:
- name – Title of the video. Ideally the same as or similar to the video’s title displayed on the page or on YouTube.
- description – A description of the video. Similar to a YouTube description or summary of what the video is about.
- thumbnailUrl – URL of a thumbnail image for the video. This should be a static image representing the video content. Provide a high-quality thumbnail URL that Google can fetch. (If the video is on YouTube, you could use the YouTube thumbnail URL or host your own.)
- uploadDate – The date the video was uploaded or published, in ISO format. If you embedded a YouTube video, use the upload date of that video if known, or the date it was published on your site.
- duration – Duration of the video in ISO 8601 format (e.g., “PT2M15S” for 2 minutes 15 seconds). This is useful for Google to potentially display the length.
- contentUrl – A URL to the actual video file content (e.g., an .mp4 file) if accessible. This is more relevant if you host the video yourself. If the video is on YouTube or another platform, you might not have a direct file URL, so this could be omitted or replaced by embedUrl.
- embedUrl – A URL that can be used to embed the video, e.g., the YouTube embed iframe src URL. For a YouTube video, this would be something like “https://www.youtube.com/embed/VIDEO_ID”.
- publisher – The publisher of the video (usually an Organization). For instance, if your site produced the video, you can list your org as the publisher with a name and logo. If it’s a YouTube video by someone else, sometimes examples include the YouTube channel as the publisher.
- potentialAction – This is a more advanced property where you can specify a WatchAction, indicating that a user can watch the video. Google sometimes uses this for rich result actions. It’s not required and a bit advanced, but schema supports it.
Typically, you would include VideoObject as a separate JSON-LD block or nested inside your Article’s JSON-LD. Often, it’s nested via an Article’s “video”: { …VideoObject… } property. Alternatively, you can have two top-level scripts: one Article and one VideoObject, and tie them with e.g. the VideoObject having the same @id as referenced in the Article’s video property. But nesting is simpler.
Example of VideoObject JSON-LD nested in an Article:
"video": {
"@type": "VideoObject",
"name": "Interview with John Doe on SEO Trends",
"description": "John Doe discusses the latest SEO trends in this exclusive interview.",
"thumbnailUrl": "https://example.com/images/john-doe-interview-thumb.jpg",
"uploadDate": "2025-02-20T10:00:00Z",
"duration": "PT5M30S",
"embedUrl": "https://www.youtube.com/embed/abc123XYZ"
}If you host the video yourself, you might have “contentUrl”: “https://example.com/videos/interview.mp4” instead of (or in addition to) the embedUrl. In the example above, we used an embedUrl for a YouTube video.
Google often automatically detects if you have an embedded YouTube and will fetch info from YouTube, but adding VideoObject ensures your page is recognized as having that video. This can help your page appear in Google’s video search results or get the video badge on the result. It’s especially useful for self-hosted videos or if you want your page (not YouTube) to be indexed as the video page.
A few best practices for video schema:
- Ensure the thumbnailUrl is accessible (not blocked by robots.txt) and is of good quality.
- Use a descriptive description (could be shown in video-rich results).
- Provide either contentUrl or embedUrl so Google knows where to get the video.
- Include duration and uploadDate as they are commonly used in search display.
- If multiple videos on one page, you can mark them all up (but Google usually will focus on one main video per page for rich result).
- If the video is the main content of the page (like a video page), sometimes you might even use VideoObject as the primary schema type of the page instead of Article. But on a news/article page with a video, it’s best to include VideoObject as a secondary object (either nested or in the same graph with a relation).
FAQ (FAQPage) Properties
If your content includes a FAQ section (a list of questions and answers, typically at the end of an article or on a dedicated FAQ page), you can implement the FAQPage schema.
This schema type can produce rich FAQ snippets in Google results – which appear as expandable Q&A under your search result. (Note: as of 2023, Google has limited FAQ rich results to certain authoritative sites, but the schema is still worthwhile to implement properly.)
The main structure for FAQPage schema is straightforward:
- The container is an object with “@type”: “FAQPage”.
- It has a property mainEntity which is an array of Question objects.
For each Question in that array:
- name – The question text (as shown on the page).
- acceptedAnswer – An Answer object containing the answer to that question.
- The Answer object should have “@type”: “Answer” and a text property that includes the answer content. You can include basic HTML in this text if needed (for example, <p> or <br>), but keep it simple (no complex formatting).
Essentially, you list each FAQ exactly as it appears on your page. The schema should mirror the actual questions and answers.
Example:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "What is the refund policy?",
"acceptedAnswer": {
"@type": "Answer",
"text": "You can request a full refund within 30 days of purchase. After 30 days, refunds are prorated."
}
},
{
"@type": "Question",
"name": "How do I contact support?",
"acceptedAnswer": {
"@type": "Answer",
"text": "You can contact our support team via the support form on our website or by emailing support@example.com."
}
}
]
}This JSON-LD corresponds to two Q&A pairs on the page (exactly as the user would see them).
Guidelines for FAQPage:
- The questions and answers must exist in full on the page, visible to users (no sneaky hidden answers just in JSON). The structured data should be a true reflection of an FAQ section on the page.
- FAQPage is meant for lists of questions with answers provided by the site (the content creator). It is not meant for user-generated Q&A or forum threads. (If you have a Q&A where users submit answers, that’s a different schema type: QAPage with Question and multiple answers, often used for sites like StackExchange). Using FAQPage for the wrong purpose can lead to a manual action.
- Don’t duplicate the same exact FAQ across many pages. Google has noted that having the same FAQ content on multiple pages can be seen as a way to grab SERP space and they dialed down FAQ snippet frequency because of that abuse. It’s fine if some questions overlap, but don’t put an identical FAQ block on every single page.
- Keep answers relatively short and to the point. If an answer is very long, Google might truncate it in the search snippet (or choose not to show the FAQ at all). A sentence or two, or a short list, is good for snippet purposes.
- As of late 2023, Google only shows FAQ rich results for well-known authoritative government and health sites (and possibly a few others). This means if you’re not one of those, your FAQ schema might not generate a rich snippet. However, it’s still useful to implement (it won’t hurt), and it could be that Google re-enables it broadly in the future or uses the data in other ways (Assistant, etc.). Also, if your site becomes authoritative enough, you never know.
Many WordPress SEO plugins or page builder blocks can automatically handle FAQ schema. For instance, Yoast SEO offers an “FAQ” content block in the Gutenberg editor that, when used, injects the corresponding FAQPage schema for you. This can simplify implementation (no need to hand-code JSON).
Organization & Author (for E-E-A-T)
In addition to content-specific schemas for each page, it’s important to mark up information about your Organization (the publisher of the site) and your content Authors. This provides context across the site and contributes to what Google calls E-E-A-T signals (Experience, Expertise, Authoritativeness, Trustworthiness).
These aren’t tied to one specific article, but rather give background about who is producing the content.
Organization schema: This typically goes on your homepage (and/or can be included on all pages in a global JSON-LD). It describes your website’s publishing organization or business. Key properties to include in an Organization schema are:
- name – The name of your organization or site.
- url – Your website URL (canonical).
- logo – An ImageObject with the URL of your logo (and ideally width/height).
- foundingDate – When the org was founded (good for establishing history).
- founder(s) – The founder(s) of the organization (could list one or multiple, each as a Person with a name).
- address or contactPoint – Contact info like physical address, phone, or email for the organization (especially if you are a business with a location or support contact, etc.).
- sameAs – Links to official social media profiles, Wikipedia page, Crunchbase, etc. that corroborate your organization’s identity.
- award or memberOf – Any notable awards or memberships (if applicable).
- parentOrganization – If your site is owned by a larger parent org, or if you have multiple brands, you can indicate relationships.
Including robust details in Organization schema helps Google’s Knowledge Graph verify details about your brand. It can contribute to getting a Knowledge Panel for your site, and it’s generally a trust signal (it shows you’re transparent about who you are).
For example, Search Engine Journal’s organization markup might include “founder: Loren Baker, founded: 2003, sameAs: Wikipedia, Twitter, LinkedIn, etc.” – these details help connect the dots for Google.
For WordPress sites, often the SEO plugin will ask for organization info (Yoast, during onboarding, asks “are you an organization or person?” and then asks for name/logo). Yoast will then output an Organization schema (and a Website schema) site-wide. Make sure to configure those settings so that your org name and logo are correctly passed to the structured data.
Person (Author) schema: Each content author on your site should ideally be marked up as a Person. The simplest way to do this is via the Article’s author property (as we covered, that already creates a Person with name, and possibly a URL). However, you can enrich this by creating full Person entries, especially on author profile pages.
On an author bio page (e.g., example.com/author/john-doe), you could include a JSON-LD:
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://example.com/authors/john-doe",
"name": "John Doe",
"jobTitle": "Technology Reporter",
"affiliation": {
"@type": "Organization",
"name": "TechNews Daily"
},
"knowsAbout": ["Artificial Intelligence", "Blockchain", "Cybersecurity"],
"sameAs": [
"https://www.linkedin.com/in/johndoe",
"https://en.wikipedia.org/wiki/John_Doe_(Journalist)"
]
}This example shows John Doe’s Person schema with jobTitle, an affiliation (his employer), a list of topics he “knows about” (areas of expertise), and links to external profiles. This kind of detailed author markup can strongly signal expertise. Google’s quality raters (in the Search Quality Rater Guidelines) consider the expertise of the author; while schema isn’t a direct ranking factor, providing this info in structured form “can only help” Google connect the dots algorithmically about your authors.
Even if you don’t go all-out on author pages, you can still include some of these in the Article’s author property via Person. For example, you could structure the Article’s author as:
"author": {
"@type": "Person",
"@id": "https://example.com/authors/john-doe",
"name": "John Doe",
"affiliation": { "@type": "Organization", "name": "TechNews Daily" },
"knowsAbout": ["AI", "Blockchain"],
"sameAs": ["https://www.linkedin.com/in/johndoe"]
}Then on the author page have a matching Person entry with that @id. This way, each article references a richly-described Person node.
Properties you might include for Person (Author):
- name
- affiliation (the Organization they work for, or multiple via an array if freelance)
- jobTitle (e.g., “Senior Editor”)
- education, qualifications, or credentials (if relevant; schema.org has things like alumniOf or hasCredential you could use to show degrees, etc., particularly for medical or financial authors).
- image (URL to author’s photo)
- sameAs (links to social media, personal website, Wikipedia, etc.).
- knowsAbout or expertise fields (topics of expertise).
- (Potentially) author’s experience – there’s no direct property for “years of experience”, but a bio in description or a CV via sameAs can imply it. Experience (the first E in E-E-A-T) can be partially demonstrated by content (like an author’s posts themselves).
Including these details on author pages indirectly boosts E-E-A-T by making it easier for Google to see that Author X on your site is the same Author X with a LinkedIn profile that shows her experience, etc. It helps establish that your authors are real people with authority.
Also, if you have content that is reviewed or fact-checked by another person (common in YMYL niches: Your Money Your Life topics like health or finance), you could use properties like reviewedBy on the Article to link to a Person who reviewed the content (e.g., a doctor). Google specifically calls out reviewedBy as a way to add trust for medical or scientific content.
To tie it together: by providing Organization and Person schema, you supply search engines with machine-readable evidence of who you are and who is behind your content. This reinforces E-E-A-T:
- Experience – Not a direct schema property, but can be inferred via detailed bios or content history.
- Expertise & Authoritativeness – Via credentials, affiliations, awards in the schema.
- Trustworthiness – Via transparent org info (address, contact) and clear author identities.
Most SEO plugins will output a basic Organization and link your authors to Person schema automatically once configured. For example, Yoast SEO by default outputs an Organization (or Person if you set the site to represent a person) and for each post, it includes a Person for the author and links it to the Organization.
Make sure those are set up correctly (check your homepage’s JSON-LD to see if Organization is there, and an article page to see if author is properly nested). If not, you may need to manually add or use an additional plugin.
With the core schemas and properties covered, now we move to some advanced techniques that can further enhance your SEO (and how to implement them efficiently in WordPress).
Advanced Schema Techniques (80/20 High-Impact Markup)
Beyond the basic article (or review) schema, there are advanced structured data techniques that follow the “80/20 rule” – a little extra effort can yield significant SEO benefits. These help capture additional search features like voice results, video enhancements, and rich snippet extensions.
Here we’ll cover five key advanced schemas for publishers: Speakable, VideoObject (advanced usage), FAQPage (proactive Q&A snippets), Breadcrumb, and Organization/Author enhancements for E-E-A-T, along with how to implement them effectively.
Speakable Schema (for Voice Search)
Speakable schema is a niche but forward-looking markup that indicates which parts of your news articles are best suited for text-to-speech. Google introduced Speakable (in beta) for news publishers to facilitate content delivery via voice assistants like Google Assistant.
By adding speakable markup, you highlight a snippet (or snippets) of your article that Google can read aloud as an answer to voice queries.
Use case
Speakable is mainly intended for news articles from publishers that are eligible for Google News. For example, if someone asks their Google Home “What’s the latest news on [Topic]?”, Google might use speakable markup from a news article to read a few lines and then prompt the user to visit the full story. Essentially, it’s for brief news summaries over voice.
Currently, speakable is officially supported only for English news content in the U.S. (as a beta). Publishers need to go through a Publisher Center process and possibly be whitelisted by Google to have their speakable content actually used.
So, adding speakable markup alone doesn’t guarantee Google will use it. There’s an approval process (to ensure only reliable news sources are used for voice readouts).
However, adding speakable schema is harmless even if you’re not yet in that program. It “future-proofs” your content for voice search. As voice search grows, Google may expand speakable to more publishers and locales. So if you produce news articles, it’s worth implementing a method to flag key points as speakable with minimal effort (like via a template or editor feature).
Implementation
The speakable specification is actually a property of an Article (or NewsArticle) schema. You add a “speakable” property to your NewsArticle JSON-LD. The value is a SpeakableSpecification which can contain up to three kinds of content locators:
- CSSSelector – One or more CSS selectors (as an array) that pinpoint the element(s) on the page that are speakable. For example, you might wrap your article’s summary paragraph in <div class=”speakable-summary”>…</div> and then use “cssSelector”: [“.speakable-summary”] in the JSON.
- Xpath – One or more XPaths to the content in the page. (This is an alternative to CSS selector; you’d rarely use this on a WordPress site unless CSS selectors are difficult.)
- Voice – (Less commonly used in examples) some implementations allow directly including text. But that’s static and not dynamic, so it’s better to use CSS selectors to point to actual HTML content.
A common approach is to have a snippet at the top of your news article (like a few sentences summary or the lede) and wrap it in a dedicated element (class or ID). Then reference that in speakable.
Example: Suppose we have an article and we identify the first two sentences as the key summary. In the HTML we do:
<p class="speakable-summary">The city council passed a new ordinance today aimed at reducing traffic congestion downtown. The policy will introduce congestion charges during peak hours starting next month, according to officials.</p>Then, in our NewsArticle JSON-LD, we add:
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".speakable-summary"]
}This tells Google that the content within the speakable-summary element on the page is especially suitable for text-to-speech. In practice, Google would read that text out if the article is chosen for a voice query.
Best practices for speakable content:
- It should be concise and able to stand alone (self-contained). Think of it as a brief news blurb that makes sense when read aloud out of context.
- Use short sentences and clear language. Avoid very long or complex sentences that might be hard for text-to-speech to parse.
- Don’t include things like captions, dates, or source attributions in the speakable snippet, as those can confuse the listener or are unnecessary in voice.
- Typically 2-3 sentences (approximately 20-30 seconds of audio) is a good length for the speakable section.
- Only mark one or two sections at most. You wouldn’t mark an entire article as speakable (that defeats the purpose, which is to give a short answer and then have the assistant invite the user to hear more).
Eligibility note: As mentioned, currently only certain publishers in US English are seeing usage of speakable, and those have often gone through a whitelisting process. If you implement this and are a Google News publisher, you might consider applying or checking Google’s guidelines on how to get speakable content approved. Even if not, leaving it in won’t harm anything; Google will just ignore it until it’s ready to use it.
From an effort standpoint, speakable is an 80/20 tactic because adding one property to your JSON-LD (and maybe wrapping a bit of content in a <div>) for each news article is a minor effort that could yield significant presence in voice search down the line.
Video Object (Video Schema for Embedded Content)
We already discussed video schema properties in the earlier section. Here, the advanced focus is more on when and how to use VideoObject in your strategy.
If your content includes videos, marking them up with VideoObject schema is a must-do advanced tactic that can greatly enhance visibility. Video schema makes your videos more discoverable in Google’s video search and can add a video thumbnail or “video” badge to your regular search snippets.
When to use: Anytime you have a significant video on a page. Common scenarios:
- A news article with a video clip (e.g., a news site embedding a relevant YouTube video or their own footage).
- A blog post with a video demonstration or interview.
- A how-to guide with an accompanying tutorial video.
- A product review with a video review embedded.
For publishers like LADbible or Sportskeeda who often post video-centric articles, VideoObject is essential for each post with a video. Even for occasional videos, it’s worth doing.
How to implement: Include a VideoObject JSON-LD alongside your Article markup. As noted, you can either nest it inside the Article schema (add a “video”: { … } in the Article JSON), or add it as a separate <script> block. If separate, you might connect them by using an @id. But if nested, make sure the Article is aware of it (most simply, just include it as a property).
Ensure the video’s meta info is accurate:
- Use the same title for VideoObject.name as the video’s actual title on the page or platform.
- Write a descriptive description that covers what’s in the video.
- Provide the thumbnailUrl. If it’s a YouTube video, you might fetch the default thumbnail or specify your own.
- Include uploadDate (the date you published or the video was uploaded).
- Include duration if known (you can get this from the video metadata or YouTube API if needed).
- contentUrl vs embedUrl: If you self-host, use contentUrl to the video file (or a playable link). If you embed from a third-party (YouTube, Vimeo), use embedUrl (and/or the page URL of the video, but embed is fine).
- You can also include optional things like interactionCount for view count, expires (if a video will go offline at a certain date), regionAllowed if geo-restricted, etc., but those are less commonly used. One emerging property is hasPart for clip markup if you have chapter timestamps, but that’s more advanced.
Example revisited: A Search Engine Journal article with an embedded video interview might have:
"video": {
"@type": "VideoObject",
"name": "Interview with John Doe on SEO Trends",
"description": "John Doe discusses the latest SEO trends in this exclusive interview.",
"thumbnailUrl": "https://www.searchenginejournal.com/videos/john-doe-interview.jpg",
"uploadDate": "2025-02-20T10:00:00Z",
"duration": "PT5M30S",
"embedUrl": "https://www.youtube.com/embed/abc123XYZ"
}This would be embedded in the Article JSON-LD under the “video” property. Google’s crawlers will pick up that there’s a video and can show a rich snippet with a play icon or maybe show the thumbnail in results.
Google often automatically detects YouTube embeds, but marking it up can ensure that your page is recognized as the video page (not just YouTube). This can help if you want your site to show up in video search results rather than deferring to YouTube. It’s also known that using VideoObject markup is important if you want to appear in Google Discover (Google Discover can show video stories – having the video markup and high-quality images helps).
Keep in mind: If the video is the main content of the page (like a video page), you might actually mark the entire page as a VideoObject instead of an Article. But on typical news or blog pages, the video is supplemental to the article text, so you do both: Article + nested VideoObject.
FAQ Schema (to Dominate Q&A Snippets)
We described FAQPage schema implementation in detail above, so here the “advanced” angle is about using FAQ schema strategically to dominate SERP real estate and address user questions.
Adding a small FAQ section to the end of articles has become a common SEO strategy. For instance, after a blog post, you might add “People also ask” style questions relevant to the topic, and answer them. By marking this with FAQPage schema, your search result could show those questions under your listing, making it much larger on the screen (and potentially pushing competitors down).
This was very effective in 2019-2021 until Google limited FAQ rich results. If you’re an authoritative site (or become one), you might still get them. If not, you can still include FAQs because they’re genuinely helpful to users.
Advanced tip: Proactively include FAQ sections on relevant pages to target long-tail questions related to your main content. For example, if you have an article about “How to improve site speed,” you might add an FAQ: “Q: Does a CDN improve site speed? A: Yes, a Content Delivery Network can help by…”, etc. These might snag some impressions for related queries or at least satisfy curious readers.
But: Avoid doing this on every single page just for the sake of schema, as Google now ignores widespread FAQ usage by generic sites. Focus on pages where Q&As truly add value.
From a WordPress implementation perspective, using a block or a custom field group for FAQs can simplify adding them. Plugins like Yoast SEO (as mentioned) have a FAQ block that automatically adds the necessary JSON-LD. If coding manually, you might create a repeater field (with subfields for question and answer) and then output a FAQ schema from that.
Also, keep an eye on Google’s stance. If they ever re-enable FAQ snippets broadly, having yours in place could give you an edge. If not, the FAQ content still enriches your page for readers, which is good for user experience and potentially even for SEO in terms of content depth.
Breadcrumbs (BreadcrumbList Schema for Site Hierarchy)
Breadcrumb navigation links (like Home > Category > Article) are both a UX element and an SEO asset. They show users (and crawlers) the path hierarchy of the site. Google often displays breadcrumbs in the search results in place of a URL, giving users a cleaner idea of where the page sits on your site.
For example, instead of example.com/2025/03/01/long-ugly-url, Google might show Example Site > Category > Page Title in the snippet.
To enable this, implement BreadcrumbList schema on your pages. Most WordPress themes or SEO plugins that have breadcrumb functionality will output this schema for you.
For instance, Yoast SEO has an option to enable breadcrumbs in your theme; if you use Yoast’s breadcrumb function in your template, it will automatically inject BreadcrumbList schema in the HTML. Similarly, the Breadcrumb NavXT plugin can output structured data.
If you need to add it manually:
- Use BreadcrumbList as @type.
- Provide itemListElement as an array of ListItem. Each ListItem represents one level in the breadcrumb trail.
- For each ListItem:
- position: 1 for the first (usually Home), 2 for next, etc..
- item: an object with @id (the URL of that breadcrumb page) and name (the title of that page).
So on an article page, the breadcrumb JSON might look like:
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"item": { "@id": "https://example.com/", "name": "Home" }
},
{
"@type": "ListItem",
"position": 2,
"item": { "@id": "https://example.com/category/", "name": "CategoryName" }
},
{
"@type": "ListItem",
"position": 3,
"item": { "@id": "https://example.com/category/article-page", "name": "Current Page Title" }
}
]
}Often, sites don’t include the current page as a clickable link in the breadcrumb trail (it might be just text). In schema, some leave out the current page item or include it. Google’s structured data examples include it, but they also accept it without it. Including it with an @id and name is fine.
Why it matters:
Breadcrumb schema reinforces your site’s structure to Google. It can improve how your result is displayed – showing the breadcrumb trail in green text, which looks nicer and can improve CTR (as users see a navigational context rather than a raw URL). It also helps Google understand site hierarchy (for example, that your page is under “Sports News” section of your site).
Breadcrumb schema doesn’t directly give a “rich snippet” beyond that URL replacement, but that in itself is a nice improvement. It’s also beneficial for accessibility and for some search features (Google might use breadcrumbs in something like sitelinks generation).
Implementation in WordPress:
If you’re using Yoast SEO, the easiest route is:
- Enable the Yoast breadcrumb feature (via Yoast settings or code).
- Insert yoast_breadcrumb() in your theme template where you want breadcrumbs.
- Yoast will then output the breadcrumb links and add the JSON-LD BreadcrumbList to the page’s head automatically.
This way, you don’t have to manually code the JSON at all. Similarly, other SEO plugins or breadcrumb plugins do the heavy lifting.
If you prefer custom code, you could generate a BreadcrumbList JSON based on the WP hierarchy (e.g., Home > if category exists > category > article). But plugin solutions are reliable.
Once set up, breadcrumbs are “set and forget” – implement site-wide (on all pages) and you usually don’t have to tweak it much after. Just ensure it’s outputting correctly on all page types.
Organization & Author (Enhanced E-E-A-T Signals)
We discussed the properties for Organization and Author in the previous section, but in the advanced context, it’s about leveraging additional properties to fully flesh out these entities, reinforcing E-E-A-T.
For Organization: go beyond just name/logo. Consider adding:
- Founder and FoundingDate to establish how long you’ve been around (history can imply trust).
- Address and/or contactPoint to show real-world presence (especially if you are a business or publisher with offices).
- SameAs links to social media, Wikipedia, Crunchbase, etc., to connect to external authority signals.
- Awards or memberOf if your organization has any notable recognitions or belongs to industry groups (e.g., a member of Online News Association, etc.).
- Unique identifiers if relevant (like taxID, leiCode, Dun & Bradstreet number) for bigger organizations – probably overkill for most.
- If you have a parent company or if this is a publication of a larger media group, you can link that via parentOrganization or subOrganization.
All these give more context about your organization’s authority. For example, Search Engine Journal’s Organization markup could include founder info and sameAs links to show it’s a known entity founded in 2003. This kind of detail can feed into Google’s Knowledge Graph and help it recognize your brand.
For Person (Author): beyond name, you can incorporate:
- jobTitle (e.g., “Senior Editor”, “Staff Writer”).
- affiliation (the Organization they work for, which is your Organization – linking them in schema ties the author to your org).
- education or credentials: For example, if an author is a MD or PhD and that matters (like medical content), you could indicate that via something like hasCredential or just mention in description. Schema.org has Medical schema for MedicalDoctor etc., but that’s a deep level only needed if you’re a health site.
- knowsAbout: topics of expertise (e.g., [“Search Engine Optimization”, “Content Marketing”]).
- image: link to author’s profile photo (some sites do this).
- sameAs: link to author’s LinkedIn, Twitter, personal blog, etc..
- description: a short bio of the author.
If your site posts author bios on each article, you can mark those up as structured data as well (e.g., wrap the author bio in a Person itemprop in microdata, or just ensure the JSON-LD for author contains it).
Indirect E-E-A-T benefit:
While Google’s algorithms for E-E-A-T aren’t fully disclosed, providing this structured data can help algorithms verify and cross-reference information about the author and publisher.
For instance, if the author’s sameAs links to a LinkedIn that matches the name and shows the jobTitle, that corroborates the expertise. It addresses some questions a quality rater might ask (like “Does the author have expertise on this topic?”) by giving clues in metadata.
One more advanced tip: If your content is medically or scientifically sensitive (YMYL topics), consider using more specific schema types for authors or reviewers.
For example, you can mark a medical author as MedicalDoctor (subtype of Person) or a legal author as Attorney in schema, or use MedicalScholarlyArticle if appropriate. These are edge cases, but it shows how far schema can go. Only do this if it truly applies, as adding misleading schema is not good.
In summary, the advanced use of Organization and Author schema is about richly describing the entities behind your content. It’s part of that extra 20% effort – adding more properties and keeping those profiles up-to-date – but it can yield an outsized benefit in how Google perceives the authority of your site and writers. It’s especially worthwhile for publishers in YMYL niches (finance, health, etc.), but even for general news and tech sites, it adds professionalism and trust.
Implementation note: Many SEO plugins already output basic Organization/Person. For example, Yoast will output Organization (with name/logo you set) and Person for the author (name, and link to author page). Check what your plugin is doing. You may just need to fill in the author’s social profiles in WordPress (Yoast can add sameAs from those fields) or use additional plugins to extend Person schema. There are plugins like “Schema & Structured Data for WP” which even include fields for author schema, speakable, etc. If you need to custom implement, you can add a <script> on author pages with Person JSON-LD including those details (and ensure the @id matches what you put in articles).
Having covered advanced schemas, let’s now discuss how to implement these schemas efficiently across a WordPress site, and how to automate the process so you’re not manually writing JSON for every post
Automation Strategies for Large-Scale Content Publishing
For a large publishing site producing content at scale, manually crafting JSON-LD for each post is not feasible. The goal is to automate schema markup generation so every article, guide, or review gets the appropriate structured data without extra effort from content creators. Here are strategies to achieve this in WordPress:
Leverage SEO/Schema Plugins (Plug-and-Play Method)
One of the easiest ways to implement schema across a large site is to use established WordPress plugins that handle structured data. These can save you from coding and stay updated with Google’s changes.
Popular options:
Yoast SEO (and Yoast SEO Premium):
Yoast automatically adds base schema to your pages. By default, Yoast will output a WebPage and Article schema for posts, complete with the author (Person) and website (Organization) info you set in its settings.
It basically creates a linked data “graph” including Organization, WebSite, WebPage, and Article on each page. It also handles breadcrumbs (if you use Yoast’s breadcrumbs) by outputting BreadcrumbList schema. Additionally, Yoast offers the HowTo and FAQ Gutenberg Blocks – if you use those blocks in your content, Yoast will automatically inject the corresponding HowTo or FAQPage schema for that part of the content.
In short, using Yoast means out-of-the-box compliance with Google’s basic article schema guidelines. You don’t have to think about Article markup at all; just ensure your Yoast settings (under SEO → Search Appearance) have the correct defaults (like marking posts as Article, etc. – though Yoast usually does Article for posts by default).
Rank Math SEO:
Rank Math is another all-in-one SEO plugin with robust schema features. It lets you choose a default schema type for posts (Article, BlogPosting, or NewsArticle, etc.) in its settings. You can also edit schema on a per-post basis with a Schema Generator UI.
Rank Math even allows multiple schema types on one post. For example, using their UI, you can add an FAQ schema or Recipe schema to a specific post, in addition to the default Article.
Rank Math Pro has Schema Templates which are very powerful: you can define a template for a certain schema (say a Review schema structure) and set conditions for it to auto-apply (e.g., all posts in “Reviews” category get this schema). This means you configure it once, and every new post meeting that condition gets the schema injected automatically. It’s similar to writing your own conditional code, but via a GUI.
All In One SEO (AIOSEO):
Another SEO plugin with schema capabilities. Like Yoast/Rank Math, it outputs default schema for pages (WebPage, Article) and has settings for Knowledge Graph info (Organization/Person). It also supports some specific types like LocalBusiness schema, etc. AIOSEO is quite similar in what it covers out of the box.
Dedicated Schema Plugins:
Schema Pro (by Brainstorm Force) – a plugin specifically for adding schema markup.
Schema & Structured Data for WP & AMP (by Magazine3) – a comprehensive schema plugin. These allow you to create custom schema templates and map them to post types or categories, similar to Rank Math’s templates.
For example, with Schema Pro you could create a “Review Schema” template where you map the post’s title to itemReviewed.name, a custom field (like a rating field) to reviewRating.ratingValue, etc., and then assign that template to all posts in the “Reviews” category.
Once set up, every time someone publishes a post in that category, the schema is added automatically. The Magazine3 plugin is known to cover even things like Speakable, FactCheck (ClaimReview schema), etc., out of the box.
Using a plugin is often the 80/20 approach for schema – you configure it once, and it covers the majority of cases correctly. Also, plugins usually keep updated with Google’s changes. For example, if Google changes the requirements for Recipe schema, the plugin developers will update the plugin so you don’t have to tweak code.
Tips when using plugins:
Configure Organization/Person info properly:
In the plugin settings, set your organization name, logo, etc. Yoast, for instance, asks on first setup whether the site represents a person or organization, and if organization, it asks for name and logo. Fill those in. That populates the Organization schema. If a person (like a personal blog), it will use your name as Person schema site-wide.
Choose the right default schema type:
If you run a news site, set the default schema type for posts to NewsArticle (Rank Math allows this easily in its settings). If it’s a personal blog, maybe BlogPosting is more appropriate.
Yoast by default outputs a NewsArticle or BlogPosting depending on context (Yoast actually outputs a base Article which Google is fine with for either news or blog). Rank Math explicitly lets you set “Article Type: NewsArticle” globally for posts. Aligning this with your content ensures consistency.
Use plugin blocks/features for special content:
For example, if you have an FAQ section, use the Yoast FAQ block instead of manually formatting it – this will ensure valid markup is added. If you’re using Rank Math, use its schema generator to add an FAQ or HowTo or Recipe snippet as needed (Rank Math’s meta box allows you to pick from predefined schema types to add to the post).
This way, you leverage the plugin’s knowledge of proper schema structure instead of writing JSON yourself.
Avoid conflicts:
If you have multiple plugins outputting schema, be careful. You don’t want duplicate JSON-LD for the same thing.
For instance, if you use Yoast SEO and also activate Schema Pro, you might end up with Yoast outputting Article schema and Schema Pro also outputting Article schema for the same post, causing duplicates. Ideally, use one primary plugin for base schema. Others you use only for additional types not covered.
Some plugins allow you to turn off certain schema types to prevent overlap. E.g., Schema Pro lets you disable its Article markup if Yoast is handling it, and only use Schema Pro for other schema types. Configure accordingly. Duplicate schema can confuse Google or at least lead to one set being ignored (and can trigger warnings in testing tools).
Keep the plugin updated:
Schema standards and Google’s preferences evolve. Good plugins update themselves.
For example, Google recently changed how it treats HowTo and FAQ (limiting their appearances) and dropped some requirements – Yoast adjusted in response by not outputting certain things or by following new rules. Keeping your SEO/plugin up to date ensures you get those changes. Likewise, if Google deprecates a field, plugin devs often remove it to avoid errors.
If your site has many custom content needs, you might even use a combination: e.g., Yoast for base + custom code for something niche, but generally stick to one to avoid complexity.
Custom Functions in Theme/Plugin (Coding Your Schema)
For maximum control or very complex custom schema needs, you can use custom code in your theme’s functions.php or a custom site-specific plugin to generate schema. This approach is developer-centric but lets you tailor the JSON-LD exactly as you want.
Here’s a general approach to rolling your own schema in WordPress:
Identify Post Types or Conditions for Schema:
Decide on logic based on post type, category, tags, etc. to determine what schema to output. For example:
- If is_singular(‘post’) and the post is in category “News”, you will output a NewsArticle schema.
- If category is “HowTo” (meaning it’s a how-to article), use HowTo schema.
- If a custom field is_review is true (or post format is “Review”), output Review schema.
- If is_page() and it’s a specific FAQ page, output FAQPage schema.
- etc. Essentially, map out which template or taxonomy implies which schema. This mirrors what we did conceptually in earlier sections.
Use WordPress template tags to fetch content:
Grab the needed data from WordPress for the schema fields. For example:
- get_the_title() for the headline.
- get_the_date(DATE_W3C) for datePublished (DATE_W3C constant formats date in ISO 8601).
- get_the_modified_date(DATE_W3C) for dateModified.
- get_the_author() or get_the_author_meta(‘display_name’) for author name (and get_author_posts_url() for author URL).
- get_the_post_thumbnail_url($post_id, ‘full’) for the featured image URL.
- get_post_meta() for any custom fields (like a stored rating, or a recipe cook time, etc.).
- Your category/tags via has_category() or in_category() to decide type, etc..
Build the JSON-LD structure:
In PHP, create an associative array representing the schema, then later wp_json_encode() it to output JSON. Ensure to add “@context”: “https://schema.org” and the “@type” at the top of the structure. You’ll populate this array step by step:
- Start with array( ‘@context’ => ‘https://schema.org’ ).
- Determine @type based on your conditions in step 1. (e.g., $schema[‘@type’] = ‘NewsArticle’; if news category, else if how-to category $schema[‘@type’] = ‘HowTo’; else default to ‘BlogPosting’).
- Then add properties: $schema[‘headline’] = get_the_title($post_id);, $schema[‘datePublished’] = get_the_date(DATE_W3C, $post_id);, etc..
- For nested objects, create sub-arrays. E.g., for author:
php $schema[‘author’] = array( “@type” => “Person”, “name” => get_the_author_meta(‘display_name’, $author_id), “url” => get_author_posts_url($author_id) );
. - For publisher:
php $schema[‘publisher’] = array( “@type” => “Organization”, “name” => “YourSiteName”, “logo” => array( “@type” => “ImageObject”, “url” => “https://example.com/path/to/your-logo.png” ) );
. - If image exists:
php if ($img_url) { $schema[‘image’] = $img_url; }
. - If certain type has extra stuff: e.g., if type is HowTo, build the steps and attach: if ($schema[‘@type’] == ‘HowTo’) { $steps = generate_howto_steps($post_id); // custom function to parse content into steps $schema[‘step’] = $steps; $schema[‘name’] = get_the_title($post_id); }
.
You’d have to write generate_howto_steps to maybe split the content or use custom fields for steps. - Similarly, you could add conditions for Review: if you had a rating meta, do $schema[‘reviewRating’] = array(…); etc. Or for FAQ: if this page is FAQ, gather the Q&As (perhaps from a repeater field) and structure them accordingly.
Output the JSON-LD in the page HTML:
In WordPress, you can hook into the page head to print your JSON-LD script. For example, use add_action(‘wp_head’, ‘my_add_schema_markup’) with priority, and inside that function, echo the <script> tag with wp_json_encode($schema).
You want it in the <head> so that it’s available to crawlers immediately (especially for Google News content, it’s recommended to have JSON-LD inline in the initial HTML, not injected later via JS).
Let’s piece it together with an example function (simplified):
function my_add_schema_markup() {
if (is_single()) { // only do on single post pages
$post_id = get_the_ID();
$schema = array();
$schema['@context'] = "https://schema.org";
// Determine @type based on category
if (has_category('News', $post_id)) {
$schema['@type'] = 'NewsArticle';
} elseif (has_category('How-To', $post_id)) {
$schema['@type'] = 'HowTo';
} else {
$schema['@type'] = 'BlogPosting';
}
// Common properties
$schema['mainEntityOfPage'] = array(
"@type" => "WebPage",
"@id" => get_permalink($post_id)
);
$schema['headline'] = get_the_title($post_id);
$schema['datePublished'] = get_the_date(DATE_W3C, $post_id);
$schema['dateModified'] = get_the_modified_date(DATE_W3C, $post_id);
$schema['author'] = array(
"@type" => "Person",
"name" => get_the_author_meta('display_name', get_post_field('post_author', $post_id)),
"url" => get_author_posts_url(get_post_field('post_author', $post_id))
);
$schema['publisher'] = array(
"@type" => "Organization",
"name" => "YourSiteName",
"logo" => array(
"@type" => "ImageObject",
"url" => "https://example.com/logo.png"
)
);
// Include featured image if available
$img_url = get_the_post_thumbnail_url($post_id, 'full');
if ($img_url) {
$schema['image'] = $img_url;
}
// Additional schema for specific types
if ($schema['@type'] == 'HowTo') {
$steps = generate_howto_steps($post_id); // custom function to build steps array
$schema['step'] = $steps;
$schema['name'] = get_the_title($post_id);
}
// (You could add similar blocks for reviews, FAQs, etc.)
// Output the JSON-LD script
echo '<script type="application/ld+json">' . wp_json_encode($schema) . '</script>';
}
}
add_action('wp_head', 'my_add_schema_markup');Let’s break down what this function does (confirming with the comments inline):
- It runs on every page load (wp_head), checks if it’s a single post page.
- It initializes the $schema array with context.
- Determines @type by checking categories: if the post is in category “News”, sets type to NewsArticle; if in “How-To”, sets HowTo; otherwise defaults to BlogPosting.
- It then fills in the common properties: mainEntityOfPage (pointing to the canonical URL), headline, datePublished, dateModified, author (Person with name and URL), publisher (Organization with name and logo).
- It grabs the featured image URL and, if present, adds it as image.
- If the schema type turned out to be HowTo, it calls a helper to build steps and adds them, also ensuring the HowTo has a name property (some schemas like HowTo might expect a name at the top level which is the title of the how-to, we reuse the title).
- (We commented that you could add similar logic for reviews or FAQs: e.g., if schema type == Review, gather rating, etc.)
- Finally, it outputs the JSON-LD by encoding the array as JSON and echoing it inside a <script type=”application/ld+json”>.
This function would generate appropriate schema for each post without manual effort per post. As long as your categories or identifiers are correctly assigned, it will pick the right schema type and populate fields.
Deployment: If you code custom functions like this, ideally put them in a child theme or a custom plugin so that they persist through theme updates. Document the schema logic in comments so future developers know what it’s doing.
Performance: JSON-LD is just text, usually a few hundred bytes to a few kilobytes per page. That’s negligible for performance. Generating it involves some database calls (for title, meta, etc.) but those are very light and similar to what the page already does for content. Just ensure you’re not doing anything extremely heavy in wp_head (like complex loops or remote API calls). The example above is pretty light. If you have thousands of posts, it’s fine – each page load only handles its own JSON, not all posts at once. So custom schema code generally won’t slow down your site if done as shown.
Maintenance: If Google’s guidelines change, you’ll need to adjust your code. E.g., if they suddenly required a new property, you’d have to add it. Keep an eye on Google updates or use testing tools regularly.
Automatic Schema Based on Templates or Custom Fields
This concept overlaps a bit with using plugins (like Schema Pro or RankMath templates) and custom coding. The idea is to use existing site structure to automate schema:
Using templates:
You can leverage WordPress template hierarchy. For instance, if you have a custom post type for “Book Reviews”, you could create a single-book_review.php template that includes a specific JSON-LD (like Review schema for a Book).
Or if you have a category “Recipes”, you might in your theme detect that category and output a Recipe schema skeleton. Essentially, baking the schema rules into your theme templates can be an approach. But nowadays using plugin conditions or the wp_head hook as above is more flexible than editing many templates.
Using custom fields:
Sometimes automation means structuring your content input. For example, you might have custom fields for “Recipe Ingredients” and “Recipe Instructions” on a post. Then you can easily map those to the Recipe schema properties when outputting JSON.
If those fields are empty, maybe you don’t output that schema. So encouraging editors to fill in specific fields can lead to automated schema. Tools like ACF (Advanced Custom Fields) paired with custom code can achieve this.
For instance, you add ACF fields for “Is this a review?” (boolean), “Product Name”, “Rating value”, etc., on posts. If filled, your code knows to output a Review schema using those values.
Using post metadata:
WordPress now has the concept of post formats (aside from categories/tags). For example, if you set a post format to “video”, you could trigger adding VideoObject markup. Or if format is “aside” vs “standard”, though that’s less relevant to schema.
Essentially, “automatic schema based on templates or fields” is already what we exemplified in custom code – using category and custom field conditions. If your site has a clear content model, you can encode that in either plugin rules or code.
Example scenario: You run a site with how-to guides, product reviews, and regular blog posts, but they’re all just posts in WordPress (not separate post types). You could:
- Add a dropdown custom field “Content Type” with options: HowTo, Review, Article.
- The editors select the appropriate type when writing.
- Your wp_head code checks that field: if “HowTo”, do howto schema; if “Review”, do review schema; if “Article” (or empty), do normal Article schema.
- For Review, you’d also have fields for rating, etc., which the code uses.
This is a bit of extra process for editors but ensures each post gets the right schema without the editor needing to know schema at all – they just fill fields.
If you prefer not to rely on manual selection, using categories as we did is an alternative (just categorize posts as “HowTo” etc., and let code decide). Both approaches can work; it depends on editorial workflow.
Scaling and Maintenance
Once you have an automation solution in place (whether via plugin or custom code), maintaining it is relatively easy:
- Monitoring: Keep an eye on Google Search Console’s Enhancements reports (they will show if Google detects schema issues on your site) and use the Rich Results Test periodically on sample pages to ensure your schema is being read correctly. If Google adds new rich result types or changes requirements, update your approach accordingly.
- Content changes: If you introduce a new content format on your site, update your schema logic. For example, if you start publishing interviews that have transcripts and you want to add Speakable or QAPage, you might extend your code or plugin use to cover that.
- Collaboration: Educate your content team about any inputs needed (like those custom fields). Provide a checklist: e.g., “When writing a review, please fill the ‘rating’ field and attach a product image,” etc. This ensures the schema output is complete. Over time, this becomes routine.
- Performance considerations: If you find any slowdowns, debug them. But as noted, schema generation is usually lightweight. Just avoid doing things like querying all posts within wp_head (you should only query data for the current post).
- Multi-plugin conflicts: Make sure after any major plugin updates that you aren’t accidentally doubling up schema. Occasionally, plugin updates might add new schema output that overlaps with your custom stuff; you then might want to disable one to avoid duplicative markup.
By implementing schema across your site automatically, you essentially make structured data a background feature of your CMS: editors just create content as usual, and the system handles the SEO markup. This is ideal, because it reduces human error (no forgetting to add schema or typos in JSON) and ensures consistency.
To conclude this section: automation can be achieved with either robust plugins or custom coding or a mix of both. Many large sites use a combination (e.g., Yoast for base + custom code for some specifics not handled by Yoast). The approach depends on your resources: non-developers will lean on plugins; developers might craft a tailored solution. Either way works – what’s important is that every page that can benefit from schema gets it, with minimal ongoing effort.
Next, let’s review some common mistakes to avoid when implementing schema, to ensure all this effort yields positive results and not penalties.
Common Schema Mistakes to Avoid
Implementing structured data can boost SEO, but mistakes in schema markup can lead to errors, missed opportunities, or even penalties. It’s crucial to get schema right. Here are common pitfalls to be aware of (and avoid):
- Using the Wrong Schema Type: Ensure the schema type matches the content. Don’t force a schema on content that doesn’t qualify. For example, marking a regular blog article about your services as a Product just to try to get a rich snippet is incorrect (since that page isn’t a product page selling an item). Google can issue manual actions for “inappropriate structured data” if you deliberately or ignorantly miscategorize content. Always choose the closest matching type that reflects the content’s true nature (NewsArticle for news, Recipe for actual recipes, Product for actual product pages, etc. – not just for whatever rich snippet you want). In short, don’t lie in your schema.
- Schema-Content Mismatch: The structured data must match the visible content on the page. This is a big one:
- Don’t put a different author or date in JSON-LD than what’s shown on the page. For instance, if the page says “By Alice on Jan 1, 2025” but your JSON says author Bob or date Dec 31, 2024, that’s a mismatch.
- If your page says “4 out of 5 stars” as a rating, ensure ratingValue: 4 (out of 5) in the schema, not 5 or something else.
- For prices, availability, etc. (like in Product schema), any discrepancy between schema and page text can trigger a manual action. Google considers it spam if, say, you mark $9.99 in schema but show $14.99 on the page or hide the price on page.
- If you mark up an FAQ question and answer, that exact Q&A should be present on the page word-for-word.
- Essentially, schema is meant to be a formalized summary of what’s on the page — not an opportunity to add info that’s missing or different. Maintain parity.
- Violating Specific Schema Guidelines: Many schema types have additional rules set by Google. Some examples:
- For Review schema: Don’t markup reviews that are self-serving or not by an actual third-party. If you (the site) write a review of your own product or service and mark it up, that’s against Google’s rich snippet guidelines. They only want reviews that are independent. Google actually made a big change in Sept 2019 to stop showing self-serving local/business reviews (sometimes called “Starmageddon”). Violating this can lead to a Structured Data Spam penalty.
- For Recipe schema: If you use it, include the required fields like ingredients, and the instructions should match what’s on page. Also, obviously, don’t use Recipe schema for something that’s not a food recipe (sounds silly, but people have tried).
- For FAQ schema: As mentioned, don’t use it for user Q&A content (that should be QAPage). Also, Google said avoid repetitive FAQs across the site.
- For Event schema: If you mark up an event, make sure to update or remove the markup once the event is over. Showing an event as “upcoming” when it’s past is against guidelines. In general, always read Google’s developer docs for any structured data type you implement. They outline specific dos and don’ts. A quick check can save you from weeks of lost rich results due to a manual action (recovering from a penalty can be time-consuming).
- Violating General Structured Data Policies: These are broader:
- No hidden or irrelevant markup: Don’t mark up content that users can’t see, or that isn’t directly related to the main content. For example, don’t dump a bunch of unrelated FAQ questions in schema that aren’t actually on the page, or mark up some random sidebar info as if it’s the main content.
- No spammy content in schema: Don’t stuff keywords or promotional language into your JSON-LD thinking “Google will read this even if users don’t see it.” Google will ignore or even penalize spam in structured data just like in visible content. E.g., don’t make your product name in schema “Buy Cheap iPhone X – Best Price”, just put the actual product name.
- Not all pages need all schema: Avoid over-marking up things sitewide that don’t apply. Ex: Don’t put an FAQ schema on every page unless every page literally has an FAQ section. Similarly, don’t put Organization markup on every article page in a way that suggests that article is an Organization (the Organization schema should be at the site level or in the publisher property, not as the primary thing on an article page). Another example: If you have breadcrumbs on the site, fine to include BreadcrumbList on all pages, but if not, don’t include an empty BreadcrumbList JSON. Basically, use schema where it makes sense for the content on that page.
- Duplicate or Conflicting Schema: Be careful not to output schema twice for the same thing. For instance, if two plugins each output an Article schema, you end up with duplicate JSON-LD that might both be picked up. This can confuse Google or lead to one being ignored. It might not directly hurt rankings, but it’s messy and can trigger warnings in SDTT (Structured Data Testing Tool) or Rich Results Test. Additionally, if those duplicates have slight differences, it could be considered “conflicting” info:
- E.g., one schema says author is “John”, another says author is “Jane” for the same page – that’s conflicting.
- Or two LocalBusiness schemas on the same page with different phone numbers. To avoid this, audit your pages with a testing tool to see what schema is being output. If duplicates are found, adjust your setup (disable one source). Google’s Rich Results Test will list all detected schemas – use that to debug.
- Overlooking Updates: As noted, schema and Google’s usage of it evolve. A common mistake is implementing schema once and never revisiting. For example, Google announced in Aug 2023 that it would greatly reduce FAQ and HowTo snippets (only showing for certain sites). If you weren’t aware, you might be puzzled why your FAQ rich results disappeared (it’s not that your schema broke, it’s that Google changed policy). Similarly, Google might deprecate certain properties or requirements.
E.g., they might say “We no longer use the description property in HowTo for rich results” – actually, Google did indicate the description field for HowTo is no longer required and not used for how-to rich results. If you continue using outdated markup (like including something that’s deprecated or failing to include a newly required field), you might not be eligible for new features or you could get warnings. It’s good to periodically validate a few pages or read Google’s updates on structured data. - Lack of Testing and Validation: Failing to test your structured data can lead to errors going unnoticed. Always:
- Use the Google Rich Results Test on sample pages. It will show if your JSON-LD parses correctly and whether you’re eligible for certain rich result types. It also flags errors or warnings (e.g., missing recommended fields).
- Use the Schema Markup Validator (on schema.org) for a more general check beyond Google’s rich results. This can catch JSON syntax errors or things that Google’s tool might not highlight.
- Check Google Search Console regularly under Enhancements or Rich Results reports. If Google finds errors at scale, it will list them (e.g., “Missing field ‘author’ in Article”). This is useful to detect issues after publishing many pages.
- If you spot issues, fix them promptly and trigger a re-crawl (you can use the URL Inspection tool in Search Console to resubmit a page after fixing schema).
- Ignoring Manual Actions: In the worst-case scenario, Google might issue a Manual Action for structured data spam if they find egregious issues (common with spammy reviews or job postings markup). If you ever get a manual action for “Structured Data”, do not ignore it. You should quickly fix the problematic markup (remove or correct whatever triggered it) and then file a Reconsideration Request via Search Console.
During a manual action, your rich snippets will likely not show at all, and possibly your rankings could drop, depending on severity. So it’s crucial to address it. Many manual actions for schema are due to either schema-content mismatch or using schema in deceptive ways, which we’ve covered above. So avoiding those mistakes helps prevent manual actions in the first place.
In summary, treat schema with the same level of honesty and care as your visible content. Use the right types, keep it aligned with on-page info, adhere to Google’s rules, test it, and maintain it. If you do that, you’ll enjoy the SEO benefits (rich results) without nasty surprises.
[By following best practices and avoiding these pitfalls, you ensure that your structured data helps rather than hurts your site.]
Putting It All Together (Conclusion & Next Steps)
Implementing structured data may seem technical, but it pays off with enhanced search visibility. Let’s recap and conclude:
By following this Schema Bible for news and blog publishing – using the right schema types for each content format, filling in the optimal properties, employing advanced schemas where appropriate (speakable, video, FAQ, etc.), and automating the process through WordPress – a publisher can significantly enhance their SEO without a huge ongoing effort.
The result is a website that is machine-friendly (search engines can fully understand your content) and primed for rich results, voice search, and whatever new structured data features come next, all while your editorial team stays focused on content quality.
In practice, here are action steps you can take after reading this guide:
- Audit your current content for schema opportunities. What types of content do you have (news, how-tos, reviews, etc.) and are you marking them up correctly today? Use Google’s Rich Results Test on a few pages to see what (if any) schema you have.
- Implement base schema site-wide: Ensure every article page outputs at least Article (or NewsArticle/BlogPosting) schema with the key fields (headline, author, date, etc.). If you’re using an SEO plugin like Yoast/Rank Math, this may already be happening – verify it. If not, consider adding a plugin or custom function to do it.
- Add specialized schema where relevant: Identify pages that would benefit from HowTo, FAQ, Review, etc. Add those either manually (through provided blocks or custom fields) or via templating. For example, add FAQ schema to pages that have FAQ sections, add VideoObject for pages with videos, mark up at least one speakable passage in each news article.
- Leverage WordPress for automation: Choose whether to use a plugin or custom code (or a hybrid). Set it up so that new posts automatically get schema. This might involve plugin configuration or writing a bit of code as shown. The time invested in setup will save exponentially more time in the long run.
- Test thoroughly: Use the Rich Results Test on a variety of page types (a news article, a how-to, a review page, etc.) after implementation. Ensure no errors. Check Search Console after Google re-crawls the pages to see if it’s recognizing the markup under Enhancements.
- Monitor and maintain: Going forward, integrate schema checks into your content QA process. If you launch a new content series or feature, consider its schema. Keep an eye on SEO news (or Google Search Central blog) for updates about structured data (for example, if Google announces support for a new schema type relevant to you, or changes in rich result eligibility).
By making structured data an integral (and automated) part of your WordPress publishing workflow, you gain a competitive edge. Your search listings can become richer and more informative (think article thumbnails, star ratings, FAQ dropdowns, breadcrumb paths — all achievable with schema).
This not only can improve click-through rates but also future-proofs your site as search evolves towards more visually enhanced and context-aware results.
Finally, remember that schema markup complements great content; it doesn’t replace it. Use this “bible” to markup your high-quality content in the best way possible, and you’ll be rewarded with greater visibility and potentially new traffic channels (like voice search) that your competitors might be missing.
Now it’s your turn: audit, implement, and iterate. With the guidelines and examples in this article, you have the blueprint to deploy schema like a pro. Happy structuring!
Responses