search
top

Spécifications SEO : Importantes, souvent négligées

« Le site doit être optimisé pour le référencement ». Je pense que je connais peu de référenceurs qui n’ont pas lu cette phrase mythique lorsqu’un chef de projet lui donne le cahier des charges de son futur site Internet. Pourtant, comme nous l’avons déjà vu dans un article consacré à la gestion de projet SEO, il est crucial de bien définir ce que l’on souhaite, afin que l’agence ou les développeurs travaillent au mieux sur le référencement du site. Deux objectifs donc, « avoir un site optimisé dès le lancement » et « optimiser les coûts ». Voici quelques points à intégrer dans vos futures spécifications ou cahiers des charges.

Pourquoi faire des spécifications SEO précises?

Les spécifications SEO vont permettre de mieux définir vos besoins et vos attentes concernant le développement du futur site Internet. Généralement intégrées au contrat, ces spécifications peuvent également servir de bases à vos plans de tests que vous allez réaliser lorsque votre prestataire vous fournira les divers livrables du projet. Concrètement, ces spécifications peuvent donc avoir une valeur légale, si elles sont dans le contrat, afin de valider ou non, le travail effectué lors du développement. C’est donc un document important sur lequel il faut travailler dès le lancement du projet. Ainsi, si vous vous contentez de mettre dans le cahier des charges, une section savamment intitulée « Référencement » et que vous mettez comme consigne « le site doit être bien référencé sur les moteurs de recherches », vous allez bien souvent « droit dans le mur ». En effet, cela veut tout simplement rien dire. Car si, au moment du go-live du site, vous vous apercevez que le site n’est tout simplement pas visible sur Google parce que les technologies utilisées, par exemple, sont bloquantes, vous allez faire face à deux problèmes :

  • Impact budgétaire : Le but d’un site est de vous apporter un retour sur investissement, sauf que s’il n’est pas visible sur les moteurs, il ne sert à rien. Sur la plupart des sites Internet, le référencement naturel est la source numéro 1 de trafic, donc il faut prendre en compte ce point et le cadrer très tôt dans le cycle de vie du projet. Aussi, il va falloir faire des corrections, des évolutions ce qui signifie que vous allez devoir remettre en cause des développements, qu’il va falloir payer donc autant tout cadrer en amont.
  • La responsabilité du prestataire : Avec une phrase aussi simple que « le site doit être bien référencé sur les moteurs de recherches », si le site est indexé sur la page 20 de Bing, alors légalement, le site est référencé donc vous ne pourrez pas vous retourner contre lui. Il s’agira de votre propre faute.

Que faut-il mettre dans les spécifications?

En gros, vous pouvez « mettre ce que vous souhaitez », charge à votre prestataire de refuser, d’accepter, ou de vous guider dans le choix de telle ou telle technique, technologie ou optimisation. Ci-dessous, vous trouverez donc une liste non exhaustive de plusieurs points à inscrire des les documents projets afin de cadrer un tant soit peu votre stratégie SEO. Après, tout dépend de la typologie de site et de vos attentes.

Techniques à proscrire

Si vous ne souhaitez pas que le prestataire avec lequel vous allez travailler utilise des techniques proscrites par les moteurs de recherches, il faut le mentionner, sinon, si vous ne lui mettez pas de limites, par définition il peut dont faire tout ou n’importe quoi. Quelques exemples : pages satellites, cloacking, keyword stuffing, textes cachés, linkwheel… A vous de voir.

Les temps de chargement

Pris en compte dans l’algorithme depuis 2010, les temps de chargement doivent être optimisés, pour les internautes afin de favoriser l’utilisabilité du site en question, augmenter les pages vues, baisser le taux de rebond et pour les moteurs afin d’optimiser le processus de crawl.

Vous pouvez reprendre, par exemple, les recommandations de Google Page Speed. Quelques exemples :

  • Mise en cache du navigateur
  • Regrouper les images dans des sprites CSS
  • Autoriser la compression
  • Réduire la taille des ressources HTML / CSS
  • Intégrer les ressources CSS / JS peu volumineuses

Quelques questions à se poser :

  • Quel temps de réponse maximum par page? 
  • Comment mesurer ce temps de réponse? Avec quel(s) outil(s)?

Les entêtes HTTP

Ici, il s’agit simplement de spécifier les bons codes HTTP à renvoyer en fonction des scénarii. Il m’est arrivé de travailler sur certains sites ou les pages d’erreurs étaient en 200, voire en 500, des redirections qui devraient être en 301, en 302 et ainsi de suite. Donc, dans le doute, vous pouvez utiliser cette liste pour spécifier les entêtes HTTP. Parmi les principales:

  • 200 : Page accessible
  • 301 : Redirection permanente
  • 302 : Redirection temporaire
  • 404 : Page d’erreur
  • 410 : Page indisponible
  • 500 : Erreur serveur
  • 503 : Maintenance

