A website sustainability audit is a systematic assessment of every factor that determines how much energy your website consumes and how much CO₂ it emits. Not a badge generator, not a single score from a free tool — a structured process that produces a defensible baseline, identifies the highest-leverage improvements, and generates documentation you can hand to an auditor, a sustainability director, or a procurement team without cringing.

I run these for clients. What follows is the actual framework, not a sanitised version of it.

The first thing most people get wrong: they treat the carbon measurement as the audit. It is not. It is step one. A real website sustainability audit covers ten distinct areas, and the carbon number you get from a tool like the Carbon Badge scanner is the starting point of the investigation, not its conclusion.

Who Needs a Website Sustainability Audit?

Three groups have clear reasons to do this properly.

CSRD-affected companies. The EU Corporate Sustainability Reporting Directive is already in force for large public-interest entities (250+ employees, €40M+ turnover, or €20M+ balance sheet) and will reach mid-size companies by 2026. CSRD requires reporting on Scope 3 emissions — indirect emissions from your value chain — and digital operations sit squarely in Scope 3. Roughly 50,000 EU companies fall into the mandatory reporting scope by 2028. If your legal team has mentioned CSRD, your website is part of the answer.

B Corps and certification-track companies. B Corp assessment includes digital infrastructure considerations under Scope 3. A company pursuing certification without documented digital emissions data will hit gaps during the assessment process. Companies already certified need to demonstrate improvement across reporting periods — which requires a baseline.

Sustainability-conscious brands with credibility concerns. A company that publishes a sustainability report while running a 3 MB homepage loaded with tracking pixels has a gap between stated values and operational reality. Sustainability buyers — an increasingly significant demographic — notice. A documented audit with a reduction roadmap is the difference between a claim and a commitment.

That said, any organisation that has made a net-zero or carbon reduction commitment has a practical reason to know what their website emits. Digital is rarely the largest source, but it is among the most fixable.

The Audit Framework: Ten Assessment Areas

1. Carbon Measurement (SWDM v4)

Start with a quantified baseline. The Sustainable Web Design Model v4 — the methodology published by Wholegrain Digital and used by Carbon Badge and most credible tools — maps page weight in bytes to kilowatt-hours to grams of CO₂. The formula:

CO₂ (g) = page_weight_GB × 0.194 kWh/GB × 494 gCO₂/kWh × (1 − green_factor)

Where green_factor = 0.243 if your host uses verified renewable energy. The 0.194 figure aggregates energy consumption across data centres (0.055 kWh/GB), network transmission (0.059 kWh/GB), and end-user devices (0.080 kWh/GB). The 494 gCO₂/kWh is the Ember Climate global average grid carbon intensity.

Run the scan on your five most-trafficked pages — not just the homepage. Product pages, blog posts, and landing pages often carry dramatically different weights. I have seen clients with a Grade B homepage and Grade E product pages. The average is what matters for total emissions, and you need per-page data to prioritise remediation correctly. For more on interpreting these scores, the website carbon footprint explainer covers the grade scale and what each range means.

Record: page weight (KB), CO₂ per pageview (g), letter grade (A–F), and monthly pageviews per page. This gives you a weighted average emissions figure for the whole site.

2. Green Hosting Verification

The single-highest-leverage change available — with zero code changes required — is migrating to a hosting provider verified as renewable by the Green Web Foundation. That verification applies a 24.3% reduction to your calculated CO₂ in the SWDM v4 formula. On a site emitting 1.0g CO₂ per pageview, that is a 0.24g reduction from a hosting change alone.

In the audit, check: does your current host appear in the Green Web Foundation database? If not, document the gap and identify verified alternatives (Infomaniak, Hetzner, Google Cloud, AWS, and others are commonly verified). If yes, verify that the specific data centre region where your site is hosted is covered — some providers are verified in EU regions but not in US ones, or vice versa.

This is also where you document your hosting provider's Power Usage Effectiveness (PUE) if available. A PUE of 1.1 (10% overhead for cooling and infrastructure) is excellent; 1.5 is mediocre; 2.0 means the facility uses as much energy for overhead as it does for actual computation. Enterprise hosting tenders increasingly ask for PUE figures — knowing yours matters.

3. Performance Analysis (Core Web Vitals)

