Mit tiefer Trauer geben wir das Ende von robots.txt bekannt, der bescheidenen Textdatei, die dreißig Jahre lang als stille Wächterin der digitalen Höflichkeit diente. Geboren am 1. Februar 1994 aus der Not heraus, als Martijn Kosters Server unter einem fehlerhaften Crawler namens „Websnarf“ zusammenbrach, verstarb robots.txt im Juli 2025, nicht durch Cloudflares Hand, sondern an den Folgen systematischer Missachtung durch KI-Konzerne. Cloudflares Entscheidung, KI-Crawler standardmäßig zu blockieren, markierte lediglich den Moment, in dem auch der letzte große Infrastruktur-Anbieter das Vertrauen in freiwillige Compliance aufgab und zu technischer Durchsetzung überging – ein letzter Akt der Verzweiflung, der das Ende einer Ära markierte. Wie bei allen bedeutsamen Verlusten brauchte es Zeit, bis das volle Ausmaß dieser digitalen Tragödie begriffen wurde.

Ein Leben der stillen Dienste

robots.txt wurde in einer Zeit geboren, in der das Internet einer kleinen, beschaulichen Nachbarschaft glich – überschaubar, persönlich und geprägt von gegenseitigem Vertrauen. Man kannte die Bots, die vorbeikamen, und pflegte den digitalen Umgang miteinander. robots.txt, geborene „RobotsNotWanted.txt“, war nie darauf ausgelegt, komplexe rechtliche Schlachten zu führen oder Milliardenunternehmen zu konfrontieren – sie war einfach ein höflicher, aber dennoch bestimmter Hinweis: „Bitte nicht hier entlang.“

In ihren goldenen Jahren lebte robots.txt in perfekter Harmonie mit den großen Suchmaschinen. Google respektierte sie, Yahoo ehrte sie, und selbst AltaVista – ruhe in Frieden – und Lycos folgten ihren Anweisungen. Es war ein Geben und Nehmen. Es war eine Freundschaft auf Augenhöhe, geprägt von einer einfachen Wahrheit: Suchmaschinen erhielten Content zur Indexierung, während Websites im Gegenzug Traffic bekamen. Dieses Crawl-zu-Referral-Verhältnis – also das Verhältnis zwischen Bot-Zugriffen und zurückgeleiteten Nutzern – lag bei Google bei einem fairen 14:1. Pro 14 von Bots aufgerufenen Seiten fand im Schnitt ein Nutzer den Weg zurück zur Website. Heute ist dieser Kontrakt gebrochen: KI-Crawler generieren Tausende oder Millionen von Zugriffen, während kaum Traffic durch Links oder Erwähnungen zurückkommt.

„Anthropics ClaudeBot zeigte im Juni 2025 das mit Abstand höchste Crawl‑zu‑Referral‑Verhältnis – etwa 70.900 Crawls pro einem Referral, weit mehr als jeder andere KI‑Crawler.“ (Cloudflare (Juli 2025))

robots.txt war so grundlegend für das Funktionieren des Internets, dass man ihr 2022 mit RFC 9309 endlich formell Anerkennung zollte. Doch selbst dieser späte Ritterschlag konnte ihr Schicksal nicht aufhalten.

Chronik eines schleichenden Endes

Die ersten Anzeichen des Wandels zeigten sich 2017, als das Internet Archive ankündigte, robots.txt bei der Archivierung historischer Inhalte nicht länger zu berücksichtigen. Am 17. April 2017 erklärte Mark Graham (Direktor der Wayback Machine), dass robots.txt-Dateien – insbesondere solche, die für Suchmaschinen gedacht sind – nicht immer mit den Archivierungszielen übereinstimmen. Das Internet Archive verfolge das Ziel, möglichst vollständige Schnappschüsse des Webs zu bewahren, einschließlich doppelter oder großer Inhalte.

„Over time we have observed that the robots.txt files that are geared toward search engine crawlers do not necessarily serve our archival purposes.“ (Mark Graham)

Doch das war nur ein Vorgeschmack auf die fortschreitende, systematische Ausschöpfung, die jetzt folgen sollte. Mit dem Aufkommen der künstlichen Intelligenz verwandelte sich das Internet von einem kollaborativen Raum in eine Extraktionszone.

Doch statt des erhofften kollaborativen Miteinanders folgte systematische Ausbeutung. KI-Konzerne errichteten neue digitale Barrieren: Cloudflares Default-Blocking, Paywalls für API-Zugang und exklusive Lizenzdeals mit ausgewählten Publishern. Content-Ersteller sahen sich einer industriellen Extraktionsmaschine gegenüber, die ihre Arbeit ohne Gegenleistung verwertete. Das Internet, einst als offenes Netz für alle konzipiert, verwandelte sich in eine zentralisierte Datenmine für Tech-Giganten.

