# EcoMark algorithm v4 | Methodology

Read the published criteria, weights and grading method used by EcoMark algorithm v4.

Canonical: https://ecomark.app/methodology/v4

Algorithm v4 · current

# How EcoMark scores a website.

[v1](/methodology/v1) [v2](/methodology/v2) [v3](/methodology/v3) [v4](/methodology/v4)

- Enter Add your website address.
- Crawl Eco checks your site.
- Analyse Measure the key signals.
- Grade Calculate your EcoMark using our algorithm.
- Improve Get simple steps how to improve.

Scoring

## Five areas. One grade.
Efficiency 25% Privacy 25% Sovereignty 20% Accessibility 15% Responsibility 15%

Grades

## A simple final band.
A
### 90–100
B
### 80–89
C
### 70–79
D
### 60–69
E
### 50–59
F
### 0–49

Algorithm v4

## The rules used for this version.

This is the published evidence scope, criterion scale, scoring formula and metric thresholds used by EcoMark v4.

### Evidence sample
Rendered homepage
### On
Connected page sample
### Up to 5
Policy page sample
### Up to 8
Asset sample
### Up to 16
DNS record types
### A, AAAA, CNAME, MX, NS, TXT
Green Web check
### On
Common-path probes
### Up to 20
PageSpeed-style diagnostics
### On
Browser security checks
### 6

### Criterion scale
4 · Strong Strong. The criterion is deliberately and consistently met. 3 · Good Good. The criterion is mostly met with only limited gaps. 2 · Mixed Mixed. Some good practice is present, but material gaps remain. 1 · Poor Poor. Significant problems or unnecessary impact remain. 0 · Fail Fails materially or creates clear harm in this criterion.
### Scoring formula

Stage | Published rule
Criterion points | criterion_points = max_points × level ÷ 4
Category score | category_score = sum(criterion_points)
Overall score | overall_score = round(sum(category_score × category_weight))
Ranking | competition ranking: equal scores share a rank and the next rank skips accordingly (1, 1, 3)
Comparison | rankings compare assessments produced by the same EcoMark version only
All criteria

## The 25 scoring rules.

Thresholds are applied from level 4 down to level 1. The first matching threshold wins; otherwise the criterion receives level 0.

25% of the final score

### Efficiency

Resource use, page weight and avoidable computation.

Criterion | Metric | 4 · Strong | 3 · Good | 2 · Mixed | 1 · Poor | 0 · Fail
Payload Measured HTML and sampled asset payload is proportionate and optimised. | average_page_kb Lower is better | ≤ 500 KB/page | ≤ 1000 KB/page | ≤ 2000 KB/page | ≤ 4000 KB/page | > 4000 KB/page
JavaScript Referenced JavaScript weight is kept proportionate. | average_javascript_kb Lower is better | ≤ 100 KB/page | ≤ 250 KB/page | ≤ 500 KB/page | ≤ 1000 KB/page | > 1000 KB/page
Requests Pages avoid excessive resource references and third-party connections. | average_resource_references Lower is better | ≤ 20 resources/page | ≤ 40 resources/page | ≤ 70 resources/page | ≤ 100 resources/page | > 100 resources/page
Media Images and video avoid obvious loading and autoplay waste. | media_issue_count Lower is better | ≤ 0 issues | ≤ 1 issues | ≤ 3 issues | ≤ 6 issues | > 6 issues
Caching and compression Sampled static assets expose effective cache policy. | cacheable_asset_percent Higher is better | ≥ 80% | ≥ 60% | ≥ 40% | ≥ 20% |
25% of the final score

### Privacy

Tracking, cookies, profiling, analytics and consent.

Criterion | Metric | 4 · Strong | 3 · Good | 2 · Mixed | 1 · Poor | 0 · Fail
Behavioural tracking Known advertising pixels and cross-site trackers are absent or minimised. | tracker_count Lower is better | ≤ 0 known trackers | ≤ 1 known trackers | ≤ 2 known trackers | ≤ 4 known trackers | > 4 known trackers
Analytics minimisation Analytics technology is absent or privacy-preserving and proportionate. | analytics_risk Lower is better | ≤ 0 risk level | ≤ 1 risk level | ≤ 2 risk level | ≤ 3 risk level | > 3 risk level
Cookies and consent Non-essential response cookies are avoided before interaction. | nonessential_cookie_count Lower is better | ≤ 0 response cookies | ≤ 1 response cookies | ≤ 3 response cookies | ≤ 6 response cookies | > 6 response cookies
Third-party disclosure Resource loading does not unnecessarily disclose visits to third parties. | third_party_percent Lower is better | ≤ 0% | ≤ 10% | ≤ 25% | ≤ 50% | > 50%
Invasive techniques Known session replay and similarly invasive tools are absent. | invasive_tracker_count Lower is better | ≤ 0 known invasive tools | ≤ 0 known invasive tools | ≤ 0 known invasive tools | ≤ 1 known invasive tools | > 1 known invasive tools
20% of the final score

### Sovereignty

Ownership, geography, openness, portability and dependency.

