onpage Guide zu den Themen Website-Relaunch onpage-faktoren Internationalisierung von Websites

Transkript

1 onpage Guide zu den Themen Website-Relaunch onpage-faktoren Internationalisierung von Websites

2 K a p i t e l I n h a l t s v e r z e i c h n i s A b s c h n i t t - / - INHALTSVERZEICHNIS TIPPS FÜR DEN WEBSITE-RELAUNCH...5 ALLGEMEINES... 5 Testsystem & Testphase... 5 PERFORM ANCE DES (NEUEN) SERVERS... 6 Ladezeiten... 6 Antwortzeiten (Time to First Byte)... 6 VERHINDERUNG DER INDEXIERUNG DES TESTSYSTEMS... 6 Verwendung der Robots.txt... 6 Meta-Robots NOINDEX... 7 URL-STRUKTUR & PROTOKOLL... 8 Übernahme der alten URL-Struktur und Pfad-Namen... 8 Weiterleitungen der alten URLs... 8 Verwendung von Speaking URLs... 8 Interne Linkstruktur und Klickpfadtiefe... 8 HTTP oder HTTPS... 9 Sitemap.xml... 9 VERMEIDUNG VON DUPLICATE CONTENT Verwendung des Canonical Link Elementes Verwendung von 301-Weiterleitungen CONTENT & META-TITEL BILDER & GRAFIKEN FEHLERSEITEN HTML-VALIDITÄT BACKLINKS TRACKING-SOFTWARE ONPAGE GLOSSAR TECHNIK S e i t e 2

3 K a p i t e l I n h a l t s v e r z e i c h n i s A b s c h n i t t - / - Top-Level-Domain Time To First Byte (TTFB) des Servers Ladezeiten Verwendung von robots.txt Verwendung von Weiterleitungen Fehler-Codes Cookies STRUKTUR / ARCHITEKTUR Absolute und relative Pfade Aufbau der URL Klickpfad-Länge XML-Sitemap Verwendung von Meta-Robots Verwendung von Rel= Nofollow Verwendung von X-Robots-Tag NOINDEX Verwendung des Canonical Link Elements Interne Verlinkung, Linktexte & Keyword Fokus Link-Attribute Prev und Next Externe Links INHALT (CONTENT) / RESSOURCEN MIME-Typ Sprache Verwendung von Meta-Titeln Verwendung von Meta-Beschreibungen Interner (Near) Duplicate-Content (Texteinzigartigkeit) Externer Duplicate-Content (Texteinzigartigkeit) Verwendung von Bildern Content (Fließtexte) / Verwendung von Überschriften Optimierung von PDF-Dateien S e i t e 3

4 K a p i t e l I n h a l t s v e r z e i c h n i s A b s c h n i t t - / - INTERNATIONALISIERUNG VON WEBSITES TECHNISCHE VORAUSSETZUNGEN (URL-STRUKTUR) Variante 1 cctld (country code Top Level Domain) Variante 2 Sub-Domains Variante 3 Sprach-Verzeichnisse CONTENT & WORDING EINSATZ DES HREFLANG-ATTRIBUTS Identische Inhalte infolge sprachlicher Übersetzungen Identische Inhalte infolge gemeinsamer Sprache mit geringfügigen regionalen Unterschieden Reine Übersetzung der Vorlage (Template) GESTALTUNG VON FORMULAREN RECHTLICHE BESONDERHEITEN LOGISTIK ZAHLUNGSMETHODEN - PAYMENT KONTAKTDATEN S e i t e 4

