Wissensdatenbank SEO: Support-Artikel, die Google findet

Eine Wissensdatenbank wird bei Google vor allem dann gefunden, wenn jeder Artikel genau ein konkretes Problem beantwortet, unter einer stabilen, sprechenden URL liegt und nicht von Hunderten Such-, Tag- und Filterseiten überlagert wird. Die Inhalte sind meist vorhanden, denn Support-Teams schreiben seit Jahren Antworten. Woran es typischerweise hapert, ist die Technik und die Ordnung um diese Antworten herum.

Dieser Beitrag behandelt die Architektur eines Help Centers: wie URLs aufgebaut sein sollten, was mit interner Suche, Tag-Archiven und Filtern passiert, wie Sie nahezu identische Artikel in den Griff bekommen und wie Hilfeseiten und Produktseiten sich gegenseitig stützen. Allgemeine Grundlagen der Suchmaschinenoptimierung setzen wir voraus. Es geht um das, was bei Support-Content anders ist.

Warum Support-Content anders funktioniert als Blogbeiträge

Wer ein Blog betreibt, veröffentlicht Beiträge einzeln und pflegt sie selten. Eine Wissensdatenbank dagegen wächst schnell, wird von mehreren Personen gepflegt und ändert sich mit jedem Produktupdate. Dadurch entstehen Probleme, die es in redaktionellen Bereichen kaum gibt: Hunderte kurze Seiten mit ähnlichem Wortlaut, veraltete Anleitungen für ausgelaufene Funktionen und automatisch erzeugte Verzeichnisseiten, die niemand bewusst angelegt hat.

Auch die Suchabsicht ist eine andere. Jemand, der nach einer Fehlermeldung oder einem konkreten Arbeitsschritt sucht, will eine schnelle, eindeutige Lösung und keine Einführung in das Thema. Eine Seite, die nach drei Absätzen Einleitung endlich zur Antwort kommt, verliert gegen eine, die die Antwort in den ersten Zeilen gibt. Das Format ist deshalb knapper, stärker strukturiert und näher an der Formulierung, in der Nutzer ihr Problem tatsächlich beschreiben.

Zudem hat Support-Content zwei Zielgruppen, die sich überschneiden: bestehende Kunden, die meist schon eingeloggt sind oder direkt im Produkt suchen, und Interessenten, die vor dem Kauf prüfen, ob ein Produkt eine bestimmte Sache kann. Für die Suche ist die zweite Gruppe oft wertvoller, denn sie kommt über Google, ohne die Marke zu kennen. Wenn Sie die Wissensdatenbank für Suchmaschinen öffnen, schreiben Sie also auch für Leute, die noch nichts gekauft haben.

URL-Struktur: flach, lesbar und dauerhaft

Die URL eines Artikels sollte das Thema benennen und nicht die Position im Menü. Bewährt hat sich ein Muster wie /hilfe/rechnung-als-pdf-herunterladen. Eine Kategorie im Pfad ist in Ordnung, wenn sie stabil ist, etwa /hilfe/abrechnung/rechnung-als-pdf-herunterladen. Problematisch werden tiefe Pfade mit drei oder vier Ebenen, weil jede Umstrukturierung der Navigation dann zu neuen URLs führt.

Zwei Fehler sind besonders häufig. Erstens hängen viele Systeme numerische IDs an den Slug, etwa /articles/4821-rechnung-herunterladen. Das ist technisch harmlos, aber die ID macht Umzüge zwischen Systemen schwerer, weil sie sich nicht mitnehmen lässt. Zweitens ändert sich der Slug automatisch, wenn jemand den Titel überarbeitet. Dann bricht jede externe Verlinkung, sofern das System nicht zuverlässig eine 301-Weiterleitung setzt. Stellen Sie den Slug deshalb nach der Veröffentlichung fest, und ändern Sie ihn nur bewusst und mit Weiterleitung.