Quelques questions à se poser:

  • Quel code utiliser lorsque des fiches produits disparaissent? 
  • Comment gérer une éventuelle migration?

Architecture du site

Ici vous pouvez spécifier vos attentes au niveau de l’architecture du site, voire fournir une arborescence afin que le prestataire travaille au mieux sur les niveaux de pages. En vulgarisant, plus les pages seront hautes dans l’architecture du site, plus elles auront de poids dans les moteurs.

Quelques questions à se poser:

  • Quelle sera la profondeur des pages en fonction du volume de pages?
  • Comment mettre en avant une page profonde ayant du potentiel en termes de trafic?

Indexation et crawl

De mon point de vue, une page indexée sur Google est une page qui doit générer du trafic, sinon, pourquoi l’indexer? Sur un site Internet, il existe plusieurs cas, pages ou fichiers qui n’ont pas nécessairement vocation a être indexés, en voici quelques uns :

  • Moteurs de recherches internes
  • Pages d’impressions
  • Pop-ins
  • Mentions légales
  • Newsletters
  • Les environnements!
  • Pages de paginations
  • Divers documents : pdf, swf, doc, txt, xml…

Pour ce faire, vous disposez de plusieurs solutions, à vous de voir ce qui va le mieux convenir à vos attentes et aux possibilités techniques:

  • Login/Password (htpasswd)
  • Meta Robots
  • Robots.txt
  • X-Robots-tag
  • Javascript

Quelques questions à se poser:

  • Automatisé le sitemap.xml ou pas?
  • Utiliser un sitemap image ou non?
  • Combien de sitemap.xml par rapport à la volumétrie du site?
  • Quelle page a un potentiel trafic?

Accessibilité

C’est typiquement le cas du site utilisant des technologies non SEO-friendly ou bien le site qui demande une identification avant d’accéder aux pages. Bon, il existe de nombreux cas, mais si Googlebot n’accède pas à vos pages, comment peut-il les indexer ? Voici quelques points basiques à préciser dans les documents projets :

  • Javascript : Comment le prestataire va gérer les liens? ou un menu de navigation? Autant éviter d’utiliser le javascript sur ces éléments.
  • Flash : Un site full flash sans version HTML? Joli, mais mauvaise idée.
  • Iframes : C’est pratique n’est-ce pas? Mais cela appel du contenu d’une autre page web donc Googlebot verra une page blanche alors comment cette page va générer du trafic si elle apparaît vide? Autant prévoir une solution.

Quelques questions à se poser:

  • Est-ce que la technologie sera SEO-friendly?
  • Est-ce que la page ou cette technologie sera utilisée a un potentiel trafic?
  • Quelles sont les alternatives?

Gestion des URL

Il y a énormément de cas ou vous risquez une duplication de contenus via la gestion des URL et on le sait tous, ce n’est pas un bon signal à envoyer à Google. C’est pourquoi il vaut mieux, dès le départ, sécuriser les points suivants:

  • Rediriger en 301 la version sans www vers www (ou l’inverse)
  • Rediriger en 301 les extensions
  • Forcer la réécriture des URL en minuscule
  • Ne pas laisser une même URL accessible avec et sans slash
  • Rediriger la vers https vers la version http

Quelques questions à se poser:

  • Utiliser l’URL rewriting ou non?
  • Comment gérer les paramètres d’URL?
  • Que faire si l’ajout de « caractères exotiques » crée des pages en 200?
  • Quelle sera la structure des URL?

Multilinguisme

Si vous avez un site multilingue, il vaut mieux se poser les bonnes questions en amont. Quoi de plus déceptif pour un internaute belge de faire une requête et de tomber sur la version française du site. Imaginez que la vente à l’étranger n’est pas possible depuis la version française, est-ce que l’internaute reviendra sur le site? Au-delà de cela, il y a également des potentiels contenus dupliqués à gérer, donc il vaut mieux préciser:

  • Si le site aura un TLD géolocalisé
  • Ou bien si cela sera géré en sous-domaine ou en répertoire
  • L’utilisation des hreflang

Titles