OpenAI führte den Angriff mit seinem GPTBot, ChatGPT-User und OAI-SearchBot an – eine Dreifaltigkeit der Verletzung, die robots.txt hilflos zusehen ließ, wie ihre Direktiven geflissentlich ignoriert wurden. Das Unternehmen behauptete öffentlich Compliance, während Cloudflare im Juni 2025 ein vernichtendes Crawl-to-Referral-Verhältnis von 1.700:1 dokumentierte – industrielle Extraktion ohne nennenswerte Gegenleistung.

Anthropic fügte dem Leiden weitere Qualen hinzu. ClaudeBot, anthropic-ai und Claude-Web hämmerten auf Server ein, wobei iFixit eine Million Besuche in 24 Stunden und Freelancer.com fast vier Millionen in vier Stunden erlebte. Mit einem Crawl-to-Referral-Verhältnis von 73.000:1 überschritt Anthropic alle Grenzen des Anstands — es war, als würde man einem Nachbarn die Haustürschlüssel anvertrauen, damit er die Blumen gießt – nur um festzustellen, dass er den gesamten Hausrat abtransportiert hat.

Perplexity AI gehörte zu den aggressivsten Akteuren: Es nutzte verdeckte (undisclosed) IP-Adressen und Drittdienste, um Crawling-Aktivitäten zu verschleiern. Als CEO Aravind Srinivas öffentlich erklärte, robots.txt sei kein rechtliches Framework, war das ein offener Affront gegen das jahrzehntealte fragile Protokoll.

Eine Textdatei im Schatten des letzten Gefechts

In ihren letzten Monaten kämpfte robots.txt verzweifelt um die Relevanz vergangener Zeiten. Website-Betreiber entwickelten immer raffiniertere Unterstützungssysteme: Crawler-Fingerprinting mit TLS-Analyse (Transport Layer Security), Honeypot-Fallen und Verhaltensanalyse. Doch es war, als versuchte man, eine akute Blutvergiftung mit fiebersenkenden Mitteln zu behandeln – technisch durchdacht, aber dem Ausmaß der Bedrohung nicht gewachsen.

Das European Data Protection Board versuchte mit der Opinion 28/2024 dem Protokoll rechtliche Verbindlichkeit zu geben, während Italiens Datenschutzbehörde Garante OpenAI mit einer Strafe von 15 Millionen Euro belegte. Doch es waren verzweifelte Wiederbelebungsversuche eines längst kollabierten Systems – der freiwillige Respekt war nicht mehr zu retten.

Alternative Protokolle – ai.txt, TDM ReP, „No-AI-Training“ HTTP-Header – wurden als potenzielle Nachfolger diskutiert. Aber sie alle trugen den Makel ihrer Geburt: Sie entstanden nicht aus Kooperation, sondern aus Konfrontation.

Das PHP-Framework Symfony feiert in dieser Woche sein 20-jähriges Bestehen. Seit 2005 entwickeln Menschen weltweit das PHP-Framework weiter, teilen Wissen und prägen damit die Webentwicklung. Aus einem einzelnen Framework ist ein globales Open-Source-Projekt geworden, das Millionen Anwendungen antreibt.

Was Symfony auszeichnet

Symfony steht für eine klare, modulare Architektur und wiederverwendbare Komponenten, die auch andere Projekte wie Laravel oder Drupal nutzen. Das Framework legt Wert auf Stabilität und langfristigen Support, bleibt dabei aber flexibel: Es lässt sich als vollständiges System oder über einzelne Bausteine einsetzen.

Klare Standards, testgetriebene Entwicklung und sauberes Design fördern die Codequalität und sichern die Wartbarkeit. Eine aktive internationale Community sorgt für Weiterentwicklung, Dokumentation und Austausch, während moderne Werkzeuge wie Symfony Flex oder die Integration von Doctrine ORM und API Platform die technische Basis bilden.

Zwei Jahrzehnte Symfony im Überblick

2005 erschien Symfony 1.0 und legte den Grundstein für strukturierte PHP-Entwicklung. Aus ersten Meetups und dem Blog A Week of Symfony entstand schnell eine aktive Community. Mit der Veröffentlichung von Symfony 2.0 (2011) führte das Projekt eine modulare Architektur ein, die bis heute Kern des Frameworks ist. Composer und wiederverwendbare Bundles machten Symfony ab 2012 flexibler und beeinflussten viele andere Open-Source-Projekte.

In den folgenden Jahren entwickelte das Team neue Standards und Werkzeuge zur Verbesserung der Entwicklererfahrung. Ab 2017 erleichterten Flex, Autokonfiguration und erweiterte Tools die tägliche Arbeit. Mit den neueren Versionen 5 bis 7 richtete sich Symfony konsequent auf moderne PHP-Versionen, API-Entwicklung und eine stärkere Verbindung von Frontend und Backend aus. Heute zählt das Framework über 250 Pakete und bleibt ein zentraler Bestandteil der PHP-Landschaft.

