1 of 30

Audit technique SEO

Promocadeaux.com

Octobre 2020

2 of 30

01

02

03

Introduction

  • Synthèse de l’audit - p 4
  • Recettage du site - p 5
  • To-do list priorisée - p 6

SEO technique

  • Points techniques vérifiés et fonctionnels – p 8
  • Test d’optimisation mobile – p 9
  • Performances d’affichage – p 10 à 14
  • Différer JS – p 15 et 16
  • Réduire le nombre d’éléments du DOM - p 17
  • Compression HTTP Brotli – p 18
  • Réduction du poids des pages - p 19 et 20

Crawlabilité et indexation

  • Points vérifiés et fonctionnels – p 23
  • Indexation des pages – p 24

04

Balisage

  • Points vérifiés et fonctionnels – p 26
  • Titres et H1 similaires
  • Duplication des H1
  • H2 Manquants
  • Optimisation des méta-descriptions

SOMMAIRE

2

3 of 30

Introduction

4 of 30

Synthèse de l’audit

Constat global : site bien optimisé, qui ne présente pas de points techniques critiques pour le SEO

  • Cependant, les performances d’affichages de votre site doivent être améliorées afin de ne pas nuire à l’expérience utilisateur notamment en cas de mauvaises connexion
      • Accès vos efforts sur la navigation mobile

  • L'optimisation des méta-titres est à prévoir pour certaines pages spécifiées dans l’audit
  • Pensez aussi à intégrer la compression Brotli qui permettra là-aussi d’améliorer vos performances de chargement.

4

5 of 30

Recettage du site

  • Nous avons recetté votre site selon des critères SEO que nous avons sélectionnés.
  • Nous essayons d’être le plus exhaustif possible.
  • C’est un score qualité qui n’a pas vocation à atteindre la note parfaite de 100%.
  • Un site qui possède une note de 85% est considéré comme optimal.
  • Le but de cet audit étant d’augmenter cette note le plus possible.

⇒ Voir le fichier de recette-promocadeaux.com

Score de qualité du site :

78%

5

6 of 30

To do list priorisée

L’objectif de cet audit est d'identifier et de prioriser les actions à mettre en place pour optimiser la performance et la qualité du site promocadeaux.com

  1. Différer l’utilisation du code JavaScript
  2. Réduire le nombre d’éléments du DOM
  3. Optimiser et réduire le poids de vos images : dimensions, nommage des fichiers et balises ALT à ajouter si manquantes
  4. Optimiser les méta titres (Titres, H1, méta-descriptions)
  5. Passer à la compression Brotli

6

7 of 30

SEO Technique

8 of 30

Points vérifiés et fonctionnels

  • Site en HTTPS
  • Site actualisé en HTTP/2
  • Certificat SSL activé (protocole HTTP à jour et sécurisé) ⚠️ Il faut le mettre à jour avant le 23/11/2020
  • Site compatible mobile
  • Localisation du serveur en France
  • Keep-Aliv activé (permet de réduire la latence et d’augmenter la vitesse et les performances du site)
  • Performance d’affichage optimisée (gain SEO marginal si amélioration)
  • Taille du DOM optimale (771 éléments)
  • Présence d’un fichier Robots.txt et d’un Sitemap.xml
  • Chargement différé (lazyloading) des images activé
  • Aucunes erreurs 40X ou 50X n’a été relevé, ce qui est un très bon point

8

9 of 30

Test d’optimisation mobile

  • La navigation est un point essentiel lors d’une stratégie SEO.
  • Une mauvaise navigation perd l’internaute qui risque de quitter le site.
  • C’est d’autant plus vrai sur mobile où l’accès aux informations peut-être gêné par :

    • Des textes trop petits
    • Des boutons/liens trop petits (et donc difficilement cliquables)
    • Des informations primordiales non visibles dans la ligne de flottaison

  • Google a commencé depuis la fin 2017 à déployer son index « mobile first » : avoir un site responsive et proposer le même contenu sur le site mobile que sur le site desktop est aujourd’hui essentiel.

  • Google privilégie aujourd’hui la version mobile de votre site.

  • Votre site présente une configuration idéale pour le mobile.

9

10 of 30

Le Score Page Speed est calculé selon deux métriques : le « First Contentful Paint » (FCP) et le « DOMContentLoaded » (DCL).

