pushState et SEO

Question

De nombreuses personnes ont dit qu'il fallait utiliser pushState plutôt que hashbang.

Ce que je ne comprends pas, c'est comment faire pour être compatible avec les moteurs de recherche sans utiliser le hashbang ?

On peut supposer que le contenu de votre pushState est généré par du code JavaScript côté client.

Le scénario est le suivant :

Je suis sur example.com . Mon utilisateur clique sur un lien : href="example.com/blog"

pushState capture le clic, met à jour l'URL, récupère un fichier JSON quelque part et crée la liste des articles de blog dans la zone de contenu.

Avec les hashbangs, Google sait qu'il doit se rendre à l'URL du fragment échappé pour obtenir son contenu statique.

Avec pushState, Google ne voit rien car il ne peut pas utiliser le code JavaScript pour charger le JSON et créer ensuite le modèle.

La seule façon de procéder que je vois est de rendre le modèle du côté du serveur, mais cela annule complètement les avantages de pousser la couche d'application vers le client.

Si je comprends bien, pushState n'est pas du tout adapté au référencement pour les applications côté client ?

Answer 1

Est pushState mauvais si vous avez besoin que les moteurs de recherche lisent votre contenu ?

Non, la discussion sur pushState a pour but d'accomplir le même processus général que les hashbangs, mais avec des URLs de meilleure qualité. Réfléchissez à ce qui se passe réellement lorsque vous utilisez des hashbangs...

Vous dites :

Avec les hashbangs, Google sait qu'il doit se rendre à l'URL du fragment échappé pour obtenir son contenu statique.

En d'autres termes,

1. Google voit un lien vers example.com/#!/blog
2. Demandes de Google example.com/?_escaped_fragment_=/blog
3. Vous retourner un instantané du contenu que l'utilisateur devrait voir

Comme vous pouvez le constater, il s'appuie déjà sur le serveur. Si vous ne fournissez pas un instantané du contenu du serveur, votre site ne sera pas indexé correctement.

Alors comment Google va-t-il voir quelque chose avec pushState ?

Avec pushState, google ne voit rien car il ne peut pas utiliser le javascript pour charger le json et créer ensuite le modèle.

En fait, Google va voir tout ce qu'il peut demander à site.com/blog . Une URL pointe toujours vers une ressource sur le serveur, et les clients obéissent toujours à ce contrat. Bien sûr, pour les clients modernes, Javascript a ouvert de nouvelles possibilités de récupération et d'interaction avec le contenu sans une URL. page rafraîchir, mais les contrats sont les mêmes.

Donc l'élégance voulue de pushState c'est qu'il sert le même contenu à tous les utilisateurs, anciens et nouveaux, compatibles JS ou non, mais les nouveaux utilisateurs bénéficiez d'une expérience améliorée .

Comment faire pour que Google voie votre contenu ?

1. L'approche Facebook - servir le même contenu à l'URL site.com/blog dans laquelle votre application client se transformerait lorsque vous pousseriez /blog sur l'État. (Facebook n'utilise pas pushState pas encore à ma connaissance, mais ils le font avec les hashbangs)

2. L'approche Twitter - rediriger toutes les URL entrantes vers l'équivalent hashbang. En d'autres termes, un lien vers "/blog" pousse /blog sur l'État. Mais s'il est demandé directement, le navigateur arrive à #!/blog . (Pour Googlebot, cela conduirait alors à _escaped_fragment_ comme vous le souhaitez. Pour les autres clients, vous pouvez pushState de retour à la jolie URL).

Alors, est-ce que vous perdez le _escaped_fragment_ capacité avec pushState ?

Dans deux commentaires différents, vous avez dit

Le fragment échappé est complètement différent. Vous pouvez servir du contenu non thématique pur, du contenu en cache, et ne pas être soumis à la même charge que les pages normales.

La solution idéale serait que Google s'occupe des sites JavaScript ou mette en place un moyen de savoir qu'il y a un fragment d'URL échappé même pour les sites pushstate (robots.txt ?).

Les avantages que vous mentionnez ne sont pas limités à _escaped_fragment_ . Il se charge de la réécriture pour vous et utilise un fichier spécialement appelé GET Le paramètre est vraiment un détail d'implémentation. Il n'y a rien de vraiment spécial à son sujet que vous ne pourriez pas faire avec des URLs standards - en d'autres termes, réécrire /blog a /?content=/blog par vous-même en utilisant mod_rewrite ou l'équivalent de votre serveur.

Et si vous ne serviez pas du tout de contenu côté serveur ?

Si vous ne pouvez pas réécrire les URLs et servir un certain type de contenu à l'adresse /blog (ou tout autre état que vous avez poussé dans le navigateur), alors votre serveur ne respecte plus vraiment le contrat HTTP.

C'est important car le rechargement d'une page (pour quelque raison que ce soit) entraînera l'extraction du contenu de cette URL. _(Voir https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "view-source et reload vont tous deux récupérer le contenu de la nouvelle URI si celle-ci a été poussée.")_

Ce n'est pas que dessiner les interfaces utilisateur une fois sur le côté client et charger le contenu via des API JS soit un mauvais objectif, c'est juste que cela n'est pas vraiment pris en compte avec HTTP et les URL et que ce n'est pas rétro-compatible.

