Menu

Advanced Mode

Advanced mode — the domain list

Switching to Advanced mode shows a table with one row per domain on your account:

WSA - Advance settings

The icons

  • ★ Defaults (first row) — your personal "profile" that applies to every domain set to Default. Edit this once and the same settings apply across all your domains automatically.
  • 🏠 Main domain — your primary domain (the one tied to your cPanel account).
  • 🌐 Addon / Subdomain — extra domains or subdomains you've added.

The three buttons per domain

Each domain (not the Defaults row) has a three-button switch:

ButtonWhat it means
DefaultThis domain uses your Defaults profile (row 1). Change Defaults and this domain follows along automatically.
NoneCaching is disabled for this domain. Every visit goes straight to your application. Useful for admin-only sites or applications that absolutely cannot be cached.
CustomThis domain has its own settings, independent of Defaults. Click the pencil to edit them.

You can click any of the three to switch the domain's state. The pencil icon to the right opens the editor (described below).

The save confirmation

When you make a change, a "Saved" overlay briefly appears on the row — that's confirmation that your change has been written and applied. The change takes effect within a few seconds.

Advanced mode — the editor

Clicking the pencil opens the editor popup. It looks like this:

WSA - Advance editor

General principles

Every option you'll see in any tab has the same shape:

  • A clear title and a one-line description
  • An (i) more-info button next to options that need extra explanation — click it for a tooltip with examples and gotchas
  • A default value indicator ("Default: …") that tells you what the inherited value is — so you always know what your setting will fall back to if you leave it blank

A consistent rule:

Empty a field → it returns to the default on save.

This is the easiest way to undo a change without remembering what the original value was.

Basic tab — Security headers

The Basic tab is four toggles that control extra HTTP headers your server sends to visitors' browsers.

WSA - Advance editor, security setting

Show "Powered-By" header

On: Adds a small identifying header to every response that says "This site is served through WSA". Useful when you're troubleshooting and want a quick way to confirm WSA is active.

Off: Removes the header. Some operators prefer to not advertise the technology stack on their public site.

Recommendation: Leave On unless you have a specific policy against advertising the stack.

Show cache status header

On: Each response includes a small label telling you what WSA did with that specific request:

LabelMeaning
HITServed from cache — fast!
MISSGenerated fresh by your site, and now stored for next time
BYPASSSkipped the cache on purpose (matched a bypass rule)
EXPIREDCached version was too old; got a fresh one
REVALIDATEDChecked with your site and confirmed the cache was still good

To see this in action: open your site, press F12 in your browser, go to the Network tab, click a request, look in Response Headers for X-Nginx-Cache-Status.

Recommendation: Leave On. This is the best debugging tool you have when something doesn't feel right.

Add XSS protection header

On: Tells older browsers (Internet Explorer, old Edge) to use their built-in XSS attack blocker. Modern browsers ignore this header but having it is best practice for compliance scans.

Off: Removes the header.

Recommendation: Leave On. Zero downside.

Add Content-Type Options header

On: Tells browsers to trust your file types and not "sniff" them. Defends against attacks where a fake image file is
secretly run as JavaScript.

Off: Removes the header.

Recommendation: Leave On. This is a baseline security header for any modern site.

Bot Protection tab

WSA can automatically block unwanted bot traffic before it reaches your site, lowering server load and improving real-user
performance. Bots are grouped into eight categories — for each, you choose one of three states.

WSA - advance editor, bot protection

The three states

For every category, you pick one:

StateMeaning
Server defaultUse whatever your hosting provider has set globally. Recommended for almost every category. The "Default:" pill to the right tells you what your provider has chosen.
BlockedForce-block this category for this domain, even if your hosting provider has it allowed elsewhere.
AllowedForce-allow this category for this domain, even if your hosting provider blocks it for other domains.

The eight categories explained

🔍 AI search and assistants

AI tools that look up your page when a real person asks them a question (e.g. someone asks ChatGPT to summarise your article). Generally beneficial — blocking them only reduces your visibility in AI-driven search products.

Recommendation: Leave Server default (usually Allowed).

🖐 AI user-initiated tools

Browser extensions or plugins triggered by user clicks ("Summarise this page", "Translate this article"). Always low-volume and tied to real user intent.

Recommendation: Leave Server default (usually Allowed).

🤖 AI training crawlers

Autonomous bots that scrape your site continuously to build AI training datasets. They consume bandwidth without providing any
direct benefit to your site.

Recommendation: Leave Server default (usually Blocked).

When you choose Blocked, you can also see and edit the list of specific bot identifiers being blocked. The shipped list
covers the well-known offenders (GPTBot, ClaudeBot, Bytespider, etc.). You can:

  • Add a new bot to block — type the User-Agent name in the text box, click +.
  • Remove a bot from your block list — click the × on the bot's tag.
  • Reset the list to defaults — click Apply default values below the tags.

🔬 Security scanners

Vulnerability scanning bots used by attackers to probe for weaknesses. Almost always malicious; legitimate security testing uses identified user agents you control.

Recommendation: Leave Server default (usually Blocked).

📈 SEO spiders

Marketing tools like AhrefsBot, SEMrushBot, Majestic that crawl the web to power SEO analysis products. Note: this does not
include Google, Bing, DuckDuckGo, or other search engines that power normal web search — those are never blocked.

Recommendation:

  • If you use Ahrefs, SEMrush, or similar tools to track your site, leave Server default (usually Allowed).
  • If these bots are causing noticeable load and you don't use the products, pick Blocked.

🎭 Fake user-agents

