Das URL-Kompendium

Das URL-Kompendium

Das ist wieder mal ein Post aus der Reihe der “longreads”. Aber keine Angst vor über 3500 Wörtern, dieser Post ist als Nachschlagewerk und Lernmodul zum Thema “URL” gedacht. Die Inhalte sind meiner Meinung nach notwendiges Grundwissen für eine kompetente Navigation im Web. Sollten Sie Anregungen haben oder sollten Sie etwas vermissen, schreiben Sie mir einen Kommentar oder kontaktieren Sie mich per Mail (steht im Impressum) oder im Fediverse auf Mastodon.

Inhaltsverzeichnis

1. Die Grundlagen
2. Die Details
3. Finden oder nicht finden
4. URLs kürzen
5. URLs teilen
6. URLs säubern
7. URLs gestalten

Die Grundlagen

Eine URL ist eines der grundlegenden Konzepte des World Wide Web. Mit Hilfe dieses Mechanismus laden Browser und andere Tools eine im Web publizierte “Resource” (z.B. Datei, Bild, Video, Audio). In der Theorie zeigt jede gültige URL auf eine eindeutige solche Resource. In der Praxis gibt es einige Ausnahmen wie beispielsweise eine URL, die auf eine Datei oder ein Bild zeigt, das nicht mehr existiert.

Der Aufbau einer URL

Eine URL ist eine speziell formatierte Zeichenkette, die sich aus verschiedenen Bestandteilen zusammen setzt. Hier ein Beispiel für eine URL:

https://developer.mozilla.org:8080/en-US/search?q=URL

Hinweis vorab: in einer URL darf kein Leerzeichen vorkommen. Diese URL besteht aus den folgenden Bestandteilen:

Zusätzlich gibt es noch die Möglichkeit, einen “fragment identifier anzugeben, der durch das Raute-Zeichen eingeleitet wird und eine sekundäre Referenz im Dokument angibt, z.B. den Abschnitt eines HTML-Dokuments.
https://www.arminhanisch.de/2019/07/das-twitterlehrerzimmer-feiern#sortieren
Damit lassen sich dann bestimmte Elemente in einem Dokument anspringen. Das erledigt allerdings der Webbrowser, denn der fragment identifier wird nicht an den Webserver übertragen, der Browser fordert immer die komplette Resource an.

Vergleich zu einer Postadresse

Um für Einsteiger eine Analogie zu schaffen, lässt sich eine URL als “Adresse” einer Resource im Web mit einer postalischen Adresse vergleichen.

Sonderzeichen in URLs

In einer URLs werden wie oben erklärt bestimmte Zeichen für bestimmte Zwecke verwendet und können daher nicht Bestandteil einer URL sein. Wie kann ich die dann trotzdem angeben? Diese Zeichen werden in einer bestimmten Art und Weise codiert. Für diese Zeichen wird der Zeichencode als hexadezimale Bytefolge angegeben, bei dem die Werte jeweils mit einem % als Präfix versehen werden. Möchte ich also auf meiner Homepage nach einem Prozentzeichen in Blogposts suchen, dann sieht die URL so aus: https://www.arminhanisch.de/search/?s=%25

Das %25 steht für “das Zeichen mit dem Code hex 25”, das ist dezimal 37 und ist der Code für das %. Der Zwinker-Smiley, den ich öfter verwendet, hat beispielsweise den Unicode-Code %F0%9F%98%89. Das Leerzeichen kann in URLs entweder als %20 oder (weil das so oft vorkommt), auch als + geschrieben werden.

Die Details

Jetzt kommen die interessanten Dinge, sozusagen das Kleingedruckte 😏

Protokoll/Schema

Das Schema http oder https kennen sicherlich die meisten. Das sind aber bei weitem nicht alle, mailto, file, data und andere sind noch etwas bekannter. Die Liste der registrierten Schemata wird bei der IANA verwaltet, der “Internet Assigned Numbers Authority”. Wer an der aktuellen Liste interessiert ist: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Host Name

