Header HTTP: come controllarli e correggerli

Perché gli header HTTP contano davvero

Gli header HTTP sono una parte invisibile ma decisiva di ogni sito web. Raccontano al browser come trattare una pagina, indicano al motore di ricerca come interpretare una risorsa, aiutano la cache a funzionare bene e, in certi casi, rafforzano la sicurezza dell’intero dominio.

Quando un sito sembra “andare”, ma mostra problemi strani di login, cache, redirect, download, SEO o sicurezza, spesso la causa è nascosta proprio qui. Un header sbagliato può non generare errori evidenti, ma produrre effetti collaterali difficili da capire: pagine che non vengono memorizzate, file scaricati con il nome sbagliato, contenuti duplicati, cookie non persistenti o policy di sicurezza troppo deboli.

La buona notizia è che il controllo degli header è una delle verifiche più semplici da fare e, allo stesso tempo, una delle più utili. Basta sapere cosa osservare e dove intervenire.

Cosa sono gli header HTTP, in pratica

Ogni risposta del server contiene una serie di metadati. Alcuni servono al browser, altri ai proxy, altri ancora ai motori di ricerca. Sono linee come Content-Type, Cache-Control, Strict-Transport-Security o X-Frame-Options.

In sintesi:

• header di contenuto: definiscono tipo e codifica della risposta;
• header di cache: stabiliscono se e per quanto tempo memorizzare una risorsa;
• header di sicurezza: limitano comportamenti rischiosi nel browser;
• header di controllo: gestiscono redirect, compressione, cookie e compatibilità.

Una configurazione corretta non significa “aggiungere più header possibile”. Significa inviare quelli giusti, con valori coerenti, evitando conflitti tra server, CMS, plugin e CDN.

Quando conviene controllarli

Il controllo degli header è utile in diversi casi reali:

• il sito è lento ma la cache sembra attiva e non lo è davvero;
• WordPress mostra problemi con login o area admin dopo un plugin di sicurezza;
• Google segnala contenuti duplicati o canonical incoerenti;
• un file PDF si apre nel browser invece di scaricarsi;
• il browser blocca risorse esterne per mancanza di policy corrette;
• un sito in HTTPS non è pienamente protetto da una configurazione HSTS;
• una CDN riscrive o sovrascrive gli header del server origin.

In molti ambienti hosting il problema nasce da più livelli che si sovrappongono: pannello di controllo, web server, applicazione, plugin e CDN. Per questo il controllo va fatto in modo ordinato, partendo dalla risposta effettiva del server e non da ipotesi astratte.

I principali header da conoscere

Content-Type

Indica al client il tipo di contenuto restituito. Esempio: text/html; charset=UTF-8. Se questo header è errato, il browser può interpretare male il file o mostrare caratteri corrotti.

Cache-Control

Gestisce la cache lato browser e intermediari. È uno degli header più importanti per performance e comportamento delle pagine statiche. Un valore sbagliato può impedire la cache oppure conservarla troppo a lungo.

Expires

È un controllo di cache più vecchio, ancora presente in molti setup. Oggi viene spesso affiancato o sostituito da Cache-Control.

ETag

Aiuta a verificare se una risorsa è cambiata. Utile in certi scenari, ma in alcuni ambienti può generare incoerenze se la configurazione è distribuita su più nodi.

Strict-Transport-Security

Conosciuto come HSTS, dice al browser di usare solo HTTPS per un certo periodo. È potente, ma va attivato solo quando il sito è stabile su HTTPS e tutti i sottodomini sono sotto controllo.

X-Frame-Options

Serve a prevenire l’incorporamento della pagina in iframe non autorizzati, riducendo il rischio di clickjacking.

X-Content-Type-Options

Con il valore nosniff impedisce al browser di “indovinare” il tipo MIME. È un piccolo header con un grande valore pratico.

Referrer-Policy

Controlla quante informazioni di provenienza vengono inviate ai siti di destinazione. Utile per privacy e sicurezza.

Content-Security-Policy

È uno degli header di sicurezza più potenti. Limita origini, script, immagini, font e altre risorse consentite. Se impostato male può rompere il sito, ma se fatto bene riduce parecchio il rischio di XSS.

Set-Cookie

Non è un header “di sicurezza” in senso stretto, ma è fondamentale: contiene parametri come Secure, HttpOnly e SameSite, che influenzano sessioni e protezione dei cookie.

