SEO Qualitätssicherung: Wie verhindert man typische SEO-Fehler vor einem Release?

Ein noindex auf der Startseite

Es ist der letzte Tag im Oktober und ich komme etwas müde im Büro an: Hände-Abklatsch zur Begrüssung bei allen (es ist das Jahr 2018) - Kaffee - Arbeitsplatz - Laptop auf - Mails - Slack - To-Dos für den Tag. Ich höre, dass der A/B-Test auf der Landingpage erfolgreich war und rufe unsere Startseite aus. Version B also. Dann bemerke ich etwas aus meinem Augenwinkel. Oben in meiner Erweiterungsleiste des Browsers: Ein ROTES Dreieck.

Ich klicke die Erweiterung an und traue meinen Augen nicht: Unsere Startseite trägt stolz das Robots-Meta-Tag “noindex”. Sprich: Die Homepage, welche eine der Traffic-stärksten Seiten ist, soll nicht mehr von Suchmaschinen indexiert werden.

(Dass das Canonical-Tag nicht korrekt ist kommt noch dazu.)

Software Testing für SEO Qualitätssicherung

Einige Wochen vorher sind wir an der Konferenz BrightonSEO und hören den Vortrag von Mike King zum Thema Software Testing für SEO. Er erklärt, wie man kritische SEO-Fehler mit SEO Qualitätssicherung bereits vor dem Release verhindert.

Uns ist klar: das ist die Lösung für unser Problem. Das “noindex”-Tag auf der Startseite war nämlich kein Einzelfall. Immer wieder kam es zu Fehlern, welche nach dem Release rückgängig gemacht werden mussten.

Grob können die bisherigen Fehler in zwei Gruppen aufgeteilt werden:

1. Kritische SEO-Fehler: Falsch gesetzte HTML-Tags führen zu Problemen

• Falsches Robots-Meta-Tag
• Falsche Canonical-Tags
• Falsche interne Links

2. Performance: Bereits umgesetzte Verbesserungen werden nach einem Release überschrieben

• Bilder sind nach dem Release nicht mehr komprimiert
• Grösser werdende JS und CSS Ressourcen

Wir haben also zwei Ziele: Automatisierte Tests, um kritische SEO-Fehler frühzeitig zu erkennen und Tests/Monitoring, um die Performance zu wahren.

Ziel 1: Automatisierte Tests, um SEO-Fehler frühzeitig zu erkennen

Website Setup

Die Webseite von Movu ist mit einigen hundert indexierten Seiten sehr übersichtlich. Allerdings sind die WordPress Apps hinter einem Reverse Proxy, was eine der Hauptfehlerquellen der Indexierungsprobleme war.

Neben den WordPress Apps ist auch die Homepage fehleranfällig, da dort jeweils A/B/x-Tests laufen sollen.

Planung & Test-Setup

Um SEO-Tests in die QA-Pipeline einzubauen gibt es zwei Ansätze:

1. Abgleich der Staging-Version mit der Live-Version
2. Tests für die Staging-Version basierend auf definierten Test-Cases

Wir entscheiden uns für Option 2 aufgrund des bestehenden QA-Setups.

Rückblickend waren die meisten SEO-Fehler systematisch. Sprich, sie betrafen jeweils alle Seiten eines Seitentyps. Pragmatisch definieren wir deshalb jeweils ein bis zwei Seiten pro Seitentyp, die in die Tests mit einbezogen werden.

Ein Spezialfall ist die Startseite, da hier laufend A/B-Tests laufen. Mittlerweile werden für Tests keine unterschiedlichen URLs mehr generiert. Man müsste die Test also mehrfach laufen lassen und hoffen, dass alle Versionen zu testen. Um dies besser zu steuern werden die Tests so aufgesetzt, dass über die verschiedenen QA-Server jeweils Version A oder Version B der Startseite aufgerufen wird.

Limitationen

Dieses Setup erlaubt es, schnell Test-Cases zu definieren und in die QA-Pipeline zu integrieren. Trotzdem gibt es einige Limitationen, die ich erwähnen möchte:

• Nicht alle Seiten werden getestet: Sollte es auf einer Seiten einen nicht systematischen Fehler geben, wird das trotzdem erst nach dem Release bemerkt.
• Neue Seiten werden nicht getestet: Werden neue Seiten publiziert, werden sie nicht automatisch mitgetestet. Sie müssten ebenfalls in die zu testenden URLs mit einbezogen werden.

Impact

Bei vorbeugenden Massnahmen ist nicht ganz einfach zu sagen, wie gross der Impact war. Subjektiv konnten wir aber erkennen, dass durch die enge Zusammenarbeit mit dem QA-Team ein Wissenstransfer in beide Richtungen stattfand. Das QA-Team wurde in dieser Zeit stark auf SEO-Themen sensibilisiert und konnte mögliche Problembereiche besser erkennen.

Auch gibt es seit der Umsetzung der SEO-Tests kaum mehr kritische Fixes, die nach einem Deploy angepasst werden müssen. Das nimmt allerdings bereits vor der vollständigen Umsetzung ab was auch mit dem zunehmenden Bewusstsein von Seiten des QA-Teams und den Entwicklern zusammenhängen könnte.

Ziel 2: Monitoring und Tests, um Performance zu wahren

