Faut-il supprimer les données structurées Sitelink Search Box maintenant que Google les ignore ?

Qu'est-ce que la search box pour sitelinks et pourquoi Google l'abandonne ?

La search box pour sitelinks permettait aux utilisateurs de lancer une recherche directement depuis les résultats Google, via un champ de saisie affiché sous certains résultats organiques. Cette fonctionnalité s'appuyait sur le balisage Schema.org SearchAction, une donnée structurée que les webmasters implémentaient pour signaler à Google l'URL de leur moteur de recherche interne.

Google ne justifie pas publiquement ce retrait. L'hypothèse la plus probable ? Un taux d'utilisation trop faible pour justifier la maintenance technique et l'espace écran occupé dans les SERP. Les sitelinks classiques restent en place — seul le module de recherche disparaît.

Cette suppression impacte-t-elle le référencement des sites concernés ?

Non. Ce changement est purement cosmétique côté SERP et n'affecte ni le crawl, ni l'indexation, ni le classement. Les sites qui affichaient cette search box ne perdent aucun avantage SEO — parce qu'il n'y en avait pas vraiment au départ.

Le véritable intérêt du balisage SearchAction était l'expérience utilisateur : faciliter l'accès rapide à la recherche interne depuis Google. Maintenant que cette passerelle n'existe plus, le Schema perd son utilité fonctionnelle sans devenir pénalisant pour autant.

Que deviennent les données structurées déjà en place ?

Google ne les exploite plus, mais tolère leur présence. John Mueller précise explicitement qu'il n'est pas nécessaire de les supprimer. Elles ne déclenchent aucune erreur dans Search Console, n'alourdissent pas le temps de traitement HTML de manière significative, et restent invisibles pour l'utilisateur final.

En pratique, cela signifie : pas d'urgence technique. Si votre équipe dev a d'autres priorités, ce nettoyage peut attendre — ou même être ignoré indéfiniment si le code ne vous gêne pas.

• La search box pour sitelinks a été retirée des SERP sans préavis ni justification détaillée
• Le balisage SearchAction n'est plus interprété par Google mais reste techniquement valide
• Aucun impact négatif sur le SEO si vous conservez ces données structurées
• Les sitelinks classiques continuent de fonctionner normalement
• Pas de migration technique urgente à planifier

Cette décision est-elle cohérente avec la stratégie produit de Google ?

Absolument. Google supprime régulièrement des fonctionnalités SERP à faible adoption — souvenez-vous des Google Posts ou des Q&A enrichis. La search box pour sitelinks était peu visible (réservée aux requêtes de marque fortes) et peu utilisée (les internautes préfèrent cliquer sur un sitelink direct plutôt que reformuler une requête).

Ce qui est plus surprenant, c'est l'absence totale de communication préalable. Aucun avertissement dans Search Console, aucune dépréciation progressive — juste un retrait silencieux. Cela confirme une tendance : Google ne traite plus les données structurées comme des contrats stables, mais comme des signaux optionnels qu'il active ou désactive selon ses propres priorités produit.

Faut-il quand même nettoyer ces données structurées obsolètes ?

Soyons pragmatiques. Si votre site gère des milliers de templates et que le balisage SearchAction est injecté dynamiquement partout, le ROI d'un nettoyage est quasi nul. Aucun gain SEO, aucun gain de performance mesurable, juste de la dette technique en moins.

En revanche, si vous refondez votre système de templating ou si vous auditez vos données structurées pour une raison stratégique (préparation SGE, optimisation des rich snippets actifs), alors oui — profitez-en pour supprimer ce code mort. Mais ce n'est jamais une priorité 1.

Quelles leçons tirer pour l'implémentation future de données structurées ?

Première leçon : n'investissez jamais massivement sur une fonctionnalité SERP non documentée comme "ranking factor". Les données structurées servent avant tout à améliorer l'affichage dans les résultats — et cet affichage reste à la discrétion totale de Google.

Deuxième leçon : privilégiez les Schema.org qui servent plusieurs moteurs de recherche (Bing, Yandex) ou d'autres usages (crawlers IA, assistants vocaux). Le SearchAction n'était exploité que par Google — d'où sa fragilité. Les balises Organization, Product, Review ou FAQPage ont une portée plus large et donc une durée de vie plus prévisible.

Que faire concrètement avec le balisage SearchAction existant ?

Rien d'urgent. Si vos données structurées sont déjà en place et ne génèrent pas d'erreurs dans Search Console, laissez-les. Elles n'interfèrent avec aucun autre traitement Google et n'alourdissent pas significativement vos pages.

Si vous souhaitez nettoyer par souci d'hygiène technique — parce que votre équipe maintient un référentiel strict des Schema actifs — alors planifiez ce chantier en priorité basse, après les optimisations qui impactent réellement le trafic ou les conversions.

Comment vérifier si mon site utilisait cette fonctionnalité ?

Deux méthodes simples. Première option : inspectez le code source de votre page d'accueil et cherchez "@type": "SearchAction" ou "potentialAction" dans vos blocs JSON-LD. Si vous trouvez ces mentions, c'est que le balisage est présent.

Seconde option : utilisez l'outil Test des résultats enrichis de Google Search Console. Collez l'URL de votre homepage — s'il détecte un Schema SearchAction, il l'affichera dans la liste des types reconnus (même si Google ne l'exploite plus).

Quelles erreurs éviter lors du nettoyage éventuel ?

Si vous décidez de supprimer le balisage, ne touchez jamais aux autres propriétés de votre Schema Organization ou WebSite. Le SearchAction est souvent imbriqué dans un objet WebSite — retirez uniquement la clé potentialAction, pas le reste.

Testez toujours après modification. Un JSON-LD mal refermé (accolade manquante, virgule en trop) peut invalider toutes vos données structurées et faire disparaître d'autres rich snippets fonctionnels. Validez avec l'outil Schema Markup Validator avant de pousser en production.

• Vérifier la présence de SearchAction dans vos templates HTML via grep ou inspection manuelle
• Évaluer le coût technique de suppression : nombre de templates concernés, risque de régression
• Prioriser ce nettoyage après les chantiers à impact SEO direct (Core Web Vitals, maillage, contenu)
• Si suppression : retirer uniquement la clé potentialAction, conserver le reste du Schema WebSite
• Valider le JSON-LD modifié avec Schema.org Validator + Google Rich Results Test
• Monitorer Search Console pendant 2 semaines post-déploiement pour détecter toute erreur imprévue