Blick zurück und nach vorn

Zum Jubiläum blickt das Projekt auf einer eigens dafür erstellten Website auf zentrale Stationen seiner Entwicklung und lädt die Community ein, die gemeinsame Geschichte zu erkunden. Im November 2025 trifft sich die Symfony-Community auf der SymfonyCon Amsterdam, um über die nächsten Schritte zu sprechen.

Symfony blickt auf zwanzig Jahre gemeinsames Arbeiten zurück – und entwickelt die Zukunft offen weiter.

(mdo)

Das JavaScript-Toolkit Bun 1.3 ist erschienen. Als bisher größtes Release angekündigt, bietet das Toolkit mit den vier Bestandteilen Runtime, Bundler, Test Runner und Paketmanager unter anderem einen Full-Stack-Dev-Server in Bun.serve(), einen integrierten Redis-Client und eine verbesserte Kompatibilität mit Node.js.

Full-Stack-Entwicklung mit Bun

Mit Version 1.3 gilt Bun laut dem Entwicklungsteam als batteries‑included Full‑Stack-JavaScript-Runtime, die „erstklassigen Support“ für die Frontend-Entwicklung anbietet. Bereits seit Bun 1.2 sind HTML-Importe möglich, aber das neue Release fügt Hot Reloading und integriertes Routing hinzu. Dank dem neu hinzugefügten Support für parametrisierte und Catch-All-Routen lässt sich nun in Bun.serve() die gleiche API für Frontend und Backend nutzen. Die Routen können mit dynamischen Pfadparametern wie :id und unterschiedlichen Handlern für unterschiedliche HTTP-Methoden umgehen. Das Bun-Team demonstriert das überarbeitete Routing im Ankündigungsbeitrag:

import { serve, sql } from "bun";
import App from "./myReactSPA.html";

serve({
  port: 3000,
  routes: {
    "/*": App,

    "/api/users": {
      GET: async () => Response.json(await sql`SELECT * FROM users LIMIT 10`),

      POST: async (req) => {
        const { name, email } = await req.json();
        const [user] = await sql`
          INSERT INTO users ${sql({ name, email })}
          RETURNING *;
        `;
        return Response.json(user);
      },
    },

    "/api/users/:id": async (req) => {
      const { id } = req.params;
      const [user] = await sql`SELECT * FROM users WHERE id = ${id} LIMIT 1`;
      if (!user) return new Response("User not found", { status: 404 });
      return Response.json(user);
    },

    "/healthcheck.json": Response.json({ status: "ok" }),
  },
});

Auch kann der in Bun enthaltene Bundler nun Frontend- und Backend-Anwendungen in einem einzigen Build verpacken.

Integrierte Anbindung an MySQL und Redis

Bun.SQL hat sich von einem integrierten PostgreSQL-Client zu einer vereinheitlichten API für MySQL/MariaDB, PostgreSQL und SQLite gemausert – ganz ohne weitere Dependencies. Wie das Bun-Team ausführt, reduziert die integrierte API nicht nur die Anzahl der in einem Projekt benötigten Dependencies, sondern bietet im Vergleich zur Nutzung bestehender npm-Pakete wie postgres oder mysql2 auch Performanceverbesserungen.

Einen integrierten Redis-Client hat Bun 1.3 ebenfalls vorzuweisen. Dieser kann nicht nur mit der In-Memory-Datenbank Redis, sondern auch mit deren BSD-lizenziertem Fork Valkey unter dem Dach der Linux Foundation umgehen. Buns Redis-Client soll sich durch eine hohe Geschwindigkeit auszeichnen und alle Standardvorgänge – insgesamt 66 Befehle – unterstützen, darunter Hashes (HSET/HGET), Listen (LPUSH/LRANGE) und Sets.

Auf dem Weg zur Node.js-Kompatibilität

Bun schickt sich an, als schnellerer und einfacherer „Drop-in“-Ersatz für Node.js zu dienen – denn Node.js hat laut dem Bun-Entwickler Jarred Sumner über die Jahre hinweg immer neue Schichten an Tooling hinzugewonnen, was die Geschwindigkeit verringert und die Komplexität erhöht habe. Im neuen Release nähert sich Bun der vollständigen Node.js-Kompatibilität weiter an. Unter anderem sind Support für das VM-Modul, node:test und Performance-Monitoring enthalten.

Der initiale Support für das node:test-Modul verwendet unter der Haube bun:test für ein einheitliches Testing-Erlebnis. Somit lassen sich laut dem Bun-Team Node.js-Tests mit den Performancevorteilen von Buns nativem Test Runner ausführen.

import { test, describe } from "node:test";
import assert from "node:assert";

describe("Math", () => {
  test("addition", () => {
    assert.strictEqual(1 + 1, 2);
  });
});

Ausführliche Informationen zu diesen und allen weiteren Updates in Bun 1.3 können Interessierte im Bun-Blog einsehen.

(mai)