Blog Schema for Archives and Individual Posts

A publisher opens a blog template and finds one field labeled “schema type.” The blog landing page lists recent posts; each post has its own URL, author, date, headline, and image. Choosing one type for all of those pages is tempting, but it collapses two different things: the collection and the individual work. That distinction is the practical heart of blog schema. Mark the blog’s collection page as a Blog when it truly presents a blog, and mark a single blog article as a BlogPosting when that is what the page contains. Then make the details in the markup agree with what readers can see.

This division follows the vocabulary itself. Schema.org defines Blog as the blog collection and offers blogPost to identify a posting within it. Its BlogPosting type describes one blog post. The distinction matters beyond tidy naming: a visitor who lands on the archive is choosing among posts, while a visitor on an article URL is reading one post. The markup should describe those different page experiences.

Choose the type that matches the page#

For an archive that displays an introduction, a list of recent posts, and links to older entries, Blog is the natural primary description. The blogPost property can connect that collection to individual BlogPosting items, provided the relationship reflects posts actually represented there. An archive listing ten posts should not imply that it displays unrelated articles simply because they exist elsewhere on the site. Schema.org’s definition of blogPost is a relationship between a blog and a post, not an instruction to dump an entire publication database into every archive page.

For an individual article, use BlogPosting if the page is recognizably a blog entry. Schema.org places that type within the Article family, so it carries the article meaning while being more precise about the format. The broader Article type covers many kinds of articles. A standalone report or editorial article that is not presented as a blog post can reasonably use Article; calling everything BlogPosting merely because the CMS stores it in a “posts” table adds a claim the page may not support.

That choice should be made from the published page, not the CMS menu label. A product update written as a dated blog entry with a byline may fit BlogPosting. A static “About” page does not become one because the site owner created it through a posts interface. Likewise, a category page that collects links is a collection page, even though it contains titles and excerpts from individual articles. The object a reader is encountering at that URL decides the type.

Google makes the distinction consequential for search. Its article structured data guidance accepts Article, NewsArticle, and BlogPosting for article pages. It does not name Blog as an article type. If the goal is to give Google explicit information about a particular post’s author, date, headline, and image, put article markup on that post page. Adding Blog to the archive does not do the post page’s job for it.

Give the post its own accurate details#

A useful post template starts with details that the page already publishes. Google recommends author, publication and modification dates, headline, and a representative image when those properties apply. It says there are no required properties in its article guidance, so the right response to a missing fact is to omit or correct that fact, not to invent one merely to fill every field.

The headline should identify the article being read. If the page title changes during editing, the structured headline should change with it. Otherwise, two parts of the same URL make competing claims about what the article is. Google specifically describes headline as the article title and advises keeping it concise because long titles can be cut off on some devices. The markup cannot turn an unclear headline into a clear one; it can only communicate the title that the publisher has actually chosen. Google’s property guidance is the appropriate reference for the supported field.

Treat author as an attribution field, not a branding opportunity. When the page names a person, use that person as the author; when it credits an organization, reflect that. Google recommends including all authors shown on the page and representing multiple authors separately rather than merging their names into one string. An author URL can help identify the author when there is a real profile or equivalent page. A made-up profile link adds no clarity. These choices matter because a template that always inserts the company name could contradict a visible individual byline across every post. Google’s author guidance describes those distinctions.

Dates require the same discipline. datePublished means when the article was first published, and dateModified means when it was most recently modified. They should not both become today’s date whenever the page is rebuilt. Google recommends date-time values in ISO 8601 format with time-zone information where available. If an article has no meaningful visible update history, there is little value in making routine template rendering look like an editorial revision. A reader who sees a published date from one year and structured data claiming another will receive a muddled signal. Google’s article documentation defines the two dates separately.

Images should be equally literal. Google asks for an image representative of the article and says image URLs must be crawlable and indexable. A logo used as the image on every post is a poor substitute for a relevant article image. If a post has no representative image, do not manufacture one in markup. Google recommends several high-resolution aspect ratios when appropriate, but those recommendations are about usable image assets, not a reason to point different fields at irrelevant files. The image requirements and recommendations explain what Google can use.

Put the description on the page it describes#

Google generally recommends JSON-LD because it is easier for site owners to maintain, while also supporting Microdata and RDFa when implemented properly. JSON-LD usually lives in a script element in the page’s HTML. The format is a delivery choice; the more important rule is that the structured data describes the content at that URL. Google’s introduction to structured data says markup belongs on the page to which the information applies and should not describe material that readers cannot see.

