8792 sujets

Développement web côté serveur, CMS

Rewriting d'url et référencement

Bonjour, j'utilise le rewriting d'url sur ces deux sites:

http://www.nyxen.net/instantane/
http://www.nyxen.net/studio/

La règle appliqué redirige toute requete vers un index.php5 situé dans chaque dossier puis le reste de l'url va etre parsé pour déterminer la page à afficher. Par exemple,

http://www.nyxen.net/instantane/journal/archives/ va charger le fichier http://www.nyxen.net/instantane/index.php5, et ce dernier va faire un require_once("Fichiers/archives.php5"); par exemple. Mais je me suis rendu compte après quelques semaines de test que les pages qui utilisaient cette méthode n'étaient pas référencé et je n'arrive pas trop à comprendre pourquoi. Je suppose qu'il doit manquer certains header indiquant à google qu'il s'agit bien la d'une page html mais à vrai dire, j'en sais trop rien... Si qq a une idée je suis preneur.

Merci !
Je viens de me rendre compte que mes headers de pages étaient incorrect, je pense que ça devrait résoudre le problème. Cela dit, pensez-vous qu'il est plus approprié d'utiliser une adresse du type:

http://www.nyxen.net/instantane/journal/archives/2005/11/25/exemple-bidon
http://www.nyxen.net/instantane/journal/archives/2005/11/25/exemple-bidon.html
ou
http://www.nyxen.net/instantane/journal/archives/2005/11/25/exemple-bidon/

Est-ce que ça change vraiment quelque chose pour les spiders des moteurs de recherche ?

Gracias !
Salut, as tu trouvé réponse à cette question ?

Je m'intéresse également à cela depuis hiers, sans pour autant avoir trouvé de régles bien établies la dessus.
Bonjour,
Voilà, moi aussi ça m'intéresse.

Qu'est-ce qu'on gagne à remplacer http://site.com/dossier/page.php?rub=test&sousrub=machin par http://site.com/dossier/page/test/machin ou des url rewriting du genre ? Pour Google ? Pour l'utilisateur lambda ?

Autrement j'ai encore une autre question, plus technique cette fois : mon hébergeur, free, ne supporte pas l'url rewriting. Aussi j'ai découvert une parade qui fonctionne, c'est utiliser une page 404 personnalisée qui, suivant l'url tapée, modifie le code HTTP renvoyé en 200 et fait un include de la page à afficher..... qu'en pensez-vous ?
Salut Quentin, je n'ai pas trop d'avis sur le coup d'utiliser une page 404 dynqmique..

PAr contre je te confirme que google digère bien mieux les pages avec URL simples. Elle sont assimilés à des pages statiques..

Pour l'utilisateur c'est aussi plus simple à lire, mémoriser, ou sipmplement saisir. donc je penses que c'est rééllement un plus.
Merci. Alors j'en arrive à la question qui a déjà été posée : .php, .htm, .html ou rien du tout en fin d'URL ?
J'ai fais le choix de tous passer en .htm

Finalement c'est clair pour n'improte qui et ça permet en plus de masquer la techno utilisée coté serveur...

l'extention .htm est tellement utilisée que cela me semble le bon choix. puis html c'est toujours un caractère de trop Smiley lol

Il est vrai que de temps à autres je garde aussi des urls genre expositions /

comme pour simuler la racine d'un répertoire...
Bonjour,

Thanh a écrit :
Mettez une extension. La base du web c'est le partage de documents localisés.


Vieille confusion... De ce point de vue, la manière dont est composée l'URI n'a pas d'importance, et l'extension éventuelle du nom de fichier est dénuée de signification exploitable ("sémantique") au-delà du serveur qui héberge la ressource. Un foo.php peut être une image png, une feuille de style CSS, un document svg ou un gratin de brocolis.

Pour la maintenance (et la permanence) des URL, il est au contraire beaucoup plus aisé de s'en tenir à des répertoires, sans nom de fichier (et terminés par le slash de rigueur).
Modifié par Laurent Denis (03 Dec 2005 - 16:10)
Merci Laurent.
D'après ce que tu dis, j'en déduis que le / final est important.
Mais j'aimerais savoir ... pourquoi ?
Le slash final indique immédiatement au serveur que la page demandée est l'index du répertoire, et simplifie les échanges clients/serveur.

Sans le slash :
1. le navigateur demande http://mon-site.com/foo
2. le serveur cherche un fichier "foo" et constate qu'il n'existe pas
3. il cherche encore, et s'apperçoit qu'il a un répertoire du même nom.
4. Mais comme il est un peu parano, il renvoit au navigateur une réponse du type "301 moved permanently", histoire de ne pas se mouiller.
5. Le navigateur soupire un grand coup, se dit que c'est pas son jour, et refait sa requête en ajoutant le slash
6. Le serveur, enfin rassuré, lui renvoit l'index du répertoire demandé...

Avec le slash, on saute les étapes 2 à 5 et le serveur envoie directement la page...

C'est d'ailleurs une bonne pratique Opquast Smiley cligne
Ce que je ne comprends pas, c'est que, comme de toute façon à la base c'est prévu pour que ça tombe soit dans une erreur 404 soit le modrewrite d'apache est activé et donc l'url est immédiatement remplacée, je ne comprends pas comment ceci peut intervenir. Je m'explique :

je demande /machin/truc
dans le .htaccess, il y a une règle qui dit : remplacer /machin/(.*) par machin.php?param=$1
L'url est modifiée et la remquête passe à machin.php?param=truc et comme la page existe elle est immédiatement renvoyée

Dans le cas de la magouille 404, un / à la fin ou pas, la cible n'existe pas, la page 404 est exécutée, etcomme $_SERVER['REQUEST_URI'] obéit à l'expression régulière /machin/(.*), on définit $_GET['param'] = "truc" et on fait un include de la page machin.php. La bonne page est renvoyée tout de suite aussi ...
comme dans les deux cas ça fait une erreur 404 (avec ou sans le /), je ne vois pas la différence...

Merci de m'éclairer (et pas avec une lampe halogène de 400W Smiley lol )
Bonjour,

La question ne se pose pas, en effet, de la même manière en cas de réécriture d'URL.

(Tant que celle-ci prévoit que l'utilisateur ne tapera pas forcément le slash final Smiley cligne Je sais que cela paraît évident, mais je viens de rencontrer le cas où une personne chargée des réécritures d'url, tout à fait compétente, avait eu un petit moment de distraction et l'avait oublié. Du coup, seules les requêtes /foo/bar/ étaient réécrites, et les autres en /foo/bar faisaient une superbe 404 Smiley lol )

Cela dit, une chose à prendre en compte avec ton utilisation de la page 404 :Un en-tête "404 not found" va être systématiquement renvoyé par ton serveur pour chacune des pages concernées (même si le contenu est en fait fourni via l'include)... Cet en-tête est susceptible d'être pris en compte par différentes machines, notament les robots d'indexation. Détourner la page 404 ne me semble pas une très bonne idée. Comme tous les détournements d'ailleurs Smiley cligne
Modifié par Laurent Denis (04 Dec 2005 - 09:30)
Justement, non, j'ai prévu le coup, je modifie le code de réponse HTTP grâce à php au moyen du code suivant :


header("HTTP/1.1 200 OK");
header("Status:200 OK");


J'ai fait un test en vérifiant les en-têtes HTTP renvoyées, le code de retour est bien pris en compte.
Sujet clos
Aller à