Fixing og:url and Canonical Mismatches

What og:url actually does

In the Open Graph protocol, og:url is one of the four required properties, described as the canonical URL of the object, the address that will be used as its permanent ID. Two things follow from that description, and both explain why a wrong value causes trouble.

• It is an identity, not a label. Platforms that count shares, reactions or comments against a link can attach them to the og:url value rather than to whatever address was pasted. If ten versions of a page all declare the same og:url, their activity is pooled. If each declares itself, it is split.
• It can redirect the scraper. Facebook in particular treats og:url as a pointer. When the value names a different address, its crawler fetches that address and builds the card from the tags it finds there. This is why an og:url set to the home page on every page makes every shared link show the home page card.

The rel="canonical" link does the equivalent job for search engines. Google does not document og:url as a canonical signal, so a mismatch will not directly change which page Google indexes. The problem is that the two tags disagreeing means someone has made two decisions about the page's main address, and at least one of them is wrong.

The patterns that go wrong

Why tracking parameters matter here

Links in emails, adverts and social posts pick up parameters such as utm_source, gclid and fbclid. If the template echoes the request address into og:url, each campaign produces a new identity for the same page. Platforms may then cache a separate card for each, and a later fix to one does not fix the others.

Why the home page value is the worst case

Every other pattern splits or muddles a page's identity. The home page pattern replaces it. Sharing a product, a blog post or a job advert shows the home page title, description and image, and anyone reading the card has no idea what the link is about.

Checking what your pages declare

The OG / Twitter Tag Generator reports a missing or invalid og:url. To see how it compares with the canonical, fetch the raw HTML and pull out both values.

URL="https://www.example.co.uk/shop/walking-boots?utm_source=test&fbclid=abc123"
curl -sL "$URL" | grep -oiE '(property="og:url"|rel="canonical")[^>]*'

Deliberately add fake tracking parameters, as above. A correct page returns the clean address in both tags, with none of the parameters. If either tag echoes utm_source or fbclid, the template is using the request address.

Test several page types

Run the same check against the home page, a deep content page, a product with a variant selected, a paginated listing and a page reached with and without a trailing slash. Write down both values for each. Differences usually cluster by template, which points to the file to change.

Use a platform's view of it

Facebook's Sharing Debugger lists the canonical address it settled on and any redirect path it followed. If it reports a different address from the one you entered, the page's og:url (or a redirect) sent it there. That is a quick way to confirm the home page pattern without reading any markup.

Building one clean address

The reliable fix is to compute the page's address once, in one function, and print it into every tag that needs it. Deciding the rules takes five minutes; writing them down stops future drift.

1. Scheme: always https.
2. Host: one form, with or without www, matching your redirects.
3. Path: the page's own path, lower-case if your server treats case as significant, with one trailing-slash convention used site-wide.
4. Query string: removed by default. Keep only parameters that genuinely change the content and that you also keep in the canonical, such as a product variant if variants have their own pages.
5. Fragment: always removed; nothing after a # is sent to the server anyway.

A small example in PHP

<?php
function page_address(string $path): string {
    $base = 'https://www.example.co.uk';
    $path = '/' . trim(parse_url($path, PHP_URL_PATH) ?? '', '/');
    return $path === '/' ? $base . '/' : $base . $path;
}
$address = page_address($_SERVER['REQUEST_URI']);
?>
<link rel="canonical" href="<?= htmlspecialchars($address) ?>">
<meta property="og:url" content="<?= htmlspecialchars($address) ?>">

The function throws away the query string and fragment, fixes the scheme and host, and removes trailing slashes except on the home page. The exact rules can differ on your site; what matters is that one function decides and both tags use it. In a CMS, the equivalent is a single field or setting that feeds both.

The fix, step by step

Platform notes

WordPress

Yoast SEO and Rank Math both derive og:url from the canonical address they calculate, so if you set a custom canonical on a post, the share address follows it. A mismatch on a WordPress site usually means a second source: a theme with its own Open Graph output, a social sharing plugin, or code in functions.php that hard-codes a value. Turn the extra source off rather than trying to make two outputs agree. Plugin settings are covered in Open Graph in WordPress.

Shopify

Liquid provides a canonical_url object that already strips most parameters. Themes that use {{ canonical_url }} in both the canonical link and og:url are consistent by default. Problems appear when a customised snippet uses {{ request.path }} or builds the address from shop.url and a handle, which can produce a different form for collection-scoped product addresses.

Next.js and similar frameworks

In the App Router Metadata API, set metadataBase once in the root layout, then give each route alternates.canonical and openGraph.url from the same relative path. Relative values are resolved against metadataBase, so both become full addresses from one setting.

export async function generateMetadata({ params }) {
  const path = `/shop/${params.slug}`;
  return {
    alternates: { canonical: path },
    openGraph: { url: path, type: 'website' },
  };
}

Static site generators

Hugo's .Permalink, Eleventy's page.url combined with a site base, and Jekyll's page.url | absolute_url all give a stable address from configuration. Use the same expression in both tags and set the production base URL in the build configuration rather than in individual templates.

Harder cases

• Syndicated or duplicated content. If an article also appears on a partner's site with a canonical back to yours, their og:url may also name your address. That pools shares on your page, which is usually what both sides want, but agree it in writing.
• Campaign landing pages that should stay separate. If a landing page deliberately differs from the main page, give it its own address in both tags. Do not point its og:url at the main page while showing different content, because the card and the page will not match.
• Moved pages. After a URL change, update the tags on the new page to name the new address. The old address should redirect; do not leave an og:url on the new page that still names the old one to keep share counts, because the old address no longer serves the page directly.
• Encoded characters. Paths with spaces or non-ASCII letters should be percent-encoded consistently. caf%C3%A9 and café can be treated as different addresses by some readers.
• Language subfolders. A French page at /fr/ should name itself in both tags. The connection to the English version belongs in hreflang and og:locale:alternate, covered in fixing og:locale issues.

Keeping it consistent

• One helper, used everywhere. Any new template that needs an address should call the same function. Code review should reject a template that assembles its own.
• An automated check. A test that fetches a few addresses with fake tracking parameters and fails when og:url differs from the canonical, or contains a parameter, catches regressions immediately.
• Environment-specific configuration. Keep the base URL in environment configuration and check it is the live domain on production after every deployment.
• Treat address changes as migrations. Changing trailing-slash policy or the www host changes every og:url at once. Plan redirects and expect platforms to build new cards.

For how the canonical tag itself should be set, see fixing canonical tags, and for www and non-www consistency, fixing www canonicalisation.