Google scheint domaininterne Kurzlinks auf Artikel zu lieben - Struktur der Links auf einzelne Artikel innerhalb eines Content Management Systems (CMS)

03.10.2017 17:16:46, Jürgen Auer, keine Kommentare

Wenn man - als Entwickler - ein wie immer geartetes Content Management System entwickelt, mit dem regelmäßig Artikel veröffentlicht werden sollen:

Dann stellt sich die Frage: Wie soll man die Links zu den Artikeln gestalten?

Da finden sich unterschiedlichste Varianten.

Bsp. /2017/10/03/Artikelname/ für einen heute veröffentlichten Beitrag.

Wobei "Artikelname" den tatsächlichen Artikelnamen in Kleinbuchstaben enthält, bereinigt um alle Sonderzeichen.

Allerdings hat das einen entscheidenden Nachteil: Wenn im Artikelnamen einzelne Buchstaben fehlen oder zuviel sind, wird ein 404 Http-Statuscode, ein "nicht gefunden" ausgegeben.

Anstatt daß auf die korrekte Version weitergeleitet wird.

Problematisch kann das bei Schreibfehlern im Titel sein, die man erst hinterher bemerkt. Wenn der Link bereits bei Facebook, Twitter oder Xing geteilt wurde oder wenn der falsche Link bereits von Suchmaschinen gespidert wurde und erst dann angepaßt wird: Die Besucher über soziale Netzwerke und die Suchmaschinen laufen ins Leere.

Ich hatte deshalb hier eine andere Lösung entwickelt:

Einer Abfrage werden die beiden Url-Ausdrücke /path-1/path-2 übergeben. Wobei der Webserver bereits im Vorfeld versucht, alles nach dem letzten Bindestrich in path-2 abzuschneiden und als Zahl zu übergeben.

Dann gibt es drei Möglichkeiten:

  1. /path-1/ ist ein Datum der Form YYYY-MM-DD, also Jahr-Monat-Tag. /path-2/ ist der korrekte Titel eines Beitrags in Groß/Kleinschreibung, wobei diverse Sonderzeichen und deutsche Umlaute ersetzt werden: ä -> ae, ö -> oe usw., Leerzeichen, Fragezeichen, Komma, Punkt, Doppelpunkt und andere Sonderzeichen werden durch einen Bindestrich ersetzt. Der Beitrag hat die als Zahl übergebene ID. Dann ist die Url korrekt, es wird ein Status 200 zurückgegeben.
  2. /path-1/ ist ein Jahr, zu dem es Beiträge gibt, /path-2 ist leer. Dann ist die Url korrekt, eine spätere Abfrage gibt alle Beiträge aus diesem Jahr zurück.
  3. /path-1/ ist eine Kombination aus Jahr und Monat (YYYY-MM), /path-2 ist leer. Auch hier ist die Url korrekt, die spätere Abfrage liefert alle Beiträge zu dieser Kombination aus Jahr und Monat zurück.
  4. /path-1/ und /path-2 sind "irgendetwas", die übergebene Zahl ist die Zahl zu einem Beitrag. Dann wird die korrekte Url /Jahr-Monat-Tag/Beitragstitel-BeitragsId übergeben und per 301-Status darauf weitergeleitet.
  5. Keiner dieser Fälle trifft zu. Dann läßt sich die Url nicht auflösen. Die Abfrage gibt einen 404-Status (nicht gefunden) zurück.

Der Webserver prüft, ob ein 200 oder 404 von der Abfrage zurückgegeben wurde. In diesen Fällen läuft der Code weiter. Im 301-Fall wird per Http-Statuscode 301 auf die in einer zusätzlichen Spalte übergebene korrekte Url weitergeleitet.

Vom Sql-Code her ist das simpel: Man baut vier Einzelabfragen, welche in ihren Where-Bedingungen die Varianten 1 - 4 abfragen, hängt eine Spalte Position dran, die 1 = 10, 2 = 20 usw. codiert, kombiniert diese per UNION, sortiert nach der Position - Spalte und läßt sich nur die oberste Zeile per Top 1 zurückgeben. Unten hängt man noch eine fünfte Zeile dran, die 404 als Wert der entsprechenden Zelle zurückgibt.

Ergebnis: Beliebige Links der Form

https://blog.server-daten.de/de/irgend-etwas/etwas-anderes-39

