Sevke.biz http://sevke.biz Online-Marketing, SEO, Google und andere Internet-Geschichten Thu, 13 Oct 2016 11:17:44 +0000 de-DE hourly 1 https://wordpress.org/?v=4.9.2 http://sevke.biz/wp-content/uploads/2016/02/ms-icon-310x310-150x150.png Sevke.biz http://sevke.biz 32 32 35918120 AMP – Accelerated Mobile Pages – schnelles Internet http://sevke.biz/2016/02/20/amp-accelerated-mobile-pages/ http://sevke.biz/2016/02/20/amp-accelerated-mobile-pages/#respond Sat, 20 Feb 2016 13:51:43 +0000 http://sevke.biz/?p=3632 Accelerated Mobile Pages Project by Google

Worum geht es bei AMP?

Kurz gesagt: Mit speziell gestalteten Webseiten soll das Internet mindestens 4x schneller werden als bisher!

AMP wurde von Google am 7. Oktober 2015 offiziell angekündigt.

Zielgruppe sind in erster Linie Anbieter von Nachrichten wie die Frankfurter Allgemeine Zeitung.

In Google werden AMP-Seiten nur dann als Suchergebnis ausgegeben, wenn man von einem mobilen Endgerät aus sucht. Der Fokus liegt also ganz klar auf der Beschleunigung des Internets (und damit auf der „Benutzererfahrung“ -> „User Experience“) auf Mobilgeräten wie Smartphones. Auf einem PC kann man sich AMP-Seiten ansehen, wenn man ihre genaue Adresse kennt.

Screenshot auf einem Smartphone
Als Beispiel suche ich in Google nach „Angela Merkel“ und erhalte die nebenstehende Ergebnisseite auf einem Smartphone:

AMP-Seiten als Suchergebnis werden in der allgmeinen Suche (also nicht News) prominent ganz oben vor allen anderen Suchergebnissen in Form eines Karussells dargestellt. Mit einer Wischgeste nach links oder rechts kann man sich im Karussel zu anderen Suchergebnissen weiter bewegen.

Screenshot des Artikels in AMP Darstellung
Wenn man den Eintrag von Spiegel Online auswählt, wird sofort die folgende Artikelseite angezeigt:

Wie reduziert diese Seite tatsächlich ist, erkennt man, wenn man sich dieselbe Seite auf dem Desktop als Nicht-AMP-Seite ansieht:
Screenshot des Artikels, wie er auf einem Desktop zu sehen ist

Und wie macht AMP das?

Im Grunde ist das Abspecken von Webseiten auch ohne Googles AMP Initiative jederzeit möglich, wenn man folgende Regeln beachtet:

  • Keine externen JavaScript nachladen
  • Keine externen Stylesheets nachladen
  • Wenige Bilder mit geringer Dateigröße auf der Seite anzeigen
  • Alle Bilder mit Angaben zu Breite und Höhe ausstatten
  • Keine Formulare
  • Keine Videos auf der Webseite anzeigen
  • Keine Werbebanner anzeigen
  • Ein Content Delivery Network (-> CDN) wie Akamai nutzen

Alles zielt darauf ab, erstens das Datenvolumen und zweitens die Anzahl der Verbindungen zu einem oder mehreren Internet-Servern möglichst klein zu halten. Als Goodie oben drauf sollte man die Seite noch responsiv machen, so dass sie sich selbstständig auf mobilen Endgeräten an die Größe des Displays anpasst.

Das kann man natürlich alles per Hand entwickeln. Oder man nutzt einfach ein Framework wie AMP und erspart sich einiges an Arbeit. Das AMP Framework übernimmt mit Hilfe von bestimmten JavaScript-Programmen die Kontrolle über alle Teile einer Webseite, die typischerweise die Ladezeit verlängern. Dazu werden spezielle HTML-Tags definiert, über die dann zum Beispiel Bilder kontrolliert werden. Zusätzlich gibt es eine ganze Reihe von Regeln, was alles auf einer AMP-Seite nicht verwendet werden darf (siehe Liste weiter oben).

Schematische Darstellung eines Content Delivery Networks
Schließlich nutzt Google ein großes Netzwerk an Servern, auf denen alle AMP-Seiten zwischengespeichert werden, um sie jedem Besucher auf dem kürzesten Weg auszuliefern. Ein Besucher aus New York wird die Seite also nicht von Ihrem Server aus München erhalten, sondern von einem in seiner Nähe.

Eine der wesentlichen Maßnahmen ist, dass die Anzahl der nachgeladenen Dateien (JavaScript, Fonts, Stylesheets) radikal reduziert wird. Damit entfallen die zusätzlichen Verbindungen zum Server (und die damit verbundene zusätzliche Kommunikation zwischen Server und Client) und ein großer Anteil an Daten.

Eine weitere Maßnahme ist, dass alle Elemente, die nicht sofort auf dem Display angezeigt werden, weil sie sich weiter unten befinden und daher erst nach einem Scrollen zu sehen sind, zunächst auch nicht geladen werden, sondern erst dann, wenn dieser Teil tatsächlich auf dem Bildschirm ist.

Wenn Sie mit „strukturierten Daten“ wie Microdata gemäß schema.org arbeiten, ist es wichtig zu wissen, dass AMP-Seiten zur Zeit nur die ItemTypes BlogPosting und NewsArticle unterstützen.

Nachteile von AMP

Nachteile von AMP-Seiten
Die Einschränkungen, die sich durch das Abspecken einer Webseite auf wesentliche Inhalte ergeben, lassen sich direkt aus den oben genannten Maßnahmen ableiten.

So müssen alle Stylesheets innerhalb der Seite definert werden und dürfen nicht mehr als 50 KB verbrauchen. Styles als Inline-Code direkt in HTML-Tags sind verboten. Transitions dürfen nur für Transformationen und Transparenz-Änderungen eingesetzt werden. Alle Transitions, die sich auf die Größe oder die Position auswirken, sind tabu. Insgesamt werden Ihnen viele Möglichkeiten für besonders aufwendige Designs genommen. Eine AMP-Seite sieht in aller Regel relativ schlicht aus.

JavaScripts von Dritt-Anbietern (außer AMP) sind verboten. Eigene Skripts dürfen zwar geladen werden, aber nur asynchron. Sie stehen also zu Beginn des Ladens einer Seite nicht zwingend zur Verfügung. Wenn Sie das JavaScript eines Dritt-Anbieters in einen iFrame stecken, dürfen Sie es verwenden, weil es dann das Laden der Seite nicht verzögert.

Bilder und Videos dürfen nur über jeweils ein spezielles AMP-HTML-Tag geladen werden und müssen über Angaben zur Breite und Höhe verfügen. Dies verhindert, dass der Browser beim Laden der Seite Zeit mit der Berechnung der Größe verschwendet. Videos dürfen darüber hinaus nur vom eigenen Server geladen werden. Für YouTube (als Google Tochter) gibt es allerdings wieder eine separate AMP-Komponente, die bei Bedarf geladen werden kann. Animierte GIFs benötigen wieder ein anderes AMP-HTML-Tag zur Steuerung. Auch Slideshows und Lightboxes lassen sich nur über zusätzliche AMP-Komponenten umsetzen.

Interaktive Elemente wie Formulare sind verboten, können aber zur Not mit einem iFrame eingebunden werden. Für die spezielle AMP-iFrame-Komponente muss allerdings ein zusätzliches JavaScript des Frameworks geladen werden. Die Kompononte sorgt dafür, dass der Inhalt des iFrames nicht das Laden der eigentlichen Seite blockiert.

Schriftarten (Fonts) dürfen nur von bestimmten Webseiten (Providern) geladen werden und benötigen ebenfalls ein eigenes AMP-HTML-Tag.

Und schließlich können auch soziale Medien nur mit speziellen AMP-Komponenten eingesetzt werden.

Ein ganz anderer Aspekt ist Werbung auf der Webseite. Gerade die von externen Seiten nachgeladene Werbung kann die Ladezeit einer Seite erheblich erhöhen. Somit ist auf AMP-Seiten nur Werbung zulässig, wenn die dafür vorgesehen AMP-Komponente die Steuerung übernehmen kann. Google AdSense (von Google) wird selbstverständlich unterstützt und auch eine Reihe weiterer Anbieter. Hier eine Liste zu veröffentlichen, macht keinen Sinn, da sicherlich sehr schnell weitere Anbieter hinzukommen werden.

