DEV Community

Cover image for I checked the Open Graph tags on 62 homepages. Here's what's actually broken.
任宏涛
任宏涛

Posted on Originally published at serpprism.com

I checked the Open Graph tags on 62 homepages. Here's what's actually broken.

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:card at 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=""/>
Enter fullscreen mode Exit fullscreen mode

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=""/>
Enter fullscreen mode Exit fullscreen mode

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[^>]*>'
Enter fullscreen mode Exit fullscreen mode

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">
Enter fullscreen mode Exit fullscreen mode

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

  1. Is the image tag carrying anything? View source, look for content=. Present-but-empty is the check no validator does for you.
  2. Do you declare width and height? Two lines, kills the "first share has no image" failure mode.
  3. Do you declare twitter:card? One in five sites skip it.
  4. Does og:title match 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)