Ist meine Single-Page-Anwendung SEO-freundlich?

Ein notorisch undurchsichtiger Bereich der Entwicklung von Single-Page-Anwendungen (SPA) ist SEO. Abhängig davon, wen Sie fragen, ist das Suchmaschinen-Crawling von Client-gerenderten Inhalten entweder absolut in Ordnung, gut, solange es synchron ist oder überhaupt nicht in Ordnung.

Aufgrund der Verwirrung, die durch all diese widersprüchlichen Ratschläge verursacht wird, sehe ich regelmäßig die Frage „Ist mein Vue SPA für SEO geeignet?“ kommen an Orten wie der Vue.js-Entwickler-Facebook-Gruppedas Vue.js-Foren und r/vuejs auf Reddit.

In diesem Artikel stellen wir die gängigen Meinungen in Frage, führen einige grundlegende Tests durch und versuchen, mit einigen vernünftigen Ratschlägen zum Aufbau SEO-freundlicher SPAs abzuschließen.

Hinweis: Dieser Artikel wurde ursprünglich veröffentlicht hier im Vue.js-Entwicklerblog am 09.04.2018.

Das Problem mit vom Client gerenderten Inhalten

Die Standardimplementierung einer Single-Page-App stellt dem Browser eine Seiten-„Hülle“ ohne sinnvollen Inhalt bereit. Stattdessen werden die Inhalte per AJAX on demand vom Server geladen und dann per JavaScript der Seite hinzugefügt.

Dies ermöglicht es einem Benutzer, die „Seiten“ einer SPA-Site ohne Seitenaktualisierung anzuzeigen, wodurch theoretisch die UX verbessert wird.

seo_01.png

Während diese Architektur für menschliche Benutzer funktioniert, die die Seite in einem Browser anzeigen, was ist mit Suchmaschinen-Crawlern? Können Crawler JavaScript ausführen? Wenn ja, warten sie, bis die AJAX-Aufrufe abgeschlossen sind, bevor sie die Seite crawlen?

Es ist wichtig, dies zu wissen, da es bestimmen kann, ob der Inhalt der Website von einer Suchmaschine indexierbar ist oder nicht, und ebenso wichtig, wie gut der Inhalt eingestuft wird.

Googlebot

Da Google das ist führende Suchmaschine global sollte sich unsere Untersuchung auf den Googlebot, den Crawler der Google-Suchmaschine, konzentrieren.

In den Anfängen des Webs hat der Googlebot nur den statischen HTML-Code einer Seite gecrawlt. Es war 2014 angekündigtdass der Googlebot nun jedoch versuchen würde, JavaScript zu rendern, bevor er mit dem Crawlen beginnt.

Um Probleme beim Rendern einer JavaScript-modifizierten Seite zu beheben, stellte Google Webmastern die Abrufen wie durch Google Tool, das eine Momentaufnahme dessen zeigt, was der Googlebot unter einer bestimmten URL sieht.

Ein verbreiteter Mythos ist, dass der Googlebot kein asynchrones JavaScript crawlt. Dieser Artikel hat großartige Arbeit geleistet, um es zu sprengen. TLDR; Der Googlebot wartet mindestens 20 Sekunden, bis asynchrone Aufrufe abgeschlossen sind!

So sieht der Googlebot ein SPA

Das grundlegende Vue.js-SPA-Beispiel ist die Sehen Sie sich den HackerNews-Klon 2.0 an. Dies ist ein Open-Source-Projekt, das vom Vue-Team bereitgestellt wird, um die vollen Möglichkeiten von Vue und effektive Designmuster zu demonstrieren.

Ich habe diese App in einer Heroku-Instanz bereitgestellt und über Fetch As Google ausgeführt. Im Bild unten zeigt der Screenshot links, wie der Googlebot es gesehen hat, und der Screenshot rechts zeigt, wie ein Benutzer es sehen würde. Sie scheinen identisch zu sein.

seo_02.png

Entfernen des serverseitigen Renderns

Eines der Hauptmerkmale des Vue HackerNews Clone 2.0 ist serverseitiges Rendering (SSR). Dies bedeutet, dass im Gegensatz zu einem einfacheren SPA der Inhalt für jede Seite auf dem Server gerendert und dem Browser bei jedem Seitenladen bereitgestellt wird, genau wie bei statischem HTML.

Was wir jedoch zu verstehen versuchen, ist, wie der Googlebot vom Client gerenderte Inhalte sieht. Aus diesem Grund habe ich SSR ausgeschaltet und den Test erneut durchgeführt:

seo_03.png

