Nach dem LesenGoogles Richtlinie, mit Ajax generierte Inhalte crawlbar zu machenZusammen mit vielen Blog-Posts von Entwicklern und Fragen und Antworten zu Stackoverflow zu diesem Thema bin ich zu dem Schluss gekommen, dass es keine Möglichkeit gibt, eine Site nur mit JavaScript / Ajax-generiertem HTML-Crawling zu erstellen. Bei einer Website, an der ich gerade arbeite, wird nicht genügend Inhalt indexiert. Die gesamte Präsentationsebene für unseren nicht indizierten Inhalt wird in JavaScript erstellt, indem HTML-Code aus JSON generiert wird, der von Ajax-basierten Webdienstaufrufen zurückgegeben wird. Aus diesem Grund indiziert Google den Inhalt unserer Meinung nach nicht. Ist das korrekt?

Die einzige Lösung scheint darin zu bestehen, eine "Fallback" -Version der Website für Suchmaschinen (insbesondere Google) bereitzustellen, auf der der gesamte HTML-Code und der gesamte Inhalt wie bisher auf der Serverseite generiert werden. Für Clients mit aktiviertem JavaScript können wir anscheinend im Wesentlichen den gleichen Ansatz wie jetzt verwenden: Verwenden von JavaScript zum Generieren von HTML aus asynchron geladenem JSON.

Nach meinem Verständnis ist dies die derzeit beste Vorgehensweise für die Anwendung desDRY-Prinzip Beim Erstellen crawlbarer, von Ajax generierter Websites, wie oben beschrieben, wird eine Vorlagen-Engine verwendet, die auf Client- und Serverseite dieselben Vorlagen verwenden kann. Für Clients mit aktiviertem JavaScript beispielsweise die clientseitige Templating-Enginemoustache.jswürde JSON-Daten, die vom Server gesendet werden, in HTML umwandeln, wie durch die Kopie einer Vorlagendatei definiert. Und für Such-Crawler und Clients mit deaktiviertem JavaScript beispielsweise die serverseitige Implementierung derselben Templating-Enginemoustache.java, würde in ähnlicher Weise die Kopie derselben exakten Vorlagendatei bearbeiten, um HTML auszugeben.

Wenn diese Lösung korrekt ist, wie unterscheidet sie sich dann von den Ansätzen, die vor 4 oder 5 Jahren von Front-End-Websites verwendet wurden, auf denen im Wesentlichen zwei Kopien des Vorlagencodes verwaltet werden mussten, eine Kopie für Benutzer mit aktiviertem JavaScript (fast alle)? und eine andere Kopie (zB inFreeMarker oderGeschwindigkeit) für Suchmaschinen und Browser ohne aktiviertes JavaScript (fast niemand)? Es scheint, als gäbe es einen besseren Weg.

Bedeutet dies, dass zwei Vorlagenmodellebenen beibehalten werden müssten, eine auf der Clientseite und eine auf der Serverseite? Wie ratsam ist es, diese clientseitigen Vorlagen mit einem Front-End-MVC-Framework (MV / MVVC) zu kombinieren, zBackbone.js, Ember.js, oderYUI-App-Bibliothek? Wie wirken sich diese Lösungen auf die Wartungskosten aus? Wäre es besser, dies zu versuchen, ohne weitere Frameworks - eine neue Templating-Engine und ein Front-End-MVC-Framework - in den Technologie-Stack eines Entwicklungsteams einzuführen? Gibt es eine Möglichkeit, dies weniger redundant zu tun?

Wenn diese Lösung nicht korrekt ist, fehlt etwas, was wir mit unserem JavaScript besser machen könnten, um unsere vorhandene asynchrone HTML-from-JSON-Struktur beizubehalten und zu indizieren, sodass wir nichts Neues einführen müssen zum Architekturstapel? Wir müssten wirklich lieber nicht zwei Versionen der Präsentationsebene aktualisieren, wenn sich die Geschäftsanforderungen ändern.