article:author meta tag set: an Open Graph byline that ...

The Mega Analyzer's Crawl Health section has a row that reads article:author meta tag set, and it only appears on pages the analyzer already believes are articles. What it is really measuring is whether the Open Graph block names an author at all, because og:type set to article opens a slot for a byline that the protocol defines, and a lot of layouts fill the title, image, and URL slots and stop there. Mine did. When the JSON-LD says a person wrote the page and the OG block says nothing, you have one machine-readable attestation of authorship where you could have two, and the second one costs a single line in the post layout.

What the check actually tests

The row is gated. It renders only when the analyzer's JSON-LD walker finds a node whose @type includes Article, BlogPosting, or NewsArticle, or when the page carries <meta property="og:type" content="article">, compared exactly, so a capitalized Article in that attribute does not open it. Either condition is enough. A homepage with og:type set to website and no Article schema never shows the row, and that absence is a skip, not a pass. The adjacent row, article:published_time + article:modified_time set, shares the gate but is a separate check with its own pass and fail.

Once the gate opens, the detector runs one query against the fetched HTML, document.querySelector('meta[property="article:author"]'), and reads its content attribute. A non-empty string passes. Anything else fails under the same title with this detail: Add <meta property="article:author" content="URL-to-author-profile"> so Facebook/LinkedIn/X link the author correctly. The severity is warn, so a failure renders as a red row without the CRITICAL prefix, counts one point against the Crawl score (critical checks count two), and lands in the Warnings tile.

The value is not validated: content="Jane Doe" passes, content="https://" passes, the company's Facebook Page URL passes. Green means present, not correct. Only the first matching tag is read, because querySelector returns the first match in document order, so an empty first tag followed by a filled second one fails. <meta name="author" content="Jane Doe"> does not count; it uses the name attribute and belongs to a different vocabulary, and the same goes for a mistyped <meta name="article:author">, since the selector requires property. <link rel="author"> is invisible to this row, and so is the author inside your JSON-LD. The analyzer's own rel=author or author-profile link present row covers the first on editorial pages, and the Schema score's Article sub-validation reads the second, docking points when an author object has no url. The analyzer parses the response body the server sent, not a rendered DOM, so a tag injected by client-side JavaScript is never seen.

Why it matters

The Open Graph protocol defines an article object type under the namespace https://ogp.me/ns/article# with six properties: article:published_time, article:modified_time, article:expiration_time, article:author ("Writers of the article", typed as a profile array), article:section, and article:tag (a string array). For any array-typed property the spec's instruction is plain: "If a tag can have multiple values, just put multiple versions of the same <meta> tag on your page."

The type is what matters for this row. article:author is not a string; it is a reference to an object of the profile type, and in the protocol's model every object is identified by its URL (og:url is described as the object's "permanent ID in the graph"). So the value that fits the type is the URL of a page about the person, ideally one that itself declares og:type as profile. A bare name is a string dropped into a slot that expects a reference, and any parser that tries to follow it gets nothing. That is why the analyzer's detail line asks for a URL even though the detector will accept a name.

The detail line names Facebook, LinkedIn, and X, so I read what those platforms publish. Facebook's current guide to sharing for webmasters documents og:type ("If you don't specify a type, the default is website" and "Each URL should be a single object, so multiple og:type values are not possible") and points you to the Sharing Debugger, which "triggers a scrape of your page". As of the day I checked, that page does not mention article:author at all. LinkedIn's help article on making a site shareable lists exactly four tags: og:title, og:image, og:description, and og:url. Neither platform currently promises to render a byline from the article block, so do not add the tag expecting a name on the share card.

The reason to add it anyway is that a byline is a cross-check, and cross-checks are cheap to read and expensive to fake. Google's Article documentation recommends author.url as "A link to a web page that uniquely identifies the author of the article. For example, the author's social media page, an 'about me' page, or a bio page." That same URL is what belongs in article:author. Google's page says nothing about Open Graph, and I am not going to claim Google reads the article block, because I cannot source it. What I can say is that a <meta> tag is the cheapest thing any HTML consumer can read, and anything that reads meta tags without parsing a JSON-LD graph gets the author's URL for free. Two statements of the same fact, in two syntaxes, that agree bind page to person more firmly than one alone. Two that disagree (the schema says Jane, the OG block says the company's Facebook Page) create an ambiguity you did not have before.