Selbst bei reinem Client-Rendering hatte der Googlebot keine Probleme, den Inhalt zu sehen. Ich habe auch ein paar Tage gewartet, um zu sehen, ob Google die App indiziert hat. Es hatte:

seo_04.png

Aber warte…

Dieser Test scheint zwar alle Bedenken bezüglich von Clients gerenderter Inhalte auszuräumen, aber es gibt einige Gründe, warum Sie ihm nicht voll vertrauen sollten:

  1. Wie alle JavaScript-Engines ist der Googlebot nicht unfehlbar und es kann Randfälle geben, in denen er Ihre Seite nicht darstellen kann
  2. Nur weil eine Seite indexiert werden kann, heißt das noch lange nicht, dass sie gut rankt

Seien Sie JavaScript gegenüber skeptisch

Der Googlebot hatte keine Probleme beim Rendern von Vue HackerNews. Aber wir sollten nicht schlussfolgern, dass es JavaScript so fehlerfrei rendern kann. Googles Ankündigung von 2014 zum JavaScript-Rendering machte deutlich, dass es keine Garantie geben würde, obwohl die meisten Entwickler dies anscheinend übersehen haben.

Genau wie ein Browser muss Googlebot über eine JavaScript-Engine mit einer bestimmten Untergruppe von implementierten Webstandards und ES-Funktionen und ihren besonderen Eigenheiten für deren Implementierung verfügen.

Entsprechend Dieses Video von den Google-Entwicklern Addy Osmani und Rob Dodson (veröffentlicht im November 2017) basiert der Googlebot derzeit auf Chrome 41. Es gibt viele neue APIs, die seit Version 41 veröffentlicht wurden, und wenn Sie eine davon verwenden, wäre der Googlebot vermutlich nicht in der Lage, Ihre Seite zu rendern und zu indizieren.

Sie denken vielleicht, dass dies ein triviales Problem ist, da Sie solche Funktionen für ältere Browser sowieso transpilieren oder polyfillen müssten. Der Punkt ist jedoch, dass Sie nicht blind darauf vertrauen sollten, dass Ihre App von jedem Such-Crawler korrekt ausgeführt wird, genauso wenig wie Sie blind darauf vertrauen würden, dass Ihre App von jedem Browser korrekt ausgeführt wird.

Optimierung

Vergessen Sie nicht, dass das „O“ in „SEO“ für „Optimierung“ steht. Von einer Suchmaschine indiziert zu sein, reicht nicht aus; Wir möchten, dass unsere Websites auch gut ranken. Abrufen Da Google uns sagt, wie eine Seite gesehen wird, aber nicht, wie die Seite im Vergleich zur Konkurrenz abschneidet.

Es gibt einen interessanten Kommentar zu dem Artikel SEO vs. Reagieren: Webcrawler sind schlauer als Sie denken erstellt von SEO-Experten Barry Adams. Zum Thema wie Suchmaschinen SPAs ranken er sagte:

“Was passiert, wenn Sie React ohne serverseitiges Rendering verwenden, ist, dass der Crawler auf der allerersten Seite anhält, weil er keine Hyperlinks sehen kann, denen er folgen könnte … Das macht den Crawl-Prozess unglaublich langsam und ineffizient. Und das ist der Grund für Websites Auf React (und ähnlichen JavaScript-Plattformen) basierende Websites schneiden in Google schlechter ab als Websites, die dem Crawler hauptsächlich reines HTML liefern Auf solchen Websites kann Google die Crawl-Priorität einzelner Seiten viel besser auswerten.”

Obwohl er dafür keine Beweise liefert, scheint es mit der Philosophie anderer Ranking-Bestimmungen wie im Einklang zu stehen Seitengeschwindigkeit.

Was tun, wenn SEO kritisch ist?

Unter dem Strich können Sie sich, wenn SEO entscheidend ist, nicht auf das Client-Rendering Ihres SPA verlassen und müssen sicherstellen, dass Inhalte in Ihre Seiten aufgenommen werden.

Dies bedeutet jedoch nicht, dass Sie die SPA-Architektur aufgeben müssen. Es gibt zwei Techniken, serverseitiges Rendern und Vorrendering, mit denen beide das gewünschte Ergebnis erzielen können.

Serverseitiges Rendern

Beim serverseitigen Rendering (SSR) wird eine Seite vom Webserver als Teil des Serveranforderungs-/Antwortzyklus gerendert. Im Fall von Vue.js und anderen ähnlichen Frameworks erfolgt dies durch Ausführen der App gegen ein virtuelles DOM.

Der Status des virtuellen DOM wird in eine HTML-Zeichenfolge konvertiert und dann in die Seite eingefügt, bevor sie an den Client gesendet wird. Wenn die Seite den Browser erreicht, wird die JavaScript-App nahtlos über den vorhandenen Inhalt montiert.

