Searchmetrics Summit 2017 – Recap

Das erwartet euch in diesem Artikel

  • Wer hat alles auf dem Summit gesprochen?
  • Was waren die wichtigsten Infos aus dem Expert Track?
  • Was haben wir gelernt?

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.

Foto: Willkommen beim Searchmetrics Summit

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

Foto: Welcome Note beim Searchmetrics Summit

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

Foto: Keynote von Marcus Tober beim Searchmetrics Summit

Abb. 3: 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.

Foto: Die Moderatoren des Expert Track

Abb. 4: 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 (https://twitter.com/igrigorik). 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 stelle 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 Spalsh Screen, bis sich das Programm öffnet. Und dann kann man genau zwei Dinge tun:

  • ein Bild öffnen
  • eine neue Datei erstellen

Ist das mit eurer Webseite genauso, dann könnt ihr 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.

Foto: Bartosz Góralewicz auf der Bühne

Abb. 5: 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

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

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 Site Speed 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 ihr das erste Byte auch richtig nutzt. Außerdem ist hier auch der Serverstandort entscheidend.

Doch was könnt ihr insgesamt tun, um euren Pagespeed zu verbessern? Bastian hat ein paar erfolgversprechende Methoden zusammengetragen.

  1. Verringert die Anzahl der Requests, indem ihr JavaScript und CSS zusammenfasst und spart.
  2. Optimiert die Bilder und spart durch bessere Kompression spürbar bei den Dateigrößen. Die richtige Kompression solltet ihr unbedingt im Editoren-Prozess einbinden, sonst sind nach sechs Monaten keine Bilder mehr optimiert. Nutzt dafür Photoshop oder TinyPNG/TinyJPG als Plugin für WordPress.
  3. Nutzt Asynchrone Request, wo es nur möglich ist: aus <script src=“javascript.js“ /> mach <script async src=“javascript.js“ />
  4. Verzichtet auf Webfonts oder nutzt den Fontloader (GitHub Link) als Workaround.
  5. Nutzt das extrem hilfreiche Prefetching & Pre-Rednering inklusive pre-connecting für HTTPS.
  6. Steigt auf HTTP/2 um – aber Achtung! Denkt 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 ihr diese Dinge implementiert habt, dann wollt ihr aber sicher herausfinden, wie gut euer 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).

Ihr könnt außerdem einmal Lighthouse ausprobieren. Dies ist ein neuer Bestandteil der Chrome Developer Tools. Wichtig ist aber vor allem eines: Setzt ein verlässliches Monitoring auf in optimiert dieses fortlaufend. Denn einmal optimiert heißt nicht, dass es immer gut bleibt.

Und wenn ihr das alles aufgesetzt habt, ist die Frage, was ihr damit messen solltet. Konzentriert euch am besten auf den First Meaningful Paint sowie die Time to Interactive. Dann könnt ihr mit dem PerformanceObserver in Google Analytics die Performance tracken (dieser muss vor allen anderen Skripten & Stylesheets geladen werden). Optimiert außerdem für den Critical Rendering Path – Critical (GitHub Link) hilft euch dabei.

Takeaways

  1. SEO: verbündet euch mit dem UX-Team, so bekommt ihr ggf. Ressourcen für Optimierungen.
  2. Macht die Performance messbar.
  3. Optimiert für den Critical Rendering Path (sichtbarer Bereich mit inline CSS).
  4. Nutzt wenn möglich Preload und asynchrones Laden.
  5. Löst euch vom Overhead (JavaScript, CSS, Requests).

Und hier findet ihr die Slides: http://pa.ag/sme17speed

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
Foto: Björn Beth auf der Bühne

Abb. 6: 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.

Verbindet euch zudem mit den UX-Designern. So seht ihr schneller, was sich ändern wird. Lasst euch außerdem einen Zugang zu den Ticketing-Systemen geben. So seht ihr, was die Entwickler aktuell tun und noch zu tun haben.

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

  1. Der JavaScript Relaunch:

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

  1. HTTPS-Migration

Achtet 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[…].Denkt daran, die Disavow Datei für die HTTPS-Proerty hochzuladen und die Sitemaps zu erstellen. Nutzt logrunner.io für die realtime Log Analyse.

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

Takeaways

  1. Hauptursache für Relaunch-Fails ist schlechtes Projektmanagement.
  2. Nutzt das RASCI Modell.
  3. Prüft alles vor dem Relaunch.

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.

Foto: Christian Olivera auf der Bühne

Abb. 7: 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

  1. Nutzt AMP nur, wenn ihr es wirklich braucht (Anm. d. Verf.: Die Frage ist allerdings, welchen Einfluss der SEO überhaupt auf diese Entscheidung hat).
  2. AMP Analytics-Daten sind nicht verlässlich.
  3. Die oben genannte Lösung solltet ihr umgehend implementieren.
  4. Folgt 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

Foto: Gianna Brachetti-Truskawa auf der Bühne

Abb 8: 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ählt eine Auszeichnungsmöglichkeit:
    • im HTML Quellcode
    • in der XML-Sitemap
    • 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

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

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) sukzessive erweitert werden. Eine Fallstudie: durch den Umstieg auf SSR (Server Side Rendering, s.o) konnte SPON eine Traffic Steigerung von 30% erzielen. Baut eure 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

  1. Die großen technischen Anforderungen von Früher™ gelten (offiziell) nicht mehr.
  2. Für News ist möglichst reines HTML eine Grundvoraussetzung.
  3. Jeder kann jetzt bei Google News akkreditiert werden.
  4. 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 Marketing. 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. Ihr solltet 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

  1. NIEMAND spricht so schnell wie Jono, ohne sich an seiner eigenen Zunge zu verschlucken. #impressive
  2. Der Kunde verschwindet zunehmend aus dem gewohnten Marketingprozess.
  3. 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!

Über den Autor

Sebastian Adler

Redakteur
Den Einstieg in die Online-Marketing-Welt fand ich 2011 bei Barketing im Offpage-Bereich. 2013 wechselte ich dann zu Searchmetrics in die SEO-Beratung, um dort den Kunden bei ihren SEO-Strategien mit Rat und Tat zur Seite zu stehen. Nach einem kurzen Ausflug ins Produktmanagement führte mich mein Weg im Sommer 2017 (zurück) zu LEAP/, wo ich nun wieder als SEO-Consultant tätig bin.
Kommentare