W3C Web Sustainability Guidelines technisch prüfen

Die Web Sustainability Guidelines (WSG) geben Teams einen prüfbaren Arbeitsrahmen für nachhaltigere digitale Produkte, begründen aber weder eine Rechtskonformität noch eine verlässliche Emissionszahl. Der W3C-Stand vom 20. August 2026 ist ein Group Note Draft. Er bündelt Ziele, Erfolgskriterien und Erläuterungen für User Experience, Webentwicklung, Hosting sowie Produktsteuerung. Eine WSG-Aussage muss deshalb stets den geprüften Umfang, die erfüllten Kriterien, das Datum und die Nachweise nennen.

Was ein WSG-Audit prüft

Ein WSG-Audit prüft nicht, ob eine Website pauschal nachhaltig ist. Es prüft einzelne Erfolgskriterien an einer benannten Website, Funktion oder Auslieferungskette. Dazu gehören etwa ungenutzter Code, schwere oder unkontrollierte Medien, externe Dienste, Datenbankabfragen, Caching, Infrastrukturdaten und Nutzerwege.

Für die Arbeitspraxis gilt eine Trennung:

Die WSG betrachten Planet, People und Prosperity gemeinsam. Energie und Treibhausgase bilden dabei nur einen Teil der Umweltwirkung. Der Entwurf nennt außerdem Materialeinsatz, Elektroschrott, Wasser und chemische Belastungen. Er weist zugleich auf Datenlücken und Zielkonflikte hin.

Der Green-SEO-Hub zu digitaler Nachhaltigkeit ordnet diese Arbeit in Strategie und Governance ein. Diese Seite bleibt beim technischen Prüfen einzelner WSG-Kriterien.

Was die WSG leisten – und was nicht

Die WSG gliedern ihre Vorgaben in Guidelines, Success Criteria und Additional Information. Guidelines benennen das Ziel. Erfolgskriterien beschreiben die prüfbare Erwartung. Die ergänzenden Hinweise liefern Kontext und Beispiele. Das erlaubt automatische Checks und menschliche Bewertung, ersetzt aber kein Messkonzept für den gesamten Lebenszyklus.

Der Entwurf erlaubt Teilkonformität auf Ebene eines Erfolgskriteriums, einer Guideline oder eines Rollenbereichs. Das Erfüllen der gesamten Spezifikation setzt alle anwendbaren Erfolgskriterien voraus. Die Regeln zu Konformität sind laut W3C noch in Arbeit. Eine freiwillige Konformitätsaussage muss mindestens Datum, Titel und URI der WSG sowie die erfüllten Kriterien oder Bereiche aufführen.

Praktische Konsequenz: Schreibe nicht „WSG-konform“, wenn nur ein Teil der Seite geprüft wurde. Benenne stattdessen den Umfang, etwa: „Geprüft am 11. September 2026: Web Development, Kriterien zu ungenutztem Code, Drittanbieterdiensten und nicht kritischen Ressourcen.“

Die WSG sind kein Siegel und keine gesetzliche Pflicht. Der W3C-Entwurf sagt ausdrücklich, dass seine Anwendung keine Erfüllung von Gesetzen oder Regulierung garantiert. Teilverbesserungen dürfen nicht als Nachweis nachhaltigen Betriebs erscheinen.

WSG-Audit in sechs Schritten

Ein Audit gewinnt an Wert, wenn es eine Nutzeraufgabe und eine technische Grenze beschreibt. Starte nicht mit einem einzelnen Page-Weight-Wert oder einem pauschalen CO₂e-Schätzwert.

1. Prüfobjekt und Grenze festlegen

Benenne URL-Gruppe, Seitentyp oder Anwendungsteil. Halte fest, welche Geräteklasse, Sprache, Region, Netzwerkannahme und Browserkonfiguration die Prüfung nutzt. Notiere außerdem, ob CDN, Consent-Tool, Karten, Video, Webfonts, Tag-Management, APIs und eingebettete Drittinhalte zum Prüfobjekt zählen.

