pushState y SEO

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

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

Es de suponer que su contenido pushState se genera mediante código 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 algún lugar y crea la lista de publicaciones de blog en el área de contenido.

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

Con pushState, Google simplemente no ve nada, ya que no puede usar el código JavaScript para cargar el JSON y luego 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 compatible con SEO para aplicaciones del lado del cliente?

¿Qué hay de usar la metaetiqueta que sugiere Google para aquellos que no quieren hash-bangs en sus URL? <meta name="fragment" content="!">

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

Desafortunadamente, no creo que Nicole haya aclarado el problema que pensé que tenía el OP. El problema es simplemente que no sabemos a quién le estamos sirviendo contenido si no usamos el hash-bang. Pushstate no resuelve esto por nosotros. No queremos que los motores de búsqueda le digan a los usuarios finales que naveguen a alguna URL que escupe 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 los presentamos al usuario de la manera que prefiramos. Si el usuario no es un humano, entonces, como alternativa, podemos ofrecer 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 para reescribir la URL de los bots de los motores de búsqueda que detectamos, pero no estoy seguro de cuán completo y a prueba de futuro sea esto. También es posible que Google pueda penalizar a las personas por hacer este tipo de cosas, pero no lo he investigado completamente. Entonces, el combo (pushstate + metaetiqueta de Google) parece ser una solución probable.

¿Es pushStatemalo si necesita motores de búsqueda para leer su contenido?

No, se habla de pushStatelograr el mismo proceso general para los hashbangs, pero con URL más atractivas. Piense en lo que realmente sucede cuando usa hashbangs ...

Tu dices:

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

En otras palabras,

1. Google ve un enlace a example.com/#!/blog
2. Solicitudes de Google example.com/?_escaped_fragment_=/blog
3. Usted regresa una instantánea del contenido que el usuario debe ver

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

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

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

De hecho, Google verá todo lo que pueda solicitar site.com/blog. Una URL todavía apunta a un recurso en el servidor y los clientes siguen cumpliendo este contrato. Por supuesto, para los clientes modernos, Javascript ha abierto nuevas posibilidades para recuperar e interactuar con contenido sin actualizar la página , pero los contratos son los mismos.

Entonces, la elegancia deseada pushStatees que sirve el mismo contenido a todos los usuarios, antiguos y nuevos, con capacidad JS y no, pero los nuevos usuarios obtienen una experiencia mejorada .

¿Cómo logras que Google vea tu contenido?

1. El enfoque de Facebook: sirva el mismo contenido en la URL en la site.com/blogque se transformaría su aplicación cliente cuando ingrese /blogal estado. (Facebook aún no usa pushStateque 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 /blogal estado. Pero si se solicita directamente, el navegador termina en #!/blog. (Para el robot de Google, esto se enrutará a _escaped_fragment_lo que desee. Para otros clientes, podría pushStatevolver a la URL bonita).

Entonces, ¿pierde la _escaped_fragment_capacidad con pushState?

En un par de comentarios diferentes, dijiste

El fragmento escapado es completamente diferente. Puede ofrecer contenido puro sin tema, contenido en caché y no estar bajo la carga de las páginas normales.

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

Los beneficios que mencionaste no están aislados _escaped_fragment_. Que haga la reescritura por usted y use un parámetro con un nombre especial GETes realmente un detalle de implementación. No hay nada realmente especial en él que no se podía hacer con las direcciones URL estándar - en otras palabras, reescribir /bloga /?content=/blogsu cuenta utilizando mod_rewrite o el equivalente en su servidor.

¿Qué pasa si no sirve ningún contenido del lado del servidor?

Si no puede reescribir las URL y entregar algún tipo de contenido en /blog(o en cualquier estado que haya introducido en el navegador), entonces su servidor ya no cumple con el contrato HTTP.

Esto es importante porque la recarga de una 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 recuperarán el contenido en el nuevo URI si se presionó uno").

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

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

Da la casualidad de que también se han utilizado (especialmente por Facebook y Twitter) para cambiar el historial a una ubicación del lado del servidor sin actualizar la página. Es en esos casos de uso que las personas recomiendan abandonar los hashbangs para pushState.

Si renderiza todo el contenido del lado del cliente, debe pensar en ello pushStatecomo parte de una API de historial más conveniente y no como una forma de evitar el uso de hashbangs.

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

Nuestra solución para hacer que nuestro sitio / aplicación Ajax basado en JavaScript en un 99% sea SEOable, #!por supuesto. Dado que la representación del cliente se realiza a través de HTML, JavaScript y PHP, usamos 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 PHP solo se usará para mostrar una versión SEOable con enlaces SEOable y no interactuar con ella como la versión 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 de escape para saber si cargar la versión PHP en lugar de la versión JavaScript. No es necesario que la versión PHP exista para contenido no apto para SEO (como páginas que solo se pueden ver después de iniciar sesión). Todo es sencillo.

Todavía estoy desconcertado de cómo algunos desarrolladores de aplicaciones para el usuario logran desarrollar excelentes sitios (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 JavaScript al 99% Por supuesto, no hará nada sin PHP en su lugar.

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

En otros comentarios. Si está creando un sitio web simple que puede funcionar sin JavaScript, entonces puedo ver que pushState es útil si desea mejorar progresivamente su experiencia de usuario desde un contenido simple renderizado estáticamente a algo mejor, pero si desea brindarle a su usuario la la mejor experiencia desde el principio obtén ... digamos que tu último juego escrito en JavaScript o algo como Google Docs, entonces su uso para esta solución es algo limitante, ya que retroceder con gracia solo puede llegar hasta cierto punto antes de que la experiencia del usuario sea dolorosa en comparación con la visión del sitio.