Searchmetrics Summit November 2017 – Der LEAP/ Recap

Der Searchmetrics Summit fand am 21.11.2017 zum zweiten Mal in der Kulturbrauerei statt. Wir waren vor Ort und geben hier unsere Eindrücke wieder.

Grundsätzlich ist zu sagen: Die Veranstaltung war wirklich gut organisiert, das Essen und der Service waren super. Der obligatorische Promotion-Bereich war vorhanden, aber sehr unaufdringlich gestaltet. Das einzige Manko: In der großen Halle wollte es bei winterlichen Temperaturen nicht so richtig warm werden.

Doch dank vieler bekannter Gesichter aus der SEO-Szene und toller Marketing-Gags (Grußkarten mit SEO- und Content-Sprüchen, die man ausfüllen und von Searchmetrics verschicken lassen konnte) fiel dieses eine kleine Problem nicht ins Gewicht. Vielmehr sahen wir zahlreiche spannende Vorträge.

Ab 08:30 hieß es für die Besucher „Willkommen beim Searchmetrics Summit 2017“

Die Welcome Note wurde von Doug Bell und Daniela Neumann gehalten (ihres Zeichens VP Marketing und VP Product)

Marcus Tober sprach über die Veränderung von allgemeinen hin zu branchenspezifischen Ranking-Faktoren

Expert-Track

Wir haben uns diesmal komplett auf den Experten-Track konzentriert. Hier gab es insgesamt sieben Vorträge, die zum ersten Mal alle auf Englisch gehalten wurden, um dem internationalen Publikum gerecht zu werden. Inhaltlich waren die Themen JavaScript, Pagespeed und AMP allgegenwärtig.

Loben wollen wir an dieser Stelle auch die Moderation der Bühne durch Monika Faseth und Björn Beth aus dem Searchmetrics Professional Services Team. Nun stürzen wir uns aber in die einzelnen Vorträge.

Das Moderatoren-Team des Expert-Track Monika Faseth und Björn Beth

Bartosz Góralewicz: „Advanced Technical SEO – in-depth look into JavaScript SEO and the technology behind Googlebot“

Der Ausgangspunkt dieses Vortrags war sein Experiment zur Indexierbarkeit verschiedener JavaScript Frameworks. Dabei hat Bartosz einen Denkfehler bemerkt und versucht zu verstehen, wie die Ergebnisse des Experimentes zustande kamen. Die Basis für sein Vorhaben, das Experiment neu aufzurollen und zu überdenken, war dabei folgende:

Wir verstehen die Technik hinter Googles Crawling-Aktivitäten nicht.

Ein gutes Beispiel für die Probleme mit JavaScript ist hulu.com. Diese erlitten einen großen Visibility-Drop, nachdem sie einen JavaScript-Relaunch durchgeführt hatten. Der Grund dafür war, dass die Inhalte für den Google Bot nicht sichtbar waren.

Bartosz erzählte in anschaulicher Weise, welche Hintergrundinformationen uns eigentlich fehlen, wenn wir über Crawling- und Indexing-Probleme sprechen. Daher suchte er Hilfe bei verschiedenen Google-Ansprechpartnern und stellte fest, dass John Mueller (quasi die Referenz für Webmaster) in technischen Belangen keine große Hilfe war.

Weitaus hilfreicher war hingegen Ilya Grigorik. Dieser gab den Hinweis, dass der Google Web Rendering Service (WRS) aktuell auf Basis von Chrome 41 rendert und damit verbunden auch dessen Probleme und Beschränkungen teilt. Bartosz testete seine Experiment-Seiten dann mit einer Chrome 41 Instanz und stellte in der Console diverse Fehlermeldungen fest, die er dann debuggte.

Fun fact: das von Google ins Leben gerufene Angular2 Framework wies zu dieser Zeit einen Fehler im Quellcode auf, der dafür sorgte, dass Chrome41 und damit auch der WRS mit Angular2 erstellte Seiten nicht rendern konnte. Nach Debugging der Testseiten mit Chrome41 konnten alle JavaScript Inhalte in den Index gebracht werden.

HTML vergibt vieles, JavaScript nicht

