How to Add Article Structured Data to SaaS Blog Posts

Choose fields the article page can support

Use BlogPosting when the page’s main content is a blog article, rather than marking up a product landing page simply because it contains some explanatory copy. Google recommends JSON-LD and advises using the most specific appropriate schema type. The useful test for each value is straightforward: could a reader or editor confirm it from the article and the assets it actually uses?

Treat the fields below as a mapping from your published post, not a form to fill at any cost. If your template has no named byline, do not invent a person. If it has no trustworthy publication date, do not guess one from a file timestamp. An edit to the markup should follow an edit to the underlying article information when that information is wrong.

• headline: use the article’s visible headline, not an unrelated keyword-heavy variation.
• author: identify the person or organization credited on the page. Omit it if the post has no verifiable attribution.
• datePublished: use the publication date shown for the article when you can confirm it. Add dateModified only when you have a reliable date for a substantive update; do not present an automatic build time as an editorial update.
• image: point to a relevant image used by the article, such as its actual cover, if it has a publicly accessible image URL. Google says an image supplied in structured data should be relevant to the page, and its URL must be crawlable and indexable for Google to use it.
• url: use the public URL of the article being described, not the blog index or a draft preview.

Add a BlogPosting JSON-LD block

Here is a fictional published post. Its visible headline is “An Onboarding Checklist for Small SaaS Teams,” its byline is Maya Chen, its displayed publication date is September 14, 2026, and its page uses the cover image named below. Every URL, name, title, and date in this example is illustrative: replace them with values from your own post before publishing.

Place this block in the HTML for that article page using your website’s page template or publishing system—not as visible article copy: <script type="application/ld+json">{"@context":"https://schema.org","@type":"BlogPosting","url":"https://example.com/blog/onboarding-checklist","headline":"An Onboarding Checklist for Small SaaS Teams","author":{"@type":"Person","name":"Maya Chen"},"datePublished":"2026-09-14","image":"https://example.com/images/onboarding-checklist.jpg"}</script>. The example.com URLs are fictional placeholders, not destinations to publish unchanged. Google’s guidelines say to put structured data on the page it describes, and recommend JSON-LD as a format.

For your version, compare the headline, byline, date, and cover image with the article page. Replace url with the article’s intended public address and image with the address of its actual cover file. If the real post has no qualifying cover, remove the entire image property and the preceding comma; do the same for any other unsupported optional detail. Make sure the remaining JSON is valid. If your site already emits article markup, update that output rather than publishing a second, conflicting account of the post.

Test the code, then the deployed URL

Before release, use the code-input option in Google’s Rich Results Test to catch errors in the proposed markup; you do not need a public URL for this check. For general schema.org validation, use the Schema Markup Validator. Google distinguishes the tools: the Rich Results Test checks what Google rich results the structured data can support, while the Schema Markup Validator checks schema.org markup without Google-specific feature validation.

Publish the article-page change, then open the public URL and compare its visible facts with the JSON-LD actually delivered on that page. Run the live URL through the Rich Results Test; a passing draft-code test cannot establish that the production template emitted the same block. If your site inserts markup with JavaScript, testing the URL is particularly useful for checking the rendered result. Google’s JavaScript guidance notes that code-input tests can face JavaScript limitations and recommends URL testing for an implementation.

If you have access to the site’s Search Console property, inspect the published URL there to check how Google sees the page and whether access is blocked. Google recommends the Rich Results Test and URL Inspection for technical structured-data checks. Fix a discrepancy on the live page, deploy it, and test the public URL again; do not mistake a valid JSON result for confirmation that Google has processed your latest release.

Treat valid markup as a description, not a promise

Valid markup gives Google an explicit description of the article; it does not guarantee a rich result. Google says a page may not display a structured-data feature even when the Rich Results Test finds its markup valid. Judge this implementation by whether the deployed block is readable and truthful, not by whether a particular search treatment appears.

Ranks says its articles live on the customer’s own blog, with a review-and-edit option before publishing. That makes the article page—not the draft editor—the place to verify its markup. If you need help with a search result’s wording, use the separate title-link guide or snippet guide. If the page is absent from Google, start with the indexing guide instead of treating Article markup as an indexing fix.