Pour Google, la vitesse de chargement d'une page constitue un des signaux utilisés par l'algorithme pour se positionner :

    • Si une page est considérée comme lente, cela peut pénaliser le « crawl budget » (le temps passé par les robots Google sur votre site) alloué et l’indexation des contenus stratégiques.

    • Une page qui met longtemps à s'afficher implique souvent un taux de rebond élevé (visiteur entré sur une page web qui quitte le site sans consulter d'autres pages), ainsi qu’un temps faible passé sur la page.

    • Si le temps que met une page à s'afficher est important pour l'utilisateur, il risque d’aller voir ailleurs…
  • Une mauvaise performance, c’est-à-dire une vitesse de chargement trop lente, influence le nombre total de pages indexées.
    • Risque de ne pas avoir l’ensemble de son site indexé

  • Après 3 secondes d’attente, plus de la moitié des mobinautes (53%) quittent une page.
    • Risque de perdre des clients

  • Chaque seconde supplémentaire de chargement d’une page fait baisser (en moyenne) le taux de conversion de 7%, le nombre de pages vues de 11% et la satisfaction client de 16%.

Performances d’affichage - Enjeux

10

11 of 30

  • Performance d’affichage - Home page
  • Au global un score de 7/100 pour le mobile et 32 pour le dekstop : (Google page speed)

  • Les scores sont assez faibles, notamment la version mobile, avec seulement 7/100.
  • Il est important de se focaliser sur la version Mobile du site pour améliorer l’expérience de navigation sur les supports mobiles (smartphones et tablettes)

  • Améliorer la performance d’affichage impacte essentiellement l’expérience utilisateur et le crawl de vos pages par les robots d’indexation. Un site rapide, c’est moins de temps passé sur chaque page pour les robots d’indexation. Pour ces raisons, il est important aujourd’hui d’améliorer la vitesse d’affichage

de vos pages.

Mobile

Desktop

11

12 of 30

  • Performance d’affichage - Pages catégories et produits

Mobile

Desktop

Exemple page catégorie

Mobile

Desktop

Exemple page produits

Les pages produits sont moins lourdes et le temps de chargement sur desktop est meilleur. Des efforts sur l’optimisation de la performance sur site sur mobile sont recommandés.

12

13 of 30

Performances d’affichage - Core Web Vitals

First Contentful Paint (FCP) et Largest Contentful Paint (LCP) sont tous deux des mesures qui évaluent le temps nécessaire au rendu visuel (paint) du contenu sur une page.

La valeur la plus importante est le LCP.

First Input Delay (FID) est une métrique Core Web Vitals qui permet d’évaluer la première impression qu’un utilisateur aura à propos de l'interactivité et de la réactivité d'un site. Il indique le temps entre le moment où un utilisateur interagit pour la première fois avec une page et le moment où le navigateur est réellement en mesure de répondre à cette interaction.

C’est une valeur essentielle.

Cumulative Layout Shift (CLS) - métrique Core Web Vital - évalue l'instabilité du contenu. Il permet de mesurer la quantité de contenu visible déplacé dans le viewport, ainsi que la distance parcourue par ces éléments.

C’est une valeur essentielle.

13

14 of 30

Performances d’affichage - CLS

Le Cumulative Layout Shift (CLS) est une métrique centrée utilisateur qui évalue la stabilité visuelle d’une page web. Elle permet de mesurer la fréquence à laquelle les utilisateurs subissent des changements de mise en page inattendus.

Un CLS faible indique que la page est stable et que son utilisation offre une expérience utilisateur optimale..

  • Votre CLS est trop élevé.

Améliorer le CLS : https://www.fasterize.com/fr/blog/core-web-vitals-google-comment-optimiser-le-cumulative-layout-shift-cls/

  • Pour les polices personnalisées, inclure les valeurs d’affichage des polices (auto, swap, block, fallback et optionnel).
    • rel=”preload” peut être utilisé pour charger une police avant qu’un arbre DOM ne soit construit et rendu.
  • Les éléments d’image et de vidéo doivent avoir des attributs de largeur et de hauteur définis en utilisant un rapport d’aspect proportionnel. Les éléments doivent avoir le même rapport hauteur/largeur pour chaque vue. Utiliser https://aspectratiocalculator.com/ pour les calculer.
  • Utilisez une interface utilisateur squelette ou un placeholder pour réserver de l’espace pour un contenu injecté dynamiquement, afin que le contenu de la page ne soit pas déplacé une fois qu’il est chargé. Pour éviter cela, essayez d’éviter d’injecter du contenu dynamique au-dessus du contenu existant (sauf lorsque cela est nécessaire pour l’interaction avec l’utilisateur).
  • On peut attribuer des images de remplacement aux espaces publicitaires rétractables sur vos pages web. Cela permet de réserver l’espace pour le chargement de l’annonce et d’éviter un décalage de la mise en page pour cet élément.