Browser können mittlerweile auch stark fehlerhafte HTML-Dokumente interpretieren und korrigieren – doch bei fehlerhaftem JavaScript ist das nicht möglich. Gleiches gilt für den Google Bot.

Dennoch sind zu diesem Thema noch ein paar Fragen offen: Kann JavaScript das Crawlbudget negativ beeinflussen? Ja, das kann es. Denn JavaScript muss erst geladen werden – und Google wartet nicht!

Hierzu eine kleine Analogie. Bei Photoshop wartet man oft sehr lange und schaut auf den Splash Screen, bis sich das Programm öffnet. Und dann kann man genau zwei Dinge tun:

1. ein Bild öffnen
2. eine neue Datei erstellen

Ist das mit deiner Webseite genauso, dann kannst du davon ausgehen, dass sie nicht gecrawlt und indexiert wird. Denn die „TTI“ (Time to interactive) ist für Google enorm wichtig. Bedenkt daher bei euren Speed-Tests auch, dass Google HTTTP/1.1 nutzt und mit HTTP/2 noch nicht umgehen kann.

Don’t go Photoshop on Google. Lass weder Google noch deine Nutzer ewig auf eine interaktionsarme Website warten

Bartosz wies dann noch darauf hin, dass der nächste WRS voraussichtlich auf Chrome 59 basieren und im Laufe des kommenden Jahres erscheinen wird. Und nicht vergessen: Der Google Bot / WRS ist ein anderes System als Fetch and render in der Search Console.

Takeaways

• Wichtige Inhalte immer in HTML ausliefern
• JavaScript am besten server sided nutzen (entspricht auch der ursprünglichen Idee von React & Angular)
• Wenn client side JavaScript genutzt wird, dann unbedingt mit Chrome 41 debuggen sowie HTTP/1.1 im Hinterkopf behalten und aktiv lassen
• Die Inhalte müssen schnell ausgeliefert werden
• Googles Crawling und Rendering Services zu verstehen ist der einzige wirkliche Schlüssel zur Lösung von Indexing-Problemen

Mehr Infos zu JavaScript und SEO findest du in diesem Artikel.

Bastian Grimm: „International Site Speed: A Complete Guide To Super-Speed Around The World“

Der nun folgende Vortrag von Bastian Grimm war der ideale Übergang, nachdem Bartosz schon über den SiteSpeed und die damit verbundenen Schwierigkeiten gesprochen hat. Passend zum Thema raste Bastian durch seinen Vortrag, was aber hauptsächlich dem engen Zeitrahmen geschuldet war.

Die Daten aus der Search Console sind beim Thema Ladezeiten absolut unkorrekt. Eine sinnvolle KPI, um den Speed zu messen, wäre zum Beispiel die TTFB (Time To First Byte) – aber nur, wenn man das erste Byte auch richtig nutzt. Außerdem ist hier auch der Serverstandort entscheidend.

Doch was kann man insgesamt tun, um den eigenen PageSpeed zu verbessern? Bastian hat ein paar erfolgversprechende Methoden zusammengetragen:

1. Verringere die Anzahl der Requests, indem du JavaScript und CSS zusammenfässt und sparst
2. Optimiere die Bilder und spare durch bessere Kompression spürbar bei den Dateigrößen. Die richtige Kompression solltest du unbedingt im Editoren-Prozess einbinden, sonst sind nach sechs Monaten keine Bilder mehr optimiert. Nutze dafür Photoshop oder TinyPNG/TinyJPG als Plugin für WordPress.
3. Nutze Asynchrone Request, wo es nur möglich ist: aus <script src=”javascript.js” /> mach <script async src=”javascript.js” />
4. Verzichte auf Webfonts oder nutze den Fontloader (GitHub Link) als Workaround
5. Nutze das extrem hilfreiche Prefetching & Pre-Rednering inklusive pre-connecting für HTTPS
6. Steige auf HTTP/2 um – aber Achtung! Denke daran, dass der Google Bot aktuell nur HTTP/1.1 kann. Doch das Protokoll macht parallele Requests möglich und beschleunigt das Herunterladen enorm.

Wenn man diese Dinge implementiert hat, dann möchtest du aber sicher herausfinden, wie gut deine PageSpeed denn nun wirklich ist. Dabei ist das PageSpeed Insights Tool von Google keine wirkliche Hilfe. Der x/100 Score ist irreführend und die Hinweise sind zum Teil nicht erfüllbar.

