Scanner

    Roadmap

    Eleven phases, ordered so each one unlocks the next. Phase 0 is what you can install today. Nothing beyond it is in the published package yet.

    StageStatus
    ShippedIn the published package, documented, tested.
    NextThe phase being built now.
    PlannedSpecified and sequenced, not started.

    1 of 11 phases shipped · 1 in progress · 9 planned

    The full item-by-item backlog, with a build-cost tag on every line, lives in features.md in the repository. This page is the summary.

    Phase 0: Shipped

    The engine as published: 93 rules across 15 categories.

    • audit(url, options) returning a scored report, plus auditToHtml, auditToMarkdown, auditScore, and render.
    • Multipage concurrent crawl with maxPages, concurrency, and maxDepth.
    • robots.txt and sitemap.xml fetched once per site and shared with every rule.
    • A shared link checker, so a URL referenced by ten rules is fetched once.
    • Severity-weighted scoring: per page, per category, and a harsher overall number.
    • Optional rendered stage through local Chromium or the PageSpeed Insights API.
    • Three output formats: JSON, Markdown, and one self-contained HTML file.
    • Pluggable rule registry. One file and one import adds a rule.
    • One runtime dependency.

    Phase 1: Report foundation and free measurements

    In progress · next up

    The gate everything else waits on.

    Most of what a page audit is expected to report are measurements, not verdicts: counts, tables, percentages. The report object holds only pass and fail findings today, so there is nowhere to put them. Building any of the later phases before this exists means building them twice.

    • A metrics output beside findings, per category, carrying numbers and tables.
    • A value status of ok, warn, bad, or missing, so a measurement can carry a verdict without inventing a finding.
    • Capped tables with a "showing N of M" count, for images, links, keywords, and the header tree.
    • A public rules option, so a custom rule array can be passed to audit() without forking.

    Then everything already sitting in the parsed DOM gets harvested:

    • Status code, page size, declared language, and published and updated dates as reported values.
    • Markup hygiene counters: inline styles, <style> blocks in the body, script tags, comment nodes, placeholder links.
    • Canonical match: does the canonical equal the URL that was actually audited.
    • Link counters and three link tables: dofollow, nofollow, and duplicate URLs with every anchor used for each.
    • Header counts per level and the full header tree in document order.
    • The complete Open Graph and Twitter Card tables, with a status per property.
    • Character counts for title, description, and H1, plus an H1 length check.

    Phase 2: Text, keyword, and readability engine

    Planned · not started

    One module that pays for four report sections.

    • A tokenizer with per-language stop word lists, lemma grouping, and n-gram extraction.
    • Main-content extraction, so nav and footer text stop polluting every statistic.
    • Text statistics: unique words, stop word share, redundancy, average sentence length, characters excluding spaces.
    • Readability: Flesch reading ease, Flesch-Kincaid grade, Gunning Fog.
    • Top words as 1, 2, and 3-word phrases with counts and percentages.
    • A keyword relevance matrix: each top keyword present or absent in the title, description, and H1.
    • Keyword highlight markers for headings, so a renderer can mark the matched spans.

    Phase 3: Answer engine and content structure

    Planned · not started

    The part most audit tools do not have, and it runs on a DOM already parsed.

    • Answer snippet check: is there a definition or short answer in the first four content blocks, and how long is it.
    • Q&A structure: question-like H2 count, how many carry a short answer, and the coverage ratio.
    • Answer formats: counts of lists, steps, tables, and definitions.
    • Topic cluster signals: internal links in main content only, related-reading detection, distinct H2 topics, anchor descriptiveness ratio.
    • Passage structure: H2 section count, average words per section, definition-format blocks.
    • Agent experience: AI crawler access in robots.txt, llms.txt, and whether the main content survives without JavaScript.
    • Schema depth: the nested type tree, plus microdata and RDFa, not only JSON-LD.

    Phase 4: Site-wide crawl intelligence

    Planned · not started

    The highest-value phase per unit of new infrastructure, since the crawler already visits every page but each rule looks at one page in isolation.

    • Duplicate titles, meta descriptions, and H1s across the crawl, grouped by the URLs that share them.
    • Near-duplicate content detection through a shingle hash.
    • Orphan pages: in the sitemap, linked from nowhere.
    • An internal link graph with inbound link counts, so thin-linked pages surface.
    • Click depth per page, and a site-wide redirect map.
    • Sitemap versus crawl reconciliation, both directions.
    • Crawling from the sitemap directly, not only by following links.
    • Score thresholds, so a run can fail itself in CI.
    • A CLI wrapper over the library, so an audit runs from a terminal or a CI step with no script to write. It was dropped in 1.0.1 and comes back on top of the stable API.

    Phase 5: Trust, authority, and compliance

    Planned · not started

    Cheap pattern detection, high client value.

    • Author box, author page link, and author bio detection, with the actual dates reported.
    • Structured data trust signals listed by name.
    • Refund or returns page, phone and physical address, affiliate disclosure, editorial policy.
    • Citation quality: are outbound citations pointing at recognised authoritative domains.
    • Local SEO: NAP consistency against LocalBusiness schema, schema completeness, business profile link.

    Phase 6: Performance and speed depth

    Planned · not started

    Mostly surfacing values the rendered stage already collects and discards.

    • Total load time, DNS lookup, TCP connection, response time, DOM interactive, DOM content loaded, DOM complete, FCP.
    • INP, with an explicit "not measurable without interaction" state rather than an undefined value.
    • Layout shift event count and the largest single shift.
    • A slow resource list: every request over a threshold.
    • Font loading, HTTP/2 and HTTP/3, preconnect hints, third-party script weight.

    Phase 7: Tech stack fingerprinting

    Planned · not started

    A signature table matched against markup, script sources, and headers.

    • Analytics per vendor, rather than one "a tag is present" result.
    • Ad pixels per vendor.
    • CMS, framework, and library detection.
    • CDN detection from headers and asset hosts.

    Phase 8: Media and asset analysis

    Planned · not started

    Real value, but it costs extra requests, so it sits behind an opt-in flag with a hard cap.

    • A per-image table: URL, pixel dimensions, transfer size, optimisation verdict.
    • Natural dimensions through a HEAD or ranged GET.
    • Optimisation estimates per format.
    • Images served far larger than their layout box.
    • Responsive image checks, video schema and captions, favicon and app icons.

    Phase 9: Mobile and rendered extras

    Planned · not started

    Everything that needs a real viewport.

    • Tap target size, mobile font size, horizontal overflow, intrusive interstitials.
    • Viewport behaviour: disabled zoom, fixed widths.
    • Console errors captured during load.
    • What content disappears with JavaScript off.
    • Screenshot capture attached to the report.

    Phase 10: External data and site integrity

    Planned · not started

    Keys, rate limits, and heuristics with false-positive risk, so it stays opt-in and never runs by default.

    • Backlink lookup behind a provider interface.
    • Keyword and content gap analysis.
    • Index coverage against a search API.
    • Obfuscated scripts, injected spam, malware and phishing patterns, leaked secrets.
    • Ad-blocker and privacy-filter impact.

    Not planned

    Worth saying out loud.

    • A hosted service or dashboard. The JSON output exists so you can build your own.
    • Rule configuration files. Options are passed in code. A config format is a second API to keep in sync.