Der Link ist das älteste und wichtigste Element des Webs, und trotzdem stecken in vielen Seiten dieselben Fehler: Sprungmarken, die unter der Kopfzeile verschwinden, doppelte IDs, rel-Werte nach Gefühl und Linktexte wie „hier“. Dieser Beitrag zeigt, was die HTML-Spezifikation heute vorgibt, was sich seit HTML 4.01 geändert hat und welche Regeln für Barrierefreiheit und Suchmaschinen zählen.
Von a name zu id: was sich seit HTML 4.01 geändert hat
HTML 4.01 kannte zwei Wege, ein Sprungziel zu setzen: das Attribut name am Element A und das Attribut id an beliebigen Elementen. Beide teilten sich laut Spezifikation denselben Namensraum. Daneben gab es rel für die Beziehung vom aktuellen Dokument zum Ziel und rev für die umgekehrte Richtung.
Der heutige HTML Living Standard der WHATWG führt name an a als veraltet, aber noch konform: Autoren sollen es nicht mehr verwenden, stattdessen id. rev ist ganz gestrichen, an seine Stelle tritt rel mit dem passenden Gegenbegriff. Wer eine alte Seite pflegt, ersetzt also <a name='kontakt'></a> durch eine id direkt an der Überschrift oder am Abschnitt. Leere Anker-Elemente als Sprungziel braucht niemand mehr.
href: absolute, relative und besondere URLs
Das Attribut href nimmt jede gültige URL auf. In der Praxis kommen vier Formen vor:
<!-- absolut: für fremde Seiten -->
<a href='https://www.w3.org/'>Website des W3C</a>
<!-- wurzelrelativ: für die eigene Domain -->
<a href='../../de/kontakt/'>Kontakt</a>
<!-- relativ zum aktuellen Verzeichnis -->
<a href='../bilder/plan.pdf'>Lageplan (PDF)</a>
<!-- Schemas für E-Mail und Telefon -->
<a href='mailto:[email protected]'>[email protected]</a>
<a href='tel:+493012345678'>030 12345678</a>
Für interne Links sind wurzelrelative Pfade meist die robusteste Wahl: Sie überstehen einen Wechsel von http auf https oder von einer Staging- auf die Live-Domain, brechen aber nicht, wenn eine Seite in ein anderes Verzeichnis wandert. Rein relative Pfade wie ../ sind fehleranfällig, sobald Templates auf verschiedenen Ebenen eingebunden werden. Absolute URLs gehören in RSS-Feeds, E-Mails und kanonische Angaben, weil dort der Bezugspunkt fehlt.
Wichtig für Suchmaschinen: Google wertet laut eigener Dokumentation zuverlässig nur <a>-Elemente mit href aus. Ein <span> mit Klick-Handler oder href='javascript:…' ist für den Crawler kein verlässlicher Link. Ein zusätzlicher onclick stört dagegen nicht, solange href eine echte URL enthält.
Sprungmarken mit id und Fragment-Links
Ein Fragment-Link besteht aus # und dem Wert einer id. Er funktioniert innerhalb der Seite und von außen:
<nav>
<a href='#preise'>Zu den Preisen</a>
</nav>
<h2 id='preise'>Preise</h2>
<!-- von einer anderen Seite aus -->
<a href='../../de/angebot/#preise'>Preise im Angebot</a>
href='#top' oder ein leeres href='#' führen laut HTML-Spezifikation an den Seitenanfang, auch ohne Element mit dieser ID. Bei fester Kopfzeile landet die Überschrift sonst unter der Leiste. Das löst eine Zeile CSS, die laut MDN seit April 2021 in allen gängigen Browsern funktioniert:
h2[id], section[id] {
scroll-margin-top: 5rem; /* Höhe der festen Kopfzeile */
}
Wie Sprungmarken und Inhaltsverzeichnisse in eine durchdachte Menüführung passen, beschreibt der Beitrag Website-Navigation gestalten.
id und class: der Unterschied in der Praxis
Eine id muss im ganzen Dokument eindeutig sein, darf keine Leerzeichen enthalten und jedes Element hat höchstens eine. class nimmt dagegen mehrere, durch Leerzeichen getrennte Werte auf und darf beliebig oft vorkommen. Die Faustregel: id für Sprungziele, Formular-Verknüpfungen (label for) und ARIA-Bezüge, class für Gestaltung. Wer IDs zum Stylen nutzt, handelt sich unnötig hohe Spezifität ein.
Technisch darf eine ID fast jedes Unicode-Zeichen enthalten. MDN rät trotzdem zu Werten, die gültige CSS-Bezeichner sind. Eine ID wie 1234 ist erlaubt, muss im Selektor aber maskiert werden, etwa mit CSS.escape(). Kurze, sprechende Werte in Kleinbuchstaben mit Bindestrich (versandkosten, faq-rueckgabe) vermeiden das Problem und ergeben lesbare Fragment-URLs. Doppelte IDs entstehen oft, wenn ein Baustein zweimal auf derselben Seite landet. Der Nu HTML Checker des W3C meldet sie zuverlässig.
rel-Werte: noopener, noreferrer, nofollow, sponsored, ugc
Das Attribut rel beschreibt die Beziehung zum Ziel. Ein Teil der Werte ist in HTML definiert, sponsored und ugc stammen von Google.
| Wert | Wirkung | Wann einsetzen |
|---|---|---|
| noopener | neues Fenster erhält keinen Zugriff auf window.opener | bei target='_blank' heute automatisch, explizit nur für ältere Browser |
| noreferrer | sendet keinen Referrer, schließt noopener ein | wenn das Ziel nicht erfahren soll, woher der Besuch kommt |
| nofollow | Autor macht sich den Link nicht zu eigen | wenn weder sponsored noch ugc passt |
| sponsored | bezahlter Link oder Werbung | Affiliate-Links, gekaufte Platzierungen |
| ugc | Link aus Nutzerinhalten | Kommentare, Forenbeiträge |
Mehrere Werte lassen sich kombinieren, etwa rel='ugc nofollow'. Google folgt solchen Links laut Search Central in der Regel nicht, kann die Zielseiten aber über Sitemaps oder andere Links trotzdem finden. Für interne Links ist nofollow der falsche Hebel: Was nicht gecrawlt werden soll, gehört in die robots.txt. Mehr zum Zusammenspiel von Links und Rankings steht im Beitrag zur Suchmaschinenoptimierung.
target='_blank' ist kein Sicherheitsrisiko mehr
Früher konnte eine in einem neuen Tab geöffnete Seite über window.opener die Ursprungsseite umleiten, ein Einfallstor für Phishing. Nach MDN verhält sich target='_blank' heute so, als wäre rel='noopener' gesetzt. Die eigentliche Frage ist eine der Bedienbarkeit: Ungefragt neue Tabs verwirren viele Nutzer, besonders mit Screenreader. Neue Fenster lohnen sich für PDFs oder Hilfetexte mitten in einem Formular, nicht als Standard für alle externen Links.
Das download-Attribut
Mit download bittet der Link den Browser, das Ziel zu speichern statt anzuzeigen. Ein optionaler Wert schlägt den Dateinamen vor:
<a href='/dateien/preisliste-2026.pdf' download='Preisliste.pdf'>
Preisliste herunterladen (PDF, 240 KB)
</a>
Die Einschränkung, an der viele scheitern: download greift laut MDN nur bei URLs derselben Herkunft sowie bei blob:- und data:-URLs. Bei Dateien auf einem CDN oder einer anderen Domain ignoriert der Browser das Attribut. Dann muss der Server den Download per Content-Disposition: attachment erzwingen.
Text Fragments: Links auf eine Textstelle
Text Fragments verlinken auf eine Textstelle, auch wenn die Seite dort keine ID hat. Die Syntax lautet #:~:text=[präfix-,]anfang[,ende][,-suffix], Sonderzeichen werden prozentkodiert:
https://example.com/ratgeber/#:~:text=Widerrufsfrist%20von%2014%20Tagen
Der Browser scrollt zur Fundstelle und hebt sie hervor. Laut web.dev unterstützen Chrome und Edge das seit Version 89, Firefox seit 131 und Safari seit 18.2. Browser ohne Unterstützung öffnen die Seite einfach oben. Groß- und Kleinschreibung spielt keine Rolle, in iframes wird nicht gesucht. Für die eigene Seite bleibt die ID die bessere Wahl, weil sie auch nach Textänderungen hält. Text Fragments eignen sich zum Zitieren fremder Seiten.
Linktexte für Screenreader und Google
WCAG 2.2 verlangt in Erfolgskriterium 2.4.4 (Stufe A), dass sich der Zweck eines Links aus dem Linktext allein oder zusammen mit seinem Kontext ergibt. Screenreader-Nutzer lassen sich oft eine Liste aller Links ausgeben, und fünfmal „hier“ hilft dort niemandem. Google empfiehlt dasselbe aus anderem Grund: beschreibende, knappe Ankertexte, keine generischen Formulierungen wie „Klicken Sie hier“ oder „Weiterlesen“ und bei verlinkten Bildern einen aussagekräftigen alt-Text, der als Ankertext dient.
- Schlecht: „Die Preisliste finden Sie hier.“
- Besser: „Die Preisliste 2026 (PDF, 240 KB) enthält alle Tarife.“
- Dateityp und Größe bei Downloads in den Linktext schreiben.
- Keine Linkketten ohne Text dazwischen, keine Keyword-Häufungen.
Quellen
- WHATWG: HTML Standard, Edition for Web Developers – Links
- WHATWG: HTML Standard – Obsolete features
- W3C: HTML 4.01 Specification – Links
- MDN: The Anchor element
- MDN: id
- Google Search Central: Ausgehende Links für Google eingrenzen
- Google Search Central: Link best practices for Google
- web.dev: Text Fragments







