Four sites built by DNAccess and Hartzer Consulting using the method described on this site are live and public. They are presented here as evidence of build quality, scope, and technical capability. They are not presented as evidence of search performance, and the reason is at the bottom of this page.
IdahoResorts.com
A directory-and-reference site on Idaho resorts, split across two categories that genuinely behave differently: ski resorts and lake resorts. Each property gets a profile with the facts a visitor actually needs, and the two-category split drives a pair of substantial index pages rather than one undifferentiated list. A regional grouping layer sits on top, which is what makes the related-property links meaningful — a resort links to its neighbours, not to a random selection.
This build is the clearest demonstration of why the entity model gets decided before anything else. Resorts are a subject where the wrong model produces forty near-identical pages; the right one produces forty pages that each say something different.
Stockyards.org
The most editorially demanding of the three: historic stockyards and livestock markets, covering both the surviving working markets and the closed historic ones. The subject carries real history — cattle trails, the growth of the rail-connected terminal markets, the federal regulation of the industry — and the profiles are written to carry it, at length, with sources. Concept entities such as the Chisholm Trail and the Packers and Stockyards Act are modelled in the EntityMap alongside the places themselves, which anchors the site's entity graph to canonical references.
It is the best example in the set of the non-thin standard. A subject like this one can be covered in 300 words per page by anyone; covering it properly is the entire difference between a reference and a placeholder.
CheckADomain.com
The most technically involved build, and the one that justifies the Flagship tier. It carries 36 top-level domain profiles — each covering the extension's registry, its rules and eligibility, its pricing structure, its renewal and transfer behaviour, and what it is realistically good for — plus nine live tools running against a domain reseller API.
The tools are the part that is hard to replicate. Each one runs through a hardened server-side proxy, so the API credential never reaches the browser: the front end calls a same-origin endpoint, the proxy validates and rate-limits the request, calls the upstream API with the key held server-side, and returns only what the page needs. The proxy path is disallowed in robots.txt, and every tool has a demo mode so the page still works if the upstream service is unavailable. Underneath each tool sits 900 to 1,200 words of genuine explanation, because a bare tool with no content ranks for nothing and answers no question the visitor arrived with.
The API work carried its own lesson, which is now a fixed step in the runbook: diagnose the third-party API against real responses before writing a parser, rather than trusting its documentation. Skipping that on this build cost a full day.
CanonicalTag.com
A reference on a single technical SEO subject, taken to the depth the subject actually needs. The core entity is not a place or a product but a problem: each page profiles one canonicalisation issue, one platform implementation, or one conflict between the canonical tag and an adjacent signal. Roughly forty pages cover the Search Console statuses people arrive searching for, step-by-step setup on the major platforms — WordPress, Yoast, Shopify, Wix, Squarespace, Webflow, Magento, Next.js and React among them — the edge cases where canonical tags interact badly with noindex, pagination and hreflang, and a set of longer guides underneath.
It carries five live tools: a canonical tag checker that fetches a URL and reports whether the tag is present, self-referencing, absolute and HTTPS, and whether either the page or its target redirects; a generator that emits a copy-ready link element plus the HTTP header equivalent for PDFs and other non-HTML files; a validator that takes a pasted document head and flags the recurring faults; a bulk checker for auditing a section or a migration in one pass; and an hreflang generator that produces the full reciprocal set including x-default.
It is the clearest demonstration of what the method does with a narrow, technical, high-intent subject. The site publishes an EntityMap declaring fifty-nine entities, which on a topic this abstract is doing more work than it would on a directory: almost every entity is a concept rather than a thing, and the relationships between them are most of what a reader needs to understand.
Why there are no traffic or ranking numbers on this page
These three sites first went live between March and May 2026. At the time of writing they are a few months old.
That is not long enough to say anything meaningful about search performance. The two published studies on time-to-rank both measure it in months to years, not weeks, and no credible 2026 replication exists. Of the three sites, only CheckADomain.com currently surfaces in search results in any consistent way; the other three did not surface even for exact phrases lifted from their own homepages when last checked.
So no ranking claim, no traffic figure, and no revenue number is attached to any of them here. What they demonstrate is what they can demonstrate today: scope, content depth, technical execution, accessibility, and — in the case of CheckADomain.com — live tooling on a real API.
When there is data worth publishing, it will be published, including the results that are unflattering. The plan is a matched-pair study across a real portfolio: a set of comparable domains, some developed and some held, tracked over 12 to 18 months. Nobody in this industry has published that dataset. Until it exists, this page will keep saying that these sites are too new to report ranking data, because that is the true thing to say.