How this was measured
On 2026-09-23 we fetched the homepage of 78 well-known domains and parsed every <meta> tag whose property or name began with og: or twitter:. 62 returned a usable page — 41 over a direct connection and 21 over a local proxy.
Two counting rules governed everything below, and both changed the numbers. First, a tag whose content attribute is empty or missing counts as absent: og:title="" is a tag that exists and says nothing. Second, nothing was rendered — this is what the server returned, so any tag injected by JavaScript is invisible here. That caveat bites less for social tags than it did for our JSON-LD survey, because social metadata is usually server-rendered precisely because crawlers do not run JavaScript, but it still makes these figures a floor rather than a rate.
Finding 1: Open Graph is near-universal; Twitter cards are not
56 of the 62 homepages (90%) carried at least one Open Graph tag. But "90% have Open Graph" hides how patchy the individual fields are:
og:title 54/62 (87%) · og:description 53/62 (85%) · og:url 49/62 (79%) · og:image 48/62 (77%) · og:type 48/62 (77%) · og:site_name 40/62 (65%) · og:locale 22/62 (35%).
So roughly one homepage in four has no shareable image at all. That is not a ranking problem — Open Graph has no effect on search — but it is a click problem, and it is invisible from inside the site because everything looks fine.
The Twitter side is where the real gap opens. 34 sites (55%) declared twitter:card as summary_large_image, 14 as summary, 2 as app, and 12 declared no twitter:card at all — about one in five. X falls back to Open Graph for title, description and image, but it still needs twitter:card to know which layout to build. Without it you get a plain link, no matter how good the Open Graph tags are.
Finding 2: two sites ship an og:image tag with nothing in it
We expected this to be common, because it is the mistake that produces a grey box: a site declares a large-image card and supplies no image. It turned out to be rare — 2 of the 34 sites declaring summary_large_image had no usable og:image.
Both are worth looking at, because they fail in different ways.
netflix.com declares twitter:card = summary_large_image and twitter:site, and nothing else — no og:image, no og:title, no og:url. The card type promises a large image that was never supplied.
forbes.com is the more instructive one, because it does emit the tag:
<meta property="og:image" name="image" data-next-head=""/>
There is no content attribute at all. The tag is present, a checker that asks "does og:image exist?" answers yes, and there is no image. Its twitter:image has the same shape, and its og:image:type is image/jpeg,image/gif,image/png — a comma-separated list, which is not a single MIME type and is not a valid value for that field.
This is the failure mode worth remembering, because it is the one automated checks miss. A missing tag fails loudly. A present-but-empty tag passes every "is it there" check and renders nothing.
We should be candid that we had this backwards. Until the day this data was collected, every one of the 25 pages on this site declared twitter:card = summary_large_image with no og:image — the pattern that turns out to be rare in the wild. It is fixed now, and that fix is what led to the next finding.
Finding 3: only 23% declare image dimensions
Of the 48 homepages with a usable og:image, just 11 (23%) also declared og:image:width and og:image:height. The rest leave the scraper to download the image and work out the layout for itself.
That sounds harmless until you think about what happens on the first share. The platform has to fetch the image before it can build the card. If that fetch is slow, rate-limited or blocked — a CDN that dislikes the crawler's user agent, a region where the image host is slow — the first share goes out with no image and the second one works. An intermittent bug like that is far harder to diagnose than a missing tag.
The 11 that declare dimensions: figma.com, x.com, docker.com, developer.mozilla.org, w3.org, moz.com, screamingfrog.co.uk, yoast.com, searchenginejournal.com, harvard.edu and heroku.com.
Four of those — Moz, Screaming Frog, Yoast and Search Engine Journal — are SEO vendors or SEO publications. All four SEO sites in the sample declare dimensions, against 23% overall. They are the same four that showed up as @graph users in our JSON-LD survey, which is a consistent signal: the sites whose business is this metadata treat it more carefully than average by a wide margin.
Only 5 of the 48 (10%) declared og:image:alt. Alternative text on a social card is not decorative — it is what a screen reader announces.
Finding 4: one in four og:title disagrees with the title
14 of the 54 homepages with both a <title> and an og:title showed different text in each — 26%.
Most are trivial: github.com drops a trailing "· GitHub" from the Open Graph version. Some are not. kubernetes.io has <title>Kubernetes</title> alongside og:title = Production-Grade Container Orchestration, so the search result says one thing and the shared link says another. asana.com ships "Work & Project Management for Human-Agent Teams • Asana" as its title and "Asana: The OS for human-agent teams" in the card.
Neither is wrong. But it means the title you optimise for search is not the title people see when the page is shared, and those are usually written for different purposes. If you only ever check one, check the one that appears in search.
Finding 5: what we expected and did not find
Across the 48 usable images: one relative path — kubernetes.io, at /images/kubernetes-open-graph.png — zero http:// images, and zero sites declaring more than one og:image.
Relative og:image URLs are the classic warning: scrapers have no base URL to resolve against, so the tag gets dropped. It happens once in 48. Insecure images, not at all. This is the third survey in a row where a widely repeated warning turned out to be rare at this sample size — which is not an argument for ignoring the warnings, but is an argument for checking the base rate before spending a day on the thing you are worried about.
What to check on your own tags
Is the image tag carrying anything? View source and look for content=. A tag with no content attribute is the one check a validator will not do for you.
Do you declare width and height? Two lines, and it removes the "first share has no image" failure mode entirely.
Do you declare twitter:card? One in five sites we checked skip it, and it is the difference between a card and a bare link.
Does og:title match your title? If not, decide which one you meant and make them agree — or accept that you have written two titles and maintain both.
The Open Graph Preview renders what your tags will actually produce, and the meta tag generator emits the full set including dimensions and alt text.
Limitations
62 homepages chosen by hand to span categories — representative of well-known sites, not of the web. Homepages only; article and product pages carry different tags and are not measured here.
Server-rendered HTML only, so JavaScript-injected tags are invisible and the 90% figure is a floor. Empty and missing content attributes count as absent, which is the stricter reading — the 77% with a usable og:image would be slightly higher if a present-but-empty tag counted.
A single-day snapshot of pages that change constantly.
Reproduce it
The extraction script and the domain list ship with this site and run in about two minutes. It stores the raw HTML for every domain, so each claim above can be checked against the markup itself rather than our summary of it.
If a row is wrong, the markup settles it. Corrections via the contact page.