Google frames authorship as a human question first. Its helpful-content self-assessment asks "Is it self-evident to your visitors who authored your content?", "Do pages carry a byline, where one might be expected?", and "Do bylines lead to further information about the author or authors involved, giving background about them and the areas they write about?", and it states that "Something that helps people intuitively understand the E-E-A-T of content is when it's clear who created it." The OG byline is the machine-side version of "bylines lead to further information", because its value is the link. If your visible byline links to a profile page and your JSON-LD author points at the same page, the OG block is the one layer left saying nothing.

For the record, this site failed the row the day I wrote it. The base layout set og:type to article on every post, the JSON-LD author was an @id reference to the site's Person node, and nothing from the article block was emitted. That is the exact shape the check was built to catch: the type promised a byline and the block never delivered one.

How to fix it

Step 1: find the author URL your JSON-LD already uses. Run Author Authority per Article on one post. Its "Author in schema" row prints the author's name and type when the author is written inline, and warns when there is a name but no URL. It does not follow an @id reference, so if your author is a pointer to a Person node elsewhere in the graph the row comes up empty; the URL you want is that node's url, a real profile page rather than the fragment identifier. If there is no author URL anywhere, fix that first; the OG tag needs a page to point at, and a profile page both layers can share is the whole point.

Step 2: add the article block to the post layout's <head>, directly after og:type. This is the shape the analyzer's detail line asks for, with the date rows included so the sibling check goes green in the same edit:

<meta property="og:type" content="article">
<meta property="article:author" content="https://example.com/about/">
<meta property="article:published_time" content="2026-09-21T09:00:00-06:00">
<meta property="article:modified_time" content="2026-09-21T14:30:00-06:00">
<meta property="article:section" content="SEO">
<meta property="article:tag" content="Open Graph">
<meta property="article:tag" content="authorship">

Four rules for the values. The datetimes are ISO 8601 with a timezone offset; the spec types them as DateTime, and Google's Article documentation says of datePublished and dateModified that "We recommend that you provide timezone information; otherwise, we will default to the timezone used by Googlebot", so feed both layers from the same source. One article:tag per tag, never a comma-joined list. For multiple authors, repeat article:author once per person. And the author value is a URL, the same URL as your JSON-LD author.url or the Person's url. A facebook.com profile URL is acceptable under the spec if you want that association, but then the two layers no longer share a value; if you go that way, put the Facebook URL in the Person's sameAs so the JSON-LD still connects to it.

While you are there, make sure the profile page itself declares <meta property="og:type" content="profile">. That is what makes the reference resolve to an object of the type article:author expects. On this site the About page already does, so the tag has somewhere correct to land.

Step 3: wire it to your generator so it never drifts. On Eleventy with Nunjucks, have the layout read an author URL from front matter or site data, default to the About page, and prefix the site URL so the value is absolute; emit article:published_time from the same date field and date filter that already feed JSON-LD datePublished, and article:modified_time from dateModified when the post has one. One source, two outputs, no drift. On WordPress, read the page source of a published post, not the plugin settings screen. Yoast's functional spec, for one, fills article:author with the author's profile URL, only on post types and only "when the user has a valid profile URL", so a blank profile field means no tag, which is why a WordPress site with og:type set to article so often shows this row red. Fill the field with the author's profile URL, or print the tag from the theme header. On Next.js with the App Router metadata API, the article fields live under openGraph; the docs show publishedTime and authors rendering as article:published_time and one article:author tag per entry, with modifiedTime, section, and tags in the same article type. The docs' own example passes bare names for authors; pass URLs:

export const metadata = {
  openGraph: {
    type: 'article',
    authors: ['https://example.com/about/'],
    publishedTime: '2026-09-21T09:00:00-06:00',
    modifiedTime: '2026-09-21T14:30:00-06:00',
    section: 'SEO',
    tags: ['Open Graph', 'authorship']
  }
};

Step 4: verify in three places. Run Meta + OG Inspector to confirm og:type reads article and the card preview still renders; it lists og:-prefixed tags only, so the article: rows will not appear there. Re-run the Mega Analyzer and watch both article rows in Crawl Health go green. Then run Author Authority per Article again: its datePublished row reads article:published_time as one of its sources, so the block you just added can turn that row green too. Finally, open the URL you put in article:author in a browser. It should return 200, be indexable, and be about the person. The analyzer will not check this, and a green row pointing at a 404 is worse than a red one.

Step 5: refetch the caches. Facebook's Sharing Debugger triggers a fresh scrape and "will show which meta tags the crawler scrapes as well as any errors or warnings". LinkedIn's Post Inspector does the equivalent for LinkedIn. Until you do this, both platforms keep serving whatever they scraped last.

When to leave it alone

Do not set og:type to article on pages that are not articles just to make these rows appear. A homepage, a product page, or a category listing is not an article, and the row correctly stays hidden. If you have Article JSON-LD on a page whose og:type says website, the row will render, and that mismatch is worth resolving in one direction or the other before you add anything.

Genuinely institutional content is the real exception. A changelog, release notes, or a newsroom post written by "the team" usually has an Organization as its JSON-LD author, and there is no person's profile page to reference. The spec types article:author as a profile, so pointing it at the company's About page is a stretch of the type. My preference is to leave the tag off and accept the warning. It costs one point, and a red row you understand beats a green row that misstates what kind of thing the author is. For the same reason, never put a bare name in the tag to silence the row; the detector accepts it, and you get a pass that means nothing to any parser that follows the reference.

Pseudonymous authors are fine. The spec asks for a profile, not a legal identity, and a pen-name profile page with its own og:type of profile satisfies both the letter and the intent. And if several authors share a byline but only some have profile pages, list the ones who do; the missing page is the thing to fix, not the tag.

Fact-check notes and sources

Source: https://ogp.me/#type_article establishes the article object type, its namespace URI, and the six properties with their types: article:author is a profile array, the time properties are DateTime, article:tag is a string array.
Source: https://ogp.me/ establishes the rule for arrays ("just put multiple versions of the same <meta> tag on your page"), DateTime as ISO 8601, og:url as the object's "permanent ID in the graph", and the profile type.
Source: https://developers.facebook.com/docs/sharing/webmasters/ establishes that the default og:type is website, that "Each URL should be a single object", and that the Sharing Debugger triggers a scrape and shows which meta tags the crawler read. As of 2026-09-21 the page does not mention article:author or any other article property.
Source: https://developers.google.com/search/docs/appearance/structured-data/article establishes that Article has no required properties, that author.url is recommended and defined as "A link to a web page that uniquely identifies the author of the article", and the timezone recommendation for datePublished and dateModified. The page does not mention Open Graph.
Source: https://developers.google.com/search/docs/fundamentals/creating-helpful-content establishes the byline questions quoted above and the sentence about E-E-A-T being easier to understand "when it's clear who created it".
Source: https://www.linkedin.com/post-inspector/ is LinkedIn's tool for re-scraping a URL's preview. LinkedIn's help article on making a site shareable (https://www.linkedin.com/help/linkedin/answer/a521928) lists og:title, og:image, og:description, and og:url and does not mention the article block.
Source: https://developer.yoast.com/features/opengraph/functional-specification/ establishes that Yoast outputs article:author as "The URL of the profile page of the author", "Only populated on post types" and "Only populated when the user has a valid profile URL".
Source: https://nextjs.org/docs/app/api-reference/functions/generate-metadata establishes the openGraph article example: type: 'article', publishedTime, and authors: ['Seb', 'Josh'] render as article:published_time and two article:author tags.

article:author meta tag set: an Open Graph byline that should agree with JSON-LD