Core Web Vitals are Google's user experience metrics, but they are also your best proxy for device-side energy consumption. The user's device — phone, laptop, tablet — draws power to render your page, execute your JavaScript, and maintain the display. Faster rendering means less CPU time, which means less energy drawn from the battery or the wall.

The metrics to record:

  • LCP (Largest Contentful Paint): time for the main content element to load. Target: under 2.5 seconds.
  • INP (Interaction to Next Paint): replaced FID in March 2024. Measures responsiveness to user input. Target: under 200ms.
  • CLS (Cumulative Layout Shift): visual stability. Target: under 0.1. Layout shifts force browsers to recalculate and repaint, consuming additional CPU cycles.
  • TBT (Total Blocking Time): not a Core Web Vital but a strong indicator of JavaScript execution cost. High TBT correlates directly with high CPU energy consumption.

Run Google Lighthouse on your key pages and record the Performance score alongside the individual metric values. A Performance score below 50 on mobile almost always indicates significant energy waste — the same inefficiencies that frustrate users are burning electricity on their devices. The correlation between Lighthouse scores and SWDM v4 grades is strong enough that I use Lighthouse failures as diagnostic signals pointing toward specific carbon reduction opportunities.

4. Resource Efficiency: Page Weight Breakdown

Open Chrome DevTools Network panel on each key page. Filter by resource type and record:

  • Total page weight (transferred, not uncompressed)
  • Image payload (KB transferred)
  • JavaScript payload (KB transferred)
  • CSS payload (KB transferred)
  • Font payload (KB transferred)
  • Number of HTTP requests

The HTTPArchive Web Almanac benchmarks are your comparison point. Median desktop in 2024: ~2.3 MB total, ~1.1 MB images, ~550 KB JavaScript. If your numbers are above median in any category, that is a documented remediation opportunity.

Pay particular attention to the Coverage tab (Ctrl+Shift+P → Coverage in DevTools). This shows you the percentage of loaded JavaScript and CSS that is actually executed during a page load. Unused code rates above 40% are common — and every unused byte still costs energy to transfer and parse. I have found clients shipping 600 KB of JavaScript where 55% was never executed on the page being audited. That is 330 KB of pure waste, and fixing it requires no design changes whatsoever.

5. Third-Party Script Audit

Third-party scripts — analytics, chat widgets, advertising pixels, A/B testing tools, social embeds — frequently account for 30–50% of page weight and a disproportionate share of JavaScript execution time. They are also the category where the least scrutiny is applied during development, because they arrive via a one-line snippet and are invisible in your own bundle analysis.

Build an inventory. For each third-party script on each key page, record:

  1. What it does (analytics, CRM tracking, chat, advertising, etc.)
  2. Its weight (KB transferred)
  3. Whether it is render-blocking (does it appear in the critical path?)
  4. The business owner responsible for it
  5. The measurable business value it delivers

That last column is the uncomfortable one. Many scripts were added by someone who left the company three years ago, continue running, and nobody can articulate what decision they inform. A well-run third-party audit typically finds 2–4 scripts per site that can be removed immediately with zero business impact. A single removed chat widget can cut 150–200 KB from every page load.

For scripts that stay, document whether they are loaded asynchronously and whether loading can be deferred until user interaction rather than firing on page load.

6. Image Optimisation Assessment

Images account for roughly 50% of median page weight. The image audit covers four questions for each significant image on your key pages:

Format: Is it WebP or AVIF? JPEG and PNG have no place on a modern optimised page except as final fallbacks. WebP delivers 25–35% better compression than JPEG at equivalent quality; AVIF goes to 50%. Both have browser support above 95% globally.

Dimensions: Is the image sized for the viewport it is displayed in, or is a 1200px-wide image being served to a 375px mobile screen? The srcset and sizes attributes exist for this. Oversized images on mobile are among the most common and most fixable audit findings.

Lazy loading: Do below-the-fold images carry loading="lazy"? One attribute, no JavaScript, browser support since 2019. If images below the fold lack it, bytes are being transferred that many users will never see.

Compression level: Use Squoosh or similar to check whether further compression is possible at equivalent visual quality. Target: photographs under 100 KB, icons under 20 KB, hero images under 150 KB.

7. Caching and Compression

Two server-side checks that often reveal quick wins requiring no design or content changes.

