Ce qui a changé dans la recherche au premier semestre 2026

Bing a commencé à montrer aux éditeurs les pages qu’il cite dans ses réponses IA. Google a modifié Discover, retiré les résultats enrichis FAQ et introduit des rapports dédiés aux impressions IA. À côté de ces changements visibles, les limites du crawl, la navigation dans le navigateur et les migrations de domaine ont donné beaucoup de points à vérifier aux équipes techniques. Cette revue relie les évolutions de janvier à juin aux rapports, aux pages et aux décisions de mise en production qu’elles concernent.

Données

La séquence qui a modifié les décisions opérationnelles

L’ordre compte, car chaque événement répond à une question différente. En janvier, la documentation sur les problèmes de pratique liés aux données structurées a été retirée, et des consignes sur les sources préférées sont apparues. En février, une Discover Core Update régionale, en anglais américain, est arrivée, et Bing a publié un premier aperçu public de son rapport AI Performance. En mars, des fenêtres de déploiement distinctes pour le spam et la core update se sont superposées, avec une explication technique sur la façon dont Googlebot traite les réponses. En avril, la core update a été terminée et le détournement du bouton Retour a été ajouté à la politique spam. En mai, l’apparence « résultats enrichis FAQ » a été supprimée et des consignes sur l’IA générative ont été publiées. En juin, Search Console a reçu un reporting IA, Bing a élargi ses vues IA et Yandex a mis en place la surveillance horaire des requêtes.

Cet ordre évite aussi les erreurs de catégorie. Un éditeur peut corriger immédiatement un problème de réponse du crawler, même s’il survient pendant une core update. Le retrait d’une fonctionnalité appelle une décision sur le gabarit et le contenu, alors qu’un lancement de reporting appelle une définition de mesure. Placez l’événement à côté des preuves sur les pages concernées, plutôt que dans une seule colonne « mise à jour algorithmique » sans distinction.

Changement produit

Discover et sources préférées

La Discover Core Update de février de Google a commencé avec un périmètre en anglais américain et des consignes sur la pertinence locale, l’expertise originale et l’actualité, ainsi que sur des contenus moins sensationnalistes. La première question de revue est donc géographique et éditoriale : le public, la langue et le format concernés se trouvaient-ils dans la surface documentée ? Un mouvement de Discover hors de ce cadre ne prouve pas qu’il faille modifier le gabarit général d’une page. Vérifiez les indices de localisation du contenu, son expertise thématique, la date de publication et le rapport Discover réel avant de considérer les impressions comme un signal de classement universel.

Les sources préférées ont suivi un autre parcours. Google a documenté la fonctionnalité en janvier, l’a étendue à toutes les langues de Search en avril, puis a ajouté AI Overviews et AI Mode au périmètre documenté en mai, comme l’indiquent ses mises à jour de la documentation. Les éditeurs peuvent proposer un bouton ou un lien qui aide les lecteurs à les choisir comme source préférée. C’est le lecteur qui fait ce choix : le balisage structuré ne peut pas le faire à sa place. Donnez aux lecteurs qui reviennent une identité de publication claire et un moyen simple de la sélectionner.

Un contrôle Discover pratique commence par le contenu lui-même : vérifiez la date visible, le sujet, la pertinence locale et la présence d’un reportage ou d’une analyse originale. Comparez ensuite le pays et la langue concernés avec le périmètre publié de la fonctionnalité. Si un site sert plusieurs marchés, n’utilisez pas une mise à jour en anglais américain pour expliquer chaque locale. Limitez les améliorations éditoriales au public qui peut réellement rencontrer cette surface.

Changement produit

Rapports IA : garder les surfaces séparées

En février, AI Performance de Bing a introduit un reporting orienté citations. Son extension de juin a ajouté Intents, Topics, Citation Share et Compare, dans la note de Bing qui fait suite. Ces rapports aident un propriétaire de site à comprendre comment les expériences IA de Bing citent ses pages. Ils ne remplacent ni les sessions, ni les positions dans Google, ni une mesure des AI Overviews. Leur question porte sur la visibilité par citation, dans la surface de reporting définie par Bing.

L’annonce de Google sur le reporting IA de Search Console de juin a introduit des vues dédiées aux impressions dans les fonctionnalités d’IA générative, sur Search et Discover. Ces impressions restent également incluses dans le rapport de performance global ; les vues dédiées n’ont d’abord été ouvertes qu’à un sous-ensemble de sites. Yandex a ajouté des données horaires de Query Monitoring, un type de rapport différent, consacré aux requêtes populaires. Séparez ces produits par plateforme, unité et fenêtre de reporting. Additionner clics, citations et valeurs horaires préliminaires brouillerait ce que chaque rapport mesure réellement.

