Back Button Hijacking : Google en fait une violation spam

Google vient d'ajouter le back button hijacking à sa liste officielle de violations spam. Ce n'est pas un simple ajustement de wording dans la documentation — c'est un signal que les rapports de spam utilisateurs peuvent désormais déclencher des actions manuelles contre les sites qui manipulent le bouton retour du navigateur. En parallèle, Google étend sa fonctionnalité de réservation de restaurants via l'agentic search à de nouveaux marchés, confirmant l'accélération de la recherche agentique.

Le back button hijacking : anatomie technique d'une manipulation

Le back button hijacking exploite l'API History du navigateur pour piéger l'utilisateur dans une boucle. Quand l'utilisateur clique sur le bouton retour, au lieu de revenir à la page précédente (typiquement la SERP Google), il reste sur le même site ou atterrit sur une page interstitielle.

Comment ça fonctionne concrètement

Le mécanisme repose sur history.pushState() ou history.replaceState(). Le script injecte des entrées fantômes dans l'historique du navigateur à l'arrivée de l'utilisateur, de sorte que le bouton retour consomme ces entrées fictives au lieu de ramener l'utilisateur à sa page d'origine.

Voici un exemple simplifié du pattern le plus courant :

// Pattern de back button hijacking — NE PAS IMPLÉMENTER
// Injecte des entrées dans l'historique dès le chargement de la page
(function() {
  // Pousse plusieurs états dans l'historique
  for (let i = 0; i < 5; i++) {
    history.pushState(
      { hijack: true, index: i },
      '',
      window.location.href + '#stay-' + i
    );
  }

  // Intercepte l'événement popstate (déclenché par le bouton retour)
  window.addEventListener('popstate', function(event) {
    if (event.state && event.state.hijack) {
      // Redirige vers une page monétisée au lieu de laisser
      // l'utilisateur revenir en arrière
      window.location.href = '/offre-speciale?ref=back';
    }
  });
})();

Une variante plus sophistiquée utilise replaceState combiné avec un beforeunload pour rendre la sortie encore plus difficile :

// Variante avec replaceState — également considérée comme spam
window.addEventListener('load', function() {
  // Remplace l'état actuel pour contrôler le point de retour
  history.replaceState({ trapped: true }, '', window.location.href);
  history.pushState({ trapped: true }, '', window.location.href);

  window.addEventListener('popstate', function() {
    // Re-pousse un état à chaque tentative de retour
    history.pushState({ trapped: true }, '', window.location.href);

    // Affiche un overlay "Attendez, voici une offre..."
    document.getElementById('exit-intent-overlay').style.display = 'block';
  });
});

Pourquoi Google agit maintenant

Ce type de manipulation existe depuis plus d'une décennie. Les sites de couponing, les comparateurs agressifs et certains éditeurs de contenu viral l'utilisaient pour gonfler artificiellement le temps passé sur le site et les pages vues par session — deux métriques qui influencent les revenus publicitaires.

Le timing de cette classification comme violation spam n'est pas anodin. Google dispose désormais de données comportementales plus granulaires via Chrome (Chrome User Experience Report, interactions signals). Un utilisateur qui clique 4 ou 5 fois sur le bouton retour sans jamais quitter un site génère un pattern de frustration détectable côté navigateur. Ce signal, agrégé à l'échelle de Chrome, donne à Google une vue directe sur les sites qui piègent les utilisateurs.

La documentation mise à jour de Google sur les spam policies inclut désormais explicitement cette pratique aux côtés du cloaking, des doorway pages et du link spam.

Détecter le back button hijacking sur vos propriétés

Même si vous n'implémentez pas volontairement ce pattern, des scripts tiers (ad networks, widgets, analytics exotiques) peuvent l'introduire à votre insu. Un tag manager mal configuré qui charge un script d'un partenaire peu scrupuleux suffit.

Audit via Chrome DevTools

Ouvrez les DevTools (F12), onglet Sources, puis filtrez les event listeners sur popstate :

Naviguez sur la page suspecte
Ouvrez la console DevTools
Exécutez ce snippet de diagnostic :

// Diagnostic : détecter les manipulations de l'historique
(function detectHistoryHijack() {
  const originalPushState = history.pushState;
  const originalReplaceState = history.replaceState;
  let pushCount = 0;
  let replaceCount = 0;

  history.pushState = function() {
    pushCount++;
    console.warn(
      `[HISTORY AUDIT] pushState appelé (total: ${pushCount})`,
      '\nArguments:', arguments,
      '\nStack:', new Error().stack
    );
    return originalPushState.apply(this, arguments);
  };

  history.replaceState = function() {
    replaceCount++;
    console.warn(
      `[HISTORY AUDIT] replaceState appelé (total: ${replaceCount})`,
      '\nArguments:', arguments,
      '\nStack:', new Error().stack
    );
    return originalReplaceState.apply(this, arguments);
  };

  // Vérifie aussi les listeners popstate existants
  const listeners = getEventListeners(window);
  if (listeners.popstate && listeners.popstate.length > 0) {
    console.warn(
      `[HISTORY AUDIT] ${listeners.popstate.length} listener(s) popstate détecté(s):`,
      listeners.popstate.map(l => l.listener.toString().substring(0, 200))
    );
  }

  console.log('[HISTORY AUDIT] Monitoring activé. Naviguez normalement.');
})();

