¿Es pushState
malo si necesita motores de búsqueda para leer su contenido?
No, se habla de pushState
lograr 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,
- Google ve un enlace a
example.com/#!/blog
- Solicitudes de Google
example.com/?_escaped_fragment_=/blog
- 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 pushState
es 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?
El enfoque de Facebook: sirva el mismo contenido en la URL en la site.com/blog
que se transformaría su aplicación cliente cuando ingrese /blog
al estado. (Facebook aún no usa pushState
que yo sepa, pero lo hacen con hashbangs)
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 el robot de Google, esto se enrutará a _escaped_fragment_
lo que desee. Para otros clientes, podría pushState
volver 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 GET
es 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 /blog
a /?content=/blog
su 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 pushState
como parte de una API de historial más conveniente y no como una forma de evitar el uso de hashbangs.