Una regola “cache everything” applicata a tutto il sito può accelerare le pagine pubbliche e, nello stesso momento, rompere login, carrello o area riservata. Il problema non è Cloudflare: è il perimetro della regola. Su WordPress la cache HTML va riservata ai visitatori anonimi, mentre richieste autenticate e percorsi dinamici devono raggiungere l’origine.
La cache HTML non è neutra
Cloudflare memorizza normalmente asset statici come immagini, CSS e JavaScript; l’HTML dinamico richiede invece una Cache Rule che lo renda idoneo. È qui che nasce il rischio operativo. Se una pagina personale finisce all’edge, un utente può ricevere una risposta costruita per un’altra sessione oppure non ottenere il cookie necessario al login. La documentazione Cloudflare segnala tra i sintomi redirect verso la pagina di accesso, sessioni che non persistono, errori CSRF e assenza dell’header Set-Cookie. WordPress, inoltre, usa wordpress_logged_in_[hash] per riconoscere l’utente autenticato sul frontend. La conseguenza pratica è semplice: non basta decidere quali URL mettere in cache; bisogna escludere anche le richieste che portano cookie di sessione. Prima di intervenire, elenca le superfici dinamiche del sito: login, amministrazione, anteprime, ricerca interna, form con stato, area cliente e, se presente, l’intero flusso WooCommerce.
Configura prima i bypass
In Cloudflare crea prima una regola con azione Bypass cache. Deve intercettare almeno /wp-admin/, /wp-login.php, le anteprime e le richieste che contengono wordpress_logged_in_. Su WooCommerce aggiungi carrello, checkout, account e i cookie di sessione effettivamente presenti sul sito. Solo dopo crea una seconda regola, meno specifica, che renda idoneo alla cache l’HTML pubblico per richieste GET senza quei segnali. L’ordine conta: il bypass deve vincere prima della regola generale. Cloudflare documenta sia il match sul campo Cookie sia l’azione “Eligible for cache”; non copiare però una lista generica alla cieca, perché plugin membership, multilingua o e-commerce possono introdurre cookie propri. Apri DevTools, completa i flussi reali e annota i cookie che cambiano la risposta. Se la pagina dipende dall’identità o da uno stato utente, deve restare fuori dalla cache condivisa.
Verifica con due sessioni e gli header
Il test minimo usa due finestre separate: una anonima e una autenticata. Nella sessione anonima richiama due volte una pagina pubblica e controlla l’header CF-Cache-Status; dopo il primo passaggio può comparire HIT, se origine e regole consentono la cache. Nella sessione autenticata la stessa pagina deve invece risultare DYNAMIC o BYPASS, e il contenuto deve riflettere l’utente corrente. Ripeti il controllo su login, anteprima, ricerca, form, carrello e checkout. Un semplice curl -I https://esempio.it/pagina/ aiuta a leggere gli header della visita anonima, ma non sostituisce il browser per i flussi con cookie. Verifica anche Cache-Control e Set-Cookie: un Edge TTL che ignora le direttive dell’origine può forzare in cache una risposta che l’applicazione considerava privata. Infine modifica una pagina e accertati che il purge renda visibile la nuova versione.
L’errore da evitare e il take finale
L’errore più comune è attivare la cache HTML su tutto il dominio, vedere un HIT e considerare il lavoro concluso. Quel test misura soltanto che la cache risponde; non dimostra che login e contenuti personalizzati siano corretti. Il controllo va fatto prima e dopo l’autenticazione, con almeno un flusso che scrive stato. Per una PMI il criterio giusto non è massimizzare la percentuale di cache, ma ridurre il lavoro dell’origine senza peggiorare l’esperienza o condividere risposte private. Parti da un perimetro piccolo: articoli, pagine istituzionali e landing senza personalizzazione. Estendilo solo dopo aver osservato header e comportamento reale. Se non puoi descrivere con precisione quali cookie e percorsi cambiano la risposta, non forzare l’HTML all’edge. Approfondimenti ufficiali: cache WordPress su Cloudflare, diagnosi dei problemi di login e cookie di autenticazione WordPress.