Google indexera-t-il toujours une page si j'utilise une variable $ _SESSION?
Pour quelques pages de notre site, j'écris un widget qui s'appuie sur ce qu'il affiche sur d'autres pages pour déterminer ce qu'il affiche sur la page actuelle. Fondamentalement, le but est simplement de s'assurer qu'il n'y a pas de contenu en double. Ce n'est pas individualisé par utilisateur, cela dépend simplement de ce qui est affiché ailleurs à l'heure actuelle.
Mon CTO ne me permettra pas d'enregistrer les données dans la base de données ou même un fichier journal pour conserver un état persistant, donc pour y parvenir, la seule autre façon dont je peux penser est de définir une variable $ _SESSION et d'y stocker l'état persistant. Cependant, je réalise que le robot de google n'utilise probablement pas de cookies, donc je ne sais pas si cela fonctionnera.
Est-ce que quelqu'un sait si Google indexera toujours les pages si ce qu'elles affichent repose sur une variable de session? Sinon, existe-t-il un autre moyen de stocker un état persistant sur des pages qui n'utilisent pas la base de données ou le fichier journal que googlebot comprendra?
En septembre 2018 John Mueller de Google a tweeté:
Voir aussi:
Source: https://www.seroundtable.com/google-cookies-seo-26344.html
John Mueller de Google a déclaré sur Twitter que Google ne peut certainement pas indexer une page qui nécessite des cookies. Il a dit que si vous voulez que Google indexe la page, assurez-vous de "supprimer la dépendance" sur les cookies.
Que faites-vous lorsqu'un utilisateur visite le site pour la première fois? Vraisemblablement vous calculez ce qui doit être affiché, affichez-le et "cachez" quelque chose dans la session (comme vous le mentionnez). Chaque visite de Googlebot est comme la première visite de l'utilisateur (comme le mentionne @Simon - le Googlebot n'utilise pas de cookies, donc aucune donnée de session ne peut persister).
Donc, en supposant que vous affichez ce contenu à l'utilisateur lors de sa première visite, GoogleBot verra également ce contenu, sauf qu'il devra être calculé (ce qui pourrait être lent?) À chaque demande.
Utilisez un hachage de la date UTC et de l'adresse IP, puis utilisez le hachage comme source d'un générateur de nombres aléatoires, utilisez le générateur de nombres aléatoires pour générer une permutation du contenu qui ira à quelle page.
Résultats: contenu de page aléatoire qui varie dans le temps tout en étant statique par utilisateur, contenu unique par page, aucun état stocké n'importe où (pas dans les cookies, pas dans les paramètres d'URL de session, pas dans db, etc.), compatible avec tous les moteurs de recherche.
inconvénient: vous avez besoin d'une liste statique de toutes les URL afin de vous assurer que chaque URL a un contenu unique. Chaque demande de page devrait mapper le contenu à chaque URL dans le même modèle aléatoire (basé sur la graine statique hachée à partir de la date + etc.). Cela nécessite un temps de traitement qui est linéairement proportionnel au nombre d'URL.