Wie gut ist Google in der Lage, SPA-Webseiten zu indexieren und zu crawlen?

[FrazeColder]

Hallo zusammen,

Ich möchte unsere Webseite neu programmieren, bin mir aber unsicher, ob ich eine Vue.js SPA-Webseite oder eine Nuxt.js SSR-Webseite programmieren soll. Der große Vorteil einer SPA-Webseite ist, dass man ein App-ähnliches Gefühl bei der Nutzung der Webseite hat, was die User-Experience deutlich erhöht. Geht mal auf die mobile Version von airbnb.com mit dem Smartphone und benutzt die Webseite. Die Webseite fühlt sich nämlich an wie eine native App auf dem Handy und keine Webseite.

Der große Nachteil einer SPA-Webseite ist jedoch, dass sie vom Client gerendert wird (client-side rendering, auch CSR genannt). Das bedeutet, dass der Webserver nur ein leeres HTML-Skelett ausliefert und der eigentliche Inhalt mittels JavaScript "ausgefüllt" wird. Dies ist ein Problem für den Googlebot, da er sich wie ein echter Webbrowser verhalten muss, um den Inhalt zu lesen und zu verstehen.

Ich habe viele Artikel darüber gelesen, wie gut der Googlebot in der Lage ist, SPA-Webseiten zu verstehen. Einige empfehlen die Verwendung von SSR (server-side rendering), um SEO-Probleme zu vermeiden, andere sagen, es sei ein überschaubares Problem. In einigen Artikeln wird auch empfohlen, eine SPA-Webseite zu verwenden mit Pre-Rendering. Dies würde bedeuten, dass ein normaler Nutzer eine JavaScript-basierte Website sieht, die den Inhalt dynamisch "auffüllt", während der Googlebot mit einer statischen HTML-Version der Website bekommt.

Das ist zwar eine gute Idee, aber keine Lösung, die zu unserer Webseite passt, da Pre-Rendering nicht wirklich gut skalierbar ist und unsere Webseite ständig neue Unterseiten erhält (quasi ein Forum). Daher ist dies nicht wirklich eine Option.

Angesichts dessen würde ich gerne wissen, was ihr darüber denkt. Wird es möglich sein, eine SPA-Webseite zu erstellen, die in Bezug auf SEO genauso gut abschneidet wie eine traditionelle oder SSR-Webseite?

Leider hat Google in den letzten Jahren keine Angaben darüber gemacht, inwieweit sie in der Lage sind, SPA/CSR-Webseiten zu crawlen und indexieren. Daher bin ich mir ziemlich unsicher.

Bin gespannt auf eure Antworten!

Viele Grüße

 

[netzgestaltung]

Ich bin eigentlich nicht der Meinung, das sich SPAs besser anfühlen, auch am Beispiel airbnb. Das Problem sind immer viele Tabs. mmn genehmigen sich manche frameworks einfach zuviel cpu & ram/tab und alles wird endlos langsam nach kurzer zeit.

zur sicherheit wird hier beispielsweise das empfohlen:

You should at least use prerendering or server-side rendering to make SPA content easier to discover, understand, and index for search engines.

https://snipcart.com/blog/spa-seo

Ich würde außerdem SEO als Barrierefreiheitsthema definieren - also Zugänglichkeit für Suchmaschinen und darüber genauso nachdenken wie Tastaturbedienung oder Readerfunktion, Metadaten, etc.

 

[FrazeColder]

Wie kann ich denn SSR aktivieren, wenn ich eine SPA Seite habe?
SPA ist ja CSR. Kann ich auch eine SPA Seite mit SSR ausliefern?

Ergänzung (21. April 2023)

Es gibt eine Option namens Pre-Rendering. Mit dieser Technik können wir eine SPA-Webseite erstellen, aber der Googlebot oder jeder andere Crawling-Bot einer Suchmaschine erhält eine statische HTML-Version unserer SPA-Webseite. Dadurch ist es für den Bot viel einfacher, den Inhalt unserer Webseite zu lesen und zu verstehen. Es gibt einen Dienst namens prerender.io, der genau das für mich tun kann. Allerdings ist es ein kostenpflichtiger Dienst und ziemlich teuer.

