Immer mehr Webseiten werden heutzutage als Single Page Applications (SPA) umgesetzt. Ein Problem, das vielen Entwicklern dabei Kopfzerbrechen bereitet, ist die Optimierung der Page nach SEO-Gesichtspunkten (SEO = Search Engine Optimization). Was bei statischen Webseiten keine große Herausforderung ist, wird bei SPAs um einiges komplizierter. Fast der gesamte SEO-relevante Content einer Seite ist in einer oder mehreren JavaScript-Dateien gekapselt und damit nicht mehr so trivial von den Suchmaschinen-Crawlern auslesbar. Das Problem wurde in der Vergangenheit oft durch serverseitiges Rendering gelöst. Allerdings bedeutete dies auch viel Aufwand.
Ich werde in diesem Artikel beleuchten, welche Fähigkeiten die aktuellen Crawler besitzen und ob das serverseitige Rendering überhaupt noch notwendig ist.
Was können die Crawler von heute?
Suchmaschinen-Anbieter wissen natürlich um die Bedeutung von SPAs und die Wichtigkeit von JavaScript, welches Inhalte dynamisch im Browser rendert. Demzufolge sind die aktuellen Crawler auch fast alle in der Lage, den JavaScript-Code auszuführen und Inhalte so anzuzeigen, wie es der Browser macht. Selbst dynamische Inhalte, die z.B. über einen API-Request zeitverzögert nachgeladen werden, kann der Crawler erfassen. Für mehr Informationen dazu siehe: „SEO vs. React: Web Crawlers are Smarter Than You Think“ .
Man kann das auch leicht für die eigene App ausprobieren, indem man die Google Search Console nutzt. Mit dem Tool kann man eine beliebige URL seiner Page rendern und sieht dann in Form von zwei Screenshots, wie der Bot die Seite wahrnimmt und wie ein User die Seite sieht.
Etwas Vorsicht ist geboten bei Googles Testtool für strukturierte Daten . Dieses rendert die SPA nicht wie der Google-Bot, weshalb man auch keine dynamisch generierten Meta-Tags oder Open-Graph-Tags in den Analyseergebnissen findet. Davon sollte man sich aber nicht beirren lassen.
Bisher sieht also alles gut aus. Warum denn nun noch serverseitiges Rendering?
Leider steckt der Teufel im Detail
In diesem aufschlussreichen SEO-Experiment wurden im Mai 2017 die verschiedenen SPA Frameworks getestet und die Fähigkeiten des Google-Bots analysiert. Das Ergebnis: Es gibt nach wie vor Probleme, z.B. hat das genutzte Framework einen Einfluss auf die SEO-Tauglichkeit der Seite. Angular schneidet am schlechtesten bei allen Tests ab, obwohl es von Google entwickelt wird. React und Vue.js werden momentan am besten unterstützt. Weiterhin macht es einen Unterschied, ob der JavaScript-Code in einer bundle.js zusammengefasst und extern referenziert wird oder komplett inline im HTML eingebunden ist. Inline-Skripte werden besser verarbeitet als extern referenzierte. Bei extern eingebundenen Skripten werden z.B. dynamisch generierte Links vom Google-Bot nicht erfasst.
In dem Artikel: „Google: Nicht alle dynamisch gesetzten Meta-Tags werden erkannt“ wird beschrieben, dass bei dynamisch generierten Meta-Tags das "noindex, follow"-Attribut nicht zuverlässig interpretiert wird. Somit tauchen dann Seiten im Google-Index auf, die man dort nicht sehen will.
Google weist in seinen Developer Guides darauf hin, dass bestimmte Features aktuell nicht unterstützt werden, wie z.B. WebSockets, IndexedDB, WebSQL, ServiceWorkers etc. Webseiten werden vom Bot auf Basis der Chrome 41 Engine gerendert. Die aktuelle Version von Chrome ist 62 (Stand November 2017). Man muss also in jedem Fall beachten, dass ggf. nicht alle JavaScript-Features zuverlässig funktionieren und man mit Polyfills und Feature Detection für Abhilfe sorgen muss. Um herauszufinden, welche JavaScript-Features Chrome 41 unterstützt, ist caniuse.com sehr hilfreich.
Und am Ende muss man natürlich auch berücksichtigen, dass Google mit seinem Bot technologischer Vorreiter ist und andere Suchmaschinen-Bots unter Umständen noch weniger Inhalte parsen können.
Fazit
Auch wenn die Bots heutzutage JavaScript rendern und die meisten Inhalte indiziert werden können, gibt es bei bestimmten Details noch Probleme. Um also bei einer SEO-kritischen Seite auf Nummer sicher zu gehen, ist das serverseitige Rendering nach wie vor die beste Alternative.
Wer wissen möchte, wie man das serverseitige Rendering (SSR) mit React umsetzt, kann dies in folgendem Artikel nachlesen: „Tutorial: Serverseitiges Rendering mit React“ . Darin baue ich eine einfache clientseitige App Schritt für Schritt in eine serverseitig gerenderte App um. Ich zeige, wie man den Redux-Store richtig auf dem Server initialisiert, React-Router so konfiguriert, dass es auch auf dem Server die richtige Seite rendert und wie man mit React-Helmet seine Meta-Tags ins statische HTML integriert.
War dieser Beitrag hilfreich?
Weitere Beiträge
von René Bohrenfeldt
31.1.2023 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
René Bohrenfeldt
Agile Coach | People Lead
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.