Bastian Grimm, SEOkomm 2021

Vortragszusammenfassung

In diesem Vortrag zeigt Bastian, wie sich mit Cloudflare Workers Änderungen an Websites umsetzen lassen, ohne Zugriff auf den Origin-Server (also den eigentlichen Webserver) zu benötigen. Das macht Workers besonders interessant für Situationen mit Altsystemen, eingeschränkten Release-Zyklen oder wenn Dienstleister bei Kunden kaum Eingriffsmöglichkeiten haben. Workers sind dabei keine „immer beste“ Lösung, sondern oft ein schneller, pragmatischer Quick-Fix – ideal, um kurzfristig Wirkung zu erzielen und anschließend saubere Anpassungen im Produktivsystem nachzuziehen.

Grundidee: Logik direkt am CDN-Edge

Bastian erklärt zunächst den Request-Lifecycle und was sich durch ein CDN ändert: Beim ersten Request holt das CDN Inhalte vom Origin, cached sie und kann Folgeanfragen direkt ausliefern. Genau in dieser Edge-Schicht setzen Workers an: kleine JavaScript-Skripte, die Requests und Responses abfangen, weiterleiten oder verändern können – inklusive Headern und HTML-Inhalten. Dadurch lassen sich technische und SEO-relevante Eingriffe durchführen, ohne den Servercode anzufassen.

Hands-on: Von Setup bis Deployment

• Cloudflare-Account anlegen (Free-Tarif reicht für erste Tests).
• DNS umstellen (Nameserver beim Domain-Provider auf Cloudflare zeigen lassen).
• Worker-Code im Playground testen, bevor er live geht.
• Im Cloudflare-Panel Worker anlegen, Deploy durchführen und anschließend über Routing festlegen, auf welchen URLs der Worker laufen soll.

Als anschauliches Beispiel modifiziert er eine HTML-Seite „brute force“ (Body-Stil), um zu zeigen: Die Veränderung passiert komplett am CDN, der Origin sieht den Request dabei nicht zwingend.

SEO-Use-Cases, die sofort helfen können

• Redirects (301/302), auch als Redirect-Map für viele Regeln.
• Reverse Proxy, um Inhalte von Subdomains oder Fremdsystemen „unter“ der Hauptdomain auszuliefern (inkl. möglichem Umschreiben interner Links).
• robots.txt absichern, z. B. fehlerhafte „Disallow: /“-Deployments abfangen und on-the-fly korrigieren.
• User-Agent-basierte Ausspielung für seriöse Szenarien (z. B. Sitemap nur für Googlebot ergänzen).
• Meta-Robots, Title, Description und andere HTML-Elemente gezielt per HTML-Rewriter anpassen (auch mit Conditional Logic, z. B. nur bei falscher Länge).
• Links umschreiben nach Migrationen, wenn Ressourcen fehlen (alte Domain durch neue ersetzen).
• hreflang per HTML oder sogar per Header setzen.
• Maintenance sauber ausspielen: Bei kaputtem Backend 503 + optional „Retry-After“ vom Edge aus liefern, damit Crawler keine Fragmentseiten indexieren.
• Content injizieren (z. B. Text hinter H1), gespeist aus JSON/Dateien oder APIs.
• Performance-Helfer wie Lazy-Loading-Attribute ergänzen oder veralteten Code entfernen.

Risiken und Verantwortung

Mit der Macht kommt Verantwortung: Workers können nahezu alles verändern und sind daher schwer zu debuggen, können Konflikte/Bugs erzeugen und müssen sauber dokumentiert sowie intern abgestimmt werden (Compliance/Prozesse). Zusätzlich gibt es ein Kostenrisiko bei sehr vielen Requests (Freikontingent, danach Abrechnung). Bastian warnt außerdem vor Missbrauch: Es gibt Fälle, in denen Workers für Spam-Injection genutzt wurden – deshalb empfiehlt er dringend Two-Factor Authentication für Cloudflare-Accounts.

Fazit

Cloudflare Workers sind ein extrem schnelles Werkzeug, um technische und SEO-relevante Probleme „an der Kante“ zu lösen – besonders dann, wenn man nicht (mehr) ans System herankommt. Der wichtigste Punkt: Workers sollten meist eine temporäre Lösung bleiben, um schnell Resultate zu liefern und anschließend die Änderungen nachhaltig im eigentlichen Produktivsystem umzusetzen.