Ebenso wichtig ist die Frage, wo die Wissensdatenbank liegt. Ein Unterverzeichnis der Hauptdomain wie example.com/hilfe nutzt die Stärke der Domain direkt, und interne Links zwischen Produkt und Hilfe sind gewöhnliche interne Links. Eine Subdomain wie hilfe.example.com wird von Suchmaschinen eher als eigenständiger Bereich behandelt. Viele Help-Center-Anbieter erzwingen diese Variante, weil sie auf ihrer Infrastruktur laufen. Das ist kein Ausschlusskriterium, aber ein Grund, die Entscheidung bewusst zu treffen und nicht aus Bequemlichkeit. Wer später von einer Subdomain auf ein Verzeichnis wechselt, muss jede einzelne URL sauber weiterleiten.

Schließlich gehört die Mehrsprachigkeit in die Struktur. Wenn die Wissensdatenbank in mehreren Sprachen existiert, brauchen die Versionen getrennte URLs und gegenseitige hreflang-Verweise. Eine Übersetzung, die nur per Cookie oder Browsersprache ausgeliefert wird, sieht Google nie.

• Slug aus dem Thema des Artikels ableiten, nicht aus der Menüposition.
• Höchstens eine Kategorieebene im Pfad, keine Datumsangaben.
• Slug nach der Veröffentlichung nicht mehr automatisch anpassen lassen.
• Sprachversionen unter eigenen URLs mit hreflang ausliefern.

Interne Suche, Tags und Filter: was in den Index gehört

Die meisten Help-Center-Systeme erzeugen nebenbei eine Fülle von Seiten, die keinen eigenen Wert haben: Ergebnisse der internen Suche (/suche?q=rechnung), Tag-Archive, Autorenseiten, sortierte Listen und paginierte Kategorien. Für Google sind das potenziell unendlich viele URLs mit dünnem oder doppeltem Inhalt. Sie verbrauchen Crawl-Budget, verwässern die Signale und landen im schlimmsten Fall selbst in den Suchergebnissen.

Die Faustregel ist einfach. Ein Artikel gehört in den Index. Eine Kategorieseite gehört in den Index, wenn sie eine echte Übersicht mit einleitendem Text bietet. Seiten der internen Suche gehören nicht in den Index. Bei ihnen sollten Sie noindex setzen und die Links zu ihnen nicht als Crawling-Pfad anbieten. Tag-Archive sind ein Grenzfall: Ein Tag, das nur dieselben Artikel wie eine Kategorie auflistet, ist überflüssig. Ein sorgfältig gepflegtes Tag mit eigener Beschreibung kann als Themenseite taugen, dann aber als bewusst gestaltete Seite und nicht als Nebenprodukt.

Beachten Sie den Unterschied zwischen robots.txt und noindex. Sperren Sie Such-URLs in der robots.txt, kann Google die Seite nicht abrufen und sieht deshalb auch ein noindex nicht. Die URL kann trotzdem indexiert werden, wenn externe Links auf sie zeigen, nur ohne Inhalt. Wollen Sie eine Seite sicher aus dem Index halten, muss sie crawlbar bleiben und ein noindex ausliefern. Die robots.txt eignet sich dagegen, um unendliche Filterkombinationen gar nicht erst abrufen zu lassen. Beides zusammen auf dieselbe URL anzuwenden, hebt die Wirkung des noindex auf.

Bei paginierten Kategorien zeigt jede Seite ihre eigene Artikelliste und sollte auf sich selbst kanonisieren, nicht auf Seite eins. Ein Canonical auf die erste Seite signalisiert, dass die Folgeseiten dasselbe zeigen, und kann dazu führen, dass die dort verlinkten Artikel schlechter gefunden werden. Kontrollieren Sie in der Search Console unter den Seitenindexierungsberichten, welche Muster tatsächlich erfasst wurden. Meldungen wie „Gecrawlt, derzeit nicht indexiert“ bei Hunderten Such- oder Tag-URLs sind ein deutliches Zeichen, dass die Struktur zu viel offenlegt.

Fast identische Artikel erkennen und zusammenführen

Kaum ein Bereich produziert so viele Beinahe-Dubletten wie ein Help Center. Es gibt „Passwort zurücksetzen“, „Passwort vergessen“ und „Zugang wiederherstellen“, dazu drei Varianten für iOS, Android und Desktop, die zu 90 Prozent denselben Text enthalten. Jede dieser Seiten konkurriert mit den anderen um dieselbe Suchanfrage. Google wählt dann eine aus, und häufig ist es nicht die, die Sie im Sinn hatten.

