Open Graph Tags for Useful Link Previews

Open Graph tags describe the title, image, and URL a social platform can use when someone shares a page. Put them in the HTML <head> returned by the server, with values generated from the page’s own content.

A useful starting point is one consistent set of tags:

<meta property="og:title" content="Building a Small Static Website">
<meta property="og:description" content="A practical guide to content, templates, and deploying a small static site.">
<meta property="og:type" content="article">
<meta property="og:url" content="https://example.com/articles/static-website/">
<meta property="og:image" content="https://example.com/images/static-website-card.png">

Replace both example URLs with public addresses you control. The image must exist; a plausible filename in a template is not enough to create a preview.

Give the essential Open Graph tags consistent values

The Open Graph protocol defines four required properties: og:title, og:type, og:image, and og:url. A description is a useful addition, although it is not one of those four.

Choose article for an article and website for a general site page. Do not copy the article type into every utility page simply because it appeared in an example.

The <title>, ordinary meta description, canonical link, and Open Graph tags have different jobs. They should agree about the page rather than advertise slightly different versions of it.

Add image details when you know them

A preview image can have structured properties immediately after its og:image tag:

<meta property="og:image" content="https://example.com/images/static-website-card.png">
<meta property="og:image:type" content="image/png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A Markdown article beside its rendered website.">

Those dimensions describe this example asset. They are not a promise that every platform uses the same crop or accepts exactly the same presentation.

The protocol also defines og:image:secure_url for an alternative HTTPS image URL. If the main image URL already uses HTTPS, do not invent another asset merely to populate the optional field.

Use actual image metadata when generating width, height, and type. An image replaced by a different shape should not retain dimensions copied from the previous file.

For an article card, I prefer a composition that survives losing a little space at its edges. Small text and important details tight against the crop are harder to keep useful across previews.

Keep page identity separate from campaign tracking

The shared object needs a stable URL. If a visitor arrives through a tagged campaign link, the metadata should still identify the article’s canonical address.

That keeps the preview tied to the content rather than to a particular newsletter or advertising link. The canonical URL article explains the search-engine side of that distinction.

Use the same normalized address consistently: the intended scheme, hostname, path, and trailing-slash convention. The point is to make the page’s identity explicit before a sharing platform has to infer it.

Add site, language, and article context deliberately

The protocol provides optional fields for the site and locale:

<meta property="og:site_name" content="Example Developer Blog">
<meta property="og:locale" content="en_US">
<meta property="article:published_time" content="2026-10-01T09:00:00+03:00">
<meta property="article:modified_time" content="2026-10-28T10:00:00+02:00">

These dates are illustrative. Generate them from the actual publication and substantial update dates; do not use the build time as an article’s modification date.

Keep locale consistent with the page’s language. An English default copied into a Latvian article describes the wrong content, even if the rest of the tags are correct.

A second og:image can represent an intentional alternative. The protocol gives the first value preference when several values conflict, so accidental duplicates from a theme and plugin are worth investigating.

Inspect the returned HTML before blaming the preview

Use the public article URL in a request that retrieves its HTML:

curl -sSL https://ronaldsvilcins.com/2024/03/23/open-graph-meta-tags/ -o /tmp/shared-page.html

Open the downloaded file as source and look inside <head>. Check the actual values, rather than only inspecting a DOM that client-side JavaScript may have changed.

If the description contains an ampersand or quotation marks, let the template system escape it for an HTML attribute. Hand-built strings can turn a readable title into malformed metadata.

Then inspect the image URL separately. It should return the intended image, not a login page, a missing-file response, or an HTML document at an image-looking path.

Diagnose the preview that is actually wrong

For a missing image, start with the returned og:image value and whether the asset is publicly accessible. For an unexpected title, look for competing tags and the URL that was shared.

When a preview looks older than the source, check the platform’s own inspection tools. Facebook’s Sharing Debugger and LinkedIn’s Post Inspector are entry points for investigating what those services see. Their access requirements and refresh behavior belong to the platform.

A corrected page and an existing shared preview are separate things to inspect. Do not promise a universal refresh interval or assume one platform’s check updates every other service.

Generate the tags from the same page data used by the title and description elsewhere. Keep one template responsible for each set of tags, then inspect the published output after changing it.

← Back to all articles