JavaScript-SEO: Stellen Sie sicher, dass die Links beim Rendern erhalten bleiben
Google rendert JavaScript mit einem Evergreen-Chromium. Das Problem ist selten das Rendern selbst. Es sind Links, die nie zu Anchors werden, und Seiten, die von einem Zustand abhängen, den ein Crawler nicht hat.
ArchiLinks-Research-Team ·
Was ein Crawler sieht
Googlebot nutzt seit Mai 2019 ein Evergreen-Chromium. Damit ist die Frage geklärt, ob es modernes JavaScript ausführen kann.
Die praktischen Risiken sind älterer Natur: Das Rendern erfolgt nach dem Crawlen und kann verzögert sein, Inhalte hinter Klicks oder Logins erscheinen nie, und ein Link, der aus einem onclick-Handler auf einem div-Element besteht, ist kein Link. Bevor Sie Backlinks auf Website-Seiten prüfen, die Sie kürzlich auf ein React-Frontend umgestellt haben, stellen Sie sicher, dass diese Seiten ihren Inhalt in der Rohantwort oder im gerenderten HTML anzeigen.
SSR, SSG, CSR: Was ändert sich für Links?
| Ansatz | Inhalte in der ersten Antwort | Interne Links als Anchors | Gut für |
|---|---|---|---|
| SSR (Next.js, Nuxt) | Ja | Ja, wenn Sie echte Anchors verwenden | Öffentliche Seiten mit sich ändernden Daten |
| SSG oder Prerendering | Ja | Ja | Dokumentationen, Blogs, Marketing-Seiten |
| CSR-Single-Page-App | Nein, leere Hülle | Erst nach dem Rendern | Dashboards hinter einer Anmeldung |
| Hybrid (SSR-Startseite, CSR-App) | Pro Route | Pro Route | Die meisten Produkte mit einer öffentlichen Seite |
Test 1: Rohes HTML versus gerendertes HTML
Wenn die wichtigsten Links in der ersten Antwort erscheinen, ist die Frage geklärt. Wenn nicht, vergleichen Sie mit einem Headless-Rendern.
# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20
# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '
Wo externe Links ins Spiel kommen
Ein Rendering-Bug verbirgt Ihre Inhalte. Er löscht nicht die Links, die andere Sites Ihnen bereits gegeben haben.
Führen Sie nach einem Umzug zu Next.js, Vite oder einem Headless-CMS toppages für den Host aus und testen Sie die 20 meistverlinkten URLs auf Status, Canonical und sichtbaren Inhalt. Tun Sie dies zuerst. Wenn eine Seite mit 40 verlinkenden Domains eine leere Hülle oder einen clientseitigen 404-Fehler zurückgibt, beheben Sie dies vor allem anderen, denn dort landet Ihre Authority. Die Interne vs. externe Link-Equity-Seite zeigt, wie Sie diese Liste mit Ihren internen Links vergleichen, und die Migrations-Checkliste integriert den Test in einen Launch-Plan.
Frameworks sind weniger wichtig als Disziplin. Express mit einer Template-Engine, ein WordPress-Theme und ein Next.js-App-Router können alle crawlbare Links ausliefern. Jeder kann auch fehlschlagen, wenn ein Team Anchors ausliefert, die erst nach einem Klick existieren.
Link- und Rendering-Checkliste
- Navigation und Paginierung verwenden
<a href>, keine Click-Handler auf anderen Elementen. - Jede Route gibt einen echten Statuscode zurück. Soft-404-Bildschirme müssen 404 zurückgeben.
- Ein
noindexoder Canonical, das durch JavaScript injiziert wird, muss mit dem in der Serverantwort übereinstimmen. - Fallback-Inhalte in der ersten Antwort sind die echte Seite, kein Spinner, den Google indexieren könnte.
- Auth-Code leitet Crawler auf öffentlichen Routen nicht um.
- Für das Rendern benötigte CSS- und JS-Dateien sind in robots.txt nicht blockiert.
- Lazy Loading verwendet IntersectionObserver oder native Ladeattribute, keine Scroll-Events.
Die Beweise in der Search Console lesen
Die Search Console beantwortet die meisten Rendering-Fragen, wenn Sie den richtigen Bericht abfragen. Nutzen Sie die URL-Inspektion und dann „Gecrawlte Seite anzeigen“.
Vergleichen Sie drei Dinge: das von Google abgerufene HTML, den Screenshot und die Ressourcen, die nicht geladen werden konnten. Eine Seite, die in Ihrem Browser vollständig aussieht, im Screenshot aber leer ist, wird normalerweise durch einen Skriptfehler oder eine blockierte Ressource verursacht, und die Lösung liegt in Ihrem Build, nicht in Ihrem Inhalt.
Berücksichtigen Sie die Verzögerung. Eine Änderung, die Sie heute ausliefern, erscheint im Inspektionstool erst, nachdem Google die URL erneut gecrawlt hat, was Tage dauern kann.
Wann sich SSR lohnt
Öffentliche Seiten, die ranken müssen: Ja. Dashboards: Nein.
Wenn eine Route organischen Traffic anziehen soll, liefern Sie den Inhalt in der ersten Antwort aus. Wenn sie hinter einer Anmeldung liegt, vermeiden Sie die Komplexität. Wählen Sie pro Route und nicht pro Projekt und dokumentieren Sie die Entscheidung, damit der nächste Entwickler sie nicht rückgängig macht.
- Verwenden Sie den Rich-Results-Test und die URL-Inspektion, um die gerenderte Ausgabe zu vergleichen.
- Testen Sie mit dem Live-Test der Search Console nach jedem Framework-Upgrade.
Ist Server-Rendern erforderlich, oder reicht Prerendering aus?
Server-Rendern ist optional. Es ist eine Möglichkeit, dafür zu sorgen, dass die erste Antwort das enthält, was ein Crawler benötigt. Viele öffentliche Seiten erreichen dies mit Prerendering, einem statischen Build oder einem Server-Render für die relevanten Seiten und lassen die angemeldeten Bereiche außen vor.
Nehmen wir an, Ihre Produktseiten und Dokumentationen sind öffentlich, während das Dashboard hinter einer Anmeldung liegt. Prerendern Sie die erste Gruppe. Lassen Sie das Dashboard clientseitig. Die öffentlichen Seiten tragen dann ihre Links in der ersten Antwort, und das Dashboard kann so komplex sein, wie es sein muss.
Nur die Startseite prerendern
Das Prerendering der Startseite löst den ersten Crawl, lässt aber jede andere Route im Browser warten. Wenn die Startseite auf clientseitig gerenderte Kategorien verlinkt, hängen die Links auf diesen Seiten immer noch vom Rendern ab. Prüfen Sie jede Vorlage, die Sie besitzen, nicht nur die Startseite.
Führen Sie eine kurze Liste öffentlicher Routen mit ihrer Render-Methode. Die Liste zeigt Lücken schneller auf als ein Crawl-Bericht.
Ändert Server-Rendern die lokale Sichtbarkeit?
Server-Rendern kann verändern, wie schnell der erste Inhalt erscheint, und Leser spüren das. Es macht eine Seite nicht automatisch für eine lokale Abfrage relevant. Diese Signale stammen aus dem Seitengehalt, den Unternehmensdaten und den Links, die darauf verweisen.
Betrachten Sie das Rendern als die Art und Weise, wie diese Signale für einen Crawler lesbar werden, und messen Sie die Links separat mit der API.
Vite- und React-Apps, die eine einzige Hülle ausliefern
Ein Vite-Build, der für jeden Pfad eine einzige HTML-Hülle ausliefert, verlagert die gesamte Arbeit auf den Client. Eine solche App kann zwar für einige Abfragen ranken, aber jede öffentliche Route benötigt einen Plan: Prerendern Sie sie, rendern Sie sie auf dem Server oder akzeptieren Sie den Verlust und notieren Sie dies.
Bevor Sie Backlinks auf Website-Routen nach einem Rebuild prüfen, entscheiden Sie, wie jede öffentliche Route ihren Inhalt erhält. Andernfalls zeigen die Linkdaten externe Links, die auf Seiten landen, die nichts enthalten.
Testen, ob eine Route ihre Links anzeigt
Zwei Tests beantworten die meisten Fragen. Die Rohantwort zeigt, was ein Crawler erhält, bevor ein Skript ausgeführt wird. Das gerenderte DOM zeigt, was ein Browser danach aufbaut. Ein Link, der nur im zweiten erscheint, ist immer noch ein Link, hängt aber davon ab, dass das Rendern reibungslos verläuft.
Den Live-Test in der Search Console lesen
Führen Sie den Live-Test aus der URL-Inspektion eine Route nach der anderen durch. Betrachten Sie das gerenderte HTML und dann die Liste der Ressourcen, die nicht geladen werden konnten. Ein blockiertes Skript kann einen gesamten Navigationsblock entfernen, und die Seite wirkt dünn, ohne einen sichtbaren Fehler anzuzeigen.
Wiederholen Sie den Test nach einem Framework-Upgrade, da ein neuer Standard verändern kann, ob Links vor oder nach der Ausführung eines Skripts gerendert werden. Die Anleitung Nicht indizierte Seiten behandelt, was zu tun ist, wenn eine gerenderte Seite dennoch nicht indexiert wird.
Wenn eine Route rendert, aber der Inhalt ein Spinner ist
Der Fallback in der ersten Antwort ist wichtiger, als die meisten Teams erwarten. Ein Spinner oder ein leerer Container bedeutet, dass die Seite zu diesem Zeitpunkt keinen Text für den Crawler enthält. Geben Sie Titel, Einleitung und die wichtigsten Links in der ersten Antwort aus, auch wenn eine detaillierte Liste später lädt.
Ein Fallback, der die echte Seite ist, kann einfach bleiben. Seine einzige Aufgabe ist es, den Inhalt zu halten, bis der Rest ankommt.
Eine clientseitige Site umziehen, ohne Links zu verlieren
Listen Sie die Routen mit externen Links auf
Führen Sie toppages für den Host aus und notieren Sie die Top-50-URLs. Testen Sie diese Routen zuerst, vor den Codeänderungen, damit Sie wissen, was der Rebuild beibehalten muss.
Vergleichen Sie die Roh- und gerenderte Ausgabe
Prüfen Sie für jede Route das Roh-HTML und das gerenderte DOM im alten und im neuen Build. Notieren Sie alle Links, die in der einen, aber nicht in der anderen Version existieren.
Click-Handler durch Anchors ersetzen
Verwandeln Sie die Navigation in echte Anchors mit einer richtigen Adresse. Geschwindigkeitsarbeiten können einen Sprint warten, während ein fehlender Anchor der Route ihren Weg in die Site kostet.
Den Test nach dem Release wiederholen
Eine Woche nach dem Release führen Sie den Live-Test auf denselben Routen durch und vergleichen Sie die Ergebnisse mit den früheren. Unterschiede zeigen, wo der Rebuild die Ausgabe verändert hat.
Statuscodes und Redirects in einer clientseitigen App
Eine Single-Page-App zeigt oft einen „Nicht gefunden“-Bildschirm, während der Server den Status 200 zurückgibt. Google kann eine solche Seite als Soft-404 behandeln, und die externen Links, die auf die fehlende URL verweisen, leisten dann wenig. Die Lösung liegt auf dem Server.
Unbekannte Routen, die dennoch 200 zurückgeben
Geben Sie für jede nicht existierende Route einen echten 404 vom Server zurück und behalten Sie den „Nicht gefunden“-Bildschirm in der App für Besucher bei, die über eine clientseitige Route ankommen. Wo ein Ersatz existiert, senden Sie stattdessen einen 301.
Prüfen Sie nach jedem Release einige erfundene Adressen auf dem Live-Host. Der Antwortcode ist das, was man lesen muss, nicht die Seite, die Sie im Browser sehen.
Redirects, die im Browser ausgeführt werden
Ein Redirect, der nach dem Laden der Seite feuert, beispielsweise durch das Lesen eines URL-Parameters in einer Komponente, ist etwas anderes als ein Server-Redirect. Ein Crawler kann die erste Antwort indexieren, bevor der Redirect ausgeführt wird. Wenn eine Route dauerhaft verschoben wurde, geben Sie einen 301 vom Server zurück und behalten Sie die Parameter bei, die den Inhalt ändern. Das Redirect-Map-Rezept zeigt, wie man diese Regeln testet.
