javascript - spa - seo for single page application

pushState y SEO

Question

Mucha gente ha estado diciendo, usa pushState en lugar de hashbang.

Lo que no entiendo es, ¿cómo serías amigable con los motores de búsqueda sin usar hashbang?

Es de suponer que su contenido de pushState es generado por el código de JavaScript del lado del cliente.

El escenario es así:

Estoy en example.com . Mi usuario hace clic en un enlace: href="example.com/blog"

pushState captura el clic, actualiza la URL, toma un archivo JSON de alguna parte y crea la lista de publicaciones de blog en el área de contenido.

Con hashbangs, google sabe que debe dirigirse a la URL escaped_fragment para obtener su contenido estático.

Con pushState, Google no ve nada, ya que no puede usar el código JavaScript para cargar el JSON y, posteriormente, crear la plantilla.

La única forma de hacerlo que puedo ver es renderizar la plantilla en el lado del servidor, pero eso niega por completo los beneficios de enviar la capa de aplicación al cliente.

Entonces, ¿estoy haciendo esto bien, pushState no es SEO amigable para las aplicaciones del lado del cliente en absoluto?

Answer 1

¿ pushState malo pushState si necesita que los motores de búsqueda lean su contenido?

No, la charla sobre pushState está orientada a lograr el mismo proceso general para hashbangs, pero con URLs más atractivas. Piensa en lo que realmente sucede cuando usas hashbangs ...

Tu dices:

Con hashbangs, Google sabe que debe ir a la URL escaped_fragment para obtener su contenido estático.

Entonces en otras palabras,

1. Google ve un enlace a example.com/#!/blog
2. Google solicita example.com/?_escaped_fragment_=/blog
3. Usted devuelve una instantánea del contenido que el usuario debería ver

Como puede ver, ya depende del servidor. Si no está publicando una instantánea del contenido del servidor, entonces su sitio no se indexará correctamente.

Entonces, ¿cómo verá Google algo con pushState?

Con pushState, google simplemente no ve nada, ya que no puede usar el javascript para cargar el json y posteriormente crear la plantilla.

En realidad, Google verá todo lo que pueda solicitar en site.com/blog . Una URL aún apunta a un recurso en el servidor, y los clientes aún obedecen este contrato. Por supuesto, para los clientes modernos, Javascript ha abierto nuevas posibilidades para recuperar e interactuar con el contenido sin una actualización de página , pero los contratos son los mismos.

Por lo tanto, la elegancia pushState de pushState es que sirve el mismo contenido para todos los usuarios, viejos y nuevos, compatibles con JS y no, pero los nuevos usuarios obtienen una experiencia mejorada .

¿Cómo consigues que Google vea tu contenido?

1. El enfoque de Facebook: site.com/blog el mismo contenido en la URL site.com/blog que su aplicación cliente se transformaría cuando site.com/blog en el estado. (Facebook aún no usa pushState que yo sepa, pero lo hacen con hashbangs)

2. El enfoque de Twitter: redirige todas las URL entrantes al equivalente de hashbang. En otras palabras, un enlace a "/ blog" empuja /blog al estado. Pero si se solicita directamente, el navegador termina en #!/blog . (Para Googlebot, esto se _escaped_fragment_ a _escaped_fragment_ como lo desea. Para otros clientes, podría volver a pushState a pushState a la bonita URL).

Entonces, ¿pierdes la capacidad _escaped_fragment_ con pushState ?

En un par de comentarios diferentes, dijiste

el fragmento escapado es completamente diferente. Puede servir contenido puro sin formato, contenido almacenado en caché y no tener la carga que tienen las páginas normales.

La solución ideal es que Google haga sitios de JavaScript o implemente alguna forma de saber que hay un fragmento de URL escapado incluso para sitios de sitios pushstate (robots.txt?).

Los beneficios que mencionaste no están aislados en _escaped_fragment_ . Que hace la reescritura para usted y utiliza un parámetro GET especialmente nombrado es realmente un detalle de implementación. No hay nada realmente especial al respecto que no pueda hacer con las URL estándar; en otras palabras, reescriba /blog en /?content=/blog por su cuenta usando mod_rewrite o el equivalente de su servidor.

¿Qué pasa si no sirve el contenido del lado del servidor en absoluto?

Si no puede volver a escribir las URL y publicar algún tipo de contenido en /blog (o el estado que ingresó en el navegador), entonces su servidor ya no se atiene al contrato HTTP.

Esto es importante porque una recarga de página (por el motivo que sea) extraerá contenido de esta URL. (Consulte https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "view-source y reload obtendrán el contenido en el nuevo URI si lo presionaron").

No es que dibujar interfaces de usuario una vez en el lado del cliente y cargar contenido a través de las API JS es un mal objetivo, es solo que no se tiene en cuenta con HTTP y URL, y básicamente no es compatible con versiones anteriores.

