Auditierung digitaler Emissionen

Digitale Emissionen lassen sich als Schätzung mit definierten Systemgrenzen berichten. Ein Wert in Gramm CO₂-Äquivalent (gCO₂e) pro Seitenaufruf oder pro API-Aufruf verlangt Zeitraum, funktionale Einheit, Datenquellen, Emissionsfaktoren und Unsicherheit. Das Sustainable Web Design Model (SWDM) schätzt für digitale Produkte Rechenzentrum, Netz, Endgeräte sowie betriebliche und verkörperte Emissionen. Es misst keinen physikalischen Fußabdruck einer einzelnen URL.

Dieser Beitrag gilt für Websites, Webanwendungen und die von ihnen ausgelösten Infrastrukturleistungen. Er behandelt den Stand der Quellen vom 11. September 2026. Er ersetzt keine Treibhausgasbilanz nach einer rechtlichen Berichtspflicht und keine Prüfung durch Wirtschaftsprüfung, Rechtsberatung oder zuständige Stellen.

Ein Emissionsaudit beantwortet vier Fragen: Welche digitale Leistung zählt? Wo endet das System? Welche Daten tragen die Schätzung? Wie lässt sich der Wert später nachvollziehen? Erst danach ergibt eine Kennzahl Sinn.

Eine Website-Messung kann eine technische Entscheidung stützen. Das Ergebnis bildet keine allgemeingültige Aussage über die Klimawirkung eines Unternehmens. Das gilt für Werte aus Werkzeugen, die keinen direkten Zugriff auf Hosting-, Energie- oder Betriebsdaten besitzen.

Was ein Emissionsaudit erfasst

Das SWDM nutzt die übertragene Datenmenge als Näherung. Version 4 verteilt die geschätzte Systemenergie auf Rechenzentren, Netze und Endgeräte. Das Modell berücksichtigt betriebliche und verkörperte Emissionen sowie Annahmen zu neuen und wiederkehrenden Besuchen und zum Cache. Datenübertragung eignet sich als Vergleichsgröße für dieselbe Seite unter derselben Methode. Das Verfahren ersetzt keine Messung am Stromzähler.

Für Software mit Betriebsdaten eignet sich die Software Carbon Intensity Specification (SCI) als Modell. Die Spezifikation teilt die Gesamtemissionen durch eine funktionale Einheit R, etwa einen API-Aufruf, eine Transaktion oder einen Nutzer. In der Formel SCI = (O + M) / R steht O für betriebliche Emissionen aus Energieverbrauch und ortsbezogener Stromintensität. M steht für den zeit- und ressourcenanteiligen Hardwareanteil. Teams behalten die Einheit über Vergleichszeiträume bei.

Die Einordnung von Green SEO und digitale Nachhaltigkeit trennt die technische Website-Arbeit von der Unternehmensbilanz. Die W3C Web Sustainability Guidelines (WSG) ergänzen das Audit um technische Prüfpunkte. Die WSG-Leitlinien bilden einen W3C Group Note Draft, keine verbindliche Rechtsnorm. Der Entwurf rät zu messbaren Leistungs- und Umweltzielen sowie zu geringerer Datenübertragung und Rechenlast.

Ablauf: vom Messzweck zum Bericht

1. →Leistung und Grenze festlegen: Benenne die funktionale Einheit vor der Datenerhebung: zum Beispiel „Seitenaufruf des Beitrags“, „Checkout“ oder „100 API-Aufrufe“. Halte fest, ob nur Hosting und Datenübertragung zählen oder auch Endgeräte, Hardware, Build-Pipeline und Backups. Eine breite und eine enge Grenze dürfen nicht in derselben Zeitreihe landen.
2. →Daten nach Herkunft ordnen: Ziehe primäre Betriebsdaten vor: Hosting-Abrechnung, Cloud-Telemetrie, CDN-Logs, Build-Logs und gemessene Bytes. Ergänze Lücken mit benannten Modellwerten. Schreibe für jeden Faktor Quelle, Abrufdatum, Region, Zeitraum und Einheit auf.
3. →Passendes Modell wählen: Nutze das SWDM für eine auf Datenübertragung gestützte Website-Schätzung. Nutze SCI für eine Softwareleistung, wenn Energie, Stromintensität, Hardwareanteil und funktionale Einheit vorliegen oder modelliert werden. Mische beide Ergebnisse nicht zu einem neuen Wert. Schließe Überschneidungen vorher aus.
4. →Grundlinie und Änderungen vergleichbar halten: Messe vor und nach einer Änderung mit gleicher URL-Gruppe, gleichem Modell, gleicher Einheit und gleichem Berichtszeitraum. Ändert sich ein Faktor (etwa Stromintensität oder Cache-Annahme), dokumentierst du die Änderung neben dem Ergebnis.
5. →Ergebnis mit Unsicherheit berichten: Veröffentliche nicht nur eine einzelne Zahl. Nenne Systemgrenze, abgedeckte Komponenten, Anteil primärer Daten, Annahmen, Ausschlussgründe und die verantwortliche Rolle.