5 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t A l l g e m e i n e s TIPPS FÜR DEN WEBSITE-RELAUNCH ALLGEMEINES Testsystem & Testphase Bevor eine neue Website online geht, muss logischerweise ein vollständig lauffähiges Testsystem geschaffen werden, das vom Umfang und Zustand her den Anforderungen eines Live-Systems entspricht. Die Tests am neuen CMS, inwieweit alle übernommenen und neuen Funktionen tatsächlich korrekt implementiert wurden, sind extrem wichtig, sodass hier die Devise gilt: Lieber ein paar Stunden mehr investieren und genau prüfen als überhastet live schalten und sich mit unnötigen Bugs und verärgerten Besuchern bzw. Kunden rumschlagen müssen. Neben dem Check des Testsystems sollte auch die Migration innerhalb einer Testumgebung erfolgen. Nur so können unvorhersehbare Problemkonstellationen erkannt und im Vorfeld beseitigt werden. Alle Maßnahmen für den reibungslosen Migrationsvorgang sind optimaler Weise zu dokumentieren. Sind alle Vorbereitungen und vorausgegangenen Tests erfolgreich abgeschlossen worden, ist es an der Zeit das CMS zu publizieren. Während der Umstellung auf das neue System sollte die bisherige Website vollständig von Netz genommen werden. Im Idealfall spielt der Umstieg auf das neue CMS sich innerhalb weniger Stunden ab und dies vorranging zu Nachtzeiten oder früh am Morgen, da hier mit dem geringsten realen Besucher-Traffic zu rechnen ist. Nach der Live-Schaltung liefern die Server-Log-Dateien ggfs. wichtige Informationen auf mögliche Fehlerquellen. Auch sich stark (negativ) ändernde Rankings wichtiger URLs bzw. Keywords liefern Indizien darauf, dass etwas nicht stimmt. S e i t e 5

6 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t P e r f o r m a n c e d e s ( n e u e n ) S e r v e r s PERFORMANCE DES (NEUEN) SERVERS Ladezeiten Die Webseitengröße und die Ladezeit sind ein wichtiger Faktor für die Besucher sowie die Suchmaschinen. Die Besucher verlassen eine Webseite, wenn diese einen langen Seitenaufbau aufweist. Des Weiteren haben die Suchmaschinen Probleme mit zu großen Seiten und erkennen möglicherweise nicht alle Seiteninhalte, da nur ein Teil des in der Datei enthaltenen Inhalts erfasst wird. Google bietet unter einen Service an, mit dem die allgemeine Performance und die vorliegenden Optimierungsmöglichkeiten geprüft und ausgeschöpft werden können - und dies im Zusammenhang mit der Nutzung durch Desktop- und Mobilgeräten. Die Ergebnisseite liefert viele wichtige Tipps und weiterführende Informationen. Antwortzeiten (Time to First Byte) Es ist ebenso wichtig zu prüfen, inwieweit der Server für das neue CMS leistungstechnisch geeignet ist. Nicht selten stellt sich nach einem Relaunch heraus, dass die Auslieferung der Daten schleppend verläuft. Neben der Reaktionszeit des Servers ist auch die zu übertragende Datenmenge zu beachten. Eine gute Antwortzeit beläuft bewegt sich im Zeitfenster < 200ms. Der vorgenannte Dienst liefert auch hierzu Hinweise, sollte die Reaktionszeit des Servers zu groß sein. VERHINDERUNG DER INDEXIERUNG DES TESTSYSTEMS Verwendung der Robots.txt Mit der Robots.txt wird den Suchmaschinen-Bots mitgeteilt, welche Bereiche einer Website sie nicht crawlen dürfen. Seriöse Suchmaschinen wie Google halten sich an die Vorgaben. Da die Bots zum Zeitpunkt der Umstellungen die neuen Seiten, welche möglicherweise die gleichen Texte wie die alten Seiten beinhalten, nicht erfassen dürfen (Vermeidung von Duplicate Content), ist diese Vorsichtsmaßnahme sehr wichtig. Im Zuge eines Relaunches ist es extrem wichtig, dass keinerlei offizielle Links zum neuen CMS existieren. Um eine Indexierung zu verhindern, sollte die Robots.txt das Verzeichnis oder die Verzeichnisse des Neusystems sperren. Beispiel: User-Agent: * Disallow: /ordner-mit-neuem-cms/ S e i t e 6

7 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t V e r h i n d e r u n g d e r I n d e x i e r u n g d e s T e s t s y s t e m s Nach Abschluss der Arbeiten am neuen CMS und dessen Veröffentlichung muss das Verbot entfernt werden, um eine Indexierung zu ermöglichen. Je nach Eigenschaften und Struktur der neuen Website ist es u.u. erforderlich, sich grundsätzlich mit der Robots.txt zu befassen und diese so anzupassen, dass die Suchmaschinen-Crawler nur die relevanten Daten erfassen. Meta-Robots NOINDEX Parallel zum Crawl-Verbot via Robots.txt ist es empfehlenswert, alle Seiten der neuen Website pauschal mit der Meta-Robots-Anweisung NOINDEX, NOFOLLOW zu versehen. So wird absolut sichergestellt, dass keine Links verfolgt und Seiten indexiert werden. Die Anweisung wird im Head-Bereich des HTML- Dokumentes ausgegeben und weist folgende Syntax auf: <meta name="robots" content="index, follow" /> Nach Abschluss der Arbeiten am neuen CMS und dessen Veröffentlichung muss diese Pauschalanwendung wieder entfernt werden, da die Seiten ansonsten nicht indexiert werden. S e i t e 7

