SEO Newsletter #10

JavaScript ist cool – verlangsamt aber auch.

Die Ladezeit von Websites wird meist durch Bilder in die Höhe getrieben. Ein Bild, das nur in 200 x 200 px angezeigt wird, aber dennoch in 20000 x 16000 px hochgeladen wird, hat halt trotzdem ein paar Megabyte.

Oft vergessen wird bei der Seitengeschwindigkeit jedoch JavaScript. Die Dateigrößen sind meist akzeptabel. Aber die Ausführung benötigt insbesondere mobil Ressourcen. Die Lösung: unnötige Scripts minimieren oder entfernen. Gerade manches Framework wird oft nur für wenige Funktionen eingebaut und verursacht einen massiven Overhead. Auf manches an sich cooles Feature verzichtet man also besser.

Laut einem ausführlicheren Artikel auf Medium hat die durchschnittliche Website 350KB JavaScript. An sich nicht viel – trotzdem braucht dieses dann 15 Sekunden(!) zur vollen Interaktionsfähigkeit.

Da kann man doch nur sagen: „Uff!“ Auch Google Page Speed Insights misst dies und gibt eine entsprechende Warnung aus – einmal unter dem generellen Rendering und einmal unter Diagnostics > Minimize main-thread work sowie Reduce JavaScript execution time.

Mögliche Lösungen beinhalten Server-Side Rendering oder eine Hybrid-Lösung.

JavaScript wird langsamer verarbeitet

Apropos JavaScript: Dass Google dieses verarbeiten kann, weiß man inzwischen. In einem Webmaster-Hangout vom Dezember 2018 hat Johannes Müller von Google aber noch einmal hervorgehoben, dass diese Verarbeitung von JavaScript mehr Ressourcen benötigt als reines HTML.

Daher findet dies oft zeitverzögert statt. Ist für bestimmte Inhalte also Aktualität wichtig (z. B. News), ist JavaScript eine schlechte Wahl. Dies gilt aber auch für Mikrodaten, die via Tag Manager ausgeliefert werden. Sinnvoller ist der direkte Einbau in die Website oder der Einsatz von Dynamic Rendering. Ansonsten muss man mit einer Verzögerung von mehreren Tagen rechnen.

Videoreihe von Google

Gerade weil JavaScript so häufig eingesetzt wird und immer wieder diverse Probleme verursacht, hat Google eine Video-Reihe zu JS und SEO begonnen. In kurzen Happen (bisher 3-6 Minuten) werden Themen behandelt wie die Indexierung von JS durch Google, wann JS für SEO relevant ist, was man beachten sollte und wie man JS-Sites für Search debugt.

Structured Data wächst

Schema.org und strukturierte Daten wachsen weiter. Eine aktuelle Übersicht mit den entsprechenden Ausspielungsmöglichkeiten findet sich hier. Dabei ist nicht jede Auszeichnungs-Möglichkeit für jeden geeignet – ein Blick lohnt aber.

How to How To

Eine der neuesten Auszeichnungsmöglichkeiten betrifft How To Artikel. Hierbei werden die einzelnen Schritte ausgezeichnet. Eine Darstellung in der Suche kann dann so aussehen:

Hinweise in der Search Console

Dass Google diese Markups durchaus forciert ist offensichtlich. Es wundert daher auch nicht, dass sich in der neuen Search Console inzwischen ein Bereich findet, der Markup-Fehler listet, konkret für Produktauszeichnungen.

Für Featured Snippes nicht notwendig

Allerdings ist es ein Irrglaube, dass man strukturierte Daten dieses Markup benötigt. Es ist allerdings durchaus hilfreich. Und für Rich Results braucht man es wiederum. Aber was ist der Unterschied?

• Featured Snippets sind zusammengefasste Antworten, meist oben auf einer Suchergebnisseite. Diese benötigen KEINE gesonderte Auszeichnung.
• Rich Snippets erweitern alle Suchergebnisse, z. B. mit Preis, Verfügbarkeit, Events oder einer Breadcrumb. Diese benötigen entsprechende Auszeichnungen.

Zwar können Roboter und Suchmaschinen auch anders vorhandene Daten interpretieren, aber Mikrodaten machen es ihnen einfacher.

Bing will nur noch explizit übermittelte URLs indexieren

Ist eine URL gut verlinkt, kommen die Suchmaschinen normalerweise von selbst und verarbeiten diese. Das will Bing nun anders machen und setzt auf manuelle Einreichung. In den Bing Webmaster Tools können nun bis zu zehntausend URLs pro Tag eingereicht werden und nur diese werden noch indexiert.

Ob das mehr Qualität bringt durch eine explizite Übermittlung? Ich vermute eher, dass passende Script entstehen werden. (Quelle)

Google Search Console: Zuordnung auf Canonicals

Ein Canonical ordnet mehrere URL-Varianten auf eine repräsentative, kanonische URL zu, die Google bevorzugt anzeigen soll. Google hat nun angekündigt, künftig auch in der Search Console die Daten für die jeweils kanonisierte URL anzuzeigen und nicht etwa auf verschiedene Varianten-URLs zu zersplittern. Das betrifft beispielsweise auch Varianten für Desktop vs. Mobile (m.xxx.tld Domains) oder AMP-Seiten, die nun zusammengefasst werden. Stichtag ist der 10. April 2019. (Quelle)

Chrome: Direkt zu Textstellen verlinken

Seit langem empfehle ich, auf Inhaltsseiten und Artikeln Inhaltsverzeichnisse zu nutzen, die direkt zu den Zwischenüberschriften verlinken. Dies ermöglicht die Anzeige von direkten Verweisen auf Googles Suchergebnisseite, inzwischen auch von kleineren „Sitelinks“, welche den Nutzer direkt zum passendsten Absatz bringen.

Google hat nun für kommende Chrome-Versionen das ScrollToText-Feature angekündigt, dass Links zu beliebigen Textstellen vom Browser aus möglich sein sollen. Inzwischen ist dies bereits in Chrome Canary verfügbar. Damit könnte auch zu einem Absatz einer Seite gelinkt werden, die keine Sprungmarken gesetzt hat. (Quelle)

Prognose: Das dürfte sich bald auf den Suchergebnisseiten widerspiegeln. Andere Browser werden entsprechend nachziehen.

Website-Relaunch? Lieber kleinere Änderungen

Noch immer ist es so, dass alle X Jahre ein Relaunch ansteht. Und wenn man sich dann endlich aufgerafft hat, möchte man gleich alles auf einmal erledigen: Neuer Inhalt, neue URL-Struktur, neue Bildwelten … Vermutlich weil man (nicht ganz zu Unrecht) davon ausgeht, dass man anschließend wieder in einen mehrjährigen Digitalschlaf verfällt.

Meine Meinung ist klar: Konstante Evolution von Websites ist dem Relaunch überlegen. Auch Google empfiehlt, nicht alles auf einmal zu ändern. Und das verhindert viele Probleme. Denn ändern sich zeitgleich Domain, URLs, Titles und Metadaten, kann man kaum den Überblick behalten. Redirects einzurichten wird schwer und im Zweifelsfall können auch Suchmaschinen die alten Inhalte nicht mehr finden. Geht man hingegen in einzelnen Schritten vor, minimiert man das Fehlerrisiko und kann es gleichzeitig gut verorten.