og:url¶
Wygard watches the content of the <meta property="og:url"> tag and alerts you when the canonical URL your pages declare to social platforms changes.
| Scope | Tier | Default | Alert |
|---|---|---|---|
| Per URL | Basic | Off — enable via the OG group | 🟠 Heads-up |
Why it matters¶
og:url is the canonical address a page hands to social platforms and chat apps. Like the Canonical tag does for search, it tells them which URL to attribute shares, likes, and engagement counts to. When it silently changes — echoing a tracking parameter, pointing at staging, or dropping entirely — social engagement fragments across URLs and previews may resolve to the wrong page.
The default severity is Heads-up. The test is off by default and belongs to the OG selection group.
What Wygard checks¶
On every run, the crawler:
- Fetches the monitored URL.
- Extracts the
contentattribute of<meta property="og:url">from the<head>. - Compares the found value against the stored desired value.
Common alerts¶
- og:url changed — the tag now points at a different URL than the baseline.
- og:url not found — the tag was removed, so platforms attribute shares to whatever URL was pasted.
- Multiple og:url tags — more than one was detected; scrapers pick one unpredictably.
Responding to an alert¶
- Open the alert and review the diff — Wygard shows the previous value and the new one.
- Decide whether the change was intended (a consolidated URL) or accidental (a template echoing query parameters, a staging URL leaking to production).
- If intended, click Set found value as desired to adopt the new URL as the baseline.
- If accidental, fix the template so
og:urlalways declares the clean canonical address, and let the next crawl turn the test green.
Pair it with Canonical
og:url is the social equivalent of the Canonical tag — both should point at the same clean URL. When one drifts to include a tracking parameter, the other usually does too, so watching them together catches the whole regression.