Langues

Guide SEO de Cloudflare Workers

Mettre en œuvre le SEO technique avec Cloudflare Workers : gestionnaire fetch, injections HTMLRewriter, redirections KV, couches de cache, cloaking et risques de Bot Fight Mode pour Googlebot.

Première publication : 3 juil. 2026 · Dernière mise à jour : 11 août 2026 · Advanced
Langues
AIRédigé parAI v2
1 indice probant sur cette page

Cloudflare Workers permet de modifier requêtes, en-têtes et HTML au niveau edge. HTMLRewriter doit rester idempotent ; KV, D1 ou Rules gèrent les redirections selon leur complexité. Distinguez API Cache, cache edge et Cache-Control. Appliquez une logique identique à Googlebot et aux visiteurs, surveillez Bot Fight Mode, puis vérifiez chaque livraison avec l’inspection d’URL et CF-Cache-Status.

En bref — Un Worker ne voit que les requêtes correspondant à sa route. Son gestionnaire fetch peut successivement réécrire la requête, les en-têtes de réponse et le corps via HTMLRewriter. Toute injection doit être idempotente et testée sur les réponses absentes, dupliquées et non HTML. Pour les redirections, KV convient aux recherches rapides et D1 aux relations ; Rules ou Bulk Redirects suffisent aux petits jeux. Donnez un seul propriétaire à chaque URL. Distinguez l’API Cache Workers, le cache edge et Cache-Control d’origine ; diagnostiquez clé, couche, TTL et invalidation. Les recommandations Google sur ETag, If-None-Match et les réponses 304 sont directement applicables. Servez la même logique à tous. Bot Fight Mode échappe au moteur de règles WAF, donc une règle d’autorisation classique ne le neutralise pas. Livrez chaque changement avec version, retour arrière et condition d’arrêt, puis vérifiez avec l’inspection d’URL et CF-Cache-Status.

Portée de cet article

Ce guide pratique complète le dossier Edge SEO, qui couvre définition générale, comparaison des plateformes, choix Snippets ou Workers et cloaking. Ici, nous approfondissons Cloudflare Workers, environnement utilisé par ce site via run_worker_first dans wrangler.toml, avec ses API réelles.

Google ne publie aucune documentation propre à Cloudflare Workers. Ses règles sur le cloaking, le cache HTTP et l’exploration des CDN sont générales et s’appliquent à toute mise en œuvre edge.

Place du Worker dans le trajet requête-réponse

Cloudflare exécute chaque Worker comme script serverless dans l’isolate V8. Toute requête couverte rejoint le gestionnaire fetch. Evidence for this claim A Cloudflare Worker receives HTTP requests through a fetch handler. Scope: Cloudflare Workers handlers. Confidence: high · Verified: Cloudflare Workers: Fetch handler Seules les URL correspondant à la route ou au domaine personnalisé l’atteignent. Le motif le plus précis prime lors d’un chevauchement. Vérifiez la route et la version active : les environnements Wrangler et les déploiements progressifs peuvent différer du code affiché. Le gestionnaire effectue trois opérations distinctes :

  1. Réécrire la requête avant l’origine.
  2. Réécrire les en-têtes de réponse au retour.
  3. Réécrire le corps avec HTMLRewriter.

Forme minimale :

export default {
  async fetch(request, env, ctx) {
    // 1. (optionally) inspect/modify the request
    const response = await fetch(request);   // hit the origin

    // 2. rewrite headers
    const headers = new Headers(response.headers);
    headers.set("X-Robots-Tag", "index, follow");

    // 3. rewrite the body with HTMLRewriter (see next section)
    return new Response(response.body, { ...response, headers });
  },
};

SALT.agency, à l’origine du terme Edge SEO dans ses recherches sur Workers, organise ses outils en trois filtres : requête, réponse et corps. Séparer mentalement ces phases maintient le code lisible.

Réécrire le HTML avec HTMLRewriter

HTMLRewriter est l’analyseur HTML en flux de Cloudflare, au cœur des injections de balises. Evidence for this claim Cloudflare HTMLRewriter provides selector-based handlers that can transform streamed HTML elements. Scope: Cloudflare Workers HTMLRewriter API. Confidence: high · Verified: Cloudflare Workers: HTMLRewriter On associe .on(selector, handler) à un gestionnaire disposant de getAttribute, setAttribute, prepend, append, setInnerContent et replace. Le flux évite de charger tout le document en mémoire.

Injecter ou corriger un canonique

class CanonicalHandler {
  constructor(url) { this.url = url; }
  element(el) { el.setAttribute("href", this.url); }
}

const rewriter = new HTMLRewriter()
  .on('link[rel="canonical"]', new CanonicalHandler("https://example.com/preferred/"));