Ce script monkey-patche pushState et replaceState pour logger chaque appel avec sa stack trace. Vous identifiez immédiatement quel script est responsable.

Audit à l'échelle avec Puppeteer

Pour un site e-commerce de 15 000 pages, l'audit manuel ne passe pas à l'échelle. Voici un script Puppeteer qui crawle un échantillon de pages et détecte les manipulations d'historique automatiquement :

// audit-history-hijack.mjs
import puppeteer from 'puppeteer';

const URLS_TO_TEST = [
  'https://shop.example.fr/categorie/chaussures',
  'https://shop.example.fr/produit/nike-air-max-90',
  'https://shop.example.fr/promo/soldes-ete',
  // ... charger depuis un sitemap ou un export Screaming Frog
];

async function auditPage(browser, url) {
  const page = await browser.newPage();
  const historyEvents = [];

  // Injecte le monitoring avant tout script de la page
  await page.evaluateOnNewDocument(() => {
    const orig = history.pushState.bind(history);
    let count = 0;
    history.pushState = function(...args) {
      count++;
      window.__historyPushCount = count;
      window.__lastPushStack = new Error().stack;
      return orig(...args);
    };
  });

  await page.goto(url, { waitUntil: 'networkidle2', timeout: 15000 });
  // Attendre 3 secondes pour les scripts lazy
  await new Promise(r => setTimeout(r, 3000));

  const pushCount = await page.evaluate(() => window.__historyPushCount || 0);
  const hasPopstateListener = await page.evaluate(() => {
    // Heuristique : tenter un back et voir si l'URL change
    return new Promise(resolve => {
      const originalHref = window.location.href;
      window.addEventListener('popstate', () => {
        resolve(window.location.href === originalHref);
      }, { once: true });
      history.back();
      setTimeout(() => resolve(false), 1000);
    });
  });

  const result = {
    url,
    pushStateCallsOnLoad: pushCount,
    possibleHijack: pushCount > 2 || hasPopstateListener,
  };

  await page.close();
  return result;
}

(async () => {
  const browser = await puppeteer.launch({ headless: 'new' });
  const results = [];

  for (const url of URLS_TO_TEST) {
    try {
      const result = await auditPage(browser, url);
      results.push(result);
      if (result.possibleHijack) {
        console.error(`⚠️  SUSPECT: ${url} (${result.pushStateCallsOnLoad} pushState calls)`);
      }
    } catch (e) {
      console.error(`Erreur sur ${url}: ${e.message}`);
    }
  }

  await browser.close();

  const suspects = results.filter(r => r.possibleHijack);
  console.log(`\nAudit terminé: ${suspects.length}/${results.length} pages suspectes`);
  console.log(JSON.stringify(suspects, null, 2));
})();

Ce que Screaming Frog ne voit pas

Screaming Frog crawle en mode headless et n'exécute pas JavaScript par défaut. Même en activant le rendering JavaScript, il ne simule pas le bouton retour. C'est un angle mort classique : un crawl technique standard ne détectera jamais le back button hijacking. Vous avez besoin d'un audit comportemental, pas d'un crawl structurel.

C'est exactement le type de régression qu'un outil de monitoring continu comme Seogard peut capturer. Un script tiers ajouté mardi qui injecte des pushState sera détecté lors du prochain scan de rendering, avant qu'un utilisateur ne soumette un rapport de spam à Google.

Spam reports et manual actions : le mécanisme de sanction

Google précise que les rapports de spam soumis par les utilisateurs via le formulaire dédié peuvent désormais déclencher des actions manuelles contre les sites identifiés comme pratiquant le back button hijacking.

La chaîne de conséquences

Le processus est le suivant :

Un utilisateur expérimente le piège du bouton retour
Il soumet un spam report via le formulaire Google
L'équipe webspam de Google examine le site
Si confirmé, une manual action est appliquée dans Search Console
Les pages affectées (ou le site entier) sont déclassées ou désindexées

La différence avec une action algorithmique est capitale : une manual action nécessite une demande de réexamen manuelle après correction. Le délai moyen de traitement d'une demande de réexamen varie de quelques jours à plusieurs semaines. Pendant ce temps, le trafic organique chute.