Die deutlich bessere Alternative ist webpagetest.org. (Anm. d. Verf.: Der Service von Webpagetest.org kann auch als eigene Instanz auf eigenen Servern betrieben werden: GitHub Link).

Du kannst außerdem einmal Lighthouse ausprobieren. Dies ist ein neuer Bestandteil der Chrome Developer Tools. Wichtig ist aber vor allem eines: Setze ein verlässliches Monitoring auf und optimiere dieses fortlaufend. Denn einmal optimiert heißt nicht, dass es immer gut bleibt.

Und wenn du das alles aufgesetzt hast, ist die Frage, was du damit messen solltest. Konzentriere dich am besten auf den First Meaningful Paint sowie die Time to Interactive. Dann kannst du mit dem PerformanceObserver in Google Analytics die Performance tracken (dieser muss vor allen anderen Skripten & Stylesheets geladen werden). Optimiere außerdem für den Critical Rendering Path – Critical (GitHub Link) hilft dabei.

Takeaways

• SEO: Verbündet dich mit dem UX-Team, so bekommst du ggf. Ressourcen für Optimierungen
• Mach die Performance messbar
• Optimiere für den Critical Rendering Path (sichtbarer Bereich mit inline CSS)
• Nutze wenn möglich Preload und asynchrones Laden
• Löse dich vom Overhead (JavaScript, CSS, Requests)

In diesem Artikel erfährst du, wie du deinen Pagespeed optimieren kannst.

Björn Beth: „ The Big Hairy Relaunch Monster!“

Speed ist wirklich das dominierende Thema des Tages – denn auch einer der beiden Moderatoren rast durch seinen Vortrag. Er gibt dabei einen Überblick zu den Relaunch-Fehlern, die ihm am häufigsten begegnen. Die meisten davon passieren seiner Meinung nach durch schlechtes Management.

Denn ein Relaunch ist für Björn ein RASCI-Prozess. Dieser definiert für den Prozess für alle Beteiligten ihre Rollen:

• Responsible
• Accountable
• Supportive
• Consulted
• Informed

Björn Beth stellt das RASCI-Modell vor

Sind die Zuständigkeiten nach diesem Modell geklärt, kann man den sehr komplexen Prozess eines Relaunches sehr gut handhaben. Und jeder Verantwortliche („Reponsible“) sieht auch ganz klar, worum er sich hauptverantwortlich kümmern muss.

Verbinde dich zudem mit den UX-Designern. So siehst du schneller, was sich ändern wird. Lass dir außerdem einen Zugang zu den Ticketing-Systemen geben. So siehst du, was die Entwickler aktuell tun und noch zu tun haben.

Im Allgemeinen gibt es zwei große Relaunch-Arten, die zurzeit stattfinden:

1. Der JavaScript Relaunch:

Denk daran, dass Google HTML-Inhalte benötigt. renderToString() in React und AngularUniversal sind die Werkzeuge für SSR (Server Sided Rendering). Nutze außerdem Fetch and render as any bot.

2. HTTPS-Migration

Achte darauf, dass alle Ressourcen mit https referenziert werden. Ein Workaround für externe Ressourcen sind protokollrelative URLs: aus src=”http://www.facebook[…]/ mach //www.faebook[…]. Denk daran, die Disavow Datei für die HTTPS-Proerty hochzuladen und die Sitemaps zu erstellen. Nutze logrunner.io für die realtime Log Analyse.

Wichtig ist natürlich auch, dass du die klassischen Fehler beim Relaunch vermeidest. Dabei handelt es sich um das komplette oder teilweise Vergessen von Weiterleitungen, das Vergessen des Index-Managements sowie das Indexieren von Parameter-URLs.

Takeaways

• Hauptursache für Relaunch-Fails ist schlechtes Projektmanagement
• Nutzt das RASCI-Modell
• Prüft alles vor dem Relaunch

Weitere Tipps für deinen Relaunch gibt’s in diesem Artikel.

Christian Oliveira: „Why your analytics tool may be lying to you about AMP“

