Le SEO technique, c'est l'ensemble de ce qui permet à Google d'explorer, de comprendre et d'indexer les pages d'un site. Pas le texte que vous écrivez, pas les liens que d'autres sites pointent vers vous : la mécanique qui fait qu'une page existe aux yeux de Google ou qu'elle reste invisible, quelle que soit sa qualité.
Et c'est là que ça devient une question de chiffre d'affaires. Un contenu excellent que Google ne lit pas ne rapporte rien. Vous pouvez payer un rédacteur pendant des mois, soigner chaque fiche produit, publier un article par semaine ; si la structure technique bloque l'exploration ou égare l'indexation, ce travail ne remonte dans aucun résultat de recherche. Pas de trafic, pas de demandes de devis, pas de vente. Dans cet article, je vous dis quoi regarder sur votre site, et dans quel ordre le corriger : ce qui empêche Google d'entrer avant ce qui le ralentit une fois qu'il est là. Si vous préférez qu'on s'en charge ensemble, j'ai détaillé comment je procède sur mon offre de référencement SEO et GEO.
Ce que recouvre le SEO technique
Exploration et indexation
Google envoie des robots qui parcourent votre site (l'exploration), puis décide quelles pages il garde en mémoire pour les afficher dans ses résultats (l'indexation). Une page peut être explorée sans être indexée ; une page en noindex (une instruction qui dit à Google de ne pas la retenir) n'apparaîtra jamais, même si elle est parfaite. Si cette étape rate, tout le reste de votre stratégie de contenu tourne à vide.
Rendu
Google doit aussi afficher la page pour comprendre ce qu'elle contient. Il exécute le JavaScript (le code qui construit certains éléments d'une page directement dans le navigateur), mais en différé. Un menu, un texte ou un lien qui n'existe qu'après cette exécution est lu plus tard, parfois moins bien. Sur un site qui dépend beaucoup du JavaScript, des pages entières ou des liens internes peuvent ainsi passer sous le radar sans qu'aucune erreur ne s'affiche nulle part.
Structure des URL et maillage
Des adresses de page claires et des liens internes cohérents aident Google à comprendre la hiérarchie de votre site : ce qui est important, ce qui se ressemble, ce qui mène où. Un maillage pauvre dilue le poids de vos pages stratégiques.
Vitesse et Core Web Vitals
Les Core Web Vitals mesurent l'expérience de chargement d'une page. Une page lente perd des visiteurs avant même qu'ils ne lisent votre contenu, et Google le sait.
HTTPS
Le certificat qui chiffre les échanges entre votre site et vos visiteurs ; son absence inquiète autant les navigateurs que les internautes.
Données structurées
Un balisage qui décrit à Google la nature d'un contenu (un produit, un avis, une recette). Ça ne garantit rien, mais ça peut faire gagner un affichage enrichi dans les résultats, donc plus de clics à position égale.
Technique, contenu, popularité : les trois piliers du SEO
Le SEO tient sur trois piliers. La technique ouvre la porte, le contenu donne une raison d'entrer, la popularité (les liens et mentions obtenus ailleurs) donne une raison de faire confiance.
| Pilier | Question posée | Qui s'en charge |
|---|---|---|
| Technique | Google lit-il le site ? | Développeur |
| Contenu | Répond-il aux recherches ? | Rédacteur, marketing |
| Popularité | Inspire-t-il confiance ? | Presse, partenaires |
La technique s'arrête là où commence la pertinence du contenu. Un audit SEO technique irréprochable ne sauvera pas un texte flou qui ne répond à aucune recherche réelle ; il rend visible ce qui mérite de l'être.
Dans quel ordre corriger : de ce qui bloque à ce qui enrichit
Ce qui bloque Google
Un robots.txt (le fichier qui autorise ou interdit l'exploration de certaines zones du site) mal configuré, une balise noindex posée par erreur sur des pages stratégiques, un sitemap (la liste des pages à explorer) jamais envoyé dans Search Console. Tant que ce niveau n'est pas réglé, rien d'autre ne compte : la page n'existe pas pour Google.
Ce qui l'égare
Des URL canoniques contradictoires (Google peut choisir une autre URL canonique que celle que vous avez déclarée), un maillage interne qui ne mène nulle part, des contenus dupliqués entre plusieurs pages. Google voit le site, mais ne sait plus quelle version montrer.
Ce qui le ralentit
Des images trop lourdes, un temps de chargement qui dégrade les Core Web Vitals, un hébergement sous-dimensionné. Ça pèse sur le classement et sur l'expérience des visiteurs. Mais une page lente reste une page qui existe.
Ce qui l'aide à comprendre
Les données structurées, un maillage affiné, des titres de page mieux pensés. C'est la dernière couche : elle affine ce qui fonctionne déjà.
Mon opinion est tranchée sur ce point : on ne travaille pas la vitesse d'un site dont la moitié des pages est en noindex. Classer les priorités dans le mauvais sens, c'est repeindre une porte qui reste fermée à clé.
Refonte ou migration : là où le SEO technique casse le plus
Une refonte réussie visuellement peut détruire des mois de positionnement sans que personne ne s'en aperçoive avant plusieurs semaines. Voici les accidents que je retrouve le plus souvent, et le signal qui doit vous alerter dans Search Console (l'outil gratuit de Google qui montre comment votre site est exploré et indexé).
Le noindex de la préproduction laissé en place : le site de test, volontairement caché aux moteurs, part en production avec cette consigne toujours active. Résultat, vos pages disparaissent des résultats en quelques jours. Dans Search Console, vous verrez un nombre de pages indexées qui chute brutalement, et la ligne « Exclue par la balise noindex » qui grossit dans le rapport d'indexation des pages.
Les redirections 301 oubliées ou en chaîne : une ancienne URL devrait rediriger vers la nouvelle, mais personne ne l'a prévu, ou alors elle rebondit sur trois intermédiaires avant d'arriver à destination. Le symptôme : un pic de pages « Introuvable (404) » dans le rapport d'indexation, et un trafic qui ne se reporte jamais sur les nouvelles pages.
Les canonical recopiés d'un gabarit : la balise canonical indique à Google quelle version d'une page faire foi. Sur un site mal migré, toutes les pages d'une catégorie pointent vers la même URL, copiée collée depuis le modèle. Google finit par choisir lui-même une autre URL canonique que celle déclarée ; vous le voyez dans Search Console sous la mention « Google n'a pas choisi la même URL canonique que l'utilisateur ».
L'ancien sitemap toujours déclaré : le fichier qui liste vos pages à explorer n'a pas été mis à jour ou pointe encore vers l'ancienne structure. Google continue d'essayer de visiter des pages qui n'existent plus, et ignore les nouvelles tant que le bon sitemap n'est pas soumis.
Le menu ou les liens qui n'existent qu'en JavaScript : si la navigation est générée uniquement après exécution du JavaScript, Google la lit plus tard, parfois mal. Des pans entiers du site deviennent alors difficiles à découvrir, ce qui se traduit par des pages jamais explorées malgré leur présence réelle sur le site.
Ces points se vérifient avant la mise en ligne, qu'il s'agisse d'une refonte de site web ou d'une migration technique ; ma checklist de migration SEO détaille l'ordre exact des vérifications.
Audit SEO technique : ce qu'un rapport utile doit vous dire
L'audit technique au sens large vérifie que le site fonctionne ; je le détaille dans cet article sur l'audit technique. L'audit SEO technique, lui, cherche une seule chose : ce qui empêche Google de lire, comprendre et classer vos pages.
Beaucoup d'outils produisent des centaines d'alertes sans aucune hiérarchie, mélangeant une image mal compressée et un blocage total d'indexation sur la même ligne. Un rapport utile priorise. Pour chaque point relevé, il doit indiquer la cause (ce qui, dans le code ou la configuration, produit le problème), la gravité pour votre trafic (est-ce que ça vous coûte des visiteurs maintenant, ou plus tard), l'effort nécessaire pour corriger, et qui doit s'en charger : votre développeur, votre CMS (l'outil qui gère votre site), ou votre équipe marketing.
Sans cette hiérarchie, vous recevez un document impressionnant que personne ne traite, faute de savoir par où commencer.
Pourquoi je corrige moi-même ce que je relève
Le développeur qui lit le code et le référenceur qui lit Search Console ont rarement le temps de se comprendre ; l'un parle balises et serveur, l'autre parle positions et clics. Je fais les deux depuis plus de dix ans, d'abord comme développeur puis comme responsable des projets web chez Cyclable, sur un site e-commerce qui recevait jusqu'à trois millions de visiteurs par an. Cette double casquette change la nature de la recommandation : elle est chiffrée par celui qui la réalisera, donc elle se fait.
C'est cette approche qui m'a permis de migrer plus de mille pages pour Ad Majoris et plus de cinq mille articles pour Skinobs sans perte de référencement : même personne du diagnostic à la correction, même checklist de mise en ligne (sauvegarde, redirections 301, certificat SSL, fichier robots.txt, sitemap envoyé dans Search Console, contrôle le lendemain).
Si vous voulez savoir où en est votre site sur ces points, je peux faire relire son état technique avant que le sujet ne coûte du trafic ou des demandes de devis : écrivez-moi.