Mise en page et SEO, ce qu’une IA comprend de votre page

Prenez une de vos pages importantes, une page de service ou une page censée faire remplir un formulaire. Faites-en une capture d’écran, celle qu’un visiteur voit en arrivant, avant de faire défiler.

Donnez cette image à ChatGPT, à Claude ou à Gemini, et posez une seule question. Quelles actions peut-on faire sur cette page ?

La réponse est instructive et souvent désagréable. Sur beaucoup de pages, l’assistant répond qu’on peut lire du texte, et rien de plus. Pas de formulaire visible, pas de bouton identifiable, aucune action proposée. Le titre est enfoui sous une grande image, l’appel à l’action se trouve près du pied de page, et ce qui permet d’agir est noyé dans la décoration.

Ce que vous venez de mesurer n’est pas un avis esthétique. C’est ce qu’une machine déduit de votre page quand elle la regarde au lieu de la lire.

La raison de faire ce test tient dans une publication. En 2025, des chercheurs de Google ont présenté à la conférence EMNLP un travail intitulé Small Models, Big Results, sur l’extraction d’intention. Le principe est simple à décrire.

Le parcours d’un internaute y est traité comme une trajectoire, c’est-à-dire une suite d’observations et d’actions. Les observations sont des captures d’écran des pages vues, les actions sont ce que la personne y a fait. Un premier modèle résume chaque interaction, un second lit la suite de ces résumés et en déduit l’intention générale. Le tout est conçu pour tourner sur l’appareil, ce qui coûte moins cher et évite d’envoyer les captures ailleurs.

Le détail vaut d’être noté. Pour interpréter des données de navigation, ces ingénieurs n’écrivent pas une règle, ils demandent à un modèle de regarder et de conclure. La déduction d’intention ne passe donc plus seulement par les mots d’une page, mais par ce qu’un modèle comprend de son apparence.

Une précision honnête s’impose ici. Ce travail porte sur la compréhension d’un parcours, pas sur le classement des sites, et rien ne dit qu’il alimente le moteur de recherche. Ce qu’il montre, c’est que l’apparence d’une page est devenue une donnée exploitable, et que les outils pour la lire sont désormais banals. Vous avez les mêmes.

Un brevet de Google circule beaucoup depuis le début de l’année, souvent présenté comme la fin des sites web. Il s’intitule AI-generated content page tailored to a specific user, porte le numéro US12536233B1, a été déposé le 3 janvier 2025 et accordé le 27 janvier 2026.

Ce qu’il décrit. Le système reçoit une requête, construit une page de résultats, puis calcule un score de page de destination pour le meilleur résultat d’une organisation. Si ce score dépasse un seuil, il peut proposer un lien vers une page générée par l’IA, assemblée en temps réel et adaptée au parcours de la personne. Le brevet prend l’exemple d’un internaute ayant cherché successivement le meilleur ordinateur portable pour l’architecture, puis pour la modélisation 3D, puis une marque précise.

Voici ce que la plupart des articles ne disent pas. Sa portée est débattue entre spécialistes. Roger Montti, du Search Engine Journal, a relu le texte et conclut qu’il vise le commerce. Il s’appuie sur des éléments concrets, un score fondé sur le taux de conversion, un bouton vers une fiche produit, une liste de produits, un lien inséré dans une annonce. D’autres spécialistes, dont Glenn Gabe, l’avaient d’abord lu comme général, et la revendication principale ne se limite pas explicitement aux annonces.

La conclusion honnête tient en 2 phrases. Un brevet accordé n’est pas une fonctionnalité lancée, et Google en dépose des milliers qui ne voient jamais le jour. Mais un brevet dit ce qu’une entreprise explore, et celui-ci traite la qualité perçue d’une page comme une donnée mesurable.

Google emploie depuis des années une expression qu’il ne définit jamais, celle de contenu qui témoigne d’un effort humain. Tout le monde a cherché à la traduire en gestes, et la plupart des traductions sont mécaniques. Ajouter un tableau, glisser une citation, insérer une image tous les 3 paragraphes.

