Lancer un annuaire national

[didier26]

Bonjour,

je lance bientôt un annuaire national des plombiers de france (environ 10000 inscrits pour l'instant)

quelle est la meilleure solution pour :
- indexer toutes les pages
- positionner toutes les pages
?

en sachant que l'annuaire est découpée en départements et qu'il y a 5 plombiers par page

Merci d'avance

 

[L.Jee]

Non le mieux est de rien indexer !

Ps : pas compris ta question ...

 

[didier26]

la question est :
comment organiser el site :

1- mettre sur la home une liste de tous les départements avec des liens
-> sur la page département mettre une liste de ville
-> ou bien mettre directement la liste des plombiers sur ce département dès la page département
2- mettre sur la home une liste de toutes les régions avec des liens (donc moins de liens)
-> sur la page région mettre une liste de départerment
-> sur la page département mettre une liste de ville
-> ou bien mettre directement la liste des plombiers sur ce département dès la page département


j'espère que c'est plus clair

Merci

 

[elas]

Tous les chemins mènent à Rome. Donc, il faut s'inspirer de wikipedia. Ce qu'il faut, c'est que la page de l'adresse finale de chaque plombier soit unique. 1000 plombiers = 1000 pages (une base de données semble évidente). Ensuite, chaque visiteur aura sa propre façon de chercher, donc il faut multiplier les possibilités de générations de listes par des queries (pour les humains). Pour les 1000 pages de résultats, un sitemap transmis a google, et quelque part un index en dur avec pas plus de 10 liens par pages et un blabla contextuel. Exemple : par départements.
Ensuite, un robot maison qui génère un joli plat de spaghettis en parcourant les 1000 pages plus l'index par départements et qui crée des liens sur les mots ente les 1000 pages.
Le niveau requis informatique pour effectuer ce référencement spécifique est : premier niveau . il faut juste savoir programmer un petit peu avec n'importe quel langage. Par contre, comme pour tout bon référencement, c'est spécifique et
il faut mettre les mains dans le cambouis.
@stirfryfrog

 

[didier26]

Merci de ta réponse.

Niveau prog je me débrouille bien, ce ne sera pas le souci
niveau mettre les mains dans le cmaboui pas de souci non plus

et quelque part un index en dur avec pas plus de 10 liens par pages et un blabla contextuel. Exemple : par départements.

mais la page d'accueil aura + que 10 liens, puisque il existe 95 départements !

Ensuite, un robot maison qui génère un joli plat de spaghettis en parcourant les 1000 pages plus l'index par départements et qui crée des liens sur les mots ente les 1000 pages.

ça a l'air appétissant mais j'ai pas compris :cry:

 

[elas]

Au dela des départements, il y a les régions... Et le chiffre 10, c'est juste un chiffre au hasard. Sur la home page, il faut un gros texte qui correspond au contexte. Et pourquoi pas 95 liens, mais pas uniquement 95 liens.

Pour les spaguettis : html = hyper texte. Souvent c'est oublié dans les sites d'aujourd'hui. Le défaut des annuaires qui se ressemblent tous, c'est qu'ils ont une structure de navigation de stype arbre inversé = du tronc en direction des feuilles. Google se balade très biens au milieu de liens qui vont dans tous les sens ex : wikipedia

Donc dans chaque page, s'il y a le mot dépannage, alors il doit lier la page dépannage. Et dans la page dépannage, s'il y a le mot drome, alors il doit lier la page du département drome...... A la fin, c'est un plat de spaguettis, et en plus, a chaque nouvelle page il doit se mettre a jour pour les 1000 déjà créés... C'est a peine plus difficle a programmer, il faut juste prendre le temps d'écrire l'algorithme sur papier.

C'est aussi cela le référencement = faire des programmes qui font ce qui manuellement devient impossible face au volume de travail (et les faire vite, parce que manuellement, les autres démarrent plus vite).
@stirfryfrog

 

[didier26]

c'est intéressant
1- pour les régions / départements, en général, ce sont les départements les + recherchés et de loin (cf insight for search)
2- pour les spaghettis, j'ai pigé (en fait, il faut une table avec une colonne mot-a-linker, une colonne page-destination) et à chaque fois que je charge une page, je parcoure chaque mot de la page en question et j'interroge cette table et linke si besoin est. juste une question : c'est pas un souci niveau ressource serveur (pour une page avec un texte de 300 mots, ça ferait plus de 300 requêtes !) ???

Merci

 

[alain78france]

Tu écris :
en sachant que l'annuaire est découpée en départements et qu'il y a 5 plombiers par page.

Pourquoi simplement 5 ? ? ?
Si tu cherches le succès il ne faut pas oublier que:
l'internaute qui cherche un renseignement va fuir ' ailleurs '
s'il n'a pas trouvé au bout de 2 clicks (au maximum 3)

Amicalement.

 

[didier26]

pour des raisons graphiques et commerciales (les premiers plombiers payent plus chers pour être mis en avant)

 

[elas]

parfait, tu as écrit l'algorithme. Mais les meilleurs sites sont statiques (je sais, certains diront le contraire), ou ont sont les canadadry des sites statiques. A une url donnée, doit correspondre un contenu donné et un seul (qui peut bien sur évoluer dans le temps). Donc il faut générer un nombre déterminé de pages a partir d'une base, point final.
Et quand il y a de nouvelles entrées, regénérer le site. Du moins pour les moteurs de recherche. Les pages de recherches peuvent elles être dynamiques. Je résume : une structure fixe avec 1000, 10000, 100000 pages qui se lient entre elles comme des spaghettis générées via un outil maison. Un index fixe pour les humains et les moteurs de recherche. Un moteur de recherche interne dynamique qui lui sort une page dynamique (qui ne sera pas traitée par les moteurs).
Tout cela existe (ou a existé) pour un site 100% ajax dont le front était totalement invisible pour les moteurs de recherche. Mais les mêmes moteurs adoraient indexés les dizaines de milliers de pages du backend.
@stirfryfrog

 

[kmenslow]

Je n'ai pas vraiment lu les réponses des autres mais pour ton cas, je classerais plutôt les plombier par ville. Cela serait assez efficace pour l'internaute. Par exemple : Plombier Rouen avec une Google map qui indique tous les plombiers de Rouen.

 

[didier26]

parfait, tu as écrit l'algorithme. Mais les meilleurs sites sont statiques (je sais, certains diront le contraire), ou ont sont les canadadry des sites statiques. A une url donnée, doit correspondre un contenu donné et un seul (qui peut bien sur évoluer dans le temps). Donc il faut générer un nombre déterminé de pages a partir d'une base, point final.
Et quand il y a de nouvelles entrées, regénérer le site. Du moins pour les moteurs de recherche. Les pages de recherches peuvent elles être dynamiques. Je résume : une structure fixe avec 1000, 10000, 100000 pages qui se lient entre elles comme des spaghettis générées via un outil maison. Un index fixe pour les humains et les moteurs de recherche. Un moteur de recherche interne dynamique qui lui sort une page dynamique (qui ne sera pas traitée par les moteurs).
Tout cela existe (ou a existé) pour un site 100% ajax dont le front était totalement invisible pour les moteurs de recherche. Mais les mêmes moteurs adoraient indexés les dizaines de milliers de pages du backend.
@stirfryfrog

merci mais tu m'as pas répondu pour la surcharge serveur à cause du gd nombre de requêtes (ou alors j'ai aps compris la réponse :cry

 

[didier26]

Je n'ai pas vraiment lu les réponses des autres mais pour ton cas, je classerais plutôt les plombier par ville. Cela serait assez efficace pour l'internaute. Par exemple : Plombier Rouen avec une Google map qui indique tous les plombiers de Rouen.

mais cela convient pour les grandes villes mais pour les petites viles où il n'y a qu'un plombier, bonjour le DC et en + niveau ergonomie, j'aurais une liste de plusieurs dizaines de milliers de liens (???)

 

[ybet]

Ensuite, un robot maison qui génère un joli plat de spaghettis en parcourant les 1000 pages plus l'index par départements et qui crée des liens sur les mots ente les 1000 pages.

ça a l'air appétissant mais j'ai pas compris :cry:

Je jouerais plus trop à cette méthode .
Elas n'a pas tout à fait analyser la méthode de Wiki, tous les mots ne sont pas liés vers la page de définition correspondante. Cette méthode à la limite du black Hat est plutôt à proscrire. En gros, son idée est de faire parcourir le site par un robot maison et de modifier chaque mot clé par un lien vers la page correspondante.

Mais les meilleurs sites sont statiques (je sais, certains diront le contraire), ou ont sont les canadadry des sites statiques. A une url donnée, doit correspondre un contenu donné et un seul (qui peut bien sur évoluer dans le temps). Donc il faut générer un nombre déterminé de pages a partir d'une base, point final.

A pat le reste, c'est effectivemet à mon sens une oluition nettement plus intéressante que les CMS avec une vollée de liens répétitifs sur chaque page. Par contre, gérer en HTML est souvent un casse tête. Pour le développement d'un site d'agence immobilière, j'ai un peu repris les deux idées.
Là, je travaille par commune. Dans l'administration, ils liens des communes à celles d'à coté suivant leurs aspiration (où plutôt suivant les règles géographiques des acheteurs potentiels. Pour les commune, la navigation reprend des liens vers des fiches des communes associées mais aussi vers les liens à vendre des communes limitrophes. C'est dynamique mais en passant dessus, ca semble statique.
Créer une structure en arbre avec uniquement les régions en page d'accueil puis dans les régions -> départements mais pour chaque département, lien vers les départements limitrophes (y compris de régions différentes). Un exemple de ma région (département). Un type de Charleville ira peut-être sur Reins ou sur Sedan mais surement pas sur Carignan (c'est valable pour le plombier) et en retour, un type de Verdun (meuse) ira prabablement pas vers Sedan (distance), ni sur Carignan (toujours distance). Maintenant Stenay et Carignan (deux départements différents mais villes proches) sont complémentaires.

PS: c'est pas une nouvelle idée, il y a déjà de la concurrence.
Et t'inquiète pas trop pour les "surcharges serveurs". Un mutu reprend souvent plus de 1000 sites sans problèmes (tant que la firme fait son boulot correctement, sans arnaquer les clients).

 

[didier26]

ok merci patrick pour ce bel exposé

comment t'y es tu débrouiller pour "gerer en HTML ce casse tete" ???

 

[ybet]

ok merci patrick pour ce bel exposé

comment t'y es tu débrouiller pour "gerer en HTML ce casse tete" ???

Pas en html mais bien en PHP (je sais que je signe mes MP par patrick ... mon prénom quand même mais su WRI, mon pseudo est YBET - et pas que sur WRI :wink: ). C'est de la pure programmation en jouant sur des tables. Visite le site (les fiches -http://www.iti.be). C'est la méthode utlisée. Le site utilise quelques tables annexes qui permettent de reproduire un site (parle des liens annexes) comme siu c'était fait manuellement. La difficultée est de garder des liens durables donc pas un truc gennre Ramdom() et c'est là que les tables MysQL interviennent. Je peux pas trop donner de détails (le développement est spécifique à cette entreprise et finalemtn leur appartient). En gros, tu permet via une admisnistration de mettre des grosses villes, des régions aux quelles elles appartiennent. Chaque ville a des villes voisines et chaque région des régions voisines. Tu met chaque fois des pondérations (dans mon cas de 0 - quasiment nul - à 5 ) et affiche ce qui semble le plus logique pour les visiteurs. (J'avoue que pour ce site, j'ai aussi pondéré les biens à vendre .... en fonction des bénéfices possibles: une maison à 5000 € est moins rentable qu'une propriété à 50.000, ils sont payés au %). L'idée est là, reprendre des tabls Mysql qui regrtoupent des département.

Page d'entrtrée -> région -> département. et dans les départements, des liens vers départements (ville plutôt dans ton cas) qui sont avoisinants. Je cherche un plombier à charlille Mézières (08 je pense), me fout d'un plombier à Paris (Reins est presque la porte à coté, SEDAN, c'est presque la banlieu) mais surement pas à Paris, ni à Lyon ou à Marseille. Tous les tests en cours sont aussi le suivi des liens via GG analytic (et GG en tient compte). Des liens pas ou très peu suivi sont moins pris en compte. GG avec ses "aides webmasters" les utilisent aussi.
L'idée de Elas (en parlant de sites staiques est justement que les pages html permettent de "gérer les liens" manuellement: liens mais aussi textes des leines). Il n'a pas tord: casser les liens de navigation répétitifs. Reste à l'adapter en PHP (ou ASP), et c'est du boulôt . Rien que débuter les idées de développement.