Open Graph tags: what every share, DM and preview reads
Leave these tags out and you do not get a blank preview. You get a preview assembled from whatever a scraper could find, which is the part most people miss: the failure is not an empty card, it is a card somebody else filled in on your behalf.
The short answer
A link preview cannot be assembled without four tags: og:title, og:description, og:image and og:url. Leave one out and the platform substitutes something, usually the first heading it finds and the first image on the page, which is often a logo or an avatar. A preview you did not write is a preview you did not choose.
The four tags a preview cannot be assembled without
The protocol defines dozens of properties and four of them do all the work. og:title is the headline of the card, og:description the line under it, og:image the picture that decides whether anyone reads either, and og:url the address the share is credited to. Everything else on the list refines a case you probably do not have.
Two mechanical details cause most of the broken implementations. First, these are property attributes, not name attributes, which is the opposite of every other meta tag on your page. A scraper looking for property="og:title" will not find name="og:title", and the tag you wrote is inert. Second, they must be in the <head>. A tag injected into the body after load is a tag no scraper will ever read, because the fetch that builds a preview does not run your JavaScript.
<meta property="og:title" content="Sharpening a carbon steel knife" />
<meta property="og:description" content="Angle, grit progression, and the two mistakes that round an edge." />
<meta property="og:image" content="https://example.com/img/sharpening-1200x630.jpg" />
<meta property="og:url" content="https://example.com/guides/sharpening" />
<meta property="og:type" content="article" />
<meta property="og:site_name" content="Fielding Cutlery" />
<!-- wrong: name= instead of property=, so nothing reads it -->
<meta name="og:title" content="Sharpening a carbon steel knife" />og:site_name is the cheapest of the optional ones and worth setting once in a layout: it is the small label some surfaces print above the headline, and without it the slot either sits empty or fills with your bare domain.
A missing tag is a substitution, not a gap
This is the mechanism that makes the whole check feel optional and is exactly why it is not. Every field has a fallback order, resolved independently. Leave out og:title and the headline comes from your <title>, which was written to be read next to nine other results and now has your brand name bolted onto the end of it. Leave out og:image and the scraper picks something off the page: a logo, an author avatar, the first thing large enough to qualify.
og:image and no og:titlegets your picture and someone else's headline. Only the text and image rows have a dead end at all, which is why an unmanaged preview still looks populated: something almost always answers.The consequence is that a broken preview rarely looks broken. It looks like a card, with a plausible headline and a picture, that nobody at your company chose. That is harder to notice than a blank space, and it is why this is one of the few checks where a page can look fine in every browser and still be shipping the wrong thing to every reader who arrives through a link somebody pasted.
og:type, and the one case where it changes anything
og:type takes website, article, video.movie, music.song and a long tail of others. On the overwhelming majority of pages it changes nothing you can see, which is why it gets set to website everywhere and forgotten.
It earns attention in one situation: article unlocks the article sub-properties, and article:published_time is the tag that puts a date on your card in the places that show one. If you publish anything time-sensitive, that date is the difference between a link that reads as current and a link that reads as undated. The rest of the article namespace, article:author and article:section and article:tag, is largely decorative now.
The failure worth avoiding is inventing a value. og:type is an enumeration, and blog, post, page and product-page are not in it. An unrecognised type is treated as the default, so you have not customised anything, you have just written a line that reads like configuration and behaves like a comment.
Check one page for a title and an image
This fetches the URL you enter and reports whether og:title and og:image are declared, because those are the two fields whose absence changes what a human sees. It reads the declarations, so it can tell you a tag is missing and cannot tell you an image returns a 404.
No signup required. Each free search audits one page, paste any URL to see it in action.
One standard, and a different reader on every surface
Open Graph came out of one company and became a convention everywhere else, which means there is no conformance test and no arbiter. What you get instead is a set of readers that mostly agree and disagree in specific, learnable ways.
- Some surfaces cache aggressively. A scraper that has seen your URL may keep its answer for days, so fixing a tag does not fix the preview already circulating. Most platforms expose a debugger that forces a re-fetch, and that is the only reliable way to clear it.
- Chat clients fetch from their own servers. A link pasted into a messaging app is unfurled by that app's infrastructure, not by the recipient's device. If your page is behind a login, a geo rule or a firewall that allows browsers and blocks unknown agents, the preview is empty for reasons that have nothing to do with your markup.
- Truncation limits differ and are not published. The same description is cut at different points on different surfaces, and none of them tell you where. Front-load the sentence and the cut stops mattering.
The practical rule: treat one platform's debugger as a syntax check and not as an oracle. It tells you your tags parse. It cannot tell you how the next client to read them will behave.
Does this affect AI search?
Indirectly, and less than the tag's prominence suggests. An assistant reading your page to answer a question is reading the page, not the head. It has the whole body available and no reason to prefer a 60-character summary you wrote for a feed. Nothing in this check makes you more quotable.
Where it does land is in the moment a machine hands your link to a person. Chat interfaces that cite sources increasingly render a card rather than a bare URL, and that card is built the same way every other card is built: from these tags, or from a guess. So Open Graph does not affect whether you are cited. It affects whether the citation looks like something worth clicking, which is the last step of a chain the rest of this audit spends its time on.
There is one honest second-order effect. og:title and og:description are two more places you state, in your own words, what a page is about. A model that reads them alongside your <title> and your first paragraph sees the same claim three times, which is worth something on a page whose subject is otherwise ambiguous. That is a modest gain and a poor reason to prioritise this check. Prioritise it for the humans.
Why a preview you did not write is rated Important
It sits below Critical because nothing about indexing or ranking depends on it. A page with no Open Graph tags is crawled normally, ranks normally and reads normally. Search engines do not consume these tags for ranking, and no amount of care here moves a position.
It sits well above Refinement because of who is affected. Every one of these people is already at the point of deciding: somebody pasted your link into a channel where their colleagues will see it, or shared it with a friend, or scheduled it in a feed. This is the highest-intent traffic on your site, arriving through the one surface where you have published no copy at all. A default card is not a neutral outcome in that context, it is a worse ad than the one you would have written in five minutes.
The rating also accounts for the shape of the fix. It is two or three lines in a layout template, applied site-wide, with no data to gather and no migration. Findings that are cheap to close and visible to a human at the moment of decision belong in the plan, not in the polish list.
Confirming what the scraper actually sees
Your browser is the wrong instrument here, because it runs your JavaScript and a scraper does not. Fetch the raw document instead and read the head as it was served.
# every og: tag, exactly as it left the server
curl -s https://example.com/guides/sharpening \
| grep -o '<meta property="og:[^>]*>'
# the mistake that produces an inert tag
curl -s https://example.com/guides/sharpening \
| grep -o '<meta name="og:[^>]*>'
# does the declared image actually resolve?
curl -sI "$(curl -s https://example.com/guides/sharpening \
| grep -o 'property="og:image" content="[^"]*"' \
| sed 's/.*content="//;s/"$//')" | head -1If the first command prints nothing and your browser's inspector shows the tags, they are being added client-side.
This is the most common false sense of security on this check. A single-page framework that sets meta tags in a client component will show them in the inspector, because the inspector shows the live DOM after your code has run. The scraper reads the response body. Move them to whatever your framework uses to render the head on the server, and confirm with curl rather than with the inspector. The same trap catches everything else rendered after load.
Then paste the URL into a private message to yourself on whichever platform your audience actually uses. It is the only check that tests the whole chain, the fetch, the cache, the crop and the truncation, in the exact place where it matters.
Questions this check raises
- What happens if og:image is missing?
- The platform picks an image from the page, and its heuristics favour whatever appears first, which on most templates is a logo, a header graphic or an author avatar. Some surfaces show no image at all, and a text-only preview in a feed of image cards is close to invisible.
- Do I need og:type on every page?
- A missing og:type defaults to website, which is correct for most pages. It matters where the value changes what a platform does with the link, such as article on editorial content or video on a video page. Setting it to article on your pricing page changes nothing and is not worth the audit.
- Do all platforms read Open Graph the same way?
- No. It is one standard with a different reader on every surface: they differ on image aspect ratio, on description truncation, on whether they follow redirects, and on how aggressively they cache. A preview that looks right in one debugger can still be cropped badly in another app.