Crawler: Optionale erweiterte Normalisierung

Vorweg sei gesagt, dass dies ein sehr spezifisches Thema ist. Effektiv sind davon nur etwa 2% unserer Kunden betroffen. Da allerdings im Rahmen eines Fachvortrages kritisiert wurde, dass wir eine solche Option nicht anbieten, haben wir sie kurzerhand umgesetzt. Somit können Webmaster von jetzt an selbst entscheiden, wie mit den Daten umgegangen werden soll.

Aktiviert man die "Erweiterte URL-Normalisierung" in den Crawl-Optionen eines Projektes, werden unter anderem folgende Normalisierungen vorgenommen, wenn wir während des Crawlens eine URL finden:

Standard-Portangaben werden entfernt
http://www.domain.com:80/	»	http://www.domain.com/
Domains werden immer kleingeschrieben
http://www.dOmAin.cOM:80/	»	http://www.domain.com/
Schemas werden immer kleingeschrieben
HTTP://www.domain.com/	»	http://www.domain.com/
Auch Port 443 (SSL) wird automatisch entfernt
hTtpS://www.domain.com:443/	»	https://www.domain.com/
Doppelte Slashes werden entfernt
http://www.domain.com/test//file.php	»	http://www.domain.com/test/file.php
Leerzeichen innerhalb der URL werden encodiert
http://www.domain.com/ /file.php	»	http://www.domain.com/%20/file.php
Nicht reservierte Zeichen werden dekodiert
http://www.domain.com/binde%2Dstrich.php	»	http://www.domain.com/binde-strich.php
Großschreibung von Percent-Encoded Octets
http://www.domain.com/a%c2%b1b/	»	http://www.domain.com/a%C2%B1b/
Erzwungener Trailing Slash bei Domains (Homepage)
http://www.domain.com	»	http://www.domain.com/
Trailing Questionmark wird entfernt
http://www.domain.com?	»	http://www.domain.com/

Und wenn wir schon einmal beim Thema sind, hier noch die wichtigsten Normalisierungen, die unser Crawler standardmäßig vornimmt:

Leerzeichen am Anfang und Ende einer URL werden entfernt
href=" http://www.domain.com/ "	»	href="http://www.domain.com/"
Relative Pfadangaben werden aufgelöst
/example/file.php	»	http://www.domain.com/example/file.php
Mehrfache relative Pfadangaben werden aufgelöst
/example/../folder/./file.php	»	http://www.domain.com/folder/file.php
Inline-Anchor werden entfernt
http://www.domain.com/#tutorial	»	http://www.domain.com/
Hashbangs werden beibehalten
http://www.domain.com/#!ajax	»	http://www.domain.com/#!ajax
Relative Schemaangaben werden aufgelöst
//www.domain.com/	»	http://www.domain.com/
Außer das Dokument verwendet https, dann wird entsprechend https verwendet

Für wen ist diese Option gedacht?

Die "Erweiterte Normalisierung" der gefundenen URLs innerhalb eines Crawls ist primär für Agenturen gedacht, die sich mit veralteten Websites auseinandersetzen müssen, aber technisch nicht in der Lage sind, deren Links zu ändern. Wenn die Option aktiviert ist, werden die entsprechenden URLs mit der "richtigen" Schreibweise gruppiert und die Metriken somit gebündelt berechnet.

Die "Erweiterte Normalisierung" ist standardmäßig nicht aktiviert. Denn wir wollen unsere Benutzer deutlich darauf hinweisen, was im Quellcode steht. Wenn ein Programmierer oder Designer innerhalb des Quellcodes URLs mal groß- und mal kleinschreibt, sollen das Benutzer möglichst schnell sehen können. Daher behandeln wir unterschiedliche Schreibweisen standardmäßig als eigene URLs, damit sie auch entsprechend in den Reports aufgezeigt werden. So kann der Benutzer einfach nach dieser Schreibweise im Quellcode suchen und findet sie direkt. Wenn die URL erst einmal normalisiert wurde, könnte der Benutzer fälschlicherweise denken, dass die URL gar nicht im Quellcode vorkommt.

Leider gibt es an dieser Stelle keine eindeutige Definition von "richtig". Der RFC-Standard - eine Art Norm, an dem sich Browser, Webserver, etc. orientieren - empfiehlt einige Normalisierungen insbesondere im Kontext des Cachings. Dies führt dazu, dass man während des Crawlings solche Normalisierungen vornehmen kann, aber nicht muss. Facebook zum Beispiel normalisiert eine Port Angabe oder doppelte Slashes nicht ( vgl.: URL Debugger von Facebook, Beispiel "http://www.dmoz.org:80/" oder "http://www.heise.de/kontakt//"). Google hingegen scheint dies zu tun, weil es ein Indikator dafür ist, dass ein Unwissender etwas falsch verstanden hat.

Für Webmaster, Designer und SEOs sollte klar sein, wie eine URL richtig aufgebaut ist. Dass Domain und Schema immer kleingeschrieben werden sollten und am besten auch Subfolder und Filenames. Auch die Tatsache, dass keine Sonderzeichen (z.B. Leerzeichen) oder Umlaute in Ordner- und Dateinamen vorkommen sollten, ist gängiger Kenntnisstand. Hintergrund: Die meisten Systeme, wie z.B. auch weitverbreitete Webserver, arbeiten mit amerikanischen Zeichensätzen. In solchen kommen deutsche Umlaute teilweise bis heute gar nicht vor.

Sei es auf Konsolenebene oder in Konfigurationsdateien: Als Programmierer ist man gewohnt, die Sonderzeichen zu "escapen". Da dies normalen Webmakern, die primär mit Web-Frontends (GUI) arbeiten, nicht unbedingt bewusst ist, ist man mit der Grundregel "Nur (englischsprachige) Buchstaben, Zahlen und Bindestriche" für Dateinnamen eigentlich am besten bedient. Damit kann man in der Regel nichts falsch machen.

Wenn nun im Quellcode aber URLs schlummern, die sich nicht an solche "Regeln" halten, wollen wir erreichen, dass unsere Benutzer dies schnellstmöglich sehen - und nehmen dabei in Kauf, dass sich eventuell der Pagerank um 0,00001 (Sprich: insignifikant) in der Berechnung verändert. Wir tun das im Sinne der Kunden, damit diese ihre Mitarbeiter entsprechend coachen können.

Sollte sich jemand dabei bevormundet fühlen, kann er dies künftig mit der Crawl-Einstellung "Erweiterte Normalisierung" umstellen.

tl;dr

Es gibt eine neue Crawl-Option "Erweiterte Normalisierung". Damit werden verschiedene Schreibweisen einer URL gruppiert (orientiert an RFC 3986 Empfehlungen), die OnPage-Analysen werden dadurch etwas "fehlertoleranter".