preload en place

Seul max-width est renseigné

En savoir plus sur l’interface utilisateur squelette :

https://www.numendo.com/blog/ux-ui/skeleton-screen/

Essayer de corriger le CLS.

A faire :

14

15 of 30

Différez l'utilisation du code JavaScript

Lorsque le navigateur web rencontre du code JavaScript en interprétant le code source d’une page web, cela peut ralentir considérablement l’affichage de la page, surtout s’il est nécessaire de télécharger un script externe.

    • Différez au maximum l’utilisation du Javascript pour assurer un début rapide de l’affichage de la page.

Vous pouvez suivre ces instructions : https://blog.dareboost.com/fr/2017/12/differer-les-scripts-pour-accelerer-le-rendu/

Différer le code JavaScript

A faire :

Que faire ?

  • Avant toute chose, distinguez les portions de votre code JavaScript qui sont critiques au chargement de la page, et doivent être chargées le plus tôt possible.
  • Placez-les ensuite dans un fichier externe JavaScript et chargez-le au plus tôt.
  • Gardez ce fichier aussi petit que possible et différez les chargements ou l’exécution de tous les autres scripts JS.

Utilisez l'une des techniques suivantes pour des appels à des fichiers externes :

  • l'attribut async
  • l'attribut defer
  • ajout du script dans le DOM en JavaScript, lors de l'évènement onload
  • placer les scripts à la fin de votre code source (idéalement à la fin du <body>)

15

16 of 30

Différer le JS

391.5 Ko du code JavaScript sont analysés lors du chargement initial de la page. Différez l'analyse de ce code pour éviter de bloquer l'affichage de la page.

  • www.gstatic.com/re[...]r.js (301.0 Ko)
  • www.promocadeaux.c[...]y.js (86.8 Ko)
  • https://www.promocadeaux.com/ (3.6 Ko de code JavaScript intégré)
  • www.google.com/rec[...]6ua7 (45 o de code JavaScript intégré)

16

17 of 30

Réduire le nombre d’éléments du DOM

La structure de la page est complexe et contient trop d’éléments (4136).

Une structure complexe de la page implique plus d'octets à télécharger, et complexifie la recherche d'éléments précis.

Il est conseillé de conserver une page avec moins de 1500 éléments dans le DOM pour ne pas pénaliser et ralentir votre site.

Réduire le nombre d’éléments du DOM

A faire :

Que faire ?

  • Pour réduire la taille de votre DOM (Document Object Model) qui correspond à la structure de votre site et de vos pages, le code HTML, CSS et JS doit être morcelé par un développeur qui se chargera d'éliminer les ressources inutiles.

17

18 of 30

Compression HTTP : Brotli

  • La compression Brotli connaît un taux de compression significativement plus important que celle de GZIP.
  • Problème : Brotli n’est pas pris en compte par tous les navigateurs.
  • Il faut donc continuer à utiliser GZIP.
  • Dans les faits, si l’internaute arrive sur un navigateur qui ne prend pas en compte Brotli, alors il se rabattra sur GZIP.
  • La plupart des navigateurs sont compatibles , la couverture est estimée à 90% des utilisateurs.
  • Brotli a été créé par des ingénieurs de Google et est mis à jour régulièrement.

Voici les chiffres qui ressortent le plus souvent pour les types de ressources statiques classiques du web :

  • HTML : 21% plus petit que GZIP
  • JavaScript : 14% plus petit que GZIP
  • CSS : 17% plus petit que GZIP

Mettre en place la compression Brotli

A faire :

18

19 of 30

