BlogPosting Schema Fields That Matter for a Cafe Blog

Thomas Garner

Oct 7

11 min read

Your cafe runs a blog on Wix, Squarespace, WordPress, or Shopify, and you want to know which parts of the BlogPosting markup those platforms already generate are actually worth your time to check. Short answer: a small set of fields does the real work, headline, author, dates, image, and publisher, and getting the honest ones right, a real named author, an accurate modified date, matters more than chasing a long list of optional properties you will never notice missing.

Most platforms already output some post level schema automatically, so the actual task here is not building this from scratch. It is knowing what your platform already produces, spotting what is missing or wrong, and fixing the handful of fields that matter. This post builds around one fictional cafe post as a working example, then explains each field, and points you to how to test the result.

This is a narrower topic than schema for your cafe as a whole. It covers only the markup attached to an individual blog post, not the broader organization level block describing your brand, your logo, or your social profiles, which is its own separate task with its own separate post. Keeping that distinction clear matters, since conflating the two tends to produce confusion about which fields belong where.

The Fields That Actually Matter

Schema.org defines BlogPosting as a type describing a blog entry, with properties including headline, author, datePublished, dateModified, image, and publisher, each meant to describe a distinct, useful fact about the post. Of these, the ones worth actively checking on your own site are the ones a reader can also see on the page itself: the headline, who wrote it, when it was published, when it was last updated, and a representative image.

Google's own article structured data documentation, worth reading directly for the current wording, generally treats these article style properties as recommended rather than strictly required in most cases, which means the honest goal here is accuracy, not completeness. A page with fewer optional properties filled in correctly beats a page with every possible property present but several of them wrong or stale.

Here is a fictional example to make this concrete, describing a post that does not exist on any real site. Imagine a post titled A Guide to Cold Brew Ratios, with a headline matching the visible page title exactly, an author block naming a real person rather than a generic site name, a datePublished set to the day it went live, a dateModified set to the day it was last genuinely edited, not a date that auto refreshes on every page load, and an image showing something relevant to the post's actual content rather than a generic stock photo unrelated to cold brew.

Notice what this fictional example does not include: an exhaustive list of every optional schema.org property BlogPosting supports, a word count field, a comment count, an elaborate set of keywords. None of those are wrong to include if your platform happens to generate them, but they are not where the actual value sits. The six fields already named cover what a reader can verify against the visible page, and that verifiability is the whole reason accuracy on these six matters more than completeness across dozens of optional properties nobody is checking.

Author: The Field Most Worth Getting Right

Schema.org allows the author property to be either a Person or an Organization, and for a cafe blog written by a specific named owner or staff member, using a Person type with that real person's actual name is the more accurate and more useful choice. A generic organization name in the author field, when a real person wrote the post, is a small but real mismatch between what the markup claims and what happened.

This matters beyond simple accuracy for its own sake. A visible byline on the page itself, Written by a real name, should agree with what the schema block claims in its author property. When these two disagree, a page saying one thing to a human reader and another thing to a machine reading the code behind it, that is exactly the kind of inconsistency worth catching and fixing, since it undermines the basic premise that markup should describe what is on the page.

If your blog posts are written by more than one person, make sure each post's author field reflects whoever wrote that specific post, rather than defaulting to a single name across every post regardless of who wrote it. This is a small, mechanical check worth running across your existing posts, not just new ones going forward.

It is also worth deciding, deliberately, how you want to handle posts where no single person is clearly the author, a recipe compiled from several staff contributions, a general shop update nobody specifically wrote alone. In that case, an Organization type naming your cafe as the author is a more honest choice than assigning it to one person who did not write it by themselves. The goal throughout is accuracy over convention, choosing whichever author type reflects what happened rather than defaulting to whichever one is easiest to set once and forget.

Dates: Published and Modified

