Bases du SEO en développement web : ce qu'il faut intégrer
Une large part du SEO n'est pas du marketing du tout : ce sont des décisions prises pendant le développement, peu coûteuses à la construction et chères ensuite. La structure des URL, la stratégie de rendu, le maillage interne et les métadonnées modifiables entrent tous dans cette catégorie.
Ce guide couvre ce qu'il faut intégrer dès le départ, à peu près par ordre de difficulté à l'ajouter après coup.
Assurez-vous que le site peut être exploré et indexé#
Tout le reste est sans objet si les moteurs ne peuvent ni atteindre ni lire vos pages. C'est aussi là que se concentrent les erreurs du jour de mise en ligne.
- Le robots.txt de production autorise l'exploration. La copie de préproduction ne doit pas être déployée avec.
- Aucune balise noindex égarée reprise de la préproduction.
- Chaque page a une URL canonique auto-référencée, et il y a un seul nom d'hôte canonique.
- Le contenu est dans le HTML ou rendu côté serveur. S'il n'apparaît qu'après exécution du JavaScript, l'indexation devient plus lente et moins fiable.
- Un sitemap XML ne listant que des URL indexables et canoniques, pas des variantes filtrées ou paginées.
- Chaque page indexable a au moins un lien interne. Les pages orphelines sont à peine explorées.
- Des codes de statut cohérents : 200 pour les vraies pages, 404 pour les manquantes, 301 pour les déplacées.
L'échec de lancement le plus courant de cette liste est le robots.txt de préproduction qui atteint la production. Vérifiez-le depuis l'extérieur de votre réseau le jour du lancement.
Une structure que les moteurs peuvent lire#
Les décisions structurelles sont celles qu'il est pénible de changer ensuite, car les changer signifie des redirections et la perte des signaux accumulés.
| Décision | Construisez-la ainsi | Coût d'un changement ultérieur |
|---|---|---|
| Motif d'URL | Courte, minuscules, tirets, stable | Élevé : redirections et signaux perdus |
| Hiérarchie des titres | Un H1, aucun niveau sauté | Faible |
| Maillage interne | Des pivots vers les pages de détail et retour | Moyen |
| Pagination | Des liens explorables, pas uniquement en JavaScript | Moyen |
| Navigation à facettes | noindex sur les combinaisons de filtres | Élevé : l'inflation d'index se résorbe lentement |
| Versions linguistiques | URL préfixées plus hreflang réciproque | Très élevé |
Des métadonnées que votre équipe peut réellement modifier#
Un échec de réalisation fréquent consiste à générer titres et descriptions depuis un gabarit sans possibilité de les remplacer. Six mois plus tard le marketing doit changer le titre d'une page et la réponse est un ticket de développement.
- Balise title modifiable par page, avec une valeur générée par défaut sensée.
- Méta-description modifiable, avec un compteur de caractères visible dans le CMS.
- Titre, description et image Open Graph modifiables pour les liens partagés.
- Données structurées sur les gabarits qui les acceptent : Article, Product, FAQ, Breadcrumb, Organization.
- Un interrupteur noindex par page pour les pages qui doivent exister sans se positionner.
- Canonique automatique, avec un remplacement manuel pour le cas rare qui en a besoin.
Ne balisez que ce qui est réellement visible sur la page. Des données structurées décrivant un contenu qu'un visiteur ne peut pas voir constituent une infraction aux règles, pas un raccourci.
Vitesse et stabilité comme exigences de réalisation#
L'expérience de page fait partie de la réalisation, pas d'un projet d'optimisation ultérieur. Ajouter de la vitesse à un site terminé signifie généralement défaire des décisions plutôt qu'ajouter du code.
| Métrique | Cible | Obtenue par |
|---|---|---|
| Largest Contentful Paint | Sous 2,5 s | Prioriser l'image principale, éviter les ressources bloquant le rendu |
| Cumulative Layout Shift | Sous 0,1 | width et height sur les images, place réservée pour les intégrations |
| Interaction to Next Paint | Sous 200 ms | Moins de JavaScript et ne pas bloquer le fil principal |
| Poids de page | Aussi bas que le design le permet | Formats d'image modernes, aucune bibliothèque inutilisée |
| Time to First Byte | Sous 800 ms | Cache, un CDN et des requêtes de base de données raisonnables |
Questions fréquentes
Le SEO doit-il figurer dans le brief de développement ?
Les parties techniques oui : explorabilité, structure d'URL, métadonnées modifiables, données structurées, objectifs de performance et cartographie des redirections. La stratégie de contenu et le netlinking sont un travail distinct avec un autre profil. Mettre les exigences techniques dans le brief signifie qu'elles sont chiffrées plutôt que découvertes après le lancement, moment où elles coûtent plusieurs fois plus cher.
Un framework JavaScript nuit-il au SEO ?
Il peut, si les pages ne sont rendues que dans le navigateur. Les moteurs exécutent le JavaScript mais avec un délai et pas toujours entièrement, donc un rendu uniquement côté client rend l'indexation plus lente et moins fiable. Le rendu côté serveur ou la génération statique supprime le problème. Pour un site éditorial, la réponse la plus simple est généralement de mettre le contenu dans le HTML.
Combien de temps après le lancement avant de voir du trafic de recherche ?
Pour un domaine tout neuf, généralement des semaines pour l'indexation et des mois avant des positions significatives : les nouveaux sites ne se positionnent pas vite, quelle que soit la qualité technique. Pour la refonte d'un site existant avec des redirections propres, comptez deux à six semaines de fluctuation avant de retrouver le niveau précédent.
Ai-je besoin d'une extension SEO ?
Sur un CMS, une extension est un moyen commode de donner à la rédaction la main sur les titres, descriptions, canoniques et sitemaps. Ce n'est pas une stratégie, et sa sortie par défaut ne remplace pas quelqu'un qui décide du sujet de chaque page. Sur un développement sur mesure, la même fonctionnalité est généralement écrite directement et s'en trouve plus légère.
seo développement webbases du seoseo techniqueseo pour développeursexplorabilitéseo on page