For compression: run curl -H "Accept-Encoding: br" -I https://yourdomain.com/ | grep content-encoding. If the response shows gzip rather than br, you are using the older algorithm. Brotli achieves 15–25% better compression than Gzip on typical web assets. If there is no content-encoding header at all, compression is missing entirely — a severe finding that affects every text-based resource on the site.

For caching: check the Cache-Control headers on static assets (CSS, JS, images, fonts). Static assets with content-hashed filenames should carry Cache-Control: public, max-age=31536000, immutable. If they show no-cache or short TTLs, every return visit is transferring assets the browser already has. For a site with 40% returning visitors, poor cache configuration can double the effective emissions per user session compared to what a single-visit measurement would suggest.

Document: compression algorithm in use, whether Brotli is active, cache TTL for key asset types, estimated returning visitor rate (from analytics) to contextualise the cache impact.

8. Accessibility Overlap

This connection is underappreciated: the technical fixes that reduce a website's carbon footprint are largely identical to the fixes that improve accessibility. Lighter pages load faster on lower-powered devices and slower connections — which is where users with disabilities and users in lower-income markets are disproportionately represented. Proper semantic HTML (which helps screen readers) is also easier for browsers to parse efficiently. Reduced JavaScript reduces cognitive and motor barriers for users who interact via keyboard or switch controls.