datePublished should reflect the actual day a post first went live, not a date that gets silently updated every time a minor edit happens. dateModified should reflect the actual day the post was last genuinely changed in some meaningful way, a real update to the content, not a technical field that auto refreshes on every page load regardless of whether anything changed.

This distinction matters because these two dates are telling a reader, and a machine, two different true things: when this existed, and how current it currently is. If dateModified changes constantly without any real edit happening, it stops carrying honest information and starts being noise, no different from having no modified date at all, just less obviously so.

A visible last updated line on the page itself, if your blog includes one, should match the dateModified value in the schema block, the same consistency principle that applies to the author field. If you update an older post, a real content change, not a formatting tweak, updating both the visible date and the schema date together keeps them honest and in agreement.

A common, easy to miss issue worth checking specifically: some platforms set dateModified automatically to the current date every time a page is simply rebuilt or re rendered behind the scenes, even without any actual edit to the content. If you notice your dateModified value changing on posts you have not touched in months, that is worth investigating with your platform's support resources, since it undermines the honest signal this field is supposed to carry.

Image and Publisher

The image property should point to an image representative of the post's content, not a generic placeholder or an unrelated stock photo reused across every post regardless of topic. A cold brew post with an image showing something entirely unrelated is a small but real mismatch, the same category of issue as the author and date inconsistencies already described.

The publisher property, typically an Organization type naming your cafe with a logo, describes who is behind the blog as a whole rather than who wrote any individual post. This is closer to a brand level block than a post level one, and it usually stays consistent across every post on your blog rather than changing post to post the way the author field does.

Together, image and publisher round out a picture that, alongside headline, author, and dates, describes a post accurately and completely enough to matter, without needing to chase every optional property schema.org happens to define. The honest ones described in this post do more real work than a long, mostly ignored list ever would.

If your publisher block is missing a logo, or the logo it references is an old version of your branding that has since changed, that is worth fixing too, though it tends to be a one time correction rather than something requiring ongoing attention the way author and dates do on every new post. Set it correctly once, and it should stay accurate across your entire blog until your branding itself changes again.

Checking What Your Platform Already Outputs

Before adding or changing anything, look at what your platform is already generating. On any live blog post, view the page source in your browser and search for BlogPosting, which should locate the JSON LD block your platform generated automatically. Compare what you find, field by field, against the target described above: headline, author, datePublished, dateModified, image, publisher.

This comparison, done on one page as a method rather than a full audit, tends to surface the same handful of common gaps: a missing or generic author, a dateModified that never changes or changes too often, an image that does not match the post's actual topic. None of these are unusual platform failures, they are simply the fields most likely to have been left at a default setting rather than deliberately filled in.

Do this same check on a Wix test post too if you have one available, since platform output can differ and it is worth knowing specifically what your own platform generates rather than assuming based on a different platform's behavior. Store what you find, dated, so you have a record of what was checked and when.

If your blog runs on more than one platform, or if you migrated from one to another at some point, run this check on a handful of posts from before and after any migration specifically. A platform change is one of the more common moments for schema fields to quietly reset to defaults or drop values entirely, and posts written before a migration are worth spot checking rather than assuming they carried over cleanly with everything intact.

Testing Your Fix

Once you have identified and fixed any gaps, validate the result using the Google Rich Results Test and the Schema Markup Validator at validator.schema.org, both of which will confirm whether your BlogPosting block is technically well formed and whether it is recognized as the type you intended. A clean validation result is a useful, concrete confirmation that the markup itself is structurally sound.

This post does not go deep into the testing process itself, since a fuller walkthrough of testing schema belongs in its own dedicated piece. The short version here is enough to confirm your fixes took effect: paste your page's URL or source into the validator, check that BlogPosting is recognized, and confirm the field values shown match what you intended to set.

Testing is not a one time task tied only to this specific fix. Any time your platform updates its templates, or you change how your blog displays authorship or dates, it is worth revalidating, since a platform change behind the scenes can quietly alter what schema gets generated without any visible change to the page itself. Building a quick revalidation check into your regular routine, alongside whatever else you already do when publishing or editing a post, keeps this from becoming a forgotten task that only gets attention once something has already gone quietly stale.