Réduction du poids des pages

  • La page d’accueil charge environ 1.84 MB de données

  • Le poids moyen d’une page web est de 1,75 MB.

  • Il faut se rapprocher le plus possible de 1 MB (ce qui est déjà très long à télécharger via une connexion lente) d’autant plus sur les pages qui n’ont pas beaucoup d’images.

  • Plus le poids d’une page est important, plus sa vitesse d’affichage est ralentie, d’autant plus sur les connexions bas débit. Cela peut également générer de la frustration pour vos internautes qui sont limités par des forfaits data.

  • Afin de vous aider à établir vos priorités d'optimisation, voici la répartition du poids de la page d’accueil par type de ressources :

      • Images : 31,96% du poids total
      • JavaScript : 25,31% du poids total
      • CSS : 11,45% du poids total
      • Textes : 3,43% du poids total
      • Polices de caractères : 2,57% du poids total
      • JSON : 0,43% du poids total

Réduire le poids des ressources images et JavaScript

A faire :

19

20 of 30

Réduction du poids des pages

  • Voici les 15 ressources les plus lourdes qui sont téléchargées lors du chargement de votre page :

20

21 of 30

Poids des pages : nombre de requêtes

Il s’agit du nombre de requêtes réalisées entre le navigateur et le serveur pour charger l’ensemble des ressources utiles à une page.

C’est une des règles de performance les plus importantes. Chaque demande (c’est-à-dire chaque ressource chargée) ralentit le chargement de la page.

  • Promocadeaux.com réalise 47 requêtes. Hélas la plupart des requêtes réalisées concernent des ressources externes (des appels JS pour des outils de tracking par exemple).

    • 16 requêts viennent des fichiers webfonts qui sont considérées comme trop lourdes
    • 12 de ces requêtes sont issues des images
    • 10 requêtes proviennent des Scrips
    • 9 requêtes du CSS / HTML

Nous avons bien conscience que réduire le nombre de requêtes est compliqué.

L’objectif est donc :

  • de ne pas augmenter le nombre de ressources,
  • faire le tri dans les ressources pour voir si elles sont toutes bien utiles.

Contrôler et réduire si possible le nombre de requêtes

A faire :

21

22 of 30

Crawlabilité et indexation

23 of 30

Points vérifiés et fonctionnels

  • Présence d’un fichier robots.txt
  • Présence d’un fichier sitemap.xml bien configuré
  • Bonne configuration de la pagination
  • Mise en place de balises canoniques (toutes en self-canoniques)
  • Pas de pages orphelines “actives”

23

24 of 30

Indexation des pages

Il y a un écart entre les pages du site indexé par Google et ce que me donne la version gratuite de Screaming Frog

  • A vérifier sur OnCrawl ou sur la Search Console

24

25 of 30

Balisage

26 of 30

Points vérifiés et fonctionnels

  • Pas de Titres dupliqués
  • H1 présent sur toutes les pages
  • Un seul H1 par page
  • Pas de H2 dupliqués
  • Organisation Hn
  • Balisage Hn de la page d'accueil

26

27 of 30

2 URLs ont le titres et le H1 similaire

-et-objet-publicitaire-un-mariage-envisageable/

  • Les balises title et H1 doivent être sensiblement les mêmes pour que Google comprenne

le sens de la page et facilite l’indexation des pages.

Cependant, le Titre et le H1 doivent varier pour ne pas être strictement identiques

  • Titres et H1 similaires

27

28 of 30

  • Duplication des H1

Chacune de vos pages doit avoir un contenu unique et donc un H1 unique même pour des pages possédant une pagination.

Recommandation sur votre page /2 , /3… :

  • Ajouter “ - Page 2” ou “Page 3” etc après le H1

Exemple :

Le H1 devient : Boissons et gourmandises - Page 2

28

29 of 30

  • H2 manquants

Beaucoup de vos pages ne possèdent pas de H2

Recommandations : Ajouter des H2 sémantiques au seins de vos pages

29

30 of 30

  • Optimiser les méta-descriptions
  • 33 de vos pages ne possèdent pas de méta-descriptions, pensez à en ajouter

  • 10 pages possèdent une méta description dupliquées → variez la méta description de vos pages ayant une pagination

  • 20 pages ont une méta description trop longue. Cette dernière est susceptible d’être tronquées par les moteurs de recherches au delà de 140 caractères.

Voir les pages sans méta-descriptions

Voir les méta-descriptions trop longues

30