Page is noindex and also canonicalised to an indexable URL
noindex_canonicalisedShort answer
The page says "don't index me" and "I am a copy of that other page". Google's John Mueller has said the two should not be mixed: they contradict, and Google picks one — usually the canonical. If this page is a duplicate, drop the noindex. If it should stay out of search, drop the canonical (or make it self-referencing).
Why it matters
The two directives send signals in different directions. A canonical says "pass my signals to that URL"; a noindex says "I should not be a search result". Google tends to resolve the conflict by trusting the canonical and may even ignore the noindex — which surprises people who used the pair to hide a page. Clear signals are faster and more predictable.
How Glimana detects it
The rule fires for a 200 HTML page that carries noindex (meta or header) and a canonical to a different URL that Glimana crawled and found indexable. If the target was not crawled or is itself noindex, nothing is reported.
How to fix it
- Find the affected pages in Glimana. Open Issues › Page is noindex and also canonicalised to an indexable 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 add noindex and a self-canonical for things like tag pages; the conflict appears when someone also filled the Canonical URL field. Clear the field, or remove noindex if the page is meant to consolidate into the target.
Usually from an app that both hides a page and rewrites its canonical. Use one of the two features.
Treat noindex and non-self canonical as mutually exclusive in the template logic.
-
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 page no longer carries both signals. 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 after marking the task done; the task closes when the page no longer carries both signals.