# article:author meta tag set: an Open Graph byline that should agree with JSON-LD
Article pages with og:type article and no article:author tag fail this Mega Analyzer row. What it reads, why the value should match your JSON-LD author, and the fix.
Author: J.A. Watte
Published: September 21, 2026
Source: https://jwatte.com/blog/blog-mega-analyzer-article-author-meta/
---
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 ``, 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 `` 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. `` does not count; it uses the `name` attribute and belongs to a different vocabulary, and the same goes for a mistyped ``, since the selector requires `property`. `` 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 `` 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 `` 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](/tools/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 ``, 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:
```html
```
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 ``. 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:
```js
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](/tools/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 `` 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.
## Related reading
- [Your pages look broken on social media because nobody checked the meta tags](/blog/blog-tool-og-twitter-card/)
- [dateModified, Updated Stamps, and article:modified_time: The Three-Layer Freshness Signal](/blog/blog-datemodified-freshness-signal/)
- [Google checks whether your articles have a real author and most don't pass](/blog/blog-tool-author-authority/)
- [Why A Byline Without An Entity Behind It Is Worth Zero To Google](/blog/blog-tool-e-e-a-t-author-entity-graph/)
- [E-E-A-T Schema Markup: The JSON-LD That Makes Google Understand Your Brand](/blog/blog-eeat-schema-structured-data/)
If you fix share cards for clients, this is the kind of one-line layout change that belongs in every audit you deliver, because it is verifiable in a minute and the client can watch the row flip; The $20 Dollar Agency is built around finding and packaging exactly that class of fix.
*This post is informational, not legal advice. Mentions of third parties are nominative fair use. No affiliation is implied.*
---
Canonical HTML: https://jwatte.com/blog/blog-mega-analyzer-article-author-meta/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/blog-mega-analyzer-article-author-meta.webp