8 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t U R L - S t r u k t u r & P r o t o k o l l URL-STRUKTUR & PROTOKOLL Übernahme der alten URL-Struktur und Pfad-Namen Es gilt zu prüfen, inwieweit das neue CMS es zulässt, die bisherige URL-Struktur 1:1 nachzubilden und die alten Pfadnamen zu übernehmen. Dies wäre die optimale Lösung (auch in Hinblick auf die SEO) und erübrigt weitere Maßnahmen, wie die Einrichtung von 301-Weiterleitungen. Weiterleitungen der alten URLs Lässt das neue CMS die Nachbildung der alten Link-Strukturen nicht zu, so ist es extrem wichtig, beim dem Relaunch die Power der bisherigen Seiten auf die neuen URLs zu übertragen. Nur so kann eine schnelle Indexierung der neuen Seiten erreicht sowie ein Verlust von Rankings und der allgemeinen organischen Sichtbarkeit weitestgehend vermieden werden. Im Vorfeld ist die Erstellung einer vollständigen Liste mit allen wichtigen URLs erforderlich. Die Liste sollte insbesondere die starken Verteilerseiten, spezielle Landingpages und andere URLs enthalten, zu denen gute Rankings vorliegen. Die Weiterleitung selber muss als permanente Weiterleitung Typ 301 umgesetzt werden (i.d.r. serverseitig in einer.htaccess im Fall eines Apache-Servers), da nur hierbei die Linkpower an die neuen Zielseiten übertragen wird. Der Status-Code 301 signalisiert den Suchmaschinen, dass die URL einer Seite einer dauerhaften Änderung unterzogen wurde. Die Suchmaschinen werden die alten URLs entsprechend aus dem Index entfernen und durch die neuen URLs ersetzen. Verwendung von Speaking URLs Bei der Einrichtung des neuen CMS sollte sofort die Nutzung von sogenannten Speaking URLs erfolgen, was viele Vorteile mit sich bringt, wie eine bessere Lesbarkeit oder die Unterbringung wichtiger Keywords. Interne Linkstruktur und Klickpfadtiefe Es ist wichtig zu überprüfen, wo sich im Quellcode harte Links befinden, die nicht automatisiert an das neue CMS angepasst werden können. Ggfs. muss hier manuell eingegriffen werden. Weiterhin ist darauf zu achten, dass die Klickpfadtiefen der bislang starken Seiten beibehalten werden. Die Klickpfadtiefe spiegelt wider, wie viele Klicks erforderlich sind, um eine bestimmte HTML-Seite zu erreichen. So kann die Verlagerung einer wichtigen Verteilerseite (z.b. Kategorieseite) auf eine tiefere Ebene infolge eines neuen Menüaufbaus dazu führen, dass die Seite weniger Linkjuice vererbt bekommt und die bisherigen Rankings einbrechen. S e i t e 8

9 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t U R L - S t r u k t u r & P r o t o k o l l HTTP oder HTTPS Da Google die Nutzung des HTTPS-Protokolls als offiziellen Rankingfaktor bekanntgab und hierdurch Vorteile gegenüber einer unverschlüsselten Datenkommunikation entstehen können, sollte beim Relaunch ein Wechsel darauf in Erwägung gezogen werden. Wichtig ist hierbei zu wissen, dass eine Verschlüsselung das Serversystem zusätzlich belastet und dieses entsprechend performant sein muss. Mit dem Relaunch ist es erforderlich, dass Vorkehrungen getroffen werden, um Duplicate Content zu vermeiden. Hierzu bietet sich an, alle Anfragen via HTTP-Protokoll auf die HTTPS-Variante der URL weiterzuleiten oder aber im Quelltext der HTML-Seiten pauschal auf die HTTPS-URL zu kanonisieren. Sitemap.xml Es ist empfehlenswert, eine aktualisierte Sitemap.xml mit den Links des neuen CMS zu erstellen. Diese kann dann beispielsweise über die Google Webmaster-Tools eingereicht werden. So wird Google schnellstmöglich mitgeteilt, dass sich was geändert hat. Ebenso ist es hilfreich, innerhalb der robots.txt auf die Sitemap.xml zu verweisen. Beispiel: Sitemap: S e i t e 9

