OG URL and canonical: when the share names a different page

The arrival URL, document, and share object have different jobs

A newsletter can link to a tracked address without creating a new article. The incoming request records how the visitor arrived; the head identifies the article. Keep those purposes separate in the page template.

Google describes redirects, canonical annotations, and sitemap inclusion as canonicalization methods. To find the URL Google selected, read indexed URL Inspection. The social metadata warning only compares declarations.

One guide, two conflicting identities

In this authored fixture, a visitor opens https://example.com/guides/ceramic-mugs?utm_source=newsletter. The production server returns the complete guide with a 200 response. The search template knows the clean production address, but the share template still reads a preview-host setting.

Changing the newsletter link would leave the stale host in every later share until the publishing origin and route source in that template are corrected. Confirm that the declared destination serves the same guide.

<link rel="canonical"
      href="https://example.com/guides/ceramic-mugs">
<meta property="og:url"
      content="https://preview.example.com/guides/ceramic-mugs?utm_source=newsletter">

<link rel="canonical"
      href="https://example.com/guides/ceramic-mugs">
<meta property="og:url"
      content="https://example.com/guides/ceramic-mugs">
<meta property="og:type" content="article">
<meta property="og:title" content="Choosing a ceramic mug">
<meta property="og:image"
      content="https://example.com/images/ceramic-mugs.jpg">

The cause of the mismatch determines the repair

Use the actual final response to select the case. Do not lowercase paths, delete every query parameter or force every page to the homepage merely to satisfy a comparison. A URL scheme and host policy can be shared across the site; page identity still belongs to the document.

The canonical relation is intended for duplicate content or a representative containing that content. Two different products with different prices and capacities do not become duplicates because they share a template. RFC 6596 describes that relationship.

Campaign attribution doesn’t require a new object

In the mug-guide fixture, ?utm_source=newsletter changes attribution only. The guide’s title, body and product recommendations stay the same. The request can retain that parameter while canonical and og:url use the clean guide address. Neither metadata declaration edits the browser’s address bar.

Generate the two metadata values from the maintained document record, using the public origin and route. A request-derived host can leak a preview hostname into production metadata; a raw request URL can put every campaign token into the object identity. Fix that source once rather than adding a second tag later with JavaScript.

If a query changes language, product configuration or a useful filtered collection, assess that representation first. Removing a parameter is a publishing decision when the parameter changes what readers receive. The canonical identity study follows the same principle across a person’s documents and profiles.

A paginated archive can share the series while indexing each page

Consider /journal/page/2/. Its search canonical can stay /journal/page/2/ because it lists different articles from /journal/. A publisher might use /journal/ as the social object when a share promotes the collection. Yoast’s support response describes that intentional behavior for paginated archives.

Keep the share title, description and destination consistent with that collection-level choice. If the intended share is specifically “Journal, page 2,” use its page-specific identity instead. A collection-level choice should not silently replace the identity of each individual article.

Page 2 still needs its own search canonical under Google’s pagination guidance. Matching it to page 1 just to agree with a collection share would erase the item distinction shown in the pagination example.

Every declaration counts in the browser

At /guide, a redirect leads to /research/guide. The server’s canonical names the new URL, its og:url still names /guide, and a client component adds another canonical containing a campaign query. These illustrative fixtures distinguish the response from the browser state.

Run the console expression after the application finishes setting metadata. Save its arrays beside the HTTP response and Link header; counting every declaration catches duplicate tags even when their targets agree.

<!-- Raw head at the final 200 response -->
<link rel="canonical" href="https://example.com/research/guide">
<meta property="og:url" content="https://example.com/guide">

<!-- Additional tag inserted into the rendered head -->
<link rel="canonical"
      href="https://example.com/research/guide?campaign=social">

<link rel="canonical" href="https://example.com/research/guide">
<meta property="og:url" content="https://example.com/research/guide">

({
  finalUrl: location.href,
  canonical: [...document.head.querySelectorAll('link[rel~="canonical"]')]
    .map(node => node.getAttribute("href")),
  openGraph: [...document.head.querySelectorAll('meta[property="og:url"]')]
    .map(node => node.getAttribute("content"))
});

The served head and the refreshed share are two observations

Start with the hub’s capture checklist: requested address, redirect hops, final response, HTTP headers, initial HTML and rendered head. Compare the exact canonical and og:url values beside the content each URL serves.

For the repaired fixture, the production response should contain one canonical link and one og:url naming the clean guide. Inspect the HTTP Link header too: a correct HTML pair can coexist with a contradictory server declaration. Use the multiple canonical tags diagnosis when those layers disagree.

Repeat the capture on the clean guide and its newsletter variant. Confirm that public visitors can open the declared URL and image. Then inspect the URL with the relevant platform’s sharing tool, such as LinkedIn Post Inspector. Correct the live raw response before requesting a fresh platform capture; a changed browser DOM alone does not establish what that platform received.

The current response can be repaired while an older preview remains visible. Inspect the card after the platform refreshes it. I would accept the repair when the document identity is right in the served head and the share presents the intended page.