Technisches SEO für Webanwendungen: Was das Ranking wirklich bewegt

Wenn eine Webanwendung nicht rankt, liegt es selten am Inhalt. Es liegt daran, dass der Crawler eine leere Seite erhielt, oder vier URLs mit demselben Inhalt fand, oder sein Crawl-Budget auf Facettenfilter-Kombinationen verbrauchte, oder von einer verirrten Anweisung gesagt bekam, die Seite gar nicht zu indexieren. Nichts davon taucht in einem Keyword-Bericht auf, und alles davon braucht jemanden, der den Code ändern kann.

Fangen Sie damit an, was der Crawler tatsächlich bekommt

Die nützlichste Gewohnheit im technischen SEO ist, die Seite nicht mehr im Browser anzusehen. Holen Sie sich das rohe HTML, das der Server zurückgibt, und lesen Sie das. Es ist regelmäßig ein anderes Dokument als das, was Sie sehen.

Bei clientseitig gerenderten Anwendungen kann es eine leere Hülle mit einem Script-Tag sein. Google rendert JavaScript zwar, aber das Rendering ist vom Crawling getrennt eingereiht und weder garantiert zügig noch vollständig — und andere Crawler, darunter die hinter Social-Vorschauen und mehreren KI-Systemen, rendern weit unzuverlässiger oder gar nicht.

Die Lösung ist, den Inhalt jeder Seite, die ranken soll, im ersten HTML auszuliefern. Server-seitiges Rendering, statische Generierung oder Prerendering erreichen das alle; welches Sie wählen, ist eine Architekturentscheidung, aber die Anforderung ist nicht verhandelbar, wenn Suche zählt.

Doppelte URLs sind der stille Killer

Anwendungen erzeugen URL-Varianten mühelos: Tracking-Parameter, Session-Kennungen, Sortier- und Filterkombinationen, Varianten mit und ohne Schrägstrich am Ende, Pfade in Großbuchstaben und dieselbe Seite über zwei Wege erreichbar. Für einen Crawler ist jede Variante eine eigene URL, und die Ranking-Signale verteilen sich darauf.

Drei Dinge lösen das. Jede Seite braucht ein selbstbezügliches Canonical, das auf die Version zeigt, die indexiert werden soll. Der Server sollte Varianten — nicht-kanonischer Host, falsches Protokoll, uneinheitlicher Schrägstrich am Ende — dauerhaft weiterleiten, statt sie alle auszuliefern. Und Parameter, die den Inhalt nicht verändern, sollten keine eigene indexierbare URL erzeugen.

Der häufigste Fehler hier ist ein Canonical, das der Sitemap widerspricht, oder eines, das auf eine URL zeigt, die weiterleitet. Beides gilt als widersprüchliches Signal, und Widersprüche werden gegen Sie aufgelöst.

Crawl-Budget ist real, sobald es Filter gibt

Für eine Website mit fünfzig Seiten ist Crawl-Budget nicht Ihr Problem. Für eine Anwendung mit Facettennavigation ist es eines der ersten, weil eine Handvoll Filter eine kombinatorische Explosion an URLs erzeugt und ein Crawler bereitwillig Wochen darauf verwendet statt auf die Seiten, die zählen.

Entscheiden Sie ausdrücklich, welche Filterkombinationen indexiert werden sollen — meist die mit echter Suchnachfrage, etwa eine Kategorie plus ein Merkmal — und machen Sie den Rest nicht indexierbar. Nutzen Sie robots.txt, um das Crawling wertloser Parametermuster zu unterbinden, und eine noindex-Anweisung für Seiten, die wegen ihrer Links crawlbar bleiben, aber nicht in den Ergebnissen erscheinen sollen.

Die beiden sind nicht austauschbar, und sie zu verwechseln ist häufig: Eine in robots.txt gesperrte Seite kann nicht gecrawlt werden, ihr noindex wird also nie gesehen, und die URL kann allein aufgrund externer Signale weiter in den Ergebnissen auftauchen. Soll eine Seite aus dem Index, muss sie crawlbar sein und noindex tragen.

Core Web Vitals, im Feld gemessen

Performance ist ein Rankingfaktor und, noch wichtiger, ein Conversion-Faktor. Der Fehler ist, gegen einen Laborwert auf einem schnellen Rechner zu optimieren statt gegen das, was echte Nutzer erleben.

Bei Largest Contentful Paint sind die üblichen Verdächtigen ein nicht vorgeladenes Bild, eine Schrift, die das Erscheinen von Text blockiert, und ein renderblockierendes Stylesheet. Laden Sie das Element vor, das das größte sein wird, nutzen Sie font-display, damit Text sofort in einer Ersatzschrift erscheint, und binden Sie die Stile für den ersten Bildschirm inline ein.

Cumulative Layout Shift kommt fast immer von Bildern und Einbettungen ohne Maßangaben, von Inhalten, die über bestehende Inhalte eingefügt werden, und von Webfonts, die beim Austausch den Umbruch ändern. Setzen Sie Breite und Höhe explizit, reservieren Sie Platz für alles, was später eintrifft, und gleichen Sie die Metriken der Ersatzschrift an.

