Użycie pliku node.js do wyświetlania treści z aplikacji Backbone.js w celu przeszukiwania robotów w celu uzyskania SEO

Question

Albo moje google-fu mnie zawiodło, albo nie ma zbyt wielu ludzi, którzy to robią. Jak wiesz, Backbone.js ma piętę achillesową - nie może wyświetlać html, który renderuje robotom indeksującym strony, takim jak googlebot, ponieważ nie obsługują one JavaScript (chociaż biorąc pod uwagę, że Google ma zasoby, silnik V8 i trzeźwy fakt, że Aplikacje JavaScript są coraz popularniejsze, spodziewam się, że kiedyś się to stanie). Mam świadomość, że Google stosuje politykę obejścia hashbang, ale jest to po prostu zły pomysł. Dodatkowo używam PushState. Jest to dla mnie niezwykle ważna kwestia i spodziewam się, że będzie również dla innych. SEO jest czymś, czego nie można zignorować, a zatem nie może być brane pod uwagę w przypadku wielu aplikacji, które wymagają, lub wymagają od niego zależą.

Wprowadź node.js. Dopiero zaczynam wchodzić w ten szał, ale możliwe, że ta sama aplikacja Backbone.js, która istnieje na kliencie, znajduje się na serwerze trzymając się za ręce za pomocą node.js. Następnie plik node.js będzie mógł wyświetlać html renderowane z aplikacji Backbone.js do robotów indeksujących strony. Wydaje się, że to wykonalne, ale szukam kogoś, kto ma większe doświadczenie z node.js lub jeszcze lepiej, ktoś, kto faktycznie to zrobił, aby mi doradzić.

Jakie kroki należy podjąć, aby umożliwić mi użycie pliku node.js do obsługi mojej aplikacji Backbone.js do robotów sieciowych? Ponadto moja aplikacja Backbone zużywa interfejs API napisany w Railsach, co moim zdaniem spowodowałoby mniej bólu głowy.

EDYCJA: Nie wspomniałem, że mam już aplikację produkcyjną napisaną w Backbone.js. Szukam zastosowania tej techniki do tej aplikacji.

Answer 1

Zasadniczo musisz zdecydować, czym służysz: czy jest to prawdziwa aplikacja (np. Coś, co może zastąpić dedykowaną aplikację komputerową), czy jest to prezentacja treści (np. "Strona internetowa")? Jeśli obawiasz się SEO, prawdopodobnie jest to drugie ("witryna treści"), a wtedy model "pojedynczej strony" nie jest odpowiedni; naprawdę zależy ci na modelu "progresywnie ulepszonej stronie" (sprawdź takie zwroty jak "dyskretny JavaScript", "ulepszenie progresywne" i "adaptacyjny wygląd sieci").

Aby nieco wzmocnić, "serwer wysyła tylko serializowane dane, a klient wykonuje renderowanie" jest odpowiedni tylko w scenariuszu "prawdziwej aplikacji". W przypadku scenariusza "witryny treści" odpowiedni model to "serwer renderuje główne, klient sprawia, że ​​wygląda lepiej i wykonuje renderowanie na małą skalę, aby uniknąć zakłócających przejść stron, gdy jest to możliwe".

Przy okazji zastrzeżenie, że stopniowe ulepszanie oznacza "upewnianie się, że użytkownik widzi nie ma nic lepszego niż niewidomy użytkownik, który używa zamiany tekstu na mowę" jest wyrazem politycznej urazy, nie rzeczywistość. Stopniowo ulepszone witryny mogą być tak fantazyjne, jak chcesz, z punktu widzenia użytkownika z zaawansowanym systemem renderowania.

Answer 2

Zostawię to tobie, aby zdecydować, czy pchanie silnika renderującego po stronie serwera jest dobrą decyzją.

Ponieważ Nodejs jest zbudowany na V8 (silnik Chrome), uruchomi javascript, np. Backbone.js. Tworzenie modeli i tak dalej odbywałoby się w dokładnie taki sam sposób.

Środowisko Nodejs oczywiście nie ma DOM. Jest to część, którą musisz odtworzyć. Uważam, że moduł najbardziej popularny jest:

https://github.com/tmpvar/jsdom

Gdy masz dostępnego API DOM w Nodejs, wystarczy zbudować swoje węzły tak jak w przypadku typowego klienta przeglądarki (być może przy użyciu jQuery) i odpowiadać na żądania serwera z renderowanym kodem HTML (za pomocą $ ("myDOM"). html() lub podobne).

Answer 3

Uważam, że można przyjąć podejście typu strategii zastępczej. Zastanów się, co by się stało z wyłączonym javascript i kliknięciem linku vs js na. Wszystko, co robisz na swojej stronie, którą można zindeksować, powinno mieć uzasadnioną procedurę zastępczą, gdy javascript jest wyłączony. Twoje linki powinny zawsze mieć link do serwera jako href, a domyślnej akcji powinno się zapobiegać przy pomocy javascript.

