Les ennuis du jour du lancement sont le plus souvent banals. Un site de préproduction est mis en ligne avec les moteurs de recherche encore bloqués. Un formulaire de contact remercie le visiteur sans envoyer de courriel à personne. La table de redirection ne couvre que les pages dont quelqu’un se souvenait. Ces vérifications essentielles avant de lancer un site web permettent de les repérer pendant qu’ils se corrigent encore en un après-midi.
Les treize vérifications suivent l’ordre dans lequel nous les faisons. Accordez le plus d’attention aux deux premières, parce qu’une erreur à ces étapes peut coûter des mois de trafic de recherche avant que quelqu’un s’en aperçoive.
1. Faites correspondre chaque ancienne URL à une nouvelle
Lors d’une refonte, cette vérification protège le trafic de recherche et les liens que l’ancien site a déjà gagnés. Explorez le site actuel, exportez toutes ses URL et attribuez à chacune une seule adresse sur le nouveau site. Les documents en font partie. Les PDF se classent dans les résultats de recherche et reçoivent leurs propres liens, et on les oublie facilement dans la table. Si votre site en contient des milliers, notre article sur la migration de documents sans perte de visibilité décrit la méthode.
Utilisez des redirections permanentes qui mènent à la nouvelle page en un seul saut. Ouvrez ensuite chaque ancienne URL et confirmez qu’elle aboutit à une page active. Une erreur 404 ou une deuxième redirection signale un trou dans la table, et un tableur marqué « complet » ne vous le dira pas. Notre page refonte et modernisation de site web explique comment nous faisons cette correspondance lors d’une refonte.
2. Retirez le noindex de préproduction, et lisez le robots.txt
Parmi les erreurs de lancement les plus coûteuses sous WordPress, il y a l’option « Demander aux moteurs de recherche de ne pas indexer ce site », laissée cochée dans Réglages, Lecture. On la coche en préproduction, puis on l’oublie au moment de la mise en ligne. Le site peut alors rester absent des résultats pendant des semaines. Comme il ressemble à un nouveau site qui ne s’est pas encore classé, personne ne cherche la cause.
Vérifiez le réglage, puis ouvrez /robots.txt et lisez-le. Il ne doit bloquer aucune page que vous voulez voir indexée, et il doit indiquer l’adresse de votre plan de site. Regardez enfin le code source de quelques gabarits pour repérer une balise noindex oubliée par une extension ou une option du thème.
3. Relisez tout, à voix haute, dans chaque langue publiée
Lisez chaque page à voix haute, parce que l’oreille attrape ce que l’œil saute. Faites-la relire par une personne qui n’a pas écrit le texte. Passez ensuite aux endroits que personne ne relit : étiquettes de formulaires, messages d’erreur, écrans de confirmation, libellés de boutons, page 404, gabarits de courriel et titres de pages.
Si vous publiez en deux langues, assurez-vous que chaque page française est en français d’un bout à l’autre. Un formulaire en français qui répond par des messages d’erreur en anglais se voit souvent. Ce sont justement les visiteurs francophones qui le remarquent en premier.
4. Testez chaque formulaire de bout en bout, courriel compris
Un message de remerciement à l’écran vous apprend seulement que le formulaire a été envoyé. Savoir si quelqu’un l’a reçu est une autre affaire. Remplissez chaque formulaire pour vrai et vérifiez que l’avis arrive à la bonne adresse, avec toutes les valeurs des champs et une adresse de réponse qui fonctionne.
Jetez aussi un œil aux courriels indésirables, puisque les messages d’un nouveau site sur un nouveau serveur y aboutissent souvent. Si votre domaine a des enregistrements SPF, DKIM et DMARC, validez-les dès maintenant, avant que des demandes perdues vous apprennent qu’il y a un problème. Testez ensuite les cas d’erreur. Envoyez le formulaire avec des champs obligatoires vides et confirmez que les messages sont clairs et annoncés aux lecteurs d’écran.
5. Vérifiez l’accessibilité
Les outils automatisés ne trouvent qu’une partie des problèmes d’accessibilité. Lancez-les d’abord, puis faites la vérification manuelle. Parcourez chaque gabarit au clavier seulement. Vous devez pouvoir atteindre et utiliser chaque élément, voir en tout temps où se trouve le focus et ne jamais rester coincé. Vérifiez que le texte courant respecte un rapport de contraste de 4,5:1. Les images porteuses de sens ont besoin d’un texte alternatif, et les images décoratives d’un attribut alt vide.
Si vous devez respecter une norme d’accessibilité précise, comme le SGQRI 008 3.0 au Québec, les WCAG 2.2 niveau AA ou les WCAG 2.0 niveau AA exigées par la LAPHO en Ontario, consignez le résultat critère par critère. Un simple « conforme » ou « non conforme » ne dit pas quoi corriger, et il se défend mal le jour où on vous demande des détails.
6. Un seul H1, un titre et une description uniques par page
Chaque page a besoin d’un seul H1, et les intertitres qui suivent doivent descendre dans l’ordre sans sauter de niveau. Les personnes qui utilisent un lecteur d’écran se déplacent dans la page par ses intertitres, et les moteurs de recherche lisent la même structure.
Chaque page a aussi besoin de sa propre balise titre et de sa propre méta description. Les doublons sont un problème fréquent, qui vient la plupart du temps d’une valeur par défaut du gabarit que personne n’a remplacée. Si une extension vous propose encore un champ de mots-clés méta, laissez-le vide. Google a cessé de s’en servir il y a longtemps.
7. Vérifiez les Core Web Vitals sur les gabarits qui comptent
Testez la page d’accueil, une page de contenu, une page de liste et chaque formulaire ou page de paiement sur un téléphone de milieu de gamme. Votre portable donnera des résultats trop flatteurs. Les cibles sont un Largest Contentful Paint sous 2,5 secondes, un Interaction to Next Paint sous 200 millisecondes et un Cumulative Layout Shift sous 0,1.
Le décalage de mise en page est celui qui passe le plus souvent inaperçu avant le lancement. Il vient d’habitude d’images sans attributs de largeur et de hauteur. Des polices web qui s’affichent en retard peuvent aussi le causer, tout comme une bannière insérée au-dessus du contenu une fois la page chargée.
8. Optimisez les images et donnez-leur un vrai texte alternatif
Servez des formats récents comme WebP ou AVIF, et donnez à chaque image la taille de l’espace qu’elle occupe vraiment à l’écran. Activez le chargement différé pour les images plus bas dans la page. Gardez-le désactivé pour la grande image du haut, puisque c’est souvent elle qui détermine votre Largest Contentful Paint. Testez aussi sur une connexion mobile lente, en plus du réseau du bureau.
Un bon texte alternatif dit à quoi sert l’image sur la page. La photo d’un produit à côté de son prix a besoin du nom du produit, et une image qui sert de lien a besoin de sa destination. Quand une image est purement décorative, l’attribut alt vide est la bonne réponse : le lecteur d’écran la saute au lieu de lire un nom de fichier.
9. Vérifiez sur de vrais navigateurs et de vrais appareils
Testez les versions courantes de Chrome, Safari, Firefox et Edge, puis Safari sur un vrai iPhone et Chrome sur un vrai téléphone Android. De petites différences visuelles d’un navigateur à l’autre sont acceptables, tant que chaque menu, formulaire et bouton fonctionne.
Essayez le mode sombre si les appareils de vos visiteurs peuvent l’utiliser. Agrandissez ensuite l’affichage du navigateur à 200 %. Les WCAG exigent que le texte reste utilisable à cette taille, et c’est une façon rapide de trouver les mises en page qui se brisent.
10. Installez et validez les statistiques et la Search Console
Installez l’outil de statistiques avant le lancement pour avoir des chiffres dès le premier jour. Vérifiez que le suivi se déclenche sur chaque gabarit, et que la bannière de consentement ne le bloque pas en silence.
Validez le site dans la Google Search Console en même temps. Après un changement de domaine, ajoutez les deux propriétés et utilisez l’outil de changement d’adresse. Définissez ce qui compte comme une conversion, et assurez-vous d’en voir une dans vos rapports avant qu’on vous demande les chiffres.
11. Soumettez le plan de site XML
Ouvrez le plan de site et lisez-le. Il doit contenir les pages que vous voulez voir indexées, sans brouillons, URL de préproduction, pages de fichiers joints ni doublons paginés. Soumettez-le dans la Search Console, puis revenez quelques jours plus tard consulter le rapport d’indexation des pages. Une erreur de configuration y apparaît en général en premier.
12. Prévoyez une page 404 qui aide les gens à se retrouver
Si soignée que soit votre table de redirection, quelqu’un arrivera sur une URL qui n’existe plus. Donnez à la page 404 un champ de recherche, des liens vers vos grandes sections et un moyen de vous joindre, pour que ces visiteurs aient quelque part où aller. Vérifiez ensuite le code de statut. La page doit renvoyer un vrai code 404. Un message « page introuvable » servi avec un code 200 est un faux 404, qui embrouille les moteurs de recherche et fait disparaître les liens brisés de vos rapports.
13. Sauvegardez, puis prouvez que la sauvegarde se restaure
Tant que vous n’avez pas restauré une sauvegarde, vous ne faites qu’espérer qu’elle fonctionne. Faites une copie complète des fichiers et de la base de données, et gardez-la ailleurs que sur le serveur d’origine. Restaurez-la ensuite quelque part et confirmez que le site démarre.
Profitez-en pour resserrer la sécurité. Confirmez que le HTTPS est imposé sur tout le site, sans avertissement de contenu mixte. Renommez tout compte administrateur appelé admin, supprimez les comptes de test et activez l’authentification à deux facteurs pour les administrateurs. Notez ensuite qui détient les accès au domaine, au DNS et à l’hébergement.
Les petites choses, rapidement
- Une icône de site (favicon) aux tailles qu’utilisent les navigateurs et les écrans d’accueil des téléphones.
- Le logo mène à la page d’accueil.
- Les balises Open Graph, vérifiées en collant une URL dans chaque plateforme où elle sera partagée.
- Un seul nom d’hôte canonique, vers lequel mènent les versions avec et sans www.
- Des styles d’impression, si des gens impriment vos pages. Regardez une longue page et un tableau dans l’aperçu avant impression.
- La politique de confidentialité, l’avis sur les témoins et les autres pages légales, avec des liens là où les visiteurs s’attendent à les trouver.
Le lendemain
La liste se poursuit pendant la semaine qui suit le lancement. Surveillez dans la Search Console les erreurs d’exploration et les changements d’indexation. Cherchez dans les journaux du serveur les erreurs 404 causées par de vrais visiteurs, et continuez de tester les formulaires. Un léger creux de visibilité après une refonte est normal. S’il ne se résorbe pas après quelques semaines, revenez aux vérifications un et deux, où se trouve habituellement la cause.
Si vous préférez confier cette liste à quelqu’un d’autre, notre page développement WordPress sur mesure explique comment nous construisons et lançons un site, et ce que nous vous remettons à la fin.