Le problème saute aux yeux. Tout cela s’automatise en une seule instruction. Si un modèle produit ces marqueurs en quelques secondes, ils ne distingueront pas longtemps un travail humain d’un travail automatique.

Ce qui ne s’automatise pas, c’est la décision de présentation. Choisir de montrer un mécanisme par un schéma plutôt que de le décrire. Décider qu’à cet endroit le lecteur a besoin d’un exemple chiffré et pas d’une définition. Organiser une page pour qu’elle réponde aux questions dans l’ordre où elles se posent. C’est un travail de mise en forme de la pensée, et il se voit.

Il y a une conséquence commerciale à cela. Une petite structure qui décide vite a ici un avantage réel sur une grande. Tout le monde dispose des mêmes modèles, ce qui départage est la capacité à trancher et à publier, pas le budget.

Sur la grande majorité des sites que nous ouvrons, les mêmes 3 défauts reviennent. Tous se corrigent dans le gabarit, le modèle de page que le site réutilise partout, donc une fois pour toutes les pages. C’est ce qui rend ces corrections rentables, l’effort est unique et le gain se répète sur des centaines d’adresses.

Le titre passe au-dessus de l’image d’ouverture. Beaucoup de maquettes placent une grande photo en haut et le titre en dessous. Il faut alors faire défiler pour savoir de quoi parle la page. Un moteur qui analyse la structure rencontre d’abord une image sans rapport avec le sujet, et le titre ensuite.

Une action doit être visible sans faire défiler, c’est-à-dire dans le premier écran, ce que les maquettistes appellent la ligne de flottaison. Un bouton clair suffit, le formulaire entier n’est pas nécessaire. Si votre page a pour but qu’on vous appelle, qu’on demande un devis ou qu’on essaie un simulateur, cela doit se voir immédiatement. C’est exactement ce que le test de la capture d’écran révèle.

Les illustrations doivent montrer, pas décorer. Une photo d’équipe souriante devant un ordinateur n’apprend rien, ni au lecteur ni à la machine. Un schéma qui explique le mécanisme, une capture de l’outil, un avant et après, oui. Le visuel devient une source d’information extraite, et il l’est déjà dans certaines réponses générées.

Aucune de ces 3 corrections ne demande de refaire un site. Toutes se discutent avec le maquettiste en une réunion, et c’est souvent la partie la plus longue.

Le test de la capture d’écran est manuel, donc il ne passe pas à l’échelle. Sur un site entier, mieux vaut mesurer, et 2 mesures suffisent. Le titre principal est-il dans le premier écran, et une action y est-elle visible ?

Voici le contrôle que nous passons sur nos propres pages. Il demande d’installer Playwright, l’outil qui pilote un navigateur, avec npm install playwright, puis de lancer node mesure.mjs https://votre-site.fr/la-page/.

import { chromium } from 'playwright';

const nav = await chromium.launch();
try {
  const page = await nav.newPage({ viewport: { width: 1440, height: 900 } });
  await page.goto(process.argv[2], { waitUntil: 'networkidle' });

  const verdict = await page.evaluate(() => {
  const flottaison = window.innerHeight;

  // Un bandeau de consentement ou une barre collante n'est pas une
  // action de la page. Sans cette exclusion, on mesure ses boutons.
  const flottant = (el) => {
    for (let n = el; n && n !== document.body; n = n.parentElement) {
      const p = getComputedStyle(n).position;
      if (p === 'fixed' || p === 'sticky') return true;
    }
    return false;
  };

  const visible = (el) => {
    if (!el) return false;
    const r = el.getBoundingClientRect();
    return r.top < flottaison && r.bottom > 0 && r.height > 0;
  };

  // Le vrai bouton d'un site est presque toujours un lien stylé, sans
  // attribut role. L'oublier fait rater l'appel à l'action principal.
  const trouves = [...document.querySelectorAll(
      'a[href^="tel:"], a[href^="mailto:"], a[class*="btn"], a[class*="button"], '
      + 'button, form, [role="button"]'
    )].filter((el) => visible(el) && !flottant(el) && el.textContent.trim());

    // Un <form> contient son propre bouton d'envoi. Sans ce filtre, une
    // page de contact annonce 2 actions là où il n'y en a qu'une.
    const actions = trouves.filter(
      (el) => !trouves.some((autre) => autre !== el && el.contains(autre))
    );

  const h1 = document.querySelector('h1');
  return {
    titre: h1 ? h1.textContent.trim() : 'AUCUN H1',
    titrePosition: h1 ? Math.round(h1.getBoundingClientRect().top) : null,
    actionsVisibles: actions.length,
    actions: actions.map((el) => el.textContent.trim().slice(0, 30)),
  };
});

  console.log(verdict);
} finally {
  await nav.close();
}