Ein ganz wesentlicher Faktor stellt die Abhängigkeit von Google dar, in die man sich zwangsweise begibt, da erstens die Server von Google als Zwischenspeicher verwendet werden, zweitens die von Google eingebundenen AMP-Skripte eben von Google entwickelt werden.

Für jede Webseite müssen Sie immer zwei Versionen eines Inhalts erzeugen, nämlich die normale Seite und die AMP-Seite. Wenn Sie ein Content Management System nutzen, wird Ihnen in der Regel das System diese Arbeit abnehmen.

Ein weiterer Nachteil ist, dass AMP zur Zeit nur den Google Universal Analytics Code unterstützt, aber nicht den Google Tag Manager. Dies ist bedeutend, wenn man Google Analytics zur Auswertung des Besucherverhaltens einsetzt. Wenn Sie für Ihre Website den Google Tag Manager einsetzen, müssen Sie zumindest auf den AMP-Seiten auf das normale Google Universal Analytics zurückgreifen.

Vorteile von AMP

Die Vortiele von AMP-Seiten
Als Webdesigner kratzen Sie sich jetzt am Kopf und fragen sich bei all den Einschränkungen: „Was bringt mir das jetzt alles?“

Bei AMP dreht sich alles um eine möglichst schnelle Ladegeschwindigkeit.

Das AMP-Framework besteht aus mehreren (einzeln nachladbaren) Komponenten, die dafür sorgen, dass kein Element auf der Webseite das Laden der Seite behindert.

Die höhere Ladegeschwindigkeit einer Seite kann verhindern, dass Internet-Besucher vorzeitig das Laden abbrechen und Ihre Website verlassen. Gerade bei mobilen Endgeräten wie einem Smartphone ist die Bandbreite der Internet-Verbindung oft nicht sehr groß und führt beim Laden einer Seite mit einem großen Datenvolumen schnell zu Frust.

Google hat angekündigt, dass in der mobilen Suche in Zukunft AMP-Seiten bevorzugt angezeigt werden. Insbesondere Nachrichten werden in einer Karussell-Darstellung noch oberhalb der normalen Suchergebnisse angezeigt und laden bei einem Tipp mit dem Finger praktisch verzögerungsfrei. Das liegt nicht nur an den beschriebenen Mechanismen, sondern auch daran, dass Google die zur Auswahl stehenden Seiten bereits (teilweise) vorab lädt, also schon, bevor der Internet-Nutzer ein Suchergebnis ausgewählt hat.


Das folgende animierte Bild zeigt, wie das auf einem Smartphone aussehen könnte:
Animiertes Bild, das die Suchergebnisse in Form eines Karussells auf einem Smartphone zeigt

Obwohl Google das AMP Projekt ins Leben gerufen hat, steht es als Open-Source Initiative dennoch allen offen.

Validierung von AMP-Seiten

Bei den vielen Restriktionen, die uns also beim Erstellen einer AMP-Seite auferlegt werden, ist es gut, wenn man die ordnungsgemäße Umsetzung schnell überprüfen kann.

Dies ist jederzeit durch Aufruf der AMP-Seite mit der Ergänzung des URLs um #development=1 möglich. Das Ergebnis der Validierung wird in der so genannten Browser-Konsole angezeigt.

Im folgenden Screenshot sehen Sie diese Seite als AMP-Seite mit Überprüfung:
Fehlermeldung in der Browser Konsole

Ganz offensichtlich gibt es noch Fehler, die vom PlugIn erzeugt werden. Die sollten natürlich behoben werden.

Hier noch zum Vergleich die Darstellung als normale Webseite und als AMP-Version in der direkten Gegenüberstellung:
Zwei Screenshots im direkten Vergleich

Betrifft mich AMP?

AMP sind momentan nur für News- und Blog-Artikel vorgesehen.

Wenn Sie einen Internet-Shop betreiben, brauchen Sie sich vorerst mit dem Thema nicht weiter zu beschäftigen. Wenn Sie eine Website betreiben, die sich zu einem großen Teil auf JavaScript-Funktionen stützt, wird Sie die AMP-Version Ihrer Seite nicht begeistern.

Eventuell betreiben Sie eine Website mit angehängtem Blog oder Nachrichten-Bereich. Für diese Teilbereiche lassen sich AMP-Seiten gut nutzen.

SEO und AMP

Offiziell werden AMP-Seiten ab dem 24. Februar 2016 in der Google Suche auf mobilen Endgeräten angezeigt.

Für die Analyse des Verhaltens der Website-Besucher wird oft das von Google bereitgestellte kostenlose Tool Google Analytics eingesetzt. Dafür muss auf jeder Seite, die später untersucht werden soll, ein kleiner JavaScript-Block eingebunden werden. Dies ist aber in AMP-Seiten verboten. Wir haben also ein Problem.

Für diesen Fall stellt das AMP Framework eine eigene Komponente bereit, die als JavaScript nachgeladen werden muss. Richtig gelesen, AMP Javescript Komponenten dürfen nachgeladen werden, allerdings nur asynchron, so dass sie das Laden der Webseite nicht verzögern. Parameter werden auf der Seite per JSON-Objekt übergeben.

Wie die Einbindung von Google Analytics im Detail umgesetzt werden kann, steht auf der Google Developers Seite.

Aus der Sicht eines Suchmaschinenoptimierers ist es wichtig, die normale Website und die AMP-Seite wechselseitig mit einem Link-Tag zu verbinden. Die normale Seite nutzt die Relationship „amphtml“ und die AMP-Seite „canonical“. Damit weiß die Suchmaschine, dass es zwei Versionen der Seite mit dem gleichen Inhalt gibt und berücksichtigt das entsprechend.

AMP-Seiten werden von Google nicht besser platziert, nur weil es AMP-Seiten sind. Allerdings ist die Ladegeschwindigkeit einer Seite durchaus ein Ranking-Faktor. Da AMP-Seiten besonders schnell laden, werden sie einen Bonus erhalten. AMP-Seiten sind von Haus aus automatisch besonders mobile friendly.

WordPress und AMP

Wer WordPress als Content Management System (-> CMS) einsetzt, ist fein raus. Automattic, also die Firma, die maßgeblich die Weiterentwicklung des Systems koordiniert und vorantreibt, bietet bereits seit Januar 2016 das PlugIn AMP an.

Das PlugIn wird einfach installiert und aktiviert. Es verfügt über keinerlei Einstellungen, lässt sich aber über diverse „Filter“ und „Actions“ in der Datei functions.php anpassen. Dazu sollte man aber über ein paar Programmierkenntnisse in PHP verfügen und sich auch ein wenig mit den WordPress-Mechanismen „Filter“ und „Action“ auskennen. Wenn Sie die Änderungen direkt in den Dateien des PlugIns durchführen, werden diese leider mit dem nächsten Update des PlugIns überschrieben. Und zur Zeit werden noch relativ viele Updates in kurzen Zeitabständen veröffentlicht.

Da AMP nur für News- und Blog-Artikel vorgesehen ist, unterstützt das AMP-PlugIn folgerichtig (bisher?) nicht die AMPfizierung von Blog-Seiten, sondern nur von Blog-Artikeln. Was ist der Unterschied? Ursprünglich war WordPress ein reines Blog-System zum Schreiben von chronologischen Artikeln. Später wurde die Funktionalität in Richtung CMS weiter entwickelt, so dass auch normale Webseiten möglich wurden. So etwas wird zum Beispiel für ein Impressum benötigt.

Den Code für Google Analytics (siehe weiter oben) fügt man am besten ebenfalls über einen Filter in der functions.php hinzu. Dafür stellt das PlugIn den Hook amp_post_template_analytics zur Verfügung.

Bei der automatischen Generierung von AMP-Seiten muss beachtet werden, dass viele WordPress-PlugIns zusätzlichen Code in die Seiten einfügen. Dieser kann durchaus Schuld daran sein, dass die AMP-Seite mit Fehlern validiert wird. Ich gehe davon aus, dass es für die wichtigsten PlugIns nach und nach Updates geben wird, die dies berücksichtigen werden. Für das bekannte SEO PlugIn von Yoast gibt es bereits ein zusätzliches PlugIn, das AMP-Seiten und die Einstellungen des Yoast PlugIns miteinander abgleicht. Dieses zusätzliche PlugIn soll in der Zukunft direkter Bestandteil des Yoast SEO PlugIns werden. Momentan muss es noch separat installiert werden.

