- Eine plattformunabhängige Spezifikation, die die technischen Funktionen zusammenfasst, über die eine gute Website verfügen sollte – von
<title> bis llms.txt
- Richtet sich sowohl an Menschen als auch an Agenten und verweist auf moderne Webstandards wie WHATWG, W3C, IETF RFCs, WCAG und MDN
- Unabhängig davon, ob mit WordPress, Next.js, einer Django-App oder reinem HTML bereitgestellt: Die Spezifikation selbst bleibt identisch und enthält auch Implementierungshinweise
- Das Gesamtthema ist in 10 Bereiche wie Foundations, SEO, Accessibility, Security und Performance gegliedert und an breit akzeptierte Standards angebunden
- Bietet einen öffentlichen MCP-Server, Agent Skill,
/llms.txt und Markdown-Antworten, die Agenten und Betreiber für Audit-, Lern- und Verbesserungsabläufe nutzen können
Eine plattformunabhängige Spezifikation für gute Websites
- The Website Specification ist eine plattformunabhängige Spezifikation, die die technischen Funktionen beschreibt, über die eine gute Website verfügen sollte – von
<title> über /.well-known/security.txt, WCAG-Kontrast bis zu llms.txt
- Sie richtet sich an Menschen und Agenten zugleich; jedes Thema ist mit modernen Webstandard-Quellen wie WHATWG, W3C, IETF RFCs, WCAG, MDN verknüpft
- Egal ob mit WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, einer Django-App oder reinem HTML ausgeliefert: Die Spezifikation selbst ist identisch, Implementierungshinweise folgen anschließend
- Auf jeder Seite gibt es einen Link Edit on GitHub, Pull Requests sind willkommen, und jede Seite weist ihre Quellen aus
-
Abgedeckte Bereiche
- Alle Themen sind in 10 Bereiche gegliedert, die breit akzeptierten Standards zugeordnet sind
- Foundations: 14 Punkte zu HTML,
head und grundlegenden Dokumentelementen
- SEO: 13 Punkte mit Elementen für die Suchsichtbarkeit wie
robots.txt, Sitemaps, Canonical und strukturierte Daten
- Accessibility: 20 Punkte mit WCAG-basierten Regeln, damit Nutzer mit unterschiedlichsten Fähigkeiten die Website verwenden können
- Security: 12 Punkte zu Headern, Übertragung und Richtlinien, die Besucher sicher schützen
- Well-Known URIs: 9 Punkte zu standardisierten, vereinbarten Pfaden unter
/.well-known/
- Agent Readiness: 18 Punkte zu Elementen, mit denen AI-Agenten und Crawler eine Website lesen können
- Performance: 19 Punkte zu Core Web Vitals, Caching, Bildern, Schriftarten und Netzwerkverhalten
- Privacy: 6 Punkte zu Einwilligung, Signalen und dem Respektieren von Besucherentscheidungen
- Resilience: 5 Punkte zu graceful failure wie Fehlerseiten, Offline-Betrieb und Redirects
- Internationalisation: 12 Punkte zu Sprache, Locale, Schreibrichtung und übersetzten Inhalten
Einsatz für Agenten und Website-Betreiber
- Die gesamte Spezifikation wird über einen öffentlichen, schreibgeschützten MCP-Server ohne Authentifizierung bereitgestellt
- Es gibt eine veröffentlichte Agent Skill, die kompatiblen Agenten erklärt, wann und wie sie die Spezifikation verwenden sollen
- Jede Spezifikations-URL liefert seitenweises Markdown über
/llms.txt und Accept: text/markdown
- Ein Beispiel für die MCP-Server-Konfiguration sieht so aus
{
"mcpServers": {
"specification-website": {
"transport": "http",
"url": "https://mcp.specification.website/mcp";
}
}
}
-
Ablauf der Nutzung
- Audit: Die Checkliste durchgehen und jeden Punkt mit „Macht die Website das – ja/nein“ prüfen
- Learn: Bei jedem Punkt nachsehen, was es ist, warum es wichtig ist und wie es umgesetzt wird
- Improve: Wenn fehlende Teile, veraltete Informationen oder ausgelassene Themen gefunden werden, kann mit Quellenangaben ein PR eröffnet werden
1 Kommentare
Hacker-News-Kommentare
Agent Readiness wirkt wie etwas à la "Web 4.0 Blockchain Integration", für das man sich mit der Zeit schämen könnte
Nicht weil Agenten bedeutungslos werden, sondern weil selbst dann, wenn sie wichtig werden, der ursprüngliche Zweck untergraben wird, sobald eine Website Sonderbehandlungen für Agenten einbauen muss
Am Ende werden böswillige Akteure das nur dafür nutzen, Agenten etwas anderes zu zeigen als Menschen, und deshalb wird es vermutlich absichtlich ignoriert werden
Heute ist auf Websites alles eine Komponente. Sogar ein simples Dropdown mit einer endlichen Liste hat seinen eigenen Loader und feuert grundlos zehn
fetch-Requests ab. Das ist keine Übertreibung, man muss sich nur Instagram und Facebook im Web ansehenWeg mit all diesen Spezifikationen, und gebt mir einfach ursprüngliches HTML, das nicht von Dingen wie React verschleiert wird, die behaupten, das nächste JS-Framework werde alles verändern
Das Web ist im Kern eine feindliche Umgebung, und ich halte einen erheblichen Teil der Website-Betreiber selbst für böswillige Akteure. Websites werden absichtlich Menschen etwas anderes zeigen als Agenten, so wie sie es auch bei Suchmaschinen getan haben
Der Grund, warum "Agent Readiness" nicht lange halten dürfte, ist, dass Website-Betreibern bald klar wird, dass Agenten im Grunde Zugriffsautomatisierung sind. Genau dagegen kämpfen sie schon die ganze Zeit, weil es ihre Fähigkeit zur Monetarisierung bedroht
Ich bezweifle allerdings, dass es in der Praxis so kommen wird. Das Problem böswilliger Akteure war schon lange möglich. Zum Beispiel, indem Suchmaschinen-Crawlern andere Inhalte geliefert werden als das, was Nutzer nach einem Klick sehen. Wenn ich mich richtig erinnere, hat Google solche Websites zeitweise abgestraft
https://frontendchecklist.io/rules
Menschen wollen eine ansprechend aussehende Website, und das geht auch mit purem HTML. Agenten brauchen nicht einmal das; idealerweise würden sie den Seiteninhalt einfach nur als Markdown sehen
Warum also keine Agenten-Version? Das spart Zeit und Geld sowohl für den Client-Agenten als auch für den Host der Website
Es wäre gut, wenn man mit einem Standard wie
llms.txtfestlegen könnte: "Agenten sollen stattdessen diesen Mirror besuchen, der die rohe Markdown-Version dessen enthält, was Menschen sehen"Ein Teil der Agent Readiness dieser Website entspricht SEO für AI. Umgekehrt erfüllt es bei Websites, die kein AI-Crawling wollen, auch die entgegengesetzte Funktion
Es wäre gut, Best Practices für Bereiche wie Login-Formulare zu haben. Zum Beispiel standardisierte Feldnamen zu verwenden, die Passwortmanager erkennen, Auto-Complete und automatische Großschreibung in Login-Feldern zu deaktivieren, bei E-Mail das korrekte HTML5-
input typezu verwenden, Formulare zu vermeiden, bei denen man erst nur die E-Mail eingibt und dann noch einmal klicken muss, um das Passwort einzugeben, sowie gemäß NIST SP 800-53 SMS-Zwei-Faktor-Authentifizierung oder beliebige Regeln für regelmäßige Passwortwechsel und Passwortkomposition zu vermeidenEs gibt auch viel zu viele Websites, die in Formularen mit nur einem Eingabefeld nicht automatisch den Fokus setzen
https://adamsilver.io/blog/form-design-from-zero-to-hero-all...
Seitdem hat er noch viele neue Beiträge veröffentlicht, und das ist möglicherweise eine der besten UX-Ressourcen im Web
Bevor man den Benutzer übermittelt bekommt, kann man nicht wissen, ob dieser Benutzer ein Passwort verwendet oder eine andere Methode nutzt
https://frontendchecklist.io/rules/html/input-types
Wenn ich UI-Komponenten von Grund auf baue, mag ich diese Website wirklich sehr
https://component.gallery/
Sie verlinkt auf Komponenten aus vielen Design-Systemen, von denen viele auch Richtlinien zu Barrierefreiheit, Internationalisierung und Ähnlichem ausführlich behandeln. Besonders gut dokumentierte Beispiele sind das Lightning Design System von Salesforce und Stacks von StackOverflow
https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car...
https://stackoverflow.design/system/forms/checkbox
Die meisten Websites behandeln das dann entweder nicht als Priorität oder wissen nicht einmal, dass es etwas ist, das man berücksichtigen sollte, und deshalb stehen wir heute da, wo wir stehen
Ich habe immer angenommen, dass es einen Grund gibt, warum Websites auf dieses Muster umsteigen. Zum Beispiel, dass es besser gegen Bots hilft. Mich würde interessieren, ob jemand dazu mehr weiß
Oberflächlich betrachtet wirkt fast alles wie AI-generierter Inhalt, daher könnte die Art der Vermittlung nicht besonders gut funktionieren. Liest man aber mehrere Punkte, vermitteln die meisten abgesehen vom Agent-Bereich eine ziemlich solide Webhygiene recht klar, sodass man es auch an Webentwickler schicken könnte, die gerade erst anfangen, sich weiterzuentwickeln.
Allerdings ist es ironisch, dass die Website selbst nicht einmal Praktiken anwendet, die sie als "erforderlich" bezeichnet.
https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification...
Ich verstehe nicht, was das Ziel dieser Website ist. Sie bewirbt sich als Spezifikation, aber ich weiß nicht, was sie eigentlich spezifizieren will.
Alle Punkte stützen sich auf andere "Quellen der Wahrheit".
"Ich war es leid, für jede einzelne Empfehlung auf sechs verschiedene Quellen verweisen zu müssen. HTML kam von WHATWG, Accessibility von WCAG, Header von der IETF, strukturierte Daten von schema.org, der Rest von MDN, web.dev und Google Search Central.
Es gab keine einzige, klare, meinungsstarke und plattformneutrale Spezifikation dafür, was moderne Websites tatsächlich tun sollten.
Also habe ich eine geschrieben."
[1] https://www.linkedin.com/posts/jdevalk_the-website-specifica...
Ich frage mich, wie verbreitet die Dinge hier eigentlich sind. /.well-known/change-password ist nett zu haben, aber wenn man sich https://news.ycombinator.com/.well-known/change-password und google.com/.well-known/change-password ansieht, scheint es nicht implementiert zu sein.
Ich habe allerdings noch nie gehört, dass es in der Praxis genutzt wird.
Googles URL liegt unter https://accounts.google.com/.well-known/change-password, nicht auf der Hauptdomain.
Das sieht aus, als käme es direkt aus einer Müllfabrik. "SEO", "Agent-readiness" — genau die Art von Dingen, die eine gute Website gerade nicht tun sollte.
Und natürlich wurde es von einem WordPress-"SEO"-Experten und Privatinvestor gemacht, der Claude LLM benutzt. Jemand, der reich wurde, indem er das Internet, das wir einmal geliebt haben, mit Werbemüll ruiniert hat, versucht jetzt mit LLM-Müll auch noch den Rest kaputtzumachen.
Dass "stable URLs" unter "agent readiness" einsortiert wurde, wirkt wie ein Signal, dass dem Autor AI wichtiger ist als Menschen. Diese Domain kommt auf meine Blockliste. Ich sehe jetzt schon, dass sie die Suche nach Informationen zur Webentwicklung weiter verschlechtern wird.
"Kein Framework. Kein Leitfaden. Eine Spezifikation — was erforderlich ist, was empfohlen wird und was zu vermeiden ist."
Es ist schwer zu sagen, wie viel der Seite LLM-Müll ist, aber manche Formulierungen wirken ganz eindeutig so.
https://specification.website/llms-full.txt
Erstens diese kleinen farbigen Tags wie required, optional, recommended.
Zweitens diese irre Menge an Content, die ohnehin niemand lesen wird.
Drittens die Art, wie schwache Ideen bis ins Schmerzhaft-Detailierte ausgewalzt werden.
Ich hatte überlegt, so etwas selbst zu bauen, aber wenn man das einfach in irgendeinen Agent-Chat einfügt, funktioniert es erstaunlich gut.
Ich habe gerade mit einem lokalen Modell (Qwen3.6 27B / pi) für eine alte Hugo-Website eine Liste fehlender Pflichtstandards erstellen lassen, daraus eine To-do-Liste gemacht und sie dann Punkt für Punkt abarbeiten lassen, wobei ich jede Änderung prüfen konnte.
Sogar ein fehlendes favicon wurde aus dem Logo ausgeschnitten und erzeugt, und das Ergebnis sah ziemlich gut aus.
piherumgespielt hast. Dieses reibungslose Gefühl bei kurzen Agent-/System-Prompts ist gut, aber wenn man ihm beliebige Aufgaben einfach überlässt, scheint es doch einiges an Warten und Sackgassen zu geben.Ich habe die Website auf einem MacBook geöffnet und die CPU-Auslastung stieg auf über 50 %.
Wenn man bedenkt, dass es sich um eine Spezifikation dafür handeln soll, wie Websites sein sollten, ist das ziemlich ironisch.
Ein Teil des Inhalts ist ziemlich gut, aber hoffentlich sorgt die Standardisierung als Checkliste mit 128 Punkten nicht dafür, dass Menschen Angst davor bekommen, überhaupt Websites zu bauen.
Meine Lieblingsspezifikation ist eine halluzinierte Spezifikation. Gratulation, schätze ich.
Ich freue mich schon auf agentengesteuerte ISO-Alternativen oder von LLMs betriebene Spielautomaten.