Ce que ce contrôle a donné sur nos propres pages, mesuré le 6 septembre 2026. Notre page d’accueil rend 2 actions visibles, une page de prestation en rend 2 également, notre page d’erreur 404 en rend 1. Et un de nos articles de blog en rend 0. C’est exactement le genre de résultat que ce test doit produire, et il nous désigne nous.

Deux avertissements, payés tous les deux. Mesurez la position réelle, pas la présence dans le code. Un titre peut exister dans la page et naître 200 pixels sous l’écran, ce que querySelector ne dit jamais. Seule la position calculée tranche.

Et regardez la liste des actions, pas seulement leur nombre. Notre première version comptait les boutons du bandeau de consentement et ratait les vrais boutons du site. Elle rendait le même verdict sur une page qui convertit et sur une page d’erreur, ce qui est le contraire du but recherché.

Ce terrain attire déjà beaucoup d’affirmations, et 2 d’entre elles font perdre de l’argent. Elles se ressemblent, elles consistent toutes les deux à prendre un signal secondaire pour le sujet principal.

La mise en page ne remplace pas le contenu. Elle départage à contenu équivalent, exactement comme la vitesse de chargement le fait depuis des années. Entre écrire la page qui manque à votre site et redessiner celle qui existe, écrivez la page. Une belle page qui répond mal reste une page qui répond mal.

La vitesse de chargement n’est pas le sujet, et son poids n’a pas été démontré. Certains affirment qu’elle remonte, d’autres qu’elle ne compte presque plus. Ce sont des impressions de praticiens, aucun ne mesure. Nos repères ne changent pas, les 3 seuils publiés par Google, affichage sous 2,5 secondes, réactivité au clic sous 200 millisecondes et stabilité visuelle sous 0,1, tous les 3 évalués au 75e centile des visites réelles. C’est la donnée de terrain qui compte, pas le score sur 100 de Lighthouse, qui est une simulation.

Une dernière remarque, qui vaut pour tout ce sujet. Personne ne sait aujourd’hui si Google classe sur la qualité d’une interface. Ce qui est certain, c’est qu’une page où l’on comprend immédiatement ce qu’on peut faire convertit mieux. Cette correction est rentable même si le pari sur les moteurs est faux, et c’est la seule raison valable de la faire maintenant.

3 gestes, du plus court au plus long. Le premier se fait seul, le deuxième demande votre maquettiste, le troisième s’étale dans le temps.

Passez le test sur vos 5 pages les plus importantes. Une capture d’écran, une question à un assistant, 10 minutes en tout. Notez les pages où la réponse ne mentionne aucune action possible, ce sont vos chantiers. Une bonne réponse nomme le bouton et dit ce qu’il déclenche. Une mauvaise réponse décrit une ambiance et parle de texte.

Faites remonter le titre et l’action dans le premier écran. Cela se règle dans le gabarit, donc en une fois pour tout le site. Vérifiez ensuite avec le script ci-dessus, sur l’adresse publique et non sur votre aperçu, car les images, les polices et les scripts tiers y diffèrent souvent, c’est-à-dire précisément ce qui décale une mise en page.

Remplacez vos images décoratives au fil de l’eau, en commençant par les pages qui doivent convertir. Une illustration qui montre le service vaut mieux que 3 qui remplissent, et le sujet rejoint celui des sources que les IA citent, puisqu’une page qui montre est une page qu’on cite.

Si vous préférez que nous nous en chargions, c’est le travail de notre prestation être cité par les IA, et notre agent IA Webmaster passe ces contrôles en continu.