Check Article Schema for the Right Author, Dates, and Images

Article markup should repeat what the published post already shows: the people in the byline, the dates a reader sees, the headline, and an image that represents the article. Check it by putting the markup and the page side by side and comparing those four facts. Where they disagree, fix the WordPress field or setting that produces the wrong value, rather than adding a second block of markup on top.

Google’s Article documentation, checked September 27, 2026, says Article objects must use one of three schema.org types, Article, NewsArticle or BlogPosting, and that “there are no required properties; instead, add the properties that apply to your content.” The recommended ones are author, datePublished, dateModified, headline and image. The WordPress SEO field guide covers structured data in general; this guide is the article-level check.

Match the type and the author to the article

Use the type that fits: BlogPosting for a blog post, NewsArticle for news reporting, Article otherwise. Google’s documentation accepts all three, so the choice is about describing the content accurately.

For authors, Google’s guidance is specific:

• Include every author shown in the byline, each in their own author entry.
• Put only the name in author.name. No job title, honorific or publisher name.
• Use Person for a person and Organization for an organization.
• Add url, “a link to a web page that uniquely identifies the author”, such as the author’s social media page, an “about me” page or a bio page.

WordPress stores one author per post: wp_insert_post(), checked September 27, 2026, takes a single post_author user ID. If your site shows two authors through a co-author plugin or a typed byline, check whether the markup lists both. It may reflect only the WordPress post author, because that is the only author WordPress itself knows about.

In WP Visibility 2.10.3, posts get a BlogPosting node by default, and the block editor’s WP Visibility sidebar has a Structured data panel with a Schema type choice whose options include Automatic, Article, BlogPosting and NewsArticle. The author is the WordPress post author, as a Person whose url is that author’s archive address (its @id is that address plus #author), and the publisher is the organization or person set in your site identity. Only one author is included. A second author needs a developer change, for example through the plugin’s wpvis_schema_graph filter.

Check the headline

headline should be the article’s title. Compare it with the visible title on the page. Titles generated from an SEO title template can differ from the visible one: a template such as {title} {sep} {site} adds the site name. In WP Visibility 2.10.3, the Article headline is the post’s SEO title (the per-post Search title if one is set, otherwise the title template), shortened at a word boundary to about 110 characters, so with the default template it ends with the separator and the site name. Decide whether that difference matters for your posts. If it does, set a per-post Search title, which also becomes the page’s title tag, or have a developer adjust the node through the wpvis_schema_piece_article filter.

Check the dates

Google’s Article documentation asks for datePublished and dateModified in ISO 8601, and recommends including a timezone, because without one Google assumes a default. Its page on byline dates, checked September 27, 2026, adds that you should show a visible date with a label such as “Published” or “Last updated”, keep visible and structured dates consistent, and not give future dates.

Then check the meaning of the modified date. WordPress updates a post’s modified time whenever the post is saved, whether the change was a new section or a fixed typo: wp_insert_post() sets it to the current time on every update. Some themes show that date as “Updated”, and WP Visibility publishes it as dateModified. That is accurate about the record, but think about what you show readers. Google’s guidance on helpful content, checked the same day, lists this as a warning sign: “Are you changing the date of pages to make them seem fresh when the content has not substantially changed?” Do not re-save posts to refresh their dates. When you make a substantive revision, say what changed if the change matters to readers.

Check the timezone too. WP Visibility prints its dates in UTC with a +00:00 offset. That names the same moment as the site’s local time, so convert the marked-up time to the site’s timezone and confirm it is the moment the page shows. Google’s byline dates page asks that the date, and any optional time and timezone, match between the visible and structured values. On a site not set to UTC, the markup’s offset differs from any local time the page shows, and a post published late in the evening in a timezone behind UTC, or early in the morning in one ahead of it, carries a different date in the markup than on the page. If that matters for your posts, a developer can rewrite the dates with the site’s offset through the wpvis_schema_piece_article filter.

Check the image

Google’s Article documentation says images must be crawlable, indexable and representative of the marked-up content, in a format Google Images supports, and asks for images relevant to the article “rather than logos or captions.” For best results it recommends several high-resolution images, each at least 50,000 pixels (width multiplied by height), in 16x9, 4x3 and 1x1 aspect ratios.

Know where your image comes from. WP Visibility uses the post’s social image if one is set, then its featured image, then the site’s default social image, at full size. That last fallback can be a logo or a generic banner, which does not represent the article. If a post has no featured image, set one that shows what the article is about. Fix the wrong image in a social preview covers the same fallback order from the social side.

Open the image URL from the markup in a private window to confirm it loads. An image blocked by robots.txt or served from a host that refuses crawlers fails the crawlable rule even when the JSON-LD itself is valid.

Compare the markup with the published page

Take one post and fill in this table from the page and from the markup. The example is illustrative: a post on garden.example whose byline shows two authors after a substantive revision.

To get the markup, view the page source and find the application/ld+json script. The inventory script in the structured data audit lists which objects a page publishes, but not their property values. Then test the URL in the Rich Results Test.

Stripped to the facts being checked, corrected markup for two authors looks like this:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Pruning Tomatoes for a Bigger Harvest",
  "author": [
    { "@type": "Person", "name": "Sam Rivera", "url": "https://garden.example/author/sam/" },
    { "@type": "Person", "name": "Priya Shah", "url": "https://garden.example/author/priya/" }
  ],
  "datePublished": "2026-03-02T09:00:00-05:00",
  "dateModified": "2026-09-10T12:20:00-04:00",
  "image": ["https://garden.example/wp-content/uploads/pruned-tomatoes-16x9.jpg"]
}

Fix the source, not the output: the byline plugin’s settings, the featured image, the SEO title, or a developer filter.

Article markup checklist

• Type matches the content.
• Every byline author appears, each in their own entry, name only, with a URL.
• Headline matches the visible title, or the difference is a decision you made.
• Dates are ISO 8601 with a timezone, match the visible dates, and were not refreshed without a real change.
• The image represents the article, loads in a private window, and is not a generic fallback.
• The URL passes the Rich Results Test after the fix.