return rewriter.transform(response);

Si aucun canonique n’existe, associez un gestionnaire à head et utilisez append. Dans tous les cas, rel=canonical reste un indice, pas une commande : le Worker l’harmonise, mais Google décide encore. Voir la canonisation. Une balise link[rel="canonical"] doit rester exacte et unique.

CanonicalHandler suppose à tort que la balise existe et que la réponse est HTML. Une réécriture de production doit être idempotente et couvrir :

  • Canonique absent : détecter le cas et l’ajouter à head.
  • Canonique dupliqué ou mal formé : retirer l’intrus au lieu d’en créer un second.
  • Réponse non HTML : ne pas transmettre API, image ou redirection à HTMLRewriter.
  • Transformation exécutée deux fois : un nouvel essai ou fetch imbriqué ne doit pas ajouter une seconde balise.

Ajouter ou corriger les variantes hreflang

Le mécanisme est identique et piloté par la configuration : ajoutez un link[rel="alternate"] par langue dans head. D1 convient aux relations entre langues ; KV à une table plate. L’injection doit rester identique pour tous les demandeurs, sans branchement sur User-Agent.

Injecter des données structurées JSON-LD

new HTMLRewriter().on("head", {
  element(head) {
    head.append(
      `<script type="application/ld+json">${JSON.stringify(schema)}</script>`,
      { html: true }
    );
  },
});

Limites CPU à grande échelle

Contrairement à la promesse « moins d’une milliseconde sans contrainte », la limite réelle est le CPU : 10 ms sur l’offre gratuite et 30 ms sur l’offre payante. L’attente de fetch ne compte pas, le calcul oui. Une réécriture courante reste légère, mais les gros passages HTMLRewriter doivent intégrer cette contrainte.

Redirections edge : KV, D1 ou Rules

Je préfère généralement les redirections au niveau CDN : elles déchargent l’origine et s’appliquent avant la génération. Dans mon guide Ahrefs des redirections SEO, j’énumère redirections unitaires ou en masse, Redirect Rules, Page Rules, Workers avec paires clé-valeur ou modification d’en-têtes.

Pour une table pilotée par Worker, KV constitue le choix naturel : recherche rapide, cohérence éventuelle et clé URL.

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const target = await env.REDIRECTS.get(url.pathname);   // KV namespace
    if (target) return Response.redirect(target, 301);
    return fetch(request);
  },
};

Choisissez D1 pour des relations SQL par langue ou segment. Pour quelques redirections statiques, Bulk Redirects ou Redirect Rules sont plus simples. Un Worker KV pour cinquante lignes serait superflu.

Attribuez un seul propriétaire à chaque URL. Worker, Bulk Redirect, Redirect Rule et origine peuvent tous s’appliquer au même chemin, rendant l’ordre difficile à déboguer. Recherchez d’abord les règles existantes, puis choisissez selon complexité, volume et responsable du suivi ou du retour arrière. Le Worker vit dans le code et les journaux ; les règles du tableau de bord sont plus faciles à examiner sans développement.

Cache : trois réalités sous un même nom

C’est la principale source de « ma modification n’apparaît pas ». Trois couches distinctes sont appelées cache :

  • API Cache Workers : caches.default et caches.open(), cache programmable du Worker.
  • Cache edge Cloudflare : cache CDN qui sert les ressources, distinct de l’API Cache.
  • Cache-Control d’origine : en-têtes de l’origine ou du Worker influençant les deux couches et Googlebot.

Les confondre fait prendre une réponse ancienne pour un échec de déploiement.

Si une modification n’apparaît pas, diagnostiquez chaque couche :

  1. Clé de cache. Identifiez URL, en-têtes ou cookies qui distinguent les entrées. Une variante non incluse dans la clé peut servir la mauvaise réponse.
  2. Couche ayant répondu. Consultez CF-Cache-Status : HIT, MISS, EXPIRED ou DYNAMIC.
  3. Emplacement et état. Le cache est distribué ; purge et déploiement n’atteignent pas toujours tout instantanément.
  4. TTL et règle responsable. Distinguez Cache Rule, Cache-Control d’origine et en-tête Worker.
  5. Invalidation. Une entrée caches.default exige son propre delete() ; purger le CDN ne la supprime pas.

Comportement de Googlebot avec ETag, If-None-Match et 304

Quand le Worker produit ou réécrit la réponse, il contrôle les en-têtes. Publiées en décembre 2024, les recommandations Google s’appliquent au cache heuristique avec ETag/If-None-Match et Last-Modified/If-Modified-Since. Google recommande fortement ETag. Si l’ETag correspond, renvoyez 304 Not Modified sans corps. Le Worker peut calculer l’ETag, le comparer à If-None-Match et répondre directement en 304, économisant du calcul.

