Schema Markup Examples for Articles and Offers

You have a page ready to publish and a schema markup example open in another tab. The tempting move is to paste the example, change the name, and wait for a more elaborate search result. That can leave a page with valid code that describes the wrong thing. A blog post, a product for sale, and a software app each need different facts, even when all three use the same JSON-LD format.

Structured data gives a search engine explicit, machine-readable information about what is on a page. Its useful unit is the relationship between a page and the thing the page describes: an article has a headline and author; a product page may show an offer; an app page describes software. Google’s introduction to structured data explains that the markup belongs on the page it describes. The practical rule is to start with the visible page, then write the code. A copied example is useful only after every marked-up fact matches what a visitor can actually find.

Choose the page’s subject before the schema type#

Begin with a plain question: what would a visitor say this particular URL is about? On a post with a byline, the main subject is the article. On a seller’s page with a purchase option, it is the product and its offer. On a page that explains an application, it may be the software itself. The same site can publish all three, but a single schema template should not label them all alike. Google’s general structured data guidelines require the markup to represent the page’s main content and prohibit marking up information hidden from readers.

Choose a format after choosing the subject. Google supports JSON-LD, Microdata, and RDFa; it generally recommends JSON-LD when the site can use it because a separate script is easier to maintain than attributes woven through page HTML. The format does not change what is true about the page. An accurate product description in Microdata is more useful than a polished JSON-LD block that invents a review or a price. Google’s format guidance treats all three as acceptable when they are implemented properly for the relevant feature.

The examples below use JSON-LD so the relationship between properties is easy to see. Each <script type="application/ld+json"> block belongs in the HTML of the page it describes. The example pages and values are illustrative; example.com URLs and any sample price must be replaced with the real page’s visible information. Do not publish the examples unchanged. Where a property has no truthful value on your page, leave it out and check the relevant feature guide before deciding whether that omission affects eligibility.

An article example starts with the headline and byline#

Imagine a page headed “How to Clean a Desk Lamp,” with a visible byline reading “Editorial Team” and a photograph that illustrates the article. The markup below identifies that page as a BlogPosting, a specific article type, and repeats those visible facts. The image URL is only a stand-in for an image actually used by the page. Google’s Article guidance covers Article, NewsArticle, and BlogPosting, and lists headline, author, publication date, and image among its recommended properties.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Clean a Desk Lamp",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  },
  "image": "https://example.com/images/desk-lamp-guide.jpg"
}
</script>

This is a small example on purpose. If the page credits a person rather than an editorial team, use Person and put that person’s displayed name in author.name. If the page has two credited authors, represent both rather than compressing their names into one author string. If the article displays a publication date, add datePublished with the actual date; if it displays a meaningful update date, dateModified can describe that update. The Article property guidance says there are no required properties for its article types, but recommends supplying the applicable ones accurately. A missing date is better than a made-up date that appears only in code.

The choice among Article, NewsArticle, and BlogPosting should follow the page, not the search appearance you hope to get. A site diary or explanatory post can use BlogPosting; a reported news story can use NewsArticle; Article works when the broader label best describes the work. None of those labels substitutes for the article itself. Marking up a product category page as a news article because the category has a short editorial introduction would misstate the page’s main purpose.

Images deserve the same care as text. The URL in image should point to a relevant, accessible image that represents this article. A logo reused across every post tells a different story from a photograph chosen for the post. Google’s Article image guidance asks for relevant, crawlable, indexable images. If your publishing system changes an image path or removes the image, update the markup with the page; otherwise the code can keep describing an asset the reader and search engine can no longer use.

For a publishing team, the sensible implementation is to draw the headline, credited author, dates, and image from the same fields that render the page. This is an editorial choice about consistency, not an additional schema property. It also makes a discrepancy easier to spot: if the byline is blank in the page template, the markup should not quietly fill it with a name borrowed from another article. Start with one representative post, examine the rendered page and its JSON-LD, then apply the pattern to posts that actually share the same structure.

A product example describes the offer that is on the page#

A product detail page calls for a different question: can a visitor buy the item here, or is the page reviewing it? Google’s Product guidance distinguishes product snippets, including pages where visitors cannot buy directly, from merchant listings for pages where customers can purchase the product. Their requirements and possible enhancements differ. A review article about a lamp is not the same page as the seller’s lamp listing, even if both name the same object.

Suppose an illustrative shop page displays an adjustable desk lamp, an image, a description, a USD 79.00 price, and current availability. The following code models that seller page. The price is an example value, not a claim about a real item. It belongs in published markup only if the page actually shows that price and the offer really belongs to that URL.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Adjustable Desk Lamp",
  "image": "https://example.com/images/adjustable-desk-lamp.jpg",
  "description": "Desk lamp with an adjustable arm",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/adjustable-desk-lamp",
    "priceCurrency": "USD",
    "price": "79.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