Frequently Asked Questions

What BlogPosting fields matter for a cafe blog?

Six fields do the real work: headline, author, datePublished, dateModified, image and publisher, all defined on the schema.org BlogPosting type. These are the fields a reader can also verify on the visible page, which is exactly why they matter most. Getting them accurate keeps what the page shows a human and what the JSON LD block tells a machine in agreement, and that beats chasing a long list of optional properties.

Does Google require all of these BlogPosting properties?

No. Google's article structured data documentation generally treats these properties as recommended rather than strictly required in most cases, so the honest goal is accuracy, not completeness. A page with fewer properties filled in correctly beats one with every property present but several wrong or stale. Word count, comment count and keyword fields are fine if your platform generates them, but that is not where the value sits.

Should the author field say a real person's name or my cafe's name?

If a real person wrote the post, use a Person type with their actual name rather than defaulting to a generic organization name. This should also match the visible byline on the page itself. A mismatch between what a page shows a human reader and what its schema block claims is exactly the kind of inconsistency worth fixing.

What is the difference between datePublished and dateModified?

datePublished is the actual day a post went live and should not change afterward. dateModified should reflect the day the post was last genuinely, meaningfully updated, not a field that auto refreshes on every page load or template rebuild. If a visible last updated line appears on the page, it should match dateModified. If a post untouched for months shows a changing dateModified, raise it with your platform's support resources.

How do I see what schema my platform already generates on a blog post?

Open any live blog post, view the page source in your browser, and search for BlogPosting to find the JSON LD block your platform generated. Compare it field by field against headline, author, datePublished, dateModified, image and publisher. The usual gaps are a generic author, a dateModified that never changes or changes constantly, and an off topic image. Store what you find, dated, so you have a record.

What is the difference between the author field and the publisher field?

Author describes who wrote a specific post and should change from post to post, using a Person type with a real name when one person wrote it. Publisher describes your cafe or brand as a whole, typically an Organization type with a logo, and usually stays the same across every post. If the publisher logo is an old version of your branding, fix it once and it holds until your branding changes again.

How do I test whether my BlogPosting schema is set up correctly?

Run the page through the Google Rich Results Test and the Schema Markup Validator at validator.schema.org. Both confirm whether your markup is technically well formed and recognized as the BlogPosting type. Paste your page's URL or source in, then check that the field values shown match what you intended to set. Revalidate whenever your platform updates its templates, since generated schema can change without any visible change to the page.

Will fixing my BlogPosting schema make Google crawl my blog more often?

No claim like that is made here. This post does not state that date fields or any other BlogPosting property change how often a page gets crawled, since that is not documented for this markup type on schema.org or in Google's article structured data documentation. The value of getting headline, author, dates, image and publisher right is accuracy, keeping the markup in agreement with the visible page, not a crawl frequency promise.

Does my image need to be unique for every blog post?

It should represent that specific post's content rather than being a generic placeholder or an unrelated stock photo reused across every post regardless of topic. In the fictional example here, a post titled A Guide to Cold Brew Ratios should carry an image of something related to cold brew. This keeps the image property honest, the same principle applied to the author and date fields elsewhere in this post.

Can Hillcane check my cafe blog's schema for me?

Yes. Hillcane can review your existing blog posts on Wix, Squarespace, WordPress or Shopify, compare what your platform already outputs against the six target fields described here, and help fix any gaps in author, dates, image or publisher. It can also spot check posts from before and after a platform migration, when schema values most often reset. Reach out at hillcane.co/contact or call (256) 384-2449.

Work with Hillcane

Your blog platform already generates some schema on every post. The question is not whether it is there, it is whether the author, dates, and image are actually accurate.

Want your cafe blog's schema checked and fixed? Reach Hillcane at hillcane.co/contact or call (256) 384-2449.