Pages :
Bonjour,

Question à laquelle je n'ai pas trouvé de réponse, faut-il encoder une URL canonique ?

<link rel="canonical" href="https://www.monsite.com/b.php?ong=42U 800 x 800&amp;ege=Ok&amp;h=H1OL*mad">


ou :

$canonique = rawurlencode ($canonique);


<link rel="canonical" href="https://www.monsite.com/b.php%3Fong%3D42U%20800%20x%20800%26amp%3Bege%3DOk%26amp%3Bh%3DH1OL%2Amad">


Je subodore et j'espère qu'il ne faut pas encoder.

Qu'en pensez-vous ?
Modifié par boteha_2 (09 Mar 2025 - 15:02)
oui google apprécie çà

dans le head html
<link rel="canonical" href="https://tondomaine/tapageindex.html">
Bonjour drphilgood,

Merci de ton suivi.

Google aime les URL canoniques dans le HEAD, d'accord, mais ce n'est pas la question.

La question est : faut-il encoder cette URL, par exemple par la fonction PHO rawurlencode () ?
Modérateur
Bonjour,

En théorie, il faudrait encoder, que ce soit pour spécifier une url canonique ou pour tout autre usage. Voir par exemple https://developers.google.com/maps/url-encoding?hl=fr

Note qu'en pratique, il se peut qu'une des briques de la longue chaine de traitement qui va traiter tes urls fassent la conversion pour toi, et qu'en conséquence, ça marchera quand même même si tu n'encodes pas tes urls.

Note que l'emploi des espaces dans une url est un peu plus risqué que n'importe quel autre caractère car si tu laisses un espace sans l'encoder dans l'url, certaines briques de la longue chaine de traitement de cette url peuvent remplacer cet espace par un "+". Il faut donc redoubler de vigilance quand on a des espaces dans une url, qu'ils soient tel quel, remplacés par un "+", ou encodés avec des %, car sinon, le résultat peut être inattendu selon ce qu'on fait de cette url (c'est à dire pas seulement quand on essaie de spécifier une url canonique, mais aussi pour tout autre usage). En d'autres termes, si tu peux éviter les espaces dans les urls, ça te simplifiera la vie.

En ce qui me concerne, j'utilise en php $_SERVER['REQUEST_URI'] que je nettoie éventuellement et que je préfixe par https + Smiley ohwell / + un nom de domaine approprié (pour que ce soit bien l'url canonique que je veux) et que je mets ensuite comme valeur du href dans <link rel="canonical" href="...">. Or, les url contenues dans $_SERVER['REQUEST_URI'] sont déjà encodées avec des % quand c'est nécessaire, ce qui fait que je n'ai pas besoin de les encoder explicitement moi-même.

Par exemple, tu peux tester le code suivant et tu constateras que si tu cliques sur le lien "Hé hé", l'url affichée dans le paragraphe <p> sera encodée avec des % alors qu'on n'a fait à aucun moment explicitement cet encodage dans notre code :
<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<h1>Test</h1>
<p><?php echo $_SERVER['REQUEST_URI'];?></p>
<a href="?v=Hé hé">Hé hé</a>
</body>
</html>


Amicalement,
Bonjour parsimonhi,

Merci pour ces explications.

Je ne comprends pas ton emploi de $_SERVER['REQUEST_URI']
Tu récupères l'URL de la page, non ?
Mais l'URL canonique peut être différente de l'URL de la page, c'est même là le principal intérêt de l'URL canonique.

La plupart de mes URL canoniques sont en .html avec un url-rewrite dans le .htaccess.
Une URL de type monsite.com/script.php?a=nhju&u=125&h=,kjhy125 va avoir comme URL canonique monsite.com/le-beau-produit-455AL.html.

