SEO on-page technique : quels sont les 12 critères qui comptent vraiment ?

Le SEO on-page technique regroupe les optimisations internes à vos pages qui déterminent si un moteur peut les explorer, les comprendre et les afficher. Douze critères suffisent, à condition de les traiter dans le bon ordre.

SEO on-page et SEO technique : quelle différence concrète ?

Le SEO on-page désigne ce que vous modifiez depuis votre back-office sans aide extérieure : titres, contenu, balises, liens internes. Le SEO technique couvre ce qui touche à la façon dont le site est servi et rendu : indexation, crawl, performance, code. La frontière ne tient ni au vocabulaire ni au niveau de difficulté, mais à une question opérationnelle.

Cette question est celle du délai de correction. Réécrire une balise title prend deux minutes et ne dépend de personne. Corriger un rendu JavaScript défaillant suppose un développeur, une recette et une mise en production. Sur un plan d’action, les deux ne se planifient pas de la même façon, et c’est la seule raison pour laquelle la distinction mérite d’exister.

Les CMS ont brouillé cette limite. Sur WordPress, un plugin SEO donne accès à des réglages d’indexation, de canonical et de sitemap qui relevaient autrefois du serveur. Une partie du technique est passée dans l’interface d’administration, ce qui explique pourquoi les deux termes sont désormais employés ensemble dans une même requête.

D’après moi, la classification on-page contre technique intéresse surtout les consultants entre eux. Un dirigeant veut savoir ce qu’il peut corriger lui-même cette semaine et ce qui demande un budget. C’est cette lecture que j’utilise dans mes plans d’action, et elle produit des arbitrages plus nets qu’un débat de taxonomie.

Par quoi commencer ? Les 12 critères classés par impact

Trois niveaux de priorité gouvernent l’ordre des corrections. Les critères bloquants empêchent votre page d’exister dans les résultats. Les structurants déterminent sa compréhension et son classement. Les fondations se vérifient une fois puis se surveillent.

L’erreur la plus fréquente consiste à travailler les finitions avant les bloquants. Optimiser cinquante balises title sur des pages que Google n’indexe pas ne produit rien. Le tableau ci-dessous donne l’ordre que j’applique dans mes audits.

La colonne « impact » se lit relativement à un site déjà fonctionnel. Sur un site neuf, tout est majeur. Sur un site existant qui stagne, la cause se trouve presque toujours dans la première section du tableau.

Les 4 critères techniques bloquants

Ces quatre points conditionnent l’existence de vos pages dans les résultats. Aucun travail éditorial ne compense leur défaillance.

1. L’indexation : vos pages sont-elles réellement dans l’index ?

Le rapport Indexation des pages de la Search Console, anciennement nommé Couverture, répond en une minute. Il classe vos URL en deux catégories : indexées et non indexées, avec le motif exact du rejet.

Deux erreurs symétriques reviennent dans presque tous les audits. Des pages sans valeur SEO se retrouvent indexées, mentions légales, pages de remerciement, archives de catégories vides, ce qui dilue l’évaluation globale du site. Et des pages stratégiques restent hors index, souvent à cause d’une balise noindex oubliée après une refonte ou d’un canonical mal orienté.

Le contrôle prend cinq minutes par mois. La correction, quand elle porte sur une page commerciale, produit l’effet le plus rapide de toute cette checklist.

2. Le crawl : robots.txt et sitemap

Le fichier robots.txt contrôle le crawl, pas l’indexation. Cette confusion est la plus répandue du métier et elle produit des situations absurdes : une page bloquée dans robots.txt peut apparaître dans les résultats, sans description, parce que Google connaît son URL par des liens externes sans pouvoir lire son contenu. Pour empêcher l’indexation, la balise noindex est le bon outil, et elle suppose que le crawl reste autorisé.

Le sitemap XML liste les URL que vous souhaitez voir explorées. Son utilité croît avec le volume : marginal sous une trentaine de pages, décisif au-delà de quelques milliers. Sur WordPress, les extensions SEO le génèrent et le maintiennent automatiquement.

3. Le rendu JavaScript : le critère que personne ne teste

Googlebot exécute le JavaScript, les robots des moteurs de réponse non. L’analyse conduite par Vercel avec MERJ sur le trafic réel de ces robots conclut qu’aucun des principaux crawlers d’IA ne rend le JavaScript. GPTBot télécharge des fichiers JavaScript dans environ 11,5 % de ses requêtes sans les exécuter, ClaudeBot dans près de 24 % des cas avec le même résultat.

La conséquence est directe pour un site dont le contenu principal se charge côté client : il peut être parfaitement indexé par Google et rester totalement vide pour ChatGPT ou Perplexity. Un canal fonctionne, l’autre pas, sans qu’aucun rapport ne le signale.

Le test demande trente secondes. Affichez le code source de la page avec le raccourci de votre navigateur, pas l’inspecteur d’éléments, puis cherchez une phrase de votre contenu principal. Si elle apparaît, tous les robots la voient. Si elle n’apparaît que dans l’inspecteur, elle est générée en JavaScript et reste invisible aux crawlers d’IA.