SSR garantiert, dass Ihre Seite crawlerfreundlich ist, da der Seiteninhalt vollständig ist, unabhängig davon, wie oder sogar ob der Crawler JavaScript ausführt.

SSR hat jedoch seine Nachteile:

  • Sie müssen Ihren Code so gestalten, dass er “universal” ist, dh er muss sowohl im Browser als auch in einer serverbasierten JavaScript-Umgebung funktionieren. Das bedeutet jeder Code, der Browser-APIs und Objekte wie erwartet window verfügbar sein, wird nicht funktionieren.
  • Ihre App wird bei jeder Anfrage an den Server ausgeführt, wodurch zusätzliche Last hinzugefügt und die Antworten verlangsamt werden. Caching kann dies teilweise lindern.
  • Die Implementierung von SSR ist kompliziert und zeitaufwändig, sodass Sie für das Projekt mehr Entwicklerstunden benötigen.
  • Es funktioniert nur gut mit einem Node.js-Backend. SSR kann beispielsweise mit Nicht-Node-Backends mithilfe der PHP-Erweiterung durchgeführt werden v8jsaber solche Lösungen sind ziemlich begrenzt.

Wenn Sie serverseitiges Rendering in einem Vue.js-SPA implementieren möchten, sollten Sie mit dem offiziellen Leitfaden beginnen: Vue.js Serverseitiges Rendering-Handbuch. Ich habe auch eine Anleitung zur Implementierung von SSR mit Laravel und Vue.js geschrieben: Serverseitiges Rendern mit Laravel & Vue.js 2.5.

Tipp: Frameworks wie Nuxt.js sind standardmäßig mit serverseitigem Rendering ausgestattet.

Vorab-Rendering

Wenn Sie SSR aus einem der oben genannten Gründe nicht verwenden können, gibt es einen anderen Weg: Pre-Rendering. Bei diesem Ansatz führen Sie die App mit einem Headless-Browser in Ihrer Entwicklungsumgebung aus, erstellen einen Snapshot der Seitenausgabe und ersetzen Ihre HTML-Dateien durch diesen Snapshot in der Antwort des Servers.

Es ist so ziemlich das gleiche Konzept wie SSR, außer dass es vor der Bereitstellung und nicht auf einem Live-Server erfolgt. Es wird normalerweise mit einem Headless-Browser wie Chrome ausgeführt und kann mit Webpack, Gulp usw. in einen Build-Flow integriert werden.

Der Vorteil des Prerendering besteht darin, dass kein Node.js-Produktionsserver erforderlich ist und Ihr Produktionsserver nicht zusätzlich belastet wird.

Prerendering hat jedoch auch Nachteile:

  • Es funktioniert nicht gut für Seiten, die sich ändernde Daten anzeigen, z. B. Vue HackerNews.
  • Sie ist nicht geeignet für Seiten mit benutzerspezifischen Inhalten, z. B. eine Kontoseite mit den persönlichen Daten eines Benutzers. Diese Art von Seiten sind jedoch weniger kritisch für SEO; Normalerweise möchten Sie sowieso nicht, dass eine Kontoseite indexiert wird.
  • Sie müssen jede Route in der App einzeln vorab rendern, was bei einer großen Website viel Zeit in Anspruch nehmen kann.

Wenn Sie Prerendering in einer Vue.js-App implementieren möchten, habe ich in diesem Blog eine Anleitung geschrieben: Eine Vue.js-App vorab rendern (mit Node oder Laravel)

Tipp: Prerendering für SEO kann als Service von erworben werden prerender.io

Fazit

Viele Entwickler sahen die Ankündigung von Google im Jahr 2014 zum JavaScript-Rendering als ein Ende der SEO-Bedenken bezüglich SPA-Inhalten. Tatsächlich gibt es keine Garantie dafür, dass der Googlebot eine Seite korrekt darstellt, und wenn dies der Fall ist, kann er die Seite immer noch niedriger einstufen als statische HTML-Seiten auf konkurrierenden Websites.

Mein Rat: Wenn Sie die SPA-Architektur verwenden, stellen Sie sicher, dass Sie vom Server gerenderte oder vorgerenderte Seiten bereitstellen.


Werden Sie 2020 Senior Vue-Entwickler.

Lernen und beherrschen Sie in unserem neuesten Kurs, was Profis über das Erstellen, Testen und Bereitstellen von Full-Stack-Vue-Apps wissen.

Mehr erfahren


Similar Posts

Leave a Reply

Your email address will not be published.