How to Set og:url and Avoid Duplicate Social Link Previews

og:url should be the stable, absolute URL that represents the page. Put it in the HTML document head and make it agree with the URL identity your site intends visitors and crawlers to use. If tracking parameters, session IDs, alternate hostnames, or route variants all show the same content, do not give each a different Open Graph identity.

The Open Graph Protocol defines og:url as the canonical URL used as the object’s permanent ID in the graph. Its four required basic properties are og:title, og:type, og:image, and og:url. Open Graph Protocol documentation

1. Choose the page’s stable URL

Before editing metadata, determine the URL your site treats as the page’s public identity. Make an explicit choice for HTTPS, hostname, path casing, and trailing slash. Use a stable URL that is publicly accessible and does not include visitor-specific or campaign-specific parameters.

For example, if these URLs all serve the same article:

• https://www.example.com/guides/og-url/
• http://example.com/guides/og-url
• https://www.example.com/guides/og-url/?utm_source=newsletter

Choose the site’s intended representative URL, such as https://www.example.com/guides/og-url/, and use it consistently in the page’s Open Graph metadata. Do not copy that example literally; substitute the real, preferred URL for your page.

This choice should line up with your site’s canonicalization plan. Search canonicalization and social metadata are separate systems, but both should express the same intended page identity. Google describes canonicalization as selecting a representative URL among duplicates and identifies redirects and rel="canonical" annotations as signals it can use. Google Search Central: How to specify a canonical URL

2. Add Open Graph metadata to the HTML head

For a static page, place the tags in the document’s <head>. Replace the sample values with the page’s real title, type, image URL, and stable page URL:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>How to Set og:url</title>
  <link rel="canonical" href="https://www.example.com/guides/og-url/">
  <meta property="og:title" content="How to Set og:url">
  <meta property="og:type" content="article">
  <meta property="og:image" content="https://www.example.com/images/og-url-guide.jpg">
  <meta property="og:url" content="https://www.example.com/guides/og-url/">
</head>
<body>
  <h1>How to Set og:url</h1>
</body>
</html>

The Open Graph Protocol specifies the metadata in the document head. The canonical link shown here is a search canonicalization signal; it does not replace og:url. Keep both declarations aligned when they describe the same page.

Required properties and practical checks

Property	What to provide	Check
og:title	The page title for the social object.	Confirm the rendered value is the intended title, not a site-wide default.
og:type	The object’s type, such as article for an article page.	Use the value appropriate to the page.
og:image	An absolute URL to the image for the preview.	Confirm it is reachable and follows the target platform’s current image requirements.
og:url	The stable, absolute identity URL for the page.	Compare it with the intended canonical URL and redirect destination.

LinkedIn says pages should comply with Open Graph and also documents image requirements specific to LinkedIn. Check the current guidance for the platform where you are sharing instead of assuming one image rule applies everywhere. LinkedIn Help: Share articles or links

3. Check duplicate routes, canonical links, and redirects

1. List the URL forms that can serve this content: HTTP and HTTPS, www and non-www, slash and no-slash, query-string variants, and old routes.
2. Decide which one is the stable public identity based on your site’s URL policy.
3. Check that alternate forms resolve consistently. Where applicable, redirects should lead to the intended URL.
4. Check that the page’s canonical link points to the intended representative URL.
5. Check that og:url declares that same identity.

Do not add a different og:url for each tracking or session URL when the underlying content is the same. The protocol’s permanent-ID definition is the reason to keep one stable identity; this is implementation guidance derived from that definition. Google documents redirects and canonical annotations as signals in its own canonicalization process, but social platforms make their own decisions.

4. Inspect the HTML crawlers receive

Validate the publicly served response, not only the source template or browser DOM you expect to render. A CMS theme, SEO plugin, server-side rendering layer, client-side app, redirect, or cache can alter what a crawler receives.

1. Request the exact public URL and inspect the returned HTML head.
2. Confirm that the response contains one intended value for each basic Open Graph property, especially og:url.
3. Compare the declared value with the final URL after redirects and with the page’s canonical link.
4. Check that og:image is an absolute, publicly fetchable URL and meets the target platform’s image requirements.
5. Use the destination platform’s inspection tool when available, then re-fetch the page if the displayed preview looks inconsistent with the HTML.

