Sous les toits

Aller au contenu | Aller au menu | Aller à la recherche

Développement

Fil des billets - Fil des commentaires

lundi 29 septembre 2008

Fichiers PDF, une partie de votre référencement ?

Par Serge le lundi 29 septembre 2008, 22:50

Référencement des fichiers PDF Ce matin, en parcourant un site en cours de construction, je tombe sur un PDF qui ne s'ouvre pas correctement sur mon ordinateur. Ni une ni deux, je couine au PDF pourri. La source est vite trouvée et je me retrouve en ligne avec le prestataire. Après quelques minutes, il me demande "Avec quelle version d'Acrobat est-ce que tu l'ouvres ?" et moi de lui répondre, "Pas d'Acrobat, c'est "Aperçu", qui est directement intégré dans Léopard". Il me répond que le PDF est optimisé pour la version 8 d'Acrobat et que c'est surement pour ça.

Sur le coup, ça me gène un peu de publier un truc sur internet qui nécessite une version (assez) récente d'un logiciel, le site est destiné au grand public, je sais très bien qu'ils n'auront pas tous la bonne version. Je convertis donc darre-darre le PDF rétif en version passablement vieillotte. Hop, tout le monde pourra l'ouvrir...
Tout le monde... Y compris notre ami Google !

Venons en aux faits : Google indexe les PDF au même titre d'une page web, le contenu étant souvent plus riche (et plus ciblé), il est donc plus facile de bien se placer sur un moteur avec un document PDF. Pour ce faire, quelques conseils en vrac :

  • Google ne semble pas indexer les PDF dans créés une version supérieure à la 1.7 (Acrobat 7), ou du moins, je n'en ai pas trouvé.
  • Le texte vectoriel, comme les images, ne peuvent pas être indexés en tant que tel. Donc sus au texte vectorisé, et on prendra soin de compléter les textes de remplacement des images.
  • Comme sur une page web, les liens auront leur importance. Ils aident à structurer le document. Google indexera les ancres interne et cherchera à qualifier les liens externes (le site d'origine par exemple).
  • La hiérarchie du document sera à prendre en compte : titre, sous titres et contenu bien organisé. Ce sera notamment important pour les moteurs qui présentent les mots clefs dans leur contexte.
  • On prendra soin de remplir soigneusement les méta-informations (titre, description, mots clefs, auteurs, etc.)
  • Afin de sécuriser l'indexation des documents, on évitera les PDF trop lourds, quitte à scinder en plusieurs chapitres les documents importants.
  • Éviter d'enfouir les PDF au fond d'une arborescence, comme les pages web, plus ils seront proche de la page d'accueil, meilleur sera leur référencement.

Après ces petites recherches, je n'ai plus qu'à vérifier l'état des PDF que j'ai déjà mis en ligne... Et vous ? Vous êtes au top sur vos PDF ?

D'autres infos ici, ou là.

2 commentaires aucun rétrolien

vendredi 26 septembre 2008

Utiliser les dernières versions d'Eclipse en français

Par Serge le vendredi 26 septembre 2008, 14:29

eclipse.jpgC'est les vacances... Donc j'en profite pour remettre un peu les mains dans le cambouis. Sauf que ça fait quand même quelques temps que je n'ai plus touché à Eclipse et que ma version est en anglais. En cherchant un peu ici et là, j'ai trouvé toutes les infos nécessaires pour passer les anciennes version d'Eclipse en français. Mais rien sur les versions depuis Europa (3.3.x). Apparemment, IBM ne fournirait plus les "languages packs".

Entre temps, heureusement, le projet Babel a eu le temps d'avancer pour prendre la relève. Passer Eclipse en français est aujourd'hui un jeu d'enfant (quand on trouve la bonne info). Un petit clic sur l'espace de téléchargement du projet, et on récupère l'URL correspondant à la version installée.

Ensuite, il suffit d'aller dans "Help", "Software Udaptes" puis "Find and Install". Aller ensuite sur "Search for new features to install". Cliquer sur "New Remote Site" et entrer l'URL ainsi qu'un nom pour le projet. Cliquer ensuite sur "Next" et valider les différentes demandes d'installation. Un petit redémarrage d'Eclipse et nous voila dans la langue de Molière.

Elle n'est pas belle la vie ? Aller, je vous laisse expérimenter, j'ai un projet à coder moi...

aucun commentaire aucun rétrolien

samedi 5 janvier 2008

Développement web durable ?

Par Serge le samedi 5 janvier 2008, 23:26

Ca fait plusieurs fois ces derniers temps que j'ai l'occasion de me demander "mais pour combien de temps ces gens développent-ils leur site internet ???". Et chaque fois, l'horizon est de 3 à 5 ans. Le web évolue vite, donc il faut refaire régulièrement. Ils en ont conscience, c'est normal, c'est une dépense lourde, mais Internet est un impératif, ça permet d'avoir une bonne vitrine et de soigner son image, il faut dépenser.

Je ne suis pas totalement contre cette idée. Le web évolue vite. Il faut donc faire évoluer les sites en même temps. Mais en revanche, une grosse refonte de profondeur est-elle vraiment nécessaire si le projet est bien pensé au départ ? A mon gout, le seul risque, c'est le changement radical de technologie (genre ASP => PHP => ROR), pour le reste, des améliorations régulières suffisent amplement.

Sauf quand un site n'est pas prévu pour durer : de très gros développements Flash, absence de séparation entre le fond et la forme, code incompréhensible pondu par une machine sans intelligence, aucune orientation objet dans le développement (ou pensé à peu près comme tel), etc...

Ce qui m'étonne le plus, c'est que l'on soit encore actuellement dans une démarche de vendre ce type de produits. Qu'à-t-on à y gagner ? Refaire le travail tous les 3 ans ? Les changements de chartes graphiques, les évolutions régulières, les nouveaux services, devraient fournir largement autant de travail... et surtout, surtout, permettre d'aboutir à un résultat plus concluant puisque pas repris régulièrement à zéro !

Ah ! Si 2008 pouvait correspondre avec une prise de conscience de l'intérêt d'un développement propre et de celui du respect des standards, ce serait une bonne année...
...à tous ! (Ben quoi ? Je ne vous l'avais pas encore souhaité !)

un commentaire aucun rétrolien

vendredi 1 juin 2007

Migrations et redirections...

Par Serge le vendredi 1 juin 2007, 22:45

Suite à une petite demande d'Alain, voici une explication du comment je suis passé plus ou moins en douceur d'une ancienne URL à la nouvelle. Pour faire de la redirection, il existe plusieurs méthodes plus ou moins propres en fonction de ce que l'on veut faire ou au contraire éviter de faire.

Méthode 1 :
Je prends une page HTML vierge et entre les balises head, je place une balise meta du genre :
<http-equiv="refresh" content="0; url=http://www.monsite.com/index.html">

Cette méthode fonctionne mais ne concerne qu'une seule page. C'est en fait un simple rafraichissement vers une nouvelle adresse.

Méthode 2 :
La même en couleur, en utilisant le javascript avec une commande du type :
window.location.replace("http://www.monsite.com/index.html");

L'avantage de cette méthode, c'est qu'elle permet de renvoyer une URL calculée... côté client. Les gros inconvénients, c'est que justement, tout se passe côté client, que c'est pas top au niveau accessibilité et que javascript est désactivé sur environ 5% du parc. Bagatelle, les moteurs de recherche ne pourront pas voir la redirection non plus.
Je profite du sujet pour signaler aux petits malicieux qui sont en train de se dire "je vais truffer une page de mots clés et renvoyer les vrais internautes vers une autre", attention, vous jouez avec le feu ! Si un moteur s'aperçoit de la supercherie, c'est le bannissement définitif.

Méthode 3 :
On peut aussi envisager un renvoi vers une URL différente via les scripts serveurs.

En php, on aura quelque chose du genre :
header("HTTP/1.1 301 Moved Permanently");
header ("Location: http://www.monsite.com");
exit();

En ASP, ça donnerait :
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.monsite.com"
Response.End

Le gros avantage d'une telle méthode, c'est que l'on voit apparaître le Moved Permanently qui permet de signaler aux moteurs de recherche qu'il faut mettre à jour le lien vers la nouvelle adresse. L'inconvénient, c'est qu'il faut traiter chaque page, ou écrire un script un peu sophistiqué.

La méthode ultime (selon ce que l'on veut faire) :
Sur un serveur Apache, vous avez en standard, la possibilité d'utiliser des fichiers .htaccess. Le .htaccess permet entre autre de sécuriser des dossiers, de faire de la réécriture d'URL, mais en fait, en regardant bien, il sait faire un tas d'autres choses (page d'erreur personnalisée, etc). C'est parmi ces diverses utilisations possibles que l'on trouve le RedirectPermanent, qui renvoi un code 301 au navigateur.

L'écriture est assez simpliste :
RedirectPermanent / http://www.monsite.com/

Là, en une ligne bien placée, on redirige un fichier, un dossier, ou tout un domaine en faisant suivre son référencement. La ligne rêvée pour la grosse feignasse que je suis !

Pour finir, pour mon blog, comme je passais de la version 1 à la beta 2, il ne me manquait plus que le petit plugin de Pep pour rediriger automatiquement les URL modifiées entre les deux versions et le tour était joué.

aucun commentaire aucun rétrolien

mardi 10 avril 2007

Quanta+ Versus Eclipse

Par Serge le mardi 10 avril 2007, 12:48

Eclipse Au moment ou le Zend Framework se mettait en place, une annonce avait été faite sur un partenariat avec Eclipse pour la création d'un module PHP. Bien entendu, comme le Zend Framework, j'avais suivi ça de près. Et j'avais tenté une ou deux fois de me servir d'Eclipse avec le module PHP. On va dire que ce n'était pas encore très au point.

Il y a une petite semaine, j'ai réitéré l'expérience, et là, miracle !! Eclipse fonctionne parfaitement bien avec PHP. Du coup, pour tout avouer, j'ai un peu lâché Quanta+ que je considérais jusque là comme l'éditeur de loin le plus pratique pour bosser.

Les avantages d'Eclipse sur Quanta+ sont pléthore :

  • Versions multi-plates-formes, ce qui me permet de bosser au bureau sous Windows et à la maison sur Linux,
  • Autocomplétion plus performante sur les différentes fonctions et classes,
  • Un catalogue de toutes les fonctions et toutes les classes d'un projet, sans parler des fonctions natives PHP5,
  • Synchronisation (dans les deux sens) très simple avec un FTP ou un SVN,
  • Possibilité de mettre des marqueurs à côté des lignes (ce qui manquait cruellement à Quanta+),
  • Intégration de Tidy pour un code plus propre,
  • Un historique plus vaste ne se limitant pas à la version précédente du fichier,
  • Eclipse est beaucoup plus léger sur les gros projets.
  • etc.

Pour mes besoins, je n'ai installé que la version dédiée à PHP d'Eclipse. Plus légère, elle n'embarque que les modules nécessaires au PHP. Je n'ai pas encore tout parcouru, mais pour l'instant, Eclipse m'a véritablement séduit. Seule petite ombre au tableau peut-être, la gestion des commentaire est moins bien finie que dans Quanta+. Simple oubli ou question de jeunesse, il ne fait aucun doute que ce sera réglé dans les futures version.

Et vous ? C'est quoi votre éditeur favoris ?

8 commentaires aucun rétrolien

- page 1 de 5