Diese Grenze verhindert falsche Vergleiche. Eine Produktdetailseite mit konfigurierbarem Warenkorb stellt andere Anforderungen als eine Wissensseite. Die WSG verlangt zudem, dass Teams Zielkonflikte bewerten: Eine Maßnahme kann etwa Datenverkehr senken und zugleich Zugänglichkeit oder Gerätekompatibilität schwächen.

2. Ziele und Messgrößen vereinbaren

Leite aus dem Prüfobjekt wenige messbare Ziele ab. Die WSG nennt Grenzen für Requests, gerenderte Elemente oder andere messbare Ressourcennutzung als mögliche Leistungsziele. Formuliere dabei den technischen Grenzwert zusammen mit der Nutzeraufgabe und der Messmethode.

Google misst reale Nutzererfahrung unter anderem mit Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Diese Werte helfen bei der Performanceprüfung, bilden jedoch weder einen WSG-Nachweis noch einen Emissionswert und ergeben keine Ranglisten- oder Sichtbarkeitszusage. Der Leitfaden Core Web Vitals und mobile Nutzbarkeit erklärt die Unterscheidung von Labor- und Felddaten.

3. Nutzerweg, Inhalte und Medien prüfen

Prüfe, ob die Seite Menschen direkt zum Ziel führt. Die WSG behandelt Wege, auffindbare Inhalte, kontrollierbare Medien, den Verzicht auf Engagement-Fallen und eine angemessene Animation als Nachhaltigkeitsfragen. Ein kurzer Weg ist nur dann besser, wenn er die Aufgabe verständlich und zugänglich löst.

Beginne bei sichtbaren Ressourcen:

• →Entferne Medien ohne Informations- oder Funktionswert.
• →Lade Audio, Video und große Bilder erst, wenn der Nutzungskontext dies trägt.
• →Gib Nutzenden Kontrolle über startende Medien, Bewegung und Benachrichtigungen.
• →Prüfe Webfonts auf Einsatz, Varianten, Zeichensätze und Auslieferung.
• →Teste Präferenzen wie reduzierte Bewegung, Kontrast, Farbe und Datenverbrauch dort, wo sie Nutzende unterstützen.

Der Beitrag Barrierefreie Websites technisch umsetzen behandelt Tastatur, Semantik, Fokus und Kontrast als eigene Prüfaufgabe. Für die technische Reduktion von Font-Lasten folgst du dem Beitrag Webfonts optimieren: WOFF2, Subsetting und lokales Hosting. Einen dunklen Darstellungsmodus prüfst du im Beitrag Dark Mode technisch und barrierefrei umsetzen. Keine dieser Maßnahmen belegt für sich allein eine Energie- oder Emissionsminderung.

4. Frontend, Backend und Drittinhalte prüfen

Die WSG fordert Leistungs- und Umweltziele, das Entfernen ungenutzten Codes, bedarfsweises Laden großer Komponenten und eine kritische Auswahl von Drittinhalten. Der Standard empfiehlt außerdem, HTML zu nutzen, nicht kritische Ressourcen später zu laden, Metadaten maschinenlesbar anzulegen und API-Aufrufe auf den tatsächlichen Bedarf zu begrenzen.

Untersuche Drittinhalte als Teil des Systems. Die WSG nennt ausdrücklich Plugins, Widgets, Feeds, Karten, Karussells und Tracking-Skripte. Das Papier rät, deren Zahl zu begrenzen, leichte Alternativen zu wählen und sie erst bei Interaktion zu laden, wenn das fachlich passt. Auch Datenschutz, Sicherheit, Aufbewahrung und Portabilität gehören in diese Bewertung.

Für technische Grundlagen wie Abruf, Rendering, Statuscodes, Ressourcen und interne Architektur führt der Beitrag Technisches SEO: Infrastruktur, Architektur und Jamstack weiter. Technische Qualität kann Auffindbarkeit stützen. Aus einer schnelleren oder schlankeren Seite folgt jedoch keine garantierte Google-Position.