10 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t V e r m e i d u n g v o n D u p l i c a t e C o n t e n t VERMEIDUNG VON DUPLICATE CONTENT Verwendung des Canonical Link Elementes Canonical Link Elemente dienen dazu, Suchmaschinen mitzuteilen, welche Seite das wichtige Original ist und demzufolge indexiert werden soll. Das Setzen von Canonical-Angaben innerhalb der (HTML-) Seiten, welche der Originalseite sehr ähnlich oder mit dieser gar identisch sind, ist ein wichtiges Instrument, um Duplicate Content vorzubeugen. Häufige Quellen doppelten oder sehr ähnlichen Contents sind: 1. Content ist mit und ohne "www" aufrufbar: Content ist sowohl über "http" als auch über "https" aufrufbar: Content ist sowohl mit als auch ohne "Slash" aufrufbar: Content ist mit dargestellter Index-Datei und ohne diese aufrufbar: Content ist auch mit Tracking-Parametern aufrufbar: S e i t e 10

11 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t V e r m e i d u n g v o n D u p l i c a t e C o n t e n t 6. Seite ist auch mit Session-IDs aufrufbar: Für Partner kommen Affiliate-IDs zum Einsatz: Content ist mit Groß- und Kleinschreibung aufrufbar: Content ist über mehrere Ansichten aufrufbar: Content ist über mehrere Filter aufrufbar: Die nachfolgenden Code-Zeilen werden im Head-Bereich einer HTML-Seite (<head>) integriert. Z.B. folgenden Canonical Tag ohne jegliche Parameter einbinden <link rel="canonical" href=" /> S e i t e 11

12 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t C o n t e n t & M e t a - T i t e l Verwendung von 301-Weiterleitungen Alternativ zu den vorausgegangenen Punkten 1 bis 4 und 8 im Zusammenhang mit der Nutzung des Canonical Link Elementes kann auch mit 301er Weiterleitungen gearbeitet werden. Hierzu bedarf es i.d.r. der Erstellung eines Regelwerkes, z.b. via.htaccess bei Apache-Servern. CONTENT & META-TITEL Mit der Einrichtung des neuen CMS sollten auch alle bislang genutzten Fließtexte, Meta-Titel- und Beschreibungen 1:1 übernommen werden, denn dies erhöht den Wiedererkennungswert seitens der Suchmaschinen und sichert des Weiteren die bisherigen Klickraten in den Suchergebnissen (insofern Rankings unverändert bleiben). Umfangreiche inhaltliche Änderungen können das Ranking trotz Weiterleitungen bzw. Nutzung der bisherigen URLs nachteilig beeinträchtigen. Im Zuge der Übernahme der Texte sollte der semantische Aufbau geprüft und ggfs. angepasst werden. So ist es von Bedeutung, dass Überschriftenelemente, Paragraphenelemente, Listenelemente usw. sinnvoll zum Einsatz kommen. Sehr wichtig ist z.b. der Einsatz einer einzigartigen Überschrift H1 innerhalb aller HTML-Dokumente. BILDER & GRAFIKEN Wie auch bei den URLs der HTML-Seiten ist es bei der Verwendung von Bildern wichtig, dass diese im Idealfall sowohl über aussagekräftige, sprechende Dateinamen verfügen als auch einen sinnvollen Alternativtext (alt-attribut) nutzen, denn häufig werden über Universal-Search-Integrationen oder die Google Bildersuche gute Besucherzahlen erreicht. Beim Relaunch kann es daher sinnvoll sein, auch die Bilder per 301 weiterzuleiten, und zwar dann, wenn die alte Struktur nicht mehr 1:1 übernommen werden kann. Bei der Weiterleitung ist wichtig darauf zu achten, dass das Weiterleitungsziel das identische Bild beinhaltet. Hierbei ist es entscheidend, dass sowohl der Bildinhalt (Pixelinformationen) und der Dateiname original bzw. unverändert sind. S e i t e 12