Nie powiedziałbym, że to bezwzględna odpowiedzialność kręgosłupa. Chodzi mi o to, że tylko kręgosłup może ci pomóc, modyfikuje twój adres URL, gdy strona się zmienia, a twoje modele/kolekcje są po stronie klienta i serwera. Widoki i routery będą uważane za stronę ściśle klienta.

To, co możesz zrobić, to tworzyć strony z jadeitami i częściowo renderować je po stronie klienta lub po stronie serwera z wtryskiwaną treścią lub bez niej. W ten sposób ta sama strona może być renderowana w dowolny sposób. Oznacza to, że jeśli zamienisz duży fragment strony i zmienisz adres URL, to html, który przechwytujesz, może pochodzić z tego samego szablonu, tak jakby ktoś bezpośrednio poszedł na tę stronę.

Kiedy twój serwer otrzyma żądanie, powinien bezpośrednio przejść do tej strony, zamiast przejść przez główny punkt wejścia i szkielet obciążenia i zmusić go do manipulowania stroną i ustawienia jej w sposób zamierzony przez użytkownika za pomocą adresu URL .

Sądzę, że powinieneś być w stanie to osiągnąć, zmieniając trochę porządek w aplikacji. Nie ma przepisywania tylko dużej ilości ruchomych elementów. Może być konieczne napisanie kontrolera, który będzie obsługiwał pliki html z treścią wstrzykniętą lub nie wstrzykniętą. Pozwoli to nadać twojej szkieletowej aplikacji html, który musi powiązać z danymi z modeli. Tak jak powiedziałem, te same szablony mogą być używane, gdy bezpośrednio trafisz te łącza przez routery zdefiniowane w pliku express/node.js

Answer 4

To jest na mojej liście rzeczy do zrobienia w naszej aplikacji: Node.js parsuje szkielet trasy (przechowywane w pamięci po uruchomieniu aplikacji), a przynajmniej wyświetlają szablon strony głównej przy prostym HTML-cokolwiek więcej byłoby prawdopodobnie zbyt dużym obciążeniem/przetwarzaniem dla BE, gdy uważasz, że tysiące użytkowników uderza w twoją stronę.

Wierzę, że aplikacje szkieletowe, takie jak AirBnB, robią to w ten sam sposób, ale tylko w przypadku robotów takich jak robot Google. Ta sytuacja również jest potrzebna do takich rzeczy jak Facebook lubi, ponieważ Facebook wysyła robot do odczytu twoich tagów og :.

Answer 5

Przede wszystkim pozwól mi dodać zastrzeżenie, które moim zdaniem to wykorzystanie node.js jest złym pomysłem. Drugie zastrzeżenie: Zrobiłem podobne hacki, ale tylko w celu zautomatyzowanych testów, a nie robotów.

Z tym na uboczu, chodźmy. Jeśli zamierzasz uruchomić aplikację po stronie klienta na serwerze, musisz odtworzyć środowisku przeglądarki na serwerze:

1. Większość oczywiście, jesteś brakuje (Document Object Model) DOM - w zasadzie AST na wierzchu sparsowanego dokumentu HTML. Rozwiązaniem dla węzła node.js jest jsdom.

2. To jednak nie wystarczy. Twoja przeglądarka udostępnia również BOM (Object Model przeglądarki) - dostęp do funkcji przeglądarki, takich jak na przykład history.pushState. To jest problematyczne. Dostępne są dwie opcje: możesz spróbować zgiąć phantomjs lub casperjs, aby uruchomić aplikację, a następnie zdjąć z niej kod HTML. Jest kruchy, ponieważ masz ogromną, pełną przeglądarkę WebKit z odciętymi częściami UI.

3. Inną opcją jest Zombie - co jest lekką ponowną implementacją funkcji przeglądarki w Javascript. Zgodnie ze stroną, która obsługuje pushState, ale moim doświadczeniem jest to, że emulacja przeglądarki jest daleka od zakończenia - jednak spróbuj i zobacz, jak daleko się dostajesz.

Answer 6

Roztwór roboczy jest użycie kręgosłup wszędzie https://github.com/Morriz/backbone-everywhere ale zmusza do korzystania z węzła jako backend.

Inną alternatywą jest użycie tych samych szablonów na serwerze i interfejsie użytkownika. Przednia strona ładuje szablony wąsów za pomocą wtyczki require.js, a serwer renderuje stronę przy użyciu tych samych szablonów wąsów.

Kolejnym dodatkiem jest również renderowanie danych modułu startowego w tagu javascript jako danych JSON, które będą natychmiast używane przez szkielet do zapełniania modeli i kolekcji.