Article structured data for a small company blog

Structured data becomes unreliable when it is treated as a box of optional fields to fill. The template says an article has an author, image, headline, and dates, so someone inserts values that look plausible. The visible page shows a different author name, the image URL is a placeholder, and the modification date changes every time the site deploys.

Useful article structured data for a blog begins with publishing truth already visible on the page. The markup describes the article. It should not invent a cleaner, newer, or more authoritative version of the content than the reader can see.

Build a ledger between visible facts and machine-readable fields, then validate both the code and the agreement between them.

Start from one rendered article

Open a real production article and identify the facts a reader can observe.

• The title

• The primary image

• The publication date

• A meaningful modification date where one is shown or supported

• The author or authors

• Links to author information

• The canonical page URL

Now inspect the page source or rendered structured data. Every value should trace back to a visible fact or a stable publishing record.

Google's Article structured data documentation explains that Article, NewsArticle, and BlogPosting markup can help Google understand article pages and details such as title, image, dates, and author. It also says that adding the markup does not guarantee a particular search appearance.

For a company blog, Article or BlogPosting may be appropriate depending on the implementation and broader vocabulary needs. Choose one consistent model with the developer or platform owner rather than changing types for superficial reasons.

Create the visible-to-markup ledger

The ledger makes ownership clear before code is written.

The ledger can include more fields when they are accurate and maintained. It should not become a target to populate everything that a vocabulary permits.

Google's general structured data guidelines state that markup should represent the main content of the page and should not be misleading or describe hidden content. Fewer accurate properties are better than a dense object built from guesses.

Build the minimum useful object

A JSON-LD implementation for a company blog might look like this.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Article structured data for a small company blog",
  "image": [
    "https://example.com/images/article-structured-data.png"
  ],
  "datePublished": "2026-07-17T09:00:00+02:00",
  "dateModified": "2026-07-17T09:00:00+02:00",
  "author": [
    {
      "@type": "Person",
      "name": "Example Author",
      "url": "https://example.com/authors/example-author"
    }
  ]
}
</script>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Article structured data for a small company blog",
  "image": [
    "https://example.com/images/article-structured-data.png"
  ],
  "datePublished": "2026-07-17T09:00:00+02:00",
  "dateModified": "2026-07-17T09:00:00+02:00",
  "author": [
    {
      "@type": "Person",
      "name": "Example Author",
      "url": "https://example.com/authors/example-author"
    }
  ]
}
</script>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Article structured data for a small company blog",
  "image": [
    "https://example.com/images/article-structured-data.png"
  ],
  "datePublished": "2026-07-17T09:00:00+02:00",
  "dateModified": "2026-07-17T09:00:00+02:00",
  "author": [
    {
      "@type": "Person",
      "name": "Example Author",
      "url": "https://example.com/authors/example-author"
    }
  ]
}
</script>

This is an illustration, not a complete copy-and-paste solution. The production object must use the site's actual visible values, valid URLs, accurate time zone, and approved author model. The surrounding page must also meet the relevant technical and content guidance.

The implementation should come from the template or content system so editors are not hand-editing JSON for every post. The ledger defines how CMS fields map into that template.

Make dates editorial facts

Date fields are a common source of false signals.

datePublished should represent the article's original publication. A CMS migration should not quietly reset it to the import date. dateModified should change when the article receives a significant update that affects the content, structured data, or useful links. A footer copyright update or routine deployment is not a meaningful article modification.

Keep a small change record that tells the template when a modification is material. If the site displays an updated date, that visible label should agree with the markup. If the workflow cannot maintain a truthful modification date, omit or redesign the field rather than fabricating precision.

Treat authors as identities, not strings

An author value should help readers and systems understand who created the article. The visible byline, markup name, and linked profile should align.

If several people contributed, record the roles honestly. The named author may have written the article while a technical reviewer verified specific claims. The visible page can explain those roles, and the structured data should follow the documented publishing model.

Avoid using a generic organization as the author for every article when a visible person is clearly credited. Avoid creating a person profile with no useful information merely to complete a property. The author page should contain accurate background, relevant areas of work, and links to published contributions where appropriate.

Select images the template can sustain

The structured image URL must resolve to an accessible image that belongs to the article. Do not point it to a local design file, authenticated preview, or temporary CDN address.

Google's article documentation recommends representative images and shows several aspect ratios in its examples. The exact image set should fit the site's publishing and media system. Define how the template derives image URLs and what happens when an article has no suitable featured image.

Test the final image directly. Confirm that crawlers can access it, that the URL remains stable, and that the visible article uses the same meaningful asset.

Two implementations that look valid but mislead

The automatic freshness template

Every deployment writes the current timestamp into dateModified. A validation tool may accept the syntax, but the field no longer represents an article change. The markup tells a different story from the content.

Repair the source mapping. The value should come from an editorial modification record, not build time.

The invisible expert

The markup names a respected specialist as the author, but the page credits only the company and provides no explanation of the specialist's role. The structured data is not a place to add credibility that the reader cannot inspect.

Repair the visible authorship and contribution record first. Then make the markup match it.

These failures show why schema QA needs more than syntax validation.

Validate in three stages

Stage one checks the template

Use representative content in a test environment. Verify the JSON format, property types, escaping, array handling, dates, image URLs, and author links. Test missing optional fields and multiple authors.

Stage two checks a small production release

Deploy the template to a limited set of real articles. Use the relevant rich result testing tool and inspect the live source. Confirm that the pages are crawlable and not blocked by robots rules, noindex, or authentication.

Stage three checks the system after change

Monitor structured data reports and sample pages after CMS updates, theme changes, migrations, or author-profile changes. A template can validate on launch and drift later when a field is renamed or an image pipeline changes.

Record the page URL, test date, observed markup, warnings, and owner. Validation is evidence, not a one-time badge.

Keep the promise modest

Structured data helps describe the page. It does not guarantee a rich result, a ranking change, or a specific title and image display. Do not sell the implementation internally as a guaranteed traffic feature.

The more durable benefits are operational. The team defines accurate publishing fields, connects them to visible pages, and creates a testable template. Those improvements can reduce metadata drift even when search appearance does not change.

Article structured data for a blog is strongest when it is boringly truthful. The page shows the title, author, image, and dates. The publishing record owns those values. The markup repeats them in a supported format. Validation proves the live page still agrees.

That visible-to-markup chain is the real implementation. The JSON-LD is only its machine-readable expression.