KATLA POUR WORDPRESS
Un consentement aux cookies qui ne ralentit ni WordPress ni WooCommerce.
Un seul plugin. Il retient les scripts non consentis sur le serveur, pendant que WordPress assemble encore le HTML, et non dans le navigateur une fois qu’ils sont déjà chargés. N’importe quel thème, n’importe quel page builder, et sur une boutique WooCommerce, le panier et la commande ne sont jamais touchés.
WordPress 6.3+ · PHP 7.4+WooCommerce 7.0+ (facultatif)WP-CLI inclus
wp-content/plugins/katla-consentSans code de thème
1. Installez le plugin depuis le zip et activez-le. 2. Collez votre Site ID dans Settings → Katla Consent, ou faites tout depuis WP-CLI : wp plugin activate katla-consent wp katla site-id 00000000-0000-0000-0000-000000000000 wp katla verify 3. Choisissez un mode : le widget hébergé de Katla, la bannière du plugin, ou votre propre interface sur window.KatlaConsent. 4. Ajoutez [katla_policy] à votre page de confidentialité. WooCommerce ne demande aucune étape à part. Les cookies de panier, de session et de fragments contournent le bloqueur automatiquement, et aucune règle ne peut bloquer les handles de script de la commande.
Chaque shortcode a son bloc GutenbergGuide complet →
POURQUOI LE CONSENTEMENT COINCE SUR LES SITES WORDPRESS
Les sites WordPress accumulent les plugins, et les plugins accumulent les cookies.
LE PROBLÈMEBloquer un traceur dans le navigateur, c’est une course, et un plugin d’optimisation qui réordonne vos scripts peut décider du vainqueur.
AVEC KATLALe plugin réécrit les scripts bloqués en type="text/plain" avec un data-katla-src pendant que WordPress construit la page. Il n’y a pas de course à perdre.
LE PROBLÈMENeutraliser un script jette généralement la configuration inline qui y était attachée, et la balise revient mal configurée.
AVEC KATLALes scripts inline ajoutés avec wp_add_inline_script sont conservés avec leur handle et rejoués dans l’ordre du code source dès que la catégorie est autorisée.
LE PROBLÈMEUn bloqueur de cookies qui bloque sans discernement vide les paniers et perd les sessions, et le symptôme ne ressemble en rien à la cause.
AVEC KATLALes cookies WooCommerce de panier, de session, de fragments et d’avis de boutique sont sur liste d’autorisation, par nom et par préfixe, dès que la boutique est détectée. Le bloqueur n’y touche jamais.
LE PROBLÈMEUne règle de blocage trop zélée peut faire tomber la commande, et ce sont vos clients qui vous le signalent, pas un test.
AVEC KATLAwc-cart-fragments, wc-checkout et wc-blocks-checkout sont retirés de la liste de blocage quoi que dise la règle : l’erreur ne peut pas atteindre la commande.
LE PROBLÈMEChaque plugin ajouté peut apporter des traceurs dont votre page de confidentialité n’a jamais entendu parler.
AVEC KATLAKatla analyse la page rendue, classe ce qu’il trouve et en régénère les politiques de cookies et de confidentialité. [katla_policy] les affiche côté serveur : elles sont dans le HTML, et indexables.
INSTALLATION
Installer, analyser, c’est fait.
- Installer le pluginTéléversez le zip, ou déposez katla-consent dans wp-content/plugins et activez-le. La prise en charge de WooCommerce est intégrée, pas vendue comme un module séparé.
- Connecter votre siteCollez le Site ID de votre tableau de bord Katla, ou lancez wp katla site-id et wp katla verify.
- Vérifier l’analyseLes cookies reviennent classés et décrits : panier et session en fonctionnels, pixels en marketing. Corrigez n’importe quel classement depuis le tableau de bord.
- PublierChoisissez un mode de bannière, ajoutez [katla_policy] ou son bloc à votre page de confidentialité et, si vous le souhaitez, un lien vers les préférences sur la page de commande et dans « Mon compte ».
CONÇU POUR WORDPRESS
Un plugin, deux missions.
Blocage côté serveurConditionnez un script par son handle enregistré, ou par un fragment de son URL pour ceux qu’un thème injecte sans rien enregistrer.
Commande protégée par défautLes cookies de boutique dont WooCommerce a besoin contournent le bloqueur, et les handles de script dont dépend la commande ne peuvent pas être bloqués. HPOS et les blocs panier et commande sont déclarés compatibles.
Trois modes de bannièreLe widget hébergé de Katla, la bannière du plugin, traduite via WordPress et stylée avec des propriétés CSS personnalisées, ou aucune interface si vous la construisez vous-même. « Refuser » et « Accepter » partagent la même taille, la même marge interne et la même graisse, comme l’exige le DMA.
Blocs et shortcodes[katla_policy], [katla_cookie_table], [katla_cookie_settings], [katla_block] et [katla_consent], chacun avec son bloc Gutenberg.
WP-CLI et filtreswp katla status, site-id, verify, cookies, policy et flush pour une installation scriptée, et katla_blocked_handles, katla_cookie_allowlist, katla_categories, katla_translations et katla_banner_css_vars plutôt qu’un fork.
Consent Mode v2 et GTMGA4 et Google Ads reçoivent les quatre signaux, refusés par défaut. Vos déclencheurs GTM existants lisent la même décision dans window.dataLayer.
CORE WEB VITALS
Les cookies s’émiettent. Votre SEO, non.
Les plugins de consentement sont une cause fréquente d’échec des sites WordPress aux Core Web Vitals : des centaines de kilo-octets, chargés avant tout le reste, sur une boutique où la vitesse fait le chiffre d’affaires. La bannière hébergée de Katla pèse 18 Ko en une seule requête, et les réponses cookies et politique dont le plugin a besoin sont mises en cache dans des transients au lieu d’être récupérées à chaque page vue.
Comment fonctionne le mode headless →18 kBTransféréBannière et données de vos cookies, brotli
0 msLCP ajoutéComparé à la même page sans lui
0Décalage de mise en pageLa bannière ne réserve aucun espace dans le flux
2RequêteUn seul script, mis en cache en périphérie
Nos propres mesures, réalisées le : voici comment.
Les questions des équipes WordPress
- Faut-il autre chose que le plugin WordPress pour WooCommerce ?
- Non. C’est un seul plugin, et le comportement WooCommerce s’active quand WooCommerce est actif. Rien d’autre à installer, et rien à configurer pour cela.
- Va-t-il casser mon panier ou ma page de commande ?
- C’est précisément pour ce cas que la prise en charge de WooCommerce existe. Les cookies de panier, de session et de fragments sont sur liste d’autorisation, les handles de script de la commande sont retirés de la liste de blocage même quand une règle les nomme explicitement, et le plugin déclare sa compatibilité avec HPOS et avec les blocs panier et commande.
- Et l’attribution des commandes ?
- sbjs_* est traité comme marketing plutôt que nécessaire, parce que c’est ce qu’il est. Conditionnez le handle wc-order-attribution et les cookies ne sont jamais déposés ; laissez-le tel quel, et ils attendent le consentement comme n’importe quel cookie marketing.
- Remplace-t-il mon plugin de consentement actuel ?
- Oui. Désactivez l’ancien une fois Katla actif, pour que deux bannières ne se disputent pas les mêmes cookies.
- Fonctionnera-t-il avec mon page builder ?
- Oui. Le blocage s’appuie sur les handles mis en file d’attente et sur des fragments d’URL, et l’analyse lit la page rendue plutôt que le builder : ce que le builder produit, c’est ce que Katla voit.
- Un point de vigilance ?
- Un seul. Excluez cdn.katla.app du report ou de la concaténation JS dans WP Rocket, Autoptimize et consorts. Le bloqueur de cookies doit s’exécuter avant tout ce qui dépose des cookies, et le différer est la façon la plus courante d’obtenir une installation qui semble fonctionner sans être conforme.
Analysez votre site, puis installez le plugin.
L’offre gratuite analyse votre site WordPress et génère une politique de cookies, sans carte bancaire.