Auch wenn ich hier nur WordPress als CMS angesprochen habe, werden andere Systeme ebenfalls in Kürze Unterstützung für AMP anbieten.

Mehr Informationen im Internet zu AMP

Dieser Artikel soll nicht alle technischen Aspekte des AMP Projekts ansprechen. Es gibt eine Reihe von zusätzlichen Informations-Quellen im Internet. Hier einige der wichtigsten:

]]>
http://sevke.biz/2016/02/20/amp-accelerated-mobile-pages/feed/ 0 3632
Googlebot hat keinen Zugriff auf CSS- und JS-Dateien http://sevke.biz/2015/07/29/googlebot-kein-zugriff-auf-css-und-js-dateien/ http://sevke.biz/2015/07/29/googlebot-kein-zugriff-auf-css-und-js-dateien/#respond Wed, 29 Jul 2015 20:43:54 +0000 http://sevke.biz/?p=3594
Weiterlesen... »]]>
Artikelbild zum Artikel Googleboot hat keinen Zugriff auf CSS- und JS-DateienWenn Sie die Google Search Console für Ihre Website verwenden (und das sollten Sie!), dann haben Sie möglicherweise in letzter Zeit eine Nachricht erhalten mit dem Titel:

Der Googlebot kann nicht auf CSS- und JS-Dateien auf URL zugreifen.

(Anstelle von URL wird Ihre Website genannt.)

In den meisten Fällen haben Sie der Suchmaschine mit Hilfe der Datei robots.txt verboten, sich bestimmte Dateien oder Verzeichnisse anzusehen (=> zu crawlen). Mehr Informationen zur robots.txt finden Sie in meinem Artikel Die Datei robots.txt.

Die Meldung selber lautet:

Die Google-Systeme haben kürzlich ein Problem mit Ihrer Startseite festgestellt, das sich auf das Rendern und Indexieren Ihrer Inhalte durch unsere Algorithmen auswirkt. Der Googlebot kann aufgrund von Beschränkungen in Ihrer robots.txt-Datei nicht auf Ihre JavaScript- und/oder CSS-Dateien zugreifen. Anhand dieser Dateien kann Google feststellen, ob Ihre Website ordnungsgemäß funktioniert. Wenn Sie den Zugriff auf diese Dateien blockieren, kann dies zu schlechteren Rankings führen.
 
E-Mail vom Googlebot, in der ein fehlender Zugriff auf CSS und Javascript gemeldet wird

Mausklick für eine größere Darstellung

Wie Sie sehen können, werden in der E-Mail auch gleich ein paar Hinweise gegeben, wie Sie dieses Problem beheben können.

Möglicherweise schleicht sich jetzt ein Stirnrunzeln in Ihr Gesicht, denn Sie haben doch immer alles daran gesetzt, dass Google Ihre Seiten leicht finden und indexieren kann, also …

 

Wieso kann Google nicht auf meine Dateien zugreifen?

Früher hat Google sich nur für den reinen Text Ihrer Seite interessiert (technisch gehört der HTML-Code auch dazu). Das Design in Form von CSS und zusätzliche Programmierung in Form von JavaScript wurde nicht berücksichtigt. Beides kann aber sehr wichtig für die Bedeutung der Inhalte einer Seite sein. Die Suchmaschinen haben daher dazu gelernt und versuchen, die Seiten zunächst zu rendern (also so aufzubereiten, wie Sie als User die Seite im Browser sehen) und erst dann zu analysieren.

Natürlich ist es dazu notwendig, dass der Zugriff auf die entsprechenden Dateien nicht per robots.txt blockiert wird.

Die E-Mail von Google bedeutet allerdings nicht, dass Ihre Webseiten fehlerhaft seien. Google vermisst lediglich den Zugriff auf einige Dateien.

 

Welche Dateien sind für den Googlebot blockiert?

In der Google Search Console gibt es einen eigenen Menüpunkt Google-Index -> Blockierte Ressourcen, um sich die Dateien anzeigen zu lassen, auf die der Googlebot nicht zugreifen kann.

Screenshot von der Google Search Console: blockierte Ressourcen

Mausklick für eine größere Darstellung

Die Liste finden Sie am unteren Ende des Screenshots als Auszug.

Zusätzlich können Sie sich die von Google gefundene robots.txt unter dem Menüpunkt Crawling -> robots.txt-Tester zur Prüfung anzeigen lassen.

Screenshot vom robots.txt-Tester in der Google Search Console

Mausklick für eine größere Darstellung

 

Was kann ich tun?

Ganz einfach: Google darf der Zugriff auf die angemeckerten Seiten nicht verwehrt werden. Werfen Sie also einen Blick in Ihre robots.txt.

In der robots.txt sollte der Zugang auf die Themes/Template-Verzeichnisse nicht gesperrt werden.

Für WordPress wären das (beispielsweise):

  • /wp-content/plugins/
  • /wp-content/cache/
  • /wp-content/themes/
  • /wp-includes/

Standardmäßig werden in der von WordPress virtuell angelegten robots.txt nur die beiden folgenden Verzeichnisse blockiert:

  • /wp-admin/
  • /wp-includes/

In /wp-includes/ werden allerdings eine ganze Reihe von CSS– und JS-Dateien abgelegt, so dass es sinnvoll ist, auch dieses Verzeichnis nicht zu sperren. Dazu muss dann allerdings eine eigene physische Datei robots.txt angelegt werden.

Joomla verwendet für Themes/Templates (beispielsweise):

  • /templates/

Alle aufgeführten Verzeichnisse enthalten sowohl CSS– als auch JS-Dateien und sollten daher nicht mit einem disallow blockiert werden.

Entfernen Sie die Einträge entsprechend in der robots.txt oder machen Sie durch das Voransetzen eines # aus der Zeile einen Kommentar (in dem Fall wissen Sie später noch, welche Verzeichnisse Sie manuell von der Blockade befreit haben).

Das könnte dann folgendermaßen aussehen:

# Disallow: /templates/

