model-view-controller seo automation dry mustache

model view controller - ¿Cuál es la forma menos redundante de rastrear un sitio con HTML generado por JavaScript?



model-view-controller seo (5)

Después de leer la política de Google de hacer que el contenido generado por Ajax sea rastreable , junto con muchas publicaciones de blog de desarrolladores y temas de preguntas y respuestas Stackoverflow sobre el tema, me queda la conclusión de que no hay forma de crear un sitio con JavaScript / Ajax solo generado HTML rastreable Un sitio en el que estoy trabajando actualmente no está indexando una buena cantidad de su contenido. Toda la capa de presentación para nuestro contenido no indexado está construida en JavaScript mediante la generación de HTML a partir de JSON devuelto por llamadas al servicio web basadas en Ajax, y creemos que Google no está indexando el contenido debido a eso. ¿Es eso correcto?

La única solución parece ser tener también una versión "fall-back" del sitio para los motores de búsqueda (específicamente Google) donde todo el HTML y el contenido se generarían como tradicionalmente ha sido, en el lado del servidor. Para los clientes con JavaScript habilitado, parece que podríamos utilizar esencialmente el mismo enfoque que ahora: usar JavaScript para generar HTML desde JSON cargado de forma asíncrona.

Leyendo, entiendo que la mejor práctica actual para aplicar el principio DRY en la creación de sitios web generados por Ajax rastreables como se describe anteriormente es usar un motor de plantillas que pueda usar las mismas plantillas en el lado del cliente y en el servidor. Para los clientes con JavaScript habilitado, el motor de plantillas del lado del cliente, por ejemplo mustache.js , transformaría los datos JSON enviados desde el servidor en HTML según lo define su copia de un archivo de plantilla. Y para los rastreadores de búsqueda y clientes con JavaScript deshabilitado, la implementación del lado del servidor del mismo motor de plantillas, por ejemplo mustache.java , operaría de manera similar en su copia del mismo archivo de plantilla exacta para producir HTML.

Si esa solución es correcta, ¿cómo es esto diferente a los enfoques utilizados hace 4 o 5 años por sitios pesados ​​de front-end, donde los sitios tenían que mantener esencialmente dos copias del código de plantillas, una copia para usuarios con JavaScript habilitado (casi todos) y otra copia (por ejemplo, en FreeMarker o Velocity ) para motores de búsqueda y navegadores sin JavaScript habilitado (casi nadie)? Parece que debería haber una mejor manera.

¿Esto implica que se necesitarían mantener dos capas de modelo de plantillas, una en el lado del cliente y otra en el lado del servidor? ¿Qué tan aconsejable es combinar esas plantillas del lado del cliente con un marco de MVC frontal (MV / MVVC) como Backbone.js , Ember.js o YUI App Library ? ¿Cómo afectan estas soluciones los costos de mantenimiento? ¿Sería mejor intentar hacer esto sin introducir más marcos (un nuevo motor de plantillas y un framework MVC de front-end) en la pila de tecnología de un equipo de desarrollo? ¿Hay alguna manera de hacer esto de forma menos redundante?

Si esa solución no es correcta, entonces hay algo que nos falta y podría estar mejorando con nuestro JavaScript para mantener nuestra estructura asincrónica HTML-from-JSON existente y obtener su indexación, para que no tengamos que introducir algo nuevo a la pila de arquitectura? Realmente preferiríamos no tener que actualizar dos versiones de la capa de presentación cuando el negocio necesite cambios.

¡Por qué no pensé en esto antes! Solo usa http://phantomjs.org . Es un navegador webkit sin cabeza. Simplemente crearía un conjunto de acciones para rastrear la interfaz de usuario y capturar el html en cada estado que desee. Phantom puede convertir el html capturado en archivos .html para usted y guardarlos en su servidor web.

Todo se automatizaría en cada compilación / confirmación (PhantomJS es impulsado por la línea de comandos). El código JS que escriba para rastrear la IU se romperá a medida que cambie la IU, pero no debería ser peor que las pruebas UI automatizadas, y es solo Javascript, por lo que puede usar los selectores jQuery para tomar botones y hacer clic en ellos.

Si tuviera que resolver el problema de SEO, este es definitivamente el primer enfoque que crearía. Rastrear y guardar, bebé. Sí señor.

