JavaScript-Links

Auch: JS-Links, onclick-Links

„Google kann kein JavaScript“ ist ein Satz, der sich hartnäckig hält und seit Jahren nicht mehr stimmt. Google führt JavaScript aus und findet dabei auch Links, die erst ein Skript in die Seite schreibt. Trotzdem gibt es Links, die für Google unsichtbar bleiben, obwohl sie für Besucher tadellos funktionieren.

Der Unterschied liegt fast nie darin, ob JavaScript im Spiel ist, sondern darin, wie der Link im fertigen HTML aussieht. Diese Seite zeigt, welche Varianten Google dokumentiert als crawlbar führt, wie die Erkennung technisch abläuft und warum das bei eingehenden Links aus Widgets und Siegeln über den Wert einer Verlinkung entscheidet.

Zwei Dinge, ein Begriff: per Skript erzeugt oder per Skript ausgeführt

Unter „JavaScript-Link“ werden zwei grundverschiedene Dinge zusammengefasst. Wer sie trennt, kann die meisten Fragen schon beantworten, bevor er ein Werkzeug öffnet.

• Per Skript erzeugte Links: Ein Skript schreibt nach dem Laden ein ganz normales <a href="/ziel/"> in die Seite, etwa ein Menü, eine Produktliste oder ein eingebettetes Widget. Im ausgelieferten HTML fehlt der Link, im fertig aufgebauten Dokument ist er ein echter Link.
• Per Skript ausgeführte Links: Das Element sieht aus wie ein Link und reagiert auf einen Klick, ist aber keiner. Typisch sind ein <span> oder <button> mit onclick, ein <a> ohne href oder ein href="javascript:…". Das Ziel steht dann nur im Skript.

Google zieht die Grenze genau an dieser Stelle. In seinen Best Practices für Links heißt es, Google könne einen Link im Allgemeinen nur crawlen, wenn er ein <a>-Element mit href-Attribut ist. Links, die per JavaScript dynamisch eingefügt werden, seien ebenfalls crawlbar, solange sie dieses Markup verwenden.

Wie Google JavaScript-Links findet: Crawling, Rendering, zweiter Blick

Google verarbeitet Seiten laut seiner Einführung in JavaScript-SEO in drei Phasen: Crawling, Rendering, Indexierung. Für Links ist wichtig, dass Google zweimal hinschaut.

1. Crawling: Der Googlebot ruft die URL ab, sofern die robots.txt das erlaubt, und durchsucht die HTML-Antwort nach Adressen in den href-Attributen von Links. Was dort schon steht, landet sofort in der Crawl-Warteschlange.
2. Rendering: Seiten mit Statuscode 200 kommen in eine Render-Warteschlange. Das kann laut Google einige Sekunden dauern, aber auch länger. Danach führt ein Headless Chromium, also ein Browser ohne Bildschirm, das JavaScript aus.
3. Zweiter Blick: Im gerenderten HTML sucht Google erneut nach Links und reiht die neu gefundenen Adressen ebenfalls zum Crawlen ein.

Ein per Skript erzeugter Link wird also gefunden, nur später als einer im ausgelieferten HTML. Eine Grenze bleibt: Google interagiert nicht mit der Seite. In der Anleitung zu Lazy Loading schreibt Google ausdrücklich, dass die Suche weder scrollt noch klickt. Ein Link, der erst nach einem Klick auf „Mehr anzeigen“ entsteht, existiert für Google nicht.

Crawlbar oder nicht: Beispiele im Vergleich

Die Tabelle fasst die Beispiele aus Googles Dokumentation zusammen und ergänzt zwei typische Fälle aus der Praxis. „Nicht empfohlen“ heißt bei Google: Man versucht eventuell trotzdem, den Link auszulesen, verlässt sich aber nicht darauf.

Markup	Einordnung	Warum
<a href="https://example.com">	crawlbar	a-Element mit absoluter Adresse
<a href="/produkte/schuhe">	crawlbar	relative Adresse, löst zu einer echten URL auf
<a href="/produkte/schuhe" onclick="goTo('schuhe')">	crawlbar	das href trägt, das Skript stört nicht
per Skript eingefügtes <a href="/ziel/">	crawlbar nach dem Rendering	Google findet es im gerenderten HTML
<a onclick="goto('https://example.com')">	nicht empfohlen	kein href, Ziel steht nur im Skript
<span href="https://example.com">	nicht empfohlen	kein a-Element
<a routerLink="produkte/kategorie">	nicht empfohlen	Framework-Attribut statt href
<a href="javascript:goTo('produkte')">	nicht empfohlen	keine echte Webadresse
<button onclick="location.href='/ziel/'">	kein Link	Schaltfläche, kein a-Element
Link erscheint erst nach Klick	nicht auffindbar	Google klickt nicht