Interaction to Next Paint ist das, woran Anwendungen am häufigsten scheitern, weil es die Reaktionsfähigkeit unter einem stark belasteten JavaScript-Hauptthread misst. Zerlegen Sie lange Aufgaben, verlagern Sie Arbeit vom Hauptthread, und seien Sie ehrlich, wie viel Framework auf einer Seite, deren Aufgabe das Anzeigen von Informationen ist, wirklich nötig ist.

Strukturierte Daten, die zueinander passen

Strukturierte Daten heben das Ranking nicht direkt, aber sie bestimmen, wie ein Ergebnis dargestellt wird und wie sicher eine Suchmaschine erkennt, worum es auf Ihrer Website geht. Der übliche Fehler ist nicht ungültiges Markup — es ist Markup, das sich über Seiten hinweg selbst widerspricht und dieselbe Organisation auf drei verschiedene Arten beschreibt.

Verwenden Sie einen identifizierten Organisationsknoten und lassen Sie jeden anderen Block darauf verweisen, statt das Unternehmen auf jeder Seite erneut zu beschreiben. Prüfen Sie im Build statt gelegentlich per Einfügen in ein Testwerkzeug, damit ein Rückfall den Build scheitern lässt, statt still auszuliefern.

Zeichnen Sie keine Bewertungen aus, die Sie nicht erhoben haben, keine Sterne, die Sie aus dem Nichts aggregiert haben, und keine FAQs, die auf der Seite gar nicht erscheinen. Das zieht manuelle Maßnahmen nach sich, und das Rich Result ist das Risiko nicht wert.

Internationalisierung, und wo sie meist schiefgeht

Wenn Sie mehrere Sprachen ausliefern, sagt hreflang den Suchmaschinen, welche Version sie zeigen sollen. Es gehört auch zu dem, was man am leichtesten unbemerkt falsch macht.

• Die Auszeichnungen müssen wechselseitig sein. Verweist die englische Seite auf die deutsche, muss die deutsche zurückverweisen, sonst wird das ganze Set ignoriert.
• Jede URL im Set muss 200 zurückgeben. Ein einziger 404 im Cluster untergräbt das Ganze.
• Das Canonical jeder Seite muss auf sie selbst zeigen, nicht auf die englische Version. Ein Canonical auf eine andere Sprache ist die Bitte, diese Seite aus dem Index zu nehmen.
• Nutzen Sie x-default als Rückfallebene, wenn keine Sprache passt.
• Übersetzen Sie eine Seite nicht maschinell und markieren sie als Sprachalternative, sofern sie nicht wirklich gut ist. Eine dünne oder verunglückte Übersetzung ist schlechter, als die Sprache gar nicht anzubieten.

Messung, die ein datenschutzorientiertes Web überlebt

Ein großer Teil der Besucher blockiert clientseitige Analyse, und der Anteil ist bei technischem Publikum am höchsten — also bei genau dem Publikum, das Sie bei einem Softwareprodukt am meisten verstehen wollen. Zahlen aus einem blockierten Tag sind nicht nur unvollständig, sie sind in einer Richtung verzerrt, die zählt.

Serverlogs und serverseitige Messung haben dieses Problem nicht, und sie zeigen Ihnen auch das Verhalten der Crawler, was clientseitige Analyse nie tut. Bei einer neuen Website ist es ein nützlicheres Signal, den Googlebot in den Logs eintreffen zu sehen, als jedes Dashboard — es sagt Ihnen, ob Sie ein Crawling- oder ein Ranking-Problem haben, und beide behebt man sehr unterschiedlich.

Die Search Console bleibt die wertvollste Quelle, weil sie die Suchanfragen meldet, für die Sie bereits erscheinen. Diese Anfragen sind ein besseres Content-Briefing als jedes Keyword-Tool, weil sie zeigen, wo Sie nah genug dran sind, dass eine kleine Verbesserung das Ergebnis verändert.

Eine sinnvolle Reihenfolge

1. Zuerst die Indexierbarkeit prüfenSearch Console, Abdeckungsbericht und ein Crawl der eigenen Website. Es bringt nichts, eine Seite zu optimieren, die ausgeschlossen ist.
2. Rendering behebenStellen Sie sicher, dass der Inhalt, der ranken soll, in der ersten HTML-Antwort steht.
3. Duplikate auflösenCanonicals, Weiterleitungen und Parameterbehandlung, damit sich Signale bündeln statt aufzuteilen.
4. Crawling steuernEntscheiden Sie, welche generierten URLs Indexierung verdienen, und stoppen Sie den Rest, bevor er Crawl-Budget verbraucht.
5. Dann die PerformanceFelddaten, keine Laborwerte, und in der Build-Pipeline festgeschrieben, damit sie nicht wieder verfallen.
6. Dann der InhaltGeschrieben für die Suchanfragen, bei denen die Search Console zeigt, dass Sie bereits nah dran sind.

Diese Reihenfolge ist wichtig. Inhalt für eine Seite, die der Crawler nicht sehen kann, ist vergeudete Arbeit, und Performance-Tuning an einer vom Index ausgeschlossenen Seite ändert überhaupt nichts.