Should og:description be different from the meta description?

By default no, and copying is the right starting point. They diverge when the audiences do: a meta description is written for someone actively searching for the thing, and a share description is read by someone scrolling past it with no intent. On pages where that distinction is real, writing both pays.

How long should og:description be?

Short enough to survive the shortest truncation you care about, which is around 100 characters on some mobile surfaces. Two hundred characters is a reasonable ceiling. The shape that survives is a complete first sentence, because a description cut mid-clause reads as broken rather than as continuing.

What happens if og:description is missing?

The platform substitutes text from the page, usually the meta description if present and the first paragraph otherwise. On a page that opens with boilerplate or a cookie notice, that substitution is visibly wrong, which is the case worth catching.

Social descriptions: when og:description should differ from your meta

Pointing og:description at the same string as your meta description is the right answer on most pages, and this guide is mostly about the exceptions. There are four of them, and one of them applies to almost every site.

The short answer

og:description is usually a copy of your meta description, and that is fine on most pages. It stops being fine in four cases: when the meta description is written to win a click from a results page rather than from a feed, when it is missing, when it is truncated differently, and when the share context differs from the search context.

RefinementAudit check · Social descriptions

The same sentence, read in two different rooms

A meta description is read by somebody scanning a ranked list. They arrived with a question already formed, they are comparing you against nine alternatives, and the line that wins is the one that most obviously contains their answer. Repeating the query language is not keyword stuffing there, it is how a scanner confirms they are in the right place.

A share description is read by somebody who was not looking for anything. The link appeared in a feed, a channel or a message from a colleague, next to a picture and a headline. There is no list to compare against and no query to match. What decides a click is whether the line makes the thing sound worth the interruption.

Those are different jobs, and most of the time one sentence does both adequately, which is why the default of a single shared string is defensible. The check exists to find the pages where the shared string is doing one job and failing the other.

The four cases where one string stops being enough

These are worth writing separately. Everything outside them is worth leaving alone.

The description is machine-generated. Ecommerce and documentation platforms commonly build a meta description by truncating the first paragraph or by filling a template with attributes. That output is serviceable in a results list, where the surrounding page and the breadcrumb supply context, and it reads as an error message in a feed. This is the case that applies at scale, and on most sites it is the only one worth acting on.
The page title only makes sense in a search result. A title like Pricing | Fielding Cutleryworks next to a URL and a breadcrumb. Alone above a card, with no site chrome and no query in the reader's head, it is a word. The description has to carry the context the result page was providing for free.
The share has a campaign behind it. If a page is being posted deliberately, with a launch or an announcement attached, the feed copy is part of the campaign and the search copy is not. Write the feed line for the moment; leave the durable one in place for the years afterwards.
The meta description is a specification and the page is a story. Reference pages and API docs get precise, dense descriptions because precision is what a searcher needs. That density is exactly wrong in a feed, where nobody has consented to reading a parameter list yet.

Notice that all four are cases where the meta description is right and simply unsuited to the second surface. If your meta description is bad, you have a different check to fix first, and copying a bad line into a second tag does not improve either of them.

A cut you cannot predict, and the shape that survives it

Every surface truncates, at a different point, and none of them publishes the number. Worse, the cut is not the same for one string in two places: a card in a sidebar shows less than the same card in a main column, and a mobile client shows less than either. Any advice of the form "keep it under N characters" is a guess dressed as a rule.

The reliable technique is structural rather than numerical. Put the whole point in the first clause, and treat everything after the first full stop as material you have accepted might not be delivered. A line built that way is complete at any truncation point, which is the only property that holds across surfaces you cannot test.

descriptions.txt

fragile, because the point is at the end
  In this guide we look at knife maintenance, covering a range of
  techniques and tools, and explain how to restore a rounded edge.

survives any cut, because the point is first
  Restore a rounded edge in ten minutes. Angle, grit order, and the
  two habits that dull a knife faster than use does.

the generated line, correct in a result and wrong in a feed
  Fielding Cutlery - KN-2000-CS - carbon steel, 20cm, full bolster,
  in stock, free delivery over 50 EUR

the deliberate one for the same page
  A forged carbon steel chef's knife that will rust if you leave it
  wet, and hold an edge for years if you don't.

Two smaller mechanics. Emoji count as characters and are dropped or substituted by some readers, so a line whose meaning depends on one is a line that sometimes has no meaning. And a description that repeats the headline word for word wastes the only other slot you have: the card already shows the title directly above it, so restating it costs you the one line of new information you were given.

Comparing two tags across every template

On one page this is trivial to check by hand: read the og:description, read the meta description, and decide whether the shared string is serving both audiences. The version worth automating is the site-wide one, where the question is which templates generate their share copy and which pages have a stale second copy nobody has read since it was pasted.

This one needs the full crawl

og:description is not in the single-page payload, so comparing it against the meta description on every page is a job for the full crawl rather than one fetch.

The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.

Run the full audit, free

Does this affect AI search?

No, in the sense that matters. Share copy is not content. A model answering a question from your page has the body of the page, and a sentence written to make a link tempting in a feed is not the sentence it needs. There is no mechanism by which a better og:description makes you more likely to be retrieved or quoted.

The one thing worth saying is a warning rather than an opportunity. Because feed copy is written to intrigue, it is often written to withhold: a line that hints at an answer without giving it. That is a legitimate technique in a feed, and it is the opposite of what answering directly on the page asks for. Keep the withholding in the share tag, where it belongs, and never let that habit migrate into the page itself.

If you want a description that helps a machine, the one to work on is the meta description, and even there the effect is small next to the content underneath it.

Why deliberate share copy sits at the bottom of the scale

Because the default outcome is adequate. A page that reuses its meta description in og:description ships a complete card with a sentence in it, written by someone at your company, about the right subject. That is a working page being improved, which is the definition of a Refinement.

The rating also reflects that the fix does not scale the way the rest of this pillar does. Nearly every other social check is a template change applied site-wide once. This one is editorial: somebody has to read a page and write a line for it, per page, and no template can do it. That makes it work you spend on your twenty most-shared URLs and decline to do on the other nine thousand, which is a reasonable position and not a backlog item.

The exception, and the reason this check is not simply noise: a generated description is not adequate, it is just present.

If your product or documentation templates are assembling share copy out of attributes and fragments, this stops being a refinement in practice, because every share of every one of those pages is showing a machine artefact to a human being. Fix the template, once, and the check goes quiet across the whole catalogue. That is the version of this work with real leverage in it.

Questions this check raises

Should og:description be different from the meta description?: By default no, and copying is the right starting point. They diverge when the audiences do: a meta description is written for someone actively searching for the thing, and a share description is read by someone scrolling past it with no intent. On pages where that distinction is real, writing both pays.
How long should og:description be?: Short enough to survive the shortest truncation you care about, which is around 100 characters on some mobile surfaces. Two hundred characters is a reasonable ceiling. The shape that survives is a complete first sentence, because a description cut mid-clause reads as broken rather than as continuing.
What happens if og:description is missing?: The platform substitutes text from the page, usually the meta description if present and the first paragraph otherwise. On a page that opens with boilerplate or a cookie notice, that substitution is visibly wrong, which is the case worth catching.