Building Atlas
How I built a website audit console that carries captured evidence into review and export.
Sulayman Bowles · · Updated
How do I tell whether an audit finding is backed by captured evidence?
Follow the finding back to its captured artifact, retrieval conditions, interpretation, and review decision. Keep missing measurements visible: saved JavaScript data is not proof that a browser rendered it. Atlas illustrates that workflow with a bounded source sample and a pinned code revision. Its tests establish behavior at that revision; the retained two-page capture establishes only what those requests returned. Neither establishes coverage or outcomes for an entire site.
Evidence: Atlas at the audited revision · Retained capture manifest · Rendering and provenance tests
Read this alongside Build search systems you can verify.
I built Atlas through VOID to make website audits easier to act on. A warning should let its reviewer inspect the evidence, understand what it establishes, and decide whether to change the site.
Atlas carries a captured page through interpretation, review, and export. Following one finding through that workflow explains the product decisions behind the console.
Scope and assumptions
The July demonstration below is a retained two-page source capture. The implementation references are pinned to the repository revision reviewed on October 1, 2026. Neither establishes client outcomes, search rankings, production coverage, or measured performance gains.
Make the finding useful
A missing heading, a conflicting canonical, and an unavailable performance measurement require different responses. A warning count cannot tell a reviewer which deserves attention.
My work covers Atlas’s product architecture, crawler, evidence policy, review workflow, and interface. The console captures pages, connects them, and retains the context behind its findings. The public repository documents a local audit console rather than a hosted commercial service. Repository scope.
A recommendation should lead back to its URL, captured state, and rule. The reviewer needs that connection at the point of decision.
Retain the conditions of capture
Collection choices affect the findings. Duplicate addresses inflate counts; partial runs can make reachable pages appear absent; a failed fetch can resemble an empty page. The record must distinguish these states.
Atlas retains measurement conditions alongside results. Crawl policy and collection limits define the sample; SQLite preserves the local run for inspection and export. A bounded crawl cannot describe the whole site.
The incremental-crawl tests check reuse after a 304 response and an unchanged 200 response, then require re-parsing when the artifact version changes. The content can stay the same while its interpretation changes. These are code-level checks, not a throughput benchmark. Incremental-crawl tests.
Separate the response from the rendered page
In the retained July 16 sample, both Quotes to Scrape pages returned HTTP 200. The ordinary page’s source contained ten quote cards. The JavaScript page contained zero quote-card elements but ten runtime data records. The capture also retained next-page addresses. Capture manifest.
A successful response does not establish content completeness. This sample contains no measured browser render and establishes nothing about indexing or a broken corpus. Assessing the JavaScript page’s visible coverage requires a browser render.
The render-pipeline tests carry that distinction into issue generation. A fixture lacks a heading in raw HTML but includes it in effective rendered facts. The expected result retains the raw-only observation without flagging a missing heading on the effective page. It also separates a raw canonical mismatch from the effective canonical state. Render-pipeline tests.
The interface should show which state produced the finding and why the raw response and effective page disagree.
| Retained source fact | Ordinary page | JavaScript page |
|---|---|---|
| HTTP response | 200 | 200 |
| Quote-card elements | 10 | 0 |
| Runtime data records | Not counted in this capture | 10 |
Source capture, July 16, 2026. This table reports retained observations; it does not report browser-rendered quote counts.
Distinguish a finding from missing evidence
The public sample records an absent canonical tag without assigning severity. Page purpose, duplication, redirects, and other signals determine whether that absence warrants a change. The report needs to show how it reached that judgment.
An unavailable provider measurement is an evidence gap. The provider-reconciliation tests include a skipped-missing-key state; missing data should never become a bad website score. Provider tests.
Link graphs, canonicals, structured data, and derived findings ask related questions: do the addresses agree, can the page be reached, does visible content support the structured claim, and can the finding be traced to an observation? The pinned implementation and retained artifacts determine which answers Atlas can support.
Use an unexplained finding to improve the system
I want the improvement cycle to start with a finding that cannot be explained, or a run that hides a missing measurement. The change should address that case and retain enough context to evaluate the result.
Keep a small example. Locate the error in capture, interpretation, or presentation. Write a regression check, rerun the example, and compare the finding with its record. Presentation cannot repair an unsupported interpretation.
The cache-version and rendered-facts tests encode parts of this method. Open questions remain: which artifacts need reinterpretation after a rule changes? What can an incomplete browser measurement establish? Where does a bounded run disclose its limits?
These tests document development practices. An autonomous improvement service, reduced audit time, and a completed validation program remain unestablished.
Compare the causes of a changed finding
The next iteration should help reviewers compare runs. A changed finding may reflect a changed page, a revised rule, a different collection limit, or a newly available provider. These causes must be separated before crediting a fix.
I would judge that work by the quality of its explanations, visible uncertainty, comparisons, and traceable exports. More information earns its place when it improves a decision.
The repository excludes rank tracking, GA4 integration, hosted dashboard delivery, and distributed crawling. These remain limits of the reviewed implementation. Repository scope.
Open the Atlas case study to inspect the retained pages and source facts.
Sources
- Atlas repository and documented scope
Reviewed Oct 1, 2026
Pinned revision ef3bad25ea0f43f7b4a854fa56c74af5a50fc8db. Scope and limits; not independent verification of operational results.
- Retained Quotes to Scrape source-capture manifest
Jul 16, 2026
Two source captures; this does not include a measured browser render.
- Incremental crawl regression tests
304 reuse, unchanged-body reuse, and artifact-version invalidation.
- JavaScript rendering and issue-provenance tests
Raw-only observations and effective rendered facts remain distinct.
- Provider-reconciliation tests
Includes skipped-missing-key behavior. Test inspection is not a fresh execution of the Atlas test suite.