En ce moment, C'est exactement ce à quoi sont destinés les hashbangs - pour représenter des états de page distincts qui sont navigués sur le client et non sur le serveur. Un rechargement, par exemple, chargera l'élément même qui peut ensuite lire, analyser et traiter la valeur hachée.

Il se trouve juste qu'ils ont a également été utilisé (notamment par Facebook et Twitter) pour changer l'historique vers un emplacement côté serveur sans rafraîchissement de la page. C'est dans ces cas d'utilisation que les gens recommandent d'abandonner les hashbangs pour le pushState.

Si vous rendez tout le contenu côté client, vous devez penser à pushState comme faisant partie d'une API d'historique plus pratique, et non comme un moyen d'éviter d'utiliser les hashbangs.

Answer 2

Pourquoi ne pas utiliser la balise méta suggérée par Google pour ceux qui ne veulent pas que leurs URL soient hachées : <meta name="fragment" content="!">

Voir ici pour plus d'informations : https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Malheureusement, je ne pense pas que Nicole ait clarifié le problème que je pensais que le PO avait. Le problème est simplement que nous ne savons pas à qui nous servons le contenu si nous n'utilisons pas le hash-bang. Pushstate ne résout pas ce problème pour nous. Nous ne voulons pas que les moteurs de recherche disent aux utilisateurs finaux de naviguer vers une URL qui crache du JSON non formaté. Au lieu de cela, nous créons des URL (qui déclenchent d'autres appels vers d'autres URL) qui récupèrent des données via AJAX et les présentent à l'utilisateur de la manière que nous préférons. Si l'utilisateur n'est pas un être humain, nous pouvons également servir un instantané html, de sorte que les moteurs de recherche puissent diriger correctement les utilisateurs humains vers l'URL où ils s'attendent à trouver les données demandées (et de manière présentable). Mais le défi ultime est de savoir comment déterminer le type d'utilisateur. Oui, nous pouvons éventuellement utiliser .htaccess ou quelque chose d'autre pour réécrire l'URL pour les moteurs de recherche que nous détectons, mais je ne suis pas sûr que cette solution soit totalement sûre et à l'épreuve du temps. Il est également possible que Google pénalise les personnes qui font ce genre de choses, mais je n'ai pas fait de recherches approfondies à ce sujet. La combinaison (pushstate + meta tag de Google) semble donc être une solution probable.

Answer 3

Toutes les discussions intéressantes sur pushState et #! et je ne vois toujours pas comment pushState remplace l'objectif de # ! comme le demande le posteur original.

La solution que nous avons trouvée pour rendre notre site/application Ajax basé à 99 % sur JavaScript et apte à être référencé dans les moteurs de recherche est la suivante #! bien sûr. Puisque le rendu client est effectué via HTML, JavaScript et PHP, nous utilisons la logique suivante dans un chargeur contrôlé par notre page d'atterrissage. Les fichiers HTML sont totalement séparés du JavaScript et du PHP car nous voulons le même HTML dans les deux (pour la plupart). Le JavaScript et le PHP font à peu près la même chose, mais le code PHP est moins compliqué que le JavaScript et offre une expérience utilisateur beaucoup plus riche.

Le JavaScript utilise jQuery pour injecter dans le HTML le contenu qu'il souhaite. Le PHP utilise PHPQuery pour injecter dans le HTML le contenu qu'il souhaite - en utilisant "presque" la même logique, mais de manière beaucoup plus simple puisque la version PHP ne sera utilisée que pour afficher une version pouvant être référencée avec des liens pouvant être référencés et ne sera pas utilisée comme la version JavaScript.

Les trois composants qui constituent une page, page.htm, page.js et page.php existent pour tout ce qui utilise le fragment échappé pour savoir s'il faut charger la version PHP à la place de la version JavaScript. La version PHP n'a pas besoin d'exister pour les contenus non exploitables par les moteurs de recherche (comme les pages qui ne peuvent être vues qu'après la connexion de l'utilisateur). Tout est simple.

Je reste perplexe quant à la façon dont certains développeurs frontaux parviennent à développer de superbes sites (avec la richesse de Google Docs) sans utiliser les technologies côté serveur en conjonction avec celles du navigateur... Si JavaScript n'est même pas activé, alors notre solution JavaScript à 99 % ne fera évidemment rien sans le PHP en place.

Il est possible d'avoir une belle URL pour atterrir sur une page servie par PHP et rediriger vers une version JavaScript si JavaScript est activé, mais ce n'est pas beau du point de vue de l'utilisateur, puisque les utilisateurs sont le public le plus important.

En passant. Si vous créez un simple site web qui peut fonctionner sans aucun JavaScript, alors je peux voir que pushState est utile si vous voulez améliorer progressivement l'expérience de l'utilisateur à partir d'un simple contenu rendu statiquement vers quelque chose de mieux, mais si vous voulez donner à votre utilisateur la meilleure expérience possible dès le départ... disons votre dernier jeu écrit en JavaScript ou quelque chose comme Google Docs, alors son utilisation pour cette solution est quelque peu limitée car le retour en arrière ne peut pas aller plus loin avant que l'expérience de l'utilisateur soit douloureuse par rapport à la vision du site.