Por el momento, esto es exactamente lo que hashbangs están destinados a: representar estados de página distintos que se navegan en el cliente y no en el servidor. Una recarga, por ejemplo, cargará el mismo recurso que luego puede leer, analizar y procesar el valor hash.

Resulta que también han sido utilizados (especialmente por Facebook y Twitter) para cambiar el historial a una ubicación del lado del servidor sin una actualización de página. Es en esos casos de uso que las personas están recomendando el abandono de hashbangs para pushState.

Si representa todo el contenido del lado del cliente, debería pensar en pushState como parte de una API de historial más conveniente y no como una forma de evitar el uso de hashbangs.

Answer 2

¡Toda la charla interesante sobre pushState y #! , y todavía no puedo ver cómo pushState reemplaza el propósito de #! como lo pide el póster original.

¡Nuestra solución para hacer que nuestro sitio / aplicación Ajax basado en JavaScript al 99% SEOable esté usando #! por supuesto. Como la representación del cliente se realiza a través de HTML, JavaScript y PHP, utilizamos la siguiente lógica en un cargador controlado por nuestro aterrizaje de página. Los archivos HTML están totalmente separados de JavaScript y PHP porque queremos el mismo HTML en ambos (en su mayor parte). JavaScript y PHP hacen casi lo mismo, pero el código PHP es menos complicado ya que JavaScript es una experiencia de usuario mucho más rica.

JavaScript usa jQuery para inyectar en HTML el contenido que desea. PHP usa PHPQuery para inyectar en el HTML el contenido que desea, usando ''casi'' la misma lógica, pero mucho más simple ya que la versión de PHP solo se usará para mostrar una versión SEOable con enlaces SEOable y no interactuará con la versión de JavaScript.

Todos son los tres componentes que componen una página, page.htm, page.js y page.php existen para cualquier cosa que use el fragmento escapado para saber si cargar la versión de PHP en lugar de la versión de JavaScript. La versión de PHP no necesita existir para contenido no SEOable (como las páginas que solo se pueden ver después del inicio de sesión del usuario). Todo es sencillo.

Todavía estoy desconcertado de cómo algunos desarrolladores de primera línea se escapan desarrollando sitios geniales (con la riqueza de Google Docs) sin usar tecnologías del lado del servidor junto con las del navegador ... Si JavaScript ni siquiera está habilitado, entonces nuestra solución de 99% de JavaScript Por supuesto, no hará nada sin el PHP en su lugar.

Es posible tener una buena URL para aterrizar en una página servida por PHP y redireccionar a una versión de JavaScript si JavaScript está habilitado, pero eso no es agradable desde la perspectiva del usuario ya que los usuarios son la audiencia más importante.

En otros comentarios. Si está creando solo un sitio web simple que puede funcionar sin JavaScript, entonces puedo ver que pushState es útil si desea mejorar progresivamente su experiencia de usuario de un contenido simple estáticamente renderizado en algo mejor, pero si desea darle a su usuario el La mejor experiencia del momento ... digamos que su último juego escrito en JavaScript o algo así como Google Docs, su uso para esta solución es algo limitante, ya que caer airosamente puede llegar tan lejos antes de que la experiencia del usuario sea dolorosa en comparación con la visión del sitio.

Answer 3

¿Qué pasa con el uso de la metaetiqueta que Google sugiere para aquellos que no quieren hash-bangs en sus URLs: <meta name="fragment" content="!">

Consulte aquí para obtener más información: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Lamentablemente, no creo que NickC haya aclarado el problema que creía que estaba teniendo el OP. El problema es simplemente que no sabemos a quién le estamos sirviendo el contenido si no usamos el hash-bang. Pushstate no resuelve esto por nosotros. No queremos que los motores de búsqueda digan a los usuarios finales que naveguen a alguna URL que escuche JSON sin formato. En su lugar, creamos URL (que activan otras llamadas a más URL) que recuperan datos a través de AJAX y se los presentan al usuario de la manera que preferimos. Si el usuario no es humano, entonces como alternativa podemos servir una instantánea html, para que los motores de búsqueda puedan dirigir correctamente a los usuarios humanos a la URL en la que esperarían encontrar los datos solicitados (y de una manera presentable). Pero el desafío final es ¿cómo determinamos el tipo de usuario? Sí, posiblemente podamos usar .htaccess o algo así para reescribir la URL de los robots de los motores de búsqueda que detectamos, pero no estoy seguro de cuán a prueba y a prueba de futuro es esto. También es posible que Google penalice a las personas por hacer este tipo de cosas, pero no lo he investigado por completo. Entonces, el combo (pushstate + metaetiqueta de google) parece ser una solución probable.