Ich bin auch auf einige Plug-ins für Vue.js gestoßen, wie rendora und prerender-spa-plugin. Leider ist das prerender-spa-plugin veraltet und wurde seit Jahren nicht mehr aktualisiert. Ich habe leider auch keine neuere Version gefunden. Die Frage ist jedoch, ob Pre-Rendering überhaupt eine Option ist, da wir eine ziemlich dynamische Webseite haben, der ständig neue Unterseiten hinzugefügt werden?

Außerdem habe gelesen, dass Pre-Rendering nicht wirklich skalierbar ist. Ist Pre-Rendering daher also überhaupt eine Option für uns, wenn wir als neue Unterseiten erstellen?

 

[Joshinator]

Es gibt incremental SSG für sowas, dort kann man bestimmte Routen einzeln vorrendern.
Aber nicht jedes Framework kann das, Next.js kann das z.B., zu Nuxt 2 Zeiten gab es da mal Diskussionen zu, keine Ahnung ob Nuxt 3 das mittlerweile kann.

Mein SEO-Halbwissen sagt mir das Google 2 Typen von Bots hat, einen dummen Schnellen, und einen schlauen Langsamen der aber nur ein bestimmtes Crawling Budget hat.
Der schlaue Crawler ist eine headless Chrome Instanz, die führt dann auch Javascript aus.
Der stumpfe Crawler guckt sich nur HTML an, ist dafür aber wesentlich schneller.
Wenn oft neue Inhalte hinzukommen/geändert werden ist es nicht verkehrt es dem dummen Bot einfach zu machen.
Falls der keinen Inhalt findet guckt sich der schlaue Bot das später an. Wenn die Seite riesig ist und das Crawling Budget erreicht ist kann es ne Weile dauern bis die Inhalte so bei Google laden.

Will damit sagen, ohne SSR landet man auch bei Google, aber je nachdem wie schnell sich der Inhalt ändert kann es was dauern bis Google das indexiert hat.

Nochmal kurz zur Semantik:

• CSR, client side rendering, da wird das "leere HTML" gesendet
• SSR, server side rendering, da führt der Server das JS einmal pro Request aus und sendet so eine volle Seite, JIT style
• SSG, static site generation, da rendert der Server einmal alle existierende Routen vor, und liefert dann das statische HTML & JS aus

Wenn CSR wegen "schlechtem SEO" raus fällt, und SSG wegen zu vielen Routen*, dann kann man auch SSR nutzen.
Dafür muss aber der Server laufen, am besten mal die Nuxt Doku dazu lesen. Bei CSR & SSG hat man eben nur statische Dateien die man überall ohne overhead hosten kann.
Hab den Nitro-Server noch nicht großartig konfigurieren müssen, aber vielleicht kann da auch eigene Logiken einbauen sodass der Server nur Bots vorrendert.


*: Nuxt 2 war schlimmer als Nuxt 3, aber selbst Nuxt 3 ist noch recht langsam was SSG angeht.
Habe eine Nuxt 3 SSG App mit 85 URLs, ein Run dauert knapp 1min.
Svelte Kit ist da meiner Erfahrung nach schneller auch wenn ich keinen 1:1 Vergleich habe, keine Ahnung wie das bei React Meta-Frameworks aussieht.
Der Svelte Kit Server ist auch anpassbarer, da ist es recht einfach den Adapter (quasi den Server) anzupassen, oder komplett selbst zu schreiben weil es nur eine Express Middleware ist.
Da kann man dann per Express sagen "Bots => Prerender, User bekommen die leere SPA & JS".

 

[mibbio]

Ich bin auch auf einige Plug-ins für Vue.js gestoßen, wie rendora und prerender-spa-plugin. Leider ist das prerender-spa-plugin veraltet und wurde seit Jahren nicht mehr aktualisiert. Ich habe leider auch keine neuere Version gefunden.

SSR kann Vue.js doch eigentlich auch schon von sich aus, ganz ohne extra Plugins.

 

