Das erwartet dich in diesem Recap:
- Wie war die Veranstaltung organisiert?
- Welche Speaker haben uns am meisten begeistert?
- Welche Vorträge blieben hinter den Erwartungen zurück?
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.
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.
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:
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.
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
Mehr Infos zu JavaScript und SEO findest du in diesem Artikel.
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:
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
In diesem Artikel erfährst du, wie du deinen Pagespeed optimieren kannst.
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:
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:
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.
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
Weitere Tipps für deinen Relaunch gibt’s in diesem Artikel.
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.
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
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 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.
Die häufigsten Fehler auf mehrsprachen Websites sind:
Takeaways
Wie du das Hreflang richtig nutzt, erfährst du hier.
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
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
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!