Neben den kritischen SEO-Fehlern möchten wir die Website-Performance, in welche wir viel investiert haben, wahren. Inspiriert hat uns hier vor allem Maria Camanes mit ihrem Vortrag zum Thema Performance-Kultur innerhalb einer Organisation.

Wie misst man Website-Performance?

Eine der grössten Herausforderungen ist die Definition einer guten Performance. Welche Metriken nimmt man, um Seitenladezeit als gut oder schlecht einzustufen? Verlässt man sich auf synthetische Tests, welche einen Seitenaufruf auf einem bestimmten Gerät simulieren? Oder nutzt man echte Nutzerdaten?

Um die Performance auf den Staging-Servern zu testen, kommen nur synthetische Tests in Frage. Echte Nutzerdaten gibt es hier nicht. Nutzerdaten sollen aber ins Monitoring miteinbezogen werden um die tatsächliche Performance zu beobachten.

Messwerte

Um die Performance möglichst gut abzubilden, möchten wir sowohl technische, visuelle als auch interaktive Metriken messen.

• Technisch: Wir wählen Time to First Byte (TTFB) um zu messen, ob der Web Server zu langsam auf Anforderungen reagiert.
• Visuell: Visuelle Metriken versuchen zu quantifizieren, wie schnell es aussieht dass eine Seite lädt. Die Metrik Largest Contentful Paint (LCP) misst zum Beispiel die Renderzeit des grössten im Fenster sichtbaren Bild- oder Textblocks.
• CLS: Während des Projekts kündigt Google die Einführung der Core Web Vitals an (Mai 2020). Damit rückt auch die Metrik Cumulative Layout Shift (CLS) auf unseren Radar. CLS misst die visuelle Stabilität und quantifiziert unerwartete Layout Shifts. Ein typisches Beispiel sind Anzeigen, welche erst später geladen werden und die Elemente auf der Seite nochmals verschieben.
• Interaktiv: Als interaktive Metrik für synthetische Tests nehmen wir Time to Interactive (TTI), welche aufzeigt, ob man eine Seite benutzen kann.

Zusätzlich möchten wir die Grösse der verschiedenen Assets ins Monitoring mit einbeziehen, da plötzliche Vergrösserungen von Bildern oder anderen Ressourcen auf die Performance auswirken können.

(Beispiel der Entwicklung der Asset-Grössen auf der Startseite.)

Speedcurve

Bei der Evaluation von möglichen Tools ist uns einerseits wichtig, dass die verschiedenen Metrik-Typen messbar sind und andererseits, dass wir die Tests in die QA-Pipeline integrieren können.

(Beispiel eines Speedcurve Reports: Entwicklung der Metrik LCP auf der Startseite. Die rote Linie markiert das Performance Budget.)

Zu dem Zeitpunkt nutzen wir bereits Speedcurve um die Performance zu beobachten. Es erfüllt unsere Anforderungen: Eine grosse Anzahl an Metriken kann gemessen werden, sowohl synthetische Tests als auch Real-User-Monitoring (RUM) sind möglich und Speedcurve lässt sich in die Test-Pipeline integrieren.

Ähnlich wie bei den SEO-Tests wählen wir einzelne Seiten pro Seitentyp, welche getestet werden sollten.

Performance Budgets

Um zu definieren, ob ein Messwert gut ist oder nicht, wägen wir folgende zwei Fragen ab:

• Was ist die empfohlene Anforderung an die Metrik? Hier gibt es beispielsweise auf web.dev viele Informationen dazu, was jeweils ein guter Messwert ist.
• Wie gut ist der Messwert aktuell? Ist der Messwert sehr gut, möchten wir ihn beibehalten. Ist er ungenügend, sollte er idealerweise verbessert werden, jedoch nicht bei jedem Test eine Warnung auslösen.

Basierend auf den aktuellen Messwerten und den empfohlenen Anforderungen definieren wir pro Seitentyp unsere Performance Budgets. Also den Wert, den wir gerne beibehalten möchten. Zudem setzen wir einen Puffer von bis zu 5%: in diesem Rahmen darf sich der Messwert bewegen. Überschreitet bei einem Test ein Messwert das Budget, wird ein Alert ausgelöst und direkt in einen Slack-Channel gesendet.

(Tabelle mit den Metriken, dem Status Quo und dem idealen Ziel.)

Limitationen und Herausforderungen

Wir merken schnell, dass sich die Antwortzeiten der Testservern von den Productionservern unterscheiden. Als einfache Lösung heben wir die Performance Budgets für die Testumgebung an.

Auch das Beharren auf den Performance Budgets stellt sich als grosse Herausforderung heraus. Das Erhöhen eines Budgets benötigt wenige Klicks während das Einhalten der Budgets potenziell bedeutet, dass an einem Task nochmals gearbeitet wird.

Impact

Ähnlich wie die Integration der SEO-Tests haben die Bemühungen, die Performance zu messen und beizubehalten zu einem Wissenstransfer und zu einer Sensibilisierung des Themas geführt.

Schnelle Ladezeiten tragen auch zu einer guten User Experience bei und können sich positiv auf Bounce Rates und Conversions auswirken.

Und zu guter Letzt sind wir zum Zeitpunkt des Page Experience Updates von Google bereit: die Core Web Vitals sind im grünen Bereich. (Hinweise auf starke Auswirkungen des Updates gibt es bisher nicht.)