The nested Offer is the important difference from the article example. It connects the lamp to a stated selling condition. A product review that merely discusses the lamp should not copy the seller’s offer as though the reviewer is making that sale. Conversely, a shop page that sells the lamp should not add a review rating simply because a generator offers a rating field. Google’s general guidelines prohibit irrelevant or misleading data, including fake reviews. The absence of a rating is ordinary; a fabricated rating changes what the page claims.

Price and availability also change more often than a product name. If a merchant changes the visible price or the item goes out of stock, the markup needs to change with the page. A static code block pasted into a template can lag behind a live product catalog. That lag matters because a search result may present product information before a visitor opens the site. For this example, the first decision is therefore operational: use the page’s live offer fields, or omit an offer you cannot keep accurate. Then consult the current product feature requirements before treating this short illustration as a complete merchant-listing implementation. Google’s Product documentation separates the two product experiences and directs site owners to the requirements for the one that fits their page.

A product with several versions needs a further decision about what the URL represents. If one URL presents several selectable versions, a price from only one version can misdescribe what the visitor sees when the page opens. The supplied example deliberately represents one item and one visible offer. Use it as a model for that situation, not as permission to flatten a complicated catalog into a single price. Google’s Product guidance notes that variant information can help describe versions of the same parent product; whether your page needs that treatment depends on how the versions and offers are actually presented.

A software example shows the limit of a schema type#

An app landing page can describe its software even when the site is not selling a physical item. Schema.org defines SoftwareApplication as a type for software applications. An illustrative page headed “Team Scheduling App,” with a short description of what the app does, could express those visible facts like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "Team Scheduling App",
  "description": "Software for arranging team shifts"
}
</script>

That code states a type and two properties. It does not establish that Google will produce a special search result for the page. Schema.org describes a vocabulary; Google’s own feature documentation determines which markup has a Google Search appearance and what that appearance requires. Google’s structured data introduction explicitly tells site owners to rely on its Search documentation for that purpose. A generic Schema.org type can still be a sensible way to describe content, but its existence is not a promise of a rich result.

This distinction changes how to use a schema generator. A generator may offer a long menu of types and properties, and the resulting code may be well formed. The useful choice is narrower: select a type that truthfully describes the page, then decide whether a Google feature for that type is relevant. If the goal is a particular search appearance, read that feature’s current rules before filling out a template. If the goal is simply to state that a page describes software, a minimal accurate SoftwareApplication block is more defensible than invented ratings, prices, or platform claims added to make the block look complete.

Test the markup and the page separately#

After adding a script, check two different questions. First, does the page expose structured data that a parser can read, and does the code use the intended type and properties? Second, is this a type and set of properties that Google may use for the search feature you have in mind? Google’s structured data testing guide recommends its Rich Results Test for Google-specific feature checks and the Schema Markup Validator for generic Schema.org markup. A software block could be legitimate Schema.org markup while offering no Google rich-result preview in the Rich Results Test. Those outcomes answer different questions.

A passing test still leaves a content check. Open the rendered page as a visitor would. Compare the headline, byline, image, product price, availability, and app description with their JSON-LD values. A parser can accept a perfectly formed price that the page no longer displays. It can also accept a type that points to the wrong primary subject. Google’s general guidelines say that quality issues such as hidden or misleading content are not easily caught by automated tests. Someone has to compare the code with the page.

Once the page is published, test the live URL as well as a pasted code sample. A correct draft script is of limited use if the site’s template omits it, changes it, or serves a different version on the live page. Google’s structured data introduction points to the Rich Results Test during development and Search Console reports after deployment. This makes testing a check on the actual implementation, not a certificate attached to a snippet copied from an editor.

Finally, keep the expected outcome modest. Correct markup can make a page eligible for a supported rich result, but Google does not guarantee that the enhanced display will appear. Its general guidelines say Search decides which presentation to show. The same caution is especially useful with popular example types: Google’s FAQ rich-result change limited regular FAQ display largely to well-known government and health sites. A general business could have genuine questions and valid FAQPage code without getting the FAQ appearance it expected. Add an FAQ for readers who need it, and choose its markup based on the page and current feature rules rather than on an old screenshot of search results.

The best schema markup example is therefore the one that survives comparison with the live page. Use BlogPosting for a real post, Product and an Offer for a real selling page, and SoftwareApplication for a page that actually describes an app. Fill in only facts the visitor can see, check the feature guide that applies, and revisit the code when those facts change. The cost is a little more attention to the page and its publishing system; the benefit is markup that still tells the truth after the example has been pasted and the page has moved on.