Web Technology Index (WTI)

What is WTI

Web Technology Index (WTI) is the engineering and security benchmark used by Clickerwayne Zelle Solutions Inc to evaluate how a website is built, secured, and delivered. We apply this exact standard to our own builds and client projects.

WTI does not measure marketing metrics. It measures the underlying engineering: TLS protocols, security headers (CSP, HSTS), email authentication (SPF, DMARC, DKIM), DNS security (DNSSEC, CAA), cookie flags, exposed files, document structure, and AI discovery files. Every domain receives two independent scores:

• WTI-Raw: Grades the raw HTTP response. 65 checks across 8 layers covering Transport & DNS, Response Headers, Crawl Foundation, Document Structure, Structured Data, Resource Efficiency, Security Posture, and AI Discovery. 100 points.
• WTI-JS: Grades JavaScript dependency and progressive enhancement. 18 checks across 4 layers. 100 points.

Each score is generated from its own HTTP fetch. The audit also requests the well-known paths listed below and runs DNS and TLS lookups for the email authentication and certificate checks. The same HTTP response, DNS state, and TLS state always produce the same score. Every completed audit is cryptographically signed with ES256 and stored in a public manifest that records the URL, score, rubric version, crawl timestamp, and the SHA-256 of the exact server output (HTML and headers).

WTI is a defensive security checklist. It is highly effective for developers and website owners who need to verify that their servers are locked down properly: TLS protocols, security headers, DNS records, email authentication, cookie flags, and the other controls that determine whether a server is configured correctly.

WTI is not a commercial website evaluator. It does not score content quality, brand presence, traffic, backlinks, or conversion. Sites that need those measurements should use tools built for them. The narrow scope is intentional. It is what makes the rubric reproducible, and a score that cannot be reproduced is just an opinion.

Why We Built It and Made It Public

We built WTI because we needed a standard for our own engineering team. Existing tools are either too ephemeral or completely opaque. Browser-based performance tools generate different scores on every run because rendering varies by milliseconds. Proprietary audits are delivered as PDFs that can be altered, with no cryptographic link to the actual server response.

We made the WTI rubric public for three reasons:

• To prove our engineering standard: We tell clients we build secure, fast, and technically sound websites. WTI is the scorecard that proves it. Anyone can run our rubric against our builds and see exactly where we stand.
• To force accountability: Publishing a strict, signed benchmark means we cannot hide behind vague reports. If a site scores poorly, the data shows exactly why. If it scores 100, the manifest proves it hasn't been tampered with.
• To set the baseline for our clients: When a client hires us, they know the exact infrastructure and security standard their new site will meet. WTI is the technical guarantee.

Who WTI Is For

WTI is a defensive security checklist. It is used by the following groups:

• Website owners and operators who need to verify that their host, agency, or vendor has actually configured the server securely, not just claimed to.
• Web engineers who need to prove a technical fix was deployed. The signed manifest binds the fix date to the graded server response.
• Security and compliance teams who need to verify that a vendor or partner site meets strict infrastructure standards (DNSSEC, DMARC, CSP, TLS 1.3).
• Agencies who need third-party confirmation that a delivered build meets a published technical standard, rather than relying on an unsigned PDF.
• Researchers studying web quality at scale. Because the benchmark is fixed, a score measured in January is directly comparable to a score measured in July.

Scope and Boundaries

WTI answers two specific questions: when a crawler requests a page, what security and structural data does the server deliver? And does the core content require JavaScript execution to be readable?

These boundaries are stated here so no reader has to infer them:

• Paint performance: Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. These require a real browser render and fluctuate by milliseconds.
• Content quality: WTI measures body text length in characters and looks for at least one substantive content block. It does not evaluate the meaning or quality of the text.
• Off-page metrics: Backlinks, domain authority, link equity, search rankings, and organic traffic. WTI does not maintain a link index or collect SERP data.
• Business metrics: User engagement, conversion rate, or business legitimacy.

WTI-Raw 1.0 Rubric

65 checks across 8 layers, weighted to 100 points. Every check comes from the target's HTTP response, its well-known paths, its DNS records, and its TLS configuration, using the SnifferBot/2.0 User-Agent. One check (CMS detection) is metadata only and carries 0 points, which is why the scored weight is 100 while the row count is 65.

Layer 1: Transport & DNS (20 points)

Layer 2: Response Headers (24 points)

Layer 3: Crawl Foundation (10 points)

Layer 4: Document Structure (7 points)

Layer 5: Structured Data (4 points)

Layer 6: Resource Efficiency (9 points)

Layer 7: Security Posture (21 points)

