Skip to content

Indexation & Canonicalization

Indexation checks answer the most fundamental SEO question: can search engines actually index this page, and if so, which URL are they indexing? VisibilityIQ audits six categories of indexation and canonicalization issues.

Every page runs this gauntlet. Fall out at any gate and the page won’t be indexed the way you intended:

flowchart TB
  P([Page]) --> RB{robots.txt<br/>allows crawl?}
  RB -->|no| NX[Not crawled]
  RB -->|yes| NI{noindex anywhere?<br/>meta · header · rendered DOM}
  NI -->|yes| OUT[Excluded from index]
  NI -->|no| CN{Canonical points to a<br/>valid 200 self or target?}
  CN -->|no| RISK[Canonical finding —<br/>Google may pick its own]
  CN -->|yes| IDX([Indexable as<br/>the canonical URL])

A page can be blocked from indexation in multiple ways at once — and they can contradict each other. VisibilityIQ checks:

  • <meta name="robots" content="noindex"> in raw HTML
  • <meta name="robots" content="noindex"> in the rendered DOM (may differ from raw)
  • X-Robots-Tag: noindex HTTP response header
  • robots.txt blocking the page (prevents crawling, not indexation — but has the same effect)

Conflict example: A page has noindex in its raw HTML but the rendered DOM removes it (via JavaScript). Googlebot, which renders pages, will index the page. A raw-only crawler would report it as noindexed. VisibilityIQ catches this mismatch as a render-parity finding.

Severity: Critical when a noindex on an important page is unintentional. High when noindex/index directives conflict across sources.

The canonical tag tells search engines which URL is the “master” version of a page. Common problems:

  • Self-canonical missing — no canonical tag at all on a page that should have one
  • Canonical to redirect target — the canonical points to a URL that redirects elsewhere
  • Canonical to non-200 page — the canonical points to a URL returning 4xx or 5xx
  • Canonical loop — page A canonicalizes to page B, which canonicalizes back to A
  • Canonical chain — page A → page B → page C (Google follows chains but may not choose the end)
  • Cross-domain canonical — the canonical points to a different domain (sometimes intentional, often not)
  • Raw vs rendered mismatch — the canonical in raw HTML differs from the one in the rendered DOM

Each of these generates a separate finding with the exact canonical values observed, where they were found, and what the correct canonical should be.

If your site is accessible at both http:// and https://, or at both www.example.com and example.com, search engines may treat them as separate URLs. VisibilityIQ flags:

  • HTTP URLs returning 200 instead of redirecting to HTTPS
  • Non-www URLs returning 200 instead of redirecting to www (or vice versa)
  • Inconsistent canonical usage across protocol/subdomain variants

A soft 404 is a page that returns HTTP 200 but has the content of an error page (e.g., “Page not found” in the body, a thin template with no real content). Search engines eventually learn to treat these as 404s, but it wastes crawl budget and can dilute your site’s quality signals.

VisibilityIQ detects soft 404 candidates by looking for:

  • Very low word count on a 200-response page
  • Error-like patterns in the page title or heading
  • Boilerplate-only content with no unique body text

Findings are marked with Medium severity and Medium confidence since soft 404 detection involves heuristics.

When multiple URLs serve substantially the same content, search engines have to guess which one to rank. VisibilityIQ identifies duplicate clusters by comparing content hashes across crawled pages. A cluster finding shows all URLs in the group and which one (if any) has a self-canonical.

If you have Google Search Console connected, VisibilityIQ compares its crawl-detected canonical with the canonical Google has actually selected. Discrepancies — where Google chose a different canonical than the one you declared — are flagged as high-priority findings because they indicate Google is overriding your intent, usually because of a signal you’re sending that you didn’t mean to.

Every indexation finding includes:

  • The exact directive or tag that caused the issue
  • What VisibilityIQ recommends it should be
  • A generated fix (e.g., the corrected canonical tag to paste into your <head>) where applicable
  • Verification steps to confirm the fix is working