Open Graph was designed so that a link pasted into Facebook could render a card. The same handful of tags are now the shortest machine-readable description of a page that exists, and they are read far more often by software that will never draw a card at all. A retrieval crawler deciding what a page is about, a tool summarising a URL somebody pasted, a model choosing which of ten results to open: each finds og:title, og:description and og:image in the first few kilobytes of the response, before any heading or paragraph, and each will use them if they are there. Two checks in the rubric look at them. B4 asks whether they are present on every page; D5 asks whether they agree with everything else the page says about itself.
What the tags are
The Open Graph protocol is a set of meta elements in the document head, each with a property attribute and a content attribute. The protocol lists og:title, og:type, og:image and og:url as required and og:description and og:site_name among the optional ones. A complete set for a product page looks like this.
<meta property="og:title" content="Field notebook, A5, dotted" />
<meta property="og:description" content="Ninety-six pages of 100gsm paper, sewn binding, and a cover that survives a coat pocket." />
<meta property="og:image" content="https://example.com/og/field-notebook-a5.png" />
<meta property="og:url" content="https://example.com/products/field-notebook-a5" />
<meta property="og:type" content="product" />
<meta property="og:site_name" content="Example Stationery" />
The rubric scores three of these plus og:site_name. og:type and og:url are harmless, and og:url is a useful second statement of the canonical address, but nothing in the rubric turns on them.
The reason a machine reaches for these before the body is that they are short, structured, sit in the head, and were written by the author to summarise the page. Extracting a summary from the body instead means finding the first heading, guessing which paragraph is the lead, and hoping the cookie notice was not first in source order. The og:description is often the only sentence on the page a person wrote specifically to say what the page is.
How B4 scores them
B4, meta and Open Graph, is worth three points and rated Low effort. One point goes to a unique title of 15 to 70 characters on every crawled page, one to a meta description of 50 to 160 on every page, and one to og:title, og:description and og:image all being present on every page. The lengths have their own post, title and description lengths, and why the ranges exist. This one is about the third point.
Three details of how the scanner reads the tags matter in practice. It reads the raw HTML from a plain fetch, so tags injected by a client-side head manager after hydration are not seen. It accepts either property="og:title" or name="og:title", because both are common in the wild and the protocol's property form is the one a strict parser wants. And it checks every crawled page, not the homepage alone. The evidence field completeOpenGraph records how many pages carried all three, against pagesCrawled. A homepage with a hand-crafted set and a blog template with none loses the point, which is the most common way it is lost.
The scanner does not check the length of og:title or og:description, only that they exist. Reusing the page's title and meta description for them is fine and is what most frameworks do by default.
How D5 uses them
D5, identity consistency, is worth three points and rated Low. Two of them are for the site name agreeing across three places: the title element, og:site_name, and the name in the page's JSON-LD. The third is for a favicon and an og:image both being declared on the homepage.
The comparison is more forgiving than it sounds. Each of the three values is lowercased and stripped of everything that is not a letter or digit, and the check passes when every value contains, or is contained by, one of the others. A title of "AgentFriendlyRank — Agent readiness audits and fixes" contains "agentfriendlyrank", so it agrees with an og:site_name of "AgentFriendlyRank" and an Organization name of the same. At least two of the three must be present; a page with no og:site_name and no JSON-LD has nothing to compare and scores zero on this part.
The gotcha is which name gets compared. The scanner takes the first name value it finds in the page's JSON-LD, in source order. If a Product block appears before the Organization block, the product's name is what is compared against og:site_name, and the check fails for a site whose identity is perfectly consistent. Put Organization or WebSite first, or in a single @graph with the organisation as the first node.
The third point wants a link element whose rel contains icon, and an og:image with content. The rubric asks that both resolve, and the free scan records whether each is declared on the homepage as hasFavicon and hasOgImage in the evidence block. Confirm the resolving part yourself: fetch the og:image URL with curl -I and expect a 200 with an image content type. A relative path, a URL on a CDN that refuses bots, or an image that was renamed when the design changed all pass the declaration and fail the intent.
The reason D5 exists at all is provenance. The recommendation text on a failing report says it plainly: an unexplained name mismatch reads as a signal the site may not be what it claims. A model weighing whether to cite a page has nothing but the page's own statements to go on, and three statements that disagree are worse than one.
How we generate the image
Our own og:image is not a file. It is rendered on the server per request, and the way it is wired is the reason every page on this site has one without any page declaring it.
In the Next.js App Router, a file named opengraph-image.tsx placed next to the root layout is rendered as a PNG through next/og, and Next inherits it down the whole route tree. A route that does not define its own gets the root image. Report pages and comparison pages do define their own, per-page cards that carry the actual score and grade, and blog posts have one too. The shared chrome — the mark and wordmark, a footer line, a blue baseline rule, the 1200 by 630 canvas — lives in one component that the root image and every per-page card render through, so they cannot drift apart. Colours in that component are the Carbon g100 values hardcoded, because next/og renders outside the site's Tailwind pipeline.
The identity half of D5 is handled the same way. The site name, the title template, og:site_name and the schema name all read from one site object, which exists so that the three values D5 compares are defined exactly once and structurally cannot disagree.
One implementation note the code carries as a comment, because it cost an afternoon: the renderer behind next/og fails on a bare number as a JSX child, with an error message about display: flex that points nowhere near the cause. A score of 87 has to be rendered as String(score). Next's own documentation for file-based metadata is at nextjs.org/docs.
None of this requires Next. The point is the pattern: one place that defines the name, one template that produces the image, and every route inheriting both. The failure mode B4 and D5 catch is the opposite pattern, where each page manages its own tags and half of them do not.
Check your own site
Run the free scan and read the B4 and D5 evidence, which show how many crawled pages carried all three tags and what the three name values were. The full definitions are under understanding and trust and freshness on the methodology page, and our own result, image and all, is at /site/agentfriendlyrank.com.