[FrazeColder]

Es gibt incremental SSG für sowas, dort kann man bestimmte Routen einzeln vorrendern.
Aber nicht jedes Framework kann das, Next.js kann das z.B., zu Nuxt 2 Zeiten gab es da mal Diskussionen zu, keine Ahnung ob Nuxt 3 das mittlerweile kann.

Mein SEO-Halbwissen sagt mir das Google 2 Typen von Bots hat, einen dummen Schnellen, und einen schlauen Langsamen der aber nur ein bestimmtes Crawling Budget hat.
Der schlaue Crawler ist eine headless Chrome Instanz, die führt dann auch Javascript aus.
Der stumpfe Crawler guckt sich nur HTML an, ist dafür aber wesentlich schneller.
Wenn oft neue Inhalte hinzukommen/geändert werden ist es nicht verkehrt es dem dummen Bot einfach zu machen.
Falls der keinen Inhalt findet guckt sich der schlaue Bot das später an. Wenn die Seite riesig ist und das Crawling Budget erreicht ist kann es ne Weile dauern bis die Inhalte so bei Google laden.

Will damit sagen, ohne SSR landet man auch bei Google, aber je nachdem wie schnell sich der Inhalt ändert kann es was dauern bis Google das indexiert hat.

Nochmal kurz zur Semantik:

• CSR, client side rendering, da wird das "leere HTML" gesendet
• SSR, server side rendering, da führt der Server das JS einmal pro Request aus und sendet so eine volle Seite, JIT style
• SSG, static site generation, da rendert der Server einmal alle existierende Routen vor, und liefert dann das statische HTML & JS aus

Wenn CSR wegen "schlechtem SEO" raus fällt, und SSG wegen zu vielen Routen*, dann kann man auch SSR nutzen.
Dafür muss aber der Server laufen, am besten mal die Nuxt Doku dazu lesen. Bei CSR & SSG hat man eben nur statische Dateien die man überall ohne overhead hosten kann.
Hab den Nitro-Server noch nicht großartig konfigurieren müssen, aber vielleicht kann da auch eigene Logiken einbauen sodass der Server nur Bots vorrendert.


*: Nuxt 2 war schlimmer als Nuxt 3, aber selbst Nuxt 3 ist noch recht langsam was SSG angeht.
Habe eine Nuxt 3 SSG App mit 85 URLs, ein Run dauert knapp 1min.
Svelte Kit ist da meiner Erfahrung nach schneller auch wenn ich keinen 1:1 Vergleich habe, keine Ahnung wie das bei React Meta-Frameworks aussieht.
Der Svelte Kit Server ist auch anpassbarer, da ist es recht einfach den Adapter (quasi den Server) anzupassen, oder komplett selbst zu schreiben weil es nur eine Express Middleware ist.
Da kann man dann per Express sagen "Bots => Prerender, User bekommen die leere SPA & JS".

Ich muss sagen, so ganz verstehe ich es nicht. Also ist es möglich eine SPA Anwendung sowohl als CSR, SSR und SSG Webseite auszuliefern?

Falls ja, welcher Weg wäre hier aus SEO Sicht der geeignete und welcher ist auch mit vielen Routes machbar?

Ergänzung (21. April 2023)

SSR kann Vue.js doch eigentlich auch schon von sich aus, ganz ohne extra Plugins.

Das stimmt, Nuxt.js erledigt beim SSR aber sehr viel schon für dich und du musst dir weniger Gedanken über die Konfiguration und so machen

 

[Joshinator]

Also ist es möglich eine SPA Anwendung sowohl als CSR, SSR und SSG Webseite auszuliefern?

Jain, CSR und SSG sind toll weil der Server nur Dateien servieren muss.
Bei CSR ist es eben nur eine leere index.html und Javascript-Bundles, bei SSG sind es mehrere `index.html`s in Ordnern und Javascript-Bundles.
"Skaliert" schöner weil diese statischen Dateien überall liegen können, egal ob nen einfaches Webhosting oder mehrere CDNs.