zoom_in

Pour un tableau de bord, définissez la ligne avant d’exporter les données. Une ligne peut représenter les clics Search Console d’un groupe d’URL ; une autre, les citations Bing d’un sujet ; une troisième, des observations horaires de requêtes Yandex. Donnez à chaque ligne sa propre propriété ou son marché, sa plage de dates et son fuseau horaire. Cela évite de tracer une courbe lisse à partir de mesures qui n’ont jamais été conçues pour être additionnées.

Action

Traitement par le crawler et la limite de 2 Mo

L’explication de Google sur le crawler de mars a rendu opérationnelle une contrainte ancienne et facile à oublier : Googlebot traite une quantité limitée de contenu de réponse, avec une limite pratique de 2 Mo pour la réponse HTML. La leçon n’est pas de compter la taille du bundle et de s’arrêter là. Inspectez le statut réel, l’URL finale, le corps de la réponse, la balise canonical et le contenu critique présent dans le résultat après rendu. Si des instructions ou un contenu essentiels arrivent trop tard, une vue dans le navigateur sur une connexion rapide peut masquer la défaillance.

Pour une grande route JavaScript, prenez une URL type du groupe et sauvegardez les en-têtes de réponse et les octets bruts. Comparez ensuite ce qui arrive dans le HTML initial avec ce qui apparaît après rendu : contenu principal, balise canonical, directives robots, données structurées et liens vers les pages importantes suivantes. Sortez du chemin critique le contenu non essentiel lorsque les preuves le justifient, mais ne supprimez rien simplement pour respecter un nombre d’octets. Le critère d’acceptation : le sens requis de la page reste accessible et rendable dans les contraintes pratiques du crawler.

zoom_in

La limite de 2 Mo concerne surtout les gabarits qui envoient de gros volumes de données sérialisées, des données de navigation ou du balisage dupliqué avant leur contenu principal. Repérez le poids en octets dans le document renvoyé, et pas seulement dans les sorties de build JavaScript. Si la balise canonical ou le texte principal est fourni côté client après une longue chaîne de traitements, rendez cette dépendance explicite et testez-la avec les mêmes paramètres de route qu’un crawler peut demander.

Action

Politique spam et détournement du bouton Retour

La mise à jour spam de mars s’est déroulée du 24 au 25 mars. La core update de mars a commencé le 27 mars et s’est terminée en avril. Ces fenêtres doivent rester distinctes dans une investigation. Une page qui perd des clics sur l’une ou l’autre période peut avoir une rupture technique, une évolution de la demande, un problème de canonical, un changement chez un concurrent ou un problème de qualité plus large ; le calendrier ne permet pas de trancher entre ces causes.

Le 13 avril, Google a ajouté le détournement du bouton Retour comme violation explicite de sa politique spam, avec une application annoncée pour le 15 juin. Cette échéance doit figurer dans le calendrier de mise en production. Il s’agit d’un comportement concret du navigateur à auditer : après qu’un visiteur a suivi un résultat, le bouton Retour doit le ramener à la page précédente, et non le piéger dans une navigation inattendue. Testez-le dans une session de navigateur vierge, sur mobile comme sur ordinateur, puis inspectez les redirections, les manipulations de l’historique et les scripts injectés. Supprimez le mécanisme au lieu de le masquer par une modification superficielle de la page d’arrivée.

Le contraste entre le changement de politique et les fenêtres de mise à jour compte dans le tri. Le détournement du bouton Retour est un défaut d’interaction reproductible : son test a un résultat clair, réussi ou échoué. Un chevauchement avec une core update constitue un contexte d’investigation, qui demande des preuves segmentées. Gardez ces chantiers séparés  : corrigez directement une navigation trompeuse démontrable, et utilisez les données par requête et par page avant de décider si une révision plus large du contenu se justifie.

Action

Un plan de migration doit couvrir toutes les variantes d’hôte

Les consignes de juin sur les déménagements de site ont rendu explicites les conseils Change of Address pour toutes les variantes de domaine. Cela modifie l’inventaire de migration : l’hôte racine, l’hôte www et tout sous-domaine pertinent ont besoin d’une destination finale déclarée, et non d’une convention implicite. Une table de redirections qui ne couvre qu’un seul nom d’hôte préféré peut laisser exposées aux utilisateurs comme aux crawlers des variantes dupliquées, cassées ou non vérifiées.