Der erste Schritt ist eine Bestandsaufnahme. Exportieren Sie Titel und URLs, und gruppieren Sie sie nach der Frage, die der Artikel beantwortet. In der Search Console sehen Sie unter Leistung, welche Seiten für dieselbe Suchanfrage Impressionen erhalten. Wechseln mehrere URLs bei einer Anfrage ständig die Position, ist das ein typisches Kannibalisierungsmuster. Prüfen Sie außerdem, ob Google eine andere URL als kanonisch gewählt hat, als Sie angegeben haben. Das Werkzeug zur URL-Prüfung zeigt beide Angaben nebeneinander.

Dann entscheiden Sie pro Gruppe. Gleiche Frage, gleiche Antwort: zusammenführen, die schwächeren URLs per 301 auf den besten Artikel weiterleiten und die Inhalte übernehmen. Gleiche Frage, aber tatsächlich unterschiedliche Schritte je nach Plattform: einen Hauptartikel schreiben, der die gemeinsame Anleitung enthält, und die plattformspezifischen Teile als Abschnitte mit Zwischenüberschriften einbauen. Nur wenn die Plattformen wirklich getrennte Suchanfragen bedienen, etwa weil die Fehlermeldung eine andere ist, rechtfertigt das eigene Seiten. Dann sollte jede Seite ihre Besonderheit im Titel und in den ersten Zeilen tragen, sonst sind sie wieder austauschbar.

Ein Canonical-Tag ist hier oft die falsche Lösung. Er verlangt, dass die Seiten im Wesentlichen denselben Inhalt haben, und ist nur ein Hinweis, kein Befehl. Wenn Sie wissen, dass eine Seite überflüssig ist, ist die Weiterleitung klarer. Canonicals haben ihren Platz bei technischen Dubletten, etwa wenn derselbe Artikel unter zwei Pfaden erreichbar ist, weil er in zwei Kategorien einsortiert wurde. Legen Sie in solchen Fällen einen Hauptpfad fest, und lassen Sie alle anderen darauf verweisen.

Planen Sie diese Bereinigung als wiederkehrende Aufgabe. Wenn ein Produktupdate eine Funktion umbenennt, entstehen sonst wieder zwei Artikel für dieselbe Sache, einer alt und einer neu.

Veraltete Artikel: aktualisieren, weiterleiten oder entfernen

Ausgelaufene Funktionen sind ein Dauerthema. Ein Artikel über eine Einstellung, die es nicht mehr gibt, frustriert Leser und erzeugt neue Support-Anfragen. Gehen Sie nach dem Zweck vor. Gibt es einen Nachfolger, leiten Sie per 301 auf den Artikel zur neuen Funktion weiter. Gibt es keinen, aber der Artikel bekommt weiterhin Zugriffe von Nutzern mit älteren Versionen, behalten Sie ihn und markieren den Status gleich zu Beginn deutlich. Ist das Thema endgültig erledigt und hat keine nennenswerten Links oder Zugriffe, ist ein Statuscode 410 oder 404 ehrlicher als eine Weiterleitung auf die Startseite.

Weiterleitungen auf eine irrelevante Seite behandelt Google häufig wie einen Soft 404. Der Nutzer erwartet eine Antwort auf sein Problem und landet in der Übersicht. Leiten Sie deshalb nur dann weiter, wenn die Zielseite die ursprüngliche Frage wirklich beantwortet.

Interne Verlinkung zwischen Hilfe und Produktseiten

Hilfeartikel sind häufig die am besten verlinkten Seiten einer Domain, weil sie in Bestätigungs-E-Mails, Produktoberflächen und Antworten des Supports auftauchen. Gleichzeitig verlinken sie oft nur nach innen auf andere Hilfeartikel. Die Stärke bleibt im Help Center, während die Produktseiten, die kommerziell zählen, davon nichts abbekommen.