Bei SSR bearbeitet ein Server jeden Request, bei Nuxt ist das Nitro (also Nodejs).
Ich habe Nitro noch nie konfigurieren müssen, aber prinzipiell kann man einem Server ja sagen:

• guck in den Useragent
• wenn Bot => lass Nitro die Nuxt App SSR für diesen Request rendern
• wenn User => servier sofort die statische leere HTML Seite

Bei Svelte Kit ist das recht einfach, aber keine Ahnung wie tief man in Nitro bei Nuxt eingreifen kann.
Die Doku ist da nicht ganz so detailliert wie bei Svelte Kit.

Wenn man Nitro konfigurieren kann wäre das vielleicht die elegantere Lösung, alles an einer Stelle und du musst nur einen Dienst beobachten.
Aber die Prerender-Dienste kann man auch selbst hosten, die nutzte auch alle nur Puppeteer & Co um eine Website headless zu laden damit HTML ausgespuckt werden kann.


Lange Rede kurzer Sinn, sehe 2 einfache Optionen und eine komplexere:

Nuxt CSR only
Nginx/Apache leitet Bots an einen Prerender-Dienst (evtl. an einen der auf deinem Server läuft), alle anderen bekommen leeres HTML mit Javascript.
Nachteil ist das du einen headless Browser betreibst, hat natürlich overhead und die Bots warten etwas länger auf die Antwort (für SEO nicht wirklich relevant).
Und oben drauf bekommen die User leere Seiten, die CWV werden also meh sein (für SEO etwas relevant).

Nuxt SSR
Jeder Request wird von Nuxt vorgerendert.
Nachteil ist, der Server arbeitet bei jedem Requests etwas mehr um das JS auszuführen.
Dafür bekommen auch User direkt Inhalte ohne erst auf Javascript zu warten.
Der Nuxt Server kann auch Caching über eine einfache Config Datei, so müsste nicht jeder Request immer komplett abgearbeitet werden.

Custom Nuxt Server
Das wäre die Combi aus CSR only & SSR ohne einen extra Prerender-Dienst.
User-Agent wird geprüft, wenn User leeres HTML liefern; bei Bots Nitro ganz normal SSR laufen lassen.
Da müsste man sich genauer mit Nitro beschäftigen, es gibt wohl Plugins mit denen man Nitro erweitern kann, aber das Beispiel ist was mager.

 

[FrazeColder]

Erst einmal vielen vielen Dank für den ganzen Text! Ich hätte dazu zwei Nachfragen.

1. Wie kann ich einen Nginx/Apache Server so konfigurieren, dass ein Bot an einen Pre-Render-Dienst oder meinen eigenen Pre-Render-Dienst geschickt werden?

2. Ich kann in Nuxt ja verschiedene Modis einstellen und auch verschiedene Modis für unterschiedliche Routes. Welchen Modus müsste ich denn nun einstellen, um eine SPA Anwendung zu erstellen, die aber SSR ausgeliefert wird (zumindest beim ersten Mal laden)?

3. Wie viele Ressourcen würde ein Nuxt SSR Server so verschlingen? Wenn da pro Tag im Schnitt 10.000 User auf der Seite sind, wird die Seite ja bei SSR 10.000 mal vom Server geredendert.

 

[Joshinator]

Wie kann ich einen Nginx/Apache Server so konfigurieren, dass ein Bot an einen Pre-Render-Dienst oder meinen eigenen Pre-Render-Dienst geschickt werden?

Steht in den Dokus vom jeweiligem Render-Service, hier z.B. für Prerender.
Eigentlich recht selbsterklärend, Nginx lässt ein Regex gegen den UA laufen und proxied die dann zur hinterlegten URL.

Ich kann in Nuxt ja verschiedene Modis einstellen

Nuxt läuft standardmäßig in SSR, du musst Nuxt explizit sagen ob einzelne (oder alle) Seiten anders behandelt werden sollen. Was welche Optionen tun ist in der Doku ja sauber erklärt.

Und das gilt alles nur für den ersten Aufruf vom Nutzer, in allen Modi wird die Nuxt SPA im Browser hydrated und dann nimmt Javascript über.

