Bug #524
ferméBug #525: Supprimer le bouton "Retour aux résultats" / Résoudre les problèmes de SERP magiques
SERP : le bouton "retour aux résultats" amène aux mauvais résultats
100%
Description
Tel qu'expliqué par Élodie :
Une anomalie super lol (cache-cache je pense) :
Je fais une recherche avec un premier mot clé -> Goetz (https://www.inserm.fr/?s=goetz)
Je regarde plusieurs résultats, dont https://www.inserm.fr/actualite/lendothelium-vasculaire-un-nouvel-allie-dans-la-formation-de-metastases/
Je fais une seconde recherche avec un autre mot clé -> métastases (https://www.inserm.fr/?s=m%C3%A9tastases)
Comme je suis bête et que ça n’est pas rouge foncé, je regarde la même actu… et comme le bouton revenir aux résultats est là, je clique dessus. Et là… j’arrive sur la page des résultat de la première recherche (avec le mot clé Goetz)
Ce tour de magie marche à la fois en connecté et en non connecté
Autrement dit : Quand on fait 2 recherches successives (A et B) qui donnent des résultats en commun, on peut revenir vers la mauvaise liste de résultats. On part des SERP B, on clique un item, on fait "retour aux résultats", et là on revient aux SERP A.
Voir vidéo en PJ.
Fichiers
Mis à jour par ggallais il y a 11 mois
Obsolète, j'ai désintallé SearchWP Metric qui produisait ces variables.
Patrice note que c'est possible parce qu'on a en réalité plusieurs URLs, selon d'où on vient.
Si je fais une recherche, et que je clique un item, je n'arrive pas sur l'URL nu (par ex)
J'arrive sur des URLs qui incluent des variables, et qui permettent ensuite de ramener au bon endroit :
https://www.inserm.fr/actualite/lendothelium-vasculaire-un-nouvel-allie-dans-la-formation-de-metastases/?swpmtx=cc1df207e1c8fc621c8793c9a5bceccd&swpmtxnonce=f4ec31a861https://www.inserm.fr/actualite/lendothelium-vasculaire-un-nouvel-allie-dans-la-formation-de-metastases/?swpmtx=1c620638686be6a3f10ef85b6789b5f9&swpmtxnonce=177885406b
Ici les deux URLS ramènent à
https://www.inserm.fr/?s=goetz
Note qu'il y a 2 variables : swpmtx et swpmtxnonce-
Mis à jour par ggallais il y a 10 mois
Testé avec https://www.inserm.fr/actualite/web-emission-arthrose-comment-attenuer-la-douleur/
- d'abord on cherche "arthrose", on clique le résultat
- bouton retour vers ?s=arthrose
- on cherche "douleur", on clique le résultat
- bouton retour vers ?s=arthrose
- on cherche "émission", on clique
- bouton retour vers ?s=arthrose
- on cherche "atténuer", on lcique
- bouton retour vers ?s=arthrose
DONC c'est la 1re recherche qui reste.
En parallèle, Élodie fait sortir des boutons retours qui ne correspondent à aucune recherche qu'elle a fait
Mis à jour par ggallais il y a 10 mois
- Fichier magie-serp.jpg magie-serp.jpg ajouté
Voilà le diagnostic au 30 janvier.
Quand on demande la page sans passer par la recherche, on nous sert la page "standard" depuis le cache.
Quand un utilisateur demande la page depuis la recherche, ça ajoute un bouton "back" qui ramène vers les SERP.
Comme il y a le bouton "back" cette page n'est pas la même que la page standard.
À partir de là, 2 possibilités :
1) Il n'existe pas de version de la page avec "back" en cache : litespeed met en cache cette page.
Le bouton "back" ramène à une page de recherche, qui correspond à celle que vient de faire l'utilisateur.
S'il clique "retour aux résultats", il arrive sur la page de SERP d'où il vient.
2) Un autre utilisateur a déjà demandé la même page depuis des SERP récemment.
Il y a donc une version de la page avec "back" déjà en cache : litespeed sert cette page.
Le bouton "back" ramène à une page de recherche qui correspond à celle faite PAR L'AUTRE UTILISATEUR.
Si l'utilisateur actif clique "retour aux résultats", il arrive sur la page de SERP mise en cache.
Voir l'image si ça aide.
Ce que je comprends :
- La page mise en cache avec back c'est du cache public.
- Elle est servie à toute personne qui a besoin de la page avec "back", quelle que soit sa requête.
- Si on voulait que la page avec "back" corresponde toujours à la requête de l'user, faudrait que le contenu du bouton back soit dans un cache privé (ou ESI ?)
- Dans ce cas là seulement, toute la page est servie en cache à l'user, mais pas le contenu du bouton back, qui est servi depuis un cache privé lié à l'user.
La solution c'est donc de changer la façon dont est mis en cache ce bouton back.
Attendu :
- Vérifier si ce diagnostic correspond à ce qui se passe en réalité
- Identifier le code qui produit le bouton back
- Identifier où est stockée l'URL contenue dans le bouton back
- Voir avec Pierre si c'est une bonne idée / possible de changer le fonctionnement du cache pour que l'URL du bouton back corresponde à la requête précédente de l'user.
Mis à jour par ggallais il y a 10 mois
Réponse de Medhy :
Le code fait la chose suivante :
Vérification de l'existence d'un HTTP_REFERER (url de la page précédente)
Si ça existe et que ça correspond à une query (au sens wordpress), alors le bouton apparaît avec cette valeur comme URL
Si ça n'existe pas, affichage de la page sans le bouton
=> Attention : certains navigateurs et/ou addons peuvent masquer/modifier le HTTP_REFERER (confidentialité/tracking), mais bon, il ne s'affiche que si une valeur cohérente est dedans donc j'ai dû mal à comprendre comment ce soucis peut exister autrement qu'avec du cache
themes > inserm > components > parts > hero-dossier.php
themes > inserm > components > parts > hero-page.php
themes > inserm > components > parts > hero-single.php
Mis à jour par ggallais il y a 10 mois
Voilà le code :
<?php if ( ! empty( $_SERVER['HTTP_REFERER'] ) ) :
$referer = parse_url( $_SERVER['HTTP_REFERER'] );
if ( ! empty( $referer['query'] ) ) :
parse_str( $referer['query'], $query );
if ( isset( $query['s'] ) ) : ?>
<div class="article__back push">
<a href="<?php echo esc_url( $_SERVER['HTTP_REFERER'] ); ?>" class="btn btn--primary btn--sm">
<i class="wpel-icon dashicons-before dashicons-arrow-left-alt2"></i>
<?php _e( 'Back to results', 'inserm' ); ?>
</a>
</div>
<?php endif ?>
<?php endif ?>
<?php endif ?>
Mis à jour par ggallais il y a 9 mois
On a eu une réunion avec Hosterra pour le #519, qui a apporté une solution pour ce ticket (réunion du 11 mars 2025).
En investiguant #519 Pierre a trouvé de lui-même #524.
On peut résoudre le problème en utilisant la fonctionnalité ESI, qui est propre à LiteSpeed (pas dispo dans Apache/NginX).
On sort le morceau de code qui génère le bouton du template (ou de là où il est), et on le met dans un fichier à part.
Vu le contenu du bouton, y'a même pas besoin que le fichier soit dans WP ou que WP éxecute quoi que ce soit.
Dans LiteSpeed on précise que ce fichier n'est pas à mettre en cache
Optionnel : on préfixe le fichier de esi- pour comprendre son rôle.
Exemple de code à mettre là où est actuellement le bouton :
<esi:include
src="http://example.com/1.html"
alt="http://bak.example.com/2.html"
onerror="continue" />
Autre solution : on utilise un shortcode pour générer ce bouton.
Ensuite on peut dire à LiteSpeed que ce shortcode est en ESI, et même lui donner un TTL.
Mais ça veut dire créer un shortcode.
Mis à jour par ggallais il y a 9 mois
Décision équipe web :
- On vérifie si ce bouton est une bonne pratique web / access identifiée OU PAS
- Si non, on supprime le bouton, mais après les travaux prévus Inovagora
- Si oui, on voit ce qu'on fait
On est d'accord que la recherche est, de base, peu utilisée. Donc ce bouton concerne peu de monde.
Avantage bouton :- si c'est une bonne pratique
- il est là et perso je l'utilise
- Modification du code qui rend le site dépendant de LiteSpeed
- Plus de complexité technique
- Plus d'impact, vu qu'un bout n'est jamais mis en cache
Pour info, le code du bouton est dupliqué à 3 endroits :
- hero-single.php
- hero-dossier.php
- hero-page.php
Mis à jour par ggallais il y a 9 mois
- % réalisé changé de 0 à 70
Bilan :
1. les bonnes pratiques de recherche parlent principalement de e-commerce (ou d'intranet)
2. la recherche est peu utilisée, et par des gens qui savent déjà ce qu'ils veulent trouver et s'attendent à ce qu'elle marche mal
3. la recherche sur site est d'abord une bouée de secours après google, l'historique du navigateur, les favoris, etc.
4. notre moteur de recherche est basique, et à d'autres améliorations prioritaires
Donc on va lâcher le bouton.