SEO-Lektionen aus der Korrektur unserer eigenen Website

Wir haben ein paar Tage damit verbracht, unsere eigene Website so zu lesen, wie es eine Suchmaschine tut, und dabei sechs Dinge gefunden, die sich zu beheben lohnen. Jede Seite meldete zwei FAQ-Blöcke, Google nutzte einen dekorativen Hintergrundglanz als unser Vorschaubild, eine Reihe von Vorlagenseiten rankte für Suchanfragen, die sie nicht beantworteten, und ein neuer Bereich der Website wurde auf Staging von unserem eigenen Edge blockiert. Nichts davon war dramatisch. Alles hat unsere Sichtbarkeit still und leise gekostet.

Die Website in einem Absatz

mythex.ai ist eine Single-Page-App, die wir zur Build-Zeit vorab rendern: Ein Skript durchläuft jede Route, schreibt dafür eine statische HTML-Datei und fügt Titel, Beschreibung und strukturierte Daten der Seite ein (den JSON-LD-Block, der Suchmaschinen sagt, worum es auf einer Seite geht, siehe was strukturierte Daten sind). Das meiste von dem Folgenden liegt in diesem Vorab-Rendering, weil das der HTML-Code ist, den ein Crawler tatsächlich liest.

1. Jede Seite behauptete, die FAQ-Seite zu sein

Symptom. Unsere HTML-Vorlage enthielt in den strukturierten Daten einen website-weiten FAQPage-Block, dessen URL auf /faq zeigte. Das Vorab-Rendering fügte dann den eigenen FAQPage jeder Seite hinzu. Also lieferte jede Seite der Website zwei davon aus, und unsere Datenschutzerklärung teilte Google mit, sie sei die FAQ-Seite.

Warum das wichtig ist. Google erwartet höchstens einen FAQPage pro Seite. Ein zweiter, der auf eine andere Stelle zeigt, führt dazu, dass das Markup einer Seite abgewertet wird und nicht nur ignoriert.

Lösung. Der globale Block ist weg. Das FAQ-Markup jeder Seite kommt jetzt von einer einzigen Stelle, auch /faq selbst, das es aus der vollständigen Fragenliste erzeugt. Seiten ohne FAQs deklarieren jetzt keine, was die ehrliche Antwort ist. Und das Vorab-Rendering bricht den Build ab, wenn eine Seite je wieder mehr als einen FAQPage trägt. Eine Regel, die nur im Gedächtnis eines Menschen existiert, wird gebrochen; eine Regel, die der Build erzwingt, nicht.

2. Google nutzte für uns das falsche Bild

Symptom. In den Suchergebnissen war das Mythex-Vorschaubild der weiche, pulsierende Glanz hinter dem Hero-Bereich unserer Startseite, also ein dekoratives Hintergrundbild, statt unserer Share-Karte.

Warum es passierte. Wir hatten Google nie gesagt, welches Bild eine Seite repräsentiert, also wählte es eines aus, das es fand.

Lösung. Zwei Seiten desselben Problems:

• Sagen Sie, welches Bild zur Seite gehört. Die Startseite hat jetzt einen WebPage-Knoten mit einem primaryImageOfPage, das auf die Share-Karte zeigt, und die strukturierten Daten jeder vorab gerenderten Seite tragen ihr eigenes Bild (das Share-Bild der Seite oder das Standardbild).
• Verstecken Sie die Dekoration. Die Hintergrundbilder sind jetzt in der robots.txt untersagt und werden mit dem Header noindex, noimageindex ausgeliefert, damit sie aus der Bildersuche und den Vorschaubildern herausbleiben.

3. Suchmaschinen kannten nur unser Logo

Unser Organization-Markup enthielt einen Namen, ein Logo und einige Social-Media-Links, also nur Branding und nichts weiter. Suchmaschinen bauen den Wissenskasten eines Unternehmens aus registerähnlichen Fakten auf, deshalb haben wir jene ergänzt, die aus unserer Gewerbeerlaubnis stammen: den offiziellen Firmennamen, das Gründungsdatum, den Gründer und die eingetragene Adresse. Die Telefonnummer haben wir bewusst weggelassen.

4. Vorlagenseiten beantworteten die falsche Frage

Symptom. Die Search Console zeigte drei Vorlagenseiten mit Impressionen und ohne Klicks. Eine rankte für „content strategist portfolio“ und Varianten davon, eine für „best italian restaurant website design“, eine für eine Gruppe rund um „agile board“. Die Hälfte dieser Suchanfragen enthielt das Wort „free“. Die Positionen lagen zwischen etwa Platz 25 und Platz 50.