Aufgrund der sehr technischen Hintergründe und des kurzen Zeitrahmens ist Christian nur an der Oberfläche des Problems und der Lösung geblieben. Einen detaillierten Blogbeitrag zum Thema gibt‘s hier.

Knapp zum Problem und lösungsorientiert Christian Olivera zeigt, warum AMP und Analytics aktuell nicht gut zusammenpassen

AMP ist aktuell nicht für ein korrektes Zusammenspiel mit Analytics designed. So kann ein User unter Umständen mehr als 4 Besuche „verursachen“. Das liegt daran, dass die URL, die eine AMP-Variante enthält, bis zu vier URL-Varianten erzeugen kann: Die normale URL, die AMP-URL sowie die Cache-URLs. Und werden Seiten in sozialen Netzwerken geteilt, so werden die Nutzer direkt auf die CDN-URLs geschickt (LinkedIn macht das z.B. so).

Die Folge: alle Analytics-Daten sind schrott! Entscheidungen auf Basis dieser Daten sind nicht valide begründbar. Doch die gute Nachricht ist: es gibt fast eine Lösung und Simo Ahava hat sie in seinem Blog veröffentlicht. Damit werden fast alle künstlich erschaffenen URLs abgefangen.

Takeaways

• Nutze AMP nur, wenn du es wirklich brauchst (Anm. d. Verf.: Die Frage ist allerdings, welchen Einfluss der SEO überhaupt auf diese Entscheidung hat)
• AMP Analytics-Daten sind nicht verlässlich
• Die oben genannte Lösung solltest du umgehend implementieren
• Folge Malte Ubl und Simo Ahava, um Up-to-date zu bleiben

Im Anschluss entbrannte eine kleine Diskussion über AMP als Machtinstrument von Google, um mehr Kontrolle über den Content der Webmaster zu erhalten und die Rolle von uns als SEOs und Webmastern, die wir derartige Technologien allzu schnell annehmen und implementieren. Das Thema ist sehr interessant und hätte sicher auch im Panel diskutiert werden können. Im Q&A war leider kein Raum für eine angemessene Diskussion.

Gianna Brachetti-Truskawa: „Get it right internationally: 10 common hreflang mistakes“

Gianna hat viel Erfahrung im Umgang mit mehrsprachigen Websites und wurde begleitet von Konnilingus der Datenkrake. Auch sie hat sich stark beeilt und einige Detail-Slides geskippt, um den Zeitrahmen zu halten.

Gianna Brachetti-Truskawa startete ihre Session mit einer zentralen Frage „Wer hat eine einsprachige Website“?

Die häufigsten Fehler auf mehrsprachen Websites sind:

1. Falsche Codes – i. d. R. Land-Sprach-Kombi falsch
   1. Es muss <link rel=”hreflang” lang=”de” href=”[…]” / > oder <link rel=”hreflang” lang=”de-AT” href=”[…]” / > sein (die Groß- und Kleinschreibung ist nicht relevant)
   2. Die Region alleine funktioniert nicht
2. UK ist GB nicht UK.
3. Fehlende Annotationen – wenn keine URL hinterlegt ist, kann es nicht klappen. Wenn keine Sprache hinterlegt ist, auch nicht.
4. Relative URLs sind eine ganz schlechte Idee
5. Missing confirmation Links – immer auch selbstreferenziell auszeichnen!
6. Mehr als eine URL pro Sprach-Region zerstört das gesamte Konstrukt
7. Die kombinierte Auszeichnung muss immer zu 100 % synchronisiert sein – und das geht meistens schief. Wähle eine Auszeichnungsmöglichkeit:
   1. im HTML Quellcode
   2. in der XML-Sitemap
   3. im HTTP-Header
8. Hreflang und Canonical – Gianna empfiehlt, es nach Möglichkeit gar nicht zu kombinieren, es aber zumindest auf die kanonischen URLs zu beschränken
9. Hreflang in Verbindung mit noindex oder Robots.txtx Sperre

Takeaways

• Als monolinguale Seite kann man mit dem Hreflang verschiedene Regionen targeten
• Sub-Regionen können funktionieren: teste es
• Strukturelle Unterschiede zwischen Sprachvarianten sind zulässig, der Umfang muss individuell getestet werden
• Daumenregel: wenn eine URL nicht in eine Sitemap dürfte, darf sie auch kein Hreflang bekommen