Bots that send a User-Agent string clearly invented (e.g. a version of Chrome that never existed). Almost always low-effort abuse.

Recommendation: Leave Server default (usually Blocked).

📑 Strict headers

Optional stricter check: require requests to carry the Accept-Language and Accept-Encoding headers (real browsers
always do; simple scripts often don't).

Recommendation: Leave Server default (usually Allowed). Only set Blocked if you're confident your real visitors all
use modern browsers — has a small false-positive rate on corporate proxies.

❓ Empty User-Agent

Blocks requests that arrive with no User-Agent header. Real browsers and well-behaved bots always send one — an empty UA almost always means a misconfigured script or a probe.

Recommendation: Leave Server default (usually Blocked).

Important: the "empty list while Blocked" rule

If you switch a category to Blocked and then remove every bot from the list, you'll see this warning:

⚠️ An empty list in Blocked mode will apply the server default values. To fully disable protection on this domain,
choose Allowed instead.

Why: When the list is empty AND state is Blocked, WSA falls back to your provider's default list. An empty list almost
certainly means "I haven't decided yet", not "block nothing".

If you want NO bot blocking for this category on this domain: switch the state to Allowed instead of trying to empty the Blocked list.

One bot, one category

A given bot identifier can only be in ONE category at a time. If you try to add gptbot to AI training while it's already in
AI search, you'll get an error message. Remove it from the other category first.

Dynamic tab — Pages and APIs

Dynamic content means web pages, HTML, JSON API responses — any output your application generates on the fly. This is the tab that most directly affects "how fast does my home page load?" for first-time visitors.

WSA - Advance editor - dynamic cache

Activate dynamic caching

The master switch for this whole tab. When OFF, none of the other settings apply — every page request goes straight to your application without ever touching the cache.

Recommendation: Keep ON. Turn it off only for special sites that genuinely can't be cached at all.

Bypass Cache-Control header

Some applications (or some themes / plugins inside them) tell browsers and caches not to store responses by sending a Cache-Control: no-cache header. Sometimes the application is wrong — the page IS cacheable, but a leftover header from years ago forbids it.

ON (Bypass enabled): WSA ignores those headers and caches anyway, based on your Server cache duration setting.

OFF (the default): WSA respects what your app says.

⚠️ Use carefully: turning this ON means YOU take responsibility for ensuring the page is actually safe to cache.
Pages with per-user data behind this toggle could leak data across users if you don't have the cookie / URI bypass lists set
up correctly to carve out logged-in users.

Server cache duration

How long WSA keeps a copy of a page after generating it. Pick a number and a unit (seconds, minutes, hours, days, weeks, months).

What your site isRecommended duration
News, blog homepage5 to 15 minutes
Product catalog1 hour
Brochure / mostly static1 day
Documentation site1 week
Restaurant menu, business hours1 day

Higher duration = more cache hits = faster site, but content takes longer to update on the live site. If you frequently update
content and want changes to be visible immediately, you can also manually clear the cache after publishing.

Browser cache duration

How long the visitor's browser keeps a copy. This is separate from the server cache. With the browser cache, repeat visits to the same page don't even reach your server.

ValueEffect
0 (the typical default)Browser doesn't cache pages — every visit checks back with the server (which still serves from its own cache, very fast).
5 to 15 minutesQuick repeat visits skip the server entirely. Risk: a content update is invisible to the user until their browser cache expires.

Recommendation: For dynamic pages, leave this at 0 or very low (a few minutes). The server-side cache (above) gives you most of the speed without the freshness risk.

Cookie bypass list

Cookies are how your site identifies logged-in users, shopping cart contents, etc. WSA should NEVER cache pages for logged-in users — they'd see each other's data.

The cookie bypass list tells WSA: "If you see one of these cookies in a request, don't try to cache the response, just pass
it through to my application."

The shipped defaults already cover most common cases. You typically only need to add cookies if your site uses custom ones the defaults don't know about.

Recommended additions for common platforms:

PlatformCookies to add
WordPress (covered by default)wordpress_logged_in_*, wp-postpass_*, comment_author_*
WooCommerce (covered by default)woocommerce_cart_hash, woocommerce_items_in_cart
Custom session-based sitePHPSESSID, your-app-session-name
Membership pluginThe plugin's session cookie name

To add a cookie: type the name in the text box, click + or press Enter. To remove: click the × on the cookie tag.

The * wildcard at the end matches anything (e.g. wordpress_logged_in_* matches wordpress_logged_in_abc123, wordpress_logged_in_xyz789, etc.).

URI bypass list

Same idea as cookies, but for URL paths. Any request whose URL matches one of the listed patterns will skip the cache entirely.

The shipped defaults already cover most admin paths and checkout flows. You typically only need to add paths if your site has custom URLs that should never be cached.

Common additions:

PathWhy bypass
/wp-admin (covered by default)WordPress admin
/cart, /checkout (covered)E-commerce cart and checkout
/admin, /dashboardCustom admin area
/api/private/*Per-user API endpoints
/preview, ?preview=trueContent preview before publishing

Wildcards (*) and query strings (?nocache=1) work in patterns.

JS / CSS tab — Scripts and stylesheets

Same idea as the Dynamic tab but for .css and .js files. The controls are simpler — no cookie bypass (scripts and styles don't depend on cookies) and no Cache-Control bypass.

WSA - Advance editor, JS and CSS

JavaScript and CSS files normally have version numbers in their URLs (style.css?v=4.7.2), so a new version means a new URL and the old cached copy doesn't matter. That's why server and browser cache durations can both be long without causing problems.

When to bypass a CSS or JS path: If you're a developer and your build process overwrites app.js without versioning it, add /app.js to the bypass list so you can see your changes immediately. For most users, leave this list empty.

Images & Fonts tab — Media

Same controls as JS/CSS but for images, fonts, videos, PDFs, and other media. Images especially can be cached for a very long time — they rarely change in place.

WSA - Advanced editor - Images and fonts.

When to bypass a media path:

  • If you have user avatars that overwrite the same filename (/avatars/user-12.png) — bypass /avatars/ so a profile picture update shows immediately.
  • A live-generated chart endpoint that returns a different PNG on every call.
  • A signed download endpoint where each URL is unique.

For most users, leave this list empty.

Saving your changes

At the bottom of the popup:

  • Cancel discards every change you made and closes the popup. Useful for "let me see what's in here without committing to anything".
  • Save writes your changes and closes the popup.

When you click Save:

  1. WSA checks every value for validity (numbers in range, bot tokens in valid format, etc.). If anything is wrong, a red banner at the top of the editor tells you which field to fix.
  2. Your changes are written and your site's cache configuration is regenerated.
  3. Within a few seconds, the new settings are live.
  4. The editor closes and the row in the domain list flashes "Saved".

If something goes wrong with the regeneration (very rare), the editor stays open with an error message describing the problem.

Starting over from defaults

If you've made changes you regret and want to wipe everything clean for a domain:

  1. On the domain list, click the Default button on that domain's row.
  2. The custom settings are removed, and the domain immediately uses your Defaults profile (or your provider's defaults if you haven't customised the Defaults row).

To reset just one section of one domain (say, only the bot protection but keep your cache durations):

  1. Open the editor on that domain.
  2. Switch to the Bot Protection tab.
  3. For each category, switch the tristate back to Server default.
  4. Save.

The other tabs' settings are untouched.

Recommended settings by website type

If you're not sure where to start, here are sensible profiles by common site type.

WordPress blog

  • Mode: Simple → Update daily
  • Or in Advanced:
    • Dynamic: server cache 1 hour, browser cache 0
    • JS/CSS: defaults
    • Images & Fonts: defaults
    • Bot Protection: defaults
    • Basic: all ON

Online store (WooCommerce, PrestaShop, Magento)

  • Mode: Simple → Online store
  • Or in Advanced:
    • Dynamic: server cache 30 minutes, browser cache 0
    • Cookie bypass list MUST include your platform's cart cookies (the shipped defaults cover the major platforms; if you have a custom checkout flow, add its cookies here)
    • URI bypass list MUST include /cart, /checkout, and your account / login paths
    • JS/CSS: defaults
    • Images & Fonts: defaults

Brochure / business website (mostly static)

  • Mode: Simple → Update weekly
  • Or in Advanced:
    • Dynamic: server cache 1 day, browser cache 5 minutes
    • JS/CSS: defaults
    • Images & Fonts: defaults
    • Bot Protection: defaults

Documentation site

  • Mode: Advanced
  • Dynamic: server cache 1 week, browser cache 1 hour
  • JS/CSS: defaults
  • Images & Fonts: defaults
  • Bot Protection: defaults

Admin-only tool or real-time application

  • Mode: Advanced, set the domain to None (caching off)
  • Or: Simple → No caching

Custom application with login areas

  • Mode: Advanced
  • Dynamic: server cache 5 to 15 minutes
  • Cookie bypass list: add your application's session cookie name
  • URI bypass list: add /admin, /dashboard, or whatever URL your logged-in area uses
  • Bot Protection: defaults

Frequently asked questions

  1. Open your site in a browser.
  2. Press F12 to open developer tools.
  3. Go to the Network tab.
  4. Refresh the page.
  5. Click any request in the list.
  6. Look for the response header X-Nginx-Cache-Status — it'll say HIT, MISS, BYPASS, or one of the other values.

If you see HIT on repeat visits, WSA is doing its job.

WSA's server cache stores responses for the duration you set in the Server cache duration field. To force-refresh:

  1. Use the Clear cache button on the WSA cPanel home (if visible).
  2. Or wait for the cache duration to expire naturally.
  3. Visitors with their own browser cache (browser cache duration > 0) will see the old version until their browser cache also expires — you can't directly force their refresh.

For development, set Browser cache duration to 0 while iterating on a design.

Common causes:

  • A cookie in the Cookie bypass list is being set on every page. Inspect your cookies in browser DevTools.
  • A Cache-Control: no-cache header is coming from your application (turn on the Bypass Cache-Control toggle to override, OR fix the source header in your app).
  • The URL matches a URI bypass list entry.
  • The page is in the admin area (covered by default bypass).

Don't. This is the cardinal rule of caching. If WSA caches a page that has user-specific content (the user's name in the
header, their cart contents, etc.), other users would see that data.

The default WSA setup excludes logged-in users via the cookie bypass list. Keep it that way.

Check the tri-state state for the AI training category:

  • If it's Server default, your provider's policy applies — it may not block that specific bot.
  • If it's Allowed, you've explicitly told WSA to let this category through.
  • If it's Blocked, your list is being enforced. Verify the bot's User-Agent token is exactly in your list (case-insensitive but punctuation-sensitive).

Also check the empty list while Blocked warning — if you've removed every entry, WSA falls back to defaults instead of blocking nothing.

  • Did you click Save? Closing the popup or hitting Cancel discards changes.
  • Did the "Saved" overlay flash on the row? If not, the save failed silently — refresh the page and try again.
  • Is your browser caching the page itself? Force-refresh with Ctrl+Shift+R.

WSA's cache files are stored on the server — they aren't directly browsable from cPanel for technical reasons. The cache hit-rate is shown on your hosting provider's WHM dashboard; if you'd like a summary for your account, ask your provider.

Not from cPanel. The "Clear cache" button (when present on the WSA home page) clears your whole account. For per-page purging you'd need to wait for the natural TTL expiration or coordinate with your hosting provider.

Yes. WSA sits on the server; the CDN sits in front of the server. Each cache layer works independently:

  • The CDN serves repeat visitors directly from edge locations.
  • When the CDN misses, it hits your server, where WSA serves from its own cache.
  • Only when WSA also misses does your application generate the response.

The cache layers reinforce each other.

No. Your domain-specific settings (the Custom state) override server-wide changes. Your Default state domains will pick up
the provider's new defaults automatically — that's the entire point of inheritance.

Need more help?

  • Talk to your hosting provider — they manage the server-wide WSA configuration and can answer questions specific to your hosting plan.
  • Check the WSA cPanel home page for the Documentation link for the latest version of this guide.
  • Visit Astral Internet for support contact information.
Mode avancé

Mode avancé — la liste des domaines

Passer en mode avancé affiche un tableau comportant une rangée par domaine de votre compte :

WSA - cPanel- Menu avancé

💡 Astuce — choisissez « Défaut » pour la plupart de vos domaines et ne personnalisez que ceux qui ont des besoins particuliers.

Les icônes

  • ★ Défauts (première rangée) — votre « profil » personnel qui s'applique à tout domaine réglé sur Défaut. Modifiez-le une seule fois et les mêmes paramètres s'appliquent automatiquement à tous vos domaines.
  • 🏠 Domaine principal — votre domaine primaire (celui rattaché à votre compte cPanel).
  • 🌐 Domaine additionnel / Sous-domaine — domaines ou sous-domaines supplémentaires que vous avez ajoutés.

Les trois boutons par domaine

Chaque domaine (sauf la rangée Défauts) possède un sélecteur à trois boutons :

BoutonSignification
DéfautCe domaine utilise votre profil Défauts (rangée 1). Modifiez les Défauts et ce domaine suit automatiquement.
AucunLa mise en cache est désactivée pour ce domaine. Chaque visite va directement à votre application. Utile pour les sites réservés aux administrateurs ou les applications qui ne peuvent absolument pas être mises en cache.
Perso.Ce domaine possède ses propres paramètres, indépendants des Défauts. Cliquez sur le crayon pour les modifier.

Vous pouvez cliquer sur l'un des trois pour changer l'état du domaine. L'icône de crayon à droite ouvre l'éditeur (décrit plus bas).

La confirmation d'enregistrement

Lorsque vous faites un changement, une superposition « Enregistré » apparaît brièvement sur la rangée — c'est la confirmation que votre changement a été inscrit et appliqué. Le changement prend effet en quelques secondes.

Mode avancé — l'éditeur

Cliquer sur le crayon ouvre la fenêtre de l'éditeur. Elle ressemble à ceci :

WSA - cPanel- Menu avancé, éditeur

Principes généraux

Chaque option que vous verrez dans n'importe quel onglet a la même forme :

  • Un titre clair et une description d'une ligne
  • Un bouton d'info (i) à côté des options qui nécessitent une explication supplémentaire — cliquez dessus pour obtenir une infobulle avec des exemples et des pièges à éviter
  • Un indicateur de valeur par défaut (« Défaut : … ») qui vous indique la valeur héritée — vous savez ainsi toujours sur quelle valeur votre réglage retombera si vous le laissez vide

Une règle constante :

Videz un champ → il revient à la valeur par défaut lors de l'enregistrement.

C'est la façon la plus simple d'annuler un changement sans avoir à vous souvenir de la valeur d'origine.

Onglet De base — En-têtes de sécurité

L'onglet De base contient quatre bascules qui contrôlent des en-têtes HTTP supplémentaires que votre serveur envoie aux navigateurs des visiteurs.

WSA - Avancé, sécurité

Afficher l'en-tête « Powered-By »

Activé : Ajoute un petit en-tête d'identification à chaque réponse qui indique « Ce site est servi par WSA ». Utile lorsque
vous dépannez et que vous voulez un moyen rapide de confirmer que WSA est actif.

Désactivé : Retire l'en-tête. Certains exploitants préfèrent ne pas annoncer leur pile technologique sur leur site public.

Recommandation : Laissez Activé, sauf si vous avez une politique précise contre l'annonce de votre pile technologique.

Afficher l'en-tête d'état du cache

Activé : Chaque réponse inclut une petite étiquette qui vous indique ce que WSA a fait avec cette requête précise :

ÉtiquetteSignification
HITServi depuis le cache — rapide!
MISSGénéré frais par votre site, puis stocké pour la prochaine fois
BYPASSCache contourné volontairement (correspond à une règle de contournement)
STALELa version en cache était trop vieille; elle sera servi, mais une nouvelle version sera préparé en arrière plan.

Pour voir cela en action : ouvrez votre site, appuyez sur F12 dans votre navigateur, allez dans l'onglet Réseau, cliquez sur une
requête, et cherchez X-Nginx-Cache-Status dans les En-têtes de réponse.

Recommandation : Laissez Activé. C'est le meilleur outil de dépannage dont vous disposez quand quelque chose vous semble anormal.

Ajouter l'en-tête de protection XSS

Activé : Indique aux vieux navigateurs (Internet Explorer, ancien Edge) d'utiliser leur bloqueur d'attaques XSS intégré. Les
navigateurs modernes ignorent cet en-tête, mais l'avoir est une bonne pratique pour les analyses de conformité.

Désactivé : Retire l'en-tête.

Recommandation : Laissez Activé. Aucun inconvénient.

Ajouter l'en-tête Content-Type Options

Activé : Indique aux navigateurs de faire confiance à vos types de fichiers et de ne pas les « renifler ». Protège contre les
attaques où un faux fichier image est secrètement exécuté comme du JavaScript.

Désactivé : Retire l'en-tête.

Recommandation : Laissez Activé. C'est un en-tête de sécurité de base pour tout site moderne.

Onglet Protection des robots

WSA peut bloquer automatiquement le trafic de robots indésirables avant qu'il n'atteigne votre site, ce qui réduit la charge du serveur et améliore la performance pour les vrais utilisateurs. Les robots sont regroupés en huit catégories — pour chacune, vous
choisissez l'un des trois états.

WSA - Protection des robots.

Les trois états

Pour chaque catégorie, vous en choisissez un :

ÉtatSignification
Défaut serveurUtilise le réglage global défini par votre hébergeur. Recommandé pour presque chaque catégorie. La pastille « Défaut : » à droite vous indique le choix de votre hébergeur.
BloquéForce le blocage de cette catégorie pour ce domaine, même si votre hébergeur l'autorise ailleurs.
AutoriséForce l'autorisation de cette catégorie pour ce domaine, même si votre hébergeur la bloque pour d'autres domaines.

Les huit catégories expliquées

🔍 Recherche et assistants IA

Outils IA qui consultent votre page lorsqu'une vraie personne leur pose une question (p. ex. quelqu'un demande à ChatGPT de résumer votre article). Généralement bénéfique — les bloquer ne fait que réduire votre visibilité dans les produits de recherche basés sur l'IA.

Recommandation : Laissez Défaut serveur (habituellement Autorisé).

🖐 Outils IA lancés par l'usager

Extensions ou modules de navigateur déclenchés par les clics de l'utilisateur (« Résumer cette page », « Traduire cet article »).
Toujours à faible volume et liés à une intention réelle de l'utilisateur.

Recommandation : Laissez Défaut serveur (habituellement Autorisé).

🤖 Robots d'entraînement IA

Robots autonomes qui aspirent votre site en continu pour bâtir des jeux de données d'entraînement d'IA. Ils consomment de la bande passante sans procurer aucun avantage direct à votre site.

Recommandation : Laissez Défaut serveur (habituellement Bloqué).

Lorsque vous choisissez Bloqué, vous pouvez aussi voir et modifier la liste des identifiants de robots précis qui sont bloqués. La liste fournie couvre les fautifs bien connus (GPTBot, ClaudeBot, Bytespider, etc.). Vous pouvez :

  • Ajouter un nouveau robot à bloquer — tapez le nom du User-Agent dans la boîte de texte, cliquez sur +.
  • Retirer un robot de votre liste de blocage — cliquez sur le × sur l'étiquette du robot.
  • Réinitialiser la liste aux valeurs par défaut — cliquez sur Appliquer les défauts sous les étiquettes.

🔬 Analyseurs de sécurité

Robots d'analyse de vulnérabilités utilisés par des attaquants pour sonder les faiblesses. Presque toujours malveillants; les tests de
sécurité légitimes utilisent des agents utilisateurs identifiés que vous contrôlez.

Recommandation : Laissez Défaut serveur (habituellement Bloqué).

📈 Robots de SEO

Outils marketing comme AhrefsBot, SEMrushBot et Majestic qui parcourent le Web pour alimenter des produits d'analyse SEO.

Note : cela n'inclut pas Google, Bing, DuckDuckGo ou les autres moteurs de recherche qui alimentent la recherche Web normale — ceux-ci ne sont jamais bloqués.

Recommandation :

  • Si vous utilisez Ahrefs, SEMrush ou des outils semblables pour suivre votre site, laissez Défaut serveur (habituellement Autorisé).
  • Si ces robots causent une charge notable et que vous n'utilisez pas ces produits, choisissez Bloqué.

🎭 Faux agents utilisateurs

Robots qui envoient une chaîne User-Agent manifestement inventée (p. ex. une version de Chrome qui n'a jamais existé). Presque toujours de l'abus à faible effort.

Recommandation : Laissez Défaut serveur (habituellement Bloqué).

📑 En-têtes stricts

Vérification optionnelle plus stricte : exiger que les requêtes portent les en-têtes Accept-Language et Accept-Encoding (les vrais navigateurs le font toujours; les scripts simples souvent pas).

Recommandation : Laissez Défaut serveur (habituellement Autorisé). Ne réglez sur Bloqué que si vous êtes certain que tous vos vrais visiteurs utilisent des navigateurs modernes — il y a un faible taux de faux positifs sur les proxys d'entreprise.

❓ User-Agent vide

Bloque les requêtes qui arrivent sans en-tête User-Agent. Les vrais navigateurs et les robots bien élevés en envoient toujours un — un UA vide signifie presque toujours un script mal configuré ou une sonde.

Recommandation : Laissez Défaut serveur (habituellement Bloqué).

Important : la règle de la « liste vide en mode Bloqué »

Si vous passez une catégorie en Bloqué puis que vous retirez chaque robot de la liste, vous verrez cet avertissement :

⚠️ Une liste vide en mode Bloqué appliquera les valeurs par défaut du serveur. Pour désactiver complètement la protection sur
ce domaine, choisissez plutôt Autorisé.

Pourquoi : Lorsque la liste est vide ET que l'état est Bloqué, WSA retombe sur la liste par défaut de votre hébergeur. Une liste vide signifie presque certainement « je n'ai pas encore décidé », et non « ne rien bloquer ».

Si vous ne voulez AUCUN blocage de robots pour cette catégorie sur ce domaine : passez l'état à Autorisé au lieu d'essayer de
vider la liste Bloqué.

Un robot, une catégorie

Un identifiant de robot donné ne peut se trouver que dans UNE catégorie à la fois. Si vous essayez d'ajouter gptbot à Entraînement IA alors qu'il est déjà dans Recherche IA, vous obtiendrez un message d'erreur. Retirez-le d'abord de l'autre
catégorie.

Onglet Dynamique — Pages et API

Le contenu dynamique désigne les pages Web, le HTML, les réponses d'API en JSON — toute sortie que votre application génère à la volée. C'est l'onglet qui influence le plus directement « à quelle vitesse ma page d'accueil se charge-t-elle? » pour les nouveaux visiteurs.

Activer la mise en cache dynamique

L'interrupteur maître de tout cet onglet. Lorsqu'il est sur OFF, aucun des autres paramètres ne s'applique — chaque requête de page va directement à votre application sans jamais toucher au cache.

Recommandation : Gardez sur ON. Ne le désactivez que pour les sites spéciaux qui ne peuvent vraiment pas être mis en cache du tout.

Ignorer l'en-tête Cache-Control

Certaines applications (ou certains thèmes / extensions à l'intérieur) disent aux navigateurs et aux caches de ne pas stocker les réponses en envoyant un en-tête Cache-Control: no-cache. Parfois l'application a tort — la page EST cachable, mais un en-tête
laissé là il y a des années l'interdit.

ON (contournement activé) : WSA ignore ces en-têtes et met quand même en cache, selon votre réglage de Durée du cache serveur.

OFF (le défaut) : WSA respecte ce que dit votre application.

⚠️ À utiliser avec prudence : activer ceci signifie que VOUS prenez la responsabilité de vous assurer que la page peut
réellement être mise en cache sans danger. Les pages comportant des données propres à chaque utilisateur derrière cette bascule
pourraient laisser fuir des données entre utilisateurs si vous n'avez pas bien configuré les listes de contournement par témoins /
URI pour exclure les utilisateurs connectés.

Durée du cache serveur

Combien de temps WSA conserve une copie d'une page après l'avoir générée. Choisissez un nombre et une unité (secondes, inutes,
heures, jours, semaines, mois).

Ce qu'est votre siteDurée recommandée
Nouvelles, page d'accueil de blogue5 à 15 minutes
Catalogue de produits1 heure
Site vitrine / surtout statique1 jour
Site de documentation1 semaine
Menu de restaurant, heures d'ouverture1 jour

Une durée plus longue = plus de succès de cache = site plus rapide, mais le contenu prend plus de temps à se mettre à jour sur le site en ligne. Si vous mettez le contenu à jour fréquemment et voulez que les changements soient visibles immédiatement, vous pouvez aussi vider le cache manuellement après la publication.

Durée du cache navigateur

Combien de temps le navigateur du visiteur garde une copie. C'est distinct du cache serveur. Avec le cache navigateur, les
visites répétées de la même page n'atteignent même pas votre serveur.

ValeurEffet
0 (le défaut typique)Le navigateur ne met pas les pages en cache — chaque visite revérifie auprès du serveur (qui sert quand même depuis son propre cache, très rapidement).
5 à 15 minutesLes visites répétées rapides évitent entièrement le serveur. Risque : une mise à jour de contenu est invisible pour l'utilisateur jusqu'à l'expiration de son cache navigateur.

Recommandation : Pour les pages dynamiques, laissez à 0 ou très bas (quelques minutes). Le cache côté serveur (ci-dessus) vous donne l'essentiel de la vitesse sans le risque sur la fraîcheur.

Liste de contournement par témoins

Les témoins (cookies) sont la façon dont votre site identifie les utilisateurs connectés, le contenu du panier, etc. WSA ne devrait JAMAIS mettre en cache des pages pour des utilisateurs connectés — ils verraient les données les uns des autres.

La liste de contournement par témoins dit à WSA : « Si tu vois l'un de ces témoins dans une requête, n'essaie pas de mettre la réponse en cache, transmets-la simplement à mon application. »

Les valeurs par défaut fournies couvrent déjà la plupart des cas courants. Vous n'avez généralement à ajouter des témoins que si
votre site en utilise des personnalisés que les défauts ne connaissent pas.

Ajouts recommandés pour les plateformes courantes :

PlateformeTémoins à ajouter
WordPress (couvert par défaut)wordpress_logged_in_*, wp-postpass_*, comment_author_*
WooCommerce (couvert par défaut)woocommerce_cart_hash, woocommerce_items_in_cart
Site personnalisé basé sur des sessionsPHPSESSID, le nom de session de votre application
Extension d'adhésionLe nom du témoin de session de l'extension

Pour ajouter un témoin : tapez le nom dans la boîte de texte, cliquez sur + ou appuyez sur Entrée. Pour retirer : cliquez sur le × de l'étiquette du témoin.

Le caractère générique * à la fin correspond à n'importe quoi (p. ex. wordpress_logged_in_* correspond à wordpress_logged_in_abc123, wordpress_logged_in_xyz789, etc.).

Liste de contournement par URI

Même idée que pour les témoins, mais pour les chemins d'URL. Toute requête dont l'URL correspond à l'un des motifs listés évitera entièrement le cache.

Les valeurs par défaut fournies couvrent déjà la plupart des chemins d'administration et des parcours de paiement. Vous n'avez
généralement à ajouter des chemins que si votre site possède des URL personnalisées qui ne devraient jamais être mises en cache.

Ajouts courants :

CheminPourquoi le contourner
/wp-admin (couvert par défaut)Administration WordPress
/cart, /checkout (couverts)Panier et paiement de commerce électronique
/admin, /dashboardZone d'administration personnalisée
/api/private/*Points d'API propres à chaque utilisateur
/preview, ?preview=trueAperçu du contenu avant publication

Les caractères génériques (*) et les chaînes de requête (?nocache=1) fonctionnent dans les motifs.

Onglet JS / CSS — Scripts et feuilles de style

Même idée que l'onglet Dynamique, mais pour les fichiers .css et .js. Les contrôles sont plus simples — pas de contournement par témoins (les scripts et les styles ne dépendent pas des témoins) et pas de contournement de Cache-Control.

WSA - Avancé, cache CSS et JS

Les fichiers JavaScript et CSS portent normalement des numéros de version dans leur URL (style.css?v=4.7.2), de sorte qu'une
nouvelle version signifie une nouvelle URL et que l'ancienne copie en cache n'a plus d'importance. C'est pourquoi les durées de cache serveur et navigateur peuvent toutes deux être longues sans causer de problèmes.

Quand contourner un chemin CSS ou JS : Si vous êtes développeur et que votre processus de compilation écrase app.js sans le
versionner, ajoutez /app.js à la liste de contournement pour voir vos changements immédiatement. Pour la plupart des utilisateurs, laissez cette liste vide.

Onglet Images & Polices — Médias

Mêmes contrôles que pour JS/CSS, mais pour les images, polices, vidéos, PDF et autres médias. Les images, en particulier, peuvent être mises en cache très longtemps — elles changent rarement sur place.

WSA - avancé, images et police

Quand contourner un chemin de média :

  • Si vous avez des avatars d'utilisateurs qui écrasent le même nom de fichier (/avatars/user-12.png) — contournez /avatars/ pour qu'une mise à jour de photo de profil s'affiche immédiatement.
  • Un point de terminaison de graphique généré en direct qui retourne un PNG différent à chaque appel.
  • Un point de téléchargement signé où chaque URL est unique.

Pour la plupart des utilisateurs, laissez cette liste vide.

Enregistrer vos changements

Au bas de la fenêtre :

  • Annuler rejette tous les changements que vous avez faits et ferme la fenêtre. Utile pour « laissez-moi voir ce qu'il y a là-dedans sans m'engager à quoi que ce soit ».
  • Enregistrer inscrit vos changements et ferme la fenêtre.

Lorsque vous cliquez sur Enregistrer :

  1. WSA vérifie la validité de chaque valeur (nombres dans la plage, identifiants de robots dans un format valide, etc.). Si quelque chose ne va pas, une bannière rouge en haut de l'éditeur vous indique quel champ corriger.
  2. Vos changements sont inscrits et la configuration de cache de votre site est régénérée.
  3. En quelques secondes, les nouveaux paramètres sont en ligne.
  4. L'éditeur se ferme et la rangée dans la liste des domaines fait clignoter « Enregistré ».

Si quelque chose tourne mal lors de la régénération (très rare), l'éditeur reste ouvert avec un message d'erreur décrivant le problème.

8. Repartir des valeurs par défaut

Si vous avez fait des changements que vous regrettez et que vous voulez tout remettre à zéro pour un domaine :

  1. Dans la liste des domaines, cliquez sur le bouton Défaut sur la rangée de ce domaine.
  2. Les paramètres personnalisés sont retirés, et le domaine utilise immédiatement votre profil Défauts (ou les défauts de votre hébergeur si vous n'avez pas personnalisé la rangée Défauts).

Pour réinitialiser seulement une section d'un domaine (disons, seulement la protection des robots tout en gardant vos durées de cache) :

  1. Ouvrez l'éditeur sur ce domaine.
  2. Passez à l'onglet Protection des robots.
  3. Pour chaque catégorie, remettez le sélecteur à trois états sur Défaut serveur.
  4. Enregistrez.

Les paramètres des autres onglets restent intacts.

Paramètres recommandés par type de site Web

Si vous ne savez pas par où commencer, voici des profils sensés selon les types de site courants.

Blogue WordPress

  • Mode : Simple → Mise à jour quotidienne
  • Ou en mode Avancé :
    • Dynamique : cache serveur 1 heure, cache navigateur 0
    • JS/CSS : valeurs par défaut
    • Images & Polices : valeurs par défaut
    • Protection des robots : valeurs par défaut
    • De base : tout sur ON

Boutique en ligne (WooCommerce, PrestaShop, Magento)

  • Mode : Simple → Boutique en ligne
  • Ou en mode Avancé :
    • Dynamique : cache serveur 30 minutes, cache navigateur 0
    • La liste de contournement par témoins DOIT inclure les témoins de panier de votre plateforme (les défauts fournis couvrent les principales plateformes; si vous avez un parcours de paiement personnalisé, ajoutez-en les témoins ici)
    • La liste de contournement par URI DOIT inclure /cart, /checkout et vos chemins de compte / connexion
    • JS/CSS : valeurs par défaut
    • Images & Polices : valeurs par défaut

Site vitrine / d'entreprise (surtout statique)

  • Mode : Simple → Mise à jour hebdomadaire
  • Ou en mode Avancé :
    • Dynamique : cache serveur 1 jour, cache navigateur 5 minutes
    • JS/CSS : valeurs par défaut
    • Images & Polices : valeurs par défaut
    • Protection des robots : valeurs par défaut

Site de documentation

  • Mode : Avancé
  • Dynamique : cache serveur 1 semaine, cache navigateur 1 heure
  • JS/CSS : valeurs par défaut
  • Images & Polices : valeurs par défaut
  • Protection des robots : valeurs par défaut

Outil réservé aux administrateurs ou application en temps réel

  • Mode : Avancé, réglez le domaine sur Aucun (cache désactivé)
  • Ou : Simple → Aucune mise en cache

Application personnalisée avec zones de connexion

  • Mode : Avancé
  • Dynamique : cache serveur 5 à 15 minutes
  • Liste de contournement par témoins : ajoutez le nom du témoin de session de votre application
  • Liste de contournement par URI : ajoutez /admin, /dashboard, ou quelle que soit l'URL qu'utilise votre zone connectée
  • Protection des robots : valeurs par défaut

Foire aux questions

  1. Ouvrez votre site dans un navigateur.
  2. Appuyez sur F12 pour ouvrir les outils de développement.
  3. Allez dans l'onglet Réseau.
  4. Rafraîchissez la page.
  5. Cliquez sur n'importe quelle requête dans la liste.
  6. Cherchez l'en-tête de réponse X-Nginx-Cache-Status — il indiquera HIT, MISS, BYPASS, ou l'une des autres valeurs.

Si vous voyez HIT lors des visites répétées, WSA fait son travail.

e cache serveur de WSA stocke les réponses pendant la durée que
vous avez réglée dans le champ Durée du cache serveur. Pour forcer
un rafraîchissement :

  1. Utilisez le bouton Vider le cache sur la page d'accueil WSA de cPanel (s'il est visible).
  2. Ou attendez que la durée de cache expire naturellement.
  3. Les visiteurs avec leur propre cache navigateur (durée de cache navigateur > 0) verront l'ancienne version jusqu'à ce que leur cache navigateur expire aussi — vous ne pouvez pas forcer directement leur rafraîchissement.

Pour le développement, réglez la durée du cache navigateur à 0 pendant que vous travaillez sur un design.

Causes courantes :

  • Un témoin de la Liste de contournement par témoins est défini sur chaque page. Inspectez vos témoins dans les outils de développement du navigateur.
  • Un en-tête Cache-Control: no-cache provient de votre application (activez la bascule Ignorer Cache-Control pour le remplacer, OU corrigez l'en-tête source dans votre application).
  • L'URL correspond à une entrée de la Liste de contournement par URI.
  • La page est dans la zone d'administration (couverte par le contournement par défaut).

Non. C'est la règle cardinale de la mise en cache. Si WSA met en cache une page comportant du contenu propre à un utilisateur (le nom de l'utilisateur dans l'en-tête, le contenu de son panier, etc.), les autres utilisateurs verraient ces données.

La configuration WSA par défaut exclut les utilisateurs connectés via la liste de contournement par témoins. Gardez-la ainsi.

Vérifiez l'état du sélecteur à trois états pour la catégorie Entraînement IA :

  • S'il est sur Défaut serveur, la politique de votre hébergeur s'applique — elle ne bloque peut-être pas ce robot précis.
  • S'il est sur Autorisé, vous avez explicitement dit à WSA de laisser passer cette catégorie.
  • S'il est sur Bloqué, votre liste est appliquée. Vérifiez que le jeton User-Agent du robot est exactement dans votre liste (insensible à la casse, mais sensible à la ponctuation).

Vérifiez aussi l'avertissement liste vide en m

  • Avez-vous cliqué sur Enregistrer? Fermer la fenêtre ou cliquer sur Annuler rejette les changements.
  • La superposition « Enregistré » a-t-elle clignoté sur la rangée? Sinon, l'enregistrement a échoué silencieusement — rafraîchissez la page et réessayez.
  • Votre navigateur met-il la page elle-même en cache? Forcez un rafraîchissement avec Ctrl+Maj+R.

Les fichiers de cache de WSA sont stockés sur le serveur — ils ne sont pas directement consultables depuis cPanel pour des raisons techniques. Le taux de succès du cache est affiché sur le tableau de bord WHM de votre hébergeur; si vous voulez un sommaire pour votre compte, demandez à votre hébergeur.

Pas depuis cPanel. Le bouton « Vider le cache » (lorsqu'il est présent sur la page d'accueil WSA) vide tout votre compte. Pour la purge page par page, vous devriez attendre l'expiration naturelle du TTL ou vous coordonner avec votre hébergeur.

Oui. WSA se trouve sur le serveur; le CDN se trouve devant le serveur. Chaque couche de cache fonctionne indépendamment :

  • Le CDN sert les visiteurs répétés directement depuis les emplacements en périphérie.
  • Lorsque le CDN manque, il frappe votre serveur, où WSA sert depuis son propre cache.
  • Ce n'est que lorsque WSA manque aussi que votre application génère la réponse.

Les couches de cache se renforcent mutuellement.

Non. Vos paramètres propres au domaine (l'état Perso.) ont préséance sur les changements à l'échelle du serveur. Vos domaines
en état Défaut adopteront automatiquement les nouveaux défauts de l'hébergeur — c'est tout le but de l'héritage.

Besoin de plus d'aide?

  • Parlez à votre hébergeur — c'est lui qui gère la configuration WSA à l'échelle du serveur et qui peut répondre aux questions propres à votre plan d'hébergement.
  • Consultez le lien Documentation sur la page d'accueil WSA de cPanel pour la dernière version de ce guide.
  • Visitez Astral Internet pour les coordonnées du soutien technique.
Sidebar