Indexing signals go to the wrong page
A changed canonical hands the authority you built to a URL you did not choose. Organic traffic can fall away without a single visible error.
Canonical tag monitoring
Danger
A canonical pointing at the wrong URL deindexes a page quietly
The canonical tag tells search engines which URL is the authoritative one. A CMS update, a new plugin or a botched deploy can redirect that signal somewhere else — and the page still loads, still looks fine.
Danger severity: you get the alert within the hour, not in tomorrow's digest.
What it may cost you
The damage is impossible to see from the site itself, which is why it runs for weeks.
Parameters split one page into thousands
A template that rebuilds the canonical from the served URL turns every campaign link and filter combination into its own near-duplicate.
Two canonicals is worse than none
When more than one tag is present, search engines pick one — often not the one the template author intended, and never predictably.
How an alert reaches you
Three steps, running every day, on something nobody looks at twice a year.
1
Every run
Baseline stored
The first crawl saves the canonical href on each monitored URL as it should be. That value is what every later run is compared against.
2
Next morning
Change detected
The href of <link rel="canonical"> is extracted and compared, checking there is exactly one of it.
3
Within the hour
Alert in your inbox
Danger-level findings go out right after the crawl batch. Milder ones wait for the daily digest, so the urgent one stands out.
You decide what counts as broken
The stored value is your desired state, not a guess. When a later run differs you get both versions side by side — and if the change was intentional, one click adopts it as the new baseline.
Severity matches the damage
This one reaches you within the hour, because the damage starts before the next digest would arrive. Every test's severity can be overridden per site, so your inbox stays useful.
Set it once, then leave it
Pick the frequency and the user agent Wygard should send, switch on JS rendering if your pages need it, and the rest needs no attention.
What we check
Two checks: the canonical as served, and the parametrized case that catches CMSes rebuilding it from the request.
| Test | What it catches | Scope | Severity |
|---|---|---|---|
| Canonical | The href changed, the tag was removed, or more than one canonical was found. |
URL · Basic | Danger |
| Self-canonical | Wygard appends a harmless query parameter and checks the canonical still points at the clean URL. | URL · Basic | Danger |
Questions about canonical tag monitoring
What the checks do, and what they don’t.
Why do I need the self-canonical test as well
The standard test watches the URL as served. Self-canonical catches templates that rebuild the canonical to include query parameters — common on parametrized e-commerce pages, and invisible otherwise.
Is self-canonical on by default
No, it is opt-in per URL. Enable it on pages that receive tracked or filtered traffic.
What if I consolidated two URLs on purpose
Open the alert, check the diff, and use Set found value as desired to adopt the new canonical as the baseline.
“This app has completely transformed how we manage our SEO. The real-time alerts ensure we never miss an issue. It's a game-changer for protecting our rankings!”
Why Wygard?
Trust, but verify. You build the site — Wygard makes sure your key SEO elements work as intended.
Your SEO protected
How quickly would you notice if your canonical tags changed? We catch it for you.
Time saved
Don't waste time on massive crawls and endless data. With 15 years of hands-on SEO experience, we know how to focus on what really matters.
Easy to Use
You don't have to be an SEO expert — your site still deserves expert monitoring. That's exactly what our tool delivers.
Single site or the whole portfolio? We can handle all today
Every online business deserves protection. No matter the size.