Die Angabe eines Hostnamens (eigentlich eines registrierten Namens, das umfasst auch alle DNS-Hostnamen) kann auch über die IP-Adresse erfolgen. Da muss also nicht immer ein Name wie kiste.firma.de stehen, sondern es kann z.B. auf ein http://127.0.0.1:1313/static/logo.jpg als URL vorkommen. Falls es sich um eine IPv6-Adresse handelt, muss diese in einer URL in eckige Klammern eingeschlossen werden: http://[2001:4860:0:2001::68]/

Die Portnummer

Sie können sich einen “port” vorstellen wie eine Verfeinerung der Serveradresse. Über den Namen finden Sie den Rechner, aber nicht den Prozess, der für die Verarbeitung der Verbindungsanfrage zuständig ist. Sie können ja auf dem gleichen Rechner eine HTML-Seite ansehen, mit Spotify Musik hören und gleichzeitig eine Datei übertragen oder per Terminalsitzung auf dem Rechner eingelogged sein. Um das unterscheiden zu können, existieren die Portnummern. Auch diese werden von der IANA (siehe oben) verwaltet. Für jedes Netzwerkprotokoll (wie HTTP) gibt es einen definierten Standardport, der dann auch nicht angegeben werden muss. Für das Protokoll https ist der Standardport die Nummer 443, so dass die Angaben unten ebenfalls äquivalent sind:

• https://www.arminhanisch.de/2019/08/we-didnt-start-the-fire/
• https://www.arminhanisch.de:443/2019/08/we-didnt-start-the-fire/

Falls Sie einen Nicht-Standard-Port nutzen, müssen Sie die Portnummer in der URL angeben, z.B. http://localhost:1313/2019/09/url-kompendium/

Der Pfad

Haben Sie auch schon bemerkt, dass es URLs gibt, die mit einem Schrägstrich (slash) enden? Andere wiederum enden mit einem Dateinamen. Wo ist denn da der Unterschied?

https://example.org/documents/tutorials/intro	https://example.org/documents/tutorials/intro/

Die Verarbeitung der Anfrage erfolgt durch den Webserver. Endet eine URL mit einem Schrägstrich, so geht der Webserver davon aus, dass es sich bei dem letzten Teil des Pfades um ein Verzeichnis handelt. Im Normalfall sind Webserver so konfiguriert, dass dann in diesem Verzeichnis die Datei mit dem Namen index.html gesucht und zurück geliefert wird (je nach Konfiguration kann das auch index.htm oder index.php oder etwas anderes sein). Das interessiert den Browser nicht, das ist der Vorteil dieses Ansatzes.

Sie können das an diesen beiden URLs testen, die liefern funktional das gleiche Resultat:

• https://www.arminhanisch.de/2019/08/we-didnt-start-the-fire/index.html
• https://www.arminhanisch.de/2019/08/we-didnt-start-the-fire/

Endet die URL nicht mit einem Schrägstrich (slash), so geht der Webserver davon aus, dass es sich um eine Datei handelt. In unserem allerersten Beispiel https://developer.mozilla.org:8080/en-US/search?q=URL ist search also im Normalfall eine Datei (auch wieder abhängig von der Konfiguration des Webservers).

Die Parameter

Parameter (oft auch “query parameter” genannt) dienen der Übermittlung von zusätzlichen Informationen in einer URL. Beispielsweise werden so oft Suchbegriffe übertragen. Die Parameter werden mit einem ? (Fragezeichen) vom Rest der URL getrennt und bestehen aus einem Schlüssel und einem Wert. Ist mehr als ein Parameter vorhanden, werden diese durch ein kaufmännisches Und-Zeichen & (ampersand) getrennt. Hier ein Beispiel. Der Parameter mit dem Schlüssel s besitzt den Wert shuttle:

https://www.arminhanisch.de/search/?s=shuttle

Der “fragment identifier”

