pushState y SEO


80

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?


Nota para los futuros lectores: esta pregunta es obsoleta . Lea la declaración oficial de Google : en resumen, el robot de Google admite JS ahora.
mik01aj

Respuestas:


17

¿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.


3
@NickC, ya veo, ahora creo que una mejor solución es mostrar el contenido inicialmente sin ningún JS. Pero en la parte superior de su JS (después de la página cargada y dom listo) ejecute un código inmediatamente para ocultar el contenido HTML que se mostró inicialmente o reemplazarlo con la mejora JS. Por ejemplo, uso cuadrículas de datos jquery, por lo que primero mostraría una tabla HTML, luego cargaría el JS inmediatamente para transformar / ocultar / reemplazar los datos tabulares normales que se muestran en la versión de cuadrícula JS. Luego, a partir de ese momento, cualquier otra solicitud de ajax se puede atender como JSON emparejado con la actualización de URL a través de pushstate.
Martillo programador

¿Cómo es su experiencia con la solución que sugirió? ¿Google indexó este HTML "temporal"? ¿Aparece correctamente en la búsqueda de Google relevante? Además, ¿no significa que la experiencia es un poco 'nerviosa' ya que la página HTML inicial se 'actualiza' con html generado por JS?
Nilesh Kale

@NileshKale Aquí está la solución con la que trabajé y cumple muy bien el trabajo: stackoverflow.com/questions/22824991/… . Solo paso una tabla HTML y también jqgrid con el equivalente JSON (a lo que está en el HTML). SEO lee el HTML y el usuario obtiene una experiencia mejorada y todas las solicitudes posteriores a través de ajax. Usando pushstate, puedo actualizar la URL en función de cómo el usuario clasifica / pagina la cuadrícula (sin necesidad de un hashbang). Esto permite al usuario guardar la URL y volver a los mismos resultados.
prograhammer

En unos días intentaré editar mi respuesta para explicarlo mejor.
prograhammer

1
El esquema de rastreo AJAX ahora está en desuso: developers.google.com/webmasters/ajax-crawling/docs/… . Se recomienda cambiar los sitios que lo usan: plus.google.com/+JohnMueller/posts/LT4fU7kFB8W
Protector one

97

¿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.


3
@Harry - ¿Leíste el resto de mi respuesta? Una URL es una URL, es decir, un localizador de recursos. ¿El servidor cree que existe contenido en site.com/blog? De lo contrario, no existe para los motores de búsqueda. El propósito de pushStateno es evitar eso. Es por conveniencia. Los hashbangs tampoco solucionan esto, y _escaped_fragment_es una solución complicada que aún depende de que el servidor tenga una instantánea del contenido generado por JS (visto por los usuarios normales, como usted lo dice). pushStateen realidad simplifica todo esto.
Nicole

1
@Harry: hasta que las URL estén diseñadas para servir contenido del lado del cliente, todavía hacen referencia a un recurso en el servidor, y los clientes los tratarán de esa manera, incluidos los bots. No significa que su objetivo de hacer todo lo posible en el cliente no sea válido, pero por el momento puede que tenga que lograrlo usando hashbangs (feos). Actualicé mi respuesta para su caso de uso.
Nicole

1
@Harry En primer lugar, solo me desvío de lo que Google dice que hacen _escaped_fragment_, y no sé qué haces específicamente. Pero por lo que dice Google, supongo que debe estar sirviendo algún tipo de contenido por parte del servidor cuando vea ese parámetro de consulta. En su caso, requeriría algunos trucos, pero podría servir algún <noscript>contenido o algo más /blogy luego hacer que JS construya la página que desea. O bien, puede intentar detectar bots y ofrecer intencionalmente contenido completamente diferente.
Nicole

2
Una vez más, la respuesta correcta y mejor no se elige como correcta ... mala, mala.

1
Si tengo un enlace como:, <a href="product/productName" onclick="showProduct(product)">A product</a>y el clic comienza con " preventDefault()", entonces AJAXly carga el nuevo contenido sobre el producto en la página y me aseguro de que el enlace "... / product / productName" cargue una versión de la página donde se incluirá el contenido específico del producto en la respuesta del servidor --- entonces, el sitio seguirá funcionando dinámicamente pero también tendrá contenido estático disponible yendo directamente a un enlace de producto, ¿verdad? No hay necesidad de pushState o hashbang de esta manera, ¿no?
Yuval A.

1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.