Compromis de réexploration avec max-age

Google conseille aussi Cache-Control: max-age pour guider la réexploration. Sur un HTML réécrit, une valeur agressive peut retarder la découverte des balises tout juste modifiées. N’appliquez pas une longue durée sans suivi.

Frontière du cloaking appliquée aux Workers

Règle absolue : exécutez la même logique pour tous. Google définit le cloaking comme la présentation de contenus différents aux utilisateurs et aux moteurs pour manipuler les classements, notamment l’insertion de texte seulement pour le robot.

Deux précisions évitent de surcorriger :

  • Lire User-Agent n’est pas automatiquement du cloaking. Journaliser les robots ou accélérer une réponse mise en cache reste légitime. Le problème est une différence de contenu selon l’identité visant le classement.
  • Un test A/B réparti par page est acceptable. Traitez chaque demandeur de la même manière ; ne séparez pas robot et humain.

Le portail d’aperçu de ce site illustre le bon modèle : le Worker renvoie 404 pour /preview/ sans cookie secret, à tout le monde, Googlebot compris. Une règle uniforme ne cache pas aux robots ce qu’elle montre aux humains.

N’utilisez pas un prérendu réservé aux robots. Google qualifie le rendu dynamique de solution de contournement, pas de solution durable.

Comment un Worker peut bloquer ou ralentir Googlebot

C’est le piège le plus propre aux Workers, et il se situe généralement hors de votre code.

Bot Fight Mode échappe au moteur de règles

Bot Fight Mode et Super Bot Fight Mode peuvent produire des faux positifs, y compris contre Googlebot. Ils s’exécutent dans un pipeline distinct du moteur WAF : une règle personnalisée « allow » ou « skip » ne les neutralise pas. Pour arrêter un défi contre Googlebot, modifiez ou désactivez le mode lui-même. Vérifiez les mécanismes actuels dans les documentations Bot Fight Mode et Super Bot Fight Mode.

Modèle de règle pour les robots vérifiés

Cloudflare expose cf.client.bot et un modèle d’autorisation des robots vérifiés. Il autorise les robots connus dans les règles personnalisées WAF, mais n’atteint pas Bot Fight Mode.

Le CDN lui-même est neutre ou positif

Cloudflare en tant que CDN ne nuit pas au SEO. Le dossier Google 2024 Crawling December indique que le taux d’exploration augmente lorsqu’un CDN est détecté, tout en avertissant qu’un WAF peut bloquer Googlebot et qu’un 503 vaut mieux qu’un interstitiel de vérification. Le risque vient d’un réglage, pas de l’infrastructure.

Vérifier ce que Googlebot a réellement reçu

Après tout déploiement, contrôlez la réponse du robot :

  • Inspection d’URL GSC → Tester l’URL en direct. Vérifiez dans le HTML rendu canonique, hreflang et JSON-LD.
  • CF-Cache-Status avec le HTML. HIT, MISS ou EXPIRED révèle si la réponse vient du cache.
  • Récupération avec User-Agent Googlebot. Comparez, mais vérifiez l’identité réelle par DNS inverse puis direct et plages publiées ; la chaîne User-Agent ne prouve rien.

Hygiène de déploiement propre aux Workers

Un wrangler deploy réussi prouve que le script est livré, pas que Googlebot reçoit la bonne sortie. Traitez tout changement SEO comme une livraison enregistrée :

  • Limitez les routes. N’utilisez pas /* par réflexe ; ciblez les chemins dans wrangler.toml.
  • Vérifiez les limites actuelles. CPU, sous-requêtes et taille varient par offre ; consultez la page des limites.
  • Consignez la version. Le modèle versions et déploiements suit source, date de compatibilité, liaisons et routes. Notez la version réellement active.
  • Versionnez et prévoyez le retour arrière. Testez en préproduction, déployez progressivement et gardez la version précédente.
  • Utilisez des journaux ciblés. Workers Logs aide au diagnostic, mais l’échantillonnage et la rétention limitée n’en font pas un registre complet.
  • Définissez une condition d’arrêt et testez le retour arrière avant l’incident.
  • Purgez les caches dans le déploiement, explicitement pour chaque couche concernée.

Note sur Bing et perspective

Bing ne publie pas non plus de guide propre au edge. Comme le déploiement est instantané et l’exploration non, IndexNow convient après une table de redirections ou une modification de balises. Cloudflare propose aussi « Redirects for AI Training », qui redirige les robots d’entraînement vérifiés vers le canonique. Ce contraste rappelle de vérifier tout traitement conditionné au robot.

Pour les comparaisons de plateformes, Snippets, gouvernance et file de développement, revenez au guide Edge SEO.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.