13 K a p i t e l T i p p s f ü r d e n W e b s i t e - R e l a u n c h A b s c h n i t t F e h l e r s e i t e n 404 FEHLERSEITEN Dank guter Vorbereitung des Relaunches sollte es keine Not Found -Fehlermeldungen für die Besucher geben. Da der Idealfall aber selten ist, ist es empfehlenswert die 404er-Seiten so nützlich wie möglich zu gestalten. Ein Link zur Hauptseite und weitere wichtige Verteilerseiten, ein Suchfeld, Feedbackformular oder eine freundliche, sachlich formulierte Nachricht können die User-Experience deutlich verbessern. Wichtig ist dabei, dass auch tatsächlich der Statuscode 404 übermittelt wird, da die Suchmaschinen den Inhalt dieser Seiten ansonsten wie normale HTML-Seiten behandeln. Da diese Seiten kaum Content aufweisen und demnach sehr ähnlich sind, können Soft-404-Fehler und Thin-Content entstehen, was bei umfangreichem Vorkommen wiederum nachteilig auf die Rankings auswirken kann. HTML-VALIDITÄT Die neuen Seiten sollten vor einer Live-Schaltung hinreichend geprüft werden. Durch eine korrekte HTML-Validität können Suchmaschinen und Browser den Inhalt der Webseite korrekt interpretieren und auswerten. Probleme können dann auftreten, wenn HTML-Tags nicht geschlossen sind und somit der weitere Bereich nicht richtig interpretiert werden kann. BACKLINKS Mit der Veränderung der URL-Struktur im neuen CMS besteht die Gefahr, dass externe Links oder Links aus eigenen, angegliederten Seiten (z.b. Subdomains) ins Leere zeigen. Hier hilft die bereits erwähnte 301-Weiterleitung, welche die Linkpower von den alten auf die neuen Seiten weiterleitet. Wenn möglich, sollten die externen, linkgebenden Seiten um eine Aktualisierung der Linkziele gebeten werden. TRACKING-SOFTWARE Der bislang verwendete Tracking Code (z.b. Google Analytics) muss in das Template des neuen CMS integriert werden, damit auch zukünftig die Besucheraktivitäten erfasst werden können. Weiterhin ist u.a. die Anpassung von Conversion-Trichtern aufgrund geänderter URLs erforderlich. S e i t e 13

14 A b s c h n i t t T e c h n i k ONPAGE GLOSSAR Nachfolgend sind die wichtigsten onpage-faktoren (inkl. technischer Aspekte) allgemeingültig beschrieben und mit Empfehlungen / Tipps versehen. Hinweis: Überschneidungen / Wiederholungen von Themen mit dem vorausgegangenen Schwerpunkt Tipps für den Website-Relaunch sind möglich. Die dortigen Themen werden jedoch mitunter tiefgreifender behandelt und mit zusätzlichen Informationen angereichert. TECHNIK Top-Level-Domain Die TLD (Top Level Domain) einer Domain ist für die Suchmaschinen wichtig. Denn hieran ist klar zu erkennen, auf welches Land sich die Webseite bezieht. Hierbei ist zwischen unterschiedlichen Typen zu unterscheiden. cctlds (Country-Code Top-Level Domains) Diese Domains sind an ein bestimmtes Land gebunden, so steht.de für Deutschland oder.at für Österreich. Sie signalisieren den Internetnutzern eindeutig, dass die Website ausdrücklich für ein Zielland ausgerichtet ist. gtlds (Generic Top-Level Domains) Hierbei handelt es sich um Domains, die keinen Rückschluss auf das Zielland liefern, also länderunspezifisch sind (z.b..com,.net,.org). Die Einstufung und Relevanz für ein bestimmtes Land wird über den enthaltenen Content, aber auch wesentlich über die vorliegenden Backlinks gesteuert. Soll z.b. die domainname.com in Deutschland ranken, so ist es wichtig, dass die meisten Backlinks von.de Domains stammen. rtlds (Regionale Top-Level-Domains) Eine Sonderstellung nehmen die regionalen TLDs ein. So geben z.b..eu oder.asia zwar eine Region an, liefern aber davon abgesehen keine weiteren, eindeutigen Rückschlüsse auf das Zielland innerhalb dieser Region. Aus diesen Gründen ist es möglich, dass solche Websites seitens Google als gtld eingestuft werden. Insofern ist auch hier wichtig, von vorne herein durch geeignete Inhalte und Backlinks aus den präferierten Ländern Signale zu setzen. S e i t e 14