Come controllare gli header in modo rapido

Il metodo più veloce è usare il browser, ma per una verifica seria conviene affiancare anche un controllo da terminale o da strumenti online affidabili.

Dal browser:

1. Apri la pagina da verificare.
2. Apri gli strumenti sviluppatore.
3. Vai nella scheda della rete.
4. Ricarica la pagina.
5. Seleziona la richiesta principale e osserva la sezione degli header di risposta.

Dal terminale, se hai accesso SSH, il controllo è ancora più pulito perché vedi la risposta reale del server senza cache del browser:

curl -I https://example.com

Se vuoi vedere anche il percorso completo della risposta:

curl -svo /dev/null https://example.com

Esito atteso: devi trovare gli header che ti interessano, con valori coerenti rispetto a HTTPS, cache, MIME type e sicurezza. Se un header manca, non significa sempre errore, ma va valutato nel contesto.

Come leggere ciò che vedi

Il punto non è collezionare header, ma interpretare le incongruenze.

• Se Cache-Control è troppo permissivo sulle pagine dinamiche, rischi contenuti obsoleti.
• Se non c’è Content-Type corretto, il browser può comportarsi in modo imprevedibile.
• Se HSTS è attivo ma il sito ha ancora risorse HTTP, puoi provocare blocchi o warning.
• Se una CDN inserisce header propri, potresti non vedere l’effetto delle modifiche fatte sul server origin.
• Se il CMS o un plugin riscrive gli header, la configurazione del web server non basta da sola.

Per questo conviene sempre testare sia la home sia una pagina interna, sia un file statico come un’immagine o un CSS. Gli header possono cambiare in base al tipo di risorsa.

Dove si modificano su Apache

Su Apache gli header si impostano di solito nel virtual host, in un file di configurazione del dominio o, in ambienti consentiti, nel file .htaccess. Il metodo corretto dipende dal livello di accesso che hai.

In un hosting con pannello, la via più ordinata è intervenire nella configurazione del dominio o nella sezione dedicata alle direttive personalizzate. In assenza di accesso diretto al virtual host, .htaccess può essere una soluzione pratica, ma va usato con cautela perché ogni richiesta lo rilegge e perché una sintassi errata può bloccare il sito.

Esempio tipico per aggiungere alcuni header di sicurezza:

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Prima di applicare modifiche, conviene fare un backup del file coinvolto. Dopo il salvataggio, verifica sempre con curl -I o con il browser che l’header sia effettivamente presente.

Dove si modificano su Nginx

Su Nginx gli header si impostano nel blocco del server o della location. È spesso la soluzione più pulita per chi gestisce VPS o server dedicati, perché la configurazione è esplicita e prevedibile.

Un esempio semplice:

add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options SAMEORIGIN always;
add_header Referrer-Policy strict-origin-when-cross-origin always;

La parola chiave always è importante in molti casi, perché forza l’invio dell’header anche su risposte non 200. Dopo la modifica, va ricaricata la configurazione e va controllato che non ci siano errori di sintassi prima del restart.

Verifica utile:

nginx -t

Esito atteso: syntax is ok e test is successful. Solo dopo questo controllo ha senso ricaricare il servizio.

Come intervenire in cPanel, Plesk e FastPanel

Nei pannelli hosting, spesso il modo migliore è usare gli strumenti già integrati, perché riducono il rischio di errori manuali.

Su cPanel, se il provider lo consente, puoi lavorare su .htaccess tramite File Manager oppure su eventuali sezioni di ottimizzazione del sito. Alcuni hosting offrono anche plugin o editor dedicati per le direttive Apache.

Su Plesk, in molti casi trovi le impostazioni del dominio e le direttive aggiuntive nella sezione hosting settings o nelle configurazioni avanzate del sito. È utile quando vuoi evitare modifiche dirette ai file del CMS.

Su FastPanel, la gestione del dominio e del web server rende più semplice intervenire sulle direttive specifiche del sito senza toccare tutto il server. La regola resta la stessa: prima verifica, poi modifica, poi controllo finale.

In qualunque pannello, evita di sovrascrivere impostazioni globali se il problema riguarda un solo sito. La correzione locale è quasi sempre più sicura e più facile da rollbackare.

WordPress: chi può cambiare gli header