Layer 8: AI Discovery (5 points)

WTI-JS 1.0 Rubric

18 checks across 4 layers, weighted to 100 points. Measures JavaScript dependency and progressive enhancement.

Layer 1: Content Availability Pre-JS (35 points)

Layer 2: Progressive Enhancement (20 points)

Layer 3: Script Delivery (15 points)

Layer 4: SSR and Hydration (30 points)

How Scores Are Calculated

A page starts at 0 points. Each passing check adds its weight. Failing checks add nothing. The total is the sum of all passed weights.

For WTI-Raw, all 65 checks always run. Maximum is always exactly 100 because the CMS detection check carries weight 0.

For WTI-JS, the noscript_meaningful check only runs when a noscript tag exists. When it does not, the maximum possible is 96. Scores are normalized to 100 in that case: final = round((earned / possible) * 100).

Signing

Every completed audit produces a manifest signed with ES256 (ECDSA over P-256). The manifest is published at /.well-known/provenance/manifest-wti-{slug}-{mode}.json.

The signed payload contains the URL, the domain, the score, the rubric version, the crawl timestamp, the HTML SHA-256, and the headers SHA-256. Anyone can fetch the manifest, canonicalize the claim object with a recursive key sort, hash it, and verify the signature against the published public key. The key fingerprint is da417e124f8738203ccb0c47ffcde4754823b599722b9481df959f13c65992b9.

Versioning

WTI-Raw and WTI-JS are versioned independently.

• Changing a check or its weight bumps the minor version (1.0 to 1.1).
• Changing the layer structure or overall scoring model bumps the major version (1.0 to 2.0).
• Old scores remain published against their original version. They are not retroactively rescored.
• Every manifest declares its version so third parties can verify against the correct rubric.

Reproducibility

Every WTI-Raw and WTI-JS audit can be reproduced with the following inputs:

1. The raw HTTP response from the target URL (status, headers, and body)
2. The responses from the well-known paths the audit requests: robots.txt, sitemap.xml, sitemap_index.xml, .well-known/security.txt, llms.txt, .well-known/ai.txt, .well-known/ard.json
3. The DNS records for the domain: CAA, DNSKEY, TXT for SPF, TXT for _dmarc, and TXT for common DKIM selectors
4. The TLS configuration: negotiated protocol version, and whether legacy TLS 1.0 or 1.1 is still accepted
5. The SnifferBot/2.0 User-Agent string

The audit is strict and repeatable: the same HTTP response, DNS state, and TLS state produce the same score. There is no inference, no modeling, no weighting by AI. The rubric is a fixed set of boolean checks and fixed weights.

Reproduction commands (replace example.com with the target):

UA='User-Agent: SnifferBot/2.0 (+https://www.clickerwaynezelle.com/wti/methodology)' B='https://example.com' # Main page with response headers curl -sS -D - -H "$UA" "$B/" # Crawl and well-known paths for p in robots.txt sitemap.xml sitemap_index.xml .well-known/security.txt llms.txt .well-known/ai.txt .well-known/ard.json; do printf "%s %s\n" "$(curl -sS -o /dev/null -w '%{http_code}' -H "$UA" "$B/$p")" "$p" done # Exposed file probes for p in .git/config .env phpinfo.php backup.zip .htaccess composer.lock package.json .DS_Store .aws/credentials; do printf "%s %s\n" "$(curl -sS -o /dev/null -w '%{http_code}' -H "$UA" "$B/$p")" "$p" done # DNS records H=example.com for r in "CAA $H" "DNSKEY $H" "TXT $H" "TXT _dmarc.$H"; do dig +short $r; done for s in default google mail s1 k1; do dig +short TXT "$s._domainkey.$H"; done # TLS configuration echo | openssl s_client -connect "$H:443" -tls1_3 2>/dev/null | grep -E "Protocol|Cipher" echo | openssl s_client -connect "$H:443" -tls1_1 2>/dev/null | grep -E "Protocol|Cipher"

Run each check in this rubric against the collected outputs. The score will match.

Discovery and Coverage

Domains enter the WTI index through an automated discovery pipeline that sources candidates from Certificate Transparency logs, Common Crawl, and public Wikipedia lists. Candidates are validated against DNS, HTTP status, parked domains, expired pages, placeholder pages, robots.txt directives, spam keywords in the domain name, and country signals before being audited.

Only domains that resolve, return HTTP 200, and pass country verification are audited. Once audited, both WTI-Raw and WTI-JS scores are generated automatically.

Anyone can submit a domain for review. Contact Clickerwayne Zelle at the address on the contact page.