In the audit, run an automated accessibility check (axe, WAVE, or Lighthouse's Accessibility audit) and note the overlap: every image missing an alt attribute is both an accessibility failure and a signal that the image workflow lacks quality control. Every missing form label is both a WCAG violation and an indicator that the front-end codebase is not being reviewed systematically. Accessibility and carbon share the same root cause: insufficient attention to page quality.

For CSRD reporting, accessibility is also a social dimension (the S in ESG) — documenting the overlap between environmental and social improvements from the same technical changes strengthens the reporting narrative.

9. Dark Mode and OLED Considerations

On OLED and AMOLED screens — which account for a substantial share of modern smartphones — a black pixel draws roughly six times less power than a white pixel. Dark-mode interfaces have measurable energy benefits at the device level. This is not the highest-priority item in an audit, but it is a documented finding worth including.

Check: does the site implement prefers-color-scheme: dark in CSS? Does the dark theme use near-black backgrounds (OLED-optimised) rather than dark grey (which still draws significant power)? Is the dark mode opt-in via user preference, or forced? A site that respects the OS-level dark mode preference serves a measurable energy benefit to the significant fraction of users who have it enabled — without making any design decision about the default experience.

10. Reporting and Documentation for CSRD/ESG

The audit findings only have value if they are documented in a format that can be used in sustainability reporting. For CSRD, what you are reporting is a Scope 3 emission from your value chain — specifically, the electricity consumed by your digital infrastructure to serve users.

What CSRD actually requires for digital is not yet fully codified in specific technical standards, but the direction is clear from the European Sustainability Reporting Standards (ESRS): material emissions sources must be identified, quantified, and tracked over time. A website serving millions of pageviews annually is a material source for many affected companies. The methodology you use for quantification must be disclosed and consistent between reporting periods.

That means: use SWDM v4 (a published, citable standard), record your page weight and CO₂ per pageview figures at a fixed date, multiply by annual pageview data from GA4 or equivalent, and document the methodology. Total annual website CO₂ (in kg or tonnes) is the figure that enters your Scope 3 inventory. For the full regulatory context, the website carbon footprint guide covers what CSRD and REEN law require at the digital level.

Sample Audit Report Structure

A deliverable audit report should include the following sections, in roughly this order:

Executive Summary — Current CO₂ per pageview (weighted average across key pages), overall grade, estimated annual emissions in kg CO₂, top three findings, and a priority recommendation.

Scope and Methodology — Pages audited, audit date, tools used (Carbon Badge for SWDM v4 measurement, Lighthouse for performance, Chrome DevTools for resource analysis), and the SWDM v4 formula with coefficient sources cited.

Per-Page Carbon Inventory — A table with page URL, page weight (KB transferred), CO₂ per pageview (g), grade, monthly pageviews, and estimated monthly CO₂ (g × pageviews).

Hosting Assessment — Provider name, Green Web Foundation status (verified / not verified), data centre region, PUE if available, and recommendation.

Resource Efficiency Findings — Image assessment (formats in use, oversizing, lazy loading gaps), JavaScript assessment (total payload, unused code percentage, third-party inventory), compression status, cache configuration.

Core Web Vitals Summary — LCP, INP, CLS, TBT for each key page, Lighthouse Performance score.

Remediation Roadmap — Findings sorted by estimated impact (CO₂ reduction × effort), with owners assigned and target dates. High-impact, low-effort items first: usually image optimisation, Brotli compression, cache header corrections, and removal of unnecessary third-party scripts.

CSRD/ESG Data — Annual CO₂ calculation (weighted average g/pageview × annual pageviews), methodology statement suitable for inclusion in a sustainability report, and baseline date for future period-over-period comparison.

DIY vs. Hiring a Professional: Where the Line Is

The tools available today make a competent DIY audit achievable for organisations with a developer on staff. The Carbon Badge scanner, Google Lighthouse, Chrome DevTools, and the Green Web Foundation database are all free. If someone can run those tools and interpret the results, the ten-area framework above is a complete guide to what to check.

Hire a professional when:

  • The audit output will be used in external sustainability reporting (CSRD, GRI, CDP). An external auditor adds independence and defensibility that internal work cannot provide.
  • You need SWDM v4 figures in a format your ESG reporting team can directly incorporate into a Scope 3 inventory. The methodology documentation and data chain need to be airtight.
  • The site is large (100+ key pages) and systematic coverage requires tooling beyond manual per-page audits.
  • The findings will be used for procurement responses — public sector tenders in France, the Netherlands, and the UK are increasingly asking suppliers for digital sustainability metrics.
  • Your internal team lacks the technical background to diagnose third-party script impact or interpret coverage data from DevTools correctly.

For most mid-size companies doing their first audit as CSRD preparation, a one-time professional audit followed by self-maintained quarterly monitoring is the right balance. The professional audit sets the methodology baseline and produces defensible documentation; ongoing monitoring via a tool like Carbon Badge catches regressions without requiring a full audit budget each quarter. The Business and Enterprise plans are designed for exactly this multi-domain, ongoing monitoring use case.

The Tools You Need

A complete audit toolkit requires four tools, all of which are either free or included in a Carbon Badge subscription:

Carbon Badge — SWDM v4 measurement, Green Web Foundation hosting check, letter grade, and ongoing monitoring. Free for up to three sites; Pro and above for unlimited sites, API access, and multi-domain reporting. Use the scanner for one-off measurement; the dashboard for recurring monitoring.

Google Lighthouse — Performance, accessibility, SEO, and best-practice audits. Built into Chrome DevTools (F12 → Lighthouse tab). Run in incognito mode to avoid extension interference. Produces LCP, INP, CLS, TBT, and the Performance score you need for the Core Web Vitals section of the report.

WebPageTest — More detailed waterfall analysis than Lighthouse, particularly useful for diagnosing third-party script loading order and identifying render-blocking resources. Free at webpagetest.org. Run tests from a location close to your primary user base.

Chrome DevTools — Network panel for resource inventory, Coverage tab for unused code analysis, and the Application tab for cache header inspection. Everything you need for sections 4, 5, 6, and 7 of the audit is here, at zero cost.

For methodology context and the SWDM v4 formula in full technical detail, the SWDM v4 explainer is the reference document to cite in your audit methodology section. For a direct comparison of how Carbon Badge and alternatives differ in approach and scope, the tool comparison guide covers the key differences. And once the audit is complete and you have a remediation roadmap, the reduction guide covers each technical fix in detail with before-and-after numbers.

How Often to Audit

A full ten-area audit is a significant piece of work. Repeating it annually makes sense for most organisations — once per sustainability reporting period. But the carbon measurement component should run continuously, or at minimum quarterly, because page weight changes with every significant deployment. A CMS plugin update, an embedded video added by a content editor, a new marketing script approved without technical review — any of these can push a Grade B page to Grade D between annual audits.

Automated monitoring through Carbon Badge or a similar tool is what catches those regressions before they accumulate into a problem that requires a full remediation sprint. Monthly automated scans on your twenty most-trafficked pages costs nothing on Carbon Badge's free tier for sites under three URLs, and very little on Pro for larger portfolios. That continuous baseline is what makes your annual full audit meaningful rather than a one-time exercise in numbers you immediately abandon.

The audit framework above is the methodology. Running it once is a starting point. Running it as a cycle — audit, remediate, monitor, audit again — is a sustainability programme.