5. Hosting und Betrieb belegen

Eine reine Browserprüfung sieht weder Serverauslastung noch Hardwarelaufzeit. Frage Hosting- oder Cloud-Anbieter deshalb nach Angaben zu Standort, Energie, Wasser, Auslastung, Wartung und Hardware. Die WSG nennt unter anderem PUE, WUE, CUE, Anteil erneuerbarer Energie, Reduktionsziele sowie Beschaffung und Wartung von Hardware als Auswahl- und Prüfmerkmale.

Dokumentiere auch, welche Daten fehlen. Die WSG weist darauf hin, dass Daten über Server, Netze und Geräte häufig unvollständig bleiben. Ein Anbieterlabel oder ein Stromtarif ersetzt keine Angaben über die tatsächliche Systemgrenze oder den Energieeinsatz einer Anwendung.

6. Befund priorisieren, ändern und erneut prüfen

Ordne jeden Befund einer Person, einer technischen Änderung, einem Termin und einem Nachweis zu. Die WSG-Impact-Ratings können bei der Reihenfolge helfen; sie stufen die erwartete Wirkung für People, Planet und Prosperity als unbestimmt, niedrig, mittel oder hoch ein und ergänzen einen erwarteten Zeitraum. Diese Werte dienen der Priorisierung; sie sind keine gemessene Wirkung der eigenen Website.

Prüfe nach jeder Änderung dieselbe Grenze erneut. Vergleiche bei Performance dieselbe URL, Gerätekonfiguration, Netzwerkannahme, Toolversion und denselben Testablauf. Für reale Nutzerdaten dokumentierst du Zeitraum, Traffic-Segment und Datengrundlage. Ergänze die Liste nach Releases, neuen Drittanbietern und geänderten Inhalten.

Prüfkriterien für die Freigabe

Eine Freigabe braucht mehr als ein Tool-Ergebnis. Die folgende Liste verbindet WSG-Prüfpunkte mit Nachweisen.

Energie, Emissionen, Recht und Suche abgrenzen

Energie und Emissionen getrennt messen

WSG-Kriterien helfen, unnötige Datenübertragung, Rechenlast oder Hardwarebedarf aufzuspüren. Das Regelwerk ergibt daraus keine Gramm-CO₂e-Aussage. Wer eine Emissionsrate veröffentlicht, benötigt eine Methode, eine abgegrenzte Systemgrenze, eine funktionale Einheit, einen Zeitraum und Datenquellen.

Die SCI-Spezifikation rechnet mit:

SCI = (O + M) / R

Betriebsemissionen O entstehen aus Energieverbrauch und ortsbezogener Kohlenstoffintensität. M ordnet die verkörperten Emissionen der genutzten Hardware zu. R ist eine funktionale Einheit, etwa ein API-Aufruf, ein Nutzer oder eine Transaktion. Der Bericht legt Systemgrenze und Rechenmethode offen. Offsets und andere marktbasierte Maßnahmen dürfen den SCI-Wert nicht mindern.

Ein WSG-Audit kann ein SCI-Projekt vorbereiten, etwa durch ein Inventar von Diensten, Anfragen und Infrastruktur. Es ersetzt die SCI-Bilanz nicht. Der Beitrag Auditierung digitaler Emissionen vertieft diese Bilanzierung.

CSRD und DPP bleiben eigene Rechtsfragen

Die WSG sind freiwillige technische Leitlinien und schaffen keine CSRD-Berichtspflicht sowie keine ESG-Offenlegung. Der mit Richtlinie (EU) 2026/470 geänderte EU-Rahmen begrenzt die verpflichtende Nachhaltigkeitsberichterstattung auf Unternehmen und Gruppen mit Nettoumsatzerlösen von mehr als 450 Millionen Euro und durchschnittlich mehr als 1.000 Beschäftigten im Geschäftsjahr. Die Anwendung hängt von nationalen Umsetzungsmaßnahmen, Unternehmenstyp, Geschäftsjahr und weiteren Vorgaben ab.