Ein sinnvoller Ansatz ist, pro Artikel ein bis drei Verweise auf Produkt- oder Funktionsseiten zu setzen, dort wo sie dem Leser tatsächlich nützen. Ein Artikel über die Rechnungsvorlage kann auf die Seite zur Rechnungsfunktion verweisen, mit einem Linktext, der beschreibt, was dort zu finden ist. Umgekehrt sollte jede Funktionsseite auf die zwei oder drei meistgenutzten Hilfeartikel zeigen. Das hilft Interessenten, die vor dem Kauf prüfen wollen, ob ein Detail funktioniert, und es gibt den Hilfeartikeln einen Weg in die Hauptnavigation der Domain.

Vermeiden Sie dabei Werbesprache in Support-Artikeln. Wer ein Problem lösen will, bricht ab, sobald der Text nach Verkauf klingt. Ein neutraler Hinweis wie „Mehr zu dieser Funktion“ reicht. Auch Breadcrumbs gehören dazu: Eine Brotkrumenleiste mit Startseite, Hilfe, Kategorie und Artikel schafft feste Pfade nach oben, zeigt dem Leser seinen Ort und liefert die Basis für strukturierte Daten.

Setzen Sie Querverweise zwischen verwandten Artikeln bewusst und nicht über automatische Listen „ähnliche Artikel“, die nach Schlagwort-Überschneidung sortieren. Solche Listen verlinken oft auch die Beinahe-Dubletten, die Sie gerade zusammengeführt haben. Eine kurze, von Hand kuratierte Liste mit den nächsten logischen Schritten hilft dem Nutzer mehr als zehn automatisch erzeugte Links.

Artikelaufbau, Markup und Pflege im Alltag

Der Titel eines Artikels sollte die Frage oder das Problem in der Sprache der Nutzer benennen: „Rechnung als PDF herunterladen“ statt „Dokumentenexport (Modul B)“. Den Fehlertext, den Nutzer tatsächlich sehen, schreiben Sie wörtlich in den Artikel, denn viele suchen genau diese Zeichenfolge. Die Lösung folgt direkt danach, nummerierte Schritte sind hier besser als Fließtext. Screenshots brauchen Alternativtexte, und wichtige Schritte sollten auch ohne Bild verständlich sein.

Bei strukturierten Daten gilt Zurückhaltung. Breadcrumb-Markup ist unkompliziert und sinnvoll. FAQ- und How-to-Markup dürfen Sie nur einsetzen, wenn der Inhalt sichtbar auf der Seite steht, und Google zeigt für How-to-Markup keine Erweiterungen mehr und für FAQ-Markup nur noch bei Behörden- und Gesundheitswebsites an. Verlassen Sie sich daher nicht darauf, dass Markup allein Klicks bringt. Die Qualität der Antwort bleibt der eigentliche Hebel.

Legen Sie zudem einen sichtbaren Hinweis auf das letzte Aktualisierungsdatum fest, und halten Sie ihn ehrlich. Ein Datum, das sich bei jeder kleinen Korrektur ändert, ohne dass sich der Inhalt wesentlich verändert hat, schafft wenig Vertrauen. Ergänzen Sie die Wissensdatenbank außerdem um eine XML-Sitemap, die nur indexierbare Artikel und Kategorien enthält, und reichen Sie sie in der Search Console ein.

Bei Wartung und Messung hilft ein klarer Rhythmus. Prüfen Sie quartalsweise, welche Artikel viele Impressionen, aber kaum Klicks haben: Dort stimmt meist der Titel nicht mit der Suchanfrage überein. Artikel mit Klicks und hoher Absprungrate beantworten die Frage womöglich nicht gut genug. Und Artikel ganz ohne Impressionen sind Kandidaten zum Zusammenführen. Beobachten Sie außerdem die häufigsten Suchbegriffe der internen Suche: Sie zeigen Fragen, für die noch kein Artikel existiert.

• Titel in der Sprache der Nutzer, Fehlermeldungen wörtlich zitieren.
• Antwort zuerst, danach Hintergründe und Sonderfälle.
• Breadcrumbs als Markup, FAQ-Markup nur bei sichtbarem Inhalt.
• Sitemap nur mit indexierbaren Seiten, quartalsweise Bereinigung.