Scénario concret : un comparateur d'assurances

Prenons un comparateur d'assurances avec 8 000 pages indexées qui génère 45 000 visites organiques mensuelles. Un partenaire publicitaire fournit un script "d'engagement" qui, en réalité, injecte 3 pushState à chaque page vue et redirige les utilisateurs vers une landing page de conversion quand ils tentent de revenir en arrière.

Le site reçoit une manual action type "user experience violations" dans Search Console. Le trafic organique chute de 70% en 48 heures. L'équipe SEO met 4 jours à identifier le script responsable (il est obfusqué et chargé via un tag manager côté partenaire), 2 jours à le retirer et redéployer, puis 12 jours à obtenir la levée de la manual action après soumission de la demande de réexamen.

Bilan : 18 jours de trafic dégradé, soit environ 27 000 visites organiques perdues. À un CPC moyen de 2,80€ dans le secteur assurance, c'est l'équivalent de 75 600€ de trafic SEO évaporé.

Vérifier l'absence de manual action

Dans Google Search Console, naviguez vers Sécurité et actions manuelles > Actions manuelles. Si le champ affiche "Aucun problème détecté", vous êtes clean. Mais ne vous arrêtez pas là — vérifiez aussi l'onglet Problèmes de sécurité qui peut signaler des scripts injectés par des tiers compromis.

L'agentic search s'étend : ce que ça change pour le SEO technique

En parallèle de l'annonce sur le back button hijacking, Google étend sa fonctionnalité de réservation de restaurants via l'agentic search à de nouveaux marchés. L'agent AI de Google peut désormais effectuer une réservation complète — choix du restaurant, sélection du créneau, confirmation — sans que l'utilisateur ne quitte l'interface de recherche.

Du lien bleu à l'action complétée

Ce n'est plus de la recherche au sens classique. L'utilisateur ne visite plus le site du restaurant. L'agent interagit directement avec les API de réservation (OpenTable, TheFork, systèmes propriétaires) pour accomplir la tâche.

Les implications SEO sont profondes : si l'agent peut accomplir la tâche sans envoyer l'utilisateur sur votre site, le trafic organique de l'étape "recherche d'information" disparaît. Vous devez être la source de données que l'agent consomme, pas la page que l'utilisateur visite.

Nous avons déjà analysé cette tendance dans notre article sur l'agentic search et le nouveau playbook SEO, ainsi que dans notre analyse sur la recherche agentique qui disrupte le SEO aujourd'hui.

Structured data : le ticket d'entrée pour l'agentic search

Pour qu'un agent AI puisse interagir avec votre contenu, vos données doivent être structurées et accessibles via des formats machine-readable. Dans le cas de la restauration, c'est le schema Restaurant combiné avec FoodEstablishmentReservation :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Le Comptoir du Marais",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "42 Rue des Archives",
    "addressLocality": "Paris",
    "postalCode": "75004",
    "addressCountry": "FR"
  },
  "servesCuisine": "Cuisine française contemporaine",
  "priceRange": "€€€",
  "acceptsReservations": true,
  "potentialAction": {
    "@type": "ReserveAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://lecomptoirdumarais.fr/reservation?date={date}&partySize={partySize}",
      "actionPlatform": [
        "http://schema.org/DesktopWebPlatform",
        "http://schema.org/MobileWebPlatform"
      ]
    },
    "result": {
      "@type": "FoodEstablishmentReservation",
      "name": "Réservation au Comptoir du Marais"
    }
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
      "opens": "12:00",
      "closes": "14:30"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
      "opens": "19:00",
      "closes": "22:30"
    }
  ]
}
</script>

Le potentialAction de type ReserveAction est le point critique : c'est ce qui permet à l'agent de déclencher une action concrète. Sans ce markup, votre restaurant existe dans le knowledge graph mais n'est pas "actionable" par l'agent.

Au-delà de la restauration

L'extension de l'agentic search à la réservation de restaurants n'est que la partie visible. Le pattern se généralise à tous les secteurs transactionnels : réservation d'hôtels, prise de rendez-vous médicaux, achat de billets, souscription d'abonnements.

Pour les sites e-commerce et SaaS, la question devient : votre site est-il conçu pour être consommé par des agents ? Notre analyse sur comment les agents AI voient votre site et sur l'architecture machine-first détaille les adaptations techniques nécessaires.

Intersection des deux annonces : la cohérence de la stratégie Google

Ces deux annonces — la classification du back button hijacking comme spam et l'expansion de l'agentic search — ne sont pas des nouvelles isolées. Elles dessinent une même direction.

Google protège la boucle de confiance