Eine Sonderform betrifft Single-Page-Anwendungen, die Ansichten über Fragmente wie #/produkte wechseln. Google rät dort zur History-API, damit jede Ansicht eine eigene, auslesbare URL bekommt.

Auf der eigenen Website: Menüs, Filter und „Mehr laden“

Für die eigene Website sind JavaScript-Links vor allem ein Thema der internen Verlinkung. Die typischen Fehler entstehen nicht aus Absicht, sondern weil ein Baukasten oder Framework Schaltflächen statt Links erzeugt:

• Navigation als Schaltflächen: Ein Mega-Menü, dessen Einträge <div onclick> sind, verbindet für Google keine einzige Kategorie. Die Unterseiten hängen dann allein an der XML-Sitemap und an externen Links.
• „Mehr laden“ statt Seitenzahlen: Lädt eine Liste weitere Artikel nur per Klick nach, sieht Google nur die erste Portion. Ältere Beiträge werden so zur verwaisten Seite, obwohl Besucher sie finden.
• Filter und Reiter: Inhalte in Tabs oder Akkordeons sind unproblematisch, solange die Links darin schon im Dokument stehen und nicht erst beim Öffnen nachgeladen werden.

Auch der Ankertext hängt am Markup. Setzt ein Skript den Linktext erst nachträglich, empfiehlt Google, mit der URL-Prüfung der Search Console zu kontrollieren, ob er im gerenderten HTML ankommt. Ob ein per Skript nachträglich gesetztes oder entferntes rel-Attribut zählt, dokumentiert Google nicht. Verlassen Sie sich deshalb für nofollow und sponsored auf das ausgelieferte HTML.

Eingehende Links aus JavaScript-Widgets

Besonders relevant wird das Thema, wenn andere Websites Ihren Code einbinden: Bewertungssiegel, Auszeichnungs-Badges, Rechner, Karten oder eingebettete Infografiken. Ob daraus ein Backlink wird, entscheidet die Form des Einbettungscodes.

• Statischer Link im Code: Der Einbettungscode enthält neben dem Skript ein festes <a href>. Der Link steht im HTML der einbindenden Seite und wird schon beim ersten Abruf erkannt. Das ist die robusteste Variante.
• Nur ein Script-Tag: Das Skript schreibt den Link erst beim Laden. Google kann ihn beim Rendering finden, wenn er als <a href> entsteht und das Skript abrufbar ist. Sperrt der Anbieter seine Skript-Adresse in der robots.txt, kann Google es nicht laden.
• iframe: Der Inhalt stammt aus einem eigenen Dokument auf der Domain des Anbieters. Ob Google einen Link darin der einbindenden Seite zuordnet, ist nicht dokumentiert. Als Backlink der einbindenden Domain sollten Sie ihn nicht zählen.
• Klick-Handler oder Tracking-Weiterleitung: Führt das Widget nur per onclick oder über eine Skript-Weiterleitung zum Ziel, entsteht kein auslesbarer Link.

Wie sich Rechner und andere kleine Werkzeuge als Linkquelle aufbauen lassen, beschreibt der Beitrag Kostenlose Tools als Linkmagnet. Siegel und Einbettungscodes bekommen im Glossar eigene Einträge (Badge-Linkbuilding, Embed-Code).

Beispiel: ein Bewertungssiegel prüfen

Ein angenommener Handwerksbetrieb wird auf einem regionalen Bewertungsportal gut bewertet und baut dessen Siegel auf seiner Website ein. Umgekehrt prüft das Portal, ob seine Siegel bei den Betrieben als Link ankommen. So geht es dabei vor:

1. Quelltext: Mit Strg+U zeigt die Seite des Betriebs nur ein <script src> und ein leeres <div>. Im ausgelieferten HTML gibt es keinen Link.
2. Entwicklertools: Im Reiter „Elemente“ steht nach dem Laden ein <a href="https://portal.example/betrieb/"> mit Bild und Alt-Text. Der Link entsteht also beim Rendering und ist grundsätzlich auffindbar.
3. Gegenprobe: Werkzeuge, die nur das ausgelieferte HTML lesen, übersehen den Link. Das Portal stellt deshalb einen zweiten Einbettungscode bereit, der das Siegel als festes <a href> mit <img> enthält und das Skript nur noch für die Sternanzeige nutzt.

Wie Sie Links im Quelltext und in den Entwicklertools zuverlässig unterscheiden, zeigt der Beitrag Dofollow-Links erkennen. Für die eigene Website gilt dieselbe Regel in kurz: Was verlinken soll, wird ein <a> mit echter Adresse, alles andere ist eine Schaltfläche.

Häufige Fragen

Alle 327 Begriffe im Glossar