Canonical uses a relative URL
canonical_relativeShort answer
The canonical is written as /path instead of https://www.example.com/path. Google resolves it, but recommends absolute URLs: if a test or staging copy of the site is ever crawled, a relative canonical points at the staging host and declares the staging page canonical. Write the full URL.
Why it matters
Google's documentation lists relative canonicals under "avoid": they work until they don't. The failure mode is quiet — a staging site accidentally left crawlable, a CDN mirror, an http version still served — and in each case the relative canonical confirms the wrong host as the original.
How Glimana detects it
The rule fires when the canonical's href does not start with a scheme (https://); the evidence shows the value found.
How to fix it
- Find the affected pages in Glimana. Open Issues › Canonical uses a relative URL. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
SEO plugins output absolute canonicals; a relative one comes from a theme or a custom header snippet. Replace it with the plugin's output or use
home_url()to build the full address.{{ canonical_url }}is absolute. A relative value means a hard-coded template line; restore the Liquid variable.Prefix the canonical with the configured canonical origin:
https://www.example.com+ path. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the canonical is absolute. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the canonical is absolute.