Construisez le jeu de tests avant de basculer le trafic. Pour chaque ancienne URL encore active, notez l’URL finale prévue, une redirection permanente directe, le code de statut final, la balise canonical, l’appartenance au sitemap et le contenu critique après rendu. Rejouez ensuite le test sur chaque variante d’hôte publique. Mettez à jour les liens internes, les balises canonical et les sitemaps vers l’hôte final, sans compter sur des chaînes pour réparer d’anciennes conventions. Si une URL n’a pas de successeur pertinent, renvoyez la réponse d’erreur « non trouvé » adaptée plutôt que de rediriger vers la page d’accueil.

Le contrôle des variantes d’hôte doit inclure le protocole, pas seulement le nom d’hôte : racine en HTTP, racine en HTTPS, www en HTTP et www en HTTPS, lorsque ces variantes répondent publiquement. Une migration échoue souvent aux limites : une image ou une cible hreflang peut conserver un ancien hôte, ou un sous-domaine historique peut contourner une redirection. Un petit mapping lisible par une machine, complété par des contrôles dans le navigateur, donne aux crawlers comme aux personnes une seule destination finale.

Changement produit

Fin des résultats enrichis FAQ et évolution ciblée des données produit

En mai, deux décisions de maintenance des données structurées très différentes ont été prises. Google a cessé d’afficher les résultats enrichis FAQ à partir du 7 mai, comme l’indiquent ses mises à jour de la documentation. Une FAQ visible peut toujours répondre à la question d’un client, mais un balisage valide n’implique plus que cette apparence précise dans Search sera affichée. Gardez les questions destinées aux lecteurs là où elles sont utiles ; ne supprimez l’implémentation réservée à la fonctionnalité qu’après avoir vérifié les dépendances aux gabarits, aux analyses et à l’accessibilité.

Les mêmes mises à jour de mai ont ajouté hasAdultConsideration à la documentation produit et marchand. Il s’agit d’un champ au périmètre étroit, destiné aux fiches où le fait est exact et représenté fidèlement. Ce n’est pas une amélioration générique du flux produit, et il ne faut pas l’insérer pour viser une fonctionnalité. La règle générale : conservez les données sémantiques qui correspondent à la page visible, validez le graphe et le consommateur cible séparément, et abandonnez les promesses concernant une apparence que le produit n’offre plus.

Pour une FAQ, testez les questions visibles sur ordinateur et sur mobile, puis demandez-vous si chaque réponse répond à une vraie question d’avant achat ou de support. Si oui, le contenu peut rester, même sans l’incitation des résultats enrichis. Pour hasAdultConsideration, exigez une source factuelle dans la fiche catalogue et une présentation visible lorsque c’est pertinent. Cela évite de traiter une propriété de type conformité comme un signal SEO spéculatif.

Action

Contrôles précis pour la prochaine revue

La prochaine revue doit produire une fiche de preuves par surface, et non un score global unique. Pour la découverte, notez le pays, la langue, le format et le rapport produit concerné. Pour la visibilité IA, conservez la plateforme, le nom du rapport, les dates, l’unité et l’attribution. Pour le travail de crawl, conservez les en-têtes de réponse, la taille du corps, le contenu critique après rendu, l’état de la balise canonical et des directives robots. Pour les migrations, conservez chaque hôte d’entrée et chaque correspondance de route. Pour les données structurées, conservez le fait visible, la validation du graphe et la politique actuelle de la fonctionnalité. Ces enregistrements permettent d’expliquer un changement ultérieur sans inventer une cause.

• Pour Discover, comparez le pays et le format de contenu concernés avec le périmètre documenté du produit avant de modifier les gabarits éditoriaux.
• Pour les rapports de Google, Bing et Yandex, conservez des tableaux séparés ; n’additionnez jamais les citations, les clics Search Console et les observations horaires de requêtes.
• Pour une route lourde, capturez la taille brute de la réponse et le contenu critique après rendu, avant et après toute modification de performance.
• Pour une migration, testez la racine, le www et chaque sous-domaine public par rapport à la table de redirections, aux balises canonical, au sitemap et à une page après rendu.
• Pour les données structurées, distinguez les informations visibles qui restent utiles d’un format de résultat enrichi que Google a retiré.
• Pour toute fenêtre de déploiement, examinez les preuves par requête, par page de destination et techniques avant d’attribuer une cause à une mise à jour.