4. Les codes de réponse : 200, 301, 404

Le vrai sujet n’est pas la pénalité, il n’y en a pas. C’est le gaspillage de ressources d’exploration et la friction pour le visiteur.

• Code 200 — la page répond normalement. C’est l’état attendu de tous vos liens internes.
• Code 301 — redirection permanente. Un lien interne qui pointe vers une redirection fonctionne, mais fait passer le robot par une étape inutile. En volume, cela consomme des ressources d’exploration sur des allers-retours plutôt que sur vos nouvelles pages.
• Code 404 — page inexistante. Un 404 isolé est normal et Google le traite sans difficulté. Un maillage interne truffé de 404 signale un site mal entretenu et fait fuir les visiteurs.

Je trouve des liens en erreur dans la quasi-totalité des audits que je réalise, y compris sur des sites soignés par ailleurs. La cause est presque toujours la même : une URL modifiée sans mise à jour des liens qui pointaient vers elle. Un crawl avec Screaming Frog identifie l’ensemble en quelques minutes.

Les 5 critères on-page à vérifier sur chaque page

Ces cinq points se travaillent page par page, sans dépendance technique. Chacun fait l’objet d’un guide dédié sur ce blog, la synthèse ci-dessous couvre l’essentiel et l’évolution 2026.

5. La balise title

Le title reste le signal on-page le plus puissant. Placez le mot-clé principal au début, gardez chaque title unique sur le site, écrivez pour inciter au clic plutôt que pour empiler des termes.

Ce qui a changé : Google réécrit fréquemment les titles affichés dans les résultats, en piochant dans votre H1 ou votre contenu quand il juge le title inadapté à la requête. Un title bien écrit reste utile, il sert de signal de pertinence même quand l’affichage diffère. L’objectif s’est déplacé de la maîtrise de l’affichage vers la clarté du signal envoyé.

6. La balise meta description

La meta description n’influence pas le classement. Elle agit sur le taux de clic, ce qui suffit à justifier de la rédiger correctement sur vos pages commerciales.

La limite d’affichage se mesure en pixels, pas en caractères, et varie entre mobile et ordinateur. Une description autour de 150 à 160 caractères reste un repère pratique. Google la réécrit souvent à partir du contenu de la page quand un extrait répond mieux à la requête. Sur un site à fort volume, concentrez l’effort sur les pages qui convertissent.

7. Les balises Hn

Les balises H1 à H6 décrivent la structure logique de votre page. Une seule H1 par page, des H2 pour les sections principales, des H3 pour leurs subdivisions, sans saut de niveau.

Leur rôle s’est élargi. Au-delà de la compréhension par Googlebot, la hiérarchie Hn détermine le découpage de votre page en passages autonomes, et donc la capacité d’un moteur de réponse à en extraire un extrait citable. Une page sans H2 offre peu de points d’entrée aux IA génératives.

8. Le maillage interne

Chaque page doit recevoir des liens depuis d’autres pages du site. Une URL orpheline se découvre mal et reçoit peu d’autorité interne. Le maillage réduit aussi la profondeur de clic, qui détermine la fréquence de passage des robots.

Les ancres descriptives valent mieux que les formules génériques : « guide du maillage interne » transmet une information que « cliquez ici » ne transmet pas. Placez les liens dans le corps du texte plutôt qu’en pied de page, la position compte.

9. Les données structurées

Le balisage JSON-LD décrit explicitement la nature de votre page et de votre entité : article, produit, question fréquente, organisation, personne. Absent de la plupart des checklists techniques françaises, c’est pourtant un levier direct.

Deux bénéfices distincts. L’éligibilité aux résultats enrichis dans Google, qui améliore la visibilité sans changer la position. Et la clarification de votre entité pour les systèmes qui construisent des graphes de connaissance, ce qui recoupe directement les mécanismes d’attribution utilisés par les moteurs de réponse.

Sur WordPress, les extensions SEO génèrent un balisage de base. Les schémas plus précis, notamment FAQPage et HowTo, demandent une intervention manuelle et se valident avec l’outil de test des résultats enrichis de Google.

Contrôle rapide, page par page :

• Une seule balise H1, unique sur le site
• Un title unique, mot-clé principal en début de balise
• Au moins deux liens internes entrants et deux sortants
• Aucun saut de niveau dans la hiérarchie Hn
• Un balisage JSON-LD valide, testé avant mise en ligne

Les 3 fondations à vérifier une fois, puis à surveiller

Ces trois critères se traitent au lancement ou lors d’une migration. Ils ne se retravaillent pas mensuellement, mais leur défaillance coûte cher.

10. Le HTTPS

Le protocole sécurisé est un acquis depuis longtemps, et son absence est aujourd’hui l’exception. Le point de vigilance se situe après une migration ou un changement d’hébergeur : contenus mixtes, certificat expiré, redirections HTTP vers HTTPS incomplètes. Un contrôle après chaque intervention serveur suffit.

11. La structure et la stabilité des URL