Wie viele Ressourcen würde ein Nuxt SSR Server so verschlingen? Wenn da pro Tag im Schnitt 10.000 User auf der Seite sind, wird die Seite ja bei SSR 10.000 mal vom Server geredendert.

Auf jeden Fall weniger Ressourcen als ein voller headless Browser, Nuxt generiert bei mir per SSG eine Seite in ~100ms. Keine Erfahrung wie Nuxt 3 in SSR performt, aber weit neben SSG wirds nicht liegen.

Das hängt auch stark von den API Calls ab, wenn 10.000 User deine API in die Knie zwingt dann muss auch Nuxt länger auf die Antworten warten.
Und wenn Nuxt den Server ins schwitzen bringt, dann kann man recht einfach einen weiteren Server mit Nuxt starten und mit einem Load Balancer die Requests zwischen zwei Kisten aufteilen. Solange deine API nicht an den Nuxt Server gekettet ist.
Komm aber erstmal zu 10.000 täglichen Nutzern, dann wirst du auch etwas an Erfahrung gesammelt haben.

 

[FrazeColder]

Dank dir erst einmal für die ganze Hilfestellung. Also das zeigt mir, dass ich mich noch ein wenig tiefer in die Thematik einarbeiten muss.

Ich hätte nun aber abschließend noch zwei Fragen an dich, nachdem ich mir das Key Concept der Rendering Modis durchgelesen habe: https://nuxt.com/docs/guide/concepts/rendering

1. Für mich scheint die Version Nuxt SSR, die du oben vorgestellt hast, für den ersten Schritt die beste Lösung. Denn so kann ich eine sehr interaktive und nutzerfreundliche SPA bauen, bei der sowohl die Bots als auch die User sofort eine HTML-Seite bekommen, die Sie nutzen können und die Bots crawlen und indexieren können.

Zudem muss ich mich nicht um einen weiteren Server oder den Overhead eines headless Chrome Browsers kümmern. Und wie du sagst, ist es nicht so, dass das Mega ressourcenintensiv ist. Denkst du, das ist eine gute Idee, kannst du mir sagen, wie ich meine Nuxt Config Datei konfigurieren muss und wie ich überprüfen kann, dass Nuxt auch direkt eine volle HTML-Seite inkl. Inhalt ausgibt?

2. In deiner letzten Antwort hast du noch von SSG gesprochen. Das ist nicht, was ich brauche und möchte, da meine Seiten ja dynamische Inhalte haben und zusätzlich pro User unterschiedlich. SSG könnte man für Blogs o.ä. hervorragend verwenden, da deren Inhalte sich nicht so häufig ändern. Zudem lässt sich SSG nicht sooo gut mit vielen dynamischen Routen skalieren - habe ich das richtig verstanden?

 

[Joshinator]

wie ich meine Nuxt Config Datei konfigurieren muss und wie ich überprüfen kann, dass Nuxt auch direkt eine volle HTML-Seite inkl. Inhalt ausgibt

SSR ist bei Nuxt Standard, die Config muss nur angepasst werden wenn du kein SSR nutzen willst.
Überprüfen kannst du das indem du CTRL + U drückst, da zeigt dir der Browser an welches HTML der Server sendet.

In deiner letzten Antwort hast du noch von SSG gesprochen. Das ist nicht, was ich brauche

Ich habe nur von SSG gesprochen weil du nach Performance gefragt hast. Ich habe nur eine Nuxt SSG Seite, kenn also nur die Zahlen.
SSG und SSR führen recht ähnlichen Code aus, der Server soll ja bei beiden die Seite vorrendern.
Wenn bei mir per SSG eine Seite in ~100ms gebaut wird, dann sollte SSR nicht unwesentlich schneller/langsamer sein.
Und ein Großteil der ~100ms auf meiner Seite kommt von 3-4 `useAsyncData`s, ist also nicht so das Nuxt 100ms nur am Rechnen ist, nen guter Teil davon wartet einfach auf API Antworten.

 

[FrazeColder]

Dank dir! Du hast mir sehr geholfen!