Ein Bericht trennt eine Schätzung pro funktionaler Einheit von der Hochrechnung für einen Zeitraum. Für die Hochrechnung multipliziert ein Team den Einheitenwert mit einer passend definierten Menge, etwa gemessenen Aufrufen derselben URL-Gruppe. Bei einem Modellwechsel hält es die frühere Reihe getrennt oder rechnet sie mit der neuen Methode nach.

Prüfkriterien für Daten und Bericht

Die SCI verlangt, Softwaregrenze, funktionale Einheit und Quantifizierungsmethode offenzulegen. Das Verfahren bevorzugt feingranulare Daten. Fehlen diese Daten, erlaubt die Regel Modellwerte bei voller Transparenz. Ein Herkunftsnachweis für Strom oder ein Kompensationsgeschäft senkt einen SCI-Wert nicht, weil die Spezifikation zur Bewertung physisch vermiedener Emissionen ortsbezogene Stromintensität nutzt und marktbasierte Maßnahmen ausschließt.

Scope 3 und CSRD richtig abgrenzen

Digitale Emissionen besitzen keine feste Scope-3-Kategorie. Die Zuordnung richtet sich nach der Organisation, die berichtet, und nach ihrer Wertschöpfungskette. Kauft ein Unternehmen Hosting, Cloud-Kapazität oder IT-Support ein, gehören die vorgelagerten Emissionen dieser eingekauften immateriellen Leistungen grundsätzlich zu Kategorie 1 „Purchased Goods and Services“, sofern keine speziellere vorgelagerte Kategorie greift.

Verkauft ein Unternehmen eine digitale Leistung, die bei Kundinnen und Kunden unmittelbar Strom verbraucht, kann Kategorie 11 „Use of Sold Products“ relevant sein. Die GHG-Protocol-Leitlinie nennt webbasierte Software als Beispiel für Produkte mit direkten Nutzungsphase-Emissionen. Das Dokument verlangt für diese Kategorie Annahmen zu Nutzung und Lebensdauer sowie eine Beschreibung der Methode. Ob eine Unternehmenswebsite oder ein kostenfreier Inhalt darunter fällt, entscheidet die dokumentierte Bilanzgrenze. Die Formel „Website = Scope 3 Kategorie 11“ greift vor einer Einzelfallprüfung zu kurz.

Die CSRD verpflichtet Unternehmen im jeweiligen Anwendungsbereich. Die EU-Kommission beschreibt Nachhaltigkeitsberichte nach ESRS als Berichte über Risiken, Chancen und Auswirkungen. Die Richtlinie (EU) 2025/794 verschob die Anwendung für Unternehmen der früheren zweiten und dritten Welle um zwei Jahre auf Geschäftsjahre ab 2027 beziehungsweise ab 2028. Am 3. Juli 2026 nahm die Kommission überarbeitete ESRS an.

Daraus folgt: Ein Web-Emissionswert erfüllt keine CSRD-Pflicht für sich. Erst eine Wesentlichkeitsprüfung, die anwendbaren ESRS, die Bilanzgrenze und die geforderten Angaben bestimmen, ob und wie ein Unternehmen Emissionen berichtet. Der geltende ESRS E1 enthält Anforderungen zu Bruttoemissionen der Scopes 1, 2 und 3, einschließlich Übergangsregeln.

Google-Daten, KI-Suche und digitale Emissionen

Google Search Console und Chrome UX Report liefern keine CO₂e-Messung. Core Web Vitals messen reale Nutzererfahrungen für Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität über LCP, INP und CLS. CrUX fasst Daten berechtigter Chrome-Nutzungen zusammen. Nicht jede URL und nicht jede Domain erscheint dort, weil Google öffentliche Auffindbarkeit und ausreichend Daten voraussetzt.

Die Daten der Werkzeuge helfen bei der Einordnung: Die Messwerte zeigen, welche Seiten oder Nutzungserfahrungen Teams neben ihrem Emissionsmodell prüfen. Die Zahlen beweisen nicht, wie viel Energie eine Seite verbraucht. Der Beitrag Core Web Vitals und mobile Nutzbarkeit prüft diese Leistungsdaten getrennt vom Emissionsmodell. Für die Verbindung von organischem Bedarf, Kosten und Kennzahlen führt die SEO-Erfolgsmessung weiter.

Auch die KI-Suche schafft keine eigene Emissionskennzahl für eine Website. Google ordnet Klicks und Impressionen aus AI Overviews und AI Mode im Performance-Bericht der Search Console dem Suchtyp „Web“ zu. Google verlangt für diese Funktionen weder spezielles Markup noch zusätzliche technische Voraussetzungen. Nutze Suchdaten als dokumentierten Nenner für eine Reichweitenanalyse. Rechne daraus keine Energie oder Emissionen, solange keine passende Betriebs- und Modellgrundlage vorliegt.

