Open Graph Tags Missing, and the One Almost Everyone Skips

We ran 118 tests that raised incomplete Open Graph tags, and 107 of them were missing the same one. It was not the title, and it was not the description.

That figure comes from our own store, and it is worth stating plainly because the usual advice treats every Open Graph tag as equally absent. They are not, and the Enterramon card tells you something slightly different from what the protocol requires. Both are worth knowing before you change anything.

What the Open Graph tags specification requires

Four properties are required on every page, per the Open Graph protocol. They are og:title, og:type, og:image and og:url.

og:description is optional. The spec lists it under optional metadata and recommends it, but it is not one of the four. The Enterramon card tells you to add og:title, og:description and og:image, which names an optional tag and omits two required ones. Follow the card alone and you can still ship a page that is missing og:type and og:url.

I would add the description anyway. It is what the platform shows beneath the headline, and a preview carrying a title with no context is worse than one with it. The card describes what most often improves a share rather than what the spec demands.

The image is the tag that is missing

Across those 118 reports, the evidence broke down like this.

On the same pages, 46 carried an og:title, 45 had a description and 44 had og:url. Eleven had an image.

The title and description are usually a CMS default. WordPress, Shopify and most site builders emit them whether or not anybody configured them. An image needs a human decision, and that is the decision that gets skipped.

A link with no image shares as a line of grey text. A link with one takes several times the vertical space in a feed, and it is where a reader's eye lands first. If you are fixing one tag today, fix that one.

One image sitewide, or one per page

A single og:image set across the whole site is the cheap version, and our own pages did exactly that for a long time. Every share looks identical, which beats nothing.

The version that pays is a template. Where pages are generated, the image can be generated too, with the page title and the site name composited over a background. That is the same work once, and afterwards every new page arrives with a preview image attached and nobody has to think about it again.

So the order is this. Set one default image today, because that alone moves the great majority of those 118 cases and it takes a minute in whatever your CMS or SEO plugin offers. Then come back and make it a template when the manual override starts to annoy you. Most WordPress SEO plugins support a sitewide default and a per-post override, which is enough for both stages.

Does X need its own tags

Ninety of our reports raise a separate finding for missing Twitter card tags, and 79 of those also raise the Open Graph finding. They are one gap reported twice, so it is worth knowing that X reads Open Graph when its own tags are absent.

The published specification for the X tags Yoast emits is explicit about it. Those tags exist for the cases where a value should differ from the Open Graph one, and several are only output once a specific X value has been set. twitter:title, twitter:description and twitter:image all fall back to their Open Graph equivalents.

The one that does not fall back is twitter:card. It tells X which layout to draw, and without it the link renders as a plain summary instead of a large image card. Across those 90 reports, not one page had it.

So the whole X side of this is one line. Add twitter:card with a value of summary_large_image and let everything else come from the Open Graph tags you already set. The exception is twitter:site and twitter:creator, which carry an account handle and have no Open Graph equivalent.

One caveat on the large card. It needs an image wide enough to fill the layout, and where the image is too small X drops back to the smaller summary card. That is a silent downgrade rather than an error, so it looks like the tag did nothing.

Two details the spec mentions that get skipped

og:image:alt describes the image. The spec says that where a page specifies an og:image it should also specify an og:image:alt, which is the same job as the alt text on the images in your markup, covered in the missing alt text guide.

og:url should be the canonical URL of the page. Where a site answers on more than one hostname, or serves the same content at two paths, this is where you say which one is real. It does the same job as the canonical link element, and it is worth checking that the two agree, because a mismatch sends the platform one URL and search engines another.

The 1200 by 630 figure quoted everywhere comes from platform guidance and convention. The protocol itself states no pixel size, and I could not find one in it. The number is repeated because it is wide enough for the largest card layout without cropping on the major platforms, which is a practice rather than a rule. Treat it as a safe default. Nothing fails if you choose another size.

What to check once you have changed it

Platforms cache the preview. Add the tags, share the link immediately, and you may still see the old preview or none at all, because the platform looked before your change and kept the result. Facebook's sharing debugger and LinkedIn's Post Inspector both force a re-scrape, and both show you which tags they actually parsed.

That is the useful part. The debugger reports what the platform parsed, and a tag that is present but malformed looks exactly like a missing one until you read its output.

Where pages sit behind a CDN, purge the HTML for the page before re-scraping. The platform fetches through the same edge everyone else does, so a cached copy without your new tags keeps the preview wrong however many times you ask it to look again.

If your page also lacks a meta description, the guide on that finding covers what happens to the search snippet, which is a different job from the social card and worth doing in the same sitting.