Frisch optimiert: Wie diese Seite jetzt besser gefunden wird

Nach dem Relaunch dieser Seite ist mir etwas aufgefallen: Bei Google tauchte sie kaum noch auf, und wenn ich einen Link zu einem Beitrag verschickt habe, kam in WhatsApp & Co. keine schöne Vorschau – nur ein nackter Link. Zeit, das zu reparieren. In diesem Beitrag erkläre ich in einfachen Worten, was ich gemacht habe und warum.

Kurioserweise war genau das bei meiner früheren Seite kein Problem: Die lief mit Jekyll, einem statischen Seiten-Generator. Dort wurde jede Seite schon beim Erzeugen zu fertigem HTML gebaut – Suchmaschinen bekamen also von Anfang an den kompletten Inhalt serviert und kamen damit bestens klar. Mit dem Umstieg auf eine moderne Web-App ging dieser Vorteil zunächst verloren – und genau den hole ich mit den folgenden Schritten zurück.

Das Problem: eine Seite, die Suchmaschinen „leer" sehen

Diese Seite ist eine moderne Web-App. Für Besucher ist das prima – alles lädt schnell und flüssig. Der Haken: Technisch wird die Seite erst im Browser zusammengebaut. Der erste Moment, den ein Besucher (oder eben eine Suchmaschine) bekommt, war lange eine praktisch leere Seite, die sich den eigentlichen Inhalt erst nachträglich holt.

Google kommt damit inzwischen einigermaßen zurecht – aber verzögert und nicht zuverlässig. Und viele andere „Besucher ohne Browser", etwa die Vorschau-Roboter von WhatsApp, Facebook oder Mastodon, sahen schlicht nichts Sinnvolles. Kein Titel, keine Beschreibung, kein Vorschaubild.

Was ich optimiert habe – in drei Schritten

1. Jede Seite bekommt eine eigene „Visitenkarte"

Früher hatten alle Unterseiten denselben Titel und keinerlei Beschreibung. Jetzt trägt jede Seite ihre eigenen Kopfdaten: einen passenden Titel, eine kurze Beschreibung und ein Vorschaubild. Das sind genau die Infos, aus denen Google seine Suchergebnisse und WhatsApp seine Link-Vorschau baut.

Man kann sich das wie die Visitenkarte einer Seite vorstellen: Vorher war sie leer, jetzt steht Name, Thema und ein Bild drauf.

2. Eine Landkarte für Suchmaschinen

Ich habe eine sogenannte Sitemap ergänzt – eine automatisch erzeugte Liste aller Seiten, die es gibt. Dazu eine kleine Datei, die Suchmaschinen begrüßt und auf diese Liste verweist.

Das ist wie ein Inhaltsverzeichnis, das ich Google in die Hand drücke: „Hier sind alle meine Beiträge, schau sie dir an." Es sorgt nicht für ein besseres Ranking, aber dafür, dass wirklich alle Seiten gefunden werden – auch neue.

3. Prerendering: fertige Seiten ausliefern statt leerer Hüllen

Das ist der wichtigste und aufwändigste Schritt – und im Grunde die Rückkehr zum Jekyll-Prinzip von oben, nur eben für eine moderne Web-App. Der Fachbegriff dafür ist Prerendering (bzw. Static Site Generation, SSG): Jede öffentliche Seite wird vorab zu fertigem HTML gerendert, samt Text, Titel und Vorschau-Daten. Statt der leeren Hülle geht dann dieses fertige HTML raus.

So läuft das ab: Ein Programm ruft im Vorfeld jede einzelne Seite einmal auf (die Startseite, den Blog, jeden Beitrag, jede Kategorie), lässt sie vollständig „durchlaufen" und friert das Ergebnis als HTML-Datei ein. Wer die Seite später besucht – ob Mensch oder Suchmaschine – bekommt sofort diese fertige Datei. Der eigentliche Clou heißt Hydration: Im Browser übernimmt die Web-App das bereits fertige HTML nahtlos und macht es wieder „lebendig" (Klicks, Navigation, dynamische Teile), ohne dass die Seite neu aufgebaut werden müsste. Kein Flackern, kein doppeltes Laden.

Und wann passiert dieses Vorab-Rendern? Beim Bauen des Docker-Containers. Diese Seite steckt in einem Container, der bei jeder neuen Version frisch gebaut wird. Genau in diesem Build-Schritt wird das Prerendering ausgeführt: Der Bauvorgang startet kurzzeitig die eigene Programmier-Schnittstelle (die API, die die Inhalte liefert), rendert alle Seiten dagegen und packt das fertige HTML mit ins Container-Abbild. Zur Laufzeit muss dann nichts mehr gerendert werden – der Server liefert nur noch fertige Dateien aus.

Das hat eine kleine Kehrseite: Ein neuer Beitrag ist erst nach dem nächsten Container-Bau als fertiges HTML da (bis dahin würde er wie früher erst im Browser zusammengebaut). Für einen Blog, dessen Beiträge ohnehin mit jeder neuen Version ausgerollt werden, ist das ein guter Tausch.

Das Schöne für Besucher: Am Bedienen ändert sich nichts, es fühlt sich weiterhin schnell an. Nur sehen Suchmaschinen und Vorschau-Roboter jetzt sofort den vollständigen Inhalt – genau das, was vorher fehlte.

Was das bringen soll

Bessere Auffindbarkeit bei Google: Die Beiträge sind mit echtem Inhalt sichtbar, statt als „dünne" oder leere Seiten eingestuft zu werden.
Schöne Link-Vorschauen: Wenn ich (oder jemand anderes) einen Beitrag teilt, erscheint jetzt Titel, Beschreibung und ein Vorschaubild – statt eines nackten Links.
Vollständige Erfassung: Über die Sitemap findet Google zuverlässig alle Seiten.

Und jetzt? Abwarten.

So sehr die Technik jetzt stimmt – den Rest habe ich nicht in der Hand. Google entscheidet in seinem eigenen Takt, wann es die Seiten neu besucht und ob sich das in besseren Platzierungen niederschlägt. Das kann Tage bis Wochen dauern, und eine Garantie gibt es nie.

Ich habe also getan, was ich tun konnte: sauberes Fundament gelegt, alles getestet, live gestellt. Jetzt heißt es beobachten und abwarten, ob die Arbeit Früchte trägt.