Link previews for AI: Open Graph and Twitter cards

Paste a link into Slack and a card appears: an image, a title, a short description, the site's name. When a page is cited in a search result, something similar shows up next to the source. Open Graph is the set of tags that fills the social preview card, and it feeds Google's title link and preview image. It is the core of this guide, along with the related tags in your page's head: Twitter/X cards, the favicon, and the feed links. Titles and meta descriptions, structured data, and robots directives are each their own topic and are covered separately. The interesting question here is not what Open Graph is, because the tags are simple. It is which machines actually read them: social platforms and Google document doing so, while ChatGPT, Claude, Perplexity and Copilot do not.

How AI crawlers see these tags

Everything in this article lives in the raw HTML head. Open Graph tags are <meta property="og:..."> elements, Twitter cards are <meta name="twitter:..."> elements, the favicon and feeds are <link> elements. A crawler gets all of them on the very first request, in the plain HTML response, before any JavaScript runs. There is nothing to render and nothing to execute.

That matters because most AI crawlers do not execute JavaScript. A December 2024 analysis by Vercel and MERJ found that the major AI crawlers, GPTBot, ClaudeBot and PerplexityBot among them, read the HTML a server returns and do not run its scripts. For the preview layer this is good news: tags in the static head are as readable to those crawlers as to any browser. The main way to lose them at the crawler level is to inject them client-side, with a tag manager or a framework that writes meta tags after load. A tag that only exists after JavaScript runs does not exist for the non-rendering crawlers Vercel and MERJ measured. Social unfurlers behave the same way in practice, but each platform documents its own fetcher.

Who actually reads your Open Graph

Social and messaging unfurlers: documented

Open Graph began as a social standard and that is still where it unambiguously runs. The protocol's own site states the purpose plainly: "The Open Graph protocol enables any web page to become a rich object in a social graph. For instance, this is used on Facebook to allow any web page to have the same functionality as any other object on Facebook" (ogp.me). Facebook, LinkedIn, Slack, Discord, iMessage, Telegram and X all send an unfurler to fetch a shared URL and build the preview card from its Open Graph tags. On platforms that document Open Graph support, these tags drive the preview people see, subject to each platform's fallbacks and caching. That behavior is documented, not guessed at.

Google: documented, for classic surfaces

Google also reads Open Graph, in two documented places. First, og:title is one of the sources Google draws on when it builds the title link for a result (Google title link docs). Second, og:image is one of the inputs to Google's automated preview-image selection. Google's documentation says "Google's selection of an image preview is completely automated and takes into account a number of different sources to select which image on a given page is shown on Google (for example, a text result image or the preview image in Discover)," and it lists "Specify the og:image meta tag" as one of the ways to influence that selection (Google image docs).

Read that scope carefully. The document covers Search and Discover, the classic surfaces. It does not mention AI Overviews. When an AI Overview shows a thumbnail next to a cited page, the image appears to come from the same automated selection, but that is an observation from watching results, not something Google documents. The documented claim stops at Search and Discover; the AI-surface benefit rides along unofficially.

AI answer engines: not documented

Now the surfaces this article is named for. ChatGPT, Claude, Perplexity and Bing Copilot do not document reading your og:* tags. Not one of the four vendors states anywhere that its answers, citations or source cards are built from Open Graph. The tags sit in static HTML, so any fetcher that gets the server response can read them; Vercel and MERJ measured GPTBot, ClaudeBot and PerplexityBot doing exactly that. Being able to read a tag and committing to use it are different things, and only the first is established.

The claim you will find across the industry, that "AI reads your OG tags" and that a polished Open Graph set improves how you appear in AI answers, is an inference. It is a plausible one: the tags are cheap to parse and describe the page well. But no vendor documents it and no study measures an Open Graph effect on AI citations. Open Graph is presentation metadata, not a ranking input: it is absent from Google's list of supported meta tags, and Google documents og:title and og:image only as inputs to how a result is presented. The honest position is this: Open Graph earns its keep on the social and Google surfaces you can verify, and any benefit in AI answers is a possible bonus you cannot count on.

Writing the Open Graph set

The spec at ogp.me requires four properties. og:title is the title of your object as it should appear in the card. og:type says what kind of thing the page is, usually article or website. og:image is "An image URL which should represent your object within the graph". og:url is "The canonical URL of your object that will be used as its permanent ID in the graph". Two optional properties are worth setting on every page: og:description, "A one to two sentence description of your object", and og:site_name, the name of the site the page belongs to.

A handful of rules cover most broken previews:

• Open Graph uses the property attribute, not name. A tag written as <meta name="og:title"> is malformed and unfurlers may ignore it.
• Use an absolute URL for og:image, and prefer HTTPS. A relative path is a common reason a card renders with no image, because the unfurler has no page context to resolve it against.
• og:url should match your canonical URL, so every share of the page consolidates on one identity instead of splitting across URL variants.
• A 1200 by 630 pixel image is the safe default size across the major surfaces.

Choose the image itself with the card in mind. Google's guidance for preview images is direct: "Avoid using a generic image (for example, your site logo) or an image with text in the schema.org markup or og:image meta tag" (Google image docs). A bare logo tells the reader nothing about the page, and text baked into the image shrinks to illegibility at card size. Use a real image that represents the content.

A complete set looks like this:

<meta property="og:title" content="A Field Guide to Winter Songbirds">
<meta property="og:type" content="article">
<meta property="og:image" content="https://example.com/images/winter-songbirds-1200x630.jpg">
<meta property="og:url" content="https://example.com/guides/winter-songbirds">
<meta property="og:description" content="How to identify the songbirds that stay through winter, with photos and range notes for each species.">
<meta property="og:site_name" content="Example Field Guides">

Twitter cards

X reads Open Graph. When a twitter:* tag is missing, X falls back to the matching og:* value, so a page with a complete Open Graph set already previews correctly there. The only line X still needs is the card type, which has no Open Graph equivalent:

<meta name="twitter:card" content="summary_large_image">

That one tag plus your Open Graph set is the whole X integration for most sites. The full twitter:title, twitter:description and twitter:image set is only worth maintaining if X is a channel you tune separately from everything else. One syntax trap: Twitter tags use the name attribute, the opposite of Open Graph's property. Mixing the two up silently breaks whichever tag got the wrong attribute.

The favicon

The favicon is the small brand icon a surface shows next to your link: in the browser tab, in bookmark lists, and on result and source cards. Google's documentation says "If your site has a favicon, it can be included in Google Search results for your site" (Google favicon docs). That document covers organic search. Beyond it, AI surfaces are observed to do the same thing: Google AI Overviews, Perplexity, Bing Copilot and ChatGPT search all show a small site icon next to cited sources in current results. That is observation of live behavior, not a documented guarantee from any of those vendors.

The mechanics are simple. A site gets one favicon per hostname, declared in the head with <link rel="icon">. The image should be square, and Googlebot-Image must be allowed to crawl it, so do not block the icon's path in robots.txt. A favicon changes nothing about how a page is ranked or retrieved. It is cosmetic. But it is the one piece of branding that follows your site onto every list and card that mentions it, and it costs one tag and one small image.

Feeds, and the dead weight

Two more kinds of <link rel="alternate"> commonly sit in the head, and they have gone in opposite directions.

RSS and Atom feeds still earn their place. A feed link such as <link rel="alternate" type="application/rss+xml"> tells feed-reading crawlers and aggregators where to find a machine-readable list of your latest content, which helps them discover new pages quickly and judge how fresh the site is. If you publish more than one feed, give each a distinct title attribute so subscribers and crawlers can tell them apart.

AMP is the opposite case. AMP is no longer required for Top Stories, and Google documents that "AMP pages can appear in Google Search as a rich result, just like other pages on the web" (Google AMP docs). <link rel="amphtml"> therefore points at a parallel copy that gets no preferential treatment. It is dead weight for most sites. Before removing it, check what the AMP pages still receive in traffic, whether any partner or platform integration consumes them, and set up redirects, because retiring a parallel URL set is a migration, not a tag deletion. Separate mobile URLs, the old m-dot pattern with its own alternate links, are a legacy of the same era. Google still supports that pattern but recommends responsive design, so migrate to responsive first and remove the alternate annotations only after the migration is complete.

FAQ

Do AI engines read my Open Graph tags?

They can: the tags sit in the raw HTML head, so no JavaScript is needed to read them. But none of ChatGPT, Claude, Perplexity or Bing Copilot documents using them, so treat any AI-answer benefit as unproven. What definitely reads Open Graph: social and messaging apps, and Google, where og:title feeds the title link and og:image can become the preview image.

Do Open Graph tags help my rankings?

No. Open Graph is not on Google's list of supported meta tags; Google documents it only as an input to how a result is presented. Its value is the preview card that shows when your page is shared or listed, not a ranking boost.

What is the right og:image size?

A 1200 by 630 pixel image on an absolute HTTPS URL works across the major surfaces. Avoid your bare logo or an image that is mostly text.

Do I still need Twitter card tags?

Barely. X falls back to Open Graph, so with a complete OG set you only need one line, twitter:card set to summary_large_image. Add the full twitter set only if you tune X separately.

Should I keep AMP or a separate mobile site?

No. AMP pages appear in Search like other pages, so the amphtml alternate link is dead weight. Google still supports separate mobile URLs but recommends responsive design.