Open Graph tags don't affect rankings. They decide something narrower and easier to forget: whether your link renders as a card with an image, or as a bare grey link that people scroll past.
I got curious about what's actually in the wild, so I fetched the homepages of 78 well-known domains and parsed every <meta> tag whose property or name started with og: or twitter:. 62 came back usable.
Here's what I found, including one failure mode I had never considered.
Method, and the two counting rules that changed the numbers
78 domains, 62 usable homepages. Two rules mattered:
An empty or missing content attribute counts as absent. og:title="" is a tag that exists and says nothing. If you count it as present, you inflate your numbers and — as it turns out — hide the most interesting bug in the dataset.
No JavaScript was executed. This is server-rendered HTML only. That's usually fine for social tags (they're server-rendered because crawlers don't run JS), but it means every percentage below is a floor, not a rate.
Finding 1: Open Graph is near-universal. Twitter cards are not.
56 of 62 homepages (90%) had at least one Open Graph tag. But that headline hides how patchy individual fields are:
| tag | count | % |
|---|---|---|
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 about one homepage in four has no shareable image.
The Twitter side is where the real gap is. Of the 62:
- 34 (55%) declared
twitter:card=summary_large_image - 14 (23%) =
summary - 2 (3%) =
app - 12 (19%) declared no
twitter:cardat all
That last group is the one to care about. 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 your Open Graph tags are.
Finding 2: two sites ship an og:image tag with nothing in it
I expected this to be common. It wasn't: only 2 of the 34 sites declaring summary_large_image had no usable image. But the two fail differently, and one of them is genuinely sneaky.
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 does emit the tag:
<meta property="og:image" name="image" data-next-head=""/>
There is no content attribute at all.
This is the failure mode worth internalising. A missing tag fails loudly — any validator catches it. A present-but-empty tag passes every "is it there?" check and renders nothing. If your audit tool asks "does og:image exist?", Forbes returns yes.
Its twitter:image has the same shape, and its og:image:type is:
<meta property="og:image:type" content="image/jpeg,image/gif,image/png" data-next-head=""/>
A comma-separated list. Not a single MIME type. Not a valid value for that field.
You can spot this in one line:
curl -s https://example.com | grep -o '<meta[^>]*og:image[^>]*>'
If the tag shows up with no content=, you've found it.
I should be candid that I had this exactly backwards: until the day I collected this data, all 25 pages on my own site declared summary_large_image with no og:image. The pattern that turns out to be rare in the wild was on every page of my site.
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.
This sounds harmless. It isn't, and the reason is subtle: without dimensions the platform has to download the image before it can lay out 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, because by the time you look, it works.
The 11 that do declare dimensions: figma.com, x.com, docker.com, developer.mozilla.org, w3.org, moz.com, screamingfrog.co.uk, yoast.com, searchenginejournal.com, harvard.edu, heroku.com.
Four of those — Moz, Screaming Frog, Yoast, Search Engine Journal — are SEO vendors or publications. All four SEO sites in the sample declare dimensions, against 23% overall. They're also the same four that showed up as @graph users when I ran the equivalent survey on JSON-LD. Consistent signal: the sites whose business is this metadata treat it better than average by a wide margin.
Only 5 of 48 (10%) declared og:image:alt. Alt text on a social card isn't decorative — it's what a screen reader announces.
Finding 4: one in four og:title disagrees with <title>
14 of the 54 homepages with both showed different text in each (26%).
Most are trivial: github.com drops a trailing "· GitHub" from the Open Graph version. Some aren't. kubernetes.io ships:
<title>Kubernetes</title>
<meta property="og:title" content="Production-Grade Container Orchestration">
The search result says one thing; the shared link says another. Neither is wrong — but it means the title you optimised for search isn't the one people see when the page is shared, and those are written for different purposes. If you only check one, check the one that appears in search.
Finding 5: the things I expected and didn't find
Across 48 usable images:
-
1 relative path (
kubernetes.io,/images/kubernetes-open-graph.png) -
0
http://images -
0 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 happened 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. That's not an argument for ignoring the warnings. It's an argument for checking the base rate before you spend a day on the thing you're worried about.
What to check on your own tags
-
Is the image tag carrying anything? View source, look for
content=. Present-but-empty is the check no validator does for you. - Do you declare width and height? Two lines, kills the "first share has no image" failure mode.
-
Do you declare
twitter:card? One in five sites skip it. -
Does
og:titlematch your title? If not, pick which one you meant.
The full dataset — including the raw HTML for all 62 domains, so you can check any claim against the markup rather than my summary of it — is on SerpPrism. There's also a preview tool that renders what your tags will actually produce.
If you find a row that's wrong, the markup settles it — and I'd genuinely like to know.
Top comments (0)