Here is an illustrative post-page pattern. Every value under example.com is a placeholder to replace with the real article URL, image, title, author, and publication time. The visible page should show those same facts. The example deliberately leaves out dateModified; add it only when the post has a real modification date to report.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Title shown on this post page",
  "datePublished": "2026-09-01T09:00:00+08:00",
  "author": {
    "@type": "Person",
    "name": "Name shown in the byline",
    "url": "https://example.com/author/profile"
  },
  "image": "https://example.com/images/post-image.jpg",
  "mainEntityOfPage": "https://example.com/blog/post-url"
}
</script>

The example is a starting shape, not a universal list of fields. Its BlogPosting type tells a processor what the main work is; the headline, author, date, and image describe that work. mainEntityOfPage connects the work to its page in the Schema.org vocabulary. Remove a field if the live post cannot support it, and replace the sample timestamp with the actual publication time. The Schema.org BlogPosting example and Google’s article example show the same basic idea in their own markup.

The archive needs a different shape. A Blog item can carry its own name and URL, with blogPost entries for posts presented as part of that collection. If the archive page displays teasers, its markup should avoid pretending that the full text of every linked article is present. The richer author, date, and image description belongs on each post page, where those facts can be checked against the article. This also keeps an archive template manageable: adding a new post does not require copying a complete article record into every page that links to it. Schema.org’s Blog property list supports connecting the collection to its posts.

A site may have more than one truthful description on a page. A post can also belong to a broader site or have navigational context, and Google’s general guidance allows multiple relevant structured data items. The decision is whether each item describes something present and useful on that URL. Adding extra types only to chase a search feature can create contradictions, particularly when an archive, a post, and a site are all given the same title or identity. Google’s general structured data guidelines say to use the most specific applicable type and to make the markup a true representation of the page.

Keep collection links and post facts in sync#

A publishing system can generate excellent markup on the first day and inaccurate markup three months later. Suppose an editor changes a headline, removes an image, or merges two author pages. If the visible article changes but the JSON-LD is cached separately, the page now states conflicting facts. The practical solution is to draw both the visible fields and the structured fields from the same maintained article record wherever the site allows it. That is an implementation judgment, not a claim that any particular CMS does this automatically.

The same reasoning applies to the archive relationship. When a post leaves the archive’s displayed list, the collection markup should no longer claim it as one of the displayed entries. When a post is linked from several category pages, the markup on those pages should describe what each page actually shows. Schema.org permits a blog-to-post relationship, but Google’s location and relevance rules still require page-level accuracy. A valid blogPost property is not a license to add invisible or unrelated posts.

URLs deserve care because they identify the work being described. A post that has moved to a new public URL should not keep an old page address in its structured data by accident. If duplicate URLs serve the same content, Google recommends placing the same structured data on all duplicates, not only on the canonical page. That is a different issue from using one URL for an archive and another for the article: those are different page types and should have different main descriptions. Google’s general guidelines cover duplicate pages and the placement of markup.

If a publication uses a theme or plugin to emit schema, inspect a real archive and a real post after rendering. A settings screen may say “blog schema enabled,” but the resulting HTML is the thing search systems read. Look for the actual @type, the values of headline and date, and whether an image URL resolves to the intended asset. If two components both generate article markup, compare them for disagreement. This is a practical check of the published result, especially after a template change.

Know what Google can and cannot promise#

Schema.org defines terms; Google chooses which terms and properties matter for its Search features. Those are connected but separate decisions. Google’s structured data introduction says its feature documentation is the authority for Google Search behavior, even though Schema.org contains many more types and properties. Consequently, a property can be legitimate Schema.org vocabulary without being a route to a particular Google display.

For blog posts, Google says article markup can help it understand a page and present better title text, images, and date information. The wording is conditional. Even correct markup does not guarantee that any special appearance will be shown. Google’s general guidelines explicitly say that a page passing the Rich Results Test may still receive an ordinary result, and they identify relevance, accuracy, access, and the search context as factors. Blog schema should be treated as a clear description of published content, not a ranking or display switch.

This is why a green result in a testing tool is a checkpoint rather than the end of the work. Google recommends using the Rich Results Test to catch critical errors, then checking deployed pages with URL Inspection to see how Google accesses them. A parser can confirm that a date is in an acceptable format; it cannot know whether the date is the true publication date. A test can recognize BlogPosting; it cannot decide whether a page is really a blog post when the visible content says otherwise. Google’s article implementation steps and quality guidelines make that distinction clear.

For most publishers, the sensible order is straightforward: classify the archive and the post separately, populate the post with real editorial facts, check a rendered page from each template, and revisit the output when the content changes. The cost is ongoing consistency between visible content and markup. That work is smaller and more defensible than filling every available Schema.org field. If the page does not show an author, date, or image that you want to claim, resolve the editorial question first; structured data cannot supply the missing fact for the reader.