La stabilité prime sur l’optimisation. Une URL courte, lisible et contenant le mot-clé apporte un gain marginal ; une URL modifiée sans redirection propre détruit l’antériorité accumulée. Évitez les caractères accentués, les underscores et les dates dans les permaliens.

La conséquence pratique : ne renommez jamais une URL en ligne pour un gain esthétique. Si la modification est nécessaire, une redirection 301 et une mise à jour de tous les liens internes qui pointaient vers l’ancienne adresse sont obligatoires.

12. Les Core Web Vitals

Trois métriques mesurent l’expérience de chargement : le LCP sous 2,5 secondes pour l’affichage du plus gros élément visible, l’INP sous 200 millisecondes pour la réactivité aux interactions, et le CLS sous 0,1 pour la stabilité visuelle. Google a remplacé l’ancien FID par l’INP le 12 mars 2024, en précisant que ce changement corrigeait les limites du FID, lequel ne mesurait que la première interaction.

Les données terrain de la Search Console priment sur le score de laboratoire de PageSpeed Insights. Sur WordPress, l’INP se dégrade principalement par accumulation de scripts tiers et d’extensions qui saturent le fil d’exécution.

Le SEO technique change-t-il avec les moteurs de réponse ?

Les fondamentaux ne bougent pas. Une page illisible pour Googlebot l’est aussi pour GPTBot, et les critères d’indexation, de crawl et de structure servent les deux canaux sans modification.

Trois points s’ajoutent. Le premier concerne les directives destinées aux robots d’IA dans robots.txt : GPTBot, ClaudeBot, PerplexityBot et Google-Extended s’y déclarent séparément, et un blocage hérité d’une configuration serveur ou d’un pare-feu peut vous exclure sans que vous le sachiez. Le deuxième est la lisibilité du contenu en HTML brut, développée plus haut. Le troisième tient à la structure extractible : des sections autonomes ouvrant sur une réponse directe se citent, un pavé continu se cite mal.

D’après moi, le fichier llms.txt ne mérite pas votre temps aujourd’hui. Ce format proposé pour guider les modèles vers vos contenus n’est reconnu officiellement par aucun des principaux moteurs de réponse à ce jour. Le créer ne coûte rien, mais le prioriser avant un problème de rendu JavaScript ou d’indexation revient à décorer une façade dont la porte est fermée. Je réévaluerai cette position si une adoption officielle intervient.

Transparence : je suis co-fondateur de Cockpyt AI. L’outil interroge chaque semaine ChatGPT, Perplexity, Gemini et Claude sur vos requêtes métier et remonte les marques citées. Le contrôle manuel décrit plus haut reste possible, il demande simplement du temps.

Questions fréquentes sur le SEO on-page technique

Quelle différence entre SEO on-page et SEO technique ?

Le SEO on-page couvre ce que vous modifiez depuis votre back-office : titres, contenu, balises, liens internes. Le SEO technique concerne la façon dont le site est servi et rendu : indexation, crawl, performance, code. La distinction utile porte sur le délai de correction, pas sur la difficulté.

Faut-il un développeur pour faire du SEO technique ?

Pas pour la majorité des critères. Indexation, robots.txt, sitemap, maillage et balises se pilotent depuis WordPress avec une extension SEO. Un développeur devient nécessaire pour le rendu JavaScript, l’optimisation de l’INP et les interventions sur le thème ou le serveur.

À quelle fréquence refaire un audit technique ?

Un audit complet une fois par an suffit sur un site stable, complété par un contrôle mensuel de l’indexation dans la Search Console. Une refonte, une migration ou un changement d’hébergeur justifient un audit immédiat, ce sont les moments où les régressions techniques apparaissent.

Le SEO technique suffit-il à bien se positionner ?

Non. La technique lève les obstacles, elle ne crée pas la pertinence. Un site techniquement irréprochable sans contenu répondant à une intention de recherche ne se positionne sur rien. La technique conditionne le reste sans le remplacer.

Combien de temps après une correction technique voit-on un effet ?

Une correction d’indexation produit un effet en quelques jours après demande de réexploration. Les Core Web Vitals reposent sur 28 jours glissants de données terrain, comptez un mois. Les corrections de structure et de maillage agissent progressivement sur plusieurs semaines.

Faut-il bloquer les robots d’IA dans son robots.txt ?

La question dépend de votre modèle. Bloquer préserve votre contenu de l’entraînement, au prix de toute chance d’être cité comme source. Autoriser expose le contenu et ouvre la visibilité. Pour une activité de conseil ou de service, la citation vaut généralement plus que la protection. Pour un éditeur vivant de son contenu, l’arbitrage est inverse.

Florian Zorgnotti, consultant SEO à Nice depuis 2016.

Sources

• Google Search Central, « Introducing INP to Core Web Vitals », mise à jour du 12 mars 2024 — remplacement du FID par l’INP. developers.google.com
• web.dev (Chrome team), « Interaction to Next Paint is officially a Core Web Vital », 12 mars 2024 — dépréciation du FID et seuils des Core Web Vitals. web.dev
• Vercel & MERJ, « The rise of the AI crawler », 2024 — analyse du trafic réel des robots d’IA : aucun ne rend le JavaScript. vercel.com