How the model works
The ten-domain scoreboard: the full decision surface from security to delivery.
The four-class split: static, runtime, external and manual verification.
Each domain follows the same seven-part template: purpose, typical problems, what the engine checks, what it can fix, live verification, sample output and executive meaning.
Security Headers
The Security Headers domain examines the policy layer that tells modern browsers within which security boundaries to run the page. It is not a mere 'is the header present?' check; HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy must be handled in a way that fits the target site type.
Typical problems
- Headers absent or on default server values
- CSP conflicts with inline code and breaks the page
- HSTS present but wrong max-age/scope
- Double CSP (server + file) intersects and narrows policy
What the engine checks: The engine statically classifies header presence, value quality, in-site conflicts (inline code ↔ strict CSP) and the risk of clashing with an existing server policy.
What it can fix: In supported environments (.htaccess) it produces a secure baseline header set; if the site already has its own CSP it does not add a duplicate policy; it turns advice into a recipe.
Live verification: Whether headers actually apply live depends on hosting behaviour; verified post-deployment with SecurityHeaders and Mozilla Observatory.
| Sample indicator | Before | After |
|---|---|---|
| Header coverage | 3/9 | 9/9 |
| CSP conflict | present | none |
| HSTS | none | max-age + subdomains |
What the engine does: The engine statically classifies header presence, value quality, in-site conflicts (inline code ↔ strict CSP) and the risk of clashing with an existing server policy.
What it doesn't: Whether headers actually apply live depends on hosting behaviour; verified post-deployment with SecurityHeaders and Mozilla Observatory.
What the output is: In supported environments (.htaccess) it produces a secure baseline header set; if the site already has its own CSP it does not add a duplicate policy; it turns advice into a recipe.
For decision-makers: This domain answers 'what does our site promise the browser'; a low score is an invisible yet measurable corporate risk.
For technical teams: The gap between file production and live behaviour is most visible here; a post-deploy header fetch is mandatory.
TLS / HTTPS Readiness
The full explanation2051 words
This domain examines readiness for encrypted, secure transport: HTTPS enforcement, HSTS policy, mixed content and certificate readiness in one frame.
Typical problems
- HTTP version still reachable
- http:// resources inside the page (mixed content)
- No HSTS or not preload-ready
- Form action goes over http
What the engine checks: The engine statically detects redirect setup, in-page http:// references, form targets and HSTS markers.
What it can fix: Produces an .htaccess recipe for HTTPS redirect + HSTS; flags mixed-content lines at file/line level.
Live verification: Certificate chain, protocol versions and OCSP stapling are graded live by SSL Labs; HSTS preload submission is an external action.
| Sample indicator | Before | After |
|---|---|---|
| Mixed content | 14 lines | 0 |
| enforcement | partial | full |
| HSTS | none | recipe ready |
What the engine does: The engine statically detects redirect setup, in-page http:// references, form targets and HSTS markers.
What it doesn't: Certificate chain, protocol versions and OCSP stapling are graded live by SSL Labs; HSTS preload submission is an external action.
What the output is: Produces an .htaccess recipe for HTTPS redirect + HSTS; flags mixed-content lines at file/line level.
For decision-makers: Browser 'not secure' warnings touch brand trust directly; this domain is the readiness that prevents them.
For technical teams: The TLS grade is decided server-side; the engine produces readiness, SSL Labs gives the grade.
Technical SEO
Technical SEO examines the technical base search engines need to crawl and index correctly: title/meta, canonical, hreflang, robots, sitemap, heading hierarchy and URL consistency.
Typical problems
- Missing/duplicate titles and descriptions
- Canonical absent or self-contradictory
- Sitemap disagrees with the real page set
- Multiple or missing H1
What the engine checks: The engine statically audits per-page meta quality, canonical/hreflang consistency, robots-sitemap relation and heading structure.
What it can fix: Missing meta/canonical completion, sitemap/robots generation and heading fixes are applied via SafeFix on the working copy.
Live verification: Broken external links, redirect chains and real indexing need a full crawl; verified with Search Console.
| Sample indicator | Before | After |
|---|---|---|
| coverage | %61 | %100 |
| Kanonik / canonical | missing | 0 |
| Sitemap | stale | current |
What the engine does: The engine statically audits per-page meta quality, canonical/hreflang consistency, robots-sitemap relation and heading structure.
What it doesn't: Broken external links, redirect chains and real indexing need a full crawl; verified with Search Console.
What the output is: Missing meta/canonical completion, sitemap/robots generation and heading fixes are applied via SafeFix on the working copy.
For decision-makers: This is the findability infrastructure; the precondition for content investment not being wasted.
For technical teams: There is no ranking promise; there is crawlability and consistency.
Structured Data
This domain examines the JSON-LD layer that lets machines understand content: correct type choice, required fields and entity consistency.
Typical problems
- Schema absent or only on the homepage
- Required fields missing (name/provider/startDate)
- Schema mismatched to page type (e.g. Product everywhere)
- Identity signals (sameAs) disconnected
What the engine checks: The engine parses JSON-LD blocks and classifies missing required fields and type mismatch across Organization/WebSite/WebPage/Service/FAQPage/BreadcrumbList.
What it can fix: Produces baseline schema blocks and file-level missing-field warnings; sector types like Product/Event are separated as conditional rules.
Live verification: Rich-result eligibility is verified live with the Rich Results Test; wrong schema can break rich results.
| Sample indicator | Before | After |
|---|---|---|
| pages with schema | %18 | %100 |
| required-field errors | 23 | 0 |
| sameAs | none | tam / complete |
What the engine does: The engine parses JSON-LD blocks and classifies missing required fields and type mismatch across Organization/WebSite/WebPage/Service/FAQPage/BreadcrumbList.
What it doesn't: Rich-result eligibility is verified live with the Rich Results Test; wrong schema can break rich results.
What the output is: Produces baseline schema blocks and file-level missing-field warnings; sector types like Product/Event are separated as conditional rules.
For decision-makers: Structured data is the brand's identity card in the machine world; when missing, the brand reads as 'anonymous'.
For technical teams: Schema correctness needs sync with content; conditional rules bind to page type.
Accessibility
The Accessibility domain examines readiness for users with disabilities and assistive technologies, deliberately separating static detection from human evaluation.
Typical problems
- Alt texts empty or meaningless
- Form fields unlabeled
- Heading order skips (H1→H3)
- No landmarks/skip link
What the engine checks: The engine statically detects alt/label/ARIA usage, landmark and heading structure, language attribute and table semantics.
What it can fix: Flagging missing alt/label, landmark/heading fixes and the language attribute are within SafeFix scope.
Live verification: Contrast ratio, focus visibility, meaningful sequence and media description need render/human evaluation; routed to manual verification. No full-WCAG-compliance guarantee is given.
| Sample indicator | Before | After |
|---|---|---|
| alt coverage | %64 | %100 |
| Etiketsiz form / unlabeled fields | 9 | 0 |
| Landmark | partial | tam / complete |
What the engine does: The engine statically detects alt/label/ARIA usage, landmark and heading structure, language attribute and table semantics.
What it doesn't: Contrast ratio, focus visibility, meaningful sequence and media description need render/human evaluation; routed to manual verification. No full-WCAG-compliance guarantee is given.
What the output is: Flagging missing alt/label, landmark/heading fixes and the language attribute are within SafeFix scope.
For decision-makers: Accessibility is both inclusion and legal-risk territory; the readiness score makes both visible.
For technical teams: Items not auto-PASSed are an honesty layer, not a weakness.
Performance Readiness
This domain examines readiness to load fast via static indicators, deliberately keeping field measurement outside.
Typical problems
- Render-blocking script/CSS
- Dimensionless images (CLS risk)
- No compression/cache header readiness
- Huge unoptimized images
What the engine checks: The engine statically classifies render-blocking patterns, image dimension/lazy signals, minify readiness and cache/compression markers.
What it can fix: Defer on external scripts, image dimension/lazy suggestions and an .htaccess compression/cache recipe are SafeFix outputs.
Live verification: Real Core Web Vitals (LCP/INP/CLS) are measured live via PageSpeed/CrUX; the engine produces no field data; CDN setup is an external action.
| Sample indicator | Before | After |
|---|---|---|
| Render-blocking | 7 | 0 |
| dimensionless imgs | 31 | 0 |
| cache recipe | none | ready |
What the engine does: The engine statically classifies render-blocking patterns, image dimension/lazy signals, minify readiness and cache/compression markers.
What it doesn't: Real Core Web Vitals (LCP/INP/CLS) are measured live via PageSpeed/CrUX; the engine produces no field data; CDN setup is an external action.
What the output is: Defer on external scripts, image dimension/lazy suggestions and an .htaccess compression/cache recipe are SafeFix outputs.
For decision-makers: Speed is conversion's silent partner; the readiness score closes the first half of 'why are we slow live'.
For technical teams: The lab/field split is preserved: engine readiness, PageSpeed measurement.
AI / GEO / AEO
This domain prepares content for correct readability by AI systems, search and answer engines: identity clarity, sourceable text and machine directives.
Typical problems
- Who/what/where unclear (weak entity)
- No llms.txt or AI directives
- FAQ not answer-ready
- Multilingual pages inconsistent
What the engine checks: The engine evaluates entity signals, llms.txt/AI-crawler directives, semantic structure, author/date markers and FAQ readiness.
What it can fix: Produces an llms.txt suggestion, structure for identity/service clarity and answer-ready FAQ markup.
Live verification: Being recommended/cited by AI is not guaranteed; readability readiness is produced and this boundary is written explicitly everywhere.
| Sample indicator | Before | After |
|---|---|---|
| llms.txt | none | ready |
| clarity | weak | strong |
| answer-ready FAQ | none | marked |
What the engine does: The engine evaluates entity signals, llms.txt/AI-crawler directives, semantic structure, author/date markers and FAQ readiness.
What it doesn't: Being recommended/cited by AI is not guaranteed; readability readiness is produced and this boundary is written explicitly everywhere.
What the output is: Produces an llms.txt suggestion, structure for identity/service clarity and answer-ready FAQ markup.
For decision-makers: In the answer-engine era visibility is not just SERP but 'appearing inside the answer'; this domain builds that readiness.
For technical teams: Citation promises are banned; readiness signals are measurable and auditable.
Privacy / Cookie
This domain examines privacy readiness via tracker visibility and cookie hygiene, deliberately leaving legal-compliance judgment to the human layer.
Typical problems
- Tracking markers before consent
- Cookie flags missing (Secure/HttpOnly/SameSite)
- Privacy/cookie policy unlinked
- Third-party trackers invisible
What the engine checks: The engine detects tracker visibility, cookie flags, pre-consent tracking markers and policy links (static signals parallel to the Blacklight/Cookiebot approach).
What it can fix: Produces cookie-flag warnings and policy-link suggestions.
Live verification: KVKK/GDPR compliance requires legal counsel; the engine gives no guarantee and routes to manual verification.
| Sample indicator | Before | After |
|---|---|---|
| pre-consent | present | flagged |
| cookie flags | missing | recipe |
| policy link | none | present |
What the engine does: The engine detects tracker visibility, cookie flags, pre-consent tracking markers and policy links (static signals parallel to the Blacklight/Cookiebot approach).
What it doesn't: KVKK/GDPR compliance requires legal counsel; the engine gives no guarantee and routes to manual verification.
What the output is: Produces cookie-flag warnings and policy-link suggestions.
For decision-makers: Privacy is now reputation; it cannot be governed without visibility.
For technical teams: 'Compliance guarantee' language is banned; 'visibility + readiness + legal sign-off' is the correct chain.
Code / Static Security
This domain runs the static security review over source and configuration, clarifying the active-testing boundary from the start.
Typical problems
- Hardcoded secrets (keys/passwords) in the repo
- Exposed files (.env, backups, .git)
- Risky JS patterns (eval, document.write)
- Weak-crypto markers (MD5/SHA1)
What the engine checks: The engine statically detects secret scanning, exposed-file checks, client-side risk patterns, server-side SAST classifications (SQLi/command/traversal/deser/SSRF/XXE), malware markers and weak crypto; findings map to OWASP.
What it can fix: Produces risky-pattern warnings, exposed-file markers and a security-header recipe; never produces exploit code.
Live verification: Active exploitation, port scanning, auth bypass and live payloads belong to a separate authorized security scope; this domain is not a pentest.
| Sample indicator | Before | After |
|---|---|---|
| secrets | 2 | 0 |
| exposed files | 5 | 0 |
| mapping | none | raporlu / reported |
What the engine does: The engine statically detects secret scanning, exposed-file checks, client-side risk patterns, server-side SAST classifications (SQLi/command/traversal/deser/SSRF/XXE), malware markers and weak crypto; findings map to OWASP.
What it doesn't: Active exploitation, port scanning, auth bypass and live payloads belong to a separate authorized security scope; this domain is not a pentest.
What the output is: Produces risky-pattern warnings, exposed-file markers and a security-header recipe; never produces exploit code.
For decision-makers: This domain surfaces 'are unknown risks in the repo'; it is the dashboard of silent risk.
For technical teams: The SAST↔DAST split is written; no active behaviour without authorization.
Deployment
This domain examines the hygiene of publishing correctly and consistently: favicon/manifest, 404, social preview, sitemap/robots consistency and file structure.
Typical problems
- Favicon/manifest missing or inconsistent
- OG/Twitter cards half-done
- No 404 page
- robots contradicts sitemap
What the engine checks: The engine audits the icon/manifest set, social-preview fields, 404 presence and the robots-sitemap relation.
What it can fix: Completing favicon/manifest, generating OG/Twitter fields and robots/sitemap fixes are within SafeFix.
Live verification: Live redirect, header and preview effect are verified post-deploy; social-preview caches refresh via debuggers.
| Sample indicator | Before | After |
|---|---|---|
| icon set | 3 pcs | 10 pcs |
| OG coverage | %40 | %100 |
| 404 | none | custom page |
What the engine does: The engine audits the icon/manifest set, social-preview fields, 404 presence and the robots-sitemap relation.
What it doesn't: Live redirect, header and preview effect are verified post-deploy; social-preview caches refresh via debuggers.
What the output is: Completing favicon/manifest, generating OG/Twitter fields and robots/sitemap fixes are within SafeFix.
For decision-makers: Delivery hygiene is the infrastructure of how the brand appears wherever it is shared.
For technical teams: Preview caches mislead; the live-verification step is never skipped.
CONTROL SURFACE
10 domains — one interactive surface
Five lines per panel: what it inspects, typical evidence, a sample finding, the boundary and the related tool. Tabs on desktop, an accordion on mobile; with JS off, all ten panels list open.
Security Headers
- What it inspects
- HSTS · CSP · nosniff
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- HSTS present in the recipe, absent from the live response header.
- Boundary
- No pentest or server-patch guarantees; header readiness is evidenced.
- Related tool
- SecurityHeaders
TLS / HTTPS
- What it inspects
- encrypted transport
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- Certificate chain complete; TLS 1.0 still enabled.
- Boundary
- SSL Labs grades certificates; the engine classifies configuration readiness.
- Related tool
- SSL Labs
Technical SEO
- What it inspects
- meta · canonical · sitemap
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- Canonical tag missing on 22 pages.
- Boundary
- No ranking guarantee; signal hygiene is evidenced.
- Related tool
- Search Console
Structured Data
- What it inspects
- JSON-LD identity
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- Logo field empty in the Organization schema.
- Boundary
- Google decides rich results; schema validity is prepared.
- Related tool
- Rich Results
Accessibility
- What it inspects
- alt · label · heading
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- Alt text missing on 3 images; contrast borderline on one card.
- Boundary
- No certification claim; static AA-targeted readiness and expert items are separated.
- Related tool
- axe / WAVE
Performance
- What it inspects
- static readiness
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- LCP-candidate image is 1.9 MB; size attributes missing.
- Boundary
- No field CWV produced; static readiness is flagged, measurement left to CrUX/PageSpeed.
- Related tool
- PageSpeed
AI / GEO / AEO
- What it inspects
- readability
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- No llms.txt; identity sentence inconsistent across pages.
- Boundary
- No citation guarantee; readability and entity clarity are prepared.
- Related tool
- —
Privacy / Cookie
- What it inspects
- tracker visibility
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- Consent banner shown, yet no Set-Cookie produced — empty consent.
- Boundary
- No GDPR compliance guarantee; visible signals are classified.
- Related tool
- —
Code Security
- What it inspects
- secrets · exposure · patterns
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- API-key-shaped string inside a JS file.
- Boundary
- Static patterns are classified; this is not a pentest.
- Related tool
- —
Delivery
- What it inspects
- deployment hygiene
- Typical evidence
- File path + pattern + class; static, repeatable.
- Sample finding
- robots.txt sitemap line points at the old domain.
- Boundary
- Live operation is not guaranteed; it is proven via Deploy-Verify bridges.
- Related tool
- DNS / panel
DEEP DIVES
Four domains, in the engine's own words
Accessibility Readiness
The accessibility path: from automated detection to manual verification.
Accessibility is governed in two layers. The static layer belongs to the engine: alt presence and quality markers, form-label matching, heading order (H1→H2→H3), landmark structure (header/nav/main/footer), skip link, language attribute, table headers. This layer is fast, repeatable and objective.
The second layer is human and deliberately not automated: the context of a contrast decision, the real look of focus visibility, the meaning of reading order, the adequacy of media description. These WCAG items demand visual/auditory judgment; hence the manual-verification rule, and 'full WCAG compliance guarantee' appears in no text. The correct promise: static readiness + flagged manual items + clear routing to a reviewer.
- alt/label/heading/landmark/skip link
- language attribute + table semantics
- contrast readiness = manual
- no WCAG guarantee
What the engine does: Detects and fixes static accessibility signals.
Performance Readiness
Performance evidence on two shores: static readiness in the engine, live measurement in independent tools.
Static performance readiness means removing in-file blockers that cap a page's speed potential. The engine's territory: a compression/cache recipe (.htaccess), render-blocking script/CSS detection with defer suggestions, image format and dimension signals, lazy-loading markers, CSS/JS minify readiness.
What is not the engine's territory is written just as clearly: producing real field CWV, measuring user data, configuring the CDN itself, changing hosting resources. The first two are runtime bridges (PageSpeed/CrUX), the last two external actions (Cloudflare/hosting recipes). This triple split keeps performance talk from ever inflating into 'the engine made it fast'; it stays on the chain 'the engine prepared, live measurement verified, the infrastructure recipe was applied'.
- compression/cache recipe
- render-blocking + defer
- image format/lazy
- minify readiness
- CDN = external action
- CWV = not field measurement
What the engine does: Detects and prepares in-file speed blockers.
Privacy / Cookie Readiness
Privacy readiness starts with visibility: which trackers exist on the page, what runs before consent, which flags cookies carry, where the policy links are. This is the static counterpart of the Blacklight/Cookiebot approach, and the engine produces these signals.
The boundary sits in the same paragraph: the engine gives no legal-compliance guarantee; it is not KVKK/GDPR counsel. Visibility and readiness come from the engine; the compliance judgment comes from the legal layer. Public copy carries this duality in one sentence: 'tracker visibility and cookie readiness — not legal advice'.
- tracker visibility
- cookie banner readiness
- pre-consent markers
- no legal guarantee
What the engine does: Makes tracker/cookie signals visible.
What it doesn't: Makes no legal-compliance judgment.
Where evidence comes from
| Evidence type | Who produces it? |
|---|---|
| Static classification | The engine — 319 working checks |
| Live headers/pulls | Deploy-Verify bridges |
| Scores and grades | Independent tools: PageSpeed, SSL Labs, Search Console |
See your score, evidenced
A Review produces an evidenced baseline across all ten domains.