Formulaire methode GET ou PSOT

[sam01]

Bonjour,

je suis actuellement en train de faire un site avec pas mal de formulaire, et j'aimerais savoir si la methode utilisée par le formulaire (GET ou POST) à une incidence sur le référencement, l'indexation du site...

Je me pose la question car la methode GET génère des url avec des ? et des & (ce que les robots n'aiment pas tellement). De plus je ne pux pas utiliser l'URL Rewrting car c'est des url générées par un formulaire.

Il reste a méthode POST qui elle génère une URL (propre), ce qui normalement devrait être plus apprécié par les robots...

est-ce le bon raisonnement à avoir ?

[Schwarzer Stern]

Salut,
Je ne pense pas que cela aura une importance pour les robots qui ne suivent pas les URL des form si je ne m'abuse. Si tu gères bien avec le GET, l'avantage pour tes visiteurs sera de pouvoir revenir facilement par exemple à des résultats de recherche. Mais c'est une question de contexte : tu ne vas pas transmettre par GET les id de connexion ou le contenu d'un message sur un forum, mais plutôt le libellé d'une recherche,...

[e-kiwi]

ces petits malins de robots se mettent à suivre les forms et du coup, en passant par du GET, il y a un risque de voir Google y passer du temps, au détriment des autres pages du site

[sam01]

Ha bon,

ben alors il faut faire la méthode POST, c'est ça ?

[e-kiwi]

ça depend, comptes tu faire indexer tes pages de résultats de recherche ? ton formulaire st-il bordé ou libre (champ full text) etc ...

[boby55]

Je vois surtout des contraintes techiques à ne pas oublier :

un GET on est limité dans le nombre de caractères (255 == URL), contrairement au post (beaucoup plus).

Aussi, je sais ,pour faire souvent des requêtes en Ajax, que par le POST permet parfois de bien encodé les caractères Français contrairement au GET, tout dépend des librairies ( Jquery, Prototype ... ).
Le POST est aussi plus gourmand que le GET en ressource (je pense que la différence n'est visible que sur un certain volume).



Pour résumer, tout dépend du contexte comme toujours : combien de champs, de quel type (numeriques, blocs de textes avec accents ...)

[jcaron]

Il y a avant tout et surtout une question de sémantique: un GET ne doit avoir aucun "effet durable". Tu peux donc utiliser un GET pour faire une recherche par exemple, mais tu ne dois pas l'utiliser pour un formulaire qui va modifier quelque chose (créer un compte, poster un message, modifier un profil...). Dans ce cas, tu dois utiliser POST. Tu peux aussi utiliser POST pour une opération sans effet durable si des contraintes techniques l'imposent, évidemment, mais de façon générale tu vas voir que la séparation entre les deux est naturelle.

Ensuite, de façon générale, les robots ne suivent pas les formulaires, ne serait-ce que parce qu'ils ne sauraient pas trop quoi mettre dans les différents champs (il peut y avoir quelques cas de figure où ils ont "repéré" l'utilisation du formulaire et ce qu'on peut y mettre, mais ça reste plus l'exception que la règle). Logiquement, même s'ils les suivaient, ils ne devraient le faire que sur un GET, jamais sur un POST.

Sinon, pour le détail, un GET est effectivement limité par la taille maximale de l'URL, mais la limite est plutôt de 1K ou 2K minimum que 255 caractères (la limite exacte dépend de la combinaison browser+serveur+proxies intérmédiaires éventuels, dans de bonnes conditions ça peut être beaucoup plus, mais jusqu'à 2K tu es tranquille normalement). Il n'y a pas de limite de taille sur un POST. De plus, un INPUT TYPE=file ne peut évidemment être envoyé que dans un POST.

Pas de raison particulière d'avoir plus de problèmes d'encodage en GET ou en POST par contre. Par défaut, un formulaire sera encodé avec le charset utilisé pour la page HTML, tu peux le changer avec l'attribut accept-charset du <form>.

Dernier point: dans une page qui effectue une action (donc normalement suite à un POST, mais il y a beaucoup de cas comme des liens simples qui sont donc en GET qui peuvent avoir une conséquence), une fois l'action effectuée, toujours effectuer un redirect vers une page qui ne fait rien (c'est le PRG, aka "Post/Redirect/Get"). Ca évite que si l'utilisateur effectue un refresh sur la page de résultats, l'action soit exécutée de nouveau.

Jacques.