Wie du das Hreflang richtig nutzt, erfährst du hier.

Insa Winter & Raphael Raue: „Google News Optimization – Basics, AMP and Timing“

Dieser Vortrag bot einen Einblick in eine komplett andere SEO-Welt. Doch auch hier sind wieder AMP und Speed ein zentrales Thema. Raphael spricht dabei über die Voraussetzungen, Insa über das Timing.

Voraussetzungen

Vor drei Jahren hat Google seinen News-Service für Publisher aller Couleur geöffnet. Das Impressum muss zeigen, dass mehrere Autoren publizieren – die Zulassung erfolgt noch immer manuell.

News können sich jetzt auch zum Brand-Building eignen. JavaScript ist in diesem Umfeld jedoch ein Killer – nutzt wenn möglich lieber reines HTML. Außerdem dürfen die Inhalte nicht fragmentiert sein. Der Content kann dann später (nach dem Erhalt des News-Rankings) sukzessiv erweitert werden. Eine Fallstudie: durch den Umstieg auf SSR (Server Side Rendering, s.o) konnte SPON eine Traffic Steigerung von 30 % erzielen. Bau deine Artikel also so, wie sie in AMP konzipiert wären.

Timing

Breaking News müssen natürlich sofort raus, aber alles andere sollte veröffentlicht werden, wenn es die Leser interessiert. Kleine Publisher könne ihre Inhalte verzögert veröffentlichen, um dann in die News zu gelangen, wenn der Wettbewerb nicht mehr so groß ist. Täglich wiederkehrende News müssen aber in jedem Fall on time bedient werden.

Takeaways

• Die großen technischen Anforderungen von Früher™ gelten (offiziell) nicht mehr
• Für News ist möglichst reines HTML eine Grundvoraussetzung
• Jeder kann jetzt bei Google News akkreditiert werden
• News zum Brandbuilding sind super – einfache Pressemeldungen aber nicht

Jono Alderson: „Digital marketing is dead: survival tips for what comes next“

Hier nur eine Auswahl von Jono’s sehr interessantem und unterhaltsamen Ausblick auf die Zukunft des Marketings. Zunächst ist er sich sicher, dass IPA (intelligent personal Assistants) die Auswahl- und Entscheidungsphase verändern werden – und damit auch den gesamten Marketing-Prozess.

Große Brands haben jedoch, wie so oft, das Problem, dass sie für solch tiefgreifende Veränderungen zu schwerfällig sind. Und zu allem Überfluss verstehen sie diese Veränderungen nicht als wichtigen Prozess. Unternehmen müssen das, was sie tun, von dem, was sie sind, lösen und die Fähigkeit zur Wandlung entwickeln. Ein gutes Beispiel ist Nokia, das vom Schuhhersteller zum Handy-Giganten und wieder zum Schuhhersteller wurde.

Die Beziehung besteht zwischen Konsument und Brand – nicht zwischen Konsument und Produkt. Du solltest also die wichtigsten Bedürfnisse der Kunden bedienen – egal, wo diese sich verorten lassen. Macht smarte Sachen – einfache Pattern-Matching-Jobs werden die Maschinen übernehmen.

Takeaways

• NIEMAND spricht so schnell wie Jono, ohne sich an seiner eigenen Zunge zu verschlucken #impressive
• Der Kunde verschwindet zunehmend aus dem gewohnten Marketingprozess
• Als Brand muss man den Kunden ca. 6 Monate vor seiner Entscheidungssituation erreicht haben

Fazit Expert-Track

Die sieben Beiträge des Experten-Track waren inhaltlich wirklich stark – und auch die optische Aufbereitung war mehr als stimmig. Aber gerade weil die Themen so interessant waren, wäre es schön gewesen, etwas mehr zu erfahren. Es könnte also nicht schaden, die einzelnen Slots in Zukunft zu verlängern.

Insgesamt war der Searchmetrics Summit eine mehr als gelungene Veranstaltung, auf der sicher alle Anwesenden ein paar neue Inspirationen aufgeschnappt haben. Nach allem, was wir gehört haben, galt dies auch für den parallel laufenden Management-Track. Wir freuen uns schon auf den für 2018 geplanten Summit in London!