Con WordPress il rischio principale è sovrapporre più livelli di configurazione. Gli header possono essere impostati dal web server, da un plugin di sicurezza, da un plugin cache, da un CDN o dal tema.

Se il sito è WordPress, prima di cambiare il server controlla sempre:

• se un plugin cache sta già inviando header personalizzati;
• se un plugin di sicurezza gestisce HSTS, CSP o cookie policy;
• se la CDN riscrive gli header in uscita;
• se il tema o il codice custom aggiungono header via PHP.

La soluzione più pulita è mantenere un solo punto di verità per ogni famiglia di header. Per esempio: cache nel sistema di caching, sicurezza nel web server, cookie nell’applicazione. Mischiare tutto in più plugin diversi è la strada più breve verso bug difficili da riprodurre.

Header e SEO: cosa conta davvero

Gli header non sono un fattore SEO diretto nel senso stretto, ma influenzano aspetti che incidono molto sulla qualità di un sito: performance, sicurezza, stabilità, indicizzazione e coerenza tecnica.

Per la SEO pratica, i punti più importanti sono:

• risposta del server coerente e veloce;
• cache corretta per pagine statiche e asset;
• redirect puliti tra HTTP e HTTPS;
• tipo contenuto corretto per HTML, CSS, JS e immagini;
• assenza di conflitti tra canonical, cache e CDN.

Un header sbagliato può far sembrare il sito lento anche quando il server è sano. Oppure può far apparire contenuti vecchi o duplicati. Per questo un audit degli header è una delle verifiche tecniche più sottovalutate.

Errori comuni da evitare

Ci sono alcuni errori ricorrenti che vale la pena riconoscere subito.

• Impostare HSTS senza aver verificato che tutto il dominio funzioni in HTTPS.
• Usare una CSP troppo rigida senza test preventivo, rompendo script e immagini.
• Mettere header duplicati su server, CMS e CDN con valori diversi.
• Dimenticare il backup del file di configurazione prima della modifica.
• Testare solo la home page e non le risorse statiche o le pagine dinamiche.

Il principio giusto è semplice: cambiare poco, testare spesso, e tenere traccia di ciò che è stato modificato.

Procedura pratica consigliata

1. Fai una fotografia dello stato attuale con curl -I e salva l’output: ti serve come riferimento e rollback.
2. Decidi dove intervenire: server, pannello, .htaccess, plugin o CDN. Scegli un solo livello per il tipo di header che vuoi correggere.
3. Modifica un solo gruppo di header alla volta, ad esempio solo sicurezza o solo cache, per capire subito l’effetto.
4. Verifica la risposta su home, pagina interna e file statico. Se usi HTTPS, controlla anche il comportamento su HTTP e redirect.
5. Se noti anomalie, annulla l’ultima modifica e riparti dal backup.

Questo approccio è più lento di un cambio massivo, ma riduce drasticamente gli errori e rende la diagnosi molto più semplice.

Quando serve un controllo più profondo

Se gli header sembrano corretti ma il comportamento del sito non cambia, il problema può essere altrove: cache lato CDN, proxy inverso, applicazione che riscrive la risposta, tema che produce output anomalo o un plugin che intercetta le intestazioni.

In questi casi conviene verificare anche:

• log del web server;
• log PHP o del CMS;
• regole del proxy o della CDN;
• eventuali redirect multipli;
• presenza di header duplicati nella stessa risposta.

Se hai accesso al server, l’analisi con curl -I e con i log è spesso sufficiente per capire dove si perde la coerenza. Se invece sei su hosting condiviso, il pannello e i supporti del provider restano la strada più sicura.

Conclusione operativa

Controllare gli header HTTP è una di quelle attività che sembrano marginali ma spesso risolvono problemi reali di cache, sicurezza e compatibilità. La chiave è osservare la risposta effettiva del server, capire dove viene generata e intervenire nel punto più vicino possibile alla sorgente del problema.

Se lavori con hosting, pannelli o WordPress, non partire dai plugin “a sentimento”. Parti dalla risposta reale, misura gli header presenti, confronta il prima e il dopo, e modifica un solo livello per volta. È il metodo più pulito, più sicuro e più facile da mantenere nel tempo.

In pratica: un buon controllo degli header non serve solo a “fare ordine”, ma a rendere il sito più stabile, più veloce e più prevedibile.