On connait tous les titles et leur importance pour le référencement, mais il peut arriver que le prestataire, agence web spécialisée en développement, ne maîtrise pas les tenants et aboutissants du référencement. Dans le doute, je préfère préciser le tout dans les spécifications:

  • Un <title> unique par page
  • Le <title> doit contenir le mot clé
  • Le <title> doit décrire le contenu du la page
  • Mot clé ciblé en début de balise
  • 70 premiers caractères avec le sujet principal de la page pour un affichage clair dans les SERP
  • Des règles de gestion peuvent être utilisées qui seront à préciser

Meta description

Idem pour la meta description, même si elle ne servira pas pour le positionnement, elle peut jouer sur le CTR dans les pages de recherches donc dans le doute:

  • Une description unique par page
  • La description doit contenir le mot clé (bold dans les SERP)
  • La description doit décrire le contenu du la page
  • 160 caractères avec le sujet principal de la page pour un affichage clair dans les SERP
  • Des règles de gestion peuvent être utilisées qui seront à préciser

Balises meta

On le sait également, toutes les balises meta ne sont pas utiles, pourtant, on retrouve souvent certains classiques dans le code. Je vous invite à consulter cet article qui explique bien la problématique, si vous souhaitez en savoir plus, sinon, voici une liste de celle qui ne vous seront d’aucune utilité :

  • Ne pas utiliser la meta keywords
  • Ne pas utiliser la meta revisit-after
  • Ne pas utiliser la meta author
  • Ne pas utiliser la meta copyright
  • Ne pas utiliser la meta meta-language
  • Ne pas utiliser les meta cache control, pragma, expires
  • Ne pas utiliser la meta identifier-URL

Structure Hn

Deux écoles : Un ou plusieurs H1? Par contre, je pense que nous sommes tous d’accord pour dire que ce n’est pas une bonne chose d’avoir des balises manquantes, vides ou dupliquées. Voici quelques consignes si jamais vous souhaitez spécifier des règles sur les Hn :

  • Un H1 unique par page
  • Des H2 si une H1 est présente
  • Des H3 si des H2 et H1 sont présents
  • H1 doit intégrer des mots clés lorsque c’est possible
  • Pas de titres manquants ou de balises dupliquées
  • Hn sur du texte et non des images
  • Pas de Hn dans le header

Images

L’objectif? Un bon positionnement dans Google Image et travailler le référencement on-page. Ici encore, voici quelques spécifications :

  • Nom de fichier avec mots clés et séparé par des tirets
  • Les images doivent être compressées
  • Idéalement au format .jpg ou .png
  • Intégrer un ALT en rapport avec l’image pour travailler les mots clés ciblés
  • Intégrer une légende à l’image
  • Intégrer les images dans un sitemap.xml dédié

Questions à se poser:

  • Comment générer dynamiquement les ALT?
  • Comment compresser les images sans perdre en qualité?

Contenus

Du côte du contenu, à ce stade, la majorité des spécifications ont été effectuées mais dans le doute… A croire que je suis un éternel perroquet:

  • Un contenu unique par page
  • Utiliser un fil d’ariane
  • Développer le maillage interne
  • Contenu structuré à l’aide des Hn
  • Contenu intégrant des images optimisées
  • Ne pas répéter inutilement le même mot clé
  • Veiller aux liens cassés

Quelques questions à se poser:

  • Comment sera gérer le fil d’ariane?
  • Comment développer un maillage interne efficace?
  • Comment monitorer les liens cassés?

Back-office

Très important! Il n’y pas que WordPress dans la vie et beaucoup de sites Internet utilisent des back-office taillés sur mesure mais il peut arriver que ces back-offices ne permettent pas de gérer les bases du référencement. Pour aller plus rapidement, vous pouvez ouvrir votre CMS préféré et demander à votre prestataire de développer les options de votre choix. Voici une petite liste:

  • Champs Titles & Meta description
  • Champs rel canonical
  • Uploader un fichier robots.txt
  • Option pour valider les outils pour webmasters (Google, Bing, Yandex)
  • Module de redirection en 301
  • Présence d’un WYSIWYG classique (textes, liens, images, version HTML…)
  • Champ de gestion des ALT, légende et noms de fichiers des images
  • Champ meta robots avec valeurs : all, none, noindex, follow, index, nofollow
  • Champ pour éditer les URL
  • Champ pour spécifier les codes de tracking Analytics
  • Gestion de la pagination

Et encore quelques questions à se poser:

  • Création et implémentation de variables? Pour dynamiser des titles par exemple.
  • Remonter des 404 ? Pratique pour les sites avec X webmasters
  • Création d’alertes? Et si les X webmasters modifient tous X fois les URL? Où bien s’ils uploadent partout des images trop lourdes?
  • Demanderez-vous au prestataire un guide d’utilisation du back-office?
  • Est-ce que tous les éléments cités dans le cahier des charges seront administrables?