DPP: Produktdaten sind kein Web-Emissionsbericht

Der Digitale Produktpass (DPP) speichert produktbezogene Informationen für Produkte, Komponenten und Materialien. Seine Rechtsgrundlage ist die Ökodesign-Verordnung (EU) 2024/1781. Pflichten entstehen je Produktgruppe über delegierte Rechtsakte oder sektorspezifisches EU-Recht. Der DPP rollt schrittweise aus; das System verlangt nicht allgemein einen Wert für den Emissionsfußabdruck einer Website.

Verknüpfe Website- oder Softwarewerte nur dann mit einem DPP, wenn der einschlägige Rechtsakt die Information verlangt und Datenmodell, Zugriffsrechte, Prüfbarkeit und Aktualisierungsrhythmus feststehen. Der DPP kann Produktdaten zugänglich machen. Der Pass ersetzt weder das Scope-3-Inventar noch eine Messmethode für den Betrieb digitaler Dienste.

Grenzen des Audits

Ein Modellwert wird nicht dadurch genauer, dass er mehr Dezimalstellen trägt. Das SWDM weist darauf hin, dass breite Systemgrenzen Über- oder Unterschätzungen erzeugen können und dass Datenübertragung ein Näherungswert bleibt. Veränderungen bei Gerät, Netz, Standort, Strommix, Cache, Drittanbieter-Skripten und Besuchsverhalten können das Ergebnis verschieben.

Ein Audit darf keine Kausalität behaupten, die seine Daten nicht tragen. Weniger übertragene Bytes können die angenommene Emissionsintensität senken. Die Reduktion belegt abseits zusätzlicher Messungen weder den absoluten Stromverbrauch eines Nutzers noch eine Wirkung auf Umsatz, Ranking oder CSRD-Pflicht. Die W3C-Leitlinien unterstützen eine fortlaufende Prüfung messbarer Ziele. Der Entwurf liefert keinen gesetzlichen Grenzwert für gCO₂e pro Seitenaufruf.

Häufige Fragen zu digitalen Emissionen

Reicht ein CO₂-Rechner für einen Nachhaltigkeitsbericht?

Nein. Ein Rechner liefert eine technische Schätzung. Für einen Bericht brauchst du zusätzlich Bilanzgrenze, Zeitraum, Datengrundlage, Rechenweg, Annahmen, Unsicherheit und eine Zuordnung zur berichtenden Organisation.

Gehört Hosting immer in Scope 3 Kategorie 1?

Aus Sicht eines Unternehmens, das eine Hosting- oder Cloud-Leistung einkauft, ist Kategorie 1 häufig der Ausgangspunkt. Prüfe dennoch, ob eine andere vorgelagerte Kategorie genauer passt und ob Vertrag, Betriebsgrenze oder lokale Bilanzierungsregeln etwas ändern.

Kann Core Web Vitals ein Emissionsbudget ersetzen?

Nein. LCP, INP und CLS beschreiben Nutzererfahrungen. Die Metriken enthalten weder Energieverbrauch noch Stromintensität oder Hardwareanteile. Nutze sie neben, nicht anstelle eines Emissionsmodells.

Muss ein DPP Werte für die Website ausweisen?

Nein. Ein DPP folgt produkt- und rechtsaktbezogenen Anforderungen. Ob ein Datenpunkt nötig ist, entscheidet der anwendbare delegierte oder sektorale Rechtsakt, nicht die Existenz einer Unternehmenswebsite.

Darf ein Team die Schätzung als „CO₂-neutral“ bezeichnen?

Eine Modellschätzung allein trägt diese Aussage nicht. Die SCI zählt Kompensation und andere marktbasierte Maßnahmen nicht als Senkung ihrer Kennzahl. Formuliere stattdessen, was die Rechnung unter welchen Annahmen geschätzt hat.

Nächster Schritt

Lege für eine URL-Gruppe oder eine abgegrenzte Softwareleistung eine funktionale Einheit, die Systemgrenze und den Berichtszeitraum fest. Erfasse danach die vorhandenen Primärdaten und kennzeichne jede Modellannahme. Für Architektur, Datenübertragung und technische Betriebsdaten unterstützt eine Jamstack-Website ab 224 € für schlanke, wartbare Webarchitektur.

Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen

Sandra Krone und Michael Kienzler | Seriöse Suchmaschinenoptimierung aus Stuttgart | Seit 2018

Über den Autor: Sandra Krone

Sandra Krone ist Partnerin und Gründerin von OLDSCHOOLSEO. Ihre Arbeit beginnt bei der Analyse der Nutzerintention und der Content-Strategie, um daraus die Anforderungen für die redaktionelle und technische Umsetzung abzuleiten.

Mehr über die GründerProfil auf LinkedIn