L'agentic search ne fonctionne que si les utilisateurs font confiance à Google pour exécuter des actions en leur nom. Si un agent réserve un restaurant et que l'utilisateur se retrouve piégé sur un site qui manipule sa navigation, la confiance dans l'ensemble du système s'effondre.

En éliminant les sites qui dégradent l'expérience utilisateur au niveau de la navigation, Google assainit l'écosystème pour rendre l'agentic search viable. Les sites qui jouent le jeu — contenu structuré, navigation clean, données fiables — deviennent les fournisseurs privilégiés de l'agent.

Le crawl des agents AI et la qualité du site

Les bots AI qui crawlent votre site pour alimenter les réponses agentiques évaluent la qualité technique globale. Un site qui manipule l'historique du navigateur envoie un signal négatif qui dépasse le cadre du spam classique — il remet en question la fiabilité des données que le site fournit.

Nous avons documenté comment les bots IA crawlent les sites dans notre analyse sur le comportement des crawlers AI. La synergie entre qualité technique et visibilité dans les réponses agentiques se renforce.

Plan d'action : audit et prévention

1. Audit immédiat des scripts tiers

Listez tous les scripts tiers chargés sur votre site via le tag manager. Pour chacun, vérifiez s'il accède à l'API History :

# Extraire tous les scripts inline et externes d'une page
curl -s https://shop.example.fr/ | \
  grep -oP '(?<=src=")[^"]+\.js' | \
  while read script; do
    echo "=== Vérification: $script ==="
    curl -s "$script" | grep -n 'pushState\|replaceState\|popstate' || echo "  Clean"
  done

Ce script Bash télécharge chaque fichier JavaScript référencé sur la page et recherche les appels à pushState, replaceState et les listeners popstate. C'est un premier filtre grossier — un résultat positif nécessite une analyse manuelle pour distinguer un usage légitime (SPA routing) d'un hijacking.

2. Distinguer usage légitime et abusif

L'API History est parfaitement légitime pour le routing côté client dans les SPA (React Router, Vue Router, etc.). La différence :

Légitime : pushState est appelé en réponse à une action utilisateur (clic sur un lien interne) et l'URL change effectivement
Abusif : pushState est appelé automatiquement au chargement de la page, souvent plusieurs fois, sans changement d'URL réel ou avec des fragments/hash artificiels

Le critère simple : si votre pushState est dans un DOMContentLoaded ou un load event sans interaction utilisateur préalable, c'est un red flag.

3. Content Security Policy comme garde-fou

Une CSP stricte peut empêcher les scripts tiers non autorisés d'accéder à l'API History :

# Configuration Nginx — CSP stricte avec reporting
add_header Content-Security-Policy "
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://cdn.trusted-partner.com;
  report-uri /csp-violation-report;
  report-to csp-endpoint;
" always;

# Endpoint de reporting pour surveiller les violations
add_header Report-To '{
  "group": "csp-endpoint",
  "max_age": 86400,
  "endpoints": [{"url": "https://shop.example.fr/csp-violation-report"}]
}' always;

En limitant script-src aux domaines de confiance, vous bloquez l'exécution de scripts tiers non autorisés. Le report-uri vous alerte quand un script bloqué tente de s'exécuter — ce qui peut révéler une injection ou un tag manager compromis.

4. Monitoring continu

Le back button hijacking peut apparaître du jour au lendemain via une mise à jour de script tiers. Un audit ponctuel ne suffit pas. Intégrez la vérification de l'API History dans votre pipeline de monitoring SEO technique. Un outil comme Seogard qui scanne le comportement JavaScript en continu détectera l'apparition de pushState non légitime avant que Google ne reçoive un spam report.

5. Préparer votre site pour l'agentic search

En parallèle de la correction des problèmes de navigation :

Auditez vos structured data avec le test de résultats enrichis de Google
Implémentez les potentialAction pertinents pour votre secteur
Assurez-vous que votre contenu est accessible sans JavaScript pour les crawlers — voir notre article sur le rendering budget de Google
Exposez vos données via des formats structurés que les agents peuvent consommer programmatiquement

L'évolution vers l'agentic search impacte aussi votre stratégie de visibilité locale, comme nous l'avons analysé dans pourquoi votre site est la source de vérité pour la recherche AI locale.

Ce qu'il faut retenir

Le back button hijacking rejoint la liste des manipulations qui déclenchent des manual actions. Si vous chargez des scripts tiers — et tous les sites en chargent — auditez-les maintenant, pas après avoir reçu la notification dans Search Console. En parallèle, l'agentic search de Google passe de l'expérimentation à l'expansion géographique : les sites qui structurent leurs données pour être actionnables par des agents prennent un avantage concurrentiel durable. Les deux annonces pointent dans la même direction — Google récompense les sites techniquement irréprochables et pénalise ceux qui sacrifient l'expérience utilisateur pour des métriques artificielles.