Creo que una combinación de algunas tecnologías y un truco codificado manualmente que podrías reutilizar te arreglaría bien. Aquí está mi idea loca, medio cocida. Es teórico y probablemente no completo. Paso 1:

  • Use plantillas del lado del cliente, como sugiere. Coloque cada plantilla en un archivo separado (para poder reutilizarlas fácilmente entre el cliente y el servidor)
  • Use underscore.js para modelar o reconfigurar Bigote. De esta forma obtendrás delimitadores de estilo ERB en tu plantilla, idénticos a los de <% =%> de Java.
  • Debido a que son archivos separados, querrá comenzar a desarrollar en módulos CommonJS con un cargador de módulos como curl.js o require.js para cargar las plantillas en su código del lado del cliente. Si no estás haciendo un desarrollo modular, es bastante impresionante. Empecé ~ hace un mes. Parece difícil al principio, pero es solo una forma diferente de ajustar el código: http://addyosmani.com/writing-modular-js/

Bien, entonces ahora tienes plantillas aisladas. Ahora solo tenemos que descubrir cómo crear una página plana en el servidor. Solo veo dos enfoques. Paso 2:

  • Podría anotar su JS para que el servidor pueda leerlo y ver una ruta predeterminada para las llamadas ajax y las plantillas a las que se vinculan, luego el servidor puede usar las anotaciones para llamar a los métodos del controlador en el orden correcto y completar una página plana.
  • O puede anotar sus plantillas para indicar a qué controlador deben llamar y proporcionar ejemplos de parámetros de llamada. Esto sería fácil de mantener y beneficiaría a los desarrolladores front-end como yo, que tienen que buscar las URL de los controladores todo el tiempo. También le diría a su código de back-end qué llamar.

Espero que esto ayude. Curioso por escuchar la mejor respuesta a esto. Un problema interesante

Encontré una solución que no requiere Java, Node.js ni ninguna otra forma de hacer una copia redundante de un sitio web generador de código JS. También es compatible con todos los navegadores.

Entonces, lo que debe hacer es proporcionar la instantánea de Google. Es la mejor solución, porque no necesita meterse con otras URLS, etc. Además: no agrega noscript a su sitio web básico para que sea más ligero.

¿Cómo hacer una instantánea? Phantomjs, HTMLUnit y demás requieren un servidor donde pueda ponerlo y llamar. Debe configurarlo y combinarlo con su sitio web. Y esto es un desastre. Lamentablemente, no hay un explorador sin cabeza PHP. Es obvio debido a los detalles de PHP.

Entonces, ¿cuál es la otra forma de obtener una instantánea? Bueno ... si el usuario abre el sitio web puede obtener la instantánea de lo que ve con JS (innerHTML).

Entonces, lo que debes hacer es:

  • compruebe si necesita una instantánea para su sitio (si lo tiene, no necesita tomar otro)
  • envía esta instantánea al servidor para guardarla en un archivo (PHP maneja la solicitud POST con instantánea y la guarda en el archivo)

Y si Google Bot visita tu sitio web hash bang, obtienes el archivo de la instantánea de la página solicitada.

Cosas para resolver:

  • seguridad: no desea que ningún script del usuario o su navegador (inyección) lo guarden en una instantánea, tal vez lo mejor sea que solo pueda generar instantáneas (consulte el mapa del sitio a continuación)
  • compatibilidad: no desea guardar desde ningún navegador, sino desde uno que admita su sitio web de la mejor manera posible.
  • No moleste a los dispositivos móviles: simplemente no use usuarios de dispositivos móviles para generar instantáneas para que la página no sea más lenta para ellos
  • Conmutación por error: si no tiene un sitio web estándar de salida de instantánea, no es nada bueno para Google, pero es mejor que nada.

Además, hay una cosa: no todas las páginas serán visitadas por los usuarios, pero se necesitan instantáneas de Google antes de su visita.

¿Entonces lo que hay que hacer? Hay una solución para esto también:

  • generar un mapa del sitio que tenga todas las páginas que tenga en el sitio web (se debe generar en vuelo para estar actualizado, y el rastreador suave no ayuda porque no ejecuta JS)
  • visite en cualquier forma las páginas del mapa del sitio que no tenga una instantánea. Esto llamará al código de instantánea y lo generará correctamente
  • visita regularmente (¿diariamente?)

Pero bueno, ¿cómo visitar todas esas páginas? Bien. Hay algunas soluciones para esto:

  • escriba una aplicación en Java, C # u otro idioma para obtener páginas para visitar desde el servidor y visitarlas con un control incorporado en el navegador. Agregue esto a su horario en el servidor.
  • escriba una secuencia de comandos JS que abre páginas requeridas en iFRAME una por otra. Agregue esto a su agenda en una computadora.
  • simplemente abra manualmente el script mencionado anteriormente si su sitio es principalmente estático

También recuerde actualizar las instantáneas antiguas ocasionalmente para actualizarlas.

Espero saber de ti qué piensas sobre esta solución.

Usa plantillas Distal . Su sitio web es HTML estático que se puede rastrear y Distal trata el HTML estático como una plantilla.