In der deutschen Literatur wird dieser oft auch als “Anker” oder “Lesezeichen” bezeichnet. Damit lassen sich im Browser dann bestimmte Stellen in einem HTML-Dokument gezielt nach dem Laden anspringen. Wie bereits weiter oben beschrieben, wird der fragment identifier nicht an den Webserver übermittelt. Es wird die komplette Resource angefordert und der Browser sucht dann im Dokument den identifier/das Lesezeichen und springt an diese Stelle. Beispiel: https://en.wikipedia.org/wiki/URL#Notes

Data-URLs

Data-URLs (gekennzeichnet durch das Schema data:) sind eine interessante Möglichkeit, Dokumente innerhalb des HTML-Dokuments einzubetten. Das können Bilder, Sounds oder textueller Inhalt sein. Mehr dazu gleich.

Syntax

Data URLs beginnen wie jede anderen URL auch mit dem schema (hier data:), dann folgt ein MIME-Typ (z.B. image/jpeg). Wird kein MIME-Typ angegeben, ist der Standard text/plain;charset=US-ASCII. Abhängig davon, ob es sich beim “Inhalt” um Text oder binäre Daten handelt, folgt nun entweder eine Kennung ;base64 oder nicht. Danach die mit einem Komma vom ersten Teil der URL abgetrennten Daten.

Das sind dann als Beispiel so aus: data:text/vnd-example+xyz;foo=bar;base64,R0lGODdh

Data-URLs lassen sich wie jede andere URL verwenden. Hier ein Beispiel (aus der Wikipedia), bei der für ein <img>-Element in HTML statt einer externen Bilddatei die base64-codierten Bilddaten enthält:

<img src="data:image/png;base64,iVBORw0KGgoAAA
ANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4
//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU
5ErkJggg==" alt="Red dot" />

Finden oder nicht finden …

Wie weiß der Browser eigentlich, ob die angeforderte Resource gefunden wurde? Wenn wir einige (OK, eine ganze Menge) technische Details außer Acht lassen, dann passiert Folgendes: wenn Sie in Ihrem Browser eine Internetadresse (eine URL) eingeben, fordert der Browser das Dokument beim genannten Server an. Dazu dient HTTP, das HyperText Transfer Protocol.

HTTP Statuscodes

Auf jede HTTP(S)-Anfrage antwortet der Webserver mit einem Statuscode (und weiteren Informationen), damit der HTTP(S)-Client (hier der Browser) weiß, wie weiter zu verfahren ist. Diese Statuscodes sind in Nummernbereiche aufgeteilt:

