Webagentur Basel sort

Weiterleitungen
mit nginx und Apache

keyboard_arrow_down

Egal ob beim Relaunch oder im normalen Betrieb: URLs ändern sich oft. Gründe gibt es viele: Verzeichnisstrukturen ändern sich, weil Inhalte umziehen. Eine Expansion in neue Länder fordert andere Domain-Strukturen (ch.domain.com, domain.com/ch, domain.ch etc). Oder aber ein Protokollwechsel von HTTP auf HTTPS steht an.

Tägliche Veränderungen einzelner Links

Im täglichen Betrieb ändern sich URLs meist nur punktuell. Es ist dann notwendig, dass die Redaktion eine Funktion vorfindet über die ein Mapping von der alten URL auf die neue URL gemacht werden kann.

Hierbei hilft auch die Google Search Console: Sind Links bei Google bekannt die bei erneutem Crawling einen 404 (oder Soft-404) Fehler auslösen, können diese in der GSC gefiltert werden.

Spätestens dann sollte man sich überlegen wie eine korrekte Weiterleitung dieser URLs auszusehen hat, d.h. welche neue Zielseite relevante Inhalte bereitstellen kann.

Versäumt man diese Link-Hygiene, wird man vom Google-Crawler insofern bestraft, als dass unnötiges Crawl-Budget verschenkt wird: Der Crawler ruft eine veraltete URL auf und wird in einen 404-Fehler geführt. Im schlechtesten Fall bleiben dann nicht mehr genügend der begrenzten Crawler-Abrufe für die wirklich relevanten Links übrig.

Massen-Weiterleitungen beim Relaunch

Nachdem man die SEO-Relevanz einer technisch korrekten Link-Landschaft verstanden hat, wird auch klar, dass ein Relaunch oft eine grosse Herausforderung bedeutet: Meist ändert sich dabei ein Grossteil der internen URL-Struktur.

Dabei ist es vor allem wichtig, dass im Vorfeld analysiert wird wie die aktuelle Link-Topologie aussieht. Auf dieser Basis können dann Weiterleitungen geplant und eingerichtet werden - und zwar vor dem Relaunch.

Ein möglicher Ablauf:

  1. Analyse der alten / aktuellen Link-Strukturen z.B. via Sitemap oder Google Analytics. Je nach Szenario müssen nun alte URLs nun von Hand auf die neuen / zukünftigen URLs gemapped werden. Das kann z.B. sehr einfach in Excel gemacht werden. Oft werden auch ganze Verzeichnis- oder Domainstrukturen umgeleitet, darauf gehen wir hier aber nicht näher ein.
  2. Gruppierung, Validierung und Optimierung des Mappings von «alt» auf «neu», bevor eine Konfiguration im Web-Server stattfindet.
  3. Konfiguration Web-Server und Testen.

Natürlich gibt es auch Möglichkeiten Umleitungen nicht direkt im Web-Server zu konfigurieren, sondern z.B. via Framework (bspw. mit django redirects). Ein grosser Vorteil der Server-Konfiguration ist aber die hohe Geschwindigkeit der Umleitung. Gerade bei grösseren Webseiten mit zig-tausend URLs entlastet es die Web-Anwendung enorm, wenn bereits auf Server-Ebene weitergeleitet wird.

Ausserdem können via Server-Config auch Regular Expressions eingesetzt werden, womit ein regelbasiertes Set an Umleitungen konfiguriert werden kann. Das vereinfacht die Wartung und den Umfang der notwendigen Konfiguration. Als Web-Server werden meistens nginx oder Apache eingesetzt.

nginx

In nginx wird das URL-Mapping über das Map-Module realisiert. Ohne weitere Erläuterungen sind hierfür nur wenige Zeilen in der Site-Konfiguration erforderlich:

map_hash_max_size 2048;
map_hash_bucket_size 256;
map $request_uri $new_uri {
  include /etc/nginx/conf-available/seo-redirects.map;
}
server {
  if ($new_uri) {
    return 301 $new_uri;
  }
}
  • 1. Zeile: Die «richtige» Grösse hängt vom Umfang der Mapping-Datei ab (Anzahl Umleitungen).
  • 2. Zeile: Auch hier bestimmt die Mapping-Datei die Mindestgrösse. Beim reloaden der geänderten Konfiguration wird nginx eine Prüfung dieser beiden Parameter vornehmen, und eine Fehlermeldung ausgeben, falls die Werte zu klein sind.
  • 3. - 5. Zeile: Hier findet das Mapping statt. Jede angefragte URL ($request_uri) wird gegen die .map Datei geprüft. Wird sie dort gefunden, speichert nginx die neue URL in der Variable $new_uri ab.
  • ab 6. Zeile: Innerhalb des Server-Blocks wird geprüft, ob die Variable $new_uri belegt wurde. Das ist dann der Fall wenn das Mapping erfolgreich war (d.h. es gibt eine «neue» URL). Nun findet eine Umleitung mittels HTTP-Statuscode 301 (permanent) auf diese neue URL statt.

Apache

In Apache findet das URL-Mapping über die Rewrite-Engine statt. Ohne auch hier auf die Hintergründe einzugehen, werden nur wenige Zeilen z.B. im VirtualHost-Block (oder via .htaccess) benötigt:

RewriteEngine On
RewriteMap seo txt:/etc/apache2/conf-available/seo-redirects.conf
RewriteCond ${seo:$1} !=""
RewriteRule ^(.*)$ ${seo:$1} [redirect=permanent,last]
  • 1. Zeile: Die RewriteEngine (bzw. mod_rewrite) wird eingeschaltet.
  • 2. Zeile: Eine Mapping-Datei (alte URL auf neue URL) wird mit dem Namen «seo» referenziert.
  • 3. + 4. Zeile: Jede angefragte URL wird gegen die Mapping-Datei geprüft. Enthält diese die URL, so leitet Apache auf die hinterlegte «neue URL» weiter (permanent).

Die Mapping-Datei

Die Mapping-Datei ist das Resultat der Recherche vor dem Relaunch. Sie beinhaltet alle alten Pfade sowie deren neues Linkziel.

Egal ob in nginx oder Apache: Die Mapping-Datei ist simpel aufgebaut und enthält pro Zeile einen alten (relativen) Link, der mittels Leerschlag vom neuen Link getrennt wird:

/de/ALT_seo_artikel123.html /de/seo-best-practice/artikel-mit-neuer-sprechender-url/
/de/index.html /de/
...

Nun wäre es z.B. auch denkbar, dass diese Mapping-Datei vom Server periodisch von einem FTP-Verzeichnis geladen wird. So könnten Redaktoren mit technischer Verantwortung (mächtigen!) Einfluss in die Server-Logik nehmen, ohne selbst einen Server-Zugang zu benötigen.

Ihre Fragen an unskeyboard_arrow_right