JavaScript-SEO: Inhalte, die Google zuverlässig sieht

Wie Google JavaScript-Seiten verarbeitet

Google geht in Phasen vor: Die Seite wird abgerufen, kommt in eine Warteschlange zum Rendern und erst danach wird JavaScript ausgeführt. Erst dann sind meine dynamischen Inhalte für den Crawler sichtbar. Ich vermeide dieses Verzögerungsrisiko gerne.

Andere Suchmaschinen oder soziale Netzwerke, in denen ich meine Inhalte teile, rendern oft gar nicht oder nur eingeschränkt. Vorschauen beim Teilen hängen daher meist vom vorhandenen HTML ab.

Rendering-Strategien im Überblick

Beim Client-Rendering wird alles im Browser erzeugt, während beim Server-Rendering der Server fertiges HTML liefert. Statische Seiten erzeuge ich vorab, was sie sehr schnell macht. Welche Strategie passt, mache ich davon abhängig, wie oft sich meine Inhalte ändern.

• Für öffentliche, redaktionelle Inhalte wähle ich bevorzugt Server-Rendering oder eine statische Auslieferung.
• Bei internen Dashboards oder Nutzerbereichen sehe ich beim Client-Rendering in der Regel kein Problem.
• Für personalisierte Elemente lade ich Inhalte zwar dynamisch nach, stelle aber sicher, dass die Kerninhalte im statischen HTML stehen.

Typische Stolperfallen

Ich achte darauf, keine Links ohne href-Attribut zu nutzen, da Google diese nicht erkennt. Ich verwende immer ein <a href> mit direkter URL und vermeide Hash-Adressen für verschiedene Inhalte, da ich echte Pfade für besser halte.

Ich vermeide weitere Fehler, wie Titel oder Meta-Beschreibungen, die erst nach dem Rendern erscheinen, Inhalte hinter Scroll-Ereignissen oder blockierte JavaScript-Dateien. Ein Cookie-Banner, das Inhalte erst nach einem Klick rendert, kann meine Seite für Crawler zudem unlesbar machen.

So prüfen Sie Ihre Seite

Ich nutze das URL-Prüftool, um das gerenderte HTML zu kontrollieren. Wenn dort Text fehlt, den ich im Browser sehe, wird dieser nicht erfasst. Ich prüfe im Quelltext, ob die wichtigsten Informationen bereits statisch vorhanden sind.

Ich bespreche mit meinem Team, ob ein Wechsel zum Server-Rendering für öffentliche Seiten Sinn ergibt, da dies für kleinere Projekte oft ein gut planbarer Fortschritt ist.

Umsetzung: Rendering-Test in vier Schritten

Schritt eins: Ich rufe die Seite auf und kopiere einen markanten Satz aus dem Text. Schritt zwei: Ich prüfe den Quelltext. Steht der Satz dort nicht, wird er erst im Browser generiert. Schritt drei: Ich prüfe die URL im URL-Prüftool und vergleiche das gerenderte HTML. Schritt vier: Ich wiederhole das bei dynamischen Seiten oder Filtern.

Ich interpretiere das Ergebnis nüchtern. Steht der Text im Quelltext, ist das Risiko gering. Erscheint er nur im gerenderten HTML, ist er für Google erreichbar, aber oft mit Verzögerung. Fehlt er in beiden, ist er für Suchmaschinen unsichtbar. Diese Prüfung dauert eine halbe Stunde und zeigt mir, ob ein Umbau nötig ist.

• Ich nutze einen markanten Satz aus dem Text als Prüfmarke.
• Ich vergleiche den Quelltext mit dem gerenderten HTML der Seite.
• Ich teste dynamische Seiten und Filter getrennt von statischen Inhalten.

Fragen an Ihr Entwicklungsteam

Erstelle ich eine Seite mit einem JavaScript-Framework, prüfe ich vier Punkte: Ist der Haupttext im HTML enthalten? Haben Titel und Beschreibung individuelle Werte vor dem Ausführen des Skripts? Sind Navigationspunkte echte Links? Gibt die Seite bei ungültigen Adressen korrekt einen 404-Statuscode aus?

Diese Fragen beantworte ich zügig und beuge so vielen typischen Fehlern vor. Wo es dennoch hakt, lässt sich oft gezielt nachbessern, ohne die technische Grundlage der Webseite grundlegend umbauen zu müssen.

Häufige Fragen zu JavaScript SEO