leiten auf den Artikel mit der Id 39 (den hiesigen Artikel) weiter. Fehlerhafte Einträge werden mit einem 404 beantwortet. Fehlerhafte interne Verlinkungen lassen sich mit einem Tool wie Xenu finden und bereinigen. So daß es keine fehlerhaften internen Verlinkungen gibt. Fehlerhafte Verlinkungen kann es damit nur von außerhalb her geben.

Das ermöglicht Kurzlinks der Form https://blog.server-daten.de/de/-39, die ebenfalls auf den hiesigen Beitrag mit dem vollständigen Titel weiterleiten.

Ähnliches findet man bsp. bei Heise, die Kurzlinks der Form /-3849106 nutzen: Das leitet auf den Artikel mit der Id 3849106 weiter. Der Tagesspiegel nutzt Konstruktionen der Form /Ressort/Artikeltitel/BeitragsId.html. Da funktioniert /20402618.html und leitet auf /politik/deutsche-einheit-was-ost-von-west-unterscheidet-eine-aufzaehlung/20402618.html weiter, auch wenn dort (im Gegensatz zu Heise) die Kurzlinks gar nicht explizit zu finden sind.

Die eigentliche Verblüffung: Google scheint diese Kurzlinks zu lieben. Inzwischen sind einige der hiesigen Artikel nicht mit dem langen Link, sondern mit dem Kurzlink im Index zu finden.

Wenn man bsp. bei Google nach

wie man wahlen verliert facebook seehofer

sucht, findet man den hiesigen Artikel mit der Id 32. Aber nicht mit der langen Url. Sondern mit der Kurz-Url https://blog.server-daten.de/de/-32 ganz oben. Eigentlich waren diese Kurzlinks nur für Benutzer gedacht, die auf diese einfache Art Beiträge verlinken können. Bei Google hatte ich gedacht, daß Google diesen Links zwar einmal folgt. Sie ab dann aber ignoriert und nicht in den Index aufnimmt. Das ist eigentlich der Zweck eines 301 - MovedPermanently - Status.

Eigentlich sollten diese Links also niemals bei Google in den Ergebnislisten auftauchen. Warum einige der Beiträge dennoch auftauchen? Da kann ich nur spekulieren. Vielleicht "sieht" Google, daß die Wörter in der Url "im wesentlichen" den Wörtern im Titel entsprechen. Und zeigt die Kurzlinks an, um zu lange Titel in den Suchergebnissen zu vermeiden.

Wenn man sich die Liste der obigen Fundstellen ansieht, fällt auf, daß es diverse Zeitungen mit teils sehr langen Seiten-Urls gibt. So daß Google die Url für den Benutzer abschneidet und durch ... begrenzt. Da ist so ein kompakter Link mit grade mal 35 Zeichen (inklusive https) durchaus praktisch.

Ferner verwende ich intern (von den Tags her) ausschließlich die lange Version. Das bevorzugt also nicht die Kurzlinks. Diese tauchen immer nur einmal am Ende des jeweiligen Artikels auf.

Folglich: Wenn Sie überlegen, einen Blog oder etwas ähnliches aufzusetzen.

1. Das genutzte Content Management System sollte es sicherstellen, daß bei späteren Titeländerungen die bisherigen Links nicht ins Leere laufen, sondern korrekt weitergeleitet werden. Das erzwingt irgendeine Variante, bei der die Beitrags-Id in der Url ist. Ob diese per Bindestrich, per Punkt oder per /BeitragsId.html abgetrennt wird, ist dabei eher egal. Wobei die letztere Variante eigentlich zu teuer ist und nochmals 5 Zeichen mehr braucht.

2. Wenn (1) erfüllt ist, dann sollten Kurzlinks /-Id ebenfalls funktionieren. Dann bauen Sie solche Kurzlinks auch direkt ein. Ob solche zusätzlichen internen Verlinkungen nutzen, kann ich nicht beurteilen. Sie scheinen jedenfalls nicht zu schaden.

Mal sehen, wie sich das Verhältnis von Beitragslanglinks zu Beitragskurzlinks im Google-Index weiterentwickeln wird.

--

Ergänzung 17:55: Das ist ja eine Überraschung. Ich sehe ins Protokoll, um 17:44 hatte sich der Microsoft Bingbot den hiesigen Artikel geholt. Den Bot hatte ich bis jetzt noch fast nicht gesehen. Dann überprüfe ich per site:blog.server-daten.de bei bing.com, wieviele Seiten dort drin sind. Und stelle um 17:46 fest, daß die grade gespiderte Seite bereits im Index ist. Die Suche nach

Google Kurzlinks

listet die Seite aktuell oben.

*
* (wird nicht angezeigt)
Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.