Skip to content
SEOWofSEOWof
Book an inspection
Browse the standard

Standard SW-1:2026.2 · Category 2 of 9

Indexation & Canonicals

Indexation faults are the most commonly mis-diagnosed problems in SEO, because the symptom (traffic loss) looks identical to a ranking problem. This category inspects what is actually eligible to appear, whether duplicates are consolidated correctly, and whether the index contains pages that dilute rather than earn.

Weight
16 / 100
Checks
7
Pass-blocking
3
WOF analogue
Registration & plates
IX-01Critical failweight 4measured

No accidental noindex on indexable pages

Is any page you want indexed carrying a noindex directive?

Pass, advisory and fail criteria for IX-01
PassNo URL that is sitemap-listed, navigation-linked or impression-earning carries noindex from any source.
Advisorynoindex present on pages that should legitimately be excluded but which are still listed in the XML sitemap.
FailAny commercially important page carries noindex via meta tag, header, or a directive injected after render.

Why it matters

A noindex directive removes a page from results entirely, and it is applied accidentally with remarkable frequency: a staging flag promoted to production, a CMS "hide from search" toggle, an SEO plugin default for a new post type, or a header set at the CDN. Because the page still loads perfectly for humans, the fault is invisible until traffic disappears — and the median time to detection is measured in months.

How we inspect it

For every URL we read the meta robots tag from the rendered DOM and the X-Robots-Tag from response headers, then reconcile them — the most restrictive directive wins. We flag any URL carrying noindex that also appears in the sitemap, receives internal links from navigation, or has recorded search impressions.

Source: Meta robots tag + X-Robots-Tag header inspection on every crawled URL

Remedy

  1. 1Identify the injection point for every affected URL: HTML source, response header, or client-side script.
  2. 2Remove the directive at source rather than overriding it downstream, so it cannot reappear.
  3. 3Audit CMS-level defaults for each post type, taxonomy and template.
  4. 4Check the CDN or reverse proxy for a blanket X-Robots-Tag left over from a staging configuration.
  5. 5Add an automated production test asserting that key templates never emit noindex.

Verification

Recheck re-reads meta tags and headers on every affected URL and confirms all target pages are indexable.

Usually fixed by
Developer
Effort
Small · 0.5–2 hrs
Est. impact
high
Typical cost
NZ$80–240
IX-02Major failweight 3measured

Canonical tags are self-referencing and consistent

Does every indexable page declare a correct, absolute, self-referencing canonical?

Pass, advisory and fail criteria for IX-02
PassEvery indexable URL declares exactly one absolute self-referencing canonical; every duplicate points to a live canonical target.
AdvisoryCanonicals correct but expressed as relative URLs, or duplicated identically in head and header.
FailCanonical chains, loops, multiple conflicting canonicals, canonicals to 3xx/4xx/noindex URLs, or a site-wide canonical to the homepage.

Why it matters

The canonical tag is how you tell a search engine which URL to keep when several serve the same content. Handled badly it does severe damage: a site-wide canonical to the homepage — a genuinely common template error — instructs the search engine to drop every other page from the index. Canonical chains are resolved unpredictably, and a canonical to a noindex page can propagate that exclusion to the original.

How we inspect it

We extract the canonical from the rendered head of every URL and resolve the canonical graph, flagging chains, loops, cross-host targets, relative URLs, multiple conflicting elements, and canonicals pointing at non-200 or noindex destinations.

Source: Canonical link element extraction and graph resolution

Remedy

  1. 1Emit an absolute self-referencing canonical on every indexable template, generated from the routing layer rather than hand-authored.
  2. 2Ensure parameterised, paginated and session variants canonicalise to the correct parent, not to the homepage.
  3. 3Never point a canonical at a URL that redirects, 404s or carries noindex.
  4. 4Remove duplicate canonical elements — conflicting signals cause the tag to be ignored entirely.
  5. 5Keep canonical, sitemap inclusion and internal link targets driven by the same single source of truth.

Verification

Recheck re-resolves the canonical graph and confirms no chains, loops or invalid targets remain.

Usually fixed by
Developer
Effort
Medium · 2–8 hrs
Est. impact
high
Typical cost
NZ$240–640
IX-03Major failweight 3measured

Important pages are actually indexed