A quick command-line check can fetch the page response for inspection:

curl -L --max-redirs 10 -sS -D response-headers.txt \
  -o page.html \
  https://www.example.com/guides/og-url/

# Inspect the saved HTML for the relevant declarations.
rg -n 'og:(title|type|image|url)|rel="canonical"' page.html

This checks the returned HTML and records response headers while following redirects. It does not guarantee that every social crawler receives the same response: access rules, user-agent handling, geographic routing, or application behavior may differ. If the crawler-facing output is in doubt, inspect the page with the platform’s current tool as well.

5. Refresh and validate the social preview

Once the served metadata is correct, use the target platform’s current preview inspection or refresh procedure if one is available. The Open Graph documentation links to Facebook’s Object Debugger. LinkedIn publishes its own sharing guidance. These tools can help inspect what a platform currently reads, but do not assume that an HTML change immediately replaces an already stored preview.

No universal cache lifetime or guaranteed refresh time is established by the sources for this guide. The steps and behavior are platform-specific, so check the platform’s current documentation and inspect again after correcting the page.

Common causes of duplicate or incorrect previews

Symptom	Likely cause	What to do
Sharing URLs with different query strings creates different-looking previews.	Variants are being treated as distinct objects, or the metadata changes based on the query.	Use the stable page identity in og:url for variants that represent the same content; inspect the served HTML for each variant.
The preview points to a different host or path.	The template or plugin emits a stale or incorrect absolute URL.	Inspect the response head and update the source that generates og:url.
The canonical link and og:url disagree.	Search and social metadata use inconsistent page identities.	Choose the intended representative URL and align both declarations if they refer to the same page.
Source view looks correct but the platform preview does not.	The public response, crawler access, rendering layer, or platform’s stored preview differs from what you inspected.	Fetch the final public URL, inspect its returned head, and use the platform’s current inspector or refresh procedure.
The preview image is missing or unsuitable.	The image URL cannot be fetched, is not absolute, or fails platform-specific requirements.	Verify public access to the image and consult the target platform’s current image guidance.
Fixing the tags does not immediately change an existing preview.	The platform may retain previously fetched data; refresh behavior varies.	Re-check the served metadata, then follow the platform-specific refresh steps. Do not rely on an assumed cache duration.

Performance, reliability, and cost considerations

og:url is a small HTML metadata declaration; the operational work is making sure every public route emits a consistent, crawler-accessible head. A static or server-rendered head makes the intended metadata directly visible in the returned HTML. With any rendering approach, verify the response a crawler can fetch rather than relying on a client-side view alone.

For reliability, include metadata generation in the page template or content system that owns the canonical route, and inspect representative URL variants after route, CMS, or SEO-plugin changes. Do not infer that a social preview has refreshed just because the HTML is correct: verify with the platform’s own current tooling.

There is no special infrastructure or per-request service cost required to add og:url; it is part of the page markup. If you need to inspect the actual rendered page or capture it for debugging, a screenshot can reveal what is visible after rendering, though it does not replace checking the HTML head for metadata.

Or skip the browser setup

If you also need a rendered screenshot while investigating what a page displays, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. It does not replace inspecting HTML metadata: use the response source or platform inspector to verify og:url.

cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://www.example.com/guides/og-url/ -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://www.example.com/guides/og-url/"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://www.example.com/guides/og-url/'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

See the ScreenshotNeo API documentation for request options. Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots; yearly billing gives two months free, and every feature is available on every plan. Sign up for 1,000 free screenshots a month, no card required.

FAQ

Does og:url redirect the visitor?

No. It is metadata that identifies the Open Graph object; it is not an HTTP redirect instruction.

Should og:url include campaign parameters?

If the parameters do not define a different page identity, use the stable URL without them. Verify the intended identity against your site’s URL policy.

Can one metadata setup guarantee the same preview on every platform?

No. Open Graph provides shared metadata conventions, while platforms can apply their own fetching, image, and refresh behavior. Check the current requirements and inspector for the platform you are targeting.

Will changing og:url immediately clear an old preview?

There is no universal refresh guarantee or cache duration established here. Correct and verify the public metadata, then use the platform’s current refresh process.