In eigener Sache

Dieser Beitrag behandelt Werkzeuge, die ich selbst herstelle und anbiete. Ich verdiene daran; berücksichtigen Sie das beim Lesen. Ein Vergleich mit fremden Werkzeugen findet hier nicht statt – dafür fehlt mir die Erhebung, und mein Eigeninteresse machte ihn ohnehin unbrauchbar.

Jedes der drei ist aus einer Grenze entstanden, an die ich beim Arbeiten gestoßen bin. Deshalb steht bei jedem, wo seine eigene Grenze liegt – das ist der interessantere Teil.

Search-Console.PRO

Der Anlass. Die Search Console zeigt je Auswertung nur eine begrenzte Zahl von Zeilen. Bei einer Website mit dreißig Seiten fällt das nicht auf. Bei einem Bestand aus mehreren hundert Adressen fehlt genau der Teil, über den entschieden werden muss – der lange Ausläufer aus Seiten mit wenigen Einblendungen.

Konkret geworden ist das bei einem Umzug: Wer entscheiden will, welche Adressen weitergeleitet und welche aufgegeben werden, braucht den vollständigen Bestand. Die vorderen Adressen behält man ohnehin.

Die Grenze. Es kann keine Daten zeigen, die Google nicht herausgibt. Selten gestellte Anfragen bleiben ausgelassen, die Speicherdauer bleibt bei sechzehn Monaten, und eine vollständige Zuordnung von Anfrage zu Seite mit stimmigen Summen ist nicht möglich. Wer das verspricht, verspricht etwas, das die Quelle nicht liefert.

Was die Search Console selbst zeigt und was nicht steht in einem eigenen Beitrag. Die ausführliche Begründung für das Werkzeug steht auf meinem Betriebsblog.

PageSpeed.de

Der Anlass. Die häufigste Frage zu Ladezeiten lautet, wie man auf hundert Punkte kommt. Sie ist fast nie die richtige, weil zwei verschiedene Messarten durcheinandergehen: die Labormessung unter festgelegten Bedingungen und die Felddaten aus tatsächlichen Aufrufen. Ein guter Laborwert bei schlechten Felddaten ist kein Widerspruch, sondern der Normalfall bei einem Publikum mit älteren Geräten.

Die Grenze. Es kann fehlende Felddaten nicht ersetzen – liegen für eine Seite keine vor, ist die Besucherzahl zu gering, und daran ändert kein Werkzeug etwas. Es benennt außerdem keine Ursachen: Es zeigt, wo Zeit vergeht, nicht warum ein bestimmtes Skript so lange braucht.

Die Unterscheidung der beiden Messarten steht ausführlich auf meinem Betriebsblog.

SEO CMS

Der Anlass. Mehrere gleichartige Portale, dieselbe Person als Betreiber und Entwickler, und die Erkenntnis, dass ein erheblicher Teil der Arbeitszeit in Aktualisierungen von Erweiterungen ging, die niemand gebraucht hätte. Ein statischer Generator erzeugt flaches HTML; ausgeliefert wird ohne Programmausführung, ohne Erweiterungen Dritter, ohne Einwilligungsbanner.

Die Grenze – und sie ist die deutlichste der drei. Es gibt kein Ökosystem: Was fehlt, wird nicht zugekauft, sondern gebaut. Es gibt kein Redaktionssystem, das man jemandem in die Hand geben kann, der es aus anderen Projekten kennt. Und es gibt keine Nutzergemeinde, die Fehler meldet – was niemandem auffällt, bleibt liegen.

Wann diese Rechnung kippt

Sobald jemand anderes das System bedienen oder warten soll. Der Vorteil beruht darauf, dass Betreiber und Entwickler dieselbe Person sind – und dass diese Person ohnehin Server administriert. Fällt eine dieser Bedingungen weg, ist ein verbreitetes System die bessere Wahl, auch wenn es mehr Wartung bedeutet.

Die vollständige Abwägung mit allen Nachteilen steht dort.

Was für alle drei gilt

Ein Werkzeug verschiebt den Aufwand. Es beantwortet keine Frage.

Keines der drei sagt, ob ein Text die Frage beantwortet, mit der jemand kam. Keines entscheidet, welche Seite bleiben soll. Was sie leisten, ist, Arbeit möglich zu machen, die von Hand nicht stattfinden würde – bei dreißig Seiten prüft man von Hand, bei dreitausend findet die Prüfung ohne Werkzeug einfach nicht statt.

Das ist ein realer Nutzen und ein begrenzter. Wer mehr verspricht, sollte gefragt werden, woher er das weiß.