What percentage of your commercially important pages are in the index?

Pass, advisory and fail criteria for IX-03
Pass95% or more of sitemap-listed canonical URLs are indexed.
Advisory85–95% indexed with no single exclusion reason dominating.
FailBelow 85% indexed, or any exclusion reason affecting more than 10% of important URLs.

Why it matters

Indexation is the pass/fail gate that sits before every other SEO consideration. "Crawled – currently not indexed" and "Discovered – currently not indexed" at scale are usually quality or architecture judgements rather than technical faults, which means the remedy is consolidation and internal linking, not resubmission. Diagnosing which exclusion reason applies is the difference between a fix that works and a year of resubmitting URLs.

How we inspect it

Where Search Console is connected we read indexed status and exclusion reason per URL directly. Where it is not, we derive an indexation estimate by comparing sitemap-listed canonical URLs against those with recorded impressions, and record the result as derived rather than measured.

Source: Search Console Index Coverage API where connected; sitemap-vs-impression differential otherwise

Remedy

  1. 1Group excluded URLs by Search Console exclusion reason before doing anything else — each reason has a different remedy.
  2. 2For "Discovered – currently not indexed", improve internal linking depth and prove the page is worth crawling.
  3. 3For "Crawled – currently not indexed", treat it as a quality signal: consolidate thin or near-duplicate pages rather than resubmitting.
  4. 4For "Duplicate, Google chose different canonical", align your declared canonical with the strongest internal linking and content signals.
  5. 5Re-inspect after four weeks; index decisions are re-evaluated on a crawl cycle, not on submission.

Verification

Recheck re-reads coverage state per URL and confirms the indexed proportion is inside the pass criteria.

Usually fixed by
SEO
Effort
Medium · 2–8 hrs
Est. impact
high
Typical cost
NZ$320–960
IX-04Minor failweight 2derived

Index is not diluted by low-value pages

Are thin, duplicate or auto-generated pages indexed?

Pass, advisory and fail criteria for IX-04
PassUnder 10% of indexed URLs are near-duplicate or zero-impression over 90 days.
Advisory10–25% of indexed URLs are low-value, concentrated in a single identifiable pattern.
FailOver 25% of indexed URLs are near-duplicate, thin or zero-impression.

Why it matters

A large index of pages nobody wants does not help and can actively hurt: it consumes crawl allocation, splits internal link equity across pages that will never rank, and gives a site-wide impression of low editorial standards. The most common sources are tag archives, internal search results left crawlable, and templated location pages differing only by a place name.

How we inspect it

We fingerprint main-content blocks with shingling to identify near-duplicates, then cross-reference against impression data to find indexed URLs earning effectively nothing. Tag archives, paginated series, internal search results and auto-generated location pages are classified separately.

Source: Content fingerprinting + impression distribution across indexed URLs

Remedy

  1. 1Rank every indexed URL by impressions and clicks over 90 days and isolate the zero-value tail.
  2. 2For each pattern choose one disposition: consolidate into a stronger page, improve it substantially, or noindex it.
  3. 3Consolidate near-duplicates with 301s to the strongest version and merge the useful content.
  4. 4noindex internal search results, thin tag archives and filter permutations — they must stay crawlable for the directive to be seen.
  5. 5Where templated location pages are genuinely needed, give each genuinely unique local information or do not publish it.

Verification

Recheck re-fingerprints the indexed set and confirms the low-value proportion is inside threshold.

Usually fixed by
SEO
Effort
Large · 1–3 days
Est. impact
medium
Typical cost
NZ$640–2,400
IX-05Minor failweight 2derived

No keyword cannibalisation on priority terms

Do multiple pages compete for the same query with unstable rankings?

Pass, advisory and fail criteria for IX-05
PassNo priority query has more than one URL earning material impressions.
AdvisoryMultiple URLs rank for a query but one is clearly dominant and stable.
FailAny priority query has two or more URLs alternating as the ranking page across the period.

Why it matters

When two of your pages compete for one query, neither accumulates the full set of signals for it. Rankings become unstable, the search engine picks the URL you did not intend, and the click-through rate drops because the chosen page is a poorer match for the intent. It is one of the most common causes of a plateau on a site that publishes consistently — the site is competing with itself, not with the market.

How we inspect it

