WHY GOVERNANCE?
The web is no longer a one-off project
Customer value cards: eight concrete values from risk reduction to live verification.
A website is now a human storefront plus a machine surface.
The page a visitor sees is simultaneously the input of dozens of automated readers. A page flawless for humans can carry missing headers, broken schemas and unclear identity signals for machines.
Even with great design, machine readability can be weak.
WHAT IS R50?
The engine's 50th release cycle — every claim accounted for
R50 is WebTrustEngine's public capability set. Its distinguishing trait is number discipline: the 2,033-item reference catalog and the 319 working checks are deliberately kept apart; no figure is inflated.
Claim safety
2,033 is not a check count; it is a signal map. The working check layer is 319, counted from code.
FOUR MODES
Review → SafeFix → Build → Deploy-Verify
Each mode produces its own evidence; no mode issues a live pass.
Review
An evidenced baseline without touching a file: 10-domain score plus classified findings.
score + findingsSafeFix
Low-risk fixes in a working copy; every change is written to a manifest.
fix manifestreversibleBuild
A schema-ready static surface: meta, canonical, hreflang, JSON-LD, accessibility skeleton.
static surfacereversibleDeploy-Verify
Post-upload live header pulls and independent-tool recipes; producing files is not enough.
live proof
The 10-domain score model
Each domain with its one-line scope; evidence, sample findings and boundaries live on the Score Model page.
Security Headers
HSTS · CSP · nosniff
TLS / HTTPS
encrypted transport
Technical SEO
meta · canonical · sitemap
Structured Data
JSON-LD identity
Accessibility
alt · label · heading
Performance
static readiness
AI / GEO / AEO
readability
Privacy / Cookie
tracker visibility
Code Security
secrets · exposure · patterns
Delivery
deployment hygiene
SAFEFIX
Not a rebuild — a safe improvement
The evidence package: files, not a score
A changed-files list, a rollback manifest and a before/after score ship together. Every change reverts in a single step.
See the processchanged_filesFlat list of every touched path.
fix_manifestPer-file before/after hashes.
rollback_manifestThe single-step way back.
diffEach change in context.
score_pairBefore/after on one ruler.
run_logDate · file set · engine seal.
DEPLOY-VERIFY
Producing files is not enough
Upload, cache purge, live header pulls and independent-tool recipes: evidence completes in production.
- Live header pull
- robots/sitemap live
- OG card refresh
- Search Console submit
- SSL Labs run
SECURITY BOUNDARY
Not a pentest — and it says so
The security boundary: static review is engine work; active testing needs separate authorization and scope.
A static security review is security analysis over source, configuration and output files without touching the target system. WebTrustEngine's security layer stays within this definition and has four blocks: secret scan (key/password/token leakage), exposed files (.env, backups, .git, config exposure), client-side risky patterns (eval, document.write, dangerous sinks) and server-side SAST classifications (SQLi/command/traversal/deserialization/SSRF/XXE markers).
SCA/CVE logic accompanies these: risky ranges of known library versions are flagged; but no 'this version is exploitable' claim is made — the flag binds to an update recipe. CSP/HSTS readiness and OWASP mapping put findings into a shared language.
When is it not a pentest? Always — in this product. No active payloads, no live port scans, no authentication-bypass attempts, no exploit generation. Any DAST-class behaviour requires written authorization, ownership verification and a separate scope document. This legal and ethical boundary is not a weakness; it is trust discipline: the client knows exactly what they bought and what must be ordered separately.
- secret scan
- exposed files
- JS sink patterns
- SCA/CVE flags
- CSP/HSTS readiness
- OWASP mapping
- DAST = authorization + scope
Boundary
Active testing requires written authorisation; the engine offers static security review.
VISUAL SYSTEM
The brand speaks its own visual language
The governance loop
Governance Loop
Four modes + Deploy-Verify
Review
evidenced baseline
SafeFix
reversible package
Build
new static surface
Monitor
periodic evidence
Deploy-Verify
live-effect proof
No guarantees — readiness, evidence and verification. Number contract: 2,033 reference catalog · 319 working checks.
WHO USES IT
Who uses it, and when?
Four typical moments: an evidence-based snapshot before a corporate site renewal; independent acceptance of an agency delivery; a recurring governance round; and quick due diligence before a merger or transfer.
Critical questions — quick answers
Q: What can it see without touching the live site?
A: All in-file signals in ZIP/local input: meta, schema, header readiness, accessibility markers, static security patterns.
Q: ZIP vs live-URL analysis?
A: ZIP shows file truth; live URL shows response truth; headers and redirects finalize only live.
Q: What if the site breaks after SafeFix?
A: The rollback manifest reverts in one step; the backup dir ships in the package.
Q: How is the rollback manifest used?
A: Copy files back from the backup dir; the changed/created lists guide you.
Q: Which changes need human approval?
A: Meaning-changing content, brand/voice decisions, legal text and the publish decision.
Q: Why isn't the 2,033 catalog automated checks?
A: The catalog is a signal map; a check is code the engine runs. The two are deliberately separate.
Q: Why is 319 the more accurate number?
A: Counted from code, consistent with the code-level count, and free of inflation.
Q: What ROADMAP=0 is not?
A: Not 'everything automated'; every item attached to its correct artifact class.
Ready for the first review?
Get an evidenced baseline without touching a file; scope and quotes are settled via contact — pricing is not published on this site.