Website prüfen: die zwölf Befunde, die am meisten kosten

Die meisten Websites sind nicht kaputt. Sie sind an einer Handvoll Stellen unfertig — und jede dieser Stellen kostet etwas: Ladezeit, Sichtbarkeit bei Google oder Vertrauen beim Besucher. Wir haben zwölf davon zusammengestellt. Die Reihenfolge folgt der Wirkung, nicht einer Häufigkeitsstatistik: unser Website-Check ist zu neu, um über Häufigkeiten etwas Belegbares zu sagen.

Was die Seite langsam macht

1. Bilder in Kameraauflösung. Ein Foto kommt mit 4.000 Pixel Breite aus der Kamera und landet genau so auf dem Server. Angezeigt wird es in 800 Pixel Breite — der Browser lädt trotzdem die volle Datei und rechnet sie erst danach klein. Das kostet auf dem Mobilfunknetz Sekunden und Datenvolumen des Besuchers. Was wir machen: Bilder auf die tatsächlich angezeigte Größe rechnen, auf WebP umstellen und mehrere Größenstufen anlegen, damit ein Mobilgerät nicht die Desktop-Fassung lädt.

2. Bilder ohne Größenangabe im Quelltext. Fehlen width und height, kennt der Browser die Bildmaße erst, wenn das Bild geladen ist. Bis dahin steht der Text an einer Stelle — und springt dann weg, oft genau während jemand liest oder auf einen Link zielt. Google misst diesen Sprung und wertet ihn ab. Was wir machen: die Maße in den Quelltext eintragen. Das ist der ärgerlichste Fehler mit der einfachsten Behebung.

3. Kein HTTP/2. Mit dem alten HTTP/1.1 holt der Browser die Dateien einer Seite in kleinen Gruppen nacheinander. Bei 80 Dateien sind das viele Runden, in denen nichts passiert außer Warten. HTTP/2 überträgt sie über eine Verbindung parallel. Bei den meisten Hostern ist das eine Einstellung und kein Umbau. Was wir machen: am Server freischalten und danach nachmessen, ob die Anzahl Anfragen überhaupt noch eine Rolle spielt.

4. Eine langsame Serverantwort. Wenn schon das erste Byte über eine Sekunde braucht, hilft kein optimiertes Bild mehr — der Browser hat bis dahin nichts, womit er anfangen könnte. Die Ursache liegt fast immer in ungezwischengespeicherten Datenbankabfragen, zu vielen Erweiterungen oder einem überbuchten Mietserver. Was wir machen: einen Seiten-Zwischenspeicher einrichten, die teuersten Abfragen straffen und erst danach über den Umzug auf einen stärkeren Server reden.

Was die Verschlüsselung entwertet

5. Gemischte Inhalte. Die Seite läuft über https, lädt aber eine Schrift, ein Bild oder ein Skript noch über http. Der Browser blockiert es entweder oder nimmt das Schloss aus der Adresszeile. Der Aufwand für das Zertifikat ist damit zu einem guten Teil verschenkt. Was wir machen: alle Einbindungen auf https umstellen und Quellen ersetzen, die kein https anbieten.

6. www und ohne www führen auf zwei verschiedene Seiten. Beide Schreibweisen antworten, aber keine leitet auf die andere um. Für Google sind das zwei Websites mit identischem Inhalt, und die Bewertung teilt sich auf beide auf. Was wir machen: eine Hauptschreibweise festlegen, die andere dauerhaft dorthin umleiten und die Canonical-Angabe entsprechend setzen.

7. Kein HSTS. Die Umleitung von http auf https ist eingerichtet — aber der allererste Aufruf läuft trotzdem einmal unverschlüsselt, bevor umgeleitet wird. Genau diese eine Anfrage lässt sich abfangen. HSTS weist den Browser an, es künftig gar nicht erst zu versuchen. Was wir machen: den Kopf mit mindestens halbjähriger Gültigkeit setzen, nachdem wir geprüft haben, dass wirklich jede Unteradresse über https antwortet — vorher wäre es ein Eigentor.

Was die Seite unsichtbar macht

8. Ein vergessenes noindex. Während des Neubaus wird die Seite für Suchmaschinen gesperrt, damit die Baustelle nicht im Index landet. Nach dem Umschalten bleibt die Sperre stehen. Die Seite ist online, sieht gut aus und ist bei Google nicht auffindbar — manchmal monatelang, bis jemand nach dem eigenen Firmennamen sucht und nichts findet. Was wir machen: die Sperre entfernen und nach jedem Umzug erneut prüfen, weil sie bei jedem Neuaufsetzen wiederkommen kann.

