JavaScript-SEO – Wirklich ein Ding?

Transkript dieser Folge

Automatisch erstellt und leicht bearbeitet. Anmerkungen in Klammern sind Ergänzungen vom 24. Oktober 2026.

Ist JavaScript der Teufel?

Es stellt sich heraus, dass es ein Kommunikationsdefizit zwischen SEOs und Entwicklern gibt. SEOs verlangen oft unrealistische Dinge von Entwicklern und stoßen damit auf Unverständnis. Hinzu kommt, dass viele Entwickler immer noch denken, dass SEOs Scharlatane sind. Aber das muss nicht sein. Die folgenden Tipps für die Optimierung von JavaScript in der Suchmaschinenoptimierung helfen bei der Entmythifizierung.

Martin Splitt von Google lässt sich von Jamie Alberico, SEO-Produktmanagerin bei Arrow Electronics, interviewen. Ihre erste Frage: Ist JavaScript der Teufel? Nein, ist es nicht. Ohne JavaScript wäre das heutige Netz sicher viel langweiliger. Martin merkt an, dass JavaScript das Web von einem Dokument zu einer App-Plattform gewandelt hat. (Anmerkung: Jamie Alberico tritt heute unter dem Namen Jamie Indigo auf und arbeitet als freie Technical-SEO-Beraterin.)

Die große Frage ist jedoch: Ist eine Single-Page-Application heutzutage tatsächlich eine gute Möglichkeit, eine Website zu betreiben, die auch aus SEO-Sicht funktioniert und ihren Nutzern gleichzeitig alle Vorteile und das Gefühl einer dynamischen Anwendung gibt? Google gibt sich auf jeden Fall alle Mühe, das zu ermöglichen.

Google ist zustandslos: Eindeutige URLs

SEOs und Entwickler müssen zunächst verstehen, dass Google stateless ist, also zustandslos. Der Googlebot stellt keinerlei Verknüpfung zwischen zwei Seiten her. Jede URL ist eine Seite, und es gibt keine logische Verbindung zwischen zwei Seiten, auch wenn es sie in einer App vielleicht gibt.

Das gilt auch für Hash-URLs, also eine Basis-URL, hinter der die Raute und dann der Pfad zur Seite der App steht. Das ist typisch für JavaScript-Apps. Wichtig ist, dass die Hash-URL eindeutig ist. Wenn ein User sie per Copy & Paste in ein Inkognito-Fenster einfügt und auf Enter drückt, sollte die App genau die gleiche Seite laden.

Lazy-Loading spielt auch eine große Rolle. Wenn du deinen Nutzern Bilder und andere Medien zeigen möchtest, achte darauf, dass diese erst mit der Nutzung der App-Seite geladen werden. Lade also nicht etwa 100 Bilder auf einen Schlag.

Crawl-Budget und Caching

Mehrfache Anfragen in JavaScript-Apps werden vom Crawl-Budget abgezogen. Aber Google cached Anfragen zu internen Ressourcen, die zum Rendern notwendig sind, zum Beispiel zu CSS-Dateien, Bildern und anderen Ressourcen. Wenn eine Anwendung 100 Seiten hat und auf jeder Seite 10 Anfragen stattfinden, davon eine zur eigentlichen Datenquelle und 9 zu unterstützenden Ressourcen, dann zählen diese 9 Anfragen ab der zweiten Seite nicht mehr.

Um das zu unterstützen und dem Googlebot Bescheid zu geben, falls sich doch mal etwas ändert, empfiehlt sich eine Versionierung der Ressourcen, zum Beispiel mit einer Zeitmarke, die an die URL der Datei angehängt wird. Auch Pre-Rendering, Hybrid-Rendering und serverseitiges Rendering können helfen, das Crawlen zu optimieren.

Das Crawl-Budget wird außerdem ständig an die Server-Performance angepasst. Ein Rückgang der Crawl-Anfragen muss also nicht zwangsläufig am SEO liegen.

Vorlagen und App-Zustand

Vorlagen sind gut, weil der Googlebot so nur noch die Daten in die entsprechenden Felder laden muss. Laut Martin ist der Googlebot schlau genug dafür. Er empfiehlt, dem Bot so viele Daten wie möglich vorzufüttern, also die Vorlage so gut auszustatten, wie es eben geht. Jede User-Intention wird idealerweise durch eine eigene Vorlage bedient. Der Zustand der App sollte anhand der URL erkennbar sein, zum Beispiel durch eine eigene URL oder entsprechende Parameter.

Martin gibt hier keine Beispiele, daher von mir eine kurze Ausführung: Wenn es sich um eine Reise-App handelt, sollte es für Destinationen eine Listenseite geben, eine Detailseite, vielleicht eine Seite zu unterschiedlichen Regionen und so weiter. Theoretisch erlaubt JavaScript ja, alles so dynamisch zu rendern, dass sogar die Vorlagen aus dem JavaScript kommen könnten. Das ist meiner Meinung nach das, wovon Martin hier abrät. Das wäre wohl etwas zu dynamisch für den Googlebot.

Lade-Performance

Die Lade-Performance spielt natürlich auch eine große Rolle bei JavaScript-Apps. Der Contentful Paint ist die Zeit, die es braucht, bis ein Nutzer den ersten Content sieht und so weiß, dass die Webseite tatsächlich lädt. Es ist sehr wichtig, den eigenen Nutzern hier bedeutende Inhalte zu zeigen, also nicht erst ein großes Bild, 500 Wörter Text und dann erst die Produktinformationen. Martin rät hier deutlich davon ab. Die Zeit bis zum ersten Byte ist zwar auch wichtig, aber nicht so wichtig wie die Zeit bis zum Contentful Paint.

Martin empfiehlt das in Chrome eingebaute Lighthouse für Geschwindigkeitstests. PageSpeed Insights ist natürlich auch empfehlenswert, ebenso der Test auf Optimierung für Mobilgeräte. Das Tool WebHint bietet eine breite Palette an Tests, die über Geschwindigkeitsmessungen hinausgehen.

Ich habe spaßeshalber die Podcast-Website content-links-seo.de überprüfen lassen und direkt über 100 Fehler oder Unzulänglichkeiten gefunden. WordPress und seine Plugins sind ganz schön ätzend: Features ohne Ende, aber dafür unendlich viele Fehler. So geht die Arbeit für uns SEOs wohl nie zu Ende.

Mein Fazit

JavaScript und SEO können ab jetzt wirklich gute Freunde sein. Da sind sich Martin und Jamie zum Schluss einig.

Das Thema SEO und JavaScript ist meiner Meinung nach immer noch ein sehr spezielles Nischenthema. Aber es schadet natürlich nicht, vollständig über alle Möglichkeiten informiert zu sein, um nachher selbst entscheiden zu können, ob das nächste Projekt auf JavaScript basieren soll. Meine Empfehlung: Wenn es keinen wirklich guten Grund dafür gibt, lass es einfach sein. Falls du dich doch dazu entscheidest, ist dir diese Folge hoffentlich eine Hilfe gewesen.

Wie immer, viel Erfolg!