Der Digitale Produktpass (DPP) bildet ebenfalls kein Ergebnis eines WSG-Audits. Die Ökodesign-Verordnung (EU) 2024/1781 schafft einen Rahmen für physische Waren. Für Produktgruppen, die ein einschlägiger delegierter Rechtsakt erfasst, dürfen Unternehmen Produkte nur mit verlässlichem, geprüftem Pass auf den Markt bringen oder in Betrieb nehmen. Produktgruppe, Rechtsakt, Dateninhalt und Zeitpunkt entscheiden über diese Pflicht.

Google und KI-Suche nicht vermischen

WSG ist keine Google-Richtlinie und kein Rankingfaktor-Katalog. Google empfiehlt gute Core Web Vitals als Teil einer Seitenerfahrung. Die Metriken LCP, INP und CLS messen Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität im Nutzungskontext. Diese Zahlen ersetzen weder WSG-Nachweise noch eine Bewertung der gesamten Umweltwirkung.

Auch für AI Overviews und den KI-Modus verlangt Google keine spezielle WSG-Maßnahme, kein Sonder-Markup und keine zusätzliche technische Datei. Google nennt die üblichen SEO-Grundlagen: crawlbare, indexierbare und hilfreiche Inhalte, sinnvolle interne Links, sichtbaren Text und passende strukturierte Daten. Selbst bei erfüllten Voraussetzungen bleiben Crawling, Indexierung und Ausspielung Einzelfallentscheidungen.

Häufige Fragen zu den WSG

Ist WSG ein W3C-Standard wie WCAG 2.2?

Nein. Die WSG liegen am 11. September 2026 als W3C Group Note Draft vor. Der Entwurf kann sich ändern und ist nicht durch W3C oder seine Mitglieder gebilligt. WCAG 2.2 ist eine W3C Recommendation mit eigenen Konformitätsstufen A, AA und AAA.

Darf ein Team eine WSG-Konformität behaupten?

Eine Aussage ist im Entwurf optional vorgesehen. Das Statement braucht mindestens Datum, WSG-Titel und URI sowie eine Liste der erfüllten Erfolgskriterien, Guidelines oder Bereiche. Eine Teilprüfung darf nicht den Eindruck lückenloser Nachhaltigkeit erwecken.

Reicht ein CO₂e-Rechner für den WSG-Nachweis?

Nein. Ein Rechner kann eine Schätzung liefern, wenn Datenbasis und Annahmen offenliegen. WSG prüft breiter als eine Emissionsschätzung. Für eine Emissionsrate verlangt SCI zusätzlich Systemgrenze, funktionale Einheit und eine dokumentierte Berechnung oder Messung.

Ersetzt eine schnelle Seite die WCAG-Prüfung?

Nein. Performance und Zugänglichkeit überschneiden sich teilweise, etwa bei Medien, Semantik oder Nutzerpräferenzen. WCAG 2.2 prüft eigene, testbare Erfolgskriterien für Barrierefreiheit. Beide Prüfungen brauchen getrennte Befunde.

Macht WSG eine Seite sichtbarer in Google oder in KI-Antworten?

Eine Zusage gibt es nicht. Technisch entwickelte Seiten und gute Seitenerfahrung unterstützen die normale SEO-Arbeit. Google nennt keine WSG-Konformität als Voraussetzung für Rankings, AI Overviews oder den KI-Modus. Für KI-Funktionen gelten laut Google keine zusätzlichen technischen Anforderungen neben den allgemeinen Voraussetzungen für Google Search.

Nächster Schritt

Lese für einen repräsentativen Seitentyp einen WSG-Prüfbogen an: Umfang, Nutzeraufgabe, Ressourceninventar, Drittinhalte, Betriebsdaten, Befunde, Verantwortliche und erneute Messung. Beginne mit nachweisbaren Änderungen und halte offene Datenlücken fest. Für die technische Entwicklung von schlanken Websites bietet OLDSCHOOLSEO Unterstützung bei einer Jamstack-Website ab 224 € an.

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