Open Graph Tags and Twitter Cards: Control How Shared Links Look

When someone pastes your link into a chat app, a social network or a messaging tool, the app usually fetches the page and builds a small preview: a title, a short description and a picture. If you have not told it what to show, it guesses. The guess might be the wrong image, a cut-off title, or no picture at all.

Open Graph tags are the standard way to control that preview. Twitter Cards (now associated with X) use a similar set of tags. This guide is for site owners, marketers and developers who want links to look right when shared. You will add the minimum set of tags, write sensible values, test the result, and avoid the mistakes that cause blank or stale previews.

Keep the scope in mind. Open Graph tags change how a link is presented by the apps that read them. They are not a Google ranking signal, and each app decides for itself how, and whether, to use them. Google does list og:title and og:image among the signals it may consider for a title link and for a preferred image, but that is a hint to Google, not control.

Before you begin

You need edit access to the <head> of your pages or your CMS or SEO plugin settings, a share-ready image for each important page (or a default image), and a few real URLs to test. Plan about an hour for a small site. Decide whether you want one default image for the whole site plus per-page overrides for articles and products.

Back up your templates before editing. If an SEO plugin already outputs Open Graph tags, do not add a second set by hand. Duplicate tags are confusing: the Open Graph protocol says that if a property is repeated in conflicting ways, the first tag from the top of the page takes precedence.

How Open Graph works

The Open Graph protocol turns a web page into an object that can be shared. You describe the object with <meta property="og:..."> tags in the <head>. The protocol's site lists four required properties:

og:title: the title of the object as it should appear in the graph.
og:type: the type of object, such as website or article.
og:image: an image URL that represents the object.
og:url: the canonical URL of the object, used as its permanent ID.

Common optional properties include:

og:description: a short description, one or two sentences.
og:site_name: the name of the overall site.
og:locale: the locale in language_TERRITORY format, such as en_US.
og:image:alt: a description of the image's content. The protocol says to include it whenever you specify og:image.
og:image:width and og:image:height: the image size in pixels.
og:image:type: the image MIME type.
og:image:secure_url: an HTTPS alternative for the image.

A page without any markup is treated as the type website. For articles, blog posts and guides, use og:type with the value article.

Twitter Card tags

Twitter's card markup uses twitter: names, such as twitter:card, which selects the card layout (for example summary_large_image). X's documentation says its card reader checks for the Twitter-specific tag first and falls back to the matching Open Graph tag, so with good Open Graph markup you often need only twitter:card. We could not open X's documentation pages directly while writing, so check the current options and image rules on the X developer site before depending on any detail beyond twitter:card and the fallback behavior.

Step-by-step instructions

Step 1: Decide the values for each page type

Why: previews work best when each page has its own title and image, and generic pages have a good default.

Write a table with a row for each page type:

Title: usually the page title, without a long site-name suffix.
Description: one or two sentences that explain the page.
Image: a relevant picture, or the default site image.
Type: website for the home page, article for articles, products and guides.
Canonical URL: the preferred address of the page.

How to confirm: every page type has a defined source for each value, from your CMS fields or template logic.

Step 2: Choose and prepare the image

Why: the image does most of the work in a preview. Google, in its image documentation, advises choosing relevant, representative images and avoiding generic ones such as logos, images containing text, and extreme aspect ratios. Use a high-resolution file where possible.

Each platform has its own size rules and they change, so check them. As a practical starting point, Crawvix's own check suggests a 1200 by 630 pixel image, a landscape shape that previews commonly crop well. That is a starting size, not a rule from the Open Graph protocol, which does not set one.

Serve the image over HTTPS from a public URL, with a real image content type. Do not put it behind a login, and do not block it in robots.txt.

How to confirm: opening the image URL in a private browser window shows the image, with no sign-in or redirect to a login page.

Step 3: Add the tags to the head

Why: this is the change that controls the preview. Use absolute URLs. Here is a complete, minimal set for an article:

<head>
  <title>Fix Redirect Chains on Your Website | Example Co</title>
  <meta property="og:title" content="Fix Redirect Chains on Your Website">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://example.com/guides/fix-redirect-chains">
  <meta property="og:image" content="https://example.com/img/redirect-chains-share.jpg">
  <meta property="og:image:alt" content="Diagram of a redirect chain with three hops">
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta property="og:description" content="Find redirect chains, shorten them to one hop and confirm the result.">
  <meta property="og:site_name" content="Example Co">
  <meta property="og:locale" content="en_US">
  <meta name="twitter:card" content="summary_large_image">