• 1xx – Informationen ("das interessiert eh wieder niemand”)
• 2xx – Erfolgreiche Operation ("passt")
• 3xx – Umleitung ("da geht’s lang")
• 4xx – Client-Fehler ("Du hast’s verbockt")
• 5xx – Server-Fehler ("Ich hab’s verbockt")
• 9xx – Proprietäre Fehler ("Ich will aber eine eigene Meldung")

Eine vollständige Liste finden Sie in der Wikipedia. Geht alles gut, erhält der Browser vom Webserver einen 200er-Code zurück (meist 200 oder 204). Wurde die angeforderte Resource nicht gefunden, dann gibt der Webserver den Code 404 (“not found”) zurück. Auf diese Weise erhält der Browser für jede Anforderung in den Kopfdaten der Antwort also eine Rückmeldung, ob und wie die URL beschafft werden konnte.

Tipp für den Unterricht

Ist eine Resource aufgrund nationaler gesetzlicher Einschränkungen nicht verfügbar (ja, ich meine staatl. Zensur), dann liefern Webserver seit etwa 2015 den HTTP-Statuscode 451 zurück. Die geneigte Leserin bzw. die SuS können ja mal raten, warum ein “unavailable for legal reasons” ausgerechnet den Code 451 liefert. Wer überhaupt keine Idee hat, kann im entsprechenden RFC-Dokument ja mal den Abschnitt “Acknowledgements” am Ende des Dokumente durchlesen, das sollte einen Hinweis geben. 😏

URLs kürzen

Niemand mag lange URLs. Zumindest dann nicht, wenn Sie von Hand eingegeben werden müssen. Aus diesem Grund existieren viele Dienste, um eine URL zu “kürzen”. Natürlich können Sie eine URL nicht einfach “abschneiden”, sondern Sie definieren eine Ersatz-URL, die (hoffentlich 😄) kürzer ist als die originale URL. Ein Kurz-URL Dienst (engl. URL shortening service) dienst dazu, eine lange URL wie https://www.arminhanisch.de/2018/11/byod-or-not-to-byod/ unter einer Art Alias z.B. als https://jmp.to/byod verfügbar zu machen. Damit lässt sich diese kurze URL wesentlich leichter eingeben bzw. nutzt bei sozialen Medien weniger Platz. Alles, was dazu benötigt wird, ist also eine Tabelle mit der kurzen URL als Schlüssel, die dann auf die lange URL verweist.

Was passiert da eigentlich?

Unabhängig davon, wie solche Kurz-URLs entstehen, der Mechanismus ihrer Nutzung ist immer der Gleiche: beim Aufruf der gekürzten URL erfolgt eine Weiterleitung auf die ursprüngliche Adresse. So einfach, so gut. Aber was bedeutet dieser Satz?

Wenn wir einige (OK, eine ganze Menge) technische Details außer Acht lassen, dann passiert Folgendes: wenn Sie in Ihrem Browser eine Internetadresse (eine URL) eingeben, fordert der Browser das Dokument beim genannten Server an. Dazu dient HTTP, das HyperText Transfer Protocol. Dazu zerlegt der Browser die URL erst einmal in die einzelnen Bestandteile. Aus https://jmp.to/shorty wird:

• https – die Angabe des Protokolls hier (https)
• jmp.to – der Zielrechner der Anfrage
• /shorty – der Pfad zum Dokument auf dem Server

Der Browser stellt also eine Verbindung zum Rechner mit dem Hostnamen jmp.to her und fordert dann dort das in der URL enthaltene Dokument an. Netterweise ist HTTP/HTTPS ein textbasiertes Protokoll, so dass wir relativ einfach “mitlesen” können.

GET /shorty HTTP/1.1

Das erste Wort (engl. verb) ist das HTTP-Kommando (prinzipiell gibt es welche zum Lesen, Aktualisieren, Erzeugen und Löschen von Dokumenten)

Auf jede HTTP(S)-Anfrage antwortet der Webserver mit einem Statuscode (siehe weiter oben). Eine erfolgreiche Anforderung würde als den Statuscode 200 liefern. Im Falle unserer Kurz-URL bekommt der Browser jedoch folgende Antwort:

HTTP/1.1 307 Temporary Redirect
Content-Type: text/html; charset=utf-8
Location: https://www.arminhanisch.de/2018/11/byod-or-not-to-byod/
Date: Sun, 02 Dec 2018 21:21:52 GMT
Content-Length: 92

<a href="https://www.arminhanisch.de/2018/11/byod-or-not-to-byod/">Temporary Redirect</a>.

Darauf der Browser: “Oh, ein 307! Dann geh ich und hol das Dokument, das in Location: steht”. Ihr Browser folgt dann automatisch dem Redirect und lädt das in der Headerzeile Location: angegebene Dokument. Und schon landen Sie ganz bequem bei der langen Zieladresse, ohne diese eingeben zu müssen.

Wieso jetzt 307 und nicht 301?

Kleiner Exkurs für Interessierte: warum 307? 301 würde ja auch reichen. Wichtigster Unterschied: es gibt permanente Umleitungen und temporäre Umleitungen. Bei einer 301 ist das ein permanenter Redirect, also ein “vergiss diese URL (die kurze), nur das Umleitungsziel (die lange) ist gültig”. Da wir aber die kurze Version ebenfalls behalten wollen (sonst wäre das ganze Projekt “URL-Kürzung” ja sinnlos 😄), benutzen wir einen temporären redirect. Wenn Sie der Unterschied zwischen 301 und 307 interessiert, sind Sie für diesen Post sowieso überqualifiziert (suchen Sie im Web einfach nach “http 302 307 difference”).

Ja, es gibt auch noch den HTTP Code 302 ("Found"). Das ist immer noch ein häufig verwendeter Statuscode, der aber von vielen Clients und Servern als Mischmasch zwischen “See other” und “Temporary Redirect” verwendet wurde. Mit HTTP/1.1 wurden deshalb die Codes 303 und 307 eingeführt, um diese Doppeldeutigkeit aufzulösen.

Wer kürzt am besten?

Es gibt mittlerweile Dutzende Dienste, die eine Kurz-URL anbieten, vom “Ur-Vater” TinyURL über bit.ly oder t1p.de bis zu eigenen Diensten von sozialen Medien wie t.co von Twitter. Warum soll ich mich dann mit dem Thema beschäftigen? Gibt’s doch kostenlos? Weil das sich Verlassen auf einen externen URL-Shortener immer mit Nachteilen verbunden ist.

Lebensdauer

Viele Anbieter solcher kostenlosen Dienste werben mit “unbegrenzter” Lebensdauer der so erzeugten Links. Das klingt solange gut, bis “unbegrenzt” dann bedeutet “solange wir nicht aus irgendeinem Grund den Betrieb einstellen”. Ganze Linksammlungen sind so schon aus dem Web verschwunden. Ich selbst habe bereits drei Kurzlink-Dienste aus dem Web verschwinden sehen.

Missbrauch / Blocking

Eine ganze Reihe von Anbietern von gekürzten URLs musste bereits aufgeben, weil der Dienst durch Spammer missbraucht wurde. Nicht nur Sie nutzen einen solchen Dienst, sondern das ganze Web. Stellt sich heraus, dass ein Großteil des Traffics von der entsprechenden Domain Spam ist oder auf Malware verweist oder gegen die Domainregistrierungs-Richtlinien der jeweiligen Top-Level-Domain verstößt, dann wird diese Domain vom Netz genommen. Ihre Links sind dann weg oder mit Roy Batty gesprochen “All diese Momente werden verloren sein in der Zeit, so wie Tränen im Regen” (ja, ich bin Blade Runner Fan 😏).

Datenschutz

Neben der Tatsache, dass ein solche Linkdienst eben auch erfährt, welche URLs von welchen IP-Adressen aufgerufen werden (die wenigsten bieten einen De-Referrer), gibt es noch weitere Nachteile hinsichtlich Datenschutz. Wird ein Kurzlink-Dienst gehackt, können die Ziel-URLs geändert werden, beispielsweise auf Phishing-Seiten oder Seiten mit Scripting-Angriffen oder Malware. Verhindern lässt sich dies beispielsweise dadurch, dass es möglich ist, zu einem Kurzlink erst einmal das Ziel anzuzeigen und nicht sofort direkt aufzurufen. Bei vielen Diensten ist dies aber eine kostenpflichtige Zusatzfunktion.

Bezahlte Features

Weniger ein Nachteil als ein Denkanstoß: wenn Sie für einen Premium-Zugang zu einem Kurz-URL-Dienst Geld bezahlen, um beispielsweise eine Anzeige des Linkziels oder die Erzeugung von QR-Codes zu erhalten, dann können Sie auch für einen virtuellen Server bezahlen, der Ihre eigene Domain hostet und dort selbst einen Kurzlink-Dienst einrichten, den nur Sie benutzen dürfen. Wenn Sie schon Geld ausgeben, sollten Sie auch das Sagen haben. 😄

Wann überhaupt kürzen?

Es gibt auf Twitter immer wieder LuL, die eine URL in einem Tweet packen und diese vorher mit einem der üblichen Dienste verkürzen. Dann packen sie diese URL (z.B. t1p.de/bwrzgl) in einen Tweet. Nun besitzt Twitter aber einen eigenen Dienst und kürzt alle URLs selbst (deshalb die t.co-Links in den Tweets), so dass ein Link in einem Tweet immer nur 24 Zeichen benötigt. Das ist dann “doppelt gemoppelt” und unsinnig. Dazu kommt, dass beim Klick auf den Link dieser über den Kürzungsdienst von Twitter aufgelöst wird, da die andere gekürzte URL rauskommt, diese vom zweiten Dienst aufgelöst wird und dann irgendwann die tatsächliche URL vom Browser angefordert wird. Daher: bei Twitter immer die originalen Links eintragen, Twitter kürzt selbst.

Kurzlinks ganz billig

Nicht jedes Mal muss es ein externe Dienst für die Kürzung von Links sein. Ganz im Sinne von “own your stuff” können Sie selbst ebenfalls für Ihre Homepage kurze Links definieren. Nehmen wir an, Ihre Homepage liegt auf der Domain fraudings.de. Was spricht gegen einen Kurzlink fraudings.de/23115.html?

Dazu legen Sie im Hauptverzeichnis Ihres Webauftritts eine Datei 23115.html (jaaa, das ist ein Beispiel, ich würde nicht mit dem Zählen bei 23115 beginnen 😄) an. Die bekommt den folgenden Inhalt:

<!DOCTYPE html>
<html>
<head>
	<title>Kurzlink</title>
	<meta http-equiv="refresh" content="5; URL=http://www.example.com/">
</head>
<body>
	<h2>Das ist ein Kurzlink mit automatischer Weiterleitung</h2>
	<p>Sollten Sie nicht innerhalb von fünf Sekunden weitergeleitet werden, 
	dann klicken Sie bitte <a href="http://www.example.com/">hier</a></p>
</body>
</html>

Die URL http://www.example.com/ ersetzen Sie durch die gewünschte “lange” URL. Fertig! Ob Sie nun Zahlen oder Kombinationen aus vier Buchstaben nutzen, bleibt Ihnen überlassen. Der große Vorteil jedoch ist, dass eine URL wie fraudings.de/5400 immer noch “abtippbar” ist, aber auf Ihrem Server und unter Ihrer Kontrolle liegt.

Das ist nur eine Methode. Sollten Sie in der Konfiguration Ihres Webserver erfahrenerer sein, dann empfehle ich Ihnen, dass über die Redirects des Webservers zu erledigen, das ist weniger Aufwand, erfordert aber auch Wissen und Zugänge, die nicht alle Nutzerinnen einer Homepage haben.

URLs teilen

Wo wird’s geteilt?

Die große Frage zu Beginn ist die nach dem Medium. Wollen Sie eine URL in einem digitalen Medium teilen oder analog ("Tinte auf toten Bäumen")? Falls eine URL elektronisch geteilt wird, dann ist der beste Weg ein einfacher Link (egal ob in einem HTML-Dokument, in Keynote, Powerpoint oder einfach als Angabe der URL). Das erlaubt es, diesen Link einfach anzuklicken. Fast überall kann die Beschriftung des Links auch unabhängig vom Link selbst gestaltet werden, so dass für die Anzeige bei langen URLs kein Platz vergeudet werden muss: Hier, ein Link. Bei Offline/Analog-Medien sind lange Links natürlich “suboptimal”. Kein Mensch möchte ein 300 Zeichen-Monster abtippen. An dieser Stelle können Kürzungsdienste für URLs (siehe hier) gute Dienste leisten.

QR-Codes

QR-Codes (das “QR” ist ein Acronym für “quick response”) sind diese zweidimensionalen quadratischen Codes mit den vielen Punkten, die Sie sicher aus diversen Dokumenten, Infotafeln und dem Web kennen. Diese wurden ursprüngliche zu Zwecken der Logistikoptimierung in der Automobilindustrie entwickelt, haben sich aber auch schnell in anderen Bereichen verbreitet. Sie erlauben eine einfache Überbrückung des Medienbruchs zwischen der analogen und der digitalen Welt. Wird der Code eingelesen, können die darin enthaltenen Daten von einem Programm verarbeitet werden. Unter anderem können in einem QR-Code auch URLs gespeichert werden, die dann im Browser geöffnet werden. Das Konzept dahinter ist kein Geheimnis, eine Einführung finden Sie z.B. hier. Mit etwas Geduld und Stift und Papier lassen sich QR-Codes sogar komplett ohne App lesen!

Hybrid-Dokumente

Viele Dokumente im Bildungsbereich haben einen hybriden Einsatzzweck, d.h. Sie werden digital verteilt, können aber auch ausgedruckt werden. Hier sollten Sie bei der Planung auch diese beiden Verwendungszwecke im Kopf haben und nicht nur die eine Seite bedienen, denn die andere wird dabei unweigerlich leiden. Was meine ich damit?

Viele Dokumente nutzen QR-Codes, allerdings nur den QR-Code. Dann wird das Dokument, da es ja auch online verfügbar sein soll beispielsweise als PDF verteilt. Wenn ich das Dokument nun auf meinem Computer öffne, bin ich der Gelackmeierte. Was soll ich mit einem QR-Code? Ich brauche einen Link! Daher bitte immer daran denken, den QR-Code im Dokument mit einem Link zu hinterlegen, so dass beim Öffnen auf einem Computer, Tablet oder Smartphone der Link angeklickt werden kann.

Zusatztipp: als Link für QR-Codes (sowohl für die Nutzlast des Codes als auch den Link um den Code) sollten Sie immer eine ungekürzte URL angeben. Das erlaubt mir, mich vor dem Öffnen des Links zu informieren, wo dieser hinführt. In den QR-Code gehen über Tausend Zeichen und digital brauche ich auch keine gekürzten Links.

Wo brauche ich dann einen Kurzlink?

Ganz einfach: wenn die Nutzung nicht komplett digital erfolgt. Klassisches Beispiel sind Vorträge mit Links, bei denen die Slides später verteilt werden. Dann lässt sich der Link in einen QR-Code stecken. Während des Vortrags hat das Publikum aber nichts davon. Unter Umständen möchte sich jemand den Link notieren, dann wäre es Unsinn, hunderte von Zeichen für den Link zu zeigen. Hier ist ein Kurz-Link wirklich sinnvoll. Dieser wird mittig unter dem QR-Code angeordnet und schon haben wir das Beste aus beiden Welten.

Ja, richtig gelesen. In den QR-Code kommt (siehe oben) der ungekürzte Link und unter dem QR-Code wird der gekürzte Link angegeben. Rufe ich den auf, lande ich ja ebenfalls beim ungekürzten Link. Der Kurzlink ist nur ein Alias, sonst nichts.

URLs säubern

URLs säubern? Rosten die etwa? 😏 Nein, das tun Sie nicht, aber wenn Sie eine URL teilen, dann sollten Sie nicht immer einfach den Inhalt der Adresszeile im Browser kopieren und irgendwo einfügen. Warum? Weil da ganz oft Parameter in der URL enthalten sind, die Sitzungsinformationen, Werbe- und Trackingdaten oder für das Linkziel unnötige Informationen enthalten. Sehen wir uns ein Beispiel an: The Verge hat einen interessanten Artikel über “AN EXCLUSIVE LOOK AT AN ORIGINAL IPHONE PROTOTYPE” veröffentlicht. Den hat jemand auf Twitter geteilt und die URL sieht wie folgt aus:

https://www.theverge.com/2019/3/19/18263844/apple-iphone-prototype-m68-original-development-board-red?utm_campaign=theverge&utm_content=chorus&utm_medium=social&utm_source=twitter

Was Sie hier sehen, sind einige Query Parameter (s. Grundlagen), die alle mit utm_ beginnen. UTM ist eine Abkürzung für urchin tracking module und dient der Werbeverfolgung Ihrer Aktivitäten. Schon allein deshalb ein Grund, das Zeug aus der URL zu verbannen, bevor der Link weitergegeben wird. Wenn Sie mehr zum Thema “utm” erfahren wollen, hier ist ein deutscher Artikel, der das Prinzip erklärt. Alles, was mit utm_ beginnt, kann also weg. Das sonst keine weiteren Parameter mehr vorkommen, kann auch das ? entfernt werden, das in einer URL die Parameter vom Rest der URL trennt. Übrig bleibt also folgende “saubere” URL:

https://www.theverge.com/2019/3/19/18263844/apple-iphone-prototype-m68-original-development-board-red

Noch ein Beispiel für einen Buchlink bei Amazon. In der Adresszeile des Browsers steht:

https://www.amazon.de/Old-Mans-War-John-Scalzi/dp/0765348276/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=old+mans+war&qid=1568110339&s=gateway&sr=8-1

Wissen Sie, was genau gut funktioniert und kürzer, leichter verteilbar und frei von den Resten der Suche nach dem Buch ist? Das hier:

https://www.amazon.de/Old-Mans-War-John-Scalzi/dp/0765348276/

(Die Zahl ist übrigens die ISBN-10). Also, etwas Frühjahrsputz schadet auch bei der Weitergabe von URLs nicht und zeugt von Medienkompetenz.

Viele Tracking-Mechanismen arbeiten ebenso mit Parametern an der URL. So existiert bei Google z.B. ein gclid-Parameter für die Clickauswertung und bei Facebook heisst dieser Parameter fbclid (Facebook Click ID). Diese Parameter sollten Sie also beim Weitergeben einer URL auf jeden Fall entfenrnen. Das hilft nur den Datensammlern, bringt aber kein Bit an Informationen für Empfänger der URL.

Es gibt im Web haufenweise Online-Tools, die dabei helfen, Links zu säubern. Eine Suche nach “URL Cleaner” oder “Link cleaner” hilft da weiter.

URLs gestalten

Dieser Abschnitt ist für alle interessant, die entweder selbst ein Blog betreiben oder aber Informationen unter einer URL zur Verfügung stellen. Es gibt einige “best practices”, wie eine URL aufgebaut werden sollte. Dies ist nicht nur für irgendwelche Suchmaschinen relevant, sondern vor allem auch für die Menschen, die mit diesem URLs arbeiten. Alle folgenden URLs sind rein fiktive Beispiele und funktionieren daher nicht beim Anklicken! 😏

Eine URL ist die Adresse einer Resource im Web. Das bedeutet, dass URLs stabil sein sollten. Haben Sie beispielsweise ein Blog und wechseln die Software, dann sollte das, was vorher unter der URL https://example.org/2019/trip-to-italy/ verfügbar war, auch danach wieder unter der gleichen URL verfügbar sein.

“Stabil” bedeutet aber auch, dass für eine URL, die wirklich nicht mehr genutzt wird, eine Weiterleitung ("redirect") auf die neue URL eingerichtet wird, so dass die alte URL immer noch parallel zur neuen URL funktioniert. Ansonsten hat jemand, der vor zwei Jahren einen interessanten Artikel in seiner Leseliste gespeichert hat, wieder mal Pech gehabt.

URLs sollten einen “sprechenden” Aufbau besitzen. Also nicht https://beispiel.de/blog?post=123670 als URL, sondern https://beispiel.de/blog/2019/06/pecorino-sorten/ – damit kann ich was anfangen, wenn ich die URL sehe, mit “123670” habe ich keine Ahnung, um was es in dem Blogpost geht.

Im Idealfalls zeigen URLs den hierarchischen Aufbau einer Website. Wenn ich aus https://beispiel.de/blog/2019/06/pecorino-sorten/ ein https://beispiel.de/blog/2019/06/ mache, komme ich im Idealfall zur Übersicht des Monats Juni 2019.

URLs sollten so kurz und einfach wie möglich sein. Keine Sonderzeichen, Umlaute oder anderes. Trennungen von Worten in einer URL mit Bindestrichen, nicht mit Unterstrichen (ist nicht nur auf der deutschen Tastatur einfacher, sondern Google erkennt Worttrennung nur bei Bindestrichen).

Das waren nur ein paar Anregungen, was beim Entwurf einer URL-Struktur für den eigenen Online-Auftritt beachtet werden sollte.