15 A b s c h n i t t T e c h n i k Time To First Byte (TTFB) des Servers Der Wert Time To First Byte wird genutzt, um die eigentliche Antwortgeschwindigkeit von Servern zu messen. Er misst die Zeit, die vergeht, bis der Server die Browser-Anfrage intern verarbeitet und das erste Byte zurückgeliefert hat. Im Vergleich zu den Serverantwortzeiten werden die Netzwerklaufzeiten nicht berücksichtigt, sodass Rückschlüsse auf die reine Berechnungszeit und Serverperformance gezogen werden können. Entscheidende Schlüsselelemente bei schlechten TTFB können sein: Server-Hardware Arbeitsspeicher-Ressourcenmangel Unzureichende Auslagerungsdatei (SWAP-File) CPU-Ressourcenmangel Langsames Netzwerk-Routing Webserver Frameworks Bibliotheken PHP-Einstellungen MySQL-Einstellungen Ladezeiten Nachdem der Server auf eine Anfrage reagiert hat, findet die Auslieferung der in den HTML-Seiten hinterlegten und angeforderten Ressourcen statt (u.a. Bilder, JS-Code). Je schneller die Daten ausgeliefert werden, desto besser. "Site Speed" ist ein offiziell bestätigter Ranking Faktor, der zwar in den meisten Fällen nicht den größten Einfluss auf das Ranking einer Seite hat, aber durchaus das Zünglein an der Waage sein kann. Vor allem, wenn die durchschnittliche Ladezeit der Webseiten signifikant höher ist als die der anderen gut gerankten Seiten. Ladezeiten von Seiten, die viele Bilder als Content beinhalten, können durch den Einsatz eines Content Delivery Networks (CDN) reduziert werden. Viele Plug-Ins, die im Bereich der CMS Verwendung finden, wirken sich ebenfalls auf den Site Speed aus. Für Wordpress beispielsweise sind umfassende Erweiterungen vorhanden, die nicht immer sinnvoll sind. Durch einen intensiven Einsatz dieser Erweiterungen besteht die Möglichkeit, dass sich der Site Speed von Webseiten verschlechtert. Für Google ist eine schnelle Ladezeit im Zusammenhang mit der User Experience der Besucher der Website sehr wichtig. Alleine dies sollte ein gewichtiger Grund sein, die Ladezeit der Seite(n) möglichst gering zu halten. S e i t e 15

16 A b s c h n i t t T e c h n i k Google PageSpeed Insights Google bietet mit den Google PageSpeed Insights ein Online-Tool an, um die bestehenden Seiten auf die Geschwindigkeit zu testen und Optimierungspotentiale zu ermitteln. Die Potentiale werden nach Priorität sortiert angezeigt und behandelt. URL zu Google PageSpeed Insights: Beispiel der Ergebnisübersicht für den Desktop (Screenshot): S e i t e 16