9. Keine oder mehrere H1-Überschriften. Die H1 sagt Suchmaschine und Vorleseprogramm, worum es auf dieser Seite geht. Manche Vorlagen setzen das Logo als H1, andere vergeben sie an jeden Abschnitt. Beides macht das Thema unscharf. Was wir machen: genau eine H1 mit dem Hauptbegriff setzen und die übrigen Überschriften eine Ebene herabstufen.

10. Keine erreichbare Sitemap. Ohne Sitemap findet Google neue und tief liegende Seiten deutlich später — bei einer Seite, die über die Navigation nicht direkt verlinkt ist, unter Umständen gar nicht. Häufig existiert eine Sitemap, ist aber veraltet oder wird von der robots.txt nicht genannt. Was wir machen: eine Sitemap erzeugen, sie automatisch aktuell halten, in der robots.txt eintragen und in der Google Search Console anmelden.

Was dem Besucher auffällt

11. Tippziele unter 44 Pixel. Ein Finger braucht rund 44 mal 44 Pixel Fläche. Menüpunkte, die am Desktop mit der Maus gut zu treffen sind, werden auf dem Mobilgerät regelmäßig danebengetroffen — besonders, wenn zwei Links direkt untereinander stehen. Was wir machen: die Tippflächen vergrößern und die Abstände zwischen benachbarten Zielen erhöhen, ohne das Layout am Desktop zu verändern.

12. Fremde Hosts, bevor der Besucher etwas anklickt. Google Fonts, eine Kartendarstellung, ein eingebundener Film, eine Schrift von einem Fremd-CDN: All das wird beim bloßen Aufruf geladen, und dabei überträgt der Browser jedes Mal die IP-Adresse des Besuchers an einen Dritten — vor jeder Zustimmung. Das ist zunächst ein technischer Befund, keine rechtliche Bewertung; ob daraus ein Problem folgt, entscheidet der Einzelfall und gehört in juristische Hände. Was wir machen: Schriften und Skripte lokal einbinden und alles Übrige hinter die Zustimmung legen, mit einer Vorschau statt der Einbindung.

Der dreizehnte Befund: niemand misst nach

Der häufigste Grund, warum diese Punkte offen bleiben, ist kein technischer. Es sieht auf dem eigenen Rechner alles in Ordnung aus — schnelle Leitung, Seite im Zwischenspeicher, großer Bildschirm. Die Messung von außen, ohne Zwischenspeicher und mit gedrosselter Mobilverbindung, sieht etwas anderes. Und ohne einen Wert, der vor und nach einer Änderung mit derselben Methode erhoben wurde, bleibt jede Verbesserung eine Behauptung.

Genau dafür haben wir den Website-Check gebaut: Domain eintragen, warten, und Sie bekommen alle acht Bereiche mit Punktzahl und Befunden. Bei der zweiten Prüfung derselben Domain steht der Vergleich zur letzten Messung darüber — Bereich für Bereich, mit der Veränderung in Punkten. Wenn Sie nur wissen wollen, wo die Ladezeit hängt, reicht der Geschwindigkeitstest.

Häufig gestellte Fragen

In welcher Reihenfolge arbeitet man die Befunde ab?

Zuerst das, was die Seite unsichtbar macht — ein vergessenes noindex schlägt jede Ladezeitoptimierung. Danach die Verschlüsselung, weil ein fehlendes Schloss Besucher an der Tür verliert. Dann die Ladezeit, angefangen bei den Bildern, weil dort das meiste Gewicht liegt. Der Bericht sortiert die offenen Punkte oben unter „Was zuerst dran ist" genau so.

Kann ich das selbst beheben?

Einiges ja. Größenangaben an Bildern, eine einzelne H1 und die Sitemap schafft jeder, der an die Vorlage kommt. HSTS, HTTP/2 und die Umleitung der Domainfassungen gehören in die Serverkonfiguration — dort macht ein falsch gesetzter Wert die Seite für Monate unerreichbar, weil Browser HSTS speichern. Im Zweifel messen, dann fragen.

Läuft die Behebung aus der Ferne?

Wir entwickeln Prüfwerkzeuge und passende Änderungen am Website-Code. Sie erhalten nachvollziehbare Tests, dokumentierte Datenwege und ein Lösungspaket für Ihre Anwendung. Vorhaben beschreiben