Warum. Jede Seite beantwortete eine andere Frage als die gestellte. Wer sehen wollte, wie gutes Design für italienische Restaurants aussieht, landete auf einer Seite, die ihm einen Baukasten verkaufen wollte.

Lösung. Jede der drei hat jetzt einen Abschnitt, der für die Suche geschrieben ist und nicht für das Produkt, einen Titel und eine Beschreibung in den Worten, die Menschen tippen, sowie FAQs, die das Markup wert sind, das sie bereits ausgegeben haben.

Derselbe Commit behob ein stilleres Problem. Der Block „verwandte Vorlagen“ nahm die ersten vier Vorlagen einer Kategorie, sodass jede Portfolio-Vorlage auf dieselben vier Portfolios verwies und der Rest dieser Kategorie gar keine internen Links hatte. Wir haben ihn durch einen Ring ersetzt, der nach Unterkategorie geordnet ist: Jede Vorlagenseite bekommt jetzt genau vier eingehende und vier ausgehende Links. Das vorab gerenderte HTML gibt diese Links jetzt ebenfalls aus. Vorher existierten sie nur, nachdem JavaScript lief, was ein Crawler womöglich nie tut.

5. Bing sofort über neue Seiten informieren

Google ignoriert IndexNow, ein Protokoll, mit dem man Suchmaschinen anpingt, wenn sich eine URL ändert. Bing, Yandex und Seznam nutzen es, und der Index von Bing ist das, was die Suche von ChatGPT liest. Ein KI-App-Baukasten, den KI-Assistenten nicht finden können, ist eine besondere Art von Fehler.

Der naheliegende Ansatz, bei jedem Deployment die gesamte Sitemap einzureichen, ist der Weg, wie ein Schlüssel gedrosselt wird, und die meisten Deployments ändern nichts, was eine Suchmaschine interessiert. Deshalb vergleicht ein Skript die Sitemap, die die Website gerade ausliefert, mit der frisch gebauten und reicht nur den Unterschied ein.

Zwei Details haben das möglich gemacht:

• Vor dem Deployment einen Snapshot erstellen. Die Ausgangsbasis muss erfasst werden, bevor der neue Build live geht. Danach ist die „live“-Sitemap bereits die neue, und jeder Vergleich ergibt nichts.
• Vorerst nur neue Seiten. Unsere Sitemap enthält keine lastmod-Daten, daher meldet das Skript neue Seiten, aber keine Überarbeitungen. Würde man jede URL mit dem Build-Datum versehen, wäre bei jedem Deployment die gesamte Website als geändert markiert, genau der Spam, den wir vermeiden wollten.

Es läuft nur bei Produktions-Deployments und lässt den Build nie fehlschlagen: Wenn es läuft, ist die Website bereits live, und ein Ping an Suchmaschinen ist kein rotes Deployment wert.

6. Unser eigener Edge sagte „nicht gefunden“

Als wir die /ai-Seiten gestartet haben (mehr dazu in einer Landingpage für jede Art von Unternehmen), zeigte Staging für alle „Nicht gefunden“, während der statische Host sie einwandfrei auslieferte.

Der Dienst vor unseren Marketing-Hosts leitet nur eine Allowlist an Pfaden weiter. Alles andere erhält einen harten 404. /ai war neu und stand nicht auf der Liste. Wir haben /ai und /ai/* hinzugefügt und einen Test ergänzt, der prüft, dass sie durchkommen. Ein kleiner Fehler, aber genau der Typ, der einen neuen Bereich für Crawler unsichtbar macht, ohne dass es jemand bemerkt.

Was wir daraus mitnehmen

• Lesen Sie das HTML, das ein Crawler liest. Die meisten dieser Fehler waren im Browser unsichtbar und in der vorab gerenderten Datei offensichtlich.
• Verwandeln Sie SEO-Regeln in Build-Prüfungen. „Ein FAQPage pro Seite“ wird jetzt erzwungen, nicht nur erinnert.
• Sagen Sie Suchmaschinen, was Sie meinen. Wenn Sie nicht sagen, welches Bild oder welche Fakten Sie repräsentieren, werden sie raten.
• Die Search Console zeigt, welche Frage Menschen gestellt haben. Impressionen ohne Klicks bedeuten meist, dass die Seite eine andere Frage beantwortet hat.
• Reichen Sie Unterschiede ein, nicht alles. Nur Geändertes anzupingen hält Sie innerhalb der Ratenlimits.

Wenn Sie dasselbe für eine von Ihnen gebaute Website tun, decken unsere Leitfäden zu SEO für mit KI gebaute Websites und die Einrichtung der Google Search Console die Grundlagen ab.