17 A b s c h n i t t T e c h n i k Verwendung von robots.txt Bei der robots.txt Datei handelt es sich um eine Textdatei, die i.d.r. im Root-Verzeichnis der Domain (z.b. liegt und in der festgelegt werden kann, welche Bereiche einer Domain vom Crawler der Suchmaschine gecrawlt werden dürfen und welche nicht. Beim Aufruf einer Domain analysiert der Crawler zunächst die robots.txt Datei und informiert sich über seine Einsatzorte. Über die Robots.txt können Verzeichnisse, bestimmte URLs oder Teile von URLs, wie die kritischen Session-IDs und GET-Parameter blockiert und vom Crawling ausgeschlossen werden. Es ist jedoch möglich, dass solche URLs dennoch in den Index gelangen, denn wird bspw. ein Backlink von extern auf die per Robots.txt ausgeschlossene Datei gesetzt, könnte Google dem Link hochgradig folgen, die Zielseite als wichtig einstufen und sie dennoch in den Index aufnehmen. Hier sollte je nach URL-Struktur und bereits erfolgter Indexierung eventuell mittels Meta-Robots-Anweisung NOINDEX gearbeitet werden, die innerhalb der jeweiligen Seite im Head-Bereich ausgegeben werden kann. Wurden unerwünschte Seiten bereits indexiert und befinden sich sowohl in der Robots.txt und den Seiten selber NOINDEX-Anweisungen, stellt sich der paradoxe Zustand ein, dass die Suchmaschinen die URLs nicht aufrufen dürfen, dies aber erforderlich wäre, um die dortige NOINDEX-Anweisung in Erfahrung zu bringen und umsetzen zu können. Bezüglich der Parameter kann auch die Nutzung des Canonical Link Elementes oder die Angabe der Parameter in den Google Webmaster Tools (Menüpunkt- Navigation: Crawling --> URL-Parameter) weiterhelfen. In den Webmaster Tools ist es ebenso möglich, die Funktion der robots.txt zu prüfen und ggfs. vorhandene fatale Fehler aufzudecken (Menüpunkt- Navigation: robots.txt- Tester). S e i t e 17

18 A b s c h n i t t T e c h n i k Nachfolgend einige Beispiele mit den wichtigsten Anwendungsfällen. Es ist zu beachten, dass die Angaben innerhalb der Robots.txt case sensitive sind, sprich zwischen Groß- und Kleinschreibung unterschieden wird. Vollständige Sperrung der Website: Disallow: / Blockieren von speziellen User-Agents: User-agent: Name-des-Bots Disallow: / Blockieren eines Verzeichnisses und seines Inhalts: Disallow: /name-des-zu-blockierenden-verzeichnisses/ Blockieren einer Seite: Disallow: /name-der-zu-blockierenden-datei.html Blockieren einer Datei (z.b. Bild): Disallow: /bildverzeichnis/name-der-bilddatei.jpg Blockieren eines bestimmten Dateityps (z.b. Bilddateien des Typs.jpg): Disallow: /*.gif$ Sternchen (*) können als Platzhalter für eine Zeichenfolge verwenden werden, um viele Anwendungsfälle auf einmal abzudecken: Mit der folgenden Anweisung können Sie beispielsweise den Zugriff auf alle Unterverzeichnisse sperren, die mit dem Wort "privat" beginnen: Alle Verzeichnisse mit dem Wort Test für den User-Agent Googlebot blockieren: User-agent: Googlebot Disallow: /test*/ S e i t e 18

19 A b s c h n i t t T e c h n i k Blockieren des Zugriffs auf alle URLs, die ein Fragezeichen (?) enthalten: Die folgenden Angaben bewirken, dass alle URIs (URI = Teil der URL nach dem Domainnamen, z.b. mit einem von Zeichenfolgen umschlossenen Fragezeichen (davor und danach) von der Indexierung ausgeschlossen werden. User-agent: Googlebot Disallow: /*? Beispiel einer ausgeschlossenen URL: Blockieren des Zugriffs auf alle URLs, die ein Fragezeichen (?) am Ende enthalten: Die folgenden Angaben bewirken, dass alle URIs (URI = Teil der URL nach dem Domainnamen, z.b. mit einem Fragezeichen am Ende von der Indexierung ausgeschlossen werden. User-agent: Googlebot Disallow: /*?$ Beispiel einer ausgeschlossenen URL: Blockieren des Zugriffs auf alle URLs, die auf eine bestimmte Zeichenfolge enden: Die folgenden Angaben bewirken, dass alle URIs (URI = Teil der URL nach dem Domainnamen, z.b. mit der vorgegebenen Zeichenfolge am Ende von der Indexierung ausgeschlossen werden. User-agent: Googlebot Disallow: /*XLS$ Beispiel einer ausgeschlossenen URL: S e i t e 19

20 A b s c h n i t t T e c h n i k Verweis auf die XML-Sitemap: Innerhalb der Robots.txt kann den Suchmaschinen mitgeteilt werden, dass eine Sitemap.xml existiert und wo diese zu finden ist. Sitemap: domainname.de/sitemap.xml Verwendung von Weiterleitungen Es existiert eine Vielzahl an Weiterleitungen (Redirect), wobei im Kontext der Suchmaschinenoptimierung vor allem diejenigen mit dem Code 302 und 301 relevant sind. Status Code 301 Der Status Code 301 sagt aus, dass die vom Client angeforderte Ressource nicht länger unter der angegebenen Adresse erreichbar ist, sondern dauerhaft auf eine andere Adresse verschoben wurde (Redirect). Die alte Adresse der Ressource ist fortan nicht mehr gültig und die neue Adresse wird an den anfragenden Client zurück gesendet, so dass dieser in der Lage ist, die Ressource unter der neuen Adresse abzurufen. Der Unterschied zwischen Status Code 301 und dem sehr ähnlichen Status Code 302 liegt in der Zeitangabe. Während die alte Adresse bei einem gesendeten Status Code 302 noch gültig bleibt, ist diese bei einem Status Code 301 nicht länger gültig. Der 301 Redirect vererbt somit Linkpower, bei 302 ist das nicht der Fall. Status Code 302 Der Status Code 302 Found steht für eine temporäre Weiterleitung. Das bedeutet, die angeforderte Ressource ist vorübergehend unter einer anderen Adresse zu finden. Neben diesem Status Code sendet der Server auch die neue Adresse der Ressource zurück. Wichtigster Unterschied zu Status Code 301 ist, dass die ursprüngliche Adresse weiterhin gültig bleibt. Dies ist zugleich auch der Grund, weshalb Inhalte, die dauerhaft unter einer neuen Adresse erreichbar sind, mit Status Code 301 und nicht mit Status Code 302 ausgeliefert werden sollten. Denn der Googlebot durchsucht und indexiert bei der temporären Weiterleitung weiterhin den ursprünglichen Speicherort. Wichtig ist auch, dass dadurch bei Status Code 302 kein Linkjuice vererbt wird, bei Status Code 301 jedoch schon. S e i t e 20

21 A b s c h n i t t T e c h n i k Fehler-Codes Permanent nicht erreichbare Seiten oder temporäre, interne Server-Fehler (z.b. infolge Überlastung / Timeout) sind unbedingt zu vermeiden. Häufig auftretende Fehler-Codes sind für Suchmaschinen und Besucher ein Anzeichen dafür, dass die Website nicht aktuell sowie schlecht gepflegt ist. Im Zusammenhang mit Fehler-Codes sind folgende Varianten wichtig: Status Code 404 (Client Fehler) Status Code 404 Not Found wird immer dann ausgeliefert, wenn die angeforderte Ressource (also meist eine URL, aber auch ein Bild oder eine andere Datei) nicht oder nicht mehr existiert. Generell kann hier zwischen zwei sinnvollen Vorgehensweisen und Handhabungen unterschieden werden: 1. Den Request auswerten und via 301-Redirect an eine ähnliche Ressource weiterleiten. Mit ähnlicher Ressource ist eine Seite gemeint, die inhaltlich der nicht verfügbaren Variante entspricht oder zumindest thematisch übergeordnet ist, sodass vergleichbare Inhalte / Produkte präsentiert werden. 2. Den Status-Code 404 Not found senden und eine entsprechende Fehlermeldung anzeigen. Eine gute 404-Seite sollte demnach folgende Kriterien erfüllen: Korrekter Statuscode: Wie bereits mehrfach angesprochen, sollte eine 404-Seite auf jeden Fall den richtigen Statuscode, also 404 Not Found oder aber 410 Gone zurückliefern. Aussagekräftige Fehlermeldung: Während für Suchmaschinen in erster Linie der Statuscode eine wichtige Rolle spielt, so kann der User damit in der Regel nichts anfangen, da er diese Information nicht sieht. Deshalb ist es wichtig, dass für den User eine aussagekräftige Fehlermeldung bereit gehalten wird. Diese sollte kurz und prägnant gehalten sein und den User darüber informieren, dass die angeforderte Ressource leider nicht mehr zur Verfügung steht. Navigationsmöglichkeit: Wenn die Inhalte schon nicht mehr verfügbar sind, sollte dem User zumindest die Möglichkeit geboten werden, die gewohnte Navigation der Website zu nutzen, um beispielsweise Kontakt zum Seitenbetreiber aufzunehmen oder nach ähnlichen Themen zu suchen. Seiten mit ähnlichem Content: Wer die Möglichkeit hat, den Request auszuwerten und entsprechend zu verarbeiten, der sollte dem User neben einer Fehlermeldung und der üblichen Navigation auch gleich passende Ziele mit ähnlichem Content vorschlagen. Das erhöht die Wahrscheinlichkeit, dass der User auf der Seite gehalten werden kann und nicht abspringt. S e i t e 21