</head>

Open Graph tags use the property attribute, while Twitter tags are normally written with name. Keep the values accurate and in step with the visible page. The og:url should match the canonical URL, as explained in Fix Duplicate URLs and Incorrect Canonical Tags.

If you rely on a prefix declaration, the protocol shows prefix="og: https://ogp.me/ns#" on the <html> or <head> element. Many consumers read the tags without it, but adding the prefix is harmless and matches the specification.

How to confirm: view the page source and find each tag exactly once, in the <head>.

Step 4: Avoid duplicates from plugins and themes

Why: SEO plugins, themes and tag managers often add their own Open Graph tags. Search the source for og:title. If it appears twice, turn one source off. Because the first tag from the top wins in a conflict, the wrong one may be winning without you noticing.

How to confirm: each og: property appears once, unless a property is intentionally repeated (such as several images).

Step 5: Test with a real fetch

Why: you want to see what an app sees. The most reliable test is to use each platform's own link preview or debugging tool, or to paste the URL into the app. Also fetch the page as a crawler would, with the URL Inspection tool or a plain request, because pages that build their tags only with client-side JavaScript may show no tags to apps that do not run scripts. Put the tags in the delivered HTML.

How to confirm: the preview shows the title, description and image you set. If you changed the image or text, some platforms cache previews, so use the platform's debugger or "refresh" option, or add a new filename to the image.

Step 6: Add alt text and keep the image URL stable

Why: og:image:alt makes the preview accessible where the platform uses it. Keep the image URL stable between edits and replace the file contents only if the new version is meant to appear. If you rename the file, update the tag.

How to confirm: og:image:alt is present, describes the picture and does not repeat the title word for word.

Step 7: Monitor for broken images

Why: a share image that returns 404 produces a bare preview. Crawvix's Open Graph check looks at sampled pages for og:title, og:description, og:image and twitter:card, and also requests the og:image URL to confirm it loads and is an image (unless robots.txt disallows the path). Run a check after launches and image moves.

How to confirm: the og:image URL for each sampled page returns 200 with an image content type.

Your <title> and meta description still serve search results and browser tabs. The Open Graph title and description serve shared links, and they may be shorter or more conversational. Keep them honest and consistent with the page. If you want to understand how Google chooses a displayed title, read Why Google Rewrites Title Tags and How to Write Titles That Stick.

Final verification checklist

og:title, og:type, og:image and og:url are present on every shareable page.
og:description, og:site_name and og:image:alt are present.
twitter:card is present with the layout you chose.
The og:url matches the canonical URL.
The og:image URL is absolute, HTTPS, public and returns an image.
Each og: property appears once unless repetition is intended.
Tags are in the server-delivered HTML, not added only by script.
A real share or platform debugger shows the expected preview.

Common mistakes to avoid

Relative image URLs. Use a full https:// address.
A logo as the share image on every page. Use a representative picture where you can.
Two plugins writing the same tags. Keep one source of truth.
Tags added only by JavaScript. Some link preview bots may not run scripts. Put the tags in the delivered HTML so it does not matter.
A blocked or private image. If robots.txt, a login or a firewall blocks the file, previews fail.
Forgetting that previews are cached. After changing tags, refresh the cached preview in the platform's tool.
Mismatched og:url. It should be the canonical address, not a tracking or staging URL.

Frequently asked questions

Do Open Graph tags improve search rankings?

No. They control link previews in apps that read them. Google lists og:title and og:image among inputs it may use for title links and preferred images, but that does not make them a ranking signal.

Do I need both Open Graph and Twitter Card tags?

X's documentation says its reader falls back to Open Graph tags when Twitter-specific ones are missing, so Open Graph plus twitter:card is usually enough. Check X's current documentation for details.

The Open Graph protocol sets no size, and platforms differ. A landscape image of about 1200 by 630 pixels is a common starting point and is the size Crawvix's check suggests. Verify against the platforms you care about.

Why does the old image still appear?

The platform cached the earlier preview. Use its debugger or refresh tool, or publish the new image under a new file name.

Which og:type should I use?

Use website for the home page and general pages. Use article for articles, posts and guides. The protocol also defines types for music, video, books and profiles.

Does the description have to match the meta description?

No. It can differ, but it should describe the same page accurately.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.