Skip to content
  • AI visibility
  • Integrations
  • MCP
  • Pricing
  • Documentation

Research, write, optimise, publish and measure — with every number telling you where it came from.

© Copyright 2026 Noverva. All Rights Reserved.

Platform
  • AI visibility
  • Integrations
  • MCP
  • Pricing
Resources
  • Documentation
  • Blog
  • Changelog
  • FAQ
  • Contact
Legal
  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • AI visibility
  • Integrations
  • MCP
  • Pricing
  • Documentation
  • Aug 26, 2026

    We pointed our crawler at our own site

    The first production crawl of noverva.com found fifty pages missing canonical URLs, three false positives in our own rule engine, and a bug that had been reporting build-time health for a year.

    The first thing we did with the crawler was point it at noverva.com. It found that every one of our fifty pages was missing a canonical URL.

    That is a real defect, and it is the kind a tool like this exists to catch. The framework does not emit one by default, and nobody had noticed because nobody had looked. Fixing it turned out to be more interesting than expected: the obvious one-line fix resolved to a URL that immediately redirects somewhere else, which would have been worse than having no canonical at all — and would have tripped a different rule in our own engine.

    The engine was wrong three times

    Running your own rules against your own site surfaces the cases you would otherwise never see.

    Our canonical rule fired at high severity on parameter consolidation — pointing ?plan=pro at the clean URL is the textbook fix, and we were calling it a defect. Our noindex rule fired at critical severity on sign-in pages, which are noindexed on purpose and linked from every page on a site, meaning it would have opened every audit with a critical finding that was simply wrong. And a third rule asked for canonical URLs on noindexed pages, where search engines ignore them.

    A rule engine that punishes the correct remedy is worse than one that stays quiet, because a user who knows one finding is wrong has no reason to trust the rest. All three are fixed, and the fixes carry tests describing the real output that motivated them.

    The keyword engine read our code samples as prose

    When we ran the opportunity scoring for the first time, the top topics on our documentation were create table, env node and action'use server.

    Code blocks were being read as sentences. Below that, twelve of the top twelve opportunities were overlapping fragments of a single sentence, every one with an identical score — which is one finding shown twelve times.

    Both are fixed. Both were only visible by reading the output rather than the exit code.

    The healthcheck had been lying for a year

    Not a crawler finding, but the same lesson. Our health endpoint reported the database as reachable. It was serving a response cached at build time with a one-year lifetime, so it could not have reported an outage even during one.

    We would rather write this down than not. A product that claims its numbers say where they came from should be willing to say where its own mistakes came from too.