Et on peut encore mettre beaucoup de choses…

Qui a dit que le référencement se limitait aux liens ? Bon, cette liste est vraiment loin d’être exhaustive mais je pense que cela pourrait en aider afin de ne pas répéter des erreurs habituelles que l’ont trouve en référencement (voir ici ou ). Dans les divers documents projets, il faudra bien souvent être très précis, par exemple, certains vont mettre des mentions sur les liens (coucou penguin) en précisant que tel ou tel type de lien est à proscrire, ou bien sur la gestion du site mobile ou des rich-snippets et ainsi de suite. Bref, bien cadrer un projet évite les mauvaises surprises et les budgets dépensés inutilement. C’est la crise non?

Killian Kostiha, 28 printemps, SERP addict, curieux et passionné, je suis consultant SEO dans une agence web à Paris, Spikly. Retrouvez ici des informations sur les divers aspects du référencement, des articles sur les bases à respecter ou bien des tests de logiciels.

20 Responses to “Spécifications SEO : Importantes, souvent négligées”

  1. Oh-my-links dit :

    Merci Killian pour cette liste déjà bien complète. Je pense que c’est effectivement une bonne idée à mettre en place quand tu travailles avec des prestataires, par contre quand tu travailles avec des développeurs internes c’est parfois encore plus compliqué de leur faire respecter ces optimisations techniques de base pour la plupart.

  2. SEO is not a crime dit :

    Oui, après on rentre dans des débats de « politique interne » et c’est vite gonflant. Faut taper plus haut, le N+1, N°2, c’est pas pour faire ch*** ces spécifications (même si on dirait le contraire) à première vue 🙂

  3. Pierre dit :

    Salut Killian,
    Ton article est intéressant et très complet, j’avoue que cela peut être très utile pour beaucoup de SEO qui se lance et cela peut éviter de se retrouver dans une situation douteuse avec un client qui a de l’expérience dans la gestion des conflits à travers les points absents des contrats.
    Mais comme Oh-my-links l’écrit, c’est très complexe de faire digérer cet ensemble de points à des dev, mais que ce soit en interne ou externe. On va dire que dans ta spec, tu as un peu la lettre au père noël, mais que malheureusement, il faut souvent jongler pour avoir un maximum de ses pré-requis qui est couvert…. Après l’autre solution est de tout prendre en charge, dev et seo, cela permet souvent de gagner beaucoup de temps, mais la facture n’est pas la même.

  4. SEO is not a crime dit :

    Oui c’est très difficile de faire en sorte que tout soit respecté car le SEO ne sera parfois qu’une composante du projet et puis il y a encore d’autres paramètres a respecter (deadlines, coûts…). Ensuite c’est une histoire de flexibilité et conciliation mais oui, c’est loin d’être évident.

  5. Daniel Roch dit :

    Entièrement d’accord avec cet article : ce n’est qu’en faisant des spécifications techniques SEO précises et complètes que l’on est sûr de pouvoir travailler convenablement le référencement d’un site Internet.

    Le gros problème, outre le fait de réussir à faire comprendre ces problématiques et spécificités aux développeurs, c’est surtout que cet aspect soit pris en compte avant de commencer à développer le site : bien souvent, le référenceur arrive après la bataille et doit tout refaire…

  6. Guillaume dit :

    Hello,

    Déjà merci pour cette liste, ça fait pas mal de point à revoir 😉
    Juste une petite question sur la gestion d’un site en multi-langues, aujourd’hui, est-il préférable d’avoir un TLD par pays, qu’opter pour des sous-domaines ou des répertoires ?

    J’ai pu lire divers avis sur internet, sans forcément de réelle certitude… Alors quelle est votre avis sur la question ?

    Merci 😉

  7. SEO is not a crime dit :

    Hello,

    Je suis habitué à travailler sur des TLD pays et je trouve cela mieux car cela donne plus de billes à Google pour comprendre les cibles du site. Malgré cela, il arrive parfois que sur une Google BE, par exemple, des résultats FR/CH ressortent, donc utilisation de la hreflang. Si, je n’ai pas le choix, je préfère les répertoires, pour qu’ils prennent la popularité du domaine, toujours avec l’usage de la balise hreflang et déclaration du pays cible sur Google Webmasters Tools.

  8. 1-ter-net dit :

    Très bon article, utile aussi bien pour les clients que pour les prestataires (car il donne de bons rappels de ce qu’il faut faire). Hélas, quand un client fournit un cahier des charges aussi complet sur le SEO, c’est qu’il le réalise lui-même.

  9. Guillaume dit :

    Ok ok, merci de ta réponse 😉

  10. Bonjour ..

    Ah, j’aime tes articles, pertinents, vulgarisateur mais aussi techniques à la fois, de quoi démarrer une réflexion sur un sujet.

    Avec ces spécifications seo pour un bon cahier des charges , il faut y coller un temps de main d’oeuvre précis afin d’ être cohérent dans son offre.

  11. consultant web dit :

    Super article résumant les diverses actions que doit un bon referenceur. Une bonne piqûre de rappel ne fera jamais de mal à tous le monde. C est un bon cahier des charges à fournir au client pour ne pas le laisser seul dans l accompagnement de son projet. Avec ceci le client permet de mieux comprendre le seo.

  12. Normand dit :

    C’est une des premières règles à ne pas transiger lorsque que l’on travaille avec des prestataires.
    Il faut absolument TOUT spécifier sinon vous le client à un moment ou un autre vous l’aurez « dans l’os » !

    A ne pas oublier qu’un prestataire est là pour faire de l’argent/du business. Pour un prix donné, moins il aura à réaliser, plus sa marge sera élevé et mieux il se portera. Son objectif premier étant d’avoir la meilleure marge possible.

  13. SEO is not a crime dit :

    @Maurice : Le truc c’est que certains clients ne souhaitent pas trop rentrer dans les détails donc c’est peut-être à cause de cela que je vulgarise. D’un côté c’est normal, le client veut du R.O.I. Merci en tout cas :).

    @Normand: Complètement OK!

  14. Un bon article qu’il faudrait diffuser aux maitres d’ouvrage comme on les appelle.
    Le SEO est malheureusement pris en compte après coup, une fois le site en ligne. Et pourtant, comme décrit ici, les impacts sont multiples :
    – budgétaire évidemment
    – technique avec la gestion des URL, l’organisation de sites multilingues, …
    – sur la production de contenu par l’ensemble de l’entreprise (là aussi, un autre sujet intéressant que la cohésion des contenus et des comportements web dans l’entreprise).

    Bref, un article à garder en favori 😉

  15. Christian from annuaire Human Directory dit :

    Le cas le plus dramatique que j’ai eu (mais qui s’est bien terminé) est un audit de presque 700 pages pour un e-commerce… toutes les erreurs étaient réunies au niveau développement… je ne finissais pas de trouver des choses bizarres…

  16. Ben dis donc Killian, tu t’es énervé sur cette article. C’est un gros pâté à envoyer directement au client ça 🙂 Franchement, il est complet, c’est nickel. Dans mon cas, je passe plus de temps à expliquer tel ou tel point du cahier des charges. Par exemple, j’ai des clients qui se savent pas ce qu’est une balise h1, un title, une balise meta ou un attribut alt d’une image. Quelques liens sont donc ajoutées pour expliquer à quoi ça sert et ou ça se trouve mais je présume que les recommandations que tu fais pour tes clients ne ressemblent pas non plus texto à cet article 😉

  17. Kilroy dit :

    Un article très intéressant en effet.
    Quelques points qu’on peut ajouter :
    – la gestion de la racine du site (pas de redirection, index.html inaccessible)
    – intégration des boutons de partage

    L’intégration des codes Analytics peut faire l’objet d’un doc séparé (plan de marquage)

    Reste qu’il faut s’assurer que les spécifs sont lues, comprises et transmises aux DEV. Je m’arrache les cheveux sur un client pour lequel ces trois conditions n’ont visiblement pas été réalisées : c’est comme si je n’avais rien fait !

  18. Monica Médias dit :

    Ah si ce genre de cahier des charges pouvait tomber du ciel dès lors que le client lambda veut « créer son site »!

    Reste plus qu’à référencer ce post en N°1 des serps sur cette requête! Ou monter un syndicat des agences propres.

    Merci pour la récap de choc

  19. tom@blogmoteurs.fr dit :

    Hello !

    Excellent ton récapitulatif de bonnes pratiques, maintenant faire un cahier des charges seo ne signifie pas qu’il va être pris en compte si les développeurs considèrent cela comme la dernière roue du carosse… et c’est bien dommage, mais cela arrive, c’est hallucinant. Ils en restent au point d’être contents d’avoir un site, alors que le but final est bien d’avoir un site visité… bref, toute une histoire, la relation développeurs / SEO 😉

  20. Alfa dit :

    Très bon article et commentaires intéressants, pour ma part j’ai beaucoup moins de problèmes avec les développeurs que les graphistes qui je trouve intègrent encore beaucoup moins que les développeur la notion de visibilité

top