How to Set Open Graph Tags for an HTML Email Landing Page
Add Open Graph metadata to the web page linked from your email, then publish and check its social preview. Here is the HTML, builder workflow, and troubleshooting guide.
Put Open Graph (OG) tags in the <head> of the published web landing page that your email links to. The tags help services that fetch a webpage URL build a social preview. They do not belong in the email body as a way to control that preview. The Open Email Standards documentation describes social metadata such as Open Graph as irrelevant to email clients; treat that as its guidance, since behavior is not established here as universal.
1. Add the required Open Graph tags
The Open Graph protocol specifies four required properties: og:title, og:type, og:image, and og:url. For a typical marketing landing page, use website for the type. The protocol describes og:description as optional and generally recommended.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Spring offer</title>
<meta property="og:title" content="Spring offer">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/spring-offer/">
<meta property="og:image" content="https://example.com/images/spring-offer-share.jpg">
<meta property="og:description" content="Explore the spring offer and see what's included.">
</head>
<body>
<main>
<h1>Spring offer</h1>
<p>Landing-page content goes here.</p>
</main>
</body>
</html>Replace the example values with the actual page title, canonical public URL, concise description, and a publicly reachable image URL. Use absolute URLs so a service fetching the page can resolve the image and page address. Keep the metadata consistent with the visible landing-page content.
Optional site, locale, and image metadata
The protocol also documents og:site_name and og:locale. It supports image properties including dimensions, MIME type, and alt text. Include image alt text to describe the image to people who cannot see it.
<meta property="og:site_name" content="Example Store">
<meta property="og:locale" content="en_US">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:alt" content="Products included in the spring offer">Only state image dimensions and type when they match the actual file. These tags describe the image; they do not resize or convert it.
2. Put metadata in a valid document head
Place these elements inside the page’s real <head>, before </head>. Google identifies <head> as the primary location for page metadata and warns that an invalid element there can cause it to ignore following elements. Its valid-element list includes title, meta, link, script, style, base, noscript, and template.
A common source of confusion is adding tags to the email template rather than the destination page template. The email’s link target is the URL social services will fetch when creating a preview; the email body is a separate document.
Prevent duplicate or conflicting metadata
Check the rendered page source for existing tags generated by a theme, CMS, or SEO plugin. The Open Graph protocol permits repeated meta elements and says the first value in document order wins when values conflict. In routine setups, keep one intentional value per property to avoid a template and plugin supplying different titles, images, or URLs.
3. Configure a landing-page builder
In Unbounce’s Classic Builder, its documented route is Page Properties → Open Graph Meta Data. Choose the content type, enter the title and description, provide the image URL and page URL, save, and republish. The same guide describes adding metadata in the page head. Builder interfaces can change, so use these as Unbounce-specific directions rather than steps that apply to every builder. See Unbounce’s Open Graph setup guide.
The Unbounce guide suggests an image at least 600 × 315 pixels and recommends 1200 × 630 pixels for display across many social networks on high-resolution devices. These are vendor recommendations, not requirements of the Open Graph protocol. Check the current guidance for the platform where the link will appear when exact rendering matters.
4. Publish and inspect the public preview
- Save the metadata in the destination page’s settings or source.
- Publish or republish the landing page.
- Open the public landing-page URL and inspect its source or rendered head to confirm the new tags are present.
- Use the target platform’s preview or debugging tool to request the URL and inspect the resulting title, description, and image.
- If the platform shows old information, request a fresh scrape or cache refresh using its available tool, then check again.
A previously shared URL may continue to show cached metadata. Unbounce’s guide mentions Facebook’s debugging tool and LinkedIn and X/Twitter refresh tools; platform tools and cache behavior can change. Confirm the page itself is correct before treating a stale preview as an HTML problem. See the Open Graph protocol and Unbounce guide.
5. Keep email markup and landing-page metadata separate
If by “HTML email landing page” you mean the destination page linked in an email, add OG metadata to that webpage. If you mean the email message itself, OG tags are not a substitute for email-specific markup or message headers. Open Email Standards’ documentation calls social and SEO tags irrelevant for email clients. The direct answer is therefore to set metadata on the public landing page and separately follow the requirements for the email message.
6. Troubleshoot common preview problems
| Symptom | Likely cause | What to check or fix |
|---|---|---|
| Preview uses the wrong title, image, or URL | A duplicate tag, plugin, or template supplies another value; some crawlers may use the first duplicate. | Inspect the final page source and remove unintended duplicates. Confirm the canonical public URL and image in the OG tags. |
| Preview has no image | The image URL may not be publicly reachable, may point to the wrong asset, or may not match the declared type or dimensions. | Open the exact absolute image URL publicly, verify it serves the intended image, and correct any optional image metadata that does not match. |
| Changes do not appear after editing | The page was not republished, or the platform has a cached scrape. | Republish, confirm the live page source, then request a refresh through the relevant platform tool. |
| Tags are present in the editor but absent from the live page | The builder setting may not have been saved or published, or tags were added to the wrong document. | Check the published destination page, not only the editor and not the email HTML. |
| Later metadata seems ignored | An invalid element in the document head can interfere with how metadata is processed. | Keep the head valid and place metadata in the head using supported elements. |
7. Check a page visually with a screenshot
After confirming the metadata, inspect the landing page itself at the public URL. A screenshot can help catch a broken hero image, blank page, or popup that is not apparent from the tags. ScreenshotNeo is a website screenshot API and MCP server for developers, made by Yorker Media. Its captures can remove cookie and consent banners, newsletter popups, and chat widgets before capture; each step can be turned off. The service reports page verdict and billing status in response headers.
Or skip the browser setup
Use a single GET request to capture the page:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/spring-offer/ -o landing-page.webpSee the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are never billed; response headers say which outcome occurred. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000 shots. Learn about ScreenshotNeo or sign up for 1,000 free screenshots a month, no card required.
Performance, reliability, and cost notes
Open Graph tags are small metadata elements; the main practical checks are whether the published page and image can be fetched and whether a platform is showing a cached scrape. The protocol does not guarantee identical rendering across platforms. For exact output, inspect each target platform’s current preview behavior and image guidance.
ScreenshotNeo offers caching with a TTL you choose, async capture jobs with signed webhooks, bulk capture for up to 100 URLs per call, and a usage API. Its plans are Free: 1,000 shots/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; and Business: $249 for 1,000,000. Yearly billing gives two months free, and every feature is available on every plan. Only clean shots are billed; unsuccessful outcomes and cache hits cost nothing.
FAQ
Do I need Open Graph tags for an email to work?
No. These tags describe the linked webpage for social previews; they are separate from sending and rendering the email.
Can I use the email’s URL as og:url?
Use the canonical public URL of the landing page itself, not the email message or a tracking URL unless that is intentionally the page’s canonical address.
Does og:description have to be present?
The protocol describes it as optional, but it is generally recommended to provide a useful summary.
Will every platform show the exact tags I set?
Not necessarily. Platforms may cache or render previews differently, so validate on the service where the link will be shared.