L'article sur Google dit qu'il faut encoder les URL (on est d'accord) mais ne parle pas des URL canoniques.

Si Google encode les URL canoniques, que se passe-t-il avec une URL déjà encodée ?
Il me semble que l'URL subira une nouvelle transformation et deviendra fausse.

Je vais poser la question sur le forum Google pour les webmasters que je trouve d'ailleurs très peu accueillant.
La dernière fois mon sujet a été fermé avant d'obtenir une réponse, les captures d'écran que j'ai voulu charger ont été bloquées alors que tout était innocent...
Modérateur
Bonjour,

boteha_2 a écrit :
Je ne comprends pas ton emploi de $_SERVER['REQUEST_URI']
Tu récupères l'URL de la page, non ?
Mais l'URL canonique peut être différente de l'URL de la page, c'est même là le principal intérêt de l'URL canonique.

La plupart de mes URL canoniques sont en .html avec un url-rewrite dans le .htaccess.
Une URL de type monsite.com/script.php?a=nhju&amp;u=125&amp;h=,kjhy125 va avoir comme URL canonique monsite.com/le-beau-produit-455AL.html.


Je ne m'amuse pas à spécifier une url canonique "à la main" pour chaque page. J'automatise.

L'information donnée par $_SERVER['REQUEST_URI'] me permet de construire l'url canonique, en faisant éventuellement le même genre de transformation que ce qui est fait dans les htaccess. Mais ça permet aussi de traiter les problèmes des noms de domaine (par exemple le cas très courant où les url www.monsite.com/xxx.php et monsite.com/xxx.php affichent la même page). La liste est non limitative. Elle dépend de ce que le développeur d'un site a bricolé sans oublier les éventuels admins de ce site (règle : ne jamais sous-estimer les nuisances potentielles des bricolages des admins).

boteha_2 a écrit :
L'article sur Google dit qu'il faut encoder les URL (on est d'accord) mais ne parle pas des URL canoniques.

Toute url est concernée où qu'elle soit. La liste des caractères qu'on n'a pas besoin d'encoder est limitée à un ensemble assez restreint. Tous les autres caractères doivent être encodés, sinon, l'url est invalide tout simplement.

En pratique, comme je l'ai déjà écrit, les briques de la chaine de traitement des urls, et en particulier les navigateurs, peuvent faire les encodages avant d'utiliser une url si cela n'a pas été fait par le développeur d'un site, ou quand l'internaute entre une url non encodée dans la barre d'adresse. Le résultat, c'est que ça marche la plupart du temps même quand un développeur ou un internaute n'encodent pas leurs urls, mais c'est un coup de bol.

Et en pratique toujours, pour les urls canoniques, si tu veux qu'elles soient vraiment canoniques, il vaut mieux les encoder complètement, sinon, il y a un risque que l'url encodée et l'url non encodée soient considérées comme deux urls distinctes. Smiley cligne

boteha_2 a écrit :
Si Google encode les URL canoniques, que se passe-t-il avec une URL déjà encodée ?
Il me semble que l'URL subira une nouvelle transformation et deviendra fausse.

Non car tout ça est normalisé. Quand il y a un % suivi d'un code dans une url, les logiciels ont l'obligation de considérer qu'il s'agit d'un caractère encodé. Par ailleurs, toute autre séquence de caractères est considérée comme non encodée. En conséquence, Google ne se trompera pas.

boteha_2 a écrit :
Je vais poser la question sur le forum Google pour les webmasters que je trouve d'ailleurs très peu accueillant.


Si tu n'as pas la même réponse, c'est qu'ils se trompent ! Smiley lol Smiley lol Smiley lol

Amicalement,
Modifié par parsimonhi (20 Mar 2025 - 13:44)
Bonjour parsimonhi,

Merci de ton suivi.

parsimonhi a écrit :
Je ne m'amuse pas à spécifier une url canonique "à la main" pour chaque page. J'automatise.


Chez moi aussi c 'est automatique côté PHP.

J'ai deux types d'URL canoniques.
Pour les pages importantes elles sont en .html.
Elles n'ont pas besoin d'être encodées car il n'y a aucun espace ni caractère spécial.

Pour les pages moins importantes elles sont .php? avec chaîne GET.
Je donne une URL canonique pour alléger le boulot des moteurs de recherche.
Celles-là devraient donc être encodées, pas de souci.

Je vais sur le forum Google dès que j'ai le temps et je reviens avec leur réponse.

À suivre.
Bonjour,

J'ai trouvé sur dans le le forum Google un interlocuteur intéressé.

Il confirme qu'il faut encoder.

Il aborde un point que j'allais aborder : & ou &amp;
Il recommande & pour l'URL canonique.

<link rel="canonical" href="https://www.monsite.com/b.php?ong=42U%20800%20x%20800&ege=Ok&h=H1OL%2Amad>


Maintenant, la même URL dans les micro-données, je la mets non encodée et avec &amp; à la place de &.

{
"@type": "ListItem",
"position": 4,
"name": "Le beau produit",
"item": "https://www.monsite.com/b.php?ong=42U 800 x 800&amp;ege=Ok&amp;h=H1OL*mad"
}


Est-ce bon ?
Modifié par boteha_2 (21 Mar 2025 - 20:39)
Modérateur
Bonjour,

1) J'avoue que je ne remplace pas & par &amp; dans l'url spécifiée dans le href du <link rel="canonical">, vu qu'un &amp; est remplacé par un & lors de la longue chaine de traitement de l'url et que quand je fais mon $_SERVER['REQUEST_URI'] en php, il n'y a donc plus de &amp; dedans, même si pour tester j'avais, pour faire afficher la page, cliqué sur un lien qui avait ces &amp; !

Mais à la réflexion, et bien que "celui qui a dit comme moi" pour l'encodage des urls conseille de faire comme je fais actuellement pour les &, il est bien possible qu'on ait tort tous les deux.

La première raison c'est que la balise <link> étant dans un document html, on devrait remplacer les & par &amp; (même si ce n'est pas vraiment obligatoire quand il n'y a pas ambiguïté).

Et la deuxième raison, c'est qu'il pourrait y avoir ambiguïté assez facilement justement, en particulier parce qu'à une époque, le ; de &amp; n'était pas obligatoire (ainsi que pour n'importe quelle entité html, ce qui fait un gros paquet de possibilités), et qu'en conséquence certaines briques de la longue chaine de traitement des urls pourraient considérer encore de nos jours qu'un & suivi de lettres même non suivies d'un ; est en fait une entité html.

Tu peux à ce propos tester le code php ci-dessous qui plante lorsqu'on clique sur le lien, car le navigateur considère que &lt est en fait un <. Si les logiciels de traitement des urls des moteurs de recherche font la même chose, ton url canonique ne sera pas ce qui est attendu.
<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<h1>Test</h1>
<p><?php echo $_GET['lt_2'];?></p>
<a href="?lt_1=1&lt_2=2">Cliquez moi</a>
</body>
</html>


Ça me semble donc plus périlleux finalement de mettre seulement & plutôt que &amp; dans le href du <link rel="canonical">.

Bref, pas simple !

2) Pour ce qui est des micro-données, je ne sais pas (je n'utilise jamais ça).

Amicalement,
bonjour parsimonhi,

Merci de ton suivi.

Pas simple, en effet, essayons d'aller au bout du problème.

On peut inverser la question :

Quel est l'inconvénient à avoir &amp; à la place de & ?

parsimonhi a écrit :
2) Pour ce qui est des micro-données, je ne sais pas (je n'utilise jamais ça).


J'ai l'impression que les micro-données sont devenues primordiales pour Google.
Des sites qui n'étaient pas référencés à cause de leur code html pourri arrivent maintenant en première page grâce aux micro-données.
Modérateur
Bonjour,

boteha_2 a écrit :
Quel est l'inconvénient à avoir &amp; à la place de & ?
Je n'en vois pas.

Par contre j'ai trouvé une autre raison de mettre &amp; à la place de & dans le href d'une url canonique. Si tu as, pour reprendre mon exemple précédent, une url se terminant par ?lt_1=1&lt_2=2 et que tu ne mets pas de &amp; dans le href de l'url canonique, alors si tu demandes à ton navigateur de montrer le code source de ta page, tu verras que l'url canonique est cliquable. Et que si tu cliques dessus, bah le navigateur affiche la page mais le &lt est remplacé par un <. Si un robot s'amuse lui aussi à faire ce clic, le résultat ne devrait pas être terrible pour ton référencement ! Smiley smile

boteha_2 a écrit :
J'ai l'impression que les micro-données sont devenues primordiales pour Google.
Des sites qui n'étaient pas référencés à cause de leur code html pourri arrivent maintenant en première page grâce aux micro-données.
Je n'ai pas trop de problèmes de référencement, mais je veux bien te croire. Les codes html pourris, ce n'est pas ça qui manquent sur le web. Et ça empire à chaque fois qu'un nouvel outil magique permettant normalement de coder mieux et plus vite est mis à disposition des développeurs (c'était la pique du jour Smiley lol Smiley lol Smiley lol ).

Et si un moteur de recherche en a marre de se faire mal aux yeux en analysant ces codes html, les micro-données m'ont l'air effectivement de pouvoir constituer un bon palliatif.

Amicalement,
parsimonhi a écrit :
Et si un moteur de recherche en a marre de se faire mal aux yeux en analysant ces codes html, les micro-données m'ont l'air effectivement de pouvoir constituer un bon palliatif.


Les micro-données sont une usine à gaz avec des trous énormes.
Par exemple ils n'ont pas pensé qu'un produit puisse exister en plusieurs versions.
Tu vends un ruban en 10 couleurs et 10 longueurs, 100 références distinctes.
Tu fais une page avec un tableau de 100 lignes, rien dans la nomenclature ne te permet de décrire ce genre de page.
Ils préfèrent 100 pages à référencer par les moteurs de recherche.
Modérateur
Bonjour,
boteha_2 a écrit :
Les micro-données sont une usine à gaz avec des trous énormes.
Par exemple ils n'ont pas pensé qu'un produit puisse exister en plusieurs versions.
Tu vends un ruban en 10 couleurs et 10 longueurs, 100 références distinctes.
Tu fais une page avec un tableau de 100 lignes, rien dans la nomenclature ne te permet de décrire ce genre de page.
Ils préfèrent 100 pages à référencer par les moteurs de recherche.

Mon moteur de recherche me dit lui qu'ils y ont peut-être pensé bien tu penses qu'ils puissent ne pas y avoir pensé.

Voir par exemple https://zeo.org/resources/blog/how-to-manage-product-variants-with-isvariantof-schema

Amicalement,
parsimonhi a écrit :
Mon moteur de recherche me dit lui qu'ils y ont peut-être pensé bien tu penses qu'ils puissent ne pas y avoir pensé.


Super, cela répond exactement au problème.
Cela date d'il y a un an.

Mais tu vois l'usine à gaz et la lourdeur de la page quand tu as 150 versions, ce qui peut être le cas.

Il suffirait de pouvoir dire :

Ruban en soie tissée etc...
Variant : couleur, longueur
Nombre : 150 versions
couleur : rouge, vert, noir, bleu....
longueur en m : 1, 2, 3, 5, 7.8 , 10...
Prix : de 1 à 40 euros
Stock : à vérifier selon la version (indiqué sur le site)

Terminé, qu'est-ce qu'il a besoin de savoir en plus ?
Modérateur
Bonjour,

boteha_2 a écrit :
Il suffirait de pouvoir dire :

Ruban en soie tissée etc...
Variant : couleur, longueur
Nombre : 150 versions
couleur : rouge, vert, noir, bleu....
longueur en m : 1, 2, 3, 5, 7.8 , 10...
Prix : de 1 à 40 euros
Stock : à vérifier selon la version (indiqué sur le site)

Terminé, qu'est-ce qu'il a besoin de savoir en plus ?

Ça, c'est ce dont tu aurais besoin toi. Mais d'autres vont vouloir les stocks version par version, ou les prix de chaque version, ou je ne sais quoi d'autre. Et le schema, lui, doit pouvoir permettre de répondre éventuellement à toutes ces questions.

Amicalement,
parsimonhi a écrit :
Ça, c'est ce dont tu aurais besoin toi. Mais d'autres vont vouloir les stocks version par version, ou les prix de chaque version, ou je ne sais quoi d'autre. Et le schema, lui, doit pouvoir permettre de répondre éventuellement à toutes ces questions.


Je sais que je prends un exemple extrême mais comment le moteur de recherche peut-il présenter 150 versions en détail ?

C'est un peu comme les avis clients.

"aggregateRating":
{
"@type": "AggregateRating",
"reviewCount": "48",
"ratingValue": "4,9"
},


Mais ensuite tu dois tout détailler :

{
"@type": "Review",
"datePublished": "2023-02-25",
"author":
{
"@type": "Person",
"name": "Thierry MACHIN"
},
"reviewRating":
{
"@type": "Rating",
"ratingValue": "5"
}
},

etc...


À quoi sert le détail, sauf à charger la page en octets ?

Bon, on sort du sujet principal.

Sur le forum Google mon interlocuteur déclare forfait après une affirmation qui me semble fausse :

a écrit :
&amp; c'est un caractère & codé en HTML, ça n'a théoriquement pas se place dans une URL.
& seul est un séparateur entre les différents paramètres de l'URL

Je ne sais pas ce que vous cherchez, mais une URL se construit d'une certaine façon, rien à voir avec du SEO. Ce sera ma dernière intervention sur le sujet.


Je lui ai répondu :

boteha_2 a écrit :
&amp; se transforme en &.
C'est un classique dans l'écriture des URL dans le code source.
Inspectez le code source de n'importe page Google vous y verrez des tonnes de &amp;

Modifié par boteha_2 (22 Mar 2025 - 20:29)
Bonjour,

URL canonique
URL micro-données

Je mets des &amp;
J'encode les valeurs susceptibles de comprendre des espaces.

Cela donne :

<link rel="canonical" href="https://www.monsite.com/b.php?ong=42U%20800%20x%201000&amp;ege=Ok&amp;h=H1OL*mad">

"item": "https://www.monsite.com/b.php?ong=42U%20800%20x%201000&amp;ege=Ok&amp;h=H1OL*mad"


Je n'encode pas * dans h=H1OL*mad, cela me semble inutile.
Modérateur
Bonjour,
boteha_2 a écrit :
Je n'encode pas * dans h=H1OL*mad, cela me semble inutile.

Il faut l'encoder.

Amicalement,