Falls Sie weder WordPress noch Joomla verwenden, könnten Sie möglicherweise eine der folgenden Zeilen in Ihrer robots.txt finden, die das Rendern der Webseite verhindern:

    
    Disallow: /*.js$
    Disallow: /*.inc$
    Disallow: /*.css$
    Disallow: /*.php$
    

Auch diese Zeilen soltlen Sie entfernen oder auskommentieren.

Anders herum funktioniert es ebenfalls. Statt Google etwas nicht zu verbieten, können Sie Google den Zugriff auch explizit erlauben. Das sieht dann folgendermaßen aus:

    
    User-agent: Googlebot
    Allow: /*.js$
    Allow: /*.css$
    

Aber Vorsicht! Die Anweisung Allow: ist offiziell nicht definiert, wird aber von einigen User-Agents (wie dem Googlebot) ausgewertet. Die Reihenfolge der Anweisungsblöcke spielt für den Googlebot in diesem Fall keine Rolle. Wenn ein Block speziell für den Googlebot definiert wird, so werden alle anderen Blöcke überlesen. Wenn Sie in Ihrem Block allerdings nichts verbieten, so wie im obigen Beispiel, dann können Sie auch gleich alles mit "Allow: /" erlauben. Der Block macht also nur Sinn, wenn Sie zusätzlich dort Verzeichnisse oder Dateien ausschließen.

 

Wie kann ich meine Bemühungen überprüfen?

Wenn Sie Ihre robots.txt geändert haben, können Sie das Ergebnis Ihrer Bemühungen sofort in der Google Search Console überprüfen. Dazu reichen Sie Ihre Seite bei Google für einen Recrawl über den Menüpunkt Crawling -> Abruf wie durch Google ein.

Screenshot der Funktion "Abruf wie durch Google" in der Google Search Console

Mausklick für eine größere Darstellung

]]>
http://sevke.biz/2015/07/29/googlebot-kein-zugriff-auf-css-und-js-dateien/feed/ 0 3594
404 Server Fehler – eigene Fehlerseite http://sevke.biz/2015/05/29/404-server-fehler-eigene-fehlerseite/ http://sevke.biz/2015/05/29/404-server-fehler-eigene-fehlerseite/#respond Fri, 29 May 2015 08:57:52 +0000 http://sevke.biz/?p=3549
Weiterlesen... »]]>
Probieren Sie es einmal aus … geben Sie den Namen Ihrer Domäne ein und ergänzen Sie den URL um „/aaa“.

Wenn Sie Pech haben, liefert Ihnen der Webserver folgende Seite zurück:

Screenshot eines generischen 404 Serverfehlers

Mit etwas Glück stellt Ihr Webhoster eine etwas gefälligere Fehlerseite zur Verfügung wie zum Beispiel Domainfactory:

Screenshot eines  404 Serverfehlers bei Domainfactory

Was ist passiert?

Sie haben versucht, eine Webseite anzusteuern, die es gar nicht gibt. Idealerweise erhalten Sie eine Fehlermeldung und Ihr Browser einen Fehlercode mit der Nummer 404. Dieser Code kann anschließend vom Browser oder von einem anderen programmgesteuerten System (zum Beispiel einer Suchmaschine), das auf diese Seite zugreifen wollte, ausgewertet werden.

 

404-Fehler aus der Sicht der Suchmaschine

Solange die Webseite im Response-Header den Server-Code 404 zurückliefert, weiß eine Suchmaschine, die bei ihrer endlosen Suche nach neuen Webseiten im Internet auf diese Seite gelangt ist, wenigstens, dass es keinen Grund gibt, die Seite in den Index aufzunehmen. Ein Besucher wird sie also auch nicht in den Suchergebnislisten sehen.

Aber manchmal erhält die Suchmaschinen keinen Code 404 vom Server, sondern wird auf eine andere Seite weitergeleitet und erhält den Server-Code 200 zurück. Sie geht nun davon aus, dass diese Seite zum gesuchten Keyword passt (falls jemand über eine Suche auf der ungültigen Webseite gelandet ist) und analysiert anschließend die Relevanz für das Keyword. In den seltensten Fällen passt die Seite noch richtig zum Keyword, was zur Folge hat, dass diese Seite abgewertet wird. Außerdem wird Google (als Beispiel für die wichtigste Suchmaschine in Deutschland) sich bei der Seite einen so genannten Soft-404 Fehler merken. Diese Fehler können Sie sich als Betreiber einer Website mit Hilfe der Google Search Console (früher Google Webmaster Tools) ansehen.

Seiten mit Soft-404 werden nicht sehr schnell aus dem Index entfernt, da die Suchmaschine diesen Fehler als vorübergehend einstuft. Somit bleiben die nicht mehr existierenden Seiten für eine sehr lange Zeit im Index.

Nun gut, Ihre Website erzielt auf den Suchergebnisseiten für einen Suchbegriff, der für Sie nicht mehr interessant ist, keine guten Platzierungen. „Egal,“ denken Sie. Aber sieht das auch ein Besucher Ihrer Website so?

 

404-Fehler aus der Sicht des Besuchers

Auf eine nicht existierende Seite, die korrekt den Server-Code 404 zurückliefert, wird ein Benutzer über Google nicht stoßen. Die Seite wird ja nicht als Suchergebnis angezeigt.

Wird sie es doch, so liefert sie den in diesem Fall falschen Server-Code 200 zurück. Entweder ist es die Fehler-Seite selber oder eine Seite, auf die bei einem Fehler weitergeleitet wird.

Auch über fehlerhafte Links auf den Websites von Dritten können Besucher natürlich zu Seiten geleitet werden, die nicht existieren (das hat dann aber nichts mit der Suchmaschine zu tun). Das können zum Beispiel Partner-Sites sein oder Erwähnungen in einem Internet-Blog oder alte Beiträge in einem Forum und dergleichen.

Jetzt versetzen Sie sich einmal in die Lage eines Besuchers, der zum Beispiel nach Informationen über den Ort Carvoeiro in Portugal sucht und dafür den Link http://www.portugal-live.net/carvoeiro eingibt oder ihm von einer Partnerseite folgt, auf der der Link so eingetragen ist.

Oder versuchen Sie mal die folgende Seite, falls Sie einen Anwalt in Carvoeiro suchen: Anwalt in Carvoeiro

Probieren Sie es ruhig einmal aus. Das Ergebnis ist ernüchternd.

Für den Fall, dass die Fehlerseite inzwischen neu gestaltet wurde, zeige ich Ihnen hier, wie die Seiten am 28.05.2015 aussahen. Per Mausklick erhalten Sie eine vergrößerte Darstellung:

Screenshot der 404-Fehlermeldung bei Portugal-LiveScreenshot der 404-Seite von Anwalt-Portugal


Wie kommt es zu 404-Fehlern

Aber wieso kann jemand überhaupt auf einer Seite landen, die gar nicht existiert? Sie geben sich wahrscheinlich sehr viel Mühe, dass die interne Verlinkung Ihrer Webseiten stets korrekt ist. Insofern müsste Google doch auch immer die korrekten Seiten in den Index aufnehmen.

Ja, das ist erst einmal richtig.

Folgende Situationen fallen mir ein, bei denen es zu ungültigen Links kommen kann:

  1. Sie tragen manuell einen ungültigen Link auf Ihrer Website ein (Schreibfehler)
  2. Sie löschen eine Seite auf Ihrer Website
  3. Das von Ihnen verwendete CMS oder Shop-System erzeugt einen ungültigen Link
  4. Ein Besucher vertippt sich bei der Eingabe eines URLs in die Adresszeile seines Browsers

 

Manuell falsch eingetragener Link

Es kann schon mal vorkommen, dass Sie auf einer Website einen Link manuell eintragen, sich dabei aber verschreiben, ohne es zu bemerken. Jeder Besucher, der den Link anklickt, wird dann eine Fehlermeldung erhalten.

 

Eine Webseite wird gelöscht

Stellen Sie sich vor, dass Sie eine Seite auf Ihrer Website löschen, dann werden Suchmaschinen beim nächsten Besuch dieser Seite (=Crawling) erkennen, dass sie nicht mehr existiert und sie aus dem Index entfernen. Voraussetzung ist natürlich, dass diese Seite den korrekten Server Fehlercode 404 („Page Not Found“) zurückliefert und nicht etwa 200 („Ok“). Auch eine Weiterleitung auf beispielsweise die Startseite verhindert, dass eine Suchmaschine die Seite aus dem Index entfernt.

Es kann aber sein, dass irgendjemand selber eine Website betreibt und dort auf Ihre alte Seite verlinkt hat. Wenn der Betreiber der Seite nicht regelmäßig seine Links auf Gültigkeit überprüft, wird er diesen ungültigen Link nur dann erkennen, wenn ihn jemand darauf hinweist. Bis dahin werden alle Internetnutzer vom Server die Meldung erhalten, dass die Seite nicht existiert, sobald sie diesem ungültigen Link folgen.

Eine zweite Möglichkeit, wieso jemand über einen ungültigen Link zu Ihnen findet, ist das Speichern eines Lesezeichens (Bookmark) im Browser. Für wichtige oder interessante Webseiten kann sich jeder in seinem Browser ein Lesezeichen setzen, so dass er die Seite später ohne große Suche schnell wiederfindet. Die hinterlegten Bookmarks werden natürlich nicht automatisch entfernt, wenn Sie auf Ihrer Website eine Seite löschen. Deswegen ist es gut möglich, dass sich jemand über einen gespeicherten ungültigen Link auf Ihre Website verirrt.

Immerhin sind Sie in diesem Beispiel irgendwie selbst schuld, dass Sie die Seite gelöscht haben. Eine Alternative wäre es, wenn Sie nur den Inhalt der Seite durch einen Hinweis ersetzen würden, dass diese Seite aus bestimmten Gründen entfernt wurde. Zusätzlich können Sie dann Ihrem Besucher gleich noch ein paar alternative Seiten als Link anbieten. Auf diese Weise käme es gar nicht erst zu einem ungültigen Link, denn Ihre Seite existiert ja weiterhin.

 

Dynamisch falsch erzeugte Links

Nun kann es aber auch passieren, dass Sie ein System verwenden (einen Shop zum Beispiel), der viele tausend Seiten dynamisch in Abhängigkeit von bestimmten Kriterien generiert wie zum Beispiel einer Produktbezeichnung. Leider passiert es immer wieder, dass URLs erzeugt werden, die ungültig sind, also auf keine existierende Seite verweisen. Auch in Systemen, die auf Mehrsprachigkeit ausgelegt sind, passiert es manchmal, dass die entsprechenden Seiten in einer anderen Sprache gar nicht vorhanden sind, dennoch Links darauf generiert werden. Sollte nicht passieren, tut es aber. Diese ungültigen Links befinden sich dann auf Ihrer Website und liefern nach einem Klick den berüchtigten Fehler 404 zurück.

Natürlich ist es bei einem Shop-System völlig normal, dass sich praktisch täglich die Artikel im Shop ändern. So zeigen völlig korrekte Links möglicherweise schon nach kurzer Zeit auf ein Produkt, das Sie nicht mehr im Shop anbieten.

 

Tippfehler im Browser

Manche Besucher geben eine Internet-Adresse direkt in die Adressleiste des Browsers ein. Dabei kann es schon mal passieren, dass sich ein Tippfehler einschleicht. Solange der Domänenname korrekt ist, wird die entsprechende Website eine Fehlermeldung zurückliefern.

404-Fehler passieren also und sind überhaupt nichts Außergewöhnliches. Deswegen sollte sich ein Website-Betreiber über die Gestaltung einer sinnvollen Fehlerseite Gedanken machen.

 

Was steht auf einer 404-Fehlerseite?

Auf einer individuell gestalteten 404-Fehlerseite sollte zuerst einmal auf den Fehler hingewiesen werden, damit der Besucher sich nicht darüber wundert, dass er nicht dort gelandet ist, wo er eigentlich hin wollte. Sie sollten darauf achten, keine fachspezifischen Begriffe zu verwenden. Schon die Erwähnung von „404“ kann abschreckend wirken. Nicht jeder Ihrer Besucher ist ein Internet-Spezialist.

Damit der Besucher an dieser Stelle nicht sofort abspringt (beispielsweise durch Drücken der Backspace-Taste … jetzt NICHT drücken! … und sich eine andere Website ansieht, sollte er eine Navigation erhalten, die ihn zu gültigen Inhalten führt. Dazu gehört auch ein Link zur Startseite.

Eine weitere Möglichkeit ist, eine Liste der 10 beliebtesten Blog-Artikel anzubieten.

Wenn man ein Shop-System betreibt, könnten auf der Fehlerseite bereits zwei, drei aktuelle Angebote präsentiert werden, die neugierig machen und den potenziellen Kunden auf der Website halten sollen.

Außerdem ist es es hilfreich, Ihrem Besucher auf der Fehlerseite eine direkte Kontaktmöglichkeit anzubieten, an die er den Fehler melden oder einfach nur Luft ablassen kann.

Zusätzlich kann es nützlich sein, wenn man auf der 404-Seite die Möglichkeit zur Suche innerhalb der Website anbietet.

Wenn Sie es ganz raffiniert machen wollen, so generieren Sie für die oben im Abschnitt Wie kommt es zu 404-Fehlern genannten Fälle jeweils eine eigene, ganz auf die Fehlerquelle zugeschnittene Fehlerseite. Dazu müssen Sie allerdings ein wenig programmieren.

 

404-Fehler in WordPress

Screenshot der Standard 404-Fehlerseite in WordPress
WordPress ist ein Content Management System, das von Haus aus eigene 404-Fehlerseiten unterstützt. Dazu muss nur die Datei 404.php im entsprechenden Theme bereitgestellt werden. Wenn Sie Ihr Theme nicht selber erstellt haben, sollte sich eine entsprechende Datei bereits im Verzeichnis des verwendeten Themes befinden (/wp-content/themes/Ihr-Theme-Name/404.php). Allerdings müssen Sie sich in jedem Fall um eine entsprechende Gestaltung kümmern.

Üblicherweise laden Sie in der 404.php zunächst den Header der Seite, zeigen dann den Inhalt Ihrer Fehlermeldung mit HTML an und binden anschließend noch den Seiten-Footer an. Damit integriert sich die Seite nahtlos in das übrige Design Ihrer Website.

Falls Sie eine eigene 404.php Datei erstellen möchten oder müssen, macht es Sinn, sich die entsprechende 404.php aus einem der mitgelieferten Standard-Themes (Twenty Fifteen) in das eigene Theme-Verzeichnis umzukopieren und dann anzupassen.

 

404-Fehler in Joomla

Screenshot der standardmäßigen 404-Fehlerseite in Joomla
Auch Joomla hat natürlich eine Standard 404-Fehlerseite an Bord. Wie bei WordPress befindet sich die entsprechende Datei ebenfalls im Themes-Verzeichnis, bei Joomla Template genannt (/templates/Ihr_Template-Name/error.php). Statt 404.php heißt die Datei bei Joomla error.php.


 

Beispiele für 404-Fehlerseiten

Üblicherweise wird es nötig sein, die vom Theme/Template mitgelieferte 404-Fehlerseite auf Ihre Anforderungen hin anzupassen, sollten Sie ein CMS wie Joomla oder WordPress einsetzen.

Falls Sie kein CMS einsetzen, sollten Sie überprüfen, ob Ihre Website überhaupt über eine eigene 404-Fehlerseite verfügt. Dazu geben Sie in der Adressleiste einfach die Adresse Ihrer Website ein und ergänzen sie am Ende mit „/aaa“, also beispielsweise http://www.google.de/aaa. Sollten Sie ausnahmesweise über eine Seite „aaa“ verfügen, so nehmen Sie stattdessen irgendeinen anderen Seitennamen, den er garantiert nicht auf Ihrer Website gibt.

Die folgenden Beispiele inspirieren Sie vielleicht zu eigenen individuellen 404-Fehlerseiten:

Screenshot der 404-Fehlerseite von Hundeland.de

]]>
http://sevke.biz/2015/05/29/404-server-fehler-eigene-fehlerseite/feed/ 0 3549
Google stellt Autorenbilder komplett ein http://sevke.biz/2014/09/02/google-stellt-autorenbilder-ein/ http://sevke.biz/2014/09/02/google-stellt-autorenbilder-ein/#respond Tue, 02 Sep 2014 16:43:52 +0000 http://sevke.biz/?p=3536
Weiterlesen... »]]>
Screenshot des Google Snippet mit Author Kennzeichnung

So wie auf dem oben stehenden Ausschnitt werden meine Links nie wieder in Google aussehen.

Bereits im Juni habe ich in meinem Artikel Google entfernt Autoren-Bilder darüber berichtet, dass Google die Autoren-Porträts neben den Suchergebnissen nicht mehr länger anzeigt.

Übrig geblieben war nur noch ein kurzer Vermerk mit dem Namen des Autors in Textform (eine so genannte Byline).

Aber auch damit ist es nun vorbei.

Ich fand die Bilder recht nützlich, konnte ich doch auf manchen Sucherergebnislisten schon auf einen Blick die Treffer vorsortieren, falls dort mir bekannte Autoren zu sehen waren. Leider haben wohl nur wenige Spezialisten die Möglichkeit genutzt, neben dem Link ein Foto von sich zu veröffentlichen.

Google argumentiert, die Autorenbilder hätten zu sehr von den Suchergebnissen abgelenkt. Diese Begründung halte ich für ziemlich fadenscheinig, denn viel mehr lenken mich die Werbeanzeigen oberhalb und seitlich der Suchergebnisse ab. Auf diese wird Google aber vermutlich nicht verzichten.

Die Reputation, die sich ein Autor im Laufe der Zeit im Internet aufbaut, wird auch in Zukunft ein wichtiges Signal für Suchmaschinen sein, das in die Relevanzbewertung (sprich: in das Ranking) einfließen wird. Der bisherige Ansatz scheint aber nicht zum Ziel geführt zu haben. So bleibt abzuwarten, auf welche Weise Google in Zukunft diese Autoren-Reputation nutzen und eventuell sichtbar machen wird.

]]>
http://sevke.biz/2014/09/02/google-stellt-autorenbilder-ein/feed/ 0 3536
Webseite aus dem Google-Index entfernen http://sevke.biz/2014/07/14/webseite-aus-dem-google-index-entfernen/ http://sevke.biz/2014/07/14/webseite-aus-dem-google-index-entfernen/#respond Mon, 14 Jul 2014 11:39:30 +0000 http://sevke.biz/?p=3519
Weiterlesen... »]]>
Artikelbild zum Artikel Webseite aus dem Google-Index entfernenManchmal möchte man, dass bestimmte Seiten aus dem Google-Index verschwinden. Zur Zeit wird viel über das Recht auf Vergessenwerden diskutiert. Damit wird es dem Einzelnen ermöglicht, unter bestimmten Voraussetzungen Verweise aus dem Google-Index entfernen zu lassen.

Darum soll es aber in diesem Artikel nicht gehen.

Thema dieses Beitrags ist die Löschung von Seiten aus dem Google-Index als Betreiber einer Website.

 

Warum überhaupt eine Seite löschen?

Heerscharen von SEO-Managern bemühen sich, möglichst viele Seiten auf möglichst hohen Positionen in Google unterzubringen. Welchen Grund könnte es geben, dass jemand Seiten ganz bewusst aus dem Index entfernen möchte?

Stellen Sie sich vor, Sie betreiben einen Webshop mit vielen Artikeln. Jeder Artikel verfügt über eine Detailbeschreibung, die über einen direkten Link erreicht werden kann. Normalerweise wird auch eine Suchmaschine diese Links irgendwann entdecken und in den Index aufnehmen. Das liegt durchaus im Interesse des Webshop-Betreibers.

Wenn Sie den Artikel aus dem Sortiment entfernen, werden Sie zur Pflege Ihres Webshops eine der folgenden Maßnahmen durchführen:

  1. Für den alten Link eine spezielle Ersatzseite mit Hinweisen oder ähnlichen Produkten bereitstellen
  2. Den ursprünglichen Link per .htaccess Datei auf ein anderes Produkt weiterleiten, das dem bisherigen sehr ähnlich ist
  3. Den ursprünglichen Link per .htaccess Datei auf die Startseite weiterleiten
  4. … oder gar nichts tun

Wenn nun ein Besucher in der Ergebnisliste einer Suchabfrage auf den alten Link klickt, wird er in den Fällen 1-3 eine (mehr oder weniger) passende Seite erreichen. (Auf diese Fälle werde ich hier nicht weiter eingehen.)

Im 4. Fall allerdings wird er auf einer (hoffentlich informativen) Fehlerseite landen. Wenn Sie Pech haben, wird er den Besuch Ihres Shops an dieser Stelle frustriert abbrechnen und es beim nächsten Treffer in der Suchergebnisliste versuchen. Das wollen wir aber verhindern!

Besser wäre es, wenn der fehlerhafte bzw. veraltete Link gar nicht mehr im Google-Index zu finden wäre.

Dies geschieht irgendwann ganz automatisch, wenn Google weiß, dass eine Seite nicht mehr existiert (Dazu muss der Server-Code 404 oder 410 zurückgegeben werden.)

Neben dem offensichtlichen Wunsch, eine nicht mehr vorhandene Seite aus dem Index zu bekommen, kann es natürlich auch Gründe geben, eine weiterhin existierende Seite aus dem Index löschen zu wollen.

Zum Beispiel könnte es urheberrechtliche Probleme mit Inhalten auf Ihren Seiten geben, die Sie deshalb möglichst schnell aus dem Google-Index entfernen müssen.

 

Wie kann ich fehlerhafte Links entdecken?

Oft stolpert man nur zufällig über fehlerhafte Links, wenn man prüft, welche Platzierungen die eigene Website bei der Suche nach bestimmten Suchbegriffen hat.

Manchmal wird man von einem Besucher auf fehlerhafte Links hingewiesen.

Die sicherste Methode ist allerdings die Nutzung der Google Webmaster Tools. (Andere Suchmaschinen bieten ähnliche Hilfsmittel an.)

Zur Nutzung der Google Webmaster Tools müssen Sie sich einen kostenlosen Account anlegen.

Anschließend können Sie sich ansehen, auf welche Fehler Google beim Crawlen Ihrer Website gestoßen ist.

Screenshot mit der Darstellung der Crawling Errors in den Google Webmaster Tools

Unterhalb der Grafik befindet sich eine Liste mit allen fehlerhaften Links. Weitere Hilfe zu dieser Seite erhalten Sie bei Google durch den Artikel Die Seite Crawling-Fehler.

 

Wie kann ich eine Seite aus dem Google-Index löschen?

Screenshot des Seitenmenüs der Google Webmaster Tools

Sobald Sie wissen, welche Seiten Sie aus dem Index der Suchmaschine entfernen möchten, können Sie die Webmaster Tools einsetzen, um die Seite zu entfernen.

Wählen Sie auf der linken Seite den Menüpunkt URLs entfernen aus.

Hierzu stellt Google eine eigene Hilfeseite bereit, nämlich Ganze Seite vollständig entfernen.

Wenn Sie eine weiterhin existierende Seite mit Hilfe der Webmaster Tools löschen, sollten Sie diese Seite parallel in der Datei robots.txt für das erneute Crawlen sperren.

Seiten, die zwar bereits im Index eingetragen sind, die sie aber dort entfernen möchten, können SIe auch noch auf eine andere, etwas langsamere Art löschen.

Dazu schreiben Sie in den Head-Bereich der Seite

<meta name="robots" content="noindex">

Sobald Google diese Anweisung bei einem Crawling-Vorgang liest, wird die Seite in der Nachbearbeitung aus dem Index gelöscht.

Ist eine Seite aus dem Suchmaschinen-Index gelöscht, stellt sich die Frage …


Wie kann ich die Indexierung verhindern?

Manchmal macht es Sinn, die Suchmaschinen darüber zu informieren, dass bestimmte Seiten gar nicht erst in den Index gelangen sollen. Dann muss man sie später nicht wieder löschen.

Vielen fällt als erstes die Datei robots.txt ein.

Vielleicht kommt Ihnen auch das Meta-Tag NOINDEX in den Sinn.

 

Kann ich die Indexierung mit der robots.txt verhindern?

Vor einigen Jahren habe ich den Artikel SEO-Tipp #7: die Datei robots.txt veröffentlicht und Syntax und Funktion dieser Datei beschrieben.

Wenn Sie mit einer SEO-Agentur zusammenarbeiten oder selber SEO-Tools einsetzen, werden Sie meistens auf das Vorhandensein oder Nicht-Vorhandensein der robots.txt hingewiesen.

Das Fehlen der robots.txt ist aus Sicht der Suchmaschinenoptimierung absolut unwichtig.

Interessanter wird es, wenn die Datei existiert.

Zunächst gilt es aber im Hinterkopf zu behalten, dass die Anweisungen in der robots.txt keineswegs bindend für irgendeinen Web-Crawler sind. Auf diese Weise lassen sich Informationen nicht verstecken! (Mehr dazu im oben angesprochenen Artikel SEO-Tipp #7: die Datei robots.txt)

Wenn Sie Inhalte wirklich schützen wollen, so stellen Sie diese am besten nicht ins Internet oder schützen Sie den Bereich durch Authentifizierungsmaßnahmen wie zum Beispiel durch die Verwendung einer Benutzerkennung/Kennwort-Kombination. So geschützt haben Suchmaschinen keine Chance, die Dateien in dem Verzeichnis auch nur zu sehen, geschweige denn zu crawlen.

Beachten Sie weiter, dass Suchmaschinen Ihre robots.txt nicht ständig neu auslesen. Wenn Sie eine Datei oder ein Verzeichnis mit Hilfe der robots.txt vom Crawlen ausschließen wollen, so definieren Sie die entsprechende Direktive ein paar Tage, bevor Sie die betroffenen Seiten tatsächlich auf Ihrem Webserver bereitstellen, mindestens jedoch 24 Stunden vorher.

Von Google gibt es dazu auch eine offizielle Aussage:

Caching

A robots.txt request is generally cached for up to one day, but may be cached longer in situations where refreshing the cached version is not possible (for example, due to timeouts or 5xx errors). The cached response may be shared by different crawlers. Google may increase or decrease the cache lifetime based on max-age Cache-Control HTTP headers.
Robots.txt Specifications

Wenn Sie alle Seiten, die nicht im Google-Index auftauchen sollen, rechtzeitig in die robots.txt eintragen, wird die Suchmaschine diese Seiten nicht crawlen. Im Index landen sie trotzdem. Nur der Inhalt wird nicht untersucht und dort vorhandene Links werden nicht verfolgt.

Leider können Sie eine Webseite mit der robots.txt weder löschen noch vor der Indexierung schützen.

 

Kann ich die Indexierung mit dem Meta-Tag und dem Attribut robots verhindern?

Es besteht die Möglichkeit, im Head-Bereich einer HTML-Seite die folgende Anweisung zu hinterlegen

<meta name="robots" content="noindex">

Diese Anweisung weist die Suchmaschine an, die Seite nicht in den Index aufzunehmen.

Falls sich die Seite bereits im Index befinden sollte, wird sie entfernt, sobald Google die Seite erneut analysiert.

Aber Achtung: die Seite muss natürlich für Google und Co. lesbar sein. Sie darf also in der robots.txt keineswegs gesperrt sein. Denn dann liest die Suchmaschine nicht den Inhalt der Seite und findet auch die Noindex-Direktive nicht.

Der Nachteil dieser Anweisung ist, dass man sie in jede betroffene Seite schreiben muss. Ein ganzes Verzeichnis lässt sich auf diese Weise nicht vor der Indexierung schützen.

 

Schlussbemerkung

Die sogenannten 404-Fehler (Seite nicht gefunden) sind aus Sicht einer Suchmaschine nicht kritisch, sondern gehören zum normalen Betrieb einer Website.

Für den Besucher einer Website können fehlerhafte Links aber sehr frustrierend sein und zum Abbruch des Besuchs führen. Umso wichtiger ist es, diese Fälle mit einer informativen Fehlerseite abzufangen.

Wie es andere machen, zeigen die Seiten 404 Error – Die schönsten Fehlerseiten oder 404-Error mal anders: 40 Beispiele für richtig kreative Fehlerseiten.

Suchmaschinen unterstützen den Website-Betreiber mit verschiedenen Werkzeugen bei der Behandlung von fehlerhaften Verlinkungen. Entweder werden die toten Links weitergeleitet oder sie werden aus dem Index gelöscht, manuell oder nach einer gewissen Zeitspanne automatisch.

Das Löschen von einzelnen Links aus dem Google Suchindex gestaltet sich für den Betreiber einer Website sehr einfach, handelt es sich nun um tatsächlich nicht mehr existierende Seiten oder um Seiten, die zwar vorhanden sind, aber nicht als Link in den Suchergebnislisten angezeigt werden sollen.

]]>
http://sevke.biz/2014/07/14/webseite-aus-dem-google-index-entfernen/feed/ 0 3519
Meta-Title oder Page-Title oder beides? http://sevke.biz/2014/07/08/meta-title-oder-page-title/ http://sevke.biz/2014/07/08/meta-title-oder-page-title/#respond Tue, 08 Jul 2014 17:37:57 +0000 http://sevke.biz/?p=3486
Weiterlesen... »]]>
Artikelbild zu HTML Title-Element

Unterschied zwischen Meta-Title und Page-Title

Bei der SEO-Optimierung einer Website bin ich auf den folgenden Meta-Tag gestoßen:

<meta name="title" content="Dies ist der Titel der Seite" />

Bisher war ich es gewohnt, den Seitentitel in Form eines HTML-Elements in die Seite einzupflegen, also:

<title>Dies ist der Titel der Seite</title>

Ich habe hier im Blog den SEO-Tipp #1: der Seitentitel zu diesem Thema geschrieben.

Im OnPageWiki finde ich dazu folgende Aussage:

Google verwendet den Meta Title einer Webseite fast immer als Überschrift der Seite in den Suchergebnisseiten. Deshalb kommt dieser Meta-Angabe eine sehr hohe Relevanz zu: Erstens kalkuliert der Google Algorithmus den Wert des Keywords darin sehr hoch. Und zweitens kann dieser Meta Title die Google User auf die Webseite locken. Der Meta Title gilt als eine der sog. low hanging fruit, da durch seine Anpassung mit einem relativ geringen Aufwand leicht ein besseres Ranking-Ergebnis erzielt werden kann.

Das trifft allerdings genau so auch auf den Page-Title (HTML-Element title) zu.

In den Beitrag ist ein Video eingebettet. Etwas verwirrend war für mich, dass in dem Video die Syntax folgendermaßen beschrieben wurde:

Screenshot der Syntax des Meta-Titles

Erstens wurde dort für das Attribut „name“ die deutsche Schreibweise „titel“ statt des englischen „title“ gewählt, was schon ungewöhnlich war, zum anderen wurde ein Teil des Titels außerhalb der umschließenden Anführungszeichen verwendet.

Zum jetzigen Zeitpunkt gehe ich davon aus, dass die Syntax falsch beschrieben wurde. War aber dann möglicherweise die ganze Beschreibung fehlerhaft?

Bei der weiteren Recherche im Internet bin ich dann auf den Artikel von Jerry West gestoßen, der mit dem Titel Meta Title Tag Explained überschrieben ist.

Er sagt:

Trust me, when speaking about Meta Title and Title Tag, there is a difference.

Im weiteren Verlauf seines Beitrags setzt sich Jerry West allerdings nur mit dem Page-Title auseinander und nicht mit dem Meta-Title.

Angela von der SEO-Agentur Six Degrees SEO hat sich auf der Seite Page Title vs. Meta Title – What’s the Difference? ebenfalls mit diesem Thema beschäftigt.

In ihrem Beitrag wird allerdings nicht so ganz deutlich, ob sie den Meta-Title, den Page-Title (also das HTML Element <title>) oder gar die Hauptüberschrift einer Seite (h1-Tag) meint.

Sie schreibt unter anderem:

Google will take bits and pieces of your meta title and display it in the search results.

Das sieht Google anders.

Auf der Webseite Meta-Tags, die Google versteht werden alle Meta-Tags explizit benannt, die Google auswertet.

Dies sind:

  • description
  • google
  • google-site-verification
  • robots

Diese Werte werden dem HTML Meta-Tag jeweils per „name“-Attribut übergeben.

Alle anderen Meta-Tags werden von Google laut eigener Aussage schlichtweg ignoriert. Dazu gehören also auch keywords und title.

Im oben genannten Artikel von Angela wird daher mit großer Wahrscheinlichkeit der Begriff Meta-Title synonym zu Page-Title verwendet. Somit ist ihr Beitrag leider auch nicht sehr hilfreich.

Dasselbe gilt auch für den deutschsprachigen Artikel von Saim Alkan mit der Überschrift Was unterscheidet Title-Tag und Meta-Title?

Er erklärt den Meta-Title folgendermaßen:

Was ist ein Meta-Title?

Der Meta-Title gehört zu den sogenannten Meta-Tags. Diese Codes schreiben Webentwickler in den Quellcode einer Website, um Suchmaschinen Zusatzinformationen zu liefern. Der normale User sieht sie nicht. Doch kaum eine Seite verwendet noch einen Meta-Title. Manche Content Management Systeme wie WordPress generieren automatisch einen aus der Überschrift des Beitrags.

Jürgen erwähnt einen neuen Aspekt, nämlich den, dass verschiedene CMS automatisch einen Meta-Title generieren. Das ist mir neu. Möglicherweise mit einem speziell dafür programmierten Plug-In.

Offzielle Informationen des W3C

Bleibt am Ende, mal beim W3C vorbeizuschauen und sich dort die offiziell erlaubten Attribute anzusehen.

Das W3C liefert im Dokument HTML5 – A vocabulary and associated APIs for HTML and XHTML eine Liste mit allen standardmäßig unterstützten Werten für das Name-Attribut des Meta-Elements.

Die zulässigen Werte sind:

  • application-name
  • author
  • description
  • generator
  • keywords

In dieser Liste ist der Wert title nicht enthalten.

Es steht aber jedem frei, dem W3C weitere Werte zur Aufnahme in die Spezifikation vorzulegen. Dafür gibt es die Webseite MetaExtensions.

Aber auch in dieser Liste ist der Wert title nicht eingetragen.

Meta-Title verwenden oder nicht?

Ich habe den Eindruck gewonnen, dass an diesem mysteriösen Meta-Title rein gar nichts dran ist. Offensichtlich wird es im Internet meistens synonym für den Seitentitel verwendet, der sehr wichtig ist.

Beim W3C findet man keine Quellen für die Existenz dieses Wertes. Natürlich kann jeder in seine HTML-Datei beliebige Attribute zum Meta-Element hinzufügen und diese möglicherweise durch eigene Programme auswerten.

Ich rate von der Nutzung des Meta-Titles ab. Für die Suchmaschinenoptimierung einer Website ist der Wert nutzlos, da Suchmaschinen den Wert nicht bei der Berechnung der Platzierung in den Suchergebnislisten berücksichtigen.

Für den Besucher der Website ist der Wert nutzlos, weil er ihn nur dann zu Gesicht bekommt, wenn er sich gezielt den HTML-Sourcecode ansieht.

Gravierende Nachteile gibt es zwar nicht, wenn man den Wert dennoch einsetzt, aber die Ladezeit der Webseite wird durch die zusätzlichen Bytes geringfügig verlängert.

]]>
http://sevke.biz/2014/07/08/meta-title-oder-page-title/feed/ 0 3486
Google entfernt Autoren-Bilder http://sevke.biz/2014/06/26/google-entfernt-autoren-bilder/ http://sevke.biz/2014/06/26/google-entfernt-autoren-bilder/#respond Thu, 26 Jun 2014 13:57:04 +0000 http://sevke.biz/?p=3474
Weiterlesen... »]]>
Screenshot des Google Snippet mit Author Kennzeichnung

Der Schmaschinen-Riese Google hat sich entschlossen, die testweise eingeführten Autoren-Porträts in den SERPs in Zukunft nicht mehr anzuzeigen. (Lesen Sie auch meinen älteren Artikel Google und die Reputation von Autoren zu diesem Thema.)

Angeblich hätten sich die Klickraten durch die Autoren-Bilder nicht wesentlich verändert, so argumentiert Google.

Ich persönlich bin der Meinung, dass die Autoren-Bilder durchaus den Blick des Suchenden auf sich gezogen haben.

Ein weiterer Grund sei die Vereinheitlichung und Vereinfachung der Anzeige der Suchmaschinen-Ergebnisse auf den verschiedenen Endgeräten wie PC, Notebook, Tablet und Smartphone.

Die Erwähnung des Autors wird nun nicht völlig aus den Suchergebnissen eliminiert, sondern lediglich das Autoren-Bild.

Google Snippets in Zukunft ohne Autoren Porträt

Wenn Sie sich die oben angegebene Informations-Seite von Google in englischer Sprache ansehen, bekommen Sie ein Beispiel dafür, wie es in Zukunft aussehen wird. Der Name des Autors steht links neben dem Seitentitel, aber das Porträt fehlt eben.

Momentan werden die Autoren-Bilder noch in den SERPs angezeigt, aber schon in den nächsten Tagen werden sie wohl entfernt werden.

]]>
http://sevke.biz/2014/06/26/google-entfernt-autoren-bilder/feed/ 0 3474
Joomla Roadmap wieder geändert http://sevke.biz/2014/06/09/joomla-roadmap-wieder-geaendert/ http://sevke.biz/2014/06/09/joomla-roadmap-wieder-geaendert/#respond Mon, 09 Jun 2014 16:18:16 +0000 http://sevke.biz/?p=3456
Weiterlesen... »]]>
Joomla! Logo

Die alten Long Term Support (LTS) und Short Term Support (STS) Versionen gibt es ab sofort nicht mehr. Stattdessen wird in jeder Hauptversion die lezte Nebenversion mindestens zwei Jahre lang unterstützt.

Somit ist eine x.5 Version auch nicht mehr die quasi ausgereifte Endversion einer Serie. Stattdessen wird, wie allgemein üblich, nun nach dem System Hauptversion.Nebenversion.Patch gezählt, also zum Beispiel Version 3.3.1.

Interessant ist, dass der Entwicklungszyklus neu definiert wurde. Es gibt nun vier Phasen:

  • Phase 1: Entwicklung, mindestens 2 Jahre
  • Phase 2: Freigabe
  • Phase 3: Ständige Verbesserung, Pflege und Wartung
  • Phase 4: Anwenderunterstützung, 2 Jahre

Dabei schließt sich die Support-Zeit von zwei Jahren entweder an die Freigabe an oder richtet sich nach der letzten Nebenversion, die nach der Freigabe veröffentlicht wird. So kann die Lebensdauer einer Version sehr wahrscheinlich länger als 4 Jahre betragen.

Die aktuelle Version 3.3.0 wird also auf jeden Fall die nächsten zwei Jahre überleben und unterstützt werden. Sollten weitere Nebenversionen folgen, so verlängert sich der Support-Zeitraum entsprechend, wird mit anderen Worten wieder auf zwei Jahre zurückgesetzt.

Support gibt es immer ausschließlich für die letzte freigegebene Nebenversion einer Hauptversion.

Wichtig ist auch, dass Updates von einer Hauptversion auf eine andere nur dann möglich sind, wenn man innerhalb des Hauptversionszweiges zunächst alle Updates bis zur letzten Nebenversion durchgeführt hat. Von dort kann dann auf die jeweils letzte Nebenversion des nächsten Hauptversionszweigs migriert werden.

Die aktuelle Versionsplanung von Joomla:

  • Version 3.4: 15. Juli 2014
  • Version 3.5: 15. September 2014
  • Version 3.6: 15. November 2014
  • Version 3.7: 15. Februar 2015
  • Version 3.8: 15. April 2015
  • Version 3.9: 15. Juni 2015
  • Version 3.10: 15. August 2015
  • Version 3.11: 15. Oktober 2015

Für die noch immer aktuelle Version 2.5 ist das Ende des Support-Zeitraums für Dezember 2014 geplant. Es wäre also sinnvoll, innerhalb des nächsten halben Jahres auf die Version 3.x umzusteigen.

Obwohl der Update-Prozess von Joomla selbst normalerweise keine Herausforderung mehr darstellt, sollte vorher die Kompatibilität der verwendeten Templates und Extensions sichergestellt werden.

Auch eine Version 4.0 wird es geben. Dazu gibt es aber noch keine Planung. „Irgendwann 2015/2015“, heißt es offiziell.

]]>
http://sevke.biz/2014/06/09/joomla-roadmap-wieder-geaendert/feed/ 0 3456
Joomla Version 3.3 verschiebt Roadmap 2016 http://sevke.biz/2014/02/23/joomla-roadmap-releaseplanung/ http://sevke.biz/2014/02/23/joomla-roadmap-releaseplanung/#respond Sun, 23 Feb 2014 15:02:49 +0000 http://sevke.biz/?p=3448
Weiterlesen... »]]>
Joomla! Logo

Das Entwicklerteam hat sich entschlossen, vor der geplanten LTS Version 3.5 eine zusätzliche Version 3.3 einzuschieben. Diese Kurzzeitversion ist für April 2014 geplant.

Damit verschieben sich alle folgenden Versionen um 6 Monate. Die Roadmap ändert sich entgegen dem im letzten Jahr veröffentlichten Plan also wie folgt:

  • Version 2.5: März 2012 (LTS Version)
  • Version 3.0: September 2012
  • Version 3.1: März 2013
  • Version 3.2: September 2013
  • Version 3.3: April 2014
  • Version 3.5: September 2014 (LTS Version)
  • Version 4.0: März 2015
  • Version 4.1: September 2015
  • Version 4.2: März 2016
  • Version 4.5: September 2016 (LTS Version)

Ab Version 3.3 wird PHP 5.3.10 vorausgesetzt. Vor einem Update sollten Sie also unbedingt mit Ihrem Hoster abklären, ob PHP 5.3.10 zur Verfügung steht.

]]>
http://sevke.biz/2014/02/23/joomla-roadmap-releaseplanung/feed/ 0 3448
SEO Erstanalyse http://sevke.biz/2013/08/05/seo-erstanalyse/ http://sevke.biz/2013/08/05/seo-erstanalyse/#respond Mon, 05 Aug 2013 05:26:40 +0000 http://sevke.biz/?p=3332
Weiterlesen... »]]>
Wegweiser zu besserer Sichtbarkeit im Internet
Sie wissen bereits, dass Sie die Sichtbarkeit Ihrer Website im Internet erhöhen wollen?

Dann kennen Sie Ihr Ziel!

Um dorthin zu gelangen, müssen Sie wissen, wo Sie aktuell mit Ihrer Website in Bezug auf Suchmaschinen stehen.

Den aktuellen Status erfahren Sie mit Hilfe einer SEO-Erstanalyse.

In einem 20-seitigen Dokument erfahren Sie

  1. Allgemeine technische Informationen zu Ihrer Website
  2. Hinweise zur Benutzerfreundlichkeit
  3. Analyse der On-Site Faktoren
  4. Analyse der On-Page Faktoren
  5. Analyse der Off-Site Faktoren
  6. Keyword Analyse
  7. Analyse Ihres Social Media Engagements
  8. Konkurrenzanalyse

Alle Analysen zeigen Schwachstellen auf und enthalten bereits erste Handlungsempfehlungen.

Mit Hilfe des Analyse-Reports sind Sie in der Lage, Optimierungspotenziale zu bewerten und umzusetzen oder umsetzen zu lassen.

Bitte nehmen Sie Kontakt über E-Mail zu mir auf, wenn Sie an einer SEO-Erstanalyse interessiert sind.

]]>
http://sevke.biz/2013/08/05/seo-erstanalyse/feed/ 0 3332