For each query we count distinct URLs receiving impressions and measure how often the ranking URL changes between weeks. Flip-flopping — where two URLs alternate as the ranking page — is scored as cannibalisation even when the average position looks stable.

Source: Search Console query-to-URL mapping over 90 days

Remedy

  1. 1Build a query-to-URL map from Search Console and flag every query with more than one impression-earning URL.
  2. 2For each conflict decide the single canonical target: usually the page with the strongest internal links and best conversion rate.
  3. 3Consolidate the losers into the winner with 301s, merging genuinely unique content across.
  4. 4Where both pages must exist, differentiate them decisively by intent — comparison versus how-to, commercial versus informational.
  5. 5Repoint internal anchors so the intended target receives the descriptive anchor text for that query.

Verification

Recheck re-maps queries to URLs after four weeks and confirms a single stable ranking URL per priority query.

Usually fixed by
SEO
Effort
Large · 1–3 days
Est. impact
medium
Typical cost
NZ$640–1,900
IX-06Minor failweight 1measured

Pagination and faceting handled correctly

Are paginated series and filtered views crawlable but not duplicative?

Pass, advisory and fail criteria for IX-06
PassEach paginated page self-canonicalises, is reachable via a crawlable link, and lists unique items.
AdvisoryCorrect handling but page-one titles and descriptions are duplicated across the series.
FailPages canonicalise to page one, or deeper items are reachable only via JavaScript-driven infinite scroll with no crawlable alternative.

Why it matters

Canonicalising page two to page one tells the search engine the items on page two do not exist — on a large catalogue that can strand most of your inventory. Infinite scroll without a paginated fallback has the same effect. The items are visible to users and completely invisible to crawlers, so the pages exist but can never be found.

How we inspect it

We identify paginated series, confirm each page is self-canonical rather than canonicalised to page one, verify that deeper pages remain reachable by crawlable links, and check that infinite-scroll implementations expose a paginated fallback.

Source: Pagination pattern detection across listing templates

Remedy

  1. 1Make every page in a series self-canonical.
  2. 2Expose real anchor elements with href attributes for each page, even when scroll loading is the primary interaction.
  3. 3Differentiate titles and meta descriptions with the page number so results are distinguishable.
  4. 4Keep any "view all" page as the canonical only when it loads within performance budget.
  5. 5Ensure deep pagination stays within a reasonable click depth, or supplement with faceted entry points.

Verification

Recheck re-crawls the listing templates and confirms self-canonicalisation and crawlable pagination links.

Usually fixed by
Developer
Effort
Medium · 2–8 hrs
Est. impact
low
Typical cost
NZ$240–640
IX-07Minor failweight 1measured

International targeting is internally consistent

If you serve multiple locales, do hreflang annotations reciprocate correctly?

Pass, advisory and fail criteria for IX-07
PassAll clusters reciprocate, codes are valid, each URL self-references, and an x-default is declared.
AdvisoryReciprocation correct but x-default missing.
FailNon-reciprocal annotations, invalid codes, or hreflang pointing at redirected or non-canonical URLs.

Why it matters

hreflang is ignored entirely unless annotations reciprocate — a one-way declaration is not a weak signal, it is no signal. The usual symptom is the wrong locale ranking in the wrong market, cannibalising local landing pages and depressing conversion because prices and currencies are wrong. This check is marked not-applicable and excluded from scoring for single-locale sites.

How we inspect it

We build the full hreflang cluster graph and validate return links, language and region code syntax against ISO 639-1 and ISO 3166-1 alpha-2, self-reference presence, x-default declaration, and whether annotated targets are canonical indexable 200s.

Source: hreflang cluster extraction and reciprocity validation

Remedy

  1. 1Generate annotations from a single locale registry so reciprocity is structural rather than maintained by hand.
  2. 2Use valid ISO codes; region without language is invalid, and en-UK is not a valid code — it is en-GB.
  3. 3Include a self-referencing entry in every cluster.
  4. 4Point annotations only at canonical, indexable, HTTP 200 URLs.
  5. 5Declare x-default for the global or language-selector fallback.

Verification

Recheck rebuilds the cluster graph and confirms full reciprocity and code validity.

Usually fixed by
Developer
Effort
Medium · 2–8 hrs
Est. impact
low
Typical cost
NZ$320–800