Po przeczytaniuZasady Google dotyczące przeszukiwania treści generowanych przez AjaxWraz z wieloma postami na blogach deweloperów i wątkami pytań i odpowiedzi Stackoverflow na ten temat, dochodzę do wniosku, że nie ma sposobu na stworzenie witryny z przeszukiwalnym kodem HTML opartym tylko na JavaScript / Ajax. Witryna, na której aktualnie pracuję, nie jest wystarczająco indeksowana. Cała warstwa prezentacji dla naszej niezindeksowanej treści jest wbudowana w JavaScript, generując HTML z JSON zwrócony z wywołań usług internetowych opartych na Ajax, i uważamy, że Google nie indeksuje zawartości z tego powodu. Czy to jest poprawne?

Jedynym rozwiązaniem wydaje się być również „zapasowa” wersja witryny dla wyszukiwarek (w szczególności Google), w której cały HTML i treść byłyby generowane tak, jak tradycyjnie, po stronie serwera. Dla klientów z włączoną obsługą JavaScript wydaje się, że możemy zastosować zasadniczo to samo podejście, które obecnie wykonujemy: używanie JavaScript do generowania HTML z asynchronicznie załadowanego JSON.

Czytając, rozumiem, że obecna najlepsza praktyka stosowaniaZasada DRY podczas tworzenia indeksowanych witryn generowanych przez Ajax, jak opisano powyżej, należy użyć silnika szablonów, który może używać tych samych szablonów po stronie klienta i po stronie serwera. Dla klientów z włączoną obsługą JavaScript, na przykład silnik szablonów po stronie klientamustache.js, przekształciłoby dane JSON wysyłane z serwera do HTML, jak zdefiniowano w jego kopii pliku szablonu. A dla przeszukiwaczy i klientów z wyłączoną obsługą JavaScript, na przykład implementacja tego samego silnika szablonów na serwerzemustache.java, podobnie działałby na swojej kopii tego samego dokładnego pliku szablonu, aby wydrukować HTML.

Jeśli to rozwiązanie jest poprawne, to w jaki sposób to się różni od podejść stosowanych 4 lub 5 lat temu przez ciężkie witryny frontonu, gdzie strony musiały zasadniczo utrzymywać dwie kopie kodu templatu, jedną kopię dla użytkowników z włączoną obsługą JavaScript (prawie wszyscy) i inna kopia (np. wFreeMarker lubPrędkość) dla wyszukiwarek i przeglądarek bez włączonej obsługi JavaScript (prawie nikt)? Wygląda na to, że powinien być lepszy sposób.

Czy to oznacza, że ​​trzeba będzie utrzymywać dwie warstwy modelu, jedną po stronie klienta i jedną po stronie serwera? Jak wskazane jest połączenie tych szablonów po stronie klienta z frameworkiem MVC (MV / MVVC), takim jakBackbone.js, Ember.jslubBiblioteka aplikacji YUI? Jak te rozwiązania wpływają na koszty konserwacji? Czy byłoby lepiej spróbować zrobić to bez wprowadzania dodatkowych ram - nowego silnika szablonów i frameworka MVC - do stosu technologii zespołu programistów? Czy istnieje sposób, aby to zrobić mniej zbędnie?

Jeśli to rozwiązanie nie jest poprawne, to czy czegoś brakuje i może być lepiej w naszym JavaScript, aby utrzymać naszą istniejącą asynchroniczną strukturę HTML-ową z JSON i uzyskać jej indeksację, więc nie musimy wprowadzać czegoś nowego do stosu architektury? Naprawdę raczej nie musielibyśmy aktualizować dwóch wersji warstwy prezentacji, gdy zmieniają się potrzeby biznesowe.