Criterion | Metric | 4 · Strong | 3 · Good | 2 · Mixed | 1 · Poor | 0 · Fail
Provider jurisdiction Observable visitor-facing dependencies minimise reliance on US-headquartered platform ecosystems. | us_provider_count Lower is better | ≤ 0 visitor-facing provider ecosystems | ≤ 1 visitor-facing provider ecosystems | ≤ 3 visitor-facing provider ecosystems | ≤ 6 visitor-facing provider ecosystems | > 6 visitor-facing provider ecosystems
Third-party geography Known non-EU third-party data exposure is minimised. | known_non_eu_data_percent Lower is better | ≤ 0% | ≤ 10% | ≤ 30% | ≤ 60% | > 60%
Portable delivery Pages minimise proprietary embeds and platform-specific content dependencies. | proprietary_embed_count Lower is better | ≤ 0 embeds | ≤ 1 embeds | ≤ 3 embeds | ≤ 6 embeds | > 6 embeds
Supplier concentration Third-party resource loading is not dominated by one provider ecosystem. | top_provider_share_percent Lower is better | ≤ 0% | ≤ 40% | ≤ 65% | ≤ 85% | > 85%
Open technology Open standards, first-party delivery, open-source technology and public source code are preferred where practical. | open_technology_score Higher is better | ≥ 90 openness score | ≥ 75 openness score | ≥ 60 openness score | ≥ 40 openness score |
15% of the final score

### Accessibility

Inclusive, semantic and resilient implementation.

Criterion | Metric | 4 · Strong | 3 · Good | 2 · Mixed | 1 · Poor | 0 · Fail
Semantics HTML exposes basic language, heading and landmark structure. | semantic_issue_count Lower is better | ≤ 0 issues | ≤ 1 issues | ≤ 2 issues | ≤ 4 issues | > 4 issues
Keyboard access Markup avoids obvious keyboard-hostile interaction patterns. | keyboard_issue_count Lower is better | ≤ 0 issues | ≤ 1 issues | ≤ 3 issues | ≤ 6 issues | > 6 issues
Forms and controls Form controls expose labels or accessible names. | unlabelled_control_percent Lower is better | ≤ 0% | ≤ 5% | ≤ 15% | ≤ 30% | > 30%
Visual accessibility Viewport and media markup avoid obvious visual accessibility barriers. | visual_issue_count Lower is better | ≤ 0 issues | ≤ 1 issues | ≤ 2 issues | ≤ 4 issues | > 4 issues
Resilience Meaningful text remains present without relying entirely on client rendering. | raw_text_ratio_percent Higher is better | ≥ 80% | ≥ 60% | ≥ 40% | ≥ 20% |
15% of the final score

### Responsibility

Transparency, security basics and responsible choices.

Criterion | Metric | 4 · Strong | 3 · Good | 2 · Mixed | 1 · Poor | 0 · Fail
Public accountability Privacy, terms, accessibility, contact and applicable registration information are discoverable. | transparency_evidence_score Higher is better | ≥ 90 evidence score | ≥ 75 evidence score | ≥ 55 evidence score | ≥ 35 evidence score | 3 risk level
Supplier disclosure Detected material visitor-facing providers are reflected in discoverable privacy information. | undisclosed_provider_percent Lower is better | ≤ 0% | ≤ 25% | ≤ 50% | ≤ 75% | > 75%
Sustainability evidence Green hosting, carbon.txt and public sustainability information provide discoverable evidence of digital sustainability practice. | sustainability_evidence_score Higher is better | ≥ 4 evidence signals | ≥ 3 evidence signals | ≥ 2 evidence signals | ≥ 1 evidence signals |

Version history

## What changed from v3?

This comparison is generated from the published v3 and v4 algorithm definitions.
1
### Evidence collection

- Connected page sample: Up to 3 → Up to 5
- Policy page sample: Up to 5 → Up to 8
- Common-path probes: Not used → Up to 20
- PageSpeed-style diagnostics: Not used → On
- Browser security checks: Not used → 6 2
### Scoring rules

- Responsibility · Security basics: security_header_count → security_header_score; thresholds 5/4/3/2 → 100/83/67/50; headers → % basic browser protections

Versioning

## Scoring changes get a new version.

Historical results keep the algorithm that produced them.

Limits

## What EcoMark knows, estimates and does not claim.

Automated website analysis has limits. EcoMark separates direct public observations from inference and unknowns.

Confidence | What this means
Observed | Public HTTP responses, headers, HTML, rendered homepage content, connected URLs, DNS, discoverable public policy/sitemap files and known technical signatures that EcoMark can actually retrieve.
Estimated or inferred | Algo v4 page weight and JavaScript are based on HTML plus a bounded sample of asset response metadata. Provider, jurisdiction, consent and some accessibility findings use published rules and known-pattern matching. These can be useful without being certain.
Not claimed | EcoMark does not know actual visitor traffic, every page on a site, exact data-processing locations, full legal/privacy/accessibility compliance, exact carbon emissions, private supplier contracts or whether an organisation itself is ethical.